教学题目： 2.1 软件度量 2.2 软件项目的估算 教学目的：了解软件度量的基本概念，掌握面向 规 模和面向功能点度量方法。了解项目估

1. 教学题目：2.1 软件度量 2.2软件项目的估算 教学目的：了解软件度量的基本概念，掌握面向 规 模和面向功能点度量方法。了解项目估 算方法。 教学重点：面向规模和面向功能点的度量方法。 教学难点：面向功能点的度量方法 教 具：多媒体教室、电子教案 作 业： 课后习题 第2章 软件项目管理

2. 2.1 软件度量 2.2 软件项目估算 2.3 软件质量度量 2.4 软件复杂性度量 2.5 软件可靠性度量 2.6 软件开发过程的管理 习题思考题 第2章 软件项目管理

3. 软件项目管理必须从项目的开头介入，并贯穿于整个软件生存周期的全过程。软件项目管理必须从项目的开头介入，并贯穿于整个软件生存周期的全过程。 软件项目管理的范围主要集中于3个P上，即： People（人员）、Problem（问题）和Process（过程）。 软件项目管理的主要任务是： 根据选定的软件开发过程框架（即软件开发模型）和对其估算的结果制定软件项目实施计划；再根据计划对人员进行组织、分工；按照计划的进度，以及成本管理、风险管理、质量管理的要求，控制并管理软件开发和维护的活动，最终以最小的代价完成软件项目规定的全部任务。 第2章 软件项目管理

4. 软件项目的成本管理、软件质量管理和软件配置管理有一定的特殊性和独立性，可单独立项。其任务分别是：软件项目的成本管理、软件质量管理和软件配置管理有一定的特殊性和独立性，可单独立项。其任务分别是： 成本管理——估算软件项目的成本，作为立项和签合同的依据之一，并在软件开发过程中按计划管理经费的使用； 质量管理——制定软件质量保证计划，按照质量评价体系控制软件质量要素，对阶段性的软件产品进行评审，对最终软件产品进行确认，确保软件质量； 配置管理——制定配置管理计划，对程序、数据、文档的各种版本进行管理，确保软件的完整性和一致性。 第2章 软件项目管理

5. 在制定有效的项目实施计划的过程中，首先要对项目的工作量、完成期限等等参考量进行估算。估算的结果将成为项目计划其他活动的基础，同时，为了对软件项目进行科学、有效的管理，就必须对软件开发过程的有关特征进行度量，度量的结果用于软件开发过程的管理与监控。在制定有效的项目实施计划的过程中，首先要对项目的工作量、完成期限等等参考量进行估算。估算的结果将成为项目计划其他活动的基础，同时，为了对软件项目进行科学、有效的管理，就必须对软件开发过程的有关特征进行度量，度量的结果用于软件开发过程的管理与监控。 本章主要介绍软件度量的概念，软件的规模度量，软件项目的估算，软件的质量度量、复杂性度量、可靠性度量、风险的分析与度量以及软件项目管理过程与步骤等等。 第2章 软件项目管理

6. 对软件工程项目的规模、成本、产品质量等属性进行定量的描述，可以帮助项目管理人员和开发者制定有效的项目计划，监控项目的风险、进度和阶段产品的质量，并为调整过程中活动和做出重要决策提供可靠的依据。下面介绍软件度量的基本概念，并介绍软件的规模度量和功能度量。对软件工程项目的规模、成本、产品质量等属性进行定量的描述，可以帮助项目管理人员和开发者制定有效的项目计划，监控项目的风险、进度和阶段产品的质量，并为调整过程中活动和做出重要决策提供可靠的依据。下面介绍软件度量的基本概念，并介绍软件的规模度量和功能度量。 2.1.1 软件度量的基本概念 1．测量、度量、估算和指标 软件工程项目的定量描述涉及测量、度量、估算和指标等一些基本概念。 2.1 软件度量

7. 1）测量（measure）：对产品或过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。1）测量（measure）：对产品或过程的某个属性的范围、数量、维度、容量或大小提供一个定量的指示。 2）度量（metric）：对系统、部件或过程的某一特性所具有的程度进行的量化测量。如软件质量度量等。 3）估算（estimation）：对软件产品、过程、资源等使用历史资料或经验公式等进行预测。如工作量、成本、完成期限等。估算一般用于立项、签订合同、制定工作计划等。 2.1.1 软件度量的基本概念

