大型软件开发失败案例(大型软件开发失败案例分享)

软件开发 28
本篇文章给大家谈谈大型软件开发失败案例,以及大型软件开发失败案例分享对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 1、项目管理怎么做 2、

本篇文章给大家谈谈大型软件开发失败案例,以及大型软件开发失败案例分享对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

项目管理怎么做

一个项目从其一成立开始,项目各方干系人都会期望项目能够根据既定的计划一步步顺利地导向最后的成功。影响项目的最后成功的因素是多方面的,包括项目管理的九大知识领域(包括项目的整体管理、范围管理、时间管理、费用管理、质量管理、人力管理、沟通管理、风险管理和采购管理),无一对项目的最后成功不产生积极影响。然而,要这九大知识领域对项目成功产生的影响的轻重程度上进行比较的话,我认为其中项目范围管理是最为重要的。

什么是项目范围管理

那么,什么是项目范围和项目范围管理呢?项目范围是指产生项目产品所包括的所以工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识,也要在如何生产这些产品方面达成一定的共识。

项目范围管理是指对项目包括什么与不包括什么的定义与控制过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。

项目范围与项目其它约束条件的相互影响

制约一个项目的条件是项目“三约束条件”——范围、时间、成本。在一个项目中这三个条件是相互影响、相互制约的,而且往往是由于范围影响了时间和成本。项目一开始确定的范围小,那么它需要完成的时间以及耗费的成本必然也小,反之亦然。很多项目在开始时都会粗略地确定项目的范围、时间以及成本,然而在项目进行到一定阶段之后往往会变成让人感觉到不知道项目什么时候才能真正结束,要使得项目结束到底还需要投入多少人力和物力,整个项目就好象一个无底洞,对项目的最后结束谁的心里也没有底。这种情况的出现对于公司的高层来说,他们是最不希望看到的,然而这样的情况出现并不罕见。造成这样的结果就是由于没有控制和管理好项目的范围。可见项目的三约束中最主要还是范围的影响最主要。

范围管理案例

失败案例:我了解到这样的实际案例,这是一个软件开发的项目,整个项目已经进行了两年多之后项目何时结实还是处于不明确的状态,因为用户不断有新的需求出来,项目组也就要根据用户的新需求不断去开发新的功能。这个项目实际是一个无底洞,没完没了地往下做,项目成员“肥的拖瘦,瘦的拖死”,实在做不下去只能跑了。大家对这样的项目已经完全丧失了信心。

这个项目其实就是一开始没有很明确地界定整个项目的范围,在范围没有明确界定的情况下,又没有一套完善的变更控制管理流程,任由用户怎么说,就怎么做,也就是说一开始游戏规则没有定好,从而导致整个项目成了一个烂摊子。

成功案例:同样是一个软件开发的项目,这个项目也比上面案例讲到的项目要小一些,这时候公司已经开始实施CMM对软件开发活动进行管理,有相对完善的软件开发管理过程。项目在一开始就先明确用户需求,而且需求基本上都是量化的、可检验的。而且项目组在公司CMM的变更管理过程的框架指导下制定了项目的范围变更控制管理过程,在项目的实施过程中,用户的需求变更都是按照事先制定好的过程执行。因此,这个项目完成的比较成功,项目的时间和成本基本上是在一开始项目计划的完成时间及成本的情况下略有增加。

造成范围界定不清的原因

既然项目范围界定不清是一种很常见的现象,而这种现象又是大家所不想见到的。那么,我们必须分析出现这种现象的原因。我认为造成这种现象的出现有以下三方面的原因:

首先,是企业一级的责任——没有完善的项目管理体系来指导项目的管理。这种情况是最糟糕的,如果是这种原因,那么项目的成败往往需要靠项目经理个人的管理、领导能力。这种情况项目成功的可能性非常小,大部分项目都是以失败而告终;

第二,是企业及项目组共同的责任——对项目没能制定出清晰规范的范围变更控制过程。企业有管理体系,但不够完善和规范,对项目组的变更过程的制定没能起到有效的指导作用。变更是不可避免的,只要有效地加以管理、控制,同样可以达到各方满意的结果;

第三,是对范围的定义不够明确,做不到可量化、可验证程度。很多时候都是一些定性的要求、而不是定量的,例如“界面友好,可操作性强,提高用户满意度”等。类似这些模糊的需求就是导致后续项目扯皮的根源。项目范围的明确定义,有经验的项目经理及系统分析员将起到至关重要的作用。

由以上的论述,我们可以得出结论:完善的项目范围管理是整个项目最终成败的关键。那么,怎样才能做好项目范围管理呢?下面大量篇幅将对这一问题进行详细的论述。

如何管理好项目范围

既然已经认识到项目范围管理如此重要,那么我们应该怎样才能管理好项目的范围呢?从上面的论证过程,我们清楚地看到造成项目范围不好管理的一些原因,那么要管理好项目范围就必须对症下药,才能管理好项目范围。

