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

《软件工程学概述共4学时课件.ppt》由会员分享，可在线阅读，更多相关《软件工程学概述共4学时课件.ppt（139页珍藏版）》请在三一办公上搜索。

1、2023/3/27,1,第1章 软件工程学概述（共4学时）,学习要求：1、了解软件危机产生的原因和消除软件危机的根本途径；2、掌握软件工程,软件工程学,软件生命周期和软件过程的概念；3、理解软件工程的基本原理；4、掌握常见的几种开发模型(过程)；,2023/3/27,2,第1章 软件工程学概述,1.1软件危机 软件危机的定义，产生原因，解决途径1.2软件工程 软件工程的概念、基本原理和软件工程方法学1.3软件的生命周期1.4软件过程 介绍瀑布模型、快速原型模型、增量模型、螺旋模型,2023/3/27,3,第1章 软件工程学概述,1.1 软件危机,1、20世纪60年代中期之前 软件规模小，编写和

2、应用在自己的小范围，软件=程序。,2、20世纪6070年代中期 出现“软件作坊”，软件的数量急剧膨胀，软件维护工作量和费用惊人增长，个别软件不可维护；软件危机出现。,一、软件危机及其表现,2023/3/27,4,1、什么是软件危机？,软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。（1）、如何开发软件满足用户的需要。（2）、如何维护大量的已有软件。,2、软件危机的典型表现,（1）、对软件开发的成本和进度估计常常不准确。,（2）、用户对“已完成”的软件系统不满意的现象常发生。,（3）、软件产品的质量时常靠不住。,（4）、软件常常不可维护。,（5）、软件没有适当的文档资料。,20

3、23/3/27,5,（6）、软件成本在计算机的系统总成本中所占的比列逐年上升。,（7）、软件开发的生产率提高的速度远远不及计算机应用普及的速度。,二、软件危机产生的原因,1、软件本身的特点有关（逻辑部件）,（1）、缺乏“可见性”，管理和控制软件开发的过程困难。,（2）、由于是逻辑部件，所以在使用过程中不会“用坏”。,2、软件开发与维护的方法有关,三、消除软件危机的途径,2023/3/27,6,1、软件危机可以被消灭吗？,不能消灭，因为：（1）、软件的特点没有改变（2）、用户的需求在不断的增长，任何软件从纵向来看不可能永远满足用户的需要，必然要出现软件危机。,2、消除软件危机的途径,（1）、对计

4、算机软件和软件开发有一个正确的认识。,（2）、技术措施 使用实践证明成功的技术和方法，开发和使用更好的软件工具。,2023/3/27,7,（3）、管理措施 使用科学的方法管理和组织计算机软件的开发。,1.2软件工程,一、软件工程的介绍,1、什么是软件工程？,采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间和实践证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就称为软件工程。,2、软件工程的特性,2023/3/27,8,（1）、软件工程关注于大型软件的构造,（2）、软件工程的中心课题是控制复杂性,（3）、软件经常变化,（4）、注重

5、开发软件的效率,（5）、和谐的合作是开发软件的关键,（6）、软件必须有效地支持它的用户的工作,（7）、在软件工程领域中是具有一种文化背景的替具有另一种文化背景的创造产品,二、软件工程的基本原理,B.W.Boehm在1983的一篇论文中提出了软件工程的7条基本原理。,2023/3/27,9,1、用分阶段的生命周期计划严格管理,2、坚持进行阶段评审,3、实行严格的产品控制,4、采用现代程序设计技术,5、结果应能清楚地审查,6、开发小组的成员应尽量少而精,7、承认不断改进软件工程实践的必要性,三、软件工程方法学,2023/3/27,10,1、什么是软件工程方法学？,通常把软件生命周期过程中使用的一整

