IPD流程中的决策与评审

概要设计的主要任务是把需求分析得到的系统扩展用例图转换为软件结构和数据结构。设计软件结构的具体任务是：将一个复杂系统按功能进行模块划分、建立模块的层次结构及调用关系、确定模块间的接口及人机界面等。数据结构设计包括数据特征的描述、确定数据的结构特性、以及数据库的设计。显然，概要设计建立的是目标系统的逻辑模型.

详细设计是软件工程中软件开发的一个步骤，就是对概要设计的一个细化，就是详细设计每个模块实现算法，所需的局部结构。在详细设计阶段，主要是通过需求分析的结果，设计出满足用户需求的嵌入式系统产品。

软件中常用的英文缩写

A

AI Action Item

活动项

C

CA Comprehensive Audit

综合检查

CCB Configuration Control Board

配置控制部

CDR Critical Design Review

关键设计评审

CD&UT Coding and Unit Testing phase

编码与单元测试阶段

CMM Capability Maturity Model

成熟度模型

CRLCMP Computer Resource Life Cycle Management Plan

计算机资源生命周期管理计划

CSCI Computer Software Configuration Item

计算机软件配置项

critical software 重要软件

D

DBDD Data Base Design Description

数据库设计描述

DCR Document Change Request

文档更改请求

DD Detailed Design Phase

详细设计阶段

DDD Detailed Design Document

详细设计文档

DDR Detailed Design Review

详细设计评审

DID Data Item Description

数据项描述

design level 设计层

F

FCA Functional Configuration Audit

功能配置审查

FA Functional Audit

功能检查

FI Formal Inspection

正式检查

FQR Formal Qualification Review

正式鉴定评审

H

HB HandBook

手册

HWCI HardWare Configuration Item

硬件配置项

I

IDD Interface Design Description

接口设计描述

IRS Interface Requirements Specification

接口需求规格说明

IT&ST Integrating and System Testing phase

组装与系统测试阶段

IS&AC Installation and Acceptance phase

安装与验收阶段

IV&V Independent Verification and Validation

独立验证与确认

K

KPA Key Process Area

关键过程域

M

management reviews 管理评审

N

NDS Non-Developmental Software

不可开发软件

P

PA Physical Audit

物理检查

PCA Physical Configuration Audit

物理配置审查

PD Preliminary Design Phase

概要设计阶段

PDD Preliminary Design Document

概要设计文档

PDR Preliminary Design Review

初步设计评审（概要设计评审）

PDS 项目开发总结

PIP 项目实施计划

PRR 阶段评审报表

PRR Product Readiness Review

产品准备就绪评审

PP&O Project Planning and Oversight

项目计划与监督

PPP 项目进展报表

Pass criteria 通过准则

project entrust organization 项目委托单位

project undertaking organization 项目承办单位

Q

quality assurance 质量保证

R

RA Requirements Analysis Phase

需求分析阶段

RMT 评审成员签字表

RPL Review Problem

评审问题记

RSR Review Summary Report

评审总结报告

S

SA&SD System Analysis and software definition phase

系统分析与软件定义阶段

SCL 源程序清单

SCM Software Configuration Management

软件配置管理

SCMP Software Configuration Management Plan

软件配置管理计划

SDD Software Design Document

软件设计文档（分成概要设计说明书[PDD]和详细设计说明书[DDD]）

SDF Software Development File

软件开发文件

SDL Software Development Library

软件开发库

SDP Software Development Plan

软件开发计划

SDR System Design Review

系统设计评审

SEI Software Engineering Institute

软件工程学会

SEPO Software Engineering Process Office

软件工程过程办公室

SOW Statement of Work

工作说明

SPR Software Problem Report

软件问题报告单

SQA Software Quality Assurance

软件质量保证

SQAP Software Quality Assurance Plan

软件质量保证计划

SRR 软件需求评审

SRR System Requirements Review

系统需求评审

SRS Software Requirment Specification

软件需求规格说明

SSDD System/Subsystem Design Description

系统/子系统设计描述

SSR Software Specification Review

软件规格说明评审

SSS System/Subsystem Specification

系统/子系统规格说明

STP 软件测试计划

STR 软件测试报告

STR Software Trouble Report

软件故障报告

STSC Software Technoligy Support Center

软件技术支持中心

SUM 用户手册

SVD Software Version Description

软件版本描述

SV&VP Software Verification and Validation Plan

软件验证与确认计划

SV&VR Software Verification and Validation Review

软件验证与确认评审

SW-CMM SoftWare Capability Maturity Model

软件成熟度模型

software 软件

software development organization 软件开发单位

software feature 软件特性

software item 软件项

software life cycle 软件生存周期

