导致软件项目成败的因素分析.doc

导致软件项目成败的因素分析.doc

《导致软件项目成败的因素分析.doc》由会员分享，可在线阅读，更多相关《导致软件项目成败的因素分析.doc（10页珍藏版）》请在冰点文库上搜索。

《软件需求分析报告的对比报告---导致软件项目成败的因素分析》计算机软件学院叶科良2008150098

《软件需求分析报告的对比报告---导致软件项目成败的因素分析》

目录

目录 1

结论一：

软件项目的成功率竟然如此的低 1

结论四：

项目成败的因素 6

总结 9

我想很多人跟我一样，在没有对软件项目的成败有个比较全面的认识之前，脑海里的软件项目根本没有失败这个概念，更加不可能知道导致软件项目失败的因素。

而自己接触的项目与那些具有一定规模的软件项目来比根本不算什么，即便是有过那么几次项目成功的经验，也不知道自己为何完成了项目任务。

可以说，了解导致软件项目成败的因素至关重要。

美国专门从事跟踪IT项目成功或失败的权威机构StandishGroup在它每年的CHAOSReport报告中给出了IT项目相关调查数据结果。

而今天我们将对它的1994年版、1999年版和2003版本的CHAOSReport进行对比分析。

结论一：

软件项目的成功率竟然如此的低

1994、1999、2003年软件项目成功失败率图表

1994

1999

2003

成功项目

16.2

26

34

质疑项目

52.7

46

51

损伤项目

31.1

28

15

从StandishGroup的1994、1999、2003关于软件项目的成功失败率的统计数据，真的可以让我们大吓一跳，直至2003年，软件项目的成功率竟然连百分之五十都达不到，即便是已经完成的了项目也不一定算得上是成功，受质疑项目竟然占如此之多的比率。

可见，关于软件项目的开发还是有一定学问的。

其1994年的报告还举了个例子，作为传统工程-建筑工程，其项目成功率远比软件工程的高。

同属于工程科学，除了前者发展时间长，积累方法经验多之外，这里面到底还存在着什么神秘的地方让软件工程项目的成功率上不去的呢？

请看后面分析。

结论二：

软件项目的成功率有上升趋势，损伤率有下降趋势

1994、1999、2003年软件项目成功失败率图表

1994

1999

2003

成功项目

16.2

26

34

质疑项目

52.7

46

51

损伤项目

31.1

28

15

从这个趋势图我们对软件项目的开发找回了一些信心，在1994至2003年之间，软件项目的成功率有上升趋势，而失败率有下降趋势。

不过，其上升的程度及下降的程序并不尽如人意，反映其中必定存在某些关键制约因素限制了软件项目的发展。

再者，受质疑项目比率仍然处于50％左右，这更让人百思不得其解。

结论三：

项目重新开始竟如此多，成本超支、进度落后、不能交付所有功能成三孪生兄弟

在3个版本的报告中，以1994年的报告数据为例，如下：

软件项目中重新开始的数据

成本超支

进度落后

内容不足

有100个软件项目中，在项目开始后竟然有94个项目需要重新开始，重新开始意味着什么？

相信不用什么知识背景都会知道：

开发成本上升、进度拖延、开发士气可能低落等等。

而在看项目成本超支、进度落后，内容不足这三项简直让人沮丧，如果照这个比率来开发软件项目，其即便是“成功”开发出产品，也可能要饱受质疑。

这里的质疑可能来自多方面的，可能是软件产品过时了已经不适合市场，或者客户因对本项目投资过大从而不满而让公司名义有损，或者说实现的内容跟当初与客户协商的不尽一致导致验收困难重重，等等。

这些都是软件项目开发中可怕的后果，其出现率竟如此的高，真的不得不让人反省研究过中学问。

好了，竟然看到软件项目开发中如此多让人不满的地方，也该是时候看看过中缘由，看看到底是什么导致了失败的项目了，又看看什么是导致软件项目成功的因素。

结论四：

项目成败的因素

1994版项目成功的因素

1999版项目成功的因素

1994版项目受质疑的因素

