首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >COCOMO如何处理可以分成小项目的大型项目?

COCOMO如何处理可以分成小项目的大型项目?
EN

Software Engineering用户
提问于 2019-11-19 16:53:50
回答 1查看 149关注 0票数 2

假设我想使用COCOMO来估计产生一个100个KLoC嵌入式项目的工作量。不包括努力调整系数,工作量为2.8 * 100^1.2 = 703。然而,该项目有两个不同的组成部分。我声称,在纸面上,每个组件都是它自己的50 KLoC项目,这使得估计值降低到2* (2.8 * 50^1.2) = 612。

哪个是对的?如果我把整个事情组织成两个完全独立的项目,有两个独立的团队,等等,第二个估计是否是正确的?这不是增加了开销,从而增加了工作量超过了最初的估计吗?或者COCOMO太不精确了,以至于在这两个估计之间没有任何真正的区别(然后我应该简单地把它们中的任何一个看作是“在500-1000的努力中”)?

EN

回答 1

Software Engineering用户

回答已采纳

发布于 2019-11-20 00:13:06

COCOMO理论观点

COCOMO是一个基于KLoc中软件大小与工作量之间的统计相关性的模型。您似乎使用过的中间模型也从估计调整因素中考虑了一些额外的成本驱动因素。

COCOMO的估计原则是,产品是一个独立的软件,构成一个整体。因此,如果您可以将代码拆分为2x50Kloc,并且每个部分可以独立运行,那么您的计算将是正确的。

COCOMO与现实

然而,这似乎是一个理想和不可能的情况:

  • 如果这两个部分在某种程度上是相互依存的,则由于每个部分的复杂性增加(由于与另一个部分的相互依存)和可靠性要求的增加(因为另一部分取决于它),EAF会增加。如果这将使分拆产品的电弧炉达到1.3,而不是1,那么总的努力将是795。比最初的100 than估计值高
  • 如果两个部分更相互依赖,甚至是高度相互依赖,那么由于额外的协调、同步和通信工作,整个KLoc的大小肯定不再是100 KLoc=2*50 KLoc。Moroever的EAF也会增加,特别是因为在复杂性的基础上有额外的同步/性能限制。

总之,你的理想案例是非常假设的,当然也离现实很远。

从直觉上讲,我们可以感觉到这个不太理想的数字当然更现实:将一个大产品分成两部分需要付出更多的努力,因为需要处理更多的交互。管理两个部分之间的代码重用也会带来额外的挑战,因为不能再孤立地修改代码。

COCOMO精度

你必须意识到:

  • COCOMO的数字是基于数量相对较少的大型项目(较老的资料来源为70-80个这样的项目,最近的工作中提到的数字在300个以上);
  • COCMO假定所有的需求都是预先知道的,因此没有发现开销。
  • COCOMO并不真正适应应付增量开发方法。
  • 最后,当涉及到从它派生出的工作时,KLOC不再是一个有意义和一致的度量方法.:我们都可以用大量的重复部分编写长代码,而更好的设计可以减少代码行,但需要更高的努力。
票数 2
EN
页面原文内容由Software Engineering提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://softwareengineering.stackexchange.com/questions/401315

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档