第二章 软件工程的概念
第一节 软件工程定义
第二节 软件工程方法
第三节 常见的几种软件开发模型
第一节 软件工程的定义
一,软件工程的定义
二,软件工程的性质
三,软件工程的目标
四,软件工程的研究内容
一、软件工程的定义
软件工程思想是 20世纪 60年代末提出的,70
年代以后逐步发展起来的一门指导计算机软件开发
和维护的工程科学。
采用工程的概念、原理、技术和方法来开发
与维护软件，把经过时间考验而证明正确的管理技
术和当前能够得到的最好的技术方法结合起来，这
就是软件工程。
这门学科的目的是研究如何从管理和技术两
方面更好地开发和维护计算机软件。
1968年在联邦德国召开的国际会议上正
式提出并使用了, 软件工程, 这个术语，运
用工程学的基本原理和方法来组织和管理软
件生产。
后来还发展了与软件有关的心理学、生
理学和经济学等方面的学科。
在这个期间，研究软件工程的专家学者
们陆续提出了 100多条关于软件工程的准则。
这 100多条准则可以概括为下述 6条基本原则。
6条基本原则。
1,用分阶段的生存周期计划严格管理
2,坚持阶段评审
3,实行严格的产品控制
4,采用现代程序设计技术
5,能非常清楚地审查结果
6,合理安排软件开发小组人员
仅遵循以上 6 条，一成不变是不够的，软件
工程本身就是一项实践工程。随着计算机系统的
发展，必须不断地灵活地改进软件工程的实践。
这就必须积极主动地采用新的软件技术，注意不
断地总结经验，不断地有条件地进行继承和扬弃，
不断地认识未知和演变地处理未知，推进软件工
程的发展。
二、软件工程的性质
软件工程涉及到计算机科学、工程
科学、管理科学、经济学和数学等领域，
是一门综合性的交叉学科。
计算机科学中的所有学科的知识都可应用于
软件工程，特别是计算机专业的本科生，通过计
算机科学与技术专业的课程学习，有了较扎实的
理论基础，软件工程将给予你一个计算机知识综
合应用的工程概念，会让你所学的计算机学科知
识起到一个画龙点睛的作用。有了软件工程思想
方法，应用所学的计算机知识，就知道如何建造
一个软件系统。
软件工程要用工程科学中的思想、观点来
进行软件项目规划、经费估算、制定项目进度、
制定项目计划和制定项目开发方案；用管理科
学、经济学的思想和方法对软件项目进行管理、
成本核算、投入产出分析；用数学的方法建立
软件项目开发过程中的各种模型和各种算法，
进行正确性、可靠性分析，建立用户需求的形
式化模型等。
三、软件工程的目标
? 有较低的开发成本。
? 能达到用户所要求的软件功能。
? 有很好的软件性能。
? 软件有较好的可移植性、稳定性、健壮性
和可靠性。
? 有较好的可维护性，较低的维护成本。
? 能按计划规定的进度开发，及时交付使用。
软件工程是一门工程性的学科，软件工程
的目的是成功地构造一个大型软件系统。所谓
成功是指达到以下标准：
软件产品是把思维、概念、算法、组织、
流程、效率、质量、成本等多方面的问题融为
一体的产品，它不同于一般意义上的工程开发
与管理，必须通过人员组织管理、项目计划管
理和配臵管理来保证软件的高质量完成。软件
的交付使用也不同于一般意义上的工程项目交
付使用，软件的交付使用必须将软件的思想方
法渗透到组织、人员中去。从这个意义上看，
软件工程目标的内涵是十分丰富多彩的。
四、软件工程的研究内容
软件工程是计算机领域的一个较大的研究方向，其内
容十分丰富，包括：理论、结构、方法、工具、环境、管理、
经济、规范等。
软件工程理论与结构是软件开发的技术基础，包括程
序正确性证明理论、软件可靠性理论、软件成本估算模型、
软件开发模型、模块划分原理等。
软件开发技术包括软件开发方法学、软件工具和软件
开发环境，良好的软件工具可促进方法的研制，而先进的软
件开发方法能改进工具，软件工具集成软件开发环境。软件
开发方法、工具和环境是相互作用的。
软件工具一般是指为了支持软件人员开发和维护
活动而使用的软件。
例如，项目估算工具、需求分析工具、设计工具、
编码工具、测试工具和维护工具等。
使用了软件工具后，可大大提高软件生产率。机
械工具可以放大人类的体力，软件工具可以放大人类
的智力。
最初的软件工具是以工具箱的形式出现的，一种
工具支持一种开发活动，然后将各种工具简单组合起
来。 这类工具箱的工具界面不统一，工具内部无联系，
工具切换由人工操作。
工具箱主要由八类工具组成：
1,业务系统规划工具。
2,项目管理工具。 有效地估算软件项目所
需的工作量、成本和研制周期。
3,支持工具。 用于支持软件工程过程，有
文档编制工具、系统软件工具、质量保证
工具、数据库管理工具、软件配臵管理工
具。
4,分析和设计工具。
5,编程工具。编译器、编辑器、调试器（如
4GL）。
6,测试与分析工具。常用的测试与分析工具。
7,原型工具。
8,维护工具。
由于工具箱存在的问题，人们在工具系统的整
体化及集成化方法上展开了一系列研究工作，使
之形成完整的软件开发环境。其目的是使软件工
具支持整个生存周期。它不仅能支持软件开发和
维护中的个别阶段，而且能够支持从项目开发计
划、需求分析、设计、编码、测试到维护等所有
阶段，做到不仅支持各阶段中的技术工作，还支
持管理和操作工作，保证项目开发的高度可预见
性、可控制性和可追踪性。
软件开发环境是指全面支持软件开发全过程
的软件工具集合，主要体现在三个级别上：
程序设计环境、系统合成环境、项目管理环
境。
如，以语言为中心的环境、面向结构的环境、
工具箱环境、基于方法的环境及计算机辅助软件
（ CASE）。
软件管理技术是实现开发质量的保证。
软件工程管理包括软件开发管理和软件经济
管理。
软件开发管理包括软件开发规划的制定、
人员的组成、制定计划、确定软件标准与配
臵。
软件经济管理主要指成本估算、效益评
价、风险分析、投资回收计划、质量评价等。
软件工程学的最终目的是研究开发以较少的
投入获得易维护、易理解、可靠性高的软件产品。
所以软件工程学就必须研究软件结构、软件设计
与开发方法、软件的维护方法、软件工具与开发
环境、软件工程的标准与规范、软件工程经济学
以及软件开发技术与管理技术的相关理论。
软件工程
软件开发技术
软件工程管理
软件开发方法
软件开发工具
软件开发环境
软件开发管理
软件心理学
软件工程经济学
第二节 软件工程方法
软件工程是系统工程概念、思想、
方法在软件开发和维护中的具体体现，
是由系统工程派生出来的。系统工程就
是把组织 管理 与 技术 管理相结合，软件
工程也是将软件开发的管理与技术紧密
结合的学科。
所谓 管理 是指通过计划、组织、领导、控制
和创新等一系列活动，合理地配臵和使用各种资
源，以达到既定目标的过程。
技术 是指在软件生命周期的全过程中使用的
一整套技术的集合。
技术由各种方法组成，方法又称范型。
? 方法
? 语言
? 工具
? 过程
软件工程方法学包括四个要素：
方法提供如何构造软件的技术。包括与
项目有关的计算和各种估算，系统和软件需求
分析，数据结构设计，程序体系结构，算法过
程，编码，测试和维护等。软件工程方法通常
引入多种专用的图形符号以及一套软件质量的
准则。方法是解决如何做的问题。
语言用以支持软件的分析、设计和实现。随着
编译程序和软件技术的完善，传统的编程语言表
述能力更强，更加灵活，而且支持过程实现更加
抽象的描述。与此同时，规格说明语言和设计语
言也开始有更大的可执行子集。
现在还发展了原型开发语言、面向对象语言。
原型开发语言除必须具有执行的能力外，还必须
有规格说明和设计这两种语言能力。
工具为方法和语言提供了自动化或半自动化的软
件支持环境。
今天，工具可以支持上面提到的任一种方法和语
言。当这些工具集成起来，由一个工具产生的信息可
以被另一个工具使用时，就形成了一个支持软件开发
的系统。这个系统我们称之为计算机辅助软件工程系
统 (Computer-Aided Software Engineering)，简称
CASE。 CASE把软件、硬件、软件工程数据库 (包括分析、
设计、编码和测试重要信息的数据结构 )组成一个软件
工程环境，类似于硬件的计算机辅助设计 /计算机辅助
工程 (CAD/CAE)。
过程是粘结剂，把方法、语言和工具粘结在一
起，它能使计算机软件开发理性化和适时化。
过程定义了方法使用的顺序、可交付产品 (文
档、报告以及格式等 )的要求以及帮助确保质量和
变更的控制，使软件管理人员能对它们的进展进
行评价。
过程是为了获得高质量的软件所需要完成的一
系列任务的框架，它规定了完成各项任务的工作
步骤。
这些工作步骤通常叫作软件工程模式，软件
工程模式是根据项目和应用的性质、方法、语言、
工具的使用、控制和可交付产品的要求来选择的。
是软件工程方法研究的主要内容。目前使用最广泛
的工程方法学是：
? 生命周期方法学
? 原型方法学
? 面向对象方法学
生命周期方法学，也称传统方法学，或称
结构化方法学。它采用结构化技术来完成软件
开发的任务，在其过程中使用适当的软件工具
或软件环境来支撑结构化技术的运用。
所谓结构化技术包括：
结构化分析、结构化设计、结构化程序设计
和结构化测试。
这种方法学把软件生命周期的全过程依次划
分为任务相对独立、相对简单的若干个阶段，
然后顺序地完成每个阶段的任务。
从对任务的抽象逻辑开始，一个阶段一个阶
段地顺序开发，前一个阶段的完成是后阶段开始
的前提和基础，后一阶段的完成通常是使前一阶
段提出的算法更进一步具体化，增加了更多的实
现细节。每一个阶段结束之前都必须进行正式的
技术审查和管理复审，从技术和管理两方面对这
个阶段的开发成果进行检查，通过这个阶段才算
结束；如果不通过，则必须进行必要的返工，并
且返工后还要再经过审查。
审查的一条主要标准就是每个阶段都应该
交出与所开发的软件相一致的文档资料，保证
在软件开发结束时有一个完整准确的软件配臵
交付使用。
在进行生命周期的每个阶段的任务时，应
该采用适合该阶段任务特点的系统化的技术，
即结构化分析、结构化设计、结构化程序设计
和结构化测试技术。
这种传统的软件开发方法，是面向过程的 (或说
是面向行为的 )。
其优点是开发的软件整体性较强。
缺点是软件开发的成功率较低，对需求分析的
要求很高，维护很困难。
它适合开发功能和性能预先知道的软件，如系
统软件、嵌入式软件、实时控制系统等。而对于一
些功能和性能事先不太明确的软件，开发的成功率
较低。
目前，这种传统的软件开发方法仍然广泛使用。
原型方法学是根据简单的用户需求，用软件
工具快速生成软件原型 (模型 )，用户与开发人员
针对这个原型进行讨论，用户提出意见，开发人
员进行修改，直到用户对这个原型满意为止。然
后，以修改好的原型为基础开发软件。
原型方法学是针对传统方法学的缺点而产
生的一种方法学。它们属于系统工程中的两种
不同的方法。
传统方法学属于霍尔的以, 优化, 为核心
的方法学，原型方法学属于切克兰德的以, 比
较、学习, 为核心的方法学 。
传统方法学有一个严格的需求分析过程，需
要准确、完整的需求分析，软件开发成功与否就
建立在需求分析的基础上，然而人类的认识能力
是有限的，对问题的认识不可能一步到位，有个
反复的螺旋上升过程，这就决定了传统方法学不
适合于需求模糊易变的软件开发。
原型方法学没有严格的需求分析阶段，只有
需求验证阶段，在需求阶段反复地与用户勾通，
满足用户的需求，其整个过程就是一个比较、学
习过程，因此原型方法学比较符合人类认识、分
析、理解客观事物的规律。
原型方法学在软件开发早期阶段应是一个学习和
实践过程，它的活动应该包括开发人员和用户两个
方面。
为了使其更有效，不仅要求开发人员要与用户紧
密合作，而且还要有一个实际系统，只有这样才能
获得成功。尽管用户在开始时说不清所要求的未来
软件系统是什么样，但他们却可以对现有系统非常
熟练地进行挑剔。
原型法的主要哲学观点就是允许失败。
面向对象方法学是面向数据同时又面向行为
的一种崭新的软件开发方法学。
它是把数据和行为 (或称为操作 )等同看待，
以数据为主线，把数据和对数据的操作紧密结合
在一起的一种方法。
面向对象方法学的出发点和基本原则是尽可
能模拟人类习惯的思维方式，使开发软件的方法
与过程尽可能接近人类认识世界、解决问题的方
法与过程，从而使描述问题的问题空间与实现的
解空间在结构上尽可能一致。
用面向对象方法学开发软件的过程是一个主动
地多次反复迭代的演化过程，如同喷泉一样。
面向对象方法在概念和表示方法上的一致性保
证了在各项开发活动之间的平滑 (无缝 )过渡。
面向对象方法普遍进行的对象分类过程支持从
特殊到一般的归纳思维过程，通过建立类等级而获
得的继承性支持从一般到特殊的演绎思维过程。
面向对象方法有如下几个特点：
1、对象 (Object)是融合了数据及在数据上的
操作行为的软件构件。对象是用数据来刻划属性
及定义了该属性对象的行为的一个被封装了的模
块。数据用于表示对象的静态属性，是对象的状
态信息，而施加于数据上的操作是用于实现对象
的动态行为。面向对象的程序是由对象组成，程
序中的元素就是对象，复杂的对象由比较简单的
对象组合而成。
2、把对象分类 (Class)。每个类都定义了一
组数据和一组操作，类是对具有相同数据和相同
操作的一组相似对象的定义。对象是类的一个实
例，类是由对象群抽象而得到
3、类有一个“继承”性质。有父类、子
类之分，父类称为基类，子类称为派生类。
子类继承了父类的全部属性和操作。
即，我们可把若干个相似类组成一个层
次结构的系统。在这个结构中，下层派生类
自动拥有上层基类中定义的数据和操作，这
就是继承。
4、封装。对象的数据属性以及对象的操作
(或称行为 )是被封装在一起的，它是进行处理
的主体，其它对象必须向它发送消息请求它执
行它的某个操作，而不能从外界直接对它访问。
这种封装性，很符合软件的信息隐蔽、信息局
部性原则，其独立性很好。
面向对象方法 =对象 +类 +继承 +用消息通信。面
向对象既用对象又用类的继承机制，对象之间通过
传递消息实现彼此通信。当软件规模较大、软件需
求较模糊易变时，传统的方法学往往显得力不从心，
面向对象方法学能起一定的作用，可以简化软件的
开发和维护工作，能提高软件的可重用性。
近年来在许多应用领域中，面向对象方法学已
经取代了传统的方法学，但我们必须清楚地认识到，
面向对象方法学并不是如人们所期望的那样万能，
也有一定的局限性。
明确问题
选择目标
系统综合
系统分析
方案优化
作出决策
付诸实施
霍尔, 优化,
方法流程图
问题现状说明
弄清关联因素
建立概念模型
改善概念模型
比 较
实 施
切克兰德, 调
查学习, 方法
流程图
第三节 常见的几种软件开发模型
模型是为了理解事物而对事物作出的一种抽象，
它忽略了不必要的细节，是事物的一种抽象形式、
一个规划、一个程式。软件开发模型就是描述软件
开发过程中各种活动如何执行的模型。一个强有力
的软件开发模型，为软件开发提供了强有力的支持，
为软件开发过程中所有活动提供了统一的规范保证，
为参与软件开发的所有成员提供帮助和指导。同时
它也揭示了如何演绎软件过程的思想，是软件开发
模型化技术的基础，也是建立软件开发环境的核心。
软件开发模型确立了软件开发和演绎中各阶段
的次序限制，以及各阶段活动的准则，确立了开发
过程所遵守的规定和限制，便于各种活动的协调以
及各种人员的有效通信，有利于活动重用和活动管
理。软件开发模型能表示各种活动的实际工作方式，
各种活动间的同步和制约关系，以及活动的动态特
性。模型应该容易为软件开发过程中的各类人员所
理解，应该适应不同的软件项目，具有较强的灵活
性以及支持软件开发环境的建立。
软件开发模型与开发模式是有区别的，开发模
式指一种开发思想。常见的软件开发模式：结构化
开发模式、原型开发模式、面向对象开发模式及
CASE模式。
常用的软件开发模型：
? 瀑布模型
? 增量模型
? 螺旋模型
? 喷泉模型
? 四代技术
? 变换模型
? 基于知识的模型
? 过程开发模型
瀑布模型
瀑布模型是属于传统的结构化开发模式, 是由
硬件和系统工程派生出来的, 是一种将软件生存
周期各活动阶段规定为依线性顺序联接的, 系统
的和顺序的开发方法 。
它包括可行性分析, 项目开发计划, 需求分
析, 概要设计, 详细设计, 编码, 测试和维护 。
这种模型的实质是面向阶段的, 线性的或传统
的开发策略 。 除了确认和验证外, 其它所有阶段
都是线性执行的, 即每个阶段只有在前一个阶段
完成后才能开始 。
它规定了由前至后、相互衔接的固定次序，
如同瀑布流水，逐级下落。
瀑布模型为软件开发提供了一种有效的管理
模型。根据这一模型制定开发计划，进行成本预
算，组织开发力量,以项目的阶段评审和文档控
制为手段有效地对整个开发过程进行指导。
因此它是以文档作为驱动、适合于需求很明
确的软件项目开发的模型。
需求定义
确认
设计
确认
编码
确认
测试
确认
维护
确认
需求说明书
设计说明书
源程序清单
测试报告
软件维护报告
瀑布模型
该模型说明整个软件开发过程是按图中 5个阶
段进行的。
每个阶段的任务完成之后，产生右边相应的
文档 (图中只列出该阶段最主要的文档 )，这些文
档通过确认后，表明该阶段工作完成，并进入下
一阶段的工作。
每个阶段均以上一阶段的文档作为开发的基
础,如果某一文档出现问题，则要返回到上一
阶段去重新进行工作。
一, 瀑布模型往往会碰到让人头痛的问题 。
例如：
1） 一个活动在项目中出现得越早, 对这个活动的
注释就越不足；
2） 一个活动在项目中出现得越早, 我们对这个活
动的理解就越少；
3） 一个错误在项目中形成越早, 这个错误所造成
的影响就越严重 。
瀑布模型有如下特点：
问题的本质是这种模式是建立在完备的需求分析的基础
上，而需求分析是不可能完备的、准确的。
原因主要是：
1）用户与开发者之间，以及他们之间的交流存在巨大
的文化差异；
2）用户由于不熟悉信息技术，可能提出非常含糊的需
求，而这种需求又可能被开发人员随意解释；
3）经验证明，一旦用户开始使用计算机系统，他们对
目标系统的理解可能又会发生变化，这显然会使原始需求无
效。
用户需求常常是一个变动的目标。由
于知识背景的不同，工作中的疏漏和通讯
媒介的局限性，使通讯中的误解无法避免。
随着项目向前推进，用户会产生新的
要求，或因环境变化希望系统也能随之变
化。
二、瀑布模型要求严格按照生存周期各个阶段的
目标、任务、文档和要求来进行开发。
它强调了每一阶段的严格性，尤其是开发前期的
良好需求说明，这样，就能解决在开发阶段后期因
修正不完善的需求说明而导致巨大费用的问题。
于是人们需要付出极大的努力来加强各阶段活动
的严格性,特别是需求定义阶段，希望得到完整、
准确、无二义性的需求说明，以减少后面各阶段不
易估量的浪费。
在传统的观念中，人们认为只要认真努力，
总可以通过详尽分析来确定完整、准确的需求
说明，从而明确系统的各种需求，只要采用一
套严格规定的术语及表达方式，就一定可以准
确清楚地表达和通讯，在严格的开发管理下得
到完美的结果。
在这种严格定义的模型中, 开发人员试图
在每一活动过程结束后, 通过严格的阶段性复
审与确认, 得到该阶段的一致, 完整, 准确和
无二义性的良好文档, 以, 冻结, 这些文档为
该阶段结束的标志, 保持不变, 作为下一阶段
活动的唯一基础, 从而形成一个理想的线性开
发序列, 以每一步的正确性和完整性来保证最
终系统的质量 。
瀑布模型是以 文档形式 驱动的，为合同双方
最终确认产品规定了蓝本，为管理者进行项目开
发管理提供了基础，为开发过程施加了, 政策,
或纪律限制，约束了开发过程中的活动。瀑布模
型以里程碑开发原则为基础，提供各阶段的检查
点，确保用户需求，满足预算和时间限制。
三, 瀑布模型是一种整体开发模型, 在开
发过程中, 用户看不见系统是什么样, 只有
开发完成向用户提交整个系统时, 用户才能
看到一个完整的系统 。
四, 瀑布模型适合于功能和性能明确, 完整,
无重大变化的软件开发 。
如, 系统软件, 嵌入式软件等就具有这些特征 。
在开发这些系统前均可完整, 准确, 一致和无二
义性地定义其目标, 功能和性能等 。 有人称这类
软件为预先指定系统 。
对于当前的大型软件项目，特别是应用软件项
目，在开发前期用户常常对系统只有一个模糊的
想法，很难明确确定和表达对系统的全面要求，
称这类软件为由 用户驱动软件 。
这类软件经过详细的需求定义，尽管可得到一
份较好的需求说明，但却很难期望该需求说明能
将系统的一切都描述得完整、准确、一致并与实
际环境相符，很难通过它在逻辑上推断出系统的
运行效果，并以此达到各类人员对系统的共同理
解。
因此, 要保证每个阶段特别是定义阶段是正确
的, 完整的, 只是理想情况, 实际上是做不到或
很难做到的 。
开发者也可能在设计中遇到某些未曾预料的实
际困难, 希望能在需求中有所权衡 。 这些都成为
进行严格线性开发的重大障碍, 尽管通过加强复
审与确认, 全面测试和设立维护阶段来缓解上述
困难, 但均未在根本上解决这些问题 。
五, 作为整体开发的瀑布模型, 由于不支持
软件产品的演化, 对开发过程中的一些很难发
现的错误只有在最终产品运行时才能发现 。
瀑布模型缺乏对付变化的机制, 所以最终产
品将难以维护 。
瀑布模型在大量的软件开发实践中也逐渐暴
露出它的严重缺点。
它是一种理想的线性开发模式，缺乏灵活性，
特别是无法解决软件需求不明确或不准确的问题。
这些缺点对软件开发带来了严重影响，最终
可能导致开发出的软件并不是用户真正需要的软
件，并且这一点在开发过程完成后才能发现，
但已为时太晚。
针对这些情况，无疑需要进行返工，或者在运
行中进行大量修改。不管是返工或进行大量修改
都必须付出巨大的代价,给软件开发带来不必要
的损失。
同时，随着软件开发项目的规模日益扩大，瀑
布模型缺乏灵活性的缺点引发的问题更为严重。
为克服瀑布模型的不足，现在已提出若干其他模
型。
增量模型
瀑布模型是一种整体开发模型 。 在开发过程
中, 用户看不到软件是什么样子, 只有开发完成
后, 整个软件才全部展现在用户面前 。 针对它的
这种缺点, 提出了增量模型 。
增量模型属于原型开发模式, 是一种非整体
开发的模型 。 它适合开发那种需求是可变的, 模
糊的以及用户与开发者难以沟通的软件 。
增量模型的基本思想
软件在该模型中是, 逐渐, 开发出来的，开发
出一部分，向用户展示一部分，可让用户及早看到
部分软件,及早发现问题。
或者先开发一个, 原型, 软件，完成部分主要
功能，展示给用户并征求意见,然后逐步完善，
最终获得满意的软件产品。
该模型具有较大的灵活性，适合于软件需求不
明确、设计方案有一定风险的软件项目。
原型模型
计划
需求分析
原型开发
原型评价
最终系统设计
最终系统实现
渐增模型
原型模型
增量构造模型
演化提交模型
探索型模型
实验型模型
演化型模型
增量模型
增量构造模型 是在瀑布模型的基础上，对
一阶段进行整体开发，对另一些阶段进行增
量开发。
演化提交模型 是在瀑布模型的基础上，所
有阶段都进行增量提交式开发，即开发一个
提交一个。
原型模型,又称 快速原型模型 。
在开发真实系统前，构造一个原型，在该原
型的基础上，逐渐完成整个系统的开发任务。
它又可分为探索型原型、实验型原型、演化
型原型。
探索型原型 是把原型法用于开发的需求分析，
目的是弄清楚用户的需求，确定所期望的软件特
征。它适用于对开发目标模糊、用户与开发者对
开发软件都缺乏经验的情况下，通过对原型的开
发、交互来验证需求。
实验型原型 主要用于设计阶段，验证方案是
否合适、能否实现。对于一个大型系统，若对
设计方案心中没有把握时，可通过这种原型来
证实设计方案的正确性。
演化型原型 主要用于及早向用户提交一个原
型系统，该原型系统包含系统的框架，或包含系
统的主要功能，在得到用户的认可后，将原型系
统不断扩充演变为最终的软件系统。
它将原型的思想扩展到软件开发的全过程。
螺旋模型
螺旋模型将瀑布模型与增量模型结合起来,
汲取了这两种模型的优点, 增加了风险分析来弥
补这两种模型的不足 。
螺旋模型将开发过程分为几个螺旋周期, 每
个螺旋周期大致和瀑布模型相符合 。
每个螺旋周期可分为 4 个工作步骤。
第一，制定计划，即确定目标，选定实施方案，
明确开发限制条件；
第二，风险分析，即分析所选方案，识别风险，
通过原型消除风险；
第三，开发实施,即实施软件开发；
第四，用户评估，即评价开发工作，提出修改
意见，建立下一个周期的计划。
螺旋模型
需求计划 操作概念 软件需求
提交部分
确定目标方案
限制条件
费用累加
风险分析
风险分析
风险分析
原型 1 原型 2 原型 3
可操作原型
详细设计
编程
模块
测试组装
测试确认测试运
行
评估方案,标识、解决风险
软件产品
设计
设计验证和确认
需求验证
开发计划
测试计划
集成和
计划下阶段工作
开发验证下一级产品
螺旋模型是一种风险驱动的模型。在软件开发
中，有各种各样的风险。对于不同的软件项目，
其开发风险有大有小。
在制定项目开发计划时，分析员要明确项目的
需求是什么，需要多少资源，如何安排开发进度
等一系列问题。
要给出准确无误的回答是不容易的。分析员通常
凭借经验的估计而给出初步的设想，这难免会带来一
定的风险。
同样，在设计阶段给出的设计方案是否能实现用
户的功能，也会具有一定风险。
实践表明，项目越复杂，设计方案、资源、成本
和进度等因素的不确定性就越大，项目开发的风险也
越大。因此，应该对风险进行识别、分析并采取对策，
从而消除或减少风险的危害。
螺旋模型适合于大型软件的开发，它吸收了软
件工程, 演化, 的概念，使得开发人员和用户对每
个螺旋周期出现的风险有所了解，从而作出相应的
反应。
但是，使用该模型需要有相当丰富的风险评估
经验和专门知识，这使该模型的应用受到一定的限
制。
图形中半径的大小代表了完成现在步骤所需的
费用累加。螺旋角度的大小代表了完成螺旋的每次
循环需做的工作，该模型反映了一个重要的概念，
即每一次循环包含一次进展，该进展对产品的每一
部分及每一级改进都指出了从用户需求文档至每一
单独程序的编程步骤的相同次序。
一, 确定目标, 方案和限制条件 。 确定软件产品各部
分的目标, 如性能, 功能和适应变化的能力等；确定
软件产品各部分实现的各种方案, 选择如 A设计, B
设计, 软件重用和购买等；确定不同方案的限制条件,
如成本, 规模, 接口调度, 资源分析和时间表安排等 。
二, 评估方案, 标识风险和解决风险 。 对各个不同实
现方案进行评估, 对出现的不确定因素进行风险分析,
提出解决风险的策略, 建立相应的原型 。 若原型是可
运行的, 健壮的, 则可作为下一步产品演化的基础 。
螺旋模型的开发步骤：
三, 开发确认产品 。 若以前的原型已解决了所有性能
和用户接口风险, 目前占主要位臵的是程序开发和接
口控制风险, 那么接下来应采用瀑布模型的方法, 进
行用户需求, 软件需求, 软件设计和软件实现等 。 同
时要对其作适当修改, 以适应增量开发 。 也可选择原
型, 模拟原型, 导致了步骤的不同子集的使用 。
四, 计划下一周期工作 。 主要工作包括对下一周期的
软件需求, 软件设计和软件实现进行计划；对部分产
品进行增量开发；或者是由部分组织和个人开发软件
的各个组成部分 。 我们可设想有一系列平行的螺旋循
环, 每一个螺旋循环对应一个组成部分, 好像在图中
加入第三维, 即加入若干重叠的螺旋平面, 不同的螺
旋平面对应于不同的软件组成部分, 以便分别演化 。
与其他模型相似，在螺旋模型中每次循环都以评
审结束，评审涉及产品的原来人员或组织，评审覆
盖前一次循环中所开发的全部产品，包括下一次循
环的计划以及实现它们的资源。
评审的主要任务是确保所有有关部分的质量，以
共同提交给下一阶段。
喷泉模型
喷泉模型是属于面向对象方法学的, 是一种以用
户需求为动力, 以对象作为驱动的模型 。
它适合于面向对象的开发方法 。 它克服了瀑布模
型不支持软件重用和多项开发活动集成的局限性 。 喷
泉模型使开发过程具有迭代性和无间隙性 。 系统某些
部分常常重复工作多次, 相关功能在每次迭代中随之
加入演化的系统 。
无间隙是指在分析, 设计和实现等开发活动之间
不存在明显的边界 。
喷泉模型
实 现
软件设计
系统设计
分 析
喷泉模型的图形如图所示 。 它以面向对象的软
件开发方法学为基础, 以用户需求作为喷泉模型
的源泉 。 其特点如下：
一, 喷泉模型规定软件开发过程有 4 个阶段,
即系统分析, 系统设计, 软件设计和实现 。
二, 喷泉模型的各阶段相互重叠, 它反映了
软件过程并行性的特点 。
三, 喷泉模型以分析为基础, 资源消耗呈塔
型, 在分析阶段消耗的资源最多 。
四, 喷泉模型反映了软件过程迭代的自然特性,
从高层返回低层无资源消耗 。
五, 喷泉模型强调增量开发, 它依据分析一点,
设计一点的原则, 并不要求一个阶段的彻底完成,
整个过程是一个迭代的逐步提炼的过程 。
六, 喷泉模型是对象驱动的过程, 对象是所有
活动作用的实体, 也是项目管理的基本内容 。
四代技术模型
四代技术, 简称 4GT。 4GT拥有一组工具, 它们都
有一个共同的特点, 即每个工具都能使开发人员在高
层次上定义软件的某些特性, 并把开发人员定义的这
些特性自动生成源代码 。
机器如果能在越高层上定义软件, 则程序生成越
快 。 软件工程的 4GT模型能在机器的一定层次上用一种
近似自然的语言或一种能赋予特殊功能的符号来定义
软件 。
目前，支持 4GT模型的软件开发环境的常见的
工具：
数据查询的非过程性语言，报表生成，数据
处理，屏幕交互和定义，代码生成，高层图形功
能和电子表格等。
四代技术模型
需求分析
设计策略
用 4GT实现
测 试
变换模型
变换模型是一种适合于形式化开发方法的
模型 。 从软件需求的形式化说明开始, 经过
一系列变换, 最终得到系统的目标程序 。
变换模型主要用于软件的形式化开发方法 。 一
个形式化的软件开发方法要提供一套思维方法和描
述开发手段, 如规范描述的原则, 程序开发的一般
过程, 描述语言等, 使开发者能利用数学概念和表
示方法恰当合理地构造形式规范, 根据开发过程的
框架及设计原则进行规范描述和系统化的设计,
并对规范的性质和设计的步骤进行分析验证 。
用于软件形式化开发方法的变换模型分为模型
规范的建立和规范实现开发的一系列变换过程。
模型检查
软件需求形式
化说明 (M0) (M2)
软件设计形式
化说明 (M１ )
程序
(Mn)……
变换 变换 变换
一, 建立软件系统的模型规范 。 将对实现环境和
系统的功能需求进行分析, 提出与系统有关的基本概
念和固有属性, 并以此为基础建立问题求解的抽象模
型, 称为模型抽象 。 它由相互关联的两部分组成, 即
表示抽象和运算抽象 。
二, 表示抽象 。 表示抽象是模型规范构造者在分
析求解问题及其实现环境的基础上, 对形成系统可观
察属性的对象域及其组成元素的形式描述 。
三、运算抽象。运算抽象是定义若干运算来模拟
系统中可能发生的事件，即围绕表示抽象给出若干运
算的规范描述。这种描述规定了运算所模拟的事件发
生前后，系统可观察属性的变化关系，即状态转换关
系。
开发过程中注意如下六个问题：
四, 变换过程 。 当软件系统模型规范的构造完成
之后, 进一步开发满足规范的实现系统 。 程序开发过
程应是设计和验证并行的多步精化过程, 对开发的每
一步, 均要慎重考虑该步开发是否正确, 在发现问题
时要及时解决 。 只有这样才能大大减少开发费用, 保
证最终产品的质量和开发效率 。 从抽象模型规范 (M0)
开始的多步开发过程可表示为
M0→M 1→M 2→ … →M n
的变换, 其中, Mi+1是 Mi的实现模型, 变换中的每一步
的, 强度, 都影响到整个变换的强度, 还要论证每个
Mi+1是 Mi的正确实现 。 这种开发过程中的证明推理是以
诸模型的形式化为前提的, 也是保证最终的实现系统
(Mn)正确实现模型规范的必要阶段 。
五, 变换的独立性 。 这种多步变换过程的一个重
要性质是每步变换对相关模型描述是, 封闭的,, 即
每步变换的正确性仅与该步变换所依据的规范 Mi以及
对变换后的假设 (如 Mi+1)有关 。 变换步骤在这种意义
下独立于其他变换步骤 。
假若没有这种独立性, 就无法控制错误的恶性蔓
延, 而变换步骤的经验也就成了一句空话 。
六, 变换的设计 。 变换的设计过程是一种, 发明,
的过程 。 在模型具体化的变换过程中, 具体实现模型
的设计是开发者的职责 。
目前还没有相当高级的规范能自动翻译成高效程
序代码的工具, 这种设计, 发明,, 是以开发者自己
对正在设计中的系统的功能和使用环境的理解, 是对
实现效率及进一步开发的预测等程序设计经验以及对
软件开发基本原则的理解为基础的 。
形式化开发方法仅提供给开发者一种严格有效的
思维工具和描述工具, 而不能代替开发者进行变换的
,发明, 。
1,该模型只适合于软件的形式化开发方法 。
2,必须有严格的数学理论和形式化技术支持 。
3,缺乏相应的支持工具, 处于手工处理方
式 。
4,尚处于研究和实验阶段, 离使用前景尚
有一段距离 。
5,对软件开发人员要求较高 。
变换模型有以下几个的特点：
基于知识的模型
基于知识的模型又称智能模型, 它把瀑布模型和专
家系统结合在一起 。
该模型在开发的各个阶段上都利用了相应的专家系
统来帮助软件人员完成开发工作, 使维护在系统需求
说明一级上进行 。
为此, 该模型建立了各阶段所需要的知识库, 将模
型, 相应领域知识和软件工程知识分别存入数据库,
把在软件工程知识基础上生成规则构成的专家系统,
与含有应用领域知识规则的其他专家系统相结合, 构
成了该应用领域的开发系统 。
基于知识的模型
用户概念
支持需求分
析专家系统
需求分析
概要设计
详细设计
编码
测试
维护
支持设计
专家系统
支持测试
专家系统
支持维护
专家系统
一, 支持需求活动的专家系统 。 支持需求活动的专
家系统用来帮助减少需求活动中的二义性, 不精确性
和冲突易变的需求 。 这种专家系统要使用应用领域的
知识, 要用到应用系统中的规则, 建立应用领域的专
家系统来支持需求活动 。
二、支持设计活动的专家系统。支持设计活动的专
家系统用于支持设计功能的 CASE中的工具和文档的选
择，这种专家系统要使用软件开发的知识。
在各阶段都有相应的专家系统支持
三, 支持测试活动的专家系统 。 支持测试活动
的专家系统用于支持测试自动化, 利用基于知识
的系统选择测试工具, 生成测试数据, 跟踪测试
过程, 分析测试结果 。
四、支持维护活动的专家系统。支持维护活动
的专家系统将维护变成新的应用开发过程的重复，
知识模型以瀑布模型与专家系统的综合应
用为基础 。 该模型通过应用系统的知识和规则
帮助设计者认识一个特定软件的需求和设计,
这些专家系统已成为开发过程的伙伴, 并指导
开发过程 。
将软件工程知识从特定领域分离出来，这些知识
随着过程范例收入知识库，产生规则，在接受软件工
程技术的基础上被编码成专家系统，用来辅助软件工
程的开发。
在使用过程中，软件工程专家系统与其他领域的
应用知识的专家系统连接起来，形成了特定软件系统，
为开发一个软件产品所应用。
知识模型的优点如下：
1,通过领域的专家系统, 可使需求说明更完整,
准确和无二义性 。
2,通过软件工程专家系统, 提供一个设计库支
持, 在开发过程中成为设计者的助手 。
3,通过软件工程知识和特定应用领域的知识和
规则的应用来提供开发的帮助 。
知识模型的缺点如下：
1,建立适合于软件设计的专家系统是非常困难
的, 超出了目前的能力, 是今后软件工程的发展
方向, 要经过相当长的时间才能取得进展 。
2,建立一个既适合软件工程又适合应用领域的
知识库也是非常困难的 。
3,目前的状况是在软件开发中正在应用 AI技术,
在 CASE工具系统中使用专家系统, 用专家系统来
实现测试自动化, 这只在软件开发的局部阶段有
所进展 。
过程开发模型
又称混合模型, 或称元模型 。 近几年来, 为了
克服瀑布模型式模型的种种缺陷, 出现了很多开发
模型 。 但是, 这些开发模型仍被限制在整个项目开
发按定义所确定的阶段性的系统开发方向上 。 解决
这一问题的方法之一是把几种模型组合为一种混合
模型 。 这种思想属于问题导向方法论 。
瀑布式 给了人们一种软件开发过程的概念，即一
个项目要经过需求分析、设计、实现、测试和维护等
阶段的一系列软件工程活动。
原型模型 是在需求分析阶段生成的原型上开发系
统。
螺旋模型 则把开发分为计划、风险、工程和用户
评价四个阶段。
4GT就其本质来看更像是开发方法和工具，而不是
具体模型。
OO开发与传统的结构化生存期比较，具有更多
的递增和迭代性质，生存期的各个阶段可以相互重
叠和多次反复，而在项目的整个生存期中还可以嵌
入子生存期。所以有人称 OO生存期为喷泉模型，就
像水喷上去落下来，可以落在中间，也可以落在最
底部。
变换模型 是一种属于形式化开发方法的模型。
知识模型 是把瀑布模型和专家系统结合在一起。
在开发的各个阶段上都利用了相应的专家系统来
帮助软件人员完成开发工作，使维护在系统需求
说明一级上进行。
以上这些方法看起来十分严谨, 但实际上很少完
全按上述过程一步一步的进行 。 这是因为任何一个项
目的开发决定于许多因素, 如软件的应用领域, 规模
大小, 可重用构件的大小和多少, 软件实现的硬软环
境, 开始和交付的规定等 。 这就需要一种更为灵活和
更加动态的方法 。
在 1985年美国国防部软件研究所提出了混合模型 。
它是根据具体的项目问题, 制定开发策略 。
混合模型有多种开发方法, 提供了一种适合
于各种具体系统, 环境或机构的灵活的结构 。
它的好处是：项目管理人员无疑不愿意在工
作中没有某种构思的框架就去进行一个项目的开
发 。 联合几种模型构成一种混合模型, 给管理人
员提供了在具体操作中使用结构框架的某种形式 。
这样就可以使每个模型的长处得到充分的发挥 。
所有项目都始于一些初始的想法, 在混合模型
中称之为构思 。
一个项目有了构思, 预计划就有了确定的过程
方向 。 混合模型允许管理人员按照当前项目的情况,
指导项目构造一种开发方法 。 由于混合模型结构中
的不确定性, 管理人员在一开始不必去决定完成开
发过程的方向 。
需要在基于项目的情况, 确定项目的决策点,
管理人员可在项目的生存期内做出决策, 当一个项
目的环境完全不同于开始时, 早决策不如晚些时候
决策好 。
过程开发模型对开发人员的要求是比较高的,
开发人员不仅要有扎实的软件工程理论基础, 而
且要有丰富的软件项目开发经验 。
习 题
1,什么是软件工程？ 软件工程产生的背景是什么？
2,什么是软件工具和软件环境？ 它们有什么区别？
3,软件工程开发软件有哪些基本模式？ 它们有什
么特点？ 其适用范围是什么？
4,常用软件工程的开发模型有哪些？
5,过程开发模型的方法论基础是什么？
6,软件工程的基本目标是什么？ 怎样做才能达能
理想的程度？
第一节 软件工程定义
第二节 软件工程方法
第三节 常见的几种软件开发模型
第一节 软件工程的定义
一,软件工程的定义
二,软件工程的性质
三,软件工程的目标
四,软件工程的研究内容
一、软件工程的定义
软件工程思想是 20世纪 60年代末提出的,70
年代以后逐步发展起来的一门指导计算机软件开发
和维护的工程科学。
采用工程的概念、原理、技术和方法来开发
与维护软件，把经过时间考验而证明正确的管理技
术和当前能够得到的最好的技术方法结合起来，这
就是软件工程。
这门学科的目的是研究如何从管理和技术两
方面更好地开发和维护计算机软件。
1968年在联邦德国召开的国际会议上正
式提出并使用了, 软件工程, 这个术语，运
用工程学的基本原理和方法来组织和管理软
件生产。
后来还发展了与软件有关的心理学、生
理学和经济学等方面的学科。
在这个期间，研究软件工程的专家学者
们陆续提出了 100多条关于软件工程的准则。
这 100多条准则可以概括为下述 6条基本原则。
6条基本原则。
1,用分阶段的生存周期计划严格管理
2,坚持阶段评审
3,实行严格的产品控制
4,采用现代程序设计技术
5,能非常清楚地审查结果
6,合理安排软件开发小组人员
仅遵循以上 6 条，一成不变是不够的，软件
工程本身就是一项实践工程。随着计算机系统的
发展，必须不断地灵活地改进软件工程的实践。
这就必须积极主动地采用新的软件技术，注意不
断地总结经验，不断地有条件地进行继承和扬弃，
不断地认识未知和演变地处理未知，推进软件工
程的发展。
二、软件工程的性质
软件工程涉及到计算机科学、工程
科学、管理科学、经济学和数学等领域，
是一门综合性的交叉学科。
计算机科学中的所有学科的知识都可应用于
软件工程，特别是计算机专业的本科生，通过计
算机科学与技术专业的课程学习，有了较扎实的
理论基础，软件工程将给予你一个计算机知识综
合应用的工程概念，会让你所学的计算机学科知
识起到一个画龙点睛的作用。有了软件工程思想
方法，应用所学的计算机知识，就知道如何建造
一个软件系统。
软件工程要用工程科学中的思想、观点来
进行软件项目规划、经费估算、制定项目进度、
制定项目计划和制定项目开发方案；用管理科
学、经济学的思想和方法对软件项目进行管理、
成本核算、投入产出分析；用数学的方法建立
软件项目开发过程中的各种模型和各种算法，
进行正确性、可靠性分析，建立用户需求的形
式化模型等。
三、软件工程的目标
? 有较低的开发成本。
? 能达到用户所要求的软件功能。
? 有很好的软件性能。
? 软件有较好的可移植性、稳定性、健壮性
和可靠性。
? 有较好的可维护性，较低的维护成本。
? 能按计划规定的进度开发，及时交付使用。
软件工程是一门工程性的学科，软件工程
的目的是成功地构造一个大型软件系统。所谓
成功是指达到以下标准：
软件产品是把思维、概念、算法、组织、
流程、效率、质量、成本等多方面的问题融为
一体的产品，它不同于一般意义上的工程开发
与管理，必须通过人员组织管理、项目计划管
理和配臵管理来保证软件的高质量完成。软件
的交付使用也不同于一般意义上的工程项目交
付使用，软件的交付使用必须将软件的思想方
法渗透到组织、人员中去。从这个意义上看，
软件工程目标的内涵是十分丰富多彩的。
四、软件工程的研究内容
软件工程是计算机领域的一个较大的研究方向，其内
容十分丰富，包括：理论、结构、方法、工具、环境、管理、
经济、规范等。
软件工程理论与结构是软件开发的技术基础，包括程
序正确性证明理论、软件可靠性理论、软件成本估算模型、
软件开发模型、模块划分原理等。
软件开发技术包括软件开发方法学、软件工具和软件
开发环境，良好的软件工具可促进方法的研制，而先进的软
件开发方法能改进工具，软件工具集成软件开发环境。软件
开发方法、工具和环境是相互作用的。
软件工具一般是指为了支持软件人员开发和维护
活动而使用的软件。
例如，项目估算工具、需求分析工具、设计工具、
编码工具、测试工具和维护工具等。
使用了软件工具后，可大大提高软件生产率。机
械工具可以放大人类的体力，软件工具可以放大人类
的智力。
最初的软件工具是以工具箱的形式出现的，一种
工具支持一种开发活动，然后将各种工具简单组合起
来。 这类工具箱的工具界面不统一，工具内部无联系，
工具切换由人工操作。
工具箱主要由八类工具组成：
1,业务系统规划工具。
2,项目管理工具。 有效地估算软件项目所
需的工作量、成本和研制周期。
3,支持工具。 用于支持软件工程过程，有
文档编制工具、系统软件工具、质量保证
工具、数据库管理工具、软件配臵管理工
具。
4,分析和设计工具。
5,编程工具。编译器、编辑器、调试器（如
4GL）。
6,测试与分析工具。常用的测试与分析工具。
7,原型工具。
8,维护工具。
由于工具箱存在的问题，人们在工具系统的整
体化及集成化方法上展开了一系列研究工作，使
之形成完整的软件开发环境。其目的是使软件工
具支持整个生存周期。它不仅能支持软件开发和
维护中的个别阶段，而且能够支持从项目开发计
划、需求分析、设计、编码、测试到维护等所有
阶段，做到不仅支持各阶段中的技术工作，还支
持管理和操作工作，保证项目开发的高度可预见
性、可控制性和可追踪性。
软件开发环境是指全面支持软件开发全过程
的软件工具集合，主要体现在三个级别上：
程序设计环境、系统合成环境、项目管理环
境。
如，以语言为中心的环境、面向结构的环境、
工具箱环境、基于方法的环境及计算机辅助软件
（ CASE）。
软件管理技术是实现开发质量的保证。
软件工程管理包括软件开发管理和软件经济
管理。
软件开发管理包括软件开发规划的制定、
人员的组成、制定计划、确定软件标准与配
臵。
软件经济管理主要指成本估算、效益评
价、风险分析、投资回收计划、质量评价等。
软件工程学的最终目的是研究开发以较少的
投入获得易维护、易理解、可靠性高的软件产品。
所以软件工程学就必须研究软件结构、软件设计
与开发方法、软件的维护方法、软件工具与开发
环境、软件工程的标准与规范、软件工程经济学
以及软件开发技术与管理技术的相关理论。
软件工程
软件开发技术
软件工程管理
软件开发方法
软件开发工具
软件开发环境
软件开发管理
软件心理学
软件工程经济学
第二节 软件工程方法
软件工程是系统工程概念、思想、
方法在软件开发和维护中的具体体现，
是由系统工程派生出来的。系统工程就
是把组织 管理 与 技术 管理相结合，软件
工程也是将软件开发的管理与技术紧密
结合的学科。
所谓 管理 是指通过计划、组织、领导、控制
和创新等一系列活动，合理地配臵和使用各种资
源，以达到既定目标的过程。
技术 是指在软件生命周期的全过程中使用的
一整套技术的集合。
技术由各种方法组成，方法又称范型。
? 方法
? 语言
? 工具
? 过程
软件工程方法学包括四个要素：
方法提供如何构造软件的技术。包括与
项目有关的计算和各种估算，系统和软件需求
分析，数据结构设计，程序体系结构，算法过
程，编码，测试和维护等。软件工程方法通常
引入多种专用的图形符号以及一套软件质量的
准则。方法是解决如何做的问题。
语言用以支持软件的分析、设计和实现。随着
编译程序和软件技术的完善，传统的编程语言表
述能力更强，更加灵活，而且支持过程实现更加
抽象的描述。与此同时，规格说明语言和设计语
言也开始有更大的可执行子集。
现在还发展了原型开发语言、面向对象语言。
原型开发语言除必须具有执行的能力外，还必须
有规格说明和设计这两种语言能力。
工具为方法和语言提供了自动化或半自动化的软
件支持环境。
今天，工具可以支持上面提到的任一种方法和语
言。当这些工具集成起来，由一个工具产生的信息可
以被另一个工具使用时，就形成了一个支持软件开发
的系统。这个系统我们称之为计算机辅助软件工程系
统 (Computer-Aided Software Engineering)，简称
CASE。 CASE把软件、硬件、软件工程数据库 (包括分析、
设计、编码和测试重要信息的数据结构 )组成一个软件
工程环境，类似于硬件的计算机辅助设计 /计算机辅助
工程 (CAD/CAE)。
过程是粘结剂，把方法、语言和工具粘结在一
起，它能使计算机软件开发理性化和适时化。
过程定义了方法使用的顺序、可交付产品 (文
档、报告以及格式等 )的要求以及帮助确保质量和
变更的控制，使软件管理人员能对它们的进展进
行评价。
过程是为了获得高质量的软件所需要完成的一
系列任务的框架，它规定了完成各项任务的工作
步骤。
这些工作步骤通常叫作软件工程模式，软件
工程模式是根据项目和应用的性质、方法、语言、
工具的使用、控制和可交付产品的要求来选择的。
是软件工程方法研究的主要内容。目前使用最广泛
的工程方法学是：
? 生命周期方法学
? 原型方法学
? 面向对象方法学
生命周期方法学，也称传统方法学，或称
结构化方法学。它采用结构化技术来完成软件
开发的任务，在其过程中使用适当的软件工具
或软件环境来支撑结构化技术的运用。
所谓结构化技术包括：
结构化分析、结构化设计、结构化程序设计
和结构化测试。
这种方法学把软件生命周期的全过程依次划
分为任务相对独立、相对简单的若干个阶段，
然后顺序地完成每个阶段的任务。
从对任务的抽象逻辑开始，一个阶段一个阶
段地顺序开发，前一个阶段的完成是后阶段开始
的前提和基础，后一阶段的完成通常是使前一阶
段提出的算法更进一步具体化，增加了更多的实
现细节。每一个阶段结束之前都必须进行正式的
技术审查和管理复审，从技术和管理两方面对这
个阶段的开发成果进行检查，通过这个阶段才算
结束；如果不通过，则必须进行必要的返工，并
且返工后还要再经过审查。
审查的一条主要标准就是每个阶段都应该
交出与所开发的软件相一致的文档资料，保证
在软件开发结束时有一个完整准确的软件配臵
交付使用。
在进行生命周期的每个阶段的任务时，应
该采用适合该阶段任务特点的系统化的技术，
即结构化分析、结构化设计、结构化程序设计
和结构化测试技术。
这种传统的软件开发方法，是面向过程的 (或说
是面向行为的 )。
其优点是开发的软件整体性较强。
缺点是软件开发的成功率较低，对需求分析的
要求很高，维护很困难。
它适合开发功能和性能预先知道的软件，如系
统软件、嵌入式软件、实时控制系统等。而对于一
些功能和性能事先不太明确的软件，开发的成功率
较低。
目前，这种传统的软件开发方法仍然广泛使用。
原型方法学是根据简单的用户需求，用软件
工具快速生成软件原型 (模型 )，用户与开发人员
针对这个原型进行讨论，用户提出意见，开发人
员进行修改，直到用户对这个原型满意为止。然
后，以修改好的原型为基础开发软件。
原型方法学是针对传统方法学的缺点而产
生的一种方法学。它们属于系统工程中的两种
不同的方法。
传统方法学属于霍尔的以, 优化, 为核心
的方法学，原型方法学属于切克兰德的以, 比
较、学习, 为核心的方法学 。
传统方法学有一个严格的需求分析过程，需
要准确、完整的需求分析，软件开发成功与否就
建立在需求分析的基础上，然而人类的认识能力
是有限的，对问题的认识不可能一步到位，有个
反复的螺旋上升过程，这就决定了传统方法学不
适合于需求模糊易变的软件开发。
原型方法学没有严格的需求分析阶段，只有
需求验证阶段，在需求阶段反复地与用户勾通，
满足用户的需求，其整个过程就是一个比较、学
习过程，因此原型方法学比较符合人类认识、分
析、理解客观事物的规律。
原型方法学在软件开发早期阶段应是一个学习和
实践过程，它的活动应该包括开发人员和用户两个
方面。
为了使其更有效，不仅要求开发人员要与用户紧
密合作，而且还要有一个实际系统，只有这样才能
获得成功。尽管用户在开始时说不清所要求的未来
软件系统是什么样，但他们却可以对现有系统非常
熟练地进行挑剔。
原型法的主要哲学观点就是允许失败。
面向对象方法学是面向数据同时又面向行为
的一种崭新的软件开发方法学。
它是把数据和行为 (或称为操作 )等同看待，
以数据为主线，把数据和对数据的操作紧密结合
在一起的一种方法。
面向对象方法学的出发点和基本原则是尽可
能模拟人类习惯的思维方式，使开发软件的方法
与过程尽可能接近人类认识世界、解决问题的方
法与过程，从而使描述问题的问题空间与实现的
解空间在结构上尽可能一致。
用面向对象方法学开发软件的过程是一个主动
地多次反复迭代的演化过程，如同喷泉一样。
面向对象方法在概念和表示方法上的一致性保
证了在各项开发活动之间的平滑 (无缝 )过渡。
面向对象方法普遍进行的对象分类过程支持从
特殊到一般的归纳思维过程，通过建立类等级而获
得的继承性支持从一般到特殊的演绎思维过程。
面向对象方法有如下几个特点：
1、对象 (Object)是融合了数据及在数据上的
操作行为的软件构件。对象是用数据来刻划属性
及定义了该属性对象的行为的一个被封装了的模
块。数据用于表示对象的静态属性，是对象的状
态信息，而施加于数据上的操作是用于实现对象
的动态行为。面向对象的程序是由对象组成，程
序中的元素就是对象，复杂的对象由比较简单的
对象组合而成。
2、把对象分类 (Class)。每个类都定义了一
组数据和一组操作，类是对具有相同数据和相同
操作的一组相似对象的定义。对象是类的一个实
例，类是由对象群抽象而得到
3、类有一个“继承”性质。有父类、子
类之分，父类称为基类，子类称为派生类。
子类继承了父类的全部属性和操作。
即，我们可把若干个相似类组成一个层
次结构的系统。在这个结构中，下层派生类
自动拥有上层基类中定义的数据和操作，这
就是继承。
4、封装。对象的数据属性以及对象的操作
(或称行为 )是被封装在一起的，它是进行处理
的主体，其它对象必须向它发送消息请求它执
行它的某个操作，而不能从外界直接对它访问。
这种封装性，很符合软件的信息隐蔽、信息局
部性原则，其独立性很好。
面向对象方法 =对象 +类 +继承 +用消息通信。面
向对象既用对象又用类的继承机制，对象之间通过
传递消息实现彼此通信。当软件规模较大、软件需
求较模糊易变时，传统的方法学往往显得力不从心，
面向对象方法学能起一定的作用，可以简化软件的
开发和维护工作，能提高软件的可重用性。
近年来在许多应用领域中，面向对象方法学已
经取代了传统的方法学，但我们必须清楚地认识到，
面向对象方法学并不是如人们所期望的那样万能，
也有一定的局限性。
明确问题
选择目标
系统综合
系统分析
方案优化
作出决策
付诸实施
霍尔, 优化,
方法流程图
问题现状说明
弄清关联因素
建立概念模型
改善概念模型
比 较
实 施
切克兰德, 调
查学习, 方法
流程图
第三节 常见的几种软件开发模型
模型是为了理解事物而对事物作出的一种抽象，
它忽略了不必要的细节，是事物的一种抽象形式、
一个规划、一个程式。软件开发模型就是描述软件
开发过程中各种活动如何执行的模型。一个强有力
的软件开发模型，为软件开发提供了强有力的支持，
为软件开发过程中所有活动提供了统一的规范保证，
为参与软件开发的所有成员提供帮助和指导。同时
它也揭示了如何演绎软件过程的思想，是软件开发
模型化技术的基础，也是建立软件开发环境的核心。
软件开发模型确立了软件开发和演绎中各阶段
的次序限制，以及各阶段活动的准则，确立了开发
过程所遵守的规定和限制，便于各种活动的协调以
及各种人员的有效通信，有利于活动重用和活动管
理。软件开发模型能表示各种活动的实际工作方式，
各种活动间的同步和制约关系，以及活动的动态特
性。模型应该容易为软件开发过程中的各类人员所
理解，应该适应不同的软件项目，具有较强的灵活
性以及支持软件开发环境的建立。
软件开发模型与开发模式是有区别的，开发模
式指一种开发思想。常见的软件开发模式：结构化
开发模式、原型开发模式、面向对象开发模式及
CASE模式。
常用的软件开发模型：
? 瀑布模型
? 增量模型
? 螺旋模型
? 喷泉模型
? 四代技术
? 变换模型
? 基于知识的模型
? 过程开发模型
瀑布模型
瀑布模型是属于传统的结构化开发模式, 是由
硬件和系统工程派生出来的, 是一种将软件生存
周期各活动阶段规定为依线性顺序联接的, 系统
的和顺序的开发方法 。
它包括可行性分析, 项目开发计划, 需求分
析, 概要设计, 详细设计, 编码, 测试和维护 。
这种模型的实质是面向阶段的, 线性的或传统
的开发策略 。 除了确认和验证外, 其它所有阶段
都是线性执行的, 即每个阶段只有在前一个阶段
完成后才能开始 。
它规定了由前至后、相互衔接的固定次序，
如同瀑布流水，逐级下落。
瀑布模型为软件开发提供了一种有效的管理
模型。根据这一模型制定开发计划，进行成本预
算，组织开发力量,以项目的阶段评审和文档控
制为手段有效地对整个开发过程进行指导。
因此它是以文档作为驱动、适合于需求很明
确的软件项目开发的模型。
需求定义
确认
设计
确认
编码
确认
测试
确认
维护
确认
需求说明书
设计说明书
源程序清单
测试报告
软件维护报告
瀑布模型
该模型说明整个软件开发过程是按图中 5个阶
段进行的。
每个阶段的任务完成之后，产生右边相应的
文档 (图中只列出该阶段最主要的文档 )，这些文
档通过确认后，表明该阶段工作完成，并进入下
一阶段的工作。
每个阶段均以上一阶段的文档作为开发的基
础,如果某一文档出现问题，则要返回到上一
阶段去重新进行工作。
一, 瀑布模型往往会碰到让人头痛的问题 。
例如：
1） 一个活动在项目中出现得越早, 对这个活动的
注释就越不足；
2） 一个活动在项目中出现得越早, 我们对这个活
动的理解就越少；
3） 一个错误在项目中形成越早, 这个错误所造成
的影响就越严重 。
瀑布模型有如下特点：
问题的本质是这种模式是建立在完备的需求分析的基础
上，而需求分析是不可能完备的、准确的。
原因主要是：
1）用户与开发者之间，以及他们之间的交流存在巨大
的文化差异；
2）用户由于不熟悉信息技术，可能提出非常含糊的需
求，而这种需求又可能被开发人员随意解释；
3）经验证明，一旦用户开始使用计算机系统，他们对
目标系统的理解可能又会发生变化，这显然会使原始需求无
效。
用户需求常常是一个变动的目标。由
于知识背景的不同，工作中的疏漏和通讯
媒介的局限性，使通讯中的误解无法避免。
随着项目向前推进，用户会产生新的
要求，或因环境变化希望系统也能随之变
化。
二、瀑布模型要求严格按照生存周期各个阶段的
目标、任务、文档和要求来进行开发。
它强调了每一阶段的严格性，尤其是开发前期的
良好需求说明，这样，就能解决在开发阶段后期因
修正不完善的需求说明而导致巨大费用的问题。
于是人们需要付出极大的努力来加强各阶段活动
的严格性,特别是需求定义阶段，希望得到完整、
准确、无二义性的需求说明，以减少后面各阶段不
易估量的浪费。
在传统的观念中，人们认为只要认真努力，
总可以通过详尽分析来确定完整、准确的需求
说明，从而明确系统的各种需求，只要采用一
套严格规定的术语及表达方式，就一定可以准
确清楚地表达和通讯，在严格的开发管理下得
到完美的结果。
在这种严格定义的模型中, 开发人员试图
在每一活动过程结束后, 通过严格的阶段性复
审与确认, 得到该阶段的一致, 完整, 准确和
无二义性的良好文档, 以, 冻结, 这些文档为
该阶段结束的标志, 保持不变, 作为下一阶段
活动的唯一基础, 从而形成一个理想的线性开
发序列, 以每一步的正确性和完整性来保证最
终系统的质量 。
瀑布模型是以 文档形式 驱动的，为合同双方
最终确认产品规定了蓝本，为管理者进行项目开
发管理提供了基础，为开发过程施加了, 政策,
或纪律限制，约束了开发过程中的活动。瀑布模
型以里程碑开发原则为基础，提供各阶段的检查
点，确保用户需求，满足预算和时间限制。
三, 瀑布模型是一种整体开发模型, 在开
发过程中, 用户看不见系统是什么样, 只有
开发完成向用户提交整个系统时, 用户才能
看到一个完整的系统 。
四, 瀑布模型适合于功能和性能明确, 完整,
无重大变化的软件开发 。
如, 系统软件, 嵌入式软件等就具有这些特征 。
在开发这些系统前均可完整, 准确, 一致和无二
义性地定义其目标, 功能和性能等 。 有人称这类
软件为预先指定系统 。
对于当前的大型软件项目，特别是应用软件项
目，在开发前期用户常常对系统只有一个模糊的
想法，很难明确确定和表达对系统的全面要求，
称这类软件为由 用户驱动软件 。
这类软件经过详细的需求定义，尽管可得到一
份较好的需求说明，但却很难期望该需求说明能
将系统的一切都描述得完整、准确、一致并与实
际环境相符，很难通过它在逻辑上推断出系统的
运行效果，并以此达到各类人员对系统的共同理
解。
因此, 要保证每个阶段特别是定义阶段是正确
的, 完整的, 只是理想情况, 实际上是做不到或
很难做到的 。
开发者也可能在设计中遇到某些未曾预料的实
际困难, 希望能在需求中有所权衡 。 这些都成为
进行严格线性开发的重大障碍, 尽管通过加强复
审与确认, 全面测试和设立维护阶段来缓解上述
困难, 但均未在根本上解决这些问题 。
五, 作为整体开发的瀑布模型, 由于不支持
软件产品的演化, 对开发过程中的一些很难发
现的错误只有在最终产品运行时才能发现 。
瀑布模型缺乏对付变化的机制, 所以最终产
品将难以维护 。
瀑布模型在大量的软件开发实践中也逐渐暴
露出它的严重缺点。
它是一种理想的线性开发模式，缺乏灵活性，
特别是无法解决软件需求不明确或不准确的问题。
这些缺点对软件开发带来了严重影响，最终
可能导致开发出的软件并不是用户真正需要的软
件，并且这一点在开发过程完成后才能发现，
但已为时太晚。
针对这些情况，无疑需要进行返工，或者在运
行中进行大量修改。不管是返工或进行大量修改
都必须付出巨大的代价,给软件开发带来不必要
的损失。
同时，随着软件开发项目的规模日益扩大，瀑
布模型缺乏灵活性的缺点引发的问题更为严重。
为克服瀑布模型的不足，现在已提出若干其他模
型。
增量模型
瀑布模型是一种整体开发模型 。 在开发过程
中, 用户看不到软件是什么样子, 只有开发完成
后, 整个软件才全部展现在用户面前 。 针对它的
这种缺点, 提出了增量模型 。
增量模型属于原型开发模式, 是一种非整体
开发的模型 。 它适合开发那种需求是可变的, 模
糊的以及用户与开发者难以沟通的软件 。
增量模型的基本思想
软件在该模型中是, 逐渐, 开发出来的，开发
出一部分，向用户展示一部分，可让用户及早看到
部分软件,及早发现问题。
或者先开发一个, 原型, 软件，完成部分主要
功能，展示给用户并征求意见,然后逐步完善，
最终获得满意的软件产品。
该模型具有较大的灵活性，适合于软件需求不
明确、设计方案有一定风险的软件项目。
原型模型
计划
需求分析
原型开发
原型评价
最终系统设计
最终系统实现
渐增模型
原型模型
增量构造模型
演化提交模型
探索型模型
实验型模型
演化型模型
增量模型
增量构造模型 是在瀑布模型的基础上，对
一阶段进行整体开发，对另一些阶段进行增
量开发。
演化提交模型 是在瀑布模型的基础上，所
有阶段都进行增量提交式开发，即开发一个
提交一个。
原型模型,又称 快速原型模型 。
在开发真实系统前，构造一个原型，在该原
型的基础上，逐渐完成整个系统的开发任务。
它又可分为探索型原型、实验型原型、演化
型原型。
探索型原型 是把原型法用于开发的需求分析，
目的是弄清楚用户的需求，确定所期望的软件特
征。它适用于对开发目标模糊、用户与开发者对
开发软件都缺乏经验的情况下，通过对原型的开
发、交互来验证需求。
实验型原型 主要用于设计阶段，验证方案是
否合适、能否实现。对于一个大型系统，若对
设计方案心中没有把握时，可通过这种原型来
证实设计方案的正确性。
演化型原型 主要用于及早向用户提交一个原
型系统，该原型系统包含系统的框架，或包含系
统的主要功能，在得到用户的认可后，将原型系
统不断扩充演变为最终的软件系统。
它将原型的思想扩展到软件开发的全过程。
螺旋模型
螺旋模型将瀑布模型与增量模型结合起来,
汲取了这两种模型的优点, 增加了风险分析来弥
补这两种模型的不足 。
螺旋模型将开发过程分为几个螺旋周期, 每
个螺旋周期大致和瀑布模型相符合 。
每个螺旋周期可分为 4 个工作步骤。
第一，制定计划，即确定目标，选定实施方案，
明确开发限制条件；
第二，风险分析，即分析所选方案，识别风险，
通过原型消除风险；
第三，开发实施,即实施软件开发；
第四，用户评估，即评价开发工作，提出修改
意见，建立下一个周期的计划。
螺旋模型
需求计划 操作概念 软件需求
提交部分
确定目标方案
限制条件
费用累加
风险分析
风险分析
风险分析
原型 1 原型 2 原型 3
可操作原型
详细设计
编程
模块
测试组装
测试确认测试运
行
评估方案,标识、解决风险
软件产品
设计
设计验证和确认
需求验证
开发计划
测试计划
集成和
计划下阶段工作
开发验证下一级产品
螺旋模型是一种风险驱动的模型。在软件开发
中，有各种各样的风险。对于不同的软件项目，
其开发风险有大有小。
在制定项目开发计划时，分析员要明确项目的
需求是什么，需要多少资源，如何安排开发进度
等一系列问题。
要给出准确无误的回答是不容易的。分析员通常
凭借经验的估计而给出初步的设想，这难免会带来一
定的风险。
同样，在设计阶段给出的设计方案是否能实现用
户的功能，也会具有一定风险。
实践表明，项目越复杂，设计方案、资源、成本
和进度等因素的不确定性就越大，项目开发的风险也
越大。因此，应该对风险进行识别、分析并采取对策，
从而消除或减少风险的危害。
螺旋模型适合于大型软件的开发，它吸收了软
件工程, 演化, 的概念，使得开发人员和用户对每
个螺旋周期出现的风险有所了解，从而作出相应的
反应。
但是，使用该模型需要有相当丰富的风险评估
经验和专门知识，这使该模型的应用受到一定的限
制。
图形中半径的大小代表了完成现在步骤所需的
费用累加。螺旋角度的大小代表了完成螺旋的每次
循环需做的工作，该模型反映了一个重要的概念，
即每一次循环包含一次进展，该进展对产品的每一
部分及每一级改进都指出了从用户需求文档至每一
单独程序的编程步骤的相同次序。
一, 确定目标, 方案和限制条件 。 确定软件产品各部
分的目标, 如性能, 功能和适应变化的能力等；确定
软件产品各部分实现的各种方案, 选择如 A设计, B
设计, 软件重用和购买等；确定不同方案的限制条件,
如成本, 规模, 接口调度, 资源分析和时间表安排等 。
二, 评估方案, 标识风险和解决风险 。 对各个不同实
现方案进行评估, 对出现的不确定因素进行风险分析,
提出解决风险的策略, 建立相应的原型 。 若原型是可
运行的, 健壮的, 则可作为下一步产品演化的基础 。
螺旋模型的开发步骤：
三, 开发确认产品 。 若以前的原型已解决了所有性能
和用户接口风险, 目前占主要位臵的是程序开发和接
口控制风险, 那么接下来应采用瀑布模型的方法, 进
行用户需求, 软件需求, 软件设计和软件实现等 。 同
时要对其作适当修改, 以适应增量开发 。 也可选择原
型, 模拟原型, 导致了步骤的不同子集的使用 。
四, 计划下一周期工作 。 主要工作包括对下一周期的
软件需求, 软件设计和软件实现进行计划；对部分产
品进行增量开发；或者是由部分组织和个人开发软件
的各个组成部分 。 我们可设想有一系列平行的螺旋循
环, 每一个螺旋循环对应一个组成部分, 好像在图中
加入第三维, 即加入若干重叠的螺旋平面, 不同的螺
旋平面对应于不同的软件组成部分, 以便分别演化 。
与其他模型相似，在螺旋模型中每次循环都以评
审结束，评审涉及产品的原来人员或组织，评审覆
盖前一次循环中所开发的全部产品，包括下一次循
环的计划以及实现它们的资源。
评审的主要任务是确保所有有关部分的质量，以
共同提交给下一阶段。
喷泉模型
喷泉模型是属于面向对象方法学的, 是一种以用
户需求为动力, 以对象作为驱动的模型 。
它适合于面向对象的开发方法 。 它克服了瀑布模
型不支持软件重用和多项开发活动集成的局限性 。 喷
泉模型使开发过程具有迭代性和无间隙性 。 系统某些
部分常常重复工作多次, 相关功能在每次迭代中随之
加入演化的系统 。
无间隙是指在分析, 设计和实现等开发活动之间
不存在明显的边界 。
喷泉模型
实 现
软件设计
系统设计
分 析
喷泉模型的图形如图所示 。 它以面向对象的软
件开发方法学为基础, 以用户需求作为喷泉模型
的源泉 。 其特点如下：
一, 喷泉模型规定软件开发过程有 4 个阶段,
即系统分析, 系统设计, 软件设计和实现 。
二, 喷泉模型的各阶段相互重叠, 它反映了
软件过程并行性的特点 。
三, 喷泉模型以分析为基础, 资源消耗呈塔
型, 在分析阶段消耗的资源最多 。
四, 喷泉模型反映了软件过程迭代的自然特性,
从高层返回低层无资源消耗 。
五, 喷泉模型强调增量开发, 它依据分析一点,
设计一点的原则, 并不要求一个阶段的彻底完成,
整个过程是一个迭代的逐步提炼的过程 。
六, 喷泉模型是对象驱动的过程, 对象是所有
活动作用的实体, 也是项目管理的基本内容 。
四代技术模型
四代技术, 简称 4GT。 4GT拥有一组工具, 它们都
有一个共同的特点, 即每个工具都能使开发人员在高
层次上定义软件的某些特性, 并把开发人员定义的这
些特性自动生成源代码 。
机器如果能在越高层上定义软件, 则程序生成越
快 。 软件工程的 4GT模型能在机器的一定层次上用一种
近似自然的语言或一种能赋予特殊功能的符号来定义
软件 。
目前，支持 4GT模型的软件开发环境的常见的
工具：
数据查询的非过程性语言，报表生成，数据
处理，屏幕交互和定义，代码生成，高层图形功
能和电子表格等。
四代技术模型
需求分析
设计策略
用 4GT实现
测 试
变换模型
变换模型是一种适合于形式化开发方法的
模型 。 从软件需求的形式化说明开始, 经过
一系列变换, 最终得到系统的目标程序 。
变换模型主要用于软件的形式化开发方法 。 一
个形式化的软件开发方法要提供一套思维方法和描
述开发手段, 如规范描述的原则, 程序开发的一般
过程, 描述语言等, 使开发者能利用数学概念和表
示方法恰当合理地构造形式规范, 根据开发过程的
框架及设计原则进行规范描述和系统化的设计,
并对规范的性质和设计的步骤进行分析验证 。
用于软件形式化开发方法的变换模型分为模型
规范的建立和规范实现开发的一系列变换过程。
模型检查
软件需求形式
化说明 (M0) (M2)
软件设计形式
化说明 (M１ )
程序
(Mn)……
变换 变换 变换
一, 建立软件系统的模型规范 。 将对实现环境和
系统的功能需求进行分析, 提出与系统有关的基本概
念和固有属性, 并以此为基础建立问题求解的抽象模
型, 称为模型抽象 。 它由相互关联的两部分组成, 即
表示抽象和运算抽象 。
二, 表示抽象 。 表示抽象是模型规范构造者在分
析求解问题及其实现环境的基础上, 对形成系统可观
察属性的对象域及其组成元素的形式描述 。
三、运算抽象。运算抽象是定义若干运算来模拟
系统中可能发生的事件，即围绕表示抽象给出若干运
算的规范描述。这种描述规定了运算所模拟的事件发
生前后，系统可观察属性的变化关系，即状态转换关
系。
开发过程中注意如下六个问题：
四, 变换过程 。 当软件系统模型规范的构造完成
之后, 进一步开发满足规范的实现系统 。 程序开发过
程应是设计和验证并行的多步精化过程, 对开发的每
一步, 均要慎重考虑该步开发是否正确, 在发现问题
时要及时解决 。 只有这样才能大大减少开发费用, 保
证最终产品的质量和开发效率 。 从抽象模型规范 (M0)
开始的多步开发过程可表示为
M0→M 1→M 2→ … →M n
的变换, 其中, Mi+1是 Mi的实现模型, 变换中的每一步
的, 强度, 都影响到整个变换的强度, 还要论证每个
Mi+1是 Mi的正确实现 。 这种开发过程中的证明推理是以
诸模型的形式化为前提的, 也是保证最终的实现系统
(Mn)正确实现模型规范的必要阶段 。
五, 变换的独立性 。 这种多步变换过程的一个重
要性质是每步变换对相关模型描述是, 封闭的,, 即
每步变换的正确性仅与该步变换所依据的规范 Mi以及
对变换后的假设 (如 Mi+1)有关 。 变换步骤在这种意义
下独立于其他变换步骤 。
假若没有这种独立性, 就无法控制错误的恶性蔓
延, 而变换步骤的经验也就成了一句空话 。
六, 变换的设计 。 变换的设计过程是一种, 发明,
的过程 。 在模型具体化的变换过程中, 具体实现模型
的设计是开发者的职责 。
目前还没有相当高级的规范能自动翻译成高效程
序代码的工具, 这种设计, 发明,, 是以开发者自己
对正在设计中的系统的功能和使用环境的理解, 是对
实现效率及进一步开发的预测等程序设计经验以及对
软件开发基本原则的理解为基础的 。
形式化开发方法仅提供给开发者一种严格有效的
思维工具和描述工具, 而不能代替开发者进行变换的
,发明, 。
1,该模型只适合于软件的形式化开发方法 。
2,必须有严格的数学理论和形式化技术支持 。
3,缺乏相应的支持工具, 处于手工处理方
式 。
4,尚处于研究和实验阶段, 离使用前景尚
有一段距离 。
5,对软件开发人员要求较高 。
变换模型有以下几个的特点：
基于知识的模型
基于知识的模型又称智能模型, 它把瀑布模型和专
家系统结合在一起 。
该模型在开发的各个阶段上都利用了相应的专家系
统来帮助软件人员完成开发工作, 使维护在系统需求
说明一级上进行 。
为此, 该模型建立了各阶段所需要的知识库, 将模
型, 相应领域知识和软件工程知识分别存入数据库,
把在软件工程知识基础上生成规则构成的专家系统,
与含有应用领域知识规则的其他专家系统相结合, 构
成了该应用领域的开发系统 。
基于知识的模型
用户概念
支持需求分
析专家系统
需求分析
概要设计
详细设计
编码
测试
维护
支持设计
专家系统
支持测试
专家系统
支持维护
专家系统
一, 支持需求活动的专家系统 。 支持需求活动的专
家系统用来帮助减少需求活动中的二义性, 不精确性
和冲突易变的需求 。 这种专家系统要使用应用领域的
知识, 要用到应用系统中的规则, 建立应用领域的专
家系统来支持需求活动 。
二、支持设计活动的专家系统。支持设计活动的专
家系统用于支持设计功能的 CASE中的工具和文档的选
择，这种专家系统要使用软件开发的知识。
在各阶段都有相应的专家系统支持
三, 支持测试活动的专家系统 。 支持测试活动
的专家系统用于支持测试自动化, 利用基于知识
的系统选择测试工具, 生成测试数据, 跟踪测试
过程, 分析测试结果 。
四、支持维护活动的专家系统。支持维护活动
的专家系统将维护变成新的应用开发过程的重复，
知识模型以瀑布模型与专家系统的综合应
用为基础 。 该模型通过应用系统的知识和规则
帮助设计者认识一个特定软件的需求和设计,
这些专家系统已成为开发过程的伙伴, 并指导
开发过程 。
将软件工程知识从特定领域分离出来，这些知识
随着过程范例收入知识库，产生规则，在接受软件工
程技术的基础上被编码成专家系统，用来辅助软件工
程的开发。
在使用过程中，软件工程专家系统与其他领域的
应用知识的专家系统连接起来，形成了特定软件系统，
为开发一个软件产品所应用。
知识模型的优点如下：
1,通过领域的专家系统, 可使需求说明更完整,
准确和无二义性 。
2,通过软件工程专家系统, 提供一个设计库支
持, 在开发过程中成为设计者的助手 。
3,通过软件工程知识和特定应用领域的知识和
规则的应用来提供开发的帮助 。
知识模型的缺点如下：
1,建立适合于软件设计的专家系统是非常困难
的, 超出了目前的能力, 是今后软件工程的发展
方向, 要经过相当长的时间才能取得进展 。
2,建立一个既适合软件工程又适合应用领域的
知识库也是非常困难的 。
3,目前的状况是在软件开发中正在应用 AI技术,
在 CASE工具系统中使用专家系统, 用专家系统来
实现测试自动化, 这只在软件开发的局部阶段有
所进展 。
过程开发模型
又称混合模型, 或称元模型 。 近几年来, 为了
克服瀑布模型式模型的种种缺陷, 出现了很多开发
模型 。 但是, 这些开发模型仍被限制在整个项目开
发按定义所确定的阶段性的系统开发方向上 。 解决
这一问题的方法之一是把几种模型组合为一种混合
模型 。 这种思想属于问题导向方法论 。
瀑布式 给了人们一种软件开发过程的概念，即一
个项目要经过需求分析、设计、实现、测试和维护等
阶段的一系列软件工程活动。
原型模型 是在需求分析阶段生成的原型上开发系
统。
螺旋模型 则把开发分为计划、风险、工程和用户
评价四个阶段。
4GT就其本质来看更像是开发方法和工具，而不是
具体模型。
OO开发与传统的结构化生存期比较，具有更多
的递增和迭代性质，生存期的各个阶段可以相互重
叠和多次反复，而在项目的整个生存期中还可以嵌
入子生存期。所以有人称 OO生存期为喷泉模型，就
像水喷上去落下来，可以落在中间，也可以落在最
底部。
变换模型 是一种属于形式化开发方法的模型。
知识模型 是把瀑布模型和专家系统结合在一起。
在开发的各个阶段上都利用了相应的专家系统来
帮助软件人员完成开发工作，使维护在系统需求
说明一级上进行。
以上这些方法看起来十分严谨, 但实际上很少完
全按上述过程一步一步的进行 。 这是因为任何一个项
目的开发决定于许多因素, 如软件的应用领域, 规模
大小, 可重用构件的大小和多少, 软件实现的硬软环
境, 开始和交付的规定等 。 这就需要一种更为灵活和
更加动态的方法 。
在 1985年美国国防部软件研究所提出了混合模型 。
它是根据具体的项目问题, 制定开发策略 。
混合模型有多种开发方法, 提供了一种适合
于各种具体系统, 环境或机构的灵活的结构 。
它的好处是：项目管理人员无疑不愿意在工
作中没有某种构思的框架就去进行一个项目的开
发 。 联合几种模型构成一种混合模型, 给管理人
员提供了在具体操作中使用结构框架的某种形式 。
这样就可以使每个模型的长处得到充分的发挥 。
所有项目都始于一些初始的想法, 在混合模型
中称之为构思 。
一个项目有了构思, 预计划就有了确定的过程
方向 。 混合模型允许管理人员按照当前项目的情况,
指导项目构造一种开发方法 。 由于混合模型结构中
的不确定性, 管理人员在一开始不必去决定完成开
发过程的方向 。
需要在基于项目的情况, 确定项目的决策点,
管理人员可在项目的生存期内做出决策, 当一个项
目的环境完全不同于开始时, 早决策不如晚些时候
决策好 。
过程开发模型对开发人员的要求是比较高的,
开发人员不仅要有扎实的软件工程理论基础, 而
且要有丰富的软件项目开发经验 。
习 题
1,什么是软件工程？ 软件工程产生的背景是什么？
2,什么是软件工具和软件环境？ 它们有什么区别？
3,软件工程开发软件有哪些基本模式？ 它们有什
么特点？ 其适用范围是什么？
4,常用软件工程的开发模型有哪些？
5,过程开发模型的方法论基础是什么？
6,软件工程的基本目标是什么？ 怎样做才能达能
理想的程度？
