软件生命周期流程-技术管理流程 - IEEE 12207-2017 软件和系统工程标准系列

1.1 目的

项目规划过程的目的是制定和协调有效且可行的计划。

这一过程确定了项目管理和技术活动的范围，确定了过程的输出、任务和可交付成果，制定了任务执行的时间表（包括成就标准）和完成任务所需的资源。这是一个持续的过程，贯穿整个项目，并定期对计划进行修订。

注：在其他每个过程中定义的策略提供输入并集成到项目规划中 过程。项目评估和控制过程用于评估计划是否综合、一致和可行。

1.2 结果

成功实施项目规划过程的结果是：

• 1. 定义目标和计划。
• 2. 定义角色 ³、 职责、责任和权限。
• 3. 正式请求并承诺实现目标所需的资源和服务。
• 4. 项目实施计划已启动。

三十八

1.3 活动和任务

项目应根据项目规划过程适用的组织政策和程序实施以下活动和任务。

a)定义项目。此活动包括以下任务：

1）确定项目目标和限制。

注：目标和约束包括性能和其他质量方面、成本、时间以及顾客和用户满意度。每个目标都具有一定程度的详细程度，以便选择、定制和实施适当的过程和活动。

注：ISO/IEC15026系统和软件保证、 ISO/IEC27001信息安全管理体系和 ISO/IEC27036供应商 ⁴关系信息安全为保证和安全相关的目标和约束提供了额外指导。

2）按照协议的规定确定项目范围 ⁵。

注意这包括满足业务决策标准和成功完成项目所需的相关活动。一个项目可以负责整个软件系统生命周期中的一个或多个阶段。项目规划包括定义适当的操作以维护项目计划、进行评估和控制项目。

3）定义并维护由各个阶段组成的生命周期模型，使用定义的生命周期模型该组织。

注：ISO/IECTS24748‑1 提供了有关生命周期阶段 ⁶和适当生命周期模型定义的详细信息。它定义了一组通用的示例系统生命周期阶段，包括概念、开发、生产、使用、支持和退役。它还确定了一组通用的示例软件生命周期阶段，包括需求确定、概念探索和定义、演示和评估、工程/开发、生产/制造、部署/销售、运营、维护和支持以及退役。

4）根据可交付产品或不断发展的流程建立工作分解结构（WBS）。软件系统的架构。

注：软件系统架构的每个元素以及相应的流程和活动都以与已识别风险一致的详细程度进行描述。 工作分解结构中的相关任务按执行情况进行分组。项目任务确定正在开发或生产的工作项。项目管理协会 (PMI) 的工作分解结构实践管理标准包含有关 WBS 的更多详细信息。

注：对于采用敏捷迭代方法的项目，从用户角度来看，WBS 元素可以对应于迭代过程中产生的主要特性。

• 5. 定义并维护将在项目中应用的流程。

注：这些过程基于组织已定义的过程（参见生命周期模型管理过程）。附件 A 包含有关定制的信息，可用于满足项目特定需求。过程的定义包括进入和退出标准、输入、过程序列约束（前置/后继关系）、过程并发要求（哪些过程和任务要与其他过程区任务或活动同时进行）、 有效性测量/性能测量属性、以及范围和成本参数（用于至关重要的成本估算 ⁷）。

注：通过投资组合管理流程来确定与其他项目或组织单位的接口。

b)规划项目和技术管理。此项活动包括以下任务：

1）根据管理、技术目标和工作内容制定并维护项目进度表估计。

注：这包括定义持续时间、关系、依赖关系 ⁸和活动顺序、成就里程碑、所使用的资源以及为及时完成项目所必需的风险管理审查和计划储备。

三十九

2） 定义生命周期阶段决策门、交付日期和对外部输入或输出的主要依赖关系的成就标准。

注：内部评审 ⁹之间的时间间隔是根据组织关于业务和系统关键性、时间表和技术风险等问题的政策定义的。

• 3. 确定成本并规划预算。

注：预算成本基于进度表、软件规模和复杂性估计、劳动力估计、基础设施成本、采购项目、获得的服务和支持系统估计以及风险管理的预算储备。

4）定义角色、职责、责任和权限。

注：这包括定义项目组织、人员招募和人员技能开发。权限包括（视情况而定）法律上负责的角色和个人，例如设计授权、安全授权以及负责适用认证或认可的人员。

5)定义所需的基础设施和服务。

注：这包括定义所需的容量、其可用性及其对项目任务的分配。基础设施包括设施、服务、工具、通信和信息技术 ¹⁰资产。还指定了每个生命周期阶段启用系统和服务的要求。

• 6. 计划从项目外部获取材料以及启用系统和服务。

注：这包括必要时的招标计划、供应商选择计划、验收计划、合同管理和合同结束计划。协议流程 ¹¹用于计划中的收购。

