作者：张劲 来源：希赛网
张劲：中大工学硕士，国家信息系统项目管理师、系统集成项目经理、高工，广东软件协会过程改进专家、希赛顾问团专家顾问，十多年软件开发和项目管理经验，其中八年以上的流程改进经验，曾担任多个优秀公司团队的过程改进负责人，负责推进ISO/CMM/CMMI的认证评估及管理工作。博客：http://blog.csai.cn/user1/35585/
选择良好的估算模型有助于公司开发团队准确控制项目进度、成本、质量以及客户满意度，这是不容置疑的。
目前IT业内常见的规模度量方法有功能点分析(FPA：function points analysis)、代码行(LOC：lines of code)、德尔菲法(Delphi technique)、COCOMO模型以及复杂度估算模型(Complexity Model)。
曾看过业内有不少公司在CMMI预评估之前都使用Function Points 功能点或COCOMO模型，但是在预评估后，都更换为其他方法，最根本的原因在于这两种方法过于复杂，虽然项目组成员经过多次估算培训，但要做到能全面合理解释、滴水不漏确实不太容易，因此在CMMI预评估时，不少公司的项目组成员在估算这个问题上给严厉的主任评估师问得漏洞百出，难以自圆其说而狼狈不堪，当然也有一小部分公司团队因为在评估前和主任评估师有很好的沟通，做了充分准备，能合理解释，有效地规避了风险。
因此，选择估算模型，一定要以自己公司的实际项目情况作为选择标准，“最适合自己的也就是最好的。” 根据估算成本和使用简单性原因，业内有不少公司采用了Delphi法或复杂度模型做为公司主要估算模型，其中以复杂度模型为最贴近项目实际运作。
复杂度估算模型原理是基于以往公司内部同类项目/工作的经验及历史数据，按功能或任务或者技术类型，按高/中/低难度进行划分，每个难度对应的 SIZE(SIZE对应值可以采用以前类似Function耗费的真实成本(比如单位：MD 人天 )的一个比率进行调节)，并通过识别新需求的复杂度来统计出项目规模。例如我们可以定义：
1.New Function
Function Type Low Average High
2.Enhancement Function
Function Type Low Average High
不同类型项目需要定义出其相应的复杂度矩阵。当复杂度矩阵定义好后，我们最后所需要做的事是：将需求分解为WBS,然后将WBS 所对应的Function套入上述已定义复杂度矩阵中，再汇总得到最终的SIZE。
使用复杂度模型的前提是：已有同类型项目成功实施并有历史数据积累。在这个基础上，估算模型的准确率是非常高的，项目组做估算成本也很低。
一般而言，在CMMI评估中，复杂度模型估算数据是无懈可击的。当然其他估计模型也各有所长，可以根据公司项目实际情况搭配使用。
文章来源于领测软件测试网 https://www.ltesting.net/