第章软件工程概述 -...

软件工程概述第 1 章

本章讨论以下内容：

软件工程的含义；软件工程的发展历程； “好的软件”的含义；为什么系统的方法是重要的；自20世纪70年代以来，软件工程是如何变革的。

软件在生活中随处可见，我们时常认为，软件理所当然地应该使我们的生活更加舒适、高效和

有效。例如，准备早餐面包这样一个简单的任务中，烤箱中的代码控制面包颜色的深浅，以及何时

将烤好的面包弹出；住宅的电力供应由程序控制和调节；能源使用的账单均由软件记录输出。实际

上，我们可以使用自动化程序支付电费账单、订购更多食品，甚至购买一台新烤箱！现在，几乎在我

们生活的各个方面，包括影响我们健康和福利的关键系统，软件都发挥着作用。正因为如此，软件工

程比以往任何时候都更加重要。好的软件工程实践必须确保软件在我们的生活中发挥积极的作用。本书强调软件工程中的关键问题，描述我们所了解的技术和工具，以及它们如何影响我们构建

和使用的终软件产品。我们将从理论和实践两个方面说明我们所了解的软件工程以及如何将其应

用于通常的软件开发或维护项目中。我们也将研究那些我们还不了解但有助于使产品更加可靠、安

全、有用、易理解的理论和实践。首先，我们探讨如何分析问题以及寻求解决方案。然后，研究计算机科学问题与工程问题之间的区

别。我们的终目标是，生产出高质量软件，进而找到解决方案，并考虑那些对质量有影响的特性。 1

我们还将探讨软件系统的开发人员已经取得了多大的成功。通过对几个软件失效的例子进行研

究，可以了解在掌握高质量软件开发的艺术方面，软件系统的开发人员已经取得的进展以及还需要

在哪些方面做出努力。接着，探讨软件开发涉及的人员。在描述客户、用户和开发人员的角色和责任之后，会转而研

究系统本身。我们看到，可以把一个系统看作是与活动相关的一组对象，并且处于某个边界之内。

或者，我们从工程师的角度考虑系统：可以像盖房子一样开发一个系统。在定义了构造系统的步骤

以后，将讨论每个步骤中开发团队的角色。后，讨论影响我们实践软件工程方式的一些变化，给出Wasserman的将实践融为一体的8个概念。

1.1 什么是软件工程

软件工程师要利用与计算机和计算相关的知识来解决问题。通常情况下，我们要处理的问题是

与计算机或现有的计算机系统相关的。但是，也有时候，解决问题的潜在困难与计算机无关。因此，

首先要理解问题的本质，这是至关重要的。尤其是，我们必须十分谨慎，不要把计算机器或技术按

我们的意愿强加给遇到的每个问题。我们必须首先解决这个问题。然后，如果需要的话，再把技术

2 第 1 章软件工程概述

作为工具来实现我们的解决方案。本书假定，我们的分析已经表明，某种计算机系统对于解决手头特

定的问题是必需的或是合适的。

1.1.1 问题求解

多数问题是大型问题，往往难以处理，尤其是，当它含有一些以前从未解决过的新问题的时候。因

此，首先要通过分析（analyzing）对问题进行研究，也就是说，将问题分解成可以理解并能够处理的若

干小的部分。这样，就可以将较大的问题变为一组较小的问题以及它们之间的关系。图1-1说明了如何进

行分析。子问题之间的关系（用图中的箭头以及子问题的相对位置来表示）与子问题本身同样是非常重

要的。有时，正是这种子问题之间的关系而不是子问题本身提供了解决大型问题的线索。

问题

子问题4子问题1 子问题2 子问题3

图1-1 分析的过程

一旦分析了这个问题之后，就需要根据针对问题不同方面的构件来构造解决方案。图1-2说明了

这样的逆向过程：合成（synthesis）是把小的构造块组合成一个大的结构。如同分析一样，将每个解

决方案组合在一起可能与寻找解决方案本身同样具有挑战性。要了解其中的原因，可以考虑写一本

小说的过程：字典中包含了写作过程中可能用到的所有单词，但是，写作困难的部分是决定如何

将单词组织好写成句子，以及如何将句子组织为段落，乃至于如何把章节组织成一本完整的书。因

此，任何问题求解技术都必须包括两部分：通过分析问题来确定问题的本质含义，然后，再基于分

析来合成解决方案。

解决方案4解决方案1 解决方案2 解决方案3

解决方案

2

3

~

图1-2 合成的过程

1.1 什么是软件工程 3

为了帮助我们解决问题，我们会采用各种方法、工具、过程和范型。方法（method）或技术

（technique）是产生某些结果的形式化过程。例如，厨师可能使用严格定时的、有序的方式，把一系

列调料成分组合成调味汁，使得调味汁变稠，但不会凝结或散开。调制调味汁的过程包括时间选择

和调料成分，但并不依赖于使用了哪种烹饪设备。工具（tool）是用更好的方式完成某件事情的设备或自动化系统。这个“更好的方式”可能是工具使

我们更精确、更高效或生产率更高，也可以是它能够提高终产品质量。例如，我们使用打字机或

者键盘加打印机来写信，因为这样写出的信件比手写的更易于阅读。再如，我们使用剪刀作为工具

是因为用它裁纸要比直接用手撕纸更快、更整齐。然而，要做好一件事情，工具并不总是必需的。

例如，使调味汁更美味的是烹调技术，而不是厨师用的锅和羹匙。过程（procedure）如同食谱：把工具和技术结合起来，共同生产特定产品。例如，就像后面的章节

所论述的那样，测试计划描述测试过程：它告诉我们，在什么情况下将使用哪种工具处理哪个数据

集，以便我们能够确定软件是否满足了需求。后，范型（paradigm）就像烹饪风格。它表示构造软件的特定方法或哲学。就像我们能够区

分法国菜烹饪法与中国菜烹饪法一样，我们也能够区分面向对象开发和过程开发这样的范型。并不

是某一种范型就一定比另一种范型好，每一种范型都有其各自的优缺点，只是在某些情况下，一种

范型可能要比另外一种范型更合适。软件工程师使用工具、技术、过程和范型来提高软件产品的质量。他们的目标就是使用高效的、

高生产率的方法形成相关问题的有效解决方案。下面的章节将重点介绍支持我们所说的开发和维护

活动的特定方法。读者可以在本书的万维网主页中找到相关工具和技术的新链接。

1.1.2 软件工程师的角色是什么

要理解软件工程师在计算机科学领域中所扮演的角色，我们先看看另外一个学科的例子。考虑

一下化学研究以及用它来解决问题这两者之间的区别。化学家研究化学物质：它们的结构、它们的

相互作用以及现象背后的理论。而化学工程师则用化学家的研究结果解决各种问题。化学家将化学

作为研究对象；但对化工人员而言，化学是用来解决一般问题（这个问题本质上甚至可能不是“化

学”领域的问题）的工具。我们可以从类似的角度看待计算技术。人们可以集中精力研究计算机和程序设计语言，也可以

把它们看作是用于设计和实现问题解决方案的工具。软件工程显然属于后一种情形，如图1-3所示。

软件工程师的精力集中于把计算机作为问题求解的工具，而不是研究硬件设计或者算法的理论证明。

在本章的后面，我们会了解到，软件工程师使用计算机的功能进行工作，并将其作为一般解决方案

的一部分，而不是研究计算机本身的理论和结构。 4

计算机科学客户

计算机功能

理论问题

软件工程

问题求解的

工具和技术

图1-3 计算机科学和软件工程之间的关系


1.2 软件工程取得了哪些进展

编写软件既是一门艺术也是一门科学。作为一名计算机专业的学生，深入理解这句话是非常重

要的。计算机科学家和软件工程研究人员研究的是计算机的机制，并建立起使它们具有更高生产率、

更有效的理论。但同时，他们也设计计算机系统并编写程序，执行相关任务，这是一项融合艺术、

天赋和技巧的实践性工作。在具体的系统上执行特定任务，可能会存在很多方法，但是，某一种方

法可能更有效、更精确、更易于修改、更容易使用或更便于理解。任何黑客都能够编写代码完成工

作，但是，要写出健壮的、易于理解和维护的并且能以高效的方式完成工作的代码，必须具备专

业软件工程师的技巧和洞察力。因此，软件工程的目标就是设计和开发高质量软件。在学习生产高质量软件系统所需要的知识之前，先回头了解一下我们取得了哪些成就。考虑这

样一个问题：用户是否对现有软件系统感到满意？答案可能是“满意”，也可能是“不满意”。一方

面，软件使我们比以往任何时候都能够更快、更有效地完成任务。例如，想一下，在字处理、表格

处理、电子邮件或网络电话等现代化技术出现之前，人们的生活是怎样的呢？软件支撑着医学在生

命维持治疗或生命救治方面的进展，以及农业、交通和其他诸多产业取得进展；另外，软件已经使

我们能够做到以前从来不敢想象的事情，如显微外科手术、多媒体教育、机器人等。 5

但是，软件也不是完美无缺的，系统的功能通常并不完全符合用户的期望。我们都听说过系统

几乎不能运行这样的事情。我们所有人都编写过有故障的程序：代码包含错误，但也刚好可用或足

以证明一个方法的可行性。显然，如果开发出这样的系统交付给客户，客户是不能接受的。课程项目中的错误和大型软件系统中的错误不可同日而语。事实上，软件故障和生产无故障软

件的困难性是文献和闲谈中经常讨论的问题。有些故障仅仅是令人讨厌，而有一些故障则会耗费大

量的时间和金钱，甚至还有一些可能会危及生命。补充材料1-1解释了故障、错误和失效之间的关系。

我们在此讨论几个关于故障的例子，看一看问题出在哪里以及其中的原因是什么。

补充材料1-1 描述“bug”的术语

我们常常会谈到软件中的“bug”，根据不同的上下文，它有多种含义。“bug”既可以指解释

需求时犯的错误，也可以指一段代码中的语法错误，还可以指由于未知因素引起系统崩溃的原因。

IEEE有描述软件产品（IEEE 1983）中“bug”的标准术语（见IEEE标准729）。当人们在进行软件开发活动的过程中出错时（称为错误（error）），就会出现故障（fault）。例

如，设计人员可能误解了某个需求，创建出与需求分析人员和用户的实际意图不相符的设计。这

个设计故障是一种错误的编码，可能导致其他故障，如不正确的代码或用户手册中不正确的描述

等。因此，单个错误可能产生多个故障，并且故障可能驻留在任何开发或维护的产品中。失效（failure）是指系统违背了它应有的行为。它可能会在系统交付前或交付后被发现，也

可能在测试过程中或者在运行和维护的过程中被发现。我们在第4章会看到，需求文档可能会包含

故障，所以即使系统按照需求规格说明来运行，如果它未进行应有的行为，也称为失效。因此，故障是系统的内部视图，这是从开发人员的角度看待系统；而失效是系统的外部视图，

它是用户所看到的问题。并非每一个故障都对应于一个失效，例如，如果不执行故障代码，或者

不进入某个特定状态，那么故障就不会使代码失效。图1-4说明了失效的起源。

可能导致可能导致

人为错误故障失效

图1-4 人为错误是如何引起失效的 6

1.2 软件工程取得了哪些进展 5

20世纪80年代早期，美国国家税务局（Internal Revenue Service，IRS）雇佣Sperry公司构建一个

联邦收入所得税表格自动处理系统。根据《华盛顿邮报》的报道，“系统……被证明难以承载当前的

工作负荷，成本几乎是预算的两倍，必须尽快更换”（Sawyer 1985）。在1985年，还需花费额外的9千万美元来升级Sperry公司初价值1.03亿美元的设备。另外，因为出现的问题妨碍了IRS在后期

限前及时向纳税人退税，IRS被迫向纳税人支付4020万美元的利息，并且要向自己的员工支付2230万美元的加班工资。到1996年的时候，情况仍未改善。《洛杉矶时报》在3月29日报道：除了6000页的技术文档外，目前系统的升级仍未有整体规划。国会议员Jim Lightfoot把这个项目称为“因为规划

失当而正在挣扎的40亿美元的惨败”（Vartabedian 1996）。诸如此类的情况仍然时有发生。在美国，联邦调查局（FBI）的“三部曲”（Trilogy）项目尝试

着更新FBI的计算机系统。但其结果却是毁灭性的：“经历了千年的艰苦工作，花费了5亿美元，但是，

