第二章过程域——技术解决方案

技术解决方案

成熟度3级的一个工程过程域

目的

技术解决方案（TS）的目的是设计、开发并实施对需求的解决方案。适当时，解决方案、设计以及实施分别或者一同完成产品、产品部件、以及与产品相关的生存期过程。

介绍

技术解决方案过程域适用于任何层面的产品体系结构以及每个产品、产品部件、与产品相关的生存期过程以及服务。本过程域注重于以下内容：

l 评价并选择满足一组分配需求的潜在的解决方案（有时被此称为“设计思路”、“设计概念”、或者“概要设计”）

l 为选定的解决方案开发详细设计（在包含制造、编码所需要的所有信息的语境中进行细化，或者实现该设计使之成为产品或产品部件）

l 实现该设计使之成为产品或产品部件

通常，这些活动相互支持。某些层面的设计在相当详细的时候还可能需要选择技术方案。产品部件的原型可能作为获得足够知识的方法，用以开发技术数据包或者一组完整的需求。

技术解决方案的特定实践不仅适用于产品或产品部件，也适用于服务和与产品相关的生存期过程。与产品相关的生存期过程与产品或产品部件协同开发。这类开发可能包括选择并采用现有的过程（包括标准过程）以及开发新的过程。

属于技术解决方案过程域的过程从需求管理过程接收产品与产品部件的需求。需求管理过程将需求开发过程创建的需求置于适当的配置管理之下并维护它们与以前的需求的可跟踪性。

对维护或支持组织来说，关于维护活动或者再设计的需要等方面的需求可能来自用户的需要或者产品部件中潜在的缺陷。运行环境的变更可能引发新的需求。这些需求可能在验证期间得到发现。验证期间可以将实际性能和规定的性能相比较，并可以确定不可接受的性能降低。属于技术解决方案过程域的过程应当被用于执行维护或支持方面的设计工作。

实现目标的关键实践

SG1选择产品部件的解决方案

从候选解决方案中选出产品或产品部件的解决方案。

在作出选择之前，应考察候选方案的相对优点。关键的需求、设计问题、以及约束得到建立，以用于候选方案的分析。为产品改进和发展提供基础的架构特性也得到考虑。从成本、进度、性能和风险等方面考察商用套装软件（COTS）的使用。COTS 候选方案可能是直接使用，也可能包含一些修改。有时可能需要对这些商品在接口方面作一些修改，或者定制某些特性，以更好地实现产品需求。

良好的设计过程有一个标志：设计是在与候选解决方案对比和评价之后选定的。对体系结构、客户化开发还是成品套件、以及产品部件的模块化等决策是需要做出的典型的设计抉择。

有时对解决方案的探索需要检查不再需要分配给更低层产品部件的相同需求的多个可行实例。这就是在产品体系结构最底层的情况。还有一些一个或多个解决方案已经固定的情况（例如指定了某个特殊的解决方案，或者需要调研诸如COTS 等可用的产品部件以便将来使用）。

通常情况下，解决方案是成套定义的。这就是说，定义下一层产品部件时，这一整套的每个产品部件的解决方案都建立了。候选解决方案不仅是处理相同需求的不同方法，还反映了不同于选定的这套解决方案的需求在产品部件之间的分配。目的是整体上优化这套方案，而不是针对某个局部。与“需求开发”过程域中的过程将会有至关重要的交互，以支持临时性地为产品部件分配需求，直到选定整套解决方案并建立最终的分配。

与产品相关的生存期过程处于选定的产品部件解决方案之中。这些与产品相关的生存期过程的实例是制造与支持过程。

SP1.1-1开发候选方案和选择准则

开发候选解决方案和选择准则。

有关如何为产品部件的解决方案临时分配需求的更多信息请参见需求开发过程域中的分配产品部件的需求特定实践。

有关如何建立选择准则并确定候选方案的更多信息请参见决策分析与解决方案过程域。

有关如何管理临时的和已建立的分配需求的更多信息请参见需求管理过程域。

候选方案基于潜在的产品体系结构并且跨越可行解决方案的设计空间。特定目标“开发设计方案”的特定实践“设计产品或产品部件”包含了关于开发潜在的产品体系结构以用于产品候选解决方案的更多的信息。

做出选择时，设计空间被缩小，其它的候选方案得到检查，直到确定满足需求与准则的最有希望的（即最佳的）解决方案。选择准则确定了为选择解决方案提供基础的关键因素。这些准则应该提供清晰的区分，并给出达到跨产品生存期的平衡解决方案时的成功标志。它们通常包括成本、进度、性能、以及风险方面的测度。

