软件工程 第1章 软件工程概述.ppt

《软件工程 第1章 软件工程概述.ppt》由会员分享，可在线阅读，更多相关《软件工程 第1章 软件工程概述.ppt（68页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第一章软件工程概述【本章引言】自从1946年第一台电子计算机诞生以来，计算机的研究生产和应用得到迅猛的发展，计算机系统已经经历了四个不同的发展阶段，计算机科学成为当今世界上发展最快和应用最广的学科之一。然而，我们仍然没有彻底摆脱“软件危机”困扰，软件已经成为限制计算机系统发展的关键因素。为了克服这种困扰，软件工作者在不断的研究消除软件危机的方法，从而逐步形成了计算机科学技术领域中的一门新兴的工程学科软件工程。本章将对软件概念、软件分类、软件发展、软件危机、软件工程概念、软件生命周期及软件开发模型等方面做简要的介绍，通过本章学习，可为后几章软件工程的深入学习打下基础。【本章重点】软件工程概念软件

2、生命周期软件开发模型【学习目标】理解软件工程的基本概念和软件生命周期了解软件开发的几种模型1.1 软件概述1.2 软件工程的概述1.3 软件生命周期1.4 软件开发模型1.5 小结1.6 习题第一章软件工程概述1.1.1 软件的概念1.1.2 软件的分类1.1.3 软件的发展1.1.4 软件危机1.1 软件概述1.1.1 软件的概念随着计算机技术的快速发展，硬件性能有了极大的提高，计算机体系结构发生了深刻的变化，内存和存储容量的快速增加，以及各种各样的输入和输出选择等，所有这些都促进了更高级和更为复杂的基于计算机系统的开发。软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关

3、文档的完整集合。其中，程序是按事先设计的功能和性能要求执行的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。1.1.2 软件的分类 软件多种多样，随着软件复杂程度的增加，软件的界限越来越不明显。按软件的作用，一般可以分为以下几类。1系统软件 系统软件（system software）是指能与计算机硬件紧密配合在一起，使计算机系统各个部件、相关的软件、和数据协调高效地工作的软件。系统软件是计算机系统的重要组成部分，它支持应用软件的开发和运行。系统软件包括：操作系统、网络软件、编译程序、数据库管理程序、文件编辑系统、系统检查与诊断软件等。2应用软件 应用

4、软件（application software）则是在系统软件基础上，为解决特定的领域应用而开发的软件。按其性质不同可以分为以下几类：事务软件 事务信息处理是一个最大的软件应用领域。如工资单、收/支计算、存货盘点报表等。这些独立的系统可以组成管理信息系统（MIS）软件，它从一个或多个装有事务信息的数据库中存取数据。在这个领域中的应用是重新建立已有的数据，便于事务操作或做出管理决策。另外，除了传统的数据处理应用，事务软件还可以实现交互计算（如营业点的交易处理）。1.1.2 软件的分类实时软件 监视、分析和控制现实世界中发生的事件，能以足够快的速度对输入信息进行处理并在规定的时间内作出反应的软件，

5、称之为实时软件。实时软件包括四个组成部分：数据采集器（负责从外部环境中获取和格式化信息）、分析器（负责将信息转换成应用所需要的形式）、输出/控件器（负责响应外部环境）、管理器（负责协调系统各个部件工作，使系统能保持在一个可接受的响应时间内给实时响应）。实时系统必须在严格的时间范围内响应，因此实时软件和计算机系统必须有很高的可靠性和安全性。1.1.2 软件的分类工程和科学软件 工程和科学软件具有数值算法的特点。其应用范围从天文学到火山学；从自动应力分析到空间航天飞机轨道动力学；从分子生物学到自动化制造。但是，在工程和科学领域中的新的应用已经远离传统的数值算法。计算机辅助设计（CAD）、系统模拟和