据报道：‘三部曲’项目几乎没有改善陈旧的案例管理系统，迄今为止，该系统仍然混乱不堪，深陷

于带有绿色屏幕的大型机和大量的纸介档案之中。”（Knorr 2005）。类似地，在英国，对“国家保健

服务信息系统”的大修，耗费了原来估算的两倍（Ballard 2006）。第2章将讨论为什么项目计划对于

高质量的软件产品是至关重要的。多年来，公众在日常生活中不断被灌输：软件不存在问题。但里根总统提出的主动战略防御

（Strategic Defense Initiative，SDI）增强了公众对开发无故障软件系统的困难性的认识。报纸和杂志

上一些有影响的报道（比如Jacky 1985, Parnas 1985, Rensburger 1985）描述了计算机科学界中的怀疑

论的观点。20年后的今天，当美国国会被要求拨款来建立一个类似系统的时侯，许多计算机科学家

和软件工程师仍然认为，在编写和测试软件时，没有办法确保它具备充分的可靠性。例如，许多软件工程师认为反弹道导弹系统至少需要1千万行代码，有些人甚至估计其代码量会

高达1亿行。相比较而言，支持美国航天飞机的软件只包含300万行代码，包括控制发射和飞行的地

面控制计算机所用的程序。1985年，航天飞机上只有10万行代码（Rensburger 1985）。因此，反导弹

软件系统将需要海量的代码测试。再者，可靠性约束是无法测试的。要了解其中的原因，考虑安全

攸关（safety-critical）软件的概念。通常我们说某些事情是安全攸关的（即这些事情的失败会对生命

或健康构成威胁），则其可靠性至少应当是10−9。正如我们将在第9章中看到的那样，这意味着系统在

109小时的运行期间其失效不能超过一次。要观察可靠性的程度，这个系统应运行至少109小时来验证

它不会失效，但是109小时是114 000多年——作为一个测试时间段来说，它实在是太长了！我们在第9章中还将看到，当软件设计有误或编程有误的时候，原本有用的技术可能会变成致命的。

例如，当Therac-25（一种射线疗法和X光设备）发生故障并致使几个病人死亡的时候，医学界变得惊

恐万状。软件设计人员没有预料到会有不按操作规范使用几个方向键的情况。其结果是，当需要低剂

量的射线束时，软件却保持高剂量的设置并发出了极为集中的射线束（Leveson and Turner 1993）。 7

很容易找到类似的意想不到的使用方式的例子。例如，近使用一些商业现货构件（作为节省

开支的手段，而不是对软件的定制加工）导致以一种原先设计者未曾设想的方式使用这些构件的设

计。许多许可协议明确地指出这种意想不到的使用方式所带来的风险：“因为每一个终端用户系统都

是定制的，并且与该软件所使用的测试平台不同；还因为用户或应用设计人员将其他产品结合在一

起，以厂商或供应商未曾评估或未曾考虑过的方式使用该软件，因此，用户或应用设计人员终对

该软件的验证和确认负责。”（Lookout Direct，未注明出版日期。）在整个软件设计活动的过程中，必须考虑对系统意想不到的使用方式。至少可以用两种方式来

处理这些非正常的使用：一是通过你的想象来考虑系统可能如何被滥用（以及正确使用），二是假定

系统将被滥用并设计软件来处理这种滥用。我们将在第8章讨论这些方法。尽管许多厂商努力设计零缺陷的软件，但事实上，大多数软件产品都不是无故障的。市场压力

促使软件开发人员快速交付产品，几乎没有时间进行完全的测试。通常，测试小组只能测试那些

有可能用到的功能，或那些有可能危及用户或激怒用户的功能。基于这样的原因，许多用户在安

装系统的时候，第一个版本时都很谨慎。他们知道，直到第二个版本，这些“bug”才会得到解决。


此外，对已知故障进行修复有时是非常困难的，甚至重写整个系统都要比改变现有代码更加容易。

我们将在第11章中探讨软件维护过程中所涉及的问题。尽管在现实生活中，有些软件取得了巨大成功并被全面接受，但是，我们生产的软件的质量仍

然有很大的改进余地。例如，缺乏质量的代价是高昂的，一个故障未被检测到的时间越长，改正它

的花费就越大。尤其是，在项目初的分析阶段改正一个错误，比起把系统移交给客户再去改正，

所需成本只有后者的1/10。不幸的是，我们没有在早期捕捉到大多数的错误。改正在测试和维护过

程中发现的故障的一半成本，是来自于系统生命周期的更早阶段所犯的错误。在第12章和第13章中，

我们将讨论评估开发活动有效性的方法，以及对过程加以改进以尽可能早地捕捉到错误的方法。我们提出的一种简单而有效的技术是使用评审和审查。许多学生习惯于自己开发和测试软件，

但是他们的测试并没有他们想象的那么有效。例如，Fagan研究了故障的检测方法。他发现，采用以

测试数据运行程序的方法只能找出开发阶段故障的1/5。然而，同行评审（由同事检查和评论彼此的

设计和代码的过程）能够揭示出其余4/5的故障（Fagan 1986）。因此，请你的同事来评审你的工作，

软件质量会有大幅度的提高。在后面的章节中，我们将学习如何在每个主要开发步骤之后，利用评

审和审查的过程尽可能早地发现并修复故障。并且，我们将在第13章了解到如何改进审查过程。 8

1.3 什么是好的软件

正如制造商寻找各种方法以确保他们生产的产品的质量一样，软件工程师也必须寻找各种途径

来确保他们的产品具有可接受的质量和功效。因此，好的软件工程必须总是使用开发高质量软件的

策略。但是在我们设计一个策略之前，必须理解高质量软件的含义是什么。补充材料1-2说明了不同

的视角是如何影响“质量”的含义的。在本节中，我们研究好的软件和差的软件之间的区别是什么。

补充材料1-2 关于质量的各种视角

Garvin描述了不同的人是如何认识质量的（Garvin 1984）。他从5种不同的视角对质量加以描述。 ● 先验论的观点：质量是可认知但不可定义的。 ● 用户的观点：质量是恰好达到目的。 ● 制造业的观点：质量是与规格说明的一致。 ● 产品的观点：质量是与产品的内在特征相联系的。 ● 基于价值的观点：质量取决于客户愿意支付的金额。先验论的观点很像柏拉图对理想的描述或亚里士多德关于形式的概念。换言之，就像每个真

实的桌子都是接近理想的桌子一样，我们可以把软件质量认为是我们努力的理想。然而，我们可

能永远也不能完全实现它。先验论的观点是无形的。它与用户更为具体的观点形成对照。当我们测量产品特性（如缺陷

密度或可靠性等）的时候，为了理解整个产品质量，我们采用用户的观点。制造业的观点是在开发过程中以及交付后考虑产品质量。尤其是，它检查产品是否第一次就

构建正确，以避免花费大量重复劳动去修复产品交付后的故障。因此，制造业的观点是过程的观

点，它提倡遵守良好的过程。然而，几乎没有什么证据能够说明遵守过程就会真正生产出含有较

少故障或失效的产品。过程可能确实会导致高质量的产品，但是也可能使生产低质量的产品成为

制度化。我们将在第12章分析其中一些问题。用户和制造业的观点从外部来考虑产品，而产品的观点是从产品内部考察产品并评估产品的内在

特性。这通常是软件度量专家所提倡的观点之一，他们假设良好的内部质量指标将会导致良好的外部

质量，例如可靠性和可维护性等。然而，仍需要做更多的研究工作来对这些假设加以验证，确定哪些

方面的质量会影响产品的实际使用。我们可能必须要开发将产品观点和用户观点联系起来的模型。 9

客户或市场人员通常采取用户的观点来看待质量。研究人员有时采取产品的观点，而开发团

1.3 什么是好的软件 7

队则会持有制造业的观点。如果未对这些观点之间的差异加以明确，则由此造成的混淆和误解可

能会导致错误的决策和劣质的产品。基于价值的观点，可以将这些完全不同的质量描述联系起来。

通过将质量与客户愿意支付的价钱等同起来，我们可以在产品价格和质量之间进行权衡，当冲突

发生时能够加以控制。类似地，购买方将产品的价格与潜在的收益进行比较，他们按照金钱的价

值来考虑质量。

Kitchenham和Pfleeger在一期 IEEE Software质量专刊的导言中，研究了这个问题的答案

（Kitchenham and Pfleeger 1996）。他们指出，背景有助于答案的确定。字处理软件的容错程度在安全

攸关或关键任务的系统中，可能是无法接受的。因此，我们必须至少以3种方式考虑质量：产品的质

量、生产该产品的过程的质量以及在产品将使用的商业环境背景下产品的质量。

1.3.1 产品的质量

我们可以要求人们命名影响整体质量的软件特性，但是，从每一个我们询问的人那里得到的答

案很可能是不同的。之所以出现这种差异，是因为特性的重要性取决于分析这个软件的人。如果软

件用易于学习和易于使用的方式做了用户想要它做的事情，用户就断定软件是高质量的。但是，有

时质量和功能是相互缠绕在一起的。如果一个软件难以学习或难以使用，但是它的功能值得这些付

出，那么仍然可以认为它是具有高质量的软件。我们设法测量软件质量，以便能够将一个产品与其他产品进行比较。要做到这一点，就要找出

影响系统整个质量的那些方面。因此，在测量软件质量的时候，用户从故障数目和故障类型等外部

特性进行评价。例如，他们可能将失效分为次要的、主要的以及灾难性的，并且希望所发生的任何

故障都是次要的。软件还必须由那些设计和编写代码的人员以及维护该程序的人员来评价。这些实践人员倾向于

考虑产品的内部特性，有时甚至会在产品交付给用户之前就考虑这些内部特性。尤其是，实践人员

通常会把故障的数目和类型看作为产品质量（或缺乏质量）的证据。例如，开发人员跟踪在需求、

设计和代码审查中发现的故障数目，并把它们作为终产品可能的质量指示器。由于这样的原因，我们通常要建立模型，把用户的外部视图和软件开发人员的内部视图联系起

来。图1-5是一个早期质量模型的例子，由McCall和他的同事构建，说明外部的质量因素（在图的左

边）与产品质量标准（在图的右边）是如何联系在一起的。McCall为右边的每一个标准都关联一种

测度，以说明一个质量要素受关注的程度（McCall, Richards and Walters 1977）。我们将在第12章研究

若干产品质量模型。

10

正确性可跟踪性完备性一致性精确性容错性执行有效性存储有效性访问控制访问审计可操作性培训通信性简单性简洁性仪器使用自描述性可扩展性通用性模块化软件系统独立性机器独立性通信共性数据共性

可靠性有效性

完整性

可用性

可维护性

可测试性

灵活性

可移植性

可复用性

互操作性

图1-5 McCall的质量模型


1.3.2 过程的质量

有很多活动会影响到终的产品质量。只要有活动出了差错，产品的质量就会受到影响。因此，

许多软件工程师认为开发和维护过程的质量与产品的质量是同等重要的。对过程进行建模的一个优

点是，我们能够研究它，并寻找方法对它加以改进。例如，我们可以提出下面的问题。在什么时间、什么地点，我们可能发现某种特定类型的故障？如何能够在开发过程的更早期阶段发现故障？如何构建容错机制以便把故障演变为失效的可能性降到低？是否有一些其他的做法能够在确保质量的前提下使我们的过程更加高效或有效？

这些问题可以应用于整个开发过程或其中一个子过程（如配置管理、复用或测试等）；我们将在

后面的章节中研究这些过程。 20世纪90年代，软件工程重点宣扬的是过程建模和过程改进。受到Deming和Juran工作的启发并

由IBM等公司实现的能力成熟度模型（CMM）、ISO 9000、软件过程改进及能力确定（SPICE）等过

程指导原则提出：通过改进软件开发过程，可以提高终产品的质量。在第2章，我们将看到如何识

别相关的过程活动，并用模型表示它们对中间产品和终产品的影响。第12章和第13章将深入分析

过程模型并改进框架。

11

1.3.3 商业环境背景下的质量

当质量评价集中于产品和过程的时候，我们通常使用包含故障、失效和计时的数学表达式来测

量质量。人们很少会拓展到商业的视角。在商业环境中，质量是根据软件所处的商业环境提供的产

品和服务来看待的。也就是说，我们考虑的是产品的技术价值，而不是更广泛的商业价值，而且我

们只根据终产品的技术质量来做出决策。换句话说，我们假定改进的技术质量会自动转化为商业

