第七章项目的计划和管理

软件工程第七章项目的计划和管理7.1软件度量

7.2软件项目估算 7.3软件质量度量 7.4软件复杂性度量

7.5软件可靠性度量

7.6软件开发过程的管理

7.7软件过程能力评估

7.8项目管理计划的组成

7.9小结本章重点软件度量软件项目管理风险管理项目计划的制定

7.1软件度量软件开发不同于其他产品的设计、制造过程，软件的整个过程都是设计过程而没有制造过程。软件开发不需要使用大量的物质资源，而主要是人力资源，并且，软件开发的产品只是程序代码和技术文件，并没有其他的物质结果。7.1.1软件度量的基本概念1．测量、度量、估算（1）测量（measure）：对产品或过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。（2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。如软件质量度量等。（3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工作计划等。2．软件项目管理的对象及其属性：软件项目管理的对象主要包括产品、过程和资源等。（1）产品（product）是指软件开发过程得到的文档和程序，如：需求规格说明、设计规格说明、源代码、测试报告等。（2）过程（process）是指与软件项目有关的活动，如软件项目计划、开发活动、维护活动、管理活动等。（3）资源（resource）是指进行软件项目所需要的各种支持，如人力、经费、方法、工具、软硬件环境等。

3.对象的属性内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。

项目管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性看成是面向管理员和用户的属性。4．软件度量的分类。可分为直接度量和间接度量两类：（1）直接度量。即对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的代码行数、操作符的个数，工作量、成本等。（2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。因为它们必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功能性、复杂性、可靠性、可维护性等等。7.1.2面向规模的度量通面向规模的度量是以软件的代码行（LOC，LineofCode）数为基础的直接度量。一般的软件开发组织对开发过的每个软件项目都有如代码行、工作量、成本、错误、人数、文档页数等的统计记录。利用代码行数可以度量软件规模、生产率、平均成本、出错率、文档率等参考量。若设：L表示软件的代码行数，单位为KLOC（千行代码）或LOC；E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；S表示软件成本，单位为美元或元；Ne表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。则有：1．软件开发的生产率Pl（即平均每人月开发的代码行数，以LOC/PM为单位）为：

Pl=L/E2．开发每行代码的平均成本Cl（以美元/LOC或元/LOC为单位）为：

Cl=S/L3．代码出错率EQRl（即每千行代码的平均错误数，以个/KLOC为单位）为：

EQRl=Ne/L4．软件的文档率Dl（即平均每千行代码的文档页数，以页/KLOC为单位）为：

Dl=Pd/L

例：已知有一个国外典型的软件项目的记录，开发人员M=6人，其代码行数=20.2KLOC，工作量E=43PM，成本S=314000美元，错误数N=64，文档页数Pd=1050页。试计算开发该软件项目的生产率Pl、平均成本Cl、代码出错率EQRl和文档率Dl。解：根据给出的已知数据，可得：

Pl=L/E=20.2KLOC/43PM=0.47KLOC/PM=470LOC/PMCl=S/L=314000美元/20.2KLOC=15.54美元/LOC

EQRl=Ne/L=64个/20.2KLOC=3.17个/KLOCDl=Pd/L=1050页/20.2KLOC=51.98页/KLOC1．简单功能点度量1979年，Albrecht首先提出了功能点度量方法。这是一种面向功能的间接度量方法，即从软件定义的基本功能出发，来估算软件系统的规模。因此，该方法可以在软件开发项目的初期，在软件定义过程中即可预测待开发软件的规模。Albrecht用5个信息量的“加权和”CT和14个因素的“复杂性调节值”Fi（i=1，2，……14）来计算功能点FP。7.1.3面向功能的度量功能点FP的度量公式如下：FP=CT×TCF=CT[0.65+0.01Fi]在FP度量公式中：基本功能点的CT计算方法，如表7.1所示。

