［软件工程］　软件项目管理

软件项目管理

工程项目的失败主要不是技术和经验，是因为管理不善→软件项目管理。
　　所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。
　　软件项目管理过程从一组项目计划活动开始，而制定计划的基础是工作量估算和完成期限估算。
　　为了估算项目的工作量和完成期限，首先需要估算软件的规模。

一、估算软件规模

（一） 代码行技术

代码行技术是比较简单的定量估算软件规模的方法。这种方法依据以往开发类似产品的经验和历史数据，估计实现一个功能所需要的源程序行数。
　　当有以往开发类似产品的历史数据可供参考时，用这种方法估计出的数值还是比较准确的。把实现每个功能所需要的源程序行数累加起来，就可得到实现整个软件所需要的源程序行数。

为了使得对程序规模的估计值更接近实际值，可以由多名有经验的软件工程师分别做出估计。
　　　　　　　　　　　　　　　　　　L=a+46m+b (13.1)
　　每个人都估计：a_{程序的最小规模、b}最大规模；m~最可能的规模。再用上式计算程序规模的估计值。
　　用代码行技术估算软件规模时，当程序较小时常用的单位是代码行数（LOC），当程序较大时常用的单位是千行代码数（KLOC）。

代码行技术的主要优点：容易计算行数。
　　代码行技术的缺点是：源程序代表整个软件的规模不太合理；代码行数于实现的语言有关；不适用于非过程语言。
　　为了克服代码行技术的缺点，人们又提出了功能点技术。

（二） 功能点技术

根据对软件信息域特性和软件复杂性的评估结果，估算软件规模。
这种方法用功能点（FP）为单位度量软件规模。

1. 信息域特性

功能点技术定义了信息域的5个特性，分别是输入项数(Inp)、输出项数(Out)、查询数(Inq)、主文件数(Maf)和外部接口数(Inf)。下面讲述这5个特性的含义。

2. 估算功能点的步骤

用下述3个步骤，可估算出一个软件的功能点数
（即软件规模）

（1）第1步：计算未调整的功能点数UFP

把产品信息域的每个特性(Inp、Out、Inq、Maf、
　　Inf)都分类为简单级、平均级或复杂级，并根据其等级为每个特性分配一个功能点数（例如：一个简单级的输入项分配3个功能点，一个平均级的输入项分配4个功能点，一个复杂级的输入项分配6 个功能点）。
　　然后，用下式计算未调整的功能点数UFP：
　　　　　　　　　　UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×
　　　　　　　　　　　　　　　　　　　　　Inf
　　其中，ai(1≤i≤5)是信息域特性系数，其值由相应特性的复杂级别决定，如表13.1所示。

（2）第2步：计算技术复杂性因子TCF

度量对软件规模有影响的14种技术因素：如高处理率、性能标准（例响应时间）、联机更新等
（见表13.2中列出了全部技术因素），用Fi(1≤i≤14)代表这些因素。
　　根据软件的特点，为每个因素分配一个从0~5的值（0为不存在或对软件规模无影响，5有很大影响），然后用下式计算技术因素对软件规模的综合影响程度DI： 14
　　　　　　　　　　　　　　　DI =Fi i=1

计算技术复杂性因子TCF：
　　　　TCF=0.65+0.01×DI
因为DI的值在0~70之间，所以TCF的值在
　　　　　0.65~1.35之间。

（3）第3步：计算功能点数FP

FP=UFP×TCF
　　　　　功能点数与所用的编程语言无关。
　　优点：功能点技术比代码行技术更合理一些；
　　缺点：在判断信息域特性复杂级别和技术因素的影响程度时，存在着相当大的主观因素。

二、 工作量估算

工作量是软件规模（KLOC或FP）的函数，工作量的单位通常是人月(pm)。
工作量估算模型只适应于特定的软件项目，没有一个估算模型可以适用于所有类型的软件和开发环境。
具体选优那种模型，视软件类型而定。

（一） 静态单变量模型

这类模型的总体结构形式如下：
　　　E=A+B×(ev)C
其中，A、B和C是由经验数据导出的常数，E是以人月为单位的工作量，ev是估算变量(KLOC 或FP)。下面给出几个典型的静态单变量模型。