6、其他交互应用系统已经做到具有实时和系统软件的特点。1.1.2 软件的分类嵌入式软件 嵌入式计算机系统将计算机嵌入在某一系统之中，使之成为该系统的重要组成部分、控制该系统的运行，进而实现一个特定的物理过程。用于嵌入式计算机系统的软件称为嵌入式软件（embedded software）。大型的嵌入式计算机系统软件可用于航空航天系统、指挥控制系统、武器系统等；小型的嵌入式计算机系统软件可用于工业的智能化产品之中，这时嵌入式软件驻留在只读存储内，为该产品提供各种控制功能和仪表的数字或图形显示功能等。如汽车的刹车控制，空调机、洗衣机的自动控制等。1.1.2 软件的分类个人计算机软件 个人计算机软件市场在

7、过去的十几年就已经兴起。发展字处理、电子报表、计算机图形、家庭游戏、数据库管理、个人和事务财务应用、外部网络或数据库存取等数百种应用。事实上，个人计算机软件体现了一些最具有创新的软件人机界面设计。基于Web的软件 浏览器检索的Web界面是软件，它结合了可执行的指令（CGI、HTML、Perl或Java）和数据（超文本和视频及音频的多种数据）。本质上，网络变成了一个巨大的计算机，提供了一个几乎无限的可通过任何调制解调器被访问的软件资源。1.1.2 软件的分类人工智能软件 人工智能（AI）软件采用非数值算法来解决不适于直接计算和分析的复杂问题。一般说来，这些问题都不能通过计算或直接分析而得到答案。

8、迄今为止，在专家系统、模式识别、自然语言理解、人工神经网络、程序验证、自动程序设计、机器人学等领域开发了许多人工智能应用软件，用于诊断疾病、产品检测、自动定理证明、图像和语言自动识别、语言翻译等。1.1.2 软件的分类3工具软件 这是20世纪80年代发展起来，是系统软件和应用软件之间的支持软件。一般用来辅助和支持开发人员开发和维护应用软件，以提高软件的开发质量和生产率。它包括需求分析工具、设计工具、编码工具、测试工具、维护工具和管理工具等。工具软件又可分为垂直工具软件和水平工具软件。垂直工具软件是指生命周期的某一阶段特定活动所使用的工具软件，如分析、设计、测试等活动；水平工具软件是指整个生命周

9、期活动所使用的工具软件，如项目管理、配置管理等活动。1.1.2 软件的分类4可重用软件 可重用技术是最近几年提出来的。实际上过去就有这种技术，如各种标准程序库，通常它是计算机厂家提供的系统软件中的一部分，对这些标准程序库里的标准子程序稍加改造，甚至不经改造就可以把它们编入新开发的程序。但过去的这种标准程序应用面比较窄，大多只限于一些数学子程序。今天，世界已把可重用范围扩展到算法以外，数据结构也可以重用。20世纪90年代的可重用构件则是把数据和相应的操作两者封装在一起（通常叫做类或对象），使软件工程师能够用可重用构件来建立新的应用程序。例如，现在的交互式界面一般就是用这种可重用构件组成的。这些可

10、重用构件能够建立图形窗口、下拉菜单、以及各种交互机制。建立这样的界面所需要的数据结构和处理细节都包含在一个由界面构件所组成的可重用库里。1.1.2 软件的分类1.1.3 软件的发展 自20世纪40年代世界上第一台计算机问世以来，软件经历了程序设计、程序系统及软件工程三个阶段的发展。程序设计阶段（20世纪50年代至60年代）的软件指的是程序，程序的开发采用个体工作的方式，开发工作主要依赖于开发人员的个人技能和程序设计的技巧，软件的质量得不到保证，缺乏与程序有关的文档。程序系统阶段（20世纪60年代至70年代）的软件是指程序和说明书，软件开发采用开发小组工作的方式，开发工作主要依赖于开发小组的水平

11、，文档资料的不齐全给软件维护带来了很大的难度，软件技术的发展不能满足需要。软件工程阶段（20世纪70年代以后）的软件则是指程序、文档、数据，由开发小组及大中型软件开发机构承担开发软件的任务，开发工作主要依赖于整个机构的管理水平，采用多种开发技术。目前在很多应用领域，人们开始采用面向对象的软件开发技术。专家系统、人工智能软件开始走向实际应用。软件技术呈现国际化、网络化、服务化等多种发展趋势。互联网作为二十世纪最重要的科技成果之一，给人类生活和经济发展都带来了深远的影响，它所展现出的勃勃商机，吸引了众多厂商围绕互联网开发软件，与分布计算、网络和互联网相关的软件技术成为软件领域的主要技术热点。此外，