价值。一些研究人员仔细研究了商业价值和技术价值之间的关系。例如，Simmons访问了很多澳大利亚

企业，以确定他们是如何做出与信息技术相关的商业决策的。她提出了一种理解公司的“商业价值”

含义的框架（Simmons 1996）。在Favaro和Pfleeger的报告（Favaro and Pfleeger 1997）中，一个大型美

国保险公司Cigna的信息主管Steve Andriole描述了他的公司是如何区分商业价值与技术价值的：

我们通过显而易见的度量来测量（软件的）质量：运行时间与停机时间、维护成本、

与修改相关的成本，等等。换句话说，我们在成本参数范围内根据操作性能来管理开发。

比起厂商提供的成本-效益性能，我们更关心工作量的结果……商业价值与技术价值相比，

前者与我们更贴近……也是我们重点关心的问题。我猜想如果我知道公司将以牺牲商业价

值为代价为追求技术价值签订合同，我会非常吃惊。如果两者有所不同，我宁可选择后者。

如果没有（所期望的）明确的商业价值（可量化地描述：可处理的要求数量等），那么我们

不会启动一个系统项目。我们非常认真地经过“有目的性的”项目需求阶段，那时我们会

问“我们为什么会需要这个系统？”以及“我们为什么关心它？”

人们一直尝试着以量化的、有意义的方式将技术价值和商业价值联系起来。例如，Humphrey、Snyder和Willis指出，根据CMM“成熟”度等级改进其开发过程（将要在第12章中讨论），Hughes飞机制造公司的生产率提高了4倍，并且节省了数百万美元（Humphrey, Snyder and Willis 1991）。类似地，Dion报道，雷神公司的生产率增加了2倍，并且过程改进中每1美元的投资都有7.7美元的

回报（Dion 1993）。在俄克拉何马州的Tinker空军基地，工作人员注意到其生产率提高了6.35倍（Lipke and Butler 1992）。

但是，Brodman和Johnson更仔细地研究了过程改进的商业价值（Brodman and Johnson 1995）。他们调查了33家执行了一定过程改进活动的公司，并且研究了几个关键事项，除此以外，Brodman12

1.3 什么是好的软件 9

和Johnson还询问了这些公司是如何定义投资回报（Return on Investment, ROI）的——这是一个在商

业界明确定义的概念。他们注意到教科书中的投资回报的定义来自金融界，把投资解释为为了其他

目标而做的付出。也就是说，“投资不仅仅是收回原始资本，而且收回必须足够多，至少等于这些资

金在其他地方所能赚来的利润，再加上风险金”（Putnam and Myers 1992）。通常，商业界使用下面3种模型中的一种来评价ROI：回收模型、会计收益率模型和折现值现金流模型。

但是，Brodman和Johnson发现，美国政府和美国工业界以不同的方式来解释ROI，并且这两种方

式与商学院的标准方法也不同（Brodman and Johnson 1995）。政府根据美元来看待ROI，同时考虑减

少运作成本、预测节省的美元以及计算采用新技术的成本。政府投资也是用美元来表示，如引入新

技术的成本或启动过程改进的成本等。另一方面，工业界根据项目工作量而不是成本或美元来看待投资。也就是说，公司感兴趣的是

节省时间和使用更少的人，而他们对投资回报的定义也体现出他们将重点放在减少工作量上。在对

这些公司的调查中，投资回报包含下列各项：培训；进度；风险；质量；生产率；过程；客户；成本；业务。

定义中的成本包含达到预计成本、提高成本效率，以及维持在预算范围之内，而不是减少运转

成本或使项目或组织机构简单化。图1-6总结了许多组织使用ROI定义的投资项目的频率。例如，那

些被访问的企业中，大约有5%将质量小组的工作量包含在ROI的工作量计算中，大约有35%的企业

在考虑投资规模时包含了软件成本。

设施

软件成本

硬件成本美元

工作量

材料

一般性的

评价

SCE费用

内部研发

处理

文档

质量小组

软件过程组

一般性的

0 10% 20% 30% 40% 50% 60% 70%

访谈企业的百分比

图1-6 工业界的投资回报定义中包含的项

观点之间的差异带来了很大麻烦，因为它意味着组织之间ROI的计算是不可比较的。但是，也有

其合理之处。因为缩短的进度、更高的质量、提高的生产率等因素节省的美元都返回给了政府而不


是承包商。另一方面，承包商常常追求竞争优势、提高的劳动能力以及更大的利润，因此，承包商

的ROI更多地是基于工作量而不是基于成本的。尤其是，更精确的成本和进度估算意味着客户的满意

度和多次的商业机会，并且缩短投入市场的时间以及提高的产品质量也被认为是提供了商业价值。尽管每个组织都可以对不同ROI计算方法进行调整，但令人担心的是，软件技术的ROI与金融的

ROI是不同的。有些时候，程序的成功必须报告给高层管理机构，其中很多与软件无关而与公司的主

要业务（如通信或银行业等）相关。用相同的术语表示截然不同的事物，会造成混淆。因此，成功

的标准不仅要对软件项目和过程有意义，而且要对支持更一般的业务实践也有意义。第12章将讨论

使用几种公共的商业价值测量来选择技术。

1.4 软件工程涉及的人员

软件开发的一个关键部分是客户与开发人员之间的交流，如果交流失败，那么系统也将失败。

必须在构建有助于解决问题的系统之前，理解客户想要什么以及他们需要什么。要做到这一点，我

们把讨论的重点转向软件开发所涉及的人员。从事软件开发工作的人员数目取决于项目的规模和难易程度，然而，不论涉及多少人，都可以

区分他们在整个项目生命周期中的角色。因此，对于一个大型项目，一个人或一个小组可能被确定

地指派为某一个角色；而在小型项目中，一个人或一个小组可以一次承担几个角色。通常情况下，参与项目的人员分为三类：客户、用户或开发人员。客户（customer）是为将要开

发的软件系统支付费用的公司、组织或个人。开发人员（developer）是为客户构建软件系统的公司、

组织或个人，其中包括协调并指导程序员和测试人员的管理人员。用户（user）是将实际使用系统的人，

包括坐在终端前的人、提交数据的人或阅读输出的人。尽管就某些项目而言，客户、用户、开发人员

是同一个人或同一组人，但多数情况下，他们还是各不相同的。图1-7显示了这三类参与人员之间的基

本关系。

13

14

~

客户发起系统开发

需要的资金开发人员

用户合同契约

构建系统使用系统

需要

软件系统

图1-7 软件开发中的参与者

客户控制着资金，常常进行合同谈判并在验收文件上签字。但是，有时候客户并不是用户。例

如，假定Wittenberg Water Works与Gentle Systems，Inc.签订了一份合同，要为公司建立计算机化的会

计系统。Wittenberg的总裁可以向Gentle Systems，Inc.的代表明确地描述他需要什么，并且他将要签

订这份合同。但是，总裁并不直接使用这个会计系统，用户将是簿记员或会计职员。因此，开发人

员确切地理解客户和用户想要什么以及需要什么是非常重要的。另一方面，假定Wittenberg Water Works是一家大型公司，它有自己的计算机系统开发部门。该

部门可能决定它需要一个自动化的工具来记录其项目的成本和进度，并且决定自己构建这个工具。

1.5 系统的方法 11

此时，该部门既是用户、客户，同时也是开发人员。近几年，客户、用户和开发人员之间的这种简单的区别变得越来越复杂。客户和用户以各种方

式介入到开发过程中。客户可能决定购买商业现货（Commercial Off-The-Shelf，COTS）软件，并合

成到开发人员将要提供和支持的终产品中。当发生这种情况的时候，客户会介入到系统体系结构

的决策中，并且对开发过程有很多约束。类似地，开发人员可能决定使用额外的开发人员，后者称

为分包商（subcontractor），分包商构建子系统并把它交付给开发人员，这些子系统包含在终产品

中。分包商可以与主开发人员在同一地点工作，他们也可能在不同的地点与主开发人员协调地工作，

并在开发过程后期交付子系统。子系统可能是个交钥匙系统（turnkey system），其代码是一个合并的

整体（不需要集成额外的代码），或者它可能需要一个单独的集成过程将主系统和子系统链接起来。

15

因此，在软件工程中，“系统”的概念不仅对理解问题分析或解决方案的合成是重要的，对组织

开发过程以及为参与者分配合适的角色同样重要。在下一节，我们会讨论好的软件工程实践中系统

方法的作用。

1.5 系统的方法

我们开发的项目并不存在于真空中。通常，我们装配在一起的硬件和软件，必须与用户、其他

软件任务、其他部分的硬件、现有数据库（即仔细定义的数据集合和数据关系）甚至其他的计算机

系统进行交互。因此，为任何项目提供一个背景是非常重要的，该背景就是项目的边界（boundary）：项目中包含什么，不包含什么。例如，假设主管让你编写一段程序为办公室的人员打印工资单。你

必须知道你的程序是否只是简单地从另一个系统中读入工作时间并且打印结果，还是必须同时计算

工资信息。类似地，你必须知道程序是否需要计算税率、养老金以及津贴，或者是否要随每份工资

单提供这些项目的报告单。实际上，你真正要问的问题是：项目从哪里开始，到哪里结束？同样的

问题可以应用于任何系统。一个系统是对象和活动的集合，再加上对象和活动之间关系的描述。就

每个活动而言，典型的系统定义包括需要的输入列表、采取的动作以及产生的输出。因此，要开始

一个项目，必须知道系统包含哪些对象或活动。

1.5.1 系统的要素

我们通过命名系统的组成部分并标识这些组成部分是如何与另一个系统相互联系的，来描述这

个系统。这种标识是分析摆在我们面前的问题的第一步。 1．活动和对象首先，我们对活动和对象加以区分。活动（activity）是发生在系统中的某些事情，通常描述为

由某个触发器引发的事件，活动通过改变某一特性将一个事物转变成另一个事物。这种转变可能意

味着数据元素从一个位置移到另一个位置，从某个值转变为另一个值，或者与其他的数据相结合为

另一个活动提供输入。例如，一个数据项可以从一个文件移到另外一个文件。这种情况下，改变的

特性是位置。或者，数据项的值可能增加。后，数据项的地址可以与若干其他数据项的地址一起

包含在参数列表中，以便可以调用另外的例程一次性处理所有数据。活动中涉及的要素称为对象（object）或实体（entity）。通常，这些对象以某种方式相互联系。

例如，对象能够排列在表格或矩阵中。对象常常组成记录，其中，每一条记录按规定的格式排列。

例如，一个雇员的历史记录中可能包含如下对象（也称字段）：

16

名邮政编码教名每小时的工资姓每小时的津贴街道地址累计休假


城市累计病假州

记录中不仅定义了每个字段，而且定义了每个字段的大小以及字段之间的关系。因此，记录描

述规定了每一个字段的数据类型、记录中的开始位置和字段的长度。依次地，因为每个雇员都有一

条记录，所有的记录组合在一起就构成了文件，并且要指明文件特性（如大的记录数等）。有时，对象定义得稍有不同。不是将每一项考虑为一个大记录中的字段，而是将对象看作是独

立存在的。对象的描述包括每个对象的特性列表，以及所有使用对象或影响对象的动作的列表。例

如，考虑“多边形”对象。一个对象描述可以是，这个对象具有诸如边数以及每条边的长度等特性。

动作可能包括计算面积和周长。甚至可能还可以有一个属性称为“多边形类型”。这样，可以标识每

个“多边形”的实例，例如是“菱形”还是“长方形”等。类型本身也可能有对象描述。例如“长

方形”可以由“正方形”和“非正方形”组成。当我们在第4章研究需求分析的时候，将会探讨这些

概念，并在第6章讨论面向对象开发的时候进行深入探讨。 2．关系和系统边界一旦定义了实体和活动，就要把实体和它们的活动进行匹配。实体和活动之间的关系应该要清

晰、仔细地予以定义。实体的定义包括实体起源于何处的描述。有些项驻留于已经存在的文件中，

有些项在活动的过程中被创建。实体的目的地也是非常重要的。有些项仅仅被一个活动所使用，而

有些项会被指定为其他系统的输入。也就是说，系统的某些项会被当前系统范围之外的活动所使用。

因此，可以认为我们正在考虑的系统是有边界的。有些项跨越边界进入我们的系统，而另一些是我

们系统的产品并为其他系统所使用。使用这些概念，我们能够把系统（system）定义成一组事物的集合：一组实体、一组活动、实

