软件工程导论第五版张海藩第13章

动态多变量模型是根据从4000多个当代软件项目中 收集的生产率数据推导出来的。 工作量是软件规模和开发时间这两个变量的函数。 E=(LOC×B0.333/P)3×(1/t)4 (13.2) E是以人月或人年为单位的工作量； t>1是以月或年为单位的项目持续时间； B是特殊技术因子，它随着规模和要求的增加而缓 慢增加:小的程序(KLOC=5~15)，B=0.16, 超过70 KLOC的程序，B=0.39; P是生产率参数 (2000-30000)
2. 面向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
13.3.1 估算开发时间
工期 >=工作量/人力 正常情况下, 估算开发时间的模型方程： (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是开发时间（以月为单位）。
COCOMO2采用了更加精细得多的b分级模型，这 个模型使用5个分级因素Wi(1≤i≤5): 划分成从甚低 （Wi=5)到特高 5 （Wi=0)的6个级别 b= 1.01 1.01 Wi (13.4)
b的取值范围为1.01~1.26。 5个分级因素如下所述： （1） 项目先例性: 该项目的新奇程度。 （2） 开发灵活性: 约束多少。 （3） 风险排除度: 重大风险已被消除的比例。 （4） 项目组凝聚力: 开发人员相互协作度。 （5） 过程成熟度: 按照能力成熟度模型（见13.7节）
13.1.2 功能点技术
依据软件信息域特性和软件复杂性，用功能点 （FP）为单位度量软件规模。 1. 信息域特性 功能点技术定义了信息域的5个特性: 输入项数 (Inp)、输出项数(Out)、查询数(Inq)、主文件数 (Maf)和外部接口数(Inf)。 （1） 输入项数： 用户向软件输入的项数，这些 输入给软件提供面向应用的数据。
对于相同的KLOC或FP值，用不同模型估算将得出 不同的结果。 主要原因是，这些模型多数都是仅根据若干应用领 域中有限个项目的经验数据推导出来的，适用范围 有限。 因此，必须根据当前项目的特点选择适用的估算模 型，并且根据需要适当地调整（例如，修改模型常 数）估算模型。
13.2.2 动态多变量模型
由多名有经验的软件工程师分别做出估计。 每个人都估计程序的最小规模(a)、最大规模(b)和 最可能的规模(m)，分别算出这3种规模的平均值, 再用下式计算程序规模的估计值： L= a 4m b (13.1)
6
单位是代码行数（LOC） 或千行代码数（KLOC）
代码行技术的优点: 代码是所有软件开发项目都有 的“产品”，且容易计算行数。 代码行技术的缺点是： 源程序仅是软件配置的一 个成分。 为了克服代码行技术的缺点，人们提出了功能点技 术。
项目网络图
什么是项目网络图？
项目网络图是项目的所有活动以及它们之间逻辑关系或排 序的图形显示。
项目网络图是活动排序的输出，它有以下作用：
（1）能表示项目活动，并表示活动之间的依赖关系。 （2）表明项目活动将以什么顺序继续。 （3）在进行工期估计时，表明项目将需要多长时间。 （4）当改变某项活动工期时，表明项目工期将如何变化。
13.2 工作量估算
软件估算模型由经验导出的公式来预测软件开发工 作量，工作量是软件规模（KLOC或FP）的函数， 工作量的单位通常是人月（pm)。 估算模型的经验数据，是从有限个项目的样本集中 总结出来的，因此，没有一个估算模型可以适用于 所有类型的软件和开发环境。
13.2.1 静态单变量模型
甘特图
甘特图与网络图的比较
甘特图
在进度报告中很有效 在作管理陈述时易于读懂和使用。 作为计划编制工具不是太强。 没有表示活动间的逻辑关系。 网络图
表明活动和事件间的相互关系。 识别关键路径，项目历程和活动排序。 表明工作流程。 帮助编制计划和组织工作。
关键路径法
查找关键路径实例： • 使用箭线图来确定关键路径。 • 使用前导图来确定关键路径。
下图是用PROJECT制作的甲项目的最简单的一个甘特图
早期的甘特图的最大缺点是通常不反映依赖关系， 但是如果在Project上建立了依赖关系，这种依赖关系会自动 显示在甘特图上。
甘特图
使用项目管理软件可以创建更为复杂的甘特图
甘特图
跟踪甘特图可以用来评价项目的进展
注意： 任务用两种水平横线表示。下部表示计划历史（基准计划历史）； 上部表示实际历史。 由于跟踪甘特图是建立在实际开始与完成日期的基础之上，将计划 与实际的项目进度信息进行比较，所以，项目经理可以用它来监控 单个任务和整体项目的进展情况。
规模为P的项目组的总生产率为 Ltot=P(L-l(P-1)r) (13.6)
对于给定的L，l和r的值，总生产率Ltot是P的函数。 存在一个最佳的项目组规模Popt，其总生产率最高。 Boehm根据经验指出，软件项目的开发时间最多可 以减少到正常开发时间的75%。
制定进度计划
任务（活动）之间的依赖关系类型
项目组规模与项目组总生产率的关系。 P名项目组员之间的通信路径数: MIN= P-1, MAX= P(P-1)/2 通信路径数大约为Pα，其中1<α<2。 一个组员不与任何人通信时个人生产率为L， 每条通信路径导致生产率减少l， 组员个人平均生产率为: Lr=L-l(P-1)r (13.5) 其中，r是对通信路径数的度量，0<r≤1
（2） 输出项数： 软件向用户输出的项数，它们 向用户提供面向应用的信息，例如，报表和出错信 息等。报表内的数据项不单独计数。 （3） 查询数： 查询即是一次联机输入，它导致 软件产生某种即时响应(输出)。 （4） 主文件数： 逻辑主文件（即数据的一个逻 辑组合，它可能是大型数据库的一部分或是一个独 立的文件）的数目。 （5） 外部接口数： 机器可读的全部接口（例如， 磁盘或磁带上的数据文件）的数量，用这些接口把 信息传送给另一个系统。
i 1
13.3 进度计划
目的: 保证项目按时完成 影响工期的因素: 工作量, 资源(人力,设备), 项目特点 方法: 把项目分解成许多小任务以利于估计, 执行, 监控 难点: 根据项目, 合理分配任务, 优化使用资源, 留有余地 工具: 经验模型, GANTT图, 工程网络
项目管理者必须定义全部项目任务，识别出关键任务， 跟踪关键任务的进展状况。 制定一个详细的进度表，监督项目进度并控制整个项目。
为了缩短开发时间应该增加开发工作的人数。 随着开发小组规模扩大，个人生产率将下降， 开发时间与开发工作的人数非简单反比关系的两个 原因： 当小组变大时，通信开销增加了。 新成员要额外花费小组其他成员的时间。
被称为Brooks规律的下述现象： 向一个已经延期 的项目增加人力，可能(只)会使得它更加延期。
2. 估算功能点的步骤 用下述3个步骤，可估算出一个软件的功能点数 （即软件规模）。 FP=UFP×TCF
（1） 计算未调整的功能点数UFP 每个特性(即Inp、Out、Inq、Maf和Inf)都分类为 简单级、平均级或复杂级 UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf 其中，ai(1≤i≤5)是特性系数，其值由相应特性的复 杂级别决定，如表13.1
这类模型的总体结构形式如下： E=A+B×(ev)C 其中，A、B和C是由经验数据导出的常数，E是以 人月为单位的工作量，ev是估算变量（KLOC或 FP）。下面给出几个典型的静态单变量模型。 1.面向FP的估算模型 (1) Albrecht & Gaffney模型 E=-13.39+0.0545FP (2) Maston,Barnett和Mellichamp模型 E=585.7+15.12FP
单击此处编辑母版标题样式
• 单击此处编辑母版副标题样式
(2) 计算技术复杂性因子TCF 14种技术因素Fi(1≤i≤14)对软件规模的影响程度。 每个因素分配一个从0（无影响）到5（有很大影响） DI= F 值在0~70之间 技术复杂性因子TCF由下式计算：
14 i 1 i
TCF=0.65+0.01×DI (3) 计算功能点数FP FP=UFP×TCF 功能点数与所用的编程语言无关。在判断信息域特 性复杂级别和技术因素的影响程度时，存在着相当 大的主观因素。
甲项目的箭线图（ADM）或 双代号网络图（AOA）示例
采用PDM绘制的甲项目的网络图示例
活动历时估计
活动历时估计是根据任务分解中定义的项目活动
和项目活动清单来估计完成这些项目所需要的工期。 工期包括一项活动所消耗的实际工作时间 加上间歇时间。
制定进度计划
甘特图
甘特图，通过日历形式列出项目活动及其相 应的开始和结束日期，它为反映项目进度信 息提供了一种标准形式。
P生产率参数，反映了下述因素对工作量的影响： 总体过程成熟度及管理水平； 使用良好的软件工程实践的程度； 使用的程序设计语言的级别； 软件环境； 软件项目组的技术及经验； 应用系统的复杂程度。 开发实时嵌入式软件时:P~=2000；电信系统和系统 软件时:P=10000；商业应用系统:P=28000。 如果把项目持续时间延长一些，则可降低完成项目 所需的工作量。
13.2.3 COCOMO2模型
构造性成本模型: COCOMO（COnstructive COst Model) 。1981年Boehm在《软件工程经济学》中 首次提出了COCOMO模型。1997年Boehm等人提 出的COCOMO2，修订了COCOMO。 3个层次的软件开发工作量估算模型： (1) 应用系统组成模型用于估算构建原型的工作量。 (2) 早期设计模型适用于体系结构设计阶段。 (3)后体系结构模型适用于完成体系结构设计之后 的软件开发阶段。