software verification and validation report软件验证与确认报告

T

TR Technical Report

技术报告

TRR Test Readiness Review

测试准备就绪评审

TSSD Total Software System Development phase

整个软件系统的开发阶段

testing 测试

test item 测试项

U

UDF Unit Development Folder

单元开发文件夹

user 用户

user documentation 用户文档

V

validation 确认

verification 验证

W

WBS Work Breakdown Structure

工作明细结构

概要设计的目标是描述软件模块的外观以及处理逻辑。模块对外暴露的服务接口，以及需要引用的接口，接口标识，接口的访问协议，接口描述都属于模块的外观，其他的模块通过这些接口和模块打交道，自然需要在概要设计阶段对接口做细致的刻画，初此之外，对于关键的模块，外观还应该说明模块的非功能属性，比如并发处理能力，数据吞吐量以及接口调用的反馈时长等等。处理逻辑是指模块从输入到输出的转换过程，描述其转换算法。无论通过何种图例和表现形式，只要能够清晰地说明模块外观和处理逻辑描述，就是好的概要设计。 概要设计过程一般包括四块内容，这四块内容都是围绕着外观和处理逻辑这两个目标进行。第一部分是模块划分，把架构设计中划分的业务模块按照开发模式迭代细化，拆分成符合高内聚低耦合的功能模块。第二部分是接口描述，重点要放在刻画模块内外部交互的接口形式。第三个部分是模块的逻辑描述，最后一个部分逻辑模型设计，包括数据库的逻辑模型设计以及值对象的概要说明。 模块划分 模块划分的粒度很难确定，不同的设计师会用不同的划分策略，相同的一组功能聚集有人会分为2个功能模块，有的人可能划分为4个或者更多。模块的粒度越大，对模块的维护成本就越大，因为修改模块的任何一个点，都有可能更新整个模块；而且越难以解决模块复杂耦合的问题，随着产品的维护，模块内的耦合会越来越严重，有些是因为新的需求引起模块内联系的增加，而有些是缺少硬约束下采用最直接的方式修改代码造成的。当然也不是模块划分的越小越好，因为小粒度的模块虽然降低了模块自身的维护成本，但过多的模块会增加模块间关系维护的成本以及系统管理的复杂性。 通常来看，模块划分要符合开闭原则和高内聚和低耦合的原则。开闭原则强调的是维护频度不同的功能不要放在同一个模块内，比如有些需要本地化的功能可以通过接口和实现分离的方式划分为业务模块和二次接口实现模块。高内聚和低耦合的原则强调的是把内部关联紧密和外部交互比较单一的功能划分成一个模块。 同时鉴于模块划分的重要性，建议尽可能把模块划分的工作前移到架构设计阶段，一方面架构设计团队的整体素质比较高，另外一方面架构设计师更能够站在全局的视角合理地划分模块。 接口描述 接口描述应该清晰地说明接口的类型，访问方式，接口的入参和出参。通常在概要设计阶段不考虑物理实现，不需要描述的非常详细，之所以如此关照接口，原因在于通过清晰的接口描述为流程逻辑和后面的详细设计建立一个硬约束。模块内的数据流和控制流的入口和出口都能限定在这个约束之内，方便评审的时候能及时发现设计中存在的问题。 逻辑描述 逻辑描述的目标是说清楚从输入到输出的转换过程。根据不同的模块的特点，可以选用不同的描述形式，对于以数据流为主的模块，可以使用数据流图，控制比较复杂的可以使用数据流图或者IPO图，而对于规范使用UML的项目可以考虑使用活动图。 可能有人会很疑惑在设计中没有谈到是用面向对象方法还是结构化的方法，这可是关键的方法论问题。确实，软件研发的坛子里面除了哪种语言更好的话题以外，最容易挑起纷争的就是结构化分析与设计和面向对象分析与设计之争了。我在这里不做结论，只做一个评说。结构化分析设计出现的比较早，那时候软件的主要使用场景更多是科学计算或者自动化控制，典型的特点是用户交互界面简单，更多是批处理的作业方式，更多关注程序的处理过程是否正确高效。随着PC机时代的到来，人机交互界面在软件中占有越来越重要的地位，原来的一套软件只有一个操作员，而现在可能有很多的使用者，为了清楚地描述不同人群对软件的诉求，业务用例应运而生，这就是面向对象的起点。不同的基因决定了他们各擅道场，一个擅长于后台计算的产品设计，另一个长于面向客户服务的产品设计。 在设计中，我们可以根据需求把两者的特点灵活地结合在一起，比如算法密集的处理模块，我们可以采用数据流图，而对于和外部交互比较复杂的模块，可以引入用例图标识模块支持的使用场景。 逻辑模型的设计 逻辑模块的设计主要是数据库的设计和值对象的设计。对于数据库的逻辑模型，可以统一设计，模块中添加引用。也可以在模块中针对所引用的库表独立描述。这两种方式都可以，如果库表结构比较复杂的建议统一建模，而比较简单的模型可以采用分开描述，提升模块设计的可读性。数据库建模现在已经比较成熟，这里不再多说。 模块的输入输出，以及中间的数据对象，我们统称为值对象，在概要设计阶段的重点是描述值对象的关键属性。需要注意的一点是值对象要和处理逻辑对应起来，特别是处理逻辑中的数据流，出口入口数据，都要在值对象上加以描述。

