1、前言 理论研究与实践的桥梁 自从 1968 年 NATO 会议首次提出“软件工程”概念以来，它经历了一条漫长的道路。在几十年前， “软件”这 个概念本身 还不能被多 数人接受。 因而软件工 程理论研究 和实践必须建立 一个 坚固的 统一 标准使 得人 们懂得 在我 们现今 生活 中如何 建立 良好软 件和 怎样评 价软件的风险、 概率。 本文 融合了当前两种软件工程的潮流： 从实践者角度， 实践者的焦点在于建立高质量的软件产品， 提供实用的功能； 从研究者角度， 侧重于寻找提高质量途径， 提高实践者的生产效率。 本书用于研究生软件工程教材， 描绘了实用的软件工程理论和实践概况， 由于学生的经历
2、有限， 本书中所举的例子可能是超出我们的经验， 但这些例子足以清楚地阐述大型软件项目从设计到实现的整个开发过程。 此书还可作为本科生软件工程概念和实践的入门教材， 或用于软件开发人员扩充该领域知识。 本书中涵盖的各种样例： 大型项目， 小型项目， 面向对象和面向过程， 实时处理， 事务处理， 开发案例， 维护， 适合各种读者群。 12 章、 13 章和 14 章提供 的材料用于激励学 生启发思想，培养研究兴趣。 核心特征 与其他书相比本书具有如下特征： null 本书将许多评价标准综合运用于软件工程， 测量标准是软件工程策略的完整部分， 不能孤立看待。 这种综合看待软件工程测量标准的办法可以使
3、学生学会如何将定量分析， 定量改进运用到日常活动中。可以评价在个人方面、团体以及项目基础上的进步。 null 本书将许多概念，如：重用、风险管理、质量工程融于软件工程中，而非分裂处理。 null 每章用两个实例说明该章中的主要概念， 两个例子均来源于实际的项目。 信息系统实例描述了一个软件系统怎样确定一家英国大型电视公司广告时间价 格，实时系统实例给出 Ariane-5 火箭控制软件；在这些实例的问题报告中，我们还可以探索软件工程中的技术怎样定位问题所在及如何解决、 避免这些问题。 学生可以从这些实例中学到如何把软件工程技术运用到实际的系统中。 null 每章末尾， 给出该章主要内容对于小组开
4、发的意义、 个人开发意义、 研究意义。 学生 可以选择阅读，查找相关部分。 null 本书给出相关的网址， 文献， 网上相关的工具， 方法和学习指南。 从网上学生可获得 许多实际的需求文档、 设计、 代码、 测 试计划等相关信息。 一些声誉较好的网站上还有进一步深入的信息。 null 本书包含许多实例和文献中的样例。 其中的简略例子详细内容可在相关网页上查询。 从中可了解理论概念是怎样运用于实践的 null 每章末尾给出启发式问题， 这些问题涉及到软件工程的合法与伦理等方面。 学生可以从社会、 政治环境出发考虑这些问题。 和其他科学一样， 必须从他给人们生活带来的后果角度看待软件工程决策。 n
5、ull 面向过程和面向对象两种思想方法在每章中都有体现。 此外将有一章专门阐述面向对象的发展过程， 面向对象的开发过程。 此处使用 UML 描述通用概念。 面向对象开发的每1一步均有实例说明。 null 本书给出注解文献的出处， 网址， 讨 论小组以及专业领域如： 软件可靠性、 容错、 计 算机安全等的相关联接。 null 本书给出解决方案手册，可以在 Prentice Hall 得到， Power Point 格式。 null 每章介绍一个项目， 比如抵押处理软件系统开发， 老师可以针对这些项目介绍， 项目变体作为课堂作业。 null 每章后给出概念索引。 内容与组织 本书分为三部分： 第一
6、部分 （第一章至第三章） 启发读者阐述软件工程知识对于实践者和研究人员的重要性， 讨论了问题理解， 项目计划意义； 第二部分 （第四章至第十一章） 详细阐述开发维护主要步骤， 可以不考虑创建软件的处理模型： 需求检查、 需求获得、 设计 问题解决方案， 代码编写和测试、 提交用户； 第三部分 （第十二章到第十四章） 集中讨论评 价与改进。这里将阐述我们如何看待软件产品的质量和怎样提高质量。 第一章：为何需要软件工程 在本章中， 我们首先说 明每种关键 问题均出现 在后面的那 些章节中。 然后参 考Wassermans 的核心因素给出软件工程的定义：抽象、分析、方法设计、专用符号、模块和体系结构
7、， 软件生命周期、 出版， 重用、 测量， 工具， 环境集成， 用户界面。 接着讨论计 算机科学和软件工程之间的差别， 解释一些可能遇到的问题， 给本书其它部分打下地基。 最后阐明了实用系统方法建立软件的必要性， 给出的两个实例是各章中都将用到的， 同时给出这些实例的工程背景。 第二章：过程模块与生命周期 给出各种不同类型的处理和生命周期模块概要， 包括： 瀑布 模式， V 模式， 螺旋模式以及其他原型。 我们还将讨论几种建模技术， 工具， 包括系统动力， SADT 和常用方法。 对于两个实例我们都给出模块分析。 第三章：项目计划与管理 本章主要讲解项目计划和进度安排。 引入几个概念， 比如：
8、 工作量， 里程碑， 进度安排表， 任务图， 风险管理， 成本估算。 同样我们将用估算模型评价两个实例的成本代价。 集中于 F-16 飞行器软件开发系统和 Digitals alpha AXP 项目的软件开发与管理的成本估算。 第四章：需求分析 本章讲解需求分析和需求说明书， 阐明功能需求与非功能需求的差别， 分别用几种不同的方式说明他们之间的差别， 讨论如何建立需求原型。 并且使用各种正式的方法说明和评价需求。此外还包括需求文档书写，需求文档回顾，需求质量及评价，需求可测性。 2第五章：系统设计 本章主要考虑系统结构问题。 首先讨论 Shaw 和 Garlan 的软件 体系结构框架。 接着描
9、述概念设计和技术设计的区别。 讨论负责设计的人员的角色， 两种基本设计方法： 组合法与分解法。然后给出良好设计特征，介绍几个设计策略，给出若干系统设计技术的实例，工具。在本章中读者还将学到客户 -服务器体系结构，可重用设计组件，人机接口设计，安全与可靠性设计（ 包括出错处 理和容错技 术） ，设计模 式，正式的 设计方法， 设计协议评 价。在解释了如何评价设计质量和正确性证明，怎样书写结果文档，我们转向代码设计阶段。 代码设计分别用模块化设计和独立设计用两种方法： 自顶向下， 自底向上解释， 并给出逻辑设计和物理设计的区别。 针对并发与安全性要求较高的系统， 我们检查其设计上的因差错而导致的
10、Therac-25 的 功能故障。举出若干设计工具，彻底讨论设计质量以及怎样衡量。最后结合信息系统和时实系统两个实例给出软件设计的实例。 第六章：关于对象 第六章从间接的角度考虑面向对象开发的特殊性质。 我们先给出使用案例的背景， 讨论如何从需求中获得对象、 对象特征。 其次要检查系统设计。 接着扩充系统设计， 加入非功能性需求， 编程设计的代码细节。 使用 UML 和构 造图， 我们可以产生面向对象的系统说明和系统设计，这里所用的实例是空军服务站系统。 对于面向对象开发的评价， 我们使用普通的面向对象规则评价服务站系统。 可以从中学到如何在规则中加入适当的改变有助于我们决定如何分配资源，寻找
11、错误。 第七章：编写代码 在本章中将讲解如何编写高质量的代码实现系统设计。 将着重讨论代码编写标准、 编写过程、 提倡使用简单实用的编程指导。 在这里给出两种类型语言的编程实例： 面向对象和面向过程。并讨论代码文档的必要性，错误处理措施。 第八章：程序测试 本章将从不同侧面考虑程序测试，比较两种方法，确认软件系统。给出软件问题定义，分类。 分类方法怎样使数据采集， 数据分析更加有效。 解释单元测试和整体测试的区别。 引入若干软件自动测试工具和技术， 测试生命周期的必要， 以及如何将这些工具、 技术集成到系统中。 第九章：系统测试 首先给出系统测试的原则， 包括测试和数据的重用性， 配置管理。
12、所引入的概念还包括：功能测试、 性能测试、 确认测试、 安装测试。 同时分析了面向对象系统的特殊测试需求。 这里给出几个测试工具， 测试小组的成员讨论内容。 接下来介绍软件可靠性模型， 可靠性问题，软件可维护性，适用性。读者可从中学会如何使用测试结果评价提交产品可能具有的特征。 第十章：系统递交 本章讲解培训与文档记录的必要性。 3第十一章：系统维护 本章我们涉及到系统变化问题， 系统变化在系统生命周期中怎样产生， 随之而来的系统设计、 代码、 测试处理、 文档变化。 并讨论典型的系统维护问题配置管理的必要性。 并彻底讨论了对可能出现变化及变化所带来后果的评测。 第十二章：产品，过程，资源评估
13、 因为许多 软 件工程决 策 涉及现存 组 件集成与 整 合，那么 就 需要一种 方 法评价过 程与 产品。 在这里我们给出经验法评估以及若干评价策略。 这些规则用来建立质量和生产力的基线。在这里使用几个质量模型，评价系统可重用性，后期使用，理解信息技术投资的回报。 第十三章：预测，处理和资源的改进 本章建立在第十一章基础上，包括几个比较深入的实例用来表示预测模型，检测技术，可以扩充软件工程的其他方面的理解并有助于提高投资技术水平的提高。 第十四章：软件工程的前景 在最后一章，我们探索几个软件工程领域的若干公开问题。重温 Wasserman 的几个概念重新看待将软件工程作为一门学科我们在相关行
14、业做得如何。 此外还要讨论在研究成果转化成实际应用时若干技术转移问题和决策制定的改进与提高。 致谢 感谢朋友和家人给我的技术与情感上的支持。 对于不能够将所有在编写本书过程中曾给过我帮助和支持的人的名字列在这里深表遗憾和歉意。 Carolyn Seaman (马里兰大学 -巴尔的摩校区 )出色的评论家，提出简化澄清的种种方法，帮助我写出更加紧凑，更易于理解的内容， 此外她还给出了绝大多数习题的答案， 并给该书分配了网址。 在此衷心感谢她的友善和帮助。 Forrest Shull (Fraunhofer Center ) 更新答案使它们能够反映最新的习题与材料。 Yiqing Liang 修复了
15、 网上的连接错误， 添加了新的材料。 Carla Valle， 来自里约热内卢联合大学， 更新网址并更新了网上资源。 尤其要感激的是 Guilherme Travassos，他允许我们使用在马里兰大学 -College Park 共同开发的项目材料。感激 Manny Lawrence， 实时空 军服务站系统经理，以及他的簿记员 Bea Lawrence，感谢他们和我们这些共同的工作和生活经历。 习题 1 怎样用处 理模型的相关概念描述一个系统？例如： 如何确定一个用处理模型描述的系统的上届？ 2 对本章中的每个模型，分别列举其优点和缺点。 3 本章中的每个模型是如何处理未来需求分析的改变。 4
16、 请画出一个商务旅行的机票订购处理图。 5 画出 Lai 公 司人造用品表， 要求包括人造用品没经测试状态、 部分经过测试状态， 完全经过测试状态。 46 用自己选 择的符号画出软件系统的开发过程， 给出三种不同的处理原型， 从中选择一个最佳的。 7 仔细考虑 2.4 节处理模 型的特征， 这里的特征对于问题和解决方案还没经彻底理解的项目非常重要。 8 在本章中 ， 我们强调软件开发是一个创造性的过程， 而非一个完全的生产过程。 讨论一现代有软件开发的生产的特征，并解释为何软件开发是一个创造性的过程。 9 一个开发 组织可以采用一个单一的处理模式处理所有的软件开发， 讨论它的正面和反面作用。
17、10 假如与某用户的合同 指明要求使 用某个特殊 的软件开发 工具，那么 这项工作应 该怎样管理？ 11 考虑本章对处理的介绍。哪一个对于需求变化反映的灵活性最大。 12 假设 Amalgamated 公 司在签订创建一个系统时合同中指明要使用某给定的模型。 你答应使用事先规定的这些人力、 物力资源和软件资源。 在软件交付和安装后， 系统遇到了一个灾难性的错误。当 Amalgamated 公司 开始调查错误原因时，你被指责没有做代码检查，这些检查可以发现递交时问题所在。 你反驳： 城代码检查并不在所要求得的处理中。 那么在这场争论中法律问题和伦理问题的焦点是什么？ 5第 1 章 为什么进行软件
18、工程 ? 在本章，我们来看一下： null 软件工程意味着什么 null 软件工程的发展 null “好软件”意味着什么 null 一个系统方法为什么重要 null 自 20 世纪 70 年代来软件工程的变化 软件遍及我们的世界， 我们有时把软件在使我们的生活更舒适、 有效率的过程中所扮演的重要角色视为当然。 例如， 考虑为早餐准备烤面包这样的简单任务。 烤箱中的代码控制面包变褐的程度及何时成品出箱。 程序调控屋子的供电， 软件为我们的能源消费记帐。 实际上，我们可能使用自动程序付电费、 定购更多杂货甚至买新的烤箱。 事实上， 现在软件或者显式的或者在幕后为我们生活的各方面服务，包括那些影响我
19、们健康和财富的重要系统。因此，软件工程显得比以往更加重要。 好的软件工程的实施必须确保软件在我们引导我们的生活中做出积极的贡献。 本书着重于软件工程中的关键问题，描述了我们所知道的有关技术和工具方面的东西，以及它们是怎样影响我们建造和使用的那些产品的。 我们从理论和实践上来看一看： 我们知道的东西和它如何应用于一个典型的软件开发或维护工程中的。 我们也检查一下我们还不知道的东西，而这些东西将有助于使我们的产品更可靠，安全、有用和易于理解。 我们从考虑我们怎样分析问题和提出解决方案方面着手。 然后我们研究一下计算机科学问题和工程问题间的差异。 而最终的目标是得到生成高质量软件的方案， 并且我们还
20、考虑为这种质量做出了贡献的特征。 我们也着眼于我们作为软件系统开发者已有的成败。 通过检查几个软件失败的例子， 我们来弄明白我们已经走得多远、及为了掌握质量软件开发的艺术我们还将必须走更远。 接着， 我们考虑一下与软件开发相关的人。 在描述顾客、 用户和开发者的角色和职责后，我们研究系统本身。 我们知道一个系统可被视作与一活动集相关并用某种边界封装的一组对象。 作为选择， 我们用一个工程师的眼睛来看待一个系统； 开发一个系统恰似修建一座房屋。在确定了建立系统的系列步骤后，我们讨论开发小组在每步中的角色。 最后，我 们 讨论一些 已 经对我们 实 施软件工 程 的方式产 生 影响的那 些 变化。
21、我 们介 绍Wasserman 的八条思想把我们的实践联系在一起以形成一个连贯的整体。 1.1 什么是软件工程？ 作为软件工程师， 我们运用计算机和计算的知识来帮助解决问题。 通常要处理的问题与计算机或现存计算机系统有关， 但有时问题中潜在困难与计算机没有关系。 因此， 首先理解问题的本质是很重要的。 特别地， 我们必须要小心， 不要把计算机械和技术强加于我们遇到的每个问题上。 首先必须解决这个问题。 然后， 如果需要， 使用技术作为工具来实现我们的解决方案。 在本书其他部分， 我们假定我们的分析已经表明某些种类的计算机系统对解决手头一类特别问题是必须且使人满意的。 1解决问题 大多数问题是庞
22、大的， 有时处理起来棘手， 特别是如果它们提出了某些以前从没解决过的新东西。 因此我们必须通过分析来对它开始进行调查， 也就是把问题分解成我们能理解并尽量能处理的问题片。因而我们能够把这个大问题用小问题集和它们间的相互关系来描述。图 1.1 解释了 如何分析。 重要的是要记住关系 （图中的箭头， 及子问题的相对位置） 跟子 问题本身一样重要。 有时， 正是关系保持着怎样解决大问题的线索， 而不简单是子问题的本身特性。 一旦分析了问题， 我们必须从表述问题各方面的部件来构建解决方案。 图 1.2 解释 了这个相反的过 程：综合 (Synthesis)，就是把从小建 筑块装配成 一个大建筑 。随着
23、分析 ，单个 解决方案的合成可能跟寻找这些方案本身一样富有挑战性。 为了弄清为什么， 考虑写一本小说的过程。 字典包含了所有你可能想在作品里使用的词。 但是， 写作最困难的部分就是决定怎样组字成句， 同样的， 组 句成段、 章以形成这部完整的书。 因此， 任何解决问题的技巧必须有两部分：分析问题以弄清它的本质，然后基于分析综合 /合成出一个解决方案。 子问题 2问 题 子问题 1 子问题 4 子问题 3图 1.1 分析过程 2子问题 2为 了 有 助 于 解 决 问 题 ， 我 们 使 用 各 种 方 法 （ method） 、工具 （ tool） 、程 序（ procedure）及 范件 事
24、 情 的 设 备 或 自 动 化 系 统 。 在这里 “更好方式” 可能意味着这件工具使用我们更准确、 更有效率、 或更多产、 或增强了所得产品的质量。 例如， 我们使用打字机或键盘和打印机来写信是因为所得文档比手写更易于阅读。 或者我们用一把剪刀作为一种工具是因为比起撕一张纸使用剪刀会剪得更快更直。 然而， 工具： 是一致地 产生特别产品的工具和方法的组合。 打就象将在后面章节看到的， 我们的测试计划描述了我们的测试程序； 它们告诉我们范例。 一种范例比不比另一个好； 每一种都有它自己的优势和劣势， 一个比另一个更恰当是最新的一套工具和方法的指示器本书相关 WWW 主页上。 置我 们 使 用
25、 各 种 方 法 （ ） 、工具 （ ） 、程 序（ ）件 事 情 的 设 备 或 自 动 化 系 统 。 在这里 “更好方式” 可能意味着这件工具使用我们更准确、 更有效率、 或更多产、 或增强了所得产品的质量。 例如， 我们使用打字机或键盘和打印机来写信是因为所得文档比手写更易于阅读。 或者我们用一把剪刀作为一种工具是因为比起撕一张纸使用剪刀会剪得更快更直。 然而， 工具并不总是更好地做某件事所必须的。 例如， 一个烹饪方法能做出更好的调料而不是厨师所使用的罐也非勺。 ： 是一致地 产生特别产品的工具和方法的组合。 打就象将在后面章节看到的， 我们的测试计划描述了我们的测试程序； 它们告诉
26、我们范例。 一种范例比不比另一个好； 每一种都有它自己的优势和劣势， 一个比另一个更恰当是最新的一套工具和方法的指示器本书相关 主页上。例 （ paradigm） 。一种 方法（ method/technique） 就是一种 用 于产生某 种 结果的正 式 的 程序（ procedure） 。 例 如 ， 一 个厨师准备调料时， 他 使用一系列成分并结合一套仔细排好的时 、序步骤以便调料变浓但又不凝固或分散。 准备调料的程序与时间选择和成分有关但可能并不依赖于使用何种类型的烹饪设备。 一件工具 （ tool） 是一件能 以 更 好 的 方 式 完 成 某）序（ ） 。 例 如 ， 一 个厨师准
27、备调料时， 他 使用一系列成分并结合一套仔细排好的时 、序步骤以便调料变浓但又不凝固或分散。 准备调料的程序与时间选择和成分有关但可能并不依赖于使用何种类型的烹饪设备。一件工具 （ ） 是一件能 以 更 好 的 方 式 完 成 某并不总是更好地做某件事所必须的。 例如， 一个烹饪方法能做出更好的调料而不是厨师所使用的罐也非勺。一个程序 （ procedure） 就 象 一 个 秘 诀个比方，一个程序 （ ） 就 象 一 个 秘 诀个比方，在何种情形下用何种工具作用在何种数据集上以便让我们检查出软件是否满足要求。最后， 范例就象一种烹饪风格； 它提供了一个特别的构建软件的方案或哲学。 恰就象我们
28、能区别出法国烹饪和中国烹饪一样， 我们也能区别出象面向对象开发和过程化开发这样的有条件的。 软件工程师使用工具、 方法、 程序和范例来增强他们软件产品的质量。 他们的目标就是使用有效的富有成果的途径来产生有效的问题解决方案。 在后续几章中， 我们将突出一些支持我们所述的开发维护活动的特别途径。在何种情形下用何种工具作用在何种数据集上以便让我们检查出软件是否满足要求。最后， 范例就象一种烹饪风格； 它提供了一个特别的构建软件的方案或哲学。 恰就象我们能区别出法国烹饪和中国烹饪一样， 我们也能区别出象面向对象开发和过程化开发这样的有条件的。软件工程师使用工具、 方法、 程序和范例来增强他们软件产品
29、的质量。 他们的目标就是使用有效的富有成果的途径来产生有效的问题解决方案。 在后续几章中， 我们将突出一些支持我们所述的开发维护活动的特别途径。软 件 工 程 师 的 位 为了理解一名软件工程师是怎样适合计算机世界的， 让我们举例看一下另一学科。 考虑化学研究和它对解决问题的作用。 化学家调查化学制剂： 结构、 相互的作用及在行为后的原为了理解一名软件工程师是怎样适合计算机世界的， 让我们举例看一下另一学科。 考虑化学研究和它对解决问题的作用。 化学家调查化学制剂： 结构、 相互的作用及在行为后的原图问 题 子问题 1 子问题 4 子问题 31.2 综合过程 3理 。 药 剂 工 程 师 把
30、化 学 家 的 研 究 运 用 于 各 种 问 题 。 化 学 被 化 学 家 视 为 研 究 对 象 。 另 一 方 面 ，对药剂工程师来说， 化学是一门工具， 被用于解决一般的问题 （可能甚至在本质上不是 “ 化学的” ） 。 我们可同样地看待计算。 我们可能关注于计算机和程序语言本身， 或者我们视它们为工具被用于设计、 实现一个问题解决方案。 软件工程是从后者角度来看的， 就象如图 1.3 所示 。一名软件工程师集中于把计算机作为一个解决问题的工具， 而不是调查硬件的设计或证明有关算法如何工作理论。 我们会在本章后面看到一名软件工程师把计算机的功能作为一般解决方 案 的 一 部 分 ，
31、而 非 计 算 机 自 身 的 结 构 或 理 论 。 1.2 我们已经取得的成功 软 件 既 是 一 门 科 学 也 是 门 艺 术 ， 作为一名计算机科学的学生理解这是为什么是很重要的。 计出现前的生活 。软件在医学、农业、运输和其他大部分行业支持着生命维系或生命救治方面的进步。另外，软件已经使我们能做我们以前从没做过的事情：显微外科、多媒体教育、机器人技术。 计算机科学 顾客 理论 计算机功能 问题软件工程 解决问题的工具、方法 图 1.3 计算机科学和软件工程间的关系写算 机 科 学 家 和 软 件 工 程 研 究 员 研 究 计 算 机 机 制 ， 和 理 论 化 有 关 怎 样 使
32、 计 算 机 多 产 有 效 。然 而 ， 他 们 也 设 计 计 算 机 系 统 并 写 程 序 以 便 在 那 些 系 统 上 能 执 行 任 务 ， 这是一项很有艺术性、独创性、 技巧性的实践工作。 在一个特定的系统上或许有许多执行任务的方式， 但一些比另外的更好。 一种方式可能更有效率、 更精确、 更 易 修 改 、 更易使用或更易理解。 任何黑客能写出使用某物工作的代码， 但是要产生健壮的、 易于理解和维护、 其工作起来尽可能最有效率和效果的代码， 是需要有专业软件工程师的技能和理解力的。 从而， 软件工程将设计和开发高质量的软件。 在 调 查 出 完 成 高 质 量 软 件 系 统
33、 要 具 备 的 东 西 前 ， 让 我 们 回 顾 一 下 我 们 已 经 取 得 的 成 功 。用户对现存的软件系统满意吗？是也不是。 软件使我们能比以前任何时候更快更有效的执行任务。 想一下， 在， 例如 字处理软件、 电子表格软件、 电子邮件、 精 巧 电 话 ，4然而软件不是说没有自身的问题。 通常系统运行却不是严密地按我们所期望的那样。 我们所有人都听说过有些系统几乎就不能工作的事情。 我们都写过不完善的程序： 一些仍然包含失误 的代 码，而 在偶 然的评 定或 在只是 演示 一个方 案可 行性的 时候 这样的 代码 又是够 好的 。不 久 必 须 被替换 ”（ Sa显 然 ， 在
34、 开 发 一 个 交 付 给 用 户 使 用 的 系 统 的 时 候 ， 此 种 行 为 是 不 可 接 受 的 。 一类工程 的 一个错误 与 一个大的 软 件系统中 的 一个错误 二 者间是有 很 大差别的 。实 际上， （人们） 在文献里或 走廊里频繁 讨论软件故 障和生产无 故障软件面 临的困难。 一些故障仅仅有点让人讨厌； 而别的将花费大量的时间和金钱。 还有些甚至威胁生命。 补充栏 1.1 解释了故障 （ fault） 、错 误（ error） 和失败 （ failure） 间的关系。 让我们看一些失败的例子， 注意发生了什么故障及为什么会这样。 补充栏 1.1 描述臭虫（ Bug
35、）的术语 通常我们说起软件里“臭虫”这暗示着有一个它所依赖的上下文环境。 一个 Bug 可能是理解需求时的一个误会、一片代码里的语法错误，或者（尚未知的）系统崩溃的原因。为了描绘软件产品中的 Bug， IEEE 已经提出了一套标准术语（ IEEE标准 729， IEEE 1983） 。 要 求 行 为 的 偏 离 。 它能在系统交付之前或之后 （在测试、操视 图 ， 而失败是外部视图： 用户能看 到的因人误解 时产生一个故障 （ fault） ， 而它称为错误 （ error） 当在执行某个软件活动而产生时。 例如， 一个设计者可能误解了一条需求而做了与实际的分析员和用户的需求真实意图不符的设
36、计。 这条设计故障便是一个错误的前奏， 并且它会导致别的故障， 如不正确的代码和用户手册中一条不正确的描述。 因此， 一个简单的错误会产生许多故障， 并且一个故障能出现在任何开发或维护产品的过程中。 失败 （ failure） 是一个对 系 统作 或 维 护 过 程 中 ） 被发现。 因为需求文档可能包含故障， 一个失败指示出系统没有按需运行，即使它可能按指定的步骤执行。 因此， 从 开发者的角度来看， 故 障 是 系 统 内 部问 题 。 并非每个故障对应一个失败； 例如， 如果不完善代码从不被执行或从不进入特别状态，那么故障将从不会引起代码失败。图 1.4 显示了失败的起源。 人为错误 （
37、 human error） 故障 （ fault）失败 （ failure）在 20 世纪 80 年代， 美国国税局 （ IRS， the United States Internal Revenue Service）雇 请Sperry 公司建立联邦收入税表格自动处理系统。 按照华盛顿邮报 （ Washington Post） 的 说 法 ，“已经证明 系统不足以 应付工作量 ，并且花费 了预期的近 两倍的费用 ，可能导致可能导致 图 1.4 人为错误（ error）怎样引起失败（ failure） wyer 1985） 。在 1985 年，为了增 强原本价值 1 亿零 3 百万 美元的 Sp
38、erry 设备又追加了9 千万美元。 另外，因为那些问题妨碍了在最后期限里向纳税者返还退款， IRS 被迫支付了4 千零 2 百万 美元的利息及 2 千 2 百 3 十万美元的 雇员的加班费 （雇员一直努力跟上工作进度） 。在 1996 年，形式仍没有改观。洛杉矶时报在三月二十九号报到说对于 IRS 的计算机现代化工作仍然没有任何高明计划， 仅仅是一份 6000 页的技术 文档。 国会议员 Jim Lightfoot把这项 工程 称为“ 因为 计划不 充分 导致的 仍在 挣扎着的 40 亿美元的 大惨败” （ Vartabedian 1996） 。我们将会在第二章看到为什么项目计划对质量软件生产是重要的。 5
