軟件危機

軟件危機泛指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。 ^[1] 

軟件危機（software crisis），20 世紀60年代以前，計算機剛剛投入實際使用，軟件設計往往只是為了一個特定的應用而在指定的計算機上設計和編制，採用密切依賴於計算機的機器代碼或彙編語言，軟件的規模比較小，文檔資料通常也不存在，很少使用系統化的開發方法，設計軟件往往等同於編制程序，基本上是個人設計、個人使用、個人操作、自給自足的私人化的軟件生產方式。

60年代中期，大容量、高速度計算機的出現，使計算機的應用範圍迅速擴大，軟件開發急劇增長。高級語言開始出現；操作系統的發展引起了計算機應用方式的變化；大量數據處理導致第一代數據庫管理系統的誕生。軟件系統的規模越來越大，複雜程度越來越高，軟件可靠性問題也越來越突出。原來的個人設計、個人使用的方式不再能滿足要求，迫切需要改變軟件生產方式，提高軟件生產率，軟件危機開始爆發 。

1968年，北大西洋公約組織（NATO）在聯邦德國的國際學術會議創造軟件危機（Software crisis）一詞。而1960年代中期開始爆發眾所周知的軟件危機，為了解決問題，在1968、1969年連續召開兩次著名的NATO會議，並同時提出軟件工程的概念。 ^[2] 

拖延工期幾個月甚至幾年的現象並不罕見，這種現象降低了軟件開發組織的信譽。

投資一再追加，令人難於置信。往往是實際成本比預算成本高出一個數量級。而為了趕進度和節約成本所採取的一些權宜之計又往往損害了軟件產品的質量，從而不可避免地會引起用户的不滿。

開發人員和用户之間很難溝通、矛盾很難統一。往往是軟件開發人員不能真正瞭解用户的需求，而用户又不瞭解計算機求解問題的模式和能力，雙方無法用共同熟悉的語言進行交流和描述。

在雙方互不充分了解的情況下，就倉促上陣設計系統、匆忙着手編寫程序，這種"閉門造車"的開發方式必然導致最終的產品不符合用户的實際需要。

系統中的錯誤難以消除。軟件是邏輯產品，質量問題很難以統一的標準度量，因而造成質量控制困難。軟件產品並不是沒有錯誤，而是盲目檢測很難發現錯誤，而隱藏下來的錯誤往往是造成重大事故的隱患。

軟件產品本質上是開發人員的代碼化的邏輯思維活動，他人難以替代。除非是開發者本人，否則很難及時檢測、排除系統故障。為使系統適應新的硬件環境，或根據用户的需要在原系統中增加一些新的功能，又有可能增加系統中的錯誤。

文檔資料是軟件必不可少的重要組成部分。實際上，軟件的文檔資料是開發組織和用户的之間權利和義務的合同書，是系統管理者、總體設計者向開發人員下達的任務書，是系統維護人員的技術指導手冊，是用户的操作説明書。

缺乏必要的文檔資料或者文檔資料不合格，將給軟件開發和維護帶來許多嚴重的困難和問題。 ^[3] 

在軟件開發過程中，用户需求不明確問題主要體現在四個方面：在軟件開發出來之前，用户自己也不清楚軟件開發的具體需求；用户對軟件開發需求的描述不精確，可能有遺漏、有二義性、甚至有錯誤；在軟件開發過程中，用户還提出修改軟件開發功能、界面、支撐環境等方面的要求；軟件開發人員對用户需求的理解與用户本來願望有差異。

缺乏有力的方法學和工具方面的支持。由於軟件開發不同於大多數其他工業產品，其開發過程是複雜的邏輯思維過程，其產品極大程度地依賴於開發人員高度的智力投入。由於過分地依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件開發產品的個性化，也是發生軟件開發危機的一個重要原因。

隨着軟件開發應用範圍的增廣，軟件開發規模愈來愈大。大型軟件開發項目需要組織一定的人力共同完成，而多數管理人員缺乏開發大型軟件開發系統的經驗，而多數軟件開發人員又缺乏管理方面的經驗。各類人員的信息交流不及時、不準確、有時還會產生誤解。軟件開發項目開發人員不能有效地、獨立自主地處理大型軟件開發的全部關係和各個分支，因此容易產生疏漏和錯誤。

軟件開發不僅僅是在規模上快速地發展擴大，而且其複雜性也急劇地增加。軟件開發產品的特殊性和人類智力的侷限性，導致人們無力處理“複雜問題”。所謂“複雜問題”的概念是相對的，一旦人們採用先進的組織形式、開發方法和工具提高了軟件開發效率和能力，新的、更大的、更復雜的問題又擺在人們的面前。 ^[1] 

軟件工程誕生於60年代末期，它作為一個新興的工程學科，主要研究軟件生產的客觀規律性，建立與系統化軟件生產有關的概念、原則、方法、技術和工具，指導和支持軟件系統的生產活動，以期達到降低軟件生產成本 、改進軟件產品質量、提高軟件生產率水平的目標。軟件工程學從硬件工程和其他人類工程中吸收了許多成功的經驗，明確提出了軟件生命週期的模型，發展了許多軟件開發與維護階段適用的技術和方法，並應用於軟件工程實踐，取得良好的效果。

在軟件開發過程中人們開始研製和使用軟件工具，用以輔助進行軟件項目管理與技術生產，人們還將軟件生命週期各階段使用的軟件工具有機地集合成為一個整體，形成能夠連續支持軟件開發與維護全過程的集成化軟件支援環境，以期從管理和技術兩方面解決軟件危機問題。

此外，人工智能與軟件工程的結合成為80年代末期活躍的研究領域。基於程序變換、自動生成和可重用軟件等軟件新技術研究也已取得一定的進展，把程序設計自動化的進程向前推進一步。在軟件工程理論的指導下，發達國家已經建立起較為完備的軟件工業化生產體系，形成了強大的軟件生產能力 。軟件標準化與可重用性得到了工業界的高度重視，在避免重用勞動，緩解軟件危機方面起到了重要作用。 ^[1] 

1995年，Standish Group研究機構以美國境內8000個軟件項目作為調查樣本，調查結果顯示，有84%軟件計劃無法於既定時間、經費中完成，超過30%的項目於運行中被取消，項目預算平均超出189%。

IBMOS/360操作系統被認為是一個典型的案例。到現在為止，它仍然被使用在360系列主機中。這個經歷了數十年，極度複雜的軟件項目甚至產生了一套不包括在原始設計方案之中的工作系統。OS/360是第一個超大型的軟件項目，它使用了1000人左右的程序員。佛瑞德·布魯克斯在隨後他的大作《人月神話》中曾經承認，在他管理這個項目的時候，他犯了一個價值數百萬美元的錯誤。

美國銀行1982年進入信託商業領域，並規劃發展信託軟件系統。項目原訂預算2千萬美元，開發時程9個月，預計於1984年12月31日以前完成，後來至1987年3月都未能完成該系統，期間已投入6千萬美元。美國銀行最終因為此係統不穩定而不得不放棄，並將340億美元的信託賬户轉移出去，並失去了6億美元的信託生意商機。