（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分解，列出要完成这个项目所需要的全部工作。然后，把这些工作通过由底而上的方式进行综合，以估算出项目规模的大小。
最后，分享这次项目失败给我的教训：要客观的利用和看待过去的经验。因为以往的估算经验虽然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用历史经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，软件开发领域的技术和方法都在发生着巨大的改变。
