軟件危機 software crisis
落後的軟件生産方式無法滿足迅速增長的計算機軟件需求，從而導致軟件開發與維護過程中出現一係列嚴重問題的現象。
概況
20 世紀60年代以前，計算機剛剛投入實際使用，軟件設計往往衹是為了一個特定的應用而在指定的計算機上設計和編製，采用密切依賴於計算機的機器代碼或匯編語言，軟件的規模比較小，文檔資料通常也不存在，很少使用係統化的開發方法，設計軟件往往等同於編製程序，基本上是個人設計、個人使用、個人操作、自給自足的私人化的軟件生産方式。
60年代中期，大容量、高速度計算機的出現，使計算機的應用範圍迅速擴大，軟件開發急劇增長。高級語言開始出現；操作係統的發展引起了計算機應用方式的變化；大量數據處理導致第一代數據庫管理係統的誕生。軟件係統的規模越來越大，復雜程度越來越高，軟件可靠性問題也越來越突出。原來的個人設計、個人使用的方式不再能滿足要求，迫切需要改變軟件生産方式，提高軟件生産率，軟件危機開始爆發 。
1968 年北大西洋公約 組織 的計算機 科學家在聯邦德國召開國際會議，第一次討論軟件危機問題，並正式提出“軟件工程”一詞，從此一門新興的工程學科——軟件工程學——為研究和剋服軟件危機應運而生。
現象
早期出現的軟件危機主要表現在：
① 軟件開發費用和進度失控。費用超支、進度拖延的情況屢屢發生。有時為了趕進度或壓成本不得不采取一些權宜之計，這樣又往往嚴重損害了軟件産品的質量。
②軟件的可靠性差。儘管耗費了大量的人力物力，而係統的正確性卻越來越難以保證，出錯率大大增加，由於軟件錯誤而造成的損失十分驚人。
③生産出來的軟件難以維護。很多程序缺乏相應的文檔資料，程序中的錯誤難以定位，難以改正，有時改正了已有的錯誤又引入新的錯誤。隨着軟件的社會擁有量越來越大，維護占用了大量人力、物力和財力。進入80年代以來，儘管軟件工程研究與實踐取得了可喜的成就，軟件技術水平有了長足的進展，但是軟件生産水平依然遠遠落後於硬件生産水平的發展速度。
軟件危機不僅沒有消失，還有加劇之勢。主要表現在：
①軟件成本在計算機係統總成本中所占的比例居高不下，且逐年上升。由於微電子學技術的進步和硬件生産自動化程度不斷提高，硬件成本逐年下降，性能和産量迅速提高。然而軟件開發需要大量人力，軟件成本隨着軟件規模和數量的劇增而持續上升。從美、日兩國的統計數字表明，1985年度軟件成本大約占總成本的90％。
②軟件開發生産率提高的速度遠遠跟不上計算機應用迅速普及深入的需要，軟件産品供不應求的狀況使得人類不能充分利用現代計算機硬件所能提供的巨大潛力。
原因
軟件工程研究結果表明 ，軟件危機的原因主要有兩方面：
①與軟件本身的特點有關。
軟件不同於硬件，它是計算機係統中的邏輯部件而不是物理部件；軟件樣品即是産品，試製過程也就是生産過程；軟件不會因使用時間過長而“老化”或“用壞”；軟件具有可運行的行為特性，在寫出程序代碼並在計算機上試運行之前，軟件開發過程的進展情況較難衡量，軟件質量也較難評價，因此管理和控製軟件開發過程十分睏難；軟件質量不是根據大量製造的相同實體的質量來度量，而是與每一個組成部分的不同實體的質量緊密相關，因此，在運行時所出現的軟件錯誤幾乎都是在開發時期就存在而一直未被發現的，改正這類錯誤通常意味着改正或修改原來的設計，這就在客觀上使得軟件維護遠比硬件維護睏難；軟件是一種信息産品，具有可延展性，屬於柔性生産，與通用性強的硬件相比，軟件更具有多樣化的特點，更加接近人們的應用問題。
隨着計算機應用領域的擴大，99％的軟件應用需求已不再是定義良好的數值計算問題，而是難以精確描述且富於變化的非數值型應用問題。因此，當人們的應用需求變化發展的時候，往往要求通過改變軟件來使計算機係統滿足新的需求，維護用戶業務的延續性。
②危機原因來自於軟件開發人員的如下弱點：
其一，軟件産品是人的思維結果，因此軟件生産水平最終在相當程度上取决於軟件人員的教育、訓練和經驗的積纍；
其二，對於大型軟件往往需要許多人合作開發，甚至要求軟件開發人員深入應用領域的問題研究，這樣就需要在用戶與軟件人員之間以及軟件開發人員之間相互通訊，在此過程中難免發生理解的差異，從而導致後續錯誤的設計或實現，而要消除這些誤解和錯誤往往需要付出巨大的代價；
其三，由於計算機技術和應用發展迅速，知識更新周期加快，軟件開發人員經常處在變化之中，不僅需要適應硬件更新的變化，而且還要涉及日益擴大的應用領域問題研究；軟件開發人員所進行的每一項軟件開發幾乎都必須調整自身的知識結構以適應新的問題求解的需要，而這種調整是人所固有的學習行為，難以用工具來代替。
軟件生産的這種知識密集和人力密集的特點是造成軟件危機的根源所在。
從軟件開發危機的種種表現和軟件開發作為邏輯産品的特殊性可以發現軟件開發危機的原因：
（1）用戶需求不明確
在軟件開發過程中，用戶需求不明確問題主要體現在四個方面：
在軟件開發出來之前，用戶自己也不清楚軟件開發的具體需求；
用戶對軟件開發需求的描述不精確，可能有遺漏、有二義性、甚至有錯誤；
在軟件開發過程中，用戶還提出修改軟件開發功能、界面、支撐環境等方面的要求；
軟件開發人員對用戶需求的理解與用戶本來願望有差異。
（2）缺乏正確的理論指導
缺乏有力的方法學和工具方面的支持。由於軟件開發不同於大多數其他工業産品，其開發過程是復雜的邏輯思維過程，其産品極大程度地依賴於開發人員高度的智力投入。由於過分地依靠程序設計人員在軟件開發過程中的技巧和創造性，加劇軟件開發産品的個性化，也是發生軟件開發危機的一個重要原因。
（3）軟件開發規模越來越大
隨着軟件開發應用範圍的增廣，軟件開發規模愈來愈大。大型軟件開發項目需要組織一定的人力共同完成，而多數管理人員缺乏開發大型軟件開發係統的經驗，而多數軟件開發人員又缺乏管理方面的經驗。各類人員的信息交流不及時、不準確、有時還會産生誤解。軟件開發項目開發人員不能有效地、獨立自主地處理大型軟件開發的全部關係和各個分支，因此容易産生疏漏和錯誤。
（4）軟件開發復雜度越來越高
軟件開發不僅僅是在規模上快速地發展擴大，而且其復雜性也急劇地增加。軟件開發産品的特殊性和人類智力的局限性，導致人們無力處理“復雜問題”。所謂“復雜問題”的概念是相對的，一旦人們采用先進的組織形式、開發方法和工具提高了軟件開發效率和能力，新的、更大的、更復雜的問題又擺在人們的面前。
解决途徑
軟件工程誕生於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個以上）的錯誤。 |
|
|