计算更高效需求管理的投资回报
2005-01-17 13:09
232 查看
Dean Leffingwell
Consultant
2005 年 1 月
有很强有力的证据显示,对于开发人员改善项目成果,以及对我们的目标-- 按照时间和预算交付高质量的软件[/b]--有帮助的方面,需求管理是一个最有效的手段。本文给出了一些实际的证据,表明在有效的需求管理方面的投资可以产生实际的回报。
软件危机依然持续
在1996年6月的Fortune杂志的题为: " The Trouble with Software Is ... It Sucks" 1的文章中,业界评论家Stewart Alsop在他的评论中指责我们的工业界仍然处在软件质量和可靠性低下的状态。在业界多数人正在旁边愤怒的时候,最近由Standish Group,一个著名的市场研究机构,提供的报告中2,给出了甚至更加清醒的看法。按照Standish Group的调查(超过352家公司报告的超过8,000个软件项目),得出了以下结论:
31% 的软件项目在完成之前就被取消($810亿的浪费)。 53% 的项目花费预算的189%。 9% 的项目按照时间和预算完成(大公司)。 16% 的项目按照时间和预算完成(小公司)。
为了更进一步帮助理解问题, Standish Group的调查也询问被调查者项目失败的原因。按照他们的回答,最前面的三个项目失败的原因列在表1中:
表 1: [/b]Standish Group 损害项目的因素[/i]
从表中可以看出,没有能够更有效地与用户一起工作以更好地理解他们的需求,加上在管理需求方面缺乏工程训练,是软件失败的主要的原因。
需求错误的高费用
在GTE, TRW和IBM完成的研究测量和分配了项目生命周期不同阶段发现错误的费用开销 3。这些统计被以后的研究进一步证实 4。尽管这些研究都是独立进行的,他们都得出了基本相同的结论:如果在代码阶段检测和修复一个错误的费用为1个单位,那么在需求阶段发现和修正一个错误的费用只有1/5到1/10。而在维护解阶段的发现和修正一个错误的费用为20单位。图1显示的主要的结果。
![](http://www-900.ibm.com/developerworks/cn/rational/347/0069_fig1.gif)
这么大的差距的原因在于,在产品完成前很多错误不能被检测出来。延迟发现错误意味着:修复错误的费用包括直接修复错误的费用加上修复错误引起的一系列投入的费用。这些投入包括重新设计代码、重新编写文档、使软件重新工作或者重新替换部署的软件。
需求错误和最常见的错误
研究表明需求阶段的错误修复起来代价极其昂贵。如果这类错误不经常发生,则项目总成本就没有那么多。然而在复杂的软件项目中,需求错误确实是发现的错误中最大类别的一种错误。在Sheldon对美国空军项目的研究中 5,错误按照来源进行了分类。这个研究发现需求错误占发现总错误的41%,逻辑设计错误仅仅占总错误数的28%。其它的研究也支持这个结果。例如,Tavolato 和 Vincena, 引用了Tom DeMarco的报告,指出所有Bug的56%可以归结于需求阶段产生的错误 6。
![](http://www-900.ibm.com/developerworks/cn/rational/347/0069_fig2.gif)
需求错误和返工费用
Raytheon, Dion报告返工的费用大约占项目总预算的40% 7。Boehm报告对于大型软件项目返工费用大约占到50%。由于需求错误的数量多,影响大, 发现和修正需求错误的费用占项目总返工费用的70% - 85% 。[/i]
减少需求错误
这里没有能够让你远离需求错误的银弹。然而一些机构给出了下面的能够有效地减少需求错误的技术:
更有效地需求导出 与客户和最终用户回顾需求 更好地组织和文档化需求 可用的需求仓库,促进改善团队通讯 改善报告过程 更好的基于需求的测试和需求的可跟踪性
为了精通上面的这些活动,需要在工具和对关键项目成员培训方面进行必要的投资。
典型项目和返工费用的估计
考虑一个包括50000行代码的应用程序,开发它的职员包括6个开发人员,一个项目经理,两个测试人员,一个质量保证人员。为了确认项目时间,假定编码为关键路径。基于每人月350行调试过的代码的生产力8,项目总时间为24个月。如果每个人员(开发/测试/质量保证)每月的工作费用为$10,000,则可以计算出总的项目预算为大约$240万。 对于这个预算,即使只有30%的返工工作量,总的返工工作费用大约$720,000。如果其中有70%的返工归结于需求错误,则整个有关需求错误的返工工作费用将超过$50万!
表 2: [/b]一个软件项目的项目费用估计[/i]
你的投资
对于没有价值的项目返工应该做什么?很简单,减少需求错误。上面描述的技术都可以有效地降低需求错误。然而,对于任何过程来说,在工具和培训方面的投资对于成功都是必要的。我们假设组织购买Requisite's RequisitePro工具包,并对项目成员进行需求管理理念和工具使用的培训。这些需求培训工作大约需要花费$19,900 [10人 *($995 工具 + $995 培训)]. 这些投资是否值得?
底线
没有人能够准确预期你的组织能够多么有效地减少需求错误。但是,对于不同组织成熟度等级的组织,假设能够减少20%或者更多的需求错误是比较合理的。由于影响的放大,任何这样的减少都能有效地影响表3中列出的项目的底线。
表 3: [/b]更有效的需求管理的投资回报
总结
上面的表3显示,即使在第一个项目中,在需求管理工具和培训上的投资能够获得实际的回报。从那以后,项目组的减少需求错误的能力将在未来的项目中持续获得更多的回报。
但是这些硬性的费用不包括那些与需求错误相关的无形费用[/i]。无形费用包括缺乏能够交付的特性导致项目资源不能专注于返工,部分用户失去信心,以及伴随的失去市场机会、收入和利润。
开始工作吧,这些费用清楚地表明一个公司不能忽略需求管理带来的利益!
参考文献
参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
Consultant
2005 年 1 月
通过降低需求中的错误,软件开发人员可以改善他们的项目成果,按照时间和预算按时交付高质量的软件。本白皮书给出在需求评估过程的管理和通讯方面进行投资的充分的理由。
摘要有很强有力的证据显示,对于开发人员改善项目成果,以及对我们的目标-- 按照时间和预算交付高质量的软件[/b]--有帮助的方面,需求管理是一个最有效的手段。本文给出了一些实际的证据,表明在有效的需求管理方面的投资可以产生实际的回报。
软件危机依然持续
在1996年6月的Fortune杂志的题为: " The Trouble with Software Is ... It Sucks" 1的文章中,业界评论家Stewart Alsop在他的评论中指责我们的工业界仍然处在软件质量和可靠性低下的状态。在业界多数人正在旁边愤怒的时候,最近由Standish Group,一个著名的市场研究机构,提供的报告中2,给出了甚至更加清醒的看法。按照Standish Group的调查(超过352家公司报告的超过8,000个软件项目),得出了以下结论:
31% 的软件项目在完成之前就被取消($810亿的浪费)。 53% 的项目花费预算的189%。 9% 的项目按照时间和预算完成(大公司)。 16% 的项目按照时间和预算完成(小公司)。
为了更进一步帮助理解问题, Standish Group的调查也询问被调查者项目失败的原因。按照他们的回答,最前面的三个项目失败的原因列在表1中:
损害项目的因素 | 回答的百分数 |
1) 缺乏用户输入 | 12.8% |
2) 不完整的需求和规格定义 | 12.3% |
3) 需求和规格定义的变更 | 11.8% |
从表中可以看出,没有能够更有效地与用户一起工作以更好地理解他们的需求,加上在管理需求方面缺乏工程训练,是软件失败的主要的原因。
需求错误的高费用
在GTE, TRW和IBM完成的研究测量和分配了项目生命周期不同阶段发现错误的费用开销 3。这些统计被以后的研究进一步证实 4。尽管这些研究都是独立进行的,他们都得出了基本相同的结论:如果在代码阶段检测和修复一个错误的费用为1个单位,那么在需求阶段发现和修正一个错误的费用只有1/5到1/10。而在维护解阶段的发现和修正一个错误的费用为20单位。图1显示的主要的结果。
![](http://www-900.ibm.com/developerworks/cn/rational/347/0069_fig1.gif)
这么大的差距的原因在于,在产品完成前很多错误不能被检测出来。延迟发现错误意味着:修复错误的费用包括直接修复错误的费用加上修复错误引起的一系列投入的费用。这些投入包括重新设计代码、重新编写文档、使软件重新工作或者重新替换部署的软件。
需求错误和最常见的错误
研究表明需求阶段的错误修复起来代价极其昂贵。如果这类错误不经常发生,则项目总成本就没有那么多。然而在复杂的软件项目中,需求错误确实是发现的错误中最大类别的一种错误。在Sheldon对美国空军项目的研究中 5,错误按照来源进行了分类。这个研究发现需求错误占发现总错误的41%,逻辑设计错误仅仅占总错误数的28%。其它的研究也支持这个结果。例如,Tavolato 和 Vincena, 引用了Tom DeMarco的报告,指出所有Bug的56%可以归结于需求阶段产生的错误 6。
![](http://www-900.ibm.com/developerworks/cn/rational/347/0069_fig2.gif)
需求错误和返工费用
Raytheon, Dion报告返工的费用大约占项目总预算的40% 7。Boehm报告对于大型软件项目返工费用大约占到50%。由于需求错误的数量多,影响大, 发现和修正需求错误的费用占项目总返工费用的70% - 85% 。[/i]
减少需求错误
这里没有能够让你远离需求错误的银弹。然而一些机构给出了下面的能够有效地减少需求错误的技术:
更有效地需求导出 与客户和最终用户回顾需求 更好地组织和文档化需求 可用的需求仓库,促进改善团队通讯 改善报告过程 更好的基于需求的测试和需求的可跟踪性
为了精通上面的这些活动,需要在工具和对关键项目成员培训方面进行必要的投资。
典型项目和返工费用的估计
考虑一个包括50000行代码的应用程序,开发它的职员包括6个开发人员,一个项目经理,两个测试人员,一个质量保证人员。为了确认项目时间,假定编码为关键路径。基于每人月350行调试过的代码的生产力8,项目总时间为24个月。如果每个人员(开发/测试/质量保证)每月的工作费用为$10,000,则可以计算出总的项目预算为大约$240万。 对于这个预算,即使只有30%的返工工作量,总的返工工作费用大约$720,000。如果其中有70%的返工归结于需求错误,则整个有关需求错误的返工工作费用将超过$50万!
典型项目 | 你的项目 | |
代码行 | 50,000 | |
开发人员数 | 6 | |
每人月代码行 | 142.9 | |
上市时间 | 24 日历月 | |
项目成员每月费用 | $10,000 | |
整个项目工作费用 | $2,400,000 | |
全部返工费用 (30%) | $720,000 | |
全部需求错误返工费用(>>70%) | $504,000 |
你的投资
对于没有价值的项目返工应该做什么?很简单,减少需求错误。上面描述的技术都可以有效地降低需求错误。然而,对于任何过程来说,在工具和培训方面的投资对于成功都是必要的。我们假设组织购买Requisite's RequisitePro工具包,并对项目成员进行需求管理理念和工具使用的培训。这些需求培训工作大约需要花费$19,900 [10人 *($995 工具 + $995 培训)]. 这些投资是否值得?
底线
没有人能够准确预期你的组织能够多么有效地减少需求错误。但是,对于不同组织成熟度等级的组织,假设能够减少20%或者更多的需求错误是比较合理的。由于影响的放大,任何这样的减少都能有效地影响表3中列出的项目的底线。
例 1 | 例 2 | 例 3 | 你的项目 | |
需求错误降低百分数 | 10% | 20% | 40% | |
典型项目的节约费用 | $50,400 | $100,800 | $201,600 | |
上市时间节约的月数 | 1.0 | 1.7 | 2.5 | |
投资回收期(月数) | 9.5 | 4.7 | 2.4 | |
第一个项目[/i]生命周期内的投资回报 | 153% | 407% | 913% |
总结
上面的表3显示,即使在第一个项目中,在需求管理工具和培训上的投资能够获得实际的回报。从那以后,项目组的减少需求错误的能力将在未来的项目中持续获得更多的回报。
但是这些硬性的费用不包括那些与需求错误相关的无形费用[/i]。无形费用包括缺乏能够交付的特性导致项目资源不能专注于返工,部分用户失去信心,以及伴随的失去市场机会、收入和利润。
开始工作吧,这些费用清楚地表明一个公司不能忽略需求管理带来的利益!
参考文献
1. | Alsop. S, "The Trouble with Software Is ... It Sucks", Fortune Magazine, June 10, 1996 |
2. | The Standish Group, Chaos Report, 1994 |
3. | Davis, A., "Software Requirements - Objects, Functions and States", Prentice Hall, 1993 |
4. | Boehm, B. and Papaccio, C. "Understanding and Controlling Software Costs", IEEE Transactions of Software Engineering, Oct 1988 |
5. | Sheldon, F. et al, "Reliability Measurement from Theory to Practice", IEEE Software, July 1992 |
6. | Tavolato, P., and K. Vincena. "A Prototyping Methodology and Its Tool." In Approaches to Prototyping, R Budde et al., eds., Berlin: Springer-Verlag, 1984. |
7. | Dion, R. "Process Improvement and the Corporate Balance Sheet," IEEE Software, (July 1993), pp. 28-35 |
8. | Grady, R. "Practical Software Metrics for Project Management and Process Improvement", Prentice-Hall, Inc. 1992 |
关于作者![]() Dean Leffingwell 是Rational负责过程与项目管理的高级副总裁,他主要负责方法论、Rational Unified Process、用户教育与培训、公司需求与变更管理方面的产品以及项目管理训练。他是Managing Software Requirements, A Unified Approach[/i] (Addison Wesley Longman, 1999)的主要作者,在Colorado大学获得工学硕士学位。 |
相关文章推荐
- 计算更高效需求管理的投资回报
- unity 计算投资回报
- 如何从crm投资中获取最大回报
- web标准的投资回报
- 主要IT投资回报评估方法
- OSChina 周五乱弹 —— 小投资高风险大回报
- 佐治亚理工学院 计算投资公开课第五周作业 市场仿真器
- 云投资回报(ROI),通过四个方面来寻求回报
- 五种测量指标 解读出企业SOA投资的整体回报
- 企业采用SaaS服务是IT投资与回报的关键
- CIO该如何衡量企业在SOA上的投资回报?
- VC投资回报“封神榜”:高调曝光中国最会赚钱的VC
- 我的简介---投资1年的时间,回报了1000倍
- 航空公司的CEO表示CIO如果可以在三个月之内实现投资回报就可以得到无限制的预算
- acmore|acmore.cc1017财务应用程序: 计算利息1018财务应用程序:计算未来投资值1019医疗应用程序: 计算BMI1020财务应用程序:复利值
- CIO该如何衡量企业在SOA上的投资回报?
- 陆金所8.4%投资项目真实收益计算
- 乔治理工大学计算投资公开课第五周作业 市场仿真器
- 简单投资组合净值的计算
- 行业细分网站创业投资少、风险低、回报大