注：ISO/IEC27036，供应商关系信息安全，为基础设施和服务的采购提供了指导。

• 7. 制定并传达项目和技术管理和执行计划，包括评审。

注：软件系统的技术规划包含在系统工程管理计划 (SEMP) 或软件工程管理计划或软件开发计划 (SDP) 中。 ISO/IEC/IEEE24748‑5 提供了更多详细信息软件工程技术管理规划，包括 SDP 的注释大纲。项目规划已在项目管理计划中捕获。 ISO/IEC/IEEE16326 提供了有关项目规划的更多详细信息。

注：每个其他过程中的战略 ¹²活动和任务均提供输入并集成到项目规划过程中。项目评估和控制过程用于帮助确保计划的完整性、一致性和可行性。

c)启动项目。此活动包括以下任务：

1)获得启动该项目的批准。

注：开始批准（继续进行）是通过投资组合管理流程提供的。

2）提交请求并获得执行项目所需资源的承诺。

注意这包括访问启用系统或服务。

3）实施项目计划。

2.1 目的

项目评估与控制过程的目的是评估计划是否一致且可行；确定项目的状态、技术和过程绩效；并指导执行，以帮助确保绩效符合计划和时间表，在预计预算范围内，以满足技术目标。

此过程定期或在重大事件时评估相对于要求、计划和总体业务目标的进展和成果。当检测到重大差异时，将提供信息以供管理行动。此过程还包括根据需要重新定向项目活动和任务，以纠正已识别的与其他技术管理或技术过程的偏差和变化。重定向可能包括根据需要重新规划。

2.2 结果

成功实施项目评估与控制过程的结果是：

• 1. 有绩效衡量或评估结果。
• 2. 评估角色、 职责、责任和权限的充分性。
• 3. 评估资源的充足性。
• 4. 进行技术进展审查。
• 5. 调查并分析项目绩效与计划的偏差。
• 6. 受影响的利益相关者 ¹³获悉项目状况。
• 7. 当项目成果未达到目标时， 定义并指示纠正措施。
• 8. 根据需要启动项目重新规划。
• 1. 授权计划从一个预定的里程碑或事件到下一个里程碑或事件的进展（或不进展） 的行动。
• 10. 项目目标已实现。

2.3 活动和任务

项目应根据与项目评估和控制过程相关的适用组织政策和程序实施以下活动和任务。

a)项目评估和控制计划。此项活动包括以下任务：

1）定义项目评估和控制策略。

注：该策略确定了预期的项目评估和控制活动，包括计划的评估方法和时间框架，以及必要的管理和技术评审。

b)评估项目。此项活动包括以下任务：

1）评估项目目标和计划与项目背景的一致性。

2）根据目标评估管理和技术计划，以确定其充分性和可行性。

3）根据适当的计划评估项目和技术状况，以确定实际和预计成本，时间表和绩效差异。

4）评估角色、职责、责任和权限的充分性。

注：这包括对人员胜任项目角色和完成项目任务的能力的充分性的评估。尽可能使用客观指标，例如资源使用效率、项目成果。

5）评估资源的充足性和可用性。

注意资源包括基础设施、人员、资金、时间或其他相关项目。此任务包括评估现有流程和基础设施资源的使用情况，并确认组织内部承诺得到满足。

6）通过衡量成就和里程碑完成情况来评估进度。

注：这包括收集和评估劳动力、材料、服务成本和技术性能的数据，以及关于目标的其他技术数据，如可负担性。这些数据将与成就衡量标准进行比较。这包括进行有效性评估，以确定不断发展的软件系统是否符合要求。它还包括使系统能够在需要时交付其服务的准备情况。

7）进行必要的管理和技术审查、审计和检查。

注意这些是正式的或非正式的，目的是确定是否准备好进入生命周期的下一阶段或项目里程碑，帮助确保项目和技术目标得到满足，或获得利益相关者的反馈。

• 8. 监控关键流程和新技术。

注：这包括识别和评估技术成熟度和技术插入的可行性。技术成熟度是指技术投入运营的准备程度，通常按从低（仅作为概念存在）到高（已在运营中得到证明）的等级进行衡量。

9）分析测量结果并提出建议。

注：对测量结果进行分析是为了发现与计划值之间的偏差、变化或不良趋势（包括潜在问题），并提出适当的纠正或预防措施建议。在适当的情况下，这包括对指示趋势的度量进行统计分析，例如，指示输出质量的故障密度、指示过程重复性的测量参数分布。

10）记录并提供评估任务的状态和结果。

注意这些通常在协议、政策和程序中指定。

• 11. 监控项目内的流程执行情况。

注：这包括对过程措施的分析和对项目目标趋势的审查。任何确定的改进措施都可以通过质量保证流程、质量管理流程或生命周期模型管理流程来处理。

c)控制项目。此项活动包括以下任务：