12、自由软件潮流、智能化、简易化、多样化等趋势正极大地拓展软件产业的发展空间，派生出许多具有成长潜力的新兴领域。1.1.3 软件的发展1.1.4 软件危机1软件危机的含义 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的。实际上，几乎所有软件都不同程度地存在这些问题。概括地说，软件危机包含下述两方面的问题：如何开发软件，以满足对软件日益增长的需求；如何维护数量不断膨胀的已有软件。鉴于软件危机的长期性和症状不明显的特征，近年来有人建议把软件危机更名为“软件萧条（depression）”或“软件困扰（afflication）”。不过“软件危

13、机”这个词强调了问题的严重性，而且也已为绝大多数软件工作者所熟悉，所以本书仍将沿用它。1.1.4 软件危机2产生软件危机的原因 产生软件危机的原因很多，总结起来有以下几点：由于缺乏软件开发经验和有关软件开发数据的积累，使得 开发工作的计划很难制定，以致经常出现超出经费预算，无法遵循进度计划，完成开发的期限一再拖延等情况。软件需求在开发的初期阶段不够明确，或是未能得到确切的表达。开发工作开始后，软件人员和用户又未能及时交换意见，造成矛盾在开发后期集中暴露。开发过程没有统一、公认的方法论和规范进行指导，参加开发的人员各行其事。另外，设计和实现过程的资料很难维护。未能在测试阶段做好充分的检测工作，提

14、交至用户的软件质量差，在运行过程中暴露出大量的问题。1.1.4 软件危机3软件危机的解决方法 为了消除软件危机，首先应该对计算机软件有一个正确的认识。应该彻底清除在计算机系统早期发展阶段形成的“软件就是程序”的错误概念。一个软件必须由一个完整的配置组成。事实上，软件是程序、数据及相关文档的完整集合。其中，程序是能够完成预定功能和性能的可执行的指令序列；数据是使程序能够适当地处理信息的数据结构；文档是开发、使用和维护程序所需要的图文资料。1983年IEEE为软件下的定义是：计算机程序、方法、规则、相关的文档资料以及在计算机上运行程序时所必须的数据。虽然表面上看来在这个定义中列出了软件的5个配置成

15、分，但是方法和规则通常是在文档中说明并在程序中实现的。1.1.4 软件危机 更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。必须充分吸取和借鉴人类长期以来从事各种工程项目所积累的行之有效的原理、概念、技术和方法，特别要吸取几十年来人类从事计算机硬件研究和开发的经验教训。应该推广使用在实践中总结出来的开发软件的成功的技术和方法，并且研究探索更好更有效的技术和方法，尽快消除在计算机系统早期发展阶段形成的一些错误的概念和做法。1.1.4 软件危机 应该开发和使用更好的软件工具。正如机械工具可以“放大”人类的体力一样，

16、软件工具可以“放大”人类的智力。在软件开发的每个阶段都有许多繁琐重复的工作需要做，在适当软件工具辅助下，开发人员可以把这类工作做得既快又好。如果把各个阶段使用的软件工具有机地集合成一个整体，支持软件开发的主过程，则称为软件工程支撑环境。总之，为了消除软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。1.2 软件工程的概念1.2.1 软件工程的定义和原理1.2.2 软件工程的目标1.2.3 软件工程的原则1.2.1 软件工程的定义和原理1软件工程的定义 软件工程（software engineerin

17、g）这个名词是北大西洋公约组织（NATO）科学技术委员会1968年秋在当时的联邦德国召集了近50名第一流的编程人员、计算机科学家和工业界巨头，制定摆脱软件危机的办法时提出来的。尽管当时专家们无法设计出一张指导软件业走向更牢固阵地的详细路线图，但他们借鉴硬件工程的办法，确实为解决软件这一难题，不仅创造了一个新名词软件工程，还使软件工程有了方向。从1968年到现在已经40多年，应该说，在今天，软件工程已发展成为一门独立的学科。1.2.1 软件工程的定义和原理 关于什么是软件工程的定义，每一位软件工程的作者都给出了自己的不同理解。我们把它定义为：运用工程学的原理和方法来组织和管理软件的生产和维护，以

