缺陷预防的目的是鉴别缺陷的原因并防止它们再出现。

　　缺陷预防包括分析过去间遇到的缺陷和采取特别措施以防止将来再出现此类缺陷。缺陷 可能曾在其它项目中和在当前项目的早期阶段或作业中已经鉴别出来。缺陷预防活动也是在 项目间传播经验教训的一种机制。

　　为了跟踪已遇到过的缺陷类型和识别出多半会再出现的缺陷，必须对趋势进行分析。基 于对项目定义软件过程和其实施方式（正如在集成软件管理 和软件产品工程关键过程区域中 所描述的）的理解，确定缺陷的根本原因和对于未来活动缺陷的推断。

　　项目和组织均采取预防缺陷再出现的特别措施。某些组织的措施可以像在过程更改管理 关键过程区域中所描述的那样处理。

目标

　　缺陷预防活动是有计划的。

　　缺陷的一般原因已经找出和标识。

　　缺陷的一般原因已按优先级排序和系统地消除。

技术改革和管理

　　技术改革管理的目的是识别出新技术（即工具、方法和过程），并以有序的方式将其引 进 ¹ 到组织中去。

　　技术改革管理包括鉴别、选择和评价新技术，并将有效的技术采用到组织中去。其目的 是改进软件质量、提高生产率和缩短产品开发周期。

　　建立一个组（例如软件工程过程组或技术支持组），它与软件项目一起引进和评价 新技术并管理对现有技术的改革。特别注重那些多半能改善组织标准软件过程能力的技术改 革（有关标准软件过程的描述在组织过程定义关键过程区域中）。

　　持对软件一有关的技术创新的了解和对它们进行系统的评价与实验，组织选择合适 的技术用以改进其软件的质量和其软件活动的效率。在新的和未经证明的技术引入到标准实

践中去之前，进行先导性试验以评估它们。当合适时，在组织管理者的恰当支持下，将选出 的技术纳入组织的标准软件过程和当前的项目。

　　按照在过程更改管理关键过程区域中所描述的那样，处理由这些技术改革所造成的对组 织标准软件过程（正如在组织过程定义关键过程区域所描述的）和项目定义软件过程（正如 在集成软件管理关键过程区域所描述的）的更改。

目标

　　技术改革的采纳是有计划的。

　　评价新技术以确定他们对质量和生产率的作用。

　　将合适的新技术收到全组织的标准实践中。

过程更改管理

　　过程更改管理的目的是本着改进软件质量、提高生产率和缩短产品开发周期的宗旨不断 改进组织中所用的软件过程。

　　过程更改管理包括定义过程改进目标，并且在高级管理者的支持下，在连续的基础上前 摄地（ Proactively ）和系统地识别、评价和实施对组织标准软件过程和项目定义软件过程的 改进。

　　制定培训和鼓励性计划，使得组织中的每个人能够并鼓励他们参加过程改进活动。识别 改进的机会并评价其对组织的可能回报。在将过程更改纳入标准实践之前，进行先导性试验 以评估这些过程更改。

　　当软件过程改进经批准用于标准实践时，在合适时修订组织标准软件过程和项目定义软 件过程。在组织过程定义关键过程区域中能找到修订组织标准软件过程的实践，在集成软件 管理关键过程区域中能找到修订项目定义软件过程的实践。

目标

　　连续的过程改进是有计划的。

　　组织的软件过程改进活动的参与面是全组织范围的。

　　组织标准软件过程和项目定义软件过程被连续偿断地改进。

　　定量过程管理的目的是定量地控制软件项目的过程性能。软件过程性能表示遵循一软件 过程所得到的实际结果。

　　定量过程管理包括建立集成软件管理关键过程区域所描述的项目定义软件过程的性能目 标、测量过程性能、分析这些测量结果并作出调整以保持过程性能在可接受的范围内。当在可接受的范围内过程性能是稳定时，项目定义软件过程、相关连的测量和测量的可接受范围就作为基线建立起来，并被用来定量地控制过程性能。

　　组织从软件项目采集过程性能数据，并使用这些数据对组织过程定义关键过程区域所描述的组织标准软件过程的过程能力（即，一个新项目能预计获得的过程性能）进行特征描述。过程能力描述从遵循一个软件过程所得到预期结果的范围（即，预计组织承担下一个软件项目时最可能的输出）。软件项目采用这些过程能力数据来建立和修订其过程性能目标和分析项目定义软件过程的性能。

目标

　　定量过程管理活动是有计划的。

　　项目定义软件过程的过程性能受到定量地控制。

　　组织标准软件过程的过程能力是定量地已知的。

软件质量管理

　　软件质量管理的目的是建立对项目的软件产品质量的定量了解和实现特定的质量目标。

　　软件质量管理包含确定软件产品的质量目标，制定实现这些目标的计划，并监控及调整 软件计划、软件工作产品、活动和质量目标，以满足顾客和最终用户对高质量产品的需要及 愿望。

　　软件质量管理的实践基于三个关键过程区域，前二个是建立和实施项目定义项目定义软 件过程的关键过程区域——集成软件管理 和软件产品工程，而后一个是定量过程管理关键过 程区域，它建立对项目定义软件过程实现所希望的结果能力的定量了解。

　　基于组织、顾客和最终用户的需要来建立软件产品的质量目标，这样这些目标才能实现。 为实现质量目标，组织制定战略和计划，项目则具体调整其已定义的软件过程 。

目标

　　项目的软件质量管理活动是有计划的。

　　软件产品质量的可测目标及其优先级是确定的。

　　实现软件产品的质量目标的实际进程是用数量表示的和受到管理的。

定量过程管理

　　定量过程管理的目的是定量地控制软件项目的过程性能。软件过程性能表示遵循一软件 过程所得到实际结果。

　　定量过程管理包括建立集成软件管理关键过程区域所描述的项目定义软件过程的性能目 标、测定过程性能、分析这些测量结果并作出调整以保持过程性能在接受的范围内。当在可 接受范围内过程性能是稳定时，项目定义软件过程、相关连的测量和测量的可接受范围就作 为基线建立起来，并被用来定量地控制过程性能。

　　组织从软件项目采集过程性能数据，并使用这些数据对组织过程定义关键过程区域所描 述的组织标准软件过程能力（即一个新项目能预计获得的过程性能）进行特征描述。过程能 力描述从遵循一个软件过程所得到预期结果的范围（即，预计组织承担下一个软件项目时最 可能的输出）。软件项目采用这些过程能力数据来建立和修订其过程性能目标和分析项目定 义软件过程的性能。

定量过程管理的目标是：

    1 ．定量过程管理活动是有计划的。

    2 ．项目定义软件过程的过程性能受到定量地控制。

    3 ．组织标准软件过程的过程能力是定量地已知的。

定量过程管理所执行的顶层活动是：

    1 ．按照已文档化的规程制定软件项目的定量过程管理计划。

    2 ．按照项目的定量过程管理计划执行软件项目的定量过程管理活动。

    3 ．在项目定义软件过程的基础上确定数据采集的策略和应作的定量分析。

    4 ．按照已文档化的规程，采集用于定量地控制项目定义软件过程的测量数据。

    5 ．按照己文档化的规程分析项目定义软件过程，并将其置于定量控制之下。

    6 ．准备和散发对软件项目的定量过程管理活动结果的书面报告。

    7 ．按照巴文档化的规程建立和维护组织标准软件过程的过程能力基线。

