绿杨馄饨-爱情蜜语

如何认识软件项目估算


作者：佚名联盟会员：项目管理者联盟转载发布时间：2009-12-2
虽然估算是一门科 学，更是一门艺术，这个重要的活动不能以随意的方式
来进行…因为估算是所有其他项目计划活动的基础 ，而项目计划又提供了通往
成功的软件工程的道路图，所以，没有它我们就会搭错车。
--Roger an《软件工程--实践者的研究方法》
1、估算前的规划
当我 们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正
有用的文件在哪里，当我们的软件相 目中收集了各种需求、意见、问题时，我
们也很难从中估算出整个项目的规模、工作量以及成本。因此， 在估算之前我
们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，
在 这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软
件开发项目成功与否的关键， 有了规划就有如成竹在胸，之后无论风云变幻，
都有应对入流的方法。当然只有正确的规划，才能给软件 开发指引正确的方向。
软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成
果等等做出合适的安排，制定出一些计划(包括高层的和细节的)，使大家按照
计划行事，最终顺利地 达到预定的目标。
1.1、规划的第一步：确定软件范围
确定软件范围，就是确定目标软件 的数据和控制、功能、性能、约束、接
口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达 成需求分析
规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还
没有开 始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分
析技术(如需求诱导)，从客户那 里得到一个具体的软件范围。当然如果是一次
全新的软件边界探索，就应当考虑软件本身可行性问题，包 括团队是否具备在

技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可 靠的竞
争优势，等等。
获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如 ，
在开发一个CS架构的铁路供电段数据上报系统中，客户向我们提供了以下的
目标软件需求描 述：
在供电站总部每天结束前要审核下属节点操作员(30~40个)的供电安全数
据报表， 要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过
自动分析，整理出整个区内的 安全形势报表，并自动反馈到每个节点。各个节
点之间通过调制解调器拨号(MODEM)用内部电话线 相连，每个节点电脑主机配备
一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作 员姓名、
上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行
修改、删 除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个
节点数据的管理权限，但是对于归档 数据(一旦审核完毕的数据，就进行归档)
总部不具备删改的权限。系统设置数据库管理员，独立于审核 权限，其职责是
对历史数据的清理维护。
通过上面的描述，我们通过提炼和简化，得到软件的一下功能：
◆节点数据录入、查询、上传
◆总部数据汇总、查询、反馈
◆总部与节点的互联
◆总部数据库存储
◆节点数据的本地存储
在本例中，软件的性能是潜在的。客户虽然没有明确提出，但是由于数 据
本身的重要性，要求系统在数据上传、反馈、存储过程中安全可靠。客户要求
使用MODEM 进行拨号连接，那么鉴于MODEM连接过程中可能会出现，由于拨号
断开而道导致的数据丢失，在节点 本地存放一份数据副本是有必要的。由于系
统要求每天上传数据，总部数据库应当是7X 24小时不间 断服务的，再加上目

前总部只有该系统运行接受数据任务，各节点数据量并不大，那么在 建议用户
选择服务器时，应当考虑性能稳定可靠，但并不一定要购买大容量磁盘阵列和
高性能双 CPU主机。由于每天上传数据接近下班时间，那么总部汇总数据应当
是自动进行的，一旦分析发现重大 问题，可以通过与外部网络的设置，向值班
人员发送手机讯息、E-MAIL或其他警示。由于不同人员 对于上报数据的权限不
同，对于系统用户实行分级管理。不同级别的用户，具有对数据的不同管理权力，从而保证在软件使用过程中不发生混乱。
那么现在一个较为清晰的软件模型已经构造完毕，接 下来我们需要进入计
划的第二步：确定工作所需资源。
1.2、规划的第二步：确定工作所需资源
软件工作所需资源包括：工作环境(软硬件环境、 办公室环境)、可复用软
件资源(构件、中间件)、人力资源(包括不同各种角色的人员：分析师、设计 师、
测试师、程序员、项目经理…)。这三种资源的组成比例，可以看作一个金字塔
的模式，最 上面是人力资源、其次是可复用软件资源、最下面是工作环境。最
上面的是组成比例最小的，最下面的是 组成比例最大的部分。
■人力资源
一个项目到底需要多少种职务的人员构成、多少数量的人 员总量，再能成
为最有创造力的团队呢?这恐怕是最让项目经理头疼的事情了。任何一个软件工
程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能
以最小成本和最高效率完成 任务。在这之前，不能盲目地进行人力扩充，而且
绝对不能为了给公司抬高门面，盲目招收高学历。
■可复用软件资源
这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才< br>发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资
源库中或许已经积累 了大量的可复用资源，但在当前任务中，只能选择有价值
的资源。根据不同的应用、时间、来源，可复用 软件资源被分为以下几种

