软件过程能力评估模型
GP 2.7确定相关的共利益者并使之介入
按计划确定。需求管理一过程的相关的共利益者并使之介入．
详细说明：
对于工程化类过程来说，要考虑在顾客、最终用户、开发人员、生产人员、测试人员、供应支持人员、营销人员、维护人员、处置人员以及可能受产品和过程影响或者可能影响产品和过程的其他人员中间的共利益者。
|
需要共利益者介入的活动的例子有： ●解决对需求的共识问题 ●评估需求变更的影响； ●通报双向源性情况 ●识别项目工作与需求之间的不一致
|
GP 2.8监督和控制该过程
对照计划监督和控制“需求管理”过程，并且采取适当的纠正措施。
详细说明：
|
在监督和控制“需求管理”过程方面的各项活动中使用的度量项目的例子有： ●需求变化性（需求变更的百分数）。 |
GP 2.9客观地评价遵循情况
对照适用的要求、目标和标准，客观地评价“需求管理一过程以及该过程的工作产品和服务的遵循情况，并且处理不符合项。
详细说明：
|
|
被审查的活动的例子有： ●管理需求 ●识别项目计划笔工作产品与需求之间的不一致 | |
|
被审查的工作产品的例子有： ●需求 ●需求源性度量项目
|
| |
GP 2.10高层管理者审查状态
高层管理者审查“需求管理“过程的活动、状态和结果，并解决问题。
GG 3制度化为已定义过程
把该过程作为已定义过程加以制度化．
GP 3.1建立已定义过程
建立并维护一个已定义的“需求管理“过程的描述．
GP 3.2收集改进信息
收集那些派生于_需求管理一过程的策划和执行的工作产品、度量项目和改进信息，用以支持本组织的过程和过程财富的进一步使用和改进．
GG 4制度化为定量管理过程
把该过程作为定量管理的过程加以制度化
GP 4.1 建立质量目标
根据赢客需求和组织业务目标，为“需求管理”过程的质量和过程性能建立定量目标并予以维护．
GP 4.2使子过程性能稳定
使“需求管理“过程的一个或几个子过程的性能稳定下来，进而确定该过程在实现所规定的定量目标和过程性能目标方面的能力．
GG 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化。
GP 5.1 确保不断的过程改进
确保“需求管理”过程不断得以改进，以适应本维织的有关的总体业务目标
GP 5.2解决问题的共性原因
识别并解决。“需求管理”过程中的缺陷和其他问题的原因．
6.4.2需求开发“需求开发“的目的是产生和分析顾客需求、产品需求和产品构件需求。
“需求开发”过程方面包含3组基本惯例。第1组惯例是定义完备的顾客需求所要求的惯倒：
这个需求集合用于开发产品需求。第2组惯例是定义完备的产品和产品构件需求所要求的惯例：
这个需求集合用于产品和产品构件设计．第3组惯例是在定义、派生和理解这些需求时用于执行
必要的分析的惯例。这3组惯例可能彼此间发生一些递归互动作用，它们与在搿技术解决一过程中开发的优选产品概念和候选解决方案的定义也存在递归互动关系．
所开发的需求将成为设计的基础。这项工作包括：
●收集和协调共利益者的需要；
●开发产品生存周期需求；
●建立顾客需求；
●建立与顾客需求一致的产品和产品构件初步需求；
●提取、分析和通报顾客需要、期望和限制条件，以获得顾客需求，从而在共利益者之间就所要满足的内容达成共识。
这个过程方面涉及所有顾客需求，而不仅仅是产品一级的需求，因为顾客也可能提出特殊的设计需求。
要把顾客需求进一步精练成产品和产品构件需求．除了顾客需求外，还可能从所选择的解决方案中派生出产品和产品构件需求。
在整个产品生存周期里，需求可能发生演变。要针对所派生的和分配的需求对设计决策、后续的纠正措施以及从生产、集成、验证、确认、产品运行、支持以及处置等得到的反馈进行分析。
通过分析来理解、定义和选择所有各个层次的需求。分析工作包括：
●需求分析：
●操作概念的开发：
●所要求的功能度的定义：
●为处理成本和可供给性而开发相应的制造和支持概念。
功能度定义（也称为功能分析）不同于软件开发中的结构化分析，不是假定面向功能的软件设计。功能度定义是在面向对象的软件设计中有关定义服务的活动。功能的定义和逻辑分组以及与需求的关系等，合在一起称为功能体系结构。
对产品体系结构的细节层次可能需要不断进行递归分析，直到细化程度足以推进产品的详细设计、采办和测试．作为对需求、操作概念（包括功能度、支持、维护和处置）以及制造或生产概念的分析的结果，将产生更多的派生的需求，包括以下需要予以注意的事项：
●各种限制条件：
●技术制约：
●成本和成本驱动因素：
●时间限制和进度驱动因素；
●风险：
●顾客或最终用户未明确指出的（隐含的）问题：
●由开发者的专有的业务考虑、法律和法规引出的因素。
通过操作概念的反复演变，建立分层次的逻辑实体（功能和子功能、对象类别和子类别）。对需求加以精练，进行派生，然后分配到这些逻辑实体上。这些需求和逻辑实体进一步被分配给产品、产品构件、人、相关的过程或服务。持续进行这项活动，可以确保需求始终得到恰当定义。
邀请所有相关的共利益者介入需求开发和分析，可以使他们直观了解需求的演变情况。
有关的过程方面
关于管理顾客要求和产品需求，求得需求提供者的一致，实现这些需求的人的承及维护溯源性的更多的信息参见“需求管理“的过程方面．
关于如何使用“需求开发糟过程的输出，以及关在精练和派生需求中使用的替代解决方案和设计的开发的更多的信息，参见“技术解决”过程方面。
关于界面需求和界面管理的更多的信息，参见“产品集成”过程方面。
关于验证产品是否满足需求的更多的信息，参见“验证”过程方面．
关予所构造的产品如何对照顾客的需求进行确认的更多的信息，参见“确认”过程方面。
关于识别和管理器求有关的风险的更多的信息，参见风险管理糟过程方面。
关予确保关键工作产品受到控管理的更多的信息，参见”风险管理”过程方面。
特定目标
SG 1开发顾客需求
收集共利益者的需要、期望、限制条件和界面，并且把它们转换成顾客需求．
SG 2开发产品需求
对顾客需求加以精练和细化，针对产品生存周期开发出产品和产品构件需求．
SG 3分析和确认需求
对需求进行分析和确认，开发出所要求的功能度的定义。
通用目标
GG1实现特定目标
该过程通过把可识别的输入工作产品转换成可识别的输出工作产品，以支持实现该过程方面的特定目标并且使之能售实现．
GG 2制度化为受管理过程
把该过程作为受管理过程加以制度化．
GG 3制度化为已定义过程
把该过程作为已定义过程加以制度化．
GG4制度化为定量管理过程
把该过程作为定量管理过程加以制度化．
GQ 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化-
与目标对应的特定惯例
Sa 1开发顾客需求
收集共利益奢的需要、期望、限制条件和接口，并且把它们转换成顾客需求．
共利益者（例如顾客、最终用户、供方、制造者以及测试人员）的需要是确定顾客需求的基础。对共利益者的需要、期望、限制条件、接口、操作概念和产品概念等进行分析、协调、精练和细化，以便把它们转换成顾客需求．
但是，共利益者的需要，期望、限制条件和接口等往往不是报明确，甚至还存在矛盾。因此，必须清楚地识别共利益者的需要、期望、限制条件和限度，并且理解它们。为此，需要在整个项目生存周期中反复运用这个过程。在非协商的情况下，往往是本组织的顾客关系部门或营销部门甚至是开发组的成员充当顾客代理或最终用户代理。在建立顾客需求时，环境、法规和可能来自顾客以外的其他限制条件也适用。
SP l.1-1 收集共利益者的需要
针对产品生存周期的所有各个阶段识别并收集共利益者的需要、期望、限制条件和接口．
这项基本活动涉及到对顾客提供的用以规定需要什么或期望什么的需求接收问题。这些需求可能用技术条款予以说明，也可能不用技术条款说明：无论以哪种形式提出，都应该涉及生存周期活动和它们对产品的影响。
子惯例
● 处理对顾客提供的用于规定需要什么或期望什么的需求接收问题。
SP l.1-2导出需要
针对产品的生存周期的所有阶段导出共利益者的需要、期望、限制条件和接口．
导出需要的活动不属于收集需求活动的范围，这是主动识别那些没有由顾客明确提供的需求。这些需求应该涉及各个生存周期活动和它们对产品的影响。
|
用于导出需要的技术的例子有： ●技术证明 ●接口控制工作组 ●技术控制工作组 ●临时项目审查； ●调查问卷、面谈和从最终用户处于的操作场景 ●原形和模型 ●智慧风暴法 ●质量功能开发 ●市场调查研究 ●测试（设放市场之前的测试） ●从信息源（例如文档、标准或规格说明）中提取； ●观察现行产品、环境和工作流程图； ●使用案例 ●业务安全分析 ●向工程化（什对传统产品）
|
子惯例
1． 用适当的方法（例如对话、场景审查、模型、模拟、原型或新的技术验证）与共利益者一起导出需要、期望、限制条件和外部接口。
2． 消除共利益者的需要、期望、限制条件和接口中的矛盾之处，并且根据分析结果把这些需要等纳入有关的主题中。
SP l.2-1转换成顾客需求
把共利益者的需要、期望、限制条件和接口转换成顾客需求。
对于顾客提供的各种输入、所得到的被顾客遗漏的信息以及所解决的矛盾，有必要加以定形，进一步生成顾客需求。顾客需求中可能包含与验证和确认有关的需要、期望和限制条件．
典型工作产品
1． 顾客需求。
2． 用于验证过程的需求。
3． 用于确认过程的需求。
4． 测试用例和期望的结果。
子惯例
1． 把共利益者的需要、期望、限制条件和接口转换成文件化的顾客需求。
2． 确定用于验证过程和确认过程的方法、判据和限制条件。
SG 2开发产品需求
对顾客需求加以精练和细化，针对产品生存周期开发产品和产品构件需求．
结合操作概念的开发对顾客需求进行分析，以派生出更加详细和精确的称之为“产品和产品构件需求“的需求集合。派生的需求可能产生于限制条件、顾客需求基线中隐含的问题、以及从所选择的体系结构、设计和开发者专有业务考虑导出的因素。要结合每个后续的低层次需求集合和功能体系结构对需求再次进行检查，并且对优选的产品概念进一步加以精练。
把需求分配给产品功能和产品构件（包括对象、人员和过程）。要抓住对功能、对象、测试或其他实体的需求可溯源性。分配的需求和功能是技术解决的基础。随着内部构件的开发，将补充定义更多的接口接口和规定更多的接口接口需求。
SP 2.1-1 确定产品和产品构件需求
为保证产品和产品构件的有效性和可提供性，根据顾客需求确定产品和产品构件需求。
顾客需求可以用顾客的词语表达，并且可以不是技术描述。产品需求则采用能够用于设计决策的技术词语表述。在初次进行内部质量功能展开时就需要把顾客需求转换成产品需求，即，把顾客的希望映射到技术参数上。
设计限制条件包括对产品构件的规格说明：这些规格说明派生于设计决策，而不是更高层次的需求。例如必须与现货数据库构件接口的应用类产品构件就必须与所选择的数据库隐含的接口需求相符合：这类产品构件需求一般不可能追溯到较高层需求。
派生的需求还应涉及生存周期其他阶段（例如生产、运行和处置）的成本和性能并且应与业务目标适当匹配。
典型工作产品
1． 派生的需求。
2． 产品需求。
3． 产品构件需求。
4． 内控质量要求。
子惯例
1． 针对产品和产品构件，用必要的技术词语拟订需求。
2． 根据设计决策派生需求。
应该注意，在选择技术途径时可能产生附加的需求．．
关于拟订解决方案（它们可能产生附加派生需求）的更多的信息，参见“技术解决”过程方面。
● 针对在需求变更管理和需求分配中的事宜确定并维护需求之间的关系．
需求之间的关系有助于评价需求变更的影响。
关子维护需求可溯源性的更多的信息，参见搿器求管理一过程方面。
SP 2.2-1 分配产品构件需求 为每个产品构件分配需求．
关于绘产晶和产品构件分配需求的更多的信息l参见“技术解决“过程方面。这个确定惯例为确定需求的分配提供信息，但是必须与“技术解决“中的惯例配合，才能拟订出按之分配需求的解决方案。
所定解决方案的产品构件的需求包括产品性能、设计限制条件、以及适应性、形式和功能，以便满足需求和便于制作。如果高层需求规定的性能将由两个或两个以上的产品构件来承担，那么，必须把这个性能分割开，作为派生的需求分别唯一地分配给每个产品构件。
典型工作产品
1． 需求分配表。
2． 临时需求分配。
3． 设计限制条件．
4． 派生的需求。
5． 派生的需求之间的关系。
6． 规格说明。
子惯例
1． 给功能分配需求．
2． 给产品构件分配需求。
3． 给产品构件分配设计限制条件。
4． 把所分配的需求之间的关系形成文件。
这种关系包括依存性，例如一个需求的某次变更可能影响到其他需求。
SP 2.3-1 确定接口需求
规定功能之间或对象之间的接口，
功能接口可能驱动“技术解决”过程方面中的候选解决方案的开发．
关于接口的管理以及产品和产品构件的集成的更多豹信息，参见“产品集成”过程方面。
要在体系结构和设计中规定产品或产品构件之间的接口要求。这些接口要求作为产品和产品构件集成的组成部分加以控制。
生存周期过程接口也必须加以规定。
生存周期过程界面的例子包括与测试设备、支持系统以及制造设施的界面。
典型工作产品
1． 接口需求。
子惯例
1. 确定产品内部的接口需求和外部的接口需求《即功能接口需求或对象接口需求》。
2．从出发点、目的地、激励因素以及数据特性等方面全面规定接口需求．
对手内部接口而言，这一点可以作为设计过程的一个部分来实施．
关于在设计过程中生成接口需求的更多的信息t参见囊技术解决抻过程方面．
随着体系结构的确定和接口的建立，一些新的接口又可能产生．此外，随着接口设计的确定，这个接口设计将成为对那些受该接口影响的产品和产品构件的一项需求。
SG3分析和确认需求
对各项需求进行分析和确认并且开发所曩求的功能度的定义．
分析需求，以确定那些影响到将来的操作环境的需求是否足以满足共利益者的需要、期望、限制条件和接口．必须对诸如可行性、任务需要、成本限制、潜在的市场规模以及采办策略之类结合产品背景予以考虑，还要建立所需功能度的定义．产品的所有规定的使用模式都要予以考虑，并且，为了给各个与项目推进时间关系密切的功能安捧顺序，要对时间段落安捧进行分析。分析的目的在于针对那些将满足共利益者需要、期望和限制条件的产品概念确定候选需求；然后把这些产品概念转换成需求，与此同时，要根据顾客输入和初步的产品概念确定那些将用于评价该产品有效性的参数．
确认需求是为了使所要创建的产品将更有把握在使用环境中运行．
SP 3.1-1建立操作概念和操作场景
建立并维护操作概念和操作场景
关于那些与所选择的设计密切相关的运行的细节开发参见“技术解决”过程方西．
所谓场景，是指一系列可能在该产品使用时发生的事件，用于明确给出共利益者的某些需要．而产品的操作概念通常则是取决于设计方案和这个场景．一般不会在拟订初步操作概念时规定各种候选解决方案，所以要开发概念性解决方案，以便分析需求时使用．随着解决方案决策的敲定和低层次详细需求的开发，要对操作概念加以精练．产品的设计解决方案可能成为产品构件的需求，而产品操作概念可能成为该产品构件的场景（需求）。
场景可以包含操作顺序，前提是，这些顺序是用于表达顾客需求而不是表达操作概念．
典型工作产品
I．操作概念．
2．产品安装、操作、维护和支持概念．
3．处置概念．
4．用例．
5．按时间顾序的场景．
6．新的需求．
子惯例
1． 开发操作概念和场景，包括功能度、性能、支持和（适当时）处置．
识别和开发场景时要考虑与共利益者的需要、期望和限制条件的详细程度一致，并且场景反映的环境应该是该产品将可能在其中运行的环境。
2． 定义产品将来的运行环境（包括边界和限制条件）．
3． 审查操作概念和场景，以便精练和进一步发现需求．
操作概念和场景的开发是一种递归过程．应该定期进行审查，以确保这些概念和场景与需求保持一致．审查工作可以采用走查的形式．
● 随着产品和产品构件的选定（以便规定产品、最终用户和环境之间的交互作用），开发出能满足操作、维护、支持和处置需要的详细的操作概念．
GP 3.2-1 建立所需功奠度的定义
建立并维护所需功奠度的定义．
功能度的定义，也称为功能分析，是描述产品要做些什么，功能废的定义可能包括行为、顺序、输入、输出或其他_些与产品使用方式有关的信息。
功能分析不同于软件开发中的结构化分析，不假定面向功能的软件设计，在面向对象的软件设计中，功能分析与定义服务有关．功能的定义、功能的逻辑分组以及与需求的关系等统称为功能体系结构．
典型工作产品
1． 功能体系结构．
2． 活动图表和用例．
3. 带有所确定的服务的面向对象的分析结果．
子惯例
1． 对最终用户所要求的功能度进行分析并加以认定．
2. 分析需求，以识别逻辑部分或功能部分（例如子功能）需求．
3． 根据所建立的准则（例如类似的功能度、性能或关联性）把逻辑和功能需求分组，以便于分别集中进行需求分析．
4. 在产品构件开发之初和开发中，考虑那些与时间安排关系密切的功能的顺序安排。
5． 把顾客需求按功能、对象、人员或支持元素分配，以支持解决方案的合成．
6． 把功能需求和性能需求分配给功能和子功能．
GP 3.3-1分析要求
分析派生的要求，以便确保它们墨必蔓的和充分的，
结合操作概念和场景对派生的需求进行分析，以支持更加详细和精确的产品或产品构件需求（集合）的开发．这个分析工作将保证所派生的需求，对于满足更高层次需求来说，是必须的和充分的，随着这些派生的需求的确定，必须了解它们与更高层次需求的关系和所确定的更高层次的功能度．其他关键行动之一是确定在跟踪技术进展时所要参照的需求。例如，产品的规模可能要结合风险问题在全程开发中予以监视．
典型工作产品
1． 需求缺陷报告．
2. 为解决缺陷问题而提出的需求更改建议．
3． 关键需求．
4．技术性能度量项目，
予惯例
1． 分析共利益者的需要、期望、限制条件和外部接口，以便消除矛盾和安排到有关的主题中．
2． 分析派生的需求，以确定它们是否满足更高层次需求的目标．
3． 分析需求，以确保它们的完整、可行、合理和可验证性．
设计工作确定的是某个具体解决方案是否可行．这个子惯例涉及到了解有哪些需求将影响可行性．
4． 识别那些对成本、进度、功能度、风险或性能有强烈影响的关键需求。
5． 确定技术性能度量项目，在开发工作期间要对它们进行跟踪。
关于度量一般用途的更多的信息，参见“测量和分析”过程方面．
6．分析操作概念和场景，以精练顾客的需要、期望、限制条件和接口并且发现新的需求．
这种分析可能产生更详细的操作概念和场景以及支持发现新的派生的需求。
SP 3.4-3评价产品成本、进度和风险 从群低生存周期成本、加快产品开发进度和减少产品开发风险角度出发，分析要求．
使用经过确认的模型、模拟和原型开发方法对于与顾客需求有关的成本和风险进行分析，分析结果可以用于降低产品成本和减少产品开发中的风险。
典型工作产品
l. 与需求有关的风险的评估结果，
子惯例
1. 对需求和功能体系结构进行风险评估．
关于对颈客篱求和产品焉求以及功能体系结构进行风险评估的更多f信息，参见“风险管理”过程方法。
● 针对需求对风险的影响，检查生存周期概念。
GP 3.5-1确认需求
确认需求，以确保将产生的产品在谈产品将能在便期的使用环境中正常运行．
需求确认是在开发工作的早期执行，以便确信这些需求能引导开发工作获得最终成功确认。这项活动应该与风险管理活动结合进行。
典型工作产品
1． 需求确认的结果．
子惯例
● 分析需求，以确定是否存在使将要产生的产品不能在预期的使用环境中恰当运行的风险。
GP 3.5-2用综合性的方法确认需求
确认需求，以确保将要产生的产品能在用户环境中恰当运行．
这项活动应该与风险管理活动结合进行．成熟的组织一般是在广泛考虑其他共利益者的需求和期望的基础上并且以经过仔细推敲的方式进行需求确认，这类组织一般会进行分析、模拟或原型设计，以确保需求满足共利益者的需求和期望。
典型工作产品
1． 分析方法和结果的记录。
子惯例
1． 分析需求，以确定是否存在着使得将要制作的产品不能在预期的使用环境中恰当运行的风险。
2．通过向顾客和最终用户显示原型、模拟情况、分析结果、场景和情节串连图，与顾客和最终用户探讨需求的充分性和完备性。
3． 随着设计趋于成熟，在需求确认的背景下评估设计，以识别确认问题和探讨未指出的顾客需求和期望目标对应的通用惯例
GG 1实现特定目标
该过程通过把可识别的输入工作产品转换成可识别的输出工作产品支持实现此过程方面的特定目标并且使之能够实现．
GP l.1确定工作范围
针对“需求开发”过程，确定所要执行的工作的范围和所要生产的工作产品的范围，并且把这些信息传达给将要执行该工作的人．
GP l.2执行基本惯例
执行Ⅳ需求开发一这个过程方面的基本惯例，以开发工作产品和提供服务，以便实现该过程方面的特定目标。
GG 2制度化为受管理过程
把该过程作为受管理过程加以制度化．
GP 2.1建立组织方针
为策划和执行“需求开发“过程，制订并维护组织方针．
详细说明：
这个方针要确定组织的如下期望：收集共利益者需要，形成产品和产品构件需求，
以及分析和确认这些需求。
GP 2,2制订该过程的计划
为执行需求开发过程，建立并维护需求、目标和计划。
详细说明：
这些需求、目标和计划一般是按“项目策划’’过程方面所述在项目计划中描述。
GP 2.3提供资源
为了执行所策划的过程、开发工作产品和提供“需求开发”过程的服务，提供足够的资源．
详细说明：
可能需要应用领域方面的专家，需要用于导出共利益者需要的方法以及用于说明和分析顾客需求、产品和产品构件需求的方法。
|
用于执行“需求开发”过程方面的活动的工具的例子有： ●需求规范化工具 ●仿真和建模工具； ●原形设计工具 ●场景定义和管理工具 ●需求跟踪工具
|
GP 2.4 分配责任
为执行该过程、开发工作产品和提供”需求开发”过程的服务，分配责任和权限．
GP 2.5培训人员
必要时，对执行或支持“需求开发斗过程的人员进行培训，
详细说明
|
培训专题的例子有： ●应用领域 ●需求定义和分析 ●需求导出 ●需求规范化和建模 ●需求跟踪
|
GP 2.6管理配置项
把“需求开发”过程的指定的工作产品置于配置管理的适当层次．
详细说明：
|
置于配置管理之下的工作产品的例子有； ●顾客需求 ●功能体系结构； ●产品和产品构件需求 ●接口需求
|
GP 2.7确定相关的共利益者并使之介入。
按计划确定“需求开发”过程的相关的共利益者并使之介入．
详细说明：
对于工程化类过程来说，要考虑在顾客、最终用户、开发人员、生产人员、测试人员、供应支持人员、营销人员、维护人员、处置人员以及可能受产品和过程影响或者可能影响产品和过程的其他人员中间的共利益者。
|
需要共利益者介入的活动的例子有； ●审查需求在满足需要、期望限制条件和界面的充分性； ●建立操作概念和场景； ●评估需求的充分性 ●确定产品的立品构件需求 ●评估产品成本、进度和风险。
|
GP 2.8监督和控制该过程
对照计划监督和控制“需求开发”过程，并且采取适当的纠正措施。
详细说明：
|
在监督和控制“需求开发”过程方面的各项活动中使用的度量项目的例子有： ●因返工而超支的成本、拖延的速度和增加的工作量； ●需求规范的缺陷密度。 |
GP 2,9客观地评价遵循情况
对照适用的需求、目标和标准，客观地评价“需求开发”过程以及该过程的工作产品和服务的遵循情况，并且处理不符合项。详细说明；
|
被审查的活动的例子有： ●收集共利益者需要； ●形成产品和产品构件需求； ●分析和确认产品和产品构件需求。 |
|
被审查的工作产品的例子有： ●产品需求； ●产品构件需求 ●接口需求 ●功能体系结构 |
GP 2.10高层管理者审查状态
高层管理审查“需求开发”过程的活动、状态和结果，并解决问题．
GG 3制度化为已定义过程
把该过程作为已定义过程加以制度化。
GP 3.1建立已定义过程
建立并维护一个已定义的“需求开发”过程的描述．
GP 3.2收集改进信息
收集那些派生千“需求开发"过程的策划和执行的工作产品、度量项目和改进信息，用以 支持本组织的过程和过程财富的进一步使用和改进．
GG 4制度化为定量管理过程
把该过程作为定量管理的过程加以制度化．
GP 4.1建立质量目标
根据顾客需求和组织业务目标，为“需求开发”过程的质量和过程性能建立定量目标并予以维护．
GP 4.2使子过程性能稳定
使“需求开发”过程的一个或几个子过程的性能稳定下来，进而确定该过程在实现所规定的定量目标和过程性能目标方面的能力．
GG 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化．
GP 5.1 确保不断的过程改进
确保“需求开发”过程不断得以改进，以适应本组织的有关的总体业务目标．
GP 5.2解决问置的共性原因
识别并解决并“需求开发”过程中的缺陷和其他问题的根本原因．
6.4.3技术解决
“技术解决”的目的在于针对需求开发、设计和实现解决方案，解决方案、设计和实现等都围绕产品、产品构件和与过程有关的产品（可能是其中之一或它们的组合）．“技术解决”过程方面适用于体系结构的任何层次，适用于产品、产品构件、生存周期过程以及服务．这个过程方面侧重子：
● 评价和选择那些可能满足所分配的适当需求的解决方案（有时称为设计途径、设计概念或初步设计）。
● 针对所选择的解决方案做详细设计（详细程度以包含全部为编码或其他实现产品或产品构件设计所需的信息为准）。
● 实现产品或产品构件的设计。
实际上，这些活动是彼此支持的，在时间安排比较细致的情况下，可能需要在某个设计层次上选择解决方案。可以运用产品构件的原型设计作为充分掌握情况的手段，这些情况将用于开发完备的技术数据包或完备的需求集合．
“技术解决”过程方面中的各个惯例不仅适用于产品和产品构件，而且适用于服务和与产品相关的过程．产品相关过程要结合产品或产品构件的开发而开发．这类开发可能包括选择和和采纳现行过程（包括标准过程）以供使用，以及开发新的过程．
源于“需求开发”过程或其他来源的产品需求，在它们被置于适当的配置管理下和经过相对于以前的需求的溯源性处理之后，将从“需求管理蚪过程输出。
对于支撑性组织来说，可能由于用户需要或在产品构件中发现的缺陷而产生新的维护需求或重新设计需求．新的需求也可能由于生存周期的变更或运行环境的变化（例如操作系统变更）而产生。产品在运行环境中进行持续使用验证期间可能发现这类情况．这些验证工作揭示将交付的实际性能并且识别（与规定的性能比较）不可接受的降档次情况。应该把“技术解决”过程运用子执行这类支撑性设计工作。
有关的过程方面。
关于需求分配、操作概念建立和接口需求定义的更多的信息，参见“需求开发现”过程方面．
技术解决方案要与需求的确定交互开发，并且，技术解决方案既随着需求而发展又使需求随着技术解决方案的成熟而进一步得到精练。
关于同行审查以及对产品和产品构件是否满足需求进行验证的更多的信息，参见“验证”过程方面随着验证问题的发现，可能需要对设计加以修改。
关于结构化决策的更多的信息，参见曩决策分析和决定”过程方面．趴一组设诗贺繁电选择解决方案，是一种应该运用结构化“决策分析和决定”过程方面的工作。
关于管理需求的更多的信息，参见科“需求管理”过程方面，应该结合“技术解决”过程的实施执行口需求管理捧中的各个惯例。
关于组织的技术过程的更多的信息，参见“组织革新和部署”过程方面。
特定目标
SG 1 选择产品构件解决方案
从各种懈决方寨中选择产品或产品构件（包括适用的产品相关过程）解决方案．
S0 2设计
做产品或产品构件设计．
SG 3实现产品设计
根据设计，实现产品构件和编制有关的支持文档．
通用目标
GQ 1实现特定目标
该过程通过把可识别的输入工作产品转换成可识别的输出工作产品-以支持实现该过程方面的特定目标并且使之能謦实现．
GG 2制度化为受蕾理过程
把该过程作为受管理过程加以翩度化-
GG 3制度化为已定义过程
把该过程作为已定义过程加以制度化．
GG 4制度化为定量管理过程
把该过程作为定量管理过程加以制度化．
GG 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化．
与目标对应的特定惯例
SG 1 选择产品解决方案
从候选解决方案中选择产品或产品构件（包括产品相关的过程）解决方案．
在选择某个解决方案时，要考虑候选解决方案及其优点。应该确定关键需求、设计问题和限制条件，以便在分析各种候选方案时使用。要考虑体系结构部件，它们是产品发展和改进的基础。对于是否选用商业现货产品构件，要结合成本、进度、性能和风险来考虑，在使用商业现货产品构件时，可以不加修改直接使用；也可能是修改后使用，例如为了更好地满足产品需求，可能需要对接口加以修改或者需要定制某些部分。
作为良好设计过程的一种表现是，在比较候选解决方案并且经过评价之后才选定设计方案。对体系结构、定制与采用现货、以及构件模块化等的决策是典型的设计选择活动。有时，对解决方案的探究是针对同一个需求（它们不需要分配到低层构件）检查各种候选解决方案．这正是产品体系结构底层的情况。有的情况下，是固定一个或几个解决方案（例如，指定某个特定解决方案，或者要求调查是否有现成可用的产品构件，如商业现货）一般情况下，是规定一组解决方案。也就是说，在确定下一层产品构件时，以集合的形式一起拟订出每个产品构件的解决方案。与候选解决方案相比较，这种成组的解决方案不仅在处理同样的需求时所用的方法不同，而且在产品构件之间分配需求的方式也不同。成组的解决方案的目标是作为整体使方案集合得以优化，而不是一个一个地处理。为了支持给产品构件临时分配需求，需要与“需求开发”过程密切交互作用，直到选择出解决方案集合和完成“最终”的需求分配。
SP l.1-1 拟订候选解决方案和选择准则
拟订出各种候选解决方案和选择准则．
关于在拟订候选方案时给产品构件悔时分配需求的更多的信息参见“需求开发时过程方面中的“分配产品构件需求”特定惯铡。
从候选解决方案不适用时有关予拟订解决方案的惯例，参见“决策分析和决定”过程方面。
关于管理临时分配的需求,f确定分配的需求的更多的信息，参见“需求管理一过程方面．
候选解决方案往往覆盖的是一个探究可行、可用的解决方案的设计空间t随着选择决定的一一作出，设计空间可能被压缩，对余下的候选解决方案进行检查，直到遴选出满足需求和选择准则的最佳（即优化）解决方案为止。选择准则应该具备实质意义上的区别点，能指示出达到某个平衡的生存周期解决方案的成功（或妥善）之点．一般，这些准则包括成本、进度、性能和风险等的度量项目．接受评价的候选解决方案往往包含为不同产品构件分配需求的各种替代方式．这些候选方案也可能涉及到对是否在产品体系结构中采用商业现货进行评价．然后要使用“需求研泼”过程方面中的惯例，为候选解决方案提供一种比较完整的有说服力的l临时需求分配方式．选择出“最好”的解决方案，也就以所分配的需求集合的形式确定了给该方案临时分配的需求．在新的开发中，很少有“不适用”检查候选解决方案的情况，不过，对有先例的产品构件的开发就不检查候选解决方案，或者仅进行少量检查．
典型工作产品
1．候选解决方案．
2.选择准则。
子惯例
1. 建立并维护用于识别侯选解决方案、选择准则和设计问题的过程。
选择准则受多种因素的影响：这些因素则受那些影响开发活动和产品生存周期的需求驱动。例如，与缓解成本风险和进度风险有关的准则可能影响到优先选择这样的商业现货解决方案：不至于造成在对其余产品构件的开发中出现不可接受的风险。在使用现行产品（例如商业现货）时；可以加以修改，也可以不加修改，应该检查那些处理逐渐萎缩的供应源或逐渐衰退的技术的准则，检查那些体现标准化的优点、维护与供方的关系等等的准则。在选择解决方案中用的准则应该提供一条在成本、效益和风险方面求得平衡的途径。
2. 确定候选的各组需求：这些需求反映那些覆盖可行的设计空间的候选解决方案的特征。
如何有效使用候选的商业现货是一种挑战。熟悉候选商业现货的知识渊博的设计者有可能揭示出那些将发挥潜在的商业现货效益回报的体系结构-
3． 识别每个候选解决方案的设计问题．
4． 确定设计问题的特征并采取适当措施。
这些措施的范围从针对表现为风险的设计问题进行风险管理，调整候选解决方案，到排除问题，拒绝现有候选解决方案并使用别的解决方案来替代。
5． 为每个候选解决方案寻求完整的需求分配方式．
6． 为每组候选解决方案作出合理解释。
SP l.1-2拟订详细候选解决方案和选择准则
拟订详细候选解决方案和选择准则．
关于建立用于结构化决策的准则的更多的信息，参见“决策分析和决定”过程方面．
详细候选解决方案是“技术解决”过程方面的基本概念，与那些非详细的候选方案比较，详细候选解决方案提供有关解决方案的更加准确的综合性信息．例如，在详细候选方案中，对性能特性的表述是以设计内容为基础，而不是简单的估计，因而可以有效评估和了解环境和操作概念的影响。有必要识别莉分析候选解决方案，以便能从生存周期中成本、进度和技术性能平衡的角度出发选择解决方案．候选解决方案覆盖成本、进度和性能的全部可接受范围。接收和使用产品构件需求的同时要考虑相应的设计问题、限制条件和候选解决方案开发准则。选择解决方案的准则一般涉及成本（例如，时间、人员、金钱）、效益（例如，性能、能力、效率）和风险（例如，可执行性、技术、成本、进度等方面的风险）。详细候选解决方案和选择准则可能包含以下内容：
● 成本（包括开发、采购、支持、生存周期等方面的成本）；
● 技术性能；
● 产品构件的复杂程度和有关的生存周期过程；
● 对产品运行和使用条件、运行方式、环境和有关的生存周期过程中变化的适应性：
● 产品扩展和升级；
● 技术限制：
● 对构造方法的敏感性：
● 风险：
● 需求和技术的进化；
● 处置。
上面所列各项内容是一个基本集合；组织应该为初步选择候选方案拟订出与业务目标一致的准则。至于尽量降低生存周期成本的考虑，可能已经超出了开发组的控制范围。对于那些在近期开销比较大，但是从整个生存周期看成本比较低的产品，顾客可能不愿意接受。在这种情况下，至少应该告诉顾客总的生存周期成本将可能降低。选择准则应该提供一种在成本、效益和风险等方面求得平衡的途径。
典型工作产品
1．候选解决方案。
2．选择准则。
3．候选解决方案初选核查表。
4．新技术评价结果。
予惯例
1．为选择可供考虑的一组候选解决方案确定初选准则。
2．确定当前使用的技术和从竞争考虑的新产品技术。
项目应该确定用于当前产品和过程的技术，并且监视当前在产品生存周期中使用的技术的进展。为了提高竞争能力，项目应该识别、选择和评价新技术并且为之投资。候选解决方案可能包含一些新开发的技术，不过也可能在不同的应用中采用成熟的技术或者维持当前的方法。
关于组织鹃技术过程的更多的信息，参见“组织革新和部署”过程方嚣。
3．生成候选解决方案。
4．为每个候选方案分配完备的需求。
5．确定选择最好的候选解决方案的准则。
这种准则应该包含对生存周期设计问题的处理，例如如何比较容易引入新技术或者如何更好地拓展使刚商业产品。与开放式没计或开放体系结构概念有关的准则也是用于评价候选方案的准则的例子。
6．为每个候选解决方案拟订产品运行和用户交互作用的时间／活动场景。
SP l.2-2发晨操作概念和场景
使概念、场景和环境不断进化，以便描述每个产品构件的运行条件、操作模式和运行状态．
关于产品构件运行对产品层的影响的信息，参见“需求开发”过程方面中“建立操作概念和场景”特定惯例。
操作概念和场景把产品构件与环境、用户和其他产品构件之间的“激励一响应”日寸序互动行为形成文件。操作概念和场景的文件化应考虑运行、产品部署／交付、支持（包括维护和支撑）、培训以及处置，并且要考虑所有模式和状态。
典型工作产品
1．针对所有可能的生存周期过程（运行、支持、培训、制造、验证、部署／交付／安装／处
置）的产品构件操作概念、场景和环境。
2．产品构件交互作用的时间一活动分析结果。
3．事件跟踪图。
4．用例。
SP l.3-1 选择产品构件解决方案
选择出最满足规定准则的产品构件解决方案．+
关于确定分配给产品构件的需求和产品构件2间的接口需求的信息参见“需求开发” 过程方面中的“分配产品构件需求”和“识别技求”特定惯例。
关于结构化决策的更多的信息，参见“决策分析决定”过程方面。
一旦选定最能满足规定准则的产品构件解决方案，也就确定了对产品构件的需求分配。所选择的候选解决方案用于开发技术数据包，并且会随着低层次需求的进化而进化。
产品构件与产品构件的接口需求主要从功能上描述。
要在初始的技术数据包中描述所选的解决方案和选择理由。技术数据包将随着解决方案和详细设计的开发以及设计的实现而进化。要保留选择理由，它们对于下游决策而言很重要。这些记录支持下游共利益者介入工作，并且使人们明白当某技术可用时将在适当环境中应用。
典型工作产品
1． 产品构件解决方案选择决定和理由。
2． 关于需求与产品构件之间的形成文件的关系。
3． 初始产品构件技术数据包。
子惯例
1． 对照选择准则评价每个／每组候选解决方案。
2． 根据对候选方案的评价情况，评估选择准则的充分性并且在必要时更新这些准则。
3． 识别并解决有关候选方案和需求的问题。
4． 选择能满足选择准则的“最好”的一些候选解决方案。
5． 确定与所选择的候选方案相关联的需求，它们将是分配给产品构件的需求。
6． 建立并维护这些解决方案、评价结果和选择理由的文件。
SG 2设计
设计产品或产品构件．
产品或产品构件设计必须提供适当的生存周期信息，不仅要用于实现产品或产品构件，而且要用于产品或产品构件的修改、采购、维护、支撑和安装。设计文档是支持相关的共利益者理解该设计的参考点，并且它支持在开发期间和在产品生存周期下游对该设计的更改。在技术数据包中给出完整的文件化的设计描述，其中包括全部特征和参数（形式、功能、接口和其他参数）．所建立的本组织或本项目的设计标准（例如核查表、模板）将为实现设计文档的高度定义化和完备化奠定基础。
SP 2.1-1运用有效的设计方法
建立并运用有效的设计方法．
|
适合于有效软件设计的技术和方法的例子有： ●原形设计 ●结构化模型 ●面向对象的设计 ●基本系统分析 ●褓关系模型 ●设计复用 ●设计模板
|
有效的设计方法可能涉及广泛的活动、工具和描述技术。一个方法是否有效，与具体情况密切相关。例如，两个公司可能在各自专长的产品方面拥有非常有效的设计方法，但是在他们的合作尝试中，这些方法却可能无效。即使精益求精的方法，到了未经训练的人手中，这些方法也未必有效。
方法是否有效还涉及到它对设计者有何帮助以及这种帮助的费／效比。例如，花费时间比较长的原型设计法，可能不适合于软件模块，但是却适用于高投入豹复杂产品的开发．而快速原型设计法则可能对这个复杂产品的产品构件很有效。利用工具确保设计工作包容所有为实现产品构件设计所必需的属性，也许是非常有效的方法。例如，“知道”制造过程的能力的设计工具就可能使制造过程中的变量控制在设计容差范围内。
典型工作产品
1． 设计方法有效性判断准则。
2． 设计方法。
3． 设计方法选择准则。
4． 设计工具。
5． 设计过程／活动。
子惯例
1． 建立并维护可以用于确定设计方法的有效性的准则。
2． 搜寻、开发或采购满足准则要求的设计方法．
3．确保设计方法遵循适用的设计标准和准则。
|
设计标准的例子如下（这些“标准”中一部分或全部可能成为设计准则，特别是在该标准沿未制订的情况下）： ●安全标准； ●操作员界面标准； ●生产限制 ●设计容差 | |
|
可以用于拟订设计准则的属性的例子有： ●模块化程度； ●明确性 ●简单性 ●可维护性； ●可验证性 ●可移植性 ●可靠性 ●准确性 ●安全性 ●性能 ●可伸缩性 ●可用性
|
|
4． 确定设计方法及其对产品构件设计的适用性。
|
例如，可以采用一种用于确定究竟是原型法还是其他技术适合于该设计过程的各个部分的机制。 |
5． 在各部分设计中运用已经建立的有效的设计方法。
SP 2.2-1 开发技术数据包
开发产品或产品构件的技术数据包．
技术数据包提供对产品或产品构件（在产品相关过程不作为独立的产品构件处理时，也包括这类过程）的描述，用于支持采办策略或产品生存周期中的设计实现、生产、工程 化和后勤支持。这种描述包括所要求的设计配置和确保产品或产品构件性能充分性的规程：包括所有适用的技术数据，例如框图、规格说明、标准、性能要求、质量保证措施和打包细节等。技术数据包包含选择实施的解决方案的描述。
典型工作产品
1． 技术数据包。
SP 2.2-3建立完备的技术数据包
建立并维护完备的技术数据包．
完备的技术数据包为开发者提供的是关于开发产品或产品构件的综合性描述。它还为在多种环境下进行采购提供一定的灵活性，例如，性能承包或从设计到做出成品。完备的技术数据包还提供有关产品类型和产品构件类型的以下信息：
● 对产品构件所要求的生存周期功能度和性能描述；
● 产品相关过程（不独立处理时）的描述；
● 关键产品特性；
●，所要求的限制条件；
● 接口需求：
● 用于确保实现需求的验证准则：
● 贯穿整个生存周期的使用条件和运行场景、运行模式和状态、支持、培训、生产和验证：
● 决策理由和特征（需求、需求分配、设计选择）。
因为设计描述可能涉及大量数据并且设计描述对于产品构件的成功开发至关重要，所以最好针对数据的组织和数据内容的选择拟订相应的准则。选择一种把下列设计关注对象作为顶层设计组成部分的分类方法是很有用的：
● 顾客：
● 环境：
● 功能度：
● 数据：
● 状态／模式；
● 结构：
● 管理。
把这些设计关注对象纳入完备的技术数据包中。
典型工作产品
1． 完备的技术数据包．
子惯例
1． 确定设计的层次和每个设计层的相应的文档层。
为了控制文档成本和支持产品集成和验证，确定那些要求文档和需求可溯源性的产品构件的层次（例如，子系统、软件配置项、软件构件、软件单元）是重要的。
2． 在分配的产品构件需求、体系结构设计和高层设计的基础上做详细设计。
3． 用技术数据包使设计文件化。
4．汇集关键（例如对成本、进度或技术性能有重大影响的）决策或决定的理由。
5． 必要时修改设计。
SP 2.3-1确定接口描述
确定并维护关于产品构件接口的解决方案．
产品构件接口描述文件中包括：
● 产品构件之间的接口；
● 低层构件与高层构件之间的接口；
● 产品构件与产品相关过程（基础设施性的／现行的、复用的或新开发的过程）之间的关系：
● 产品构件与外部产品之间的接口。
典型工作产品
1． 接口设计．
2． 接口设计文档。
SP 2.3-3设计综合接口
运用所确定并维护的准则设计产品构件接口。
接口设计包括以下内容：
● 原发点：
● 目的地：
● 激励源和数据特性。
接口设计准则经常表现为综合在一起的一系列关键参数；为了确定这些参数的能力，必须定义，或者至少要研究它们。这些参数往往与安全性和任务关键特性相关。
典型工作产品
1． 接口规格说明．
2． 接口控制文档。
3． 接口规格说明准则和模板。
4． 接口规格说明模板的更新本。
SP 2.4-3进行制作、购买或复用分析
根据所规定的准则，对产品构件究竟是新开发、采购还是复用进行评价．
关于规定准则、候选方案和进行结构化决策的更多的信息，参见“决策分析和决定”过程方面。
制作、购买和复用决策对项目和组织的成功有很大的影响。
关于如何处理产品构件采办的更多的信息，参见“供方协定管理”过程方面。
技术进步状况是选择开发或者采购产品构件的重要理由。在开发工作很复杂时，可能以采购现货构件为佳，而拥有先进工具的情况则支持自己开发。现货产品可能不够完整，或者文档不够准确，将来能不能得到支持很难预料。
一旦作出采购现货产品构件的决定，就要根据产品构件需求拟订供方协定。有时，“现货”指的是在市场上不能马上得到的现行产品，也就是说，不是真正的“现货”。在有的情况下，在使用这类非开发的产品时需要把性能细节和其他产品特性限定在规定范围内；在这种情况下，要在供方协定中规定需求和验收准则并予以管理。在另外一些情况下，现货产品是真正的现货（例如字处理软件）．不需要与供方签定协定。
典型工作产品
1． 设计和构件复用准则。
2． 制造或购买分析的结果。
3． 选择商业现货构件的指南。
子惯例
1． 当选择采购的产品或非开发产品（商业现货、复用品）时，制订维护这些产品的计划。
要考虑如何处理与操作系统和数据库管理软件的将来版本的兼容性．
SG 3实现产品设计
实现产品构件设计并产生相应的支持文档，
根据（按照特定目标2中的惯例所做的）设计实现产品构件。这种实现通常涉及到在把产品构件投入“产品集成”过程和编制最终用户文档之前进行单元测试。
SP 3.1-1实现设计
实现产品构件的设计．
一旦产品构件设计完成，就要予以实现。反映设计得以实现的特征与产品构件的类型密切相关。软件代码是典型的产品构件。
|
这类实现特征的例子有； ●软件编码； ●编写数据文档 ●编写服务文档 ●编写过程文件 |
典型工作产品
1． 实现的设计。
子惯例
1． 运用有效的方法实现产品构件。
|
编码方法的例子有： ●结构化程序设计； ●面向对象的程序设计 ●自动代码生成 ●软件代码利用 ●使用适用的设计模板。
|
在项目已定义过程中直接编入实现产品构件的方法，或者予以引证。
2． 遵循适用的标准和准则。
|
编码标准的例子有： ●语文标准 ●变量命名约定 ●可接受的语言结构； ●软件构件的结构和分层 ●代码和注释格式
|
|
编码准则的例子有： ●模块化程度； ●简易性 ●结构化； ●可维护性；
|
3． 对所选择的产品构件进行同行审查。
关于进行同行审查的更多的信息，参见“验证”过程方面。
4． 适当时，对产品构件进行单元测试。
单元测试方法的例子有： ●语句覆盖测试； ●分支覆盖测试 ●谓词覆盖测试 ●路径覆盖测试 ●边界值测试； ●特殊值测试 |
5． 必要时修改产品构件。
|
可能要对产品构件进行修改的时机的例子是当设计更改时。 |
SP 3.2-1 编制产品支持文档
编制并维护量终用户文档。
这个惯例旨在编制和维护将用于产品安装、运行和维护的文档。
典型工作产品
1．培训材料。
2． 用户手册。
3． 操作手册。
4． 维护手册。
5． 在线帮助。
子惯例
1． 审查需求、设计、产品和测试结果，以确保发现那些影响安装、运行和维护的问题并加以解决。
2． 运用有效的方法编制安装、运行和维护方面的文档。
在项目已定义过程中直接纳入编制文档的方法，或者引用它们。
遵循适用的文档编制标准。
|
文档编制标准的例子有： ●与指定的字处理器兼容 ●可接受的字休 ●页码、章节和段落编号； ●与指定的文档编制风格一致 ●缩写词的使用 ●机密标志 ●国际要求 |
4． 在生存周期的早期编写安装、运行和维护文档的初步版本：以供相关的共利益者审查。
5． 对安装、运行和维护文档进行同行审查。
关于进行同行审查的更多的信息，参见“验证”过程方面。
6． 必要时，修改安装、运行和维护文档。
有必要对文档进行修改的情况的例子有： ●需求变更； ●设计变更 ●产品变更 ●文档有差错 ●围绕工作的应急措施
|
与目标对应的通用惯例
GG 1实现特定目标
该过程通过把可识别的输入工作产品转换成可识别的输出工作产品支持实现此过程方面的特定目标并且使之能够实现．
GP l.1确定工作范围
针对“技术解决”过程，确定所要执行的工作的范圈和所要生产韵工作产品的范圈，并且把这些信息传达给将要执行该工作的人。
GP l.2执行基本惯倒
执行“技术解决“这个过程方面的基本惯例，以开发工作产品和提供服务，以便实现该过程方面的特定目标．
GG 2制度化为受管理过程
把该过程作为受管理过程加以制度化．
GP 2.1建立组织方针
为策划和执行搿技术解决一过程，制订并维护组织方针．
详细说明：
这个方针要确定组织的如下期望：反复进行产品构件的选择、产品和产品构件的设计以及产品构件设计的实现工作。
GP 2.2策划该过程
为执行Ⅳ技术解决月过程，建立并维护需求、目标和计划．
详细说明：
这些需求、目标和计划一般是按“项目策划”过程方面所述在项目计划中描述。
GP 2.3提供资源
为了执行所策划的过程、开发工作产品和为“技术解决”过程提供服务，提供足够的资源．
详细说明：
为了针对需求拟订、设计和买现解决方案，可能需要一些特殊设施。必要时，要开发或购买“技术解决”过程方面中的活动所要求的设施。
|
用于执行“技术解决”过程方面的活动的工具的例子有： ●设计规范工具； ●住址程序和建模工具 ●原形设计工具 ●场景定义和管理工具 ●需求跟踪工具 ●交互式文档编制工具 |
GP 2.4分配责任
为执行该过程、开发工作产品和提供“技术解决”过程所需的服务，分配责任和权限．
GP 2.5培训人员
必要时，对执行或支持“技术解决”过程的人员进行培训．
详细说明：
|
培训专题的例子有： ●产品和产品构件的应用领域 ●设计方法 ●接口设计； ●单元测试技术 ●标准（例如产品标准、安全性标准）
|
GP 2.6管理配置项
把技术解决帮过程的指定的工作产品置于配置管理的适当层次．
详细说明：
GP 2.7确定相关的共利益者并使之介入
按计划确定“技术解决”过程的相关的共利益者并使之介入。
详细说明：
对于工程化类过程来说，要考虑在顾客、最终用户、开发人员、生产人员、测试人员、供应者、营销人员、维护人员、处置人员以及可能受产品和过程影响或者可能影响产品和过程的其他人员中间的共利益者。
|
需要共利益者介入的活动的例子： ●拟订候选解决方案和选择准则； ●逐渐形成操作概念和场景； ●寻求批准外部界面规范和设计描述； ●开发技术数据包； ●针对产品构件评估各种方案是制作、购买、还是复用 ●实现设计
|
GP 2.8监督和控制该过程
对照监督和控制“技术解决”过程，并且采取适当的纠正措施．
详细说明：
|
在监督和控制“技术解决”过程方面的各项活动中使用的度量项目的例子有： ●因返工而带来的超支的成本、拖延的进度和加大的工作量： ●产品或产品构件设计中所处理的需求的百分比： ●产品、产品构件、接口和文档的规模和复杂程度： ●技术解决方案工作产品的缺陷密度。 |
GP 2.9客观地评价遵循情况
对照适用的需求、目标和标准，客观地评价搿技术解决一过程以及该过程的工作产品和服务的遵循情况，并且处理不符合项．
详细说明：
|
被审查的活动的例子有： ●选择产品构件解决方案； ●设计产品和产品构件； ●实现产品构件设计 |
|
被审查的工作产品的例子有； ●技术数据包 ●产品、产品构件和接口设计 ●实现的设计（例如，代码） ●用户、安装、运行和维护文档。 |
GP2.10高层管理者审查状态
离层管理者审查“技术解决”过程的活动、状态和结果，并解决问题。
GG3制度化为已定义过程
把该过程作为已定义过程加以制度化．
GP 3.1建立已定义过程
建立并维护一个已定义的“技术解决”过程的描述．
GP 3,2收集改进信息
收集那些派生于“技术解决”过程的策划和执行的工作产品、度量项目和改进信息，用以支持本蛆织的过程和过程财富的进一步使用和改进．
GG4制度化为定量管理过程
把该过程作为定量管理的过程加以制度化
GP 4.1 建立质量目标
根据曩窖需求和组织业务目标，为“技术解决”过程的质量和过程性能建立定量目标并予以维护．
GP 4,2使子过程性能稳定
使“技术解决”过程的一个或几个子过程的性能稳定下来，进而确定该过程在实现所规定的定量目标和过程性能目标方面的能力．
GG 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化．
GP 5.1 确保不断的过程改进
确保_技术解决一过程不断得以改进，以适应本组织的有关的总体业务目标．
GP 5.2解决问曩的共性原因识别并解决“技术解决”过程中，的缺陷和其他问题的根本原因。
6.4.4产品集成
“产品集成”的目的在于把产品构件组装成产品，确保所集成的产品恰当地发挥作用，确保交付产品。
这个过程方面涉及到把产品构件集成为比较复杂的或更加完整的产品。在这个过程方面里使用术语“集成”就是指上述意义，不要把它与本模型中其他地方可能描述的人或活动的集成或综合相混淆。这个过程方面的范围是按照规定的集成策略实现完整的产品集成，而不论是通过一步或多个步骤来完成产品构件的组装。
产品集成的关键之一是产品和产品构件的内部和外部接口的管理，要确保接口之间的兼容性。
在整个项目进程中都应注意接口管理。
产品集成不是只在设计和制作结束时产品构件一次性组装，往往是采用“产品构件组装、评价组装的产品、再组装更多的产品构件”这样一个迭代过程逐渐进行。这种迭代过程可以从分析和模拟（例如，主线扩展、快速原型、虚拟原型和实物原型）开始，稳步地推进，逐渐增加功能度，直到实现最终产品，在每次成功“建造”中，构造原型并加以评价、改进和根据评价中了解的情况重新构造。原型的虚、实程度取决于设计工具的功能度、产品的复杂程度以及相应的风险．按照这种迭代方法集成的产品，通过验证和确认的可能性很大。有些产品的最后集成阶段要在运行现场完成。
有关的过程方面
关于识剐接口需求的更多的信息，参见“需求开发”过程方面。
关于定义接和集成环境（当需要开发集成环境时）豹更多的信息，参见“技术解决”过程方面。
关于验证接口、集成环境和逐渐组装的产品构件的更多的信息，参见“验证捧过程方面。
关于对产品构件和集成的产品进行确认的更多的信息，参见“确认”过程方面。
关于识别风险和利用原型缓解接口能力和产品构件集成的风险的更多的信息，参见“风险管理”过程方面。
关于运用结构化方法选择适当的集成策略和决定是开发还是采购集成环境豹更多的信息，参见“决策分析和决定”过程方面。
关于管理接口定义变更和信息分发的更多的信息，参见“配置管理”过程方面。
关于采购产品构件或集成环境组成部分的更多的信息，参见“供方协定管理”过程方面．
特定目标
SG 1准备产品集成
制订并维护进行产品集成的策略．
SG 2确保接口兼容性
确保产品构件接口在内部和外部两个方面都是兼容的．
SG 3坦装产品构件和交付产品
组装经过验证的产品构件，交付已完成集成、验证和确认的产品．
通用目标
G0 1实现特定目标
该过程通过把可识别的输工作产品转换成可识别的输出工作产品．以支持实现该过程方面的特定目标并且使之能够实现．
G0 2制度化为受管理过程
把制度化作为受管理过程加以制度化．
GG3制度化为已定义过程
把该过程作为已定义过程加以制度化．
GG 4制度化为定量管理过程
把该过程作为定量管理过程加以制度化．
GGI 5制度化为持续优化过程
把该过程作为持续优化过程加以制度化．
与目标对应的特定惯例
Sa 1准备产品集成
制订并维护进行产品集成的策略．
产品构件集成的准备，涉及到建立和维护集成策略。集成策略应在当前项目的早期结合实施“技术解决”过程方面的惯例来拟订。集成策略和支持性文档将确定各种产品构件的接收、组装和评价活动的顺序。
SP l.1-1Ik立产品集成策略
建立并维护关于产品构件集成的策略．
关于定义产品，产品构件的接口的更多的信息，参见“技术解决”过程方面中“设计综合接口”特定惯例。
集成策略是有效的产品集成的基础。成功的集成策略应该根据产品构件的复杂程度和中间的以及最终的组装产品的复杂程度采用各种技术的组合．在制订集成策略时．必须分析各种组装顺序，选择最好的解决方案，以及确定产品构件集成的环境和最低限度规程。
产品构件、测试设备、规程、集成环境以及人员技能的可用性等等都是影响制订集成策略的因素．集成策略支持产品构件的渐进式组装和评价，因而为进一步纳入其他产品构件莫定良好基础，或者是为高风险产品构件的原型奠定良好基础。对于复杂的产品而言，集成策略应该是渐进式的并且涉及“建造一评价一建造”的迭代过程。集成策略应该与“技术解决”过程方面中有关解决方案的选择和产品及产品构件的设计等活动协调。
关于运用结构化方法选择适当的产品集成策略的更多的信息，参见“决策分析决定”过程方面。
关于管理分发产品集成策略变更情况的更多豹信息，参见“配置管理”过程方面。
关于识别和处理产品集成策略中豹风险的更多的信息，参见“风险管理”过程方面。
典型工作产品
1． 产品集成顺序和选择该顺序的理由。
2. 不采纳其他组装场景的理由。
3． 产品集成环境定义。
4． 产品集成规程和准则。
5． 用于产品构件的组装的评价策略。
6． 产品集成策略文档。
子惯例
1． 识别待组装的产品构件。
2． 确定将运用产品构件间接口定义进行的产品集成验证。
3． 确定在集成产品构件时所要求的产品集成环境。
这项活动可能包括为建立集成环境规定专门的工具和测试设备。
4． 确定产品构件集成的逻辑顺序。
5． 制订产品集成策略。
|
产品集成战略所包含的内容的例子有： ●产品集成顺序 ●要做的工作 ●每项活动的责任和所需求的资源； ●应子满跳的进度 ●应予遵循的规程 ●所要求的工具
|
6． 定期审查产品集成策略并且在必要时予以修改。
对集成策略进行评估，以确保不至于因生产和交付进度的变化而给前面的决策所依据的因素或顺序造成不利影响。
7． 汇集关于作出决定和暂缓决定的理由。
8． 采取纠正措施，改进产品集成策略。
9． 不断评估产品集成策略。
10.管理产品集成策略的更改和分发有关的信息。
SP l.2-1建立产品集成环境
建立并维护必要的环境，以支持产品构件的集成，
关于如何开发产品集成环境或如何购买或复用这种环境的更多的信息，参见“技术解决”过程方面。
产品集成策略可能要确定必须购买的或开发的环境：于是将产生关于设备、软件或其他资源的采购或开发的需求。在“需求开发”过程中要处理这些需求。产品集成环境可以包含对组织的现有资源的复用。在这种情况下，集成策略应该指出这些资源的用途并且必须作出使用安排。关于是采购还是开发产品集成环境的决策，是在“技术解决”过程中进行。如果决定开发产品集成环境，将实施“技术解决”和其他涉及项目开发的过程方面中的有关惯例。在产品集成过程中的每个步骤上所要求的环境可能包括测试设备、仿真程序（在没有现成可用的产品构件的情况下）和记录设备等。
典型工作产品
1． 经过验证的产品集成环境。
2． 产品集成环境的支持文档。
子惯例
1． 识别关于产品集成环境的需求。
2． 确定产品集成环境用的验证准则和规程。
3． 决定是制作还是购买必要的产晶集成环境。
4． 启动开发集成环境的项目（如果不能购买时）o
对于没有先例的复杂的项目，产品集成环境可能是一个重要的开发项目，可能涉及项目策划、需求开发、技术解决、验证、确认和风险管理等过程a
5． 在整个项目开发过程中维护产品集成环境。
6． 当该集成环境不再使用时，处置该环境的各个部分。
SP l.3-1 规定详细的产品集成规程
为产品构件的集成规定详细的规程和准则．
随着产品集成策略的成熟，需要详细的规程、输入、输出、预期的结果和判定进展的准则。产品构件集成用的详细规程可能包括（例如）所要执行的迭代的次数和预期测试的细节以及在每个阶段进行的其他评价。详细的进展准则可能包括一些用于判断供集成的产品构件是否准备就结盟或者这些产品构件的可接受性的准则。
|
准则的例子有： ●恰当发挥作用的可能性 ●音乐会率及其偏差 ●从定货到交付的时间； ●人员可用性 ●集成环境的可用性
|
可以针对产品构件如何验证和产品构件的预期功能，以及组装的产品构件和最终组装完成的产品如何确认和交付等规定详细准则。详细准则还可以包含集成测试环境的细节规定或产品构件通过测试的允许仿真程度。’
典型工作产品
1． 详细的产品集成规程。
2． 详细的产品集成准则。
子惯例
1． 制订并维护用于产品构件的详细的产品集成规程。
2． 制订并维护用于产品构件集成和评价的详细准则。
3． 制订并维护用于已集成产品的确认和交付的详细准则。
SG 2确保接口兼容性
确保产品构件接口，不论内部的还是外部的，都是兼容的。
许多产品集成问题都出自于对内部或外部接口不了解或失控。产品构件接口需求、规范、以及设计的有效管理有助于确保所实现的接口完备和兼容。
SP 2.1-1 审查接口描述的完备性
就覆盖情况和完备性，审查接口描述。
这里所说的接口，除了产品构件接口以外，还应该包括与产品集成环境的所有接口。
典型工作产品
1． 接口分类。
2． 每类接口的一览表。
3． 接口与产品构件和产品集成环境的对照。
子惯例
1． 审查接口数据的完备性，确保完全覆盖所有接口。
在消息处理类软件中，接口包括：
● 原发点：
● 目的地；
● 激励因素：
● 协议和数据特性。
要考虑所有产品构件并且准备一份关系对照表。
2． 确保产品构件和接口加注标志，以保证容易作到正确连接。
3． 定期审查接口描述的充分性。
接口描述一旦建立，必须定期进行审查，以确保现行描述与正在开发或购买的产品之间不发生偏离。
SP 2.2-1管理接口
针对产品和产品构件管理内部和外部的接口的定义、设计和变更。
关于接口需求的更多的信息，参见“需求开发”过程方面。
关于产品构件之间的的接口的设计的更多的信息，参见“技术解决”过程方面。
1929