第2章 软件过程

第2章软件过程软件过程框架传统软件过程模型现代软件过程模型软件能力成熟度(CMM与CMMI)个体软件过程(PSP)团队软件过程(TSP)第2章软件过程当开发产品或构建系统时，遵循一系列可预测的步骤（即路线图）是非常重要的，它有助于及时交付高质量的产品。软件开发中所遵循的路线图就称为“软件过程”。第2章软件过程软件过程提高了软件工程活动的稳定性、可控性和有组织性，如果没有过程约束，软件活动将失控并变得混乱。但是，现代软件工程方法必须是“灵活”的。也就是要求软件工程活动、控制以及文档的编制适合于项目团队和要开发的产品。2.1软件过程框架软件过程框架的内容软件过程框架定义了若干框架活动，为完整的软件开发过程建立了基础。过程框架还全面包括了可用于整个软件过程的活动，称为“普适性活动（UmbrellaActivities）”。

2.1软件过程框架软件过程框架的内容

2.1软件过程框架软件过程框架的内容过程框架：定义了若干框架活动，这些活动适用于所有软件项目。普适性活动：如软件质量保证，软件配置管理和测量，它们贯穿于整个过程模型之中。框架活动：框架中每一个活动都由一组软件工程动作组成，每一个动作又包含一个任务集合。任务集合：每一个集合都由软件工程工作任务、项目里程碑、软件工程产品以及质量保证点组成，使得框架活动适应于不同软件项目的特征和项目组的需求。2.1软件过程框架通用过程框架通用过程框架可适用于绝大多数的软件项目，该框架由沟通、策划、建模、构造和部署5个通用框架活动组成。(1)沟通。这项框架活动包含系统分析员与客户之间大量的交流和协作，还包括需求获取以及其他相关活动。(2)策划。策划活动协助软件开发团队定义全局目标，并为后续的软件工程工作制定计划。策划活动包括一系列管理和技术实践，如描述需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。2.1软件过程框架通用过程框架(3)建模。建模的目的是为了更好地理解需要构建的实体。在软件工程中，要创建两类模型：分析模型和设计模型。分析模型通过描述软件的信息域、功能域及行为域来表达客户的需求；设计模型描述软件架构、用户界面及构件细节，从而帮助开发者高效地开发软件。2.1软件过程框架通用过程框架(4)构造。构造活动包括一系列构件组装、编码和测试任务，从而为向客户和最终用户交付可运行软件做好准备。(5)部署。部署活动是将软件（全部或者完成的部分）交付给用户，用户对其进行评测并给出反馈意见。部署活动包括三个动作：交付、支持和反馈。2.1软件过程框架典型的普适性活动(1)软件项目跟踪和控制：由项目组根据计划来评估项目进度，并且采取必要的措施保证项目按进度计划进行。(2)风险管理：评估可能对项目成果或者产品质量产生影响的风险。(3)软件质量保证：确定和执行用以保证软件质量的活动。(4)正式技术评审：评估软件工程产品，尽量在错误传播到下一个动作或活动之前，发现并清除错误。2.1软件过程框架典型的普适性活动(5)测量：定义和收集过程、项目和产品的度量数据，以帮助团队在发布软件的时候满足客户要求。同时，测量还可与其他框架协同使用。(6)软件配置管理：管理整个软件过程中变更所带来的影响。(7)可复用管理：定义产品复用的标准（包括软件构件），并且建立构件复用机制。(8)工作产品的准备和生产：包括创建产品所必须的活动，如建模、文档、日志、表格和列表等。2.2传统软件过程模型最早提出过程模型是为了改变软件开发的混乱状况，使软件开发更加有序。历史证明这些传统模型为软件工程工作增加了大量有用的结构化设计，并为软件团队提供了有效的路线图。不管采用了何种过程模型，软件工程师通常都会选择一个通用的过程框架，这个框架包含以下一些框架活动：沟通、策划、建模、构建、部署。2.2传统软件过程模型传统软件过程模型包括：瀑布模型（线性顺序模型）快速原型模型RAD模型增量模型螺旋模型喷泉模型2.2传统软件过程模型瀑布模型在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型。传统的瀑布模型如图所示。

