CMMI项目管理实践(txt+pdf+epub+mobi电子书下载)

作者：刘文红,马贤颖,董锐,张敏,吴欣,张光迎

出版社：清华大学出版社

格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT

CMMI项目管理实践试读：

随着软件产业的迅猛发展，项目过程管理不善的问题日益突出，人们逐渐意识到产品质量主要取决于产品研制过程的质量，并将焦点由技术转移到管理。20世纪90年代，美国卡内基梅隆大学软件工程研究所推出软件能力成熟度模型CMM，后来，CMMI逐步取代CMM，成为软件过程框架的工业标准。该模型描述了从混乱的、不成熟的软件过程向成熟的、有纪律的软件过程改进的一条途径，然而，它只要求“做什么”，并不明确“怎么做”，对于推进实施来讲还需要一个理解和本地化的过程。

本书紧扣CMMI二级的过程要求，结合国内软件研制现状，设计了一套可以满足配置管理（CM）、测量与分析（MA）、项目监控（PMC）、项目策划（PP）、过程和产品质量保证（PPQA）、需求管理（ReqM）和供方协议管理（SAM）7个过程域通用目标和专用目标的实践细则，并给出过程记录的参考模板，对于加快CMMI在软件研制单位推广、实施，指导软件研制单位进行基于CMMI的软件质量管理体系建设，具有较好的借鉴作用，可作为推广应用CMMI的重要参考资料。

本书由刘文红确定研究内容和整体结构，并负责全书的审稿。本书共分为三大部分：第1章～第3章为第一部分，主要介绍CMMI基础知识、CMMI实施方法及实施总则；第4章～第11章为第二部分，主要结合CMMI的七个过程域，分别介绍各个过程的实施指南，通过大量过程记录参考模板，讲述“怎么做”；第12章为第三部分，主要介绍作者单位研发的软件过程管理工具SPM。本书第1章、第2章、第3章、第4章由马贤颖编写，第5章、第6章、第7章由刘文红编写，第8章、第10章由董锐编写，第9章由张敏编写，第11章由张光迎编写，第12章由吴欣编写。杜会森、尹平、陈青、闫国英、张卫祥、魏波、张慧颖、王佳等人参加了CMMI七个过程域部分内容的编写，窦朝晖、姜兴伟、徐洋等参与了部分内容的录入与校对工作。

本书是作者多年从事CMMI质量体系建设的实践经验总结，实用性和指导性较强，可供从事软件项目管理和过程改进的人员参考，也可供进行CMMI质量管理体系建设的单位和相关人员学习。本书同样适合一般开发人员、测试人员、配置管理人员、质量保证人员以及过程改进实践人员参考。

在本书出版之际，我们要衷心感谢在编写过程中曾给我们大力支持和帮助的赵辉、谈利群、杨宝明、张为民等同志，同时也感谢清华大学出版社的大力支持。本书的编写参考了大量的文献，我们对所有这些文献作者表示真诚的谢意。

由于水平有限，书中难免有疏漏和不妥之处，敬请读者批评指正。第1章　绪论1.1　CMM

在当前以计算机为核心的信息社会，各行各业都需要大量的计算机软件支撑，计算机软件的品种、数量、规模、功能不断扩展，对软件质量、成本和开发时间的要求也越来越高。软件的质量、成本、进度是软件项目的三大目标，它们之间相互联系、相互制约（其关系如图1-1所示），如何处理好这三者的关系，将直接影响软件研制“又好又快”目标的实现。图1-1　软件开发三大目标

一些公开的数据表明，软件质量达不到要求、成本超出预算、进度超出预期的情况屡见不鲜。1968年，北大西洋公约组织（NATO）召开计算机科学会议，首次提出“软件工程”的概念，用现代工程的概念、原理、技术和方法进行计算机软件的开发、管理、维护和更新，使用正确的工程方法开发出成本低、可靠性好并能在机器上高效运行的软件，从而解决或者缓解软件危机。

软件工程包括三个要素：方法、工具和过程，如图1-2所示。软件工程方法为软件开发提供了“如何做”的技术，软件工具为软件工程方法提供了自动的或半自动的软件支撑环境，软件工程过程则是将软件工程的方法和工具综合起来达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、软件开发各个阶段完成的里程碑等。简单来说，过程就是为实现某一特定目标而采取的一系列步骤，即谁（Who），在什么时间（When），做什么（What），如何达到目标（How）。软件过程应当是科学的、合理的，否则必将影响软件产品的质量。过程与产品存在某种因果关系，只有好的过程才能得到好的产品，差的过程只能得到差的产品。图1-2　软件工程三要素

随着软件工程的深入开展，软件过程管理不善的问题日益突出，项目管理成为影响软件开发质量的重要因素。于是，针对软件过程管理与改进，提出了各种各样的方案。1986年11月，美国卡内基·梅隆大学软件工程研究所（CMU/SEI）着手开发改进软件过程的软件过程成熟度框架，并于1991年推出了软件能力成熟度模型CMM1.0版。

CMM指能力成熟度模型（Capacity Maturity Model），是软件工程管理的一部分。软件过程能力的成熟度是指一个软件过程得到明确的定义、管理、测量、控制的有效程度。CMM提供一个软件过程改进的框架，为软件过程改进奠定了循序渐进的基础。这个框架与软件生存周期无关，也与所采用的技术无关。该框架用5个不断进化的等级表示：（1）等级1：初始级，是混沌的过程；（2）等级2：可重复级，是经过训练、有纪律的软件过程；（3）等级3：已定义级，是标准一致的软件过程；（4）等级4：已管理级，是可预测的软件过程；（5）等级5：优化级，是能持续改进的软件过程。

CMM将软件开发看成一组过程，并根据软件过程管理和统计质量管理的理论对软件开发进行过程管理，使其工程化、标准化，使组织能够更好地实现商业目标。1.2　CMMI1.2.1　CMMI提出背景