软件质量管理

　　软件质量管理的目的是建立对项目的软件产品质量的定量了解和实现特定的质量目标。

　　软件质量管理包含确定软件产品的质量目标，制定实现这些目标的计划，并监控及调整 软件计划、软件工作产品、活动和质量目标，以满足顾客和最终用户对高质量产品的需要及 愿望。

　　软件质量管理的实践基于三个关键过程区域，前二个是建立和实施项目定义软件过程的 关键过程区域——集成软件管理和软件产品工程，而后一个是定量过程管理关键过程区域， 它建立对项目定义软件过程实现所希望结果的能力的定量了解。

　　基于组织、顾客和最终用户的需要来建立软件产品的质量目标，这样这些目标才能实现。 为实现质量目标，组织制定战略和计划，项目则具体调整其已定义的软件过程。

软件质量管理的目标是：

　　1 ．项目的软件质量管理活动是有计划的。

　　2 ．软件产品质量的可测目标及其优先级是确定的。

　　3 ．实现软件产品的质量目标的实际进程是用数量表示的和受到管理的。

软件质量管理所执行的顶层活动是：

　　1 ．按照已文档化的规程制定和维护项目的软件质量计划。

　　2 ．项目的软件质量计划是项目软件质量管理活动的基础。

　　3 ．在整个软件生存周期，确定、监控和修定项目的软件产品的定量质量目标。

　　4 ．在事件驱动的基础上，对项目软件产品的质量进行测量、分析，并将其与产品的定量 质量目标相比较。

　　5 ．将软件项目的产品定量质量目标恰当地分配给那些向项目交付软件产品的于承包商。

　　组织过程焦点的目的是建立组织对软件过程活动的责任，这些活动能改进组织的整体软 件过程能力。

　　组织过程焦点包括增进和保持对组织的和项目的软件过程的了解，协调那些评估、制定 护和改进这些过程的活动。

　　组织提供长期的保证和资源，通过诸如软件工程过程组那样的组来协调那些横跨当前和 未来软件项目的软件过程的制定和维护工作。这个组负责组织的软件过程活动。具体负责制定和维护组织的标准软件过程和有关的过程财富（正如在组织过程定义关键过程区域中所描述的），同时它和软件项目一起协调过程活动。

目标

　　在整体组织中，过程的制定和改进活动是协调的。

　　已标识出所使用的软件过程与一个过程标准的相比的强处和弱点。

　　组织层上过程的制定和改进活动是有计划的

组织过程定义

　　组织过程定义的目的是开发和维护一组便于使用的软件过程财富，这些财富改进横跨各 项目的过程性能，并为组织积累性的长期得益打下基础。

　　组织过程定义包括制定和维护组织的标准软件过程，以及相关的过程财富，例软件生存 周期的描述，过程剪裁指南和准则，组织软件过程数据库和软件过程一有关文档库。

　　这些财富能经多种方式汇集，取决于对组织过程定义的组织实施。例如软件生存周期的 描述可以是组织标准软件过程的一个必备部分，或者软件过程一有关文档库的某些部分可以存储在组织软件过程数据库中。

　　在开发、实施和维护项目定义软件过程中，可以使用组织软件过程财富。（与项目定义 软件过程的制定和维护有关的实践在集成软件管理关键过程区域中加以描述）。

目标

　　制定和维护组织的标准软件过程。

　　收集和评审有关软件项目使用组织标准软件过程的信息，并使用合同。

培训大纲

　　培训大纲关键过程区域的目的是培育个人的技能和知识，使他们能有效地和效率高地履 行其职责。

　　培训大纲首先分别识别出组织、项目和个人所需要的培训、然后展开或设法获得培训以 满足所识别的需求。

　　每个软件项目评价练当前的和未来的技能需求，并决定如何才能获得这些技能。某些技 能可有效地和效率高地通过非正式的载体传递（例如在职培训和非正式指导），而其它的技术能则需要较正式的培训载体（例如课堂培训和受指导的自学）才能有老头儿地和效率高地传递。必须选择和使用恰当的载体。

　　这个关键过程区域仅包括培训组完成培训功能的实践，而识别特定培训专题（即所需要 的知识或技能）的实践则包含在各个有关的关键过程区域的执行能力共同特点中。

目标

　　培训活动是有计划的。

　　提供用以培育为履行软件管理和技术角色所需要的技能和知识的培训。

　　软件工程组和软件一有关组中的个人受到履行其角色所必须的培训。

集成软件管理

　　集成成软件管理的目的是将活动和管理活动集成为一个协调的、已定义的软件过程，该 软件过程是从组织的标准软件过程和有关的过程财富剪裁而得到的，这在组织过程定义中加以描述。

　　集成软件管理包括制订项目定义软件过程并采用此已定义的软件过程去管理软件项目，项目定义软件过程是组织标准软件过程经剪裁的版本，剪裁是为了针对项目的具体特征。

　　软件开发计划是基于项目定义软件过程并描述将如何实施和管理项目定义软件过程的活动。软件项目的规模、工作量、成本、进度、人员配置和其它资源等与项目定义软件过程的作业紧密相连。

　　由于项目定义软件过程全部是由组织标准软件过程剪裁而得到的，因此软件项目能共享 过程数据和所吸取的经验教训。

　　关于估计、策划和跟踪软件项目的基本实践均在软件项目策划 和软件项目跟踪和监督等 关键过程区域中描述。当问题出现时它们集中注意力于识别问题及调整计划和（或）性能以便解决这些问题。本关键过程区域的实践建立在那两个关键过程区域的实践之上，是对它们的补充。集成软件管理的重点转到采取预防防止问题发生，避免这些问题的后果或使之影响最小。

目标

　　项目定义软件过程是组织标准软件过程经剪裁的版本。

　　按照项目定义软件过程对项目进行计划和管理。

软件产品工程

　　软件产品工程的目的是一致地执行一个妥善定义的工程过程，该过程集成全部软件工程活动，以便有效地且高效率地生产正确的、一致的软件产品。

　　软件产品工程包括彩项目定义软件过程（在集成软件管理关键过程区域中加以描述）和适当的方法及工具去进行构造与维护软件的工程作业。

　　软件工程作业包括：分析分配给软件的系统需求（这些系统需求在需求管理关键过程区域中加以描述）、制定软件需求、开发软件的体系结构、设计软件、用代码实现软件、集成软件万分、和测试软件以验证它满足所规定的需求（即分配给软件的系统的需求和软件需求）。

　　制定并评审为进行软件工程作业所必须的文档（即软件需求文档、软件设计文档、测试计划和测试规程）以保证每个作业都针对其前面作业的结果，而它所产生的结果又适合于后续的作业（包括运行软件和维护软件的作业）。当更改被批准时，受影响的软件工作产品、计划、约定、过程和活动也要修改以反映该被批准的更改。

目标

　　定义和集成软件工程作业一致地执行它们以生产软件。

　　软件工作产品彼此间保持一致。

组间协调