18、保证软件产品开发，运行和维护的高质量和高生产率。1993年，IEEE在IEEE Standard Collecation：Software Engineering给出了以下全面的定义：应用系统的、规范的和可量化的方法去开发、运行和维护软件，即软件的工程化应用。对（1）中所述方法的研究。1.2.1 软件工程的定义和原理2软件工程的基本原理 自从1968在联邦德国召开的国际会议上正式提出并使用了“软件工程”这个术语以来，研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则或“信条”。著名的软件工程专家B.W.Boehm综合这些学者们的意见并总结了TRW公司多年开发软件的经验，于1983年

19、在一片论文中提出了软件工程的7条基本原理。他认为这7条原理是确保软件产品质量和开发效率原理的最小集合。这7条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理。因此，它们是缺一不可的最小集合。然而这7条原理又是相当完备的，人们虽然不能用数学方法严格证明它们是一个完备的集合，但是可以证明在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。1.2.1 软件工程的定义和原理下面简要介绍软件工程的7条基本原理。用分阶段的生命周期计划严格管理 有人经统计发现，在不成功的软件项目中有一半左右是由于计划不周造成的，可见把建立完善的计划作为第1条基本原理是吸取了前人的教训

20、而提出来的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条基本原理意味着，应该把软件生命周期划分成若干个阶段，并相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。Boehm认为，在软件的整个生命周期中应该制定并严格执行六类计划，它们是项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划和运行维护计划。不同层次的管理人员都必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受客户或上级人员的影响而擅自背离预定计划。1.2.1 软件工程的定义和原理坚持进行阶段评审 当时已经认识到，软件的质量保证工作不能等到编码阶段结束之后再进行。这样说至

21、少有两个理由：第一，大部分错误是在编码之前造成的。例如，根据Boehm等人的统计，设计错误占软件错误的63%，编码错误仅占37%；第二，错误发现与改正得越晚，所需付出的代价也越高。因此，在每个阶段都进行严格评审，以便尽早发现在软件开发过程中所犯的错误，是一条必须遵循的重要原则。1.2.1 软件工程的定义和原理实行严格的产品控制 在软件开发过程中不应随意改变需求，以为改变一项需求往往需要付出较高的代价。但是，在软件开发过程中改变需求又是难免的。由于外部环境的变化，相应地改变用户需求是一种客观需要，显然不能硬性禁止客户提出改变需求的要求，而只能依靠科学的产品控制技术来顺应这种要求。也就是说，当改变

22、需求时，为了保持软件各个配置成份的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理。所谓基准配置又称为基线配置，它们是经过阶段评审后的软件配置成份（各个阶段产生的文档或程序代码）。基准配置管理也称为变动控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准后才能实施修改。绝不能谁想修改软件（包括尚在开发过程中的软件），就随意进行修改。1.2.1 软件工程的定义和原理采用现代程序设计技术 从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。20世纪60年代末提出的结构程序设计技术，已经成为绝大多数人公认的程序设计技术

23、。以后又进一步发展出各种结构分析（SA）与结构设计（SD）技术。近年来，面向对象技术已经在许多领域中迅速地取代了传统的结构开发方法。实践证明，采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。1.2.1 软件工程的定义和原理结果应能清楚地审查 软件产品不同于一般的物理产品，它是看不见摸不着的逻辑产品。软件开发人员（或开发小组）的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难于评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚

24、地审查。1.2.1 软件工程的定义和原理开发小组的人员应该少而精 这条基本原理的含义是，软件开发小组的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量，是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件中的错误。此外，随着开发小组人员数目的增加，因为交流情况讨论问题而造成通信开销也急剧增加。当开发小组人员数为N时，可能的通信路径有N(N-1)/2条，可见随着人数N的增大，通信开销将急剧增加。因此，组成少而精的开发小组是软件工程的一条基本原理。1.2.1 软

