软件度量始于规模,终于规模
发布于 2024-10-01
1369
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
1 项目初期的度量
在项目初期,甲乙双方都希望能够制定出合理的预算和项目报价。通过初步需求的功能点估算,结合历史成本基线,可以预计出项目成本,并加上利润制定报价。需求调研完成后,使用精确的功能点度量方法来衡量软件规模,并依据历史生产率基线或规模与工作量的回归方程来预估开发工作量。进一步,工作量的估算结果将助于项目总体工期的估计,通过回归方程或关键路径模拟方法进行。确定了工作量后,计算出人工成本和其他成本,可得出项目预算。最后,依据历史缺陷密度基线估计质量活动中应发现的缺陷数量。
2 项目收尾的度量
项目末期,根据实际完成的软件规模进行结算,例如按每个功能点定价结算。项目结束后,评估项目组业绩时,可通过实际工作量和规模之比来计算开发效率,体现为每功能点的人月消耗。开发效率受多种因素影响,例如开发团队、平台、复用率和产品成熟度等。除开发效率外,还需评价产品质量,使用缺陷密度和质量单位投入两个指标。在质量投入足够的情况下,缺陷密度能有效评价产品质量。因此,在软件度量中,规模度量是核心,始终贯穿项目始末。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 814.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
敏捷的过程改进方法:从经验教训中学习
每次去客户现场做差距分析或者运行检查,总是习惯于找他们的缺点,但是每次也总能从客户那里发现他们的优点,时间久了,慢慢地对缺陷麻木了,审丑疲劳了,只有发现他们的优点时,我才会精神一振,心情愉快。 今年1-2月份期间我去给一个客户做运行检查,整理完发现报告后,我查阅了那6个项目组的阶段总结报告与项目总结报告中的经验教训部分,我发现的60%的缺陷他们自己也感觉到了,只是没有人去提取、去系统的归纳整理、
软件开发经济实用的15条实践
无论是否参考CMMI的模型,在软件开发的过程,我认为如下的15条实践比较经济实用: (1)控制项目组的团队规模不超过10人,人员要少而精。 (2)需求文档化,无论大小项目必须清晰的描述需求。 (3)采用用例、界面原型描述需求,采用这2种手段强制使需求描述的完备而清晰。 (4) 项目的阶段计划与2周计划,阶段计划定义总体承诺,2周计划定义近2周的详细任务安排。 (5)逐日跟踪+周例会,每
项目里程碑评审的关注点
(1) 项目工期情况 关键路径是否按计划完成了? 如果没有按计划完成: 提前或拖期的原因是什么? 在后续阶段如何采取改进措施? 对后续阶段的工期有什么影响? (2)任务进展情况 计划完成的任务情况: 计划完成的任务有哪些? 提前完成的有哪些?提前完成的任务工作量有多少? 未完成的任务有哪些?未完成的任务工作量有多少? (3)工作量投入 计划投
TSP中的10个量化法则
TSP(Team software process)是Humphery提倡的解决CMM如何做的一个模型,他认为采用了TSP之后,可以加快企业达到CMMI5级的速度,可以提高企业的质量。在TSP中Humphery提出多项度量数据,我从中整理了如下的10个量化法则和大家分享,其中前5个法则是关于工作量的分布,后5个法则是关于质量的。其实这些法则中具体数值的大小完全可以商榷,但是最关键的是蕴含在这些数值
高成熟度的真正难点是什么?
很多朋友认为4-5级难做的原因是度量做的不好,其实我认为那只是表象,最根本的原因还是过程不稳定,2-3级的过程就没有做好,过程不稳定,反应在数据上就不稳定,MA可以做的很好,但是MA的结果可能没有管理的参考价值,建立的模型就没有意义。比如: 我们可以很准确的度量身高、体重、年龄、每天的饭量、每天饭食里葡萄糖的含量、智商。我们希望建一个模型来预测智商,假如根据上述信息建立了一个模型: 智商=f(
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线