6、套技术和方法的集合称为软件工程方法学，也称范型。,2、软件工程方法学的要素,（1）、方法 完成软件开发的各项任务的技术方法，“怎样做”。,（2）、工具 为运用方法而提供的软件支撑环境。,（3）、过程 为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。,2023/3/27,11,3、目前常用的软件工程方法学,（1）、传统方法学 又称为生命周期方法学或结构化范型。,（2）、面向对象方法学 它是以数据为主线，把数据和对数据的操作紧密地结合起来的方法学。A、把对象作为唯一的软件结构 B、把所有对象划分成类 C、按照父类与子类的关系，把相关类组成一个层次结构的系统 D、对

7、象之间只能通过发送消息相互联系,2023/3/27,12,1.3软件生命周期,一、软件生命周期,1、什么是软件生命周期？,软件从定义、开发、使用和维护，直到最终被废弃，所经历的漫长的时期称为软件的生命周期。,2、软件生命周期的若干阶段,（1）、软件定义时期 A、问题定义回答系统“要解决的问题是什么”。B、可行性研究回答“对上面确定的问题是否有行得通的解决办法”。,2023/3/27,13,C、需求分析 确定“为了解决这个问题，目标系统必须做什么”，即目标系统应该有那些功能。,（2）、开发时期,A、总体设计 解决“怎样实现目标系统？”。B、详细设计 解决“应该怎样具体实现目标系统？”。C、编码和

8、单元测试 写出正确、易理解和维护的程序模块。,2023/3/27,14,D、综合测试 通过各种类型的测试使软件达到预定的要求。,（3）、运行维护期 使软件持久满足用户的需要直到废弃。改正性维护：改正系统中存在的错误。适应性维护：使软件适应软硬件环境的变化。完善性维护：根据用户要求使软件更加完善。预防性维护：为将来的维护活动预先做准备。,2023/3/27,15,1.4软件过程,软件过程是近十年来人们关注的焦点。软件过程是为开发高质量软件所需要完成的任务的框架。软件工程是有创造力、有知识的人在定义好的、成熟的软件过程框架中进行的。,2023/3/27,16,软件过程,软件过程层次图,质量焦点,过

9、程,方法,工具,2023/3/27,17,软件过程,软件过程提供了一个框架，在该框架下可以建立一个软件开发的综合计划：若干框架活动适用于所有软件项目，而不在乎其规模和复杂性。若干不同任务的集合-每一个集合都由任务、里程碑、交付物以及质量保证点组成-使得框架活动适应于不同软件项目的特征和项目组的需求。若干保护性活动-如软件质量保证、软件配置管理、测试与度量-它们贯穿于整个过程模型之中。保护性活动独立于任何一个框架活动，且贯穿于整个过程之中。,2023/3/27,18,软件过程,里程碑、交付物,SQA点,公共过程框架,框架活动,保护性活动,任务集合,工作任务,2023/3/27,19,软件过程,软

10、件过程可分为三大类：基本过程类：是构成软件生存周期主要部分的那些过程，包括获取、供应、开发、操作、维护等过程。支持过程类：可穿插到基本过程中提供支持的一系列过程，包括文档开发、配置管理、质量保证、验证、确认、联合评审、审计、问题解决等过程。组织过程类：一个组织用来建立、实施一种基础结构、并不断改进该基础结构的过程，包括管理、基础、改进、培训等过程。,2023/3/27,20,软件过程模型,软件过程模型是软件开发的指导思想和全局性框架，软件过程模型的提出和发展反映了人们对软件过程的某种认识观，体现了人们对软件过程认识的提高和飞跃。,2023/3/27,21,什么是过程？,软件工程中的目标就是开发

