《软件工程》课件-第1章 软件工程概述

第1章

软件工程概述XX大学XX系XXX软件工程教程电子科技大学出版社学习目标l

掌握软件的定义与特性；了解软件的分类；l

掌握软件危机产生的原因、表现形式和消除软件危机的途径；l

熟悉软件工程的形成和发展；l

理解软件工程的定义、目标和原则；l

了解软件工程的知识体系及知识域；l

理解软件的生存周期的概念；熟悉常见的软件过程模型；l

掌握软件生存周期各个阶段的任务；了解软件工程的发展趋势。目录010203软件软件危机软件工程04050607软件生存周期软件过程模型软件工程发展趋势本章小结软件01软件简述软件是计算机系统中与硬件相对应的另一部分，是一系列程序、数据及其相关的文档集合。程序是按照特定顺序组织的计算机数据和指令的集合；数据是使程序能正常执行的数据结构；文档是是开发、使用和维护程序所需要的图文资料。计算机软件的核心是程序，而文档则是软件不可分割的组成部分。软件定义著名软件工程专家R.S.

Pressman对软件给出了这样的定义：“软件是能够完成预定功能和性能的可执行的计算机程序和使程序正常执行所需要的数据，加上描述程序的操作和使用的文档。”软件的特性（1）软件的本质特性①

复杂特性。软件是个庞大的逻辑系统，一方面在软件中要客观地体现人类社会的事务，反应业务流程的自然规律；另一方面在软件中还要集成多种多样的功能，以满足用户在激烈的竞争中对大量信息及时处理、传输、存储等方面的需求，这就使得软件变得十分复杂。软件的复杂性使得软件产品难以理解、难以生产、难以维护，更难以对生产过程进行管理。软件的特性②

抽象特性。软件是人们经过大脑思维后加工出来的产品，一般寄生在内存、磁盘、光盘等载体上，我们无法观察到它的具体形态，这就导致了软件开发不仅工作量难以估计，进度难以控制，而且质量也难以把握。③

依赖特性。软件必须和硬件保持一致，软件的开发和运行往往受到计算机硬件的限制，对计算机系统有着不同程度的依赖性。软件与计算机硬件的这种密切相关性与依赖性，是一般产品所没有的特性。为了减少这种依赖性，有关人员在软件开发中提出了软件的可移植性问题。好的软件在设计时就考虑到如何应用到不同的系统平台。软件的特性④

使用特性。软件的价值在于应用，软件产品不会因多次反复使用而磨损老化，一个久经考验的优质软件可以长期使用。由于用户在选择新机型时，通常会提出兼容性要求。因此，一个成熟的软件可以在不同型号的计算机上运行。软件的特性⑤

废弃特性。在软件的运行和使用期间，存在退化问题，必须要对其进行多次修改与维护，直至其“退役”。如早期的DOS操作系统，就是进行了多次修改与维护，实在难以与Windows操作系统匹敌而“退役”了。图1.1和图1.2分别展示了硬件的失效率和使用时间的关系，以及软件的失效率和时间的关系。软件的特性图1.1硬件失效曲线图软件的特性图1.2软件失效曲线软件的特性⑥

应用特性。软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无可取代的地位。软件的特性（2）软件的生产特性①

软件开发特性。由于软件固有的特性，使得软件的开发不仅具有技术复杂性，还有管理复杂性。技术复杂性体现在：软件提供的功能比一般硬件产品提供的功能多，而功能的实现具有多样性，需要在各种实现中做出选择，更有实现算法上的优化带来的不同，而实现上的差异会带来使用上的差别。管理上的复杂性表现在：第一，软件产品的能见度低,要看到软件开发进度比看到有形产品的进度困难得多；第二,软件结构的合理性差，结构不合理使软件管理复杂性随软件规模增大而呈指数增长。软件的特性②

