軟體危機

軟體危機是指落後的軟體生產方式無法滿足迅速增長的計算機軟體需求，從而導致軟體開發與維護過程中出現一系列嚴重問題的現象。

基本介紹

• 中文名：軟體危機
• 外文名：software crisis

含義

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

產生背景

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

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

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

主要表現

軟體開發進度難以預測

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

軟體開發成本難以控制

投資一再追加，令人難於置信。往往是實際成本比預算成本高出一個數量級。

而為了趕進度和節約成本所採取的一些權宜之計又往往損害了軟體產品的質量，從而不可避免地會引起用戶的不滿。

用戶對產品功能難以滿足

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

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

軟體產品質量無法保證

系統中的錯誤難以消除。軟體是邏輯產品，質量問題很難以統一的標準度量，因而造成質量控制困難。

軟體產品並不是沒有錯誤，而是盲目檢測很難發現錯誤，而隱藏下來的錯誤往往是造成重大事故的隱患。

軟體產品難以維護

軟體產品本質上是開發人員的代碼化的邏輯思維活動，他人難以替代。除非是開發者本人，否則很難及時檢測、排除系統故障。

為使系統適應新的硬體環境，或根據用戶的需要在原系統中增加一些新的功能，又有可能增加系統中的錯誤。

軟體缺少適當的文檔資料

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

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

原因分析

用戶需求不明確

在軟體開發過程中，用戶需求不明確問題主要體現在四個方面：

在軟體開發出來之前，用戶自己也不清楚軟體開發的具體需求；

用戶對軟體開發需求的描述不精確，可能有遺漏、有二義性、甚至有錯誤；

在軟體開發過程中，用戶還提出修改軟體開發功能、界面、支撐環境等方面的要求；

軟體開發人員對用戶需求的理解與用戶本來願望有差異。

缺乏正確的理論指導

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

軟體開發規模越來越大

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

軟體開發複雜度越來越高

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

解決途徑

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

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

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

危機實例

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

IBMOS/360

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

美國銀行信託軟體系統開發案

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