软件危机是早期计算机科学中的一个术语，指的是软件开发和维护过程中的一些严重问题，这些问题可能导致软件产品的寿命缩短或过早死亡。软件开发是一项非常困难和危险的活动。由于高故障率，存在所谓的“软件危机”。软件危机的根源是复杂性、期望和变化。该术语用于描述计算机性能快速增长的影响以及可以解决的问题的复杂性。本质上，它指的是编写准确、可理解和可验证的计算机程序的困难。
20世纪60年代，计算机科学界经历了一场软件危机，当时工程师们无法构建他们所需要的软件。对软件的需求在上升，但软件和开发人员的能力是有限的。开发人员无法跟上要求他们工作的项目的复杂性。1968年和1969年的北约软件工程会议帮助解决了一些问题，并开始了寻找解决方案(软件)的过程。
1972年，艾兹赫尔·戴克斯特拉于计算机协会图灵奖的演讲：
软件危机的主要原因，把它很不客气地说：在没有机器的时候，编程根本不是问题；当我们有了计算机，编程开始变成问题；而现在我们有巨大的计算机，编程就成为了一个同样巨大的问题。
艾兹赫尔·戴克斯特拉，《Communications of the ACM》
10年后到1986年，Brooks发表了一篇著名的论文“没有银弹（No Silver Bullet: Essence and Accidents of Software Engineering）”，断言“在10年内无法找到解决软件危机的杀手锏（银弹）。这文章激起许多软件工程专家的辩论﹐而没有银弹（No Silver Bullet）也成为脍炙人口的名词。Brooks认为软件工程专家们所找到的各种方法都是舍本逐末，它们解决不了软件中的根本困难，即软件概念结构(conceptual structure)的复杂性，无法达成软件概念的完整性和一致性，自然无法从根本上解决软件危机带来的困境。
软件危机使人们认识到中大型软件系统与小型软件有着本质性差异： 大型软件系统开发周期长、费用昂贵、软件质量难以保证、生产率低，它们的复杂性已远超出人脑能直接控制的程度 ，大型软件系统不能沿袭工作室的开发方式，就像制造小木船的方法不能生产航空母舰一样。
虽然我们无法从根本上解决软件危机，但是我们应当通过软件工程不断改进和优化软件开发过程来延缓危机。
如今，我们利用软件开发模型对软件生命周期进行建模，大致有如下几种：
瀑布模型
定义了软件开发的每个阶段，并明确了文档（需求规范、总体设计、详细设计等）应在每个阶段交付，因为不鼓励恢复到流程的前一阶段，所以不太灵活。
带原型的瀑布模型
显然瀑布模型会将整个软件开发过程中的众多风险积累到最后才能暴露出来，为了尽早暴露风险和控制风险，在瀑布模型的基础上增加一个原型化（prototyping）阶段，可以有效将风险前移，改善整个项目的技术和管理上的可控性。
V模型
V模型也是在瀑布模型基础上发展出来的，我们发现单元测试、集成测试和系统测试是为了在不同层面验证设计，而交付测试则是确认需求是否得到满足。也就是瀑布模型中前后两端的过程活动具有内在的紧密联系，如果将模块化设计的思想拿到软件开发过程活动的组织中来，可以发现通过将瀑布模型前后两端的过程活动结合起来，可以提高过程活动的内聚度，从而改善软件开发效率。
分阶段增量和迭代
分阶段开发可以让客户在没有开发完成之前就可以使用部分功能，也就是每次可以交付系统的一小部分，从而缩短开发迭代的周期。如图所示，分阶段开发还可以让产品系统和开发系统并行进行。
螺旋模型
结合了瀑布和迭代，强调了迭代风险分析，每次绕螺旋的行程都经过四个基本象限：确定迭代的目标、备选方案和约束；评估备选方案，识别和解决风险；开发和验证迭代中的可交付成果；计划下一次迭代。
除此以外，结构化程序设计、面向对象分析和设计、模块化方法、设计模式、软件架构等一系列技术都能在一定程度上缓解了软件危机的表现，这些技术本质上都是通过对软件本身的抽象来有效管控软件的复杂性。
参考资料：代码中的软件工程 https://gitee.com/mengning997/se
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！