计算机科学学院 陈汶滨 E_Mail:cwb650501@sina.com Tel:13981892216 软件工程基础 计算机科学学院 陈汶滨 E_Mail:cwb650501@sina.com Tel:13981892216

本课程的主要任务 理解软件危机的发生及其原因，掌握程序、软件、软件工程、软件生成周期的基本概念 熟练掌握软件项目可行性分析、需求分析、概要设计、详细设计、编码、软件测试、软件维护各阶段的任务、使用的技术、产生的文档

考试考核办法 平时成绩（考勤、随堂提问等）：10% 作业成绩：20% 期末成绩：70%

参考书及网络资源 软件工程，钱乐秋等，清华大学出版社，2016年 软件工程导论（第6版），张海藩，清华大学出版社，2008年 软件工程思想，林锐，软件工程教研室内部试用版，2012年 软件工程学教程，陈明，科学出版社，2002年 UML软件工程组织 http://www.uml.org.cn/ 共创联盟软件工程 http://cosoft.org.cn 中国最大的开发者网络 http://www.csdn.net/ 软件工程俱乐部 http://www.rational-club.org/

资源 http://course.jingpinke.com/details?uuid=8a833999-1e4881f5-011e-4881fb4f-06b5 复旦大学 http://www.icourses.cn/coursestatic/course_4192.html 国防科技大学 http://www.icourses.cn/coursestatic/course_6804.html 浙江大学 http://www.icourses.cn/coursestatic/course_3016.html 清华大学 http://www.icourses.cn/coursestatic/course_6305.html 北京大学

软件工程 第1章 概论

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

计算机软件指计算机系统中的程序及其文档 计算机软件 程序是计算任务的处理对象和处理规则的描述 文档是为了便于了解程序所需的阐明性资料 计算任务：以计算机为处理工具的任务 处理对象：数据（如数据、文字、图形、图象、声音等，它们只是表示，而无含义）或信息（数据及有关的含义） 处理规则：一般指处理的动作和步骤。程序必须装入计算机内才能工作 文档是为了便于了解程序所需的阐明性资料

软件的发展 1946-1956年 从计算机问世到实用的高级程序语言出现前 存储容量比较小，运算速度比较慢 采用个体工作方式,用低级语言编写程序 应用领域主要是以数值数据处理为主的科学计算，其特点是输入、输出量较小，但计算量大 衡量程序质量的标准主要是功效，即运行时间省、占用内存小 主要研究内容是科学计算程序、服务性程序和程序库，研究对象是顺序程序

从实用的高级程序语言出现到软件工程出现前 1956-1968年 从实用的高级程序语言出现到软件工程出现前 存储器容量大，外围设备得到迅速发展，出现了高级程序设计语言 应用领域包括数据处理（非数值数据），其特点是计算量不大，但输入、输出量却较大 高速主机与低速外围设备的矛盾突出，出现了操作系统、并发程序、数据库及其管理系统 20世纪60年代初提出了软件一词，开始认识到文档的重要性 研究高级程序设计语言、编译程序、操作系统、支持编程的工具及各种应用软件 工作方式逐步从个体方式转向合作方式 出现软件危机

1968年-至今 从软件工程出现到现在 硬件向巨型机和微型机二个方向发展，出现了计算机网络，软件方面提出了软件工程，出现了“计算机辅助软件工程”（CASE） 计算机的应用领域渗透到各个业务领域，出现了嵌入式应用，其特点是受制于它所嵌入的宿主系统 开发方式逐步由个体合作方式转向工程方式 软件工程方面的研究主要包括软件开发模型、软件开发方法及技术、软件工具与环境、软件过程、软件自动化系统等 软件方面研究以智能化、自动化、集成化、并行化、以及自然化为标志的软件开发新技术

软件危机 许多软件项目不能满足客户的要求 许多软件项目超出预算和时间安排

软件危机的表现 对软件开发成本和进度的估计常常很不正确 用户对“已完成的”软件系统不满意的现象经常发生 软件产品的质量往往靠不住 软件常常是不可维护的 软件通常没有适当的文档资料 软件成本在计算机系统总成本中所占的比例逐年上升 软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的趋势