1）采取必要行动解决已发现的问题。

注：当项目的技术成果未达到计划目标时，将发生此任务。这包括预防、纠正和问题解决措施。当检测到不足或不可用时，或当项目的技术成果超出目标或计划时，措施通常要求重新计划或重新分配人员、工具和基础设施资产。它们通常会影响成本、进度或技术范围或定义。措施有时需要更改生命周期过程的实施和执行。

注：记录并审查行动以确认其充分性和及时性。

2）启动必要的项目重新规划。

注：当项目目标或约束发生变化，或规划假设被证明无效时，就会启动项目重新规划。

注：任何需要变更购买方和供应商之间的协议的变更都会调用购买和供应流程。

3）当合同因合同约定的成本、时间或质量发生变更时，应启动变更行动收单方或供应商请求。

注：这包括考虑修改供应条款和条件或启动新供应商的选择，这将调用采购和供应流程。

四十二

• 4. 如果合理，授权项目继续进行下一个里程碑或事件。

注意项目评估和控制过程用于就里程碑完成达成一致。

3.1 目的

决策管理过程的目的是提供一个结构化的分析框架，以便客观地识别、描述和评估生命周期中任何时候的决策替代方案，并选择最有利的行动方案。

此过程用于解决技术或项目问题，并响应软件生命周期中遇到的决策请求，以便确定可为情况提供首选结果的替代方案。决策管理最常用的方法是行业研究和工程分析。每个替代方案都根据决策标准进行评估（例如，成本影响、进度影响、程序约束、监管影响、技术性能特性、关键质量特性和风险）。这些比较的结果通过合适的选择模型进行排名，然后用于决定最佳解决方案。关键研究数据（例如，假设和决策原理）通常保留以告知决策者并支持未来的决策。

当需要对其中一个标准的参数进行详细评估时，可以采用系统分析注释过程来执行评估。

3.2 结果

成功实施决策管理流程的结果是：

• 1. 确定需要进行替代分析的决策。
• 2. 确定并评估替代行动方案。
• 3. 选择首选的行动方案。
• 4. 确定决议、 决策理由和假设。

3.3 活动和任务

项目应根据与决策管理过程相关的适用组织政策和程序实施以下活动和任务。

a)为决策做好准备。此活动包括以下任务：

1）定义决策管理策略。

注：决策管理策略包括确定角色、职责、责任和权限。该策略考虑获取信息输入和及时做出决策的需要。它包括确定决策类别和优先顺序方案。决策的产生是有效性评估、技术权衡、 需要解决的问题、应对超过可接受阈值的风险所需采取的行动或项目进展到下一个生命周期阶段的新机会的结果。

组织或项目指南决定了决策分析 ¹⁴的严谨程度和正式程度。

2） 确定情况和决策需要。

注意问题或机会以及解决其结果的替代行动方案均已被记录、分类和报告。

3）让相关利益相关者参与决策，以吸取经验和知识。

注意确定分析和决策所需的主题专业知识是一种很好的做法。

b)分析决策信息。此活动包括以下任务：

1）为每个决策选择并声明决策管理策略。

注意：确定解决这些问题或机会所需的严谨程度，以及评估替代方案所需的数据和系统分析。定义做出决策的时间框架。

2）确定期望结果和可衡量的选择标准。

注意：确定可量化标准的期望值和阈值（超过该阈值属性将不令人满意），以及标准的加权因子。

3）确定交易空间和替代方案。

注：如果存在大量替代方案，则需要进行定性筛选，将替代方案减少到可管理的数量，以便进行进一步的详细系统分析。这种筛选通常基于对风险、成本、进度和监管影响等因素的定性评估。

4）根据标准评估每个替代方案。

注：系统分析过程 ¹⁵用于根据需要量化每个待评估贸易替代方案的特定标准。这包括新的设计参数、不同的架构特性和关键质量特性的数值范围。系统分析过程评估参数变化范围，以便对每个待评估的贸易替代方案进行敏感性分析。这些结果用于确定各种贸易替代方案的可行性。

c)制定和管理决策。此活动包括以下任务：

1）确定每个决策的优选方案。

注意：使用选择标准对替代方案进行定量评估。选定的替代方案通常可以对已确定的决策进行优化或改进。

2）记录决议、决策依据和假设。

3）记录、跟踪、评估和报告决策。

注：这包括问题和机会的记录及其处置，以协议或组织程序中规定的方式以及允许审计和从经验中学习 ¹⁶的方式。

注：这使组织能够确认问题已得到有效解决、不利趋势已得到扭转并且已充分利用机遇。

4.1 目的

风险管理过程的目的是持续识别、分析、处理和监控风险。

风险管理过程是一个在系统产品或服务的整个生命周期内系统地处理风险的持续过程。它可以应用于与系统的获取、开发、维护或运行相关的风险。

