软件危机
软件危机（英语：Software Crisis）是早期电脑科学的一个术语[1]，是指在软件开发及维护的过程中所遇到的一系列严重问题，这些问题皆可能导致软件产品的寿命缩短、甚至夭折。[2]软件开发是一项高难度、高风险的活动，由于它的高失败率，故有所谓“软件危机”之说。[3]软件危机的本源是复杂、期望和改变。这个术语用来描述正急遽增加之电脑的力量带来的冲击和可能要处理的问题的复杂性。从本质上来说，它谈到了写出正确、可理解、可验证的计算机程序的困难。
历史
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操作系统被认为是一个典型的案例。到现在为止，它仍然被使用在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火箭爆炸。
参见
资料来源
- ^ World Med MBA Program - Information Systems and Strategy Course. Euromed Marseille School of Management. [2012-05-20]. （原始内容存档于2020-02-04） （英语）.
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.
- ^ 洪耀明. 軟體工程講義 - 數位學習平台. 明道大学. [2012-05-22] （中文（台湾））.[永久失效链接]
- ^ 郑炳强. 軟體工程：從實務出發 (PDF). 智胜文化事业有限公司. [2012-05-24]. ISBN 978-957-729-659-7. （原始内容 (PDF)存档于2013-12-28） （中文（台湾））.
- ^ Report about the NATO Software Engineering Conference dealing with the software crisis. [2012-05-24]. （原始内容存档于2013-07-16）.
- ^ Waterbird. 軟體、軟體危機、軟體工程. http://www.dotspace.idv.tw/. [2012-05-22]. （原始内容存档于2006-01-10） （中文（台湾））.
- ^ 陈增荣. 软件开发方法述评. AKA 杂志. [2012-05-22]. （原始内容存档于2007-08-06） （中文（中国大陆））.
60年代中期开始爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。
- ^ E. W. Dijkstra Archive. [2012-05-24]. （原始内容存档于2020-05-13）.
- ^ Dijkstra, E. W. The Humble Programmer. Communications of the ACM. Aug 1972, 15 (10): 859–866 [2012-05-24]. doi:10.1145/355604.361591. （原始内容存档于2021-04-21）.
- ^ 物件導向技術概述 (PDF). [2012-05-25] （中文（台湾））.[永久失效链接]
- ^ 施保旭. 個體導向軟體開發. 资策会. 1994-04-01. ISBN 9789579076784. （原始内容存档于2016-03-04） （中文（台湾））.
- ^ 11.0 11.1 11.2 軟體工程概論. [2012-05-24] （中文（台湾））.[永久失效链接]
- ^ IBM 360之父--Frederick P. Brooks, Jr.. [2012-05-29]. （原始内容存档于2016-03-04）.
- ^ 软件危机[永久失效链接]
外部链接
- 不流淚的軟體開發. 鼎新电脑. （原始内容存档于2016-03-04） （中文（台湾））.
- 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) （页面存档备份，存于互联网档案馆）