软件工程学概述共4学时课件

第1章软件工程学概述（共4学时）学习要求：1、了解软件危机产生的原因和消除软件危机的根本途径；2、

掌握软件工程,软件工程学,软件生命周期和软件过程的概念；3、理解软件工程的基本原理；4、

掌握常见的几种开发模型(过程)；9/19/20231第1章软件工程学概述（共4学时）学习要求：8/6/2023第1章软件工程学概述1.1软件危机软件危机的定义，产生原因，解决途径1.2软件工程软件工程的概念、基本原理和软件工程方法学1.3软件的生命周期1.4软件过程介绍瀑布模型、快速原型模型、增量模型、螺旋模型9/19/20232第1章软件工程学概述1.1软件危机8/6/20232第1章软件工程学概述1.1软件危机1、20世纪60年代中期之前软件规模小，编写和应用在自己的小范围，软件=程序。2、20世纪60——70年代中期出现“软件作坊”，软件的数量急剧膨胀，软件维护工作量和费用惊人增长，个别软件不可维护；软件危机出现。一、软件危机及其表现9/19/20233第1章软件工程学概述1.1软件危机1、20世纪60年代中1、什么是软件危机？软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。（1）、如何开发软件满足用户的需要。（2）、如何维护大量的已有软件。2、软件危机的典型表现（1）、对软件开发的成本和进度估计常常不准确。（2）、用户对“已完成”的软件系统不满意的现象常发生。（3）、软件产品的质量时常靠不住。（4）、软件常常不可维护。（5）、软件没有适当的文档资料。9/19/202341、什么是软件危机？软件危机是指在计算机软件的（6）、软件成本在计算机的系统总成本中所占的比列逐年上升。（7）、软件开发的生产率提高的速度远远不及计算机应用普及的速度。二、软件危机产生的原因1、软件本身的特点有关（逻辑部件）（1）、缺乏“可见性”，管理和控制软件开发的过程困难。（2）、由于是逻辑部件，所以在使用过程中不会“用坏”。2、软件开发与维护的方法有关三、消除软件危机的途径9/19/20235（6）、软件成本在计算机的系统总成本中所占的比列逐年上升。（1、软件危机可以被消灭吗？不能消灭，因为：（1）、软件的特点没有改变（2）、用户的需求在不断的增长，任何软件从纵向来看不可能永远满足用户的需要，必然要出现软件危机。2、消除软件危机的途径（1）、对计算机软件和软件开发有一个正确的认识。（2）、技术措施使用实践证明成功的技术和方法，开发和使用更好的软件工具。9/19/202361、软件危机可以被消灭吗？不能消灭，因为：2、消除（3）、管理措施使用科学的方法管理和组织计算机软件的开发。1.2软件工程一、软件工程的介绍1、什么是软件工程？采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间和实践证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就称为软件工程。2、软件工程的特性9/19/20237（3）、管理措施1.2软件工程一、软件工程的介绍1、什么是软（1）、软件工程关注于大型软件的构造（2）、软件工程的中心课题是控制复杂性（3）、软件经常变化（4）、注重开发软件的效率（5）、和谐的合作是开发软件的关键（6）、软件必须有效地支持它的用户的工作（7）、在软件工程领域中是具有一种文化背景的替具有另一种文化背景的创造产品二、软件工程的基本原理B.W.Boehm在1983的一篇论文中提出了软件工程的7条基本原理。9/19/20238（1）、软件工程关注于大型软件的构造（2）、软件工程的中心课1、用分阶段的生命周期计划严格管理2、坚持进行阶段评审3、实行严格的产品控制4、采用现代程序设计技术5、结果应能清楚地审查6、开发小组的成员应尽量少而精7、承认不断改进软件工程实践的必要性三、软件工程方法学9/19/202391、用分阶段的生命周期计划严格管理2、坚持进行阶段评审3、实1、什么是软件工程方法学？通常把软件生命周期过程中使用的一整套技术和方法的集合称为软件工程方法学，也称范型。2、软件工程方法学的要素（1）、方法完成软件开发的各项任务的技术方法，“怎样做”。（2）、工具为运用方法而提供的软件支撑环境。（3）、过程为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。9/19/2023101、什么是软件工程方法学？通常把软件生命周期过程中3、目前常用的软件工程方法学（1）、传统方法学又称为生命周期方法学或结构化范型。（2）、面向对象方法学它是以数据为主线，把数据和对数据的操作紧密地结合起来的方法学。A、把对象作为唯一的软件结构B、把所有对象划分成类C、按照父类与子类的关系，把相关类组成一个层次结构的系统D、对象之间只能通过发送消息相互联系9/19/2023113、目前常用的软件工程方法学（1）、传统方法学（2）、面向对1.3软件生命周期一、软件生命周期1、什么是软件生命周期？软件从定义、开发、使用和维护，直到最终被废弃，所经历的漫长的时期称为软件的生命周期。2、软件生命周期的若干阶段（1）、软件定义时期A、问题定义回答系统“要解决的问题是什么”。B、可行性研究回答“对上面确定的问题是否有行得通的解决办法”。9/19/2023121.3软件生命周期一、软件生命周期1、什么是软件生命周期？C、需求分析确定“为了解决这个问题，目标系统必须做什么”，即目标系统应该有那些功能。（2）、开发时期A、总体设计解决“怎样实现目标系统？”。B、详细设计解决“应该怎样具体实现目标系统？”。C、编码和单元测试写出正确、易理解和维护的程序模块。9/19/202313C、需求分析（2）、开发时期A、总体设计8/6/202313D、综合测试通过各种类型的测试使软件达到预定的要求。（3）、运行维护期使软件持久满足用户的需要直到废弃。改正性维护：改正系统中存在的错误。适应性维护：使软件适应软硬件环境的变化。完善性维护：根据用户要求使软件更加完善。预防性维护：为将来的维护活动预先做准备。9/19/202314D、综合测试（3）、运行维护期8/6/2023141.4软件过程软件过程是近十年来人们关注的焦点。软件过程是为开发高质量软件所需要完成的任务的框架。软件工程是有创造力、有知识的人在定义好的、成熟的软件过程框架中进行的。9/19/2023151.4软件过程软件过程是近十年来人们软件过程软件过程层次图质量焦点过程方法工具9/19/202316软件过程软件过程层次图质量焦点过程方法工具8/6/20231软件过程