　　组间协调的目的是建立软件工程组与其它工程组一起积极参与的方式以使得项目更能够 有效地和效率高地满足顾客的需要。

　　组间协调包括软件工程组和其它项目工程组一起参与阐述系统层的需求、对对象和问题。 项目工程组的代表，当合适时与顾客和最终用户一起工作，参与建立系统层的需求、对象和计划，这些需求、对象和计划成为全部工程活动的基础。

　　对组间的技术工作界面和相互作用加以计划和管理以保证整个系统的质量和统一性。各 项目工程组的代表参与定期的技术评审和内部交流，以保证所有工程组都清楚名组的状态和计划，并保证系统和组间的问题受到恰当的关注。

　　和这些工程作业有关的软件．专门实践的需求管理 和软件产品工程关键过程区域中描述。  

目标

　　顾客需求得到全部受影响的组的认同。

　　工程组之间的约定得到受影响的组的认同。

　　工程组识别、跟踪和解决组间问题。

同行评审

　　同行评审的目的是为了及早地和高效率地从软件工作产品中消除缺陷。一个重要的伴随 结果是对软件工作产品及可防止的缺陷得到更好的了解。

　　同行评审包括生产者的同行对软件工作产品进行系统地考察，以便识别缺陷和需作更改 的区域。将经受同行评审的具体产品在项目定义软件过程中加以标识，并作为软件项目策划活动的一部分来安排进度，正如在集成软件管理中所描述的。

　　这个关键过程区域仅包括执行同行评审的实践。而识别需经受同行评审的具体软件工作 产品的实践则包含在描述每个软件工作产品的开发和维护的关键过程区域中。

目标

　　同行评审活动是有计划的。

　　识别和消除在软件工作产品中的缺陷。

　　需求管理的目的是在顾客和将处理顾客需求的软件项目之间建立对顾客需求的共同理解。
　　需求管理包括和顾客一起建立和维护有关软件项目需求的协议，该协议称作“分配给软 件的系统需求”。“顾客”可解释为系统工程组、销售组、另一个内部组织、或者一个外部顾 客。协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、策划和跟踪整个软件生存周期内软件项目活动的基础。
　　 将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组（例如 系统工种组）完成，软件工种组可能对此分配无直接控制，在项目约束范围内，软件工程组采取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统需求。
　　为实现此控制，软件工种组评审初始的和经修改的分配给软件的系统需求，以便在它们 被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。

目标

　　分配给软件的系统需求是受控的，建立供软件工程和管理使用的基线。

　　软件计划、产品和活动与分配给软件的系统需求保持一致。

软件项目策划

　　软件项目策划的目的是为完成软件工程和管理软件项目制定合理的计划。

　　软件项目策划包含估计待完成的工作，建立必要的缩写和确定进行该工作的计划。

　　软件策划首先作出有关待完成的工作和其它定义及界定软件项目的约束和目标（由需求管理 关键过程区域的实践所建立的）的陈述。软件策划过程包括以下步骤：估计软件工作产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。为了制定软件计划（即计划开发计划），可能需要重复地通过这些步骤。

　　该计划提供完成和管理软件项目活动的基础，并按照软件项目的资源、约束和能力，阐 述对软件项目的顾客作的约定。

目标

　　对鸺策划和跟踪软件项目用的软件估计已建立文档。

　　软件项目的活动和约定是有计划的并已建立文档。

　　受影响的组和个人同意他们的关于软件项目的约定。

软件项目跟踪和监督

　　软件项目跟踪和监督的目的是建立对实际进展的适当的可视性，使管理者能在软件项目 性能明显偏离软件计划时采取有效措施。

　　软件项目跟踪和监督包括对照已文档化的估计、约定、和计划评审和跟踪软件完成情况 和结果，基于实际的完成情况和结果调整这些计划。

　　软件项目的巴文档化的计划（即软件开发计划，正如在软件项目策划关键过程区域中所 描述的）用作跟踪软件活动、传送状态和修订计划的基础。管理者监控软件活动。主要通过在所选出的软件工作产品完成的时和在所选择的里程碑处，将实际的软件规模、工作量、成本和时间表与计划相比较、来确定进展情况。当确定末实现软件项目计划时，采取纠正措施。这些措施可以包括修订软件开发计划以反映实际的完成情况和重新策划遗留的工作或者采取改进性能的措施。

目标

 
　　对照软件计划，跟踪实际结果和性能，

    当实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理直到结束。

 
　　对软件约定的更改得到受到影响的组和个人的认可。

软件子合同管理

　　软件子合同管理的目的是选择合格的软件子承包商并有效地管理他们。

　　软件子合同管理包括选择软件子承包商、建立和子承包商的约定，及跟踪和评审子承包 商的性能和结果。这些引起实践包括对纯软件子合同的管理，也包括对子合同的软件成分的管理，后者含有软件、硬件和可能有的其它系统成分。

　　基于子承包商完成工作的能选择子承包商。许多因素对将主承包商工作的一部分签为子 合同的决策产生影响。选择子承包商可以基于战略经营同盟及技术上的考虑。这个关键过程区域的实践阐述与将工作一个确定部分签子合同给另一组织的相联系的传统的采购过程。

　　当签子合同时，建立一个包括技术和非技术（例如交付日期）需求的已文档化的协议并 将其用作管理合同的基础。对将由于承包商完成的工作和关于该工作的计划建立文档。子承包商将遵循的标准和主承包商的标准一致。

　　子承包商的软件的策划、跟踪的监督活动由于承包商完成。主承包商确保恰当地完成这 些策划、跟踪和监督活动并且确保子承包商交付的软件产品满足其验收准则。主承包商和子承包商一起工作去管理他们的产品和过程界面。

目标

　　主承包商选择合格的软件子承包商。

　　主承包商和软件子承包商认同他们相互的约定。

　　主承包商和软件子承包准则保持不断通信。

　　主承包商对照约定期跟踪软件子承包商的实际结果和性能。

软件质量保证

　　软件质量保证 的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的可视性。

　　软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项 目和其它有关的经理提供这些评审和审计的结果。

　　在软件项目的早期阶段，软件质量保证组与软件项目一起工作制定计划、标准和规程等， 这些计划、标准、和规程将增加软件项目的价值并将满足项目和组织方针上的限制。通过参与制定计划、标准和规程，软件质量保证组帮助确保它们适合项目的需要，并且帮助验证它们对完成整个软件生存周期中的评审和审计将是适用的。软件质量保证组在整个生存周期评审项目活动，审计软件工作产品，并就软件项目是否正遵守已制定的计划、标准和规程等给管理者提供可视性。

　　首先在软件项目内部处理符合性问题，如可能的话就地解决它。对于那些无法在软件项 目内部解决的问题，软件质量保证组遂级上递该问题到管理者的恰当层次以求得解决。

　　这个关键过程区域只包括该组履行软件质量保证功能的实践。而识别软件质量保证组要 评审和（或）审计的具体的活动和工作产品的实践一般包含在其它关键过程区域的验证实施共同特点中。

目标

　　软件质量保证活动是有计划的。

　　软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证。

　　受影响的组和个人接到软件质量保证活动和结果的通知。

　　高级管理者处理在软件项目内部不能解决的不符合问题。