可直接使用的构件：已有的，能够从第三方厂商获得或已经在 以前的项目
中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。
具 有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、
设计、代码、或测试数据。当前 软件项目组的成员在这些构件所代表的应用领
域中具有丰富的经验。因此，对于这类构件进行所需的修改 其风险相对较小。
具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立
的 规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的
成员在这些构件所代表的应用 领域中仅有有限的经验，因此，对于这类构件进
行所需的修改会有相当程度的风险。
新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构
件。
在采用 构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂
亮的构件的应用，可能会带来潜在出错 的风险或者必须经过复杂修改或者效率
低下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满 足项目的需
要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使
用的构 件。
■环境资源
工欲善其事，必先利其器，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一
般管理人员都会购买可 以满足需要的软件开发工具和硬件平台，但是工作环境
和管理制度往往被忽视。
站在人件的角 度看，向工作人员提供更轻松自在、安静舒适的办公环境的
公司员工往往比整天在狭小隔间中工作的公司 员工，产生更高的工作效率。而
那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技 术的
人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。
到此为止，估算前 的项目计划已经完成，我们已经形成一个工程开发框架。
这是一个有界限的框架，虽然还不够精确，但足 以进行估算的工作。

2、估算的对象
目前为止，一个较为准确的软件项目估 算的定义是：在给定公差范围内，
对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和 日历事
件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限
定在一定范 围内的估计。
估算主要包括以下几个重要内容：
◆规模估算
软件估算首先要将整 个工程的规模估算出来，才能进行下面的其他估算。
规模，就是一个工程可量化的结果，是用具体数字来 体现项目的描述。规模估
算的信息来源是清晰、有界限的用户需求。
◆工作量估算
这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团
队的规模和构建。通常以人时、 人天、人月、人年的单位来衡量，这些不同单
位之间可以进行合理的转换。
◆进度估算 进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标
志。进度估算是针对以阶段 为单位的估算，而不是对每一个细小任务都加以估
算，对任务的适当分解很重要，分解得越细反而会不准 确。因为任何一个软件
工程，在各个方面都有与生俱来的不确定性。
◆成本估算
包 括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要
部分。比较容易被忽视的使学习成 本、软件培训成本、人员变动风险成本、开
发延期成本等，一些潜在成本消耗。
3、估算的策略

在软件估算的众多方法中，存在着自顶向下和自底向上两种不 同的策
略，两种策略的出发点不同，适应于不同的场合使用。
3.1、自顶向下的策略 这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目
标，任何估算结果都必须符 合这个目标。其工作方法是，由项目经理为主的一
个核心小组根据客户的要求，确定一个时间期限，然后 根据这个期限，将任务
分解，将开发工作进行对号入座，以获得一个估算结果。
当然由于这完 全是从客户要求出发的策略，而由于软件工程是一个综合项
目，几乎没有哪个项目能完全保质保量按照预 定工期完工，那么这样一个策略
就缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被 项目
经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行
着。
3.2、自底向上的策略
与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的 角度
出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的
任务分解。在 将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特
长进行分配，并要求进行估算。最后将估 算加起来就是项目的估算值
显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一< br>来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目
经理也不会采用这种 方法。
4、估算的方法
显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么 估算
本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，
人们对产品需 求、技术、市场预期、人员素质等因素的了解还远远不够，在这
种情况下人们很难作出准确的估计。但是 依据某种方法进行估计显然比瞎猜好
得多。