以解决。 ISOGuide 73:2009 将风险定义为“不确定性对目标的影响”。这附有注释 1，“注释影响是与预期的偏差 积极和/或消极”。积极风险通常被称为机会，可以在风险管理过程中予

4.2 结果

成功实施风险管理流程的结果是：

a)已识别风险。

四十四

b)分析风险。

• 3. 识别、 排列优先次序并选择风险处理方案。

d)实施适当的治疗。

e)评估风险以评估状态的变化和治疗的进展。

4.3 活动和任务

项目应根据适用的组织有关风险管理流程的政策和程序实施以下活动和任务。

ISO9001 ISO/IEC/IEEE16085 提供了一套更详细的风险管理活动和任务。此风险管理流程与 ISO31000:2009风险管理 原则和指南以及 ISO 指南 73:2009风险管理 词汇保持一致。:2015 在 6.1 中描述了风险和机遇规划。

a)规划风险管理。此项活动包括以下任务：

1）定义风险管理策略。

注意这包括供应链供应商的风险管理流程，并描述如何将供应商的风险提升到下一个级别以纳入项目风险流程。

2）定义并记录风险管理过程的背景。

注：这包括利益相关者的观点、风险类别的描述，以及技术和管理目标、假设和约束 ¹⁷的描述（可能通过引用）。风险类别包括软件系统的相关技术领域，并有助于识别整个产品生命周期中的风险。如上所述

在ISO31000中，此步骤的目的是根据可能造成、加强、防止、降低、加速或延迟目标实现的事件生成一份综合的风险清单。

注：机会是风险的一种，它为软件系统或项目提供潜在的利益。每一个追求的机会都有与之相关的风险，这些风险会减损预期的利益。这包括不追求机会所带来的风险，以及未能实现机会的效果的风险。

b)管理风险概况。此项活动包括以下任务：

1）定义并记录风险阈值和可以接受风险水平的条件。

2）建立并维护风险概况。

注：风险概况记录：风险管理环境；每种风险状态的记录，包括其发生的可能性、后果和风险阈值；基于利益相关者提供的风险标准的每种风险的优先级 ¹⁸；以及风险行动请求及其处理状态。当单个风险状态发生变化时，风险概况会更新。风险概况中的优先级用于确定资源的处理应用。

3）根据利益相关者的需求，定期向其提供相关的风险概况。

c)分析风险。此活动包括以下任务：

• 1. 识别风险管理环境中所述类别中的风险。

注：风险通常通过各种分析来识别，例如安全性 ¹⁹、可靠性、保障和性能分析；技术、架构和就绪性评估；以及行业研究。这些风险通常在生命周期的早期识别，并延续到软件系统的使用、支持和退役过程中。此外，风险通常是通过对不断发展的软件系统的测量分析来识别的。

2）评估每个已识别风险发生的可能性和后果。

注：风险的后果通常涉及技术、进度、成本或质量影响。

四十五

3）根据风险阈值评估每种风险。

4）对于每个不符合风险阈值的风险，定义并记录建议的治疗策略和措施。

注：风险处理策略包括但不限于消除风险、降低其发生的可能性或后果的严重性、或接受风险。处理还包括承担或增加风险以追求机会。措施提供有关处理替代方案的有效性的信息。

d)处理风险。此项活动包括以下任务：

• 1. 确定风险处理的推荐替代方案。

2） 实施风险处理替代方案，利益相关者确定应采取的行动使风险可接受。

3）当利益相关者接受未达到其阈值的风险时，应将其视为高优先级，并持续监控，以确定未来的风险处理行动是否必要或其优先级是否发生了变化。

• 4. 一旦选定了风险处理方案，就要协调管理行动。

注意：可以应用项目评估和控制流程。

e)监控风险。此项活动包括以下任务：

1）持续监控风险和风险管理环境的变化，并在风险发生变化时评估风险。状态已改变。

2）实施和监控措施，评估风险处理的有效性。

3）在整个生命周期中持续监控新风险和新风险源的出现。

5.1 目的

配置管理的目的是在生命周期内管理和控制系统元素和配置。配置管理 (CM) 还管理产品与其相关配置定义之间的一致性。

软件配置管理（SCM）适用于软件系统及其接口。接口管理的目的是与接口合作伙伴就软件系统和服务之间的通信进行的数据交换达成一致。附件 E（见 E.5）提供了接口管理流程视图的一个示例。

软件配置通过受控的新版本发布进行更改。发布的目的是授权和影响软件特性、功能或系统的可用性，用于特定用途，对一组用户有或无限制。

5.2 结果

成功实施配置管理过程的结果是：

• 1. 识别并管理需要配置管理的项目。

b)建立配置基线。

• 3. 对配置管理下项目的变更进行控制。

d)配置状态信息可用。

四十六

e)所需的配置审计已完成。

