SG 2 开发设计

产品或产品组件设计得到开发。

产品或产品组件设计不但应当为实现提供合适的内容，而且应为诸如修改、重新采购、维护、支持与安装等产品生命周期其它阶段提供合适的内容。

设计文档为支持相关干系人对设计的相互理解提供了参考，并且支持未来在开发期间以及产品生命周期后续阶段对设计的变更。完整的设计描述得以文档化在技术数据包中，技术数据包含有特性与参数的完整范围，包括外形、安装匹配、功能、接口、制造工艺特性以及其它参数。已建立的组织级或项目级的设计标准（例如：检查单、模板、对象框架）形成基础，以达成设计文档的高规格定义与设计文档的完整性。

SP 2.1 设计产品或产品组件

开发产品或产品组件的设计。

产品设计大致由两个执行时可重叠的阶段组成：初步设计与详细设计。初步设计建立产品能力与产品架构，包括架构风格与模式、产品分块、产品组件标识、系统状态与模式、主要的组件间接口，以及产品外部接口。详细设计则完全地定义了产品组件的结构与能力。

参阅“需求开发”过程域，中的“建立必需的功能与质量属性的定义”特定实践以进一步了解如何开发架构需求。

架构定义由在需求开发过程期间所开发的架构需求集合所驱动。这些需求识别了对产品的成功有重要作用的质量属性。随着产品设计细节的建立，架构定义了结构上的元素与协调机制，这些元素与机制要么直接满足需求，要么支持需求的达成。架构可以包含支配产品组件与其接口开发的标准与设计规则，以及辅助产品开发人员的指南。“选择产品组件解决方案”特定目标中的特定实践包含如何使用产品架构作为备选解决方案基础的进一步说明。

架构师提出设想并开发产品的模型，做出判断，将功能性需求与质量属性需求分配给包括硬件与软件的产品组件。可以开发并分析支持备选解决方案的多个架构以确定在架构需求方面的优势与劣势。操作概念以及操作的、支持的与开发的场景被用于形成用例以及与质量属性相关的场景，用于对架构进行细化。在产品设计中定期执行的架构评价过程中，它们也作为手段用以评价架构对其预期目的的适合程度。

参阅“需求开发”过程域，中的“建立操作概念与场景”特定实践以进一步了解如何开发操作概念与场景用于架构评价。

架构定义任务的实例有：

• 建立分块的结构关系，以及有关分块内的元素之间接口的规则，以及有关分块之间接口的规则

• 选择支持功能性需求与质量属性需求的架构模式，并将那些模式实例化，或组成那些模式，以建立产品架构

• 识别主要的内部接口与所有的外部接口

• 识别产品组件，以及产品组件之间的接口

• 使用架构描述语言，正式定义组件行为与交互作用

• 定义协调机制（例如：对软件的、硬件的）

• 建立基础能力与服务

• 开发产品组件模板，或者类与框架

• 建立设计规则与进行决策的职权

• 定义过程／线程模型

• 定义将软件向硬件的物理分配

• 识别主要的复用途径与来源

在详细设计期间，产品架构细节被最终确定，产品组件被完整定义，并且接口的特征被完全描述。可以针对特定质量属性优化产品组件设计。设计者可以对遗留产品或COTS 产品用作产品组件的决策进行评价。随着设计的成熟，要追踪分配给低一级产品组件的需求，以确保可以满足那些需求。

参阅“需求管理”过程域，以进一步了解如何确保项目工作与需求之间的协调一致。

对于软件工程，详细设计关注于软件产品组件的开发。通过定义产品组件的内部结构，形成数据模式，开发算法，建立探试法等，以为产品组件提供满足已分配需求的能力。

对于硬件工程，详细设计关注于电子的、机械的、电光的以及其它硬件产品及其组件的产品开发。电气原理图与连接图被开发，机械与光学装配模型被生成，生产与装配工艺被制订。

CMMI模型中，TS过程域工作产品实例：

1. 产品架构

2. 产品组件的设计

CMMI模型中，TS过程域子实践：

1. 建立并维护准则，据此可以对设计进行评价。

除了期望的产品性能，可用于建立设计准则的质量属性实例有：

• 模块化

• 清晰

• 简洁

• 可维护

• 可验证

• 便携

• 可靠

• 准确

• 安全

• 可扩充

• 易用

2. 识别、开发或采购适用于产品的设计方法。

