CMMI-技术解决方案（TS）

技术解决方案Technical Solution TS的目的在于选择、设计并实现对需求的解决方案。解决方案、设计与实现包括单独的或以适当形式组合的产品、产品组件以及与产品相关的生命周期过程。

一、概述

“技术解决方案”过程域适用于产品架构的任一层级和每一个产品、产品组件以及与产品相关的生命周期过程。在本过程域内用到术语“产品”与“产品组件”的地方其预期的含义也包含服务、服务系统及其组件。

本过程域所关注的有

• 评价并选择解决方案有时亦指“设计方法”、 “设计概念”或“初步设计”这些解决方案可能满足所分配的功能性需求与质量属性需求的适当集合

• 开发所选解决方案的详细设计所谓详细指的是包含所有制造、编码或其它将设计实现为产品或产品组件的必要信息

• 将设计实现为产品或产品组件

典型情况下这些活动相互作用、相互支持。有些层级的设计有时可能需要相当详细以用于选择解决方案。原型或试点可以作为一种手段以获得充分的知识来开发技术资料包或完整的需求集合。可使用质量属性模型、模拟、原型或试点来获得有关潜在设计解决方案方面的额外信息以帮助解决方案的选择。对于开发多系统构成的系统systems-of-systems的项目模拟可能尤其有效。“技术解决方案”的特定实践不但适用于产品与产品组件而且适用于与产品相关的生命周期过程。与产品相关的生命周期过程的开发配合产品或产品组件进行。这类开发活动可以包括选择并修改供使用的现有过程包括标准过程与开发新的过程。与“技术解决方案”过程域相关联的过程从需求管理过程得到产品或产品组件需求。需求管理过程将来源于需求开发过程的需求置于适当的配置管理之下并维护其到前期需求的可追溯性。对于维护类或支持类项目在维护行为或重设计活动中所需要的需求可能由用户的需要、技术的成熟与陈旧、或者产品组件中的遗留缺陷驱动。操作环境中的变化可能引发新的需求。这样的需求可能在产品的验证期间被发现此时其实际的性能可以与其规定的性能相比较并可能识别出不可接受的性能下降。应当将与“技术解决方案”过程域相关联的过程用于执行维护类或支持类的设计工作。对于产品线这些实践既适用于核心资产的开发即为复用进行构建也适用于产品的开发即使用复用进行构建。核心资产的开发还需要进行产品线可变管理产品线可变机制的选择与实现以及产品线生产计划过程的制订与其它工作产品的开发以定义如何构建产品以充分利用用核心资产

在敏捷环境中关注点是及早进行解决方案的探索。通过更明确地进行选择并进行决策的权衡“技术解决方案”过程域有助于提高决策的质量无论其是单独的还是长期的。解决方案可以用功能、特性集、发布或其它任何有助于产品开发的成分进行定义。当团队之外的人员未来会从事产品方面的工作时所安装的产品中通常包括了发布信息、维护日志与其他数据。为了支持产品未来的更新要记录下权衡、接口与所购买的部件的依据以便更好地理解为什么会有该产品。如果所选的解决方案风险很低就大大降低了将决策进行正式记录的需要。见第一部分中的“使用敏捷方法时对 CMMI 的解读” 。

二、特定目标与特定实践摘要

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 开发产品支持文档

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

产品或产品组件解决方案得以从备选解决方案中选出。

在选择解决方案之前备选解决方案与其相对长处得到了考虑。关键需求、设计问题与约束得到了建立用于备选解决方案的分析。支持达成质量属性需求的架构选择与模式得到了考虑。 同样地 商用现货 commercialoff-the-shelf COTS 产品组件的使用在比较了成本、进度、性能与风险的情况下得到了考虑。 COTS 的备选方案既可在修改后也可不加修改地予以使用。有时这些 COTS 项需要在诸如接口或某些特性的定制方面加以修改以纠正与功能性需求或质量属性需求之间的不匹配或与架构设计的不匹配。好的设计过程的一个标志是设计是在对备选解决方案进行比较并评价之后选择得到。架构决策、定制开发或是使用现货的决策、以及产品组件模块化的决策是所应对的有代表性的设计选择。某些这样的决策可能要求使用正式的评价过程。