1. 面向KLOC的估算模型

(1) Walston_Felix模型
　　　E=5.2×(KLOC)0.91
(2) Bailey_Basili模型
　　　E=5.5+0.73×(KLOC)1.16
(3) Boehm简单模型 E=3.2×(KLOC)1.05
(4) Doty模型（在KLOC>9时适用）
　　　E=5.288×(KLOC)1.047

2. 面向FP的估算模型

(1) Albrecht & Gaffney模型
　　　E=-13.39+0.0545FP
(2) Maston,Barnett和Mellichamp模型
　　　E=585.7+15.12FP

从上面各模型，对于相同的KLOC或FP值，不同模型估算将得出不同的结果。
　　原因：这些模型多数都是仅根据若干应用领域中有限个项目的经验数据推导出来的，适用范围有限。
　　因此，必须根据当前项目的特点选择适用的估算模型，并且根据需要适当地调整（例如，修改模型常数）估算模型。

（二） 动态多变量模型

动态多变量模型也称为软件方程式，该模型把工作量(E)看作是软件规模(LOC)和开发时间(t)这两个变量的函数：
　　　　 E=(LOC×B0.333/P)3×(1/t)4 (13.2)
　　E~以人月或人年为单位的工作量； t~以月或年为单位的项目持续时间；
　　B_{特殊技术因子，它随着对测试、质量保证、文档及管理技术的需求的增加而缓慢增加，对于较小的程序（KLOC=5}15），B=0.16，对于超过70 KLOC的程序，B=0.39;

P是生产率参数，它反映了下述因素对工作量的影响：总体过程成熟度及管理水平；使用良好的软件工程实践的程度；使用的程序设计语言的级别；软件环境的状态；软件项目组的技术及经验；应用系统的复杂程度。

开发实时嵌入式软件时，P的典型值为2000；开发电信系统和系统软件时，P=10000；
　　对于商业应用系统来说，P=28000。
　　可以从历史数据导出适用于当前项目的生产率参数值。
　　从（13.2）式可以看出，开发同一个软件（即 LOC固定）的时候，如果把项目持续时间延长一些，则可降低完成项目所需的工作量。

（三） COCOMO2模型

COCOMO~COnstructive COst MOdel，构造性成本模型。
　　1981年Boehm在《软件工程经济学》中首次提出了COCOMO模型，1997年Boehm等人提出的COCOMO2模型，是原始的COCOMO模型的修订版，它反映了十多年来在成本估计方面所积累的经验。
　　本教材在介绍COCOMO2模型时，比较 COCOMO模型进行。

COCOMO2给出了3个层次的软件开发工作量估算模型，在估算工作量时，对软件细节考虑的
　　详尽程度逐级增加。3个层次的估算模型分别是：
　　　（1）应用系统组成模型
这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时大量使用已有的构件。
　　　（2）早期设计模型这个模型适用于体系结构设计阶段。
　　　（3）后体系结构模型
这个模型适用于完成体系结构设计之后的软件开发阶段。

