维基百科

软件危机

软件危机（英语：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

参见：System/360

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

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

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

其他

参见

资料来源

  1. ^ 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. 
  2. ^ 洪耀明. 軟體工程講義 - 數位學習平台. 明道大学. [2012-05-22] （中文（台湾））. [永久失效链接]
  3. ^ 郑炳强. 軟體工程：從實務出發 (PDF). 智胜文化事业有限公司. [2012-05-24]. ISBN 978-957-729-659-7. （原始内容 (PDF)存档于2013-12-28） （中文（台湾））. 
  4. ^ Report about the NATO Software Engineering Conference dealing with the software crisis. [2012-05-24]. （原始内容存档于2013-07-16）. 
  5. ^ Waterbird. 軟體、軟體危機、軟體工程. http://www.dotspace.idv.tw/. [2012-05-22]. （原始内容存档于2006-01-10） （中文（台湾））. 
  6. ^ 陈增荣. 软件开发方法述评. AKA 杂志. [2012-05-22]. （原始内容存档于2007-08-06） （中文（中国大陆））. 60年代中期开始爆发了众所周知的软件危机。为了克服这一危机，在1968、1969年连续召开的两次著名的NATO会议上提出了软件工程这一术语，并在以后不断发展、完善。与此同时，软件研究人员也在不断探索新的软件开发方法。 
  7. ^ E. W. Dijkstra Archive. [2012-05-24]. （原始内容存档于2020-05-13）. 
  8. ^ 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）. 
  9. ^ 物件導向技術概述 (PDF). [2012-05-25] （中文（台湾））. [永久失效链接]
  10. ^ 施保旭. 個體導向軟體開發. 资策会. 1994-04-01. ISBN 9789579076784. （原始内容存档于2016-03-04） （中文（台湾））. 
  11. ^ 11.0 11.1 11.2 軟體工程概論. [2012-05-24] （中文（台湾））. [永久失效链接]
  12. ^ IBM 360之父--Frederick P. Brooks, Jr.. [2012-05-29]. （原始内容存档于2016-03-04）. 
  13. ^ 软件危机[永久失效链接]

外部链接

检索自“https://zh.wikipedia.org/w/index.php?title=软件危机&oldid=79265412”