8. 4）指标（guideline） 指标——是一个度量或度量的组合，它可对软件产 品、过程或资源提供更深入的理解。 如有4个小组共同完成一个软件项目，每一个小组都必须采用自行选择的评审类型进行技术评审。管理者检查“每小时每人所发现的错误数”这一度量结果时发现：采用正式技术评审方法的两个小组的该度量值要比另外两个小组高出40%。假设4个小组的其他参数都相同，这就给管理者提供了一个指标：正式技术评审方法比其他技术评审方法更有效率。于是，管理者可决定建议所有小组都采用更加正式的技术评审方法。 2.1.1 软件度量的基本概念

9. 软件项目管理的对象主要包括产品、过程和资源等。软件项目管理的对象主要包括产品、过程和资源等。 产品（product）是指软件开发过程得到的文档和程序，如：需求规格说明、设计规格说明、源代码、测试报告等； 过程（process）是指与软件项目有关的活动，如软件项目计划、开发活动、维护活动、管理活动等； 资源（resource）是指进行软件项目所需要的各种支持，如人力、经费、方法、工具、软硬件环境等。 要对软件项目管理的对象进行有效的管理与控制，就必须对这些对象的属性进行测量、度量与估算。一般来说，产品、过程、资源等对象都具有内部属性和外部属性。 2．软件项目管理的对象及其属性

10. 内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。内部属性是指对象本身的属性，如软件产品的代码长度、模块化的程度、复杂性等。 对象的外部属性体现了对象与环境的关系，如软件的可靠性、可维护性、可移植性、成本、人员的生产率等。对象的部分属性如表2-1所示。 对象的属性

11. 表2-1 软件工程的产品、过程、资源的属性

12. 项目管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性看成是面向管理员和用户的属性。但在软件开发的过程中，软件的外部属性一般是很难度量和控制的。这些外部属性是由软件的内部属性所决定的，因此，可以通过研究内部属性与外部属性之间的关系来解决外部属性的度量问题，进而逐步建立起了软件工程度量系统。项目管理员和用户都十分关心产品、过程、资源的外部属性，于是可将外部属性看成是面向管理员和用户的属性。但在软件开发的过程中，软件的外部属性一般是很难度量和控制的。这些外部属性是由软件的内部属性所决定的，因此，可以通过研究内部属性与外部属性之间的关系来解决外部属性的度量问题，进而逐步建立起了软件工程度量系统。 对象的属性

13. 可分为直接度量和间接度量两类： 1）直接度量。即对不依赖于其他属性的简单属性的测量。如软件的模块数、程序的代码行数、操作符的个数，工作量、成本等。 2）间接度量。即对涉及若干个其他属性的软件要素、准则或属性的度量。因为它们必须通过建立一定的度量方法或模型才能间接推断而获得。如软件的功能性、复杂性、可靠性、可维护性等等。 软件度量系统还可进一步划分为两个侧面。它们之间的关系如图2-1-1所示。 3．软件度量的分类

14. 图2-1-1 两侧面间关系 技术度量 质量度量 生产率度量 面向规模的度量 面向功能的度量 面向人的度量

15. 面向规模的度量是以软件的代码行（LOC，Line of Code）数为基础的直接度量。一般的软件开发组织对开发过的每个软件项目都有如代码行、工作量、成本、错误、人数、文档页数等的统计记录。利用代码行数可以度量软件规模、生产率、平均成本、出错率、文档率等参考量。 设：L表示软件的代码行数，单位为KLOC（千行代码）或LOC；E表示开发软件所需工作量，单位为人月（PM）或人年（PY）；S表示软件成本，单位为美元或元；N表示错误个数；Pd表示软件文档页数；M表示开发所用的人数。则有： 2.1.2 面向规模的度量

16. 1．软件开发的生产率P（即平均每人月开发的代码行数，以LOC/PM为单位）为：1．软件开发的生产率P（即平均每人月开发的代码行数，以LOC/PM为单位）为： P = L / E （2-1） 2．开发每行代码的平均成本C（以美元/LOC或元/LOC为单位）为： C = S / L （2-2） 3．代码出错率EQR（即每千行代码的平均错误数，以个/KLOC为单位）为： EQR = N / L （2-3） 4．软件的文档率D（即平均每千行代码的文档页数，以页/KLOC为单位）为： D = Pd / L（2-4）