表7.1基本功能点的CT计算方法测量参数值简单权值一般权值复杂权值用户输入数□*3*4*6＝□用户输出数□*4*5*7＝□用户查询数□*3*4*6＝□文件数□*7*10*15＝□外部界面数□*5*7*10＝□CT＝□TCF是技术复杂性调节因子。0.65和0.01为经验数据。Fi（i=1，2，…，14）：复杂性调节值。Fi所代表的因素，每个Fi可根据实际情况取0、1、2、3、4、5中的一个值。其中：0—没有影响、1—偶然的、2—适中、3—普通、4—重要、5—极重要的影响。TCF取值范围：0.65~1.35。2．功能点度量简单功能点度量方法没有直接考虑软件本身的算法的复杂性问题。所以它仅适用于度量算法简单的事务处理等系统。1986年Jones对简单功能点度量进行了推广，在计算软件系统的基本功能点CT时，引入了算法复杂性因素，我们称这种推广的度量方法为功能点度量。推广功能点的CT计算方法，如表7.2所示。表7.2推广功能点的CT计算方法测量参数值权值用户输入数□*4＝□用户输出数□*5＝□用户查询数□*4＝□文件数□*7＝□外部界面数□*7＝□算法□*3＝□CT＝□这两种方法对一般的事务处理系统等算法简单的软件系统计算出来的FP值基本相同，但对于较复杂的软件系统，功能点度量方法比简单功能点度量方法计算出来的FP值要高20%~35%。用功能点计算软件项目的有关参考量：（1）生产率Pf（平均每人月开发的功能点数，以功能点/PM为单位）：

Pf=FP/E（2）平均成本Cf（以美元/功能点或元/功能点为单位）：

Cf=Sf/FP（3）代码出错率EQR（即每功能点的平均错误数，以个/功能点为单位）为：

EQRf=Ne/FP（4）软件的文档率Df（即平均每功能点的文档页数，以页/功能点为单位）为：

Df=Pd/FP3．功能点度量方法的优点：（1）可用于软件项目开发的初期阶段的项目估算。因为在可行性研究和需求分析阶段已能基本确定输入、输出等各个参考量；（2）与程序设计语言无关。适合于过程或非过程式语言。4．功能点度量方法的缺点：（1）某些参考量的收集有一定困难；（2）度量值的主观因素较多，如Fi取值；（3）功能点FP本身没有直观的物理意义。软件的功能点数与选用的程序设计语言无关，但对于同一个软件（功能点数已定），如用不同的程序设计语言来实现，所得到的软件的代码行数可能会有较大差别。Albrecht等人通过多个软件统计出了用不同程序设计语言实现每个功能点所需代码行数，即计算出各语言的。各种语言的LOC/FP(平均值)如表7.3所示。

7.1.4代码行与功能点度量的比较程序设计语言LOC/FP(平均值)汇编语言320COBOL105FORTRAN105Pascal90Ada70面向对象的语言30四代语言(4GL)20代码生成器157.2软件项目估算常用的软件项目的估算方法主要有以下4种：1．根据已完成项目的总成本或总工作量来推算待开发软件的总成本或总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。 优点：估算工作量小、速度快。缺点：对项目中的特殊困难估计不足，有可能产生遗漏，估算出的值盲目性较大。2．把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。需要指出，在对软件进行细分时，一种是按照功能将大的软件项目划分为若干个子项目；另一种是按照软件生命周期分解为各个阶段。当然，也可以两者同时进行。 优点：计算各个部分的准确性较高。缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管理、质量管理），估算值往往偏低，必须用其他方法进行校正。3．用待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。差别估算法综合了以上两种方法的优点。 优点：估算的准确程度高。缺点：不容易划分相似的界限。4．根据经验估算公式，通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。软件项目的规模是影响软件项目成本和工作量的重要因素。软件项目代码行和功能点估算是成本和工作量估算的基础。采用上述四种估算方法可以估算出LOC或FP的乐观值a，悲观值b和一般值m，然后根据下列加权公式计算出期望值，公式如下所示：

E=（a+4m+b）/6软件的LOC或FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作量等进行估算了。7.2.1工作量估算1．IBM模型IBM模型是根据已估算出的源代码行数来估算其他资源的需要量的，因此该模型是面向LOC的静态单变量估算模型。还有一些面向FP的静态单变量估算模型。由于这些模型的准确度不高，在实际应用中必须对公式中的参数进行调整，以适应目前情况。2．COCOMO模型7.2.2经验估算模型CoCoMo模型按其详细程度分三个层次：基本CoCoMo模型；中间CoCoMo模型；详细CoCoMo模型。软件估算模型使用由经验导出的公式来预测软件开发工作量，其中，工作量是软件规模(LOC或FP)的函数，工作量的单位通常是人月（PM）。支持大多数估算模型的经验数据，都是从有限个项目的样本集中总结出来的，因此，没有一个估算模型可以适应所有类型的软件和开发环境。（1）基本CoCoMo模型基本CoCoMo模型是静态的、单变量的模型，其工作量和开发时间的估算公式如下：

