整理估算指南0527.docx
《整理估算指南0527.docx》由会员分享，可在线阅读，更多相关《整理估算指南0527.docx（20页珍藏版）》请在冰点文库上搜索。
整理估算指南0527
1目的
此文档作为软件质量体系中的估算过程的具体使用指南，用来指导本行项目过程中的估算活动实施的进行。
本指南假设读者已了解并熟悉软件质量体系的估算过程，在此前提下，对于过程中已作了明确要求和解释的内容，将不再详细说明，指南将着重说明与本行实际情况相结合的关键事项。
2估算的目标范围
2.1什么是估算
估算就是对项目将花费多少资源、持续多长时间或将花费多少成本的预测，通过估算结果与项目目标进行比较来确定项目目标是否足够现实，在无法通过控制项目达到目标时，必须调整项目目标使其更符合实际情况。
良好估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策，为项目跟踪提供重要的支持。
估算与计划、承诺的区别：
估算是客观的过程。
估算结果构成了计划的基础，但计划并不一定要与估算结果相同。
如果估算结果与目标之间存在显著的区别，进行项目计划时就要认识到两者之间的差距，并考虑可能存在较高的风险。
计划是有目的性的主观设计过程去寻求特定的结果。
我们经常会让计划倾向某个方面以得到特定的结果，通过计划一些特定的方法来达到特定的目标。
承诺是许诺在特定日期之前以特定质量水平交付规定的功能。
承诺可以与估算相同，可能比估算更激进，也可能比估算更保守。
也就是说，不要假定承诺必须和估算是一样的；它们是不相同的。
计划的结果往往在很多时候是一种承诺。
2.2估算对象
通常估算的对象有规模、进度、成本、工作量等。
在实际的估算过程中，我们常常直接进行工作量估算，所以很容易混淆项目规模和工作量。
为了区分这两个概念，在本指南中，“规模”特指软件系统本身的规模大小而不指工作量大小，一般使用诸如代码行、功能点、用户案例（UseCase）或者其他度量单位来估算给定项目属性集的技术工作的范围。
对于一个项目的估算活动，最困难的估算在于规模与总工作量，而其他的目标值，如：
进度、资源、成本等都可以从中计算出来。
因此：
1、当前本行的软件项目估算的目标范围包括有：
a）规模（建议使用代码行（单位：
千行）或功能点数（单位：
个）统计）
b）工作量（单位：
人月）
c）进度（单位：
工作日或月）
d）成本（单位：
万元）
2、首要的估算目标为：
项目规模、总工作量。
2.3进入估算的思想准备
2.3.1什么是好估算
要做好估算，首先应当先明确的就是“好估算”。
良好估算是指对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。
从数据统计上看，一个估算良好的项目，单点估算值可能和最终结果有所偏差，但最终结果始终在估算范围之内，并且随着项目的进行，估算范围是越来越小的。
如图1：
时间
项目启动
图1：
良好估算过程的数据比较图
图2是一个估算较差且有低估倾向的项目的估算过程数据统计，该项目一直处于低估状态，并且估算的范围太窄以致于始终没有将最终结果估算进范围内。
图2：
不好的估算过程的数据比较图
2.3.2为什么我的估算总是不准确
2.3.2.1估算不准确罪魁祸首之一：
低估
大多数人都这样认为，如果你给一个开发者5天时间去做一件4天就能完成的工作，他必然会去寻找一些事情来把多出来的一天用掉；如果你给一个项目组6个月时间来完成4个月就能完成的项目，他们同样会找到办法来把多出来的2个月用掉，所以管理者都希望通过挤压估算来避免这个现象。
当然还有一些人认为如果给了太多的时间，开发人员往往会把任务放到后面来开展，这样他们还是匆匆忙忙的完成甚至无法按时完成。
这些担忧都是正确的，而且也是客观事实，但是在软件开发中，高估的代价是线性的可控的，顶多就是浪费掉多估出来的那些时间。
图3：
高估和低估代价示意图
但是低估就没有坏处么？
有，而且低估的代价是非线性的不可控的（见上图），例如估算错误造成计划5%-10%的延迟本身并不是很要紧的问题，但是很多时候估算造成的是100%以上的偏差，基于这样估算上的计划就是在猜想了，计划也就根本没有意义了；同时，由于低估带来的计划延期等问题在严格规范管理的组织里需要进行延期原因分析、影响评估、计划变更评审等等相关工作，这些工作所需要代价往往是非线性增长的。
所以不要有目的的去低估，低估的代价比高估的代价更高，更何况程序员一般是乐观主义者，他们往往给出的估计值就已经是较少的时间和成本了。
2.3.2.2估算不准确罪魁祸首之二：
拍脑袋
在估算中拍脑袋的表现就是即兴估算，就是根据个人记忆在未仔细考虑前给出的看似思考分析过的估算值。
因为个人记忆常常出现错误，比如并不是记住项目的实际结果而是估算值或者是直觉，所以这种估算也常常出现错误。
根据McConnell收集的24组估算人员的即兴估算数据，并对即兴估算的平均误差和经过小组评审的估算结果的平均误差进行比较，见下图：
图4：
即兴估算与评审过的估算的平均误差比较图
可见一般的即兴估算的平均相对误差量为67%，而一般评审过的估算的误差只有30%，只有前者的一半。
所以不要拍脑袋，即使只用15分钟坐下来查查以前的记录的数据再进行估算也会更加准确些。
2.3.2.3估算不准确罪魁祸首之三：
遗漏工作
看看下面这些表，是不是有些工作你根本没想到要在开发过程中进行呢?
或许就是这些漏网之鱼每每造成你的估算值变小，导致项目计划不合理而常常延期。
表1:
软件估算中经常遗漏的功能需求和非功能需求
功能需求
非功能需求
安装程序
准确度
可复用性
数据转换工具
互操作性
可伸缩性
使用第三方或开源软件所需的集成代码
可修改性
安全性
帮助系统
性能
抗毁性
部署方式
可靠性
易用性
与外部系统的接口
响应性
表2软件估算中经常遗漏的软件开发活动
交接/部署
数据转换
安装
定制
需求澄清
维护修订控制系统
为构建工作提供支持
安装测试版本
生成测试数据
管理测试版程序
参与技术评审
集成工作
项目开发过程中为现有系统提供技术支持
项目开发过程中对以前的系统进行维护
缺陷纠正工作
性能调整
学习新开发工具
与缺陷跟踪有关的管理工作
开发人员与测试人员间的相互协调
回答质量保证部门提出的问题
编辑和评审用户文档
评审技术文档
新团队成员的所需的准备时间
指导新团队成员
管理层协调、管理人员会议
维护运行每日构建所需的脚本
维护与每日构建相关联的自动化模拟测试
与客户或最终用户进行交互，为客户安装测试版本提供支持
评审计划、估算、架构、详细设计、阶段计划、代码、测试用例等等
处理变更请求
出席变更控制会议
与分包商进行协调
向客户或用户演示软件
表3软件估算中经常遗漏的非软件开发性活动
休假
公司会议
病假
配置新的工作站
周末
假日
部门会议
培训
在工作站上安装新版工具
排除软硬件故障
3估算的时机
3.1一般的估算时机
理论上，主动估算可以在项目周期内的任何时间，只要项目没有结束，就有估算的意义和价值。
并且随着不确定性的消除，估算才会更加准确，因此在制定出消除不确定性的决策后，估算便可以进行并有更大的价值，参见下图。
可见在需求大纲定义完成（已批准的产品定义）、需求完成、用户界面设计完成、详细设计完成等里程碑点上是进行估算的时点。
很明显我们知道估算的时间越早，价值越高，但准确性也越低；越往后，由于条件的充分，估算准确性越高，但价值越小。
根据不确定性影响统计（见下图），让我们感到幸运的是估算的准确度在项目的前30％的时间内可以得到显著改善。
图5：
项目开发过程不确定性收敛图
3.2本行项目的估算时机
根据我行目前项目模式和组织流程的特点，要求但不仅限于以下几个时间点进行估算：
1.立项准备阶段，需求大纲完成后，项目经理需要对项目总成本进行初步估算，以作为项目立项的必要内容之一。
（以下简称“立项成本估算”）
2.项目立项完成，启动阶段。
项目经理需要对项目总体进度进行估算，估算结果将帮助制定项目章程和项目总体计划。
（以下简称“总体进度估算”）
3.软件开发计划阶段，需求设计完成后，项目经理或开发负责人应对项目的详细进度、资源需求情况进行估算，以支持制定详细开发计划。
（以下简称“详细进度估算”）
4.概要设计评审通过后，对项目总成本进行重估算。
（以下简称“成本重估算”）
4怎么做估算
4.1选择估算方法
4.1.1影响估算方法选择的几个因素
选择估算方法时，要考虑我们要估算的对象、被估算项目的规模、软件开发方式、所处的开发阶段以及需要的估算准确度的影响。
这些因素可能的情况见表格：
影响因素
可能情况
估算对象
规模、工作量、进度、特性
项目规模
小、中、大
开发阶段
早期、中期、后期
软件开发方式
迭代式、顺序式或两者皆可
可能的准确度
低、中、高
1．估算对象
在实际估算过程中，一般是先确定项目要实现的软件项目的特性，然后估算为了交付这些特性需要多少时间和工作量。
当然也有些项目则是先确定他们的预算和开发时间限制，然后估算在这些限制内可以交付多少特性。
一般来说，特性、时间和成本是相互制约、此消彼长的关系，因为项目应先明确目标再进行有针对性的估算。
2．项目规模
小型：
一般指不超过5个团队人员的项目，因为受个人生产率变化的影响，基于统计的估算方法不太适用，最佳的估算方法为“自底向上”的方法，也就是基于将要实际进行工作的个人提供的估算之来进行估算。
中型：
项目大约包括5－25个人，持续时间为3－12个月。
几乎可以使用所有的估算方法。
大型：
项目拥有超过25人以上的团队成员，项目将持续6－12个月以上。
项目早期，最佳的估算方法是基于数学和统计学的“自顶向下”的方法；项目中期，可以结合“自顶向下”和基于项目自身历史数据的自底向上的方法结合起来；项目后期，自底向上的方法可以提供最准确的估算。
3．开发阶段
早期：
顺序式项目中，早期阶段是指从项目概念起始到需求定义基本完成的时期；在迭代式项目中，早期指的是初始计划的时期。
中期：
在顺序式项目中，是指从需求工作、架构工作到完成了足够的构造（可能是详细设计或者编码）活动产生了可以用于估算的项目生产率数据；迭代式项目中，中期则指最初的2－4次迭代，也是为后期估算产生项目自身生产率数据的阶段。
后期：
包括从中期构造直到项目发布的时间。
4．软件开发方式
迭代式项目和顺序式项目都可能开始于自顶向下的或者说基于统计学的估算方法，最后都迁移到自底向上的方法。
由于迭代式项目的每次迭代都可以产生实际的生产率数据，所以在使用项目自身的数据时，它们可以更快地对估算结果进行精化。
常见的几种生命周期模型相对于估算而言顺序式和迭代式的分类如下：
顺序开发：
瀑布模型、v模型、分阶段交付、RUP
迭代开发：
Scrum、极限编程、演进式原型法
5．可能的准确度
估算方法的准确度取决于三个方面：
估算方法本身、方法是否被用于适当的估算问题和方法被用于项目的哪个阶段。
而且一般来说高准确度的估算也需要较高的估算成本，因此根据项目所处的阶段和当时的不确定性情况，选择低成本、低准确度的方法或许是更实际的。
4.1.2现有估算方法的适用性
在本指南中，将简单引入几种最通常的估算方法，作为组织级推荐的方法。
这些方法和方法选择判断条件有：
估算方法
判断条件
按工作分解结构（WBS）分解
类比估算
宽带Delphi法
简化功能点（Dutch）法
专家估算法（Pert）
估算对象
工作量
规模、工作量、进度、特性
规模、工作量、进度、特性
规模、特性
规模、工作量、进度、特性
项目规模
中大
小中大
中大
小中大
小中大
开发阶段
早期-中期
早期-后期
早期
早期
早期-后期
迭代式或顺序式
两者皆可
两者皆可
顺序式
顺序式
两者皆可
可能的准确度
中
中
中
低
高
各类估算方法的详细介绍和使用范例，请见相应的估算方法手册。
随着今后质量体系的推广，对估算过程的规范性和估算结果准确性也将慢慢提高，将逐步引入更多更完善的估算方法，以适应发展的需要。
4.1.3后续准备工作
估算方法选定后，为了保证估算高效开展，项目经理还应进行以下工作：
1、确定估算参与人员：
选定估算方法后，我们需要根据选择的估算方法确定参与估算人员的资格要求，选定合适的估算参与人员，并提前通知相关人员；
2、项目相关信息准备：
本项目和估算相关信息，如需求说明书、设计说明书、项目基本情况等；
3、估算方法介绍：
相关估算专家不了解将使用的估算方法的情况时，估算组织者（一般是项目经理）应准备相关估算方法的培训材料，相关培训也可以向QA申请，由QA进行培训。
4、估算所需资料准备：
估算组织者（一般是项目经理）应事先学习选定的估算方法，并依据方法要求，准备好估算需要的材料，如必要的历史资料、已往相关项目的经验数据、以及电子文档、打印纸质表格、估算结果记录表、白板等。
综合性规划
（1）土地利用的有关规划；4.2通用的顺序式开发项目估算过程
一个获得良好估算的项目的单个估算流程，首先应关注对规模的估算，然后根据规模估算值中计算出工作量、进度、成本和可交付的特性（如功能点），估算过程见下图。
规模估算主要适用于顺序式项目的早期和中期阶段，后期则主要通过自底向上的进行工作量估算即可。
常见的规模估算方法见下表：
方法
（3）环境影响分析、预测和评估的可靠性；可估算的规模类型
目前，获得人们的偏好、支付意愿或接受赔偿的意愿的途径主要有以下三类：
①从直接受到影响的物品的相关市场信息中获得；②从其他事物中所蕴含的有关信息间接获得；③通过直接调查个人的支付意愿或接受赔偿的意愿获得。
类比
二、环境影响评价的要求和内容特性、功能点、web页面、GUI组件、数据库表、接口定义、代码行
（二）安全评价的基本原则分解
（4）预防或者减轻不良环境影响的对策和措施的合理性和有效性；特性、功能点、web页面、GUI组件、数据库表、接口定义、代码行
Dutch方法（简化功能点法）
（5）污染防止措施能否达到要求。
功能点、代码行
功能点
功能点、代码行
宽带Delphi
功能、用户故事、故事点、需求、用例、功能点、Web页面、GUI组件、数据库表、接口定义、类、函数/子例程、代码行
4.2.1从规模推算总工作量
大部分项目最终将根据详细任务清单直接估算工作量，但在项目早期，从规模估算值计算出的工作量估算值是最准确的做法。
对项目工作量影响最大的因素是待构建软件的规模，其次的因素是组织的开发生产率水平。
1、有历史数据可参考的情况下：
如果有规模差距不大的项目的历史数据，就可以考虑用类比法，甚至是直接采用线性模型来估算，例如：
a）获得历史项目的指标数据：
单位功能点工作量。
此指标的来源：
根据历史相关项目的数据统计而来。
计算方法：
单位功能点工作量=某历史项目的真实总工作量/这个项目在对应的时间上估算出来的功能点数据
b）根据已知的规模（功能点数），参考历史数据，可算出总工作量。
计算方法：
当前项目总工作量=单位功能点工作量*当前项目的规模
对于这些历史项目的类比数据，有不同的维度可以选择，比如针对某个PM的数据。
针对某一类项目的统计，针对某个业务部门的统计。
不同的组合可以得到精度不同的结果。
2、使用ISBSG方法来计算：
Ø项目类型：
一般
Ø项目类型：
改进已有项目
Ø项目类型：
新开发项目
Ø项目类型：
桌面应用
4.2.2从工作量推算成本
按照本行对单位工作量的成本换算标准（3万/人月），即可。
4.2.3从工作量推算进度
假设项目工作量已知，需要推算项目的进度。
1.有历史数据时
可以考虑类比法，获得历史项目的指标数据：
历史进度、历史工作量。
直接使用公式计算：
指数取1/3适用于超过大约50人月的工作量的中型和大型项目，对较小的项目，指数应该取1/2。
2.项目早期且无历史数据时
在中型和大型项目的早期，可以直接使用基本的进度公式：
系统3.0是可以根据实际情况调整的，一般应使用本行的历史数据进行校准，可以得到特定的比例系数。
在明确了将参与项目工作的具体人员后，应转用其他方法进行估算。
4.3组织估算
不同的估算方法，有不同的过程、参与人员和组织形式。
鉴于本行目前主要使用顺序式开发方法，本指南主要以顺序式开发来介绍各估算过程的可能情况。
在条件准备到位后，开始执行估算过程。
4.3.1立项估算
对于“立项估算”（成本和总体进度），建议估算过程如下：
1、估算进入条件：
需求大纲编写完成
2、估算内容为：
成本和进度，一般是根据已经确定的项目需要完成的需求来估算项目的规模或者所需的工作量，进而计算出项目所需要的成本和时间。
3、估算过程
a）根据确定的估算方法来估算项目规模或者项目工作量，可能的估算方法有Dutch功能点估算法、类比估算法、专家估算法（PERT公式）等。
b）估算人员使用宽带Delphi过程来收敛得到的估算值，此时估算值一般是以单点数据来体现的。
c）若是得到项目规模估算值，可以根据从规模推算工作量的方法推算项目工作量或a）中介绍的估算方法估算项目工作量。
若直接估算项目工作量则直接执行d）。
d）根据项目估算工作量直接计算或采用估算方法估算项目成本（N）。
e）根据项目不确定性因素的影响，该阶段的项目估算准确度在[-50%，+100%]之间，因此我们以（0.5N－2.0N）来体现估算结果。
4、估算结果
关于估算结果应用时需注意：
a）不应提交用于这些计算的单点值，预算公布值应是最高值2.0N。
b）本期估算结果除了用于估算预算外，不应用于外部承诺
4.3.2总体进度估算
对于“总体进度估算”（进度），建议估算过程如下：
1、估算进入条件：
业务需求规格说明书完成，进入启动阶段
2、估算目标为：
进度，根据已经确定的项目需要完成的需求来估算项目规模或所需的工作量，从而得出项目所需要的时间；或者根据项目的时间、成本限制来估算项目所能完成的需求范围。
3、估算过程
a）根据确定的估算方法来估算项目规模或项目工作量，可能的估算方法有功能点估算法、类比估算法、自底向上估算法、专家估算法等
b）估算人员使用宽带delphi过程来收敛得到的估算值，此时一般是以单点数据来体现的
c）若是得到项目规模估算值，可以根据从规模推算工作量的方法推算项目工作量或a）中介绍的估算方法估算项目工作量。
若直接估算项目工作量则直接执行d）。
d）根据项目估算工作量直接计算或者使用估算方法估算项目进度（N）。
e）根据项目不确定性因素的影响，该阶段的项目估算准确度在[-50%，+100%]之间，因此我们以（0.5N－2.0N）来体现估算结果。
4、估算结果
关于估算结果应特别注意的是：
a）不应提交用于这些计算的单点值，所需进度的公布值应为2.0N
b）本期估算结果除了用于估算项目总体进度外，不应用于外部承诺
4.3.3详细进度估算
对于“详细进度估算”（工作量、进度），操作过程如下：
1、估算进入条件：
软件需求分析完成，进行项目详细计划制定前
2、估算目标为：
进度，根据已经确定的项目需要完成的需求来估算项目所需的工作量，从而得出项目所需要的时间。
3、估算过程
a）根据确定的估算方法来估算项目规模或项目工作量，可能的估算方法有类比估算法、自底向上估算法、专家估算法（PERT公式）等。
b）估算人员使用宽带delphi过程来收敛得到的估算值，此时一般是以单点数据来体现的
c）若是得到项目规模估算值，可以根据从规模推算工作量的方法推算项目工作量或a）中介绍的估算方法估算项目工作量。
若直接估算项目工作量则直接执行d）。
d）根据项目估算工作量直接计算或使用估算方法估算项目进度（N）。
e）根据项目不确定性因素的影响，该阶段的项目估算准确度在[-33%，+50%]之间，因此我们以（0.67N－1.50N）来体现估算结果。
4、估算结果可用于支持制定详细的软件开发计划
a）按照1.0N分配预算、资源和工作量
b）按照0.25N分配应急预算
c）只公布估算范围的最大值（1.5N）
4.3.4成本重估算
对于“成本重估算”（成本），操作过程如下：
1、估算进入条件：
概要设计完成
2、估算内容为：
成本，根据已经确定的项目需要完成的需求和时间限制来估算项目所需的工作量，从而得出项目所需要的成本。
3、估算过程
a）根据确定的估算方法来估算项目所需的工作量，可能的估算方法有类比估算法、自底向上估算法、专家估算法（PERT公式）等获。
b）估算人员使用宽带delphi过程来收敛得到的工作量估算值，此时一般是以单点数据来体现的。
c）通过工作量估算项目成本值（N）。
d）根据项目不确定性因素的影响，该阶段的项目估算准确度在[-20%，+25%]之间，因此我们以（0.8N－1.25N）来体现估算结果。
4、估算结果应用于支持计划和成本估算
a）按照1.0N分配预算、资源和工作量
b）按照0.25N分配应急预算
c）只公布估算范围的最大值（1.25N）
4.3.5其他重估算
在项目假设出现显著变化时都应对项目进行重估算，假设中的变化包括但不限于需求的增加、主要需求定义的变更、可用人员的变更以及进度目标的变更。
4.4估算输出物
估算全部完成后，项目经理应负责将估算结果填入要求的表格，并整理估算过程中的相关资料，整理出估算报告，一并提交入库。
升级会员 