• 6. 系统发布和交付受到控制和批准。

5.3 活动和任务

项目应根据与配置管理流程相关的适用组织政策和程序实施以下活动和任务。

注：ISO/IEC/IEEE19770 为 IT 资产管理系统提供了程序和要求。

a)规划配置管理。此活动包括以下任务：

1）定义配置管理策略，包括以下方法：

• 1. CM治理， 包括角色、职责、责任、权限和使用配置控制（变更控制）委员会；以及

二） 在批准配置基线以及常规和紧急变更请求时考虑风险和影响的级别。

注意：使用批准的程序定期应用软件补丁或签入和签出正在开发中的经过单元测试的软件元素的计划变更通常是自动执行的，或者作为例行事务每天进行审查和批准。相比之下，对项目成本和进度有重大影响的软件系统设计的重大变更可能涉及广泛的分析、与供应商的磋商、利益相关者的审查以及组织最高级别的批准。

三） 在软件系统的整个生命周期内，或者在协议或项目的范围内，在采购方、供应商和供应链组织之间进行 CMac 的协调（视情况而定）。

四） 控制对配置项的访问、更改和处置。

• 22. 需要建立的必要基线， 包括开始配置的标准事件控制并维护不断演变的配置的基线。

六） 控制软件许可、数据权利和其他知识产权资产。

七） 软件版本和发布的频率、优先级和内容。

8. 验证配置定义信息的持续完整性和安全性的审计策略和职责。

9. 变更管理，包括让利益相关者，尤其是用户做好运营软件系统和服务变更的准备。

注：对于复杂的软件系统，需要进行权衡研究，例如，选择合适的自动化工具来支持 SCM 需求和策略中确定的范围。

注：关于配置管理活动的附加指导可以在 ISO10007、IEEEStd828 和 SAEANSI/EIA‑649‑B 中找到。

注3SWEBOK（软件工程知识体系指南）提供了有关 SCM 的详细讨论。该知识领域涉及 SCM 系统的背景、SCM 项目和流程规划、SCM 计划和大纲、工具选择、分包商控制、监视和其他审计、软件配置项和关系、软件库以及配置管理流程活动。

注：SCM 策略通常记录在计划中，例如配置管理计划，有时也记录在项目的 SEMP、SDP 或项目管理计划 (PMP) 中。配置管理的策略规划通过项目规划过程进行协调。在建立点以建立基线和进行审计时，CM 规划与软件生命周期保持一致。重复 SCM 活动的频率与技术过程和阶段的迭代保持一致。SCM 规划通常包括决定何时审查配置管理规划、什么条件需要更新 CM 计划以及谁有权限更改 CM 计划和配置控制中的项目。

四十七

• 2. 定义配置项、CMartifacts 和记录的存储、归档和检索过程。

注：软件系统配置项（如源代码和可执行软件）的存储位置和条件是根据指定的完整性、安全性和保密性级别建立的。

b)执行配置识别。此活动包括以下任务：

• 1. 选择要唯一标识为配置项的软件系统元素，配置控制。

示例：软件系统中受配置控制的配置项通常包括系统/软件需求规范、接口规范；开发中的产品和系统元素（如软件对象、硬件和服务）、为阶段间过渡而建立并发布用于操作使用的基线配置或软件版本；不同平台或版本的源代码或可执行软件的主（“黄金”）副本；用于操作使用的站点特定配置；和信息项，如协议、架构模型、服务描述和操作程序；以及启用系统中的项。

注：可以将唯一标识应用于软件组件、版本或单独许可的副本。标识符符合相关标准和产品行业惯例，以便配置控制下的项目可以明确追踪到其供应商及其规格或等效记录的描述。信息项目通常与其他配置项目分开识别和管理。

注：当多个开发人员或维护程序员处理同一软件功能时，软件配置标识符有助于实现可追溯性 ²⁰，从而可以成功地重新组装和测试各个代码分支。

注：ISO/IEC19770 标准（多个部分）提供了用于跟踪软件许可证的 ITA 资产管理系统。

2）识别配置项的属性。

注：属性是指项目状态或对管理或维护软件系统有用的物理或逻辑特征。对于硬件和软件配置项，适当的属性可能有所不同。

注：配置属性和标识符可以反映软件系统的组成，以便在需要控制变更的级别上跟踪配置项。

示例：可以通过许可和维护协议跟踪来自外部供应商的软件，其中可以涉及跟踪其位置、使用系统的数量或大小，或允许的并发用户数量。

软件版本可以追溯到他们实施的利益相关者的要求。

• 3. 在生命周期中定义基线。

注：基线捕获指定时间或定义情况下软件系统元素的不断演变的配置状态。基线的内容是通过技术过程开发的，但通过配置管理过程在数据时间点正式化。基线构成后续变更的基础。选定的基线通常在采购方和供应商之间正式化，这取决于行业实践和采购方在配置管理过程中的合同参与情况。系统级基线主要有三种类型：功能基线、分配基线和产品基线。它们因领域或局部策略而异。

