蓝田玉PDF文档网 / 电脑教程 / 软件工程——实践者的研究方法
 


软件工程——实践者的研究方法



前 言


  软件工程已进入到目前的第四代,它已具有许多优势,虽然它仍存在同 时代人曾经历的某些弱点,但其早年的天真和热情已被更合理的经历多年培 育的期望(以及甚至善意的嘲讽)所替代,软件工程正带着许多成就步入中 年,然而还有大量工作需要去做,今天,它已被公认为一个重要学科,值得 认真地研究、细心地学习和热烈地争论。在整个产业界,“软件工程师”已 经替代“程序员”成为更受欢迎的工作头衔。产业应用软件中已广泛而成功 地采用了软件过程模型、软件工程方法以及软件工具。管理者和实践者均认 识到,需要一个更严谨的软件方法来支持手头的工作。
  但是,在本书的早期版本中很多讨论的问题仍然存在,很多个人和公司 仍然在随意地开发软件,很多专业人员和学生不知道现代方法,最终,我们 生产的软件仍然存在大量质量问题。此外,关于软件工程方法的真实性质的 争论仍在继续。然而,今天软件工程已成为研究的热点,人们对它的态度已 有很大变化,它的发展也很明显,但是,要使软件工程最终发展成为一个完 全成熟的学科还需做大量工作。
  本书的第 4 版试图成为正逐步走向成熟的软件工程学科的一个指南。和 前面三版一样,第 4 版的主要读者群仍然是学生和实践者,而且在写作风格 上我们力图仍然保持前面各版的格式和风格。本书的基本目标仍然是:作为 产业界专业人员的指南以及作为高年级大学生和一年级研究生的软件工程的 全面导论。
我们在第 4 版中并不仅仅简单地修订了原稿,为适应本领域快速的增长
我们完全重新组织了书中的内容,并着重讨论了新的重要的软件工程方法, 还全面地修订了从早期版本保留的章节,加入了 12 章新内容,以提供对当代 趋势和技术的完整讨论。加入了很多新例子、思考题,每一章中还增补了推 荐阅读文献及其他信息搜索地址,包括数百个新的出版站点以及超过 160 个 WWW 信息站地。
第 4 版由 5 个部分共 30 章构成。这样做的目的是按专题安排内容,并使
那些没有时间在一个学期内完成书中内容教学任务的老师,可以按需取用。 第一部分:产品和过程,简介软件工程的相关语境,引出书中主要内容,并 着重介绍了以后章节用到的概念;第二部分:管理软件项目,讨论那些与计 划、管理和控制软件开发项目的人员相关的话题;第三部分:传统软件工程 方法,讨论那些被视为传统软件工程不同“学派”的分析、设计和测试方法; 第四部分:面向对象软件工程,讨论跨越整个软件工程过程的面向对象方法, 包括分析、设计和测试方法;第五部分:软件工程高级课题,分章专门讨论 形式化方法、净室软件工程、复用、再建工程、客户/服务器软件工程和 CASE。
  第 4 版比以前版本更多地强调了度量和测度方面的相关技术。有三章和 软件度量相关,分别是:软件过程和项目的度量、软件的技术度量、面向对 象系统的技术度量。
  本书的组织使得老师可以根据时间和学生需要安排授课话题。一个学期 可选择一个或多个部分。例如,“设计课程”可能只需要第三或第四部分, “方法课程”可能只需第三、第四和第五部分的部分章节,“管理课程”可 能只需要第一和第二部分。按这种方式组织本书第 4 版,目的是给老师提供 灵活的教学选择。
  
  第 4 版的写作工作已成为我生活中持续最长的技术计划。即使当写作停 止时,从各种技术文献中提炼、组织信息的工作也一直在进行,为此,我要 感谢许多书籍、论文和文章的作者,以及新一代的电子媒体(新闻组和 WWW) 的贡献者们,他们在过去的 15 年中给我提供了大量的信息资源、思想和评 注,很多信息资源已在每章的参考文献中列出,他们在这个快速发展的领域 中的贡献是值得称道的。我还要感谢第 4 版的审阅者:Wayne State University 的 Frank H.Westervelt、The University of Connecticut 的 Steven A.Demurjian、California State PolytechnicUniversity 的 Chung Lee、University of Colorado 的 Alan Davis、QSM Associates 的 Michael C.Mah、University of California-Irvine 的 Richard N.Taylor、Virginia Tech.的 Osman Balci、AuburnUniversity 的 James H.Cross、Portland State University 的 Warren Harrison、NortheasternUniversity 的 Mieczyslaw M.Kokar,他们的评注和批评是无价的。
  本书第 4 版内容的成型有赖于许多曾经使用过本书以前版本的产业界专 业人员、大学教授和学生,他们花了很多时间和我通信交流他们的建议、批 评和思想,我要感谢他们中的每一位。
  此外,我也要向我们的在北美和欧洲的许多产业客户表示感谢,他们教 我的比我教他们的要多。
Roger S.Pressman

译者序


  20 世纪末发生在我们这个星球上的最大变化之一无疑是席卷全球的信 息技术(IT)革命,人们将这场革命视为 21 世纪——知识经济时代的前奏曲。 在这场 IT 革命中,软件无疑扮演了极其重要的角色。软件产业作为一个独立 形态的产业,正在全球经济中占据越来越举足轻重的地位。而软件工程正是 软件产业健康发展的关键技术之一。
  从 1968 年软件工程概念的正式提出到现在,软件工程已有逾 30 年的发 展,出现了大量的研究成果,也进行了大量的技术实践。正是由于学术界和 产业界的共同努力,软件工程正在逐步发展为一门成熟的专业学科,以解决 软件生产的质量和效率问题为宗旨,在软件产业的发展中起到了重要的技术 保障和促进作用。
  本书是一本系统而全面地介绍软件工程理论、技术和实践的专著,是北 美学术界和产业界的畅销书之一。本书作者 Roger S.Pressman 是软件工程领 域国际知名的咨询专家和作者,著有多本学术专著,本书已是其第四版。本 书第二版曾在国内翻译出版,并被很多学校选为软件工程教材,在我国软件 工程研究、教学和实践中起到了很好的借鉴和参考作用。而第四版并不仅仅 是简单的修订,而是被完全重构以适应软件工程领域快速的增长并着重于新 的、重要的软件工程方法。从早期版本保留的章节被全面地修订,并加入了
12 章新内容,以提供对当代趋势和技术的完整讨论。书中还加入了很多新例
子、思考题、推荐阅读文献及其它参考信息源。本书的翻译出版旨在向国内 软件工程领域的研究、教学、管理和技术人员提供一个全面的参考文献、教 材或实践指南。
本书由黄柏素、梅宏组织翻译,其中梅宏负责第二部分 7、8、9 章和第
三部分的翻译工作,黄柏素翻译了其余部分并负责全书的统稿工作。同时译 者希望向参与了部分章节翻译工作的李克勤、张路、袁望洪、常继传、郭立 峰、谢涛、郭耀、马黎等,以及参与了插图绘制和参考文献录入工作的徐松 青、沈璞、刘洋、孟祥文等表示诚挚的感谢。
由于译者自身的知识局限及时间的仓促,译稿中难免存在错误和遗漏。
谨向读者及原书作者致以歉意,并欢迎指正。
                           黄柏素、梅宏 黄柏素(女),博士,北京大学计算机科学技术系副教授。1993 年于西 北工业大学获得博士学位。同年进入北京大学计算机科学技术系博士后流动 站。1995 年出站后留校工作。主要研究方向为软件工程、软件开发环境及工 具、面向对象技术、用户界面管理系统等。承担了软件工程课程教学工作。 目前已发表学术论文 20 余篇,并获得多项国家及部委科技成果奖和个人奖。 梅宏,博士,北京大学计算机科学技术系教授。1992 年于上海交通大学 获工学博士学位,1994 年从北京大学计算机科学技术系博士后出站。研究、 教学工作主要涉及软件工程及软件开发环境、软件复用及软件构件技术、(分 布)对象技术、软件工业化生产技术及支持系统、新型程序设计语言等。已 在国内外学术刊物及国际、全国学术会议上发表学术论文 60 余篇。并多次获
得国家及部委级科技成果奖,以及其他个人荣誉奖。