软件配置管理

　　软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整性。

　　软件配置管理包括标识在给定时间点上软件的配置（即选定的软件工作产品及其描述）， 系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可跟踪性。置于软件配置管理之下的工作产品包括交付给顾客的软件产品（例如软件需求文档和代码），以及与这些软件产品等同的产品项或生成这些软件产品所要求的产品项（例如编译程序）。

　　建立一个软件基线库，当软件基线形成时就将它们纳入该库。通过软件配置管理的更改 控制和配置审计功能，系统地控制基线的更改和那些利用软件基线库构造成的软件产品的发行。

　　这个关键过程区域仅包括实施软件配置管理功能的实践。而标识具体的配置项或单元的 实践则包含在描述每个配置项或单元的开发和维护的关键过程区域中。

目标

　　软件配置管理活动是有计划的。

　　所选定的软件工作产品是已标识的、受控的和适用的。


　　对已标识的软件工作产品的更改是受控的。

　　受影响的组和个人得到软件基线的状态和内容的通知。

　　一个角色是一项已定义的职责，它可能安排给一个或多个个人。在关键实践中常用以下 角色的描述：

经理（manager）

经理履行的任务包括：对在经理职责范围内进行作业和活动的个 人提供技术和管理方面的指导并进行控制。经理的传统职能包括 在其职责范围内进行策划、资源分配、组织、指导和控制。

高级经理（senior manager）

高级经理在组织的足够高的层次上履行管理任务，主要关注组织 的长期生存力，而不短期原项目和合同关心的事项及压力。一般 讲，一个高级工程经理负责多个项目。高级经理也提供和保护用 于软件过程长期改进的资源（例如，软件工程过程组）。 高级管理者，当用在 CMM 中时，能表示满足上述描述的任何经 理，直到且包括整个组织的头。当用在关键实践中，术语高级管 理者应该按关键过程区域及考虑中的项目和组织的上下文加以解 释。为实现关键过程区域的目标必须完成一些十分重要的领导和 监督任务：这里的意图就是要特别包括那些履行这些十分重要的 任务所必须的高级经理。

项目经理（Project manager）

项目经理履行的任务是对整个项目的总体业务负责；项目经理是 指导、控制、管理和调整项目进行构造软件或硬件嫩件系统工作 的个人，项目经理是最终向顾客负责的个人。 在面向项目的组织机构中，工作在同一个项目的大多数人应向项 目经理报告，尽管某些科目可能有一个矩阵式的报告关系。而在 矩阵式的组织机构中，可能仅业务职务只向项目经理报告，而工 程组则有一个矩阵式的报告关系。

项目软件经理（Project softWare manager)

项目软件经理履行的任务是对项目的全部软件活动总负责。项目 件经理是项目经理按软件约定与其打交道的个人，且是控制一 个项目的所有软件资源的个人。 一个项目的软件工程应向项目软件经理报告，尽管某些活动—— 例如工具开发——可以有一个矩阵式的报告关系。 在大型项目中，项目软件经理多半是二线、三线或四线经理。在 小型项目或只有单个项目的部门中，项目软件经理可能是一线软 件经理或可能在更高层次。

一线软件经理（Firat－lineSoftware manager）

一线软件经理履行的任务是对由软件工程师和其它有关人员组成 的一个机构单位（例如，一个部门或者项目组）的人员配置和活 动负直接管理责任（包括提供技术方向及对人员和薪金进行管理 的功能）。

软件作业领导（Software Task leader)

一个软件作业领导履行的任务是充当特定作业的技术组的领导 者，负有技术责任并向工作在该作业的职员提供技术方向。 软件作业领导通常和其它工作在该作业的人员一样向同一个一线 软件经理报告。

职员、软件工程职员、个人（Staff,software staff,individuals）

在 CMM 的不同的关键实践中描述了不同的技术角色，在 CMM 中采 用几个术语去指示履行这些不同技术任务的个人。职员是包括作 业领导的一些个人，他们负责完成一项指派的功能，例如软件开 发或软件配置管理，但他们不是经理。 软件工程职员是软件技术人员（例如分析员、程序员和工程师）， 包括软件作业领导，他们进行项目的软件开发和维护活动，但他 们不是经理。术语“个人”，当用在关键实践中时，由该词出现 处的上下文未定性和限定（例如参与管理软件子合同的个人）。

　　对于其它的工程组，例如系统工程组或系统测试组，也能对其角色作了类似的分解。

　　在一个具体的项目或组织中，在这些角色和个人之间不必—一对应。一个人能完成多个 角色，或者一个角色可由若干个人承担。

　　例如，对于一个小的纯软件项目，一个人可以承担多到六个角色：系统工程的一线经理， 项目的系统工种经理，软件的一线经理、项目的软件经理、项目经理和软件配置管理经理。

　　对于略大一点的项目，一个人可以担当：系统工程的一线经理、项目的系统工种经理和 项目经理，而另一个人可以既是一线软件经理又是项目的软件经理。这两位经理可以在同一个二线机构中，也可以在不同的二线机构中。

　　对于大项目，许多岗位，特别是管理岗位，多半由不同的个人承担。

　　每个关键过程区域用能对实现其目标作出贡献的关键实践加以描述。关键实践描述对关键过程区域的有效实施和规范化贡献最大的基础设施和活动。

　　每个关键实践的组成是：一个单句子，常常紧跟着较为详细的描述，后者可能包括例子和详细细节。前者，又称为顶层关键实践，说明关键过程区域的基本方针、规程和活动。进行详细描述的分量常称作于实践。

　　关键实践描述应作什么，但是不应解释为强制如何实现目标。替代的实践也可能实现该关键过程区域的目标。应该合理地解释关键实践以便判断关键过程区域的目标是否已有效地实现，尽管实现目标的方式可能不同。

关键实践的版面介绍

　　关键实践按成熟度等级分组。而等级间又用一个标记页分开。标记页上包括成熟度等级 的描述、那个等级的关键过程区域的清单，以及每个关键过程区域的起始页码 。

　　每个关键过程区域的包括，

　　l  关键过程区域的简要描述，

　　l  关键过程区域的目标，和

　　l  关键实践。

　　关键实践本身又被分组到五个共同特点（即执行约定、执行能力、执行的活动，测量和 分析、及验证实施）的名下，并且以层次式的格式表示，正如在图 中所显示的一个关键实践的版面例子。关键实践包括：

图3.1  关键实践陈述的例子

关键实践（ Key practices ）

  　关键实践，又称为顶层关键实践，阐述关键过程区域的基本方针，规程和 活动。他们粗体字表示并在每个共同特点内加以编号。例如在执行的活动 这一共同特点中的第一个关键实践被标志为活动 1 。

子实践（ subpractices ）

　　子实践，又称下级关键实践被列在顶层关键实践的下面，它描述人们所预 期的，为完成顶层实践而应该做的事。子实践可用于帮助确定关键实践是 否得到满意的实施。

补充信息（ Supplementary  information ）

　　在关键实践之后用方括号括起补充信息。补充信息包括例子、详细解释， 以及对其它关键过程区域的索引。

　　当一个关键实践下的子实践或补充信息扩展到另一页时，在新页开头处的园括号内标出 该关键实践以指示这页的信息是前页关键实践信息的继续 。

