技术解决方案（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 设计产品或产品组件
开发产品或产品组件的设计。
产品设计大致由两个执行时可重叠的阶段组成：初步设计与详细设计。初步设计建立产品能力与产品架构，包括架构风格与模式、产品分块、产品组件标识、系统状态与模式、主要的组件间接口，以及产品外部接口。详细设计则完全地定义了产品组件的结构与能力。参阅“需求开发”过程域中的“建立必需的功能与质量属性的定义”特定实践以进一步了解如何开发架构需求。架构定义由在需求开发过程期间所开发的架构需求集合所驱动。这些需求识别了对产品的成功有重要作用的质量属性。随着产品设计细节的建立，架构定义了结构上的元素与协调机制，这些元素与机制要么直接满足需求，要么支持需求的达成。架构可以包含支配产品组件与其接口开发的标准与设计规则，以及辅助产品开发人员的指南。“选择产品组件解决方案”特定目标中的特定实践包含如何使用产品架构作为备选解决方案基础的进一步说明。架构师提出设想并开发产品的模型，做出判断，将功能性需求与质量属性需求分配给包括硬件与软件的产品组件。可以开发并分析支持备选解决方案的多个架构以确定在架构需求方面的优势与劣势
操作概念以及操作的、支持的与开发的场景被用于形成用例以及与质量属性相关的场景，用于对架构进行细化。在产品设计中定期执行的架构评价过程中，它们也作为手段用以评价架构对其预期目的的适合程度。参阅“需求开发”过程域中的“建立操作概念与场景”特定实践以进一步了解如何开发操作概念与场景用于架构评价。架构定义任务的实例有：
• 建立分块的结构关系，以及有关分块内的元素之间接口的规则，以及有关分块之间接口的规则
• 选择支持功能性需求与质量属性需求的架构模式，并将那些模式实例化，或组成那些模式，以建立产品架构
• 识别主要的内部接口与所有的外部接口
• 识别产品组件，以及产品组件之间的接口
• 使用架构描述语言，正式定义组件行为与交互作用
• 定义协调机制（例如：对软件的、硬件的）
• 建立基础能力与服务
• 开发产品组件模板，或者类与框架
• 建立设计规则与进行决策的职权
• 定义过程／ 线程模型
• 定义将软件向硬件的物理分配
• 识别主要的复用途径与来源
在详细设计期间，产品架构细节被最终确定，产品组件被完整定义，并且接口的特征被完全描述。可以针对特定质量属性优化产品组件设计。设计者可以对遗留产品或 COTS 产品用作产品组件的决策进行评价。随着设计的成熟，要追踪分配给低一级产品组件的需求，以确保可以满足那些需求。参阅“需求管理”过程域以进一步了解如何确保项目工作与需求之间的协调一致。对于软件工程，详细设计关注于软件产品组件的开发。通过定义产品组件的内部结构，形成数据模式，开发算法，建立探试法等，以为产品组件提供满足已分配需求的能力。对于硬件工程，详细设计关注于电子的、机械的、电光的以及其它硬件产品及其组件的产品开发。 电气原理图与连接图被开发，机械与光学装配模型被生成，生产与装配工艺被制订。工作产品实例
1. 产品架构
2. 产品组件的设计
子实践
1. 建立并维护准则，据此可以对设计进行评价
除了期望的产品性能，可用于建立设计准则的质量属性实例有：
• 模块化
• 清晰
• 简洁
• 可维护
• 可验证
• 便携
• 可靠
• 准确
• 安全
• 可扩充
• 易用
2. 识别、开发或采购适用于产品的设计方法。
有效的设计方法可以包含活动、工具及描述性技术等广阔范围。某种方法是否有效依赖于具体情况。两家公司可能各自拥有其所专长的有效的产品设计方法，但这些方法可能在合营企业并不有效。高度成熟的方法在那些未得到方法使用方面的培训的设计者手里，也未必一定有效。方法是否有效也依赖于其给设计者提供了多大的帮助，以及该帮助的成本有效性。例如，多年的原型投入可能不适用于简单的产品组件，但对于前所未有的、昂贵的且复杂的产品开发则也许是正确的事情。然而，快速原型技术可以非常有效地用于许多产品组件。有些方法使用工具来确保设计将包含实现产品组件设计所必需的所有必要属性，这些方法也可以是有效的。例如，“了解”制造工艺能力的设计工具可以在设计容限中容许制造工艺的偏差。可促进有效设计的技术与方法的实例有：
• 原型法
• 结构模型
• 面向对象的设计
• 实质的系统分析
• 实体关系模型
• 设计的复用
• 设计模式
3. 确保设计遵循所适用的设计标准与准则
设计标准的实例有（这些标准的一部分或全部可以是设计准则，特别是在标准尚未建立的场合）：
• 操作员接口标准
• 测试场景
• 安全标准
• 设计约束（例如：电磁兼容、信号集成、环境）
• 生产约束
• 设计容限
• 部件标准（例如：生产废料、浪费）
4. 确保设计遵循已分配的需求。
应当考虑已识别的 COTS 产品组件。例如，若要将已有的产品组件放到产品架构中，也许就修改了需求与需求分配方案。
5. 将设计文档化。
SP 2.2 建立技术数据包
建立并维护技术数据包。
技术数据包为开发者提供所开发产品或产品组件的全面描述。这样的数据包也为诸如绩效保证式合约（performance based contracting）或设计蓝本式制造（build-to-print）等各种情况提供了采购方面的灵活性。（见术语表中“技术数据包”的定义。）在创建初步设计、进行架构定义的文档化的过程中，设计被记录在技术数据包中。在产品的整个生命期中，要维护该技术数据包，记录下产品设计的重要细节。技术数据包提供了产品或产品组件（包括未作为单独的产品组件处理的与产品相关的生命周期过程）的描述，支持了采购策略、或产品生命周期的实现、生产、工程与物流支持阶段。这样的描述包括必需的设计配置与规程的定义，以确保产品或产品组件性能方面的充分性。它包括所有适用的技术数据，诸如绘图、相关联的清单、规格说明、设计描述、设计数据库、标准、质量属性需求、质量保证条款与打包细节。技术数据包中含有挑选进行实现的所选定备选解决方案的描述。由于设计描述可能包含大量数据，且又对成功的产品组件开发起关键作用，所以建立组织数据与选择数据内容的准则是可取的。 特别有效的是以产品架构为手段，来组织这些数据，并抽象出清晰的且与某问题点或所关心的特性相关的视图。 这些视图有：
• 客户
• 需求
• 环境
• 功能
• 逻辑
• 安全
• 数据
• 状态／ 模式
• 建造
• 管理
这些视图文档化在技术数据包中。
工作产品实例
1. 技术数据包
子实践
1. 确定设计层次的数量，以及每一设计层次适当的文档水平。
确定需要进行文档化、并要求需求可追溯的产品组件层次的数量（例如：子系统、硬件配置项、电路板、计算机软件配置项［computer softwareconfiguration item， CSCI］ 、计算机软件产品组件、计算机软件单元等）对于管理文档的成本并支持集成计划与验证计划来说是重要的。
2. 确定用于进行架构文档化的视图。
视图被选择用以记录产品的内在结构并应对特定干系人的关注点。
3. 将设计的详细描述建立在已分配的产品组件需求、架构与上一级设计的基础之上。
4. 将设计文档化在技术数据包中。
5. 文档化所做出的或所定义的关键（即：对成本、进度或技术性能产生显著影响的）决策，并包括其依据。
6. 必要时修订技术数据包。
SP 2.3 使用准则设计接口
使用所建立的准则设计产品组件的接口。
接口的设计有：
• 起源
• 目标
• 软件的刺激源（stimulus）与数据特征，包括次序方面的约束或协议
• 处理特定刺激源所耗费的资源
• 对错误的或超出规定限度之外的刺激源的例外处理或出错处理行为
• 硬件的电气的、机械的与功能的特征
• 通信的服务线路
接口的准则通常体现了应当得到定义、或至少得到调查的关键参数，以确保其适用性。这些参数通常是给定的产品类型（例如：软件、机械、 电气、服务）所特有的，并通常与安全性、安保性、耐久性以及任务关键性特性相关联。
参阅“需求开发”过程域中的“识别接口需求”特定实践以进一步了解如何识别产品与产品组件的接口需求。
工作产品实例
1. 接口设计规格说明
2. 接口控制文档
3. 接口规格说明准则
4. 所选接口设计的依据
子实践
1. 定义接口准则
这些准则可以是组织级过程资产的一部分。
参阅“组织级过程定义”过程域以进一步了解如何建立并维护一套可用的组织级过程资产与工作环境标准。
2. 识别与其它产品组件相关联的接口。
3. 识别与外部项相关联的接口。
4. 识别产品组件和与产品相关的生命周期过程之间的接口。
举例来说，这类接口可能包括那些在待制作产品组件与制造过程中用于使制作成为可能的钻模与固定装置之间的接口。
5. 将准则用于接口设计备选方案。
遵循已建立的准则，对已识别的多个备选方案进行评价，以分析可能的决策。
6. 将选定的接口设计与选择的依据文档化。
SP 2.4 执行自制、购买或复用分析
依据所建立的准则，评价产品组件是应当自行开发、还是购买或者复用。
通常将确定采购哪些产品或产品组件的过程称之为“自制或购买分析”。这基于对项目需要的分析。自制或购买分析开始于项目早期的第一次设计迭代期间；在设计过程中继续进行；完成于对产品的开发、采购或复用的决策。
参阅“需求开发”过程域以进一步了解如何挖掘、分析并建立客户需求、产品需求与产品组件需求。
参阅“需求管理”过程域以进一步了解如何管理需求。
影响自制或购买决策的因素有：
• 产品将提供的功能，以及如何将这些功能融入到项目中
• 可用的项目资源与技能
• 采购成本与内部开发成本的对比
• 关键的交付与集成日期
• 战略上的业务联盟，包括高层次的业务需求
• 已具备产品的市场研究，包括 COTS 产品
• 已具备产品的功能与质量
• 潜在供方的技能与能力
• 对核心竞争力的影响
• 与待采购产品相关联的许可、质保、责任与限制
• 产品的具备程度
• 专有事项
• 风险的降低
• 在需要与产品线核心资产之间的匹配度
可以采用正式评价方法来进行自制或购买决策
技术在演化，产品组件的开发或购买的选择依据也会随之演化。尽管复杂的开发工作可能更支持采购现货产品组件，但在生产率及工具方面的进步可能会给出相反的依据。现货产品的文档可能不完整或不准确，并且将来是否能够得到支持也是未知数。一旦做出采购现货产品组件的决策，如何实施该决策则依赖于待采购项的类型。有时候“现货”所指的既有产品并不能拿来就用，因为必须先进行定制以满足采购方规定的特殊的性能需求与所采购的其它产品特性（例如飞机发动机）。为了管理这类采购，需建立包含这些需求与应满足的验收准则的供方协议。在其它情况下，现货产品是真正的现货（例如字处理软件），不存在需要管理的与供方的协议。
参阅“供方协议管理”过程域中的“建立供方协议”特定目标以进一步了
解如何处理供方协议，以修改 COTS 产品。
工作产品实例
1. 设计与产品组件复用的准则
2. 自制或购买分析
3. 选择 COTS 产品组件的指南子实践
1. 制订复用产品组件设计的准则。
2. 分析设计，以确定产品组件应该开发、复用还是采购。
3. 对已购买项或非开发项（例如： COTS、政府现货、复用）进行考虑时，分析维护的含义。
维护的含义实例有：
• 与未来所发布的 COTS 产品的兼容性
• 供方变更的配置管理
• 非开发项与其解决方案中的缺陷
• 计划外的淘汰
SG 3 实现产品设计
产品组件与相关支持文档，按照设计得以实现。
产品组件的实现按照“开发设计”特定目标中的特定实践所建立的设计进行。实现通常包括在送交产品集成之前对产品组件所进行的单元测试，以及最终用户文档的开发。
SP 3.1 实现设计
实现产品组件的设计。
完成设计后，即将其实现成为产品组件。实现的特性依赖于产品组件的类型。在产品层次结构顶层的设计实现，涉及对产品层次结构下一个层次的各产品组件进行规格说明。这一活动包括各产品组件的分配、细化与验证。它还涉及产品组件的各种开发工作之间的协调
这样的实现，其特征的实例有：
• 软件得到编码。
• 数据得到文档化。
• 服务得到文档化。
• 电气的与机械的部件得到制作。
• 独特的产品生产工艺得到投入使用。
• 工艺得到文档化。
• 设施得到建造。
• 材料得到生产（例如：独特的产品材料可以是石油、机油、润滑剂、新型合金等）。
工作产品实例
1. 已实现的设计
子实践
1. 使用有效的方法进行产品组件的实现。
软件编码方法的实例有：
• 结构化编程
• 面向对象编程
• 面向方面的编程
• 自动化代码生成
• 软件代码复用
• 使用合适的设计模式
硬件实现方法的实例有：
• 门电路水平的合成
• 电路板版图设计（位置与布线）
• 计算机辅助设计绘图
• 版图设计后的模拟
• 制造方法
2. 遵循适用的标准与准则
实现标准的实例有：
• 语言标准（例如：软件编程语言标准、硬件描述语言标准）
• 绘图需求
• 标准件清单
• 生产件
• 软件产品组件的结构与层次
• 工艺与质量标准
准则的实例有：
• 模块化
• 清晰性
• 简洁性
• 可靠性
• 安全性
• 可维护性
3. 对选定的产品组件执行同级评审。
参阅“验证”过程域以进一步了解如何执行同级评审。
4. 适当地执行产品组件的单元测试。
注意，单元测试不局限于软件。单元测试涉及在集成之前的单个硬件或软件单元的测试，或一组相关项的测试。
参阅“验证”过程域以进一步了解如何验证选定的工作产品。
单元测试方法（手工的或自动的）的实例有：
• 语句覆盖测试
• 分支覆盖测试
• 断言覆盖测试
• 路径覆盖测试
• 边界值测试
• 特殊值测试
单元测试方法的实例有：
• 功能测试
• 辐射检查测试
• 环境测试
5. 必要时，修正产品组件。
产品组件何时可能需要修正，一个实例是在实现时发现了在设计期间不能预见的问题
SP 3.2 开发产品支持文档
开发并维护最终使用文档。
本特定实践开发并维护将用于产品的安装、操作与维护的文档。
工作产品实例
1. 最终用户培训资料
2. 用户手册
3. 操作手册
4. 维护手册
5. 在线帮助
子实践
1. 对需求、设计、产品与测试结果进行评审，以确保影响安装、操作与维护文档的问题得到识别与解决。
2. 使用有效的方法以开发安装、操作与维护文档。
3. 遵循所适用的文档标准。
文档标准的实例有：
• 与指定的文字处理器兼容
• 可接受的字体
• 章、节、页编号规则
• 与指定的风格手册一致
• 缩写的使用
• 机密分类标识
• 国际化需求
4. 在项目生命周期的早期阶段，进行安装、操作与维护文档初步版本的开发，以供相关干系人评审。
5. 进行安装、操作与维护文档的同级评审。
参阅“验证”过程域以进一步了解如何执行同级评审。
6. 必要时，修订安装、操作与维护文档。
文档何时可能需要修订，其实例包括下列所发生的事件：
• 已进行需求的变更
• 已进行设计的变更
• 已进行产品的变更
• 已识别文档的错误
• 已识别修正的变通方案
Doker 做好产品，做暖心服务的3C品牌！！！
文章下方有交流学习区！一起学习进步！也可以前往官网，加入官方微信交流群！！！
你的支持和鼓励是我创作的动力❗❗❗
官网：Doker 多克;