11、和维护软件及相关产品,2023/3/27,22,当前主流的软件过程,CMMRUPMSFXP,2023/3/27,23,过程铁三角,过程：把各部分集成在一起 CMM,2023/3/27,24,软件过程,了解软件过程掌握软件过程模型:瀑布模型、原型模型、增量模型、迭代模型了解RUP了解XP,2023/3/27,25,过程,过程就是针对某一给定目标的一系列运作步骤，IEEE-STD-610 是在过程环境下的一系列有序活动。所谓活动（Activity）就是过程对象一次状态改变，也叫过程步(Step)。活动起始态和活动结果态表征了活动的进行。可以说一切事物的发生、发展、消亡都离不开过程，都寓于过程之中。

12、,2023/3/27,26,过程的一般定义,2023/3/27,27,煮蛋的启示,2023/3/27,28,软件过程,软件过程是将用户的需求转化成有效的软件解决方案的一系列活动。许多软件组织无法正确定义和控制这一过程，但这恰恰是组织改进的关键。,2023/3/27,29,软件过程(Cont.),过程的好坏由结果状态与预期状态的差异决定，也就是目标成果质量的好坏。规程（Procedure）是人们对客观事物运动规律 的理解和掌握，使规范了的过程。软件过程是为了获得高质量软件产品所需要完 成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件过程必须科学、合理，才能开发出高质量 的软件产品。,2

13、023/3/27,30,软件过程(Cont.),软件过程又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。早期：立项、需求分析、设计、编码、测试、交付、维护、退役,2023/3/27,31,软件过程(Cont.),项目计划就是安排实际的过程，制作项目计划首先要定义过程。项目计划是某个软件过程模型的实例。软件过程是人类制作产物的一系列活动，而过去的软件工程师把产物和人分离，只研究产品过程及其质量，假定人力、物力资源是无限大、无限好。现在认识到面对实际资源实施软件过程学，求相对最佳质量才是有效的。,2023/3/27,32,软件过程(Cont.),现在的软件生命

14、周期过程包括：早期：立项、需求分析、设计、编码、测试、交付、维护、退役又加入了：管理各种活动、质量保证环境基础设施配置、文档管理等。,2023/3/27,33,软件开发问题的循环解决过程,状态描述问题定义技术开发方案综述,2023/3/27,34,软件开发过程,为开发小组的活动顺序提供向导详细说明那些制品将被开发，以及什么时候开发指导每一个开发人员和整个开发组的工作为监控和度量项目的产品和活动提供准则,2023/3/27,35,软件工程 方法学,传统方法学面向对象的方法学,2023/3/27,36,传统方法学(生命周期方法学),仍然是使用十分广泛的软件工程方法学。采用结构化技术来完成软件开发的

15、各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。从上而下，顺序地完成软件开发的各阶段任务。,2023/3/27,37,软件过程模型,瀑布模型（Waterfall）原型模型（Prototype）增量模型（Incremental）螺旋模型（Spiral）迭代模型（Iterative）,2023/3/27,38,瀑布模型(线性顺序模型),瀑布式模型包含以下活动：系统/信息工程和建模软件需求分析设计代码生成测试维护,2023/3/27,39,基本概念,软件生存期（过程）模型：软件生存期是软件产品或系统一系列相关活动的全周期。从形成概念开始，经过研制，交付使用，在使用中不断增补修订，

16、直到最后被淘汰，让位于新的软件产品的过程。对软件生存期的不同划分，形成了不同的软件生存期模型。,2023/3/27,40,软件工程的传统途径生命周期方法学,生命周期方法学的基本内容 从时间角度对软件开发和维护的复杂问题进行分解，把软件生命的漫长周 期依次划分为若干个阶段，每个阶段有相对独立的任务，然后逐步完成每个阶 段的任务。生命周期方法学的应用方法 从对任务的抽象逻辑分析开始，一个阶段一个阶段地进行开发；前一个阶段任 务的完成是后一个阶段工作的前提和基础，而后一个阶段任务通常是使前一阶 段提出的解法更进一步的具体化，加进了更多的实现细节。阶段过渡方法 每一个阶段的开始和结束都有严格标准，前一

