軟件危機
軟件危機（英語：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) （頁面存檔備份，存於互聯網檔案館）