作者简介


  Roger S.Pressman 是软件工程领域国际知名的咨询专家和作者。他以优 等成绩从 Connecticut 大学获得学士学位,从 Bridgeport 大学获得硕士学 位,从 Connecticut 大学获得工学博士学位。已有超过 25 年的产业经验。主 要从事工程产品软件和系统软件的开发技术工作和管理工作。
  作为产业的实践者和管理者,Pressman 博士主要从事的是航空航天应用 中高级工程和制造的 CAD/CAM 系统的开发,他也从事科学及系统程序设计方 面的工作。
  除了他的产业经验之外,Pressman 博士还是 Bridgeport 大学计算机工 程系的兼职副教授和该大学的计算机辅助设计和制造中心的主任。
  Pressman 博士是 R.S.Pressman& Associates,Inc 公司的总裁,这是 一家专门从事软件工程方法和培训的咨询公司。他是公司主要的咨询专家, 专门负责帮助其他公司建立有效的软件工程方法。他开发了 RSP&A 软件工程 评估方法,该方法采用独特的数量和质量分析混合的方式,帮助客户评估他 们软件工程实践的当前状况。
  除了给 500 多个客户提供咨询服务外,R.S.Pressman & Associates, Inc 公司还提供大量的软件工程培训及过程改善服务。公司开发了一个艺术 式的录像课程“Essential SoftwareEngineering”,它全面地讲述了产业界 关于这一主题的内容。另一个产品“Process Advisor”是指导企业软件工程 改进的自测系统。
Pressman 博士还在产业期刊上发表了许多技术论文,是企业期刊的特约
撰稿人并出版了 6 本书。除了本书外,还有:“Making Software Engineering Happen(Prentice Hall 出版公司出版)”,这是第一本涉及到改善软件工 程实施过程中的主要管理问题的书籍;“Software Shock(DorsetHouse 出 版公司出版)”,该书叙述了软件及其对商业和社会的影响;“A Manager
′s Guide toSoftware Engineering(McGraw-Hill 出版公司出版)”,该
书使用独特的 Q&A 方式表示了创立和理解技术的管理指南。Pressman 博士 是杂志 American Programmer(美国程序员)和 IEEESoftware(IEEE 软件) 的编委,是 IEEE Software 的 Manager(管理员)专栏的编辑。他还是 ACM、 IEEE、Tau Beta Pi、Phi Kappa Phi、Eta Kappa Nu 和 Pi Tau Sigma 的会
员。

软件工程 实践者的研究方法

第一部分 产品和过程


  在本书的这一部分中我们主要讨论什么是工程产品和如何为工程技术提 出一个框架的过程。在下面的章节中,我们主要解决下列问题:
·到底什么是计算机软件?
·为什么我们不断努力要建造高质量的基于计算机的系统?
·我们如何对计算机软件的应用领域分类?
·关于软件仍存在什么样的神话?
·什么是软件过程?
·是否存在一般性的方法评价一个过程的质量?
·软件开发中可以应用什么过程模型?
·线性过程和迭代过程有何区别?
·它们的优点和缺点是什么?
·在软件工程中可以建议什么更高级的过程模型? 一旦回答了这些问题,读者就能够更好地理解本书其余部分给出的工程
原则的管理和技术方面的知识。

第 1 章 产品


  本书的第 1 版在 80 年代初出版后不久,Business Weekly(《商业周刊》) 杂志在头版给出如下的大标题:“软件:新的驱动力”。编辑们当时并没有 意识到他们的预见是多么的正确。那时,大多数人对软件还是一无所知。大 软件公司,如微软公司,还不存在;拥有 15000 平方英尺专门出售包装好的 软件的计算机超市闻所未闻;在电视上为计算机操作系统做 60 秒钟商业广告 的想法是可笑的;而互联网仅为个别研究者和高等学校学生所知。但是,在 不到 20 年的时间里,所有这些(甚至更多)已经成为现实。
  计算机软件已经成为一种驱动力。它是进行商业决策的引擎;它是现代 科学研究和工程问题解决的基础;它也是区分现代产品和服务的关键因素。 它在各种类型的系统中应用,如交通、医药、通讯、军事、产业化过程、娱 乐、办公??难以穷举。软件在现代社会中的确是必不可少的。而且当我们 进入 21 世纪,软件将成为从基础教育到基因工程的所有各领域新进展的驱动 器。
  所有这一切已经改变了软件的常见概念。计算机软件是无所不在的,人 们把软件看作是生活中现实的技术。在很多情况下,人们把他们的工作、他 们的舒适、他们的安全、他们的娱乐、他们的决策、甚至他们的整个生活都 依赖于计算机软件。软件千万可不能出错。
本书介绍的若干技术是那些想要建造正确的计算机软件的人们需要用到
的。这些技术包括一个过程,一组方法和一系列工具,我们称之为软件工程。

1.1 软件的发展


  今天,软件担任着双重角色。它是一种产品,同时又是开发和运行产品 的载体。作为一种产品,它表达了由计算机硬件体现的计算潜能。不管它是 驻留在蜂窝电话中,还是操作在主机上,软件就是一个信息转换器——产生、 管理、获取、修改、显示或转换信息,这些信息可以很简单,如一个单个的 位(bit),或很复杂,如多媒体仿真信息。作为开发运行产品的载体,软件是 计算机控制(操作系统)的基础、信息通信(网络)的基础,也是创建和控制其 他程序(软件工具和环境)的基础。
许多人相信 21 世纪最重要的产品是——信息,软件充分体现了这一观
点。它处理个人数据(如个人的金融事务),使得这些数据在局部范围中更为 有用;它管理商业信息增强了商业竞争力;它提供了通往全球信息网络(如 Internet)的途径;它也提供了以各种形式获取信息的手段。
  计算机软件的角色在 20 世纪后半叶发生了很大的变化。硬件性能的极大 提高,计算机体系结构的不断变化,内存和硬盘容量的快速增加,以及大量 输入输出设备的多种选择,均促进了更为成熟和更为复杂的基于计算机的软 件系统的出现。如果一个系统是成功的,那么这种成熟性和复杂性能够产生 出奇迹般的结果,但是它们也给建造这些复杂系统的人员带来很多的问题。
  在 70 年代和 80 年代出版的受欢迎的书对于计算机、软件和它们对我们 文化的影响等方面提供了有用的历史的视角。Osborne[OSB79]称之为一次“新 的工业革命”。Toffler[TOF80]称微电子的发展是人类历史上的“第三次 浪潮”,Naisbitt[NAI82]则预言了从工业社会向“信息社会”的转变。
  
Feigenbaum 和 McCorduck[FEI83]认为由计算机控制的信息和知识将是 20 世纪中表现能力的焦点,Stoll[STO89]则提出由网络和软件产生的“电子社 会”将是全球知识交换的关键。
  进入 90 年代,Toffler[TOF90]描述了“权利的转移”,因为计算机和 软件导致了“知识的民主化”,因而旧的权利结构(政府,教育,工业,经济, 及军事)将要瓦解。Yourdon[YOU92]担心美国公司在软件相关的业务中会失 去竞争力,并预言“美国程序员的衰落和下降”。Hammer 和 Champy[HAM93] 提出信息技术将在“公司的再工程”中起到很关键的作用。在 90 年代中期, 计算机和软件的流行产生了大量“新劳工运动”的书籍(例如:由 James Brook
和 Iain Boal 编辑的“抵制虚拟的生活”,以及 Stephen Talbot 写的“未来 不是计算”)。这些作者把计算机看成是魔鬼,强调了其合法性,而忽略了已 被人们意识到的巨大的利益[LEV95]问题。
  在计算机发展的早期阶段,大多数人把软件看成是不需预先计划的事 情。计算机编程很简单,没有什么系统化的方法。软件的开发没有任何管理, 一旦计划延迟了或成本提高了,程序员才开始手忙脚乱地弥补,而他们的努 力一般情况下也会取得成功。
  在通用的硬件已经非常普遍的时候,软件却相反,对每一类应用均需自 行再设计,应用范围很有限。软件产品还在婴儿阶段,大多数软件均是由使 用它们的人员或组织自己开发的,如你写软件,使其运行,如果它有问题, 你负责改好。工作的可变性很低,管理者必须得到保证:一旦发生了错误你 必须在那里。因为这种个人化的软件环境,设计往往仅是人们头脑中的一种 模糊想法,而文档就根本不存在。
在早期,我们了解了很多关于计算机系统的实现,但对于计算机系统工
程几乎一无所知。但是公平地讲,我们应该感谢这个时期开发的许多卓越的 计算机系统,其中不少一直到今天还在使用,并继续发挥着巨大的作用。
计算机系统发展的第二阶段跨越了从 60 年代中期到 70 年代末期的十余
年(如图 1-1)。多道程序设计、多用户系统引入了人机交互的新概念。交互 技术打开了计算机应用的新世界,以及硬件和软件配合的新层次。实时系统 能够从多个源收集、分析和转换数据,从而使得进程的控制和输出的产生以 毫秒而不是分钟来进行。在线存储的发展导致了第一代数据库管理系统的出 现。
第二阶段还有一个特点就是软件产品的使用和“软件作坊”的出现。软
件被开发,使得它们可以在很宽的范围中应用。主机和微机上的程序能够有 数百甚至上千的用户。来自工业界、政府和学术界的企业家们纷纷开始开发 各类软件包,并赚了大笔钱财。
早期 第二阶段 第三阶段 第四阶段
·面向批处理 ·多用户 ·分布式系统 ·强大的桌面系统 ·有限的分布 ·实时 ·嵌入“智能” ·面向对象技术 ·自定义软件 ·数据库 ·低成本硬件 ·专家系统 ·软件产品 ·消费者的影响 ·人工神经网络 ·并行计算 ·网络计算机