E=a（L）bD=cEd

其中：L——软件代码行的估算值（以KLOC计）；E——工作量（以PM计）；D——开发时间（以月计）；a、b、c、d——经验常数。（2）中间CoCoMo模型中间CoCoMo模型在估算工作量时，在基本CoCoMo模型的基础上再乘以由15个因素组成的工作量调节因子EAF，于是有：E=a（L）bEAF=a（L）bFi其中：

L——软件的代码行数（以KLOC计）；

E——工作量（以PM计）；

a、b——经验常数

（3）详细CoCoMo模型简介详细CoCoMo模型的基本工作量（指EAF=1时的工作量）公式、开发时间公式与中间CoCoMo模型相同。所不同的是详细CoCoMo模型在计算EAF时针对每个影响因素，分层次（系统层、子系统层、模块层）并按软件生存周期分阶段给出工作量因素的分级表。详细CoCoMo模型可以更准确地估算软件项目的工作量。详细CoCoMo模型这里就不详细介绍了，感兴趣的同学可以查阅相关的参考资料。

软件质量是软件的生命。它作为软件工程的一部分，贯穿于整个软件生存周期之中。生产高质量的软件产品是软件工程的首要目标。由于软件是逻辑产品，软件质量很难直接度量。因此，应当给出软件质量的科学的、实用的定义，并通过一定的度量模型进行度量，以便在整个软件生存周期中对其进行评价和控制。7.3软件质量度量7.3.1软件质量定义1．软件质量的定义：1983年，ANSI/IEEEstd729标准给出了软件质量的定义如下：软件质量是软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，包括：（1）软件产品满足用户要求的程度；（2）软件拥有所期望的各种属性的组合程度；（3）用户对软件产品的综合反映程度；（4）软件在使用过程中满足用户需求的程度。2.McCall等人的软件质量度量模型McCall等人提出了由软件质量要素、评价准则、定量度量三个层次组成的三层次度量模型。其中:第一层是将对软件质量的度量归结为对直接影响软件质量的若干个软件质量要素的度量；第二层是用若干个可度量的评价准则来间接度量软件质量要素；第三层是对相应评价准则的直接度量。3．ISO三层次软件质量度量模型。1985年，国际标准化组织也提出了三层次软件质量度量模型。其中：高层称为软件质量需求评价准则（SQRC），并由正确性、可容性、有效性、安全性、可用性、可维护性、灵活性、可互操作性等8个要素组成；中层称为软件质量设计评价准则（SQDC），并由可追踪性、完全性等共23个评价准则组成；低层称作软件质量度量评价准则（SQMC）。ISO认为，应对高层和中层建立国际标准，而低层可由各使用单位自行制定。软件质量要素（factor）是指直接影响软件质量的软件质量特性。随着对软件质量的认识的逐步提高，软件质量要素也可能有所变化。当时McCall等人认为，软件质量由11个软件质量要素来衡量。这11个质量要素可划分为三类：它们之间的关心如图7.1所示（1）面向运行特征的软件质量要素有正确性、可靠性、有效性、完整性和可用性；（2）面向软件承受修改的质量要素有可维护性、灵活性、可测试性；（3）面向转移的软件质量要素有可移植性、可重用性、可互操作性。7.3.2软件质量要素图7.1McCall软件质量要素1．质量要素概念：（1）正确性（correctness）：指程序满足需求规格说明及用户目标的程度；（2）完整性（integrity）：指对未授权人员访问程序或数据加以控制的程度；（3）可用性（usability）：指学习使用软件（即操作软件、准备输入数据、解释输出结果等）的难易程度；（4）灵活性（flexibility）：指改变一个操作的顺序所需工作量的多少；（5）可测试性（testability）：指测试软件以便使其具有预定功能所需工作量的多少；（6）可互操作性（interoperability）：指程序与其他系统相互交换并使用信息的能力。