共同特点

　　每个关键过程区域中的关键实践按一组共同特点加以组织。共同特点是表明一个关键过 程区域的实施和规范化是否有效、可重复且持久的一些属性。共同特点也将关键实践分组和 排成序列，方便组织使用它们。五个共同特点列举中下：

　　执行约定 执行约定描述组织为保证过程得以建立和继续起作用所必须采取的行动， 执行约定一般包括制定组织的方针和建立高级管理者的支持。

　　执行能力 执行能力描述为了能实施软件过程，项目或组织中必须存在的先决条件。 执行能力一般包括资源、组织机构和培训。

　　执行的活动 执行的活动描述为实现一个关键过程区域所必须的岗位和规程。执行的活 动一般包括制定计划和现程、进行工作、跟踪它、并在需要时采取纠正措施。

　　测量和分析 测量和分析描述对过程进行测量和对测量结果进行分析的需要。测量和分 析一般包括为了确定所执行活动的状态和有效性所能采用的测量的例子。

　　验证实施 验证实施描述那些能保证遵照已建立的过程进行活动的措施。验证一般包 括管理者和软件质量保证部门所作的评审和审计。

　　在执行的活动 这一共同特点中的实践描述为建立过程能力必须作些什么。而其它的实践 作为一个整体形成了一个基础，在此基础上组织能规范化执行的活动中描述的实践由项目。 或组织所执行的活动构成关键实践中最大的一类，因为它们描述关键过程区域的实际实施。 在其它共同特点下的关键实践也是同等重要的，因为它们阐述为了支持和规范化关键过程区 域而必须做的事情。

CMM的关键过程区域

　　中列出 CMM 中每个成熟度等级的关键过程区域。每个关键过程区域识别出一串相关活动，当这些活动全部完成时，能达到一组对增强过程能力至关重要的目标。每个关键过程区域定义在单个成熟度等级上。关键过程区域是一些结构单元，它们指明组织为改进其软件过程应关注的区域。关键过程区域为达到某一成熟度等级必须解决的问题。

      

　　一个组织的软件过程成熟度能帮助预测一个项目达到其目标的能力。等级 1 组织中的不同项目在达到成本、进度、功能和质量等指标的能力上差别很大。正如图2.4 中的例子所示，随着组织软件过程成熟，在满足预定目标方面能观察到三个改进之处。

其次，随着成熟度增长，实际结果相对预定目标结果的偏差范围减小。例如，等级 1 组织中，对具有类似规模项目的交付日期是不可预测的，其变化很大。而等级 5 组织中的类似项目的交付日期在小得多的范围内变化。在最高成熟等级上变化范围很小的原因是所有的项目实际上均在接近组织的有关成本、进度、功能和质量等过程能力的受控参数的范围内运行。（图2.4 中，以集中于预定目标线附近的面积大小说明这点。）

　　第三，随着组织成熟度的增加，预定目标结果得到改善。这就是说，随着软件组织的成熟，成本降低，开发时间缩短、生产率和质量提高。在等级1上的组织，其开发时间可能十分长，因为必须完成大量的用以纠正错误的返工。相反，等级5组织采用不断改进过程和缺陷预防技术增加过程有效性和消除费钱的返工，使得开发时间得以缩短。（图2.4中，这点反映在预定目标线在指向原点方向上的水平移动。）

　　图2.4中所表示的在预测项目结果方面的改进基于以下假定，即随着噪声（通常以返工形式出现）从软件过程中消除，软件项目结果更加可以预测。但是，无先例的系统会使情况复杂化，因为新的技术和应用问题增加可变性，从而降低过程能力。即使在无先例系统的情况下，与比较不成熟的组织相比，较成熟的组织管理和工程实践的特征能在开发周期的较早阶段帮助识别和阐述问题。由于较早识别出缺陷，能消除后面阶段的返工，从而提高项目的稳定性和性能。风险管理是成熟过程中项目管理的必不可少部分。在某些情况下，一个成熟过程意味着在软件生命周期的早期识别出“失败”项目，使得在徒劳无功的事情上投资最小。

跳跃成熟度等级

　　CMM 中的成熟度等级描述在一个成熟度等级上组织的特征。每一等级均为接连的几个等级奠定基础，为有效地且效率高地实施过程提供支持。可是，在有益时，组织也可以使用比它们所在等级高的那些成熟度等级中所描述的过程。例如，虽然 CMM 中在等级 3 以前不讨论工程过程——一诸如需求分析、设计、编码和测试，但是甚至等级 1 组织都必须进行这些活动。在有利可图时，等级 1 或等级 2 组织可以进行同行评审（等级 3 的）、 Pareto 分析（等级 4 的）、或者引入新技术（等级 5 的）。在讨论为了从等级 1 提高到等级 2 一个组织应采取何种步骤时，一个经常性的建议是建立软件工程过程小组，而这是等级 3 组织的属性。虽然度量是等级 4 的关注焦点，但它也是较低成熟度等级的必备部分。

　　可是这些过程的潜力只有在建立适当基础之后才能得到完全的发挥。例如，同行评审不 可能完全有效，除非始终一致地实施这种评审，即使对非常紧急的项目也是如此，成熟度等级只描述一个等级上占主导地位的问题。等级 1 组织的占主导地位的问题是管理；策划和管理软件项目的困难掩盖了其它问题。

　　因为每个等级形成一个必要的基础，从此基础出发才能达到下一个等级，因此，跳越等 级是违反生产规律的。 CMM 识别几个等级，一个组织必须逐步经历这些等级才能建立优秀的软件工程文化。没有合适基础的过程，在正是最需要它们的时刻——即处于压力下—一不起作用，它们也不提供未来改进的基础。

　　等级 1 组织，在尚未建立可重复过程（等级 2 ）之前，试图去实施已定义的过程，通常不会成功，因为项目经理会被进度和成本的压力压垮。这是在关注工程过程之前应首先集中注意力于管理过程的基本原因。看起来定义和实施一个工程过程似乎要比定义和实施管理过程容易（特别在技术人员眼中），但是如果没有管理规定，工程过程会成为进度和成本等压力的牺牲品（ Humphrey 88 ）。

　　一个尚无已定义过程作为基础就试图实施已管理（等级 4 ）的组织通常是不成功的，因为没有已定义的过程就没有解释度量的共同基础。虽然对于一个个项目能采集数据，但几乎没有什么度量对本项目之处的其它项目有重大意义，也不能显著地增加组织对软件过程的理解。缺少已定义过程时，由于被测过程的变化，要鉴别出有意义的度量是困难的。

　　一个尚无已管理过程（等级 4 ）作为基础就试图实施优化过程（等级 5 ）的组织，由于缺乏对过程更改所产生的后果的了解，多半会失败。在不能控制过程使它处于统计意义上狭窄的范围内（即过程度量中仅有小的变化）的情况下，数据中有太多的噪声以致不能客观地确定某项具体的过程改进是否有效。因为几乎没有定量基础用于作出理性的、有信息依据的决策，决策可能退化为宗教式的争斗。

　　过程改进工作应该把焦点集中在经营环境的止下文中组织的需要。具有实施较高成熟度 等级的过程的能力并不表示可以跳越成熟度等级。