随着计算机系统的增多,计算机软件库开始扩展。内部开发的项目产生

了上万行的源程序,从外面购买的软件产品加上几千行新代码就可以了。这 时,一团黑云出现在地平线上,当发现错误时需要纠正所有这些程序(所有这 些源代码);当用户需求发生变化时需要修改;当硬件环境更新时需要适应。 这些活动统称为软件维护。在软件维护上所花费的精力开始以惊人的速度消 耗资源。
  更糟糕的是,许多程序的个人化特性使得它们根本不能维护。“软件危 机”出现了。
  计算机系统发展的第三阶段始于 70 年代中期并跨越了整整十年。分布式 系统——多台计算机,每一台都在同时执行某些功能,并与其他计算机通讯
——极大地提高了计算机系统的复杂性。广域网和局域网、高带宽数字通讯 以及对“即时”数据访问需求的增加都对软件开发者提出了更高的要求。然 而,软件仍然继续应用于工业界和学术界,个人应用很少。
  第三阶段的主要特点是微处理器的出现和广泛应用。微处理器孕育了一 系列的智能产品——从汽车到微波炉,从工业机器人到血液诊断设备——但 那一个也没有个人计算机那么重要,在不到十年时间里,计算机真正成为大 众化的东西。①
  计算机系统发展的第四个阶段已经不再是着重于单台计算机和计算机程 序,而是面向计算机和软件的综合影响。由复杂的操作系统控制的强大的桌 面机,广域和局域网络,配合以先进的软件应用已成为标准。计算机体系结 构迅速地从集中的主机环境转变为分布的客户机/服务器环境。世界范围的信 息网提供了一个基本结构,使得学者和政治家可以同样考虑“信息高速公路” 和“网际空间连通”的问题。事实上,Internet 可以看作是能够被单个用户 访问的“软件”。
软件产业在世界经济中不再是无足轻重的。由产业巨子如微软做的一个
决定可能会带来成百上千亿美元的风险。随着第四阶段的进展,一些新技术 开始涌现。面向对象技术(本书第四部分)在许多领域中迅速取代了传统软件 开发方法。虽然关于“第五代”计算机的预言仍是一个未知数,但是软件开 发的“第四代技术”确实改变了软件界开发计算机程序的方式。专家系统和 人工智能软件终于从实验室里走了出来,进入了实际应用,解决了现实世界 中的大量问题。结合模糊逻辑应用的人工神经网络软件揭示了模式识别和类 似人的信息处理能力的可能性。虚拟现实和多媒体系统使得与最终用户的通 讯可以采用完全不同的方法。“遗传算法”[BEG95]则提供了可以驻留于大 型并行生物计算机上的软件的潜在可能性。
  但是,一系列软件相关的问题在计算机系统的整个发展过程中一直存在 着,而且这些问题还会继续恶化:
  1.硬件的发展一直超过软件,使得我们建造的软件难以发挥硬件的所有 潜能。
  2.我们建造新程序的能力远远不能满足人们对新程序的需求,同时我们 开发新程序的速度也不能满足商业和市场的要求。
  3.计算机的普遍使用已使得社会越来越依赖于可靠的软件。如果软件失 败,会造成巨大的经济损失,甚至有可能给人类带来灾难。
4.我们一直在不断努力建造具有高可靠性和高质量的计算机软件。
5.拙劣的设计和资源的缺乏使得我们难以支持和增强已有软件。 为了解决这些问题,整个产业界开始采用了软件工程实践。


1.1.1 产业的观点


  在计算机发展的早期,计算机系统是采用面向硬件的管理方法来开发 的。项目管理者着重于硬件,因为它是系统开发中最大的预算项。为了控制 硬件成本,管理者建立了规范的控制和技术的标准。他们要求在真正开始建 造系统之前,进行详尽的分析和设计,他们度量过程,以发现哪里还可以进 一步改进,他们坚持质量控制和质量保证,他们设立规程,以管理变化。简 言之,他们应用了控制、方法和工具,我们可以称之为硬件工程。但遗憾的 是软件只不过是事后才考虑的事情。
  在早期,程序设计被看作是一门“艺术”。几乎没有规范化的方法,也 没有人使用它们。程序员往往从试验和错误中积累经验。建造计算机软件的 专业性和挑战性,使其披上了一种神密的面纱,管理者们很难了解它。软件 世界真是完全无序——这是一个开发者的为所欲为的时代。
  今天,计算机系统开发成本的分配发生了戏剧性的变化。软件,而不是 硬件,是最大的成本项。在近二十年里,管理者和很多开发人员在不断地问 以下的问题:
·为什么需要那么长时间才能结束开发?
·为什么成本如此之高?
·为什么我们不能在把软件交给客户之前就发现所有的错误?
·为什么在软件开发过程中我们难以度量其进展? 这些问题以及其他许多问题都表明了对软件及其开发的方式是必须关注
了——这种关注最终导致了软件工程实践的出现。

1.1.2 老化的软件工厂


  在 50 和 60 年代,许多评论家批评美国的钢铁产业缺少对其工厂的投入。 工厂开始恶化,现代化的方法很少被采纳,最终产品的质量和成本难以容忍, 外来的竞争开始赢得市场份额。这些企业在管理中确定把主要的投资投入到 其主营业务中,以保持竞争力。随着时间的推移,美国的钢铁产业蒙受了巨 大损失,大量市场份额被外来竞争者占领——这些企业拥有新工厂,采用更 为现代化的技术,并且得到政府的资助,使得他们极具价格优势。
在那个时期,羽翼未丰的计算机产业中的很多人都以蔑视的态度评价钢
铁产业,“如果它们不愿在自己的业务上投入,那当然会失去市场份额”。 这些话现在轮到说我们自己了。
  听上去很戏剧化,今天的软件产业就像五、六十年代的钢铁产业,无论 大公司还是小公司,都有一个老化的“软件工厂”——有成千上万的重要的 基于软件的应用程序急待更新:
  · 20 年前开发的信息系统应用程序经过了几十次的修改,已经真正不 可维护了。即使是最小的修改也会引起整个系统失败。
  ·一些用于生成关键设计数据的工程应用程序,由于不断的修改和老化, 已经没有人真正了解其内部结构。
  ·嵌入式系统(有成千上万的这类应用程序,其中包括核电站控制、航空 调度和工厂管理)表现出奇怪的有时甚至是无法解释的行为,但又不能不用它
  
们,因为目前还没有其他方法可以替代它们。 有问题就“打补丁”,并给这些应用程序一个时髦的界面,仅仅如此是
不够的。软件工厂的许多构件需要再生产,否则它们就不再具有竞争力了。 但不幸的是,许多企业的管理者并不愿投入资源去进行再生产,他们辩解: “这些应用程序仍能工作,投入资源去使得它们更好是不经济的”。

1.1.3 软件的竞争


  许多年来,大、小公司雇佣的软件开发人员仅仅在公司内部服务,而且 他们也愿意这样。因为每一个计算机程序都是自行开发的,这些“自家”的 软件人员控制着成本、进度和质量。今天,所有这一切都改变了。
  软件目前是一个竞争很强的行业。曾经要自行开发的软件现在可以在货 架上买到,许多公司过去雇佣了大量的程序员开发特定的软件,现在它们大 部分的软件工作已交给第三方厂商去完成[MIN95]。
  成本、进度和质量将是未来若干年中导致软件激烈竞争的主要因素。美 国和西欧有很成熟的软件产业,而远东(如韩国,新加坡)、亚洲(如印度、中 国)和东欧的一些国家拥有大量的有天份、受过良好教育且相对较低廉的专门 人才[ECO94]。这种压力导致了必须迅速采用现代化的软件工程实践的需要, 同时软件开发也是一个必须认真考虑的因素,因为世界范围的软件从业人员 都在追求尽量少的开发费用。
