軟體危機(Software Crisis) 是計算機軟體在它的開發和維護過程中所遇到的一系列嚴重問題。概括地說，主要包含兩方面的問題：如何開發軟體，怎樣滿足對軟體日益增長的需求；如何維護數量不斷膨脹的已有軟體。
“軟體危機”使得人們開始對軟體及其特性進行更深一步的研究，人們改變了早期對軟體的不正確看法。早期那些被認為是優秀的程式常常很難被別人看懂，通篇充滿了程式技巧。現在人們普遍認為優秀的程式除了功能正確，效能優良之外，還應該容易看懂、容易使用、容易修改和擴充。
程式設計語言雖然為計算機的應用開拓了無比廣闊的前景，但遊蕩在軟體世界的幽靈——“軟體危機”依然存在。因為軟體的開發不僅受到程式設計的方法、結構的制約，而且受到開發週期以及軟體開發成本的限制，更重要的是軟體質量的保障與其程式設計的正確性關係極大。如果所開發的軟體其可靠性得不到保障，在執行中將會產生不堪設想的嚴重後果。
60年代中期以後，計算機硬體技術日益進步，計算的存貯容量、運算速度和可靠性明顯提高，生產硬體的成本不斷降低。計算機價格的下跌為它的廣泛應用創造了極好的條件。在這種形勢下，迫切要求計算機軟體也能與之相適應。因而，一些開發大型軟體系統的要求提了出來。然而軟體技術的進步一直未能滿足形勢發展的需要，在大型軟體的開發過程中出現了複雜程度高、研製週期長、正確性難以保證的三大難題。遇到的問題找不到解決辦法，致使問題堆積起來，形成了人們難以控制的局面，出現了所謂的“軟體危機”。
最為突出的例子是美國IBM公司於1963年～1966年開發的IBM360系列機的作業系統。該軟體系統花了大約5 000人一年的工作量，最多時，有 1000人投入開發工作，寫出近100萬行的源程式。儘管投入了這麼多的人力和物力，得到的結果卻極其糟糕。據統計，這個作業系統每次發行的新版本都是從前一版本中找出1000個程式錯誤而修正的結果。可想而知，這樣的軟體質量糟到了什麼地步。
難怪該專案的負責人F·D·希羅克斯在總結該專案時無比沉痛地說：“……正像一隻逃亡的野獸落到泥潭中作垂死掙扎，越是掙扎，陷得越深，最後無法逃脫滅頂的災難，……程式設計工作正像這樣一個泥潭……一批批程式設計師被迫在泥潭中拼命掙扎，……，誰也沒有料到問題竟會陷入這樣的困境……。” IBM360作業系統的歷史教訓已成為軟體開發專案中的典型事例被記入歷史史冊。
如果開發的軟體隱含錯誤，可靠性得不到保證，那麼在執行過程中很可能對整個系統造成十分嚴重的後果，輕則影響到系統的正常工作，重則導致整個系統的癱瘓，乃至造成無可挽回的惡性事故。如，銀行的存款可能被化為烏有，甚至弄成赤字；工廠的產品全部報廢，導致工廠破產。
1963年，美國用於控制火星探測器的計算機軟體中的一個“，”號被誤寫為“·”，而致使飛往火星的探測器發生爆炸，造成高達數億美元的損失。
為了克服這一危機，一方面需要對程式設計方法、程式的正確性和軟體的可靠性等問題進行系列的研究；另一方面，也需要對軟體的編制、測試、維護和管理的方法進行研究，從而產生了程式設計方法學。
1968年，E·W·代克斯特拉首先提出“GOTO語句是有害的”論點，向傳統程式設計方法提出了挑戰，從而引起了人們對程式設計方法討論的普遍重視。眾多著名的計算機科學家都參加了這種討論。程式設計方法學也正是在這種廣泛而深入的討論中逐漸產生和形成的。
什麼是程式設計方法學呢？簡言之，程式設計方法學是討論程式的性質、程式設計的理論和方法的一門學科。它包含的內容比較豐富，例如，結構程式設計，程式正確性證明，程式變換，程式的形式說明與推導、程式綜合、自動程式設計等。在程式設計方法學中，結構程式設計佔有十分重要的地位，可以說，程式設計方法學是在結構程式設計的基礎上逐步發展和完善起來的。
什麼是結構程式設計呢？至今仍眾說紛紜，還沒有一個嚴格的，又能被大家普遍接受的定義。1974年，D·格里斯將已有的對結構程式設計的不同解釋歸結為13種，其中，比較有代表性的如下：
結構程式設計是避免使用GOTO語句的一種程式設計；
結構程式設計是自頂向下的程式設計；
結構程式設計是一種組織和編制程式的方法，利用它編制的程式易於理解、易於修改；
程式結構化的一個主要功能是使程式正確性的證明容易實現；
結構程式設計對設計過程中的每一步去驗證其正確性，這樣便自動導致自我說明和自我捍衛的程式設計風格；
按照結構程式設計的要求設計出的程式設計語言稱為結構程式設計語言。利用結構程式設計語言，或者說按結構程式設計的思想和原則編制出的程式稱為結構化程式。
在60年代末和70年代初，關於GOTO語句的用法的爭論比較激烈。主張從高階程式語言中去掉GOTO語句的人認為，GOTO語句是對程式結構影響最大的一種有害的語句，他們的主要理由是：GOTO語句使程式的靜態結構和動態結構不一致，從而使程式難以理解，難以查錯。去掉GOTO語句後，可直接從程式結構上反映程式執行的過程。這樣，不僅使程式結構清晰，便於理解，便於查錯，而且也有利於程式的正確性證明。
持反對意見的人認為，GOTO語句使用起來比較靈活，而且有些情形能提高程式的效率。若完全刪去GOTO語句，有些情形反而會使程式過於複雜，增加一些不必要的計算量。
1974年，D·E·克努斯對於GOTO語句爭論作了全面公正的評述，其基本觀點是：不加限制地使用GOTO語句，特別是使用往回跳的GOTO語句，會使程式結構難於理解，在這種情形，應儘量避免使用GOTO語句。但在另外一些情況下，為了提高程式的效率，同時又不致於破壞程式的良好結構，有控制地使用一些GOTO語句也是必要的。用他的話來說就是：“在有些情形，我主張刪掉GOTO語句；在另外一些情形，則主張引進GOTO語句。”從此，使這場長達10年之久的爭論得以平息。
後來，G·加科皮尼和C·波姆從理論上證明了：任何程式都可以用順序、分支和重複結構表示出來。這個結論表明，從高階程式語言中去掉GOTO語句並不影響高階程式語言的程式設計能力，而且編寫的程式的結構更加清晰。
結構程式設計的思想體現在採用了一些比較行之有效的方法，在這些方法中較有代表性的是“逐步求精”方法。所謂“逐步求精”方法，就是在編制一個程式時，首先考慮程式的整體結構而暫時忽略一些細節問題，然後逐步地一層一層地細化直至用所選用的語言完全描述每一個細節，即得到所期望的程式為止。換言之，它是按照先全域性後區域性、先整體後細節、先抽象後具體的過程組織人們的思維活動，使得編寫出的程式結構清晰、容易理解、容易驗證、容易修改。“逐步求精”方法與模組化設計方法既有聯絡又有區別。粗略地講，逐步求精主要指一個程式的設計過程，而模組化設計主要指比較大的系統的設計過程。
此外，面對“軟體危機”，人們調查研究了軟體生產的實際情況，逐步感到採用工程化的方法從事軟體系統的研究和維護的必要性，於是與程式設計方法學密切相關的軟體工程在1968年應運而生。軟體工程的主要物件是大型軟體。軟體工程研究的內容主要包括：軟體質量保證和質量評價；軟體研製和維護的方法、工具、文件；使用者介面的設計以及軟體管理等。軟體工程的最終目的是擺脫手工生產軟體的狀況，逐步實現軟體研製和維護的自動化。
軟體危機的主要表現：
1. 對軟體開發成本和進度的估計常常很不準確。
實際成本比估計成本有可能高出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象並不罕見。這種現象降低了開發組織的信譽。為趕進度和節約成本所採取的權宜之計往往又損害了軟體產品的質量，從而不可避免地引起使用者的不滿。
2. 使用者對“已完成的”軟體系統不滿意的現象經常發生。
軟體開發人員常常在對使用者需求只有模糊的瞭解，甚至對所要解決的問題還沒有確切認識的情況下，就倉促上陣匆忙著手編寫程式。軟體開發人員和使用者之間的交流往往很不充分，“閉門造車”必然導致最終產品不符合使用者實際需要。
3. 軟體產品的質量常常靠不住。
軟體可靠性和質量保證的確切定量概念剛剛出現，軟體質量保證技術（審查、複審和測試）還沒有堅持不懈地應用到軟體開發的全過程中，這些都會導致軟體產品發生質量問題。
4. 軟體常常是不可維護的。
程式中的錯誤很難改正，實際上不可能使這些程式適應新的硬體環境，也不能根據使用者的需求在原有程式中增加新的功能。
5. 軟體通常沒有適當的文件資料。
軟體不僅是程式，還應該有一整套文件資料。這些文件資料是在軟體開發過程中產生出來的，而且應該是“最新的”（與程式碼完全一致）。缺乏文件必然給軟體的開發和維護帶來許多嚴重的困難和問題。
6. 軟體成本在計算機系統總成本中所佔比例逐年上升。
隨著微電子技術的進步和生產自動化程度的提高，硬體成本逐年下降，然而軟體開發需要大量的人力，軟體成本隨著通貨膨脹以及軟體規模和數量的不斷擴大而逐年上升。美國在1995年的調查表明，軟體成本大約已佔計算機系統總成本的90%。
軟體危機的出現，使得人們去尋找產生危機的內在原因，發現其原因可歸納為兩方面，一方面是由軟體生產本身存在著複雜性，另一方面卻是與軟體開發所使用的方法和技術有關。
軟體工程正是為克服軟體危機而提出的一種概念，並在實踐中不斷地探索它的原理，技術和方法。在此過程中，人們研究和借鑑了工程學的某些原理和方法，並形成了一門新的學科—軟體工程學，但可惜的是時至今日人們並沒有完全克服軟體危機。
軟體危機(Software Crisis) 是計算機軟體在它的開發和維護過程中所遇到的一系列嚴重問題。概括地說，主要包含兩方面的問題：如何開發軟體，怎樣滿足對軟體日益增長的需求；如何維護數量不斷膨脹的已有軟體。
“軟體危機”使得人們開始對軟體及其特性進行更深一步的研究，人們改變了早期對軟體的不正確看法。早期那些被認為是優秀的程式常常很難被別人看懂，通篇充滿了程式技巧。現在人們普遍認為優秀的程式除了功能正確，效能優良之外，還應該容易看懂、容易使用、容易修改和擴充。
程式設計語言雖然為計算機的應用開拓了無比廣闊的前景，但遊蕩在軟體世界的幽靈——“軟體危機”依然存在。因為軟體的開發不僅受到程式設計的方法、結構的制約，而且受到開發週期以及軟體開發成本的限制，更重要的是軟體質量的保障與其程式設計的正確性關係極大。如果所開發的軟體其可靠性得不到保障，在執行中將會產生不堪設想的嚴重後果。
60年代中期以後，計算機硬體技術日益進步，計算的存貯容量、運算速度和可靠性明顯提高，生產硬體的成本不斷降低。計算機價格的下跌為它的廣泛應用創造了極好的條件。在這種形勢下，迫切要求計算機軟體也能與之相適應。因而，一些開發大型軟體系統的要求提了出來。然而軟體技術的進步一直未能滿足形勢發展的需要，在大型軟體的開發過程中出現了複雜程度高、研製週期長、正確性難以保證的三大難題。遇到的問題找不到解決辦法，致使問題堆積起來，形成了人們難以控制的局面，出現了所謂的“軟體危機”。
最為突出的例子是美國IBM公司於1963年～1966年開發的IBM360系列機的作業系統。該軟體系統花了大約5 000人一年的工作量，最多時，有 1000人投入開發工作，寫出近100萬行的源程式。儘管投入了這麼多的人力和物力，得到的結果卻極其糟糕。據統計，這個作業系統每次發行的新版本都是從前一版本中找出1000個程式錯誤而修正的結果。可想而知，這樣的軟體質量糟到了什麼地步。
難怪該專案的負責人F·D·希羅克斯在總結該專案時無比沉痛地說：“……正像一隻逃亡的野獸落到泥潭中作垂死掙扎，越是掙扎，陷得越深，最後無法逃脫滅頂的災難，……程式設計工作正像這樣一個泥潭……一批批程式設計師被迫在泥潭中拼命掙扎，……，誰也沒有料到問題竟會陷入這樣的困境……。” IBM360作業系統的歷史教訓已成為軟體開發專案中的典型事例被記入歷史史冊。
如果開發的軟體隱含錯誤，可靠性得不到保證，那麼在執行過程中很可能對整個系統造成十分嚴重的後果，輕則影響到系統的正常工作，重則導致整個系統的癱瘓，乃至造成無可挽回的惡性事故。如，銀行的存款可能被化為烏有，甚至弄成赤字；工廠的產品全部報廢，導致工廠破產。
1963年，美國用於控制火星探測器的計算機軟體中的一個“，”號被誤寫為“·”，而致使飛往火星的探測器發生爆炸，造成高達數億美元的損失。
為了克服這一危機，一方面需要對程式設計方法、程式的正確性和軟體的可靠性等問題進行系列的研究；另一方面，也需要對軟體的編制、測試、維護和管理的方法進行研究，從而產生了程式設計方法學。
1968年，E·W·代克斯特拉首先提出“GOTO語句是有害的”論點，向傳統程式設計方法提出了挑戰，從而引起了人們對程式設計方法討論的普遍重視。眾多著名的計算機科學家都參加了這種討論。程式設計方法學也正是在這種廣泛而深入的討論中逐漸產生和形成的。
什麼是程式設計方法學呢？簡言之，程式設計方法學是討論程式的性質、程式設計的理論和方法的一門學科。它包含的內容比較豐富，例如，結構程式設計，程式正確性證明，程式變換，程式的形式說明與推導、程式綜合、自動程式設計等。在程式設計方法學中，結構程式設計佔有十分重要的地位，可以說，程式設計方法學是在結構程式設計的基礎上逐步發展和完善起來的。
什麼是結構程式設計呢？至今仍眾說紛紜，還沒有一個嚴格的，又能被大家普遍接受的定義。1974年，D·格里斯將已有的對結構程式設計的不同解釋歸結為13種，其中，比較有代表性的如下：
結構程式設計是避免使用GOTO語句的一種程式設計；
結構程式設計是自頂向下的程式設計；
結構程式設計是一種組織和編制程式的方法，利用它編制的程式易於理解、易於修改；
程式結構化的一個主要功能是使程式正確性的證明容易實現；
結構程式設計對設計過程中的每一步去驗證其正確性，這樣便自動導致自我說明和自我捍衛的程式設計風格；
按照結構程式設計的要求設計出的程式設計語言稱為結構程式設計語言。利用結構程式設計語言，或者說按結構程式設計的思想和原則編制出的程式稱為結構化程式。
在60年代末和70年代初，關於GOTO語句的用法的爭論比較激烈。主張從高階程式語言中去掉GOTO語句的人認為，GOTO語句是對程式結構影響最大的一種有害的語句，他們的主要理由是：GOTO語句使程式的靜態結構和動態結構不一致，從而使程式難以理解，難以查錯。去掉GOTO語句後，可直接從程式結構上反映程式執行的過程。這樣，不僅使程式結構清晰，便於理解，便於查錯，而且也有利於程式的正確性證明。
持反對意見的人認為，GOTO語句使用起來比較靈活，而且有些情形能提高程式的效率。若完全刪去GOTO語句，有些情形反而會使程式過於複雜，增加一些不必要的計算量。
1974年，D·E·克努斯對於GOTO語句爭論作了全面公正的評述，其基本觀點是：不加限制地使用GOTO語句，特別是使用往回跳的GOTO語句，會使程式結構難於理解，在這種情形，應儘量避免使用GOTO語句。但在另外一些情況下，為了提高程式的效率，同時又不致於破壞程式的良好結構，有控制地使用一些GOTO語句也是必要的。用他的話來說就是：“在有些情形，我主張刪掉GOTO語句；在另外一些情形，則主張引進GOTO語句。”從此，使這場長達10年之久的爭論得以平息。
後來，G·加科皮尼和C·波姆從理論上證明了：任何程式都可以用順序、分支和重複結構表示出來。這個結論表明，從高階程式語言中去掉GOTO語句並不影響高階程式語言的程式設計能力，而且編寫的程式的結構更加清晰。
結構程式設計的思想體現在採用了一些比較行之有效的方法，在這些方法中較有代表性的是“逐步求精”方法。所謂“逐步求精”方法，就是在編制一個程式時，首先考慮程式的整體結構而暫時忽略一些細節問題，然後逐步地一層一層地細化直至用所選用的語言完全描述每一個細節，即得到所期望的程式為止。換言之，它是按照先全域性後區域性、先整體後細節、先抽象後具體的過程組織人們的思維活動，使得編寫出的程式結構清晰、容易理解、容易驗證、容易修改。“逐步求精”方法與模組化設計方法既有聯絡又有區別。粗略地講，逐步求精主要指一個程式的設計過程，而模組化設計主要指比較大的系統的設計過程。
此外，面對“軟體危機”，人們調查研究了軟體生產的實際情況，逐步感到採用工程化的方法從事軟體系統的研究和維護的必要性，於是與程式設計方法學密切相關的軟體工程在1968年應運而生。軟體工程的主要物件是大型軟體。軟體工程研究的內容主要包括：軟體質量保證和質量評價；軟體研製和維護的方法、工具、文件；使用者介面的設計以及軟體管理等。軟體工程的最終目的是擺脫手工生產軟體的狀況，逐步實現軟體研製和維護的自動化。
軟體危機的主要表現：
1. 對軟體開發成本和進度的估計常常很不準確。
實際成本比估計成本有可能高出一個數量級，實際進度比預期進度拖延幾個月甚至幾年的現象並不罕見。這種現象降低了開發組織的信譽。為趕進度和節約成本所採取的權宜之計往往又損害了軟體產品的質量，從而不可避免地引起使用者的不滿。
2. 使用者對“已完成的”軟體系統不滿意的現象經常發生。
軟體開發人員常常在對使用者需求只有模糊的瞭解，甚至對所要解決的問題還沒有確切認識的情況下，就倉促上陣匆忙著手編寫程式。軟體開發人員和使用者之間的交流往往很不充分，“閉門造車”必然導致最終產品不符合使用者實際需要。
3. 軟體產品的質量常常靠不住。
軟體可靠性和質量保證的確切定量概念剛剛出現，軟體質量保證技術（審查、複審和測試）還沒有堅持不懈地應用到軟體開發的全過程中，這些都會導致軟體產品發生質量問題。
4. 軟體常常是不可維護的。
程式中的錯誤很難改正，實際上不可能使這些程式適應新的硬體環境，也不能根據使用者的需求在原有程式中增加新的功能。
5. 軟體通常沒有適當的文件資料。
軟體不僅是程式，還應該有一整套文件資料。這些文件資料是在軟體開發過程中產生出來的，而且應該是“最新的”（與程式碼完全一致）。缺乏文件必然給軟體的開發和維護帶來許多嚴重的困難和問題。
6. 軟體成本在計算機系統總成本中所佔比例逐年上升。
隨著微電子技術的進步和生產自動化程度的提高，硬體成本逐年下降，然而軟體開發需要大量的人力，軟體成本隨著通貨膨脹以及軟體規模和數量的不斷擴大而逐年上升。美國在1995年的調查表明，軟體成本大約已佔計算機系統總成本的90%。
軟體危機的出現，使得人們去尋找產生危機的內在原因，發現其原因可歸納為兩方面，一方面是由軟體生產本身存在著複雜性，另一方面卻是與軟體開發所使用的方法和技術有關。
軟體工程正是為克服軟體危機而提出的一種概念，並在實踐中不斷地探索它的原理，技術和方法。在此過程中，人們研究和借鑑了工程學的某些原理和方法，並形成了一門新的學科—軟體工程學，但可惜的是時至今日人們並沒有完全克服軟體危機。