有效的设计方法可以包含活动、工具及描述性技术等广阔范围。某种方法是否有效依赖于具体情况。两家公司可能各自拥有其所专长的有效的产品设计方法，但这些方法可能在合营企业并不有效。高度成熟的方法在那些未得到方法使用方面的培训的设计者手里，也未必一定有效。方法是否有效也依赖于其给设计者提供了多大的帮助，以及该帮助的成本有效性。例如，多年的原型投入可能不适用于简单的产品组件，但对于前所未有的、昂贵的且复杂的产品开发则也许是正确的事情。然而，快速原型技术可以非常有效地用于许多产品组件。有些方法使用工具来确保设计将包含实现产品组件设计所必需的所有必要属性，这些方法也可以是有效的。例如，“了解”制造工艺能力的设计工具可以在设计容限中容许制造工艺的偏差。

可促进有效设计的技术与方法的实例有：

• 原型法

• 结构模型

• 面向对象的设计

• 实质的系统分析

• 实体关系模型

• 设计的复用

• 设计模式

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

设计标准的实例有（这些标准的一部分或全部可以是设计准则，特别是在标准尚未建立的场合）：

• 操作员接口标准

• 测试场景

• 安全标准

• 设计约束（例如：电磁兼容、信号集成、环境）

• 生产约束

• 设计容限

• 部件标准（例如：生产废料、浪费）

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

应当考虑已识别的COTS 产品组件。例如，若要将已有的产品组件放到产品架构中，也许就修改了需求与需求分配方案。

5. 将设计文档化。

SP 2.2 建立技术数据包

建立并维护技术数据包。

技术数据包为开发者提供所开发产品或产品组件的全面描述。这样的数据包也为诸如绩效保证式合约（performance based contracting）或设计蓝本式制造（build-to-print）等各种情况提供了采购方面的灵活性。

在创建初步设计、进行架构定义的文档化的过程中，设计被记录在技术数据包中。在产品的整个生命期中，要维护该技术数据包，记录下产品设计的重要细节。技术数据包提供了产品或产品组件（包括未作为单独的产品组件处理的与产品相关的生命周期过程）的描述，支持了采购策略、或产品生命周期的实现、生产、工程与物流支持阶段。这样的描述包括必需的设计配置与规程的定义，以确保产品或产品组件性能方面的充分性。它包括所有适用的技术数据，诸如绘图、相关联的清单、规格说明、设计描述、设计数据库、标准、质量属性需求、质量保证条款与打包细节。技术数据包中含有挑选进行实现的所选定备选解决方案的描述。

由于设计描述可能包含大量数据，且又对成功的产品组件开发起关键作用，所以建立组织数据与选择数据内容的准则是可取的。特别有效的是以产品架构为手段，来组织这些数据，并抽象出清晰的且与某问题点或所关心的特性相关的视图。这些视图有：

• 客户

• 需求

• 环境

• 功能

• 逻辑

• 安全

• 数据

• 状态／模式

• 建造

• 管理

这些视图文档化在技术数据包中。

CMMI模型中，TS过程域工作产品实例：

1. 技术数据包

CMMI模型中，TS过程域子实践：

1. 确定设计层次的数量，以及每一设计层次适当的文档水平。

确定需要进行文档化、并要求需求可追溯的产品组件层次的数量（例如：子系统、硬件配置项、电路板、计算机软件配置项［computer software configuration item，CSCI］、计算机软件产品组件、计算机软件单元等）对于管理文档的成本并支持集成计划与验证计划来说是重要的。

2. 确定用于进行架构文档化的视图。

视图被选择用以记录产品的内在结构并应对特定干系人的关注点。

3. 将设计的详细描述建立在已分配的产品组件需求、架构与上一级设计的基础之上。

4. 将设计文档化在技术数据包中。

5. 文档化所做出的或所定义的关键（即：对成本、进度或技术性能产生显著影响的）决策，并包括其依据。

6. 必要时修订技术数据包。

SP 2.3 使用准则设计接口

使用所建立的准则设计产品组件的接口。

接口的设计有：

• 起源

• 目标

• 软件的刺激源（stimulus）与数据特征，包括次序方面的约束或协议

• 处理特定刺激源所耗费的资源

• 对错误的或超出规定限度之外的刺激源的例外处理或出错处理行为

• 硬件的电气的、机械的与功能的特征

• 通信的服务线路