17、阶段结束的标准是后一阶段工作 开始的标准。技术审查和管理复审。基本概念 文档及其作用。生命周期各阶段的基本任务 问题定义可行性研究 需求分析 总体设计（概要设计）详细设计 编码和单元测试 综合测试 软件维护。,软件工程（生命周期各阶段的基本任务）,问题定义,可行性研究,需求分析,总体设计,详细设计,编码与单元测试,综合测试,软件维护,要解决的问题是什么？,问题性质、工程目标和规模的报告,分析员：实际用户+负责人,是否有解决办法？,分析员,高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告,为了解决的问题，目标系统必须做什么？准确确定系统的功能,系统的逻辑模型（数据流图+数据字

18、典+简要算法）,如何解决这些问题,模块划分软件结构,如何具体地实现系统：每个模块的流程图（程序的详细规格说明）,通过各种类型的测试，使软件达到预定的要求,写出正确的容易理解和容易维护的程序模块,通过各种必要的维护活动使系统持久地满足用户的需要,生命周期法各阶段的工作小结,生命周期法各阶段的工作小结,2023/3/27,44,“生命周期法”的特点,阶段具有顺序性和依赖性推迟实现的观点质量保证的观点每个阶段都必须完成规定的文档每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。,2023/3/27,45,软件工程瀑布模型,瀑布模型,问题定义,特点：1）阶段间具有顺序性和依赖性 2

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

20、3/27,49,传统的瀑布模型 存在什么问题？,传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。在设计阶段可能发生规格说明文档中的错误。而设计上的缺陷或错误可能在实现过程中显现出 来。在综合测试阶段将发现需求分析、设计或编码阶段 的许多错误。,2023/3/27,50,Tom Gilb：“假如你不积极地解决你项目中存在的风险，它们就会积极地解决掉你”瀑布方法会掩饰项目中真正的风险，当你太晚发现它们时已无济于事。,2023/3/27,51,瀑布模型 问题,实际项目很少按照该模型给出的顺序进行用户常常难以清楚地给出所有需求用户必须有耐心开发者常常被不必要地耽搁,2023/3/27

21、,52,软件开发过程模型,瀑布模型的缺点：从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。,2023/3/27,53,瀑布模型 实际的瀑布模型,需求分析,验证,规格说明,验证,设计,验证,编码,测试,综合测试,维护,变化的需求,验证,2023/3/27,54,软件开发过程模型,具有维护循环的软件生存期的瀑布模型,2023/3/27,55,软件开发过程模型原型模型,基本思想在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立

22、一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。,2023/3/27,56,原型模型,快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。,2023/3/27,57,原型模型 适用情况,用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式；原型模型可能是最好的选择,2023/3/27,58,原型模型(C

23、ont.),原型模型从需求收集开始。开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。原型由用户评估，并进一步精化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的。,2023/3/27,59,原型模型(Cont.),快速原型,验证,规格说明,验证,设计,验证,编码,测试,综合测试,维护,变化的需求,验证,维护过程,开发过程,2023/3/27,60,原型模型存在的问题,用户似乎看到的是软件的工作版本，其实开发者常常需

24、要实现上的折衷，以使原型能够尽快工作,2023/3/27,61,原型模型,在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。,2023/3/27,62,原型模型,在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。