设计CMM是为了指导软件组织，通过确定当前过程的成熟度和识别对软件质量和过程改进至关重要的问题，进行过程改进。自从CMM发布以来，SEI逐渐开发了多种CMM模型，包括系统工程（SE-CMM）、软件工程（SW-CMM）、软件采办（SA-CMM）、人力资源管理（P-CMM）、集成化产品和过程开发（IPPD-CMM）等。虽然这些模型对许多组织是有用的，有助于改善组织过程，以构造更好的产品，提高质量，降低成本，但是在跨越不同组织、学科、单位或文化的环境下，组织内存在的不同过程组可能会选用不同的、有时甚至是相互冲突的过程改进模型，这就失去了过程改进的意义。因此，美国国防部提出了能力成熟度模型集成（CMMI）的设想，即把现有模型和即将开发的模型全部集成到一个框架中去。

目前CMMI集成了三种源模型：软件能力成熟度模型（SW-CMM V2C）；EIA临时标准731，系统过程能力模型（SECM）；集成化产品开发能力成熟度模型（IPD-CMM）V0.98。CMMI并不是简单地把现有各个学科的能力成熟度模型放在一起，而是针对过程模型繁多、工程环境复杂、交叉学科、并行工程等问题构造的一个能容纳多学科的框架。CMMI主要通过消除不一致性、减少重复、增加透明度和可理解性、提供公共术语、提供一致的风格、建立统一的构造规则、维护公共构件、实现尽量好的可继承性降低过程改进的成本。通过集成，在所有的过程域中引入统一的行为方式，消除模型之间的不一致，能够高效地进行过程评估和改进。

1997年CMU/SEI发布了CMM 2.0，但该版本很快就被终止。因为此时CMU/SEI的主要精力已投入软件能力成熟度模型集成CMMI（Capability Maturity Model Integration）的研究，此后CMU/SEI用CMMI逐步取代CMM。CMMI目前已发展到1.3版本，以前用于系统工程和软件的CMMI-SE/SW，现在改成CMMI-DEV（CMMI for Dvelopement），意思是用于开发的CMMI，成为国际上流行的软件过程标准和软件组织成熟度等级认证标准。1.2.2　CMMI表示方法

CMMI模型的表示方法有两种：阶段式表示和连续式表示，其实质完全相同。在CMM源模型中，SW-CMM是阶段式表示，SECM是连续式表示，IPD-CMM是混合模型，组合了阶段式表示和连续式表示的特点。之所以提供两种不同的表示方法，是为了加快用户到CMMI的迁移速度，但是CMMI的最终方向还是使用统一的表示方法。

阶段式表示和连续式表示使用的组件都是过程域、共用目标、共用实践、专用目标、专用实践、子实践、典型工作产品、子产品、注释等，两者在内容结构上是相同的。连续式模型在改善次序上没有专门的指导，一个组织的不同过程域可能具有不同的能力等级，其典型代表是EIA/IS 731；而阶段式模型为组织级改善提供了过程全面改进的途径，其典型代表是软件CMM。阶段表示形式采用成熟度等级，包括从1级到5级共5个成熟度等级；连续表现形式采用能力等级，包括从0级到5级共6个能力等级。1．CMMI阶段式表示方法

CMMI将软件过程改进具体化，给出了软件过程改进的途径，即从1级至5级，逐级进行软件过程改进。成熟度等级是一个已定义的、组织过程改进的进化台阶。每个成熟度等级表示组织过程的一个重要部分已经成熟，并为它进入下一个成熟度等级做好准备。每一等级构成了前进中过程改进基础的一个层次，它们都是实现下一个成熟度等级的基础。软件研制能力成熟度模型共有5个成熟度等级，从1级到5级软件能力成熟度逐步提高，它们奠定了持续过程改进的基础，如图1-3所示。图1-3　软件研制能力成熟度5个等级

1）成熟度等级1——初始级

软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的能力和勤奋。

2）成熟度等级2——已管理级

组织的项目已确保其过程按照方针进行策划并得到执行，必要的过程纪律已经就位，工作产品的状态和服务的交付在规定的时间点对管理者是可见的。在成熟度等级2，组织的项目已确保其过程按照方针进行策划并得到执行。成熟度等级2反映的过程纪律有助于确保在有压力的情况下保持现有的实践。在这些实践都到位的情况下，项目都能按照其文档化的计划进行实施和管理。在成熟度等级2，工作产品的状态和服务的交付在规定的时间点（例如，在主要里程碑和主要任务完成时）对管理者是可见的，工作产品和服务满足其规定的过程说明、标准和规程。

3）成熟度等级3——已定义级

组织的标准过程集被建立，并能够被不断改进。这些标准被用于建立组织范围内的一致性。所有项目均按照裁剪指南裁剪组织的标准过程集，以建立项目已定义的过程。在成熟度等级3，过程已经得到了很好的定义和理解，并用标准、规程、工具和方法进行了描述。作为成熟度等级3的基础，组织的标准过程集已经建立，并随着时间推移而不断改进。这些标准过程用于建立整个组织的一致性。

成熟度等级2和成熟度等级3的关键区别是标准、过程说明和规程的适用范围。在成熟度等级2，这些标准、过程说明和规程在过程的各个特定实例（例如，某个具体项目）之间可以有很大差别。在成熟度等级3，一个项目的标准、过程说明和规程都是为了适合具体项目或组织的情况而从组织的标准过程集中剪裁出来的，因此，除了剪裁指南所允许的差别之外，这些标准、过程说明和规程都是一致的。另一个关键区别是：在成熟度等级3，过程一般描述得比成熟度等级2更加严格。一个已定义过程明确地阐述了其目的、输入、入口准则、活动、角色、测量、验证步骤、输出和出口准则。在成熟度等级3，通过对过程活动的相互关系、过程的详细测量值、过程的工作产品和服务的理解，使过程都得到更加积极主动的管理。在成熟度等级3，组织应使其成熟度等级2的过程域得到进一步的成熟。为了达到成熟度等级3，应使用在成熟度等级2中没有阐述的、与共用目标3有关的共用实践。

4）成熟度等级4——定量管理级

组织和项目为质量和过程绩效建立了定量目标，并将其用作管理过程的准则。在成熟度等级4，这些定量目标是根据顾客、最终用户、组织和过程实现者的需要建立的。质量和过程绩效都按统计术语进行理解并在该过程生存周期间受到管理。

成熟度等级3和成熟度等级4之间的关键区别是过程绩效的可预测性。在成熟度等级4，过程绩效使用统计技术和其他定量技术加以控制，并且是可定量地预测的。在成熟度等级3，过程通常只是定性地可预测的。

5）成熟度等级5——优化级

