軟件危機
在肯尼迪航天中心，高高的發射架上豎起了即將發射的航天飛機。時間是1981年的4月份。
這是美國“哥倫比亞”號航天飛機的處女飛行，離發射還有20分鍾，倒數計時器正在不停地向零邁進。緊張的準備工作正在有條不紊地進行著。對於這裏的工作人員來說，這些工作是職業性的，不帶絲毫的個人因素，因為在這裏發射各種火箭、衛星已經不是第一次了。那種看著火箭升空的激動正慢慢地變成一種習慣性的忙碌。
突然警報燈開始閃爍起來，警笛長鳴，計時器停止倒數計時，人們立刻停止手中的工作，焦急地等待控製台的信號及命令。初步判定是控製飛行的計算機係統出了毛病 。按規定3小時內如不能排除故障，則必須取消這次飛行計劃。計算機分析員們立即投入異常緊張的檢查工作，很快便查明計算機硬件係統完全正常。問題出在控製計算機運行的程序——控製軟件上。技術人員敏感地意識到這是一個十分嚴重的問題。絕非一時半刻所能解決排除的。因為控製航天飛機的計算程序包括近50萬條指令，要從中找出一處錯誤如同在一本大百科全書裏找出一個拚錯了的單詞那樣困難。航天飛機的處女飛行不得不延期。
從那時起，計算機專家們提出了軟件危機的概念，即計算機軟件的發展已跟不上計算機硬件發展，並且由於軟件規模的擴大，軟件的可靠性、效率及成本上出現了一係列的問題，稱之為軟件危機。
計算機係統軟件在六十年代中取得重大的進展。操作係統是係統軟件發展史上的一個裏程碑，也是第三代計算機的主要特征之一。而應用軟件更是百花齊放，各種應用軟件層出不窮，應有盡有。
但是就像前麵所述的控製航天飛機飛行的軟件近５0萬條指令，這麼龐大的係統誰能保證它是完全安全可靠的呢？
196５年至19７0年，美國範登堡基地發射火箭多次失敗，絕大部分出於控製係統軟件的故障，一點小小的錯誤結果導致了災難性的後果。一次在美國肯尼迪角發射一枚阿脫拉斯火箭，預定將用這種火箭運載飛往金星的宇宙飛船，火箭升至離地麵幾十英裏的高空時開始翻滾，並且開始向地麵墜落，如果落到地麵可能造成更大的損失，地麵中心被迫下令炸毀。後經檢查是飛行計劃程序裏漏了一個連字符。小小的疏忽造成了這支價值18５0萬美元的火箭失敗，而且影響了其後的宇宙飛船的升空計劃。
由於軟件工程龐大，很多情況下往往是采用人海戰術來進行軟件製作。但各人之間製作的軟件如何相對接，仍然是很多專家們致力解決的問題。同時，軟件費用的急劇增長也是軟件工程擴大帶來的必然副作用。例如ＩＢＭ 360係統研製費用５億美元之中的一半就花在軟件研製上。美國全球軍事指揮控製係統的計算機硬件費用為1億美元（19７1年），而軟件費用則高達７億2000萬美元。按理說軟件應當是費用較低的，可在這些情況下，卻恰恰相反。