总之，软件过程评估和软件能力评价方法两者均：

　　l 采用成熟度提问单作为现场访问的出发点；
　　l 采用 CMM 作为指导现场调查研究的路线图；
　　l 利用 CMM 中的关键过程区域生成标识软件过程强项和弱项的调查发现；
　　l 在对关键过程区域目标满足情况进行分析的基础上，推导出一个剖面；和
　　l根据调查发现和关键过程区域剖面向合适的对象提出结论意见。

　　尽管等级 1 组织常被特征化为具有无秩序的、甚至是混乱的过程，但它们常常开发出能工作的产品，即使它们可能超出预算和进度要求。等级 1 组织的成功依赖于组织中人员的能力和杰出的努力。对所有成熟度等级的组织来说，选择、雇用、培养、和（或）留住有能力的人都是重要议题，但它们多半在 CMM 的考虑范围之外。

理解可重复级和已定义级

　　随着项目规模和复杂性的增长，注意力逐渐从技术问题转达向组织体系和管理问题——一过程成熟度的焦点问题（ Siegel 90 ，   DoD 87 ，   GAD-92 － 48 ）。通过将最优秀职员所取得的经验教训纳入已文档化的过程、通过培育有效地执行那些过程必须的技能（通常以培训的方式）、以及通过以向完成任务的人们学习的方式所得到的不断改进，过程能使人们工作得更为有效。

　　为达到等级 2 ，管理者必须集中注意力于他们自己的过程以便实现一个有纪律性的软件过程。等级 2 是等级 3 的基础，因为在处理等级 3 上的技术和组织体系问题之前，关注焦点必须放在管理者改进其过程的行为上。在实现等级 2 的过程中，通过将项目管理过程编制成文档并遵照执行，管理者建立起领导地位。

　　在等级 2 组织中不同项目的过程可以不同；为了达到等级 2 ，组织体系上要求是存在指导项目建立合适的管理过程的方针。已文档化的规程为这些一致的过程打下基础，在培训和软件质量保证工作的帮助下，能在全组织范围内使这些过程规范化。

　　通过对整个软件过程加以定义、集成和文档化，等级 3 建立在项目管理的基础之上。在此情况下，集成意味着一个作业的输出顺利地成为下一个作业的输入。当作业间存在不匹配的现象时，在软件过程的规划阶段它们就能得到识别和处理，而不是等到实施过程中遇到它们时才加以解决。等级 3 上的一个挑战是构造这样一些过程，这些过程允许软件人员开展工作时仍有一定的自由度（ Humphrey 91b ）。

理解已管理级和优化级


　　成熟度等级 4 和等级 5 对软件产业界来说还是一个相对未知的领域。仅存在不多几个等级 4 和等级 5 的软件项目和组织（ Hllmphrey  91a Kitson  92 ）。由于现有的实例太少，以致不能导出有关等级 4 和等级 5 组织特征的一般结论。通过与其它产业类比和利用软件产业界中能显示这些等级过程能力的少数例子，这些等级的特征已经得到定义。
    图2.2 例子说明统计过程的基本概念，等级 4 和等级 5 的许多特征建立在这些概念之上。朱兰三部曲（ Juran Trilogy ）图（ Juran 88 ）显示过程管理的主要目标。
   

图2.2 朱兰三部曲（Jurun  Trilogy)  　
图：质量策划、质量控制和质量改进

　　Juran将质量管理分成三个基本的管理过程（Juran 88）。质量策划的目的是向运作人员，即软件生产者提供生产能满足顾客需求的产品的方法。操作人员生产出产品，但由于质量缺陷不得不做某些返工。这种浪费是经常性的（因为过程被设计成那种样子）；执行质量控制是为了防止事情恶化。过程中的零星的尖锋，如图2.2所示，代表消防活动。经常性的浪费提供了改进的机会，抓住这个机会进行工作就叫做质量改进。
　　质量改进的第一个职责，也是等级4的关注焦点是过程控制。对软件过程进行管理以致它能稳定运行在质量控制带内。虽然必定还有一些经常性的浪费，测量结果中可能还有尖锋信号需要控制，但是系统在整体上是稳定的。正是这些地方，控制变化的特殊原因这个概念开始起作用。因为过程既稳定又可测，所以当出现某些例外情况时，能够识别出并阐述变化的“特殊原因”。
　　质量改进的第二个职责，也是等级5的关注焦点，是过程的不断改进。为了提高质量，变更软件过程，随后质量控制带移动。建立新的能减少经常性浪费的性能基线。在改进这样一个过程中所得到的经验教训被运用到规划未来的过程中。正是在这些地方，消除变化的一般原因这个概念开始引人注目。仅仅由于随机变化，在任何系统中均以返工的形式存在经常性的浪费。
　　浪费是不能容忍的；有组织地减少浪费的努力导致更改系统，也就是通过克服造成低效性的“一般原因”来改善过程以防止出现浪费。我们期望达到最ＣＭＭ最高成熟度等级的组织,具有能在预测成本和进度的限制下生产出极端可靠的软件过程。随着对较高成熟度等级理解的加深，将对已有的关键过程区域加以提炼，也可能给模型添加些内容。CMM是从制造业中所产生的过程思想推导出的，但是软件过程不像制造过程那样以重复问题占主导地位。软件过程以设计问题占主导地位，而且是知识密集性的活动（Crutis 88)。

软件过程的可视性

　　软件工程师们对项目状态有详细而深入的了解，因为他们掌握有关项目状态和性能的第一手材料。可是，对大项目而言，他们的洞察力常来源于在其职责范围内的个人经验。项目以外的不掌握第一手材料的人，例如高级经理，对项目过程缺乏可视性，为得到他们监控进程所需求的信息只得依靠定期的评审。 显示在过程成熟度过每个等级上，提供给管理者的对项目状态和性能的可视性等级。每个后断的成熟等级逐步增加地提供软件过程更好的可视性。

图2.3 管理者对每个成熟度等级的软件过程的可视性

　



　等级 1 的软件过程是一种无组织的整体——一个黑盒，项目过程的可视性是有限的。由于没有很好地定义活动阶段的划分，经理在确定项目过程和活动状态上极为困难¹  。
　　需求以失控的方式进入软件过程，然后生产出产品。软件开发常被看作为不可知的魔术， 特别对不熟悉软件的经理而言更是如此。

　　等级 2 上，顾客需求和工作产品受到控制，已经建立起基本的项目管理实践。这些管理控制使得在规定的场合项目可视。构造软件的过程可看作为一个接一个的黑盒子，这使得随着活动在盒子间流动，在各过渡点（项目里程碑）上具有管理可视性。尽管管理者可能不知道盒子内发生事情的细节，但是过程的产品和用以证实过程正在适当进行的检验点都有是确定且已知的。当问题出现时，管理者能对它们作出反应。

　　等级 3 上，盒子的内部结构（即项目定义软件过程中的作业）是可视的。内部结构表示组织的标准软件过程用于具体项目的方式。经理们和工程师们都了解他们在过程中的角色和职责，并且知道他们的活动如何在合适的细节层次上相互影响，管理者预先作好应付可能发生风险的准备。由于己定义的过程提供对项目活动很好的可视性，项目外的个人能获得精确的、即时的状态更新信息。

