软件项目的估算历来是比较复杂的事，因为软件本身的复杂性、历史经验的可重复性、估算工具的缺乏以及一些人为错误，都会导致软件项目的估算往往和实际情况相差甚远。据有关机构调查发现，约有60%的软件项目的失败是因为估算偏差引起的，而不是因为技术实力不够。因此，估算偏差已被列为软件项目失败的四大原因之一。

从软件工程学上，我们知道软件需求和估算是软件项目的基础。因为只有准确的了解客户的需求，以之为基础，并使用科学的方法对目标软件系统的规模、工作量和进度做出合理的估算，我们才能在预算内按时按质顺利的完成项目。然而，软件估算作为软件项目的基础领域却常常被人们所忽视。我在近期的一个开发项目中就尝到忽视软件规模估算带来的苦果，结果是项目进行到一半时就发现不但工期严重滞后于计划，而且项目的各种资源也严重的不足和缺乏，项目被迫暂停下马。

常见的项目规模估算失准原因

一直以来，软件项目的规模估算(Size Estimation)是个争论不休的问题。不论是对软件开发团队还是对软件用户，软件规模估算的重要性都是不容置疑的。因为它能极大的影响着甲方对发包软件的成本估算，乙方对自身开发成本的预测，以及乙方对开发过程的量化管理等诸多方面。而且，只有相对合理和相对准确地估算软件规模，才能对项目的进度安排、资源分配等各个环节进行合理的部署。所以，软件项目的规模估算是软件项目中相当重要的一环。但是，以下的原因却使到我在这次项目的实际操作中对项目规模估算失准了：

(1)对项目规模估算认识不足

项目规模估算一般分为两种应用场景：一是招投标的时候用来估价、报价;二是用来安排进度计划和指导项目具体工作的分配。因此，如果对规模估算认识不足的话，将可能会在这两种应用场景中估算失准。例如，如果项目规模低估的话就会造成人力估算低估、成本预算低估、日程过短，最终人力资源耗尽，成本超出预算。最后为了完成项目不得不赶工，不但会影响到项目质量，甚至会导致项目失败。而如果规模高估的话，就会因估价过高而降低了招投标时的竞争力，或在进度安排时提高了开发成本和浪费资源。由于对规模估算的认识不足，使到我在这次项目中就尝到一个大苦果，就是低估项目规模导致项目需要多次的追加预算。我不但多次受到公司领导的批评，而且还受到客户的多次投诉。

(2)个人经验估算法带有一定的局限性

一般来说，依靠历史或个人经验的规模估算方法都有一定的局限性。原因是很难在项目分析和计划阶段就对软件的规模进行相对准确的估算。因为估算是依靠评估人员的经验，所以对评估人员的能力要求比较强，并且难以由第三方对评估人员的工作偏差作出修正。在这次项目的初期，我片面的只是根据个人经验进行估算，结果是轻率的估算了项目规模。这是最后导致项目失利的原因之一。另外，不同软件项目使用的技术不一样，这一点也非常影响到软件规模的估算。例如同一个功能,使用JAVA语言和使用Ruby语言所涉及的代码行相差数十行，甚至数百行。即使同为JAVA语言,使用不用的框架所需要编写的代码行也不一样。

(3)对项目估算时缺乏数据支持

因为在软件开发初期时对规模估算都是很难准确量化的，所以到底需要多少资源、多长时间或者规模估算到什么的程度才算是合理的是没有一个标准的。但一个好的项目估算，是离不开一个准确的、可信的、客观的数据作为基础。如果在项目规模估算时只凭项目管理人员的经验进行估算，而缺乏大量的数据支持，那么估算最终就会变成常见的"三拍"现象："首先是项目经理拍脑袋估算，然后是项目经理估算失准时拍马屁的补救，最后是项目失败时拍屁股走人"。当然，这只是个玩笑。不过由此可见项目规模估算不能只依靠经验来估算，而应该是要有大量的数据来支持。

什么是软件项目的规模估算?

软件开发项目管理中的一项重要任务是开发项目的规模估算，这是极其重要但却很容易被忽视的一项内容。因为没有正确的规模估算，项目计划就会失去成功的基础。可惜大部分的开发团队都很难做到对项目规模进行准确的估算。

(1)什么是项目规模估算?

做好软件项目管理的基础是要做好项目的规划工作，而做好项目规划的前提是要做好软件估算。也就是说，就是没有好的软件估算，项目的规划、跟踪和控制就根本无从谈起。因此，软件估算是项目计划活动的基础之一。