在关于信息服务对美国及世界的影响的论著中, Feigenbaum 和
McCorduck[FEI83]作了如下陈述: 知识就是力量,而计算机是这种力量的倍增器??美国的计算机产业是
创新的、充满活力的和成功的。在某种程度上,它是一个理想的产业。它通
过转化知识分子的脑力劳动来产生价值,而几乎不需要什么能源和原材料。 今天,我们在这个最重要的现代技术上领导着世界的想法和市场,但明天会 怎样哪?
是的,明天会怎样哪?计算机硬件已经成为一种商品,可从很多渠道得
到。但软件仍然是美国保持着“创新的、充满活力的和成功的”一个产业。 但我们还会继续保持领先吗?至少答案的一部分就在这里:我们将采用什么 样的方法去建造下一代计算机系统的软件。

1.2 软件


  在 1970 年,只有不到 1%的人能够比较准确地描述出什么是“计算机软 件”。而现在,大多数专业人士和许多业外公众都认为他们了解了什么是软 件。但他们真的了解吗?
  关于软件,教科书上一般是如下定义的:软件是(1)能够完成预定功能和 性能的可执行的指令(计算机程序);(2)使得程序能够适当地操作信息的数据 结构;(3)描述程序的操作和使用的文档。毫无疑问,也可以给出其他更详细 的定义。但我们不只是需要一个形式上的定义。

1.2.1 软件特征

  要理解软件的含义(以及对软件工程有一个全面的理解),首先要了解软 件的特征是很重要的,据此能够明白软件与人类建造的其他事物之间的区 别。当建造硬件时,人的创造性的过程(分析、设计、建造、测试)能够完全 转换成物理的形式。如果我们建造一个新的计算机,初始的草图、正式的设 计图纸和面板的原型一步步演化成为一个物理的产品(VLSI 芯片、线路板、 电源等等)。
  而软件是逻辑的而不是物理的产品。因此,软件具有与硬件完全不同的 特征:
  1.软件是由开发或工程化而形成的,而不是传统意义上的制造产生的。 虽然在软件开发和硬件制造之间有一些相似之处,但两者本质上是不同 的。这两者,都可以通过良好的设计获得高质量,但硬件在制造过程中可能 会引入质量问题,这种情况对于软件而言几乎不存在(或是很容易改正)。软 件成为产品之后,其制造只是简单的拷贝而已;两者都依赖于人,但参与的 人和完成的工作之间的关系不同;两者都是建造一个产品,但方法不同(见第
3 章)。
  软件成本集中于开发上,这意味着软件项目不能象硬件制造项目那样来 管理。
在 80 年代中期,“软件工厂”的概念被正式引入[MAN84]、[YAJ84]。
应该注意到这个术语并没有把硬件制造和软件开发认为是等价的。而是通过 软件工厂这个概念提出了软件开发中应该使用自动化工具(见第 5 部分)。
2.软件不会“磨损”。
  图 1-2 刻划了随着时间的改变硬件故障率的变化曲线图。其关系,常常 被称作“浴缸曲线”,表明了硬件在其生命初期有较高的故障率(这些故障主 要是由于设计或制造的缺陷);这些缺陷修正之后,故障率在一段时间中会降 到一个稳定的曲线上(很低)。随着时间的改变,故障率又提升了,这是因为 硬件构件由于种种原因会不断受到损害,例如灰尘、振动、滥用、温度的急 剧变化以及其他许多环境问题。简单讲,硬件已经开始磨损了。


  软件并不受到这些引起硬件磨损的环境因素的影响。因此,理论上讲, 软件的故障率曲线呈现出如图 1-3 所示的形式。隐藏的错误会引起程序在其 生命初期具有较高的故障率。但这些错误改正之后(我们假设理想情况下改正 过程中并不引入其他错误),曲线就趋于平稳,如图所示。图 1-3 给出了实 际软件故障模型的一个总的简化图(第 8 章将给出更多信息)。其意义很清楚
——软件不会磨损,不过它会退化。


  这个说法表面上似乎是矛盾的,我们可以通过图 1-4 来解释清楚。在其 生命期中,软件会经历修改(维护),随着这些修改,有可能会引入新的错误, 使得故障率曲线呈现为图 1-4 所示的锯齿形。在该曲线能够恢复到原来的稳 定状态的故障率之前,又需要新的修改,又引起一个新的锯齿。慢慢地,最 小故障率就开始提高了——软件的退化由于修改而发生了。


  关于磨损的另一个侧面也表明了硬件和软件之间的不同。当一个硬件构 件磨损时,可以用另外一个备用零件替换它,但对于软件就没有备用零件可 以替换了。每一个软件故障都表明了设计或是将设计转换成机器可执行代码
  
的过程中存在错误。因此,软件维护要比硬件维护复杂得多。
3.大多数软件是自定的,而不是通过已有的构件组装而来的。 我们先看一看一个基于微处理器的控制硬件是如何设计和建造出来的。
设计工程师画一个简单的数字电路图,做一些基本的分析以保证可以实现预 定的功能,然后查阅所需的数字零件的目录。每一个集成电路(通常称为“IC” 或“芯片”)都有一个零件编号、固定的功能、定义好的接口和一组标准的集 成指南。每一个选定的零件,都可以在货架上买到。
  而软件设计者就没有上述这种荣幸了。几乎没有软件构件。有可能在货 架上买到的软件,它本身就是一个完整的软件,而不能作为构件再组装成新 的程序①。虽然关于“软件复用”已有大量论著,但这种概念的成功实现还只 是刚刚开始。

1.2.2 软件构件


  随着工程化的发展,大量标准的设计构件产生了。标准螺丝和货架上的 集成电路芯片仅仅是成千上万的标准构件中的两种,机械和电子工程师在设 计新系统时会用到它们。这些可复用构件的使用使得工程师们能够集中精力 于设计中真正有创造性的部分(如设计中那些新的成分)。在硬件中,构件复 用是工程化的必然结果。而在软件中,它还仅仅是在小范围内取得一定应用。 可复用性(Reusability)是高质量软件构件的一个重要特征(第 26 章将 给出更详细的讨论),一个软件构件应该被设计和实现为能够在多个不同程序 中复用。在 60 年代,我们建造了科学计算子程序库,它们能够在很多工程和 科学应用中复用,这些子程序库可以以一种高效的方式复用,定义明确的算 法,但其应用范围有限。今天,我们已经扩展了复用的概念,不仅是算法, 还可以是数据结构。现代的可复用构件包含了数据以及应用这些数据的处理 过程,使得软件工程师能够从已有可复用构件中创建新的应用②。例如,现在 交互界面都是通过可复用构件建造的,你可以使用它们创建图形窗口、下拉 式菜单和各种交互机制。建造用户界面所需的数据结构和处理细节均包含在
一个可复用的界面建造构件库中。
  软件构件使用某种程序设计语言实现,该语言具有一个有限的词汇表、 一个明确定义的文法及语法和语义规则。在最底层,该语言直接反映了硬件 的指令集;在中层,程序设计语言,如 Ada 95、C 或 Smalltalk 可用于创建 程序的过程化描述;在最高层,该语言可使用图形化的图标或其他符号去表 示关于需求的解决方案。由于可执行代码就自动生成了。
  机器级语言是 CPU 指令集的一个符号表示。当一个好的软件开发者在开 发一个可维护、文档齐全的程序时,使用机器语言能够很高效地利用内存并 优化该程序的执行速度。当程序设计得很差且没有文档时,机器语言就是一 场恶梦。
中层语言使得软件开发者和程序可独立于机器。如果使用了很好的翻译 器,一个中层语言的词汇表、文法、语法和语义都能够比机器语言高级得多。



① 这种状况目前正在迅速改变。面向对象技术的广泛使用已导致了软件构件的生产,本书第 19 至 29 章将
有详细讨论。
② 本书第四部分介绍了面向对象技术的使用和它们对构件复用形成的影响。

事实上,中层语言的编译器和解释器的输出就是机器语言。 虽然目前有成百上千种的程序设计语言,但只有不到 10 种中层的程序设
计语言在工业界广泛使用。一些语言,如 COBOL 和 FORTRAN 从它们发明至今 已经流行了 30 余年,更多的现代程序设计语言,如 Ada95、C、C++、Eiffel、 Java 和 Smalltalk 也各自有一大批热心的追随者。
  机器代码,汇编语言(机器级语言)和中层程序设计语言通常被认为是计 算机语言的前三代。因为这些语言中的任何一种,都需程序员既要关心信息 结构的表示,又要考虑程序本身的控制。因此这前三代语言被称为是过程语 言。
  第四代语言,也称非过程语言,使得软件开发者更加独立于计算机硬件。 使用非过程语言开发程序,不需要开发者详细说明过程化的细节,而仅仅“说 明期望的结果,而不是说明要得到该结果所需要的行为”[COB85]。支撑软件 会把这种规约自动转换成机器可执行的程序。