通过增量式和创新式的过程和技术改进持续地改进过程绩效。在成熟度等级5，根据对过程中固有变异共因的定量理解，组织持续地改进它的过程。建立组织的定量过程改进目标，持续地修订过程改进目标以反映日益变化的业务目标，并将这些目标用作管理过程改进的准则。对照定量的过程改进目标，测量并评价已部署的过程改进的效果。无论是项目的已定义过程，还是组织的标准过程集，它们都是可测量的改进活动的对象。

成熟度等级4和成熟度等级5之间的关键区别是所涉及的过程变异类型。在成熟度等级4，组织关注过程变异的特殊原因，并提供结果的统计可预测性。虽然过程可以产生可预测的结果，但是，这些结果可能不足以实现已确定的目标。在成熟度等级5，组织关注过程变异的共因，并且改变过程（移动过程绩效的均值或者减少过程的固有变异）以改进过程绩效并实现已确定的定量过程改进目标。

1级不包含过程域，2级及2级以上每一等级包含一组过程域。CMMI阶段式表示的成熟度等级和过程域如表1-1所示。表1-1　CMMI阶段式表示的过程域2．CMMI连续式表示方法

连续式表示使用6个能力等级，根据相关关系按照过程域分类进行组织，并指定每个过程域中过程改进的能力等级。CMMI过程域分为四类：过程管理类、项目管理类、工程类和支持类。

CMMI连续式表示的过程域如表1-2所示。表1-2　CMMI连续式表示的过程域1.2.3　GJB5000A

CMMI是国际标准，GJB5000A—2008《军用软件研制能力成熟度模型》（简称GJB5000A）是针对军用软件研制将CMMI—DEV1.2进行本地化后的执行标准。众所周知，产品质量主要取决于产品研制过程的质量，军用软件产品亦是如此。为规范军用软件采购单位、军用软件研制单位按照软件工程方法的基本原则不断改进软件过程，GJB5000A—2003《军用软件能力成熟度模型》（简称GJB5000）应运而生，成为各军用软件研制单位执行和贯彻的标准。直至2008年，总装备部根据CMMI—DEV1.2，提出GJB5000A，代替了原有的GJB5000，成为新的执行标准。GJB5000A规定了军用软件研制能力成熟度的模型，并规定了软件研制和维护活动中的主要软件管理过程和工程过程的实践，其内容与CMMI—DEV1.2基本一致，所描述的军用软件研制能力成熟度模型采用分级表示法，按预先确定的过程域集定义组织的改进路径，并用成熟度等级进行表示。两者的对照关系如表1-3所示。表1-3　CMMI和GJB5000A的对照表1.3　CMMI过程域内部结构

CMMI二级及二级以上每一等级均包含一组过程域，每个过程域包含一组专用目标和共用目标。专用目标下包含一组专用实践，共用目标下包含一组共用实践，专用实践下又包含一组子实践和一组典型工作产品等，如图1-4所示。图1-4　CMMI过程域内部结构图

要完成一个项目通常需确定两方面的内容：一是工作内容，二是工作方式。专用目标和专用实践体现项目实施过程中的主要工作内容，即为完成一个项目，必须完成的在工程、管理和支持方面的最佳实践，各个过程域需具体分析。共用目标和共用实践则体现项目实施过程中的主要工作方式，目的在于保证当组织结构、人员等发生变化时，也能够持续地采用这些实践。制度化是软件过程改进的一个重要概念。CMMI的一个主要特点是在所有的过程域中引入统一的共用目标和共用实践，CMMI的共用目标有两个：制度化已管理过程和制度化已定义过程。制度化已管理过程包括10个共用实践，制度化已定义过程，包括2个共用实践。过程的能力必须不断提高，共用目标描述从已管理过程直至优化过程，其制度化程度逐渐提高的过程，共用实践描述有关制度化的活动。

下面以CMMI二级为例，说明对共用目标和共用实践的要求。1．GP 2.1　建立组织方针（1）存在有效的用于策划和执行配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理的组织方针；（2）存在有效的该方针实施证据。2．GP 2.2　策划过程（1）存在有效的配置管理计划、测量与分析计划、项目监控计划、项目策划计划、过程和产品质量保证计划、需求管理计划和供方协议管理计划；（2）各个计划应协调一致；（3）存在有效的配置管理计划、测量与分析计划、项目监控计划、项目策划计划、过程和产品质量保证计划、需求管理计划和供方协议管理计划的实施证据。3．GP 2.3　提供资源

配置管理过程、测量与分析过程、项目监控过程、项目策划过程、过程和产品质量保证过程、需求管理过程和供方协议管理过程得到实施，且未发现因资源不足导致问题的发生。4．GP 2.4　指派职责（1）指派了实施配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理的各类人员的职责；（2）存在有效的各类人员履行其职责的证据。5．GP 2.5　培训人员（1）存在有效的实施配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理相关人员岗位技能要求（如岗位技能矩阵）；（2）存在有效的相关人员接受培训的记录，如培训教材、签到表、免修申请及审批证明；（3）培训的有效性。6．GP 2.6　配置管理

配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理的工作产品置于合适等级的控制之下。7．GP 2.7　标识并吸纳利益相关方（1）标识了配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理活动的利益相关方，以及他们参加相关活动的安排；（2）存在有效的利益相关方参加配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理活动的记录。8．GP 2.8　监控过程（1）按照计划监督相应过程的活动；（2）控制项目的配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理过程，必要时采取纠正措施。9．GP 2.9　客观评估遵循程度（1）存在有效的依据标准和规程客观评价配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理过程、活动的记录；（2）存在有效的依据标准客观评价产品的记录；（3）确保不符合项得到处理。10．GP 2.10　与更高层管理者一起评审状态（1）存在有效的更高层管理者定期对配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理过程的活动、状态和结果进行评审的记录；（2）必要时，解决底层无法解决的问题的记录存在且有效。11．GP 3.1　建立已定义过程（1）存在有效的配置管理过程、测量与分析过程、项目监控过程、项目策划过程、过程和产品质量保证过程、需求管理过程和供方协议管理过程，以及裁剪指南和维护记录；（2）项目依据组织规定制订项目的配置管理过程、测量与分析过程、项目监控过程、项目策划过程、过程和产品质量保证过程、需求管理过程和供方协议管理过程。12．GP 3.2　收集改进信息（1）收集了配置管理过程、测量与分析过程、项目监控过程、项目策划过程、过程和产品质量保证过程、需求管理过程和供方协议管理过程的工作产品、测量项和改进建议，例如，各种活动所花费工作量、特定活动中引入和排除的缺陷以及经验教训等；（2）测量数据和改进建议纳入组织过程资产库。