1、TR1：在概念阶段CDCP前针对产品包需求和产品概念的评审。TR1重点关注产品包需求的完备性以及选择的产品概念是否满足产品包需求。

2、TR2：在计划阶段对产品设计规格的评审。TR2重点关注产品设计需求到产品设计规格的完备性。

3、TR3：在计划阶段对概要设计的评审，确保设计规格已经完全、正确地在概要设计中得到体现。TR3的结果将作为开发阶段的后续详细设计活动是否继续投入资源的根据。

4、TR4：保证BuildingBlock用于系统级构建之前是完整的。对于一次构建（Build）涉及到的每一个BuildingBlock，应该有且仅有一次TR4对其进行评审。任何不符合规定的情况都应该在TR4问题记录中得到记录，并进行风险评估。

5、TR4A：在SDV完成后，对产品技术上的成熟度进行评估，确保所有存在的问题和风险都进行了评估，并生成了相应的改进计划，以保证供应和制造能力足以支撑初始产品生产活动。

6、TR5：在发布给客户前对项目整体状态在设计稳定性和技术成熟度方面的独立评估活动。TR5目的是确保产品符合预定的功能和性能要求，以满足前期确定的产品包需求。

7、TR6：是一个关注于系统级的评审，确保产品的制造能力已经能适应全球范围内发货的需求。

IPDTR（TechnicalReview）是指IPD流程中定义的TR1、TR2、TR3、TR4、TR4A、TR5、TR6等7个技术评审点。用于检查IPD实施到一定阶段以后产品的技术成熟度，发现遗留的技术问题，评估存在的技术风险，给出技术上的操作建议。

3. 软件开发

3.1 软件的需求分析

3.1.1 需求分析

3.1.2 需求分析报告的编制者

3.1.3 需求报告评审

3.1.4 需求报告格式

3.2 软件的概要设计

3.2.1 概要设计

3.2.2 编写概要设计的要求

3.2.3 概要设计报告的编写者

3.2.4 概要设计和需求分析、详细设计之间的关系和区别

3.2.5 概要设计的评审

3.2.6 概要设计格式

3.3 软件的详细设计

3.3.1 详细设计

3.3.2 特例

3.3.3 详细设计的要求

3.3.4 数据库设计

3.3.5 详细设计的评审

3.3.6 详细设计格式

3.4 软件的编码

3.4.1 软件编码

3.4.2 软件编码的要求

3.4.3 编码的评审

3.4.4 编程规范及要求

3.5 软件的测试

3.5.1 软件测试

3.5.2 测试计划

3.6 软件的交付准备

3.6.1 交付清单

3.7 软件的鉴定验收

3.7.1 软件的鉴定验收

3.7.2 验收人员

3.7.3 验收具体内容

3.7.4 软件验收测试大纲

3.8 培训

3.8.1 系统应用培训

3.8.2 系统管理的培训（可选）

集成测试划分为4个阶段：计划阶段，设计阶段，实现阶段，执行阶段(实施阶段)

计划阶段

1)时间安排 概要设计完成评审后大约一个星期

2)输入 需求规格说明书 概要设计文档 产品开发计划路标

3)入口条件 概要设计文档已经通过评审

4)活动步骤 1.定被测试对象和测试范围 2.评估集成测试被测试对象的数量及难度，即工作量 3.确定角色分工和作任务4.标识出测试各阶段的时间，任务，约束等条件5.考虑一定的风险分析及应急计划6.考虑和准备集成测试需要的测试工具，测试仪器，环境等资源7.考虑外部技术支援的力度和深度，以及相关培训安排8.定义测试完成标准

5)输出 集成测试计划

6)出口条件 集成测试计划通过概要设计阶段基线评审

设计阶段

1)时间安排详细设计阶段开始

2)输入需求规格说明书概要设计集成测试计划

3)入口条件概要设计基线通过评审

4)活动步骤 1.被测对象结构分析 2.集成测试模块分析3.集成测试接口分析4.集成测试策略分析