软件估算一般是通过主观经验和客观分析两种方法进行，包括有四个重要方面：规模估算、工作量估算、进度估算和成本估算。其中，对规模进行估算是为了将项目范围进行量化。规模估算是整个软件估算中最核心、最基础的环节，也是整个软件估算的第一步。规模估算有两个主要作用：一是通过规模估算建立项目基线;二是利用基线对项目生产率和状态进行评价，并确定软件过程的进度目标。也就是说，规模估算是一切估算的基础，是能直接决定和影响到其它三个估算的决策。

(2)常用的软件规模估算方法

估算是建立在客观事实上对未来可能发生的事情的一种合理性预测。估算本身的不确定性，决定了它不可能是百分之百准确无误的，但是依据某种方法进行合理估计显然比瞎猜好得多。软件估算方法有很多，大致分为基于技术分解模型和基于经验模型两大类。目前基于技术分解模型的方法有：功能点估算法、LOC估算法、MARK II等;基于经验模型的方法有：IBM模型、普特南模型、COCOMO模型等。目前基于技术分解的常用方法是FP功能点估算法和LOC代码行估算法。本文重点介绍这两种方法。

①FP功能点法

功能点分析法 (FPA：Function Point Analysis) 是一种相对抽象的方法，是一种人为设计的估算方式。它是从系统的复杂性和系统的特性这两个角度来估算系统的规模，它的关注点在于程序的"功能性"和"实用性"，是对软件和软件开发过程的间接估算。最初是由 IBM 工程师艾伦艾尔布策提出的，随后被IFPUG 方法继承，是目前国际上主流的软件规模估算方法。

功能点估算法的核心是利用软件信息域中的一些计数估算和软件复杂性估计的经验关系式而导出功能点FP。因此，它是一种在需求分析阶段基于系统功能的一种规模估计方法。主要是通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模X技术复杂度。其中，信息处理规模包括：各种输入、输出、查询、内部逻辑文件数、外部接口文件数等;技术复杂度则包括：性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等。

②LOC代码行估算法

衡量软件项目规模的最常用方法还有代码行LOC(Line of Code) 估算法。LOC是指所有的可执行的源代码行数，包括可交付的工作控制语言语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。这是一种从技术角度来估算的方法，是以代码行(LOC)作为软件工作量的估算单位。开发团队可以根据对历史项目的审计来核算开发团队的单行代码价值，一个代码行的价值和人月均代码行数可以体现一个软件开发团队的生产能力。LOC方法在早期的系统开发中较为广泛使用。优点在于方便计算、容易监控、能反映程序员的思维能力;缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此，在传统的LOC方法上有许多改进的方法。这些不断演化的新方法有：PERT功能点估算法、类比估算法、系统分解法等。

除了以上介绍的两种方法外，还有许多其它的估算方法。不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。因此，建议至少使用两种方法进行规模估算，不要依赖于任何一种方法。只有量体裁衣，具体问题具体分析，才能得到尽量合理的规模估算。

准确进行项目规模估算的步骤

(1)规模估算前先制定良好的规划

一个成功的软件项目首先要有一个好的起点，也就是一个合理的规划。同样道理，一个好的规模估算也需要有一个好的规划。例如，当我们的办公室内堆满了杂乱无章的文件时，恐怕是无法知道对于我们真正有用的文件在哪里。同样道理，当我们从软件项目中收集了各种需求、意见和问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前首先要对众多信息进行整理、归类和分析，从而得到一个条理清晰的项目规划。在这个规划提供的框架内，才可能正确的估算。因为有了规划才能成竹在胸，才能给规模估算指出正确的方向。

(2)确定软件项目的范围

确定软件项目的范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性的要求。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，就必须要使用需求分析技术从客户处得到一个具体的软件范围。因为确定软件项目的范围，就能形成一个有界限的开发框架。虽然这个开发框架还不够精确，但足以进行规模的估算工作。

(3)制订各级别的估算表框架和模板

在开发框架明确后，我们下一步要做的是把公司内部最有项目经验、最有估算经验的工程们召集在一起，制定各级别的估算表框架和估算表模板，并写上足够清晰的指导。当项目组用这些模板的时候，就相当于用了估算精英们的脑袋来思考本项目的估算了。然后，再根据项目的实际情况列出具体的活动，最后是把这些活动进行细化估算。据我过往的经验，很多时候规模估算没有做好的缘故是因为没有估算好非直接生产编程的活动的规模，例如管理类、支持类、维护类的活动，而根本的原因是没有制定好估算表框架和有合适的模板可利用。

(4)根据合适的估算表模板进行由底而上的估算

最后一步是项目组根据项目的特点利用合适的估算表模板继续细化，例如进行详细的WBS分解，列出要完成这个项目所需要的全部工作。然后，把这些工作通过由底而上的方式进行综合，以估算出项目规模的大小。

最后，分享这次项目失败给我的教训：要客观的利用和看待过去的经验。因为以往的估算经验虽然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用历史经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，软件开发领域的技术和方法都在发生着巨大的改变。