软件工程的核心是什么？

     我们经常做一件事情，时间做久了，忘记了当初的旨意。在软件工程中，人们谈过程、谈规范、谈过程改进，结果将为什么要搞软件工程的最初动机给忘了，舍本求末。

做任何事情，都要清楚其目标才能把事情做好。软件工程旨在提高软件开发的效率和软件产品的质量，这是最基本的两项目标。在任何时刻、做任何事情，“质量”和“生产力”都是工作的核心，也就是时时刻刻要问自己这样一个问题——如何以低成本、高效率开发出更优秀的软件？用通俗的语言来概括软件工程的基本目标，那就是“多、快、好、省”四个字。

• 多——更多地实现客户所需要的功能，产品的功能特性越强，越能满足用户更多的需求。
• 快——开发效率高、开发周期被缩短，项目在预期内完成或提前完成。
• 好——所开发出来的产品质量高，产品性能稳定、实用性强、可扩展性高，能切切实实满足客户的需求。
• 省——开发的成本低，用最小的代价开发出特定的功能。

在这4个目标中，“好”是最重要的，也就是说，质量是核心，以质量为中心，在“多、快和省”上面获得最佳平衡。软件工程的实施不是虚的，是实实在在的，其结果就是使软件企业能够开发出品质好的软件或提供优质的软件服务，而且开发速度快、成本低、维护容易，这也是企业所期望的。如果达到这些基本目标，就说明软件工程在企业应用获得成功。

 

 

     我的新书《软件工程导论》围绕软件工程最基本的核心——“质量和生产率”展开，力求通过一些具体的实例来说明软件工程的思想和方法。这本书内容丰富，构思新颖，突破软件工程图书的传 统框架，使整个软件工程体系更清晰，从思想和管理出发，自然延伸到流程、方法、工具和环境，重新阐释了软件工程体系。而且，吸收了软件工程的最新进展，适 应软件即服务（SaaS）的开发模式，增加了相应的内容，符合当今软件工程的实际需求。

    四十年前，人们就开始讨论“软件工程”这样一个话题，但至今软件工程依旧不是很成熟，例如今天的软件质量水平依旧不高，软件的开发模式还在探索之中，而这一切主要归于软件技术的日新月异的变化和软件自身的复杂特性。互联网的普及将软件技术的变化推向新的高潮，人们借助互联网的力量可以随时随地沟通、协作，可以共享知识、技能和经验，甚至可以积聚全世界的力量共同探讨同一个技术主题，所有这些极大地推动软件技术的发展。而在这同时，软件产业也在悄悄地发生着巨大的变化，从传统的软件产品销售模式向软件服务模式转化，软件即服务（Software as a Service）或按需服务（On-demand service）的趋势越来越明显，其中最具代表性的服务就是Salesforce，每年以80%速度增长，客户满意度高达97%。Salesforce为中小型企业提供各种业务应用的在线服务，从销售团队自动化到合作伙伴关系管理、市场营销和客户服务，Salesforce重新定义客户关系管理。企业不再需要部署自己的服务器、不需要购买软件等，只要按照自己的实际需求，访问Salesforce.com以获得自己所需要的业务处理功能，每个月或每年只要付出很低的服务费。软件开发模式，也自然随着SaaS模式诞生而正在发生巨大的变化，有必要在这关键时刻重新审视软件工程的思想、方法和实践，这也是本书写作的主要理由。

软件工程不仅面临着技术突飞猛进的挑战，还要面临需求变化频繁、质量难以控制的巨大挑战。下面两个例子，某种程度上说明了这种挑战的严峻性。

 

 

 

例一：交通红绿灯的需求变化 大家都非常熟悉街道上的红绿灯，可以根据不同方向的车流量和人流量，进行调节，实施智能控制。但早期的红绿灯，可不是这样的，非常简单，一个方向红的时候则另一个方向绿，每隔60秒交替变化，这时用简单的定时模拟电路控制就可以了。 后来，人们觉得这样的设计不够人性化，中途经过十字路口的行人或驾驶员不知道要等多少时间，绿灯才会亮。所以，加上一个数字计时器，显示剩下的等待秒数。这时，模拟电路控制就必须改为数字电路，需要重新设计和实现。 再到后来，人们发现一个十字路口的两个方向，车/人流量是不一样的，需要调整不同方向的红绿灯切换的间隔时间，例如一个方向是75秒而另外一个方向是25秒。而且，将来的车流量会发生变化，即红绿灯间隔时间用户可自行设置，这样要求原来的数字电路或控制程序进行修改，这种改动可能很大，需要修改设计和修改实现。

 

例二：简单又挖苦地讽刺软件工程的现状 (1)程序员写出自认为没有Bug（缺陷）的代码。 (2)软件测试，发现了100个Bug。 (3)程序员修改了50个Bug，并告诉测试组另外50个Bug不是Bug。 (4)在已修正的50个Bug中，测试组验证时，发现其中20个仍然存在，同时又发现了30个新Bug。 (5)不断重复上面的步骤⑶和步骤⑷。 (6)鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品还是按时上市了。 (7)用户发现了不少问题（近百个Bug），反馈到研发部。 (8)已经领了项目奖金的程序员不知跑到哪里去了。 (9)新组建的项目组差不多修正了全部Bug，但测试组又发现了80多个Bug。 (10)早先离开的程序员打电话给测试组，将他们挖走。 (11)公司的软件发布更快来了，因为现在是开发人员自己来测试自己写的程序，发现的缺陷很少。 (12)客户发现的问题越来越多，抱怨越来越多。 (13)客户开始减少得很快，公司很快倒闭。 (14)新的公司被组建，新进来的程序员写出自认为没有Bug的代码。

 

软件需求总是变化的，这种变化来源于客户需求的变化，其中许多变化不是用户驱动的而是由竞争对手驱动的。许多需求的变化导致产品架构变化，原先的设计和实现不能适应这种变化，就必须重新设计和重新实现，这就是重构。软件的迭代开发或重构，正是适应这种特定的需求，并日益受到重视，最终导致软件工程思想和方法的变化。

  软件质量的改善，也迫在眉睫，招聘大量的测试人员可以部分地解决问题，但不能彻底地解决问题，因为质量是构建出来的，而不能靠测试测出来。当软件中存在大量的缺陷，虽然经过充分的测试，但软件发布时漏掉的缺陷可能还会不少，而且测试、开发人员的返工引起的代价很大。所以，要真正提高质量，要将需求、设计和编码等各项工作做好，归纳起来，做每项工作的时候，第一次就把它做对，这就是缺陷预防的思想。

  本书在交待了软件危机、软件过程内容、软件工程目标和要求等基础之上，强调建立正确的软件工程思想，思想是万物之源，思想会决定流程和方法。另一方面，思想需要借助特定的方法来实现，而方法需要付诸于实践、由实践来检验。这就是本书的基本构思，从思想到方法，从方法到建模，再到软件环境、工具，逐步向前推进，不断揭示软件工程的内涵。通过软件工程的思想、方法、技术和工具的全面介绍，帮助读者了解完整的软件工程体系，为将来深入地学习需求工程、软件设计、软件测试等课程打下坚实的基础。

 

 

 

 

 

 

 什么是软件工程？