注：软件系统开发通常需要建立多个开发基线，以满足生命周期中各个关键点不断变化的软件配置需求，例如，允许在软件设计、原型、集成和测试发布期间同时控制软件版本。这可能涉及分布式配置管理职责和档案（例如，软件开发或测试库和主配置支持库）的访问限制。

4） 获得购买方和供应商协议以建立基线。

注意项目评估和控制过程用于达成协议。当软件用于商业或内部使用时，收购方或项目发起人可以是批准基准的权力机构。

c)执行配置变更管理此活动包括以下任务：

四十八

注：配置变更管理建立了用于管理已建立的基线变更的程序和方法。有时这被称为配置控制。术语“变更管理”也用于管理组织程序和业务工作流的变更。

• 1. 识别并记录变更请求和差异请求。

注：要求变更通常被称为偏差、放弃或让步。

2）协调、评估和处理变更请求和差异请求。

注：评估通常包括对软件和互操作系统的基本原理和需求以及其影响的分析，同时考虑风险和机会、质量、用户、进度和成本。决策取决于是否实施或拒绝变更请求。

注：变更请求和差异请求通常受配置控制委员会 (CCB) 的正式控制。

• 3. 跟踪和管理已批准的基线变更、变更请求和差异请求。

注：此任务涉及确定优先级、跟踪、安排时间安排和结束变更。然后通过技术流程进行变更。这些变更通过验证和确认流程进行核实或确认，以帮助确保已正确应用已批准的变更。

注：变更和理由通常在批准和完成时记录。

d)执行发布控制。此活动包括以下任务：

• 1. 识别并记录发布请求，识别发布中的软件系统元素。

注：生命周期模型有助于确定迭代或增量软件发布的频率。集成过程 ²¹用于选择和配置发布包、软件版本、更新或补丁。这些变更通过验证或确认过程进行验证或确认。变更是通过技术过程（尤其是过渡）进行的。

示例：用于软件测试、软件或系统鉴定或其他正式测试、或用于试用（测试版）或操作使用的版本。

2）批准软件系统的发布和交付。

注：发布通常涉及优先排序、跟踪、调度和结束变更。发布的操作使用批准可以包括接受已核实和确认的变更。发布的批准标准通常包括回滚计划或发布不成功时的应急计划。

注：对于软件系统，自动版本控制工具可以帮助确保只有正确的源代码版本才能由适当的人员访问、更新、测试和记录批准的更改，并发布。

3）跟踪和管理软件系统发布到指定环境或软件的分发交付。

注：已发布软件版本的主副本或增量变更的副本可在受控环境中为系统或项目的整个生命周期进行维护。软件供应商通常会向购买方交付许可软件的副本，以提供商定的软件维护。软件系统版本根据协议和所涉及组织的政策进行存储和分发。

e)执行配置状态核算。此活动包括以下任务：

• 1. 开发和维护软件系统元素、基线和版本的CM状态信息。

注：配置状态会计提供受控产品的状态数据，这些数据用于在整个产品生命周期中对系统元素做出决策。例如，软件状态可以包括软件功能生命周期各个阶段的过去、当前和计划进展，以及软件元素的验证和确认活动的完成。配置状态信息允许向前和向后追溯其他配置状态。配置状态记录在软件或项目生命周期中保留，然后根据协议、相关法律或组织实践进行归档。

注：记录、检索和合并当前配置状态以及以前配置的状态，以确认信息的正确性、及时性、完整性和安全性。执行审计以验证基线是否符合架构视图、接口控制文档、软件许可协议和其他协议要求。

• 2. 捕获、存储和报告配置管理数据。

f)执行配置评估。此活动包括以下任务：

• 1. 确定 CM 审计的需求并安排相关活动。

2）通过将要求、约束和豁免（差异）与正式验证活动的结果进行比较，验证产品配置是否满足配置要求，其中可能涉及抽样方法。

• 3. 监控已批准的配置变更的实施。

4）评估软件系统是否满足所确定的功能和性能要求基线。

注意这有时称为功能配置审核 (FCA)，它确保产品配置满足指定的要求。

5）评估运行的软件系统元素是否符合批准的配置信息。

注意这有时称为物理配置审核 (PCA)。对于软件项，PCA 的标准可以包括是否根据软件许可或协议在指定系统上安装指定的配置项。

6）记录CM审计结果及处置行动项目。

6.1 目的

信息管理过程的目的是向指定的利益相关者生成、获取、确认、转换、保留、检索、传播和处理信息。

信息管理计划、执行和控制向指定的利益相关者提供明确、完整、可验证、一致、可修改、可追踪和可呈现的信息。信息包括技术、项目、组织、协议和用户信息。信息源自组织、系统、流程或项目的数据记录。

