COCOMO的发展历程和很多IT管理相关模型的产生一样有着十分传奇的色彩，和其国的Levi’s品牌牛仔裤一样有着悠久的历史。1981年的一天，师出TRW汤普森·拉莫·伍尔德里奇公司[美]计算机科学部从事软件开发成本估算研究工作的Barry Boehm博士——一个为成全天下软件开发事业而投生到历史的洪流中去,决意用智慧为世界迎来崭新的明天的人。工夫不负有心人，在历经日以继夜的无数次失败后，终于在这一天提出的结构型成本估算模型——“构建式成本模型”(COCOMO)，它是一种精确、易于使用的成本估算方法，而且是一个和Putnam一样已经得到业界数据的验证的模型。时过境迁，在随后的10年岁月里，在美国空军任职的Ray Kile先生,对其进行了修订改良，形成了中级COCOMO增强版，同时也是美军使用的标准版本。Boehm重来没有放弃成为一个伟大软件成本估算模型专家的理想，而一直从事如何有效地将COCOMO有效的运用到软件项目成本估算工具当中，他意识到IT界的发展极为迅速，如果没有发展和创新COCOMO终究有一天将会被社会所淘汰，被世人所遗忘，所以到了1996年，Boehm博士根据软件发展情况，终于发布了改进版，将COCOMO升级为COCOMOII，而COCOMO II是对经典COCOMO模型的彻底更新，反映了现代软件过程与构造方法。美军国防部在1999年春季公布的参数模型指导手册中将此模型作为软件评估模型的首选，Boehm终于把COCOMO从浩瀚的同类工具中脱颖而出并推上世界巅峰，期间其著作《软件成本估算：COCOMOn模型方法》和《软件工程经济学》更成为无数IT项目管理人员所景仰的经典之作，终于智慧爆发,惨悟透了老子《道德经》中“大有则无”的思想,发现自己再强也只不过是凡俗人间的一片过眼云烟,所以看破红尘就此归隐。
然而他却给世人留下COCOMOII这个巨大的财富，为软件开发事业做出无法估计的贡献，也许是对他为软件世界付出辛勤汗水的一点告慰吧。要使用COCOMOII模型进行成本估算，首先必须了解一些关于它的用法和需要注意的地方，这样我们才能有效的将它应用当管理工作当中。
首先我们应该了解一下COCOMO模型中用到的一些变量，当然还有COCOMOII模型的类型和分类，这是估算软件成本的重要环节：
（1）COCOMO模型中的变量。
DSI-------源指令条数。不包括注释。1KDSI = 1000DSI。
MM-------开发工作量（以人月计） 1MM = 19 人日 = 152 人时 =1/12 人年
TDEV-----开发进度。(以月计)
（2）COCOMO模型的类型：
COCOMO模型中，考虑开发环境，软件开发项目的类型可以分为3种：组织型(organic): 相对较小、较简单的软件项目。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）
嵌入型(embedded): 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。
半独立型（semidetached）：介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。
（3）COCOMO模型的分类：
COCOMO模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详细COCOMO模型。其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数(LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。
COCOMOII不仅可以评估开发工作量，而且可以对项目的进度进行具体估计。 COCOMOII拥有规模计算，工作量估算，进度估算等重要能力能很好地帮助我们软件维护和进行软件决策。对我们在对项目的范围，时间，成本等管理是十分有利的条件，使我们拥有更多时间去关心项目的质量和使得人力资源更有效分配和利用起到极其重要的作用。可以从产品大小估计的结果中计算出项目的总体人员工作量和时间表。除了大小输入，另一项关键输入是对团队生产率的评测。该输入值可确定项目的总工作量。总的项目时间表与总工作量之间存在非线性的关系。遗憾的是，这些模型从数学的角度来看非常复杂，但是COCOMOII模型正好给我们的工作简化其中复杂的过程，为我们赢得更多的有效时间。
图片附件: 012901.jpg (2007-1-29 10:37, 4.68 K)
PM nominal = Person months effort of the project (人月工作量)
A = Constant representing the nominal productivity (工作量调整因子)
B = accounts for the relative economies/ diseconomies of scale (规模调整因子)
Size = Size of the project (规模,千代码行或功能点数目)
首先这里我们可以看到COCOMO是一个典型的参数估算模型。其中重要的就是两个调整因子和规模的确定上面。
对于软件项目的规模，最适合的还是采用功能点法进行估算，在估算出功能点后可以根据功能点和代码行的折算关系得到代码行的估算数据。因此我们看到COCOMO本身并不能够解决规模估算的问题，更重要的是根据系统已经有的规模来确定项目的工作量和项目周期。
B是规模调整因子，也叫做过程调整参数，当B=1时候说明了工作量和规模之间是线性的关系，这个时候就等同到了我们平时通过规模/生产率来确定项目的工作量的情况上面。但根据实践经验，项目工作量并不是完全由简单的个体生产率来确定的，还涉及到开发灵活性，架构风险，团队，过程成熟度等很多的影响因素。因此需要对B进行适当调整,具体的调整规则参考下表： 图片附件: 012902.jpg (2007-1-29 10:37, 27.03 K)
B = 1.01 + 0.01 ( PREC + FLEX + RESL + TEAM + PMAT)
这里一般B一般都是大于1.01的。
当B<1时候，说明项目架构，开发环境，团队都足够健壮和稳定。这个时候项目表现出来了对规模的经济性，当规模成倍增加的时候，工作量反而不要翻倍。
当B>1时候，说明了项目工作量对规模的非经济性。当规模增加的时候可能会导致工作量的成倍增加。
对于调整因子A一般都是常量，这个需要总结历史项目的度量数据进行反推来计算。因此说要使用COCOMO成本估算模型，必须积累足够多的历史经验数据。
在工作量估算出来后，就可以根据工作量来估算项目的进度。个人认为COCOMO最大的贡献在于对项目进度的估算，如果说对工作量估算还存在当B=1的时候工作量和规模会成为线性关系的话，那对于进度估算则基本上不会出现简单的线性关系。基本上都说明了项目的进度不是简单的根据工作量除以资源的投入而得到的。 图片附件: 012903.jpg (2007-1-29 10:37, 2.8 K)
TDEV代表项目的进度，其中单位仍然按月计算。通过Excel绘制出工作量与进度的关系曲线如下： 图片附件: 012904.jpg (2007-1-29 10:37, 14.11 K)
应用PSM进行软件度量的经验-整理
1.度量是一致但灵活的过程，可以根据信息收集和项目或组织的需求进行裁剪。
2.决策者必须理解要度量哪些度量元，并信任收集到的信息
3.度量必须被用来产生价值
度量的信息分类
1.进度和过程
2.资源和成本
3.产品的规模和稳定性
4.产品的质量
5.过程性能
6.技术有效性
7.客户满意度
图片附件: 012905.jpg (2007-1-29 10:44, 27.65 K)
度量计划
1.度量可以从一个小的度量集做起，然后逐步增加
2.度量计划不仅要定义度量什么，还要定义具体的收集，分析等过程
3.可以根据项目的实际需求对组织级度量过程进行裁剪
4.成功的度量过程应该整合了所以决策者需求
执行度量
1.收集度量数据，执行分析和展现结果
2.度量数据的分析可以包括估算，计划可行性，实际数据与计划数据偏差性能分析
3.尽可能的采用自动收集系统收集数据
4.当需要对度量进行裁剪的时候，一种集结方法需要事先定义。
图片附件: 012906.jpg (2007-1-29 10:44, 23.26 K)
评价度量
1.度量过程和度量数据本身都应该周期性和定时的进行评估和改进。
2.度量是一个迭代的过程，而且会随着信息需求变化和组织级目标不断精练。
理解和信任度量信息
1.应该明确定义和提供清晰的度量元保持度量的一致性和连贯性。
2.展现度量结果和数据时候应该用一种决策者很容易理解的方式。
3.执行度量的人一般不直接做决策，因此度量信息展现必须简单明了。
4.仅仅是因为度量信息是准确和客观的，并不能说明度量一定起作用.
度量数据必须使用
1.度量数据必须尽可能早的收集和提供，以便管理者决策
2.度量结果必须在整个组织内实时的沟通和共享
3.决策并不一定期待完美的数据，但数据本身必须是准确的。
4.度量的结果应该帮助决策者优化整个过程性能
文章来源于领测软件测试网 https://www.ltesting.net/
