1目的目的此文档作为软件质量体系中的估算过程的具体使用指南，用来指导本行项目过程中的 估算活动实施的进行。 本指南假设读者已了解并熟悉软件质量体系的估算过程，在此前提下，对于过程中已 作了明确要求和解释的内容，将不再详细说明，指南将着重说明与本行实际情况相结合的 关键事项。2估算的目标范围估算的目标范围2.1 什么是估算什么是估算估算就是对项目将花费多少资源、持续多长时间或将花费多少成本的预测，通过估算 结果与项目目标进行比较来确定项目目标是否足够现实，在无法通过控制项目达到目标时， 必须调整项目目标使其更符合实际情况。 良好估算是对项目实际情况有足够清晰看法的估算，它让项目负责人可以做出控制项 目达到目标的好的决策，为项目跟踪提供重要的支持。 估算与计划、承诺的区别： 估算是客观的过程。估算结果构成了计划的基础，但计划并不一定要与估算结果相同。 如果估算结果与目标之间存在显著的区别，进行项目计划时就要认识到两者之间的差距， 并考虑可能存在较高的风险。 计划是有目的性的主观设计过程去寻求特定的结果。我们经常会让计划倾向某个方面 以得到特定的结果，通过计划一些特定的方法来达到特定的目标。 承诺是许诺在特定日期之前以特定质量水平交付规定的功能。承诺可以与估算相同， 可能比估算更激进，也可能比估算更保守。也就是说，不要假定承诺必须和估算是一样的； 它们是不相同的。计划的结果往往在很多时候是一种承诺。2.2 估算对象估算对象通常估算的对象有规模、进度、成本、工作量等。在实际的估算过程中，我们常常直 接进行工作量估算，所以很容易混淆项目规模和工作量。为了区分这两个概念，在本指南 中， “规模规模”特指软件系统本身的规模大小而不指工作量大小，一般使用诸如代码行、功能 点、用户案例（Use Case）或者其他度量单位来估算给定项目属性集的技术工作的范围。 对于一个项目的估算活动，最困难的估算在于规模与总工作量，而其他的目标值，如： 进度、资源、成本等都可以从中计算出来。 因此： 1、 当前本行的软件项目估算的目标范围包括有： a)规模（建议使用代码行（单位：千行）或功能点数（单位：个）统计） b)工作量（单位：人月） c)进度（单位：工作日或月） d)成本（单位：万元） 2、 首要的估算目标为：项目规模、总工作量。2.3 进入估算的思想准备进入估算的思想准备2.3.1 什么是好估算什么是好估算要做好估算，首先应当先明确的就是“好估算” 。良好估算是指对项目实际情况有足够 清晰看法的估算，它让项目负责人可以做出控制项目达到目标的好的决策。 从数据统计上看，一个估算良好的项目，单点估算值可能和最终结果有所偏差，但最 终结果始终在估算范围之内，并且随着项目的进行，估算范围是越来越小的。如图 1：图图 1：良好估算过程的数据比较图：良好估算过程的数据比较图图 2 是一个估算较差且有低估倾向的项目的估算过程数据统计，该项目一直处于低估 状态，并且估算的范围太窄以致于始终没有将最终结果估算进范围内。图图 2：不好的估算过程的数据比较图：不好的估算过程的数据比较图2.3.2 为什么我的估算总是不准确为什么我的估算总是不准确项目启动需求完成核心架构完成中间版本1 完成中间版本2 完成中间版本3 完成交付时间范围项目启动需求完成核心架构完成中间版本1 完成中间版本2 完成中间版本3 完成交付时间范围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 个团队人员的项目，因为受个人生产率变化的影响，基于统计 的估算方法不太适用，最佳的估算方法为“自底向上”的方法，也就是基于将要实际进行 工作的个人提供的估算之来进行估算。 中型：项目大约包括 525 个人，持续时间为 312 个月。几乎可以使用所有的估算 方法。 大型：项目拥有超过 25 人以上的团队成员，项目将持续 612 个月以上。项目早期， 最佳的估算方法是基于数学和统计学的“自顶向下”的方法；项目中期，可以结合“自顶 向下”和基于项目自身历史数据的自底向上的方法结合起来；项目后期，自底向上的方法 可以提供最准确的估算。 3 开发阶段 早期：顺序式项目中，早期阶段是指从项目概念起始到需求定义基本完成的时期；在 迭代式项目中，早期指的是初始计划的时期。 中期：在顺序式项目中，是指从需求工作、架构工作到完成了足够的构造（可能是详Comment Y1: 可能的方法有分解、 类比、功能点、宽带 Delphi、pert 法、 简化功能点法细设计或者编码）活动产生了可以用于估算的项目生产率数据；迭代式项目中，中期则指 最初的 24 次迭代，也是为后期估算产生项目自身生产率数据的阶段。 后期：包括从中期构造直到项目发布的时间。 4 软件开发方式 迭代式项目和顺序式项目都可能开始于自顶向下的或者说基于统计学的估算方法，最 后都迁移到自底向上的方法。由于迭代式项目的每次迭代都可以产生实际的生产率数据， 所以在使用项目自身的数据时，它们可以更快地对估算结果进行精化。常见的几种生命周 期模型相对于估算而言顺序式和迭代式的分类如下： 顺序开发：瀑布模型、v 模型、分阶段交付、RUP 迭代开发：Scrum、极限编程、演进式原型法 5 可能的准确度 估算方法的准确度取决于三个方面：估算方法本身、方法是否被用于适当的估算问题 和方法被用于项目的哪个阶段。而且一般来说高准确度的估算也需要较高的估算成本，因 此根据项目所处的阶段和当时的不确定性情况，选择低成本、低准确度的方法或许