1．评价准则概念（1）可审查性（audit-ability）：检查软件需求、文档、过程、标准等是否一致的难易程度；（2）准确性（accuracy）：计算和控制的精确程度；（3）简明性（conciseness）：程序源代码的紧凑程度；（4）通信通用性（communicationcommonality）：使用标准接口、协议和带宽的程度；（5）数据通用性（datacommonality）：在程序中使用标准数据结构和类型的程度；7.3.3软件质量要素评价准则（6）容错性（error-tolerance）：在各种异常情况下软件能继续提供操作的能力；（7）执行效率（executionefficiency）：软件运行效率；（8）可扩充性（expandability）：结构、数据、过程等设计可以扩充的程度；（9）通用性（generality）：程序潜在应用领域的多少；（10）硬件独立性（hardwareindependence）：软件与其运行的硬件环境无关的程度；（11）检测性（instrumentation）：程序监视自身运行并标识错误的程度；（12）可操作性（operability）：操作该软件的难易程度；（13）安全性（security）：控制或保护程序和数据不被破坏、非法访问等机制的能力；（14）自文档化（self-documentation）：源代码提供自身说明文档的程度；（15）简单性（simplicity）：程序易于理解的程度；（16）软件独立性（softwareindependence）：软件与非标准编程语言特征、操作系统特征等软件环境约束无关的程度；（17）易培训性（training）：软件对使用它的新用户的支持程度。（18）完全性(Completeness)整个软件系统不丢失任何重要的成分，软件完全实现系统所需的功能、行为和性能（19）一致性(Consistency)整个软件系统均使用统一的符号、概念和术语（20）模块化(Modularity)模块是程序中一个逻辑上相对独立、具有良好的接口定义的编程单位：过程、函数、类、程序包等（21）可追踪性(Tracebility)对软件进行正向和反向追踪的能力2．软件质量要素Fj的值可用下式计算：

Fj＝CjkMkj=1,2，...,11.其中Mk是软件质量要素Fj对第k种评价准则的测量值，Cjk是相应的加权系数。加权系数Cjk满足Cjk＝1。7.4软件复杂性度量

通过软件的复杂性度量值可以估算出软件中故障的数量，也能估算出软件开发所需的工作量；定量度量的结果还可以用于比较不同设计方案的优劣。同时，软件的复杂性也能从某些方面影响软件的可维护性、可靠性等软件质量要素。因此，软件复杂性度量是软件度量的一个重要组成部分。7.4.1软件复杂性及度量原则

1．软件复杂性的概念 一个软件系统由于开发规模相同、复杂性不同的软件，花费的时间和成本会有很大差异。K.Magel

从6个方面来描述软件复杂性：（1）理解程序的难度；（2）维护程序的难度；（3）向其他人解释程序的难度；（4）按指定方法修改程序的难度；（5）根据设计文件编写程序的工作量；（6）执行程序时需要资源的多少。 软件复杂性反映了软件的可理解性、模块化、简单性等属性。2．软件复杂性度量的原则（1）软件的复杂性与其规模的关系不是线性的；（2）数据结构复杂的程序较复杂；（3）控制结构复杂的程序较复杂；（4）转向语句使用不当的程序较复杂；（5）循环结构比选择结构复杂、选择结构比顺序结构复杂；（6）语句、数据、子程序模块等出现的顺序对复杂性有影响；（7）非局部变量较多的程序较复杂；（8）参数按地址调用（Callbyreference）比按值调用（Callbyvalue）复杂；（9）函数副作用比显式参数传递难理解；（10）作用不同的变量同名时较难理解；（11）模块、过程间联系密切的程序较复杂；（12）程序嵌套层数越多越复杂。以上这些基本原则是指导我们进一步研究定量度量软件复杂性的基础。7.4.2控制结构的复杂性度量

McCabe度量模型：1976年，McCabe提出了基于程序拓扑结构的软件复杂性度量模型。该方法是把程序流程图转化为程序图：即把程序看成是有一个入口结点和一个出口结点的有向图，图中每个结点对应一个语句、一个简单判断或一个顺序流程的代码块，原来程序流程图中的箭头变成连接各结点的有向弧（或称为边）。一般地，可以假设从程序图中的开始结点可以到达图中的任一结点，而从图中的任一结点都可以到达出口结点。程序图又称为程序控制结构图或程序流图，如图7.2所示。McCabe给出了程序控制结构图G的巡回秩数V（G）作为程序控制结构复杂性的度量，其度量模型为：

V（G）=e–n+2其中：e——程序图G中边的总数；n——程序图中结点的总数。V（G）又称为图G的环形复杂度。7.4.3文本复杂性度量

在20世纪70年代初，Halstead给出了称为文本复杂性度量的模型也叫Halstead度量模型。它是根据统计程序中的操作符和操作数的个数来度量程序的复杂程度。程序可以看成是由操作符和操作数组成的符号序列。操作符是指程序中出现的语法符号，如+、–、if-then-else、while等。操作数是操作对象，如程序中定义或使用的变量、常量、数组、指针等。7.5软件可靠性度量