1.2.3 软件应用


  软件可以应用于任何场合,只要定义了一组预说明的程序步骤(如一个算 法,但也有例外,如专家系统和人工神经网络)。信息的内容和确定性是决定 一个软件应用的特性的重要因素。内容指的是输入和输出信息的含义和形 式,例如,许多商业应用使用高结构化的输入数据(一个数据库),且产生格 式化的输出“报告”。而控制一个自动化机器的软件(如一个数控系统)则接 受限定结构的离散数据项,并产生快速连续的单个机器命令。
信息的确定性指的是信息的处理顺序及时间的可预定性。一个工程分析
程序接受预定顺序的数据,不间断的执行分析算法,并以报告或图形格式产 生相关的数据。这类应用是确定的。而一个多用户操作系统,则接受可变化 内容和任意时序的数据,执行可被异常条件中断的算法,并产生随环境功能 及时序而变化的输出。具有这些特点的应用是非确定的。
在某种程度上讲我们难以对软件应用给出一个通用的分类。随着软件复
杂性的增加,其间已没有明显的差别。下面给出一些软件应用领域,它们可 能是一种潜在的应用分类:
系统软件:系统软件是一组为其他程序服务的程序。一些系统软件(如
编译器、编辑器和文件管理程序)处理复杂的但也是确定的信息结构。其他的 系统应用(如操作系统、驱动程序和通讯进程等)则处理大量的非确定的数 据。不管哪种情况,系统软件均具有以下特点:与计算机硬件频繁交互;多 用户支持;需要精细调度、资源共享及灵活的进程管理的并发操作;复杂的 数据结构;及多外部接口。
  实时软件:管理、分析、控制现实世界中发生的事件的程序称为实时软 件。实时软件的组成包括:一个数据收集部件,负责从外部环境获取和格式 化信息;一个分析部件,负责将信息转换成应用时所需要的形式;一个控制/ 输出部件,负责响应外部环境;及一个管理部件,负责协调其他各部件,使 得系统能够保持一个可接受的实时响应时间(一般从 1 毫秒到 1 分钟),应该 注意到术语“实时”不同于“交互”或“分时”。一个实时系统必须在严格 的时间范围内响应。而一个交互系统(或分时系统)的响应时间可以延迟,且 不会带来灾难性的后果。
  
  商业软件:商业信息处理是最大的软件应用领域。具体的“系统”(如 工资表、帐目支付和接收、存货清单等)均可归为管理信息系统(MIS)软件, 它们可以访问一个或多个包含商业信息的大型数据库。该领域的应用将已有 的数据重新构造,变换成一种能够辅助商业操作和管理决策的形式。除了传 统的数据处理应用之外,商业软件应用还包括交互式的和客户机/服务器式的 计算(如 POS 事务处理)。
  工程和科学计算软件 :工程和科学计算软件的特征是“数值分析”算 法。此类应用含盖面很广,从天文学到火山学;从汽车压力分析到航天飞机 的轨道动力学;从分子生物学到自动化制造。不过,目前工程和科学计算软 件已不仅限于传统的数值算法。计算机辅助设计、系统仿真和其他交互应用 已经开始具有实时软件和系统软件的特征。
  嵌入式软件:智能产品在几乎每一个消费或工业市场上都是必不可少 的,嵌入式软件驻留在只读内存中,用于控制这些智能产品。嵌入式软件能 够执行很有限但专职的功能(如微波炉的按钮控制),或是提供比较强大的功 能及控制能力(如汽车中的数字控制,包括燃料控制、仪 表板显示,刹车系统 等)。
  个人计算机软件:个人计算机软件市场是在过去十年中萌芽和发展起来 的。字处理、电子表格、计算机图形、多媒体、娱乐、数据库管理、个人及 商业金融应用、外部网络或数据库访问,这些仅仅是成百上千这类应用中的 几种。
人工智能软件:人工智能(AI)软件利用非数值算法去解决复杂的问题,
这些问题不能通过计算或直接分析得到答案。一个活跃的 AI 领域是专家系 统,也称为基于知识的系统。AI 软件的其他应用领域还包括模式识别(图象 或声音)、定理证明和游戏。最近,AI 软件的一个新分支,称为人工神经网 络,得到了很大进展。神经网络仿真人脑的处理结构(生物神经系统的功能), 这有可能导致一个全新类型的软件登场,它不仅能够识别复杂的模式,而且 还能从过去的经验中自行学习进步。

1.3 软件:地平线上的危机


  许多产业界观察者(包括本书早期版本的作者)都把与软件开发相关的问 题称为“危机”。但实际上我们的问题与这个术语真正的含义可能并不相同。 “危机”这个词在韦氏字典中定义为“任何事情过程中的一个转折点; 决定性的或危急的时刻、阶段或事件”。而对于软件而言,没有“转折点”, 没有“决定性时刻”,只有延迟或进展上的变化。在软件产业中,“危机”
已经伴随我们走过了近 30 年,这在术语上是很矛盾的。 在字典中查找“危机”这个词,我们还可以发现另外一个定义:“疾病
过程中的一个转折点,能够确定病人是生是死”。这个定义多少可以反映出 软件开发中面临的问题的真正含义。
我们已经到了计算机软件的危机阶段,实际上我们真正的问题应该是一 种“慢性的苦恼”①。“苦恼”这个词定义为“引起痛苦或不幸的任何事情”。 但形容词“慢性的”这个词的定义能够更加贴切地反映问题:“持续很长时



① 该术语由 Michigan 大学的 DanielTiechrow 教授于 1989 年 4 月,在 SwitzerlndGeneva 提出。

间或经常重犯;不确定地延续”。这很准确地描述了过去 30 年我们所经历的 问题是一种慢性的苦恼,而不是危机。并没有一种灵丹妙药可以完全治愈这 种病疼,但在我们正努力去发现解决方案的同时会得到很多缓解痛苦的方 法。
  不管我们称之为软件危机还是软件苦恼,该术语都是指在计算机软件开 发中所遇到的一系列问题。这些问题不仅局限于那些“不能正确完成功能的” 软件,还包含那些与我们如何开发软件、我们如何维护大量已有软件以及我 们的开发速度如何跟上目前对软件越来越大的需求等相关的问题。
  虽然关于危机甚至是苦恼的介绍可能看起来有些戏剧化,但这些段落对 于表明在软件开发的所有领域中所遇到的真正的问题起到很大作用。

1.4 软件神话


  引起软件危机的诸多原因可以追溯到软件开发的早期阶段产生的神话。 它不象古代的神话那样可以给人以经验和教训,软件神话使人产生了误解和 混乱。软件神话具有一些特征使得它们很有欺骗性:例如,它们表面上看很 有道理(有时含有一定真实的成分);它们符合人的直觉;它们常常是有经验 的实践者发布出来的。
今天,大多数专业人员已经认识到这些神话误导了人们,给管理者和技
术人员都带来了严重的问题。但是,旧的观念和习惯难以改变,软件神话仍 被不少人相信着。
管理者的神话:负责软件的管理者象大多数其他行业的管理者一样,都
有巨大的压力,要维持预算、保持进度及提高质量。就像溺水者抓住一根救 命稻草,软件管理者常常抓住软件神话不放,如果这些神话能够缓解其压力 的话(哪怕是暂时的)。
神话:我们已经有了关于建造软件的标准和规程的书籍,难道它们不能
给人们提供所有其需要知道的信息吗?
  事实:不错关于标准的书籍已经存在,但真正用到了它们吗?软件实践 者知道它们的存在吗?它们是否反映了现代软件开发的过程?它们完整吗? 很多情况下,对于这些问题的答案均是“不”。
神话:我们已经有了很多很好的软件开发工具,而且,我们为它们买了
最新的计算机。
  事实:为了使用最新型号的主机、工作站和 PC 机去开发高质量的软件, 我们已经投入太多的费用。实际上,计算机辅助软件工程(CASE)工具相比起 硬件而言对于获得高质量和高生产率更为重要,但大多数软件开发者并未使 用它们。
  神话:如果我们已经落后于计划,可以增加更多的程序员来赶上进度 (“有时称为蒙古大夫概念”)。
  事实:软件开发并非象制造一样是一个机械过程。用 Brooks[BRO75] 的话来说,“给一个已经延迟的软件项目增加人手只会使其更加延迟”。看 起来,这句话与人的直觉正好相反。但实际上,增加新人,原来正在工作的 开发者必须花时间来培训新人,这样就减少了他们花在项目开发上的时间。 人手可以增加,但只能是在计划周密、协调良好的情况下。
用户的神话:需要计算机软件的用户可能就是邻桌的人,或是另一个技