专用目标和共用目标是必需部件，是组织为满足过程域必须实现的目标；专用实践和共用实践是期望部件，是组织为了实现必需的部件通常应实施什么，用于指导过程改进和评估；子实践、典型工作产品、共用实践详细说明、目标和实践的注释等是资料性部件，主要用于表达组织如何处理必需部件和期望部件的细节。在软件过程评估过程中，通常根据是否达到与每组预定过程域相关的专用目标和共用目标判定是否满足相应的成熟度等级。实现一个等级，必须实现该等级所包含的全部过程域；实现一个过程域，必须实现其所有的专用目标和共用目标；实现一个目标，要求实现目标下的全部实践。各实践总结了实现目标和不断过程改进的最关键的要点，其精神是必须要遵从的，但方式可能不同，如果按标准实施比较困难，也可以采用替代方法。第2章　CMMI实施指南

CMMI提供了一套从低到高即从过程模糊、过程可重复、过程可定义、过程可量化、过程持续改进等逐级改进的方法及模型。但是，CMMI只告诉我们该做什么，而没有告诉我们该如何做，对于推进实施来讲都还需要一个理解和本地化的过程，必须将CMMI的普遍原理与组织的具体实际相结合，产生一种实施组织过程改进的方法。CMMI 2级是建设CMMI过程能力的基础，按照过程持续运行、积累，逐渐达到3级已定义和4级量化管理要求，持续进行过程的分析改进，从而达到5级能力。图2-1描绘了2级的主要过程域活动及其与软件开发活动的关系。图2-1　CMMI2级过程域与开发过程的关系示意图

CMMI实施流程一般包括：CMMI实施准备、建立软件质量管理体系文件、体系试运行、项目评估及整改、体系正式运行五个阶段进行，如图2-2所示。组织要进行CMMI认证，应对现有组织机构进行调整，对体系编写人员、项目组成员等进行CMMI知识培训；组织应成立体系编写组，建立适合组织的软件质量管理体系文件；对项目人员进行体系文件知识培训，选择2～3个项目试运行；试运行结束后，组织专家进行评估，针对体系运行出现的问题，对体系文件进行修改；体系修改后，按照新版体系文件要求正式实施。图2-2　CMMI实施流程2.1　CMMI实施准备

按照CMMI要求实施软件过程管理首先应获得高层管理者的支持，然后还需进行以下准备，如图2-2所示。（1）制订CMMI实施计划，确定实施CMMI的等级、途径、人员和时间安排；（2）建立组织机构，一般需增设软件工程过程组（EPG）和质量保证组（QA）；（3）进行CMMI培训，在体系准备、建立、运行等各个阶段对各类相关人员进行培训；（4）提供资源保障，包括资金、人力资源、计算机软／硬件资源等。2.1.1　制订CMMI实施计划

实施CMMI是一个循序渐进的过程，首先应对组织当前发展状况和未来发展方向进行分析，制订一个长远的实施规划。（1）根据组织的规模、客户要求、商业目标等实际情况，明确实施CMMI的等级是CMMI2、CMMI3、CMMI4或CMMI5；（2）根据组织当前实施软件质量管理的情况，明确实施CMMI的途径是从CMMI2级开始按部就班实施，还是直接实施CMMI3级。如果组织实施ISO9000、ISO/IEC 12207等其他管理体系的效果较好，可直接实施CMMI3级，否则，建议从CMMI2级开始实施；（3）确定实施CMMI所需参与的人员，例如软件工程过程组成员、质量保证组成员、体系编写组成员、体系试运行项目组成员；（4）制订实施CMMI的进度计划。如果从CMMI2级开始实施，一般要经历几个阶段，如表2-1所示。表2-1　CMMI实施计划2.1.2　建立组织机构

根据CMMI的最佳实践，实施CMMI需要有软件工程过程组EPG、质量保证组QA、配置管理组、项目负责人、软件工程组、软件测试组等角色，组织应根据自身的特点和业务流程等建立适合组织自身的软件过程改进组织机构。一般情况下，组织结构中都有配置管理组、项目负责人、软件工程组、软件测试组等，只需要增设软件工程过程组EPG和质量保证组QA。

EPG成员应满足以下要求：（1）熟悉研发过程；（2）提倡软件过程改进；（3）在组织中有一定的权威性；（4）具有丰富的工程实践经验，对组织的业务背景知识十分了解。

QA成员应满足以下要求：（1）熟悉组织过程；（2）具有独立第三方检查的能力；（3）具有良好的沟通技巧。2.1.3　培训1．确定培训需求

培训贯穿于CMMI实施的各个阶段，各阶段培训需求如表2-2所示。表2-2　CMMI培训需求2．组织实施培训

确定培训需求后，应制订培训计划，根据计划实施培训。在培训计划中，一般应明确培训的时间／阶段、内容、目的、类别和形式等。培训类别分为外部培训和内部培训。外部培训主要包括推进CMMI的专题培训，例如，CMMI发展及意义、CMMI各过程域讲解；内部培训主要包括EPG或QA对过程实施相关人员进行的培训，培训的内容是根据CMMI制订的标准过程。培训的形式包括授课、讨论等。2.1.4　资源保障

这里的资源包括资金、人力资源、计算机软／硬件资源。

实施CMMI需要资金投入，花费多少取决于以下因素：（1）培训费、咨询费、评估费；（2）参与人员数量；（3）项目组成员为软件过程改进投入的精力；（4）开发CMMI支持系统所需时间和费用；（5）购买相关软／硬件资源所需的费用。

人力资源包括为实施CMMI投入的专职人员，如EPG、QA；参与项目中的人员，如项目负责人、开发人员、测试人员；对CMMI各过程域内容进行培训的专家；对组织CMMI实施过程进行评估的专家等。