以后体系结构模型为例介绍COCOMO2模型: 将软件开发工作量(E)表示成代码行数(KLOC) 的非线性函数： 17
　　　　　 E = aKLOCb  fi (13.3)
　　　　　i=1
　　E~开发工作量(以人月为单位) a~模型系数 KLOC~千行源代码 b~模型指数 fi(i=1₁₇₎成本因素。

每个成本因素都根据它的重要程度和对工作量影响大小被赋予一定数值（称为工作量系数）. 这些成本因素对任何一个项目的开发工作量都有影响，成本因素包括：产品因素、平台因素、人员因素和项目因素等4类。
　　表13.3列出了COCOMO2模型使用的成本因素及与之相联系的工作量系数。

与原始的COCOMO模型相比，COCOMO2模型使用的成本因素有变化，反映了在过去十几年中软件行业取得的巨大进步。
　　（1） 新增加了4个成本因素：可重用性、需要的文档量、人员连续性（即人员稳定程度）和多地点开发。这个变化表明，这些因素对开发成本的影响日益增加。
　　（2） 略去了原始模型中的2个成本因素（计算机切换时间和使用现代程序设计实践）。
现在，开发人员普遍使用工作站开发软件，批处理的切换时间已经不再是问题。而“现代程序设计实践”已经发展成内容更广泛的“成熟的软件工程实践”的概念，并且在COCOMO2工作量方程的指数b中考虑了这个因素的影响。
　　（3）某些成本因素（分析员能力、平台经验、语言和工具经验）对生产率的影响（即工作量系数最大值与最小值的比率）增加了，另一些成本因素（程序员能力）的影响减小了。
为了确定工作量方程中模型指数b的值：
COCOMO模型：把软件开发项目划分成组织式、半独立式和嵌入式这样3种类型，并指定每种项目类型所对应的b值(分别是1.05,1.12,1.20);
COCOMO2模型：使用5个分级因素Wi(1≤i≤5), 每个因素都划分成从甚低（Wi=5)到特高（Wi=0) 的6个级别，然后用下式计算b的数值：
　　　　(13.4)
b的取值范围为1.01~1.26。
　　这种分级模式比原始COCOMO模型的分级模式更精细、更灵活。

COCOMO2使用的5个分级因素如下所述：
　　（1） 项目先例性
反映项目的新奇程度。诸如开发类似系统的经验，需要创新体系结构和算法，以及需要并行开发硬件和软件等因素的影响，都体现在这个分级因素中。
　　（2） 开发灵活性
反映出为了实现预先确定的外部接口需求及为了及早开发出产品而需要增加的工作量。
　　（3） 风险排除度反映了重大风险已被消除的比例。
　　（4） 项目组凝聚力
表明了开发人员相互协作时可能存在的困难。这个因素反映了开发人员在目标和文化背景等方面相一致的程度，以及开发人员组成一个小组工作的经验。
　　（5）过程成熟度
反映了按照能力成熟度模型（见13.7节）度量出的项目组织的过程成熟度。

三、 进度计划

任何工作均可分为若干个小任务，有一些任务处于“关键路径”（13.3.5）之外，对整个项目的完成时间影响小；一些任务处于关键路径之中，对整个项目的完成日期影响大。
　　项目管理者的目标识别并跟踪关键任务的进展状况，以保证能及时发现拖延进度的情况。
　　为达到上述目标，管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。进度是需要随着项目进展不断细化、完善的。

（一） 估算开发时间

估算总工作量之后需要回答：项目的开发时间？对于一个估计工作量为20人月的项目，可能想出下列几种进度表：
　　1个人用20个月完成该项目；
　　4个人用5个月完成该项目；
　　20个人用1个月完成该项目。
　　不现实，软件开发时间与人数之间并不是简单的反比关系。
　　通常，成本估算模型也同时提供了估算开发时
间T的方程。例如：
　　(1) Walston_Felix模型
T=2.5E0.35
　　(2) 原始的COCOMO模型
T=2.5E0.38
　　(3) COCOMO2模型
T=3.0E0.33+0.2×(b-1.01)
　　(4) Putnam模型
T=2.4E1/3
　　E~开发工作量（以人月为单位）， T~开发时间（以月为单位）。

为了缩短开发时间应该增加从事开发工作的人数。但是，经验告诉我们，随着开发小组规模扩大，个人生产率将下降，以致开发时间与从事开发工作的人数并不成反比关系。
　　出现上述现象主要有下述两个原因：
　　　当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了通信开销。

如果在开发过程中增加小组人员，则最初一段时间内项目组总生产率不仅不会提高反而会下降。
　　这是因为新成员在开始时不仅不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。
　　
综合上述两个原因，存在被称为Brooks规律的下述现象：向一个已经延期的项目增加人力，只会使得它更加延期。

项目组规模与项目组总生产率的关系。
　　项目组成员之间的通信路径数，由项目组人数和项目组结构决定。
　　如果项目组共有P名组员，每个组员必须与所有其他组员通信以协调开发活动，则通信路径数为
　　　　　P(P-1)/2。
　　如果每个组员只需与另外一个组员通信，则通信路径数为P-1。
　　因此，通信路径数大约在P~P2/2的范围内变化。即在项目组中，通信路径数为Pα，其中　　　　1<α<2。