术组,也可能是市场/销售部门,或另外一个公司。在许多情况下,用户相信 关于软件的神话,因为负责软件的管理者和开发者很少去纠正用户的错误理 解。神话导致了用户过高的期望值,并引起对开发者的极端不满意。
  神话:有了对目标的一般描述就足以开始写程序了——我们可以以后再 补充细节。
  事实:不完善的系统定义是软件项目失败的主要原因。关于待开发项目 的应用领域、功能、性能、接口、设计约束及确认标准的形式化的、详细的 描述是必需要的。这些内容只有通过用户和开发者之间的通信交流才能确 定。
  神话:项目需求总是在不断变化,但这些变化能够很容易地满足,因为 软件是灵活的。
  事实:软件需求确实是经常变化的,但这些变化产生的影响会随着其引 入的时间不同而不同。如果我们很注重早期的系统定义,这时的需求变化就 可被很容易地适应。用户能够复审需求,并提出修改的建议,这时对成本的 影响会相对较小。当在软件设计过程中才要求修改时,对成本的影响就会提 高得很快。资源已经消耗了,设计框架已经建立了,这时的变化可能会引起 大的改动,需要额外的资源和大量的设计修改,例如,额外的花费。实现阶 段(编码和测试阶段)功能、性能、接口及其他方面的改变对成本会产生更大 的影响。当软件已经投入使用后再要求修改,这时所花的代价比起较早阶段 做同样修改所花的代价可能是几何级数级的增长。


  开发者的神话:那些至今仍被软件开发者相信的神话是由几十年的程序 设计文化培植起来的。正如我们在本章一开始就提到的,在软件的早期阶段, 程序设计被看作是一门艺术。这种旧的观念和方式是很难改变的。
神话:一旦我们写出了程序并使其正常运行,我们的工作就结束了。
  事实:有人说过:“越早开始写程序,就要花越长时间才能完成它”, 产业界的数据[LIE80]表明在一个程序上所投入的 50%到 70%的努力是花费 在第一次将程序交给用户之后。
神话:在程序真正运行之前,没有办法评估其质量。
  事实:从项目一开始就可以应用的最有效的软件质量保证机制之一是正 式的技术复审。软件复审(见第 8 章)是“质量的过滤器”,比起通过测试找 到某类软件错误要有效得多。
神话:一个成功项目唯一应该提交的就是运行程序。
  事实:运行程序仅是软件配置的一部分,软件配置包括:程序、文档和 数据。文档是成功开发的基础,更重要的是,文档为软件维护提供了指导。 许多软件专业人士认识到上述这些神话是错误的。但令人遗憾的是旧的 观念和方法培植了拙劣的管理和技术习惯,虽然现实情况已经需求有更好的
方法。对软件现实的认识是形成软件开发的实际解决方案的第一步。

1.5 小结


  软件已经成为基于计算机的系统及产品的关键组成成分。在过去 40 年 中,软件已经从特定的问题解决和信息分析工具演化为一门独立的产业。但 早期的“程序设计”文化和历史产生了一系列至今还存在的问题,软件已经
  
成为计算机系统演化过程中的阻碍因素。软件是由程序、数据和文档组成。 这些条目构成了软件工程过程中的配置项,软件工程的目的就是为建造高质 量的软件提供一个框架。

思考题


  1.1 软件在许多基于计算机的系统或产品中具有不同的特点,试举 2 到 3 个产品以及至少 1 个系统,说明软件而非硬件在其中的差别。
  1.2 在五、六十年代,计算机程序设计是一门艺术,其学习环境就象在 工厂当学徒。早期阶段对今天的软件开发有何影响?
  1.3 很多作者已经探讨了“信息时代”的影响。试举若干实例(正面的和 反面的)说明软件对当今社会的影响。参考 1.1 节中任—90 年代以前的参考 文献,指出其中作者的哪些预见是正确的,哪些是错误的?
  1.4 试举一个特定应用并说明(a)它属于哪一个软件应用类型(见 1.2.3 节);(b)与该应用相关的数据内容;(C)该应用的信息确定性。
  1.5 随着软件的普及,公众所冒的危险(由于软件的错误引起的)受到越 来越多的关注。试举一个因为计算机程序的失败而带来巨大灾难的(对人类或 经济均可)实际可能发生的场景。
1.6 精读 Internet 上的新闻组 comp.risks 的内容,并对最近正在讨论
的软件带来的危险作一个总结。[另一个可选的资料来源是: Software Engineering Notes(软件工程注释),由 ACM(theAssociation of Computing Machinery(计算机协会))出版]。
1.7 写一篇文章总结某个前沿软件应用领域的最新进展。推荐可选的领
域包括:人工智能,虚拟现实、人工神经网络、高级人机界面和智能代理。
  1.8 1.4 节陈述的神话随着时间的推移已经慢慢淡化了,但另外一些新 神话替代了它们,试着为每一类神话增加一二个“新”神话。

推荐阅读文献及其他信息源


  关于计算机软件有成千上万的书籍,大多数是探讨程序设计语言或软件 应用的,但也有一部分是讨论软件本身的。关于该话题的一个非正式的探讨 可在[PRE91]中找到。Negroponte 的畅销书(Being Digital,数字化,Alfred A.Knopf,Inc.,1995)阐述了计算的观点及其对 21 世纪的影响。DeMarco(Why Does Software Cost So Much?为什么软件的成本如此之高,Dorset House,
1995)对于软件及其开发过程进行了精辟的和有远见的论述。 对计算机软件和软件工程深刻理解的基础是计算机科学,这个话题涉及
面太宽,超出了本书讨论的范围。“计算机科学文献汇总”(Computer Science Bibliography Collection)中收集了近 600 个计算机科学领域的文献目录。 在其中的 300 000 个参考文献中几乎每一个都与软件工程相关:
http :
//www.pilgrim.umass.edu/pub/misc/bibliographies/index.html
  “计算机科学指导”(the World Guide to Computer Science)中包含了 很多大学的研究机构在计算机科学领域取得的进展:
http://www.worldwidenews.net/subjects/htm

软件方面的术语词,包括缩略词可在以下网站上找到: http://dxsting.cern.ch/sting/glossary.html “工程的国际互联”(Internet Connection for Engineering)给出了国
际上工程程序正在研究的方向索引:
http://www.englib.cornell.edu/ice/ice-index.html

第 2 章 过程


  软件过程是过去十年中人们关注的焦点。但准确讲什么是软件过程呢? 在本书中,我们定义软件过程为建造高质量软件需要完成的任务的框架。“过 程”与软件工程同义吗?答案是“是也不是”。一个软件过程定义了软件开 发中采用的方法,但软件工程还包含该过程中应用的技术——技术方法和自 动化工具。
  更重要的一点,软件工程是有创造力、有知识的人在定义好的、成熟的 软件过程框架中进行的。本章的目的就是探讨软件过程的研究现状,并为在 本书以后的章节中更详细地讨论关于管理和技术方面的话题提供指导。

2.1 软件工程——一种层次化技术


  虽然有很多作者都给出了软件工程的定义,但 Fritz Bauer[NAU69]在 NATO 会议上给出的定义仍是进一步展开讨论的基础:
  软件工程 是为了经济地获得可靠的和能在实际机器上高效运行的软 件而建立和使用的好的工程原则。
几乎每一个读者都忍不住想在这个定义上增加点什么。它没有提到软件
质量的技术层面,也没有直接谈到用户满意度或按时交付产品的要求,它忽 略了测度和度量的重要性,甚至没有阐明一个成熟的过程的重要性。但 Bauer 的定义给我们提供了一个基线。什么是可以应用到计算机软件开发中的“好 的工程原则”?我们如何“经济地”建造软件使得其可靠性高?如何才能创 建出能够在多个、而不是一个不同的实际机器上“高效运行”的程序?这些 都是进一步挑战软件工程师的问题。
IEEE[IEE93]给出了一个更加综合的定义:
  软件工程:(1)将系统化的、规范的、可度量的方法应用于软件的开发、 运行和维护的过程,即将工程化应用于软件中。(2)(1)中所述方法的研究。

2.1.1 过程、方法和工具


  软件工程是一种层次化的技术(如图 2-1 所示)。任何工程方法(包括软 件工程)必须以有组织的质量保证为基础。全面的质量管理和类似的理念刺激 了不断的过程改进,正是这种改进导致了更加成熟的软件工程方法的不断出 现。支持软件工程的根基就在于对质量的关注。
  软件工程的基层是过程层。软件工程过程是将技术层结合在一起的凝聚 力,使得计算机软件能够被合理地和及时地开发出来。过程定义了一组关键 过程区域的框架(KPAs)[PAY93],这对于软件工程技术的有效应用是必须的。 关键过程区域构成了软件项目的管理控制的基础,并且确立了上下各区域之 间的关系,其中规定了技术方法的采用、工程产品(模型、文档、数据、报告、 表格等)的产生、里程碑的建立、质量的保证及变化的适当管理。
  软件工程的方法层提供了建造软件在技术上需要“如何做”。方法涵盖 了一系列的任务:需求分析、设计、编程、测试和维护。软件工程方法依赖 于一组基本原则,这些原则控制了每一个技术区域,且包含建模活动和其他 描述技术。
  
  软件工程的工具层对过程和方法提供了自动的或半自动的支持。当这些 工具被集成起来使得一个工具产生的信息可被另外一个工具使用时,一个支 持软件开发的系统就建立了,称为计算机辅助软件工程(CASE)。CASE 集成了 软件、硬件和一个软件工程数据库(一个仓库,其中包含了关于分析、设计、 编程和测试的重要信息),从而形成了一个软件工程环境,它类似于硬件的 CAD/CAE(计算机辅助设计/工程)。