软件危机的原因 软件是逻辑产品，开发进度、成本难以估计 缺乏或不完整、不一致的文档给维护带来困难 用户对软件需求的描述往往不够精确，有遗漏，有二义 软件开发人员对需求的理解与用户的本来愿望有差异 大型软件项目需多人协同完成，缺乏管理经验 开发人员不能有效地、独立自主地处理大型软件的全部关系 缺乏有力的方法学和工具的支持 软件项目的特殊性和人类智力的局限性

克服软件危机的途径 消除错误的概念和做法 推广使用成功的开发技术和方法 使用软件工具和软件工程支持环境 加强软件管理

软件的特点 软件是一种逻辑实体，而不是有形的系统元件，其开发成本和进度难以准确地估算 软件是被开发的或被设计的，没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大 软件的使用没有硬件那样的机械磨损和老化问题

其它特点： 软件的开发和运行常受到计算机硬件的限制，对计算机硬件有着不同程度的依赖性 软件的开发至今尚未完全实现自动化 软件成本相当昂贵 相当多的软件工作涉及到社会因素

软件的分类 系统软件：位于计算机系统中最靠近硬件的一层，其它软件一般都通过系统软件发挥作用，它与具体的应用领域无关。如操作系统、编译程序等。 支持软件：支持软件的开发和维护的软件。如数据库管理系统、网络软件、软件开发环境等。 应用软件：特定应用领域专用的软件。如实时软件、嵌入式软件、科学和工程计算软件、事务处理软件、人工智能软件等。

按软件工作方式划分 实时处理软件 分时软件 交互式软件 批处理软件 按软件服务对象的范围划分 项目软件 产品软件

按使用的频度进行划分 一次使用 频繁使用 按软件失效的影响进行划分 高可靠性软件 一般可靠性软件

软件语言software language 软件语言是用于书写计算机软件的语言。 它主要包括： 需求定义语言 功能性语言 设计性语言 实现性语言（即程序设计语言） 文档语言

需求定义语言 requirements definition language 需求定义语言用于书写软件需求定义 软件需求定义是软件功能需求和非功能需求的定义性描述。软件功能需求刻画软件“做什么”，软件非功能需求刻画诸如功能性限制、设计限制、环境描述、数据与通信规程及项目管理等 典型的需求定义语言有PSL语言（Problem Statement Language问题陈述语言）

功能性语言 functional language 功能性语言用于书写软件功能规约（functional specification） 软件功能规约是软件功能的严格而完整的陈述。通常它只刻画软件系统“做什么”的外部功能，而不涉及系统“如何做”的内部算法 典型的功能性语言有广谱语言、Z语言

设计性语言design language 设计性语言用于书写软件设计规约（design specification） 软件设计规约是软件设计的严格而完整的陈述。一方面，它是软件功能规约的算法性细化，刻画软件“如何做”的内部算法，另一方面，它是软件实现的依据。 典型的设计性语言有PDL语言（Program Design Language）

实现性语言 实现性语言用于书写计算机程序 实现性语言也称编程语言或程序设计语言（programming language） 程序设计语言可按语言的级别、对使用者的要求、应用范围、使用方式、成分性质等多种角度进行分类

按语言级别分：低级语言和高级语言 低级语言是与特定计算机体系结构密切相关的程序设计语言，如机器语言、汇编语言。其特点是与机器有关，功效高，但使用复杂，开发费时，难维护 高级语言是不反映特定计算机体系结构的程序设计语言，它的表示方法比低级语言更接近于待解问题的表示方法。其特点是在一定程度上与具体机器无关，易学、易用、易维护。但高级语言程序经编译后产生的目标程序的功效往往较低

按用户要求分：过程式语言和非过程式语言 过程式语言（procedural language）是通过指明一列可执行的运算及运算次序来描述计算过程的程序设计语言。如FORTRAN、C、Java等 非过程式语言（nonprocedural language）是不显式指明处理过程细节的程序设计语言。在这种语言中尽量引进各种抽象度较高的非过程性描述手段，以期做到在程序中增加“做什么”的描述成分，减少“如何做”的细节描述。如第四代语言（4GL）、函数式语言、逻辑式语言

