扫码阅读
手机扫码阅读
软件度量始于规模,终于规模
84 2024-10-01
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:软件度量始于规模,终于规模
文章来源:
麦哲思科技任甲林
扫码关注公众号
1 项目初期的度量
在项目初期,甲乙双方都希望能够制定出合理的预算和项目报价。通过初步需求的功能点估算,结合历史成本基线,可以预计出项目成本,并加上利润制定报价。需求调研完成后,使用精确的功能点度量方法来衡量软件规模,并依据历史生产率基线或规模与工作量的回归方程来预估开发工作量。进一步,工作量的估算结果将助于项目总体工期的估计,通过回归方程或关键路径模拟方法进行。确定了工作量后,计算出人工成本和其他成本,可得出项目预算。最后,依据历史缺陷密度基线估计质量活动中应发现的缺陷数量。
2 项目收尾的度量
项目末期,根据实际完成的软件规模进行结算,例如按每个功能点定价结算。项目结束后,评估项目组业绩时,可通过实际工作量和规模之比来计算开发效率,体现为每功能点的人月消耗。开发效率受多种因素影响,例如开发团队、平台、复用率和产品成熟度等。除开发效率外,还需评价产品质量,使用缺陷密度和质量单位投入两个指标。在质量投入足够的情况下,缺陷密度能有效评价产品质量。因此,在软件度量中,规模度量是核心,始终贯穿项目始末。
想要了解更多内容?
查看原文:软件度量始于规模,终于规模
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 92.4K
麦哲思科技任甲林的其他文章
迭代回顾会议咨询记录
每次敏捷迭代都是一次PDCA循环, 迭代的回顾会议则是其中的A(adjust),不断的复盘总结可以帮助项目一次比一次做的更好,使团队形成一个自学习的组织。 近日我旁观了一个敏捷项目组的迭代回顾会议,项目组成员对本次迭代的经验教训进行了总结,我作为外部顾问旁观了整个过程,并对项目组中存在的问题,本次回归会议的优缺点进行了点评,咨询记录如下: ...
给程序员的18个忠告
1 想清楚,写清楚,说清楚,才是真正的清楚!2 多花点时间沟通清楚需求,才能把握正确方向!3 修复需求错误的成本是代码错误的几十倍!4 程序员最大的坏习惯就是:急于动手写代码! 5 提高开发效率的捷径:一次做对,不返工!6 写代码之前三件事: 弄清楚做什么; 说清楚怎么做; 想清楚怎么测!7 职业的程序员设计程序,业余的程序员调试程序;8 拷贝粘贴式的作业方式,最容易导入b
硝烟中的Scrum和XP读书笔记
CH1-1 Scrum不是方法学,它是一个框架。CH1-2 Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情 况来对它进行调整;CH2-1 产品Backlog中包含了:故事、特性、需求+优先级并且是用用户的术语的表达;CH2-2 how to demo实际是对用户故事的细化,是设想的用户操作场景,可以作为用户故事的验收准则。CH2-3 指出如何解决问题的应该是...
一次典型的重构
背景描述:近期要去讲一次重构,想收集一个案例,恰好从网上看到了一个朋友写的一个计算算术表达式的C#程序,原程序是计算含括号的正整数表达式的四则运算值。读后,发现问题比较多,而且逻辑有错误,因此对其进行了重构。为简化起间,将程序的功能进行了简化:1 计算的算术表达式只含有+、-、*、/运算2 不含有括号3 表达式的第一个符号是数字4 假定表达式是合法的算术表达式且满足上边的约
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线