关于工作量估算，我提一个自己的看法

[dxymm]

我们公司的项目都是差不多，很多时候可以套用，但是因为通用性没做好，导致很多时候要重写

经常做此类项目

我提一个工作量估算的公式

工作量=复杂度的平方 / 旧模式的相近度（0.1 - 0.9）

大家认为如何？

[dxymm]

我的观点

复杂度可拆分成两点
1、模块数、模块功能点
2、技术难点
这里需要做一些研究，搞出一些公式或者数据表出来

相近度可以这样核算
旧模式中可利用的功能点）/旧模式的所有功能点

各位，再想想，还有什么要素要考虑进去

• 打赏
• 举报

回复 赞

[stonespace]

根据《人月神话》的数据，工作量和代码行数的关系是1.5次方，不是平方。复杂度和代码行数的关系应该是线性的。所以复杂度的幂用1.5可能更接近事实。

相近度的幂是不是-1就很难说了，再说感觉搂主对相近度也没有一个精确定义，很难分析相近读的影响。我感觉相近度的幂不应该是-1，相近之所以能够节省工作量，是因为可以重用，而重用导致工作量减少，应该是一个差值，比如我可以重用1000行代码，那么工作量就可以减去1000行代码的工作量。所以用减可能比用除好。

• 打赏
• 举报

回复 赞

[zhf_karen]

嘿嘿，复杂度如何衡量？相近度如何衡量？而且，某些模块不仅仅是复杂和相近的问题，还有很多其他的问题，比如相对过于少的时间，就需要把某个模块的工作量扩大几倍，因为大家承担了过于多的压力。那么你最好还是有个系数来平衡，但是这些要素如果没有大量的用例来证明，还是会出现不是量化而是定性的问题。

不管如何工作量的考核，至少在现在，落实在最后就是主管的主观感受。仅此而已。

• 打赏
• 举报

回复 赞

[once168]

COCOMO

• 打赏
• 举报

回复 赞

[dxymm]

Good,我没从头到尾读过《人月神话》，只大致翻阅了一下，有时间一定仔细研究。

至于是1.5还是2，我觉得这是一个对开发工具熟悉的程序

如果对开发工具异常熟悉，1.5有可能，但是如果不是非常熟悉（我感觉国内大部分如此），2还是比较合理，甚至取2.5也不为过

• 打赏
• 举报

回复 赞

[sxzz]

我不知道用你的公式最后得出的工作量是什么或多少。
我认为：
工作量的度量单位：人时、人天、人月、人年，1人年=12人月，1人月=22人天，1人天=8人时；
工作量的种类：研发工作量、管理工作量、支撑工作量。
研发工作量≈新开发软件规模*难度系数/人均生产率。
管理工作量≈项目研发工作量*比例系数。
支撑工作量≈项目研发工作量*比例系数。
在这里“新开发软件规模、难度系数、人均生产率、比例系数”将会因为各公司各团队的不同而有差别，具体的取值会因人而异，更多的会是经验数据。
软件规模的定义方法有很多文献介绍，大家可以选一些参照，较常见的定义方法是代码行定义法：
1. 小规模软件源程序行数小于5000的软件；
2. 中规模软件源程序行数为10000～50000的软件；
3. 大规模软件源程序行数为100000—500000的软件；
4. 特大规模软件源程序行数大于500000的软件。
难度系数就更主观了，可以说完全由团队实际情况根据经验给出。
我觉得这样的量化也许直观一些。

• 打赏
• 举报

回复 赞

[rolandash]

都是经验公式而已，不可能强求一致

• 打赏
• 举报

回复 赞

[linnet2000]

功能点的计算由于开发工具的不同，参数也不同，诸如COCOMO模型等经验公式，没有实际意义。

• 打赏
• 举报

回复 赞