17. 【例2.1】 已知有一个国外典型的软件项目的记录，开发人员M=6人，其代码行数=20.2KLOC，工作量E=43PM，成本S=314000美元，错误数N=64，文档页数Pd=1050页。试计算开发该软件项目的生产率P、平均成本C、代码出错率EQR和文档率D。 解：根据给出的已知数据，可得： P = L / E =20.2 KLOC /43 PM = 0.47 KLOC / PM = 470 LOC / PM C = S / L = 314000美元 / 20.2 KLOC = 15.54 美元 / LOC EQR = N / L = 64个 / 20.2KLOC = 3.17 个 / KLOC D = Pd / L = 1050 页 / 20.2 KLOC = 51.98 页 / KLOC 2.1.2 面向规模的度量

18. 优点：简单、直接。 缺点：如它依赖于程序设计语言的功能和表达 等特征、在开发初期很难准确估算出 代码行数、对设计水平高的软件项目 产生不利影响。 适用场合：适合于过程式程序设计语言和事后 度量。 基于代码行面向规模优缺点、适用场合

19. 1．简单功能点度量 1979年，Albrecht首先提出了功能点度量方法。这是一种面向功能的间接度量方法，即从软件定义的基本功能出发，来估算软件系统的规模。因此，该方法可以在软件开发项目的初期，在软件定义过程中即可预测待开发软件的规模。 2.1.3 面向功能的度量

20. 功能点FP的度量公式如下： FP = CT×TCF = CT [0.65 + 0.01∑F i ] （2-5） 其中： CT——基本功能点。 CT值按表2-2来计算，它的值为5个参数加 权值的总和。 1．简单功能点度量 14 i=1

21. 表2-2 简单功能点度量的基本功能点的计算

22. 1）用户输入数：用户为软件系统提供的输入参数的个1）用户输入数：用户为软件系统提供的输入参数的个 数（不包括查询）； 2）用户输出数：软件为用户提供的输出参数（报告、 屏幕帧、错误信息等）的个数； 3）用户查询数：一次联机输入导致软件以联机输出方 式实时产生一个响应的个数； 4）文件数： 逻辑主文件的个数； 5）外部接口数：机器可读的接口（如磁盘或磁带上的 数据文件等）的个数。 表2-2中的5个参数的含义

23. 在FP度量公式中： TCF——技术复杂性调节因子。 0.65和0.01——经验数据。 Fi（i=1，2，…，14）——复杂性调节值。 Fi所代表的因素如表2-3所示，每个Fi可根据实 际情况取0、1、2、3、4、5中的一个值。 其中：0—没有影响、1—偶然的、2—适中、 3—普通、4—重要、5—极重要的影响。 TCF取值范围：0.65 ~ 1.35。 1．简单功能点度量

24. 表2-3 F i取值表

25. 简单功能点度量方法没有直接考虑软件本身的算法的复杂性问题。所以它仅适用于度量算法简单的事务处理等系统。简单功能点度量方法没有直接考虑软件本身的算法的复杂性问题。所以它仅适用于度量算法简单的事务处理等系统。 1986年Jones对简单功能点度量进行了推广，在计算软件系统的基本功能点CT时，引入了算法复杂性因素，即使用表2-4计算CT 。我们称这种推广的度量方法为功能点度量。 这两种方法对一般的事务处理系统等算法简单的软件系统计算出来的FP值基本相同，但对于较复杂的软件系统，功能点度量方法比简单功能点度量方法计算出来的FP值要高20%~35%。 2．功能点度量

26. 表2-4 推广的功能点度量的基本功能点的计算

27. 1）生产率P（平均每人月开发的功能点数，以功1）生产率P（平均每人月开发的功能点数，以功 能点 / PM为单位）： P = FP / E （2-6） 2）平均成本C（以美元/功能点或元/功能点为单 位）： C = S / FP （2-7） 用功能点计算软件项目的有关参考量：

28. 3）代码出错率EQR（即每功能点的平均错误 数EQR = N / FP （2-8） 4）软件的文档率D（即平均每功能点的文档 页数，以页/功能点为单位）为： D = Pd / FP（2-9），以个/功能点为单位）为： 用功能点计算软件项目的有关参考量：

29. 优点： ①可用于软件项目开发的初期阶段的项目估 算。因为在可行性研究和需求分析阶段已 能基本确定输入、输出等各个参考量； ②与程序设计语言无关。适合于过程或非过 程式语言。 缺点： ①某些参考量的收集有一定困难； ②度量值的主观因素较多，如Fi取值； ③功能点FP本身没有直观的物理意义。 3．功能点度量方法的优缺点