包括候选的对不同产品部件的需求分配在内的候选解决方案要频繁地得到评价。还可以将这些候选方案结构化以评价COTS 在产品体系结构中的使用。所以，应采用“需求开发”过程域中的过程来为候选解决方案提供完整而鲁棒的临时性需求分配。

对最佳解决方案的选择建立了针对该方案的临时性需求分配，得到一组分配需求。在新产品开发中，对候选方案的检查没有什么作用的情形很少见，然而，开发有例可循的产品部件时，可能不检查，或者只是最简单地检查候选解决方案。

典型工作产品

1. 候选解决方案

2. 选择准则

子实践

1. 建立并维护确定候选解决方案、选择准则以及设计问题的过程。

选择准则受到很多因素的影响，这些因素由该项目的需求以及产品的生存周期驱动。例如，与降低成本和进度风险相关的准则可能引起对COTS 解决方案的较大偏爱，如果这类选择并不导致对其它需开发的产品部件的不可接受的风险的话。使用现有的构件，诸如COTS时，不论是否需要修改，关于减少资源供给或者技术退化的准则应该得到检查，同时还应检查获得标准化的收益、维持与供应商的关系等方面的准则。选择时所采用的准则应提供一种平衡成本、收益和风险的方法。

2. 确定候选的需求分组，这些分组刻画了可行设计空间内的候选解决方案集合。

有效采用COTS 的候选方案可能提出特殊的挑战。知识渊博，熟悉候选COTS 方案的设计师可能发掘出体系结构上的机会来利用潜在的COTS 结果。

3. 确定每组候选方案中每一方案的设计问题。

4. 刻画设计问题并采取适当的行动。

适当的行动可能是将问题描述为风险并纳入风险管理、调整候选解决方案以排除问题、或者拒绝该候选方案并用其它的候选方案来替代。

5. 获得每种候选方案的完整的需求分配。

6. 将每一组候选方案的理由文档化。

SP1.1-2开发详细的候选方案和选择准则

开发详细的候选方案和选择准则。

有关如何建立用于做出决策的准则的更多信息请参见决策分析与解决方案过程域。

对于集成化的产品与过程开发

选择候选解决方案与需要提交决策分析与折中研究的其它事项的活动需要与相关干系人共同完成。这些干系人既代表业务和技术功能，也代表产品和与产品相关的生存期过程（例如制造、支持、培训、验证、以及退役处理）的同步开发。在这种模式下，重要的事项可以比传统的串行开发更早地在产品开发中提出来，并且能够在它们成为花费巨大的错误之前就得到处理。

详细的候选解决方案是“技术解决方案”过程域的一个基本概念。它们比未细化的候选项给出了更精确和完整的关于解决方案的信息。例如，基于设计内容的性能特征描述比简单的模拟更加能够保证有效地评估与理解环境和运行概念方面的影响。候选解决方案需要得到识别和分析，以保证选出一个在产品的生存期内，成本、进度、以及技术性能各方面平衡的解决方案。这些解决方案基于针对关键的产品品质而提出的产品体系结构。与特定目标“开发设计方案”相关的特定实践提供了关于开发能够并入产品候选解决方案的潜在的产品体系结构的更多信息。

候选解决方案跨越成本、进度与性能的可接受范围。产品部件的需求被接收并且与设计问题、约束、以及开发候选解决方案的准则一同得到使用。选择准则通常应该针对成本（例如时间、人员、资金）、收益（例如性能、能力、有效性）、以及风险（例如技术上的、成本的、进度的）。对详细的候选解决方案的考虑因素和选择准则包括：

l 成本（开发、采购、支持、产品生存期）

l 技术性能

l 产品部件以及与产品相关的生存期过程的复杂性

l 对产品运行与使用条件的鲁棒性，运行模式，环境，以及在与产品相关的生存期过程中的变化

l 产品的扩展与成长

l 技术上的限制

l 对建造方法与材料的敏感度

l 风险

l 需求与技术的演进

l 退役处理

l 最终用于与操作员的能力与限制

上面列出的考虑事项是一个基本集。组织应该开发筛选的准则，来缩短与其业务目的一致的候选方案清单。尽管是一个需要降低的重要参数，产品生存期成本可能超出了开发组织的控制。客户可能不愿意为短期成本较高但是能够最终降低产品整个生存期费用的特性来付账。在这种情况下，客户至少应该得到关于降低生存期成本的潜力的所有建议。用于选择最终解决方案的准则应该对成本、收益和风险提供一个平衡的途径。