　　等级 4 上已定义的软件过程被配备上度量，并得到定量地控制。经理们能够度量进程和问题。他们作决策时，有一个客观的定量的基础。随着过程的变异性越来越小，他们预测结果的能力稳定地成为越来越准确。

　　等级 5 上，为了提高生产率和质量，以受控的方式对构造软件的新的和已改进的方法进行不断的试验。因为无效的或者易出错的活动均行到标识并加以替代或修改，有纪律的更改成为一种生活方式。不仅对现存在过程明察毫，而且洞察力扩展到能了解过程潜在变化的影响。经理们能定量地估计更改的影响和有效性。然后跟踪它们。

　　在初始级组织一般不提供开发和维护软件的稳定环境。当组织中缺乏健全的管理实践时，不适当的规划和反应驱动体系会降低由良好的软件工程实践所带来的效益。  

　　在危机时刻，项目一般抛弃预定的规程，回复到仅作编码和测试。成功完全依赖于有一 个杰出的经理及一支有经验的、战斗力强的软件队伍。偶尔，有能力的、坚强的软件经理能经受住他们在软件过程中走捷径的压力，但是当他们离开项目后，他们能使过程稳定的影响也随之消失。甚至一个强的工程过程也不能克服由于缺乏健全的管理实践所造成的不稳定。

　　等级 1 组织的过程能力是不可预测的，因为随着工作进展软件过程经常被改变或修定（即过程是无秩序的（ ad hoc)) 。进度、预算、功能性和产品质量一般是不可预测的。性能依赖于个人的能力，且随个人固有的技能、知识和动机的不同而变化。等级 1 组织几乎没有明显的稳定的软件过程，只能通过个人的能力而不是组织的能力去预测性能。

等级2----可重复级

　　在可重复级上，已建立管理软件项目的方针和实施这些方针的规程。基于在类似项目上 的经验对新项目进行规划和管理。达到等级 2 的目的使软件项目的有效管理过程制度化，这使得组织能重复在以前项目上所开发的成功实践，尽管项目所实施的具体过程可能不同。一个有效过程可特征化为实用的、已文档化的、已实施的、已培训的、已测量的和能改进的。

　　等级 2 组织中的项目已设置基本的软件管理控制。实际可行的项目约定是基于对以前项目的观察结果和当前项目的需求。项目的软件经理跟踪软件成本、进度和功能性：在满足约定方面的问题，一旦出现就被识别。对软件需求和实现需求所开发的工作产品建立基线，并控制其完整性。软件项目标准均己确定，并且组织能保证准确地执行这些标准。如果有子承认包商的话，软件项目与他们一起努力建立一种强有力的顾客——供应商关系。

　　等级 2 组织的过程能力可概括为有纪律的，因为软件项目的规划和跟踪是稳定的，能重复以前的成功。由于遵循基于以前项目性能所制定的切实可行的计划，项目过程处在项目管理系统的有效控制之下。

等级3----已定义级

　　在已定义级上，全组织的开发和维护软件的标准过程已文档化，包括软件工程过程和软 件管理过程，而且这些过程被集成为一有机的整体。在 CMM 中的所有地方，均称此标准过程为组织的标准软件过程。等级 3 上所建立（适当时，经更改）的过程，被用来帮助软件经理和技术人员工作得更有效。组织在使其软件过程标准化时，利用有效的软件工程实践。存在一个负责组织的软件过程活动的组，例如软件工程过程级（ SEPG ）（ Fower 90 ）实施全组织的培训计划以保证职员和经理具有履行其职责所必须的知识和技能。

　　项目通过剪裁组织的标准软件过程去建立他们自己定义的软件过程，它说明项目独有的 特征。在 CMM 中，这种剪裁后的过程称作项目定义软件过程。一个已定义软件过程包含一个组协调的、集成的、妥善定义的软件工程过程和管理过程。妥善定义的过程可特征化为具有准备就绪判据、输入、标准、进行工作的规程、验证机制（例如同行评审）、输出、以及完成判据。因为软件过程已妥善定义，管理者就能洞察所有项目的技术进展。

　　等级 3 组织的软件过程能力可概括为标准的和一致的，因为无论软件工程活动还是管理活动，过程都是稳定的和可重复的。在所建立的产品线内，成本、进度和功能性均受控制、对软件质量也进行跟踪。这种过程能力建立在整个组织范围内对已定义过程中的活动、角色和职责的共同理解之上。

等级4----已管理级

　　己管理级上，组织对软件产品和过程都设置定量的质量目标。作为组织测量大纲的一部 分，对所有的项目都测量其重要的软件过程活动的生产率和质量。利用一个全组织的软件过程数据库收集和分析从项目定义软件过程中得到的数据。等级 4 上的软件过程均已配备有妥善定义和一致的度量。这些度量为定量地评价项目的软件过程和产品打下基础。

　　项目通过将其过程性能的变化限制在定量的可接受的范围之内，实现对其产品和过程的 控制。可以将过程性能方面有意义的变化与随机变化（噪声）区别开来，特别在所建立的产品线内。开发新应用领域的软件所带来的风险是已知的，并得到精心的管理。

　　等级 4 组织的软件过程能力可概括为可预测的，因为过程是已测量的并在可测的范围内运行。该等级的过程能力使得组织能在定量限制的范围内预测过程和产品质量方面的趋势。当超过限制范围时，采取措施予以纠正。软件产品具有可预测的高质量。

等级5---优化级

　　在优化级，整个组织集中精力进行不断的过程改进。为了预防缺陷出现，组织有办法识 别出弱点并预先针对性地加强过程。在对新技术和所建议的组织软件过程的更改进行费效分析时利用有关软件过程有效性的数据。识别出采用最好软件工程实践的技术创新并推广到整个组织。

　　等级 5 组织的软件项目群组分析缺陷以确定其发生的原因。为了防止已知类型的缺陷再次出现他们认真评价软件过程，同时将经验教训告知其它项目。