25、在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。,2023/3/27,63,原型模型特征,原型特征软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征：(1)它是一个可实际运行的系统。,2023/3/27,64,原型模型特征,(2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其

26、中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。,2023/3/27,65,原型模型特征,(3)从需求分析到最终产品都可作原型，即可为不同目标作原型。(4)它必须快速、廉价。(5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。,2023/3/27,66,原型模型评价,原型法的评价优点1.原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信。2.原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。3.原型给用户以机会更改心中原先设想的、不尽合理的最终系统。4.原型可低风险开发柔性较大的计算机系统。5.原型增

27、加使系统更易维护、对用户更友好的机会。6.原型使总的开发费用降低，时间缩短。,2023/3/27,67,缺点1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。2.原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分。3.原型过快收敛于需求集合，而忽略了一些基本点。4.资源规划和管理较为困难，随时更新文档也带来麻烦。5.长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。,原型模型评价,2023/3/27,68,适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替代生存

28、期的部分或全部阶段，具体可以用于以下领域：1.辅助分析和确定用户需求的任务。2.作为软件设计的一种工具。例如：研究系统设计的可行性和适应性。3.作为一种解决不确定性的工具。例如：研究一种新技术的效果，逐步使其适应预定的环境。4.作为一种实验工具。5.充作同步培训工具。6.“一次性”的应用。例如写一个能运行的程序，一旦得到答案，该程序将不再使用。7.作为软件维护的辅助工具。特别是在用户需求不稳定，维护工作量很大的情况下，要求大量的重新设计工作。,原型模型评价,2023/3/27,69,增量模型,融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。,2023/3/27

29、,70,增量模型(Cont.),需求分析,验证,规格说明,验证,设计,验证,维护,针对每个构件完成详细设计、编码和集成，经测试后交付给用户,2023/3/27,71,增量模型(Cont.),分析,分析,分析,分析,设计,设计,设计,设计,编码,编码,编码,编码,测试,测试,测试,测试,增量1,增量2,增量3,增量4,2023/3/27,72,增量模型(Cont.),增量模型融合了瀑布模型的基本成分和原型的迭代特性。例如，使用增量模型开发字处理软件基本的文件管理、编辑和文档生成功能。更完善的编辑和文档生成能力。实现拼写和文法检查功能。完成高级的页面布局功能。,2023/3/27,73,增量模型(

30、Cont.),第一个增量往往是核心产品每一个增量均发布一个可操作产品早期的增量是最终产品的“可拆卸”版本,2023/3/27,74,软件开发过程模型,喷泉模型喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的。主要用于面向对象方法中,2023/3/27,75,软件开发过程模型螺旋模型,在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。,2023/3/27,76,软件开发过程模型螺旋模型,2023/3/27,77,软件开发过程模型螺旋模型,2023/3/27,78,螺旋模型分析在螺旋模型结构中，维护只是螺旋模型的另一个周期，在维护和开发之间本质上并没有区别，从而解决了做太多测试或

31、未作足够测试所带来的风险。适用条件内部的大规模软件的开发，不太适合合同软件。一般只适用于大规模软件的开发,软件开发过程模型螺旋模型,2023/3/27,79,迭代模型,建立在Barry Boehm 的螺旋模型基础上的。,2023/3/27,80,迭代模型(Cont.),2023/3/27,81,迭代模型(Cont.),Each iteration results in an executable release.,2023/3/27,82,2023/3/27,83,Time,Risk,Waterfall Risk,Risk Profiles,2023/3/27,84,特点,这种方法可以在生命周

32、期早期强制性的确定项目中存在的风险。这种方法是一个连续地发现、创造和实现的过程。在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动项目制品的生产和制作。,2023/3/27,85,提供解决方案：,在生命周期的早期，这种方法可以及时地发现一些严重的需求理解错误，此时还可能修正这些错误。允许并鼓励用户反馈信息，以明确系统的真实需求。这种方法使开发小组重视项目中最关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。不断地迭代测试能够给出项目状况的客观评价。,2023/3/27,86,提供解决方案:(Cont.),尽早地发现需求、设计和实现中的不一致。在整个项目生命周期中更加平均地分配开发

33、组的工作量，特别是测试小组的工作量。开发组可以不断打在开发中进行学习从而改进过程。在整个生命周期中，项目相关人员可以通过具体证据了解项目状况。,2023/3/27,87,Review:软件过程模型,瀑布模型原型模型增量模型螺旋模型迭代模型,2023/3/27,88,软件开发问题的症状,对于最终用户的需要理解得不够精确对需求的改变束手无策程序块不兼容软件不易维护或不易扩展对项目严重缺陷的发现较晚软件质量低劣软件性能令人无法接受开发组的人员按各自的方式进行开发，如果有人改变可部分软件，将很难进行重组一个不可靠的构造和发布过程,2023/3/27,89,Symptoms of SW Developm

34、ent Problems,User or business needs not metRequirements churnModules dont integrateHard to maintainLate discovery of flawsPoor quality or end-user experiencePoor performance under loadNo coordinated team effortBuild-and-release issues,2023/3/27,90,失败原因,特别的需求管理模糊和不精确的交流脆弱的构架过度复杂未检测出需求、设计和实现之间的不一致测试的不

35、足对于项目状况的评估过于主观未解决存在的风险无法控制变化的产生和传播自动控制不足,2023/3/27,91,RUP,现在软件产业界普遍认为，开发复杂软件项目必须采用基于UML的、以构架为中心、用例驱动与风险驱动相结合的迭代式增量开发过程，他是世界公认的开发复杂软件项目的最好过程，已经成为软件界的“圣经”。这一开发过程目前已经稳定、成熟。这就是：,2023/3/27,92,RUP,RUPRational Unified Process,2023/3/27,93,Rational Unified ProcessRUP,Rational 统一过程是由Rational 软件公司开发和营销的一种软件工程

36、过程，是开发组织用以分配与管理任务和职责的一种规范化方法。这个过程的目的是在预定的进度和预算范围内，开发出满足最终用户需要的高质量软件。,2023/3/27,94,RUP捕获的6项最佳商业实践,被证明是解决软件开发过程中根本问题的方法,2023/3/27,95,最佳软件开发实践 Best Practices,迭代地开发软件 Develop Iteratively管理需求 Manage Requirements应用基于构件的构架 Use Component Architectures为软件建立可视化的模型 Model Visually(UML)不断地验证软件质量 Continuously Ver

37、ify Quality控制软件的变更 Manage Change,2023/3/27,96,RUP的目标,按照预先制定的时间计划和经费预算，开发出高质量的软件产品以满足最终用户的需求,2023/3/27,97,RUP是什么？,是一种软件工程过程是一个过程产品有自己的过程框架捕获了现代软件开发中的最佳实践,2023/3/27,98,RUP的三大特点,用例驱动以架构为中心迭代和增量开发,2023/3/27,99,用例驱动,用Use Case作为划分问题的组织单元，分析和设计活动的局部粒度都遵循这一划分原则。Use Case的定义反映可系统外部要素根据特定目标使用拟建系统的状况，能确保问题的局部划分

38、粒度适当，保持了全局与局部的平衡。,2023/3/27,100,2023/3/27,101,RUP的整体架构,2023/3/27,102,RUP的迭代模型,2023/3/27,103,RUP的关键概念,2023/3/27,104,RUP,RUP将这些最佳实践活动以一种适当的形式结合起来，从而适应了广泛的项目和开发组织。,RUP 是一个过程产品(process product)。Rational(IBM)软件公司开发并维护着这个产品，并将其与Rational 软件公司自己的一系列软件开发工具集成。,2023/3/27,105,RUP,RUP 有自己的过程框架(process framework)

39、,这个框架可以被改造和扩展以适应采纳此方法的组织。,软件过程也是软件设计、开发、交付和维护,2023/3/27,106,RUP 简要历史,RUP 2000,RUP 5.5,RUP 5.0,ROP 4.1,ROP 4.0,Rational 方法,Objective 过程3.8,200019991998199719961995,实时,ROOM,业务工程,配置和,变更管理,需求学院,Booch 方法,OMT,UML 0.8,SQA 过程,UML 1.1,数据工程,UI 设计,UML 1.2,基于WEB的开发,UML1.3,2023/3/27,107,谁在使用RUP?,电信业Ericsson、Alca

40、tel、MCI 交通、航空、国防Lockheed-Martin、British Aerospace制造业Xerox、Volvo、Intel金融业Visa、Merrill Lynch、Schwab 系统集成业Ernst&Young、Oracle、Deloitte&Touche,2023/3/27,108,RUP,RUP核心是解决可操作性问题，帮助开发人员尽可能少地依赖那些“不可描述的经验”。他详细给出了每个阶段参与该过程的各种焦色，然后表示在过程中，该角色创建的制品。,2023/3/27,109,Rational Unified Process 的主要工件，及这些工件间的信息流,2023/3/2

41、7,110,2023/3/27,111,2023/3/27,112,2023/3/27,113,2023/3/27,114,2023/3/27,115,2023/3/27,116,增量和迭代开发,基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。,2023/3/27,117,RUP 二维过程结构,沿时间轴的组织结构,沿内容轴的组织结构,2023/3/27,118,RUP的生命开发周期,2023/3/27,119,RUP的生命开发周期,2023/3/27,120,RUP的生命开发周期,2023/3/27,121,RUP的生命开发周期

42、,2023/3/27,122,主要困难,多层次持续的规划与评估判断架构中关键风险的经验高效率的验证和评价手段多工种之间的频繁沟通多版本工作产品的管理,2023/3/27,123,基础保障,核心人员必要的管理与技术经验自动化的验证和评价工具团队成员之间有高效的沟通工具软件配置与变更管理工具,2023/3/27,124,RUP 的裁减,RUP 仅仅是一个通用的过程框架，需要根据实际情况裁减。,2023/3/27,125,A Process is not Enough to Build a System,2023/3/27,126,XP,XP（Extreme Programming），它是由Kent

43、 Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。,2023/3/27,127,XP是什么？,敏捷方法的代表。Kent Beck在他的开篇之作Extreme Programming Explained Embrace Change中提出97年一种高度动态的过

44、程，它通过非常短的迭代周期来应对软件开发中的变化强调有效测试和演化设计fowler,2023/3/27,128,XP的目标,在规定的时间生产出满足客户需要的软件,2023/3/27,129,什么时候需要XP？,需求不明确、变化快高风险：在特定的时间内，面对一个相当难开发的系统 中小型团队（人数不超过10 个）,2023/3/27,130,XP的系统隐喻,2023/3/27,131,XP体现四个价值目标,沟通（communication）简化（simlicity）反馈（feedback）勇气（courage）,2023/3/27,132,XP的12个核心实践,规划策略(Planning game

45、)系统隐喻(System Metaphor)简单设计(Simple design)配对编程(pair programming)编码标准(Coding standards)测试驱动(Test-driven)重构（Refactoring）持续集成(Continuous integration)小发行版(Small releases)现场客户(On-site customer)集体代码所有权(Collective ownership)一周40小时(40-hour week),2023/3/27,133,实践之间的互相支持,2023/3/27,134,XP项目的状态图,2023/3/27,135,XP

46、的计划/反馈循环,2023/3/27,136,从CMM角度看XP,XP部分满足或大部分满足了CMM 2-3 级KPA 的要求，而基本上没有涉及CMM 4-5 级的KPAXP 侧重于具体的过程和开发技术，而CMM 更关注组织和管理上的问题 XP 缺少的一个重要内容是“institutionalization”-Mark Paulk,SEI,2023/3/27,137,XP vs.RUP,2023/3/27,138,对XP的置疑,技术前提：对变化成本曲线的置疑 技艺前提：对于有经验的人是简单的代码，对没有经验的人是复杂的 社会结构前提：程序员可以能否对自己的开发过程承担责任,2023/3/27,139,不适用于XP的场合,不能接受XP 文化的组织 中大型（超过10 个人）的团队 重构会导致大量开销的应用 需要很长的编译或测试周期的系统 不太容易测试的应用 人员异地分布的物理环境 Beck,