软件产品形式特性。软件产品在设计阶段成本高昂，而在生产阶段成本极低。硬件产品试制成功之后，批量生产需要建设生产线。投入大量的人力物力和资金，生产过程中还要对产品进行质量控制，对每件产品进行严格的检验。然而，软件是把人的知识与技术转化为信息的逻辑产品，开发成功之后，只需对原版软件进行复制即可。大量人力、物力、资金的投入，以及质量控制，软件产品检验都是在软件开发中进行的。由于软件的复制非常容易，软件的知识产权保护就显得极为重要。软件的特性③

软件维护特性。软件在运行过程中的维护工作比硬件复杂得多。首先软件投入运行后，总会存在缺陷甚至暴露出潜伏的错误，需要进行“纠错性维护”。其次，用户可能要求完善软件性能，对软件产品进行修改，进行“完善性维护”。当支撑软件产品运行的硬件或软件环境改变时，也需要对软件产品进行修改，进行“适应性维护”。软件的缺陷或错误属于逻辑性的，因此，不需要更换某种备件，而是修改程序，纠正逻辑缺陷，改正错误，提高性能，增加适应性。当软件产品规模庞大、内部的逻辑关系复杂时，经常会发生为纠正一个错误而产生新错误的情况，因此，软件产品的维护往往比硬件产品的维护工作量大且复杂。软件的分类由于软件产品各式各样、种类繁多，要对软件产品进行分类，并不是件容易的事情。按照不同的标准，会有不同的分类结果。比如，按照软件产品功能的不同，可以分为系统软件、支撑软件和应用软件；按照软件产品服务对象的不同，软件可以分为通用软件和定制软件；按照软件产品规模的不同，软件可以划分为小型、中型、大型和超大型软件；按照软件产品工作方式的不同，可以划分为实时软件、分时软件、交互式软件和批处理软件。软件的分类图1.3软件的分类软件的分类另外，从软件工程学的角度来划分软件产品，可以分为基础软件、支撑软件和应用软件等。基础软件是指保证计算机运行并支撑应用软件运行的基础环境，包括操作系统、数据库、中间件。支撑软件是指支撑各种软件的开发与维护的软件，又称减开发环境（IntegratedDevelopmentEnvironment,

IDE），主要有环境数据库、各种接口软件和工具组，包括编程工具、建模工具、版本控制、软件测试等类型。应用软件是指为满足用户不同领城、不同问题的应用需求而提供的软件，它是用户可以使用的各种程序设计语言，以及用各种程序设计语言编制的应用程序的集合，分为应用软件包和用户程序。应用软件包是利用计算机解决某类问题而设计的程序的集合，可供多用户使用。软件的分类实际上，软件工程所涉及的主要就是应用软件的开发方法和开发管理。应用软件主要可分为如下四类。（1）桌面通用(个人)软件。桌面通用(个人)软件是指安装在PC上可以独立运行的软件，包括办公室软件(如Office,WPS)、互联网软件(如QQ,IE)、多媒体软件(如Photoshop,AutoCAD)等。软件的分类（2）企业级软件。企业级软件是指为商业组织、大型企业、行政事业部等特定领域创建并部署的软件。随着信息化时代的到来以及经济全球化的不断深入，企业级软件已经发生了从部门独立应用到企业集成、从少数人使用到面向广大客户、从企业内部使用到企业问协作的转变。软件的分类（3）嵌入式软件。嵌入式软件就是基于嵌入式系统设计的软件，它也是计算机软件的一种,

同样由程序及其文档组成，也有自己的基础软件(嵌入式系统，如手机上的Android系统)、支撑软件（开发工具包、应用程序编程接口（Application

Programming

Interface,

API）和应用软件。软件的分类（

4

）

云

计

算

软

件

。

对

于

云

计

算

（

C

l

o

u

