软件工程成功失败案例借鉴

软件工程_成功案例

1．卡拉OK点播系统

项目名称：卡拉OK点播系统；

项目功能：适合酒吧，歌厅等小型的场所使用的小型局域网卡拉OK点播系统；

项目成功经验：

1.目标明确

该项目目标明确是该项目成功的一个关键因素。一开始，在与客户方面经过友好地沟通，使得项目目标清晰定义，即在小型的局域网中使用的卡拉OK点播系统。基于明确目标定义，为以后的开发工作，包括需求分析，计划制定，人员任务分配等等都给予了极大的方便。很明显，在一个项目开始时，明确好整个项目的目标是很重要而且是必要的。

2.开发人员经验丰富

很明显，开发人员的开发经验丰富与否，决定着整个项目的进度，质量，甚至成功与否。在该项目中，几个开发人员开发经验丰富，都有过一到两年的开发经验，其中两个甚至有开发过类似的项目的经验。后来的事实也证明，正是由于开发人员的丰富经验，极大地促进了整个项目的进度，以及质量。

3.文档的完备

在我国，软件工程危机的一个很大的原因在于，没有形成及时保存文档的习惯。往往，一个项目结束了，可是文档就那么几份，甚至连最基本的需求分析，计划大纲都不清楚。在进行该项目的过程中，项目经理充分注意了这个问题。明确要求，小组开发人员在完成完一天的工作，一个任务单元时必须完成文档的总结。有了这些文档，为项目后期的测试工作起了很大的作用。

2．远程医疗保健系统

项目名称：远程医疗保健系统。

项目功能：实现医疗服务的远程实现。

项目成功经验：

1.小组分工明确

这个项目的人员不是很多，只有四个，如何充分利用有限的项目小组人员是很重要的。该项目中，项目经理对小组的开发人员进行了明确的分工，在项目开发的一系列环节中都进行了人员的安排，例如，需求的定义，计划的制定，代码的编写，功能的测试，客户的联系等。完备的而又明确的小组分工，有利于项目的顺利运行。

2.充分调动开发人员的积极性

该项目正是调用了开发人员的积极性，充分激发了开发人员的开发热情，发挥了开发人员的以往经验，从而使得项目在开发人员不是很多的情况下，保质保量地完成了整个项目的开发工作。

3.项目经理管理得当（财务，人事，风险,时间）

项目经理是一个项目的灵魂。其能力的强弱，经验的丰富与否直接影响到了项目的开发。该项目中，项目经理是一个有着丰富的IT管理经验的人员。在财务的管理，人事的计划，时间的安排等方面的良好，是该项目成功的一个很重要的因素。

3．城域网综合资源管理系统

项目名称：城域网综合资源管理系统。

项目功能：有效的管理网络资源，包括歌曲，电影，课件，新闻，提高网络资源的利用率。项目成功经验：

1.需求分析清晰

需求定义，是整个软件工程的基本前提。没有一个良好的，明确的，清晰的项目需求，开发工作的缺陷是显而易见的。为此，公司在需求定义方面花了大气力。专门派了一个人员与客户经常保持联系。使得客户的一件能够很及时地反映到软件设计中。整是

由于这样，使得该项目在客户鉴定时很容易就通过了，完全减少了后期的需求变动的麻烦。

2.与客户保持沟通

很明显，需求是很重要的。如果需求不明确，或者需求经常变动，会影响项目的开发工作。而需求的明确与否，又与跟客户的沟通密切相关。与客户及时有效的沟通，有利于客户及时的理解，建议，修改项目的功能和质量，也减少了到了项目开发后期，由于需求的变动，从而导致项目失败的危险性。该项目中，项目经理花了很大的时间与客户保持联系，了解客户需求，这对项目的益处是显而易见的。

3.跟踪项目

为什么要跟踪项目？有没有这个必要性？是不是一种时间的浪费？这个项目的成功充分地说明了这个问题。答案是肯定的。有必要进行项目的跟踪。这个项目开发人员有限，开发资金也不是很充足，而且加上开发周期短，技术难度大等因素使得这个项目的开发难度极大。但是，由于以前公司开开发过类似项目，同时与以外项目的客户又有经常的沟通，及时帮助客户进行项目维护。这些都为理解该项目的功能背景，技术背景，专业背景具备了良好的环境。可以说，该项目的成功实施，是离不开前期对以外类似项目的跟踪的。

软件工程_失败案例

1．数据语音网络系统

项目名称：数据语音网络系统

项目功能：满足家庭用户和集团用户的语音业务及宽带数据业务的需求

项目失败教训：

A．领导不力

由于领导的不力，导致了小组在坚持计划和个人约束方面出问题。虽然有能力的领导是对领导角色的基本的要求，但是，能力是多方面的，包括知识框架，社交技巧，

领导技巧，沟通技巧，风险估计等等都是对领导的要求。领导的能力直接决定了整个项目的整体质量。

B．时间无限制拖延