典型工作产品

1. 候选方案的筛选准则

2. 对新技术的评价

3. 候选的解决方案

4. 最终解决方案的选择准则

子实践

1. 为选择一组需考察的候选解决方案确定筛选准则。

2. 为获取竞争优势确定当前使用的新的产品技术。

有关如何改进组织的技术的更多信息请参见组织革新与部署过程域。

项目应该确定适用于当前产品与过程的技术，并在产品生存期内监督当前使用的技术的进展。项目应该识别、选择、评价、并投资于新技术以获得竞争优势。候选解决方案可能包含新开发的技术，但是也可能包括在不同的应用中采用成熟的技术，或者维持当前的方法。

3. 产生候选解决方案。

4. 获得每种候选方案的完整的需求分配。

5. 开发选择最佳候选解决方案的准则。

准则中应该包含处理产品生存期内的设计问题的内容，诸如更容易引入新技术或者更好地利用商用产品的能力等规定。这方面的实例包括用于被评价候选方案的开放设计或者开放体系结构概念。

6. 对于每个候选解决方案，开发产品运行与用户交互的时间线场景。

SP1.2-2逐步完成运行概念和场景

逐步完成运行概念、场景、以及环境，以描述每一产品部件特定的条件、运行模式和运行状态。

有关产品部件运行的产品级影响和牵连的更多信息请参见需求开发过程域的建立运行概念和场景特定实践。

对于系统工程

对每一层物理上的产品分解，集成不同个人或组提出的运行概念和场景。

运行概念和场景得到逐步完成，以便选择实现后将能满足产品预期使用的产品部件解决方案。运行概念和场景将产品部件与环境、用户、以及其它产品部件的交互行为文档化，不论它们属于哪个工程科目。它们应该将运行、产品部署、交付、支持（包括维护与支持）、培训、以及退役处理等文档化，并且应针对所有模式与状态。

各种环境（运行、支持、培训等）也需要逐步演进。任何给定产品部件的环境都将受到其它产品部件以及外部环境的影响。

典型工作产品

1. 用于所有与产品相关的生存期过程（例如运行、支持、培训、制造、部署、守备、交付、以及退役清理）的产品部件的运行概念、场景、以及环境

2. 对产品部件交互活动的时间线分析

3. 用例

子实践

1. 逐步完成运行概念和场景，达到与产品部件相适应的详细程度。

2. 逐步完成产品部件的运行环境。

环境可能包括热、压力、电磁以及其它需要文档化的要素。

SP1.3-1选择产品部件的解决方案

选择最好地满足了已建立的准则的产品部件解决方案。

有关如何建立产品部件的分配需求和产品部件之间的接口需求的更多信息请参见需求开发过程域的分配产品部件需求并确定接口需求特定实践。

有关正式评价的更多信息请参见决策分析与解决方案过程域

选择最好地满足准则的产品部件建立了产品部件的需求分配。较低层的需求从选定的候选方案中产生，并被用于开发产品部件设计。产品部件之间的接口需求得到描述，主要是在功能上。物理上的接口描述也被包含在文档中，用以说明与产品外部的事物和活动的接口。

解决方案的描述和选择的理由都得到文档化。该文档在开发中演进为解决方案，详细设计得到开发，并且这些设计得到实现。维持对理由的记录对下游的决策至关重要。这些记录避免了下游干系人的返工，并且提供了洞察力，以便将技术用于适用的情形。

典型工作产品

1. 选择产品部件的决策与理由

2. 文档化的需求与产品部件关系

3. 文档化的解决方案、评价、以及理由

子实践

1. 按照运行概念、运行模式、运行状态等语境中建立的选择准则评价每个/每组候选解决方案。

2. 根据对候选方案的评价，评估选择准则的充分性，并且在必要时更新这些准则。

3. 确定并解决与候选解决方案和需求相关的问题。

4. 选择满足已建立的选择准则的最佳候选解决方案集合。

5. 建立与选定的候选方案集合相关的需求，使之成为产品部件的分配需求集合。

6. 确定将要重用或者获取的产品部件解决方案。

有关如何获取产品与产品部件的更多信息请参见供应协议管理过程域

7. 建立并维护关于解决方案、评价、以及理由的文档。

SG2 开发设计方案

开发出产品或产品部件的设计方案。