25、件工程的定义和原理承认不断改进软件工程实践的必要性 遵循上述六条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产。但是，仅有上述六条原理并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原理。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。例如，收集进度和资源耗费数据，收集出错类型和问题报告数据等。这些数据不仅可以用来评价新的软件技术的效果，而且可以用来指明必须着重开发的软件工具和应该优先研究的技术。1.2.2 软件工程的目标 组织实施软件工程项目，从技术

26、上和管理上采取了多项措施以后，最终希望得到项目的成功。成功指的是达到以下几个主要的目标：付出较低的开发成本；达到要求的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用；能按时完成开发工作，及时交付使用。在实际开发的具体项目中，企图让以上几个目标都达到理想的程度往往是非常困难的。而且上述目标很可能是互相冲突的。若只顾降低开发成本，很可能同时也降低了软件的可靠性。另一方面，如果过于追求提高软件的性能，可能造成开发出的软件对硬件有较大的依靠，从而直接影响到软件的可移植性。1.2.2 软件工程的目标 图1-1表明了软件工程目标之间存在的相互联系。其中有些目标之间是互补关系，例如，易

27、于维护和高可靠性之间，低于开发成本与按时交付之间，还有一些目标是彼此互斥的，例如，上述指出的互相冲突的情况。图1-1 软件工程目标之间的关系 这里提到的几个目标很自然地成为判断软件开发方法或管理方法优劣的衡量尺度。如果提出一种新的开发方法，人们关心的是它对满足哪些目标比现有的方法更为有利。实际上，实施软件开发项目就是力图在以上目标的冲突取得一定程度的平衡。1.2.3 软件工程的原则 软件工程的目的是提高软件生产率，提高软件质量，降低软件成本。为了达到这个目的，在软件的开发过程中必须遵循以下软件工程原则。抽象 抽象事物最基本的特征和行为，忽略非基本细节。采用分层次抽象，自顶向下、逐层细化的办法控

28、制软件开发过程的复杂性。信息隐藏 将模块设计成“黑箱”，实现细节隐藏在模块内部，不让模块的使用者直接访问，这就是所谓信息封装（使用与实现分离）的原则。使用者只能通过模块接口访问模块中封装的数据。1.2.3 软件工程的原则模块化 模块是程序中在逻辑上相对自主的成分，是独立的编程单位，应有良好的接口定义。如C语言程序中的函数过程，C+语言程序中的类。模块化有助于信息隐蔽和抽象，有助于表示复杂的系统。局部化 在一个物理模块内集中逻辑上相互关联的计算机资源，保证模块之间有松散的耦合，模块内部有较强的内聚，这有助于控制软件的复杂性。确定性 软件开发过程中所有概念的表达应是确定的，无歧义的、规范的。这样有

29、助于人们在交流时不会产生误解、遗漏，保证整个开发工作的协调一致。1.2.3 软件工程的原则一致性 整个软件系统（包括程序、文档和数据）的各个模块应使用一致的概念、符号和术语；程序内、外部接口应保持一致；软件同硬件、操作系统得接口应保持一致；用于形式化规格说明的公理系统应保持一致。完备性 软件系统不会丢失任何重要成分，可以完全实现系统所要求的功能。为了保证系统的完备性，在软件开发和运行过程中需要严格的技术评审。可验证性 开发大型的软件时需要对系统自顶向下、逐层分解。系统分解应遵循使系统易于检查、测试、评审的原则，以确保系统的正确性。使用一致性、完备性和可验证性可以帮助开发者设计一个正确的系统。1

30、.3 软件生命周期 正如同任何事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程。一般称其为计算机软件的生命周期。根据这一思想，把上述基本的过程活动进一步展开，可以得到软件生命周期的六个步骤，即制定计划、需求分析、设计、程序编码、测试及运行维护。以下对这六个步骤的任务作一概括的描述。1.3 软件生命周期1制定计划 确定要开发软件系统的总目标，给出它的功能、性能、可靠性以及接口等方面的要求；由系统分析员和用户合作，研究完成该项软件任务的可行性，探讨解决问题的可能方案，并对可利用的资源（计算机硬件、软件、人力等）、成本、可取得的效益、开发的进度做出估计，制定出完成开发任务的实施计划，连同