时间上的无限制拖延也是该项目失败的原因之一。原本两个月的开发计划，结果由于开发小组的效率低下，导致了整个项目时间上的无限制拖延。

C．质量低下

软件质量的低下，无疑也是项目失败的关键原因。由于软件质量的低下，导致了项目测试阶段的工作量的复杂，最终导致了项目开发的失败。

2．邮政资信管理系统

项目名称：邮政资信管理系统。

项目功能：管理邮政方面业务的监督和管理，提高邮政的服务效率。

项目失败教训：

A．需求内容不明确，把握不充分

这是我们经常遇到的问题。一方面，由于客户（需求方）IT知识缺乏，一开始自己也不知道要开发什么样的系统，或者懒于系统地整理出来，经常是走一步算一步，不断地提出和更改需求，使得实现方叫苦连天。另一方面，实现方由于行业知识的缺乏和设计人员水平的低下，不能完全理解客户的需求说明，而又没有加以严格的确认，经常是以想当然的方法进行系统设计，结果是推倒重来。因此，需求分析必须注重双方理解和认识的一致，逐项逐条地进行确认。

B．工数估算过少

软件开发的工数估算是一项很重要的工作，必须综合开发的阶段、人员的生产率、工作的复杂程度、历史经验等因素，将一些定性的内容定量化。对工数的重要性认识不足，经常用拍脑袋的方式草算，是最常见的问题。还有，软件开发经常会出现一些平时不可见的工作量，如人员的培训时间、各个开发阶段的评审时间等，经验不足的项目经理经

常会遗漏。同时，还有如下一些原因也是很典型的：

（1）出于客户和公司上层的压力在工数估算上予以妥协。例如，客户威胁要用工数更少的开发商，公司因经营困难必须削减费用、缩短工期，最后只能妥协，寄希望于员工加班。

（2）设计者过于自信或出于自尊心问题，对一些技术问题不够重视，或者担心估算多被嘲笑。

（3）过分凭经验。由于有过去的成功经验，没有具体分析就认为这次项目估计也差不多，而没有想到这次项目可能规模更大、项目组成员更多、素质各异、新员工很多，而且是一个新的行业。

C．项目组织过小

每个公司都希望以最少的成本完成项目，人手不足是大多数项目都会面临的问题。还有一种情况是项目组成员的技术水平达不到项目的要求，公司只能提供这些分配好的技术人员，或者由于项目经理的失误，在项目工数估算时没有明确要求技术水平，寄希望于员工自己努力。还有一些项目经理认为，在项目启动时不需要高水平的技术人员。

开发计划不充分

没有良好的开发计划和开发目标，项目的成功就无从谈起。开发计划太粗略，主要反映在以下几个方面：

（1）工作分担（责任范围）不明确，工作分割结构（WBS）与项目组织结构不明确或者不相对应，各成员之间的接口不明确，导致有一些工作根本无人负责。

（2）每个开发阶段的提交结果定义不明确，中间结果是否已经完成，完成了多少模糊不清，结果是到了项目后期堆积了大量工作。

（3）开发计划没有指定里程碑或检查点，也没有规定设计评审期。

（4）开发计划没有规定进度管理方法和职责，导致无法正常进行进度管理。

3．企业客户资料管理系统

项目名称：企业客户资料管理系统。

项目功能：负责企业自身的客户的资料的管理，分析，提取，提出实用方案。

项目失败教训：

A．设计能力不足

项目组设计人员能力的低下是项目失败的原因之一。一方面，由于对技术问题的难度未能正确评价，将设计任务交给了与要求水平不相称的人员，造成设计结果无法实现。另一方面，随着资源外包现象的日益普遍，一些公司经常因工期紧而匆忙将中标的项目部分转包给其他协作公司，这些公司的设计能力如不加仔细评价，就会对整个项目造成影响。

B．项目经理的管理能力不足

没有及时把握进度。项目经理自己也不知道项目的状态，下属人员报喜不报忧，害怕报告问题后给自己添麻烦。进度管理必须随时收集有关项目管理的数据，开发人员总是担心管理工作会增加自己的工作量，不愿配合。管理人员甚至不知道应该收集哪些数据。

由于没有进行定期的项目评审报告会，表面上进展顺利而实际上隐藏着危机。管理人员总是轻信下属的报告而没有加以核实。

出现严重问题时，管理人员没有根据现阶段状况重新评价需求分析结果、工数估算、设计结果等就匆忙采取头痛医头、脚痛医脚的措施，致使问题更严重。

4．电子印花分色系统

项目名称：电子印花分色系统。

项目功能：该系统集计算机、激光、电子等高科技技术于一体，支持高速、高质量图像生成与编辑和印花工艺处理，是一套稳定性高、功能完备、易于扩充、操作快速简便的已达到国际先进水平的开放式电子印花分色系统，是国内唯一集样稿扫描，花样设计与编辑，云纹处理，连晒输出等多功能于一体的具有自主版权的集成化系统

项目失败教训：

A．开发商和客户的关系