　　等级 5 组织的软件过程能力可特征化为不断改进，因为这些组织为扩大其过程能力的范围进行着不懈的努力，因而不断改善其项目的过程性能。既通过在现有过程中增量式前进的办法，通过采用新技术、新方法的革新办法，使改进不断出现。

         对于CMM的作用归纳两个主要方面: 科学地评价软件开发单位的软件能力成熟等级; 帮助软件开发单位进行自检，了解自己的强项和弱项，从而不断完善和改进单位的软件开发过程，确保软件质量，提高软件开发能效率。

         由于CMM并未提供有关实现CMM关键过程域所需的具体知识和技能，因此，美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发了个体软件过程PSP（Personal software process）和群组软件过程TSP(Team Software Process)，形成CMM/PSP/TSP体系。

          PSP 个体软件过程（Personal Software Process）是由美国Carnegie Mellon大学软件工程研究所(CMU/SEI)的Watts s. Humphrey领导开发的，于1995年它的推出，在软件工程界引起了极大的轰动，可以说是由定向软件工程走向定量软件工程的一个标志。PSP是一种可用于控制、管理和改进个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。 PSP为基于个体和小型群组软件过程的优化提供了具体而有效的途径，例如如何制订计划，如何控制质量，如何与其他人相互协作等等。在软件设计阶段， PSP的着眼点在于软件缺陷的预防，其具体办法是强化设计结束准则，而不是设计方法的选择。PSP保障软件产品质量的一个重要途径是提高设计质量。

           PSP能够说明个体软件过程的原则；帮助软件工程师作出准确的计划；确定软件工程师为改善产品质量要采取的步骤；建立度量个体软件过程改善的基准；确定过程的改变对软件工程师能力的影响。

          TSP　群组软件过程TSP(Team Software Process) 指导项目组中的成员如何有效地规划和管理所面临的项目开发任务，并且告诉管理人员如何指导软件开发队伍。始终以最佳状态来完成工作。TSP实施集体管理与自己管理自己相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对群组开发过程的定义、度量和改进。

          TSP致力于开发高质量的产品，建立、管理和授权项目小组，并且指导他们如何在满足计划费用的前提下，在承诺的期限范围内，不断生产并交付高质量的产品。

         CMM是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式。企业只有开始CMM改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训,合理分配项目人员,并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。
          PSP能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用PSP，从而有助于CMM目标的实现。
         TSP结合了CMM的管理方法和PSP的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与　组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项　目的管理，向组织展示如何应用CMM的原则和PSP的技能去生产高质量的产品。
        总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是CMM/PSP/TSP的有机集成。

实施CMM的必要性

           软件开发的风险之所以大，是由于软件过程能力低，其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。

         软件质量是一模糊的、捉摸不定的概念。我们常常听说：某某软件好用, 某某软件不好用；某某某软件功能全、结构合理, 某某某软件功能单一、操作困难……这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。可以通过一些方法和人类活动，来改进质量。

          实施CMM是改进软件质量的有效方法:控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有：需求工程(RE：REQUIREMENTS ENGINEERING)。理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。软件复用(SR：SOFTWARE REUSE)。定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。这种技术，可改进软件产品质量和生产率。还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。

CMM在中国的现状

         近两年来，CMM在我国获得了各界越来越多关注，业界有过多次关于CMM的讨论，2000年6月国务院颁发的《鼓励软件产业和集成电路产业发展的若干政策》对中国软件企业申请CMM认证给予了积极的支持和推动作用,第17条规定"对软件出口型企业CMM认证费用予以适当支持。"2000年中国村电脑节上还有CMM专题论坛，吸引了众多业内人士。鼎新、东大阿尔派、联想、方正、金蝶、用友、浪潮、创智、华为、东大阿尔派等大型集团或企业等都从1997---2000年起批企业都在进行研究、实验或实施预评估。其中鼎新公司从1997年着手进行CMM认证工作。1999年7月通过第三方认证机构的CMM2认证。东大阿尔派公司于2000年10月通过第三方认证机构的CMM2认证。2001年1月，联想软件经过英国路透集团的严格评估，顺利通过CMM2认证。2001年6月26日，沈阳东软软件股份有限公司（原沈阳东大阿尔派软件股份有限公司）正式通过了CMM3级认证，成为中国首家通过CMM3级的软件企业。

        CMM本身只是一个可以被用来评估企业能力成熟度的过程框架，而并不是什么“标准”，CMM的重点在于软件过程的改进而不在于什么“评审”，至于所谓的“认证”那更是扯不上边的事情。

　   CMM/CMMI本身是一套非常有价值的过程模型，但简单的将其图腾化却是整个中国软件行业的悲哀，反观CMM/CMMI的发源地——美国，除了和军方有业务往来的软件企业会寻求通过CMM/CMMI评审外，其他多数的企业并不怎么在乎是通过了CMM/CMMI的三级还是四级，象是著名的微软、甲骨文等知名企业都没听说过和CMM/CMMI沾过边，但这也丝毫不影响以他们为代表的美国软件企业在整个行业中独领风骚。

       CMM/CMMI不是为软件研究性项目设计的，而是为产品项目设计的。对于那些研究性的项目，搞上CMM，等于把自己打进了死牢。研究性的项目需要创新的思想，需要更多的实验与思维，给与研究人员更多的创新空间，而不是能够在短时间内出产品的，不是需要更多的文档和过程。所以，需要搞清楚你的项目是研究性的，还是产品性的，不要盲从CMM/CMMI。 

          软件过程成熟度框架（Humphrey 87a）将这些阶段排序，使每个阶段上的改进能为下一阶段的改进打下基础。所以，从软件过程成熟度框架导出的改进策略，对过程不断改进的历程提供了一份导引图。它指导组织前进共识别出其缺陷，但它并不企图对有问题的项目提供快速修复措施。

CMM可用于：

　　□ 软件过程改进，为此组织策划、设计和实施对其软件过程的更改；

　　□ 软件过程评估，为此一个经培训的软件专业人员组确定组织当前软件过程的状态、确 定组织所面临的具有高优先级的软件过程一有关问题，并获得组织上对软件过程改进的支持；   和

　　□ 软件能力评价，为此一个经培训的软件专业人员级鉴别合格的能完成软件工作的承包 商或监控现有软件工作中所用软件过程的状态。

       CMM/PSP/TSP即软件能力成熟度模型/ 个体软件过程/群组软件过程，是1987年美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI)以W.S.Humphrey为首的研究组发表的研究成果"承制方软件工程能力的评估方法"；SO 9000质量标准体系是在70年代由欧洲首先采用的，其后在美国和世界其他地区也迅速地发展起来。目前，欧洲联合会积极促进软件质量的制度化，提出了如下ISO9000软件标准系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年国际标准化组织采纳了一项动议，开展调查研究，按照CMU-SEI的基本思路，产生的技术报告ISO/IEC 15504--信息技术软件过程评估

       目前，学术界和工业界公认美国 Carnegie Mellon 大学软件工程研究所(CMU/SEI) 以W.S.Humphrey为首主持研究与开发的软件能力成熟度模型CMM是当前最好的软件过程，已成为业界事实上的软件过程的工业标准。

不外乎以下方面：
形成文档化的制度，
规范和模板；
严格按照制度办事；
按照要求形成必要的记录；
检查、监督和持续改善。

在软件需求管理方面，对于准备通过CMM2级评测的开发机构，团队应将注意力放在以下几个方面:

* 软件需求必须形成文档；

* 软件需求必须能被控制，进而建立工程和管理的基线；

* 成员必须接受需求管理培训；

* 建立衡量需求状态的信息。

对于准备通过CMM3级评测的开发机构，应将注意力放在以下几个方面:

* 对需求进行系统化分析，确保软件需求完整性，一致性和可测试性；

* 软件需求、设计、编码和测试用例都能够回溯到相应的源头，在需求发生实质变更之前能够判别该变更所带来的潜在影响；

* 需求的修订应遵从统一的流程，需求的变更应从始至终被跟踪，软件需求文档应当通过配置和变更管理工具进行管理。

最后要强调的是，过程成熟度水平是衡量机构开发流程成熟度的标准，不应该被当作开发流程改进的奋斗目标。开发机构切忌本末倒置，应该以现有流程为基础，实事求是地改进、优化各项具体工作，参照过程成熟度模型全面提升开发机构的需求管理能力。