软件危机：落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
第一次软件危机 （60年代~70年代）
20 世纪60年代以前，计算机刚刚投入实际使用，这个时期主要的软件开发方式是使用机器语言或者汇编语言在特定的机器上进行软件的设计与编写。此时的软件规模较小，文档资料通常也不存在，也不需要使用系统化的软件开发方法，基本上是个人设计编码、个人操作使用的的私人化的软件生产模式。这个时代的程序一个典型特征就是依赖特定的机器，程序员必须根据所使用的计算机的硬件特性编写特定的程序。
然而从60年代中期开始，大容量、高速度计算机问世，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出，程序设计的复杂度也随之增长。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发 。
1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出“软件工程”一词，从此一门新兴的工程学科——软件工程学——为研究和克服软件危机应运而生，“软件危机”的概念也是在那次会议上由F. L. Bauer提出的。
当时业界最迫切的需求是需要在不损失性能的前提下获得更好的“抽象性”和“可移植性”。此时，比汇编和机器语言更高级的语言相聚诞生，典型的代表莫过于C语言（1972年）。C语言让程序员能让程序员编写的代码在没有或只有较少机器相关性的同时又有不输于汇编语言的性能，而且丰富的语言特性也使得编程难度大大降低，成功的解决了“抽象性”和“可移植性”的问题。
现象
早期出现的软件危机主要表现在：
① 软件开发费用和进度失控。费用超支、进度拖延的情况屡屡发生。有时为了赶进度或压成本不得不采取一些权宜之计，这样又往往严重损害了软件产品的质量。
②软件的可靠性差。尽管耗费了大量的人力物力，而系统的正确性却越来越难以保证，出错率大大增加，由于软件错误而造成的损失十分惊人。
③生产出来的软件难以维护。很多程序缺乏相应的文档资料，程序中的错误难以定位，难以改正，有时改正了已有的错误又引入新的错误。随着软件的社会拥有量越来越大，维护占用了大量人力、物力和财力。进入80年代以来，尽管软件工程研究与实践取得了可喜的成就，软件技术水平有了长足的进展，但是软件生产水平依然远远落后于硬件生产水平的发展速度
第二次软件危机（80年代~90年代）
这次危机可以归因于软件复杂性的进一步增长。这个时候的大规模软件常常由数百万行代码组成，有数以百计的程序员参与其中，怎样高效、可靠的构造和维护这样规模的软件成为了一个新的难题。著名的《人月神话》中提及，IBM公司开发的OS/360系统共有4000多个模块，约100万条指令，投入5000人年，耗资数亿美元，结果还是延期交付。在交付使用后的系统中仍发现大量（2000个以上）的错误。
现象
软件危机不仅没有消失，还有加剧之势。主要表现在：
①软件成本在计算机系统总成本中所占的比例居高不下，且逐年上升。由于微电子学技术的进步和硬件生产自动化程度不断提高，硬件成本逐年下降，性能和产量迅速提高。然而软件开发需要大量人力，软件成本随着软件规模和数量的剧增而持续上升。从美、日两国的统计数字表明，1985年度软件成本大约占总成本的90％。
②软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的需要，软件产品供不应求的状况使得人类不能充分利用现代计算机硬件所能提供的巨大潜力。
这时候人们典型需求的是更好的“可组合性”(Composability)、“可延展性”(Malleability)以及“可维护性”(Maintainability)。程序的性能已经不是一个大问题了，因为摩尔定律能帮你搞定它（70年代编写的C程序仍然能在现在的计算机上运行，而且它还更快！）。为了解决这次危机，面向对象的编程语言（C++、C#、Java等）诞生了，更好的软件工程方法（设计模式、重构、测试、需求分析等等）诞生了，而程序员们也越来越不需要知道硬件是怎么工作的了。软件和硬件的界限越来越牢固，Java编写的代码能在任何JVM支持的平台上运行，程序员也非常乐于享受这样的便利。
第三次软件危机（2005年至今）
兄弟们，“免费的午餐已经结束了”。
摩尔定律在串行机器上宣告失效，多核时代正式来临！
这个时候怎样在多核平台上仍然能保持性能的持续增长就成为了这一次软件危机的核心。并行编程给我们带来了许许多多新的技术难题，现阶段想要高效的利用这些多核平台以获得更好的性能，就必须对计算机的硬件有较深入的理解，而广大程序员却更喜欢能有一些更加便利的编程模型（也许是一门新的语言、也许是新的编程模型）来简单高效地进行并行编程。我们正处在这次危机的开端，前路满是荆棘。但是只要有问题，就会有机会。多核时代，你们的机会在哪里呢？
原因
软件工程研究结果表明 ，软件危机的原因主要有两方面：
与软件本身的特点有关
软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件；软件样品即是产品，试制过程也就是生产过程；软件不会因使用时间过长而“老化”或“用坏”；软件具有可运行的行为特性，在写出程序代码并在计算机上试运行之前，软件开发过程的进展情况较难衡量，软件质量也较难评价，因此管理和控制软件开发过程十分困难；软件质量不是根据大量制造的相同实体的质量来度量，而是与每一个组成部分的不同实体的质量紧密相关，因此，在运行时所出现的软件错误几乎都是在开发时期就存在而一直未被发现的，改正这类错误通常意味着改正或修改原来的设计，这就在客观上使得软件维护远比硬件维护困难；软件是一种信息产品，具有可延展性，属于柔性生产，与通用性强的硬件相比，软件更具有多样化的特点，更加接近人们的应用问题。
随着计算机应用领域的扩大，99％的软件应用需求已不再是定义良好的数值计算问题，而是难以精确描述且富于变化的非数值型应用问题。因此，当人们的应用需求变化发展的时候，往往要求通过改变软件来使计算机系统满足新的需求，维护用户业务的延续性。
来自于软件开发人员的弱点
其一，软件产品是人的思维结果，因此软件生产水平最终在相当程度上取决于软件人员的教育、训练和经验的积累；
其二，对于大型软件往往需要许多人合作开发，甚至要求软件开发人员深入应用领域的问题研究，这样就需要在用户与软件人员之间以及软件开发人员之间相互通讯，在此过程中难免发生理解的差异，从而导致后续错误的设计或实现，而要消除这些误解和错误往往需要付出巨大的代价；
其三，由于计算机技术和应用发展迅速，知识更新周期加快，软件开发人员经常处在变化之中，不仅需要适应硬件更新的变化，而且还要涉及日益扩大的应用领域问题研究；软件开发人员所进行的每一项软件开发几乎都必须调整自身的知识结构以适应新的问题求解的需要，而这种调整是人所固有的学习行为，难以用工具来代替。
软件生产的这种知识密集和人力密集的特点是造成软件危机的根源所在。
从软件开发危机的种种表现和软件开发作为逻辑产品的特殊性可以发现软件开发危机的原因：
（1）用户需求不明确
在软件开发过程中，用户需求不明确问题主要体现在四个方面：
在软件开发出来之前，用户自己也不清楚软件开发的具体需求；
用户对软件开发需求的描述不精确，可能有遗漏、有二义性、甚至有错误；
在软件开发过程中，用户还提出修改软件开发功能、界面、支撑环境等方面的要求；
软件开发人员对用户需求的理解与用户本来愿望有差异。
（2）缺乏正确的理论指导
缺乏有力的方法学和工具方面的支持。由于软件开发不同于大多数其他工业产品，其开发过程是复杂的逻辑思维过程，其产品极大程度地依赖于开发人员高度的智力投入。由于过分地依靠程序设计人员在软件开发过程中的技巧和创造性，加剧软件开发产品的个性化，也是发生软件开发危机的一个重要原因。
（3）软件开发规模越来越大
随着软件开发应用范围的增广，软件开发规模愈来愈大。大型软件开发项目需要组织一定的人力共同完成，而多数管理人员缺乏开发大型软件开发系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。软件开发项目开发人员不能有效地、独立自主地处理大型软件开发的全部关系和各个分支，因此容易产生疏漏和错误。
（4）软件开发复杂度越来越高
软件开发不仅仅是在规模上快速地发展扩大，而且其复杂性也急剧地增加。软件开发产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件开发效率和能力，新的、更大的、更复杂的问题又摆在人们的面前。