软件危机是怎么回事？

软件危机爆发于20世纪60年代末期，虽然人们一直致力于发现解决危机的方法，但是软件危机至今依然困绕着我们，并没有一种灵丹妙药可以完全治愈这种病痛。
　　软件危机的具体表现如下：
　　（1） 软件开发的进度难以控制，经常出现经费超预算、完成期限一再拖延的现象。
　　1979年，美国US Government Accounting Office对政府项目进行了调查，其中9个软件项目的结果如下：

　　一个复杂的软件系统需要建立庞大的逻辑体系，而这些往往只存在于人们的头脑中，正如一个大项目负责人所说："软件人员太像皇帝新衣故事中的裁缝，当我来检查软件开发工作时，所得到的回答好像对我说：我们正忙于编织这件带有魔法的织物，只要一会儿，你就会看到这件织物是极其美丽的。但是我什么也看不到，什么也摸不到，也说不出任何一个有关的数字，没有任何办法得到一些信息说明事情确实进行得非常顺利，而且我已经知道许多人最终已经编织了一大堆昂贵的废物而去，还有不少人最终什么也没有做出来。"

　　（2） 软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果。

　　软件需求的缺陷将给项目成功带来极大风险，如产品的成本过高、产品的功能和质量无法完全满足用户的期望等等。即使一个项目团队的人员和配备都很不错，但不重视需求过程也会付出惨痛的代价。导致需求缺陷的主要原因包括需求的沟通与理解、需求的变化与控制、需求说明的明确与完整，模棱两可的需求所带来的后果便是返工--重做一些你认为已做好的事情，返工会耗费开发总费用的40%，而70%～85%的重做是由于需求方面的错误引起的。

　　（3） 由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下，运行中出现大量问题。

　　在1985年到1987年之间，至少有2个病人是死于Therac-25医疗线性加速器的过量辐射，其原因是控制软件中的一个故障。1965年至1970年，美国范登堡基地发射火箭多次失败，绝大部分出于控制系统的故障，一个小小的疏漏往往会造成上千万美元的损失。由此可见，软件错误的后果是十分严重的，医疗软件的错误可能造成病人的生命危险，银行系统的错误会使金融混乱，航管系统的错误会造成飞机失事等等。

　　由于认识到软件的设计、实现、维护和传统的工程规则有相同的基础，于是北大西洋公约组织（NATO）于1967年首次提出了"软件工程（Software Engineering）"的概念。关于编制软件与其他工程任务类似的提法，得到了1968年在德国召开的NATO软件工程会议的认可。委员会的结论是，软件工程应使用已有的工程规则的理论和模式，来解决所谓的"软件危机"。
　　软件危机至今仍然困绕着我们，这表明软件生产过程在许多方面和传统的工程相似，但却具有独特的属性和问题。