本来开发商和客户之间是软件产品的提供者和使用者之间的关系,一个卖东西,一个买东西,两者之间的关系是平等的,公平交易,童叟无欺,这才是两者之间的正常合理的关系,可是现在呢?

现在开发商和用户之间的关系是严重不平等的,开发商为了得到订单,往往委屈求全,放弃自己应该坚持的原则,在竞标时相互压价,甚至采用某些不够光明正大的手段来得到订单,自己把自己放到了一个被动的地位.许多开发商都有这样的口号"以客户为中心",他们不仅是这样说的,而且也是这样做的,问题是,一种不平等的关系,能够长期坚持下去吗?我从网上看到说,某个项目竞标,某开发商提供的标书有一大箱子,需要两个人才能抬到会场上.请问,这种标书有谁会看呢?难道开发商连这点起码的常识都没有了吗?既然没有人看,那么为什么要写呢?难道开发商真的以为客户会傻到不知道你在欺骗他吗?那么写这种标书欺骗的是谁呢?恐怕是自己欺骗自己吧!

开发商怕得罪客户,却没有认识到有时和客户冲突是不可避免的,客户怕开发商来欺骗自己,于是一次一次进行试探,开发商越让步,客户越认为自己受到了欺骗.开发商的让步往往换不来客户的信任,而是换来了客户的更加不信任.由于开发商自己不相信自己,自己欺骗自己,最后也无法得到客户的信任.

毕竟软件开发是由开发商来完成的,那么就应该也必须由开发商来决定项目的进展和内容,可是现在却往往由于客户的压力而妥协,放弃自己的原则,这样来做软件开发,能成功吗?失败是必然的,成功才是侥幸.

结论就是,在软件开发中,应当以开发商为中心,而不是以客户为中心,客户的意见只是

参考和借鉴,而不是金科玉律,不应该害怕和客户发生冲突,而应该分析冲突产生的原因,把冲突看成问题的征兆,而不是单纯来消除冲突本身.

B．销售人员和技术人员之间的关系

一个人担任的角色不同,他考虑问题自然会更多考虑到自己的切身利益,至于这样做可能会给同事带来的麻烦,就管不了那么多了.在开发商内部,销售人员和技术人员之间的关系也非常奇特.在许多公司,为了提高销售人员的工作积极性,对销售人员采用提成的方式进行奖励,而将底薪定得很低,这样一来,销售人员为了拿到项目的订单,往往会屈从于客户的压力,许下许多难以兑现的诺言,或者由于对于技术的不了解而随意答应客户的要求.等到合同签订完毕,进入项目开发阶段时,客户会拿这些诺言来要求开发人员进行兑现,结果是开发人员非常被动,对销售人员怨气冲天,于是告诉客户这些要求无法满足,而客户也勃然大怒,你们这些人怎么一拿到钱就变了脸了呢?问题就是,由于销售人员不考虑技术人员将来的实现,从而许下了过高的诺言,这样做的结果也许可以拿到订单,可是由于销售人员和技术人员的口径不一样,最后客户无所适从,感到自己受到了欺骗,接着将一腔怒火发到了技术人员头上,两者之间的合作和信任关系逐渐变成了对抗和欺骗的关系.

销售人员和技术人员应该是一个自行车的两个轮子,他们的关系必须是相互合作,相互支持的,而不应该是互相拆台,相互对抗的,一旦他们之间相互对抗,那么就会给整个公司的声誉带来灾难性的后果.

C．项目管理者和开发人员之间的关系

项目管理者和开发人员之间的关系,本来应该是相互团结,相互帮助,共同面对问题的关系,可是许多项目管理者把这种关系扭曲成了管理与被管理的强制性关系,用种种规章制度,种种管理方法来强迫开发人员接受,把自己放到了开发人员的对立面,和开发人员离心离德,甚至还美其名曰"量化管理,科学管理".在这种糟糕的管理下,开发人员没有任何办法,要么被动接受糟糕的管理,要么辞职以抗议.一旦一个项目发生了这种情况,

它想成功就非常难了.

这种问题原来并不明显,现在随着各种MBA,印度经验,软件工厂等似是而非的理论的泛滥,许多人,尤其是许多根本不懂软件开发的管理者,更加变本加历,用近乎苛刻的手段来加强对开发人员的管理,提出种种令人发笑的量化指标来对开发人员进行度量,还加上理论的依据,对于敢于反抗他们这种做法的开发人员,一律以开除来解决问题,造成的一个非常荒诞的现实就是,许多公司里宁愿使用刚刚毕业没有任何经验的学生,不要有工作经验的工程师,美其名曰:易于管理,哈,容易上当受骗而已.请问,在这种管理者和开发人员之间的关系作用下,软件项目有可能获得成功吗?

项目管理者和开发人员并没有本质的区别,他们只是所处的岗位不同,担任的责任不同而已,在软件开发的问题上,尤其在具体的技术细节上,往往管理者不甚精通,如果他不能吸纳开发人员的智慧,而是自己一个人拍脑袋来做决策,那么失败就在眼前了.