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

技术解决方案

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

目的

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

介绍

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

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

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

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

 

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

 

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

 

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

 

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

相关过程域

有关需求分配、建立运行概念以及接口需求的定义的更多信息请参见需求开发过程域。

      

有关同行评审以及验证产品与产品部件是否满足需求的更多信息请参见验证过程域。

 

有关正式评价的更多信息请参见决策分析与制定过程域。

 

有关如何管理需求的更多信息请参见需求管理过程域。需求管理过程域中的特定实践与技术解决方案过程域中的特定实践交互执行。

 

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

 

实践－目标关系表

连续式	分级式
SG1选择产品部件的解决方案	SG1选择产品部件的解决方案
SP1.1-1开发候选方案和选择准则
SP1.1-2开发详细的候选方案和选择准则	SP1.1-2开发详细的候选方案和选择准则
SP1.2-2逐步完成运行概念和场景	SP1.2-2逐步完成运行概念和场景
SP1.3-1选择产品部件的解决方案	SP1.3-1选择产品部件的解决方案
SG2 开发设计方案	SG2 开发设计方案
SP2.1-1 设计产品或产品部件	SP2.1-1 设计产品或产品部件
SP2.2-3 建立技术数据包	SP2.2-3 建立技术数据包
SP2.3-1 建立接口描述
SP2.3-3 使用准则设计接口	SP2.3-3 使用准则设计接口
SP2.4-3 执行制造、购买或重用分析	SP2.4-3 执行制造、购买或重用分析
SG3 实现产品设计	SG3 实现产品设计
SP3.1-1 实现设计	SP3.1-1 实现设计
SP3.2-1 开发产品支持文档	SP3.2-1 开发产品支持文档
GG1 达到特定目标
GP1.1 完成基础实践
GG2 制度化一个已管理的过程	GG2 制度化一个已管理的过程
GP2.1建立组织的方针	GP2.1建立组织的方针
GP2.2 计划过程	GP2.2 计划过程
GP2.3 提供资源	GP2.3 提供资源
GP2.4 分配职责	GP2.4 分配职责
GP2.5 培训人员	GP2.5 培训人员
GP2.6 管理配置	GP2.6 管理配置
GP2.7 识别和包括相关的干系人	GP2.7 识别和包括相关的干系人
GP2.8 监督和控制这个过程	GP2.8 监督和控制这个过程
GP2.9 客观的评价坚持状况	GP2.9 客观的评价坚持状况
GP2.10 以更高等级的管理评审状态	GP2.10 以更高等级的管理评审状态
GG3 制度化已定义的过程
GP3.1 建立一个已定义的过程	GP3.1 建立一个已定义的过程	C/ML3-5
GP3.2 收集改进信息	GP3.2 收集改进信息
GG4 制度化一个已量化管理的过程
GP4.1 建立过程的量化目标
GP4.2 稳定子过程的执行
GG5 制度化一个优化中的过程
GP5.1 保证连续的过程改进
GP5.2 改正问题的根源

实现目标的关键实践

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

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

 

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

 

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

 

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

 

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

 

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

 

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

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

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

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

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

 

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

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

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

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