也可称：命令式语言和申述式语言 命令式语言（imperative language）即过程式语言 申述式语言（declarative language）是着重描述要处理什么，而非描述如何处理的语言。申述式语言程序是关于问题解的约束陈述，这些约束迫使含于实现中的算法处理机制生成一个解或一组解。如函数式语言、逻辑式语言

函数式语言(functional programming language)中函数是构造程序的基本成分，它提供一些设施用于构造更为复杂的函数。程序人员根据提出的问题去定义求解函数（即主程序），其中可能包含一些辅助函数。如Lisp语言 逻辑式语言(logic programming language)的基本运算单位是谓词。谓词定义了变元间的逻辑关系。例如，Prolog语言的基本形式是Horn子句，其程序围绕着某一主题的事实、规则和询问三类语句组成。这三类语句分别用于陈述事实、定义规则和提出问题

通用语言指目标非单一的语言，如FORTRAN、C、Java等 专用语言指目标单一的语言，如自动数控程序APT 按应用范围分：通用语言和专用语言 通用语言指目标非单一的语言，如FORTRAN、C、Java等 专用语言指目标单一的语言，如自动数控程序APT

按使用方式分：交互式语言和非交互式语言 交互式语言指具有反映人机交互作用的语言，如BASIC 非交互式语言指不反映人机交互作用的语言，如FORTRAN、COBOL

按成分性质分：顺序语言、并发语言、分布语言 顺序语言指只含顺序成分的语言，如FORTRAN、C 并发语言指含有并发成分的语言，如Modula、Ada、并发Pascal 分布语言指考虑到分布计算要求的语言，如Modula

文档语言 documentation language 文档语言用于书写软件文档。 计算机软件文档是计算机开发、维护和使用过程的档案资料和对软件本身的阐述性资料 通常用自然语言或半形式化语言书写

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

软件工程定义 1968年NATO(北大西洋公约组织)会议上首次提出 Fritz Bauer：软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行 IEEE：软件工程是：①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；②在①中所述方法的研究 计算机科学技术百科全书：软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。软件工程借鉴传统工程的原则、方法，以提高质量、降低成本为目的

软件工程的框架 目标 生产具有正确性、可用性以及价格合宜的产品 正确性反映软件产品实现相应功能规约的程度 可用性反映软件的基本结构、实现及其文档为用户可用的程度 价格合宜反映软件开发与运行的总代价满足用户要求的程度

过程 生产一个最终满足需求且达到工程目标的软件产品所需要的步骤 软件工程过程包括：开发过程、运作过程、维护过程、管理过程、支持过程、获取过程、供应过程、剪裁过程等

原则 选取适宜的开发模型 采用合适的设计方法 提供高质量的工程支持 重视软件工程的管理

软件生存周期 （ software life cycle） 软件有一个孕育、诞生、成长、成熟、衰亡的生存过程。这个过程即为计算机软件的生存周期 软件生存周期大体可分为如下几个活动：计算机系统工程、需求分析、设计、编码、测试、运行和维护

计算机系统工程 计算机系统包括计算机硬件、软件、使用计算机系统的人、数据库、文档、规程等系统元素 计算机系统工程的任务 确定待开发软件的总体要求和范围，以及它与其它计算机系统元素之间的关系 进行成本估算，做出进度安排 进行可行性分析，即从经济、技术、法律等方面分析待开发的软件是否有可行的解决方案，并在若干个可行的解决方案中作出选择

软件需求分析 主要解决待开发软件要“做什么”的问题 确定软件的功能、性能、数据、界面等要求，生成软件需求规约

软件设计 主要解决待开发软件“怎么做”的问题 软件设计通常可分为系统设计（也称概要设计或总体设计）和详细设计 系统设计的任务是设计软件系统的体系结构，包括软件系统的组成成分、各成分的功能和接口、成分间的连接和通信，同时设计全局数据结构 详细设计的任务是设计各个组成成分的实现细节，包括局部数据结构和算法等

