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

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

这篇译文也发表在：

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

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

评论

25 楼 zhanghonglun 2009-07-08  

mock1234 写道

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

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

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

组织内部使用的度量数据，只要自己的标准一致就足够了。

24 楼 seemoon 2009-06-27  

yecllsl 写道

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

估算的意义除了准之外，还有一个“获知时间提前”的作用，并据此展开其他管理工作。误差是允许的，但做过学问都知道误差范围这一说，如珠峰测试，你测试出一个7000米高度试试？

估算需要基础，而基础的建立也并非大公司作为前提，先生存是必须的，但不能作为赖活的借口。

23 楼 seemoon 2009-06-27  

引用

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

好，那么我们拿道德经来做管理吧，先从煎鱼学起。

22 楼 xianlv 2009-06-27  

ltian 写道

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

这篇译文也发表在：

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

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

规模度量如果只用于客观，是个好东东。但如果据此来做绩效评价，最后难免变成扯谈。

对于想要管理的目标。

有这样的矛盾：无法衡量的指标是无法管理的，在这里是软件规模；但是人们只做管理上去度量的东西，而不是按照管理目标做事情。

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

21 楼 yecllsl 2009-06-23  

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

20 楼 phpxer 2009-06-22  

darkewiser 写道

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

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

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

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

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

毫无疑问，功能点估计能够帮助我们预估需要多少人力，并帮助确定一个项目中止日期。 虽然功能点估计本来就是一个猜的比重比较大的，但是终究比不去仔细考虑随意猜要好。 功能点估计同样是要有一个量化标准的，无论在什么情况下，有标准有助于细化。尤其应对历史数据进行积累，并逐步改进。

19 楼 m0085_cn 2009-06-18  

我觉得有好多同学都进入了一个误区，就是功能点是不能这样单纯比较的，因为功能点 有粒度的划分，同一个模块，A估算3000个功能点，而B可能估算300个功能点，因为大家对功能点划分的粒度是不同的；
可以比较的是工作量，而工作量最后应该是多少人天或者是多少人月，也就是A说的3000个功能点需要多少人天或者人月，这就涉及到一个功能点需要多少人天或者人月了，也许对于A一个功能点需要0.2人天，对于B一个功能点可能需要2人天；
但是对于一个公司或者一个组织来说，对应功能点的估算应该是有一个比较统一的标准的，也就是功能点的粒度应该是有一个标准的，不管粒度是粗是细，最终都要估算成工作量（多少人天或者人月），既然是估算肯定是有误差，这个跟很多因素有关系，比如：功能复杂度、功能点的粒度、人员风险等等。

总之不管是代码行估算还是功能点估算，都是估算的一种方法，目的都是要估算的工作量更加接近实际的工作量，最终可以比较的是工作量（人天或者人月），而不是代码行数或者功能点数。

18 楼 issppt 2009-06-16  

抛出异常的爱 写道

seemoon 写道

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

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

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

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

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

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

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

感觉估计工作量的结果才是：一堆错误值中找一个老板能接受的值。
额。。。感觉工作量估计的根据应该是经验，不过说实话，任何和估计扯两边的东西都是和经验会联系在一起，所谓的量化的方法，只不过是吧一大堆的项目拿过来统计一下，然后发现下共同点，然后拿几个元素套一下公式之类。实际上大部分估计还是做个简单的划分，功能点也好，页面数也好，UI复杂度也好，然后根据经验去估计规模，工作量，工期，buffer等等。

17 楼 RCFans 2009-06-15  

乐观估计、悲观估计是程序员自己估算的，专家估计中的专家是指系统设计师和商业分析师的估计，这两个角色，没有就没办法。
每个项目会有一个偏差率，由QA来进行监控和归档，就算是“感觉”，经历过三、四次估算的程序员基本上误差会在5%以内，关键是要去做。
中国人那点经验就是迈向专业化生产必然付出的成本。

16 楼 darkewiser 2009-06-15  