体和活动之间关系的描述以及系统边界的定义。系统的这个定义不仅适用于计算机系统，而且适用

于其他任何事物（其中，对象以某种方式与其他对象交互）。 3．系统举例要了解系统定义是如何进行的，考虑一个呼吸系统的例子：身体吸进氧气排出二氧化碳和水。

我们可以很容易地定义它的边界：如果指出身体的一个具体器官，就能说出它是不是呼吸系统的一

部分。氧气和二氧化碳分子都是实体或对象，它们按照可以明确定义的方式进出呼吸系统。我们也

可以根据实体间的交互来描述系统中的活动。如果必要的话，可以通过什么进入以及什么离开来描

述这个系统，也可以用一个表格来描述其中涉及的所有实体和活动。图1-8说明了一个呼吸系统。请

注意每个活动都涉及实体，并且可以通过描述哪些实体是输入，它们如何被处理，以及输出的结果

来进行定义。

17

边界

实体：微粒物氧气二氧化碳水氮气鼻子嘴气管支气管肺肺泡

活动：吸入气体过滤气体传输分子进入／离开血液

呼出气体

图1-8 呼吸系统

1.5 系统的方法 13

我们还必须清晰地描述计算机系统，与预期的用户一起定义系统的边界：我们的工作从什么地

方开始以及在什么地方结束？另外，我们必须知道什么处于系统的边界上，从而可以确定输入的开

始和输出的目的地。例如，在打印工资单的系统中，支付信息可能来自公司的计算机，系统输出可

能是发送到邮箱的工资单的集合，送到适当的接收者手中。在图1-9所示的系统中，我们可以了解边

界并且理解实体、活动和它们之间的关系。

计算机

支付信息

邮箱

日期确认

工资单

打印

计算

系统边界

图1-9 工资单产品的系统定义

1.5.2 相互联系的系统

边界的概念之所以重要，是因为几乎不存在与其他系统无关的系统。例如，呼吸系统必须与消

化系统、循环系统、神经系统以及其他系统交互。呼吸系统没有神经系统就不能发挥作用，循环系

统没有呼吸系统也不能正常工作。这种相互依赖可能是非常复杂的（实际上，由于我们不能认清生

态系统的复杂性，已经引起并加剧了许多环境问题）。但是，一旦描述了系统的边界，就很容易了解

什么在系统内部、什么不在以及什么超出了边界。此外，一个系统存在于另外一个系统的内部也是可能的。描述一个计算机系统的时候，通常是

集中于实际系统的一小部分。这种集中使得我们能够定义和构建一个比包裹它的系统简单得多的系

统。如果仔细记录那些影响系统的系统之间的交互，即使集中于更大系统中的较小部分，也不会有

任何损失。

18

我们来讨论一个例子，看一看是如何做到这一点的。假定要开发一个水系监控系统，该系统在

整条河流经过的很多地点采集数据。在数据采集点完成若干计算，其结果被传送到中心站点进行汇

总报告。这样一个系统的实现方式可能是：有一个中心站点的计算机，它与数十个在远程站点的小

型计算机进行通信。其中，必须考虑很多系统活动，包括收集水质数据的方式、在远程站点进行的

计算、与中心站点的信息通信、通信数据在数据库或共享数据文件中的存储以及根据数据创建报告。

可以把这个系统看成是一些系统的集合，其中每个系统都有特定的目的。尤其是，我们可以只考虑

较大的系统的通信方面，并且开发一个通信系统将数据从远程站点传送到中心站点。如果我们仔细

地定义通信系统和大系统之间的边界，通信系统的设计和开发就可以独立于大系统来完成。整个水系监控系统的复杂性要比通信系统大得多，因此，通过对分开的、较小的部分进行处理

可以简化我们的工作。如果边界定义详细、正确，那么根据较小的部分构建较大的系统是相对容易

的。通过以分层的方式来考虑较大的系统，可以按图1-10那样描述系统的构造过程（以水系监控系

统为例）。一个层次本身就是一个系统，但是，每一层及其包含的那些层次也构成一个系统，图1-10


中的圆圈表示它所代表的系统的边界，所有圆圈的集合构成了水系监控系统。 19

一个系统可能包含另外一个系统，认识到这一点是很重要的，因为它反映了这样一个事实：一

个系统中的对象或活动是外层所代表的每一个系统的一部分。因为每一层都会引入更多的复杂性，

所以随着每一层系统的加入，要理解任何一个对象或活动就会更加困难。因此，首先集中于小的

系统是简单的方法，这样便于更好地理解随后的系统。

数据报告系统

采集数据的数据管理系统

从远程站点到中心站点的通信系统

远程数据计算系统

远程数据采集系统

图1-10 水系监控系统的层次结构

我们使用这种思想来构建一个替换旧版本的新系统（无论是手工方式还是自动方式）。我们希望

尽可能多地理解新、旧系统是如何运行的。通常情况下，两个系统之间的差别越大，设计和开发就

越困难。之所以出现这样的困难，不仅是因为人们倾向于拒绝改变，而且这种差别使得系统难以学

习。在构造或合成大系统的时候，把新系统的构造作为一系列递增的中间系统是极其有用的。不是

从A系统直接构建B系统，而是从A到A′，再到A′′，然后到B。例如，假定A是一个包含3个主要功能

的手工系统，B是A的自动化版本。我们可以将A′系统定义为一个新的系统，它只有功能1是自动化

的，而功能2和功能3仍是手工的。然后，A′′有自动化的功能1和功能2，但其功能3仍是手工的。后，

B具有3个自动化的功能。通过将A到B的“距离”分成三段，我们就得到了一系列小的问题，这比整

个问题要更容易处理。在我们的例子中，两个系统非常相似。它们的功能是相同的，但是实现的方式不同。但是，目

标系统常常与现有系统存在着巨大差别。尤其是，通常希望目标系统不受现有硬件和软件所强加的

约束的限制。增量开发（incremental development）方法可以包含一系列阶段，其中每一个阶段都使

前面的系统不受当前系统约束的限制。例如，阶段1可能增加一个新硬件，阶段2可能替换执行一组

特定功能的软件。系统逐渐地从旧的软件和硬件中脱离开，直到它体现出新系统的设计。

20

因此，系统开发可以首先在实际系统中实现一组变化，然后增加一系列变化以生成完整的设计

方案，而不是从当前一步一下跳到将来。使用这种方法，我们必须同时从两个不同的方面看待系统：

静态地和动态地。静态视图告诉我们系统如今如何运行，而动态视图展示系统如何演变成终的系

统。缺少任何一方面都是不完整的。

1.6 工程的方法

理解了系统的本质之后，就可以开始构造系统了。在这一刻，软件工程中的“工程”部分就是

1.6 工程的方法 15

密切相关的，并且使我们到目前为止所做的工作更加完美。回顾一下，本章开始我们谈到软件的编

写不仅是一门科学，而且是一门艺术。生产系统的艺术是指软件产品的工艺。编写软件作为艺术的

一面是，我们开发技术和工具，这些技术和工具已经被证明有助于生产有用的、高质量的产品。例

如，我们可能将一个优化的编译器作为工具，来生成在我们使用的机器上快速运行的程序。或者，

我们可能将特定排序和搜索程序作为节省系统时间和空间的技术。这些基于软件的技术只是作为技

术，而工具则被用于打造精美的家具或用于盖房子。实际上，流行的编程工具集被称为程序员的工

作平台，因为程序员对它们的依赖如同木匠对工作台的依赖。因为构建系统类似于盖房子，我们可以将盖房子作为例子，来说明为什么“艺术”方法对软件

开发是很重要的。

1.6.1 盖房子

假设Chuck和Betsy Howell要雇人为他们造一所房子。由于工程规模大，比较复杂，通常需要由

多人组成的建筑队。因此，Howell夫妇雇佣了McMullen建筑公司。建造房子涉及的第一件事是，Howell夫妇与McMullen公司面谈，解释他们想要什么。这次会谈不仅探讨了Howell夫妇想要的房子的外观，

也探讨了房子应该具有什么样的特征。然后，公司草拟出房子的建筑平面图和建筑透视图。在Howell夫妇与McMullen公司讨论了细节之后，又进行了一些修改。一旦Howell夫妇认可McMullen公司的方

案，房子的建造就可以开始了。在盖房子的过程中，Howell夫妇很可能亲临建房的现场，考虑他们想要进行的改变。整个盖房

子的过程中可能会发生若干变化，但终房子会建成。在建造的过程中以及Howell夫妇搬进来之前，

会对房子的若干部分进行测试。例如，电工测试配线电路，管道工确保管道没有泄漏，而木匠调整

木板的变形，使地板更光滑平整。后，Howell夫妇搬了进来。如果有什么地方不合适，Howell夫妇可以叫McMullen公司来修复，但终Howell夫妇完全负责这所房子。

21

我们现在进一步讨论这个过程涉及了哪些内容。首先，由于房子是由很多人同时建造的，所以

文档资料是必需的。不但建筑平面图和建筑透视图是必需的，而且还需要写下细节，以便管道工和

电工等专业人员可以随着房子建造的过程，把产品装配在一起。其次，如果Howell夫妇只在这个过程的开始描述他们的房子，然后直到房子建成再来看，这是

不合理的。相反，Howell夫妇在建造的过程中可能会多次修改房子的设计。这些修改可能出于以下

几种情况。初指定的材料现在无法买到。例如，某种类型的瓦可能已经不再生产了。在Howell夫妇看到房子已经成形的时候，他们可能又有了新的想法。例如，Howell夫妇可能

意识到，再花点钱就可以给厨房增加一个天窗。材料或资金限制可能迫使Howell夫妇改变他们的需求，以满足进度或预算。例如，房子要在

冬天来临之前建造完成，而Howell夫妇想要预订的特殊窗子在这个时间内无法准备好，因此，

可能用现成的窗子作为替代品。初认为是可行的项目或设计，后来可能被证明是不可行的。例如，土壤渗透性测试表明，

房子周围的土地不能支撑Howell夫妇初要求的那么多个浴室。在房子开始建造之后，McMullen公司也可能建议进行一些变更，其原因也许是由于有更好的想

法，也许是由于建筑队的某个关键成员无法工作了。并且，即使房子的某一方面已经建造完成，

McMullen公司和Howell夫妇也有可能改变他们关于该处的想法。后，McMullen必须提供蓝图、布线和管道图、用具操作手册和其他文档，使Howell夫妇在入

住之后能够进行修改或修理。这个建造过程的总结如下。

确定和分析需求。提出并文档化房子的总体设计。


提出房子的详细规格说明。识别并设计房子的组成部分。构建房子的每一个组成部分。测试房子的每一个组成部分。把房子的各个组成部分集成在一起，在住户搬进来之前做后的修改。由房子的住户持续进行维护。 22

我们已看到，参加人员必须保持灵活性，并能够在建造过程的各个点改变初始的规格说明。房子是在社会、经济以及它所处的政府体系的背景下建造的，记住这一点很重要。就像图1-10

所示的水系监控系统描述的各个子系统之间的依赖关系，我们必须把房子看作是一个大方案中的一

个子系统。例如，房子的建造是在市或县的建设法规和条例的背景下完成的。McMullen的员工必须

经过市或县的许可才能工作，并且必须按照建设标准进行施工。建设场所要经过建筑监理的检查，

他们确保相关标准得到遵守。建筑监理设定质量的标准，检查作为建筑项目质量保证的检查点。社

会或习惯的限制也可能成为常识性的或为人们所接受的行为。例如，房子的前门直接对着厨房或卧

室是不符合习惯的。同时，我们必须认识到，不可能一开始就准确地规定建造房子的活动，必须根据经验为决策留

有余地，以处理未预料到的或非标准的情形。例如，许多房子都是根据预先制好的部件建造的，门

已经装在框架中，浴室使用预制好的淋浴房等。但是，有时需要对标准化的房子建造过程进行修改，

使之适应于特殊的特征或请求。假设框架已经搭好，水泥墙已经砌好，地板已经铺好，下一步就是

在浴室的地面上铺设瓷砖。建筑人员沮丧地发现，墙和地面并不正好是正方形。这个问题并不是由

于过程不当造成的，建造房子的部件有一些自然的或制造上的变形，因此会出现一些不太精确的情

况。如果按照标准方式用小正方形铺设地砖的话，这些不精确的地方就会更加突出。这正是艺术和

专业技术发挥作用的地方。建筑人员可能从垫层上下取下瓷砖，然后每次铺一块，并对每一块做一

