扫码阅读
手机扫码阅读
快速学习COSMIC方法之十七:如何寻找更简单有效的规模度量方法?

我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。

麦哲思科技任甲林
扫码关注公众号

工作量估算方法的探索与分析摘要
企业在估算软件工作量时,首先需要估算软件规模。传统的代码行估算方法因人员经验和编程语言的不同导致结果差异较大,缺乏可比性和精确性。因此,更多企业转向使用功能点来衡量软件规模。
COSMIC方法作为功能点度量的先进方式,被认为是简单易用的估算方法。尽管存在学习成本,但逐渐被行业采纳。企业在寻找简化方法时,应确保其合理性和科学性,特别是当与业内其他组织进行比较时。
判断自创规模度量方法的有效性可以通过分析规模数据与实际工作量数据的相关性。成功案例展示了一个公司使用需求个数作为规模估算,历史数据分析显示需求个数与编码工作量相关性超过90%,证明了方法的适用性。然而,失败案例中的另一公司自定义的需求点与工作量相关性较弱,相关系数只有0.439,表明需求点不是一个合适的规模计量单位。
另一成功例子是故事点用于规模估算的敏捷方法,其与工作量的相关性超过60%,验证了故事点的定义合理性。最终,一个公司在实施COSMIC方法后对其进行本地化调整,用于度量维护和升级软件规模,相关性超过80%,说明调整后的方法适合公司项目,能有效估算开发工作量。
想要了解更多内容?

麦哲思科技任甲林
扫码关注公众号

麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 222.6K
麦哲思科技任甲林的其他文章
杂谈Barry Boehm的软件工程七原则与敏捷实践
大概在5年以前曾经从网上搜到了Barry Boehm提出的软件工程的七原则(Seven Basic Principles of Software Engineering),这是Barry Boehm1983年发表的文章,在网上搜到的是别人对这七个原则的转译与介绍,看后觉得怪怪的,总是觉得有些地方不能准确把握这七个原则的含义。于是去google搜其原文,未果,最近终于搜到了原文,因此更能准确把握Ba
各阶段缺陷检出密度的统计分析案例
某企业积累了10个项目的历史度量数据,积累了5个阶段的缺陷密度,即从需求评审的缺陷密度,直至交付后3个月内的缺陷密度,计量单位统一为缺陷数/KLOC。 需求评审缺陷密度 设计评审缺陷密度 代码评审缺陷密度 测试发现缺陷密度 交付后缺陷密度 P1 ...
敏捷方法中采集的度量数据
在敏捷方法中,要求度量的数据少之又少,可谓简单实用:规模:(1)故事点:用以估算工作量、度量开发效率。工作量: (2) 计划的工作量:用以排定项目计划。 (3) 剩余任务的计划工作量:用以跟踪项目进展。效率:(4)开发速度:每次迭代完成的需求的规模(如故事点),用以估算项目需要的迭代次数。其他度量元根据项目组的实际情况,可以由项目组自己定义。
我说CMMI 2.0 之 配置管理
和CMMI1.3相比,CMMI2.0中配置管理的实践基本没有变化。CMMI DEV 2.0 的20个PA中,CM是唯一一个没有3级实践的PA。基本概念这个PA涉及到的基本概念比较多,我们挑选部分基本概念,做通俗解释:配置管理:通过配置标识、版本控制、版本管理、基线管理和配置审计来管理工作产品的完整性。配置项:配置管理的对象,包括各种文档资料,代码等工作产品。包括:给客户的交付...
卑鄙是卑鄙者的通行证?
偶尔看到最近的新闻:东航为临时调走飞机赔偿每名乘客2000元(http://news.sina.com.cn/c/2007-11-11/024914279102.shtm),颇有些出离愤怒。航空公司晚点已经是家常便饭,我大概每周坐3到4次飞机,飞机的正点率小于20%,晚点也就罢了,最可恨的就是不告诉你晚点的真相,要么是航空管制,要么是目的地天气不好,总而言之很少有航空公司的责任。这则新闻描述的欺骗
加入社区微信群
与行业大咖零距离交流学习


PMO实践白皮书
白皮书上线
白皮书上线