参阅“决策分析与解决”过程域以进一步了解如何使用正式的评价过程遵循已建立的准则对已识别的多个备选方案进行评价以分析可能的决策。有时候解决方案的搜索仅检查相同需求的备选实例而无需对低一级产品组件进行分配。这种情况出现在产品架构的底部。也有些情况一个或多个解决方案是已固定的例如已指定了具体的解决方案或已调查了如 COTS 等已具备的产品组件的使用。一般情况下解决方案定义为一个集合。也就是说当定义下一层次的产品组件时同时建立集合中的每一个产品组件的解决方案。备选解决方案不仅是解决相同需求的不同方式而且也体现了构成解决方案集合的产品组件之间不同的需求分配。目标是将集合的整体进行优化而不是单个组件。与“需求开发”过程域的关联过程会有大量的相互作用以支持至产品组件的暂定的分配方案直到选定解决方案集合并且建立最终分配。从备选解决方案选择产品组件解决方案中包含有与产品相关的生命周期过程。这些与产品相关的生命周期过程的实例有制造、交付与支持过程

SP 1.1 开发备选解决方案与选择准则

开发备选解决方案与选择准则。

参阅“需求开发”过程域中的“分配产品组件需求”特定实践以进一步了解如何取得至产品组件备选解决方案的需求的分配。参阅“决策分析与解决”过程域以进一步了解如何建立评价准则。应当进行备选解决方案的识别与分析以能够选出在整个产品生命期中成本、进度、性能与风险等方面取得平衡的解决方案。这些解决方案基于所提议的产品架构这样一些产品架构解决了关键的产品质量属性需求并且遍及可行解决方案的设计空间。与“开发设计”特定目标相关联的特定实践提供进一步的信息说明如何开发潜在的产品架构并结合到产品的备选解决方案之中。备选解决方案经常包含至不同产品组件的备选需求分配方案。这些备选解决方案可以包括在产品架构中使用 COTS 解决方案。之后再使用与“需求开发”过程域相关联的过程来提供更完整且更健壮的、至备选解决方案的暂定需求分配方案。备选解决方案遍及成本、进度与性能的可接受范围。产品组件需求被接收并与设计事项、约束和准则一起用于开发备选解决方案。进行选择的准则通常应对了成本例如时间、人员、金钱、收益例如产品性能、能力、有效性以及风险例如技术、成本、进度。

在备选解决方案方面的考虑点与选择准则有

• 开发、制造、采购、维护与支持的成本

• 关键质量属性需求的达成诸如产品及时性、安全性、可靠性与可维护性

• 产品组件的复杂度以及与产品相关的生命周期过程

• 产品操作与使用条件的健壮程度、操作模式、环境、以及与产品相关的生命周期过程的变动情况

• 产品扩展与增长

• 技术限制

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

• 风险

• 需求与技术的演化

• 废弃

• 最终用户与操作人员的能力与局限

• COTS 产品的特性

列在这里的考虑点是是一个基本集合组织应当制订与其业务目标相一致的过滤准则以缩小备选解决方案清单的范围。尽管产品生命周期成本是一项值得尽可能缩减的参数但该参数可能并不在开发组织的控制范围内。客户可能不愿意为短期内导致成本更高但在产品生命期内最终会降低成本的特性付费。在这种情况下至少应当告知客户降低生命周期成本的潜在可能。用于选择最终解决方案的准则应当是平衡了成本、收益与风险的方法。

工作产品实例

1. 备选解决方案的过滤准则

2. 新技术的评价报告

3. 备选解决方案

4. 最终选择结果的选择准则

5. COTS 产品的评价报告

子实践

1. 识别过滤准则以选择可供考虑的备选解决方案集合。