dComputing），目前广为接受的是美国国家标准与技术研究院(National

Institute

of

Standards

andTechnology,

NIST)给出的定义：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池(资源包括网络、服务器、存储、应用软件和服务)，这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。软件危机02软件危机概述软件危机是指在计算机软件开发和维护时所遇到的一系列问题。软件危机主要包含两方面的问题，一是如何开”发软件以满足社会对软件日益增长的需求；二是如何维护数量不断增长的已有软件。软件危机产生的原因（1）忽视软件开发前期的需求分析。（2）开发过程缺乏统一的、规范化的方法论指导。软件开发是一项复杂的工程，人们需要用科学的、工程化的思想来组织和指导软件开发的各个阶段。而这种工程学的视角正是很多软件开发人员所没有的，他们往往简单地认为软件”开发就是程序设计。（3）文档资料不齐全或不准确。软件文档的重要性没有得到软件开发人员和用户的足够重视。软件文档是软件开发团队成员之间交流和沟通的重要平台，还是软件开发项目管理的重要工具。如果人们不能充分重视软件文档的价值，势必会给软件开发带来很多不便。软件危机产生的原因（4）忽视与用户之间、开发组成员之间的交流。（5）忽视测试的重要性。（6）不重视维护或由于上述原因造成维护工作的困难。由于软件的抽象性和复杂性,使得软件在运行之前对开发过程的进展情况很难估计。再加上软件错误的隐蔽性和改正的复”杂性，这些都使得软件开发和维护在客观上比较困难。（7）从事软件开发的专业人员对这个产业的认识不充分，缺乏经验。软件产业相对于其他工业产业而言，是一个比较年轻、发展不成熟的产业，人们在对它的认识上缺乏深刻性。软件危机产生的原因（8）没有完善的质量保证体系。完善的质量保证体系的建立需要有严格的评审制度，同时还需要有科学的软件测试技术及质量维护技术。若软件”的质量得不到保证，会使得开发出来的软件产品往往不能满足人们的需求，同时人们还可能需要花费大量的时间、资金和精力去修复软件的缺陷，从而导致软件质量的下降和开发预算超支等后果。软件危机的表现形式（1）软件开发费用和进度失控。费用超支、进度拖延的情况屡屡发生。有时为了赶进度或压成本不得不采取一些权宜之计，这样又往往严重损害了软件产品的质量。”（2）软件系统实现的功能与实际需求不符。软件开发人员对用户需求缺乏深入的理解，往往急于编写程序,闭门造车,最后完成的软件与用户需求相距甚远。（3）软件的可靠性差。尽管耗费了大量的人力物力，系统的正确性却越来越难以保证,出错率大大增加，由于软件错误而造成的损失十分惊人。软件危机的表现形式（4）软件难以维护。很多程序缺乏相应的文档资料，程序中的错误难以定位，难以改正，有时改正了已有的错误又引入新的错误。随着软件的社会拥有量越来越大，软件维护占用了大量的人力、”物力和财力。（5）软件通常没有适当的文档资料。计算机软件不仅仅是程序，还应有一整套文档资料。这些文档资料应该是在软件开发过程中产生出来的，与程序代码完全一致的。缺乏必要的文档资料或者文档资料不合格，必然给软件开发和维护带来许多严重的问题。软件危机的表现形式（6）软件成本在计算机系统总成本中所占的比例居高不下，且逐年上升。由于微电子学技术的进步和硬件生产自动化程度不断提高，硬件成本逐年下降，性能和产量迅速提高。然而软件开发需要大量人力，软件成本随着软件规模和数量的剧增而持续上升。”（7）软件生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。软件生产不能满足日益增长的软件需求。软件生产率远低于硬件生产率和计算机应用的增长率,社会出现了软件供不应求的局面。更为严重的是，软件生产效率随软件生产规模的增加和软件复杂性的提高而急剧下降。消除软件危机的途经（1）使用好的软件开发技术和方法。（2）使用好的软件开发工具，提高软件生产率。（3）开发过程要有统一的、公认的方法论和规范指导，必须”按照规定的方法论进行开发。（4）必须在测试阶段充分做好检测工作，给客户提交高质量的软件。软件工程03软件工程的形成与发展（1）20世纪70年代。提出了软件生产工程化的思想、软件生存周期的概念、多种开发模型、方法与多种软件开发工具。（2）20世纪80年代。提出软件能力成熟度模型、个体软件过程、群组软件过程等概念。在软件定量研究方面提出了软件工作量估计COCOMO（Constructive

