软件（Software）是一系列按照特定顺序组织的计算机数据和指令的集合。软件一般被划分为系统软件、应用软件和介于这两者之间的中间件软件。软件并不是只包括可以在计算机（这里的计算机是指广义的计算机）上运行的程序，与这些程序相关的文档、数据等元素一般也被认为是软件的一部分。

随着计算机技术的迅速发展和广泛应用，软件从最初的计算机硬件的附属品，仅仅作为计算机硬件的运行和做一些简单的计算与数据处理的程序，发展到今天大规模的封闭或开放式的系统软件和应用软件。有的软件的源代码甚至超过千万行。例如，美国阿波罗计划的软件长达1000万行，航天飞机计划的软件更是长达4000万行，桌面操作系统为千万级量级规模。

软件是抽象的，是人类逻辑思维的产物，它不受物质材料的限制，也不受物理定律或加工过程的制约，这一特性使软件工程得以简化，因为软件的潜能不受物理因素的限制；另外一方面，由于缺乏自然约束，软件系统的实现在实施过程中，容易变得极为复杂，理解它会很困难、改变它付出的代价更加高昂。软件规模的增长，使其复杂度也随之大大增加，而高复杂度和高可靠性的不相容性，使得软件可靠性随着其规模的增长而降低，质量难以保证，维护愈加困难，投资预算很难控制，传统的软件研制开发方法已无法适应大规模软件的开发需求。

为了解决在软件开发和维护过程中遇到的一系列软件危机的严重问题，1968年，北大西洋公约组织（NATO）的科学家和官员们在原德意志联邦共和国召开的国际会议上讨论并首次提出了软件开发要工程化。当时，单个的程序开发技术已经不能扩展并应用到大型的、复杂的软件系统中。软件项目有时甚至要推迟几年才能完成，不仅比预计的费用高且难以维护。软件工作者开始认真研究消除软件危机的途径，从而逐渐形成了一门新兴的工程学科——计算机软件工程学（Software Engineering），简称软件工程。软件工程是一门工程学科，涉及软件生产过程中的各个方面，从最初的问题提出一直到投入使用后的系统维护，都属于其学科研究范畴。

一、软件危机

1．摩尔定律和超越摩尔

1965年，Intel联合创始人戈登·摩尔提出了著名的理论：半导体芯片上可集成的元器件的数目每18个月便会增加一倍。也就是说，同样规格的芯片的成本，每18个月便会降低一半。1965年每个芯片可以容纳50个晶体管，摩尔预测到1970年，每个芯片将能够容纳1000个元器件，每个晶体管的价格会降低90％。

经过简化，这个发现被归纳为“摩尔定律”：每个芯片上晶体管的数目每12个月将会增加一倍。戈登·摩尔的发现不基于任何特定的科学或工程理论，只是真实情况的映射总结。硅芯片行业注意到了这个定律，没有简单地把它当作一个描述的、预言性质的观察，而是作为一个说明性的、重要的规则、整个行业努力的目标。

除此之外，还有一个与摩尔定律相对的洛克定律（Rock＇s law），强调了生产中的成本因素。通过观察可知，芯片制造厂商的成本每4年便会增加一倍。技术的进步以不断为芯片上晶体管数量的增加铺平道路，但是芯片生产设施的建造会十分昂贵，而更小、更便宜的处理器的使用还在不断增加。

硬件技术在不断发展，但现在，这种发展轨迹要告一段落了。由于同样小的空间里集成越来越多的硅电路，产生的热量也越来越大，这种原本两年处理能力加倍的速度已经慢慢下滑，原本的摩尔定律在逐步失效。目前，行业研究规划蓝图新的战略是“超越摩尔”（More than Moore）：与以往首先改善芯片、软件随后跟上的发展趋势不同，以后半导体行业的发展将首先看软件——从手机到超级计算机再到云端的数据中心——然后反过来看要支持软件和应用的运行需要什么处理能力的芯片来支持。

这种局势的转变使得人们更加强调软件的重要性。计算机的应用日益广泛、深入，然而硬件的进步只是为计算机系统提供了潜在的能力，如果没有软件来驾驭和开发这种能力，人类并不能有效地使用计算机，因此，软件已成为限制计算机系统发展的关键因素。

计算机软件是一个逻辑的而非物理的系统，它具有与硬件显著的不同特点。它的主要工作集中在定义、开发、维护等纯智力活动方面。随着软件需求的剧增，软件规模不断增大，软件数量急剧膨胀。在程序运行时发现的错误必须设法改正；用户有了新的需求时必须相应地修改程序；硬件或操作系统更新时，通常需要修改程序以适应新的环境。上述种种软件维护工作，以令人吃惊的比例耗费资源。更严重的是，许多程序的个体化特性使得它们最终成为不可维护的。软件危机就这样开始出现。

2．软件危机的概念

软件危机（Software Crisis）是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题，也可以指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。

广义上讲，所谓软件危机包含两方面问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。

狭义上讲，所谓软件危机主要有以下一些典型表现：

（1）对软件开发成本和进度的估计常常很不准确。实际成本比估计成本有可能高出一个数量级，实际进度比预期进度拖延几个月甚至几年的现象并不罕见，这种现象降低了软件开发组织的信誉。而为了赶进度和节约成本所采取的一些权宜之计又往往降低了软件产品的质量，从而不可避免地会引起用户的不满。

（2）开发人员和用户之间很难沟通，矛盾很难统一。往往是软件开发人员不能真正了解用户的需求，而用户又不了解计算机求解问题的模式和能力，双方无法用共同熟悉的语言进行交流和描述。在双方互不充分了解的情况下，就仓促上阵设计系统、匆忙着手编写程序，这种“闭门造车”的开发方式必然导致最终的产品不符合用户的实际需要。

（3）大型软件项目需要组织一定的研发人力共同完成。软件项目管理人员缺乏开发大型软件系统的经验及软件开发各类人员的信息交流不及时、不准确，有时还会产生误解，这些都会导致软件质量无法得到保证。

（4）软件系统中的错误难以消除。软件是逻辑产品，质量问题很难以统一的标准度量，因而造成质量控制困难。软件产品并不是没有错误，而是盲目检测很难发现错误，而隐藏下来的错误往往是造成重大事故的隐患，这些都会导致软件产品出现质量问题。

（5）软件常常是不可维护的。很多程序中的错误是非常难改正的，实际上不可能使这些程序适应新的硬件环境，也不能根据用户的需求在原有程序中增加一些新的功能。“可重用的软件”还是一个没有完全做到的、正在努力追求的目标，人们仍然在重复开发类似的或基本类似的软件。

（6）软件通常没有适当的文档资料。错误的观点经常认为：软件就是程序。程序代码写完软件也就设计完了。实际上软件不仅仅是程序，还应该有一整套文档资料。这些文档资料应该是软件开发过程中产生出来的，而且应该是和程序代码完全一致的。软件开发过程中，基线是软件文档和源代码的一个稳定版本，它是进一步开发的基础。软件开发组织的管理人员可以使用这些文档资料作为“里程碑”，来管理和评价软件开发工程的进展状况；软件开发人员可以利用它们作为通信工具，在软件开发过程中准确地交流信息；对于软件维护人员而言，这些文档资料更是必不可少的。缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的困难和问题。