软件度量始于规模,终于规模
发布于 2024-10-01
987
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
1 项目初期的度量
在项目初期,甲乙双方都希望能够制定出合理的预算和项目报价。通过初步需求的功能点估算,结合历史成本基线,可以预计出项目成本,并加上利润制定报价。需求调研完成后,使用精确的功能点度量方法来衡量软件规模,并依据历史生产率基线或规模与工作量的回归方程来预估开发工作量。进一步,工作量的估算结果将助于项目总体工期的估计,通过回归方程或关键路径模拟方法进行。确定了工作量后,计算出人工成本和其他成本,可得出项目预算。最后,依据历史缺陷密度基线估计质量活动中应发现的缺陷数量。
2 项目收尾的度量
项目末期,根据实际完成的软件规模进行结算,例如按每个功能点定价结算。项目结束后,评估项目组业绩时,可通过实际工作量和规模之比来计算开发效率,体现为每功能点的人月消耗。开发效率受多种因素影响,例如开发团队、平台、复用率和产品成熟度等。除开发效率外,还需评价产品质量,使用缺陷密度和质量单位投入两个指标。在质量投入足够的情况下,缺陷密度能有效评价产品质量。因此,在软件度量中,规模度量是核心,始终贯穿项目始末。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 567.3K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
如何澄清“一句话需求”?
很多项目需求写的模糊,如何对这些模糊的需求进行澄清呢?通过哪些问题可以帮我们澄清需求呢?我设计了一个问题单供大家参考。
如何做好软件估计?
1 有经验的人参与估算 一方面要对估计的内容有开发经验,另一方面也要经过了估计的训练,在估计方面有经验.两种经验缺少其一,估计的风险都比较大. 2 分解的颗粒度要小 在估计时要对估计的内容进行分解,划整为零,对于小的任务进行估计时,才容易把握.比如让你估计一碗大米中有多少粒一样,一般的办法就是把大米划分成大小基本相等的几堆,先估计其中一小堆或者数一数,然后再估计整体的粒数. 3 确保没有遗漏 如果
同行评审培训练习点评结果
2008年3月3日做同行评审的培训,讲解同行评审方法花费了3小时,练习时间为1小时,点评时间为45分钟。参加培训的人员为20人,19人参与了练习,划分成了3个小组练习。3个小组对同一个需求进行了同行评审,该需求为一个实际项目需求的一部分,仅有1页纸,但是质量比较差。 这3个小组的练习结果如下表所示: 第1组 第2组 第3组
3种工厂模式的比较
简单工厂:一个具体工厂通过条件语句创建多个产品,产品的创建逻辑集中与一个工厂类。客户端通过传不同的参数给工厂,实现创建不同产品的目的增加新产品时,需要修改工厂类、增加产品类,不符合OCP原则 工厂方法:一个工厂创建一个产品,所有的具体工厂继承自一个抽象工厂。客户端先创建不同产品的工厂,再由工厂创建具体产品,产品的创建逻辑分散在每个具体工厂类中。客户端只依赖于抽象工厂与抽象产品,不依赖任何具
读的感触点
1 开发人员的快乐: 创建事物, 开发对他人有用的东西, 组装的魅力, 持续学习的快乐, 在易于驾御的介质上工作 开发人员的苦恼: 追求完美 由他人设定目标 对他人有依赖 查找修改BUG 过时的很快 2 BROOKS法则:向拖期的项目追加人手,只能让项目更拖期 3 设计人员要少而精 4 开发人员如何避免画蛇添足 5 非正式交流,正式交流,
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线