Download - 北京理工大学 软件工程实践
北京理工大学软件工程实践汤铭端
中国航天科工集团公司 204 所
第十二讲软件估计
软件项目跟踪与控制
内容和目的 了解软件估计的概念 掌握基本的软件估计方法 掌握软件项目追踪与控制的原理 了解软件项目追踪与控制的过程
软件估计方法 经验方法 类比方法 三点法 Delphi 技术 分解法 宽带 Delphi 技术
功能点方法 生产率因子方法 COCOMO 方法 IBM 模型
经验方法 根据估计者自己的经验进行估计 根据大家的共同经验进行估计
标准工法 标准工时
根据项目和项目组的具体情况进行调整
类比方法 使用过去类似项目的确切数字，考虑与当前项目的差异程度，来估计当前项目的相应数据。
当前项目估计 = 参考项目数据 × （ 1+ 差异百分比） 差异百分比当前项目比参考项目多（正）或少（负）的百分比。 规模估计可以选取功能、输入输出等作为比较的参考依据。 如当前项目系统与系统 XYZ 类似， XYZ 系统的规模是10K 代码行，当前系统比 XYZ 系统增加了约 10% 的功能。对当前系统的规模估计是： 10K×（ 1+10%）=11K。
三点法（ Putnam 模型） 通过估计最大值、最可能值、最小值，并加权平均的估计方法。
估计期望值 = （最大值 +4× 最可能值 + 最小值） /6 例如，若你认为软件规模的最大值是 100K 代码行，最小值是 50K 代行，而最可能值是 60K代码行，则加权平均所获得的规模估计初始期望值为：（ 50+4×60+100 ） /6=65K 代码行。
分解方法 进行整体估计感觉困难的时候，可以采用分解方法。 软件的功能结构、物理结构、软件项目的 WBS 等都为分解估计方法提供了参考框架。 如根据软件的功能结构（逻辑结构）和 / 或软件（可能）的物理结构，将软件进行逐步分解，直至分解到能够对最小块进行较准确的估计。 分别采用基于经验的方法和 / 或某种估计方法，对分解得到的各块进行估计。 将这些子块的估计加在一起，获得对项目软件的整体估计。
各阶段工作量分布 阶段 工作量分布比例
需求分析 18%
项目策划 5%
设计 20%
实现和集成 32%
测试 24%
形成产品 1%
德尔菲 (Delphi) 方法 在难以获得经验、历史数据及专家时，可考虑采用德尔菲方法作为一种有效的替代估计方法。 德尔菲方法通过群体的智慧和交流分析来获得不断趋向准确和一致的估计结果。 过程：成立估计小组，首先介绍项目和产品情况，而后让估计小组成员分别进行估计，结果（第一轮）以列表和（或）直方图形式反馈给小组成员。在此基础上，估计值比平均值相差大的人各自讲述自己的理由，然后再分别进行下一次估计，得到新的估计结果（第二轮）。再次让小组讨论后进行新的估计（第三轮）。在第三轮结果的基础上进行最后的调整，得到的平均值就是估计结果。 通过上述估计和反馈过程，人们的估计会越来越接近，意见更为统一，也就能得到综合各方面意见更为准确的结果。
宽带德尔菲 (Wide Band Delphi) 选择3至 10名具有管理和估计经验的人员作为估计员 共同讨论和了解软件项目的目标、范围、需求、资源 分别按照各自的方法，对软件规模进行估计，并记录 分别分析项目估计的意外与风险，并确定估计风险与意外调整百分比 分别根据其初始估计和估计风险与意外调整百分比，确定各自的最后估计或最后估计范围。计算公式为：
最后估计 = 初始估计 × （ 1+意外调整百分比） 最后估计范围 = （ 1+[ 减少调整百分比，增加调整百分比 ]） × 初始估计
必要时，安排进行讨论和再评估，以便进一步取得一致 估计负责人对所有的最后估计进行平均，获得规模估计
生产率因子方法 假设在同等条件下开发速度（生产率）是一个常数。 各机构可以根据以前的工作经验和历史数据，获得生产率因子。再根据估计的软件产品规模，估计项目的工作量和持续时间。
确定项目产品的功能点 估计项目工作量和持续时间5 功能点 / 人月 ≤生产率因子≤ 9 功能点 / 人月生产率因子平均值 =8 功能点 / 人月工作量（人月） = 功能点数 / 生产率因子持续月数 = 2.5× （工作量人月数） 0.38 各阶段工作量划分
功能点方法 代码行数与编程语言相关的，不具可比性 功能度量是一致的、可比的 先进行核心计算获得未调整功能点（ UFP），然后用调整因子获得值调整因子（ VAF），将 UFP乘以 VAF ，就达到了调整功能点（ AFP）。
AFP=UFP×VAF UFP 的计算：考虑五个功能分量：外部输入 EI ，外部输出
EO ，外部查询 EQ ，文件 EIF ，外部接口 ILF。UFP= IEI×EI+ IEO×EO+ IEQ×EQ+ IEIF×EIF+ ILIF×LIF
VAF 根据软件项目和软件产品的 14个相关属性计算获得。
未调整功能点 UFP 计算公式测量参数 计数 简单 平均 复杂
用户输入数 × 3 4 6 =
用户输出数 × 4 5 7 =
用户查询数 × 3 4 6 =
文件数 × 7 10 15 =
外部接口数 × 5 7 10 =
总计数值 × =
五个功能分量 用户输入数：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。 用户输出数：计算每个用户输出，它们向用户提供面向应用的数据。这里输出是指报表、屏幕、出错信息等。一个报表中的单个数据项不单独计算。 用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。 文件数：计算每个逻辑的主文件（如数据的一个逻辑组合。它可能是某个大型数据库的一部分或一个独立的文件。） 外部接口数：计算所有机器可读的接口（如磁带或磁盘上的数据文件），利用这些接口可以将信息从一个系统传送到另一个系统。
调整功能点 AFP 计算公式 AFP=UFP×[0.65+0.01×∑Fi]， I=1-14 Fi是对影响产品规模的 14个因素进行分析确定的“复杂度调整值”，取值范围是 0-5 Fi通过回答后面的问题后参照以下标尺得到0 1 2 3 4 5没有影响 偶有影响 轻微影响 平均影响 较大影响 严重影响
Fi1. 系统需要可靠的备份和复原吗？2. 需要数据通信吗？3. 有分布处理功能吗？4. 性能关键吗？5. 系统是否在一个已有的、很实用的操作环境中运行？6. 系统需要联机数据项吗？7. 联机数据项是否需要在多屏幕或多操作之间切换以完成输入？8. 需要联机更新主文件吗？9. 输入、输出、文件或查询很复杂吗？10. 内容处理复杂吗？11. 代码需要被设计成可重用吗？12. 设计中需要包括转换及安装吗？13. 系统的设计支持不同组织的多次安装吗？14. 应用的设计方便用户修改和使用吗？
COCOMO 方法 构造性成本模型（ COnstructive COst
MOdel） Barry Boehm 提出 当前使用最为广泛和最有效的估计软件项目开发成本和工作量的方法 两个核心方程：用规模估计工作量；用工作量估计项目持续时间
Effort = a× ( Size ) b
Tdev = c× ( Effort ) d
Effort(人月 )， Size(KLOC)， Tdev(月 )
COCOMO 的层次 基本 COCOMO 模型：将软件开发工作量（或成本）作为程序规模的函数进行计算，程序规模以估算的代码行表示 中级 COCOMO 模型：将软件开发工作量（或成本）作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、项目属性的主观评估 高级 COCOMO 模型：包含了中级模型的所有特征，并结合了“成本驱动因子”对软件工程过程中每一个步骤（分析、设计等）的影响的评估
COCOMO针对的软件项目类型 有机方式（ Organic），主要关注数据处理、事务和数据检索
较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严肃的需求开展工作 嵌入式方式（ Embedded），基于硬件系统的集成部件
必须在一组严格的硬件、软件及操作约束下开发的软件项目 半分离方式（ Semi-Detached），介于有机方式和嵌入式方式之间
一个中等的软件项目，具有不同经验水平的项目组必须满足严格的及不严格的需求
基本 COCOMO 的参数a b c d
有机 2.4 1.05 2.5 0.38半分离 3.0 1.12 2.5 0.35嵌入 3.6 1.20 2.5 0.32
中级 COCOMO 的公式和参数
(p.84 有错 ) a b
有机 2.8 1.05半分离 3.0 1.12嵌入 3.2 1.20
Effort = a× ( Size ) b×EAF
EAF= Π ＦＩ (I=1-15)
产品属性 RELY ：所需的软件可靠性 DATA ：数据库的大小 CPLX ：产品复杂性
计算机属性 TIME ：执行时间方面的约束 STOR ：主存限制 VIRT ：虚拟机的易变性 TURN ：计算机周转时间
人员属性 ACAP ：分析员能力 AEXP ：应用领域中的实际经验 PCAP ：程序员能力 VEXP ：虚拟机使用经验 LEXP ：程序语言使用经验
项目属性 MODP ：现代程序设计方法 TOOL ：软件工具的使用 SCED ：所需的开发进度
Π ＦＩ表示 15个成本属性的取值连乘，从产品、计算机、人员、项目等方面考虑
每个成本属性取值在 0.9至 1.4 。平均情况下取 1.0；如果对成本的影响较大取大于 1.0；否则取小于 1.0
高级模型 高级模型进一步对中级模型进行了两方面的改进：
a. 提出了针对不同开发阶段的成本属性因子b. 提出了成本属性因子按照模块级、子系统级、系统级等三级产品层次结构变化和确定
COCOMO2.0 1995年形成适用面更宽、更为精确的改进模型 COCOMO2.0 COCOMO2.0 的核心公式与 COCOMO 一致，但系数不同 a取常参数 2.5， b变参数，由五个属性共同确定：
PERC ：开发先例 FLEX ：开发灵活性 RESL ：体系结构 /风险解决方案 TEAM ：小组凝聚力 PMAT ：过程成熟度
分别在 1.0周围取值 W1，W2，W3，W4，W5 b = 1.01 + 0.01 ∑ Wi
功能点和各种语言代码行对比程序设计语言 LOC/
FP程序设计语言 LOC/FP
汇编语言 320 面向对象语言 30C 128 第四代语言 20COBOL 105 代码生成器 15FORTRAN 105 电子表格 6PASCAL 90 图形语言 4ADA 70
IBM 模型 总结 IBM 的 60个项目数据，其中源代码从 400 到467000 ，开发工作量从 12人月到 11578人月，使用了 29种编程语言和 66 中不同的计算机。
E = 5.2 × L 0.91
D = 4.1 × L 0.36 = 2.47 × E 0.36
S = 0.54 × E 0.6
DOC = 49 × L 1.01
其中， E为开发工作量，单位为人月；D 为项目持续时间，单位为月；DOC 为文档页数；L为源代码行数；S为所需的开发人员数。
项目的追踪和控制
项目管理 制定计划 按计划去做
执行计划 检查计划的执行情况 控制对计划的偏差
对比 项目管理
计划 执行 追踪 控制
PDCA环 计划 执行 检查 处理
项目的追踪和控制 计划、追踪、控制是项目管理不可分割的三个环节 控制的基础是信息，信息的获得靠追踪 计划 -追踪 -控制是一个封闭循环，一个系统过程，一个以信息为共同核心的相互依赖、相互制约的互动过程。 计划 -追踪 -控制的主要对象是进度、成本、质量
什么是项目追踪 项目追踪是指项目各级管理人员根据项目的规划和目标等，在项目实施的整个过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的下列活动过程。
项目追踪系统的设计… 项目追踪对象
范围 变更 关键假设 资源供给 非项目时间 主要里程碑 进度 工作时间及任务完成情况 项目总结报告
收集信息范围 投入活动信息 采购活动信息 实施活动信息 项目产出信息
项目追踪系统的设计 项目追踪过程
观察 测量 分析 报告
什么是项目控制 项目控制是指在项目按事先制定的计划朝最终目标挺进的过程中，由于前期工作的不确定性和实施过程中多种因素的干扰，实施进展必然会偏离轨道，为此，项目管理者根据项目追踪提供的信息，对比原计划（即定目标），找出偏差，分析成因，研究纠偏对策，实施纠偏措施的全过程。 项目控制的目的是使项目按预定的轨迹运行和实现。
项目控制原理 控制：为了改善某个或某些对象的功能和发展，需要获得并使用信息，并以这种信息为基础，加于该对象上的作用。 系统原理、反馈原理、封闭原理。 项目控制的三步曲原理：
寻找偏差 原因于趋势分析 采取纠偏行动
项目控制方法 传统项目控制以各种文件、报表、图表为主要工具，以定期、不定期会议为主要方法。 项目控制文件：合同、工作范围细则、职责划分细则、项目程序细则、技术范围文件、计划文件 项目控制会议：检查分析里程碑完成情况、计划未实现的影响、工作何时能完成、是否采取纠偏措施、何时才能回到计划轨道、下一步活动里程碑计划
控制过程 自动控制 通过 / 通不过控制
采取检测方式看特定的先决条件是否被满足 项目用得最多的控制方式 在基本控制检查点进行
后控制 为改善未来项目实现目标的机会而设立
项目控制系统的设计 项目控制系统的组成
建立系统（目标）标准 获得最新信息 偏差分析、评价 采取纠偏措施 通知所有有关部门
项目控制分析工具 偏差分析 趋势分析 关键比值 因果分析
项目的三大控制权衡 质量控制 进度控制 控制权衡
在质量、成本、进度过程的约束三角形内完成项目是科学、艺术、意志的完美结合。 如果项目超出了控制范围，想不牺牲范围、预算、计划进度或质量就实现项目目标是困难的。
制定基准计划（进度计划、预算）项目开始执行
在每个报告期内收集实际进程数据（进度、成本） 将变更修订进项目计划
估算新的进度、预算和预测分析目前状况与基准计划比较
确定纠正措施协调相关变更
需要采取纠正措施吗？
等到下一个报告期
是否
对软件的特别建议… 对 10% 或以上的进度偏移的纠正，如果没有对软件功能的 10% 或更多的减少，或者成本、风险 10% 或以上的增加，则是不可期望的。 对延误的软件项目增加更多的人手通常使其延误更多。 在选取供应商之前允许需方和客户利用演示体验软件产品的能力，可以缓解风险。 用原型开发软件功能的一部分来演示功能的适当执行。 关键的系统工程工作的实施不能没有足够的软件工程专门知识。
对软件的特别建议 与投资方合作，在项目过程中定期评审软件需求基线，以调整目标（成本，进度，绩效）。 项目成员和小组的数目应当与预算和进度相联系，正常的控制间距不应当被跨越。 由于软件的结果的显现是困难的，评估进展存在许多困难。管理者必须定义和推敲确定进展的技术，以在早期发现成本或进度的超越，或绩效的不足。 由于软件开发和维护活动通常依赖个人的技巧和经验，管理者应当努力防止在工作进行中不必要地替换职员。
项目追踪和监督— CMM 的要求活动 1 将已文档化的软件开发计划用于跟踪软件活动和传送状态。活动 2 按照已文档化的规程修订项目的软件开发计划。活动 3 高级管理者参与按照已文档化的规程评审那些对组织外部的个人和组所作的软件项目约定和约定的更改。活动 4 将经批准的、影响软件项目约定的更改传达给软件工程组和其它软件－有关组的成员。活动 5 跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施。活动 6 跟踪项目的软件工作量和成本，必要时采取纠正措施。
项目追踪和监督— CMM 的要求活动 7 跟踪项目的关键计算机资源，必要时采取纠正措施。活动 8 跟踪项目的软件进度，必要时采取纠正措施。活动 9 跟踪软件工程技术活动，必要时采取纠正措施。活动 10 跟踪与项目的成本、资源、进度及技术方面有关的软件风险。活动 11 记录软件项目的实际测量数据和重新策划的数据。活动 12 软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进展、计划、性能和问题。活动 13 按照已文档化的规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果。
软件项目的追踪与控制 追踪
了解项目的进展情况 采集项目进展数据 统计分析 与计划对比 发现与计划的偏差
控制 分析偏差 决策是否调整计划 按规程调整计划 评审、实施、管理
项目追踪的方式 定期会议报告 项目组成员定期报告 里程碑检查 评审记录审查 软件质量保证人员报告 统计分析 与计划对比
软件项目追踪与控制过程 确定追踪元素
工作量、成本、进度、资源、风险 追踪
个人工作周记 项目工作月报 阶段总结报告
分析决策 计划
工作产品名称 规模 工作量 成本 开始日期 完成日期计划 实际 计划 实际 计划 实际 计划 实际 计划 实际
规模、工作量、成本和进度跟踪表
序号 名称型号版本 数量 技术指标 使用起始日期 使用持续日期
备注计划 实际 计划 实际 计划 实际 计划 实际 计划 实际
关键资源跟踪表
序号 名称型号版本 数量 技术指标 使用起始日期 使用持续日期
备注计划 实际 计划 实际 计划 实际 计划 实际 计划 实际
风险跟踪表
课题名称 时段
填表人 岗位 填表日期
工作产品名称 完成比例规模 投入时间
总体 新编 更新 总计 周 1 周 2 周3 周4 周 5 周 6 周日
工作陈述：
下周工作计划：
上级主管评语：
附注：
个人工作周报
文档编制完成百分比计算方法 事件 工作完成百分比
启动 10
启动内部评审 50
完成内部评审 75
文档通过正式评审，并已受到软件配置管理 100
短期工作完成百分比计算方法 事件 工作完成百分比
任务启动 50
任务完成 100
需求分析完成百分比计算方法 事件 工作完成百分比
任务启动 10
完成系统级需求和相关算法的定义 40
需求分类并详细说明 55
完成软件需求规格说明到系统规格说明的追踪 65
启动内部评审 75
完成内部评审 90
文档通过正式评审，并已受到软件配置管理 100
设计工作完成百分比计算方法 事件 工作完成百分比 启动任务 10
完善数据流图，定义相关算法 25
定义软件单元和结构关系 35
定义了每个软件单元的所有性能规格说明 /算法 50
定义了每个软件单元的接口规格说明 60
完成软件设计文档到软件需求规格说明的追踪 70
启动内部评审 80
完成内部评审 90
文档通过正式评审，并已受到软件配置管理 100
程序开发完成百分比计算方法 事件 工作完成百分比
启动任务 10
完成编码 50
完成代码审查 60
完成代码单元测试 85
软件单元追踪到软件设计文档 95
代码存入软件配置管理库 100
测试设计完成百分比计算方法事件 工作完成百分比
启动任务 10
确定测试用例设计原则 30
设计完测试用例 60
形成测试说明 75
启动内部评审 80
完成内部评审 90
测试说明存入软件配置管理库 100
课题名称 月 份
填表人 填写日期 跟踪表版本
序号 数据分析内容 数据分析结论是 否 不适用
不知道1 分配需求的更改
2 新的软件约定
3 对软件约定的更改
4 未来工作中可能出现新的软件风险
5 未来工作中可能需要新的关键资源
6 项目工作产品的规模的实际值与项目计划中的预计值相差 15% 以上
7 项目工作产品的完成工期的实际值与项目计划中的预计值相差 15% 以上
8 项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15% 以上
9 项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10 出现重大的软件技术问题
11 资源不到位
12
13
14
15
不适用数据分析内容的证据：课题组内部评审结论：下月工作计划：工程部经理审查意见： 需要更改项目计划吗？ 是 否附注：
课题工作月报
课题名称 阶段名称
填表人 填写日期 跟踪表版本
序号 数据分析内容 数据分析结论是 否 不适用
不知道1 分配需求的更改
2 新的软件约定
3 对软件约定的更改
4 未来工作中可能出现新的软件风险
5 未来工作中可能需要新的关键资源
6 项目工作产品的规模的实际值与项目计划中的预计值相差 15%以上
7 项目工作产品的完成工期的实际值与项目计划中的预计值相差 15%以上
8 项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15%以上
9 项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%
10 出现重大的软件技术问题 11 资源不到位 12 13 14 15
不适用数据分析内容的证据：课题组内部评审结论：正式评审结论：工程部经理审查意见： 需要更改项目计划吗？ 是 否附注：
阶段总结报告
分析决策 根据偏差确定是否需要修改计划：
项目工作产品的规模的实际值与项目计划中的预计值相差 15% 以上？ 项目工作产品的完成工期的实际值与项目计划中的预计值相差 15% 以上？ 项目工作产品所花费的工作量和成本的实际值与项目计划中的预计值相差 15% 以上？ 项目里程碑的完成日期点的的实际值与项目计划中的预计值相差时间值超过项目整个工期的 10%？
更改项目计划 明确修改内容 外部约定的更改与批准 受影响的组和个人参与和认可对约定的更改 按照软件项目策划过程修订项目计划，并形成文档。必要时重新估计项目的规模、工作量、成本、进度、关键资源，重新分析软件风险 对配置管理计划和质量保证计划进行相应修改 评审项目计划更改 审查和批准对项目计划的修改 生成项目计划新版本并实施配置管理 将约定和计划的更改传达到相关组和个人
Boehm(1991) Top Ten Risk Item1. 人力不足2. 不切实际的进度和预算3. 开发错误的软件功能4. 开发错误的用户界面5. 镀金6. 连续不断的需求变更7. 外部执行任务的短缺8. 外部供应部件的短缺9. 实时性能的短缺10. 紧张的计算机科学能力