Cost

Model）模型。软件开发过程从目标管理转向过程管理。（3）20世纪90年代末。出现了许多的敏捷方法。（4）21世纪。对快速应用开发(Rapid

ApplicationDevelopment，RAD)追求的趋势仍在继续。软件工程的定义软件工程是计算机科学中的一个重要分支，国家标准GB/T11457--2006《信息技术软件工程术语》对软件工程的定义为：“软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度，实现满足用户要求的软件产品的定义、开发、发布和维护的工程或进行研究的学科。”IEEE对软件工程的定义为：①

将系统化、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。②对①中所述方法的研究。软件工程的定义具体来说，软件工程是以借鉴传统工程的原则和方法，以提高质量、降低成本为目的指导计算机软件开发和维护的工程学科。它是一种层次化的技术，如图1.4所示。图1.4软件工程层次图软件工程的目标和原则软件工程要达到的基本目标包括以下六方面：（1）达到要求的软件功能。（2）取得较好的软件性能。（3）开发出高质量的软件。（4）付出较低的开发成本。（5）需要较低的维护费用。（6）能按时完成开发工作，及时交付使用。软件工程的目标和原则1983年，著名软件工程专家B.W.Boehm综合有关专家和学者的意见并根据多年来开发软件的经验，提出了软件工程的七条基本原则。（1）用分阶段的生存周期计划进行严格的项目管理；（2）坚持进行阶段评审；（3）实行严格的产品控制；（4）采用现代程序设计技术；（5）软件工程结果应能清楚地审查；（6）软件工程结果应能清楚地审查；（7）承认不断改进软件工程实践的必要性。软件工程知识体系及知识域软件工程知识体系指南将软件工程知识体系划分为10个知识域，包含在两类过程中。一类过程是开发与维护过程，包括软件需求、软件设计、软件构造、软件测试和软件维护；另一类过程是支持过程，包括软件配置管理、软件工程管理，软件工程过程、软件工程工具写方法、软件质量。每个知识域还可进一步分解为若干个论题，在论题描述中引用有关知识的参考文献，形成一个多级层次结构，以此确定软件工程知识体系的内容和边界。每个知识域的具体内容如表1.1所示。软件工程知识体系及知识域表1.1软件工程知识体系指南的内容知识域子知识域软件需求基础、需求过程、需求获取、需求分析、需求规格说明、需求确认、实践考虑软件需求软件设计基础、软件设计关键问题、软件结构与体系结构、软件设计质量的分析与评价、软件设计记法、软件设计的策略与方法软件设计软件构造

软件构造基础、管理构造、实际考虑软件测试

软件测试基础、测试级别、测试技术、与测试相关的度量、测试过程软件工程知识体系及知识域软件维护

软件维护基础、软件维护关键问题、维护过程、维护技术软件配置过程管理、软件配置标识、软件配置控制、软件配置软件配置管理状态报告、软件配置审计、软件发行管理和交付项目启动和范围定义、软件项目计划、软件项目实施、评审与评价、项目收尾、软件工程度量软件工程管理软件工程

过程定义、过程实践与变更、过程评估、过程和产品度量过程软件工程知识体系及知识域软件工程工

软件工具（软件需求工具、软件设计工具、软件构造工具、具与方法

软件测试工具、软件维护工具、软件配置管理工具、软件工程过程工具、软件质量工具和其他工具问题）、软件工程方法（启发式方法、形式化方法、原型方法）软件质量