首先,我们必须先了解项目范围管理的一些科学过程。做好项目管理应该包含下面过程:启动、范围计划、范围定义、范围核实及范围变更控制。下面将详述如何做好这些过程:

启动过程

启动是指组织正式开始一个项目或继续到项目的下一个阶段。启动过程的一个输出就是项目章程。项目章程是一个重要的文档,这个文件正式承认项目的存在并对项目提供一个概览。

启动过程明确指定这一过程有一个重要的输出文档——项目章程,项目章程将粗略地规定项目的范围,这也是项目范围管理后续工作的重要依据。项目章程中还将规定项目经理的权利以及项目组中各成员的职责,还有项目其他干系人的职责,这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确的规定,以致后续工作可以更加有序地进行。因此,千万不能忽略项目的启动过程。

范围计划过程

范围计划是指进一步形成各种文档,为将来项目决策提供基础,这些文档中包括用以衡量一个项目或项目阶段是否已经顺利完成的标准等。作为范围计划过程的输出,项目组要制定一个范围说明书和范围管理计划。古语云:“预则立,不预则废!”。一个项目经理要想真正管理好项目范围,没有必要的技术和好的方法是肯定不行的。

要做好一个项目首先强调的就是周密地做好范围计划编制。范围计划编制是将产生项目产品所需进行的项目工作(项目范围)渐进明细和归档的过程。做范围计划编制工作是需要参考很多信息的,比如产品描述,首先要清楚最终产品的定义才能规划要做的工作,项目章程也是非常主要的依据,通常它对项目范围已经有了粗线条的约定,范围计划在此基础上进一步深入和细化。

前面讲到这个过程有一个输出是范围说明书,那么范围说明指的是什么呢?范围说明是在项目参与人之间确认或建立了一个项目范围的共识,作为未来项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。项目论证是商家的既定目标,要为估算未来的得失提供基础;项目产品是产品说明的简要概况;项目可交付成果一般要列一个子产品级别概括表,如:为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、人机交互学习程序等。任何没有明确要求的结果,都意味着它在项目可交付成果之外;项目目标是要考虑到项目的成功性,至少要包括成本、进度表和质量检测。项目目标应该有标志(如:成本、单位)和绝对的或相对的价值。尽量避开不可量化的目标(如:“客户的满意程度”),因为它将让你的项目承担很高的风险。

范围计划又是什么呢?范围管理计划是描述项目范围如何进行管理,项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估(比如:怎样变化、变化频率如何及变化了多少)。范围管理计划也应该包括对变化范围怎样确定,变化应归为哪一类(当产品特征仍在被详细描述的时候,做到这点特别困难,但绝对必要)等问题的清楚描述。

范围定义过程

范围定义是指将项目主要的可交付成果细分成较小的、更易管理的组分。这个过程中,项目组要建立一个工作分解结构(WBS)。WBS的建立对项目来说意义非常重大,它使得原来看起来非常笼统、非常模糊的项目目标一下子清晰下来,使得项目管理有依据,项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时,变更就不可避免地出现,很可能造成返工、延长工期、降低团队士气等一系列不利的后果。

制定好一个WBS的指导思想是逐层深入。先将项目成果框架确定下来,然后每层下面再把工作分解,这种方式的优点是结合进度划分直观,时间感强,评审中容易发现遗漏或多出的部分,也更容易被大多数人理解。

范围核实过程

范围核实是指对项目范围的正式认定,项目主要干系人,如项目客户和项目发起人等要在这个过程中正式接受项目可交付成果的定义。

这个过程是范围确定之后,执行实施之前各方相关人员的承诺问题。一旦承诺则表明你已经接受该事实,那么你就必须根据你的承诺去实现它。这也是确保项目范围能得到很好的管理和控制的有效措施。

范围变更控制过程

范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行动与教训总结。

再好的计划也不可能做到一成不变,因此变更是不要避免的,关键问题是如何对变更如何进行有效的控制。控制好变更必须有一套规范的变更管理过程,在发生变更时遵循规范的变更程序来管理变更。通常对发生的变更,需要识别是否在既定的项目范围之内。如果是在项目范围之内,那么就需要评估变更所造成的影响,以及如何应对的措施,受影响的各方都应该清楚明了自己所受的影响;如果变更是在项目范围之外,那么就需要商务人员与用户方进行谈判,看是否增加费用,还是放弃变更。

因此,项目所在的组织(企业)必须在其项目管理体系中制定一套严格、高效、实用的变更程序。

执行好以上项目范围管理的五个过程,我认为对项目范围的管理、控制将是行之有效的!

楼主不知道有没有考项目管理PMP资格认证,那个证书对项目管理有很大作用的,含金量高,如果要做项目还是要去学习一下加实践一下的,光是理论也不行,边学边考证书能节约成本,现在大型企业外企招人有个PMP证书还是吃香的,有什么不懂的或者像问的加我QQ:1650874687 很高兴能帮助您,说了这么说,给分哦,嘿嘿,谢谢啦

急求!!!因开发时测试不足就上市运用后造成很大损失的软件案例有哪些,比如千年虫啥的