些小的调整，使得除了辨别能力极强的人，一般人察觉不到这种变形。因此，盖房子是一项复杂的任务，在建造的过程中，过程、产品或资源很多时候会发生变化，

但都可通过艺术和专业知识进行适当的调剂。虽然盖房子过程可以标准化，但是，专家的判断力和

创造性总是需要的。

1.6.2 构建系统

软件项目的进展方式与盖房子过程类似。在上面的例子中，Howell夫妇是客户和用户，McMullen是开发人员。假定Howell夫妇让McMullen建造的房子是要Howell先生的父母搬进去住的，那么，用

户和客户就是不同的人了。同样地，软件开发涉及用户、客户和开发人员。如果让我们为某个客户

开发一个软件系统，第一步是与客户会面以确定需求。正如我们前面所看到的那样，这些需求是对

系统的描述。如果不了解边界、实体和活动，要描述软件及其与它的环境的交互是不可能的。一旦定义了需求，我们就可以创建系统设计来满足指定的需求。正如在第5章中将要看到的，系

统设计告诉客户，从客户的角度看，系统会是什么样的。就像Howell夫妇查看建筑平面图和建筑透

视图一样，我们向客户展示将要使用的视频显示屏幕的图片、将要生成的报表以及任何其他解释用

户将如何与完成的系统交互的相关描述。如果系统有手工备份或覆写过程，也要对其进行描述。起

先，Howell夫妇只对房子的外观和功能感兴趣。到后来，他们必须决定是用铜管还是用塑料管。同

样，软件项目的系统设计（也称为体系结构）阶段只描述外观和功能。

23

接着，客户要对设计进行评审。当设计得到批准后，整个系统设计将被用来生成其中单个程序

的设计。请注意，直到这个步骤才会提到程序。在功能和外观确定之前，考虑编码是没有意义的。

在建造房子的例子中，这一阶段准备讨论的是管道的类型或电线的质量。我们之所以能够决定是用

塑料管还是用铜管，是因为我们现在知道了在建筑物中哪里会有水流过。同样，当系统设计被大家

认可之后，就准备开始讨论程序了。讨论的基础是关于系统的软件项目的定义明确的描述，系统设

1.7 开发团队的成员 17

计包含功能以及所涉及的相互关系在内的完整描述。当程序编写完之后，必须在把它们链接到一起之前将其作为单独的代码段进行测试。这是测试

的第一个阶段，称为模块测试或单元测试。一旦我们确信每段程序都能够按我们的期望来运行，就

把它们组合到一起，并确保它们能够正确运行。这是第二个测试阶段，通常称为集成测试，因为它

是逐步加入一部分来构建系统的，直到整个系统可以运转。后的测试阶段称为系统测试，是对整

个系统的测试，用于确保起初指定的功能和交互得以正确实现。在这个阶段，会把系统和需求进行

比较。开发人员、客户和用户共同检查系统是否达到了希望的目标。后，交付终产品。随着它的使用，差异和问题就会暴露出来。如果我们的系统是一个交钥

匙系统，那么在移交之后客户将对该系统负责。可是，很多系统不是交钥匙系统，如果出现任何问

题，或者需求发生变化，开发人员或其他组织要对其进行维护。因此，软件的开发包含下面的活动。

需求分析和定义。系统设计。程序设计。编写程序（程序实现）。单元测试。集成测试。系统测试。系统交付。维护。

理想情况下，一次执行一个活动，当到达上述活动的结尾时，就完成了软件项目。但是，实际

上，很多步骤是重复执行的。例如，在评审系统设计时，你和客户可能发现有些需求还没有进行文

档化。你可能与客户一起工作，加入需求，有时可能要重新设计系统。类似地，当编写和测试代码

时，你可能发现某个设备并没按照其文档描述的那样运行。你可能不得不重新设计代码，重新考虑

系统设计，甚至回过头与客户讨论如何满足需求。由于这样的原因，我们将软件开发过程（software development process）定义为包含前面列出的9个活动（部分或全部）的软件开发的描述，对这些活

动加以组织，以便生产经过测试的代码。第2章将探讨若干不同的软件开发过程。后面的章节中将研

究从需求分析到维护的每个子过程和它们的活动。但是在研究它们之前，先来考虑一下谁开发软件

以及软件开发面临的挑战在这些年发生了哪些变化。

24

1.7 开发团队的成员在本章的前面，我们看到客户、用户和开发人员在新产品的定义和创建中发挥着重要的作用。

开发人员是软件工程师，但是，每一位工程师可能都只擅长于软件开发的某一特定方面。因此，我

们在此更深入、详细地讨论开发团队成员的角色。任何开发过程的第一步都是找出客户想要什么，并且将需求文档化。正如我们已经看到的，分

析就是把事物分解成其组成部分的过程，以便我们能够更好地理解它们。因此，开发团队包含一个

或多个需求分析员跟客户一起工作，并且把客户想要的分解为离散的需求。一旦了解了需求并且把需求文档化，分析员就与设计人员一起工作，生成系统层描述（系统要

做什么）。然后，设计人员与程序员一起工作，以程序员能够编写实现指定需求的代码行的方式来描

述系统。生成代码之后，必须对它进行测试。通常，第一次测试由程序员自己完成；有时，也使用另外

的测试人员帮助程序员发现他们忽略的错误。当代码单元被集成为一个个运行的功能组时，测试人

员小组与实现小组会在各部分组合构建系统的过程中，验证系统是否能够正确运行，是否符合规格


说明。当开发团队对系统的功能和质量感到满意时，注意力就转向了客户。测试小组和客户一起验证

整个系统是否是客户想要的系统。他们通过把系统如何工作与初需求规格说明进行比较，来完成

这项工作。然后，培训人员向用户说明如何使用这个系统。就很多软件系统而言，客户的验收并不意味着开发工作的结束。如果在系统验收之后发现了故

障，维护小组就要修复它们。另外，随着时间的推移，客户的需求可能会发生变化，系统也必须进

行相应的改变。因此，维护可能涉及分析人员，由分析人员决定增加或变更哪些需求；还可能涉及

设计人员，由设计人员确定改变系统哪个部分的设计；还可能涉及实现这些变化的程序员，确保改

动后的系统仍然正确运行的测试人员，以及向用户解释这些变化如何影响系统使用的培训人员。图

1-11说明了开发团队的角色与开发步骤的对应关系。

25

就课程项目而言，学生通常会自己工作或者在一个开发团队的小组中工作。教师所要求的文档

是少的，学生常常不需要编写用户手册或培训文档。再者，布置的作业是相对稳定的，需求在项

目的生命周期中不会发生变化。后，学生构建的系统很可能在课程结束后就丢弃掉，他们的目的

是证明他们的能力，而不必为实际的客户解决问题。因此，对于课程项目而言，程序规模、系统复

杂性、文档化的需要以及可维护性的需要都是相对很少的。

需求分析和定义

系统设计

程序设计

程序实现

单元测试

集成测试

系统测试

系统交付

维护

分析员

设计人员

程序员

测试人员

培训人员

开发人员角色

软件开发步骤

图1-11 开发团队中的角色

但是，对一个实际的客户而言，系统的规模可能会很庞大，复杂性可能会很高，可能需要大量

的文档，可维护性的要求也可能会很高。对于一个涉及成千上万行代码并涉及开发团队成员间很多

交互的项目来说，项目各方面的控制可能是很困难的。为了支持开发团队中的每一个成员，一些人

员可能在开发的开始就要介入系统，并且自始至终都是如此。资料管理员负责准备和存储在系统生命周期中用到的文档，包括需求规格说明、设计描述、程

序文档、培训手册、测试数据、进度等。与资料管理员一起工作的是配置管理小组的成员。配置管

理涉及维护需求、设计、实现和测试之间的对应关系。根据这种交叉引用，开发人员可以得知，如

果需要改变需求，相应地要改变什么程序；或者如果提议进行某种改变，会影响到程序的哪一部分。

配置管理成员还要协调可能建立或支持的系统的不同版本。例如，一个软件系统可能要运行在不同

的平台上，或者按一系列不同的发布进行交付。配置管理要确保各个平台上系统的功能都是一致的，

而且新发布的功能不会降级。

26

开发角色可由一个人或几个人承担。就小型项目而言，两三个人就可以承担所有角色。然而，

1.8 软件工程发生了多大的变化 19

就大型项目而言，通常要根据开发中职责，把开发团队分成不同的小组。有时，维护系统的人员与

初设计和编写系统的人员是不同的。对某些规模巨大的开发项目来讲，客户甚至会雇佣一家公司

做初的开发，而用另外一家公司进行维护工作。我们在后面的章节中讨论开发和维护活动时，会

讨论每种类型的开发角色需要哪些技能。

1.8 软件工程发生了多大的变化

我们已经对构建软件和建造房子进行了比较。每年全国会建造几百栋房子，觉得满意的客户会

搬进去。每年开发人员构造数百个软件产品，但是，更常见的是客户对结果不满意。为什么会存在

这种差别呢？如果可以如此容易地列举出系统的开发步骤，那么为什么软件工程师生产高质量的软

件却是这样艰难呢？让我们回过头来再考虑建造房子的例子。在建造房子的过程中，Howell夫妇不断地检查计划。

他们还有很多时候会改变自己的想法。同样地，软件开发允许客户在每一个步骤评审计划并且对设

计进行改变。毕竟，如果开发人员生产出一个非凡的产品却不能满足客户的要求，那么终的系统

将只会浪费所有人的时间和精力。由于这样的原因，以灵活的方式运用软件工程工具和技术是至关重要的。过去，作为开发人员，

我们假定客户从一开始就知道他们想要什么，但这种稳定性通常不符合实际情况。随着一个项目展

开，开始没有预料到的约束就会出现。例如，在选定一个相应要使用的硬件和软件之后，我们可能

发现由于客户需求的变化，使得很难使用特定的数据库管理系统生成承诺给客户的菜单；或者发现

与系统交互的另外一个系统已经改变了它的过程或数据的格式；我们甚至可能发现硬件或软件并没

像厂商的文档所承诺的那样工作。因此，我们必须记住每一个项目都是与众不同的，必须使所选择

的工具和技术能够反映对这个项目的约束。 27我们还必须承认，大多数系统并不是单独存在的。它们与其他的系统交互，或接受信息或提供

信息。开发这样的系统会很复杂，原因很简单，相互通信的系统之间需要大量的协调行为。对于那

些并行开发的系统来讲，这种复杂性更是如此。过去，开发人员难以确保系统间接口的文档的精确

性和完整性。在后面的章节中，我们将讨论控制接口问题的相关事项。

1.8.1 变化的本质

有很多问题会影响到软件开发项目的成功，上述那些问题也在其中。无论采用什么样的方法，

我们都必须既要展望未来，也要回顾过去。也就是说，我们必须回顾以前的开发项目，看一看关于

软件质量保证的有效性以及关于技术和工具的有效性，我们到底学到了什么。另外，还要预测在将

来很有可能改变我们实践的软件开发的方式以及软件产品的使用方式。Wasserman指出，自从20世纪

70年代以来，软件开发一直发生着巨大的变化（Wasserman 1995）。例如，早期的应用软件是运行在

单处理器上的，通常是大型机。输入是线性的，往往是一副卡片或一个输入磁带，而输出是字母数

字。系统用两种基本方式来设计：转换（transformation），它将输入转换为输出；事务（transaction），由输入决定哪个功能将被执行。如今，基于软件的系统已经大不相同，并且更为复杂。它们通常运

行在多个系统上，有时配置在具有分布式功能的客户/服务器体系结构中。软件不仅执行用户需要的

主要功能，而且还要执行网络控制、安全性、用户界面表示和处理，以及数据或对象管理。传统的

“瀑布”开发方法假定开发活动是线性前进的，即只有在一个活动的前一个活动完成以后才会进行这

个活动（将在第2章中学习）。这种方法不再灵活也不再适合于当今的系统了。在Stevens的演讲中，Wasserman通过已经改变软件工程实践的7个关键因素，总结了这些变化

（Wasserman 1996），如图1-12中所示。


对象技术瀑布型的问题

桌面计算技术

经济上的转变

投入市场的时间软件工程中的变化

网络用户界面图1-12 改变软件开发的关键因素

