软件规模度量的功能点分析法

因为如果不需要判断，就等于听了当作消遣，那么拿出它来讨论所谓“规模度量”，就更是无稽之谈了。

度量的规则是要贯穿始终的，所以不仅仅功能点的数量要度量，功能点的定义也需要能够可以被度量。如果2个人预测出的功能点是依据同样的原则，那么就可以说1000个功能点比300个多3倍左右的工作量。

度量的难度不在于实施，而在于定义标准。

项目管理的量化不仅仅是一句口号，照着人老外的流程做就完事了。每个想将实际工作真正量化起来的公司，都必须首先制定自身的量化标准。在本帖的具体问题上，功能点的定义就是标准。企业本身应该有这样的标准文档，说明什么样的东西应该被定为一个功能点，这个文档是来自于该企业过去的历史数据，通过不断的完善以及评审之后得到的。而这种文档的建立以及维护更新工作本身就是一个非常困难的事情，何况需要很多个同类型的文档来描述不同的标准(需求定义文档，测试用例定义文档...)。

所以量化管理才这么困难。

软件规模度量和估计有很多方法，常见的就是代码行估计法，但是随着UI在软件中的比重逐渐扩大的情况下，通过代码行来确定软件规模显得有些不适用，或者不够全面，功能点分析法是一种新的软件规模评估方法。我个人认为比较适合MIS一类的软件系统的规模估计，但是由于公司规模不大，这些理论模式没有精力去验证和实施，希望有兴趣，有条件的人去研究和实施吧。

这篇译文也发表在：

http://www.softwaremetrics.com/Articles/FPABase.pdf

同时原文也在这个网站上，感兴趣的人可以去这里看看。

古人说的好“水至清则无鱼”，有些事情还是模糊点比较好，比如说软件规模度量。

之所以叫估算，因为他准不了。最准的是在项目都做完后的“估算”。不准就要想办法准，找依据，找规律。个人觉得这不是科学计算，允许有误差，那还较什么真，得到的无非是个经验值。
真要想接近准确，就要从一开始量化、标准化，什么样的是一个用例，不可在天上，不可在海底。这样，一个用例或功能点才有可能量化。工作量何其大，一般的公司宁可接受估算的误差，也不想用这么大的力气做这项工作，因为看不到投入后产出什么。套句俗话，我们要先生存！

一个功能点算作多大的规模？这个弯弯绕的概念，其实是个谎言。

不能回答这个问题，那么你怎么去判断张三所说的1000个功能点就一定在规模上大于李四所说的300个功能点呢？

所谓“没有去验证和实施”，通常不是因为“精力”问题，而是这些理论本来就是空洞的，所以让人无法实施。