管理信息具有这些平等特征：明确、完整、可验证、一致、可修改、可注释、可追踪、可呈现。

6.2 结果

成功实施信息管理流程的结果是：

a)需要管理的不可识别信息。

b)定义信息表示。

c)信息的获取、开发、转换、存储、验证、呈现和处理。

• 4. 确定信息的状态。
• 5. 信息可供指定的利益相关者获取。

6.3 活动和任务

项目应根据组织有关信息管理流程的适用政策和程序实施以下活动和任务。

注（文 ISO/IEC/IEEE15289 总结了生命周期过程信息项内容 ²²的要求档）并提供有关其开发的指导。

a)准备信息管理。此活动包括以下任务：

1）定义信息管理策略。

注意：关于同一主题的信息可以在生命周期的不同阶段针对不同的受众以不同的方式开发。

• 2. 定义要管理的信息项目。

注意这包括在软件生命周期内管理的信息，以及可能在规定期限后维护的信息。这是根据组织政策、协议或法律完成的。

3）指定信息管理的权限和职责。

注意应考虑信息和数据立法、安全和隐私，例如所有权、协议限制、数据访问权和数据所有权 ²³、知识产权和专利。当存在限制或约束时，信息将予以相应识别。了解此类信息的工作人员将被告知他们的义务和责任。

4)定义信息项的内容、格式和结构。

注：信息有多种形式（如视听、文本、图形、数字）和媒介（如电子、印刷、磁性、光学）产生和终止。组织约束（如基础设施、组织间通信和分布式项目运作）均被考虑在内。根据政策、协议和法律约束使用相关信息项目标准和惯例。

5)定义信息维护行动。

注：信息维护包括对存储信息的状态进行审查，以确保其完整性、有效性和可用性。它还包括根据需要复制或转换到替代介质的任何需求，或者在技术变化时保留基础结构，以便可以读取存档介质或将存档介质迁移到其他技术。

b)执行信息管理。此活动包括以下任务：

• 1. 获取、开发或转换已识别的信息项目。

注：这包括从适当的来源（例如，来自任何生命周期过程）收集数据、信息或信息项，以及编写、说明或将其转换为利益相关者可用的信息。它包括根据信息标准审查、验证和编辑信息。

2）维护信息项及其存储记录，并记录信息的状态。

注：信息项根据其完整性、安全性和隐私性要求进行维护。信息项的状态将得到维护（例如，版本描述、发行日期或有效日期、分发记录、安全分类）。清晰的信息以易于检索的方式存储和保留。

注：用于转换信息的源数据和工具以及生成的文档根据配置管理流程置于配置控制之下。ISO/IEC/IEEE26531 提供了对生命周期信息和文档有用的内容管理系统的要求。

3）发布、分发或向指定的利益相关者提供信息和信息项目的访问权限。

注：根据商定的时间表或规定的情况的要求，以适当的形式向指定的利益相关者提供信息。信息项目包括用于认证、认可、许可或评估的文件（根据需要）。

4）归档指定信息。

注：归档是根据审计、知识保留和项目结束的目的进行的。信息的媒体、位置和保护是根据指定的存储和检索期限以及组织政策、协议和法律来选择的。已做出安排，以便在项目结束后保留必要的信息项目。

• 5. 处理不需要的、无效的或未经验证的信息。

注意这是根据组织政策以及安全和隐私要求完成的。

7.1 目的

测量流程的目的是收集、分析和报告客观数据和信息，以支持有效管理并展示产品、服务和流程的质量。

注：这些措施具有这些平等特征： 可验证、有意义、可操作、及时和具有成本效益。

7.2 结果

成功实施测量过程的结果是：

a)确定信息需求。

b)根据信息需求，确定或制定一套适当的措施。

c)收集、验证和存储所需数据。

d)分析数据并解释结果。

e)信息项提供支持决策的客观信息。

7.3 活动和任务

项目应根据组织关于测量过程的适用政策和程序实施以下活动和任务。

注：本文 ISO/IEC15939 提供了一套更详细的测量活动和任务，与件中的活动和任务。

注：ISO9001:2015规定了质量管理体系对测量和监控的要求。

a)准备测量。此活动包括以下任务：

1）定义测量策略。

2）描述与测量相关的组织特征，如业务和技术目标。

3） 识别信息需求并确定其优先顺序。

注意信息需求基于组织的业务目标、项目目标、已识别的风险和与项目决策相关的其他事项。测量可以与项目、流程、产品或决策相关。

4）选择并指定满足信息需求的措施。

注：所定义的措施是可验证且具有成本效益的。

• 5. 定义数据收集、分析、访问和报告程序。

6）定义评价信息项和测量过程的标准。

• 7. 识别并规划所需的支持系统或服务。

b)进行测量。此活动包括以下任务：