2.1.2 软件工程的一般视图


  工程是对技术(或社会)实体的分析、设计、建造、验证和管理。抛开要 工程化的实体,下列问题是必须首先回答的:
·要解决的问题是什么?
·要用于解决该问题的实体具有什么特点?
·如何实现该实体(解决方案)?
·如何建造该实体?
·采用什么方法去发现该实体设计和建造过程中产生的错误?
·当该实体的用户要求修改、适应和增强时,如何支持这些活动? 本书全文只针对一个实体——计算机软件。要适当地建造一个软件,软
件开发过程是必须定义的。本节给出了软件过程的一般性特点,本章的以后
几节进一步阐述了特定的过程模型。 如果不考虑应用领域、项目规模和复杂性,与软件工程相关的工作可分
为三个一般的阶段。每一个阶段回答了上述的一个或几个问题。
  定义阶段集中于“做什么”。即在定义过程中,软件开发人员试图弄清 楚要处理什么信息,预期完成什么样的功能和性能,希望有什么样的系统行 为,建立什么样的界面,有什么设计约束,以及定义一个成功系统的确认标 准是什么。即定义系统和软件的关键需求。虽然在定义阶段采用的方法取决 于使用的软件工程范型(或范型的组合),但在某种程度上均有三个主要任 务:系统或信息工程(见第 10 章),软件项目计划(第 3 章到第 7 章),和需求 分析(第 11,12 和 20 章)。
开发阶段集中于“如何做”。即在开发过程中,软件工程师试图定义数
据如何结构化,功能如何转换为软件体系结构,过程细节如何实现,界面如 何表示,设计如何转换成程序设计语言(或非过程语言),测试如何执行。在 开发阶段采用的方法可以不同,但都有三个特定的任务:软件设计(第 14、
15 和 21 章),代码生成,和软件测试(第 16、17 和 22 章)。 维护阶段集中于“改变”,与以下几种情况相关:纠正错误;随着软件
环境的演化,而要求的适应性修改;及由于用户需求的变化而带来的增强性 修改。维护阶段重复定义和开发阶段的步骤,但却是在已有软件的基础上发 生的。在维护阶段可能遇到四类修改要完成:
  纠错:即使有最好的质量保证机制,用户还是有可能发现软件中的错 误。纠错性维护是为了改正错误而使软件发生变化。
  适应:随着时间的推移,原来的软件被开发的环境(如 CPU、操作系统、 商业规则、外部产品特征)可能发生了变化。适应性维护是为了适应这些外部 环境的变化而修改软件。
  
  增强:随着软件的使用,用户可能认识到某些新功能会产生更好的效 益。完善性维护是由于扩展了原来的功能需求而修改软件。
  预防:计算机软件由于修改而逐渐退化,因此,预防性维护,常常称为 软件再工程,就必须实行,以使软件能够满足其最终用户的要求。本质上讲, 预防性维护对计算机程序的修改,可使得能够更好地纠错软件的错误,提高 软件的适应性和增强软件的需求。
  今天,“老化的软件工厂”(见 1.1.2 节)已经迫使许多公司不得不实行 软件再工程(第 27 章)。从一个全面的观点来看,软件再工程常常被视为商业 过程再工程的一个组成部分。
  还有很多保护性活动可用来补充在软件工程的一般视图中(本节)所阐述 的阶段和相关步骤。典型的活动包括:
·软件项目追踪和控制。
·正式的技术复审。
·软件质量保证。
·软件配置管理。
·文档的准备和产生。
·可复用管理。
·测试。
·风险管理。
这些活动贯穿于整个软件过程中,将在本书的第 2 和第 5 部分探讨。

2.2 软件过程


  一个软件过程可以表示为图 2-2 所示的形式。一个公共过程框架,是通 过定义若干框架活动来建立的,如果不考虑其规模和复杂性这些活动适用于 所有软件项目。若干任务集合——每一个集合都由软件工程工作任务、项目 里程碑、软件工程产品和交付物以及质量保证点组成——使得框架活动适应 于不同软件项目的特征和项目组的需求。最后是保护性活动——如软件质量 保证,软件配置管理,和测试度(这些内容在以后的章节中还要详细讨论)—
—它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动,且
贯穿于整个过程。 近年来,“过程成熟度”成为人们关注的焦点(参见文献[PAU93])。软
件工程研究所(SEI)提出了—个综合模型,定义了当一个组织达到不同的过程
成熟度时应该具有的软件工程能力。为了确定一个组织目前的过程成熟度, SEI 使用了一个评估调查表和一个五分的等级方案,这个等级方案与能力成 熟度模型[PAU93]一致,该模型定义了在不同的过程成熟度级别上所需要的 关键活动。SEI 的模型提供了衡量一个公司软件工程实践的整体有效性的方 法,且建立了五级的过程成熟度级别,其定义如下:
  第一级:初始级——软件过程的特征是无序的,有时甚至是混乱的。几 乎没有过程定义,成功完全取决于个人的能力。
  第二级:可重复级——建立了基本的项目管理过程,能够追踪费用、进 度和功能。有适当的必要的过程规范,使得可以重现以前类似项目的成功。 第三级:定义级——用于管理和工程活动的软件过程已经文档化、标准 化,并与整个组织的软件过程相集成。所有项目都使用文档化的、组织认可
  
的过程来开发和维护软件。本级包含了第二级的所有特征。 第四级:管理级——软件过程和产品质量的详细度量数据被收集,通过
这些度量数据,软件过程和产品能够被定量地理解和控制。本级包含了第三 级的所有特征。
  第五级:优化级——通过定量的反馈,进行不断的过程改进,这些反馈 来自于过程或通过测试新的想法和技术而得到。本级包含了第四级的所有特 征。
  SEI 定义的这五个级别是根据 SEI 基于 CMM 的评估调查表得到的反馈而 产生的结果。调查表的结果被精确化而得到单个的数字等级,表示了一个组 织的过程成熟度。
  SEI 将关键过程区域(KPAs)与每一个成熟度级别联系起来。KPAs 描述了 要达到某一特定级别必须满足的软件工程功能(如软件项目计划,需求管 理),每一个 KPA 均通过标识下列特征来描述:
·目标——KPA 要达到的总体目的。
  ·约定——要求(组织必须遵守的)。这些要求是要达到目标就必须满足 的,或是提供了是否实现目标的考察标准。
·能力——使得组织能够满足约定要求的那些事物(组织的或技术的)。
·活动——为了完成 KPA 的功能所需要的特定任务。
·监控实现的方法——活动在实现过程中被监控的方式。
  ·验证实现的方法——KPA 的活动能够被验证的方式。成熟度模型中定 义了 18 个 KPAs(每一个都用上述的结构来描述),它们映射到过程成熟度的 不同级别。下面给出了在每个过程成熟度级别上应该实现的 KPAs(注意 KPAs 是叠加的。例如,过程成熟度第三级包含了第二级的所有 KPAs 加上第三级特 有的 KPAs):
过程成熟度第二级
软件配置管理 软件质量保证 软件子合同管理 软件项目追踪和查错 软件项目计划 需求管理
过程成熟度第三级
详细复审 组内协调 软件产品工程 集成的软件管理 培训程序 组织的过程定义 组织的过程焦点
过程成熟度第四级 软件质量管理 定量的过程管理 过程成熟度第五级 过程变化管理

技术变化管理 错误预防
  每一个 KPA 都由一组用于满足其目标的关键行为来定义。这些关键行为 是在一个关键过程区域完全建立之前必须完成的策略、规程和活动。SEI 定 义了关键指示器:“那些关键行为或关键行为的构件,能够很好地判定一个 关键过程区域的目标是否达到”。用于评估的问题被设计来探查关键指示器 的存在(或缺少)。