你好!以下的案例给你参考一下,看能不能用上吧:

微软Office漏洞造成损失 2.8万中文网遭袭

近日,微软向全球用户紧急发布最新安全通告,承认Office组件存在一个严重安全漏洞,并已遭到黑客的攻击。

据悉,此次微软承认Office漏洞是继7月7日以来,一周内连续两次发布紧急通告。360安全中心专家石晓虹博士表示,微软这一举动非常罕见,说明网络安全形势已非常严峻。“Office内存破坏”的漏洞从11日被曝光以来,已导致1600多万人次遭到“挂马”攻击,而一周前开始爆发的微软MPEG-2视频漏洞攻击目前仍在持续爆发中。

根据360安全中心统计,目前这两大微软高危漏洞已导致近7000万人次遭攻击,超过2.8万家网站被先后“挂马”。根据中国互联网中心今年第一季度统计数据,目前全球中文网站数为287万。这意味着,由于微软两大0Day漏洞,国内被“挂马”的网站数已接近总数的1%。

目前微软在安全方面承载着巨大的压力,一方面是漏洞频出;另一方面是修补速度较慢。之前的视频漏洞大约用了8天时间才提供补丁。在这期间全靠金山毒霸、360安全卫士等国产安全软件提供紧急安全解决方案。已经有中国的安全软件厂商呼吁微软能够在发现漏洞时及时更正以避免更多的网民受到黑客攻击。

你好!另一案例:

利用电信系统漏洞拨打境外声讯电话套取返利 徐州电信损失4600万

核心提示:3月30日,江苏省徐州市中级人民法院对张胜利、高鼎等13名被告人利用电信公司系统漏洞,冒用他人身份证办理小灵通电话,拨打境外国际声讯电话套取返利,造成电信公司经济损失4600多万元的特大诈骗案作出一审判决,以诈骗罪判处被告人张胜利、高鼎无期徒刑,没收个人全部财产,其他11名被告人分别被判处有期徒刑7至15年不等,并处罚金。

张胜利、高鼎等13名被告人除一人是60年代出生的,其余12人均为80后。分别来自安徽、河南、湖南、湖北、江西、新疆6省,其中有一对父子、一对兄弟。经查明:2008年9月份,上述被告人在互联网的QQ聊天中听说徐州地区的小灵通可以呼叫转移到国际声讯台,通过拨打小灵通电话可以套取话费提成的“赚钱”方法后,先后来到徐州。自2008年11月至自2009年1月间,上述被告人利用徐州电信公司的系统漏洞,交叉结伙,采取冒用他人身份办理小灵通卡,设置呼叫转移至境外国际声讯台号码,然后让他人在互联网上使用拨号软件群呼或自己使用移动电话重复拨打的手段,诈骗话费以非法获取国外声讯台返利,给徐州电信公司造成经济损失共计人民币46615404.50元。

历史上著名的软件危机事件

1.IBMOS/360

IBMOS/360操作系统被认为是一个典型的案例。到现在为止,它仍然被使用在360系列主机中。这个经历了数十年,极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。OS/360是第一个超大型的软件项目,它使用了1000人左右的程序员。

佛瑞德·布鲁克斯在随后他的大作《人月神话》中曾经承认,在他管理这个项目的时候,他犯了一个价值数百万美元的错误。

2.美国银行信托软件系统开发案

美国银行1982年进入信托商业领域,并规划发展信托软件系统。项目原订预算2千万美元,开发时程9个月,预计于1984年12月31日以前完成,后来至1987年3月都未能完成该系统,期间已投入6千万美元。

美国银行最终因为此系统不稳定而不得不放弃,并将340亿美元的信托账户转移出去,并失去了6亿美元的信托生意商机。

扩展资料:

软件危机表现在以下四个方面:

(1)经费预算经常突破,完成时间一再拖延。由于缺乏软件开发的经验和软件开发数据的积累,使得开发工作的计划很难制定。

主观盲目制定计划,执行起来与实际情况有很大差距,使得开发经费一再突破。由于对工作量估计不足,对开发难度估计不足,进度计划无法按时完成,开发时间一再拖延。

(2)开发的软件不能满足用户要求。开发初期对用户的要求了解不够明确,未能得到明确的表达。开发工作开始后,软件人员和用户又未能及时交换意见,使得一些问题不能及时解决,导致开发的软件不能满足用户的要求,因而导致开发失败。

(3)开发的软件可维护性差。开发过程中没有同意的、公认的规范,软件开发人员按各自的风格工作,各行其是,开发过程无完整、规范的文档,发现问题后进行杂乱无章的修改。程序结构不好,运行时发现错误也很难修改,导致维护性差。

(4)开发的软件可靠性差。由于在开发过程中,没有确保软件质量的体系和措施,在软件测试时,又没有严格的、充分的、完全的测试,提交给用户的软件质量差,在运行中暴露出大量的问题。

参考资料来源:百度百科-软件危机

关于大型软件开发失败案例和大型软件开发失败案例分享的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

扫码二维码