接口的准则通常体现了应当得到定义、或至少得到调查的关键参数，以确保其适用性。这些参数通常是给定的产品类型（例如：软件、机械、电气、服务）所特有的，并通常与安全性、安保性、耐久性以及任务关键性特性相关联。

参阅“需求开发”过程域，中的“识别接口需求”特定实践以进一步了解如何识别产品与产品组件的接口需求。

CMMI模型中，TS过程域工作产品实例：

1. 接口设计规格说明

2. 接口控制文档

3. 接口规格说明准则

4. 所选接口设计的依据

CMMI模型中，TS过程域子实践：

1. 定义接口准则。

这些准则可以是组织级过程资产的一部分。

参阅“组织级过程定义”过程域，以进一步了解如何建立并维护一套可用的组织级过程资产与工作环境标准。

2. 识别与其它产品组件相关联的接口。

3. 识别与外部项相关联的接口。

4. 识别产品组件和与产品相关的生命周期过程之间的接口。

举例来说，这类接口可能包括那些在待制作产品组件与制造过程中用于使制作成为可能的钻模与固定装置之间的接口。

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

参阅“决策分析与解决”过程域，以进一步了解如何使用正式的评价过程，遵循已建立的准则，对已识别的多个备选方案进行评价，以分析可能的决策。

6. 将选定的接口设计与选择的依据文档化。

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

依据所建立的准则，评价产品组件是应当自行开发、还是购买或者复用。

通常将确定采购哪些产品或产品组件的过程称之为“自制或购买分析”。这基于对项目需要的分析。自制或购买分析开始于项目早期的第一次设计迭代期间；在设计过程中继续进行；完成于对产品的开发、采购或复用的决策。

参阅“需求开发”过程域，以进一步了解如何挖掘、分析并建立客户需求、产品需求与产品组件需求。

参阅“需求管理”过程域，以进一步了解如何管理需求。

影响自制或购买决策的因素有：

• 产品将提供的功能，以及如何将这些功能融入到项目中

• 可用的项目资源与技能

• 采购成本与内部开发成本的对比

• 关键的交付与集成日期

• 战略上的业务联盟，包括高层次的业务需求

• 已具备产品的市场研究，包括COTS 产品

• 已具备产品的功能与质量

• 潜在供方的技能与能力

• 对核心竞争力的影响

• 与待采购产品相关联的许可、质保、责任与限制

• 产品的具备程度

• 专有事项

• 风险的降低

• 在需要与产品线核心资产之间的匹配度

可以采用正式评价方法来进行自制或购买决策。

参阅“决策分析与解决”过程域，以进一步了解如何使用正式的评价过程，遵循已建立的准则，对已识别的多个备选方案进行评价，以分析可能的决策。

技术在演化，产品组件的开发或购买的选择依据也会随之演化。尽管复杂的开发工作可能更支持采购现货产品组件，但在生产率及工具方面的进步可能会给出相反的依据。现货产品的文档可能不完整或不准确，并且将来是否能够得到支持也是未知数。一旦做出采购现货产品组件的决策，如何实施该决策则依赖于待采购项的类型。有时候“现货”所指的既有产品并不能拿来就用，因为必须先进行定制以满足采购方规定的特殊的性能需求与所采购的其它产品特性（例如飞机发动机）。为了管理这类采购，需建立包含这些需求与应满足的验收准则的供方协议。在其它情况下，现货产品是真正的现货（例如字处理软

件），不存在需要管理的与供方的协议。

参阅“供方协议管理”过程域，中的“建立供方协议”特定目标以进一步了解如何处理供方协议，以修改COTS 产品。

CMMI模型中，TS过程域工作产品实例：

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

2. 自制或购买分析

3. 选择COTS 产品组件的指南

CMMI模型中，TS过程域子实践：

1. 制订复用产品组件设计的准则。

2. 分析设计，以确定产品组件应该开发、复用还是采购。

3. 对已购买项或非开发项（例如：COTS、政府现货、复用）进行考虑时，分析维护的含义。

维护的含义实例有：

• 与未来所发布的COTS 产品的兼容性

• 供方变更的配置管理

• 非开发项与其解决方案中的缺陷

• 计划外的淘汰

【TS过程域相关文章】

CMMI过程域详解-技术解决方案（TS）之概述

CMMI过程域详解-技术解决方案（TS）之SG 1

CMMI过程域详解-技术解决方案（TS）之SG 2

CMMI过程域详解-技术解决方案（TS）之SG 3