对一个组员，他与其他组员通信的路径数在1~
　　　　（P-1）的范围内变化。
如果不与任何人通信时个人生产率为L，而且每条通信路径导致生产率减少l，则组员个人平均生产率为
　　　　　Lr=L-l(P-1)r (13.5)
其中，r是对通信路径数的度量，0<r≤1(假设至少有一名组员需要与一个以上的其他组员通信，因此r>0)。

对于一个规模为P的项目组，从（13.5）式导出项目组的总生产率为
　　　　　Ltot=P(L-l(P-1)r) (13.6)
对于给定的一组L，l和r的值，总生产率Ltot是项目组规模P的函数。随着P值增加，Ltot将从0增大到某个最大值，然后再下降。因此，存在一个最佳的项目组规模Popt，这个规模的项目组其总生产率最高。

假设个人最高生产率为500LOC/月(即L=500)，每条通信路径导致生产率下降10%(即l=50)。如果每个组员都必须与组内所有其他组员通信(r=1)，则项目组规模与生产率的关系列在表13.4中，可见，在这种情况下项目组的最佳规模是5.5人，即
　　　　Popt=5.5。
Boehm根据经验指出，软件项目的开发时间最多可以减少到正常开发时间的75%。
如果要求一个软件系统的开发时间过短，则开发成功的概率几乎为零。

（二） Gantt图

假设有一座陈旧的矩形木板房需要重新油漆。
　　这项工作必须分3步完成：刮掉旧漆、刷上新漆、清除溅在窗户上的油漆。
　　假设共15名工人工作，然而工具却很有限：只有5把刮旧漆用的刮板，5把刷漆用的刷子，5把清除溅在窗户上的油漆用的小刮刀。怎样安排才能使工作进行得更有效呢?
　　一种做法是首先刮掉四面墙壁上的旧漆，然后给每面墙壁都刷上新漆，最后清除溅在每个窗户上的油漆。显然这是效率最低的做法，因为总共有15名工人，然而每种工具却只有5件，这样安排工作在任何时候都有10名工人闲着没活干。
　　应该采用“流水作业法”：
　　首先由5名工人用刮板刮掉第1面墙上的旧漆(这时其余10名工人休息)，当第1面墙刮净后，另外5 名工人立即用刷子给这面墙刷新漆(与此同时拿刮板的5名工人转去刮第2面墙上的旧漆)，一旦刮旧漆的工人转到第3面墙而且刷新漆的工人转到第2 面墙以后，余下的5名工人立即拿起刮刀去清除溅在第1面墙窗户上的油漆，……。这样安排每个工人都有活干，因此能够在较短的时间内完成任务。
　　假设木板房的第2、4两面墙的长度比第1、3两面墙的长度长一倍，此外，不同工作需要用的时间长短也不同，刷新漆最费时间，其次是刮旧漆，清理需要的时间最少。表13.5列出各工序时间。图13.1中的Gantt图描绘上述流水作业过程：
　　时间为零时开始刮第1面墙上的旧漆，两小时后转去刮第2面墙，同时另5名工人开始给第1面墙刷新漆，每当刷完一面墙新漆后，第3组的5名工人立即清除窗户上的漆。从图13.1可以看出12小时后刮完旧漆，20小时后完成刷漆工作，再过2小时后清理工作，全部工程在22小时后结束。如果用前述的第一种做法，则需要36小时。

　　　　　　　　　　　　　图13.1 旧木板房刷漆工程的Gantt图

（三） 工程网络

Gantt图具有直观简明和容易掌握、容易绘制的优点，但是Gantt图也有3个主要缺点：
　　　(1) 不能显式地描绘各项作业彼此间的依赖关系；
　　　(2) 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象；
　　　(3) 计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。
工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及每项作业的开始时间和结束时间，此外，它还显式地描绘各个作业彼此间的依赖关系。

图13.2 旧木板房刷漆工程的工程网络

