CMMI3 PA之技术解决方案(TS) 过程域解释和实施指南

项目工期紧，常常成为很多事情的理由。因为赶时间，拿到需求后，不考虑哪种设计方案更合适，想到什么办法就用什么办法来做，甚至是没有设计可言，直接编码，写设计文档变成了浪费时间的一个事情。不少人进行设计的时候，眼光都放得不够开，不知道公司提供了很多可重用的代码，直接自己编码实现数据操作、日志处理、权限认证等事情，结果浪费了时间，而且还不能保证自己的代码是没有问题的。很多公司的代码都是经过严格测试的，设计架构良好的，可直接使用或者稍加修改则可以为自己所用。

概要设计和详细设计的设计准则和规范要考虑增加复用和可扩展性；要提高效率和质量，考虑复用以提高生产率。

不知道您的工作中，在设计方面是否有这样的一些问题：
1)无设计文档
2)有设计文档，但形同虚设
3)设计时没有考虑可以重用以前项目或者第三方的代码或组件
4)没有用需求来驱动设计
5)设计没有考虑多过一个的方案
6)没有考虑清楚设计的原则和标准
7)设计的弹性不够、架构落后？
8)代码与设计脱节？
9)到处都是面条式代码
......

典型的大型项目的结构化设计过程所需的设计阶段：

1. 定义需求（需求定义）

2. 定义解决方案（系统规范）

3. 概念化的解决方案（系统概要设计）

4. 划分任务（产品说明）

5. 定义产品设计（产品概要设计）

6. 将产品划分为组件（组件规范）

7. 定义组件设计（组件概要设计）

8. 将组件划分为模块（模块规范）

9. 细化解决方案（模块细化设计）

10. 实施解决方案（模块实施和测试）

技术解决方案这个PA，主要讲述的是设计开发、实现方面的问题。在CMM中，对设计、开发、实现面的要求是比较简单的。

技术解决方案(Technical Solution, TS) 的目的，为设计、开发及实现需求的解决方案。解决方案、设计结果及实现成品包括产品、产品组件，以及与产品相关生命周期的单一过程或适当组合的过程。

提示：产品架构、系统、子系统、性能、组件的解决方案，容易出现没有记录和文档问题；

对于瀑布模型开发来说，系统或产品分解后，架构不能经常变；对于迭代模型开发来说，前一两个迭代，系统或产品的架构要确定；至于设计，对新的产品或系统，考虑如何设计，对于旧的产品，考虑如何优化设计；

概要设计和详细设计的设计准则和标准要描述和规范（基于提高复用性，可扩展性；提高效率，质量，考虑复用提高生产率。）设计准则和标准选择理由加以记录；选择的评估会议可以是非正式如周例会；

设计过程：分解到组件后，是自己做还是采购，考虑增加复用和可扩展性；提高效率和质量，考虑复用提高生产率。

特定目标及实践摘要

SG 1 选择产品和产品组件解决方案

SP 1.1 开发备选解决方案及评选准则

SP 1.2 选择产品组件解决方案

SG 2 开发设计：设计产品和产品组件

SP 2.1 设计产品或产品组件

SP 2.2 建立技术相关数据

SP 2.3 使用准则设计接口

SP 2.4 执行自制、购买或再用之分析

SG 3 实现产品设计

SP 3.1 实现设计

SP 3.2 建立产品支持文件

SG1: 选择产品和产品组件解决方案：从候选方案中选择产品或者产品组件的解决方案。

这个目标的主要内容就是制定选择的标准（一般涉及成本、进度、效益、风险、技术性能等），设计候选方案，针对产品规格，依据选择标准从候选方案中选出合适的产品或产品组件解决方案。解决方案(有时称为“设计方案”、“设计概念”或“初步设计”)；初步设计或设计方案可能与产品需求和产品组件需求开发同步进行并互动（在开发或获取客户需求之后）。

提示：产品架构、系统、子系统、性能、组件的解决方案，容易出现没有记录和文档问题；

SP1.1开发备选解决方案及评选准则：开发详细的候选方案及选择的标准。

典型的工作产品

1.备选解决方案筛选准则

2. 新技术的评估报告

3. 备选解决方案

4. 最终选择的评选准则

5. 对市场现有成品的评估报告

子实践