产品或产品部件的设计必须提供适当的内容，这些内容不仅是为了实现设计，还为了产品生存期的其它阶段，诸如修改、再采购、维护、支持、以及安装等。设计文档为支持相关干系人共同理解设计提供了参考，并支持未来在开发期间以及产品生存期中后继阶段对设计的更改。完整的设计在一个技术数据包中文档化，包括了完整的特性与参数，包含形式、配合、功能、接口、制造过程特性以及其它参数。已经建立的组织级或项目级设计标准（例如检查单、模板、对象框架）构成了在设计文档中实现高度的精确性与完整性的基础。

对于集成的产品与过程开发

集成化团队与产品的设计同步开发与产品相关的适当的生存期过程的设计。合适时，这些过程可能从组织的标准过程集中选择出来并且不需修改。

SP2.1-1 设计产品或产品部件

为产品或产品部件开发设计。

产品设计由两个执行时可能重叠的主要阶段组成：概要的与详细的设计。概要设计建立产品的能力与产品的体系结构，包括产品划分、产品部件识别、系统状态与模式、主要的部件间接口、以及外部产品接口。详细设计全面定义产品部件的结构与能力。

有关体系结构需求的开发的更多信息请参见需求开发过程域

体系结构定义由需求开发过程中开发的一组体系结构需求驱动。这些需求表示了对产品成功至关重要的质量与性能要点。体系结构定义了结构元素与协同机制，它们既可以直接满足需求，也可以在建立产品设计的细节时支持需求的实现。体系结构可以包括控制产品部件及其接口开发的标准与设计规则以及帮助产品开发人员的指导。“选择产品部件的解决方案”特定目标下的特定实践包含了关于将产品体系结构作为候选解决方案的基础的更多信息。

架构师假定并开发产品的模型，做出关于需求在产品部件——包括软件和硬件——之间的分配的决策。可以开发并分析支持候选解决方案的多种体系结构，以确定在体系结构需求环境中的优缺点。

运行概念和场景被用来生成用于细化体系结构的用例和质量场景。在体系结构评价过程中，它们还被用作评价体系结构对其预期目的的适应性的手段。这种评价在产品设计期间定期进行。“逐步完成运行概念和场景”特定实践给出了关于在体系结构评价中详细描述运行概念和场景的更多信息。

有关用于体系结构评价的运行概念和场景的开发的更多信息请参见需求开发过程域的“建立运行概念与场景”特定实践。

对于软件工程

除了上述任务以外，软件体系结构定义还可能包括：

l 建立各部分的结构关系以及关于各部分内部元素之间和各部分

l 之间的接口的规则

l 确定软件的主要内部接口和全部外部接口

l 确定软件产品部件

l 定义软件的协同机制

l 建立基础设施的能力与服务

l 开发产品部件的模板或者类与框架

l 建立设计规则以及关于决策制定的授权

l 定义进程/ 线程模型

l 定义软件在硬件中的物理部署

l 确定主要的重用方式与资源

详细设计期间，产品体系结构得到最终确定，产品部件得到完整定义，而且接口也得到全面描述。产品部件的设计可能得到针对特定的质量或性能特征的优化。设计师可能评价遗留产品或COTS 产品在产品部件中的使用、随着设计的成熟，指派给较底层产品部件的需求得到跟踪，以确保这些需求得到了满足。

有关如何跟踪产品部件的需求的更多信息请参见需求管理过程域

对于软件工程

详细设计注重于软件产品部件的开发。产品部件的内部结构得到定义，生成了数据模式，开发了算法，并且建立了试探法，以提供满足分配需求的产品部件能力。

典型工作产品

1. 产品体系结构

2. 产品部件设计

子实践

1. 建立并维护评价设计时所需遵循的准则。

除了预期性能之外，可以为之建立设计准则的属性的实例包括：

l 模块化

l 清晰

l 简单

l 可维护

l 可验证

l 可移植

l 可靠

l 精确

l 保密

l 可伸缩

l 可用

2. 确定、开发或者采办适用于产品的设计方法。

有效的设计方法能够包含范围广泛的活动、工具以及描述技术。给定的方法是否有效取决于环境条件。两家公司可能有针对它们专长的产品的非常有效的设计方法，但是这些方法或许不能有效地用于双方的协作。高度复杂的方法在没有受过使用这些方法的培训的设计人员手中也未必是有效的。