编码 用某种程序设计语言，将设计的结果转换为可执行的程序代码 测试 发现并纠正软件中的错误和缺陷。测试主要包括单元测试、集成测试、确认测试和系统测试 运行和维护 在软件运行期间，当发现了软件中潜藏的错误或需要增加新的功能或使软件适应外界环境的变化等情况出现时对软件进行修改

软件工程方法学 把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。 （Methodology or Paradigm） 软件工程方法学包含3个要素：方法、工具和过程 方法 — 完成软件开发的各项任务的技术方法，回答“怎样做”的问题； 工具 — 为运用方法而提供的自动的或半自动的软件工程支撑环境； 过程 — 为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

软件工程方法学分类： 传统方法学 面向对象的方法学 形式化方法

传统方法(生命周期方法) 仍然是使用十分广泛的软件工程方法学。 采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。 从上而下，顺序地完成软件开发的各阶段任务。

面向对象方法 出发点和基本原则是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识实践解决问题的方法与过程，从而使描述问题的问题空间与实现解法的解空间在结构上尽可能一致。

面向对象方法的特点 把对象作为融合了数据及在数据上的操作行为的统一软件构件； 把所有对象都划分成类； 按照父类与子类的关系，把若干个相关类组成一个层次结构的系统； 对象彼此间仅能通过发送消息互相联系。

形式化方法 形式化方法是借助数学的方法来解决软件工程领域的问题，主要包括建立精确的数学模型以及对模型的分析活动。 是一种基于形式化数学变换的软件开发方法，它可将系统的规格说明转换为可执行的程序。 本质是基于数学的方法来描述目标软件系统属性的一种技术。不同的形式化方法的数学基础是不同的，有的以集合论和一阶谓词演算为基础（如Z和VDM），有的则以时态逻辑为基础。形式化方法需要形式化规约说明语言的支持。

软件工程方法的三要素 方法 软件开发提供了“如何做”的技术。它包括了多方面的任务，如项目计划与估算、软件需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等 工具 为软件工程方法提供了自动的或半自动的软件支撑环境。目前，已经推出了许多软件工具，这些软件工具集成起来，建立起称之为计算机辅助软件工程(CASE)的软件开发支撑系统。CASE将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。 过程 将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

软件过程 软件过程指软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合

GB/T 8566-2007软件生存周期过程 GB/T 8566-2007标准把软件生存周期中可以开展的活动分为5个基本过程，9个支持过程和7个组织过程。每一个过程划分为一组活动，每项活动进一步划分为一组任务

基本（primary）过程供各参与方在软件生存周期期间使用。包括： 获取（acquisition）过程：为获取系统、软件产品或软件服务的组织即需方而定义的活动 供应（supply）过程：为向需方提供系统、软件产品或软件服务的组织即供方而定义的活动 开发（development）过程：为定义并开发软件产品的组织即开发方而定义的活动 运作（operation）过程：为在规定的环境中为其用户提供运行计算机系统服务的组织即操作方而定义的活动 维护（maintenance）过程：为提供维护软件产品服务的组织即维护方而定义的活动

支持（supporting）过程用于支持其他过程，它有助于软件项目的成功和质量提高。包括： 文档编制（documentation）过程： 为记录生存周期过程所产生的信息而定义的活动 配置管理（configuration management）过程： 定义配置管理活动 质量保证（quality assurance）过程：为客观地保证软件产品和过程符合规定的需求以及已建立的计划而定义的活动 验证（verification）过程：根据软件项目需求，按不同深度验证软件产品而定义的活动

确认（validation）过程：确认软件项目的软件产品而定义的活动 联合评审（joint review）过程：为评价一项活动的状态和产品而定义的活动 审核（audit）过程：为判定符合于需求、计划和合同而定义的活动 问题解决（problem resolution）过程：为分析和解决问题而定义的活动 易用性（usability）过程：为易用性专业人员而定义的活动

组织（organizational）过程用于软件组织建立和实现由相关的生存周期过程和人员组成的基础结构，并不断改进这种结构和过程。包括： 管理（management）过程：为生存周期过程中的管理包括项目管理而定义的基本活动 基础设施（infrastructure）过程：为建立生存周期过程基础结构而定义的基本活动 改进（improvement）过程: 为某一组织建立、测量、控制和改进其生存周期过程而定义需要执行的基本活动

