整理估算指引-0527

精品文档1目的此文档作为软件质量体系中的估算过程的具体使用指南，用来指导本行项目过程中的估算活动实施的进行。本指南假设读者已了解并熟悉软件质量体系的估算过程，在此前提下，对于过程中已作了明确要求和解释的内容，将不再详细说明，指南将着重说明与本行实际情况相结合的关键事项。2估算的目标范围什么是估算估算就是对项目将花费多少资源、持续多长时间或将花费多少成本的预测，通过估算结果与项目目标进行比较来确定项目目标是否足够现实，在无法通过控制项目达到目标时，必须调整项目目标使其更符合实际情况。良好估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策，为项目跟踪提供重要的支持。估算与计划、承诺的区别：估算是客观的过程。估算结果构成了计划的基础，但计划并不一定要与估算结果相同。如果估算结果与目标之间存在显著的区别，进行项目计划时就要认识到两者之间的差距，并考虑可能存在较高的风险。计划是有目的性的主观设计过程去寻求特定的结果。我们经常会让计划倾向某个方面以得到特定的结果，通过计划一些特定的方法来达到特定的目标。承诺是许诺在特定日期之前以特定质量水平交付规定的功能。承诺可以与估算相同，可能比估算更激进，也可能比估算更保守。也就是说，不要假定承诺必须和估算是一样的；它们是不相同的。计划的结果往往在很多时候是一种承诺。估算对象通常估算的对象有规模、进度、成本、工作量等。在实际的估算过程中，我们常常直接进行工作量估算，所以很容易混淆项目规模和工作量。为了区分这两个概念，在本指南中，“规模”特指软件系统本身的规模大小而不指工作量大小，一般使用诸如代码行、功能点、用户案例（UseCase）或者其他度量单位来估算给定项目属性集的技术工作的范围。对于一个项目的估算活动，最困难的估算在于规模与总工作量，而其他的目标值，如：进度、资源、成本等都可以从中计算出来。因此：1、当前本行的软件项目估算的目标范围包括有：a）规模（建议使用代码行（单位：千行）或功能点数（单位：个）统计）b）工作量（单位：人月）c）进度（单位：工作日或月）d）成本（单位：万元）2、首要的估算目标为：项目规模、总工作量。进入估算的思想准备什么是好估算精品文档

精品文档要做好估算，首先应当先明确的就是“好估算”。良好估算是指对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。从数据统计上看，一个估算良好的项目，单点估算值可能和最终结果有所偏差，但最终结果始终在估算范围之内，并且随着项目的进行，估算范围是越来越小的。如图1：图1：良好估算过程的数据比较图图2是一个估算较差且有低估倾向的项目的估算过程数据统计，该项目一直处于低估状态，并且估算的范围太窄以致于始终没有将最终结果估算进范围内。图2：不好的估算过程的数据比较图为什么我的估算总是不准确精品文档精品文档估算不准确罪魁祸首之一：低估大多数人都这样认为，如果你给一个开发者5天时间去做一件4天就能完成的工作，他必然会去寻找一些事情来把多出来的一天用掉；如果你给一个项目组6个月时间来完成4个月就能完成的项目，他们同样会找到办法来把多出来的2个月用掉，所以管理者都希望通过挤压估算来避免这个现象。当然还有一些人认为如果给了太多的时间，开发人员往往会把任务放到后面来开展，这样他们还是匆匆忙忙的完成甚至无法按时完成。这些担忧都是正确的，而且也是客观事实，但是在软件开发中，高估的代价是线性的可控的，顶多就是浪费掉多估出来的那些时间。图3：高估和低估代价示意图但是低估就没有坏处么？有，而且低估的代价是非线性的不可控的（见上图），例如估算错误造成计划5%-10%的延迟本身并不是很要紧的问题，但是很多时候估算造成的是100%以上的偏差，基于这样估算上的计划就是在猜想了，计划也就根本没有意义了；同时，由于低估带来的计划延期等问题在严格规范管理的组织里需要进行延期原因分析、影响评估、计划变更评审等等相关工作，这些工作所需要代价往往是非线性增长的。所以不要有目的的去低估，低估的代价比高估的代价更高，更何况程序员一般是乐观主精品文档