(1) 商用产品投入市场时间的紧迫性。 (2) 计算技术在经济中的转变：更低的硬件成本，更高的开发、维护成本。 (3) 功能强大的桌面计算的可用性。 (4) 广泛的局域网和广域网。 (5) 面向对象技术的采用及其有效性。 (6) 使用窗口、图标、菜单和指示器的图形用户界面。 (7) 软件开发瀑布模型的不可预测性。例如，市场压力意味着企业必须抢在竞争对手之前准备好新的产品和服务，否则，企业本身的

生存将会受到威胁。因此，如果传统的评审和测试技术需要大量的时间投入，但是却没有减少相应

的故障或失效率，那么这些技术就不能再使用。类似地，以前花在提高速度或减少空间方面的代码

优化的时间不再是明智的投资，因为增加磁盘和内存条对于该问题可能是更为便宜的解决方案。另外，桌面计算把开发的权利交到用户的手中，用户现在使用他们的系统开发电子表格和数据

库应用、小程序甚至是专门的用户界面模拟程序。这种开发责任的转移意味着软件工程师更有可能

构建比以前更为复杂的系统。类似地，大多数用户和开发人员可以利用巨大的网络资源，使得用户

更容易在没有特殊应用的情况下找到信息。例如，现在在万维网上搜索是快速、容易和有效的。用

户不再需要为找到自己所需要的内容而编写数据库应用。开发人员现在发现他们的工作价值也增加了。面向对象的技术、网络和复用库，使开发人员可

以直接、快速地将大量可复用模块用于新的应用中。并且，常常用专门的工具开发图形用户界面，

有助于使复杂的应用友好地面对用户。由于在分析问题方面我们已经变得精于此道，因此，现在能

够对一个系统进行划分，以便并行地开发其子系统，这就需要一个与“瀑布”模型有很大不同的开

发过程。将在第2章中看到，我们有很多选择，包括使我们建立原型的过程（用于同客户和用户一起

验证需求是否正确，并评价设计的可行性）和活动间正确迭代的过程。这些步骤有助于确保在将需

求和设计变成代码之前，使它们尽可能没有故障。

28

29

~

1.8.2 软件工程的 Wasserman 规范

Wasserman指出，7个技术变化中的任何一个都对软件开发过程有着重大的影响（Wasserman 1996）。它们合在一起，改变了我们的工作方式。在DeMarco的介绍中，描述了这种根本的转变：我

们首先解决了容易的问题——这意味着尚未解决的一组问题比以前更加困难了。Wasserman通过提出


软件工程中存在的8个基本概念来应对这一挑战。这些概念构成了有效的软件工程规范的基础。在这

里给出它们的简要介绍，在后面的章节中，将回过头来探讨它们在什么地方适用于我们所做的事情，

以及如何应用于我们所做的事情。 1．抽象有时，在一个问题的“自然状态”（即如同客户和用户表达的那样）考虑这个问题是一件令人畏

惧的事情。在问题的“自然状态”下，我们不可能发现以有效的或者甚至只是可行的方法处理问题

的显而易见的方式。抽象（abstraction）是在某种概括层次上对问题的描述，使得我们能够集中于问

题的关键方面而不会陷入细节。这个概念与转换（transformation）不同，转换是把问题转移到另外

一个我们理解得更好的环境中。转换通常用于将一个问题从现实世界转移到数学世界中，这样我们

能够利用数字的知识来解决问题。通常，抽象可以认为是标识对象的类，使得我们能够把多个项组合在一起。这样，我们处理的

事情可以更少，而且可以集中考虑每个类中各个项之间的共性。我们可以讨论一个类中各个项的性

质或属性，检查属性以及类之间的关系。例如，假定我们要为一条大的、复杂河流构建一个环境监

测系统。监控设备可能包括监测空气质量、水质、温度、流速以及其他环境特性的传感器。但是，

为了达到目的，我们可能决定定义一个称为“传感器”的类。类中的每个项具有固定的属性，不论

它监测哪个特性：高度、重量、电力需求、维护进度等。我们在了解问题环境的过程中，或在设计解

决方案的过程中，处理的是类，而不是它的元素。这样，类的使用有助于简化问题陈述以及集中于问

题的本质要素或特性。抽象也可以按层次的方式进行组织。例如，传感器是一种类型的电子设备，而我们可能有两种

类型的传感器：水传感器和空气传感器。因此，可以构成图1-13所示的简单层次结构。通过隐藏其中一些细节，我们可以集中精力考虑

必须处理的对象的本质特性，并且得到简单、优雅的解决方案。我们将在第5章、第6章和第7章中更

详细地讨论抽象和信息隐藏。

电子设备

传感器

水传感器空气传感器

图1-13 监控设备的简单层次结构

2．分析和设计方法以及表示法当设计一个作为课程作业的程序时，通常需要自己完成工作。产生的文档是一个正式描述，它

告诉你自己为什么选择这个特定的方法、变量名的含义是什么以及实现的算法。但是，当与团队一

起工作的时候，必须与开发过程中的其他参与者进行交流。大多数工程师，无论他们是做什么样的

工程，都会使用标准的表示法来帮助他们进行交流以及文档化相关决策。例如，建筑师画了一张图

或蓝图，任何其他的工程师都能够理解他画的图。更为重要的是，公共的表示法使得建筑承包商能

够理解建筑师的意图和想法。正如将在第4章、第5章、第6章和第7章中看到的，软件工程中没有类

似的标准，由此产生的误解是当今软件工程中的一个关键问题。

30

分析和设计方法不止是提供了交流媒介，还使我们能够建立模型并检查模型的完整性和一致性。

再者，我们可以更容易地从以前的项目中复用需求和设计组件，从而相对容易地提高生产率和质量。


但是，在我们能够决定一组标准的方法和工具之前，仍然有许多悬而未决的问题需要解决。正

如我们将在后面的章节中看到的那样，不同的工具和技术处理的是问题的不同方面，我们需要标识

建模原语，以便用一种技术就能获取问题的所有重要的方面。或者我们需要开发一种供所有方法使

用的表示技术，当然可能需要某种形式的剪裁。 3．用户界面原型化

原型化（prototyping）意味着构建一个系统的小版本，通常只有有限的功能，它可用于：帮助用户或客户标识系统的关键需求；证明设计或方法的可行性。

通常，原型化过程是迭代的：首先构建原型，然后对原型进行评估（利用用户和客户的反馈），

考虑如何改进产品或设计，之后再构建另外一个原型。当我们和客户认为手头问题的解决方案令人

满意时，迭代过程就终止了。原型化通常用来设计一个良好的用户界面（user interface），即系统与用户交互的部分。但是，

在其他场合也可以使用原型，甚至是在嵌入式系统（embedded system）（即其中的软件功能不是明确

地对用户可见的系统）中。原型能够向用户展示系统将会有什么样的功能，而不管它们是用硬件还

是用软件实现的。因为从某种意义上讲，用户界面是应用领域和软件开发团队之间的桥梁，所以，

原型化可以把使用其他需求分析方法不能明确的问题和假设表面化。我们将在第4章和第5章讨论用

户界面原型化的作用。 31

4．软件体系结构系统的整个体系结构不仅对实现和测试的方便性很重要，而且对维护和修改系统的速度和有效

性也是很重要的。体系结构的质量可能成就一个系统，也可能损害一个系统。事实上，Shaw和Garlan将体系结构独自作为规范，它影响整个开发过程（Shaw and Garlan 1996）。一个系统的体系结构应该

体现我们将在第5章和第7章学习的良好设计的原则。系统的体系结构根据一组体系结构单元以及单元之间的相互关系来描述系统。单元越独立，体

系结构越模块化，就越容易分别设计和开发不同的部分。Wasserman指出，至少有5种方法可以将系

统划分为单元（Wasserman 1996）。 (1) 模块化分解：基于指派到模块的功能。 (2) 面向数据的分解：基于外部数据结构。 (3) 面向事件的分解：基于系统必须处理的事件。 (4) 由外到内的设计：基于系统的用户输入。 (5) 面向对象的设计：基于标识的对象的类以及它们之间的相互关系。这些方法并不是相互排斥的。例如，可以用面向事件的分解设计用户界面，同时，使用面向对

象或面向数据的方法来设计数据库。我们将在后面的章节中进一步详细分析这些技术。这些方法之

所以重要，是因为它们体现了我们的设计经验，并通过复用已经做过的和所学到的，充分利用过去

的项目。 5．软件过程自从20世纪80年代后期以来，很多软件工程师已经在密切留意开发软件的过程以及由此产生

的产品。活动中的组织和规范对软件的质量和软件开发的速度的积极作用已经得到承认。然而，

Wasserman指出：

不同应用类型和组织文化之间的巨大差异使得对过程本身进行预先规定是不可能的。

因此，软件过程不可能以抽象和模块化的方式作为软件工程的基础。（Wasserman 1996）

相反，他提出，不同的软件类型需要不同的过程。尤其是，Wasserman指出企业范围的应用程序

需要大量的控制，而单个的或部门级的应用程序可以利用快速应用程序开发，如图1-14所示。


受控开发

快速应用程序开发

企业范围

应用程序

或区域范围

应用程序

部门应用

单用户，桌

面生产工具

● 数据包/ 小开发 ● 低成本/低风险 ● 单平台

● 关键任务 ● 多用户 ● 多平台 ● 2～3层开发

● 有限的范围/视景 ● 低/中风险 ● 单/多平台 ● 1～2层开发

图1-14 不同开发中的差别（Wasserman 1996）

利用目前的工具，很多中小规模的系统可以由一两个开发人员来完成，其中每个开发人员必须

担任多个角色。这样的工具可能包含文本编辑器、编程环境、测试支持工具，还可能包含一个获取

关于产品和过程的关键数据元素的小型数据库。因为项目的风险相对较低，所以需要很少的管理支

持或评审。但是，大型、复杂的系统需要更多的结构、检查和平衡。这些系统通常涉及很多客户和用户，

并且开发会持续很长时间。再者，因为某些关键子系统可能由他人提供或用硬件实现，开发人员并

不总是能够控制整个过程。这种类型的高风险系统需要分析和设计工具、项目管理、配置管理、更

复杂的测试工具以及对系统更严格的评审和因果分析。第2章将详细讨论若干可选的过程，以了解不

同的过程是如何处理不同的目标的。然后，在第12章和第13章，我们评估一些过程的有效性，并探

讨对它们进行改进的方法。 6．复用在软件开发和维护中，通常通过复用以前开发项目中的项来利用应用程序之间的共性。例如，

在不同的开发项目中，我们使用同样的操作系统和数据库管理系统，而不是每次都构建一个新的。

类似地，当我们构建一个与以前做过的项目类似但有所不同的系统时，可以复用需求集、部分设计

以及测试脚本或数据。Barnes和Bollinger指出，复用并不是一个新的思想，他们还给出了很多有趣的

例子，说明复用的不仅仅是代码（Barnes and Bollinger 1991）。 Prieto-Diaz介绍了这样一种理念：可复用构件是一种商业资产（Prieto-Diaz 1991）。公司和组织

机构对那些可复用的项进行投资，而当这些项再次用于后面的项目中的时候，就可以获得巨大的收

益。但是，制定一个长期、有效的可复用计划可能是很困难的，因为存在如下这些障碍。

32

33

~

有时候，构建一个小的构件比在可复用构件库中搜索这样一个构件要更快。要使一个构件足够通用、可以在将来被其他开发人员很容易地复用，则可能需要花费格外多

的时间。由于难以对做过的质量保证和测试的程度进行文档化，可能会导致一个潜在的复用人员认为

构件的质量是令人满意的。如果某个复用的构件失效或需要进行更新，不清楚谁应该对此负责。理解和复用一个由他人编写的构件，其代价可能是高昂的，也可能是很耗时的。在通用性和专业性之间通常存在冲突。

我们将在第12章中更详细地讨论复用，并研究几个成功复用的例子。


7．测度改进是软件工程研究的驱动力：通过改进过程、资源和方法，我们可以生产和维护更好的产品。

但是，我们有时只能概况地表示改进目标，原因是没有量化地描述我们做了什么以及我们的目标是

什么。正因为如此，软件测度已经成为好的软件工程实践的一个关键方面。通过量化我们做了什么

以及我们的目标是什么，就可以用通用数学语言来描述我们的行动和结果，从而使我们能够评估我

们的进展。另外，量化的方法允许我们比较不同项目的进展。例如，当John Young担任惠普公司的

CEO时，他设置了“10X”的目标，即无论对于何种应用的类型和领域，对于惠普的每一个项目，在

质量和生产率方面都要有10倍的提高（Grady and Caswell 1987）。在较低的抽象层次上，测度有助于使我们的过程和产品的特定特性更加可见。将我们对现实的、