1）将数据生成、收集、分析和报告的手动或自动化程序集成到相关流程。

注意此任务可能涉及对其他生命周期流程的变更影响，以实现程序集成。

2）收集、存储和验证数据。

3）分析数据并开发信息项目。

4)记录结果并告知测量用户。

注：测量分析结果应及时、可用的方式报告给相关利益相关方，以支持决策制定并协助采取纠正措施、风险管理和改进措施。结果应报告给决策者。

过程参与者、技术和管理评审参与者、以及产品和过程改进过程 ²⁴业主。

8.1 目的

质量保证过程的目的是帮助确保组织的质量管理过程有效地应用于项目。

质量保证的重点是确保质量要求得到满足。对项目生命周期流程和输出进行主动分析，以确保生产的产品符合所需的质量，并且遵循组织和项目的政策和程序。

8.2 结果

成功实施质量保证流程的结果是：

• 1. 定义并实施项目质量保证程序。
• 2. 定义质量保证评估的标准和方法。
• 3. 对项目的产品、 服务和过程进行评估，符合质量管理政策、程序和要求。
• 4. 向相关利益相关者提供评估结果。
• 5. 事件已解决。
• 6. 优先处理问题

注：结果 a) 至 d) 与质量管理过程活动和任务的结果一致。

8.3 活动和任务

项目应根据组织有关质量保证流程的适用政策和程序实施以下活动和任务。

注：IEEEStd730‑2014， 软件质量保证流程，提供了额外的细节。

a)为质量保证做好准备。此活动包括以下任务：

1）定义质量保证策略。该策略与组织质量管理政策和目标一致，并包括：

我） 将质量保证资源应用于对所交付产品和服务的质量影响最大的流程和任务的优先级；

二） 明确角色、职责、责任和权限；

三） 过程、产品和服务的评价标准 ²⁵和方法，包括产品或服务验收标准；

四） 适合每个供应商（包括分包商）的活动；

五） 针对产品或服务所需的验证、确认、监控、测量、评审、检查、审计和测试活动；以及

6. 问题解决以及流程和产品改进活动。

注：在软件项目中， 对产品质量有重大影响的活动和任务包括就新的和变更的需求达成一致、进行同行评审和单元测试、分析问题报告和用户反馈；验证项目里程碑评审时分配的纠正措施的完成情况，以及对缺陷的根本原因 ²⁶分析。

2）建立质量保证与其他生命周期过程的独立性。

注：质量保证资源通常由不同的组织分配， 以独立于项目管理。

b)执行产品或服务评估。此活动包括以下任务：

1）评估产品和服务是否符合既定的标准、合同、规范和规章制度。

注：此任务包括验证产品或服务验收标准是否反映在验证和确认活动中。 派生的系统/软件质量要求通常与需求定义过程中的质量特性相关。 ISO/IEC25010 和 ISO/IEC25030 提供了有关系统/软件质量特性的附加信息。

2） 监控生命周期过程输出的验证和确认，以确定是否符合指定的要求。

c)执行流程评估。此活动包括以下任务：

1）评估项目生命周期流程的一致性。

2）评估支持或自动化一致性过程的工具和环境。

3）评估供应商流程是否符合流程要求。

注：请考虑诸如协作软件开发环境、要求供应商提供的流程措施或要求供应商使用的风险流程等项目。这包括对整个供应链中流程实施的监督审查。

d)管理 QA 记录和报告。此活动包括以下任务：

1）创建与质量保证活动相关的记录和报告。

注意使用信息管理流程根据组织、法规和项目要求创建记录和报告。

2）维护、存储和分发记录和报告。

3）识别与产品、服务和流程评估相关的事件和问题。

注：这包括吸取经验教训。确定解决问题的责任。

e)处理事件和问题。此项活动包括以下任务：

注：在质量管理术语中，问题通常被描述为“不符合项”，如果遗留如果不加以处理，它们可能会导致项目无法满足要求。

注：有关问题类别和优先级分类的更多信息和示例，请参阅 ISO/IECTS24748‑1:2016，附件C。

1）记录、分析和分类事件。

• 2. 识别与已知错误或问题相关的选定事件。

3）记录、分析和分类问题。

注意分析结果包括潜在的治疗方案。

4）找出问题的根本原因并尽可能处理问题。

5）确定问题处理的优先次序（问题解决）并跟踪纠正措施。

注：实施是在项目评估和控制过程启动后在技术过程中完成的。组织中用于问题升级的程序可以帮助集中资源解决滞后的问题。

6）分析事件和问题的趋势。

7）确定流程和产品的改进措施，以防止将来发生事故和问题。

注意风险管理流程用于处理风险和机遇。生命周期模型管理流程用于改进组织的流程。

8）向指定的利益相关者通报事件和问题的状态。

• 9. 跟踪事件和问题直至解决。