软件质量基础、软件质量过程、实践考虑软件工程知识体系及知识域软件工程学的主要内容是软件开发技术和软件工程管理。其中，软件开发技术包括软件工程方法学、软件工具和软件开发环境；软件工程管理包括软件工程经济学和软件管理学。（1）软件工程方法学软件工程方法学是编制软件的系统方法，它确定软件开发的各个阶段，规定每阶段的活动、产品、验收的步骤三个要素，分别为方法、工具和过程。其中，方法是完成软件开发任务的技术方法；工具是为方法的运用提供自动或半自动的软件支撑环境；过程规定了完成任务的工作阶段、工作内容、产品、验收的步骤和完成准则。软件工程知识体系及知识域（2）软件工具软件工具(Software

Tools，ST)是指为了支持计算机软件的开发和维护而研制的程序系统。使用软件工具的目的是提高软件设计的质量和生产效率，降低软件开发和维护的成本。（3）软件开发环境软件开发环境的设计目标是提高软件生产本和改善软件质量。（4）软件工程管理软件工程管理就是对软件开发各阶段的活动进行管理，其目的是确保按预定的时间和费用，成功地生产出软件产品。软件生存周期04软件生存周期的软件生存周期由软件定义、软件开发和运行维护(也称为软件维护)三个时期组成，每个时期又进一步划分成八个阶段，如图1.5所示。图1.5软件生存周期软件生存周期各个阶段的任务（1）软件定义时期软件计划时期确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本,并且制定工程进度表。分为问题定义、可行性研究和需求分析三个阶段，这个时期的工作通常又称为系统分析，由系统分析员负责完成。软件生存周期各个阶段的任务（2）软件开发时期软件开发时期可分为概要设计、详细设计、编码和单元测试、综合测试四个阶段组成。其中，前两个阶段又称为系统设计，后两个阶段又称为系统实现。（3）软件维护时期软件交付使用后，在软件运行过程中，需要不断地进行维护，才能使软件持久地满足用户的需要。具体地说，当软件在使用过程中发现错误时应该加以改正；当环境改变时应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。通常对维护时期不再进一步划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。软件生存周期各个阶段的任务下面依次介绍软件生存周期八个阶段的主要任务。（1）问题定义确定系统的目标、规模和基本任务。（2）可行性研究从经济、技术、法律等方面分析确定系统是否值得开发，及时建议停止不值得开发的项目，避免人力、物力和时间的浪费。（3）需求分析确定软件系统应具备的具体功能。通常用数据流图、数据字典和简明算法描述表示系统的逻辑模型，以防止产生系统设计与用户的实际需求不相符的后果。软件生存周期各个阶段的任务（4）概要设计确定系统设计方案、软件的体系结构。确定软件由哪些模块组成以及这些模块之间的相互关系。（5）详细设计描述应该如何具体地实现系统。详细设计的每个模块应确定实现模块所需要的算法和数据结构。（6）软件实现和单元测试阶段进行程序设计(编码)和单元测试。软件生存周期各个阶段的任务（7）综合测试阶段通过综合测试过程，查找软件设计中的错误并改正，确保软件质量。同时，还要在用户的参与下进行验收，才可交付使用。（8）运行维护阶段在软件运行期间，通过各种必要的维护，使系统改正错误或修改扩充功能以适应环境变化，从而延长软件的使用寿命，提高软件的效益。每次软件维护的要求及修改过程都应详细准确地记录下来，并作为文档加以保存。软件过程模型05瀑布模型瀑布模型（Waterfall

model）一直是唯一被广泛采用的软件生存期模型。瀑布模型是一种基于里程碑的阶段过程模型,

它所提供的里程碑式的工作流程,

为软件项目按规程管理提供了便利，并对提高软件产品质量提供了有效保证。传统软件工程方法学的软件过程，基本上都可以用瀑布模型来描述，如图1.6所示。瀑布模型图1.6传统的瀑布模型瀑布模型（1）传统的瀑布模型的特点如下：①