精品文档义者，他们往往给出的估计值就已经是较少的时间和成本了。估算不准确罪魁祸首之二：拍脑袋在估算中拍脑袋的表现就是即兴估算，就是根据个人记忆在未仔细考虑前给出的看似思考分析过的估算值。因为个人记忆常常出现错误，比如并不是记住项目的实际结果而是估算值或者是直觉，所以这种估算也常常出现错误。根据McConnell收集的24组估算人员的即兴估算数据，并对即兴估算的平均误差和经过小组评审的估算结果的平均误差进行比较，见下图：225%200%-175%-150%-125%-75%-50%-25%-0%-25%--50%-225%200%-175%-150%-125%-75%-50%-25%-0%-25%--50%--75%估算小组编号误差100%-图4：即兴估算与评审过的估算的平均误差比较图可见一般的即兴估算的平均相对误差量为67%，而一般评审过的估算的误差只有30%，只有前者的一半。所以不要拍脑袋，即使只用15分钟坐下来查查以前的记录的数据再进行估算也会更加准确些。估算不准确罪魁祸首之三：遗漏工作看看下面这些表，是不是有些工作你根本没想到要在开发过程中进行呢?或许就是这些漏网之鱼每每造成你的估算值变小，导致项目计划不合理而常常延期。表1:软件估算中经常遗漏的功能需求和非功能需求功能需求非功能需求安装程序准确度可复用性数据转换工具互操作性可伸缩性使用第三方或开源软件所需的集成代码可修改性安全性帮助系统性能抗毁性部署方式可靠性易用性与外部系统的接口响应性表2软件估算中经常遗漏白勺软件开发活动交接/部署项目开发过程中为现有系统提供新团队成员的所需的准备时间精品文档

