北京理工大学 软件工程实践

1. 北京理工大学软件工程实践 汤铭端 中国航天科工集团公司204所

2. 第十二讲 软件估计 软件项目跟踪与控制

3. 内容和目的 • 了解软件估计的概念 • 掌握基本的软件估计方法 • 掌握软件项目追踪与控制的原理 • 了解软件项目追踪与控制的过程

4. 经验方法 类比方法 三点法 Delphi技术 分解法 宽带Delphi技术 功能点方法 生产率因子方法 COCOMO方法 IBM模型 软件估计方法

5. 经验方法 • 根据估计者自己的经验进行估计 • 根据大家的共同经验进行估计 • 标准工法 • 标准工时 • 根据项目和项目组的具体情况进行调整

6. 类比方法 • 使用过去类似项目的确切数字，考虑与当前项目的差异程度，来估计当前项目的相应数据。 当前项目估计=参考项目数据×（1+差异百分比） • 差异百分比当前项目比参考项目多（正）或少（负）的百分比。 • 规模估计可以选取功能、输入输出等作为比较的参考依据。 • 如当前项目系统与系统XYZ类似，XYZ系统的规模是10K代码行，当前系统比XYZ系统增加了约10%的功能。对当前系统的规模估计是：10K×（1+10%）=11K。

7. 三点法（Putnam模型） • 通过估计最大值、最可能值、最小值，并加权平均的估计方法。 估计期望值=（最大值+4×最可能值+最小值）/6 • 例如，若你认为软件规模的最大值是100K代码行，最小值是50K代行，而最可能值是60K代码行，则加权平均所获得的规模估计初始期望值为：（50+4×60+100）/6=65K代码行。

8. 分解方法 • 进行整体估计感觉困难的时候，可以采用分解方法。 • 软件的功能结构、物理结构、软件项目的WBS等都为分解估计方法提供了参考框架。 • 如根据软件的功能结构（逻辑结构）和/或软件（可能）的物理结构，将软件进行逐步分解，直至分解到能够对最小块进行较准确的估计。 • 分别采用基于经验的方法和/或某种估计方法，对分解得到的各块进行估计。 • 将这些子块的估计加在一起，获得对项目软件的整体估计。

9. 阶段 工作量分布比例 需求分析 18% 项目策划 5% 设计 20% 实现和集成 32% 测试 24% 形成产品 1% 各阶段工作量分布

10. 德尔菲(Delphi)方法 • 在难以获得经验、历史数据及专家时，可考虑采用德尔菲方法作为一种有效的替代估计方法。 • 德尔菲方法通过群体的智慧和交流分析来获得不断趋向准确和一致的估计结果。 • 过程：成立估计小组，首先介绍项目和产品情况，而后让估计小组成员分别进行估计，结果（第一轮）以列表和（或）直方图形式反馈给小组成员。在此基础上，估计值比平均值相差大的人各自讲述自己的理由，然后再分别进行下一次估计，得到新的估计结果（第二轮）。再次让小组讨论后进行新的估计（第三轮）。在第三轮结果的基础上进行最后的调整，得到的平均值就是估计结果。 • 通过上述估计和反馈过程，人们的估计会越来越接近，意见更为统一，也就能得到综合各方面意见更为准确的结果。

11. 宽带德尔菲(Wide Band Delphi) • 选择3至10名具有管理和估计经验的人员作为估计员 • 共同讨论和了解软件项目的目标、范围、需求、资源 • 分别按照各自的方法，对软件规模进行估计，并记录 • 分别分析项目估计的意外与风险，并确定估计风险与意外调整百分比 • 分别根据其初始估计和估计风险与意外调整百分比，确定各自的最后估计或最后估计范围。计算公式为： • 最后估计=初始估计×（1+意外调整百分比） • 最后估计范围=（1+[减少调整百分比，增加调整百分比]）×初始估计 • 必要时，安排进行讨论和再评估，以便进一步取得一致 • 估计负责人对所有的最后估计进行平均，获得规模估计

