软件危机（英語：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) （页面存档备份，存于互联网档案馆）