经验世界的理解转换为形式化的、数学世界中的要素和相互关系，通常是有益的，这样，我们可以

操纵它们，从而得到进一步的理解。正如图1-15所示的那样，可以使用数学和统计的方法来解决问

题、寻找趋势或刻画一种情形（例如使用平均值和标准差）。而这个新的信息可以接着被映射回现实

世界，作为我们试图解决的现实问题的解决方案的一部分。在本书中，我们将看到测度如何应用于

支持分析和决策的例子。

现实的、经验的世界形式化的数学世界

测度形式化的相关系统

经验的相关系统

解决方案的实现

数学、统计学

解释经验的

相关结果数字的结果

图1-15 借助于测度发现解决方案

8．工具和集成环境多年以来，厂商一直推荐使用CASE（计算机辅助软件工程）工具，其中的标准化的集成开发环

境将增强软件开发。但是，我们已经看到，不同的开发人员是如何使用不同的过程、方法和资源的。

因此，一个统一的方法说起来容易，做起来就难了。另一方面，研究人员已经提出了几个框架，使我们能对已有的环境和打算构建的环境进行比较

和对照。这些框架还允许我们检验每个软件工程环境提供的服务，决定哪一个环境适合于给定的

问题或应用程序的开发。 34

对工具进行比较主要的难点之一是厂商很少针对整个开发生命周期。相反，他们集中于小的活

动集，例如设计或测试等，并且由用户把选择的工具集成到一个完整的开发环境中。Wasserman指出

了在任何工具集成中必须处理的下列5个问题（Wasserman 1990）。 (1) 平台集成：工具在异构型网络中的互操作能力。 (2) 表示集成：用户界面的共性。 (3) 过程集成：工具和开发过程之间的链接。 (4) 数据集成：工具共享数据的方式。 (5) 控制集成：一个工具通知和启动另一个工具中的动作的能力。在本书后面的每一章中，我们将研究支持我们本章描述的活动和概念的工具。你可以将这里描述的8个概念想象成把本书编织起来的8条线，它们把分离的活动连接起来，称

为软件工程。随着我们对软件工程了解得越来越多，我们将重新讨论这些概念，以了解它们是如何

1.9 信息系统的例子 25

把软件工程统一和提升为一个学科的。

1.9 信息系统的例子

本书每一章的结尾都有两个例子，一个是信息系统，另外一个是实时系统。我们把本章中描述

的概念应用到每一个例子的相关部分，这样你就能够了解概念在实践中的含义，而不仅仅是理论上

的含义。 35

信息系统的例子是从James和Suzanne Robertson写的Complete Systems Analysis：The Workbook, the Textbook, the Answers（Robertson and Robertson 1994）中抽取的（已获许可）。它是一个销售皮卡地

里电视台广告时间的系统开发实例。皮卡地里电视台拥有英国本土一定区域的特许经营权。图1-16显示出皮卡地里电视台的覆盖地区。正如我们看到的那样，电视时段价格方面的约束很多，因此，

这个问题很吸引人，难度也很大。本书强调了问题的诸多方面及其解决方案。Robertson的书介绍了

获取和分析系统需求的详细方法。

中部节目

皮卡地里电视台

图1-16 皮卡地里电视台特许覆盖区域

在英国，广播委员会授予商业电视公司为期8年的特许经营权，给予它在国内严格规定区域播放

节目的独家权限。作为回报，被授权者必须播放预先规定的短剧、喜剧、体育、儿童以及其他节目。

而且对于什么节目在何时可以播放、节目内容和商业广告内容也有相应的规定。广告商要向中部地区的观众播放广告，可以有若干选择：皮卡地里、有线频道和卫星频道。皮

卡地里吸引了大部分观众。因此，皮卡地里必须设定价格以吸引广告商的国内预算的那一部分。吸

引广告商注意力的方法之一是靠收视率，收视率反映了一天中不同时段观众的数量和类型。收视率

根据节目类型、观众类型、一天的时段、电视公司等进行报告。但是，广告收费不仅仅取决于收视

率。例如，如果广告商购买了很多小时的广告时间，那么每小时的价格可能会便宜一些。而且，特

定时间和特定节目中广告的类型也是有限制的。例如：酒类广告要在晚上9点以后才可以播放；如果某个演员出现在电视剧中，那么有这个演员的广告不能在该电视剧播出后的45分钟内

出现；如果某类产品的广告（如汽车）是为特定的商业插播安排的，那么这一类的任何其他广告都

不能在该插播中播出。 36

随着我们更详细地探讨这个例子，我们将注意到有关广告及其费用的其他规则和条例。从图1-17所示的系统环境图中，我们可以得知，系统的边界以及它如何与这些规则相联系。阴影的椭圆是我

们的信息系统例子皮卡地里系统，系统边界是椭圆的圆周。箭头和长方形表示可能影响皮卡地里系

统运转的项，但是，我们仅仅把它们作为一组输入和输出，它们分别具有自己的源地和目的地。


广告代理

拷贝播放规则

广告活动需求选择的

插播广告

广告更新请求代理

发票

同意的广告活动计费卡

抢先占有警告

建议的广告活动

更新确认

观众测量局电视收视率报告

节目播放表皮卡地里电视广

告时间销售

新节目商业拷贝带子销售目

标指导电视收视率报告

节目播放表

节目播放规则

节目购买

协议

产品公司皮卡地里管

理机构广播电视

委员会

节目供应方

图1-17 说明系统边界的皮卡地里系统背景图

在后面的章节中，我们将使阴影椭圆中（即系统边界内部的）的活动和元素可见，用每章描述

的软件工程技术检查这个系统的设计和开发。

1.10 实时系统的例子

下面举个实时系统的例子，我们来看阿丽亚娜5型火箭中的嵌入式软件。阿丽亚娜5型火箭属于

欧洲航天局（ESA）。1996年6月4日，在它的首次航行中，发射大约飞行了40秒钟后开始偏离航向，

在地面控制系统的引导下，火箭通过远程控制被销毁。销毁这个未保过险的火箭不仅损失了火箭本

身，而且也损失了它装载的4颗卫星。这次灾难共造成50亿美元的损失（Newsbytes home page 1996；Lions et al. 1996）。

37

从火箭导航系统到它各个组成部分的运行，几乎所有方面都与软件有关。火箭发射的失败以及

随后的销毁提出了很多与软件质量有关的问题。在后面的章节中会看到，调查委员会在调查原因时，

把重点放在了软件质量及软件质量保证上。在本章，我们根据火箭的商业价值来探讨质量问题。许多组织机构在阿丽亚娜5型火箭中有投资，包括ESA、法国中央国家航天局（CNES，负责阿

丽亚娜计划的全面指挥），以及其他12个欧洲国家。不断的延期和一连串问题损害了阿丽亚娜火箭计

划，这些问题还包括在1995年测试引擎的过程中，由于氮气泄漏导致两位工程师死亡的事故。但是，

1996年6月的事故是首次直接由软件失效导致的事故。这次事故的商业影响远远超过了50亿美元的设备损失。1996年，阿丽亚娜4型及其以前型号获得

了世界一半以上的发射合同，领先于美国、俄罗斯以及中国的运载火箭。因此，这次事故不仅使计

划的可信度大受损害，也使阿丽亚娜火箭的商业前景充满危机。新的生意部分基于新火箭能够把更重的负荷运载到轨道。阿丽亚娜5的设计目标是能运载一颗重

达6.8吨的卫星或两颗合在一起重达5.9吨的卫星，进一步的目标是希望在2002年之前达到更大的运载

能力。这些增加的运载能力具有明显的商业优势。通常，操作人员通过多颗卫星共同使用一个火箭

来减少发射费用，因此，阿丽亚娜能够同时运载多家公司的卫星。在这个例子的背景下，我们考虑一下质量的含义是什么。阿丽亚娜5型火箭的销毁证实，这个灾难

1.11 本章对单个开发人员的意义 27

性后果的原因是客户错误地说明了需求。既然这样，开发人员可能声称系统仍然是高质量的，只不过

是根据错误的需求规格说明构造了系统。的确，调查委员会在总结调查原因和补救措施时指出：

委员会的调查结果是基于阿丽亚娜5项目组完全的公开介绍和文档，这些文档从总体上表

明，从工程技术以及文档的完整性和文档可跟踪性来说，阿丽亚娜5的程序是高质量的

（Lions et al. 1996）。

但是从用户和客户的观点来看，规格说明的过程已经足够好，能够确定规格说明中的缺陷，并

且在灾难发生前，使客户能够改正规格说明中的缺陷。调查委员会认识到：

SRI（最终找到的引起问题的子系统）的厂商仅仅是遵循了给定的规格说明，即在检测到任

何异常的情况下，处理器将终止执行。异常的发生并不是因为偶尔的失效，而是由于一个

设计错误。异常被检测到了，但是并没有被适当处理。原因是采用了这样一种观点，即在

软件发生故障之前，就应该认为它是正确的。委员会有理由相信阿丽亚娜5软件设计的其他

部分也采纳了这个观点，而委员会支持相反的观点：应该假定软件是有故障的，直到应用

了目前可接受的最好的实践方法并能够证明它是正确的（Lions et al. 1996）。

在后面的章节中，我们将更详细地研究这个例子，探讨开发人员和客户决策中的设计、测试和

维护的含义。我们将看到，在开发初期，低质量的系统工程是如何导致一系列决策失误，进而又是

如何导致一系列灾难发生的。另一方面，包括ESA和调查委员会等所有相关机构的开诚布公，以及

高质量的文档和尽快得知真相的真诚的愿望，促成了眼前问题的快速解决和防止未来类似问题发

生的有效计划。

38

系统的观点使调查委员会和开发人员可以把阿丽亚娜5看作子系统的集合。这个集合反映了对问

题的分析，正如我们本章论述的那样，不同的开发人员能够开发具有明显不同功能的独立子系统。

例如：

发射器的飞行姿态和它在空间中的运动由惯性参照系统（SRI）测量。它具有自己内部的计

算机，根据捷联式惯性平台的信息，通过激光陀螺和加速器计算角度和速度。来自SRI的数据

通过数据总线传输到机载计算机（On-Board Computer，OBC），该计算机通过伺服阀门和液

压执行器执行飞行程序、控制固体推进器的喷射器和Vulcain低温引擎（Lions et al. 1996）。

但是综合的解决方案必须包括一个具有所有构件的总体视图，它把各个部件合在一起考虑，以

决定各部件之间的“联系”是否紧密、合适。在阿丽亚娜5的例子中，调查委员会提出客户和开发人

员应该一起工作以找出关键软件，并确保它不仅能够处理预测到的行为，而且能够处理未预测到的

行为。

这意味着，关键软件（从某种意义上来说，该软件的失效会使任务处于危险的境地）必须在

一个非常详细的层面标识出来，异常行为必须细化，并且一个合理的备份策略必须将软件

失效考虑进去（Lions et al. 1996）。

1.11 本章对单个开发人员的意义

本章介绍了许多概念，它们对于优秀的软件工程研究和实践来说都很重要。单个的软件开发人

员可以通过下面的方法使用这些概念。当有一个问题需要解决时（无论解决方案是否涉及软件），可以通过把问题分解成不同的组

成部分和各部分之间的关系来分析问题。然后，解决单个子问题并把它们合并成为统一的整

体，从而产生一个解决方案。


必须理解需求可能发生变化，即使在分析问题、形成解决方案时需求也会变化。因此，解决

方案必须是良好文档化的并且具有灵活性的，还应该把假设和使用的算法文档化（以便在以

后处理变化时使用）。 39

必须从几个不同的角度来观察质量，理解技术质量和商业质量可能有很大差异。可以使用抽象和测度帮助标识哪些是问题和解决方案的本质。必须牢记系统的边界，这样做出的解决方案才不会与相关系统发生重叠（相关系统是指与正

在构建的系统相互交互的系统）。

1.12 本章对开发团队的意义

大部分开发工作都是由大型开发团队的成员来完成的。正如本章所述，开发包括需求分析、设

计、实现、测试、配置管理、质量保证以及其他活动。开发团队中的有些成员可能会承担多个角色。

项目的成功在很大程度上取决于团队成员之间的交流与协调。在本章我们已经看到，通过以下选择，

可以帮助项目获得成功。一个适合团队规模、风险级别以及应用领域的开发过程。集成很好的工具，它们提供项目所要求的交流方式。测度和支持工具，它们提供尽可能多的可见性和易理解性。

