扫码阅读
手机扫码阅读
软件度量始于规模,终于规模
191 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:软件度量始于规模,终于规模
文章来源:
麦哲思科技任甲林
扫码关注公众号
1 项目初期的度量
在项目初期,甲乙双方都希望能够制定出合理的预算和项目报价。通过初步需求的功能点估算,结合历史成本基线,可以预计出项目成本,并加上利润制定报价。需求调研完成后,使用精确的功能点度量方法来衡量软件规模,并依据历史生产率基线或规模与工作量的回归方程来预估开发工作量。进一步,工作量的估算结果将助于项目总体工期的估计,通过回归方程或关键路径模拟方法进行。确定了工作量后,计算出人工成本和其他成本,可得出项目预算。最后,依据历史缺陷密度基线估计质量活动中应发现的缺陷数量。
2 项目收尾的度量
项目末期,根据实际完成的软件规模进行结算,例如按每个功能点定价结算。项目结束后,评估项目组业绩时,可通过实际工作量和规模之比来计算开发效率,体现为每功能点的人月消耗。开发效率受多种因素影响,例如开发团队、平台、复用率和产品成熟度等。除开发效率外,还需评价产品质量,使用缺陷密度和质量单位投入两个指标。在质量投入足够的情况下,缺陷密度能有效评价产品质量。因此,在软件度量中,规模度量是核心,始终贯穿项目始末。
想要了解更多内容?
查看原文:软件度量始于规模,终于规模
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 134.4K
麦哲思科技任甲林的其他文章
过程改进的关注点之项目管理过程
从项目估算到项目策划、再到计划跟踪控制,包括风险的识别与管理,常见的改进点有哪些呢?
实施敏捷的四个致命障碍
敏捷方法在中国推行的如火如荼,我也为多家公司做了敏捷的导入咨询,在实践中遇到了几个致命障碍,限制甚至阻止了敏捷方法的推行,我把有深刻体会的障碍总结出来,供大家在实践中规避之。障碍一:没有建立组织级的敏捷价值观与环境。 很多公司在导入敏捷时,先从一个项目开始尝试敏捷方法,试图在单项目内成功了,再推广到其他项目。这种初衷是好的,但是往往事与愿违,为什么呢?因为缺乏组...
我说CMMI之三:CMMI的构件
我说CMMI之三:CMMI的构件 CMMI中的内容是按照成熟度等级或过程域类别、过程域、目标、实践、子实践的方法来进行分类管理的,这些概念之间的整体部分关系可以参见下图。 过程域的概念我们前面讲过了,这里不赘述。每个PA都有一个目的,在英文里明确区分了Purpose与goal这两个单词,我们翻译为了目的与目标。在中文里这2个单词病没有特别明显的区别。Purpose是一种抽象的,宏观的期望,goal是一种具体的,微观的期望。 PA之间有一定的关联性,互相影响,比如RD的输出为TS的输入,TS的输出又影
我说CMMI2.0之产品集成
产品集成(PI)即把不同部件集成在一起,形成一个更大的部件或一个完整的可交付的产品。该PA包含了集成策略的制定、集成准备、集成、集成后的验证与确认、以及交付的活动。 实践列表 PI 1.1 Assemble solutions and deliver to the customer. 组装解决方案并交付给客户 ...
快速学习COSMIC方法之十七:如何寻找更简单有效的规模度量方法?
很多企业都在探索合理估算工作量的方法,而工作量的多少主要取决于软件规模的大小,因此在估算软件工作量之前需要先估算其规模。传统的规模估算方法是进行代码行的估算,但是对于同一个需求,不同经验的人员去估算,结果差别很大,不同的实现语言,估算结果差别也很大,即使不同经验的人员针对同一种需求去实现,实际的代码行数也差别很大,并且实际情况中,往往一个需求可能需要多种语言结合才能实现。因此,使用代码行作为衡...
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线