计算机软／硬件资源包括：实施CMMI需购买的计算机硬件资源、CMMI支持系统、各种独立的软件过程改进工具，如需求管理工具、测试管理工具、配置管理工具和度量分析工具。大量的实践表明，CMMI的众多过程域的实施都要求有相应的工具提供资源保证。工具在软件过程改进的过程中具有非常重要的作用，例如，用于生成进度计划表的Project、用于配置管理的SVN、用于生成测量分析趋势图的Excel。2.2　建立软件质量管理体系文件

CMM/CMMI是模型，而非过程，只讲“做什么”，不讲“如何做”，实施时，必须以模型为指导，加以本地化，形成自己的过程，建立自己的体系文件，然后根据体系文件实施各个过程的管理。软件研制单位应组织体系编写组，建立基于CMMI的软件质量管理体系文件。体系文件的层次结构一般分为四层，如图2-3所示。图2-3　体系文件层次结构

第一层次是顶层方针，主要内容是规定软件质量管理体系的组织方针、机构及职责、体系结构、软件项目管理过程等总体要求，是软件质量管理体系中的纲领性文件。第二层次是过程文件，目的在于指导项目开发过程中的配置管理活动、测量与分析活动、项目监控活动、项目策划活动、过程和产品质量保证活动、需求管理活动和供方协议管理活动。第三层次是规程文件，定义各过程域中具体活动的准则和操作流程，用于规范过程活动。第四层次是模板类文件，定义各过程域中具体活动的工作产品模板，用于统一工作产品的格式与内容。

表2-3是一个体系文件层次结构示例。表2-3　体系文件层次结构示例2.3　体系试运行

体系试运行的目的是为了验证体系的合理性、可行性与适宜性。体系试运行前，首先要对参与项目的所有人员进行体系文件知识培训。然后，选择2～3个项目按照体系文件的要求，模拟整个生存周期的软件研制过程和控制过程。实施时要注意试运行的项目应能够覆盖各个过程域的各个分支，例如，需求变更、计划变更和向高层上报问题。2.4　项目评估及整改

项目评估一般包括以下几个步骤，如图2-4所示。图2-4　CMMI评估过程（1）成立评估专家组。评估组成员一般由4～7名熟悉CMMI标准、具有丰富软件工程管理经验的专家担任，在现场评价前需对评估组成员进行“CMMI入门”和“评价方法”培训。（2）被评估组织确定访谈对象。访谈对象应涵盖高层管理者、中层管理者代表、EPG成员、项目负责人、开发人员、测试人员、配置管理人员和质量保证人员等，原则上每个人只访谈一次，现场评价前必须确定。（3）制订评估计划。评估计划中包括：明确组织的应用领域，选定项目和评估参与人员；评估活动的日程表；现场评价所需资源；评价结束后需交付的工作产品；完成该计划所涉及的潜在风险及采取措施等。（4）现场访谈，文档检查。评估专家组到现场对相关人员进行访谈，并对软件工程文档进行检查，从文档的内容、格式、种类等方面评估软件工程过程是否符合CMMI标准和组织定义的软件质量体系文件的要求。（5）评价总结。评估专家组召开评价总结会，共同梳理问题清单，指出软件过程存在的问题。

EPG组对项目运行过程中需求管理、项目策划、监督与控制、配置管理、质量保证、测量分析、供方协议管理等方面的状况进行全面的诊断检查，针对发现的问题，可调研其他单位的实现情况，学习相关的经验和方法，制订改进措施。如果是体系本身存在问题，需组织体系编写组成员对体系文件进行修订完善；如果是项目存在问题，需对项目组成员进行相关知识的培训。2.5　体系正式运行

新版软件质量管理体系文件发布后，需对相关人员进行培训，然后按照体系文件要求正式实施CMMI。项目运行过程中，难免会发现体系的不完善因素，这时就需要修改、完善体系。另外，CMMI的等级划分也决定了软件过程的改进不是一蹴而就的，而是从1级到5级逐级进化，这就决定了体系的运行、评估及整改是一个循序渐进的过程。在CMMI实施过程中，应定期对体系运行情况进行评估，逐步、逐级完善体系，持续进行软件过程改进。第3章　软件过程管理实施总则3.1　概述

在对各过程域实施方法介绍前，先提出软件过程管理的实施总则。软件过程管理实施总则是实施CMMI的基础和纲领性要求，依据CMMI已管理级（ML2）的要求制订，阐述了实施需求管理过程、项目策划过程、项目监控过程、配置管理过程、过程和产品质量保证过程、测量与分析过程和供方协议管理过程的组织方针，明确所必须的各组织机构的关系及职责等。3.2　组织方针

组织方针包括共同方针和各过程域相关的组织方针。1．共同方针（1）按照成熟度等级2（已管理级）的要求，对软件项目生存周期全过程实施配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理；（2）组织应为各个过程提供充足的资源和必要的培训；（3）高层管理者应定期和事件驱动地评审各个软件过程的活动、状态和结果，解决下层组织无法解决的问题，并提出组织不断提高软件研制能力的长远目标。2．需求管理（ReqM）组织方针（1）根据软件开发计划制订和维护需求管理计划；（2）管理软件需求和控制软件需求的变更；（3）维护需求的双向可追溯性，标识软件需求与项目计划及工作产品的不一致性，启动纠正措施。3．项目策划（PP）组织方针（1）在项目范围估计和生存周期模型定义的基础上进行项目规模和工作量估计；（2）在工作量估计的基础上制订项目进度、标识项目风险、制订数据管理计划、提出资源需求和获取计划、策划项目所需的知识和技能、制订相关方参与计划、编写软件开发计划；（3）评审软件开发计划，获得对计划的承诺，并协调和落实软件开发计划；（4）当规模、工作量和进度等与项目实际执行情况存在显著偏差时，应对项目规模、工作量和进度等进行维护，以便使计划得到有效实施。4．项目监控（PMC）组织方针（1）根据软件开发计划制订和维护项目监控计划，并按计划实施软件项目的监控；（2）准确、及时地分析和报告进度、工作量、资源、人员技能、承诺、项目风险、数据管理、相关方参与的实际情况，适时地开展月／阶段跟踪和里程碑评审；（3）当实际情况偏离软件开发计划时，应采取纠正措施，直至问题得到解决。5．配置管理（CM）组织方针（1）成立具有管理基线权限的软件配置控制委员会；建立适合于分级控制的配置管理机构，包括配置控制委员会、配置管理组；（2）建立配置管理库和相关的管理规则；（3）标识需交付的软件产品、必须的内部工作产品、软件开发工具和环境资源以及需采购的产品等，并实施合适等级控制的配置管理；（4）对处于配置管理之下的工作产品的更改进行跟踪和控制；（5）记录配置状态，进行配置审核，建立和维护基线的完整性。6．过程和产品质量保证（PPQA）组织方针（1）依照软件开发计划和适用的过程说明、标准与规程制订质量保证计划，并按照该计划进行过程和产品评价；（2）客观地跟踪和交流不符合项，确保不符合项得到解决；（3）项目质量保证组应独立于项目组，并有向不同层次的管理者，包括最高管理者报告问题的权利。7．测量与分析（MA）组织方针（1）建立和维护测量分析的目标，使它们与已标识的信息需要和组织目标相一致；（2）规定测量项和分析技术，以及数据收集、数据存储、报告和反馈的机制；（3）执行数据的采集、存储、分析和报告；（4）提供客观的结果，为决策提供依据；（5）跟踪测量分析结果与测量目标的一致性，维护测量目标与测量项。8．供方协议管理（SAM）组织方针（1）根据软件开发计划制订和维护供方协议管理计划；（2）与选择的供方签署正式协议，并执行协议所规定的活动；（3）对供方过程进行监督；（4）对供方工作产品进行评价；（5）对供方产品进行验收和移交。3.3　组织机构和职责