12. 生产率因子方法 • 假设在同等条件下开发速度（生产率）是一个常数。 • 各机构可以根据以前的工作经验和历史数据，获得生产率因子。再根据估计的软件产品规模，估计项目的工作量和持续时间。 • 确定项目产品的功能点 • 估计项目工作量和持续时间 5 功能点/人月 ≤生产率因子≤9 功能点/人月 生产率因子平均值=8 功能点/人月 工作量（人月）=功能点数/生产率因子 持续月数 = 2.5×（工作量人月数）0.38 • 各阶段工作量划分

13. 功能点方法 • 代码行数与编程语言相关的，不具可比性 • 功能度量是一致的、可比的 • 先进行核心计算获得未调整功能点（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个相关属性计算获得。

14. 未调整功能点UFP计算公式

15. 五个功能分量 • 用户输入数：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。 • 用户输出数：计算每个用户输出，它们向用户提供面向应用的数据。这里输出是指报表、屏幕、出错信息等。一个报表中的单个数据项不单独计算。 • 用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。 • 文件数：计算每个逻辑的主文件（如数据的一个逻辑组合。它可能是某个大型数据库的一部分或一个独立的文件。） • 外部接口数：计算所有机器可读的接口（如磁带或磁盘上的数据文件），利用这些接口可以将信息从一个系统传送到另一个系统。

16. 0 1 2 3 4 5 没有 影响 偶有 影响 轻微 影响 平均 影响 较大 影响 严重 影响 调整功能点AFP计算公式 • AFP=UFP×[0.65+0.01×∑Fi]，I=1-14 • Fi是对影响产品规模的14个因素进行分析确定的“复杂度调整值”，取值范围是0-5 • Fi通过回答后面的问题后参照以下标尺得到

17. Fi • 系统需要可靠的备份和复原吗？ • 需要数据通信吗？ • 有分布处理功能吗？ • 性能关键吗？ • 系统是否在一个已有的、很实用的操作环境中运行？ • 系统需要联机数据项吗？ • 联机数据项是否需要在多屏幕或多操作之间切换以完成输入？ • 需要联机更新主文件吗？ • 输入、输出、文件或查询很复杂吗？ • 内容处理复杂吗？ • 代码需要被设计成可重用吗？ • 设计中需要包括转换及安装吗？ • 系统的设计支持不同组织的多次安装吗？ • 应用的设计方便用户修改和使用吗？

18. COCOMO方法 • 构造性成本模型（COnstructive COst MOdel） • Barry Boehm 提出 • 当前使用最为广泛和最有效的估计软件项目开发成本和工作量的方法 • 两个核心方程：用规模估计工作量；用工作量估计项目持续时间 Effort = a× ( Size ) b Tdev = c× ( Effort ) d • Effort(人月)，Size(KLOC)，Tdev(月)

19. COCOMO的层次 • 基本COCOMO模型：将软件开发工作量（或成本）作为程序规模的函数进行计算，程序规模以估算的代码行表示 • 中级COCOMO模型：将软件开发工作量（或成本）作为程序规模及一组“成本驱动因子”的函数来进行计算，其中“成本驱动因子”包括对产品、硬件、人员、项目属性的主观评估 • 高级COCOMO模型：包含了中级模型的所有特征，并结合了“成本驱动因子”对软件工程过程中每一个步骤（分析、设计等）的影响的评估

20. COCOMO针对的软件项目类型 • 有机方式（Organic），主要关注数据处理、事务和数据检索 • 较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严肃的需求开展工作 • 嵌入式方式（Embedded），基于硬件系统的集成部件 • 必须在一组严格的硬件、软件及操作约束下开发的软件项目 • 半分离方式（Semi-Detached），介于有机方式和嵌入式方式之间 • 一个中等的软件项目，具有不同经验水平的项目组必须满足严格的及不严格的需求

21. 基本COCOMO的参数

22. 中级COCOMO的公式和参数 Effort = a× ( Size ) b×EAF