1.13 本章对研究人员的意义

本章所讨论的许多问题是值得进一步研究的好课题。我们已经指出了软件工程中一些悬而未决

的问题，包括需要找到以下几项。适当的抽象级别：使得问题易于解决。适当的测度：使得问题和解决方案的本质可见且有用。适当的问题分解方法：使得每一个子问题都是可解决的。通用框架和表示法：允许方便有效的工具集成，使项目参加者之间的交流有效。

在后面的章节中我们会描述许多技术，其中一些一直在使用，并且是被软件开发实践充分证明

的。而其他一些技术是提议性质的，只在一些小的、“玩具式的”或学生项目中进行过演示。我们希

望告诉读者如何改进你的工作，并且激发你在将来尝试新的技术和进程方面的创造力和想像力。

1.14 学期项目

如果不与你的同事一起参与软件开发项目，是不可能学会软件工程的。因此，本书的每一章都

将介绍你可以与同学一起进行的学期项目的相关信息。学期项目是一个基于真实组织机构的真实系

统，是对分析、设计、实现、测试和维护的真正挑战。另外，因为你将会与一个团队一起工作，你

会面对团队的多样性和项目管理的问题。 40

这个学期项目是当你想买一套房子的时候，你可能与银行磋商贷款的方式。银行有很多途径获

得收入，通常是以较低利率从储户那里借钱，然后以较高的利率用贷款的方式把这些钱借出。长期

的房产贷款（比如抵押贷款）的期限一般有15、25甚至30年。也就是说，有15、25或30年的时间去

偿还贷款，包括本金（你初借的钱）和利息。尽管从这些贷款利息获得的收入是丰厚的，但由于

贷款占用时间很长，会妨碍银行进行其他投资。因此，银行常常把它们的贷款出售给财团机构，这

虽然减少了长期利润，但可以用其他方式使用资本。学期项目应用称为Loan Arranger。我们假设金融财团组织（FCO）处理从银行购买的贷款，然

1.15 主要参考文献 29

后再把它卖给投资者，从中获得利润。银行把款贷给FCO，FCO获得本金作为回报。然后，FCO把

贷款转让给那些愿意比银行等更长时间获得回报的投资者。要了解这一交易如何运作，考虑你获得房贷（称为“抵押贷款”）的情形。你可以首付5万元（称

为头期款）、贷款10万元购买一套15万元的房子。从第一国家银行贷款的“期限”可能是30年，利息

是5%。这意味着第一国家银行给你30年的时间来偿还你借的钱（“本金”）加上也不用立即偿还的利

息。例如，你可以通过每月付款一次的方式偿还10万元（也就是说，360个“分期付款”或“月供”），

并包括未付余额的利息。如果初的差额是10万元，银行根据本金的数额、利率、你偿还贷款的时

间和假定你每月等额偿还等因素来计算每月的付款额。例如，假设银行告诉你每月付款额是536.82元。第一个月的利息是（1/12）×（0.05）×（100 000

元）＝ 416.67元。其余的欠款额是本金减少120.15元（536.82元 − 416.67元）。第二个月，你现在欠

银行是100 000元减去120.15元，因此，利息减少为（1/12）×（0.05）×（100 000元 − 120.15元），即

416.17元。因此，在第二个月有416.17元的付款是利息，而其余的付款额120.65元支付的是本金。随

着时间的推移，你偿还的利息越来越少，并且剩下的本金越来越少，直到你付完所有的本金，完全

拥有自己的房子，并收回银行对财产的抵押权为止。在偿还贷款期间，第一国家银行可能把你的贷款卖给FCO一段时间。第一国家银行与FCO商谈

一个价格。依次地，FCO可能把你的贷款卖给ABC投资公司。你仍然必须每月偿付抵押贷款，但是

你的款付给了ABC，而不是第一国家银行。通常，FCO用“组合”的方式销售贷款，而不是单个贷

款，因此，投资者根据风险、包含的本金和期望的回报率购买贷款。换言之，像ABC这样的投资者

可以联系FCO，并指定希望投资多少钱、多长时间、希望承担多少风险（基于贷款人或组织机构偿

还贷款的历史）以及预期的利润。

41

Loan Arranger允许FCO的分析人员选择符合投资者期望的投资特性的一组贷款。该应用从各种

借款机构中访问FCO购买的贷款信息。当一个投资者指定投资标准后，系统选择优的、满足标准

的贷款组合。而系统支持更高级的优化策略，例如，从那些可用的子集中选择优的贷款组合（例

如是从马萨诸塞州所有的贷款而不是从所有可用的贷款中选择），系统也允许分析人员为客户从贷款

组合中手工选择贷款。另外，除了贷款组合的选择，系统还能将信息管理活动自动化。诸如，当银

行每月提供有关信息时，自动地更新银行信息、贷款信息以及增加新的贷款记录。现在总结一下上面的信息。Loan Arranger系统允许贷款分析人员访问FCO从多个贷款机构购买

的抵押贷款的相关信息（家庭贷款在这里也简单地被描述成“贷款”）。FCO的目的是将贷款重新打

包后卖给其他投资者。FCO把为投资的目的购买以及转卖的贷款统称为贷款投资组合。Loan Arranger系统在贷款信息库中跟踪这些贷款投资组合。贷款分析人员可以增加、浏览、更改或删除贷款投资

组合中关于借款方和贷款集合的相关信息。另外，系统允许贷款分析人员建立贷款组合以销售给投

资者。Loan Arranger的用户是贷款分析人员，他们跟踪FCO购买的抵押贷款。在后面的章节中，我们将更深入地探讨系统的需求。现在，如果你想理解本金和利息的相关信

息，可以复习以前的数学书，或查看http://www.interest.com/hugh/calc/formula.html。

1.15 主要参考文献

在风险论坛（Risk Forum）中，可以找到软件失效和软件故障的相关信息，该论坛由Peter Neumann主持。风险论坛中的有些文章发行在每一期的Software Engineering Notes中，该刊由计算机学会软件

工程专题小组（SIGSOFT）出版。可以在ftp.sri.com的Risks目录上访问到风险论坛归档的文章。

风险论坛新闻组可以从comp.risks在线阅读，或者通过自动列表服务器[email protected]订

阅。关于阿丽亚娜5型火箭项目的更多信息可以从欧洲航天局的网站获得：http://www.esrin.esa.it/

htdocs/esa/ariane。描述此项任务失败的ESA/CNES的联合新闻稿（英文）在http://www.esrin.esa.it/htdocs/


tidc/Press/Press96/pressl9.html。法文版的新闻稿在http://www.cnes.fr/Acces_Espace/Vol_50x.html。阿

丽亚娜5型火箭飞行501失败报告的电子版在http://www.esrin.esa.it/htdocs/tidc/Press/Press96/Ariane5rep. html。

Leveson和Turner非常详细地描述了Therac软件设计和测试问题（Leveson and Turner 1993）。 IEEE Software 1996年1月刊是软件质量专刊，尤其是Kitchenham和Pfleeger撰写了介绍性文章

（Kitchenham and Pfleeger 1996），描述并评论了几个质量框架。Dromey的文章论讨了如何用可测量的

方式定义质量（Dromey 1996）。

42

关于皮卡地里电视例子的更多信息，可以参考（Robertson and Robertson 1994）或访问

www.systemsguild.com网站了解Robertson的软件需求方法。

1.16 练习

11. 下面是《华盛顿邮报》曾经发表过的一篇文章（美联社1996）。

导航计算机错误导致飞机失事泛美航空公司称单字母编码是喷气式飞机在哥伦比亚坠毁的原因

达拉斯8月23日电——航空公司今天声称，去年12月在哥伦比亚失事的泛美航空公司喷气式飞机的

机长输入了一条错误的单字母计算机指令，正是这条指令使飞机撞到了山上。这次失事致使机上163人中除4人生还外，其余全部丧生。美国调查人员总结说，显然这架波音757飞机的机长认为他已经输入了目的地Cali的坐标。但是，

在大多数南美洲的航空图上，Cali的单字母编码与波哥大（Bogota）的编码相同，而波哥大位于相反方

向的132英里处。据泛美航空公司的首席飞行员和飞行副总裁Cecil Ewell的一封信中说，波哥大的坐标引导飞机撞到

了山上。Ewell说，在大多数计算机数据库中，波哥大和Cali的编码是不同的。泛美航空公司的发言人John Hotard确认，Ewell的信首先是在《达拉斯早间新闻》中报道，本周交

到了所有航空飞行员的手中以警告他们这种编码问题。泛美航空公司的发现也促使联邦航空局向所有的航空公司发布公告，警告他们有些计算机的数据

库与航空图存在不一致。计算机错误还不是引起这次失事原因的最终结论。哥伦比亚政府正在调查并希望在10月份以前公

布调查结果。国家运输安全委员会的发言人Pat Cariseo说，哥伦比亚调查人员也在检查飞行员训练和航空交通管

制的因素。 Ewell谈到当他们把喷气式飞机的导航计算机与失事计算机的信息相比较时，泛美航空公司的调查

人员发现了计算机错误。数据表明，错误持续了66秒钟未被检测到，而同时机组人员匆忙遵照航空交通管制的指令采取更

直接的途径到达Cali机场。 3分钟以后，当飞机仍在下降而机组人员设法解决飞机为什么已经转向时，飞机坠毁了。 Ewell说这次失事告诉了飞行员两个重要的教训。 43 “首先，不管你去过南美或任何其他地方多少次，比如落基山区，你绝对不能假设任何情况。”他

对报社记者说。其次，他说，飞行员必须明白他们不能让自动驾驶设备承担飞行的责任。

这篇文章就是软件危机存在的证据吗？软件工程如何使航空飞行变得更安全？在软件开发过程中应

该强调什么事项才会使我们在未来防止类似问题的发生？

12. 给出一个问题分析的例子，其中问题部分相对简单，但是解决问题的困难在于子问题之间的相互联系。

1.16 练习 31

13. 解释错误、故障和失效之间的区别。举出一个关于错误的例子，并且这个错误导致了需求、设计、代

码的故障。举出在需求中存在故障的例子，并且这个故障导致了失效。举出在设计中存在故障的例子，

并且这个故障导致了失效。举出在测试数据中存在故障的例子，并且这个故障导致了失效。 14. 为什么故障数目的计算可能误导产品质量的测量？ 15. 很多开发人员认为技术质量就等同于产品质量。举出一个具有很高技术质量的产品的例子，而这个产

品的客户并不认为该系统是高质量的。是否有道德的因素限制了对质量的认识，使人们仅仅考虑技术

质量？使用Therac-25的例子说明你的观点。 16. 很多组织机构购买商品化的软件，认为那样比内部开发和维护的软件便宜。论述使用COTS软件的利

与弊。例如，如果COTS产品的厂商不再支持该产品，将会发生什么样的情况？当在一个大系统中使

用COTS软件设计一个产品的时候，客户、用户和开发人员必须预见到哪些问题？ 17. 使用COTS软件的法律和道德含义是什么？分包合同的使用呢？例如，当COTS软件中一个故障导致主

系统失效时，谁来负责改正问题？当这样的失效直接（就像汽车中刹车失灵）或间接地（就像错误信

息被提供给其他系统时，如练习1中看到的那样）导致对用户的伤害时，谁应该为此负责？在COTS被集成到一个大系统之前，需要什么样的检查和权衡以保证COTS软件的质量？

18. 图1-17所示的皮卡地里系统的例子包含了大量的规则和约束。对其中3个规则和约束进行讨论，并解

释把它们置于系统边界之外的利与弊。 19. 阿丽亚娜5火箭坠毁成为法国和其他国家的头条新闻。法国《解放报》在头版把它称为“一场370亿法

郎的焰火表演”。事实上，这次爆炸是几乎所有欧洲报纸的头条新闻，也是大多数欧洲电视网晚间新

闻的头条。与此形成对照的是，由于纽约的互联网提供商Panix被黑客入侵，迫使Panix系统关闭了几

个小时。而这次事件的新闻仅仅出现在《华盛顿邮报》商业版的头版。当报道基于软件的突发事件时，

新闻的责任是什么？如何评价和报道软件失效的潜在影响？ 44

第章软件工程概述 -...

Documents

Transcript of 第章软件工程概述 -...

第 章 软件工程概述 -...

Documents

Transcript of 第 章 软件工程概述 -...

第章软件工程概述 -...

Transcript of 第章软件工程概述 -...