某种方法是否有效还取决于它给设计人员提供了多少帮助，以及这些帮助的成本效益如何。例如，多年的原型工作可能并不适用于一个简单的产品部件，但是可能适用于一项史无前例的、昂贵而复杂的产品开发。然而，快速原型技术可能对许多产品部件是高度有效的。使用工具来保证设计将涵盖所有实现产品部件设计所需要的属性的方法可能是非常有效的。例如，某种 “知道”制造过程能力的设计工具能够允许在设计公差中计入制造过程的可变性。

使有效的设计更加便利的技术与方法的实例包括：

l 原型

l 结构化模型

l 面向对象设计

l 基本系统分析

l 实体关系模型

l 设计重用

l 设计模式

3. 保证设计遵从适用的设计标准与准则。

设计标准的实例包括（这些标准中的部分或者全部可能就是设计准则，尤其是在标准尚未建立的情况下）：

l 操作员的界面标准

l 安全性标准

l 生产约束

l 设计公差

l 零件标准（例如生产上的废料与浪费）

4. 确保设计遵从分配需求。

已确定的COTS 产品部件必须得到重视。例如，将现有的产品部件置入产品体系结构可能修改需求与需求的分配。

5. 将设计文档化。

SP2.2-3 建立技术数据包

建立并维护技术数据包。

技术数据包为开发人员提供了产品或产品部件在开发过程中的全面的描述。在诸如基于性能的合同或者为出版而构建等很多情形下，这么一个包还提供了采购上的灵活性。

设计被记录在技术数据包中，该数据包在概要设计期间创建以便将体系结构定义文档化。在整个产品生存期间，技术数据包都得到维护，以记录产品设计的基本细节。技术数据包提供了产品或产品部件的描述（包括与产品相关的生存期过程，如果它们未被作为独立的产品部件处理的话），该描述支持某种采办策略，或者支持产品生存期中的实施、生产、工程、以及后勤支持阶段。该描述包括了对必要的设计配置与规程的定义，以确保产品或产品部件达到足够的性能。它包括所有适用的技术数据，包括图纸、相关列表、规格说明、设计描述、设计数据库、标准、性能需求、质量保证条款、以及包装细节。技术数据包包括了对所实施的选定解决方案的描述。

技术数据包应该包括适用于产品或产品部件类型（例如，对于与软件服务或过程相关的产品部件来说，材料与制造需求可能就不适用）的以下信息：

l 产品体系结构描述

l 分配需求

l 产品部件描述

l 与产品相关的生存期过程描述，如果没有作为独立的产品部件描述的话

l 关键的产品特性

l 需要的物理特性与约束

l 接口需求

l 材料需求（材料清单和材料特性）

l 制造与装配需求（既针对初始的设备制造者，也针对现场支持）

l 用于确保需求得以实现的验证准则

l 在整个产品生存期中运行、支持、培训、制造、退役清理、以及验证的使用条件（环境）和运行/使用场景、模式与状态

l 决策与特性（需求、需求分配以及设计抉择）的理由

由于设计描述可能涵盖非常大量的数据并且对成功的产品部件开发至关重要，建立组织数据和选择数据内容的准则是明智的做法。采用产品体系结构作为组织这些数据并从中抽象出于对所关心的问题或特性的清晰视图的方法就特别有用。这些视图包括：

l 客户

l 需求

l 环境

l 功能

l 逻辑

l 保密性

l 数据

l 状态/模式

l 构建

l 管理

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

典型工作产品

1. 技术数据包

子实践

1. 确定设计分层的数量以及每层设计的合适的级别。

确定要求文档化和需求可追踪性的产品部件的层数（例如子系统、硬件配置项、线路板、计算机软件配置项[CSC]、计算机软件产品部件、计算机软件单元）对管理文档成本和支持集成与验证计划来说是重要的。

2. 将详细设计描述建立在产品部件的分配需求、体系结构以及更高层的设计基础上。

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

4. 文档化作出或定义关键（换言之，对成本、进度或技术性能有重要影响）决策的理由。

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

SP2.3-1 建立接口描述

建立并维护产品部件接口的解决方案。

产品部件的接口描述覆盖了以下各项之间的接口：

l 产品部件与产品部件

l 较低层的产品部件与较高层的产品部件

l 产品部件和与产品相关的生存期过程

l 产品部件与外部事物

典型工作产品

1. 接口设计

2. 接口设计文档

子实践

1. 确定与其它产品部件的接口并将其文档化。

2. 确定与外部事物的接口。

3. 确定产品部件和与产品相关的生存期过程之间的接口。

