40
年前，人们就开始讨论“软件工程”这样一个话题，但至今软件工程依然不太成熟，例如今天的软件质量水平依旧不高，软件的开发模式还在探索之中，而这一切主要归结于软件技术的日新月异的变化和软件自身的复杂特性。互联网的普及将软件技术的变化推向新的高潮，人们借助互联网的力量可以随时随地沟通、协作，可以共享知识、技能和经验，甚至可以积聚全世界的力量共同探讨同一个技术主题，所有这些极大地推动软件技术的发展。而在这同时，软件产业也在悄悄地发生着巨大的变化，从传统的软件产品销售模式向软件服务模式转化，软件即服务（software as a service）或按需服务（ondemand service）的趋势越来越明显，其中最具代表性的服务就是Salesforce。Salesforce为中小型企业提供各种业务应用的在线服务，每年以80%的速度增长，客户满意度高达97%，从销售团队自动化到合作伙伴关系管理、市场营销和客户服务，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） 不断重复上面的步骤（3）和步骤（4）。
（6） 鉴于市场方面的压力，为了配合当初制定的过分乐观的发布时间表，产品还是按时上市了。
（7） 用户发现了不少问题（近百个Bug），反馈到研发部。
（8） 已经领了项目奖金的程序员不知跑到哪里去了。
（9） 新组建的项目组差不多修正了全部Bug，但测试组又发现了80多个Bug。
（10） 早先离开的程序员打电话给测试组，将他们挖走。
（11） 公司的软件发布更快了，因为现在是开发人员自己来测试自己写的程序，发现的缺陷很少。
（12） 客户发现的问题越来越多，抱怨越来越多。
（13） 客户开始减少得很快，公司很快倒闭。
（14） 新的公司被组建，新进来的程序员写出自认为没有Bug的代码。
软件需求总是变化的，这种变化来源于客户需求的变化，其中许多变化不是用户驱动的而是由竞争对手驱动的。许多需求的变化导致产品架构变化，原先的设计和实现不能适应这种变化，就必须重新设计和重新实现，这就是重构。软件的迭代开发或重构，正是适应这种特定的需求，并日益受到重视，最终导致软件工程思想和方法的变化。
软件质量的改善，已迫在眉睫，招聘大量的测试人员可以部分地解决问题，但不能彻底地解决问题，因为质量是构建出来的，而不能靠测试测出来。当软件中存在大量的缺陷，虽然经过充分的测试，但软件发布时漏掉的缺陷可能还会不少，而且测试、开发人员的返工引起的代价很大。所以，要真正提高质量，要将需求、设计和编码等各项工作做好，归纳起来，做每项工作的时候，第一次就把它做对，这就是缺陷预防的思想。
本书在交代了软件危机、软件过程内容、软件工程目标和要求等基础之上，强调建立正确的软件工程思想，思想是万物之源，思想会决定流程和方法。另一方面，思想需要借助特定的方法来实现，而方法需要付诸于实践、由实践来检验。这就是本书的基本构思，从思想到方法，从方法到建模，再到软件环境、工具，逐步向前推进，不断揭示软件工程的内涵。通过软件工程的思想、方法、技术和工具的全面介绍，帮助读者了解完整的软件工程体系，为将来深入地学习需求工程、软件设计、软件测试等课程打下坚实的基础。通过下表，可以更清楚本书的写作思路，更好地学习本书的内容。
问题章节、内容
什么是软件工程
为什么要讨论软件工程1.1软件危机
1.2软件的问题在哪里
1.3软件工程的诞生
1.4软件工程的命题
软件工程包含哪些内容
在软件工程中要学习哪些知识1.5软件工程知识体系
过去几十年，软件工程发生了哪些变化
为什么会发生这些变化1.6现代软件工程
如何理解软件工程
成功的软件工程是怎样的2.1完整的软件生命周期
2.2需求工程
2.3设计
2.4实施
2.5部署、运行和维护
2.6软件非工程过程
软件工程带来的益处又是什么
软件工程的基本思想是什么3.1软件工程的基本目标
软件工程中有哪些要求
软件工程中要考虑的因素有哪些3.2软件工程的影响要素
3.3软件工程的业务需求
3.4软件工程的质量要求
3.5软件工程的成本要求
3.6软件工程的资源限制
如何指导软件工程的开展
软件工程的思想4.2以人为本
4.3软件开发不是一门艺术
4.4向传统工业学习
4.5软件工程的例外
4.6软件工厂思想
7.1环境造就软件
如何开展软件工程
开展软件工程有哪些方法第4章软件工程思想
5.1软件方法论
5.2用户需求的获取方法
5.3软件工程的分析方法
5.4软件工程的设计方法
5.5软件测试方法
软件工程实施中最关键的是什么
如何保证软件工程实施顺利6.2软件建模
7.2软件工程组织
7.3软件工程文化
7.4软件工程基础设施
8.3制定计划
8.4资源管理
8.5进度和成本管理
8.6质量管理
8.7风险管理
8.8软件配置管理
8.9项目跟踪和控制
续表
问题章节、内容
如何更有效地实施软件工程6.3元建模
6.4建模语言和UML
9.3商业工具解决方案
9.4开源工具集成的解决方案
如何改进软件工程
如何更好地理解软件过程
6.5.1瀑布模型的不足
6.5.2V模型诠释软件过程
6.5.3没有统一天下的RUP
6.5.4MSF的过程模型
7.5过程定义
7.6过程评估和改进
本书特别重视理论与实践相结合，使读者既能领会软件工程的思想和方法，又能将这些思想、方法等应用到实际工作中去。因此，本书既适合作为计算机软件、软件工程等学科的大学教材，也适合从事软件工程人员阅读，包括软件项目经理、软件开发人员和软件测试人员。
由于作者水平有限，本书难免会存在一些差错，恳请读者及时提出宝贵意见。
作者
2008年6月