软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划：若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。若干不同任务的集合----每一个集合都由任务、里程碑、交付物以及质量保证点组成----使得框架活动适应于不同软件项目的特征和项目组的需求。若干保护性活动----如软件质量保证、软件配置管理、测试与度量----它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。9/19/202317软件过程软件过程提供了一个框架，在该框架下可软件过程里程碑、交付物SQA点公共过程框架框架活动保护性活动任务集合工作任务9/19/202318软件过程里程碑、交付物SQA点公共过程框架框架活动保护性活动软件过程软件过程可分为三大类：基本过程类：是构成软件生存周期主要部分的那些过程，包括获取、供应、开发、操作、维护等过程。支持过程类：可穿插到基本过程中提供支持的一系列过程，包括文档开发、配置管理、质量保证、验证、确认、联合评审、审计、问题解决等过程。组织过程类：一个组织用来建立、实施一种基础结构、并不断改进该基础结构的过程，包括管理、基础、改进、培训等过程。9/19/202319软件过程软件过程可分为三大类：8/6/202319软件过程模型软件过程模型是软件开发的指导思想和全局性框架，软件过程模型的提出和发展反映了人们对软件过程的某种认识观，体现了人们对软件过程认识的提高和飞跃。9/19/202320软件过程模型软件过程模型是软件开发的指什么是过程？软件工程中的目标就是开发和维护软件及相关产品NeworchangedrequirementsNeworchangedsystemSoftwareEngineeringProcess9/19/202321什么是过程？软件工程中的目标就是开发和维护软件及相关产品Ne当前主流的软件过程CMMRUPMSFXP9/19/202322当前主流的软件过程CMM8/6/202322过程铁三角过程：把各部分集成在一起－－CMM规程人技术和工具9/19/202323过程铁三角过程：把各部分集成在一起－－CMM规程人技术软件过程了解软件过程掌握软件过程模型:瀑布模型、原型模型、增量模型、迭代模型了解RUP了解XP9/19/202324软件过程了解软件过程8/6/202324过程过程就是针对某一给定目标的一系列运作步骤，[IEEE-STD-610]是在过程环境下的一系列有序活动。所谓活动（Activity）就是过程对象一次状态改变，也叫过程步(Step)。活动起始态和活动结果态表征了活动的进行。可以说一切事物的发生、发展、消亡都离不开过程，都寓于过程之中。9/19/202325过程过程就是针对某一给定目标的一系列运作步骤，[IEEE-S过程的一般定义9/19/202326过程的一般定义8/6/202326煮蛋的启示9/19/202327煮蛋的启示8/6/202327软件过程软件过程是将用户的需求转化成有效的软件解决方案的一系列活动。许多软件组织无法正确定义和控制这一过程，但这恰恰是组织改进的关键。9/19/202328软件过程软件过程是将用户的需求转化成有效的软件解决方案的一软件过程(Cont.)过程的好坏由结果状态与预期状态的差异决定，也就是目标成果质量的好坏。规程（Procedure）是人们对客观事物运动规律的理解和掌握，使规范了的过程。软件过程是为了获得高质量软件产品所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量的软件产品。9/19/202329软件过程(Cont.)过程的好坏由结果状态与预期状态的差异决软件过程(Cont.)软件过程又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。 早期： 立项、需求分析、设计、编码、 测试、交付、维护、退役9/19/202330软件过程(Cont.)软件过程又称软件生存周期过程，是软件生软件过程(Cont.)项目计划就是安排实际的过程，制作项目计划首先要定义过程。项目计划是某个软件过程模型的实例。软件过程是人类制作产物的一系列活动，而过去的软件工程师把产物和人分离，只研究产品过程及其质量，假定人力、物力资源是无限大、无限好。现在认识到面对实际资源实施软件过程学，求相对最佳质量才是有效的。9/19/202331软件过程(Cont.)项目计划就是安排实际的过程，制作项目计软件过程(Cont.)现在的软件生命周期过程包括： 早期：

立项、需求分析、设计、编码、 测试、交付、维护、退役 又加入了：

管理各种活动、质量保证 环境基础设施配置、文档管理等。

9/19/202332软件过程(Cont.)现在的软件生命周期过程包括：8/6/2软件开发—问题的循环解决过程状态描述问题定义技术开发方案综述9/19/202333软件开发—问题的循环解决过程状态描述8/6/202333软件开发过程为开发小组的活动顺序提供向导详细说明那些制品将被开发，以及什么时候开发指导每一个开发人员和整个开发组的工作为监控和度量项目的产品和活动提供准则9/19/202334软件开发过程为开发小组的活动顺序提供向导8/6/202334软件工程—方法学传统方法学面向对象的方法学9/19/202335软件工程—方法学传统方法学8/6/202335传统方法学(生命周期方法学)仍然是使用十分广泛的软件工程方法学。采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。从上而下，顺序地完成软件开发的各阶段任务。9/19/202336传统方法学(生命周期方法学)仍然是使用十分广泛的软件工程方法软件过程模型瀑布模型（Waterfall）原型模型（Prototype）增量模型（Incremental）螺旋模型（Spiral）迭代模型（Iterative）9/19/202337软件过程模型瀑布模型（Waterfall）8/6/2023瀑布模型(线性顺序模型)瀑布式模型包含以下活动：系统/信息工程和建模软件需求分析设计代码生成测试维护9/19/202338瀑布模型(线性顺序模型)瀑布式模型包含以下活动：8/6/20基本概念软件生存期（过程）模型：软件生存期是软件产品或系统一系列相关活动的全周期。从形成概念开始，经过研制，交付使用，在使用中不断增补修订，直到最后被淘汰，让位于新的软件产品的过程。对软件生存期的不同划分，形成了不同的软件生存期模型。9/19/202339基本概念软件生存期（过程）模型：8/6/202339软件工程的传统途径—生命周期方法学

生命周期方法学的基本内容从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶段的任务。

生命周期方法学的应用方法从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发；前一个阶段任务的完成是后一个阶段工作的前提和基础，而后一个阶段任务通常是使前一阶段提出的解法更进一步的具体化，加进了更多的实现细节。

阶段过渡方法每一个阶段的开始和结束都有严格标准，前一阶段结束的标准是后一阶段工作开始的标准。技术审查和管理复审。基本概念

文档及其作用。生命周期各阶段的基本任务

问题定义→可行性研究→需求分析→总体设计（概要设计）→详细设计→编码和单元测试→综合测试→软件维护。

9/19/202340软件工程的传统途径—生命周期方法学8/6/202340软件工程（生命周期各阶段的基本任务）问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护要解决的问题是什么？问题性质、工程目标和规模的报告分析员：实际用户+负责人是否有解决办法？分析员高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告为了解决的问题，目标系统必须做什么？准确确定系统的功能系统的逻辑模型（数据流图+数据字典+简要算法）如何解决这些问题模块划分软件结构如何具体地实现系统：每个模块的流程图（程序的详细规格说明）通过各种类型的测试，使软件达到预定的要求写出正确的容易理解和容易维护的程序模块通过各种必要的维护活动使系统持久地满足用户的需要9/19/202341软件工程（生命周期各阶段的基本任务）问题定义可行性研究需求分生命周期法各阶段的工作小结生命周期法各阶段的工作小结生命周期法各阶段的工作小结生命周期法各阶段的工作小结“生命周期法”的特点阶段具有顺序性和依赖性推迟实现的观点质量保证的观点每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。9/19/202344“生命周期法”的特点8/6/202344软件工程——瀑布模型瀑布模型

问题定义特点：1）阶段间具有顺序性和依赖性2）推迟实现的观点3）质量保证的观点。可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护软件定义时期软件开发时期软件维护时期9/19/202345软件工程——瀑布模型瀑布模型问题定义特点：1）阶段间具有顺软件开发过程模型瀑布模型的特征从上一项活动中接受该项活动的工作对象，作为输入。利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，作为输出传给下一项活动对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。9/19/202346软件开发过程模型瀑布模型的特征8/6/202346瀑布模型—特点文档驱动的模型阶段间具有顺序性和依赖性推迟实现的观点质量保证的观点9/19/202347瀑布模型—特点文档驱动的模型8/6/202347思考？？？？

传统瀑布模型存在什么问题？9/19/202348思考？？？？8/6/202348传统的瀑布模型—存在什么问题？？？

传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现出来。在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。9/19/202349传统的瀑布模型—存在什么问题？？？传统的瀑布模型过于理

TomGilb：

“假如你不积极地解决你项目中存在的风险，它们就会积极地解决掉你”瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时已无济于事。9/19/202350TomGilb：8/6/202350瀑布模型—问题实际项目很少按照该模型给出的顺序进行用户常常难以清楚地给出所有需求用户必须有耐心开发者常常被不必要地耽搁9/19/202351瀑布模型—问题实际项目很少按照该模型给出的顺序进行8/6软件开发过程模型瀑布模型的缺点：从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。9/19/202352软件开发过程模型瀑布模型的缺点：8/6/202352瀑布模型—实际的瀑布模型

需求分析验证规格说明验证设计验证编码测试综合测试维护变化的需求验证9/19/202353瀑布模型—实际的瀑布模型需求分析验证规格说明验证设计验软件开发过程模型具有维护循环的软件生存期的瀑布模型9/19/202354软件开发过程模型具有维护循环的软件生存期的瀑布模型8/6/2软件开发过程模型——原型模型基本思想在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。9/19/202355软件开发过程模型——原型模型基本思想8/6/202355原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。9/19/202356原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的原型模型—适用情况用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；……

原型模型可能是最好的选择

9/19/202357原型模型—适用情况用户定义了一组一般性目标，但不能标识出原型模型(Cont.)原型模型从需求收集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的。9/19/202358原型模型(Cont.)原型模型从需求收集开始。开发者和用户原型模型(Cont.)

快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程9/19/202359原型模型(Cont.)快速原型验证规格说明验证设计验证编原型模型—存在的问题用户似乎看到的是软件的工作版本，其实……开发者常常需要实现上的折衷，以使原型能够尽快工作9/19/202360原型模型—存在的问题用户似乎看到的是软件的工作版本，其实……原型模型在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。

9/19/202361原型模型在“需求分析”、“原型设计”两个阶段中，开发者和用户原型模型在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。9/19/202362原型模型在演示原型期间，用户可以根据他所期望的系统行为来评价原型模型特征原型特征软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征：(1)它是一个可实际运行的系统。9/19/202363原型模型特征原型特征8/6/202363原型模型特征(2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。9/19/202364原型模型特征(2)它没有固定的生存期。一种极端是扔掉原型（以原型模型特征(3)从需求分析到最终产品都可作原型，即可为不同目标作原型。(4)它必须快速、廉价。(5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。9/19/202365原型模型特征(3)从需求分析到最终产品都可作原型，即可为不同原型模型评价原型法的评价优点1.原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信。2.原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。3.原型给用户以机会更改心中原先设想的、不尽合理的最终系统。4.原型可低风险开发柔性较大的计算机系统。5.原型增加使系统更易维护、对用户更友好的机会。6.原型使总的开发费用降低，时间缩短。9/19/202366原型模型评价原型法的评价8/6/202366缺点1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。2.原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分。3.原型过快收敛于需求集合，而忽略了一些基本点。4.资源规划和管理较为困难，随时更新文档也带来麻烦。5.长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。原型模型评价9/19/202367缺点原型模型评价8/6/202367适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替代生存期的部分或全部阶段，具体可以用于以下领域：1.辅助分析和确定用户需求的任务。2.作为软件设计的一种工具。例如：研究系统设计的可行性和适应性。3.作为一种解决不确定性的工具。例如：研究一种新技术的效果，逐步使其适应预定的环境。4.作为一种实验工具。5.充作同步培训工具。6.“一次性”的应用。例如写一个能运行的程序，一旦得到答案，该程序将不再使用。7.作为软件维护的辅助工具。特别是在用户需求不稳定，维护工作量很大的情况下，要求大量的重新设计工作。原型模型评价9/19/202368适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替增量模型融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。9/19/202369增量模型融合了瀑布模型的基本成分和原型的迭代特征。采用随着日增量模型(Cont.)

需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户9/19/202370增量模型(Cont.)需求分析验证规格说明验证设计验证维增量模型(Cont.)分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2增量3增量49/19/202371增量模型(Cont.)分析分析分析分析设计设计设计设计编码增量模型(Cont.)增量模型融合了瀑布模型的基本成分和原型的迭代特性。例如，使用增量模型开发字处理软件基本的文件管理、编辑和文档生成功能。更完善的编辑和文档生成能力。实现拼写和文法检查功能。完成高级的页面布局功能。9/19/202372增量模型(Cont.)增量模型融合了瀑布模型的基本成分和原增量模型(Cont.)第一个增量往往是核心产品每一个增量均发布一个可操作产品早期的增量是最终产品的“可拆卸”版本9/19/202373增量模型(Cont.)第一个增量往往是核心产品8/6/20软件开发过程模型喷泉模型喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的。主要用于面向对象方法中9/19/202374软件开发过程模型喷泉模型8/6/202374软件开发过程模型——螺旋模型在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。9/19/202375软件开发过程模型——螺旋模型8/6/202375软件开发过程模型——螺旋模型9/19/202376软件开发过程模型——螺旋模型8/6/202376软件开发过程模型——螺旋模型9/19/202377软件开发过程模型——螺旋模型8/6/202377螺旋模型分析在螺旋模型结构中，维护只是螺旋模型的另一个周期，在维护和开发之间本质上并没有区别，从而解决了做太多测试或未作足够测试所带来的风险。适用条件内部的大规模软件的开发，不太适合合同软件。一般只适用于大规模软件的开发软件开发过程模型——螺旋模型9/19/202378螺旋模型分析软件开发过程模型——螺旋模型8/6/202378迭代模型建立在BarryBoehm的螺旋模型基础上的。9/19/202379迭代模型建立在BarryBoehm的螺旋模型基础上的。迭代模型(Cont.)9/19/202380迭代模型(Cont.)8/6/202380迭代模型(Cont.)PlanningRequirementsAnalysis&DesignImplementationDeploymentTestEvaluationManagementEnvironmentEachiterationresultsinanexecutablerelease.9/19/202381迭代模型(Cont.)PlanningRequirement9/19/2023828/6/202382RiskReductionTimeRiskWaterfallRiskIterativeRiskRiskProfiles9/19/202383RiskReductionTimeRiskWaterfal特点这种方法可以在生命周期早期强制性的确定项目中存在的风险。这种方法是一个连续地发现、创造和实现的过程。在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动项目制品的生产和制作。9/19/202384特点这种方法可以在生命周期早期强制性的确定项目中存在的风险提供解决方案：在生命周期的早期，这种方法可以及时地发现一些严重的需求理解错误，此时还可能修正这些错误。允许并鼓励用户反馈信息，以明确系统的真实需求。这种方法使开发小组重视项目中最关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。不断地迭代测试能够给出项目状况的客观评价。9/19/202385提供解决方案：在生命周期的早期，这种方法可以及时地发现一些严提供解决方案:(Cont.)尽早地发现需求、设计和实现中的不一致。在整个项目生命周期中更加平均地分配开发组的工作量，特别是测试小组的工作量。开发组可以不断打在开发中进行学习从而改进过程。在整个生命周期中，项目相关人员可以通过具体证据了解项目状况。9/19/202386提供解决方案:(Cont.)尽早地发现需求、设计和实现中的Review:软件过程模型瀑布模型原型模型增量模型螺旋模型迭代模型9/19/202387Review:软件过程模型瀑布模型8/6/202387软件开发问题的症状对于最终用户的需要理解得不够精确对需求的改变束手无策程序块不兼容软件不易维护或不易扩展对项目严重缺陷的发现较晚软件质量低劣软件性能令人无法接受开发组的人员按各自的方式进行开发，如果有人改变可部分软件，将很难进行重组一个不可靠的构造和发布过程9/19/202388软件开发问题的症状对于最终用户的需要理解得不够精确8/6/2SymptomsofSWDevelopmentProblemsUserorbusinessneedsnotmetRequirementschurnModulesdon’tintegrateHardtomaintainLatediscoveryofflawsPoorqualityorend-userexperiencePoorperformanceunderloadNocoordinatedteameffortBuild-and-releaseissues9/19/202389SymptomsofSWDevelopmentPro失败原因特别的需求管理模糊和不精确的交流脆弱的构架过度复杂未检测出需求、设计和实现之间的不一致测试的不足对于项目状况的评估过于主观未解决存在的风险无法控制变化的产生和传播自动控制不足9/19/202390失败原因特别的需求管理8/6/202390RUP现在软件产业界普遍认为，开发复杂软件项目必须采用基于UML的、以构架为中心、用例驱动与风险驱动相结合的迭代式增量开发过程，他是世界公认的开发复杂软件项目的最好过程，已经成为软件界的“圣经”。这一开发过程目前已经稳定、成熟。 这就是：9/19/202391RUP现在软件产业界普遍认为，开发复杂软件项目必须采用基于URUP

RUP—RationalUnifiedProcess9/19/202392RUP8/6/202392RationalUnifiedProcess—RUP Rational统一过程是由Rational软件公司开发和营销的一种软件工程过程，是开发组织用以分配与管理任务和职责的一种规范化方法。这个过程的目的是在预定的进度和预算范围内，开发出满足最终用户需要的高质量软件。9/19/202393RationalUnifiedProcess—RUP RUP捕获的6项最佳商业实践

被证明是解决软件开发过程中根本问题的方法控制变更迭代开发使用基于构件的架构管理需求可视化建模质量验证9/19/202394RUP捕获的6项最佳商业实践被证明是解决软件开发过程中根本最佳软件开发实践BestPractices迭代地开发软件DevelopIteratively管理需求ManageRequirements应用基于构件的构架UseComponentArchitectures为软件建立可视化的模型ModelVisually(UML)不断地验证软件质量ContinuouslyVerifyQuality控制软件的变更ManageChange9/19/202395最佳软件开发实践BestPractices迭代地开发软件RUP的目标按照预先制定的时间计划和经费预算，开发出高质量的软件产品以满足最终用户的需求9/19/202396RUP的目标按照预先制定的时间计划和经费预算，开发出高质量的RUP是什么？是一种软件工程过程是一个过程产品有自己的过程框架捕获了现代软件开发中的最佳实践9/19/202397RUP是什么？是一种软件工程过程8/6/202397RUP的三大特点用例驱动以架构为中心迭代和增量开发9/19/202398RUP的三大特点用例驱动8/6/202398用例驱动用UseCase作为划分问题的组织单元，分析和设计活动的局部粒度都遵循这一划分原则。UseCase的定义反映可系统外部要素根据特定目标使用拟建系统的状况，能确保问题的局部划分粒度适当，保持了全局与局部的平衡。9/19/202399用例驱动用UseCase作为划分问题的组织单元，分析和设计9/19/20231008/6/2023100RUP的整体架构9/19/2023101RUP的整体架构8/6/2023101RUP的迭代模型9/19/2023102RUP的迭代模型8/6/2023102RUP的关键概念9/19/2023103RUP的关键概念8/6/2023103RUPRUP将这些最佳实践活动以一种适当的形式结合起来，从而适应了广泛的项目和开发组织。RUP是一个过程产品(processproduct)。Rational(IBM)软件公司开发并维护着这个产品，并将其与Rational软件公司自己的一系列软件开发工具集成。9/19/2023104RUPRUP将这些最佳实践活动以一种适当的形式结合起来，从而RUPRUP有自己的过程框架(processframework),这个框架可以被改造和扩展以适应采纳此方法的组织。软件过程也是软件设计、开发、交付和维护9/19/2023105RUPRUP有自己的过程框架(processframeRUP—简要历史RUP2000RUP5.5RUP5.0ROP4.1ROP4.0Rational方法Objective过程3.8200019991998199719961995实时ROOM业务工程配置和变更管理需求学院Booch方法OMTUML0.8SQA过程UML1.1数据工程UI设计UML1.2基于WEB的开发UML1.39/19/2023106RUP—简要历史RUP2000RUP5.5RUP5.谁在使用RUP?电信业Ericsson、Alcatel、MCI交通、航空、国防Lockheed-Martin、BritishAerospace制造业Xerox、Volvo、Intel金融业Visa、MerrillLynch、Schwab系统集成业Ernst&Young、Oracle、Deloitte&Touche9/19/2023107谁在使用RUP?电信业8/6/2023107RUPRUP核心是解决可操作性问题，帮助开发人员尽可能少地依赖那些“不可描述的经验”。他详细给出了每个阶段参与该过程的各种焦色，然后表示在过程中，该角色创建的制品。9/19/2023108RUPRUP核心是解决可操作性问题，帮助开发人员尽可能少RationalUnifiedProcess的主要工件，及这些工件间的信息流9/19/2023109RationalUnifiedProcess的主要工件9/19/20231108/6/20231109/19/20231118/6/20231119/19/20231128/6/20231129/19/20231138/6/20231139/19/20231148/6/20231149/19/20231158/6/2023115增量和迭代开发基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。9/19/2023116增量和迭代开发基于风险前驱的原则，渐进地展开分析、设计及其相RUP二维过程结构沿时间轴的组织结构沿内容轴的组织结构9/19/2023117RUP二维过程结构沿时间轴的组织结构沿内容轴的组织结构8/RUP的生命开发周期9/19/2023118RUP的生命开发周期8/6/2023118RUP的生命开发周期9/19/2023119RUP的生命开发周期8/6/2023119RUP的生命开发周期9/19/2023120RUP的生命开发周期8/6/2023120RUP的生命开发周期9/19/2023121RUP的生命开发周期8/6/2023121主要困难多层次持续的规划与评估判断架构中关键风险的经验高效率的验证和评价手段多工种之间的频繁沟通多版本工作产品的管理

9/19/2023122主要困难多层次持续的规划与评估8/6/2023122基础保障核心人员必要的管理与技术经验自动化的验证和评价工具团队成员之间有高效的沟通工具软件配置与变更管理工具9/19/2023123基础保障核心人员必要的管理与技术经验8/6/2023123RUP的裁减RUP仅仅是一个通用的过程框架，需要根据实际情况裁减。9/19/2023124RUP的裁减RUP仅仅是一个通用的过程框架，需要根据实AProcessisnotEnoughtoBuildaSystem9/19/2023125AProcessisnotEnoughtoBuiXPXP（ExtremeProgramming），它是由KentBeck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历