为满足GJB 5000A二级的要求，需建立相应的组织机构。这些机构相互协调工作实现软件研制项目管理和过程的持续改进。

组织机构的建立没有固定的模式，各软件研制单位应按照自身的特点和业务流程等建立合理的组织机构，明确各组织机构的职责，形成自己的制度和规范，进而提高管理水平，长久、持续地实施过程改进。

本章给出一个软件质量管理与过程改进组织机构的示例，如图3-1所示。该组织机构包括：软件工程管理委员会、软件工程过程组（EPG）、组织级质量保证组、组织级配置控制委员会、组织级配置管理组、主管单位、责任单位、需求提供者、项目负责人、软件工程组、软件测试组、项目质量保证组、项目配置控制委员会和项目配置管理组。图3-1　软件质量管理与过程改进组织关系示例

组织机构中各部门职责如下：1．软件工程管理委员会职责（1）负责提出组织的软件质量管理目标，组织制订软件过程持续改进的长远规划；（2）监督软件工程过程能力持续改进与提高；（3）最高管理者召开验证会，评审组织层面的过程活动、状态和结果，解决下层组织不能解决的管理和技术问题。2．软件工程过程组（EPG）职责（1）策划、跟踪、协调组织软件过程改进活动；（2）负责软件质量管理体系文件的建立与维护；（3）培训、诊断和咨询软件质量管理体系；（4）选择、评价新的过程、规程、方法和工具；（5）审核项目对过程活动所作的剪裁和修改；（6）审核和批准项目自定义生命周期模型；（7）建立和维护组织测量目标，收集、分析软件项目的各类质量数据。3．组织级质量保证组（IQA）职责（1）咨询与指导项目实施过程中的质量管理工作；（2）负责对本单位软件质量人员的培训；（3）处理项目质量保证组不能解决的问题；（4）审核项目的过程和产品质量保证活动；（5）向软件工程管理委员会汇报各项目对软件过程的改进建议。4．组织级配置控制委员会职责（1）负责审核以下内容，并批准审核意见：

●交付的软件产品定义申请；

●软件产品库的入库、出库申请；

●软件配置管理有关的标准、规程和约定。（2）审批软件需求变更。5．组织级配置管理组（CMG）职责（1）建立和维护软件产品库；（2）负责软件产品库的出入库管理；（3）负责拟制软件产品库管理报告。6．主管单位职责（1）下达软件研制任务通知；（2）落实并实施软件工程管理委员会制订的软件过程改进方针；（3）接收软件需求及软件需求变更，组织项目的对外承诺和任务下达，适时监控项目进展；（4）组织项目的评审、验收、移交与归档工作；（5）制订并落实组织级培训计划，检查培训效果；（6）组织收集、分析软件项目的各类质量数据，建立并维护过程资产库；（7）审阅项目里程碑报告。7．责任单位职责（1）接收主管单位下达的软件研制任务通知；（2）保障并监督软件项目的人员、设施和设备等资源的合理配置；（3）审阅项目月／阶段报告和里程碑分析报告，参加项目相关计划评审；（4）协调软件项目与组织级各职能机构的关系，处理项目组无法解决的不符合项问题；（5）责任单位领导组织召开验证会，评审项目层面的过程活动、状态和结果，解决项目研制过程中需要处理的问题。8．需求提供者职责

负责项目的系统分析与设计、协调用户需求等工作，主要职责是：（1）进行软件系统分析与设计，编写软件研制任务书；（2）解释软件源需求的确切含义；（3）确认软件的隐含需求；（4）维护软件研制任务要求；（5）参加软件需求变更评审。9．项目负责人职责

接受主管单位和／或责任单位的领导，其主要职责如下：（1）负责软件需求管理，建立分配基线；（2）组织项目估计、策划以及对相关计划的评审；（3）监控软件开发过程，进行项目月／阶段／里程碑跟踪与分析；（4）对质量数据进行测量与分析并评估测量分析的效果；（5）负责组织软件项目的内部评审；（6）合理配置软件项目内的各种资源；（7）组织评估变更影响及实施更动；（8）负责组织解决项目监控、过程和产品质量评价、测试和评审过程中发现的问题和不符合项；（9）协调软件工程组、软件测试组、项目质量保证组和项目配置管理组之间的各种关系；（10）协调软件项目外各利益相关方的关系；（11）协助主管单位进行项目的评审和软件产品的验收与交付等。10．软件工程组职责

负责软件项目的具体研制工作，主要职责如下：（1）依据分配需求进行软件需求分析；（2）依据分配需求和软件需求开展软件设计、编码、测试以及各类软件技术文档编写；（3）依据软件质量管理体系提供过程跟踪和质量控制所需的信息；（4）协助项目负责人完成项目估计和策划工作，参加项目相关计划评审。11．软件测试组职责