RCFans 写道

三点估算法啊，乐观估计、悲观估计，然后，专家估计

说的非常好，但是我有一个问题，乐观估计，悲观估计是怎么来的呢？用什么标准？专家估计--什么样的水平算是专家？是不是所有专家的水平都是一样的？每个专家的估计结果都会相同？

其实我提这些无非是想说，这些本身还是经验估计，说白了还是“感觉”。三点估计算法没有问题，而且是很好的方法，能够一定程度上降低估算的偏差。问题是每个点算出来的是不是可靠，而我的看法是：不能量化的就不可靠，“感觉”最多只是感觉一下趋势。

老外在项目完成后会把完成的项目归档，然后对整个过程进行分析，从而不断的修正出一些基本的度量方式（因企业而各不相同）：多少代码算一个功能点，每个功能点完成之后大概会出现多少个bug...当项目的数量越来越多的时候，数据的准确性会越来越接近真实。这时候，用这些标准以及度量方式得出的结论才是比较贴合实际的。

只是在国内，这么做的公司很少。

15 楼 RCFans 2009-06-15  

三点估算法啊，乐观估计、悲观估计，然后，专家估计

14 楼 darkewiser 2009-06-15  

yiding_he 写道

如果是事先度量，那么找个有经验的人说个数，然后乘以 2 就可以了；

如果是事后度量，那更简单了，把各项成本加起来就行了。

“有经验的人”本身就无法度量。

这种度量本身不能被标准所量化，不存在操作性。直接结果就是量化管理无法起作用--这个就是度量难做的原因。

中国人喜欢用经验，外国人喜欢用数字。所以国外的项目管理方法到中国来就问题多多。

13 楼 yiding_he 2009-06-15  

如果是事先度量，那么找个有经验的人说个数，然后乘以 2 就可以了；

如果是事后度量，那更简单了，把各项成本加起来就行了。

12 楼 RCFans 2009-06-15  

周报日报确实没有必要填写，采取最新的“天气图”、“笑脸图”吧，并且，关于项目进度汇报问题，也不应该落实到成员身上，由PM去check。

11 楼 darkewiser 2009-06-15  

蓝皮鼠 写道

引用

度量的难度不在于实施，而在于定义标准。
所以量化管理才这么困难

定义标准不困难，量化管理也不困难，真正困难的是找到需要干这些是的原因。
其实就是价值的问题，没有合理的利益，为什么要做？

这是一种本末倒置的说法。大家有分歧的原因是在于对所谓利益的理解。什么是合理的利益？只是钱么？“有效”的项目管理能够合理的规划与控制成本，并能较准确预测出最后的收益。

遗憾的是在中国，基本看不到真正有效的项目管理。大部分公司所谓的项目管理只是为了忽悠领导跟客户而做做样子。不信我们可以回想一下项目组成员是怎么填写周报，日报的。基本上都是拍脑袋写法--随便整点东西出来对付一下，实在没法写了都写 bug fixing。本来为了提高效率的手段反而变成了大家伙的负担，项目的管理与控制完全由PM的人格魅力与管理艺术决定，项目管理的规定与实际完全脱节--我想这才是楼上这位仁兄觉得项目管理没有意义的原因吧。

10 楼 蓝皮鼠 2009-06-13  

引用

度量的难度不在于实施，而在于定义标准。
所以量化管理才这么困难

定义标准不困难，量化管理也不困难，真正困难的是找到需要干这些是的原因。
其实就是价值的问题，没有合理的利益，为什么要做？

9 楼 darkewiser 2009-06-12  

mock1234 写道

gigix 写道

mock1234 写道

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

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

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

为什么需要判断？

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

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

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

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

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

8 楼 抛出异常的爱 2009-06-12  

seemoon 写道

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

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

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

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

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

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

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

7 楼 seemoon 2009-06-12  

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

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

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

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

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

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

6 楼 抛出异常的爱 2009-06-11  

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