精品文档数据转换安装定制需求澄清维护修订控制系统为构建工作提供支持安装测试版本生成测试数据管理测试版程序参与技术评审集成工作技术支持项目开发过程中对以前的系统进行维护缺陷纠正工作性能调整学习新开发工具与缺陷跟踪有关的管理工作开发人员与测试人员间的相互协调回答质量保证部门提出的问题编辑和评审用户文档评审技术文档指导新团队成员管理层协调、管理人员会议维护运行每日构建所需的脚本维护与每日构建相关联的自动化模拟测试与客户或最终用户进行交互，为客户安装测试版本提供支持评审计划、估算、架构、详细设计、阶段计划、代码、测试用例等等处理变更请求出席变更控制会议与分包商进行协调向客户或用户演示软件表3软件估算中经常遗漏的非软件开发性活动休假公司会议病假配置新的工作站周末假日部门会议培训在工作站上安装新版工具排除软硬件故障3估算的时机3.1一般的估算时机理论上，主动估算可以在项目周期内的任何时间，只要项目没有结束，就有估算的意义和价值。并且随着不确定性的消除，估算才会更加准确，因此在制定出消除不确定性的决策后，估算便可以进行并有更大的价值，参见下图。可见在需求大纲定义完成（已批准的产品定义）、需求完成、用户界面设计完成、详细设计完成等里程碑点上是进行估算的时点。很明显我们知道估算的时间越早，价值越高，但准确性也越低；越往后，由于条件的充分，估算准确性越高，但价值越小。根据不确定性影响统计（见下图），让我们感到幸运的是估算的准确度在项目的前30%的时间内可以得到显著改善。3.2本行项目的估算时机精品文档精品文档根据我行目前项目模式和组织流程的特点，要求但不仅限于以下几个时间点进行估算:.立项准备阶段，需求大纲完成后，项目经理需要对项目总成本进行初步估算，以作为项目立项的必要内容之一。（以下简称“立项成本估算”）.项目立项完成，启动阶段。项目经理需要对项目总体进度进行估算，估算结果将帮助制定项目章程和项目总体计划。（以下简称“总体进度估算”）.软件开发计划阶段，需求设计完成后，项目经理或开发负责人应对项目的详细进度、资源需求情况进行估算，以支持制定详细开发计划。（以下简称“详细进度估算”）.概要设计评审通过后，对项目总成本进行重估算。（以下简称“成本重估算”）4怎么做估算选择估算方法影响估算方法选择的几个因素选择估算方法时，要考虑我们要估算的对象、被估算项目的规模、软件开发方式、所处的开发阶段以及需要的估算准确度的影响。这些因素可能的情况见表格：影响因素可能情况估算对象规模、工作量、进度、特性项目规模小、中、大开发阶段早期、中期、后期软件开发方式迭代式、顺序式或两者皆可可能的准确度低、中、高1.估算对象在实际估算过程中，一般是先确定项目要实现的软件项目的特性，然后估算为了交付这些特性需要多少时间和工作量。当然也有些项目则是先确定他们的预算和开发时间限制，然后估算在这些限制内可以交付多少特性。一般来说，特性、时间和成本是相互制约、此消彼长的关系，因为项目应先明确目标再进行有针对性的估算。.项目规模小型：一般指不超过5个团队人员的项目，因为受个人生产率变化的影响，基于统计的估算方法不太适用，最佳的估算方法为“自底向上”的方法，也就是基于将要实际进行工作的个人提供的估算之来进行估算。中型：项目大约包括5-25个人，持续时间为3—12个月。几乎可以使用所有的估算方法。大型：项目拥有超过25人以上的团队成员，项目将持续6-12个月以上。项目早期，最佳的估算方法是基于数学和统计学的“自顶向下”的方法；项目中期，可以结合“自顶向下”和基于项目自身历史数据的自底向上的方法结合起来；项目后期，自底向上的方法可以提供最准确的估算。.开发阶段早期：顺序式项目中，早期阶段是指从项目概念起始到需求定义基本完成的时期；在迭代式项目中，早期指的是初始计划的时期。中期：在顺序式项目中，是指从需求工作、架构工作到完成了足够的构造（可能是详细设计或者编码）活动产生了可以用于估算的项目生产率数据；迭代式项目中，中期则指最初的2-4次迭代，也是为后期估算产生项目自身生产率数据的阶段。精品文档精品文档后期：包括从中期构造直到项目发布的时间。.软件开发方式迭代式项目和顺序式项目都可能开始于自顶向下的或者说基于统计学的估算方法，最后都迁移到自底向上的方法。由于迭代式项目的每次迭代都可以产生实际的生产率数据，所以在使用项目自身的数据时，它们可以更快地对估算结果进行精化。常见的几种生命周期模型相对于估算而言顺序式和迭代式的分类如下：顺序开发：瀑布模型、v模型、分阶段交付、RUP迭代开发：Scrum、极限编程、演进式原型法.可能的准确度估算方法的准确度取决于三个方面：估算方法本身、方法是否被用于适当的估算问题和方法被用于项目的哪个阶段。而且一般来说高准确度的估算也需要较高的估算成本，因此根据项目所处的阶段和当时的不确定性情况，选择低成本、低准确度的方法或许是更实际的。.1.2现有估算方法的适用性在本指南中，将简单引入几种最通常的估算方法，作为组织级推荐的方法。这些方法和方法选择判断条件有：估算方法判断条件按工作分解结构（WBS）分解类比估算宽带Delphi法简化功能点（Dutch）法专家估算法（Pert）估算对象工作量规模、工作量、进度、特性规模、工作量、进度、特性规模、特性规模、工作量、进度、特性项目规模中大小中大中大小中大小中大开发阶段早期-中期早期-后期早期早期早期-后期迭代式或顺序式两者皆可两者皆可顺序式顺序式两者皆可可能的准确度中中中低高各类估算方法的详细介绍和使用范例，请见相应的估算方法手册。随着今后质量体系的推广，对估算过程的规范性和估算结果准确性也将慢慢提高，将逐步引入更多更完善的估算方法，以适应发展的需要。.1.3后续准备工作估算方法选定后，为了保证估算高效开展，项目经理还应进行以下工作：1、确定估算参与人员：选定估算方法后，我们需要根据选择的估算方法确定参与估算人员的资格要求，选定合适的估算参与人员，并提前通知相关人员；2、项目相关信息准备：本项目和估算相关信息，如需求说明书、设计说明书、项目基本情况等；3、估算方法介绍：相关估算专家不了解将使用的估算方法的情况时，估算组织者（一般是项目经理）应准备相关估算方法的培训材料，相关培训也可以向QA申请，由QA进行培训。4、估算所需资料准备：估算组织者（一般是项目经理）应事先学习选定的估算方法，并依据方法要求，准备好估算需要的材料，如必要的历史资料、已往相关项目的经验数据、以及电子文档、打印纸质表格、估算结果记录表、白板等。精品文档精品文档4.2通用的顺序式开发项目估算过程一个获得良好估算的项目的单个估算流程，首先应关注对规模的估算，然后根据规模估算值中计算出工作量、进度、成本和可交付的特性（如功能点），估算过程见下图。^^^度进度范围 M工作量二L成本特性规模估算主要适用于顺序式项目的早期和中期阶段，后期则主要通过自底向上的进行工作量估算即可。常见的规模估算方法见下表：方法可估算的规模类型类比特性、功能点、web页面、GUI组件、数据库表、接口定义、代码行分解特性、功能点、web页面、GUI组件、数据库表、接口定义、代码行Dutch方法（简化功能点法）功能点、代码行功能点功能点、代码行宽带Delphi功能、用户故事、故事点、需求、用例、功能点、Web页面、GUI组件、数据库表、接口定义、类、函数/子例程、代码行从规模推算总工作量大部分项目最终将根据详细任务清单直接估算工作量，但在项目早期，从规模估算值计算出的工作量估算值是最准确的做法。对项目工作量影响最大的因素是待构建软件的规模，其次的因素是组织的开发生产率水平。1、有历史数据可参考的情况下：如果有规模差距不大的项目的历史数据，就可以考虑用类比法，甚至是直接采用线性模型来估算，例如：a）获得历史项目的指标数据：单位功能点工作量。此指标的来源：根据历史相关项目的数据统计而来。计算方法：单位功能点工作量=某历史项目的真实总工作量/这个项目在对应的时间上估算出来的功能点数据b）根据已知的规模（功能点数），参考历史数据，可算出总工作量。计算方法：当前项目总工作量=单位功能点工作量*当前项目的规模对于这些历史项目的类比数据，有不同的维度可以选择，比如针对某个PM的数据。针对某一类项目的统计，针对某个业务部门的统计。不同的组合可以得到精度不同的结果。精品文档精品文档2、使用ISBSG方法来计算：项目类型：一般人月=0.512X功能点0.392X团队最大规模0.791项目类型：改进已有项目人月=0.669X功能点0.338X团队最大规模0.758项目类型：新开发项目人月=0.520X功能点0.385X团队最大规模0.866项目类型：桌面应用人月=0.157X功能点0.591X团队最大规模0.810从工作量推算成本按照本行对单位工作量的成本换算标准（3万/人月），即可。从工作量推算进度假设项目工作量已知，需要推算项目的进度。.有历史数据时可以考虑类比法，获得历史项目的指标数据：历史进度、历史工作量直接使用公式计估算的进度=历史进度X（估算的工作量/历史工作量）1/3指数取1/3适用于超过大约50人月的工作量的中型和大型项目，对较小的项目，指数应该取1/2。.项目早期且无历史数据时在中型和大型项目的早期，可以直接使用基本的进度公式：进度月数=3.0X人月数1/3系统3.0是可以根据实际情况调整的，一般应使用本行的历史数据进行校准，可以得到特定的比例系数。在明确了将参与项目工作的具体人员后，应转用其他方法进行估算。.3组织估算不同的估算方法，有不同的过程、参与人员和组织形式。鉴于本行目前主要使用顺序式开发方法，本指南主要以顺序式开发来介绍各估算过程的可能情况。在条件准备到位后，开始执行估算过程。4.3.1立项估算对于“立项估算”（成本和总体进度），建议估算过程如下：1、估算进入条件：需求大纲编写完成2、估算内容为：成本和进度，一般是根据已经确定的项目需要完成的需求来估算