2.3 软件过程模型


  为了解决产业环境中的实际问题,一个软件工程师或一组工程师必须综 合出一个开发策略,该策略能够覆盖 2.1.1 节所述的过程、方法和工具三个 层次以及 2.1.2 节所讨论的一般阶段。这个策略常常被称为过程模型或软件 工程范型。软件工程过程模型的选择是基于项目和应用的特点、采用的方法 和工具以及需要的控制和交付的产品。在一篇关于软件过程本质的有趣文章 中,L.B.S.Raccoon(参见文献[RAC95])使用了分级几何表示,作为讨论软件 过程本质的基础。
所有软件开发都可看成是一个问题循环解决过程(图 2-3a),其中包含
四个截然不同的阶段:状态描述,问题定义,技术开发和方案综述。状态描 述“表示了事物的当前状态”[RAC95];问题定义标识了要解决的特定问题; 技术开发通过应用某些技术来解决问题;方案综述提交结果(如文档、程序、 数据、新的商业功能、新产品)给那些从一开始就需要方案的人。2.1.2 节定 义的软件工程的一般阶段和步骤可以很容易地映射到这些阶段上。
上述的问题循环解决过程可以应用于软件工程的多个不同开发级别上。
它可以用于考虑整个系统的宏观阶段;开发程序构件的中级阶段;甚至是代 码行编写阶段。因此,可以使用分级几何表示(最早是在几何学的表示中提出 的。定义一个模式,然后在连续的更小的规模上递归地应用它;一个模式套 着一个模式)来提供关于过程的理想化的视图。在图 2-3b 中,问题循环解决 过程的每一个阶段又包含一个相同的问题循环解决过程,该循环还可以再包 含另一个问题循环解决过程(这可以一直继续下去直到一个合理的边界,对于 软件而言,是代码行)。
实际上,要想像图 2-4 那样清楚地划分活动是很困难的,因为阶段内部
和阶段之间的活动常常是交叉的,但这个简化的视图产生了一个重要的思 想:对于一个软件项目而言,不管选择了什么过程模型,所有的阶段——状 态描述,问题定义,技术开发和方案综述——在某个细节的级别上都是同时 存在的。给出了递归性质的图 2-3b,上面讨论的四个阶段既可以用于一个 完整应用的分析也可以用于一小段代码的生成。
  Raccoon(参见文献[RAC95])建议了一种“无序模型”,它描述“软件开 发是从用户到开发者到技术的一个连续过程”。随着向一个完整系统的逐步 进展,上述的阶段递归地应用于用户的需求和开发者的软件技术说明形成 中。
  在下节中,讨论了多个不同的软件工程过程模型,其中每一个都代表了 一种将本质上无序的活动有序化的企图。重要一点的是记住每个模型都具有 能够帮助实际软件项目的控制及协调的特征。但在他们的核心中,这些模型
  
又表现了无序模型的特点。



2.4 线性顺序模型


  图 2-4 表明了软件工程的线性顺序模型,有时也称“传统生命周期”或 “瀑布模型”,线性顺序模型提出了软件开发的系统化的、顺序的方法(虽然
由 Winston Royce[ROY70]提出的最早的瀑布模型支持带有反馈的循环,但 大多数使用该过程模型的组织均把它视为是严格线性的),从系统级开始,随 后是分析、设计、编码、测试和维护。借鉴了传统的工程周期,线性顺序模 型包含以下活动:













  系统/信息工程和建模:因为软件总是一个大系统(或商业)的组成部分, 所以一开始应该建立所有系统成分的需求,然后再将其中某个子集分配给软 件。整个系统基础是,以软件作为其他成分如硬件、人及数据库的接口。系 统工程和分析包括了系统级收集的需求,以及一小部分顶层分析和设计。信 息工程包括了在战略商业级和商业领域级收集的需求。
软件需求分析:需求收集过程特别集中于软件上。要理解待建造程序的
本质,软件工程师(“分析员”)必须了解软件的信息领域(见第 11 章),以及 需求的功能、行为、性能和接口。系统需求和软件需求均要文档化,并与用 户一起复审。
设计:软件设计实际上是一个多步骤的过程,集中于程序的四个完全不
同的属性上:数据结构、软件体系结构、界面表示及过程(算法)细节。设计 过程将需求转换成软件表示,在编码之前可以评估其质量。象需求一样,设 计也要文档化,并且是软件配置的一部分。
代码生成:设计必须转换成机器可读的形式。代码生成这一步就是完成
这个任务的。如果设计已经表示得很详细,代码生成可以自动完成。
  测试:一旦生成了代码,就可以开始程序测试。测试过程集中于软件的 内部逻辑——保证所有语句都测试到,以及外部功能——即引导测试去发现 错误,并保证定义好的输入能够产生与预期结果相同的输出。
  维护:软件在交付给用户之后不可避免地要发生修改(一个可能的例外 是嵌入式软件)。在如下情况下会发生修改:当遇到错误时;当软件必须适应 外部环境的变化时(例如,因为使用新的操作系统或外设);或者当用户希望 增强功能或性能时。软件维护重复以前各个阶段,不同之处在于它是针对已 有的程序,而非新程序。
  线性顺序模型是最早,也是应用最广泛的软件工程范例。但是,对于该 模型的批评使得即使是最积极的支持者也开始怀疑其功效[HAN95]。在使用
  
线性顺序模型过程中有时会遇到如下一些问题:
  1.实际的项目很少按照该模型给出的顺序进行。虽然线性模型能够容许 迭代,但却是间接的。结果,在项目组的开发过程中变化可能引起混乱。
  2.用户常常难以清楚地给出所有需求,而线性顺序模型却要求如此,它 还不能接受在许多项目的开始阶段自然存在的不确定性。
  3.用户必须有耐心。程序的运行版本一直要等到项目开发晚期才能得 到。大的错误如果直到检查运行程序时才被发现,后果可能是灾难性的。
  4.开发者常常被不必要地耽搁。在对实际项目的一个有趣的分析中, Bradac[BRA94]发现传统生命周期的线性特征会导致“阻塞状态”,其中某 些项目组成员不得不等待组内其他成员先完成其依赖的任务。事实上,花在 等待上的时间可能会超过花在开发工作上的时间!阻塞状态经常发生在线性 顺序过程的开始和结束。
  这些问题都是真实存在的。但不管怎样,传统的生命周期范型在软件工 程中仍占有肯定的和重要的位置。它提供了一个模板,使得分析、设计、编 码、测试和维护的方法可以在该模板的指导下展开。传统的生命周期模型仍 然是软件工程中应用最广泛的过程模型。虽然它确实有不少缺陷,但很显然 它比起软件开发中随意的状态要好得多。

2.5 原型模型


  常有这种情况,用户定义了软件的一组一般性目标,但不能标识出详细 的输入、处理及输出需求;还有一些情况,开发者可能不能确定算法的有效 性、操作系统的适应性或人机交互的形式。在这些及很多其他情况下,原型 范型可能是最好的选择。
原型范型(如图 2-5 所示)从需求收集开始。开发者和用户在一起定义软
件的总体目标,标识出已知的需求,并规划出进一步定义的区域。然后是“快 速设计”,快速设计集中于软件中那些对用户/客户可见的部分的表示(如输 入方式和输出格式)。快速设计导致原型的建造。原型由用户/客户评估,并 进一步精化待开发软件的需求。逐步调整原型使其满足客户的要求,同时也 使开发者对将要做的事情有更好的理解,这个过程是迭代的。


  理想上,原型可以作为标识软件需求的一种机制。如果建立了可运行原 型,开发者就可以在此基础上试图利用已有的程序片断或使用工具(如报表生 成器、窗口管理器等)来尽快生成工作程序。
但当原型已经完成了上述目的之后,我们将如何处理它们呐? Brooks
[BRO75]给出了一个答案: 在大多数项目中,建造的第一个系统很少是可用的。它可能太慢,太大,
难以使用或三者都有。没有其他选择,只能重新开始,虽然痛苦,但会得到 更好的结果。建造一个经过重新设计的版本,解决了上述的问题??。当使 用了新的系统概念或新技术时,你应该建造一个抛弃型的系统,因为即使是 最好的计划也不可能是无所不知的,第一次就能完全正确。因此,管理上的 问题不是你是否要建造一个指导系统,然后抛弃它,你必须这么做。唯一的 问题是:是否需要事先计划好建造一个抛弃型系统,或是承诺要将抛弃型系 统交付给用户。
软件工程——实践者的研究方法的下一页
成为本站VIP会员VIP会员登录, 若未注册,请点击免费注册VIP 成为本站会员.
版权声明:本站所有电子书均来自互联网。如果您发现有任何侵犯您权益的情况,请立即和我们联系,我们会及时作相关处理。


其它广告
联系我们     广告合作     网站声明     关于我们     推荐PDF     全部分类     最近更新     宝宝博客
蓝田玉PDF文档网致力于建设中国最大的PDF格式电子书的收集和下载服务!