1. 界定筛选准则，以作为选择备选解决方案的考虑因素

2.界定现有技术与具竞争优势的新产品技术

3.界定能满足需求的备选现成品:供方

4. 产生备选方案

5. 取得每一备选解决方案的完整需求配置。

6. 开发选择最佳备选解决方案的准则

SP 1.2选择产品组件解决方案：

选择最符合要求的产品组件解决方案（设计方案）。针对每个产品组件描述操作概念、场景、环境、操作模式和操作状态等选择产品组件解决方案（设计方案）。

典型的工作产品

1. 产品组件选择决策及理由

2. 需求及产品组件间相关性的记录

3. 解决方案、评估及选择理由的记录

子实践

1. 依据操作概念、操作方式及操作状态所建立的评选准则，评估各备选解决方案/解决方案组。针对每一个备选解决方案，开发产品操作及使用者互动的时序场景。

2. 依据备选解决方案的评估，评?评选准则之适用性，必要时，更新准则。

3. 界定并解决与备选技术方案及需求有关的问题。

4. 选择能满足已建立之评选准则的最佳解决方案。

5. 建立与所选择之备选方案关联的需求，此即为该产品组件的配置需求。

6. 界定将再用（重用）或取得的产品组件解决方案。

7. 建立并维护解决方案、评估及选择理由的文件。维护选择理由对后续决策十分重要，可以使后续干系人免于返工，也可在某些适用的应用环境下，提供对技术应用的深入见解。

SG1讲述的是如何找出最合适的设计方案，我们很多开发人员，做编码之前都不太喜欢认真思考设计方案，迫于时间压力，不仔细考虑设计方案是否合适，就直接开展工作，这样做的风险是非常大的。

SP1.1讲述的是先考虑好我们设计方案的选择标准，并找出可能的候选方案。SP1.2要求我们对产品的规格进行详细的表述，因为我们的方案是要满足这些规格的，也只有这样，我们才能更好地找出合适的解决方案。根据选择标准选出最佳方案。

有人可能有这样的疑问，有些项目很简单，或者设计方案很明确，没有必要搞什么候选方案和选择标准，直接设计就可以了。设计方案除了针对整个项目的大的设计方案，还包括组成产品的各个组件的设计方案，绝大部分情况下，一个项目肯定会有部分地方技术不太明确需要仔细分析的。另外，不管怎样，都应该根据项目的实际情况，定出这个项目的设计标准，就算只有一个方案，也需要用该设计标准来检验该方案。大部分情况下，认为不需要考虑多个设计方案、不考虑设计标准，都是“懒惰”思想作怪，不做这样的考虑，项目的风险是比较大的。

SG2: 开发设计

开发产品或者产品组件设计。最佳候选方案确定后，就可以开展具体的设计工作了。设计不仅是为了实现，也是为了产品生命周期阶段如修正、重新采购、维护、及安装等。设计文件提供给相关的干系人，以方便对设计的相互了解提供参考，并在产品的开发与后续的生命周期阶段设计上的改变。完整的设计描述，记录与技术数据包内。

SP2.1 设计产品或产品组件：开发产品或者产品组件的设计。产品设计一般包含两个阶段，在执行上可能相互重叠：概要设计与详细设计。

概要设计建立产品功能和框架，包含产品组成区块、产品组件界定、系统状态与模式、主要的内外部接口和界面设计。常见的概要设计说明书问题有（功能模块设计、数据库设计包括逻辑设计和物理设计及安全性能设计、模块接口和界面设计）：软件性能描述不具体；性能的解决方案没有记录和文档；数据库设计包括逻辑设计和物理设计及安全性能设计不具体等；

详细设计：完整定义产品组件的结构和功能。详细设计说明书是为编码人员所写，要详细描述实现方法、算法；如是面向结构或数据流方法，、数据结构和处理流程（输入、转换、输出数据流）；如是面向对象方法，设计类的函数和成员变量，并明确对象之间的相互关系。常见问题是详细设计说明书过于简单，和概要设计一样，接口（内部和外部）设计不具体；

典型的工作产品

1. 产品架构

2. 产品组件设计

子实践

1. 建立并维护准则，以评估设计。