31、可行性研究报告，提交管理部门审查。2需求分析和定义 对待开发软件提出的需求进行分析并给出详细的定义。软件人员和用户共同讨论决定：哪些需求是可以满足的，并对其加以确切的描述。然后编写出软件需求说明书或系统功能说明书，及初步的系统用户手册，提交管理机构评审。1.3 软件生命周期3软件设计 设计是软件工程技术核心。在设计阶段中，设计人员把已确定了的各项需求转换成一个相应的体系结构。结构中的每一组成部分都是意义明确的模块，每个模块都和某些需求相对应，即总体设计。进而对每个模块要完成的工作进行具体的描述，为源程序编写打下基础，即详细设计。所有设计中的考虑都应以设计说明书的形式加以描述，以供后继工作使用并

32、提交评审。4程序编写 把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”。这一步工作也称为编码。自然，写出的程序应当是结构良好、清晰易读的，且与设计相一致的。1.3 软件生命周期5软件测试 测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检验软件的各个组成部分。首先是进行单元测试，查找各模块在功能和结构上存在的问题并加以纠正；其次是进行组装测试，将已测试过的模块按一定顺序组装起来；最后按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。6运行/维护 已交付的软件投入正式使用，便进入运行阶段。这一阶段可能持续

33、若干年甚至几十年。软件在运行中可能由于多方面的原因，需要对它进行修改。其原因可能有：运行中发现了软件中的错误需要修正；为了适应变化了的软件工作环境，需做适当的变更；为了增强软件的功能需做变更。1.4 软件开发模型 为了指导软件的开发，用不同的方式将软件生存周期中的所有开发活动组织起来，形成不同的软件开发模型，软件开发模型是从软件项目需求定义直至软件经使用后废弃为止，跨越整个生命周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。到现在为止，已经提出了多种软件开发模型。例如，瀑布模型、快速原形模型、增量模型、螺旋模型、喷泉模型等。1.4 软件开发模型1.4.1 瀑布模型1.4.2

34、快速原型模型1.4.3 增量模型1.4.4 螺旋模型1.4.5 喷泉模型1.4.1 瀑布模型 瀑布模型（Waterfall Model），它是1970年由W.Royce提出的。瀑布模型规定了各项软件工程活动，包括：制定开发计划，进行需求分析和说明，软件设计，程序编码，测试及运行维护。参看图1-2。并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。图1-2 软件生命周期的瀑布模型1.4.1 瀑布模型 然而软件开发的实践表明，上述各项活动之间并非完全是自上而下，呈线性图式。实际情况是，每项开发活动均应具有以下特征：从上一项活动接受该项活动的工作对象，作为输入；利用这一输入实施该项

35、活动应完成的内容；给出该项活动的工作成果，作为输出传给下一项活动；对该项活动实施的工作进行评审。若其工作得到确认，则继续进行下一项活动;在图1-2中用向下指的箭头表示；否则返回前项，甚至更前项的活动进行返工，在图1-2中由向上指的箭头表示。1.4.1 瀑布模型 需要注意：软件维护在软件生存期中有它的特点。一方面，维护的具体要求是在软件投入运行以后提出来的，经过“评价”，确定变更的重要性，才进入维护工作。另一方面，维护对软件的变更仍然要经历上述软件生命周期在开发中已经历过的各项活动。如果把这些活动一并比表达，就构成了生命周期的循环，如图1-3所示。事实上，有人把维护称为软件的二次开发，正是出于这

36、种考虑。由于软件在投入使用以后可能经历多次变更，为把开发活动和维护活动区别开来，便有了b型的软件生命周期表示，如图1-4所示。它与前述的软件生命周期循环一样，都是软件生命周期瀑布模型的变种。1.4.1 瀑布模型图1-3 软件生存期循环1.4.1 瀑布模型图1-4 具有维护循环的软件生命周期1.4.1 瀑布模型 瀑布模型为软件开发和软件维护提供了一种有效的管理图式。根据这一图式制定开发计划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品及时交付，并达到预期的质量要求。瀑布模型20多年来之所以广为流行，是因为它在消除非结构化软件、降低软