在工程网络中的一个事件，如果既有箭头进入又有箭头离开，则它既是某些作业的结束又是另一些作业的开始。例如，图13.2中事件2既是作业
　　1—2(刮第1面墙上的旧漆)的结束，又是作业2—3(刮第2面墙上旧漆)和作业2—4(给第1面墙刷新漆) 的开始。
　　也就是说，只有第1面墙上的旧漆刮完之后，才能开始刮第2面墙上旧漆和给第1面墙刷新漆这两个作业。
　　因此，工程网络显式地表示了作业之间的依赖关系。

在图13.2中还有一些虚线箭头，它们表示虚拟作业，也就是事实上并不存在的作业。
　　引入虚拟作业是为了显式地表示作业之间的依赖关系。例如，事件4既是给第1面墙刷新漆结束，又是给第2面墙刷新漆开始(作业4—6)。但是，在开始给第2面墙刷新漆之前，不仅必须已经给第1 面墙刷完了新漆，而且第2面墙上的旧漆也必须已经刮净(事件3)。也就是说，在事件3和事件4之间有依赖关系，或者说在作业2—3(刮第2面墙上旧漆)和作业4—6(给第2面墙刷新漆)之间有依赖关系，虚拟作业3—4明确地表示了这种依赖关系。注意，虚拟作业既不消耗资源也不需要时间。

（四） 估算工程进度

画出类似图13.2那样的工程网络之后，系统分析员就可以借助它的帮助估算工程进度了。为此需要在工程网络上增加一些必要的信息。
　　其次，为每个事件计算下述两个统计数字：最早时刻EET和最迟时刻LET。这两个数字将分别写在表示事件的圆圈的右上角和右下角，如图13.3 左下角的符号所示。

　　　　　　　　　　图13.3 旧木板房刷漆工程的完整的工程网络

（五） 关键路径