软件生存周期的顺序性顺序性是指只有前一阶段工作完成以后，后一阶段的工作才能开始；前一阶段的输出文档，就是后一阶段的输入文档。只有在前一阶段有正确的输出时，后一阶段才可能有正确的结果。因而，瀑布模型的特点是由文档驱动。如果在生存周期的某一阶段出现了错误，往往要追溯到在它之前的一些阶段。瀑布模型②

尽可能推迟软件的编码程序设计也称编码。实践表明，大、中型软件的编码阶段开始得越早，完成所需要的时间反而越长。瀑布模型在编码之前安排了需求分析、概要设计、详细设计等阶段，从而把逻辑设计和编码清楚地划分开来，尽可能推迟程序编码阶段，以保证软件开发质量。瀑布模型③

保证质量为了保证质量，瀑布模型坚持两个重要做法。一方面，每个阶段都要完成规定的文档；另一方面，每个阶段都要对已完成的文档进行复审，以便及早发现隐患，排除故障。瀑布模型事实上，实际的瀑布模型是带“反馈环”的，如图1.7所示。右图中实线箭头表示开发过程，虚线箭头表示维护过程。当在后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。图1.7实际的瀑布模型瀑布模型（2）瀑布模型的优点①可强迫开发人员采用规范化的方法；②严格地规定了每个阶段必须提交的文档；③要求每个阶段交出的所有产品都必须是经过验证(评审)的。（3）瀑布模型的缺点①

由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要，如果需求规格说明与用户需求之间有差异，就会发生这种情况；②瀑布模型只适用于项目开始时需求已确定的情况。快速原型模型快速原型模型(RapidPrototype

Model)的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。快速原型模型从图1.8可以看出，快速原型模是不带反馈环的，快速原型模型的点如下。（1）有助于满足用户的真实需求。（2）原型系统已经通过与用户的交而得到验证，据此产生的规格说明档能够正确地描述用户需求。（3）软件产品的开发基本上是按线顺序进行。图1.8快速原型模型快速原型模型（4）因为规格说明文档正确地描述了用户需求，所以在开发过程的后续阶段不会因发现规格说明文档的错误而进行较大的返工。（5）开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。（6）快速原型的本质是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型就可以抛弃，当然也可以在原型的基础上进行开发。增量模型增量模型（Incremental

model）也称为渐增模型，是Mills等人于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。增量模型每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图1.9所示。图1.9增量模型增量模型（1）增量模型的优点①

能够在较短的时间内向用户提交一些有用的工作产品，即从第一个构件交付之日起，用户就能做些有用的工作。②

逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少全新的软件可能给用户、组织带来的冲击。③

项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。④

优先级最高的服务首先交付，然后，再将其他增量构件逐次集成进来。一个必然的事实是：最重要的系统服务将接受最多的测试。这意味着系统最重要的部分一般不会遭遇失败。增量模型（2）采用增量模型需注意的问题①在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出来的产品。②

软件体系结构必须是开放的，即向现有产品中加人新构件的过程必须简单、方便。螺旋模型在软件开发过程中必须及时识别和分析风险，并且采取适当措施以清除或减少风险的危害。1988年，Boehm最早提出了螺旋模型（Spiral

