开发阶段
技术方案（ Technical Solution ）
SG1 选择产品构建解决方案
SP1.1 开发详细候选解决方案和选择准则 SP1.2 开发操作概念和场景 SP1.3 选择产品构件解决方案
SG2 设计
SP2.1 运用有效的设计方法 SP2.2 建立完备的技术数据包 SP2.3 设计综合性接口 SP2.4 进行制作、购买或复用分析
SG3 实现产品设计
SP3.1 实现设计 SP3.2 编制产品支持文档
为设计、开发及实现需求的解决方案。解决方案、设计结果及实现成品包括产品、产品组件，以及与产品相关生命周期的单一过程或适当组合的过程。
提示：产品架构、系统、子系统、性能、组件的解决方案，容易出现没有记录和文档问题；
对于瀑布模型开发来说，系统或产品分解后，架构不能经常变；对于迭代模型开发来说，前一两个迭代，系统或产品的架构要确定；至于设计，对新的产品或系统，考虑如何设计，对于旧的产品，考虑如何优化设计；
概要设计和详细设计的设计准则和标准要描述和规范（基于提高复用性，可扩展性；提高效率，质量，考虑复用提高生产率。）设计准则和标准选择理由加以记录；选择的评估会议可以是非正式如周例会；
设计过程：分解到组件后，是自己做还是采购，考虑增加复用和可扩展性；提高效率和质量，考虑复用提高生产率。
项目工期紧，常常成为很多事情的理由。因为赶时间，拿到需求后，不考虑哪种设计方案更合适，想到什么办法就用什么办法来做，甚至是没有设计可言，直接编码，写设计文档变成了浪费时间的一个事情。不少人进行设计的时候，眼光都放得不够开，不知道可以从很多途径找到可重用的代码，直接自己编码实现数据操作、日志处理、权限认证等事情，结果浪费了时间，而且还不能保证自己的代码是没有问题的。不少可重用的代码都是经过严格测试的，设计架构良好的，可直接使用或者稍加修改则可以为自己所用。
设计方面常见问题：
1)无设计文档
2)有设计文档，但形同虚设
3)设计时没有考虑可以重用以前项目或者第三方的代码或组件
4)没有用需求来驱动设计
5)设计没有考虑多过一个的方案
6)没有考虑清楚设计的原则和标准
7)设计的弹性不够、架构落后？
8)代码与设计脱节？
9)到处都是面条式代码
技术解决方案主要讲述的是设计、开发、实施方面的问题。
SG1: 从候选方案中选择产品或者产品组件的解决方案
Product or product-component solutions are selected from alternative solutions.
制定选择的标准，设计候选方案，针对产规格依据选择标准，从候选方案中选出合适的方案。
这个目标的主要内容就是制定选择的标准（一般涉及成本、进度、效益、风险、技术性能等），设计候选方案，针对产品规格，依据选择标准从候选方案中选出合适的产品或产品组件解决方案。解决方案(有时称为“设计方案”、“设计概念”或“初步设计”)；初步设计或设计方案可能与产品需求和产品组件需求开发同步进行并互动（在开发或获取客户需求之后）。
很多开发人员，做编码之前都不太喜欢认真思考设计方案，迫于时间压力，不仔细考虑设计方案是否合适，就直接开展工作，这样做的风险是非常大的。
提示：产品架构、系统、子系统、性能、组件的解决方案，容易出现没有记录和文档问题；
SP1.1 开发详细的候选方案及选择的标准
Develop detailed alternative solutions and selection criteria.
先考虑好我们设计方案的选择标准，并找出可能的候选方案
典型的工作产品
1.备选解决方案筛选准则
新技术的评估报告
备选解决方案
最终选择的评选准则
对市场现有成品的评估报告
子实践
- 界定筛选准则，以作为选择备选解决方案的考虑因素
2.界定现有技术与具竞争优势的新产品技术
3.界定能满足需求的备选现成品:供方
产生备选方案
取得每一备选解决方案的完整需求配置。
开发选择最佳备选解决方案的准则
SP1.2 针对每个产品组件描述操作概念、场景、环境、操作模式和操作状态等
Evolve the operational concept,scenarios,and environments to describe the conditions,operating modes,and operating states specific to each product component.
要求对产品的规格进行详细的表述，因为我们的方案是要满足这些规格的，也只有这样，我们才能更好地找出合适的解决方案
典型的工作产品
产品组件选择决策及理由
需求及产品组件间相关性的记录
解决方案、评估及选择理由的记录
子实践
依据操作概念、操作方式及操作状态所建立的评选准则，评估各备选解决方案/解决方案组。针对每一个备选解决方案，开发产品操作及使用者互动的时序场景。
依据备选解决方案的评估，评?评选准则之适用性，必要时，更新准则。
界定并解决与备选技术方案及需求有关的问题。
选择能满足已建立之评选准则的最佳解决方案。
建立与所选择之备选方案关联的需求，此即为该产品组件的配置需求。
界定将再用（重用）或取得的产品组件解决方案。
建立并维护解决方案、评估及选择理由的文件。维护选择理由对后续决策十分重要，可以使后续干系人免于返工，也可在某些适用的应用环境下，提供对技术应用的深入见解。
SP 1.3 选择最符合要求的产品组件设计方案
Select the product-component solutions that best satisfy the criteria established.
根据选择标准选出最佳方案
有人可能有这样的疑问，有些项目很简单，或者设计方案很明确，没有必要搞什么候选方案和选择标准，直接设计就可以了。设计方案除了针对整个项目的大的设计方案，还包括组成产品的各个组件的设计方案，绝大部分情况下，一个项目肯定会有部分地方技术不太明确需要仔细分析的。另外，不管怎样，都应该根据项目的实际情况，定出这个项目的设计标准，就算只有一个方案，也需要用该设计标准来检验该方案。大部分情况下，认为不需要考虑多个设计方案、不考虑设计标准，都是“懒惰”思想作怪，不做这样的考虑，项目的风险是比较大的。
SG2: 开发产品或者产品组件设计
Product or product-components designs are developed.
最佳候选方案确定后，就可以开展具体的设计工作了。设计不仅是为了实现，也是为了产品生命周期阶段如修正、重新采购、维护、及安装等。设计文件提供给相关的干系人，以方便对设计的相互了解提供参考，并在产品的开发与后续的生命周期阶段设计上的改变。完整的设计描述，记录与技术数据包内。
SP2.1 开发产品或者产品组件的设计
Develop a design for the product or product components.
产品设计一般包含两个阶段，在执行上可能相互重叠：概要设计与详细设计。
概要设计建立产品功能和框架，包含产品组成区块、产品组件界定、系统状态与模式、主要的内外部接口和界面设计。常见的概要设计说明书问题有（功能模块设计、数据库设计包括逻辑设计和物理设计及安全性能设计、模块接口和界面设计）：软件性能描述不具体；性能的解决方案没有记录和文档；数据库设计包括逻辑设计和物理设计及安全性能设计不具体等；
详细设计：完整定义产品组件的结构和功能。详细设计说明书是为编码人员所写，要详细描述实现方法、算法；如是面向结构或数据流方法，数据结构和处理流程（输入、转换、输出数据流）；如是面向对象方法，设计类的函数和成员变量，并明确对象之间的相互关系。常见问题是详细设计说明书过于简单，和概要设计一样，接口（内部和外部）设计不具体；
典型的工作产品
产品架构
产品组件设计
子实践
建立并维护准则，以评估设计。
界定、开发或取得适合于产品的设计方法。选择适合的方法并在一定的工具支持下对设计提供很大的帮助，一般常用的技术和方法：原型法、面向结构化设计方法、面向对象设计方法、E-R模型、设计复用、设计模式等；
确保设计遵循所应用的设计标准与准则。
确保设计遵循已配置的需求。
记录设计。
SP2.2 建立和维护技术数据包
Establish and maintain a technical data package.
这个Practice的字面意思比较难理解，其实意思很简单，就是要建立和维护一套管理所有设计文档、数据的方法或者体制，对设计过程的数据、文档进行有效的管理。技术数据包是给开发人员的做的（主要是需求、设计资料等），设计人员不想做，开发人员非常需要。完备的技术数据包为开发者提供了开发产品或组件的综合性描述，还提供了有关产品类型的以下信息：产品架构描述、分配需求、产品组件的描述、产品相关生命周期过程描述、关键产品特性、必需的物理特征和约束、接口需求、用于确保实现需求的验证准则等。
SP2.3 根据所建立和维护的标准，设计合适的产品组件接口
Design comprehensive product-component interfaces in terms of established and maintained criteria.
考虑外部接口和内部接口；与原来系统的关系；
典型的工作产品
接口设计规格说明
接口控制文件
接口规格准则
所选之接口设计的理由
子实践
定义接口准则。一般是组织过程资产的一部分
界定与其它产品组件相关的接口。
界定与外部相关的接口。
界定介于产品组件与产品相关生命周期过程的介面。
应用准则于接口设计的备选方案。
记录已选取的接口设计与理由。
SP2.4 根据制定的标准评估哪些产品组件需要开发、购买或者重用
Evaluate whether the product components should be developed,purchased,or resued based on established criteria.
技术状况是对开发或采购产品组件作出选择的重要理由；在开发工作很复杂时，可能以采购现有组件为佳，而拥有先进工具及充足人员情况下则支持自己开发。毕竟有时购买现有的组件，可能不够完备或不能完全满足系统的需要。一旦作出采购现有组件（或外包开发）的决定，就要在供应商协议中进行落实。
典型的工作产品
设计与产品组件再用的准则
自制或采购分析
选择现有成品组件的指引
子实践
开发产品组件设计再用的准则。
分析设计以决定产品组件要自行开发、再用或采购。
当采购或选择非开发的(现成品、政府的成品及再用)时，分析维护所隐藏的代价
SG3: 实施产品设计并开发相应的支持文档
Product components,and associated support documentation,are implemented from their designs.
SP3.1 实施产品组件的设计
Implement the designs of the product components.
简单地说就是依据设计进行编码活动了
典型的工作产品
- 已实现的设计
子实践
使用有效的方法实现产品组件。比如结构化编程、面向对象编程、自动代码生成、软件代码复用、应用合适的设计模式等。
遵循适当的标准与准则。比如编码规范、过程及质量标准、编码时遵循模块化、明确、简单、可靠、安全、可维护等准则；编码规范描述内容（如编码模块的复杂度和内聚性等）
对选定的产品组件，执行同行审查。可以通过代码走查、测试等多种方式来实现；单元测试是验证是否实现设计；单元测试要提到接口测试；
适当时对产品组件执行单元测试。 这里单元测试不局限于软件，涵盖个别硬件、软件单元或先前已整合的相关组合；
必要时修订产品组件。在实现阶段发生了未能与设计阶段预见的问题，就是修订产品组件时机的范例之一。
SP3.2 开发和维护最终用户文档
Develop and maintain the end-use documentation.
开发和维护用于产品安装、操作及维护的相关文档，如用户手册、安装手册、管理员手册、在线帮助等。
典型的工作产品
终端使用者培训教材
使用者手册
操作手册
维护手册
在线求助
子实践
审查需求、设计、产品及测试结果，以确保影响安装、操作及维护等项文件的相关议题已被界定并解决。
使用有效的方法，制作安装、操作及维护的文件。
遵循适当的文件制作标准。如《技术文档编制规范》
在生命周期的初期阶段就制作安装、操作及维护等文件的初始版本，以供相关的干系人审查。
执行安装、操作及维护等文件的同行审查。
必要时修订安装、操作及维护文件。一般为需求、产品、设计、产品实现变更时 。
产品集成（ PI ）
SG1 准备产品集成
SP1.1 建立产品集成战略 SP1.2 建立产品集成环境 SP1.3 规定详细的产品集成规程
SG2 确保接口兼容性
SP2.1 审查接口描述的完备性 SP2.2 管理接口
SG3 组装产品构件和交付产品
SP3.1 确认集成用的产品构件已经准备就绪 SP3.2 组装产品构件 SP3.3 核查组装的产品构件 SP3.4 打包和交付产品或产品构件
把组成产品的所有软件组件组装起来，使之运行在目标环境上，产品集成包括软件组件之间的集成、软件与硬件的集成、软件基础数据的录入、调试等。系统越复杂，集成就显得越发重要。
基本道理就是随时保证组成最终产品接口一致，能顺畅运行，能随时拿得出可运行的版本。(持续集成)
SG1 完成产品集成的准备工作
Preparation for product integration is conducted.
准备产品、组件集成，包含建立并维护集成的活动和活动顺序、搭建集成环境、执行集成程序。
SP1.1 确定产品组件的集成顺序
Determine the product-component integration sequence.
需要集成的产品组件包括：交付产品的一部分、测试设备、测试程序、以及其他配件等的一个综合体。
产品的集成顺序与确定技术解决方案是一致的，对于复杂的产品而言，集成应该是渐进式的，并且运用“集成-一评价-一集成”的迭代过程。集成支持产品组件渐进式组装和评价，为进一步纳入其他可用产品组件奠定良好的基础，或者是为高风险产品组件的原型设计奠定良好的基础。
具体步骤：
1、确定待集成产品组件。
这个需要注意的是，产品组件还要考虑数据库部分的集成。由于数据库设计与其他功能组件的设计不同，所以往往有专门的数据库人员来设计和维护，所以在产品集成时数据库的集成多数将成为忽略点或是难点。数据库的构架建设最好能自动化执行，因为有时数据库持续集成时可能删除原来数据库，重新自动创建数据库也许是最快捷的方法。
2、利用产品组件接口间的定义，对待集成组件进行验证和确定。
3、确定组件集成的顺序(可以为多种集成顺序方案)。还应包含明确在这些集成的顺序中的一些测试设备、测试软件、支撑产品等
4、确定最佳集成顺序。
5、定期检查集成顺序，必要时进行修改。因为在随着变更，集成顺序也会变更。另外，在集成时还要评估集成、测试环境和实际运行环境的差距，不断调整集成环境，有时集成顺序会变更。
6、记录制订产品集成方案(包括一些被否决的原因)
产品集成方案可以包含的(但不局限)内容有：
*待集成的组件
*产品集成顺序
*要做的活动
*每项活动的责任和所要求的资源
*应予满足的进度
*应予遵循的规程
*所需要的工具
等
注：这里所说的待集成的组件可能还包括数据库，数据库集成有时也是产品集成的一部分重要内容。
SP 1.2 建立和维护用于支持产品组件集成的环境
Establish and maintain the environment needed to support the integration of the product components.。
这些环境包括硬件环境、网络环境、数据环境等。
产品集成环境可以采用外部采购、复用或是自行开发。为了建立集成环境必需开发设备、软件以及其他资源的自主开发或是采购的需求。这些需求应该在前期需求开发阶段就要进行开发。是外购还是自研、重用是在制定技术解决方案阶段就应该确定的。
产品集成环境可包括：集成设备/程序、测试设备/程序、模拟器(比如一些桩程序)、记录工具等。
具体步骤：
1、确定产品集成的需求。也包括产品集成都需要什么内容?
2、确定产品整合环境的验证标准和程序。这个验证程序可以是自动化的软件程序，也可以是手工的测试流程和用例。
3、确定产品集成自研或是采购所需的产品集成环境。
4、如果无法采购所需集成环境，则进行集成环境的自研工作。
对于无前例、复杂的项目而言，产品集成环境的自研工作将是一项重要的开发工作。它本身就像一个小的项目，也应该包括项目计划、需求开发、技术解决方案、验证、确认以及风险管理等环节。
5、在整个项目执行过程中，进行维护产品集成环境。
如果产品整合环境不再使用时，应进行处理。比如：根据情况分析是否可以复用，如不可再次复用就要进行资源的释放。
SP 1.3 建立和维护产品组件集成的过程及标准
Establish and maintain procedures and criteria for integration of the product components.
这里提到了过程，与SP1.1似乎有点重复，SP1.1只强调考虑集成的现有顺序，而SP1.3要需要考虑具体的集成过程，除了集成顺序，还需要考虑每一步的验证办法、成功标准等。
产品集成流程可包括：每次增量迭代进行集成的组件和集成编号、每个集成迭代进行测试和评价的内容和验证标准等。
产品集成标准：实际上是产品集成阶段的准入、准出的标准。它可以定义如何验证产品组件期望值的功能，并定义如何验证交付最终已集成的产品。
产品集成流程和标准的内容，可以有如下内容：
*已建立组件的测试内容
接口的验证
*性能偏差的可接受程度
*产品组合与外部接口的衍生需求
*经验证的可替代元件
*测试环境的参数
*测试成本的限制问题和风险
*产品集成时，质量与成本的平衡点
*正常执行的可接受几率
*需求交付率的可接受程度
*订货到交货的时间及供货周期(需重复提供时需要)
*人员的可用性
*集成设备、生产线和环境的可用性
*具体步骤：**
1、建立并维护产品组件的产品集成流程
2、建立并维护产品组件集成与评估标准
3、建立并维护产品组件的确认与交付标准
SG2 确保产品内部与外部的接口是兼容的
The product-component interfaces,both internal and external,are compatible.
SG1的SP的工作产品一般会是集成计划、接口说明、集成标准等文档，SG1的主要任务是完成这些文档，而SG2的主要任务就是检查接口是否一致，并在发生接口变化的时候，管理接口的变化，使之保持一致。
许多产品集成的问题往往是由于产品内部接口之间或是与其相连接的外部系统的接口不兼容导致的。所以有效管理产品组件内、外部接口的需求、规格设计，可以确保接口的完整性与兼容性。
SP2.1 检查接口描述，保证覆盖性和完整性
Review interface description for coverage and completeness.
通常我们通过评审接口说明的办法来检查接口的完整性、覆盖性。除审查产品组件接口外，接口应包括产品集成所有环境的接口。
具体步骤：
1、审查接口文件的完整性，确保已涵盖所有的接口。
这个要借助在技术解决方案时编制的接口文档，明确各接口之间的相互关系。对于软件产品而言，接口文件至少应包括如下信息：
*接口用途
*接口中的参数类型说明
*接口参数的来源
*接口输出参数用途
*协议与数据特性
*影响该接口的因素
等
2、确保产品组件与接口已标识好标记，确保产品组件可以正确、容易地连接。
3、定期审查产品接口说明的充分性。
定期审查现有产品接口说明与正在开发、生产、购买等中的产品没有偏差。有时这种审查要与供应商或生产商共同审查，如有偏差应及时处理有可能涉及到的库存、生产线、用户处等范围。
SP2.2 管理产品和产品组件的内部和外部接口的定义、设计及变更
Manage internal and external interface definitions,designs,and changes for products and product components.
各组件之间是有关系的，我们需要对这些关系进行管理，保证组件间保持一致。
接口需求驱动着产品组件所需接口的开发，在开发初期就开始管理产品与产品组件的接口。接口的定义接口不仅影响产品组件和外部系统，也影响着验证、确认的环境。
接口管理包含：维护接口在整个产品周期的一致性，以及解决冲突、不符合以及变更的问题。
除产品组件接口外，还应包括在集成产品过程中所涉及到的所有接口，以及用于验证、确认、操作、调试、其它支持环境的接口。并且需要记录、维护接口变更的信息，并使其容易查询到和使用。
具体步骤：
1、确保接口在整个产品生命周期内的兼容性
2、解决冲突、不符合以及变更的问题
3、维护项目成员可以取得接口资料的的存储库
共享取用的接口资料存储库，提供确保每个成员都知道最新资料的存放处，以及获取和使用的机制，建议放到配置库中。
SG3 组合已集成的产品组件，并交付已集成、已验证、已确认的产品
Verified product components are assembled and the integrated,verified,and validated product is delivered.
主要讲的是执行集成的过程，并交付产品给客户。
根据已制定的产品组件集成的顺序，进行产品组件的集成。整合前，每一个产品组件应确定于其接口相符。集成可以分阶段逐步完成，可以将一些产品组件集成为更大、更复杂一些的产品组件，一直到整个产品集成完毕。在集成过程中，如果出现问题应用文字进行记录，并采取纠正措施。
SP3.1 在产品集成前，确定要集成的产品的产品组件已被确认、并依据其说明执行，并且确定产品集成接口符合接口说明
Confirm,prior to assembly,that each product component required to assemble the product has been properly identified,functions according to its description,and that the product-component interfaces comply with the interface descriptions.
简单的说就是在集成前，做全面的检查工作，保证各部分符合既定的要求。
确保产品要集成的已被适当的标识、确认的组件符合说明文件，并能根据集成顺序进行实际集成。检查产品组件数量、及产品组件与接口说明不一致的问题。
具体步骤：
1、当产品组件处于可进行集成的状态时，尽快跟踪所有产品组件的状态。
2、根据产品集成顺序与自动化集成程序，确保产品组件已完整提交到集成环境中。
3、确定每个正确标识的产品组件。
4、确保已标识的产品组件与说明文件一致。
5、根据预期配置进行检查配置项的状态。
6、在集成产品组件前，执行所有接口的预先检查。
SP3.2 根据产品集成顺序和相关过程集成产品组件
Assemble product components according to the product integration sequence and available procedures.
具体步骤：
1、确保产品集成环境已准备就绪。
2、确保正确地按集成顺序执行。
记录适当的集成过程中的信息，比如：集成组件在配置库中的状态(是否在基线)、产品组件序号、型式以及集成所需的仪表校正日期。
3、适当地修订产品集成顺序以及集成执行的程序。
SP3.3 评估产品组件的接口兼容性
Evaluate assembled product components for interface compatibility.
这种评估不仅是对已集成的产品或组件进行评审，还应创造使用环境进行运行，以来评估产品的功能完整性、性能、适用性等符合需求。
评估的顺序可以按集成顺序，按阶段进行。比如一个OA产品有不同的功能模块，我们可以按照集成顺序先检测登陆，再进行邮箱功能评估，最后进行文档的流转、审批功能的评估。每次集成一部分并进行分步评估，确保每次集成的产品都符合架构的要求。
具体执行步骤：
1、根据产品集成顺序与执行程序评估已集成的产品组件。
2、记录评估结果。
记录内容可以为：
*要求与集成规程的适应性
*产品配置的变更(如：备用零件以及新产品)
*评估得到的问题。
SP3.4 打包组装已集成的产品或组件，并交付给适当的客户
Package the assembled product or product component and deliver it to the appropriate customer.
某些产品的包装已经写在了需求规格或是检验标准中，当客户自己进行仓储和运送产品时这点要非常的关注。比如：
*包装经济且易于运输的需求(如货柜、集装箱装货的需求)
*可说明性(如：使用可压缩型的薄膜或泡沫等)
*易拆封且安全(如：锐利边缘、订装的可靠度、对儿童的保护、环保、重量等)
如果需要开发、制造者进行仓储、运输的话，则要注意一些隐形的包装需求。比如：跨国海运对木箱是否要进行熏蒸除虫;根据仓储地考虑室内防潮、防锈的处理等等，实际这些需求不仅会影响产品的包装，也可能会影响到产品本身的需求。对于这些包装的需求应首先参考国家或国际标准，进行设计、实施。
对于产品包装，我们应尽可能做一些可靠性的实验，已验证包装的可靠性，比如：跌落试验、盐雾试验、防水等级实验等等。
在工厂中为配合产品组件所做的调整，可能是在真是安装现场所做的不同，这时应对这些调整和原因进行记录。
具体执行步骤：
1、 审查需求、设计、产品、验证结果及文件，以确保影响产品包装与交付问题已被界定与解决。
2、 利用有效方法包装与交付已集成的产品。
3、 满足包装与交付产品的需求与标准。如：
*存储与交付媒体的类型
*软体原始及备份版本的保管信息
*必要的文件(使用说明书、维护手册等)
*版权(一般应在合同或说明书中明确)
*提供的授权(该产品授权的范围，比如：不可以直接将该产品销售，但可以进行扩展开发其他功能后进行销售)
*软件安全性
4、 为产品安装准备场地
这个准备安装场所，也可能是客户或最终用户的责任。
5、 交付产品与其相关文件，并确定收到收据。
6、 在安装场所进行安装，并确保正确操作。
安装产品可能是客户或是最终用户的责任，比如现在的手机APP。但是也有些软件是在安装现场进行安装，用户只是使用。