23. 产品属性 RELY：所需的软件可靠性 DATA：数据库的大小 CPLX：产品复杂性 计算机属性 TIME：执行时间方面的约束 STOR：主存限制 VIRT：虚拟机的易变性 TURN：计算机周转时间 人员属性 ACAP：分析员能力 AEXP：应用领域中的实际经验 PCAP：程序员能力 VEXP：虚拟机使用经验 LEXP：程序语言使用经验 项目属性 MODP：现代程序设计方法 TOOL：软件工具的使用 SCED：所需的开发进度 EAF= ΠＦＩ(I=1-15) ΠＦＩ表示15个成本属性的取值连乘，从产品、计算机、人员、项目等方面考虑 每个成本属性取值在0.9至1.4。平均情况下取1.0；如果对成本的影响较大取大于1.0；否则取小于1.0

24. 高级模型进一步对中级模型进行了两方面的改进：高级模型进一步对中级模型进行了两方面的改进： a.提出了针对不同开发阶段的成本属性因子 b.提出了成本属性因子按照模块级、子系统级、系统级等三级产品层次结构变化和确定 高级模型

25. 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

26. 功能点和各种语言代码行对比

27. 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为所需的开发人员数。

28. 项目的追踪和控制

29. 项目管理 • 制定计划 • 按计划去做 • 执行计划 • 检查计划的执行情况 • 控制对计划的偏差

30. 项目管理 计划 执行 追踪 控制 PDCA环 计划 执行 检查 处理 对比

31. 项目的追踪和控制 • 计划、追踪、控制是项目管理不可分割的三个环节 • 控制的基础是信息，信息的获得靠追踪 • 计划-追踪-控制是一个封闭循环，一个系统过程，一个以信息为共同核心的相互依赖、相互制约的互动过程。 • 计划-追踪-控制的主要对象是进度、成本、质量

32. 什么是项目追踪 • 项目追踪是指项目各级管理人员根据项目的规划和目标等，在项目实施的整个过程中对影响项目进展的内外部因素进行及时的、连续的、系统的记录和报告的下列活动过程。

33. 项目追踪对象 范围 变更 关键假设 资源供给 非项目时间 主要里程碑 进度 工作时间及任务完成情况 项目总结报告 收集信息范围 投入活动信息 采购活动信息 实施活动信息 项目产出信息 项目追踪系统的设计…

34. 项目追踪系统的设计 • 项目追踪过程 • 观察 • 测量 • 分析 • 报告

35. 什么是项目控制 • 项目控制是指在项目按事先制定的计划朝最终目标挺进的过程中，由于前期工作的不确定性和实施过程中多种因素的干扰，实施进展必然会偏离轨道，为此，项目管理者根据项目追踪提供的信息，对比原计划（即定目标），找出偏差，分析成因，研究纠偏对策，实施纠偏措施的全过程。 • 项目控制的目的是使项目按预定的轨迹运行和实现。

36. 项目控制原理 • 控制：为了改善某个或某些对象的功能和发展，需要获得并使用信息，并以这种信息为基础，加于该对象上的作用。 • 系统原理、反馈原理、封闭原理。 • 项目控制的三步曲原理： • 寻找偏差 • 原因于趋势分析 • 采取纠偏行动

37. 项目控制方法 • 传统项目控制以各种文件、报表、图表为主要工具，以定期、不定期会议为主要方法。 • 项目控制文件：合同、工作范围细则、职责划分细则、项目程序细则、技术范围文件、计划文件 • 项目控制会议：检查分析里程碑完成情况、计划未实现的影响、工作何时能完成、是否采取纠偏措施、何时才能回到计划轨道、下一步活动里程碑计划

38. 控制过程 • 自动控制 • 通过/通不过控制 • 采取检测方式看特定的先决条件是否被满足 • 项目用得最多的控制方式 • 在基本控制检查点进行 • 后控制 • 为改善未来项目实现目标的机会而设立