30. 软件的功能点数和选用的程序设计语言无关，但对于同一个软件（功能点数已定），如用不同的程序设计语言来实现，所得到的软件的代码行数可能会有较大差别。Albrecht等人通过多个软件统计出了用不同程序设计语言实现每个功能点所需代码行数，即计算出各语言的LOC/FP的平均值，如表2-5所示。软件的功能点数和选用的程序设计语言无关，但对于同一个软件（功能点数已定），如用不同的程序设计语言来实现，所得到的软件的代码行数可能会有较大差别。Albrecht等人通过多个软件统计出了用不同程序设计语言实现每个功能点所需代码行数，即计算出各语言的LOC/FP的平均值，如表2-5所示。 4．软件的代码行与功能点的关系

31. 表2-5 部分程序设计语言LOC/FP平均值的比较

32. 常用的软件项目的估算方法主要有以下4种： 1．自顶向下的估算方法 基本思想：首先根据已完成项目的总成本或总工作量来推算待开发软件的总成本或总工作量，然后再按比例将其分配到各开发任务中去。即从整体到局部。 优点：估算工作量小、速度快。 缺点：对项目中的特殊困难估计不足，有可能产生遗漏，估算出的值盲目性较大。 2.2 软件项目估算2.2.1 软件项目的估算方法

33. 基本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。基本思想是：把待开发软件细分，直到每一个子任务或阶段都已经明确所需要的开发工作量或成本，然后再把它们累加起来，得到待开发软件的总工作量或总成本。 需要指出，在对软件进行细分时，一种是按照功能将大的软件项目划分为若干个子项目；另一种是按照软件生命周期分解为各个阶段。当然，也可以两者同时进行。 优点：计算各个部分的准确性较高。 缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管理、质量管理），估算值往往偏低，必须用其他方法进行校正。 2．自底向上的估算方法

34. 基本思想：把待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。差别估算法综合了以上两种方法的优点。基本思想：把待开发的软件项目与过去完成的软件项目进行比较，从各子任务中区分出类似的和不同的部分。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。差别估算法综合了以上两种方法的优点。 优点：估算的准确程度高。 缺点：不容易划分相似的界限。 3．差别估算法

35. 通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。 没有一种估算模型能够适合于所有类型的软件项目。因此，对估算的结果应当慎重使用。 在实际估算时，几种估算方法可单独、同时或组合使用，以便提高估算的准确程度。 4．根据经验估算公式

36. 【例2.2】Boehm给出了“软件库存情况更新”项目采用自顶向下估算方法的一个参考例子，由过去已完成的项目的工作量，估算出该项目的总工作量为53。然后将其按比例分配到各个阶段，如表2-6所示。从中可以看出软件开发各阶段工作量的分配情况。【例2.2】Boehm给出了“软件库存情况更新”项目采用自顶向下估算方法的一个参考例子，由过去已完成的项目的工作量，估算出该项目的总工作量为53。然后将其按比例分配到各个阶段，如表2-6所示。从中可以看出软件开发各阶段工作量的分配情况。 估算方法举例

37. 表2-6 软件项目的自顶向下估算

38. 教学题目：2.2.2 代码行和功能点的估算 2.2.3软件 项目的经验估算模型. 教学目的：熟悉软件项目估算模型。 教学重点：软件项目估算模型。 教学难点：详细CoCoMo模型 教 具：多媒体教室、电子教案 作 业： 第2章 软件项目管理

39. 采用2.2.1中介绍的估算方法可以估算出代码行或功能点的乐观值a、一般值m和悲观值b，并用如下的加权平均公式计算LOC或FP的期望值（expectation）：采用2.2.1中介绍的估算方法可以估算出代码行或功能点的乐观值a、一般值m和悲观值b，并用如下的加权平均公式计算LOC或FP的期望值（expectation）： X =（ a +4 m +b）/ 6 （2-10） 软件的LOC或FP的期望值估算出来后，就可以根据已有的标准生产率对成本和工作量等进行估算了。 2.2.2 代码行和功能点的估算

40. 解：这里采用自底向上的估算方法。即首先，将CAD项目按功能分解为7个子项目，并估算出每个子项目LOC的乐观值a、一般值m和悲观值b，由此可估算出每个子项目的代码行的期望值X。在根据已知的开发类似子项目的生产率P和平均成本C即可估算出每一个子项目的成本和工作量，最后将7个子项目的成本和工作量分别累加，即可估算出软件项目的总成本S和总工作量E。估算的各种值如表2-7所示。解：这里采用自底向上的估算方法。即首先，将CAD项目按功能分解为7个子项目，并估算出每个子项目LOC的乐观值a、一般值m和悲观值b，由此可估算出每个子项目的代码行的期望值X。在根据已知的开发类似子项目的生产率P和平均成本C即可估算出每一个子项目的成本和工作量，最后将7个子项目的成本和工作量分别累加，即可估算出软件项目的总成本S和总工作量E。估算的各种值如表2-7所示。 【例2.3】对CAD软件项目进行估算