model），该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。螺旋模型可以看作是在每个阶段之前都增加了风险分析过程的快速原型模型，如图1.10所示。螺旋模型图1.10完整的螺旋模型螺旋模型图1.11完整的螺旋模型螺旋模型螺旋模型的优点是：（1）对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。（2）减少了过多测试或测试不足所带来的风险。（3）在螺旋模型中维护只是模型的另一个周期，因此，在维护和开发之间并没有本质区别。螺旋模型螺旋模型的缺点是：螺旋模型是风险驱动的，因此，要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险，当项目正在走向灾难时，开发人员可能还以为一切正常。喷泉模型喷泉模型(FountainModel)是典型的面向对象软件开发模型，着重强调不同阶段之间的重叠，认为面向对象的软件开发过程不需要或不应该严格区分不同的开发阶段。喷泉模型的示意图如图1.12所示。喷泉模型图1.12喷泉模型喷泉模型在分析阶段，定义类和对象之间的关系，建立对象-关系和对象-行为模型。在设计阶段，从实现的角度对分析阶段模型进行修改或扩展。在编码阶段，使用面向对象的编程语言和方法实现设计模型。在面向对象的方法中，分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行。统一软件开发过程模型统一软件开发过程（Rational

Unified

Process，R

U

P

）

模

型

是

基

于

统

一

建

模

语

言

（

U

n

i

f

i

e

dModeling

Language，UML）的一种面向对象软件开发模型。它解决了螺旋模型的可操作性问题，采用迭代和增量递进的开发策略，并以用例驱动为特点，集中了多个软件开发模型的优点。RUP模型是迭代模型的一种。RUP模型的示意图如图1.13所示。统一软件开发过程模型图1.13统一软件开发过程模型统一软件开发过程模型基于统一软件开发过程模型所构造的软件系统，是由软件构件建造而成的。这些软件构件定义了明确的接口，相互连接成整个系统。在构造软件系统时，RUP采用架构优先的策略。软件架构概念包含了系统中最重要的静态结构和动态特征，架构体现了系统的总体设计。架构优先开发的原则是RUP开发过程中至关重要的主题。统一软件开发过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。基于构件的开发模型基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的，也可以是现有的商业成品构件（Commercial

Off-The-Shelf，COTS）。

基

于

构

件

的

软

件

工

程