图13.3中有几个事件的最早时刻和最迟时刻相同，这些事件定义了关键路径，在图中关键路径用粗线箭头表示。关键路径上的事件(关键事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。
　　工程项目的管理人员应该密切注视关键作业的进展情况，如果关键事件出现的时间比预计的时间晚，则会使最终完成项目的时间拖后；如果希望缩短工期，只有往关键作业中增加资源才会有效果。

（六）机动时间

不在关键路径上的作业有一定程度的机动余地——实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些，而并不影响工程的结束时间。一个作业可以有的全部机动时间等于它的结束事件的最迟时刻减去它的开始事件的最早时刻，再减去这个作业的持续时间：
　　机动时间=(LET)结束-(EET)开始-持续时间对于前述油漆旧木板房的例子，计算得到的非关键作业的机动时间列在表13.6中。

在工程网络中每个作业的机动时间写在代表该项作业的箭头下面的括弧里(参看图13.3)。
在制定进度计划时仔细考虑和利用工程网络中的机动时间，往往能够安排出既节省资源又不影
响最终竣工时间的进度表。在图13.4中的Gantt图描绘了其中的一种方案。

　　　　　　　　　　图13.4 旧木板房刷漆工程改进的Gantt图之一

这个简单例子明显说明了工程网络比Gantt图优越的地方：它显式地定义事件及作业之间的依赖关系，Gantt图只能隐含地表示这种关系。但是Gantt图的形式比工程网络更简单更直观，为更多的人所熟悉，因此，应该同时使用这两种工具制订和管理进度计划，使它们互相补充取长补短。

四、 人员组织

软件项目成功的关键是要有高素质的软件开发人员。如何组织项目组（人员组织）是一个重要的管理问题，具有较高生产率，能够按预定的进度计划完成所承担的工作。
　　现有的软件项目组的组织方式很多，通常，组织软件开发人员的方法，取决于所承担的项目的特点、以往的组织经验以及管理者的看法和喜好。下面介绍3种典型的组织方式。

（一） 民主制程序员组

民主制程序员组的一个重要特点是，小组成员完全平等，享有充分民主，通过协商做出技术决策。
　　适合于程序设计小组的人数不能太多,由于小组内有n个成员，可能的通信信道共有n(n-1)/2条。
　　此外,通常不能把一个软件系统划分成大量独立的单元。
　　一般说来，程序设计小组的规模应该比较小,以2～8名成员为宜。
　　民主制程序员组的主要优点是，组员们对发现程序错误持积极的态度，这种态度有助于更快速地发现错误，从而导致高质量的代码。
　　如果组内多数成员是经验丰富技术熟练的程序员,那么上述非正式的组织方式可能会非常成功。
　　也有严重缺点：由于没有明确的权威指导开发工程的进行,组员间将缺乏必要的协调,最终可能导致工程失败。

（二） 主程序员组

美国IBM公司在20世纪70年代初期开始采用主程序员组的组织方式。采用这种组织方式主要出于下述几点考虑：
　　　(1) 软件开发人员多数比较缺乏经验；
　　　(2) 程序设计过程中有许多事务性的工作，例如，大量信息的存储和更新；
　　　(3) 多渠道通信很费时间，将降低程序员的生产率。
主程序员组用经验多、技术好、能力强的程序员作为主程序员，同时，利用人和计算机在事务性工作方面给主程序员提供充分支持，而且所有通信都通过一两个人进行。

（三） 现代程序员组

民主制程序员组的一个主要优点，是小组成员都对发现程序错误持积极、主动的态度。
　　主程序员对每行代码的质量负责，因此，他必须参与所有代码审查工作。
　　由于主程序员同时又是负责对小组成员进行评价的管理员，他参与代码审查工作就会把所发现的程序错误与小组成员的工作业绩联系起来，从而造成小组成员出现不愿意发现错误的心理。
　　很难找到既是高度熟练的程序员又是成功的管理员的人，取消主程序员的行政管理工作。
　　于是，实际的“主程序员”应该由两个人共同担任：一个技术负责人，负责小组的技术活动；一个行政负责人，负责所有非技术性事务的管理决策。

明确划分技术组长和行政组长的管理权限是很重要的。

由于程序员组成员人数不宜过多，当软件项目规模较大时，应该把程序员分成若干个小组，采用图13.7所示的组织结构。

把民主制程序员组和主程序员组的优点结合起来的另一种方法，是在合适的地方采用分散做决定的方法，如图13.8所示。

这样做有利于形成畅通的通信渠道，以便充分发挥每个程序员的积极性和主动性，集思广益攻克技术难关。
　　尽管这种组织方式适当地发扬了民主，但是上下级之间的箭头（即管理关系）仍然是向下的，也就是说，是在集中指导下发扬民主。显然，如果程序员可以指挥项目经理，则只会引起混乱。

五、质量保证

（一） 软件质量

软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。
　　(1)软件需求是度量软件质量的基础，与需求不一致就是质量不高。
　　(2)指定的开发标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致软件质量不高。
　　(3) 如果软件满足明确描述的需求，但却不满足隐含的需求（例如，软件应该是容易维护的），那么软件的质量仍然是值得怀疑的。

图13.9 软件质量因素与产品活动的关系

六、 软件配置管理

软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来：
　　①标识变化；
　　②控制变化；
　　③确保适当地实现了变化；
　　④向需要知道这类信息的人报告变化。
　　　软件配置管理的目标是，使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。

（一） 软件配置

1. 软件配置项软件过程的输出信息可以分为3类：
   　　　　①计算机程序（源代码和可执行程序）；
   　　　　②描述计算机程序的文档；
   　　　　③数据（程序内包含的或在程序外的）。
   　　上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。
2. 基线
   IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。
   　　基线就是通过了正式复审的软件配置项。在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程（称为规程）来评估、实现和验证每个变化。

（二） 软件配置管理过程

软件配置管理主要有5项任务：标识版本控制变化控制配置审计和报告。

七、能力成熟度模型

美国卡内基梅隆大学软件工程研究所在美国国防部资助下于20世纪80年代末建立的能力成熟度模型（capability maturity model，CMM)，是用于评价软件机构的软件过程能力成熟度的模型。
软件过程的管理不尽人意，在无规则和混乱的管理之下，先进的技术和工具并不能发挥出应有的作用。
　　CMM有助于软件开发机构建立一个有规律的、成熟的软件过程（各种活动、技术和工具），既包括了软件开发的技术方面又包括了管理方面。
　　CMM的策略是，力图改进对软件过程的管理，而在技术方面的改进是其必然的结果。

