2012年最可怕的软件项目事故汇总

数十亿美元就这样打了水漂——今年多个软件项目遭遇失利,此类事故已经引起管理者的高度重视。

诚然,很多企业在软件项目的推进过程中获得了成功,也将供应商所承诺的新特性与新功能顺利传递给终端用户:更低的运营成本、更简洁的管理流程以及各类足以取悦消费者的要素。

但遗憾的是,仍然有一些项目以失败告终;投入巨资的客户只能面对“断瓦残垣”而欲哭无泪,并被卷入危害事业进展、有损合作关系的漫长诉讼当中。

而从积极的角度来看,我们能够将这些过往的事故当作前车之鉴,无论是供应商还是项目客户都能够从中吸取经验教训。下面就请大家一同关注2012年最可怕的软件项目事故汇总。

耗资十亿美元,美国空军一怒之下叫停ERP项目

今年十一月,有报告称美国空军决定放弃名为“远程作战保障系统”(简称ECSS)的主要ERP(企业资源规划)软件项目,因为空军管理者发现在投入高达十亿美元的建设资金后,该项目并未带来“任何显著的军事能力提升”。

早在2005年就已诞生的ECSS项目计划更换超过两百套遗留系统,但这套以甲骨文软件为基础的方案在成本方面发生了无法扼制的恶性膨胀。美国空军官员与系统承包商CSC引入了大量计划之外的附加定制编码工程与集成任务,这一步步将项目推向了灭亡的边缘。

一位空军军方发言人指出,该项目需要再投入十一亿美元才能完成既定目标的四分之一,而且即使一切顺利,项目也无法在2020年之前整体竣工。

监督机构的调查报告显示,美国军方所着力打造的军事ERP项目遭到彻头彻尾的失败

美国政府问责办公室(简称GAO)于今年三月发布的报告宣称,许多由军方发起的ERP项目不仅在进度上落后于计划,更是严重超出财政预算。

其中典型的例子要数海军陆战队搞出来的“全球作战支持系统”,其实际耗资几乎为初期预算的十倍,本该于2009年11月就正式完成。而根据问责办公室的统计,其最终开销达到十一亿美元,远超过当初定下的1.26亿美元。

海军发起的另一个ERP项目始于2003年,计划于2011财年之内完成。然而由于各种原因,项目最终将于2013年8月竣工,实际开发成本也由最初的十九亿美元增长到二十七亿美元。

“这样的情况令我们难以接受,也许政府应该把那帮一拍脑门也做决策、把几十亿美元投入垃圾项目的家伙们踢出门去,”咨询企业Asuret公司CEO兼分析师Michael Krigsman在采访中表示,他同时也是一位杰出的IT项目管理专家。

“最大的问题在于,这类失败是怎么发生的?”Krigsman补充道。“控制机制何在?为什么这样的状况屡屡出现,却没人站出来加以阻止?政府的IT部门是不是已经掌握不了局势了?”

时间: 2024-11-17 05:36:24

2012年最可怕的软件项目事故汇总的相关文章

软件项目“免坑”指南

"谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日."这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的.就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去. 一.坑有多深? 当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑.造坑的项目,往往具有某些"臭味",以下是我的一些认识,这些"臭味"即是项目健康状态不佳的明显标志: ● 编码规范形同废纸,代码质量低下.每个项目都有编码规范,但真正严格

《Microsoft.NET企业级应用架构设计(第2版)》——2.2 软件项目的机制

2.2 软件项目的机制 如果你问:"什么导致项目失败?",你得到的最常见的回答可能会把失败归咎到与业务有关的问题,比如说,缺少需求,项目管理不到位,成本估算不正确,缺少沟通,甚至各个团队的人员相互不配合.你很难看到坏代码可能导致问题这种情况. 有鉴于此,我们认为未被发现的BBM可以严重损害软件项目,但未能处理的BBM却可以真的毁了它. 最终,个体以及个体之间的实际互动才能真的决定软件项目的成功或失败.但是,组织结构及其整体文化也会影响最终结果. 2.2.1 组织文化 Apple公司的组

软件项目,什么叫坑爹!大家注意了