2.2传统软件过程模型瀑布模型的特点阶段间具有顺序性和依赖性。其中包含两重含义：①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；②前一阶段的输出文档就是后一阶段的输入文档。2.2传统软件过程模型瀑布模型的特点推迟实现的观点①瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。②清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。2.2传统软件过程模型瀑布模型的特点质量保证的观点①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。2.2传统软件过程模型实际的瀑布模型实际的瀑布模型是带“反馈环”的，如图所示。图中实线箭头表示开发过程，虚线箭头表示维护过程。2.2传统软件过程模型瀑布模型的优点可强迫开发人员采用规范化的方法。严格地规定了每个阶段必须提交的文档。要求每个阶段交出的所有产品都必须是经过验证的。2.2传统软件过程模型瀑布模型的缺点由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。瀑布模型只适用于项目开始时需求已确定的情况。2.2传统软件过程模型快速原型模型快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型如图所示。2.2传统软件过程模型快速原型模型的优点(1)有助于满足用户的真实需求。(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。(3)软件产品的开发基本上是按线性顺序进行。(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。2.2传统软件过程模型快速原型模型的优点(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。(6)快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。2.2传统软件过程模型增量模型增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。2.2传统软件过程模型增量模型增量模型如图所示。

2.2传统软件过程模型增量模型的优点

(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。2.2传统软件过程模型增量构件开发

每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图所示。

2.2传统软件过程模型采用增量模型需注意的问题

(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。(2)软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。2.2传统软件过程模型螺旋模型螺旋模型最初是Boehm于1988年提出来的。该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。2.2传统软件过程模型螺旋模型理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。

2.2传统软件过程模型完整的螺旋模型

2.2传统软件过程模型完整的螺旋模型

在螺旋模型中，软件过程表示成一个螺线，而不是像以往的模型那样表示为一个具有回溯的活动序列。在螺线上的每一个循环表示过程的一个阶段。每个阶段开始时的任务是确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果成功地排除了所有风险，则启动下一步开发步骤，在这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。2.2传统软件过程模型螺旋模型的4项活动

螺线上的每一个循环可划分为4个象限，分别表达了4个方面的活动。(1)目标设定——定义在该阶段的目标，弄清对过程和产品的限制条件，制订详细的管理计划，识别项目风险，可能还要计划与这些风险有关的对策。(2)风险估计与弱化——针对每一个风险进行详细分析，设想弱化风险的步骤。(3)开发与验证——评价风险之后选择系统开发模型。(4)计划——评价开发工作，确定是否继续进行螺线的下一个循环。如果确定要继续，则计划项目的下一个阶段的工作。2.2传统软件过程模型螺旋模型的优点

对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。2.2传统软件过程模型螺旋模型的缺点

螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。2.2传统软件过程模型喷泉模型

喷泉模型是典型的面向对象生命周期模型。“喷泉”一词体现了迭代和无间隙特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在重叠。2.3现代软件过程模型现代软件过程模型包括：基于构件的开发形式化方法模型面向方面的软件开发统一过程敏捷过程2.3现代软件过程模型基于构件的开发模型

基于构件的软件工程（component-basedsoftwareengineering，CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程。2.3现代软件过程模型基于构件的开发模型

Clements对CBSE给出了如下描述。

CBSE正在改变大型软件系统的开发方式。CBSE体现了FrodBrooks和其他人支持的“购买，而非构造”的思想。就如同早期的子程序将程序员从考虑编程细节中解脱出来一样，CBSE将考虑的重点从编码转移到组装软件系统。考虑的焦点是“集成”，而不再是“实现”。这样做的基础是假定在很多大型软件系统中存在足够多的共性，使得开发可复用的构件来满足这些共性是可行的。2.3现代软件过程模型基于构件的开发模型

当软件团队使用传统的需求获取技术确定了待开发软件的系统需求时，该过程开始。体系结构设计完成后，并不立即进行详细设计任务，而是针对每一系统需求考虑以下问题:(1)现有的商品化构件（commercialoff-the-shelf，COTS）是否能够实现该需求？(2)内部开发的可复用构件是否能够实现该需求？(3)可用构件的接口与待构造系统的体系结构是否相容？

2.3现代软件过程模型基于构件的开发模型

2.3现代软件过程模型开发步骤

不考虑构件的开发技术，基于构件的开发模型由以下步骤组成：(1)对于该问题领域的基于构件的可用产品进行研究和评估。(2)考虑构件集成的问题。(3)设计软件架构以容纳这些构件。(4)将构件集成到架构中。(5)进行充分的测试以保证功能正常。2.3现代软件过程模型典型的构件模型(1)OMG/CORBA。对象管理组织发布了公共对象请求代理体系结构（OMG/CORBA），一个对象请求代理提供了多种服务使得可复用构件（对象）可以与其他构件通信。(2)MicrosoftCOM/DCOM/.NET。微软公司开发了构件对象模型（COM），此模型提供了运行于Windows操作系统下的单个应用中使用不同厂商生产的构件的规格说明。(3)SunJavaBean构件。JavaBean构件系统是一个可移植的、平台独立的、使用Java程序设计语言开发的CBSE基础设施。2.3现代软件过程模型形式化方法模型形式化系统开发模型是一种基于形式化数学变换的软件开发方法，它可将系统规格说明转换为可执行的程序。2.3现代软件过程模型与瀑布模型的区别

软件需求规格说明被细化为用数学记号表达的详细的形式化规格说明。设计、实现和单元测试等开发过程由变换开发过程代替。通过一系列变换将形式化规格说明细化成为程序。这种细化的过程如图所示。2.3现代软件过程模型面向方面的软件开发

面向方面的软件开发（aspect-orientedsoftwaredevelopment，AOSD）通常称为面向方面编程（aspect-orientedprogamming，AOP），是相对较新的一种软件工程模型，为定义、说明、设计和构建方面（aspect）提供过程和方法。2.3现代软件过程模型随着现代计算机系统变得更加复杂，某些关注点(客户需要的属性或者技术兴趣点)体现在了整个架构设计中。某些关注点是系统的高层属性（例如安全性，容错能力），还有一些关注点影响了系统的功能（如商业规则的应用等）。如果某个关注点涉及到系统多个方面的功能、特性和信息时，这些关注点通常称为横切关注点（crosscuttingconcern）。2.3现代软件过程模型方面需求(aspectualrequirement)定义了那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发为定义、说明、设计和构建方面(aspect)提供过程和方法，是对横切关注点局部表示的一种机制。2.3现代软件过程模型Grundy在面向方面的构件工程(Aspect-OrientedComponentEngineering,AOCE)中对方面的讨论：AOCE对纵向分解的软件构件进行横向切片，称为“方面”(Aspect)，以表示构件功能及非功能的横切属性。系统的方面包括用户接口、协同工作、发布、持续性、存储器管理、事务处理、安全、完整性等等。2.3现代软件过程模型统一过程

由Booch、Jacobson及Rumbaugh提出，统一过程模型如图所示。

2.3现代软件过程模型统一过程的工作流

在统一过程中，有5个核心工作流。

①需求工作流。需求工作流的目标是确保开发人员构建正确的系统。②分析工作流。分析工作流的目标是分析和细化需求。③设计工作流。设计工作流是对分析工作流的细化，直到设计模型可以被程序员实现为止。④实现工作流。实现工作流的目标是：用选择的实现语言实现目标信息系统。⑤测试工作流。测试工作流是质量保证组的职责。2.3现代软件过程模型统一过程的阶段

统一过程有4个阶段，分别是初始阶段、细化阶段、构造阶段和移交阶段。①初始阶段。初始阶段主要关注项目计划和风险评估，其目的是确定是否值得开发目标信息系统。②细化阶段。细化阶段关心定义系统的总体框架，其目标是：细化初始需求（用况）、细化体系结构、监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划。③构造阶段。构造阶段是建立系统，构造信息系统的第1个具有操作质量的版本，以能够交付给客户进行测试的版本结束，有时称为测试版本。④移交阶段。移交阶段包含测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满足客户的需求。

2.3现代软件过程模型敏捷过程模型

2001年，KentBeck等17名编程大师发表“敏捷软件开发”宣言：

我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认为：个体和交互胜过过程和工具；可工作软件胜过宽泛的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。

2.3现代软件过程模型敏捷过程模型

对于敏捷开发，IvarJacobson给出了下面非常有用的论述。

“敏捷（Agility）已经成为当今现代软件过程的一个时髦用词。每个人都是敏捷的，敏捷团队是能够适当响应变化的灵活团队。变化就是软件开发本身，软件构建有变化、团队成员在变化、使用新技术会带来变化，各种变化都会对开发的软件产品以及项目本身造成影响。我们必须接受的是支持变化的意识，它应当根植于软件开发中的每一件事中，因为这是软件的心脏与灵魂。敏捷团队意识到软件是团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。”2.3现代软件过程模型敏捷过程

任何一个敏捷过程都可以由所强调的3个关键假设识别出来，这3个假设可适用于大多数软件项目。(1)提前预测哪些需求是稳定的、哪些需求会变化非常困难。同样的，预测项目进行中客户优先级的变化也很困难。(2)对很多软件，设计和构建是交错进行的。事实上，两种活动应当顺序开展以保证通过构建实施来验证设计模型，而在通过构建验证之前很难估计应该设计到什么程度。(3)从制订计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。2.3现代软件过程模型极限编程

极限编程（eXtremeProgramming，XP）使用面向对象方法作为推荐的开发范型。XP包含了策划、设计、编码和测试4个框架活动的规则和实践。2.3现代软件过程模型极限编程的框架活动

①策划。策划活动开始于建立健全描述待开发软件特征与功能需求的“故事”（也称为用户故事）。②设计。XP设计严格遵循KIS（keepitsimple，保持简洁）原则，通常更愿意使用简单设计而不是更为复杂的表述。③编码。XP推荐在故事开发和基本设计完成之后，团队不应直接开始编码，而是开发一系列用于检测本次（软件增量）发行包括所有故事的单元测试，一旦建立起单元测试，开发者就可以更集中精力于必须实现的内容以通过单元测试。

④测试。2.3现代软件过程模型自适应软件开发

自适应软件开发（adaptivesoftwaredevelopment，ASD）是由JimHighsmith提出的；它可作为构建复杂软件和系统的一项技术，其基本概念着眼于人员合作和团队自组织。2.3现代软件过程模型自适应软件开发模型

2.3现代软件过程模型自适应软件开发的阶段

(1)思考：思考过程中，开始项目规划并完成自适应循环策划。自适应循环策划通过使用项目开始信息，来确定项目所需的一系列软件增量发布循环。(2)协作：受激励的人员以超越其聪明才智和独创成果的方式共同工作，协作方法是所有敏捷方法中不断重现的主旋律。(3)学习：当ASD团队成员开始开发作为自适应循环一部分的构件时，其重点是在完成循环的过程中学习尽可能多的东西。2.4软件过程成熟度模型软件过程成熟度模型也称软件能力成熟度模型CMM（CapabilityMaturityModel），它并不是一个软件生命周期模型，而是改进软件过程的一种策略。近20年来，很多人试图通过采用新的软件开发技术来解决在软件生产率和软件质量等方面存在的问题，但效果并不十分令人满意。这一现象促使人们进一步考察软件过程，从而发现对软件过程的管理不尽人意。事实表明，在无规则和混乱的管理之下，先进的技术和工具并不能发挥应有的作用。

1987年，CMU（美国卡内基•梅隆大学）的SEI（软件工程研究所）发表了一个简短的软件过程成熟度框架，其后在Humphrey《管理软件过程》一书中进行了扩充。书中提出了两种方法：一种是软件过程评估和软件能力评价，另一种是成熟度问卷，用于评价软件过程的成熟度。

1991年发布CMM1.0版本;1993年发布CMM1.1版本；

1997年发布CMM2.0版本。

2.4软件过程成熟度模型2.4软件过程成熟度模型

1997年SEI开始研究CMMI，其任务是将已有的CMM模型结合成一个模型。

2001年12月发布CMMI1.1版本;2006年发布CMMI1.2版本。不成熟过程与成熟过程的对比角色与职责不成熟过程成熟过程没有明确规定角色和职责每个人做自己认为要做的事常会发生重叠和不清楚的所属关系和责任明确规定角色和职责相互关系无重叠有明确的目标和测量方法能够体现持续改进过程的机制不成熟过程与成熟过程的对比处理变更的方式不成熟过程成熟过程每个人都按自己的想法做事遵循一个规划好的文件化过程可分享取得的经验不成熟过程与成熟过程的对比对发生问题的反应不成熟过程成熟过程无秩序的混乱现象随处可见“救火”方式解决出现问题的情况经常发生每个人都想当英雄根据已有的知识和专业规则对发生的问题进行分析和处理不成熟过程与成熟过程的对比可靠性不成熟过程成熟过程有时延迟交付产品或超出预算如有估算也不可靠估算准确项目得到有效的控制和管理目标一般能够达到对工作人员的奖励不成熟过程成熟过程奖励的对象是“救火”队员“如果你第一次就把事情做好了，那是你的本分，没有人理睬，但你若先把事情搞乱，然后再去解决，你就成了英雄。”_Deming,1986奖励那些生产高质量产品的团队奖励那些防火者而不是救火者不成熟过程与成熟过程的对比预见性不成熟过程成熟过程质量不可把握，它依赖于个人进度和预算不能根据以往的经验确定项目的进度和产品的质量均可预见进度和预算可根据以往项目的经验确定，并且是符合实际的不成熟过程与成熟过程的对比CMMCMM将软件过程的成熟度分为5个等级，每一个成熟程度级别由几个关键过程区域组成，较为全面地描述和分析软件过程能力的发展程度，一个软件开发组织可采用一系列改良步骤向更高的成熟度等级迈进。

这五个级别主要特征为：(1)初始级。软件过程的特点是杂乱无章，有时甚至混乱，几乎没有明确定义的步骤，成功完全依赖于个人的能力和行为。(2)可重复级。建立了基本的项目管理过程来跟踪成本、进度和功能。建立了必要的过程规范，使得可以重复以前类似项目所取得的成功。(3)确定级。用于管理工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件开发过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。(4)可管理级。制定了软件过程和产品质量的详细的度量标准。软件过程和产品的质量都被开发组织的成员所理解和控制。(5)优化级。加强了定量分析，通过来自过程质量反馈和来自新观念、新科技的反馈使过程能不断持续地改进。

软件过程能力成熟度等级

CMM每个成熟级别的可视性输出1输入输出2输入输出3输入输出4输入输出5输入初始级的可视性输出1输入对管理人员或用户而言，只能看到项目的要求和项目的结果，整个软件过程是一个黑箱，无法看到项目的软件过程。当然无法确定开发活动的阶段。项目开发如同黑色魔术，处于一种不可控方式下进行。管理人员不了解软件，要想了解某个具体项目的进度状况，或制定项目计划都是非常困难的。用户只有在软件交付时，才能评估软件产品是否符合需求。可重复级的可视性输出2输入开发过程好像一系列的黑盒子。可以按阶段来进行软件开发的控制和管理。这种管理控制允许在某些定义的时段（里程碑）上，可使项目活动情况可视。但在黑盒内部发生的事，仍然看不见。因此，用户的需求和工作产品只在一定程度上可以控制。这时候可以建立基本的项目管理活动，在过程的检查点上对产品进行检查，以考察过程是否正常进行，或对发生的问题作出反应。用户也可在检查点上了解项目的进展。确定级的可视性输出3输入

可以看到盒子中的内部结构，例如项目所定义的软件过程的任务。这种内部结构表示软件开发组织将已有的标准软件过程应用于特定项目时的情况。因此，管理人员在理解自己在过程中的责任和任务情况下，在一定程度上能和各种软件开发活动进行交互。管理人员能预见可能发生的风险，为此作一定准备。用户能得到较为准确而快速的状态报告。管理级的可视性输出4输入在这一级可以定量地指导和控制所定义的软件过程。管理者可以根据客观的度量，预见过程中的经费支出和其他情况。定量地、有目标地做出决定。当软件过程的不稳定性减少时，预见结果的能力也增大，变得更精确。用户能定量地理解过程的能力及存在的风险。优化级的可视性输出5输入

为了提高生产率和质量，从组织上已经有控制地、不断地、系统地尝试新的改进方法。自觉地识别不够有效和可能出错的活动，并将其改正和替换，以达到更进一步的效果。工作成就的标准不再是达到里程碑的要求，而是减少错误率。管理人员可以有能力来估计及定量跟踪变化的影响和效果。用户和开发组织合作关系良好。可重复级（2）初级（1）软件配置管理软件质量保证软件子合同管理软件项目的跟踪及监督软件项目计划需求管理确定级（3）伙伴审查组间协调软件产品工程综合软件管理培训程序组织的过程定义组织的过程重点管理级（4）软件质量管理定量的过程管理优化级（5）过程变动管理技术变动管理缺陷防范各成熟度级的关键过程区域软件过程评估。是用来判断一个组织当前的软件过程的能力状态，判断一个组织所面对的更高层次上的与软件过程相关的课题，以及利用组织的鼎力支持来对该组织的软件过程进行有效的改进。软件能力评价。是用来判断有意承担某个软件项目的软件组织（也就是投标者）的软件过程能力，或是判断已进行的软件过程所处的状态是否正确或是否正常。CMM的应用选择工作组成熟度问卷CMM样例结果分析现场访问面谈及文档审查发现基于CMM关键过程区域的基本概况⑵⑴⑶⑹⑸⑷软件过程评估和软件能力评价的步骤CMMI集成一些科目的成熟度模型称为CMMI。这里的科目可以是系统工程、软件工程等。CMMI的能力等级有6级：从0到5。第0级：不完全级（Incomplete）。过程域（如需求管理）没有实施，或者已经实施但未达到CMMI一级成熟度所规定的所有目标。第1级：已执行级（Performed）。CMMI中定义的所有过程域的目标都已经实现。为了获得相应工作产品的任务都已经执行。第2级：已管理级（Managed）。所有第一级的标准都已经达到。另外，所有与过程域相关的工作都符合组织的规程；工作人员都有足够的资源完成工作；共利益者都积极地参与到要求的过程域；所有任务和产品都被“监督、控制和评审；并评估是否与过程描述相一致”。第3级：已定义级（Defined）。所有第二级的标准都已经达到。另外，根据组织剪裁准则，对其标准过程进行了剪裁，剪裁过的过程对组织的过程资产增添了新的内容，如工作产品、测量和其它过程改进信息等。CMMI第4级：定量管理级（QuantitativelyManaged）。所有第三级的标准都已经达到。另外，通过采用测量和定量的评估等手段，对过程域进行控制和不断改进。“已经建立起来对质量和过程性能的定量指标，并作为过程管理的标准。”。第5级：优化级（Optimized）。所有第四级的标准都已经达到。另外，采用定量（统计）的方法调整和优化过程域，以满足用户不断变更的需求，并持续地提高过程域的有效性。CMMICMM虽然提供了一个有力的软件过程改进框架，却只告诉我们"应该做什么"，而没有告诉我们"应该怎样做"，并未提供有关实现关键过程域所需要的具体知识和技能。为了弥补这个欠缺，Humphrey主持开发了个体软件过程(PersonalSoftwareProcess，PSP)。CMMI2.5个体软件过程个体软件过程（PSP,personalsoftwareprocess）由美国Carnegie-Mellon大学软件工程研究所的WattsS.Humphrey领导开发的。PSP的经典著作：《ADisciplineforsoftwareEngineering》,addison-Wesley,1995.PSP的简化版：《IntroductiontoThePersonalsoftwareProcess》,addison-Wesley,1997.PSP过程模型定义了五个框架工作活动：策划：策划活动从需求活动分离出来，并根据需求估算项目的规模和所需资源，并且预测缺陷数目。所有的度量都用工作表或是模板记录。最后，识别开发任务，并建立项目进度计划。高层设计：建立每个构件的外部规格说明，并完成构件设计。如果有不确定的需求，则构建原型系统。记录和跟踪所有问题。2.5个体软件过程高层设计评审：使用正式的验证方法来发现设