危机管理-软件危机与软件工程课件.pptVIP

软件危机与软件工程 软件危机 0美元支票 一位主管收到了一张由计算机开出的0美元的账单，在嘲笑了“愚蠢的计算机”后他将账单丢进了垃圾桶，一个月后，又一张账单寄来了，还标志着30天的逾期，这样的情形持续了4个月，最后还带来了一封信，警告如果再不付账的话，将会采取法律行动，由于担心自己的信用度，这个主管在一个软件工程师的建议下，寄出了一张0美元的支票，最后一张0美元的收据送到了，该主管小心翼翼地将这张不同寻常的收据保存起来以备将来查询。 软件危机（续） 有错误的爱国者导弹 1991年海湾战争中，一枚飞毛腿导弹穿过了爱国者反导弹的防御，击中了沙特阿拉伯的Dhahran附件的一个兵营，造成28名美国人死亡，98人受伤。这个错误是由累积的定时错误引起的，爱国者导弹每次只能工作几小时，超过这个时间后，系统时钟就会复位。可悲的是新的软件第二天才运到。 软件危机（续） 美国国内税收处20世纪年代让Sperry公司建立一套联邦税收表格自动处理系统，该系统被证明不适合当前的工作量，花费几乎是预算的2倍，到1996年，共花费了40亿美元，但情况并没改善。原因是“没有充分计划就错误行事”。 软件危机的表现 超出预算时间和成本 研究表明，每8个新的大型软件中就有2个会被取消，软件开发时间平均超出计划的50%，而软件开发中的主要成本是人力资源成本，进度的落后意味着成本的增加 用户对生产出的软件不满意 开发人员往往不注重或不善于和客户交流，找出客户真正需要的东西，匆忙地进行开发，在开地过程中又不能从客户那里得到反馈信息，最后生产出的软件和客户想要的相差很远，难免出现纠纷。 软件危机的表现（续） 软件有残存的错误 研究表明，所有的大型系统中，大约有3/4的系统有运行问题，要么不是像预料的工作，就是根本不能使用 软件产品不可维护 不能改正错误 在原有模块上不能增加新的功能 不能增加新的模块 软件危机的表现（续） 文档资料不完整 软件文档是交流平台，管理工具，必须和软件同步更新 软件生产率的提高跟不上硬件的发展速度 摩尔定律：每隔 18 个月计算机硬件的运算速度提高一倍,价格下降一半 软件：手工开发为主 软件危机的表现（续） 软件成本在计算机系统总成本中的比例不断提高 而软件 维护的成 本占软 件的成 本也越 来越高 引起软件危机的原因 软件开发无计划性 没有经过仔细考虑就匆忙开发,出现问题才想办法补救,不能保证软件开发进度和预算,不能保证软件质量，在进度落后时，盲目增加人手，结果适得其反 引起软件危机的原因（续） 软件需求不充分 没有将问题搞清楚就匆忙上马，在开发过程中又不能和客户有效地沟通，许多问题在交付软件时才集中地爆发出来，这时候已经是大势已去，难以挽回了（和数值计算软件和平时学习语言编写的程序不同，在实际的软件开发中,首先应该满足的是客户的需要，开发软件不是为了展示个人的技巧。 ） 引起软件危机的原因（续） 软件开发过程无规范 开发过程没有统一的方法和规范 不重视文档 各开发人员之间的接口没有统一规划 引起软件危机的原因（续） 软件产品无评测手段 个人提交产品时没有进行测试 模块之间接口没有测试 整个系统没有进行整体测试 忽略压力及性能测试 软件危机解决之道:软件工程 1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(software crisis)这个名词。 1968年秋季，北约的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念 用工程化的理念、方法进行软件开发 软件工程的定义 软件工程[IEE93] 将系统的、规范的、可度量的方法应用于软件的开发、运行和维护的过程； 上述方法的研究 软件工程基本原理 B.W.Boehm提出 7条原理，互相独立，最小集合 其他软件工程原理在此基础上组合、蕴含、派生 软件工程基本原理-1 用分阶段的生命周期计划严格管理 不成功的软件中有一半左右是由于计划不同造成的 应该将软件生命周期划分成若干个阶段，并相应制定出切实可行的计划，并按计划对软件的开发和维护进行管理 六类计划：项目概要计划，里程碑计划，项目控制计划，产品控制计划，验证计划，运行维护计划 软件工程基本原理-2 坚持进行阶段评审 统计表明，大部分错误是在编码之前造成的 错误发现与改正越晚，所需付出的代价也越高（见下页） 坚持阶段评审，可以避免错误的“水波效应” 各阶段改正错误的相对花费 软件工程基本原理-3 实行严格的产品控制 尽量避免修改需求 修改需求必须在