1994项目损伤因素

可以发现，虽然上面没有将1999和2003的图标全部列出，但是可以说的是，软件工程经过了尽10年的发展，影响其成功的因素主要都是：

用户参与、管理层支持、清晰明确的软件需求、合理的计划、现实的期望。

而导致软件项目失败的因素主要是：

缺少用户参与、不完整的需求及规格、需求规格的变更、缺乏管理层的支持和不现实的期望。

其实这里很值得去思考。

为何这些项目失败的原因跟成功的原因都位于项目开发的中期甚至乎是前期？

软件需求与对项目的期望、计划都是软件项目开发前期主要的工作，其实，需求在变这似乎是一个真理，而这种变动与前期跟客户协商的定位好了的期望能不能掌控在一个限度之内？

也就是说，假如前期跟客户协商好了项目要开发什么，并且协商好了不开发什么，这样对于客户期望的变动能否实现一定的限制呢？

而就像建房子挖一个地基似的，前期说好了建多少层是客户说了算，而作为开发人员则有确定挖多深的地基的权利，开发人员必定会量力而为，即便是与客户达成协议也会给自己一个余地。

而这个余地，对于应付日后客户的需求变动能否有一定的作用。

或者说，对于应对市场的变动能否留有余力？

就像任何工程一样，软件项目工程也是一个人与人之间的工程，而实现工程就是实现人脑海中的想法，假如作为客户都不能清晰地表达自己想要什么，或者说开发人员不能正确引导客户说出他心中的想要的东西而产生误解，到了最后交付的时候客户发现“货不对版”，这岂不是会让这个项目受到质疑？

所以说，管理层与客户的沟通，开发人员与用户的沟通是很需要的，这会让一个项目能够得到及时的纠正以避免最后的失败。

而合适的更小的历程碑我认为是在开发过程中的一个很好的工具。

结论五：

成功的项目必定具有成功的潜力

成功潜力得分表

在94年的报告中有几个很有意思的例子，如上图。

分别是：

DMV:

加利福利亚机动车管理部门的大项目，目的是改善其驾驶执照及登记的应用程序。

可惜，到1993年，其历史6年，花费4500万美元，终究被中止。

CONFIRM:

汽车租赁及客房预定系统，是美国航空公司于1994年中止的一个项目。

花费了1.65亿美元最后还是被叫停了。

Hyatt:

Hyatt酒店预订系统，其与CONFIRM处于同一时段，却取得的最后的成功。

ITAMARATI：

巴西私营银行BANCO成功开发的系统，使其短时间内从巴西银行排名第46位上升至15位，赢利增长51%。

上述例子的详细经过暂且不谈，到底这些成功与失败的例子给了我们什么启示？

根据上面的成功潜力得分表，可以直接地说DMV项目注定失败，其只有10的成功潜力得分就是根据，因为它并没有什么成功性可言。

而CONFIRM的29分虽然比DMV稍微多了些，但也是一个低分，如果当时他们的项目拍板人看到这个图表，相信也不会有这个项目的存在。

而取得100分的HYATT系统也正如报告中所说，“这个预订系统进度超前，低于预算，实现比预算更多的功能，仅仅花费1500万美元，拥有了几乎所有的成功因素”。

而这里所说的成功因素，就是用户参与、管理层支持、清晰明确的需求、适当的规划以及更小的里程碑。

所以，它成功了，而且很漂亮。

至于得分85的ITAMARATI不如HYATT，不过也具有很大程度上的成功潜力，其成功就是一个证明。

总结

软件项目的成败有其必然性，无论成败都与这几个因素相关：

用户参与、管理层支持、清晰明确的需求、适当的规划以及更小的里程碑，软件开发毕竟是异于传统工程，而其需要的与传统工程在本质上并无多大差别。

而且差别就在软件开发没有像传统工程那样雄厚的基础，而我们要做的就是把握住前人成功的路线，在这个基础上做好才有资格去求变。

其如此低的成功率也让我们不能有丝毫的放松，必须严谨对待方可有成功的希望。

10