举例来说，这类接口可能包括将要制作的产品部件与制造过程中使用的夹具等固定装置之间的接口。

4. 确保该解决方案包括了需求开发过程中开发出来的接口需求。

有关如何确定产品与产品部件的接口需求的更多信息请参见需求开发过程域中的“确定接口需求”特定实践。

SP2.3-3 使用准则设计接口

按照已经建立并维护的准则全面设计产品部件接口。

接口设计包括：

l 发源

l 终点

l 软件的激励和数据特性

l 硬件的电、机械、以及功能特性

接口准则常常反映了全面的关键参数列表，这些参数必须被定义，或者至少要受到研究，以确定其适用性。这些参数往往是给定的产品类型所特有的（例如软件、机械、电），而且常常与安全性、保密性、耐久性、以及任务关键特性相关。

典型工作产品

1. 接口设计规约

2. 接口控制文档

3. 接口规约准则

4. 选择接口设计的理由

子实践

1. 定义接口准则。

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

有关如何建立并维护组织级过程资产的更多信息请参见组织过程定义过程域

2. 将准则用于接口设计的候选项。

有关如何确定准则并根据这些准则选择候选项的更多信息请参见决策分析与解决方案过程域

3. 将选定的接口设计以及选择理由文档化。

SP2.4-3 执行制造、购买或重用分析

根据已建立的准则，评价产品部件应该开发、购买还是重用。

对将要采办哪些产品或产品部件的决定常常被称为“做或买分析”（“make-or-buy analysis”）它基于对项目需要的分析。这种做或买分析在项目初期第一次设计迭代期间开始，在设计过程中持续，做出开发、采办或重用产品的决策时完成。

有关如何确定产品或产品部件的需求的更多信息请参见需求开发过程域

有关需求的管理的更多信息请参见需求管理过程域

影响做或买决策的因素包括：

l 将要提供的产品或服务功能以及这些功能如何适合于项目

l 可用的项目资源与技能

l 采办与内部开发的成本

l 关键的交付与集成日期

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

l 对可用产品的市场研究，包括COTS 产品

l 可用产品的功能性与质量

l 潜在的供应商的技巧与能力

l 对核心竞争力的影响

l 与所购产品相关的许可证、授权、责任以及限制

l 产品的可用性

l 专利事项

l 风险的降低

这些因素中的多数需要由项目来处理。

做或买决策能够采用正式评价方法来进行。

有关如何定义准则与候选项并执行正式评价的更多信息请参见决策分析与解决方案过程域

随着技术的演进，选择开发或购买某个产品部件的理由也在演变。尽管复杂的开发工作可能支持购买一个套装产品部件，生产力和工具方面的优势可能提供一个反对的理由。套装产品可能不具备完整或精确的文档，并且可能得不到将来的支持。

一旦做出了购买套装产品部件的决策，需求就被用来建立一个供方协议。有些时候“套装”（“off the shelf”）是指市场上还不提供的一个现有的产品。例如，某些类型的飞机与发动机并不真正是“套装”的，但是可以容易地获得。有些情况下，使用这类未开发的产品是因为预期的性能细节与其它产品特性需要被控制在特定的范围内。在这些情况下，需求和验收准则可能需要包含在供方协议里并且受到管理。在其它情况下，套装产品是字面上的套装（例如字处理软件），而且不存在需要被管理的与供方的协议。

有关如何采办需要购买的产品部件的更多信息请参见供应协议管理过程域

典型工作产品

1. 设计与产品部件重用的准则

2. 做或买分析结果

3. 选择COTS 产品部件的指导

子实践

1. 开发重用产品部件设计的准则。

2. 对设计进行分析，以确定应该开发、重用还是购买产品部件。

3. 选择购买或者不开发（COTS、政府的套装件、以及重用）的产品时，计划它们的维护。

对于软件工程

考虑如何处理操作系统或数据库管理系统的未来版本的兼容性。

SG3 实现产品设计

产品部件及其相关的支持文档得到根据其设计的实现。

产品部件按照“开发设计方案”特定目标下的特定实践所建立的设计得以实现。实现通常包括产品部件在被提交产品集成之前的单元测试，以及最终用户文档的开发。

SP3.1-1 实现设计

实现产品部件的设计。

对于软件工程

软件代码是典型的软件产品部件。

设计一旦完成之后，就被实现为产品部件。该实现的特征取决于产品部件的类型。

产品层次结构顶层的设计实现包括在产品层次结构下一层的每个产品部件的规格说明。该活动包括分配、细化、以及验证每个产品部件。它还包括协调不同产品部件的开发工作。