(

C

o

m

p

o

n

e

n

t

B

a

s

e

dSoftware

Engineering，CBSE)强调使用可复用的软件“构件”来设计和构造基于计算机系统。一种基于构件的开发模型如图1.15所示，包括系统开发、构件开发与维护两部分。基于构件的开发模型图1.15基于构件的开发模型基于构件的开发模型基于构件的开发模型中，需求分析与设计建模活动开始于识别可选构件，这些构件有些设计成通用的软件模块，有些设计成面向对象的类或软件包。不考虑构件的开发技术，基于构件的开发模型由以下步骤组成：（1）对该问题领域的基于构件的可用产品进行研究和评估；（2）考虑构件集成的问题；（3）设计软件体系结构(或称架构)以容纳这些构件；（4）将构件集成到体系结构中；（5）进行充分的测试以保证功能正常。敏捷软件开发模型（1）敏捷过程概述敏捷开发开始于“敏捷软件开发宣言”。在2001年2月，17位软件开发方法学家在美国犹他州召开了长达两天的会议，制定并签署了“敏捷软件开发宣言”，该宣言给出了四个价值观。①个体与交互高于过程和工具②可运行软件高于详尽的文档③与客户协作高于合同(契约)谈判④对变更及时响应高于遵循计划敏捷软件开发模型（2）极限编程极限编程是一种实践性较强的、规范化的软件开发方法，它强调用户需求和团队工作。极限编程包含了一组相互作用和相互影响的规则和实践。极限编程的整体开发过程如图1.16所示。敏捷软件开发模型图1.16极限编程的整体开发过程敏捷软件开发模型首先，项目组针对客户代表提出的“用户故事”（用户故事类似于用例，但比用例更简单，通常仅描述功能需求），进行讨论，提出隐喻，在此项活动中可能需要对体系结构进行“试探”，所谓试探就是提出相关技术难点的试探性解决方案。然后，项目组在隐喻和用户故事的基础上，根据客户设定的优先级制订交付计划(为了制订出切实可行的交付计划，可能需要对某些技术难点进行试探)。接下来开始多个迭代过程(通常每个迭代历时1-3周)，在迭代期内产生的新用户故事不在本次迭代内解决，以保证本次开发过程不受干扰。开发出的新版本软件通过验收测试之后交付用户使用。极限编程的迭代开发过程如图1.17所示。敏捷软件开发模型图1.17极限编程的迭代开发过程几种模型之间的关系（1）瀑布模型与RUP模型之间的关系在宏观上，瀑布模型是静态模型，RUP模型(RUP型是迭代模型的一种)是动态模型。RUP模型的每一次迭代，实际上都需要执行一次瀑布模型，都要经历先启、细化、构建和产品化这四个阶段，完成瀑布模型的整个过程。在微观上，瀑布模型与RUP模型都是动态模型。瀑布模型与RUP模型在每一个开发阶段(先启、细化、构建、产品化)的内部都需要有一个小小的迭代过程，只有进行这样的迭代，开发阶段才能做得更好。几种模型之间的关系瀑布模型与RUP模型之间的关系可用图1.18来表述，瀑布模型中有RUP模型，反过来，RUP模型中也有瀑布模型。图1.18瀑布模型与RUP模型之间的关系几种模型之间的关系（2）瀑布模型与增量模型之间的关系增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，一个模块接着一个模块地进行开发，直到开发完所有的模块。在开发每个模块时，通常都是采用瀑布模型，从分析、设计、编码和测试这几个阶段进行开发。所以，增量模型中有瀑布模型，即宏观上是增量模型，微观上是瀑布模型。增量模型也体现了迭代思想，每增加一个模块，就进行一次迭代，执行一次瀑布模型。因此，增量模型本质上是迭代的。几种模型之间的关系（3）瀑布模型与快速原型模型之间的关系快速原型模型的基本思想是快速建一个能反映用户主要需求的原型系统，在此基础上之后的每次迭代，都可能会用到瀑布模型。快速原型模型中不但包含了迭代模型的思想，而且包含了瀑布模型的思想。几种模型之间的关系（4）瀑布模型与螺旋模型之间的关系螺旋模型是瀑布模型和快速原型模型的结合，快速原型模型是原型模型的简化，原型模型又是迭代模型和瀑布模型的组合，这些模型之间是相互依存的、彼此有关的。螺旋模型每次顺时针方向旋转，相当于顺时针方向迭代一次，都是走完一次瀑布模型，这就是瀑布模型与螺旋模型之间的关系。实际上，瀑布模型与喷泉模型也有关系。软件过程模型的选择（1）软件过程模型选择需要考虑的因素①符合软件自身的特性，如规模、成本和复杂性等。②满足软件开发进度的要求。③对软件开发的风险进行预防和控制。④具有计算机辅助工具的支持。⑤与用户和软件开发人员的知识和技能相匹配。⑥有利于软件开发的管理和控制。软件过程模型的选择（2）软件过程模型实例例1：针对下面这些应用开发软件，应采用哪种软件过程模型？要求说明原因。①已经充分了解了的数据处理应用程序。解：应选用瀑布模型。原因：在软件开发的过程中，需求不发生或很少发生变化，并且开发人员可以一次性获取全部需求；软件项目的风险较低；开发者对软件应用领域很熟悉。软件过程模型的选择（2）软件过程模型实例例1：针对下面这些应用开发软件，应采用哪种软件过程模型？要求说明原因。②

通过卫星通信连接计算机的新软件产品，假设之前没有开发卫星通信软件的经验。解：应选用螺旋模型。原因：没有相应的开发经验，风险较大，螺旋模型明确包括了开发的每一阶段中的风险处理，在每一次迭代中，风险分析通过原型构建进行，允许对处理风险可用的不同选项进行权衡。软件过程模型的选择（2）软件过程模型实例例2：假设计划研发一种产品技术含量很高，与客户有关的风险也很多，你会采用哪种软件过程模型？请说明理由。解：采用RUP模型。RUP模型在每个步骤后都会形成一个可以发布的产品