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