模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
文章
如何让项目失败和成本超支率大幅下降
作者 Jim Johnson 译者 罗小平 发布于 2007年9月20日 上午1时57分
有关项目失败率的CHAOS统计数据，经常被敏捷或其他过程改造方法的推崇者引用。因此，这些数据的真实性就非常重要。今年8月，《ACM通讯》（Communications of the ACM，CACM）发表了Robert Glass的一篇文章，影响很大。于是，InfoQ采访了项目失败系列研究报告“CHAOS Chronicles”的创立人Jim Johnson，咱们来听他说说是如何整理出这些数据的。
在采访后的一系列讨论中，有个关键问题仍然没弄明白：对于成本超支率从1994年的189%剧降至1998年的69%，Standish Group是如何解释的？互联网的其他很多地方对这个问题也有提及。Robert Glass文章认为，可能是因为Standish在这几年改变了研究方法，只不过没有在报告中说明。如果真是这样的话，那么比较1994到1998年的CHAOS数据的就毫无意义了。
Standish创始人Jim Johnson对1994到1996年间的研究结果差异也非常重视，甚至1996年的数据从未单独公开。在本文中，他将和大家一起分析CHAOS数据背后隐藏的90年代中期软件开发领域的重大变化。
文章引自CHAOS大学简报2006年11月刊，作者为Standish Group创始人兼现任负责人Jim Johnson。
近来，不少人希望我能解释项目成本超支率从1994年的189%剧降至1998年69%的原因。其实，我们已经在很多场合很多会议上做过说明，比如我最近的文章《CHAOS Chronicles 3.0》和著作《My Life is Failure》。今天再和大家讨论一下，当然，不会有什么新东西。
如果说这种进步是我们的研究报告促使大家努力改进工作而取得的，显然是夸大其词、过于自恋了，我们不会贪天之功。不过，报告首发以后，我们的确发现在我们关注的很多团队和组织中，用户参与度提高、管理层支持加强、大家对业务目标的认识更为清楚，很多公司开始重视其项目经理的PMI认证。所有这些，显然都产生了积极作用，但我们觉得这或许可以让1994年的189%下降到1996年的142%，而说成是上面问题的主要原因，仍然站不住脚。
在本月的调查问卷中，我们要求SURF参与者反映他们对项目时间和成本的评估水平。有不到10%的人认为他们水平已经很高，而几乎三分之二的人仍然认为他们还在起步至中等层次。
项目时间和成本评估能力的高低，对项目的时间和成本超支率有直接影响。1998年春季，我们曾就是否已经改进项目评估问题对很多团队做过调查。结果显示，绝大多数人认为自己到那时为止仍然习惯于先大致评估，然后在考虑不可控因素基础上增加一个误差范围的传统方法。从1998年开始，大多数团队开始修正原来的老办法，以期实现最优评估，这和我们在上图中看到的1994到1998年发展趋势是吻合的。然而我们认为，这仍然不是超支率从189%猛降到69%的主要原因。因此，在你阅读下面段落之前，我希望你能回忆1994到1998年发生过的事情。闭上你的眼睛，遥想在那几年里，我们的IT产业和计算机应用领域究竟发生了什么样的巨大变化。
现在睁开眼睛，你想到了什么？我先提供一个线索！我们1996年的报告显示约有40%的项目失败了。这年的情况是如此混乱，以致于我们没有提供正式的1996年版CHAOS报告。不过，如果找到包含所有年份的CHAOS报告，你将会看到如下结果：
是什么原因导致1996年如此之高的失败率？答案是互联网。我们从传统的C/S转变到互联网开发模式。C/S应用的开发和实施比互联网应用复杂得多，总是莫名其妙出现很多问题，你永远不知道用户的PC上会出现什么样的软件冲突。于是，所有组织迫不及待地将C/S模式像垃圾一样丢掉。互联网应用使项目变得更小、更简单、实施更快、更容易管理。而其中基于浏览器的无客户端模式则是主力军。于是，从1998年开始，我们看到项目失败率稳定下降。仅从这点，我们就能学到很多东西，特别是必须努力让我们的思想进步，学会选择最优的软件开发方法。
其实这里有个测不准的问题
发表人
ozzzzzz liu
发表于
2007年9月24日 上午1时45分
Re: 其实这里有个测不准的问题
发表人
霍 泰稳
发表于
2007年9月25日 上午8时31分
技术对项目成败的影响貌似被夸大了
发表人
jim han
发表于
2007年9月27日 上午8时25分
3 条回复
关注此讨论 回复