计算机程序的可靠性无疑是软件整体质量的一个重要因素。如果程序在执行时总是频繁地、重复地失败，那么其他软件质量因素是否可以接受也就无从谈起。软件可靠性可以通过对历史数据和开发数据来测量、标示和估算出来。7.5.l软件可靠性的概念1．软件可靠性一些软件投入使用后会逐渐暴露出一定数量的错误。当某些操作或输入数据导致遇到这些错误时，就会使程序失效，从而出现软件故障。软件可靠性定义为在某个给定时间间隔内，程序按照规格说明成功运行的概率。7.5.2软件的有效性软件的有效性函数A（t）定义为软件系统在时刻t按照规格说明成功运行的概率。可靠性与有效性之间的差别是，可靠性强调软件系统在0～t这段时间间隔内都有效，而有效性强调软件系统在时刻t这一时间点有效。7.6软件开发过程的管理为达到软件工程的目标，必须对软件开发项目的工作范围、所需的工作量和成本、必需的人力和软硬件资源、可能遇到风险、进度的安排、待实现的任务、经历的里程碑等进行管理。软件开发过程的管理应在所有技术工作开始之前启动，直至软件工程过程的结束。软件开发项目管理过程主要包括以下几个方面：1．启动一个软件项目2．成本估算3．风险分析4．进度安排5．追踪和控制7.6.1风险分析软件开发中的风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。1．风险的特点：（1）具有不确定性，某项风险可能发生也可能不发生；（2）一旦某项风险变成了现实，就必然会给项目带来不良的影响和损失，甚至灾难性后果。风险分析有四个主要活动，分别为有风险标识、风险估算、风险评价和风险驾驭和监控。2．风险标识风险按影响的范围，可分为三类：（1）项目风险是指项目在预算、进度、人力等资源、客户和需求等方面可能存在的问题。这些问题一旦发生将对软件开发项目产生不利影响。（2）技术风险是指在需求、设计、实现、接口、验证和维护等方面的潜在问题。如果技术风险发生了，将直接威胁软件产品的质量和交付日期。（3）商业风险是指开发一个没人需要的优质软件产品、开发一个销售部门不知道如何销售的软件产品、或开发一个不再符合整体商业策略的产品等等。3．风险估算——风险预测软件项目管理人员主要从影响风险的因素和风险发生后带来的损失来度量风险。要对风险进行估算，首先应建立风险度量指标体系、指明风险带来的影响和损失，确定影响风险的因素，估计风险出现的可能性或概率，即进行定量的估算。4．风险评价常采用三元组[ri，pi，xi]来描述风险。其中ri代表第i种风险，pi表示第i种风险发生的概率，xi代表该风险带来的影响，i=1，2，…，l，表示软件开发项目共有l种风险，i为风险序号。5．风险驾驭和监控风险分析的目的是建立处理风险的策略，监控、驾驭风险。驾驭风险是利用原型化、软件自动化、可靠性工程学等技术和软件项目管理方法设法避开或转移风险。描述风险的三元组[ri，pi，xi]是驾驭风险的基础。7.6.2进度安排进度安排可能是如下两种方式之一：（1）软件产品最终交付日期已经确定，开发方只能根据最终交付日期安排进度；（2）最后交付日期主要由软件开发方来确定。图7.3软件开发各个阶段工作量分布常用的项目进度1．甘特图（Ganttchart）中，每一任务完成的标准，不是以能否继续下一阶段任务为标准，而是必须交付应交付的文档与通过评审为标准。甘特图形象地描绘了任务的分解，及每个作业的开始和结束时间，优点是直观简明、容易掌握和绘制，但有三个缺点：（1）不能显示地描绘各项作业间的依赖关系；（2）进度的关键部分不明确，难以判断哪些部分是主攻和主控的对象；（3）计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。使用Gantt图描述软件开发进度

2.软件项目的进度安排的另外两种比较常用的方法是程序评估与审查技术（PERT，ProgramEvaluationandReviewTechnique）和关键路径法（CPM，CriticalPathMethod），这两种方法都生成描述项目进展状态的工程网络图，PERT图如图7.5所示。图7.5PERT图图7.6关键路径网络图7.6.3软件质量保证1．软件质量保证活动的内容为了开发出高质量的软件，达到软件工程的目标，必须有计划地、系统地进行软件质量保证（SQA，SoftwareQualityAssurance）活动。2．软件工程的正式技术评审（1）正式技术评审是保证软件质量的重要措施。（2）正式的技术评审是降低软件成本的重要措施。7.6.4人员的组织与分工