5.集成测试工具分析6.集成测试环境分析7.集成测试工作量估计和安排。

5)输出集成测试设计(方案)

6.出口条件集成测试设计通过详细设计基线评审。

实现阶段

1)时间安排在编码阶段开始后进行

2)输入需求规格说明书概要设计集成测试计划集成测试设计

3)入口条件详细设计阶段

4)活动步骤:1.集成测试用例设计2.集成测试代码设计(如果需要)3.集成测试脚本(如果需要)4.集成测试工具(如果需要)

5)输出集成测试用例集成测试规程集成测试代码集成测试脚本集成测试工具

6)出口条件测试用例和测试规程通过编码阶段基线评审

执行阶段

1)时间安排单元测试已经完成后就可以开始执行集成测试了

2)输入 需求规格说明书概要设计集成测试计划集成高度设计集成测试例集成测试规程集成测试代码(如果有)集成测试脚本集成测试工具详细设计代码单元测试报告

3)入口条件单元测试阶段已经通过基线化评审

4)活动步骤执行集成测试用例回归集成测试用例撰写集成测试报告

5)输出集成测试报告

6)出口条件集成测试报告通过集成测试阶段基线评审

1.什么是同行评审

同行评审是一种通过作者的同行（开发、测试、QA等）来确认缺陷和需要变更区域的检查方法。

一、计划阶段

1.项目负责人指定组织者；作者自检工作产品；组织者规划本次评审，制定Review Plan

2.检查入口准则：是否符合文档标准？是否已用工具检查？代码<=500行；文档<=40页；……

3.准备评审包：评审通知单；待Review产品；参考资料；评审表单（Review Form）；评审计划(Review Plan)；

4.确定评审专家3—6人,选取原则: 评审对象所处生命周期上一阶段、当前阶段和后一阶段的参与者（就是和评审对象相关的人）

5.组织者将评审包、评审通知单发给相关人员

二、介绍会议（*可选）

1.不了解流程以及产品技术难度较高，技术较新时，由专家提出，作者讲解相关产品及流程

2.时间不超过1小时，30-60分为宜

三、准备阶段（最重要、发现缺陷最多）

1.评审专家个人独立完成工作产品的审视，提出缺陷，填写评审表单；反馈评审表单给组织者

2.准备时间大于会议时间，且应于会议前2天开始

3.组织者：汇总并检查评审表单；裁决是否需要增加评审投入（增加准备时间；增加评审专家人数；更换评审专家等）

四、Review会议（只提问题，不关注解决）

1.组织者召开评审会议（不能是作者）

2.讲解员讲解工作产品（不能是作者或组织者）

3.大家共同确认问题（评审表单中记录的问题；会上发现的问题），由组织者作裁决

4记录员记录所有的问题，并发给组织者

5.组织者更新评审表单（问题确认、问题根源、预防/修正措施）

五、第三小时会议（*可选）

在Review会议上未解决或有争议的问题，由作者决定是否召开

六、返工

作者修改工作产品，更新评审表单

七、跟踪

1.组织评审专家确认各缺陷得到了修改，并且没有引入新的缺陷；

2.协助组织者确认相关问题得到了正确修改并且没有引入新的缺陷；

3. 汇总所有需要的数据到评审表单发给相关评审专家

4.是否重新Re-review

你好！

根据你的情况，要看你们双方当时签订合同时的有关规定，和双方在合同中的权利义务，如果已明确就应该提供，如果没有规定，可以不提供，这样也不构成违约。对于合同是否失效，要根据你们上方签订的合同来确定，希望我的回答能给你带来帮助，谢谢~！

分为概要设计和详细设计两个阶段。 概要设计也称为结构设计或总体设计，主要任务是把系统的功能需求分配给软件结构，形成软件的模块结构图。

概要设计的基本任务：设计软件系统结构：划分功能模块，确定模块间调用关系；数据结构及数据库设计：实现需求定义和规格说明过程中提出的数据对象的逻辑表示；编写概要设计文档： 包括概要设计说明书、数据库设计说明书，集成测试计划等；概要设计文档评审：对设计方案是否完整实现需求分析中规定的功能、性能的要求，设计方案的可行性等进行评审。

概要设计工具：结构图（SC: Structure Chart ），反映系统的功能实现以及模块与模块之间的联系与通信，即反映了系统的总体结构。注意：数据流DFD是软件生命周期的定义阶段中的需求分析方法中结构化分析方法的一种，此外还有数据字典（DD）、判定树和判定表，而SC是开发阶段中概要设计使用的方法。 详细设计的目的：为软件结构图（SC）中的每 一个模块确定采用的算法，模块内数据结构，用某种选定的表达工具（如N-S图等）给出清晰的描述。