负责软件项目的测试工作，主要职责如下：（1）按照要求完成软件项目的配置项测试和系统测试（软件测试组和软件工程组的人员组成，可以独立，也可以交叉，以不测试自己开发的软件代码为原则），并编写相应的文档；（2）参加软件开发过程的评审；（3）协助软件项目负责人完成项目估计与策划，参加项目相关计划评审；（4）协助完成软件项目的验收和移交工作。12．项目质量保证组职责

负责软件项目各类过程与产品的质量评价，主要职责如下：（1）策划项目的PPQA活动，制订并维护软件质量保证计划；（2）依据软件质量保证计划实施过程和产品评价，记录质量信息；（3）参加软件项目的评审；（4）跟踪软件项目的不符合项，直至其关闭；（5）定期或在项目结束时完成质量保证报告；（6）提出软件过程改进的建议；（7）向更高层管理者直至最高管理者报告质量信息。13．项目配置控制委员会职责

项目配置控制委员会主要职责如下：（1）评审软件项目配置管理计划；（2）评审受控库基线设置及变更；（3）审批受控库软件配置管理项的入库、出库申请；（4）组织配置审核，并编写配置管理审核报告。14．项目配置管理组职责

负责软件开发过程中受控库的配置管理工作，主要职责如下：（1）策划软件项目的配置管理活动，编制并维护软件配置管理计划，参加项目相关计划评审；（2）标识置于配置管理之下的配置管理项；（3）负责建立并维护受控库，按计划实施配置管理；（4）负责审核受控库中的软件配置管理项。3.4　过程控制要求

软件研制能力达到GJB 5000A二级程度的软件研制单位在软件研制过程中应实施配置管理、测量与分析、项目监控、项目策划、过程和产品质量保证、需求管理和供方协议管理（如需要）等过程，以达到通过过程控制提高软件产品质量的目的。其中，供方协议管理是GJB 5000A二级7个过程域中唯一可以裁剪的过程域，其裁剪与否取决于软件研制单位是否存在从供方获取产品的需求。各个过程域的过程管理可按照第4章至第11章的内容实施。第4章　需求管理4.1　概述

需求管理过程管理项目接收的或产生的所有需求，包括技术需求和非技术需求，以及组织强加于项目的需求。特别是，当实施需求开发过程域时，它的过程将产生产品和产品部件需求，这些需求也要受需求管理过程的管理。在这些过程域中，凡用到“产品”和“产品部件”处，其含义也包括服务及其组成部分。需求管理的目的是管理项目的产品和产品部件的需求，并标识这些需求与项目计划和工作产品之间的不一致性。

需求管理过程主要分为制订需求管理计划、需求理解与承诺、管理需求更改、维护需求的双向可追溯性、标识项目工作与需求之间的不一致5个活动，需求管理活动贯穿于软件研制整个生存周期。

制订需求管理计划是指提出需求管理活动的实施计划，说明要进行的需求管理活动的内容、时间、人员及利益相关方；需求理解与承诺是指通过需求评审等形式在项目组和相关人员之间获得对需求的一致理解，并对需求作出承诺；管理需求更改的目的是合理有效地控制并执行需求更改；维护需求的双向可追溯性是利用需求跟踪矩阵，保证每个需求得到实现，以及辅助进行影响分析，确保需求与工作产品之间的一致性；标识项目工作与需求之间的不一致是在发现需求与项目计划和工作产品不一致时，记录不一致的具体内容，分析产生不一致的原因，并制订相应的纠正措施。

需求管理流程如图4-1所示。图4-1　需求管理活动关系图4.2　制订需求管理计划

进行需求管理，首先应根据进度计划制订需求管理计划，在计划中明确需求管理的人员、资源，制订需求理解与承诺、需求双向追踪、需求变更等活动的利益相关方参与计划。1．入口准则及输入

制订需求管理计划的前提条件是获得软件研制任务要求（包括：软件研制任务书、研制合同、技术协议、使用要求等），并且主管单位已下达了软件研制任务通知。

软件研制任务要求的内容如下。软件研制任务要求1　范围1.1　标识写明本文档的：（1）已批准的标识号；（2）标题；（3）本文档适用的系统和／或CSCI。1.2　系统概述概述本文档所适用系统和／或CSCI的用途。1.3　文档概述概述本文档的用途和内容。2　引用文档按文档号、标题、编写单位（或作者）和出版日期等列出本文档引用的所有文件。3　术语和定义给出所有在本文档中出现的专用术语和缩略语的确切定义。4　总体研制要求提出软件系统的体系结构要求，明确待研制开发的软件配置项的名称和标识，说明软件系统的研制要求等。5　详细研制要求以软件配置项为单位分别提出研制要求。软件系统的集成要求可作为独立的一节进行描述。5.X　（软件配置项名称和项目唯一标识号）5.X.1　功能要求描述要开发的CSCI的功能要求。5.X.2　性能要求描述要开发的CSCI的性能要求。例如：数据收发和处理时延、双工／双机切换时间、软件重启动时间等要求。5.X.3　接口关系分小节描述待开发的CSCI的外部接口，接口连接的实体，接口的用途和连接方式。5.X.3.Y （接口名称和项目唯一标识号）从5.X.3.1节开始编号。分小节详细说明接口的需求以及接口间数据传递的要求，包括接口间的优先级别、通信协议和通信数据元素的定义（名称、单位、类型、格式、值域、分辨率等）信息。5.X.4　环境可分小节说明待开发软件的运行与支持环境。5.X.4.1　运行环境从硬件、软件和固件三方面阐明待开发的CSCI运行的设备和资源。例如：目标机的CPU、主频、存储器和系统软件的情况。5.X.4.2　支持环境从硬件、软件和固件三方面阐明待开发的CSCI研制开发使用的设备、工具和资源。5.X.5　工作模式分小节描述软件的工作模式（亦称任务剖面）。描述为完成规定任务，待开发的CSCI各工作阶段和工作模式的细节及安装、操作方面的要求。5.X.5.Y （工作模式名称）从5.X.5.1节开始编号。分小节详细说明各工作阶段和工作模式的进入／触发条件、初始状态、输入信息、信息处理过程、输出信息和过程结束的条件等内容。5.X.6　设计约束指明待开发软件系统和／或CSCI在设计时应考虑的约束条件。例如：研制方法、中断能力和中断处理时间、关键数据的保护和校核、冗余信息处理原则、偶发异常事件处理和设计余量。5.X.7　其他软件要求根据CSCI的情况，可分小节描述除功能要求、性能要求外的软件要求。例如安全性、可靠性、软件效率、人机工程、可测试性、可理解性、可维护性和可移植性方面的要求。一般情况下，应描述软件安全性和可靠性的要求。6　管理要求6.1　配置项关键等级说明待开发的各CSCI的软件关键等级。6.2　进度要求说明待开发的软件系统和／或CSCI的软件开发进度和质量控制节点的要求。6.3　质量保证要求说明待开发的软件系统和／或CSCI的质量保证方面的要求。例如标准规范的采用、人员培训、配置管理、外协管理等方面的要求。6.4　评审要求说明待开发的CSCI的各阶段的评审要求。6.5　测试要求说明软件研制单位应完成的测试级别，以及测试应达到的定性、定量要求。当软件需要进行第三方评测时，应说明支持第三方评测的相关要求。例如被测软件、测试环境、测试时间等相关要求。6.6　文档要求说明待开发的软件系统和／或CSCI开发过程中，应完成的文档资料和文档规范要求。7　验收与交付说明待开发的软件系统和／或CSCI的完成形式和交付内容，验收准则和验收测试的运行环境等。另外，还应说明软件承制方应提供的服务和内容（例如软件安装、检查和培训）。8　维护规定验收后出现问题的处理原则，说明待开发的软件系统和／或CSCI的纠错、适应、完善和预防性维护工作的要求。