有关需求的分配与细化的更多信息请参见需求开发过程域。

有关接口管理和产品与产品部件的集成的更多信息请参见产品集成过程域。

该实现的特征的实例包括：

l 软件编码完成

l 数据被文档化

l 服务被文档化

l 制作了电气与机械零件

l 产品所特有的制造过程已经就绪

l 过程被文档化

l 设备已经构建完成

l 原材料已经生产出来（例如，某种产品所特有的材料可能是一种石油、油料、润滑剂，或者一种新的合金）。

典型工作产品

1. 被实现的设计

子实践

1. 采用有效的方法来实现产品部件。

对于软件工程

软件编码方法的实例包括：

l 结构化编程

l 面向对象编程

l 自动代码生成

l 软件代码重用

l 采用适当的设计模式

对于系统工程

适当的制造方法的实例包括：

l 铸造

l 模铸

l 成型

l 连接

l 机加工

l 切削

l 焊接

l 挤压

2. 遵从适用的标准与准则。

对于软件工程

软件编码标准的实例包括：

l 语言标准

l 变量的命名约定

l 可接受的语法结构

l 软件产品部件的结构与层次

l 代码与注释的格式

对于软件工程

软件编码准则的实例包括：

l 模块化

l 清晰性

l 简洁性

l 结构化（例如：不用GOTO 、单入口与单出口）

l 可维护性

对于系统工程

标准的实例包括：

l 标准件清单

l 标准图纸要求

l 对制造件的国际标准化组织（ISO ）T3303 标准

对于系统工程

准则的实例包括：

l 可维护性

l 可靠性

l 安全性

3. 对选定的产品部件进行同行评审。

有关如何进行同行评审的更多信息请参见验证过程域。

4. 适当时，对产品部件执行单元测试。

注意单元测试并不只局限于软件。单元测试包括对单独的硬件或软件单元或者一组相关件在它们被集成之前的测试。

有关验证方法与规程，以及如何按照预定的需求验证工作产品的更多信息请参见验证过程域。

对于软件工程

单元测试方法的实例包括：

l 语句覆盖测试

l 分支覆盖测试

l 谓词覆盖测试

l 路径覆盖测试

l 边界值测试

l 特殊值测试

5. 必要时修改产品部件。

产品部件可能需要修改的一个实例情形是在实现期间发现了设计时无法预见的问题。

SP3.2-1 开发产品支持文档

开发并维护最终用户文档。

本特定实践开发并维护将被用于安装、运行、以及维护产品的文档。

典型工作产品

1. 最终用户培训材料

2. 用户手册

3. 操作手册

4. 维护手册

5. 联机帮助

子实践

1. 评审需求、设计、产品、以及测试结果，以确保影响安装、运行与维护文档的问题都已被发现和消除。

2. 采用有效的方法来开发安装、运行与维护文档。

3. 遵从适用的文档标准。

文档标准的实例包括：

l 与指定的文字处理器的兼容性

l 可用的字体

l 页、章节、以及段落的编号

l 与指定风格的手册的一致性

l 缩略语的使用

l 保密性分级记号

l 国际化需求

4. 在产品生存期的早期阶段开发安装、运行与维护文档的初始版本，供相关干系人评审。

5. 对安装、运行与维护文档进行同行评审。

有关如何进行同行评审的更多信息请参见验证过程域。

6. 必要时修订安装、运行与维护文档。

需要修订文档的实例情形包括以下事件的发生：

l 需求变更

l 设计变更

l 产品变更

l 发现了文档错误

l 发现了工作区调整

目标的一般实践

GG1 完成特定目标

通过将可识别的输入工作产品转变为可识别的输出工作产品，过程支持并且能够使过程域的特定目标实现。

GP1.1 履行基本实践

履行技术解决方案过程的基本实践从而发展工作产品和提供达到过程域的特殊目标的服务。

GG2 制度化一个已管理的过程

过程被作为一个已管理的过程制度化。

仅仅适用于连续式

GG3 制度化一个已定义的过程

过程被作为一个已定义的过程制度化。

编者按：这类目标的外观反映它在分级表示法中的位置。

仅仅适用于分级式

执行的保障

GP2.1 建立组织的方针

建立和维持一个用于计划和执行技术解决方案过程的组织性方针。

详尽的细节

这个方针建立了对处理选择产品部件解决方案、开发产品与产品部件的设计、以及实现产品部件设计的迭代式循环的组织性的期望。