CMM在改进软件过程中所起的作用主要是，指导软件机构通过确定当前的过程成熟度并识别出对过程改进起关键作用的问题，从而明确过程改进的方向和策略。
　　CMM把软件过程从无序到有序的进化过程分成5 个阶段，并把这些阶段排序，形成5个逐层提高的等级。这5个成熟度等级定义了一个有序的尺度，这些等级还能帮助软件机构把应做的改进工作排出优先次序。

CMM通过定义能力成熟度的5个等级，引导软件开发机构不断识别出其软件过程的缺陷，并指出应该做哪些改进，但是，它并不提供做这些改进的具体措施。
　　能力成熟度的5个等级从低到高依次是：
　　　初始级 （1级）
　　　可重复级 （2级）
　　　已定义级 （3级）
　　　已管理级 （4级）
　　　优化级 （5级）
下面介绍这5个级别的特点。

（一）初始级

• 软件过程的特征是无序的，甚至是混乱的。
• 几乎没有什么过程是经过定义的（即没有一个定型的过程模型），项目能否成功完全取决于开发人员的个人能力。
• 1级成熟度等级的软件机构，基本上没有健全的软件工程管理制度，其过程能力是不可预测的，其软件过程是不稳定的，产品质量只能根据相关人员的个人工作能力而不是软件机构的过程能力来预测。

（二）可重复级

• 软件机构建立了基本的项目管理过程(过程模型),可跟踪成本、进度、功能和质量。已经建立起必要的过程规范，对新项目的策划和管理过程是基于以前类似项目的实践经验，使得有类似应用经验的软件项目能够再次取得成功。
• 处于2级成熟度的软件机构的过程能力可以概括为，软件项目的策划和跟踪是稳定的，已经为一个有纪律的管理过程提供了可重复以前成功实践的项目环境。软件项目工程活动处于项目管理体系的有效控制之下，执行着基于以前项目的准则且合乎现实的计划。

（三）已定义级

• 软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。所有项目组都使用文档化的、经过批准的过程来开发和维护软件。
• 这一级包含了第2级的全部特征。
• 处于3级成熟度的软件机构的过程能力可以概括为，无论是管理活动还是工程活动都是稳定的。软件开发的成本和进度以及产品的功能和质量都受到控制，而且软件产品的质量具有可追溯性。这种能力是基于在软件机构中对已定义的过程模型的活动、人员和职责都有共同的理解。

（四） 已管理级

• 软件机构对软件过程和软件产品都建立了定量的质量目标，所有项目的重要过程活动都是可度量的。
• 这一级包含了第3级的全部特征。
• 处于4级成熟度的软件机构的过程能力可以概括为，软件过程是可度量的，软件过程在可度量的范围内运行。这一级的过程能力允许软件机构在定量的范围内预测过程和产品质量趋势，在发生偏离时可以及时采取措施予以纠正，并且可以预期软件产品是高质量的。

（五）优化级

• 软件机构集中精力持续不断地改进软件过程。
• 这一级的软件机构是一个以防止出现缺陷为目标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。在这样的机构中，可以获得关于软件过程有效性的统计数据，利用这些数据可以对新技术进行成本/效益分析，并可以优化出在软件工程实践中能够采用的最佳新技术。
• 这一级包含了第4级的全部特征。

（六）优化级

• 处于5级成熟度的软件机构的过程能力可以概括为，软件过程是可优化的。这一级的软件机构能够持续不断地改进其过程能力，既对现行的过程实例不断地改进和优化，又借助于所采用的新技术和新方法来实现未来的过程改进。
• 一些统计数字表明，提高一个完整的成熟度等级大约需要花18个月到3年的时间，但是从第1级上升到第2级有时要花3年甚至5年时间。这说明要向一个迄今仍处于混乱的和被动的行动方式的软件机构灌输系统化的方式，将多么困难。