37、件的复杂度、促进软件开发工程工程化方面起着显著作用。与此同时，瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。其中最为突出的缺点是该模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。这些问题的存在对软件开发会带来严重影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。面对这些情况，无疑需要进行返工或是不得不在维护中纠正需求的偏差。但无论上述哪一种情况都必须付出高额的代价，并将为软件开发带来不必要的损失。另一方面，随着软件开发项目规模的日益庞大，由于瀑布模型不够灵活等缺点引发出的上述问题显得更为严重。为弥补瀑布模型的不足，近年来已经提出

38、了多种其他模型。1.4.2 快速原型模型 快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。如图1-5所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修该意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用。一旦用户认为这个原型系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件可以满足用户的真实需求。1.4.2 快速原型模型图

39、1-5 快速原型模型1.4.2 快速原型模型 从图1.5可以看出，快速原型模型是不带反馈环的，这正是这种过程模型的主要优点：软件产品的开发基本上是线性顺序进行的。能做到基本上线性顺序开发的主要原因如下。原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求。因此，在开发过程的后续阶段不会因为发现了规格说明文档的错误而进行较大的返工。开发人员通过建立原型系统已经学到了许多东西（至少知道了“系统不应该做什么，以及怎样不去做不该做的事情”），因此，在设计和编码阶段发生错误的可能性也表较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。软件产品一旦交付给用户使用之后

40、，维护便开始了。根据所需完成的维护工作种类的不同，可能需要返回到需求分析、规格说明、设计或编码等不同阶段，如图1.5中虚线箭头所示。1.4.2 快速原型模型 快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型将被抛弃。因此，原型系统的内部结构并不重要，重要的是，必须迅速地构建原型然后根据用户意见迅速地修改原型。UNIX Shell和超文本都是广泛使用的快速原型语言。最近的趋势是，广泛地使用第四代语言（4GL）构建快速原型。当快速原型的某个部分是利用软件工具由计算机自动生成的时候，可以把这部分

41、用到最终的软件产品中。例如，用户界面通常是快速原型的一个关键部分，当使用屏幕生成程序和报表生成程序自动生成用户界面时，实际上可以把这样得到的用户界面用在最终的软件产品中。1.4.3 增量模型 增量模型也称为渐增模型，如图1-6所示。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。例如，使用增量模型开发字处理软件时，第一个增量构件可能提供基本的文件管理、编辑和文档生成功能；第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现

42、拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。最佳分解方法因软件产品特点和开发人员的习惯而异。分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的。1.4.3 增量模型图1-6 增量模型1.4.3 增量模型 采用瀑布模型或快速原型模型开发软件时，目标都是一次就把一个满足所有需求的产品提交给用户。增量模型则与之相反，它分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品。整个软件产品被分解成许多个增量构件，开发人员一个构件接一个构件地向用户提交产品。每次用户都得

43、到一个满足部分需求的可运行的产品，直到最后一次得到满足全部需求的完整产品。从第一个构件交付之日起，用户就能做一些有用的工作。显然，能在较短时间内向用户提交可完成一些有用的工作的产品，是增量模型的一个优点。增量模型的另一个优点是，逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。1.4.3 增量模型 使用增量模型的困难是，在把每个新的增量构件集成到现有软件体系结构重视，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便。也就是说，软件体系结构必须是开放的。从长远观

44、点看，具有开放结构的软件拥有真正的优势，这样的软件的可维护性明显好于封闭结构的软件。因此，尽管采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。如果一个设计非常灵活而且是够开放，足以支持增量模型，那么，这样的设计将允许在不破坏产品的情况下进行维护。事实上，使用增量模型时开发软件和扩充软件功能（完善性维护）并没有本质区别，都是向现有产品中加入新构件的过程。1.4.3 增量模型 从某种意义上说，增量模型本身事自相矛盾的。它一方面要求开发人员把软件看作一个整体，另一方面又要求开发人员把软件看作构件序列，每个构件本质上都独立于另一个构件。除非开发人

