3.1　软件工程

3.1.1　软件危机

“软件工程”这个词是不是听着既有点熟悉又有点陌生？这几年确实提得少了，但它在当年诞生时，是具有划时代意义的。它诞生在1970年左右的“软件危机”之时，软件工程对解决软件危机很有帮助。

为什么会有“软件危机”呢？当时的情况是，落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致在软件开发与维护过程中出现一系列严重问题。

最初的程序设计往往只是一两个程序开发人员，写一个由几百行、几千行代码构成的“小玩意儿”，运行在单台机器上，供少数从事“高精尖”工作的人自给自足地用一用。这种事情，让那些天才兀自去探索就好了。

然而，随着时代的发展，软件的规模越来越大，软件越来越复杂，需要有更好的系统架构；软件开发人员变多了，他们之间需要更好地协调；软件要支撑的用户数量越来越多，需要有更好的性能和可靠性；软件要持续使用和维护的时间越来越长，需要有更好的可维护性，等等。以前的小作坊式的工作方法，当遇到这些情况时就不灵了：开发进度变得难以预测，开发成本难以控制，质量无法保证……这就是“软件危机”。

3.1.2　工程化

那么软件工程怎么解决这些问题呢？软件工程的核心思想是，把其他行业和领域里的工程化经验借鉴过来，以系统性的、规范化的、可定量的工程化方法来开发和维护软件。这包括相应的流程、工具、方法论等。

下面看一个对软件工程的典型的定义。在IEEE的软件工程术语汇编中是这么定义软件工程的：定义一，将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；定义二，对“定义一”中所述方法的研究。

接下来我们来看看软件工程的七条基本原理。

第一，用分阶段的生命周期计划严格管理。凡事预则立，不预则废。建大桥、盖高楼需要有详细的设计规划和详细的时间计划，软件的开发和维护也一样。应该把软件生命周期分成若干阶段，并相应地制订切实可行的计划：何时完成哪种类型的工作。然后严格按照计划对软件的开发和维护进行管理。这样的计划包括项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划等。

第二，坚持进行阶段评审。对软件的质量保证工作不能等到写完代码后再进行。因为根据统计，大部分错误是在编写代码之前造成的，包括需求分析方面的错误、系统设计方面的错误等。这些错误，发现并改正得越晚，所需付出的代价就越大。所以应该在每个阶段都进行严格的评审，以便尽早发现问题，尽量不让问题遗留到下一个阶段。

第三，对产品需求变更实行严格的控制。在软件开发过程中不应随意改变需求，因为改变需求往往意味着改变计划、重新做系统分析和设计、重新编写代码等，代价往往比较大。当然也不能一刀切地禁止改变需求：在软件开发过程中改变需求是难免的，由于外部环境等因素的变化，相应地改变产品需求是一种客观需要。所以，对需求变更需要进行严格的评审，从多个角度综合考虑，确实需要变更时再变更。并且当需求变更时，要保证其他各个阶段的文档和代码都随之相应地改变。

第四，采用现代程序设计技术。从结构化软件开发技术到后来的面向对象技术等，从第一代语言到第四代语言，人们在不断探索。采用先进的技术，既可以提高软件开发效率，又可以降低软件维护成本。

第五，对中间成果应能清楚地审查。必须找到一种方法，在软件开发项目的最终成果，也就是软件，最终运行起来之前，就能够探测到项目的进度和质量，以便更好地管理和降低风险。为此，软件开发过程中的各项活动，要产生可见的中间产物，比如需求文档、设计文档等。

第六，开发人员应该少而精。开发人员的素质和数量是影响软件质量与开发效率的重要因素，开发人员应该少而精。高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，在开发工作中犯的错误也要少得多。此外，随着人数的增加，沟通和协作的成本会显著增加。通过这个简单的模型就能看出来：当开发小组为N人时，可能的通信信道为N(N-1)/2个。

第七，承认不断改进软件实践的必要性。我们不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度、问题等数据，进行统计和报告。这些数据既可以用来评估新的软件技术的效果，也可以用来指明必须着重注意的问题，以及应该优先进行研究的工具和技术。

以上七条基本原理，主要就是在说，我们要采用工程化的方法来开发软件。

今天我们听到的很多耳熟能详的词汇，都是从那个时代流传下来的。比如：结构化编程、面向对象、需求分析、软件规格说明书、软件质量保证、软件配置管理、可维护性、可追踪性等。软件工程的思想和方法是前人的非常有价值的积累与沉淀，在很大程度上仍在指导着我们的工作。