[原]软件项目量化管理目标举例
标签:
| 发表时间:2014-05-07 02:59 | 作者:dylanren
出处:http://blog.csdn.net/dylanren
1 产出类目标
1.1总体目标
进度:项目工期偏差率介于+-15%之间;
质量:项目的缺陷逃逸率不高于5%;
项目交付的缺陷密度不高于1个bugs/KLOC;
规模:需求变更率不超过15%;
成本:工作量偏差率不超过+-30%;
每人月实际投入项目的时间不少于上班时间的50%;
项目返工工作量不高于20%;
效率:全生命周期生产率不小于1KLOC/MM;
其他:人员变更率不超过20%;
1.2局部目标:
进度:阶段工期偏差率不超过+-15%;
质量:需求评审的缺陷密度不少于0.2/页;
设计评审的缺陷密度不少于0.5/页;
系统测试的缺陷密度不少于2个/KLOC;
单元测试的缺陷密度不少于5个/KLOC;
代码走查的缺陷密度不少于10个/KLOC;
集成一次通过率不少于90%;
静态检查的缺陷密度不高于10个/KLOC;
测试缺陷重现率不高于10%;
规模:需求文档的页数不多于15CFP/页;
代码复用率不少于20%;
2 投入类目标:
每月平均加班工时不超过2天;
文档中的图表数量平均每页不少于1个;
需求评审的工作量:需求开发的工作量>50%;
设计评审的工作量:设计的工作量>50%;
需求、设计评审的速度不高于10页/小时;
注释代码比例不少于10%;
代码评审速度不高于250行/小时;
代码走查的投入工作量不少于1小时/人天;
单元测试的用例密度不少于50个测试用例/KLOC;
系统测试的投入工作量不少于100人天;
系统测试的用例密度不少于10个测试用例/KLOC.
作者:dylanren 发表于2014-5-6 18:59:05
原文链接
相关 [软件 项目 量化] 推荐:
- - 麦哲思科技
进度:项目工期偏差率介于+-15%之间;. 质量:项目的缺陷逃逸率不高于5%;. 项目交付的缺陷密度不高于1个bugs/KLOC;. 规模:需求变更率不超过15%;. 成本:工作量偏差率不超过+-30%;. 每人月实际投入项目的时间不少于上班时间的50%;. 项目返工工作量不高于20%;.
- HICU - FeedzShare
来自: 小众软件 - FeedzShare . 发布时间:2011年09月12日, 已有 3 人推荐. Planner 是一款开源、易用、跨平台的项目管理软件. 二猪用了 OpenProject 几年,现在已经受够了它的各种问题. 前段时间发现了 Planner,这个也算有些历史了,可是完全不如 OpenProject 名气大.
- 乾 - 《程序员》杂志官网
作者结合切身经历,展示了他之前所在团队软件项目延期的种种原因,而其中印象最深刻的是各种人事纷扰乃至于勾心斗角. 六年前,毕业未久的我在一家外企工作,我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周. 这本身根本不是什么大事情,但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻. 我的老东家是一家大型跨国电信设备开发商,曾具有辉煌的历史.
- - CSDN博客研发管理推荐文章
原文:http://www.itworld.com/article/2845997/what-software-project-managers-can-learn-from-nasa.html. 无可否认,NASA 的工程经验相当丰富. 他们不只做出了火箭和太空船这些酷炫的硬件,还做出了一系列 高可用的软件.
- - 外刊IT评论
本文的作者Capers Jones是Namcook Analytics公司的副总裁和首席技术总监. 他一直在收集软件质量和开发效率上的数据. 他写了几十本关于软件质量、最佳实践方法、评估、测量方面的著作. 在处理软件需求时,有三个问题一直折磨着我们,并使软件项目消耗无数资金. 其中很大一部分都产生在项目交付并运行后的新需求的收集工作中.
- - CSDN博客研发管理推荐文章
在软件开发过程中需求的变更会给开发带来不确定性,但只要把需求变更作为重点、难点小心加以控制,软件开发的进度、成本和质量也就有了"安全"的基础. 变化并不是人们最害怕的,最怕的是跟不上变化的步伐. 需求变更是因为需求发生变化. 根据软件工程思想,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减,均属于需求变更.
- - 博客园_新闻
“兄弟,你看做这样一个软件需要多少钱. ” 这估计是所有软件从业人员被问的最多也是最无奈的一个问题. 这个问题等同于,“你看装修一个 100 平米的房子需要多少钱. 软件开发你不懂,装修你总懂吧,100 平米的房子装修从 10 万到 100 万均有可能,取决于你找什么级别的设计公司,买什么样的材料,请什么样的施工队……所以,我真的没有办法回答你“做这样一个软件需要多少钱.
- Me - 云风的 BLOG
本文的标题只是一个猜想,并不是我坚信的观点. 事实上,我这几年自觉学到的重要东西之一,就是如何在开发过程中分工,如何信任队友开发的组件,如何组织许多人做同一个项目. 这个世界上我们需要做的软件可能没有太多真正庞大到需要很多人合作才做的出来. 需要配置产品经理,需要设计人员,需要前端开发,后端开发等等.