软件研制任务通知中一般应明确项目责任单位、项目负责人、项目质量保证组、项目配置控制委员会、需求提供者和其他利益相关方，并说明任务来源、任务质量目标和要求、组织和技术接口关系等内容。2．主要活动

制订需求管理计划的主要活动如下：【活动1】确定合格的需求提供者，如用户、客户。该活动的目的是确定合格的需求提供者，以便获得有效的需求。需求提供者的主要职责是：（1）进行软件系统分析与设计，编写软件研制任务书；（2）解释软件源需求的确切含义；（3）确认软件的隐含需求；（4）维护软件研制任务要求；（5）在需求变更控制时，参加软件需求变更评审。【活动2】确定需求管理人员的职责。明确负责需求管理的人员及职责，标识与需求管理活动有关的利益相关方及其职责。【活动3】确定需求管理所需要的资源。需求管理人员根据需要，确定需求管理所需的软／硬件资源。【活动4】确定需求管理活动的时间节点、跟踪的工作产品以及参与需求管理活动的利益相关方。需求管理主要活动包括：（1）需求理解；（2）需求承诺；（3）建立需求跟踪矩阵和需求状态跟踪表；（4）在软件生存周期的各个阶段，例如需求分析阶段、软件设计与实现阶段、软件测试与验收阶段进行需求跟踪，建立双向跟踪矩阵、需求状态跟踪表，标识项目工作与需求之间的不一致项，并启动纠正措施；（5）在需求发生变更时，管理需求的更改。

利益相关方参与的主要活动如下：（1）解决对需求的共识问题；（2）评估需求变更的影响；（3）通报双向溯源性情况；（4）识别项目工作与需求之间的不一致。【活动5】将上述需求策划的内容文档化，形成需求管理计划，并对需求管理计划进行评审。3．出口准则及输出

制订需求管理计划完成的标志是已制订需求管理计划（可作为软件开发计划的一部分），并且需求管理计划通过评审。4.3　需求理解与承诺

需求理解与承诺是为了保证所有利益相关方在项目一开始就对需求建立一个共同的理解，并承诺以它作为公共的起点。项目组成员、需求提供者及其他利益相关方要一起对需求进行分析，以确保对该需求的含义达成共识，并形成达成一致的需求集；所有利益相关方需对当前达成一致的需求作出承诺。如果需求发生变更，所有利益相关方应重新对需求变更及其影响域进行分析，并对变更后的需求重新作出承诺。1．入口准则及输入

需求理解与承诺的前提条件是获得软件研制任务要求和软件研制任务通知，所必需的输入是软件研制任务要求。2．主要活动

需求理解与承诺的主要活动如下：【活动1】项目负责人接收需求。应从以下正式渠道或来源接收需求（或需求更改要求）：（1）经上级机关批复的软件研制任务书；（2）有效的软件研制合同、技术协议等；（3）有效的需求更改要求，如会议纪要。【活动2】获得对需求（或需求更改要求）的共同理解。项目负责人、需求管理人员、软件工程组与需求提供者进行充分的协商与沟通，对需求进行分析，确保对需求的含义达成共识，对需求的理解可用协调纪要等形式进行记录。【活动3】需求的评审。项目负责人组织软件工程组、软件测试组、项目配置管理组、项目质量保证组及其他利益相关方召开评审会，按照以下准则评审需求。（1）需求完备，描述清晰、无歧义；（2）各项需求之间相互一致，无矛盾；（3）具备完成项目的能力和资源，时间进度合理可接受；（4）技术性需求可实现可测试；（5）各项需求能够唯一标识和追溯。

参加会议人员达成一致认识后，形成评审意见表，以承诺软件研制任务要求中提出的全部要求。【活动4】形成达成一致的需求集，创建或修改需求跟踪矩阵（表格模板见表4-1、表4-2）和需求状态跟踪表（表格模板见表4-3）。表4-1　需求跟踪矩阵（正向）表4-2　需求跟踪矩阵（逆向）表4-3　需求状态跟踪表填表说明：（1）当阶段结束或工作产品发生变更时，对每项需求的状态进行更新跟踪；（2）需求描述，指软件研制任务要求中功能需求项和非功能需求项。状态说明：（1）已承诺，指该项需求已通过评审并经过用户确认及高层管理者审批；（2）已分析，指该项需求已反映在软件需求规格说明中并通过评审；（3）已设计，指针对该项需求已进行软件设计并通过评审；（4）已实现，指针对该项需求已进行代码编写并通过单元测试；（5）已验证，指针对该项需求已完成确认测试；（6）已完成，指针对该项需求已完成验收测试。【活动5】如果需求发生变更，则重复上述活动，重新进行需求理解与承诺。3．出口准则及输出

需求理解与承诺完成的标志是建立达成一致的需求集，且需求已获得相关人员的承诺。

试读结束[说明：试读内容隐藏了图片]

下载完整电子书