估算方法有很多，大致分为基于分 解的技术和基于经验模型两大类。基于
分解的技术的方法包括功能点估算法、LOC估算法、MARK II等；基于经验模型
的方法包括IBM模型、普特南模型、COCOMO模型等。
4.1、FP功能点估算法
功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计 方法。
通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特
性。这种方 法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规
模包括各种输入、输出、查询、内部 逻辑文件数、外部接口文件数等等；技术
复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分 布式处理复杂
度、在线更新复杂度等等。
4.2、LOC估算法
这是一种从技术的 角度来估算的方法总称，其中又包含许多方法。这类方
法以代码(LOC)作为软件工作量的估算单位， 在早期的系统开发中较为广泛使用。
基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控 、能反映程
序员的思维能力；缺点在于代码行数的含糊不清，不能正确反映一项工作的难
易程度 以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被
使用，且不断演化的方法包括以 下：
PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：
一个 产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计
用来得到一个产品期望规模和标 准偏差的Pert统计估计，Pert估计可得到代
码行的期望值和标准偏差SD。
类比估算 法：类比法适合评估一些与历史项目在应用领域、环境和复杂度
的相似的项目，通过新项目与历史项目的 比较得到规模估计。类比法估计结果
的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法 的前提条
件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是
可信赖的 。

Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况 下，
这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预
测和深度分析 的领域，依赖于专家的技术指导，可以获得较为客观的估算。通
过专家们的互相讨论，还可以博取众长。
系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果
累加就是LOC的总 规模。其中关键是建立起SBS(系统分解结构)，它描述了系
统的不同组件。SBS还被使用在其他重 要的地方，如系统设计、系统分析等。
在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的 SBS构成
4.3、IBM模型估算法
该模型是Watson和Felix在1977年发 布的，是基于IBM联合系统分布负
责的60个项目的总结而得到的模型。该模型是一个静态模型，而参 考数据只有
60多个项目，因此有很大的局限性。
4.4、COCOMO估算法
B oehm在其经典著作软件工程经济学
中，介绍了一种软件估算模型的层次体系，称为COCOMO(构 造性成本模型，
COnstructive COst MOdel)，它代表了软件估算的一个综合经验模型。
COCOMO模型是适用于三种类型的软件项目：(1)组织模式--较小的、简单
的软件项目 ，有良好应用经验的小型项目组，针对一组不是很严格的需求开展
工作(如，为一个热传输系统开发的热 分析程序)；(2)半分离模式--一个中等的
软件项目(在规模和复杂性上)，具有不同经验水平的项 目组必须满足严格的及
不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求)；(3)嵌入模式-- 必须在一组严格的硬件、软件及操作约束下开发的软件项
目(如，飞机的航空控制系统)。
4.5、软件方程式估算法项目管理培训
软件方程式是一个多变量模型，它假设在软件开发项 目的整个生命周期中
的一个特定的工作量分布。该模型是从4000多个当代的软件项目中收集的生产< br>率数据中导出的公式。初期的方程式较为复杂，通过，Putnam和Myers的努力

< br>又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得
到的。
4.6、WBS估算法
这是一种基于WBS(工作任务分解)的方法，即先把项目任务进行合 理的细
分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估
算每个WB S要素的费用。采用这一方法的前提条件或先决步骤是：
对项目需求作出一个完整的限定；
制定完成任务所必需的逻辑步骤；
编制WBS表；
项目需求的完整限定应包括工作 报告书、规格书以及总进度表。工作报告
书是指实施项目所需的各项工作的叙述性说明，它应确认必须达 到的目标。如
果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价
的根 据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总
进度表应明确项目实施的主要阶 段和分界点，其中应包括长期定货、原型试验、
设计评审会议以及其他任何关键的决策点。如果可能，用 来指导成本估算的总
进度表应含有项目开始和结束的日历时间。
除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、
Standard- component估算法、普特南估算法等。当然不同的方法适用于不同的
具体环境，有些方法虽然很 好但并不一定适合当前的任务。只有量体裁衣，具
体问题具体分析，才能得到尽量合理的估算。
5、估算的戒律
记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确?--亚里斯多德

对于任何一个项目经理，都知道要慎重估 算，但是我们仍然会看到人力资
源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们 不是
用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。
不要追求 完美：就像没有人能预测出未来，如果还没有完成，就不要企图
完美的结果。更何况估算的太精确，反而 会失去灵活机动的空间。
不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，
那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的
权利，而且是完成 任务的前提。
不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思
索地砍 掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。
客观地估算，不贪多不偷减：就像老 板不能随便削减你的估算一样，你也
同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减 必然导致
不足。这两个结果恐怕都不是一个合格的项目经理的作为。
客观利用过去的经验：对 于以往估算的经验，当然是宝贵的财富，但是如
果财富用错了地方就会变成垃圾。在使用经验时，要注意 现在和参考经验之间
的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在
发生着改变。
不要以客户目标作为估算的结果：客户是上帝，软件公司一定要尽力实现
客户 的需求。但我们要实现的是合理的目标，况且不能为了完成目标而去堆积
数字，这样岂不是因果倒置了。
不要隐匿不确定的成本：软件开发中存在潜在风险，是很正常的事情。现
在风险就会带来潜在的 成本，如：突然一位程序员离职，导致工作进度路落后。
我们不可能估算到任何一种可能发生的情况，但 有责任把可能出现的一些关键
环节列出来。
特别声明：

1
：资料来源于互联网，版权归属原作者

2
：资料内容属于网络意见，与本账号立场无关

3
：如有侵权，请告知，立即删除。