1．组织原则建立一个好的软件项目组织是保证软件开发能够顺利进行的必要条件之一。2．组织结构常用的3种模式：（1）按课题划分的模式（ProjectFormat）（2）按职能划分的模式（FunctionalFormat）（3）矩阵模式（MatrixFormat）3．程序设计小组的组织形式程序设计小组的组织和小组内部人员的组织形式对生产率都会产生影响。常采用的组织形式有主程序员制小组、民主制小组、层次式小组3种。4．人员配备实践表明，软件开发各个阶段所需要的技术人员的类型、层次和数量是不同的。在软件项目的计划和分析阶段，只需要少数人，主要是系统分析员、从事软件系统论证和概要设计的软件高级工程师和项目高级管理人员，人数虽不多，但都是高层次人员。概要设计阶段要增加几个高级程序员。详细设计阶段要增加软件工程师和程序员。7.7软件过程能力评估软件过程能力描述了一个开发组织开发软件开发高质量软件产品的能力。现行的国际标准主要有两个：ISO9000.3和CMM。ISO9000.3是ISO9000质量体系认证中关于计算机软件质量管理和质量保证标准部分。CMM（能力成熟度模型）是美国卡纳基梅隆大学软件工程研究所（CMU／SEI）于1987年提出的评估和指导软件研发项目管理的一系列方法，用5个不断进化的层次来描述软件过程能力。现在CMM是2.0版本。ISO9000和CMM的共同点是二者都强调了软件产品的质量。所不同的是，ISO9000强调的是衡量的准则，但没有告诉软件开发人员如何达到好的目标，如何避免差错。CMM则提供了一整套完善的软件研发项目管理的方法。它可告诉软件开发组织，如果要在原有的水平上提高一个等级，应该关注哪些问题，而这正是改进软件过程的工作。7.8项目管理计划的组成软件项目计划（SoftwareProjectPlanning）是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。7.8.1项目计划的内容软件项目计划通常包括3个方面的内容，内容如下：1.范围。对该软件项目的综合描述,定义起所要做的工作以及性能限制,它包括:（1）项目目标。（2）主要功能。（3）性能限制。（4）系统接口。（5）特殊要求。（6）开发概述。2.资源。资源计划就是决定在项目中的每一项工作中用什么样的资源（人、材料、设备、信息、资金等等），在各个阶段使用多少资源。项目费用计划包括资源计划、费用估算、费用预算。（1）人员资源。（2）硬件资源。（3）软件资源。（4）其他。3.进度安排。进度安排的好坏往往会影响整个项目的按期完成,因此这一环节是十分重要的。制定软件进度与其他工程没有很大的区别，其方法主要有：（1）工程网络图。（2）Gantt图。（3）任务资源表。（4）成本估算。（5）培训计划。7.8.2项目计划的制定项目计划详细说明了所需软件工作及如何实现。它定义了每一个主要任务，并估算其所需时间和资源，同时为管理层的评估和控制提供了一个框架。项目计划也提供了一种很有效的学习途径。如果能合理建档，它便是一个与实际运行效能比较的基准。这种比较可以使计划者看到他们的估算误差，从而提高其估算精确度。1.制订软件项目计划的方法与策略（1）注重项目计划的层次性（2）重视与客户的沟通（3）繁简得当（4）制订的项目计划要现实2.运用过程化的思想指导开发软件的需求管理、软件项目计划、项目跟踪和监控、软件转包合同管理、软件质量保证、软件配置管理就构成了软件项目的过程管理内容。通常需要根据项目的进展情况对项目计划进行修改，以便应付需求和承诺的变更、不够准确的估计、纠正措施和过程更改等。在策划和重新策划中涉及的活动，都包含在这个过程方面里。3.利用成熟的项目管理工具很多软件产品都提供项目管理的功能，如MicrosoftProject、Visio等，它们是都可以用于项目管理。它们自带了一个叫做“软件”的模板，可以用它来生成大体的框架，再作细节方面的改动，也可以自己制作一个符合自己公司软件项目运作流程的模板。4.软件项目计划编制方针软件项目计划编制的目的