39. 项目控制系统的组成 建立系统（目标）标准 获得最新信息 偏差分析、评价 采取纠偏措施 通知所有有关部门 项目控制分析工具 偏差分析 趋势分析 关键比值 因果分析 项目控制系统的设计

40. 项目的三大控制权衡 • 质量控制 • 进度控制 • 控制权衡 • 在质量、成本、进度过程的约束三角形内完成项目是科学、艺术、意志的完美结合。 • 如果项目超出了控制范围，想不牺牲范围、预算、计划进度或质量就实现项目目标是困难的。

41. 制定基准计划 （进度计划、预算） 项目开始执行 等到下一个 报告期 在每个报告期内 收集实际进程数据 （进度、成本） 将变更修订进 项目计划 估算新的进度、 预算和预测 分析目前状况 与基准计划比较 需要采取纠正 措施吗？ 否 是 确定纠正措施 协调相关变更

42. 对软件的特别建议… • 对10%或以上的进度偏移的纠正，如果没有对软件功能的10%或更多的减少，或者成本、风险10%或以上的增加，则是不可期望的。 • 对延误的软件项目增加更多的人手通常使其延误更多。 • 在选取供应商之前允许需方和客户利用演示体验软件产品的能力，可以缓解风险。 • 用原型开发软件功能的一部分来演示功能的适当执行。 • 关键的系统工程工作的实施不能没有足够的软件工程专门知识。

43. 对软件的特别建议 • 与投资方合作，在项目过程中定期评审软件需求基线，以调整目标（成本，进度，绩效）。 • 项目成员和小组的数目应当与预算和进度相联系，正常的控制间距不应当被跨越。 • 由于软件的结果的显现是困难的，评估进展存在许多困难。管理者必须定义和推敲确定进展的技术，以在早期发现成本或进度的超越，或绩效的不足。 • 由于软件开发和维护活动通常依赖个人的技巧和经验，管理者应当努力防止在工作进行中不必要地替换职员。

44. 项目追踪和监督—CMM的要求 活动1 将已文档化的软件开发计划用于跟踪软件活动和传送状态。 活动2 按照已文档化的规程修订项目的软件开发计划。 活动3 高级管理者参与按照已文档化的规程评审那些对组织外部的个人和组所作的软件项目约定和约定的更改。 活动4 将经批准的、影响软件项目约定的更改传达给软件工程组和其它软件－有关组的成员。 活动5 跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施。 活动6 跟踪项目的软件工作量和成本，必要时采取纠正措施。

45. 项目追踪和监督—CMM的要求 活动7 跟踪项目的关键计算机资源，必要时采取纠正措施。 活动8 跟踪项目的软件进度，必要时采取纠正措施。 活动9 跟踪软件工程技术活动，必要时采取纠正措施。 活动10 跟踪与项目的成本、资源、进度及技术方面有关的软件风险。 活动11 记录软件项目的实际测量数据和重新策划的数据。 活动12 软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进展、计划、性能和问题。 活动13 按照已文档化的规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果。

46. 追踪 了解项目的进展情况 采集项目进展数据 统计分析 与计划对比 发现与计划的偏差 控制 分析偏差 决策是否调整计划 按规程调整计划 评审、实施、管理 软件项目的追踪与控制

47. 项目追踪的方式 • 定期会议报告 • 项目组成员定期报告 • 里程碑检查 • 评审记录审查 • 软件质量保证人员报告 • 统计分析 • 与计划对比

48. 软件项目追踪与控制过程 • 确定追踪元素 • 工作量、成本、进度、资源、风险 • 追踪 • 个人工作周记 • 项目工作月报 • 阶段总结报告 • 分析决策 • 计划

49. 工作产品名称 规模 工作量 成本 开始日期 完成日期 计划 实际 计划 实际 计划 实际 计划 实际 计划 实际 规模、工作量、成本和进度跟踪表

50. 序号 名称 型号版本 数量 技术指标 使用起始日期 使用持续日期 备注 计划 实际 计划 实际 计划 实际 计划 实际 计划 实际 关键资源跟踪表