"谁也无法改变现状,唯有无数程序员血洒大地,才能使项目重建天日."这一点也不夸张,软件项目做烂了就是个坑,参与者也不过是填坑的.就像是在魔兽世界战场遇到国家队一样,你赢也赢不了,出也出不去. 一 坑有多深? 当我们进入一个项目时,通过不断观察我们可以发现我们的项目到底是不是一个坑.造坑的项目,往往具有某些"臭味",以下是我的一些认识,这些"臭味"即是项目健康状态不佳的明显标志: ◆  编码规范形同废纸,代码质量低下 每个项目都有编码规范,但真正严

小型软件项目开发流程探讨

一.导言 国内很多项目都是小型项目,参与人员少(两到五个人),要快速交付(一两个月) . 要成功完成这种项目,除了使用成熟且被团队成员熟练使用的技术之外,有一个良好的开发流程,也是很必要的. 二.小型软件项目开发流程 下图是我对小型软件项目开发流程的一个设想: 需求分析的重要性想必大家都应该清楚,对于项目来说,满足用户的需求是第一位的. 因为时间紧,系统设计经常被忽略. 这会留下很大的隐患,国内很多项目的需求通常是很简略的,还需要在系统设计阶段把一些需求进一步的明确. 不然会出现因为前期一些需求

CMM可重复级在特殊软件项目中的应用

引言 由 SEI 在 1991 年 8 月发布的软件能力成熟度模型( SW-CMM ),用来评估软件企业的 成熟度级别,使软件企业了解自己的优势和不足之处,从而持续地改进企业的软件开发过程,提高管理水 平,降低管理成本,保证软件开发效率和软件质量. 然而, CMM 是针对大型项目和企业制定的. 小项目和中小企业由于受到相应条件的限制,如组织结构.角色和关系.过程模式定义等,生搬硬套 CMM 框架只能给自己带来沉重的负担.可取的做法是把 CMM 作为一个参考,从 CMM 评估体系中汲取适合于自 身

使用IBM RTC管理软件项目工程中的日常开发任务

IBM Rational Team Concert(RTC)作为软件协同开发工具,被逐渐应用在大型项目的生产过程中,维系着规模庞大的项目组织团队,有条不紊地管理每一项开发任务,从而为创造高质量的软件产品打下坚实基础. RTC 提供了贯穿整个http://www.aliyun.com/zixun/aggregation/17799.html">开发过程的集成环境,包括:需求定义.迭代计划.源码控制.自动构建.缺陷跟踪.变更管理以及统计报表等功能.本文将通过三个层次,自下而上地详细阐述如何使用

《Python数据挖掘:概念、方法与实践》一2.3 项目—发现软件项目标签中的关联规则

2.3 项目-发现软件项目标签中的关联规则 1997年,Freshmeat网站创立,它是一个跟踪免费.自由和开放源码软件(FLOSS)项目的目录.2011年,该网站更名为Freecode.在出售.并购和多次网站重新设计之后,2014年,Freecode网站的所有更新都停止了.这个网站仍然在线,但是不再更新,目录中也不再加入任何新项目.现在,Freecode是20世纪90年代和21世纪初FLOSS项目相关信息的快照.每个软件项目的相关事实包括名称.描述.下载软件的URL.描述其特征的标签.代表其流

关于软件项目后期Fix bug的意义之我见

众所周知:基本上所有的软件项目到后期必不可少的是fix bug,一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题.现在有一些成熟的bug跟踪系统,譬如:bugzero,bugzilla, redmine等等. 解bug是很头痛的问题,一般是以下原因引起的: (1)设计上的缺陷: (2)写代码时考虑不周全: (3)测试人员无中生有: (4)所依赖的插件,框架本身的缺陷. 第一种情况:最棘手,需要修改程序架构,费时又费力,但是不改又不行总不能要客户该需求,按照你的程序来吧.没办

去年一个百万级的小软件项目经验分享,20来个功能模块,项目不太好做有些棘手

转自http://www.cnblogs.com/jirigala/archive/2010/04/10/1709223.html  别人总觉得是在显吧,干脆把这个项目认为是小项目了,不知道把这个项目是小了,别人会不会又觉得又显吧了?说大也不行.说小也不行,也的确没招了.   我想主要把项目里遇到的问题分享给大家一起探讨,也并不是为了什么显吧什么的,希望大家用一个正确的心态阅读此文章,希望有更多的朋友把更大软件项目的经验分享给大家,让大家知道一下,大型软件项目里都会遇到什么问题,如何解决才好,我