41. 表2-7 采用加权平均、自底向上方法估算代码行、成本和工作量

42. 为了使估算更准确，可以组织几个专家采用无记名的方式分别填写表2-7，然后组织者计算出这几个表格的平均值；这一过程可反复几次，直到获得一个得到多数专家共识的软件规模。为了使估算更准确，可以组织几个专家采用无记名的方式分别填写表2-7，然后组织者计算出这几个表格的平均值；这一过程可反复几次，直到获得一个得到多数专家共识的软件规模。 另外，还可以将每个子项目再按生存周期划分，估算其各阶段的工作量，再累加求出每个子项目的工作量和整个项目的工作量。可将用几种方法估算的结果进行比较来验证估算的准确性。 估算的组织实施

43. 1．IBM模型——1977年，IBM公司对60个软件项目的1．IBM模型——1977年，IBM公司对60个软件项目的 数据利用最小二乘法拟合，得到的经验估算公式： E = 5.2 × L0.91（2-11） D=4.1×L0.36 = 2.136× E0. 3956（2-12） S = 0.54 × E0.6（2-13） DOC = 49 × L1.01（2-14） 其中：E为工作量（PM）；L为源代码行数（ KLOC ）； D为项目持续的时间，以月为单位； S为人员需要量（人）；DOC为文档数量（页）。 2.2.3 软件项目的经验估算模型

44. IBM模型是根据已估算出的源代码行数来估算其他资源的需要量的，因此该模型是面向LOC的静态单变量估算模型。IBM模型是根据已估算出的源代码行数来估算其他资源的需要量的，因此该模型是面向LOC的静态单变量估算模型。 还有一些面向FP的静态单变量估算模型。由于这些模型的准确度不高，在实际应用中必须对公式中的参数进行调整，以适应目前情况。 1．IBM模型

45. 1978年，Putnam提出了大型软件项目的动态多变量估算模型。1978年，Putnam提出了大型软件项目的动态多变量估算模型。 该模型以工作量在30人年以上的大型软件项目的实测数据为依据，推导出了工作量分布曲线，如图2-2-1所示。 图中的工作量分布曲线的形状与著名的Rayleigh-Norden曲线相似。 2．Putnam模型

46. 图2-2-1 软件项目的工作量分布曲线 工作量 （人年） 系统定义、需求分析 开 发 运行维护 总工作量 测试和确认 设计编码 维护 功能设计 规格说明 系统定义 管理 0 td 时间t（年） 开发占总工作量的40% 维护占总工作量的60%

47. 由上图可得出Putnam估算模型如下： L = Ck E1/3 td 4/3（2-15） 其中：L为源代码行数（以LOC计）； E为开发与维护的工作量（以人年计）； td为开发时间（以年计）； C k为技术状态常数，与开发环境有关，如下： 2000 较差，没有方法学的支持，缺乏文档 和评审，采用批处理方式； C k = 8000 一般，有方法学的支持，有适当的文档 和评审，采用交互处理方式； 11000 较好，有集成化的CASE工具和环境。 2．Putnam模型

48. 由式（2-15）可以得出估算工作量的式子： E = L3 / (Ck3 td4) (2-16) 工作量估算出来之后，就可以估算软件项目的成本。 式中的td是对应于软件交付时的时间，它正好是工作量曲线的峰值，说明此时的工作量最大、参加项目的人最多。 图2-2-2给出了软件开发项目每年所需的人年数与开发时间的关系。 2．Putnam模型

49. R-N分布 人年数\年 线性分布 td 0 1 2 3 4 t（年） 图2-2-2 概率密度

50. 如图2-2-2所示，软件开发项目每年所需的人年数与开发时间的关系满足Rayleigh-Norden分布，即软件项目的工作量分布曲线不是线性的，因此，参加软件项目的人员就不能一成不变。如图2-2-2所示，软件开发项目每年所需的人年数与开发时间的关系满足Rayleigh-Norden分布，即软件项目的工作量分布曲线不是线性的，因此，参加软件项目的人员就不能一成不变。 如果按线性方案平均分配人员，则开发的初期一部分人力是多余的，而到了峰值段人力明显不足，到了开发的后期再临时增加人力已为时过晚，即造成了浪费，又拖延了进度。 2．Putnam模型