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

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

这篇译文也发表在：

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

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

       一般都是按功能点来估计吧，一个功能点多少行来计算

为什么需要判断？

其实我还想问为什么需要规模度量

另外，“一个功能点算作多大的规模？”
你希望得到怎样的回答？
比如“去年做的ABC项目里的‘显示shopping cart’算2个点”这样的回答你觉得如何？

    怎么不知道呢？ 每个功能点都会估算出代码行数，既然是估算，误差肯定是有。 代码估算，有三种方法。

    对于功能点的难度，复杂度，都是经过分析可得出来的.

  比如一个登陆功能，一个单表维护。 在确定框架后，大概就知道要多少行了。

  项目完后，在总结大会上，会对项目前的估计行数和实际行数进行分析的。

这个东西是楼主做的吗 ?? 先表示钦佩 然后问下
要是
出现 mock1234 说的
<!--
其实我还想问为什么需要规模度量

另外，“一个功能点算作多大的规模？”
你希望得到怎样的回答？
比如“去年做的ABC项目里的‘显示shopping cart’算2个点”这样的回答你觉得如何？
--> 怎么办呢?

用户故事永远无法与工作量成比例.....

好比罗那尔多，上一场穿粉红球靴，进球了，下一场比赛的时候，罗拿多也会再穿上粉红球靴，这叫心理暗示，给自己下一场进球找一个理由。而软件规模度量的，也类似于寻找这样一个理由，或者暗示，让pm和老板们心里有一些慰藉──“起码我是有依据的”。

不能象建筑一样用长宽高来度量，成为软件从业人员心中永远的痛，于是通过LOC,通过Feature points来进行“毛咕咕”的度量，当然，这种度量永远带有不确定性，所以有了争吵。

但没有pm在投标的时候不去做这样的一个“毛估估”，无论是在脑子里间或一轮还是利用微软的计算器运算抑或是打开一个excel表格输入几个数据最后得出结果或者有一套super的系统专门来分析。

问题不在于毛估估，而在于毛估估的方法，如让一个没有完整做过项目的人毛估估一下肯定相差十万八千里，印度阿三的大型外包软件公司通常都有历史项目数据库，细分到功能点，当手头有一个近似的项目时，阿三们就可以把数据调出来做参考，那么当数据积累越来越多的时候，当然毛估估的质量也越来越高──但这些都需要积累专业和成本！！！

也有人用代码经济学的思路去搞，比如加一些权重因子进去，也有老外专门搞了程序出来，通常你把数据如是敲进去后得出的结果却令你异常失望，比如你发现老毛子们是用美刀算的，你却用rmb，而且工钱还践得要死，四个字──极不靠普，你想自己编一个吧，但是好像中国人又不太喜欢造汽车轮子。代码行数有个极其伪善的面孔，比如ruby们经常吹虚的代码行数能让java们嫉妒得发狂，你用以个java的代码经济软件来跑ruby项目你要吐血。

所以还是拿个现成的东西毛估估把，回到前面，找一个理由让自己或者老板踏实一下,但是别太当真。

估计工作量的根据是:一堆错误值中找一个老板能接受的值

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

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

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

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