软件项目失控的案例.ppt

软件项目失控的案例东华大学 周力 什么是软件失控项目 软件失控项目就是由于在创建系统所需软件时遇到困难，从而导致大大超出可控制范围的项目。 KPMG的定义是： 软件失控项目是显著未能实现目标和 超出原定预算30％的项目[KPMG 1995]。 “软件危机”(software crisis) 软件总是超出预算、落后于进度表，而且不可靠。 根据GAO (Government Accounting Office，美国政府审计局)的研究、最著名的统计数字是有98％以上的项目都失败了(“只有不到2％的合同订购软件在发布时具有可用件”)。 “软件危机”的观点对吗？ 看看四周，我们看到的是一个计算机软件不可或缺的世界。计算机和软件处理我的机票预订，控制我的银行事务，把人类送到太空——其可靠性毋庸置疑。 为什么有那么多的人在叫喊着软件危机呢? 因为这样做有利可图。某些经销商叫喊危机是为了卖出他们声称能够提供对策的产品或者服务；某些研究者叫喊危机是为了获得他们所称同样（最终）将提供对策的研究项目的经费；某些学术界人士叫喊危机是为广促使人们接受并阅读他们提出对策的专业论文。 对危机的叫喊，某种程度上表现了“恶人先告状”的心理；软件项目门未能达到费用和进度表的目标，经常是因为这些目标本身就是错误的；这样软件从业人员辛辛苦苦地工作，其实是去实现不现实的目标，尽管实现目标希望渺茫，还是要反复耗费大量时间去迎合目标，最终由于从项目开始便无法控制的问题而受到谴责； 对软件估算做出的实际调研表明，最为常见的是由营销人员或者客户来制定费用目标和进度表，其次是由管理人员制定，很少有实际完成项目的技术人员涉足其中：由于无法掌握自己的命运，在出现问题时这些实践者们总是受到指责。 计算机领域的研究通常都专注于理论而不注重于实践。也就是说，计算机研究人员对于开发新算法、新数据表达或者新的体系方法很感兴趣，但是他们很少对可以从最佳实践中形成的经验或者从最差实践中获取的教训感兴趣。 这是计算机研究领域的很重要的失败。大家都知道在其他领域中有时候是实践指导(比理论更高级)理论的，而计算机理论家们并没有很好地利用这一点。 所以[KPMG1995]报告的作者有得天独厚的机会展示时隔六年之久的观察结果： 可预测的发现是： (1)许多失控的项目都是(或曾是)“野心过大”的项目。在业内大家都知道大型项目更客易出问题。 (2)很多项目失败的原因是多方面的。可能有主要原因，也可能没有，但是多数失控的项目都出现了问题。 (3)管理问题比技术性问题更多地成为主要原因。但是请看(4)中令人吃惊的发现。 (4)进度超时(89％)比成本超额(62％)更普遍。 意外的发现是： (1)被调查者认为在政府和金融部门中应该有更多的失控项目，而服务业和制造业中较少。但是调查结果显示，所有的部门都同样难逃其患： (2)被调查者对于失控的趋势很乐观，42％的人认为失控项目的数量将会降低，只有8％的人认为数量会增长。 (3)使用打包软件对于减少失控项目的发生没有什么帮助。在研究的失控项目中，47％是由混合的定制软件项目和打包软件项目组成，24％是定制软件项目，而22％是打包软件项目。 (4)失控项目在项目生命期的早期就显示了它们的真实面目。超过50％的项目在系统开发过程中显示出问题症状，而25％的项目在初始的计划阶段就显示出了问题的症状。 (5)除了上面提到的，首先意识到项目失控的是项目团队(72％)只有19％的项目失控是由高级管理层首先意识到的。 (6)技术越来越成为项目失控的原因．颇具戏剧性。“企业采用新技术“是项目失控的第四个最普遍的原因。请参见下面有关趋势的讨论。 (7)风险管理在软件管理文献中出现得越来越频繁：但是55％的失控项目没有实行过任何风险管理．而在38％实行了风险管理(有些被调查者不知道是否实行了风险管理)的项目中，有50％的项目在启动之后没有使用风险发现(risk finding)。 对趋势的发现是： 企业在1995年比在1989年讨论失控项目时更为勉强。新的研究中的被调查者只有前一次的50％，虽然调查人数(大约250个主要组织)大致相同。 技术越来越成为项目失控的原因，且势头发展迅猛。在1989年只有7％的企业将其作为原因进行报告，而在1995年这个数字是45％(有意思的是，只有16％的被调查者认为技术不适合该项目)，[KPMG 1995的结论是“技术的发展比开发者的技巧进展得更快。] 但是从我们研究的项目中可以明显看出：第一，新技术同样经常成为问题的起因；第二，项目失败的原因常常是使用的技术不成熟或者不合适。 我们的结论是：常常是技术本身(尤其是它们缺少可扩展性或者缺少扩展这些技术的追踪记录)导致了项目失控．而不是技术人员导致项目