人力资源（human resources）过程: 为给组织或项目提供拥有技能和知识的员工而定义的活动 资产管理（asset management）过程：为组织的资产管理者而定义的活动 重用程序管理（reuse program management ）过程：为组织的复用大纲主管而定义的活动 领域工程（domain engineering）过程: 为领域模型、领域体系结构的确定及该领域资产的开发和维护而定义的活动

ISO/IEC 12207-2008 软件生存周期过程 第一类过程称为系统周境过程（system context processes）：这类过程处理独立的软件产品、服务或软件系统的系统周境 第二类过程称为软件特定过程（software specific processes）：用于实现一个软件产品或者大型系统中的某一服务

系统周境过程包括以下4个过程组，25个过程 协定过程组：获取过程、供应过程 组织级项目使能（启用）过程组：生存周期模型管理过程、基础设施管理过程、项目投资管理过程、人力资源管理过程、质量管理过程 项目过程组：项目计划管理过程、项目评估和控制过程、决策管理过程、风险管理过程、配置管理过程、信息管理工程、测量过程 技术过程组：利益相关方需求定义过程、系统需求分析过程、系统体系结构设计过程、实现过程、系统集成过程、系统合格性测试过程、软件安装过程、软件验收支持过程、软件运作过程、软件维护过程、软件废弃（处置）过程

软件特定过程包括以下3个过程组，18个过程 软件实现过程组：软件实现过程、软件需求分析过程、软件体系结构设计过程、软件详细设计过程、软件构造过程、软件集成过程、软件合格性测试过程 软件支持过程组：软件文档管理过程、软件配置管理过程、软件质量保证过程、软件验证过程、软件确认过程、软件评审过程、软件审核过程、软件问题解决过程 软件复用过程组：领域工程过程、复用资产管理过程、复用程序管理过程

能力成熟度模型CMM CMM（Capability Maturity Model）即能力成熟度模型，是美国卡内基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程

软件组织的成熟与不成熟 1. 不成熟的软件组织 软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划 有时，即使软件过程已计划好，仍不按计划执行 没有一个客观的基准来判断产品质量，或解决产品和过程中的问题 对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消 产品在交付前，对客户来说，一切都是不可见的

没有长远目标，管理员通常只关注解决任何当前的危机 由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度

2. 成熟的软件组织 具有全面而充分的组织和管理软件开发和维护过程的能力 管理员监视软件产品的质量以及生产这些产品的过程 制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题 进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的 能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作 凡规定的过程都编成文档

软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程 全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生

CMM提供了一个成熟度等级框架： 1级-初始级 2级-可重复级 3级-已定义级 4级-已管理级 5级-优化级

软件过程成熟度等级 1.初始（initial）级： 软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力 2.可重复（repeatable）级： 建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功

3.已定义（defined）级： 己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件 4.已管理（managed）级： 收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制 5.优化（optimizing）级： 整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进

5.优化级 4.已管理级 3.已定义级 2.可重复级 1.初始级 标准、一致的过程 有纪律的过程 可预测的过程 持续改进过程 软件过程成熟度 的5个等级

能力成熟度模型的结构 成熟度等级表明了一个软件组织的过程能力的水平。除初始级外，每个成熟度等级都包含若干个关键过程域（Key Process Area，简称KPA）（见表1.2） 达到某个成熟度级别，该级别（以及较低级别）的所有关键过程域都必须得到满足，并且过程必须实现制度化。

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

软件过程模型 软件过程模型是软件开发全部过程、活动和任务的结构框架 也称软件开发模型 或软件生存周期模型

软件过程模型 典型的软件过程模型有： 瀑布模型（waterfall model） 演化模型（evolutionary model） 增量模型（incremental model） 原型模型（prototyping model) 螺旋模型（spiral model） 喷泉模型（water fountain model） 基于构件的开发模型（component-based development model） 形式方法模型（formal methods model）

系统工程 需求分析 与规约 设计与 规约 编码与 单元测试 集成测试 系统测试 运行与 维护 瀑布模型

