軟件危機（Software Crisis）是指由于落后的軟件生產方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一系列嚴重問題的現象。
軟件危機是早期計算機科學的一個術語，由北大西洋公約組織于1968年在德國的國際學術會議上提出的。
軟件危機包含兩個方面的問題即如何開發軟件，以滿足人們對軟件日益增的需求；如何維護數量不斷膨脹的已有軟件。
軟件危機概況
20 世紀 60??年代以前，計算機剛剛投入實際使用，軟件設計往往只是為了一個特定的應用而在指定的計算機上設計和編制，采用密切依賴于計算機的機器代碼或匯編語言，軟件的規模比較小，文檔資料通常也不存在，很少使用系統化的開發方法，設計軟件往往等同于編制程序，基本上是個人設計、個人使用、個人操作、自給自足的私人化的軟件生產方式。60年代中期，大容量、高速度計算機的出現，使計算機的應用范圍迅速擴大，軟件開發量急劇增長。高級語言開始出現；操作系統的發展引起了計算機應用方式的變化；大量數據處理導致第一代數據庫管理系統的誕生。軟件系統的規模越來越大，復雜程度越來越高，軟件可靠性問題也越來越突出。原來的個人設計、個人使用的方式不再能滿足要求，迫切需要改變軟件生產方式，提高軟件生產率，軟件危機開始爆發。1968 年北大西洋公約 組織 的計算機 科學家在德國召開國際會議，第一次討論軟件危機問題，并正式提出“軟件工程”一詞，從此一門新興的工程學科——軟件工程學——為研究和克服軟件危機應運而生。
軟件危機現象
早期出現的軟件危機主要表現在：① 軟件開發費用和進度失控。費用超支、進度拖延的情況屢屢發生。有時為了趕進度或壓成本不得不采取一些權宜之計，這樣又往往嚴重損害了軟件產品的質量。②軟件的可靠性差。盡管耗費了大量的人力物力，而系統的正確性卻越來越難以保證，出錯率大大增加，由于軟件錯誤而造成的損失十分驚人。③生產出來的軟件難以維護。很多程序缺乏相應的文檔資料，程序中的錯誤難以定位，難以改正，有時改正了已有的錯誤又引入新的錯誤。隨著軟件的社會擁有量越來越大，維護占用了大量人力、物力和財力。進入80年代以來，盡管軟件工程研究與實踐取得了可喜的成就，軟件技術水平有了長足的進展，但是軟件生產水平依然遠遠落后于硬件生產水平的發展速度。軟件危機不僅沒有消失，還有加劇之勢。主要表現在：①軟件成本在計算機系統總成本中所占的比例居高不下，且逐年上升。由于微電子學技術的進步和硬件生產自動化程度不斷提高，硬件成本逐年下降，性能和產量迅速提高。然而軟件開發需要大量人力，軟件成本隨著軟件規模和數量的劇增而持續上升。從美、日兩國的統計數字表明，1985年度軟件成本大約占總成本的90％。②軟件開發生產率提高的速度遠遠跟不上計算機應用迅速普及深入的需要，軟件產品供不應求的狀況使得人類不能充分利用現代計算機硬件所能提供的巨大潛力。
原因??軟件工程研究結果表明，軟件危機的原因主要有兩方面：①與軟件本身的特點有關。軟件不同于硬件，它是計算機系統中的邏輯部件而不是物理部件；軟件樣品即是產品，試制過程也就是生產過程；軟件不會因使用時間過長而“老化”或“用壞”；軟件具有可運行的行為特性，在寫出程序代碼并在計算機上試運行之前，軟件開發過程的進展情況較難衡量，軟件質量也較難評價，因此管理和控制軟件開發過程十分困難；軟件質量不是根據大量制造的相同實體的質量來度量，而是與每一個組成部分的不同實體的質量緊密相關，因此，在運行時所出現的軟件錯誤幾乎都是在開發時期就存在而一直未被發現的，改正這類錯誤通常意味著改正或修改原來的設計，這就在客觀上使得軟件維護遠比硬件維護困難；軟件是一種信息產品，具有可延展性，屬于柔性生產，與通用性強的硬件相比，軟件更具有多樣化的特點，更加接近人們的應用問題。隨著計算機應用領域的擴大，99％的軟件應用需求已不再是定義良好的數值計算問題，而是難以精確描述且富于變化的非數值型應用問題。因此，當人們的應用需求變化發展的時候，往往要求通過改變軟件來使計算機系統滿足新的需求，維護用戶業務的延續性。②危機原因來自于軟件開發人員的如下弱點：其一，軟件產品是人的思維結果，因此軟件生產水平最終在相當程度上取決于軟件人員的教育、訓練和經驗的積累；其二，對于大型軟件往往需要許多人合作開發，甚至要求軟件開發人員深入應用領域的問題研究，這樣就需要在用戶與軟件人員之間以及軟件開發人員之間相互通訊，在此過程中難免發生理解的差異，從而導致后續錯誤的設計或實現，而要消除這些誤解和錯誤往往需要付出巨大的代價；其三，由于計算機技術和應用發展迅速，知識更新周期加快，軟件開發人員經常處在變化之中，不僅需要適應硬件更新的變化，而且還要涉及日益擴大的應用領域問題研究；軟件開發人員所進行的每一項軟件開發幾乎都必須調整自身的知識結構以適應新的問題求解的需要，而這種調整是人所固有的學習行為，難以用工具來代替。
軟件生產的這種知識密集和人力密集的特點是造成軟件危機的根源所在。
解決途徑? ?軟件工程誕生于60年代末期，它作為一個新興的工程學科，主要研究軟件生產的客觀規律性，建立與系統化軟件生產有關的概念、原則、方法、技術和工具，指導和支持軟件系統的生產活動，以期達到降低軟件生產成本、改進軟件產品質量、提高軟件生產率水平的目標。軟件工程學從硬件工程和其他人類工程中吸收了許多成功的經驗，明確提出了軟件生命周期的模型，發展了許多軟件開發與維護階段適用的技術和方法，并應用于軟件工程實踐，取得良好的效果。
在軟件開發過程中人們開始研制和使用軟件工具，用以輔助進行軟件項目管理與技術生產，人們還將軟件生命周期各階段使用的軟件工具有機地集合成為一個整體，形成能夠連續支持軟件開發與維護全過程的集成化軟件支援環境，以期從管理和技術兩方面解決軟件危機問題。
此外，人工智能與軟件工程的結合成為80年代末期活躍的研究領域。基于程序變換、自動生成和可重用軟件等軟件新技術研究也已取得一定的進展，把程序設計自動化的進程向前推進一步。在軟件工程理論的指導下，發達國家已經建立起較為完備的軟件工業化生產體系，形成了強大的軟件生產能力。軟件標準化與可重用性得到了工業界的高度重視，在避免重用勞動，緩解軟件危機方面起到了重要作用。
軟件危機的形成
1.硬件生產率大幅提高
如今，計算機的發展已進入一個新的歷史階段；
硬件產品已系列化、標準化，"即插即用"。
硬件產品的生產可以采用最高精尖的現代化工具和手段、自動成批生產。生產效率幾百萬倍的提高。
生產能力過剩。
2. 軟件生產隨規模增大復雜度增大
以美國航空航天局的軟件系統為例：
1963年 水星計劃系統 200萬條指令
1967年 雙子座計劃系統 400萬條指令
1973年 阿波羅計劃系統 1000萬條指令
1979年 哥倫比亞航天飛機系統 4000萬條指令
假設1個人一年生產一萬條有效指令，那么是否4000人生產一年，或400人生產10年就能完成任務呢？答案是否定的。一萬條指令的復雜度決不僅僅是100條指令復雜度的100倍。
3. 軟件生產率很低
伴隨計算機的普及，整個社會對計算機應用的需求越來越大。
但軟件的生產卻還沿用"手工作坊"的生產方式，人工編程生產。生產效率僅提高了幾倍。
生產能力極其低下。
4. 硬、軟件供需失衡
社會大量需求，生產成本高，生產過程控制復雜，生產效率低等等因素構成軟件生產的惡性循環。
由此產生"軟件危機"。
5. 矛盾引發"軟件危機"
軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。
為了研究、解決軟件危機，誕生了一門新興學科--軟件工程。它把軟件作為工程對象，從技術措施和組織管理兩個方面來研究、解決軟件危機。
軟件危機的具體體現
1. 軟件開發進度難以預測
拖延工期幾個月甚至幾年的現象并不罕見，這種現象降低了軟件開發組織的信譽。以丹佛新國際機場為例:
該機場規模是曼哈頓機場的兩倍，寬為希思機場的10倍，可以全天侯同時起降三架噴氣式客機；投資1.93億美元建立了一個地下行李傳送系統，總長21英里，有4，000臺遙控車，可按不同線路在20家不同的東航浙江公司柜臺、登機門和行李領取處之間發送和傳遞行李；支持該系統的是5，000個電子眼、400臺無線接收手機、56臺條形碼掃描儀和100臺計算機。按原定計劃要在1993年萬圣節前啟用，但一直到1994年6月，機場的計劃者還無法預測行李系統何時能達到可使機場開放的穩定程度。
2. 軟件開發成本難以控制
投資一再追加，令人難于置信。往往是實際成本比預算成本高出一個數量級。
而為了趕進度和節約成本所采取的一些權宜之計又往往損害了軟件產品的質量，從而不可避免地會引起用戶的不滿。
3. 用戶對產品功能難以滿足
開發人員和用戶之間很難溝通、矛盾很難統一。往往是軟件開發人員不能真正了解用戶的需求，而用戶又不了解計算機求解問題的模式和能力，雙方無法用共同熟悉的語言進行交流和描述。
在雙方互不充分了解的情況下，就倉促上陣設計系統、匆忙著手編寫程序，這?quot;閉門造車"的開發方式必然導致最終的產品不符合用戶的實際需要。
4. 軟件產品質量無法保證
系統中的錯誤難以消除。軟件是邏輯產品，質量問題很難以統一的標準度量，因而造成質量控制困難。
軟件產品并不是沒有錯誤，而是盲目檢測很難發現錯誤，而隱藏下來的錯誤往往是造成重大事故的隱患。
5. 軟件產品難以維護
軟件產品本質上是開發人員的代碼化的邏輯思維活動，他人難以替代。除非是開發者本人，否則很難及時檢測、排除系統故障。
為使系統適應新的硬件環境，或根據用戶的需要在原系統中增加一些新的功能，又有可能增加系統中的錯誤。 6. 軟件缺少適當的文檔資料
文檔資料是軟件必不可少的重要組成部分。
實際上，軟件的文檔資料是開發組織和用戶的之間權利和義務的合同書，是系統管理者、總體設計者向開發人員下達的任務書，是系統維護人員的技術指導手冊，是用戶的操作說明書。
缺乏必要的文檔資料或者文檔資料不合格，將給軟件開發和維護帶來許多嚴重的困難和問題。最典型失敗系統的例子是：
IBM公司開發OS/360系統，共有4000多個模塊，約100萬條指令，投入5000人年，耗資數億美元，結果還是延期交付。在交付使用后的系統中仍發現大量（2000個以上）的錯誤。
參考資料 >