2. 界定、开发或取得适合于产品的设计方法。选择适合的方法并在一定的工具支持下对设计提供很大的帮助，一般常用的技术和方法：原型法、面向结构化设计方法、面向对象设计方法、E-R模型、设计复用、设计模式等；

3. 确保设计遵循所应用的设计标准与准则。

4. 确保设计遵循已配置的需求。

5. 记录设计。

SP2.2建立和维护技术数据包。

建立和维护技术数据包。这个Practice的字面意思比较难理解，其实意思很简单，就是要建立和维护一套管理所有设计文档、数据的方法或者体制，对设计过程的数据、文档进行有效的管理。技术数据包是给开发人员的做的（主要是需求、设计资料等），设计人员不想做，开发人员非常需要。完备的技术数据包为开发者提供了开发产品或组件的综合性描述，还提供了有关产品类型的以下信息：产品架构描述、分配需求、产品组件的描述、产品相关生命周期过程描述、关键产品特性、必需的物理特征和约束、接口需求、用于确保实现需求的验证准则等。

SP2.3 使用准则设计接口

根据所建立和维护的标准，设计接口。考虑外部接口和内部接口；与原来系统的关系；

典型的工作产品

1. 接口设计规格说明

2. 接口控制文件

3. 接口规格准则

4. 所选之接口设计的理由

子实践

1. 定义接口准则。一般是组织过程资产的一部分

2. 界定与其它产品组件相关的接口。

3. 界定与外部相关的接口。

4. 界定介于产品组件与产品相关生命周期过程的介面。

5.  应用准则于接口设计的备选方案。

6. 记录已选取的接口设计与理由。

SP2.4执行自制、购买或再用之分析：根据制定的标准评估哪些产品组件需要开发、购买或者重用。

技术状况是对开发或采购产品组件作出选择的重要理由；在开发工作很复杂时，可能以采购现有组件为佳，而拥有先进工具及充足人员情况下则支持自己开发。毕竟有时购买现有的组件，可能不够完备或不能完全满足系统的需要。一旦作出采购现有组件（或外包开发）的决定，就要在供应商协议中进行落实。

典型的工作产品

1. 设计与产品组件再用的准则

2. 自制或采购分析

3. 选择现有成品组件的指引

子实践

1. 开发产品组件设计再用的准则。

2. 分析设计以决定产品组件要自行开发、再用或采购。

3. 当采购或选择非开发的(现成品、政府的成品及再用)时，分析维护所隐藏的代价。

SG3:实现产品设计：实施产品设计并开发相应的支持文档。

SP3.1 实现设计：实施产品组件的设计，简单地说就是依据设计进行编码活动了。

典型的工作产品

1. 已实现的设计

子实践

1. 使用有效的方法实现产品组件。比如结构化编程、面向对象编程、自动代码生成、软件代码复用、应用合适的设计模式等。

2. 遵循适当的标准与准则。比如编码规范、过程及质量标准、编码时遵循模块化、明确、简单、可靠、安全、可维护等准则；编码规范描述内容（如编码模块的复杂度和内聚性等）

3.对选定的产品组件，执行同行审查。可以通过代码走查、测试等多种方式来实现；单元测试是验证是否实现设计；单元测试要提到接口测试；

4. 适当时对产品组件执行单元测试。 这里单元测试不局限于软件，涵盖个别硬件、软件单元或先前已整合的相关组合；

5. 必要时修订产品组件。在实现阶段发生了未能与设计阶段预见的问题，就是修订产品组件时机的范例之一。

SP3.2建立产品支持文档：开发和维护用于产品安装、操作及维护的相关文档，如用户手册、安装手册、管理员手册、在线帮助等。

典型的工作产品

1. 终端使用者培训教材

2. 使用者手册

3. 操作手册

4. 维护手册

5. 在线求助

子实践

1. 审查需求、设计、产品及测试结果，以确保影响安装、操作及维护等项文件的相关议题已被界定并解决。

2. 使用有效的方法，制作安装、操作及维护的文件。

3. 遵循适当的文件制作标准。如《技术文档编制规范》

4. 在生命周期的初期阶段就制作安装、操作及维护等文件的初始版本，以供相关的干系人审查。

5. 执行安装、操作及维护等文件的同行审查。

6. 必要时修订安装、操作及维护文件。一般为需求、产品、设计、产品实现变更时 。