1970年W.Royce提出瀑布模型 特征 缺点 接受上一阶段的结果作为本阶段的输入 利用这一输入实施本阶段应完成的活动 对本阶段的工作进行评审 将本阶段的结果作为输出，传递给下一阶段 缺点 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发 开发早期存在的问题往往要到交付使用时才发现，维护代价大

演化模型 许多软件项目在开发早期对软件需求的认识是模糊的、不确定的，因此软件很难一次开发成功 可以在获取了一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，称之谓原型（prototype），然后根据用户在试用原型的过程中提出的意见和建议、或者增加新的需求，对原型进行改造，获得原型的新版本，重复这一过程，最终得到令客户满意的软件产品 演化模型的开发过程就是从构造初始的原型出发，逐步将其演化成最终软件产品的过程 演化模型适用于对软件需求缺乏准确认识的情况 典型的演化模型有：增量模型、原型模型、螺旋模型

增量模型 交流 计划 建模（分析，设计） 软件功能性和特征 增量n 构造（编码，测试） 部署（发布，反馈） 第n次增量发布 增量2 … 1 3 4 5 第2次增量发布 增量2 第n次增量发布 增量n 第1次增量发布 增量1 … 项目日历时间 软件功能性和特征 部署（发布，反馈） 构造（编码，测试） 建模（分析，设计） 计划 交流

增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。 增量模型融合了瀑布模型的基本成分（重复地应用）和演化模型的迭代特征 增量模型强调每一个增量都发布一个可运行的产品

增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术 增量模型特别适用于： 需求经常变化的软件开发 市场急需而开发人员和资金不能在设定的市场期限之前实现一个完善的产品的软件开发 增量模型能有计划地管理技术风险，如早期增量版本中避免采用尚未成熟的技术

原型模型 原型（prototype）是预期系统的一个可执行版本，它反映了系统性质（如功能、计算结果等）的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型 原型方法从软件工程师与客户的交流开始，其目的是定义软件的总体目标，标识需求。然后快速制订原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其建模，并构建原型 被开发的原型应交付给客户试用，并收集客户的反馈意见，这些反馈意见可在下一轮迭代中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发

部署交付和反馈 构建原型 交流 快速设计方式建模 快速计划 原型模型

原型的类型： 探索型（exploratory prototyping） 其目的是要弄清目标系统的要求，确定所希望的特性，并探讨多种方案的可行性 实验型（experimental prototyping） 其目的是验证方案或算法的合理性，它是在大规模开发和实现前，用于考核方案是否合适，规格说明是否可靠 演化型（evolutionary prototyping） 其目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统

原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中 原型的使用策略： 废弃（throw away）策略 主要用于探索型和实验型原型的开发。这些原型关注于目标系统的某些特性，而不是全部特性，开发这些原型时通常不考虑与探索或实验目的无关的功能、质量、结构等因素，这种原型通常被废丢，然后根据探索或实验的结果用良好的结构和设计思想重新设计目标系统 追加（add on）策略 主要用于演化型原型的开发。这种原型通常是实现了目标系统中已明确定义的特性的一个子集，通过对它的不断修改和扩充，逐步追加新的要求，最后使其演化成最终的目标系统 原型可作为单独的过程模型使用，它也常被作为一种方法或实现技术应用于其它的过程模型中

螺旋模型 B.Boehm于1988年提出 是瀑布模型和演化模型的结合，并增加了风险分析 螺旋模型沿着螺线旋转，在四个象限上分别表达四个方面的活动，即： 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件 风险分析：评价所选的方案，识别风险，消除风险 工程实施：实施软件开发，验证工作产品 客户评估：评价开发工作，提出修正建议

螺旋模型出现了一些变种，它可以有3到6个任务区域 螺旋模型指引的软件项目开发沿着螺线自内向外旋转，每旋转一圈，表示开发出一个更为完善的新软件版本 如果发现风险太大，开发者和客户无法承受，则项目就可能因此而终止 多数情况下沿着螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统

喷泉模型

喷泉模型是一种支持面向对象开发的模型 体现迭代和无间隙特征 迭代：各开发活动常常重复工作多次，相关的功能在每次迭代中随之加入演进的系统 无间隙：开发活动之间不存在明显的边界