项目的规模或者所需的工作量，进而计算出项目所需要的成本和时间。3、估算过程精品文档精品文档根据确定的估算方法来估算项目规模或者项目工作量，可能的估算方法有Dutch功能点估算法、类比估算法、专家估算法(PERT公式)等。估算人员使用宽带Delphi过程来收敛得到的估算值，此时估算值一般是以单点数据来体现的。若是得到项目规模估算值，可以根据从规模推算工作量的方法推算项目工作量或a)中介绍的估算方法估算项目工作量。若直接估算项目工作量则直接执行d)。根据项目估算工作量直接计算或采用估算方法估算项目成本(N)。根据项目不确定性因素的影响，该阶段的项目估算准确度在[-50%，+100%]之间，因此我们以(0.5N—2.0N)来体现估算结果。4、估算结果关于估算结果应用时需注意：不应提交用于这些计算的单点值，预算公布值应是最高值2.0N。本期估算结果除了用于估算预算外，不应用于外部承诺总体进度估算对于“总体进度估算”(进度)，建议估算过程如下：1、估算进入条件：业务需求规格说明书完成，进入启动阶段2、估算目标为：进度，根据已经确定的项目需要完成的需求来估算项目规模或所需的工作量，从而得出项目所需要的时间；或者根据项目的时间、成本限制来估算项目所能完成的需求范围。3、估算过程根据确定的估算方法来估算项目规模或项目工作量，可能的估算方法有功能点估算法、类比估算法、自底向上估算法、专家估算法等估算人员使用宽带delphi过程来收敛得到的估算值，此时一般是以单点数据来体现的若是得到项目规模估算值，可以根据从规模推算工作量的方法推算项目工作量或a)中介绍的估算方法估算项目工作量。若直接估算项目工作量则直接执行d)。根据项目估算工作量直接计算或者使用估算方法估算项目进度(N)。根据项目不确定性因素的影响，该阶段的项目估算准确度在[-50%,+100%]之间，因此我们以(0.5N—2.0N)来体现估算结果。4、估算结果关于估算结果应特别注意的是：不应提交用于这些计算的单点值，所需进度的公布值应为2.0N本期估算结果除了用于估算项目总体进度外，不应用于外部承诺详细进度估算对于“详细进度估算”(工作量、进度)，操作过程如下：1、估算进入条件：软件需求分析完成，进行项目详细计划制定前2、估算目标为：进度，根据已经确定的项目需要完成的需求来估算项目所需的工作量，从而得出项目所需要的时间。3、估算过程a)根据确定的估算方法来估算项目规模或项目工作量，可能的估算方法