项目估算指南
版本:V1.0
1介绍
1.1目的
本文件的目的是描述在项目计划过程中可参照的指南,以确保正确的使用估算方法进行项目估算。
1.2范围
本文件只适用于公司的软件开发类项目估算。
2术语表
| 名称/缩写 | 英文全称 | 中文解释 |
| CPM | Critical Path Method | 关键路径法 |
| PERT | Program Evaluation an Review Technique | 计划评审技术 |
| PP | Project Plan | 项目策划 |
| Delphi(戴尔菲) | Delphi | 戴尔菲法、一种流行的专家评估技术 |
本规程应用于项目不同时机的项目估算(PP),主要包括Delphi法、类比法、PERT法和CPM法的使用指南说明,以及常用估算方法介绍。
4项目估算指导
4.1估算对象描述
| 估算对象 | 可选估算单位 | 估计属性 | 说明 |
| 规模 | 基准功能/代码行/文档页数 | 数量:规模度量单位个数 | |
| 工作量 | 人天/人月/人年 | 难度(D):(0-2) 复用率(R):(0-100%) 实现生产率:3.0(天/基准功能) | 难度指综合考虑的复杂度和实现难度 复用率是指对已有的代码复用,而非本项目中的复用 |
| 进度 | 工时 | 人员技能等级和权重:初级(0.8)、中级(1.0)、高级(1.3) |
根据《项目估算计划》或特定估算时机,确定各类估算对象的估算时机,依照《项目估算表》进行估算,参考如下项目估算时机表,其中前三种次估算时机是必做的估算,其他估算时机依项目情况由项目经理自行决定。
| 估算时机 | 估算对象 | 参考工作产品 | 估算目的描述 |
| 项目策划初始估算 | 规模、工作量、进度 | 《项目合同附件》 《方案建议书》 《客户需求说明书》 | 确定项目核心组织; 明确需求调研和需求分析阶段的人员投入和工作计划; 确定项目各阶段时间计划; |
| 需求规格说明书通过评审后,概要设计阶段开始时 | 规模、工作量、进度 | 《需求规格说明书》 | 为安排详细进度计划提供依据; 估计项目的完整规模、工作量和人员需求; |
| 发生重大变更时 | 规模、工作量、进度 | 《变更申请单》 | 确定变更对规模、工作量和进度的影响; |
| 计划与实际有严重偏差时 | 规模、工作量、进度 | 《项目状态报告》 | 属纠偏措施,目的在于提供计划更准确估计值; |
4.3.1规模度量单位
| 规模单位 | 说明 | 适用条件 |
| 基准功能 | 通过对业务功能的特点,分类定义成不同类型的基准功能单位 | 适用于有已知项目范围或项目需求,对产品进行规模估计; |
| 代码行 | 有效代码行 | 适用于设计完成后,对编码实现,对产品进行规模估计; |
| 文档页数 | 参考各类模板,经裁剪后的估计页数; | 适用于对产出物类文档规模估计 |
4.3.2.1难度/复用率
| 名称 | 度量指数 | 分类准则 | 说明 |
| 难度(D) | 1. 基准功能难度值D=1; 2. 比基准功能简单时0 | 1.涉及10-20个业务数据项 2.包含6-8个业务操作 | 业务数据项:需求点所涉及可得到的业务数据项 页面:实现此功能所需的页面数 |
| 复用率(R) | 0-100% | 在此项目中存在已有可重用的指数 | 如:完全复用=100%;复用半数=50%;,没有复用=0% |
| 分类 | 名称 | 实现语言 | 实现生产率 | 分类准则 | 说明 |
| 产品 | J基准功能 | Java | 3人天/规模单位 | 1.涉及15±5个业务数据项 2.由3个页面组成 | 参考准则: 1.包含6-8个业务操作 2.使用2-3个业务数据表 3.包含1-2个业务规则 |
| C#基准功能 | C# | 3人天/规模单位 | 1.涉及15±5个业务数据项 2.由3个页面组成 | 参考准则: 1.包含6-8个业务操作 2.使用2-3个业务数据表 3.包含1-2个业务规则 | |
| 文档 | 文档页数 | 1人天/5页 | 编写文档的平均生产率 |
| 类别 | 等级 | 权重 | 说明 |
| 开发人员 | 初级 | 0.8 | 对应初级软件开发工程师 |
| 中级 | 1.0 | 对应中级软件开发工程师 | |
| 高级 | 1.3 | 对应高级软件开发工程师 |
| 序号 | 活动类型 | 组织参考比例 | 说明 |
| 1 | 项目管理 | 10% | 组织参考的分配比例,请以《组织过程数据库》定义为准 |
| 2 | 需求分析 | 22% | |
| 3 | 系统设计 | 18% | |
| 4 | 实现 | 30% | |
| 5 | 测试 | 10% | |
| 6 | 系统实施 | 5% | |
| 7 | 质量保证 | 3% | |
| 8 | 配置管理 | 2% |
根据项目特点,根据如下选择建议,选用估算方法,进行估算。
1.对于没有有历史数据积累,而估算人员没有估算经验,优先选用Delphi法进行估算。
2.对于没有有历史数据积累,而估算人员有估算经验,优先选用PERT法进行估算。
3.对于有历史数据积累,优先选用类比法进行估算。
4.当前,Delphi法、PERT法作为通用方法,可由项目经理自行选择
5.在项目启动阶段初始估算,从1-4中选择合适方法进行规模估算,使用自上而下进行工作量估算。
6.在需求分析完成,需求确认后,从1-4中选择合适方法进行规模估算,使用自下而上进行工作量估算。
4.5估算内容
4.5.1规模估算
规模估算是根据已经确定的估算单位确定产品的大小,如参考基准功能定义准则进行估计。
对于有历史数据积累时,优先使用《类比规模估算表》进行估算。
4.5.2工作量估算
当明确项目工作产品,完成产品WBS分解后的估算,采用《自上而下》方法,根据《估算表》进行项目整体工作量估算;
对于项目需求不确定,产品为完成WBS分解,在需求分析前,先采用《自下而上》方法,根据《估算表》和《项目已定义过程》的项目WBS结果,进行项目启动阶段和需求分析阶段的工作量估计;当完成需求分析后,再次采用《自上而下》方法进行项目整体工作量估算。
4.5.2.1自上而下
根据规模估算结果,并对WBS分解结果(如模块)的实现难度和复用率进行估计,根据组织提供的实现生产率,计算构建产品和完成交付文档所需的工作量。
工作量最小以人天为单位,换算关系为:1人月=22人天;1人天=8人时。
工作量的估算是基于规模估算结果,通过《项目估算表》的工作量自上而下估算,以下是工作量计算公式如下:
1.实现工作量 = ∑(单位规模数*(1-复用率)*难度)*实现生产率
2.项目总工作量 = 实现工作量/实现所占比例
3.各类活动工作量 = 项目总工作量*各类活动工作量所占比例
4.各阶段工作量 = ∑(阶段中各类活动工作量比例*各类活动工作量)
4.5.2.2自下而上
根据《项目进度计划》任务分解结果,对所有任务逐条估计工作量,然后按需向上累加工作量,得到各工作组工作量、阶段内活动工作量、各阶段工作量、项目总工作量等。参考《项目估算表》的工作量自下而上估算表进行估算。
4.5.3进度估算
4.5.3.1估计项目阶段和里程碑
根据项目实施特点,对于有明确的项目起始时间,采用《固定项目工期》方法估计阶段和里程碑;对于资源固定(主要是人力资源),则采用《固定人力资源》方法估计阶段和里程碑。
4.5.3.2固定项目工期
当项目工期固定时,进度估算主要依据阶段或增量的工作量和里程碑时间约束,合理安排人力资源,完成进度安排。估算步骤如下:
1.根据项目生命周期模型和项目已定义过程,明确项目阶段组成和项目里程碑。
2.先确定里程碑活动,根据项目要求识别强里程碑(强里程碑指,项目甲方或投资人预先设定时间点的里程碑),并设置里程碑时间点;对于非强里程碑的,则根据里程碑所在的阶段时间点来确定。
3.根据组织不同项目类型的阶段的工期配比,初步确定项目各阶段工期;结合人力资源情况和强里程碑的时间约束调整项目阶段工期。
4.根据各阶段的工作量估算结果,对各阶段的工作量提供指导,确保各阶段的工作任务的总工作量与估算的工作量相当。
5.在Project文档中安排各阶段的项目WBS工作任务的依赖关系,如有FS、SS、FF、滞后和提前等关系。
4.5.3.3固定人力资源
当人力资源固定时,进度估计完成各阶段或增量中的工作任务所需的工作时间为基础,根据项目生命周期模型和项目已定义过程,确定项目阶段后增量、以及里程碑的时间点。估算步骤如下:
1.根据项目已定义过程和项目生命周期模型提供的项目WBS和产品WBS的结果,形成Project文档
2.根据工作量估算结果,得到的各阶段或增量的工作量(按人月计)除以可得的人力资源数,估算出阶段或增量的工期;
3.在Project文档中安排各阶段的项目WBS工作任务的依赖关系,如有FS、SS、FF、滞后和提前等关系;
4.除了实现工作任务外,对其他的工作量进行估计,并根据可得的人力资源合理安排项目工作任务确定里程碑时间点;
4.5.4成本估算
根据组织要求,填写《项目预算表》,完成项目成本估算。
5估算方法介绍
5.1类比法
类比估算法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目,通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度,因此,用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制,对历史项目的数据分析是可信赖的。其基本步骤是:
1.整理出项目模块列表和实现每模块的操作数/功能点;
2.标识出每个模块列表与历史项目的相同点和不同点,特别要注意历史项目做得不够的地方;
3.通过步骤1和2得出各个模块的估计值;
4.产生规模估计。
软件项目中用类比法,主要是基于模块近似实现,存在模块复用等场合。
5.2PERT法
PERT (计划评审技术,Program Evaluation an Review Technique) 主要用来估计项目工期,Barry Boehm 将此技术应用来估计软件的规模、工作量或者成本,称为Pert Sizing估算方法,此时,该方法解释为: 在估计每一项任务时,首先按最佳的、可能的、悲观的三种情况给出估计值,分别记作a、m、b,则估计结果按如下的公式计算:
E = (a+4m+b)/4 ,E为期望值。
在该公式中,包含了如下的2个原理:
1)对上面公式进行变换,引入一个中间结果c,a、m、b的平均值 ,则可以看出E=(m+c)/2 ,也就是说,E是a、m、b三数的平均数与m又求了一次平均。
2)从上面的公式也可以看出,在计算E的公式中,m的权重是4,而a和b的权重都是1,也就是说,该方法强调了中间值的重要性,而极值的重要性并不高。
对于该方法,在实际使用,需要注意如下问题:
1)当只有一个人参与估算时,则需要估算人估算三个数值:悲观值、可能值、乐观值,然后套用E的计算公式就可以了。
2)当有2个人参与估算时,则需要2个估算人分别估算三个数值:悲观值、可能值、乐观值,然后分别计算这3个数值的平均值,再将悲观值、可能值、乐观值的平均值代入E的计算公式就可以了。
3)当有3个人参与估算时,有2种方法:
a.类似第(2)种情况处理,此时总共需要估计9个数;
b.每个人只估计一个数,取最大最小值作为悲观值与乐观值,取中间的数值作为可能值,代入E的计算公式。
4)当有N个人(N>3)参与估算时,也有2种方法:
c.类似第(2)种情况处理,此时总共需要估计3N个数;
d.每个人只估计一个数,取最大最小值作为悲观值与乐观值,对中间的N-2个数值取平均值作为可能值,代入E的计算公式。
在这种情况下,需要注意当N=6时,假设6个数按从大到小依次排列为:a,b,c,d,e,f,此时,E就是此6个数的平均值了。当N>6时,比如N=7,假设7个数按从大到小依次排列为:a,b,c,d,e,f,g. 此时可以发现2个极值的权重大于了中间值的权重,这就违背了PERT方法的原理2)。
如果在取可能值时,以所有参与人员的估算值的平均值,则会存在极值的权重高于了中间值的权重,违背了PERT方法的原理2)。
因此,综合上边的分析可以看出,PERT方法一般适合于少于6人参与估算的情况。
5.3Delphi估算法
Delphi法是最流行的专家评估技术,在没有历史数据的情况下,这种方式适用于评定过去与将来,新技术与特定程序之间的差别,但专家“专”的程度及对项目的理解程度是工作中的难点,尽管Delphi技术可以减轻这种偏差,专家评估技术在评定一个新软件实际成本时通常用得不多,但是,这种方式对决定其他模型的输入时特别有用。Delphi法鼓励参加者就问题相互讨论。这个技术,要求有多种软件相关经验人的参与,互相说服对方。
1.估算准备
1)项目经理根据项目的特点选定估算类型(规模,工作量等),确定估算组织者,参与者,会议议程,并准备好相应的材料。在选择估算人员时应考虑:
2)3-5名具有开发经验的人员,可以是项目组外的人员
3)具备该项目的背景知识
4)指定的估算组织者负责与参加估算人员进行沟通,确定估算会的时间,地点,会议议程。
2.估算会议
1)会议启动
a.在必要时,组织者向参与者解释Delphi方法
b.组织者发给估算参与人估算的输入材料
c.组织者对估算内容进行陈述,帮助估算人员了解项目背景
d.对每一个需要估算的任务小组讨论出共同的假设和约定条件,并作为估计的基础
2)初始估算
a.估算参与人检查提供的工作任务列表内容,为每一项任务进行估算,得到初始估算数据,并且清晰注明所考虑的假设和。
b.组织人收集所有人的匿名估算数据。
3.估算解释,再估算
1)初始估算结束后,估算组织者解释估算人员填写的估算值及假设条件,所有人一起讨论被估算的对象,使用的假设,需要澄清的问题等,讨论中应注意:
2)有可能需要增加任务
3)讨论时间由组织人负责控制在15-20分钟
4)讨论之后,估算参与人根据讨论中获得的新信息和假设,以及考虑别人的意见,各自对自己的估算进行调整,此过程中应避免互相讨论。
5)组织人收集所有人的匿名估算数据,用图形标明所有人调整的估算值,一轮估算结束。
4.达成一致
1)组织者判断是否结束估算,应考虑以下几种情况:
2)所有人的估算的结果已经落到一个能够接受的狭窄范围之内
3)没有人愿意对自己的估算进行修改
4)会议时间到
5)已经进行4轮估算
6)如果无法达成一致,需要进行再估算,重复以上过程(估算解释,再估算)
5.整合数据
7)组织者收集估算活动原始记录表格。
8)组织者针对估算结果进行讨论后选择估算数据。可选用的方法包括:
c.取平均值
d.取中值
5.4关键路径法
关键路径法(CPM),也称为关键路径分析,是一种用来预测项目总体历时的项目网络分析技术,它既可以用来估计软件项目的总体进度,也是帮助项目经理克服项目进度拖延现象的一种重要工具。一个项目的关键路径是指一系列决定项目最早完成时间的活动。它是项目网络图中最长的路径,并且有最少的浮动时间或时差。浮动时间或时差是指一项活动在不耽搁后继活动或项目的完成日期的条件下可以拖延的时间长度。
要找到一个项目的关键路径,首先必须绘制一个好的网络图,而绘制项目网络图又需要一个建立在工作分解结构基础上的活动清单。一旦建立了项目网络图,必须估计每项活动的历时,然后才能确定关键活动。关键路径的计算包括将项目网络图每条路径所有活动的历时分别相加。最长的路径就是关键路径。
下图显示了一个简单项目的项目网络图,该图总共包含4条路径。每条路径从第一个节点(1)开始,在最后一个节点(8)结束。该图也显示了每条路径在项目网络图上的长度或总历时。通过将路径上各个活动的历时相加,就可计算出每条路径的长度。由于路径B-E-H-J有最长的历时——16天,所以这条路径叫项目的关键路径。
Figure 1 关键路径示例
尽管关键路径是历时最长的路径,但它反映了项目完成的最短时间。如果关键路径上有一项或多项活动所花费的时间超过计划的时间,除非项目经理采取某种纠正措施,否则项目总体进度就要被拖延。
一个项目可能有一条以上的关键路径,在上面这个例子中,假设活动A的估计历时是3天,那么路径1的长度增加到16天。现在该项目有两条长度相同的最长路径,所以有两条关键路径。此时,项目经理应该同时注意这两条关键路径上活动的执行情况
随着项目的进展,一个项目的关键路径可能发生变化。假设在上面的例子中,活动I出现了问题,活动I的完成时间超过4天,那么它使路径4的长度比其它三条路径长,而此时假定其它路径都按计划进行。这种变化会使路径4成为新的关键路径。因此,一个项目的关键路径可能会发生变化。下载本文