基于构件的开发模型 支持软件复用（reuse） 利用预先包装好的软件构件（包括组织内部开发的构件和现存商品化构件COTS）来构造应用系统

领域工程 应用系统工程 领域分析 构件可变性 分析 构建 可复用构件 领域模型 领域基准 体系结构 可复用 构件库 体系结构设计 获取构件 构件特化 和修改 评价 构件组装 和测试 开发未找到 构件的部分 应用系统工程 应用系统 领域工程

领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库 领域分析分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构（reference architecture），标识领域的候选构件 对候选构件进行可变性分析，以适应多个应用系统的需要 构建可复用构件，经严格测试和包装后存入可复用构件库

应用系统工程的目的是使用可复用构件组装应用系统 分析待开发的应用系统，设计应用系统的体系结构，标识应用系统所需的构件 在可复用构件库中查找合适的构件（也可购买第三方的构件） 特化选中的构件，必要时作适当的修改，以适应该应用系统的需要 开发那些未找到合适构件的应用部分 组装应用系统 评价构件的复用情况，以改进可复用构件，同时对新开发的部分进行评价，并向构件工程推荐候选构件

根据AT&T、Ericsson、HP公司的经验，有的软件复用率高达90%以上，产品上市时间可缩短2～5倍，错误率减少5～10倍，开发成本减少15%～75%。仅管这些结论出自一些较好使用基于构件开发的实例，但毫无疑问，基于构件的开发模型对提高软件生产率、提高软件质量、降低成本、提早上市时间起到很大的作用

形式方法模型 形式化方法（formal methods）是建立在严格数学基础上的一种软件开发方法。软件开发的全过程中，从需求分析、规约、设计、编程、系统集成、测试、文档生成、直至维护各个阶段，凡是采用严格的数学语言，具有精确的数学语义的方法，都称为形式化方法 形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的岐义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能

形式方法模型 净室软件工程（cleanroom software engineering）是一种形式化方法，希望在缺陷可能产生严重的危险前消除缺陷 净室软件工程强调在程序构造开始前进行正确性验证，并将软件可靠性认证作为软件测试的一部分 净室方法还强调统计质量控制技术，分析使用情况的概率分布，并由统计样本导出测试 净室方法采用增量模型，每个增量开发包括如下净室任务：增量策划、需求收集、盒结构规约、形式化设计、正确性验证、代码生成、代码审查和验证、统计测试计划、统计使用测试、认证等。如图1.14所示

净室过程模型 系 统 工 程 需求 收集 代码 审查 盒结构规约 形式化设计 正确性验证 生成 统计 使用 测试 认证 测 试 计 划 测 试 计 划 增量1 统计使用测试 测 试 计 划 增量2 增量3

内容摘要 计算机软件 软件工程 软件过程 软件过程模型 CASE工具与环境

计算机辅助软件工程（CASE） Computer Aided Software Engineering 在软件工程活动中，软件工程师和管理人员按照软件工程的方法和原则，借助于计算机及其软件工具的帮助，开发、维护、管理软件产品的过程称为计算机辅助软件工程

CASE工具 软件工具是用来辅助计算机软件的开发、运行、维护、管理、支持过程中的活动或任务的软件 按支持的软件过程活动分类： 开发过程：需求分析工具，设计工具，编码工具，测试工具 它们还可按支持的开发方法分为：结构化XX工具，面向对象XX工具

维护过程：版本控制工具，文档分析工具，逆向工程（reverse engineering）工具，再工程（reengineering）工具 管理过程：项目管理工具，配置管理工具，软件评价工具 应用类工具

集成型软件开发环境 集成型开发环境是一种把支持多种软件开发方法和过程模型的软件工具集成到一起的软件开发环境 集成型开发环境由环境集成机制和工具集组成

思考 1 什么是计算机软件？软件的特点是什么？ 2 何谓“软件危机”？ 3 主要有哪些软件工程方法？软件工程方法有哪三个要素？ 4 软件生命周期主要包含哪几个阶段？ 主要有哪些过程模型？