执行的能力

GP2.2计划过程

建立和维持一个用于执行技术解决方案过程的计划。

详尽的细节

通常，执行技术解决方案过程的计划是项目计划过程域所描述的项目计划的一部分。。

GP2.3 提供资源

提供足够的资源用于执行技术解决方案过程，开发工作产品，以及提供过程的服务。

详尽的细节

为开发、设计、以及实现针对需求的解决方案，可能需要特殊的设施。

必要时，开发或者购买技术解决方案过程域中的活动所需要的设施。

提供的资源包括如下工具所示：

l 设计规约工具

l 模拟器与建模工具

l 原型工具

l 场景定义与管理工具

l 需求跟踪工具

l 交互式文档工具

GP2.4 分配职责

分配执行过程，开发工作产品以及提供技术解决方案过程服务的职责。

GP2.5 培训人员

必须培训执行和支持技术解决方案过程的人员。

详尽的细节

培训主题示例如下：

l 产品与产品部件的应用领域

l 设计方法

l 接口设计

l 单元测试技术

l 标准（例如产品、安全性、人素、环境）

引导（过程的）执行

GP2.6 管理配置

给技术解决方案过程中的指定工作产品以适宜的配置管理水平。

详尽的细节

在配置管理下存放的工作产品示例如下：

l 产品、产品部件、过程、服务、以及接口的设计

l 技术数据包

l 接口设计文档

l 设计与产品部件重用的准则

l 被实现的设计（例如软件代码、制作好的产品部件）

l 用户、安装、运行、以及维护文档

GP2.7 识别和包含相关的干系人

对照计划，识别和包含技术解决方案过程的相关干系人。

详尽的细节

从客户、最终用户、开发人员、生产人员、测试人员、供应商、市场人员、维护人员、最终清理人员和其它受到产品与过程的影响、或者影响产品与过程的人员中选择相关干系人。

干系人的活动示例如下：

l 开发候选解决方案与选择准则

l 逐步完成运行概念和场景

l 获得对外部接口规约与设计描述的批准

l 开发技术数据包

l 评估候选的产品部件制作、购买或重用方案

l 设计的实现

GP2.8 监督与控制过程

根据计划监督与控制技术解决方案过程，从而执行过程并进行适当的纠正活动。

详尽的细节

用于监督与控制的度量方法示例如下：

l 返工所花费的成本、进度与工作量

l 产品或产品部件的设计满足的需求的百分比

l 产品、产品部件、接口、以及文档的规模与复杂性

l 技术解决方案工作产品的缺陷密度

验证（过程的）执行

GP2.9 客观的评价坚持状况

对照过程的描述、规则、程序，客观评估技术解决方案过程的坚持状况，并处理未按此执行的相关事宜。

详尽的细节

评审活动示例如下：

l 选择产品部件的解决方案

l 开发产品与产品部件的设计

l 实现产品部件的设计

工作产物评审示例如下：

l 技术数据包

l 产品、产品部件、以及接口设计

l 已实现的设计（例如软件代码、制作好的产品部件）

l 用户、安装、运行、以及维护文档

GP2.10 用更高等级的管理评审状态

用更高层次的管理评审技术解决方案过程中的活动、状态、和结果，并解决问题。

GG3 制度化一个已定义的过程

过程被作为一个已定义的过程制度化。

执行的能力

GP3.1 建立一个已定义的过程

建立和维持一个已定义的需求开发过程的描述。

引导（过程的）执行

GP3.2收集改进信息

收集工作产品、度量方法、度量结果以及源于计划和执行技术解决方案过程的改进信息，从而支持将来的使用以及组织过程和过程域的改进。

连续式/成熟度3-5级

GG4 制度化一个集成的已管理的过程

过程是作为一个集成的已管理的过程被制度化的。

GP4.1 为过程建立集成目标

为技术解决方案过程建立和维持集成目标从而明确质量和过程执行是基于客户需求和商业目标的。

GP4.2 稳定子过程执行

稳定一个或多个子过程的执行从而确定技术解决方案过程的能力以达到建立的集成质量和过程执行目标。

GG5 制度化一个已优化的过程

过程是作为一个已优化的过程被制度化的。

GP5.1 确保连续的过程改进

在完成组织的相关商业目标过程中确保连续的技术解决方案过程改进。

GP5.2 纠正问题的根源原因

在技术解决方案过程中识别和纠正缺陷和其他问题的根源原因。

仅仅适用于连续式