数学

首页 > 数学

软件危机

2018-12-31 19:06:10     所属分类:软件史

软件危机英语:Software Crisis)是早期计算机科学的一个术语[1],是指在软件开发及维护的过程中所遇到的一系列严重问题,这些问题皆可能导致软件产品的寿命缩短、甚至夭折。[2]软件开发是一项高难度、高风险的活动,由于它的高失败率,故有所谓“软件危机”之说。[3]软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之计算机的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说,它谈到了写出正确、可理解、可验证的计算机程序的困难。

目录

  • 1 历史
  • 2 何谓软件危机
  • 3 实际案例
    • 3.1 IBM OS/360
    • 3.2 美国银行信托软件系统开发案
    • 3.3 其他
  • 4 参见
  • 5 数据源
  • 6 外部链接

历史

1968年,北大西洋公约组织(NATO)在联邦德国的国际学术会议创造软件危机Software crisis)一词。[4][5]而1960年代中期开始爆发众所周知的软件危机,为了解决问题,在1968、1969年连续召开两次著名的NATO会议,并同时提出软件工程的概念。[6]

1972年,艾兹赫尔·戴克斯特拉于计算机协会图灵奖的演讲[7]

软件危机的主要原因,把它很不客气地说:只要没有机器,编程是一点问题也没有;当我们有几台微弱的计算机,编程就成为平和的问题,而现在我们有巨大的计算机,编程已成为一个同样巨大的问题。 — 艾兹赫尔·戴克斯特拉,谦逊的程序员,《Communications of the ACM》[8]

软件危机使人们认识到中大型软件系统与小型软件有着本质性差异:大型软件系统开发周期长、费用昂贵、软件质量难以保证、生产率低,它们的复杂性已远超出人脑能直接控制的程度 ,大型软件系统不能沿袭工作室的开发方式,就像制造小木船的方法不能生产航空母舰一样。[9]它的存在已经有数十年的历史了,一直到了1980年代的面向对象技术才解决了一部分在软件危机上的窘境。[10]

何谓软件危机

软件危机其原因,衔接到硬件的整体复杂度,与软件开发流程。危机表现在几个方面:

  • 项目运行超出预算。
  • 项目运行超过时间。
  • 软件质量低落。
  • 软件通常不匹配需求。
  • 项目无法管理,且代码难以维护。

硬件成长率每年大约30%,软件每年只勉强以4~7%速度在成长,信息系统的交付日期一再延后,许多待开发的软件系统无法如期开始。1960年代软件开发成本占总成本20%以下;1970年代软件成本已达总成本80%以上,软件维护费用在软件成本中高达65%。1986年公布的数据,所有验收的外包软件中,竟然只有4%可用,其余96%却是不堪一用。大部分的企业自行开发的信息系统中,有四分之三也是功败垂成。因此软件维护成本居高不下,软件产品质量低落是最主要的原因。[11]

实际案例

1995年,Standish Group研究机构以美国境内8000个软件项目作为调查样本,调查结果显示,有84%软件计划无法于既定时间、经费中完成,超过30%的项目于运行中被取消,项目预算平均超出189%。[11]

IBM OS/360

OS/360英语OS/360 and successors操作系统被认为是一个典型的案例。到现在为止,它仍然被使用在360系列主机中。这个经历了数十年,极度复杂的软件项目甚至产生了一套不包括在原始设计方案之中的工作系统。OS/360是第一个超大型的软件项目,它使用了1000人左右的程序员。佛瑞德·布鲁克斯在随后他的大作《人月神话》中曾经承认,在他管理这个项目的时候,他犯了一个价值数百万美元的错误。[12]

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

美国银行1982年进入信托商业领域,并规划发展信托软件系统。项目原订预算2千万美元,开发时程9个月,预计于1984年12月31日以前完成,后来至1987年3月都未能完成该系统,期间已投入6千万美元。美国银行最终因为此系统不稳定而不得不放弃,并将340亿美元的信托账户转移出去,并失去了6亿美元的信托生意商机。[11]

其他

  • 1985年-1987年,导致病人死于Therac-25医疗线性加速器的过量辐射。[13]
  • 1996年,亚利安五号原型爆炸。
  • 1998年,波音Delta III火箭爆炸。

参见

  • 软件工程
  • 软件开发
  • 佛瑞德·布鲁克斯
  • 技术奇异点

数据源

  1. ^ World Med MBA Program - Information Systems and Strategy Course. Euromed Marseille School of Management. [2012-05-20] (英语). The earliest computing machines had fixed programs and forced the operator to change their physical layout to alter the program. These computers were not so much "programmed" as "designed". "Reprogramming" was a manual process, starting with flow charts and paper notes, followed by detailed engineering designs, and then you had to re-wire, or even re-structure, the whole machine. 
  2. ^ 洪耀明. 软体工程讲义 - 数位学习平台. 明道大学. [2012-05-22] (中文(*)‎). [永久失效链接]
  3. ^ 郑炳强. 软体工程:从实务出发 (PDF). 智胜文化事业有限公司. [2012-05-24]. ISBN 978-957-729-659-7 (中文(*)‎). 
  4. ^ Report about the NATO Software Engineering Conference dealing with the software crisis
  5. ^ Waterbird. 软体、软体危机、软体工程. http://www.dotspace.idv.tw/. [2012-05-22] (中文(*)‎). 
  6. ^ 陈增荣. 软件开发方法述评. AKA 杂志. [2012-05-22] (中文(大陆)‎). 60年代中期开始爆发了众所周知的软件危机。为了克服这一危机,在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语,并在以后不断发展、完善。与此同时,软件研究人员也在不断探索新的软件开发方法。 [永久失效链接]
  7. ^ E. W. Dijkstra Archive
  8. ^ Dijkstra, E. W. The Humble Programmer. Communications of the ACM. Aug 1972, 15 (10): 859–866. doi:10.1145/355604.361591. 
  9. ^ 物件导向技术概述 (PDF). [2012-05-25] (中文(*)‎). [永久失效链接]
  10. ^ 施保旭. 个体导向软体开发. 资策会. 1994-04-01. ISBN 9789579076784 (中文(*)‎). 
  11. ^ 11.0 11.1 11.2 软体工程概论. [2012-05-24] (中文(*)‎). [永久失效链接]
  12. ^ IBM 360之父--Frederick P. Brooks, Jr.
  13. ^ 软件危机[永久失效链接]

外部链接

  • 不流泪的软体开发. 鼎新计算机 (中文(*)‎). 
  • B. Randell - The NATO Software Engineering Conferences
  • Markus Bautsch: Cycles of Software Crises in: ENISA Quarterly on Secure Software (PDF文件:1.86MB)
  • Edsger Dijkstra: The Humble Programmer (PDF文件:473Kb)

上一篇:打孔卡
相关推荐