2. 识别当前所使用的技术与获得竞争优势的新产品技术

项目应当识别适用于当前产品及过程的技术并且监督当前所用技术在项目生命期内的发展。项目应当识别、选择、评价并投资于新技术以取得竞争优势。备选解决方案可以包含新技术但也可包含将成熟的技术进行不同的应用或者维持当前的方法。

3. 识别满足需求的候选 COTS 产品

COTS 产品的供方所需要满足的需求有

• 产品功能与质量属性

• 产品质保的条款与条件

• 有助于在产品的持续维护与支持方面减轻供方责任的期望例如评审活动方面的、约束或检查点

4. 识别可复用解决方案组件或适用的架构模式。

对于产品线组织的核心资产可作为解决方案的基础

5. 形成备选解决方案。

6. 获得各备选方案的完整的需求分配方案。

7. 制订用于选择最佳备选解决方案的准则。

应当包含解决产品生命期中设计问题的准则如更方便地导入新技术、或更有能力地利用商用产品的条款。实例包括与所评价的备选方案的开放式设计或开放式架构概念相关的准则。

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

基于选择准则选择产品组件解决方案。

参阅“需求开发”过程域中的“分配产品组件需求”与“识别接口需求”特定实践以进一步了解如何建立产品组件的已分配的需求与产品组件之间的接口需求。选择最佳满足准则的产品组件就建立了对产品组件的需求分配方案。选定的备选方案又形成了低一级的需求并被用于开发产品组件设计。产品组件之间的接口被描述。在至产品外部的产品接口与活动接口的文档中应包含物理接口的描述。要将解决方案的描述与选择的依据进行文档化。开发过程中解决方案与详细设计被开发出来并实现了这些设计贯穿在这样的开发过程中 解决方案文档也要不断演进。维护选择依据的记录对于下游的决策意义重大。这类记录防止了下游干系人的重复劳动并随着技术在所适用场合中的具备而能够提供对应用该技术的洞察力。

工作产品实例

1. 选择产品组件的决策与依据

2. 需求与产品组件之间文档化了的关系

3. 文档化的解决方案、评价与依据

子实践

1. 对照以操作概念与场景为背景而建立的选择准则评价各备选解决方案或解决方案的集合。为各备选解决方案开发产品操作与用户交互的时间轴场景。

2. 依据备选方案的评价评估选择准则的充分性并在必要时更新准则。

3. 识别并解决备选解决方案与需求方面的问题。

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

5. 建立与选定的备选方案集合相关联的功能性需求与质量属性需求作为至那些产品组件的已分配需求的集合。

6. 识别将复用或采购的产品组件解决方案。

参阅“供方协议管理”过程域以进一步了解如何管理从供方采购产品和服务的活动。

7. 建立并维护解决方案、评价与依据的文档。

SG 2 开发设计

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

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

SP 2.1 设计产品或产品组件

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

产品设计大致由两个执行时可重叠的阶段组成初步设计与详细设计。初步设计建立产品能力与产品架构包括架构风格与模式、产品分块、产品组件标识、系统状态与模式、主要的组件间接口以及产品外部接口。详细设计则完全地定义了产品组件的结构与能力。参阅“需求开发”过程域中的“建立必需的功能与质量属性的定义”特定实践以进一步了解如何开发架构需求。架构定义由在需求开发过程期间所开发的架构需求集合所驱动。这些需求识别了对产品的成功有重要作用的质量属性。随着产品设计细节的建立架构定义了结构上的元素与协调机制这些元素与机制要么直接满足需求要么支持需求的达成。架构可以包含支配产品组件与其接口开发的标准与设计规则以及辅助产品开发人员的指南。“选择产品组件解决方案”特定目标中的特定实践包含如何使用产品架构作为备选解决方案基础的进一步说明。架构师提出设想并开发产品的模型做出判断将功能性需求与质量属性需求分配给包括硬件与软件的产品组件。可以开发并分析支持备选解决方案的多个架构以确定在架构需求方面的优势与劣势