1.2.5 软件危机

在计算机刚刚投入实际使用时，往往只是为了一个特定的应用而在指定的计算机上设计和编制软件，一般采用密切依赖于计算机的机器代码或汇编语言，软件的规模较小，文档资料通常也不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序，基本上是个人设计、个人使用、个人操作、自给自足的私人化的软件生产方式。

20世纪60年代中期，大容量、高速度计算机的出现使计算机的应用范围迅速扩大，软件开发的规模急剧增长，同时高级语言开始出现，操作系统的发展引起了计算机应用方式的变化，大量的数据处理促进了第一代数据库管理系统的诞生。因而软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再满足实际要求，因而迫切需要改变软件生产方式，提高软件生产率，软件危机由此开始爆发。

软件危机是指在软件开发和维护过程中遇到的一系列严重问题，表现为：

●软件开发进度难以预测，拖延工期几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉；

●软件开发成本难以控制，投资一再追加，实际成本往往比预算成本高出一个数量级，而为了赶进度和节约成本所采取的一些权宜之计又往往降低了软件产品的质量，不可避免地会引起用户的不满；

●用户对产品功能难以满意，开发人员和用户之间很难沟通、矛盾很难统一，原因往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和沟通，在双方互不充分了解的情况下就仓促设计系统、匆忙着手编写程序，必然导致最终产品不符合用户的实际需求；

●软件产品质量无法保证，系统中的错误难以消除，原因在于软件是逻辑产品，质量问题很难使用统一的标准进行度量，从而造成质量控制的困难，另外盲目的检测很难发现软件产品中的所有错误，隐藏下来的错误往往是造成重大事故的隐患；

●软件产品难以维护，表现在软件本质上是开发人员代码化的逻辑思维活动，他人难以替代，除非是开发者本人，否则维护人员很难及时检测、排除系统故障，另外，为使系统适应新的硬件环境或根据用户的需要在原系统中增加的一些新功能，又有可能造成系统中的新错误；

●软件缺少适当的文档资料，文档资料是软件中必不可少的重要组成部分，是开发组织和用户之间的权利和义务的合同书，是系统管理者、总体设计者向开发人员下达的任务书，是系统维护人员的技术指导手册，是用户的操作说明书。缺乏必要的文档资料或文档资料不合格，将给软件开发和维护带来许多严重的问题。

因此，软件危机客观上是由于软件本身的特点造成的——软件由复杂的逻辑部件构成，同时规模又十分庞大；主观上是由不正确的开发方法造成的——开发者通常会忽视需求分析，并错误认为“软件开发=程序编写”，同时轻视软件的测试和维护。

在软件开发项目中常以人月来衡量工作量。这种度量暗示着人手和时间是可以互换的，但这种“人多力量大”的想法是一种一厢情愿的虚妄神话（见《人月神话》）。布鲁克斯法则表明：向滞后的软件项目追加人手，会使进度更加迟缓。为此提倡外科手术式的团队组织，即软件项目的核心概念要由很少的人来完成，以保证概念的完整性。另外，软件开发过程中的沟通手段非常必要，并需要保持适度的文档。需要牢记的是：在软件开发过程中，只有适度改进，没有包治百病的银弹。

目前在软件开发过程中，人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地结合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支撑环境，以期从管理和技术两个方面来解决软件危机问题。

此外，人工智能与软件工程的结合成为20世纪80年代末期开始活跃的研究领域。程序变换、自动生成和可重用软件等软件新技术研究也已取得了一定的进展，把程序设计自动化的进程向前推进了一步。在软件工程理论的指导下，发达国家已经建立起较为完备的软件工业化生产体系，形成了强大的软件生产能力。软件标准化与可重用性也得到了工业界的高度重视，在避免重复劳动、缓解软件危机方面起到了重要作用。