45、员有足够的技术能力协调好这一明显的矛盾，否则用增量模型开发出的产品可能并不令人满意。图1-6所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和总体设计的工作。由于在开始构建第一个构件之前已经有了总体设计，因此风险较小。图1-7描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档。完成后，规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件，用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。1.4.

46、3 增量模型图1-7 风险更大的增量模型1.4.4 螺旋模型 螺旋模型（Spiral Model）如图1-8所示。1988年B.W.Boehm将瀑布模型和原型模型相结合，提出了螺旋模型，这种模型综合了瀑布模型和原型模型的优点，并增加了风险分析。螺旋模型包含了如下四个方面的活动：制定计划：确定软件的目标，选定实施方案，弄清项目开发的限制条件。风险分析：分析所选的方案，识别风险，消除风险。实施工程：实施软件开发，验证阶段产品。客户评估：评估开发工作，提出修正建议。采用螺旋模型时，软件开发沿着螺旋自内向外旋转，每旋转一圈都要对风险进行识别、分析，采取对策以消除或减少风险，进而开发一个更为完善的新软件

47、版本。在旋转的过程中，如发现风险太大，以至于开发者和客户无法承受，那么项目就可能因此而终止。通常，大多数软件开发都能沿着自内向外逐步延伸，最终得到所期望的系统。1.4.4 螺旋模型图1-8 螺旋模型1.4.4 螺旋模型 软件工程的螺旋模型开发模式是当前大型系统或软件开发的最现实的方法。它采用一种逐步逼近的演化方法，使开发人员和用户能了解每一个演化过程中的风险，并做出反应。它保留了传统生存周期逐步求精和细化的方法，但是把它综合到一个重复的框架以后，就可以对这个真实世界做出更加现实的反映。螺旋模型要求对项目所有阶段的技术风险进行直接研究，如果应用正确，将减少它们成为问题的风险。同其他模式一样，螺旋

48、模型也不是包治百病的灵丹妙药。它很难让用户确信（特别是有合同的情况下）这种演化方法是可以控制的。它要求有风险评价的专门技术，因为这些专门技术决定评价的成功与否。如果主要风险不能发现，则问题很可能会发生。1.4.5 喷泉模型 喷泉模型（Water Fountain Model）如图1-9所示，它主要用于描述面向对象的开发过程。喷泉一词体现了面向对象的迭代和无间隙特征。迭代意味着模型中的开发活动常常需要多次重复，在迭代过程中，不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，它不像瀑布模型那样，需求分析活动结束之后才开始设计活动，设计活动结束后才开始编码，而是允许

49、各开发活动交叉、迭代地进行。图1-9 喷泉模型1.5 小结 软件工程是指用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题，指导计算机软件开发和维护的一门工程学科。本章对计算机软件工程学首先作了一个简短的概述。力求使读者对软件工程的基本原理和方法学有一个概括和本质的认识。软件的生命周期模型（即软件过程模型）规定了把生命周期划分成的阶段及各阶段的执行顺序。本章介绍了五类典型的软件生命周期模型。瀑布模型历史悠久、广为人知，它的优势在于它是规范的、文档驱动的方法。这种模型的问题是，最终交付的产品可能不是用户真正需要的。快速原型模型正是为了克服瀑布模型的缺点而提出来的，它通过快速构

50、建起一个可运行的原型系统，让用户试用原型并收集用户反馈意见的办法，获取用户的真实需求。增量模型具有能在软件开发的早期阶段使投资获得明显回报和易于维护的优点。但是，要求软件具有开放结构是使用这种模型时固有的困难。风险驱动的螺旋模型适用于大规模的内部开发项目，但是，只有在开发人员具有风险分析和排除风险的经验及专门的知识时，使用这种模型才会获得成功。1.5 小结 当使用面向对象范型开发软件时，软件生命周期必须是循环的。也就是说，软件过程必须支持反馈和迭代。喷泉模型是一种典型的适合于面向对象范型的过程模型。每个软件开发组织都应该选择适合于本组织及所要开发的软件特点的软件生命周期模型。这样的模型应该把各