软件项目估算（一）
大家好，我将从以下三个方面来介绍软件项目估算（希望能做到深入浅出）：
一、什么是项目估算
二、为什么做项目估算
三、项目估算的方法
内容有点多，分几篇讲吧。
一、什么是项目估算
项目估算是对需求分析、设计、编码、测试、集成交付等整个软件开发过程所花费工作量、时间、成本等的预测。是软件研发中最难的工序之一。
二、为什么做项目估算
软件系统的规模、功能越来越复杂，难于理解，必须通过某种方法对软件的规模、工期、成本进行度量、预计，从而能更好的控制软件开发活动。（有很多非常有趣的漫画用于形容项目估算、工期的问题，大家自己搜搜吧）
项目估算是制定合理的项目计划的基础。
三、项目估算的方法
下图是常见的评估方法以及可用于评估的对象。我们以规模和工作量的估算为主，因为工期和成本是可以通过规模和工作量计算出来的。
3.1 规模估算
可进行估算的规模属性包括需求数、接口数、功能数、功能点数、文档页数、代码行数、类与对象数、数据库表与字段数等等。（参见CMMI-PP）
上述规模属性可以划分为两类：
1） 技术规模：开发人员角度，常用的是基于代码行的估算
2） 功能规模：用户角度，较流行的是基于功能点的估算
在COCOMOII模型中，定义了功能点和不同语言的代码行之间的转换关系。
1.基于代码行的估算：
在软件生命周期早期阶段，一般不采用代码行估算规模。
优势：
- 直观
劣势：
- 没有公认的可接受的代码行标准。尽管SEI等对源代码行做出了定义，但仍无法面面俱到。在注释、变量、复用语句、包含多条指令的语句等处都有分歧
- 过于依赖编程语言及个人能力
- 在项目早期，需求不稳定、设计不成熟、实现不确定的情况下估算准确度较低
- 过于强调编码的工作量，编码只是项目实现阶段的一部分
2.基于功能点的估算：
2003年，功能点估算方法被ISO标准采纳，包括：1个总标准（ISO14143）和5个子标准。
- IFPUG：适用所有类型软件，主要用于MIS（使用最为广泛）
- NESMA：与IFPUG十分相似，简化了使用流程
- Mark II：适用逻辑事务能被确定的任何类型软件
- COSMIC：适用商业应用软件和实时系统
- FISMA：适用所有类型软件
优势：
- 可以在早期根据功能需求对产品规模进行估算
- 在信息系统、数据库密集系统、4GL应用系统开发中被广泛认可
劣势：
- 其考虑复杂性问题的客观性受到质疑，不能应用在逻辑较复杂的实时系统、科学软件开发中， 对于此类软件的规模度量，还需要考虑诸如复杂度、状态转换数目等信息。
3.1.1 WideBand Delphi（宽带Delphi）
适合条件：没有历史数据的情况
时机：立项阶段、计划阶段的初步估计
人员：
- 估计专家，至少3人
- 项目经理，可兼任估计专家
- 评估协调人，可由项目经理兼任。如果项目经理同时兼任估计专家和协调人，须注意匿名估计的有效性
流程：
- 协调人发送估计所需的材料，估计表
- 协调人召集会议，讨论与待估量相关的估计假定和理由
- 专家匿名提交估计表
- 协调人整理，并将结果返回给专家，计算各待估量的最大值、最小值、平均值、偏差率。若偏差率未超过可接受范围，则不需要再估计，可将平均值作为最终结果。建议的偏差率可接受范围为30%。偏差率=MAX[（最大值-平均值），（平均值-最小值）] / 平均值
- 协调人召集会议，讨论偏差率超出可接受范围的待估量。不用对估计结果进行讨论，看是否可以将一些任务再进行分解或者合并
- 专家匿名提交新的估计表
- 重复4~6，直至估计分布范围已小到可接受的范围
优点：不需要历史数据，适合新类型项目的估计。
缺点：
- 依赖于专家的经验，对专家的业务素质要求较高
- 可能需要多轮估计，比较费时
3.1.2 三点估算法
适合条件：没有历史数据的情况
时机：立项阶段、计划阶段的初步估计
人员：
- 估计专家，至少3人
- 项目经理，可兼任估计专家
- 评估协调人，可由项目经理兼任。
流程：
- 协调人发送估计所需的材料，估计表
- 协调人召集会议，讨论与待估量相关的估计假定和理由
- 专家填写待估量最小值、一般值、最大值，提交估计表
- 协调人计算待估量的最小值a、一般值b、最大值c a=（a1+a2+…+an）/n；b=（b1+b2+…+bn）/n；c=（c1+c2+…+cn）/n
- 协调人计算期望值 E=（a+4b+c）/6
优点：不需要历史数据，适合新类型项目的估计
缺点：依赖于专家的经验，对专家的业务素质要求较高
其他：
- 先计算最小值、一般值、最大值的平均值，再计算期望值，与先计算每个专家的期望值，再计算期望值的平均值，得到结果是一样的
- 如果是先计算出了每个专家的期望值，也可以采用Delphi的方法，计算出偏差率，对超出偏差率范围的待估量进行讨论，可以直接讨论确定估计值，也可以再进行几轮估计
3.1.3 类比法
适合条件：存在类似的具有可比性的项目
时机：立项阶段、计划阶段的初步估计
人员：项目组
流程：
- 确定类比项目
- 整理项目比较因子，常见的比较因子有软件开发方法、功能需求文档数、接口数等，由项目组讨论确定
- 标识每个比较因子与历史项目的相同点和不同点 特别注意历史项目做得不够的地方
- 计算各个任务或工作产品的估计值，估计值=历史项目类比值*调整系数，调整系数应由项目组讨论决定
- 合计系统总估计值
优点：基于实际系统开发经验，成本低，耗时少
缺点：
- 依赖于历史项目与现行项目的近似程度，准确性可能很高（当是本质而非表面上的相似，例如某些升级项目），但也可能很低
- 依赖于历史项目数据的完整性、准确性
其他：
- 可重用代码的估计：例如，有2000行代码，30%须重新设计，50%须重新编码，70%须重新测试，则2000 * （30%+50%+70%）/3 = 1000，即重用这2000行代码相当于编写1000行代码的工作量。
3.1.4 功能点法
功能点法重点介绍IFPUG和NESMA两个标准。
功能点是重头戏，下次集中讲吧。
文章被以下专栏收录
