软件工程1-3.过程模型.ppt

《软件工程1-3.过程模型.ppt》由会员分享，可在线阅读，更多相关《软件工程1-3.过程模型.ppt（91页珍藏版）》请在三一办公上搜索。

1、软件工程,第一部分 软件过程 第3章 惯例过程模型Chapter 3 Prescriptive Process ModelsPrescriptive：giving directives or rulesprescriptive a.规定的，指示的；约定俗成的,1968 年正式提出“软件工程”这一术语之后，软件工程围绕计算机科学、工程和管理三个方面，做了很多研究，建立了早期关于软件工程管理的一些基本准则，从中，我们可以看出早期软件工程的一些思路与出发点。其中最著名的是著名软件工程专家B.W.Boehm 在1983 年的一篇论文中，提出的软件工程7 条基本原理，反映了作为软件工程应该关注和考虑的若

2、干本质问题：,软件工程的基本原理,（1）用分阶段的生命周期计划严格管理经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。Boehm认为，在软件的整个生命周期中应制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。（2）坚持进行阶段评审大部分错误是在编码之前造成的错误发现与改正得越晚，所需付出的代价越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程的错误,软件工程的基本原理,（3）实行严格的产品控制在软件开发过程中不要随意改变需求，因为改变某项需求往往需要付出较高的代价，但在实践中用户往往会提出需求变更，因此需要采取科

3、学的产品控制技术。目前主要实行基准配置管理：基准配置是指经过阶段评审后的软件配置成分，如各个阶段产生的文档或程序代码。对涉及基准配置的修改，必须经过严格的评审，通过后才能实施修改。（4）采用现代程序设计技术实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。80年代及之前：结构化分析、设计技术90年代：面向对象分析、设计技术,软件工程的基本原理,（5）结果应能清楚地审查软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，使所得的结果能够清楚地审查（6）开发小组的人员应该少而精开发小组人员的素质和数量是

4、影响软件产品质量和开发效率的重要因素。开发小组人员数目的增加，使相互交流复杂、费用增加。（7）承认不断改进软件工程实践的必要性遵循前6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但不能保证赶上时代前进的步伐。积极主动采纳新的软件技术，且不断总结经验。,软件工程的基本原理,惯例过程模型通常称为“传统的”过程模型回顾通用过程框架（包含哪些框架活动？）下面我们要讨论一些惯例过程模型,3.1 惯例过程模型,模型应用背景：在可以相当清楚地了解问题的需求，从沟通到部署，工作可按线性的方式进行。在对一个已有系统进行明确的调整或增强时（如税法修改了起征点，财务软件需要进行相应修改）；需求能

5、准确定义并且相对稳定的新项目（如老师布置的大作业）。,3.2 瀑布模型,3.2 瀑布模型,基于通用过程框架的瀑布模型,沟通项目启动需求获取,策划项目估算进度计划项目跟踪,建模分析设计,构建编码测试,部署交互支持反馈,The Waterfall Model,3.2 瀑布模型,瀑布模型的另一个图示传统的生命周期模型70年由Royce提出典型瀑布模型具有顺序性和依赖性,瀑布模型的特征从上一项活动中接受该项活动的工作成果（工作产品），作为输入。利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，作为输出传给下一项活动对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。,3.2 瀑

6、布模型,瀑布模型的优点：1.强调开发的阶段性；2.强调早期计划及需求调查；3.强调产品测试。,3.2 瀑布模型,瀑布模型的缺点：从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。特别是瀑布模型过于依赖早期进行的唯一一次需求调查，不能适应需求的变化；软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。特别是由于瀑布模型是单一流程，开发中的经验教训不能反馈应用于本产品的过程。,3.2 瀑布模型,瀑布模型造成软件错误的积累和放大效应,思考：1、我们的日常生活中，有哪些活动是符合瀑布模型的？2、为什

7、么有时候我们的小型开发团队连瀑布模型都不能坚持做到？客观因素是什么？3、瀑布模型的实用之地在哪里？,3.2 瀑布模型,模型应用背景：在许多情况下，初始的软件需求有明确的定义，但整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再细化和扩展功能。两种增量过程模型：增量模型、RAD模型,3.3 增量过程模型,增量模型以迭代的方式运用瀑布模型。随着时间的推移，增量模型在每个阶段运用线性序列。每个线性序列生产出一个软件的可交付增量。增量模型又称产品改进模型（Incremental Model）当使用增量模型时，第一个增量往往是核心的产品，即实现

8、了基本的需求，但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。核心产品交用户使用(或进行更详细的复审)，使用和/或评估的结果是下一个增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。,3.3.1 增量模型,3.3.1 增量模型,项目时间,软件功能和特征,增量模型,例如，使用增量模型开发的字处理软件，可能在第一个增量中发布基本的文件管理、编辑和文档生成功能；在第二个增量中发布更加完善的编辑和文档生成能力；第三个增量实现拼写和文法检查功能；第四个增量完成高级的页面布局功能

9、。,3.3.1 增量模型,增量模型特点增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。应该注意：任何增量的过程流均可以使用原型范型。增量过程模型，像原型和其他演化方法一样，具有迭代的特征。但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功能，并且提供了给用户评估的平台。,3.3.1 增量模型,增量模型应用举例如果在项目既定的商业要求期限之前不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增

10、量可以由较少的人员实现。如果核心产品的口碑不错，可以为下一个增量投入更多的人力(如果需要的话)。此外，增量能够有计划地管理技术风险，例如，一个系统需要用到某个正在开发的新硬件，而这个新硬件的交付日期不确定。因此可以在早期的增量中避免使用这个硬件，这样，就可以保证部分功能按时交付给最终用户，不至于造成过分的延期。,3.3.1 增量模型,RAD模型RAD（快速应用开发）模型是一个增量型的软件开发过程模型，强调极短的开发周期。该模型是瀑布模型的一个“高速”变种，通过大量使用可复用构件，采用基于构件的建造方法赢得了快速开发。如果正确地理解了需求，而且约束了项目的范围，利用这种模型可以很快创建出功能完善

11、的信息系统。其流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试及反复。,3.3.2 RAD模型,RAD模型,3.3.2 RAD模型,RAD模型与瀑布模型相比，RAD模型不采用传统的第3代程序设计语言来创建软件，而是采用基于构件的开发方法复用已有的程序结构（如果可能）或使用可复用构件和或创建可复用的构件（如果需要）。在所有情况下，均使用自动化工具辅助软件创造。很显然，加在一个RAD模型项目上的时间约束需要“一个可伸缩的范围”。如果一个业务能够被模块化使得其中每一个主要功能均可以在不到3个月的时间内完成，则其是RAD的一个候选者。每一个主要功能可由一个单独的RAD组来实现，最后集成起来

12、形成一个整体。,3.3.2 RAD模型,RAD模型RAD模型通过大量使用可复用构件加快了开发速度，对信息系统的开发特别有效。但是与所有其他软件过程模型一样，RAD方法有如下缺陷。并非所有应用都适合RAD。RAD模型对模块化要求比较高，如果有哪一个功能不能被模块化，那么建造RAD所需要的构件就会有问题。如果高性能是一个指标且该指标必须通过调整接口使其适应系统构件才能赢得，RAD方法也有可能不能奏效。开发人员和客户必须在很短的时间内完成一系列的需求分析，任何一方配合不当都会导致RAD项目失败。RAD只能用于信息系统开发，不适合技术风险很高的情况。当一个新应用要采用很多新技术或当新软件要求与已有的计

13、算机程序的高互操作性时，这种情况就会发生。,3.3.2 RAD模型,模型应用背景：在开发过程中，业务和产品需求经常发生变化，直接导致最终产品难以实现；严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。演化模型是迭代的过程模型。三种增量过程模型：原型开发、螺旋模型、协同开发模型。,3.4 演化过程模型,3.4.1 原型开发,模型应用背景：客户提出了软件的一些基本功能，但是没有详细定义输入、处理和输出需求；开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况不确定。

14、在这些情况下，原型开发模型是不错的解决办法。虽然原型开发模型可以作为一个独立的过程模型，但是更多时候是作为一种技术应用在其他过程模型中。当用户需求模糊时，原型开发模型帮助软件工程师和客户更好地理解究竟需要做什么。,快速建立原型的目的，是获取需求,3.4.1 原型开发,沟通,策划快速策划,建模快速分析设计,构建构建原型,部署部署交付品及反馈,原型开发模型,快速建立原型的目的，是获取需求,3.4.1 原型开发,communication,Quickplan,ModelingQuick design,Constructionof prototype,Deploymentdelivery&feedba

15、ck,快速建立原型的目的，是获取需求,3.4.1 原型开发,应用原型开发模型需要注意：在“需求分析”阶段，开发团队和用户一起为想象中的系统的某些主要部分，定义需求和规格说明，并由开发团队在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括哪些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。通过演示原型，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发团队重新定义需求。,3.4.1 原型开发,该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和

16、开发团队都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发团队是否理解了用户的意思，同时试验实现它们的若干方法。有了满意的系统原型，同时也积累了使用原型的经验，用户常会提出新目标，从而进一步重新原型周期。新目标的范围要比修改或补充不满意的原型大。,3.4.1 原型开发,原型开发模型的特点软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、反映最后软件的主要特征的系统。它具有以下特征：(1)它是一个可实际运行的系统。(2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但在产品中并不使用这些模块）；另一种极端是最终产品

17、的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。,3.4.1 原型开发,(3)从需求分析到最终产品都可作原型，即可为不同目标作原型。(4)它必须快速、廉价。(5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。,3.4.1 原型开发,5.对原型法的评价优点任何功能一经开发就能进入测试以便验证是否符合产品需求。帮助导引出高质量的产品要求。如果没有可能在一开始就弄清楚所有的产品需求，它们可以分批取得。而对于已提出的产品需求，则可根据对现阶段原型的试用而做出修改。风险管理可以在早期就获得项目

18、进程数据，可据此对后续的开发循环做出比较切实的估算。提供机会去采取早期预防措施，增加项目成功的机率。大大有助于早期建立产品开发的配置管理，产品构建（build），自动化测试，缺陷跟踪，文档管理。均衡整个开发过程的负荷。,3.4.1 原型开发,开发中的经验教训能反馈应用于本产品的下一个循环过程，大大提高质量与效率。如果风险管理发现资金或时间已超出可承受的程度，则可以决定调整后续的开发，或在一个适当的时刻结束开发，但仍然有一个具有部分功能的，可工作的产品。心理上，开发人员早日见到产品的雏型，是一种鼓舞。使用户可以在新的一批功能开发测试后，立即参加验证，以便提供非常有价值的反馈。可使销售工作有可能提

19、前进行，因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。,3.4.1 原型开发,主要缺点客户看到了软件的工作版本，但不知道整个软件是用“口香糖和包装带”搭成的，也不知道为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。当开发者告诉客户整个系统需要重建以提高软件质量的时候，客户会不满意，并且要求对软件稍加修改使其变成一个可以运行的产品。因此，软件开发管理往往陷入失效。开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。他们经常使用不合适的操作系统或程序设计语言，仅仅是因为当时可用、熟悉。他们也经常采用一种低效的算法，仅为了证明系统的能力。时间

20、长了，开发者可能使用折中选择，而忽略了这些选择其实并不适合的理由，造成并不完美的选择变成了系统的组成部分。,3.4.1 原型开发,尽管原型开发有一些缺点，但仍是一个有效的模型。关键是要在游戏开始的时候制定规则：客户和开发者必须认同原型是为定义需求服务的；要丢弃原型（至少是部分丢弃），实际的软件系统以质量为第一目标。,3.4.1 原型开发,问题：请举例一个适合采用原型开发模型的软件项目。,3.4.1 原型开发,3.4.1 原型开发,螺旋模型 最早由Boehm提出，是一种演进示软件过程模型。结合了原型的迭代特性和普遍模型的系统性和可控性特点。在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模

21、型。具有快速开发越来越完善软件版本的潜力。Boehm这样描述螺旋模型：,3.4.2 螺旋模型,3.4.2 螺旋模型,基于通用框架活动的螺旋模型,3.4.2 螺旋模型,五、螺旋模型 英文版。,3.4.2 螺旋模型,五、螺旋模型 英文版。,3.4.2 螺旋模型,螺旋模型分析其他过程模型在软件交付后就结束了。螺旋模型则不同，它应用在计算机软件的整个生命周期。螺旋上的第一圈表示“概念开发项目”，它起始于螺旋的中心，经过多个迭代，直到概念开发结束。如果这个概念将被开发成实际的产品，过程模型将继续沿着螺旋向外伸展，此时成为“新产品开发项目”。新产品可能沿着螺旋通过一系列的迭代不断演进。最后，可以用一圈螺旋

22、表示“产品提高项目”。本质上，当螺旋模型以这种方式进行下去的时候，它将永远保持可操作性，直到软件产品的生命周期结束。,3.4.2 螺旋模型,螺旋模型优点螺旋模型是开发大型系统和软件的理想方法。由于软件随着过程的推进而变化，在每一个演进层次上，开发者和客户可以更好地理解和应对风险。螺旋模型吧原型开发作为降低风险的机制，更重要的是，开发者可以在产品演进的任何阶段使用原型开发方法。保留了经典生命周期中系统逐步细化的方法，但是把它纳入一种迭代框架中，这种迭代方式与真实世界更加吻合。螺旋模型要求在项目的所有阶段始终考虑技术风险，如果适当地应用该方法，能够在风险变为问题之前化解风险。,3.4.2 螺旋模型

23、,螺旋模型缺点很难说服客户（特别是以合同的形式）演进的方法是可控的。依赖大量的风险评估专家来保证成功。如果有较大的风险没有被发现和管理，肯定会发生问题。,3.4.2 螺旋模型,螺旋模型和增量模型的区别？,3.4.2 螺旋模型,螺旋模型和增量模型的区别？（以下内容仅供参考！）相同都引入了迭代特性，引入了瀑布模型的系统性和可控性。应用背景不同：增量模型要求初始软件需求有明确的定义，螺旋模型不要求初始软件需求有明确的定义。风险认识不同：增量模型未明确把风险问题放入过程模型中；螺旋模型要求所有阶段要考虑风险。“雕琢”与“堆砌”的区别。螺旋模型在过程级迭代（整体迭代），增量模型在活动级迭代（部分迭代）螺

24、旋模型每次迭代都提交一个完整的软件版本，而增量模型的每次增量开发是在上次增量的基础上提交新的一部分软件,3.4.2 螺旋模型,3.4.3 协同开发模型,英文：Concurrent Model Concurrent：同时的，并行的，翻译成并发开发模型可能更贴切。但在本课，仍然采用书上的翻译：协同开发模型定义：也称为“协同工程”，它关注于多个任务的并发执行，表示为一系列的主要技术活动、任务及其相关状态。构成：协同过程模型由客户要求、管理决策和评审结果驱动，不是将软件工程活动/动作/任务限定为一个顺序的事件序列，而是定义一个活动网络，网络上的每一个活动均可与其他活动同时发生。这种模型可以提供准确的项

25、目当前状态视图。,在协同开发模型中，对建模活动可以给出一个描述。在某一时间，建模活动可能处于图中任何一种状态。,3.4.3 协同开发模型,正在开发,等待变更,正在修改,正在评审,基线建立,结束,空（None）,建模活动,表示软件工程活动或任务的某一状态,3.4.3 协同开发模型,3.4.3 协同开发模型,其他活动或任务（如沟通、构建）可以用类似的方式表示。所有活动同时存在，并处于不同的状态。如，在项目早期，沟通活动完成了第一个迭代，停留在等待变更状态。初始沟通完成后，建模活动一直停留在空状态，现在转换到正在开发状态。如果客户要求必须修改需求，建模活动从正在开发状态转换到等待变更状态。,特点：协

26、同过程模型定义了一系列事件，对于每一个软件工程活动，它们触发一个状态到另一个状态的变迁。大多数软件开发过程模型均为时间驱动，越到模型的后端，就越到开发过程的后一阶段，而一个并发过程模型是由用户要求、管理决策和结果复审驱动的。,3.4.3 协同开发模型,优点：协同开发模型对软件开发全过程活动并行化，打破了传统软件开发的各阶段分割封闭的观念。强调开发人员团队协作，注重分析和设计等前段开发工作，从而避免了不必要的返工可用于所有类型的软件开发。,3.4.3 协同开发模型,3.4.4 演化过程模型的最终评述,现代软件总是在持续改变，这些变更通常要求在非常短的期限内实现，并且要充分满足客户/用户的要求。许

27、多情况下，及时投入市场是最重要的管理需求。如果市场时间错过了，软件自身可能变得毫无意义。演进过程模型就是用来解决上述问题的。,3.4.4 演化过程模型的最终评述,演进过程模型也有缺点,3.4.4 演化过程模型的最终评述,3.5 专用过程模型,专用过程模型具有前面提到的过程模型的一些特点，但应用面往往较窄，只适合某些特定的软件工程方法。3种专用过程模型：基于构件的开发、形式化方法模型、面向方面的软件开发。,3.5.1 基于构件的开发,基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。和螺旋模型不同的地方在于：基于构件开发模型采用预先打包的软件构件开发程序。Co

28、mponent based developmentthe process to apply when reuse is a development objective,3.5.1 基于构件的开发,基于构件的开发模型由以下步骤组成（采用演进方法）：,3.5.1 基于构件的开发,3.5.2 形式化方法模型,形式化方法模型的主要活动是生成计算机软件形式化的数学规格说明。形式化方法使软件工程师可以应用严格的数学符号来说明、开发、验证基于计算机的系统。此方法的一个变型：净室软件工程。Formal methodsemphasizes the mathematical specification of re

29、quirements,3.5.2 形式化方法模型,优点使用形式化方法，歧义性问题、不完整问题、不一致问题都能更容易被发现和改正不是依靠特定的评审，而是应用数学分析的方法。在设计阶段，形式化方法是程序验证的基础，使软件工程师能够发现和改正一些往往会被忽略的问题。尽管不是主流方法，但可以提供无缺陷的软件。,3.5.2 形式化方法模型,缺点目前，形式化模型开发非常耗时，成本也很高。只有极少数程序员有应用形式化方法的背景，因此需要大量的培训。对于技术水平不高的客户，很难用这种模型进行沟通。,3.5.3 面向方面的软件开发,不论选择什么软件过程，复杂软件无一例外地实现了一套局部化的特征、功能和信息内容。

30、这些具备的软件特性被做成构件（如面向对象的类、COM组件），然后在系统架构中使用。,3.5.3 面向方面的软件开发,计算机系统的某些关注点客户需要的属性或者技术兴趣点体现在整个架构设计中。有些关注点是系统的高层属性（如安全性，容错能力），还有一些关注点影响了系统功能，还有一些是系统的（如，任务同步或存储器管理）。如果某个关注点设计系统多个方面的功能、特性和信息，这些关注点通常称为横切关注点（crosscutting concern)。,3.5.3 面向方面的软件开发,方面需求（aspectual requirement）定义了那些对整个软件体系结构产生影响的横切关注点。面向方面的软件开发（As

31、pect Oriented Software Development，AOSD）通常称为面向方面编程（Aspect Oriented Programming，AOP）是相对较新的一种软件工程模型，为定义、说明、设计、构建Aspect提供过程和方法是对横切关注点局部表示的一种机制，超越了子程序和继承的方法。AOSDprovides a process and methodological approach for defining,specifying,designing,and constructing aspects,3.5.3 面向方面的软件开发,AOCE（Aspect Oriented

32、Component Engineering）对纵向分解的软件构件进行横向切片，称为“方面”，以表示构件功能及非功能的横切属性。通常系统的方面包括用户接口、协同工作、发布、持续性、存储器管理、事务处理、安全、完整性等。构件也许提供或需要某一方面的“方面细节信息”，如视图机制、可扩展性和接口类型（用户接口方面）；时间发生、传输和接收（分布式方面）；数据存取/查询和索引（持久性方面）；认证、编码和访问权限（安全方面）；原子事务、协同控制和登录策略（事务方面）。,The Unified Software Development Process or Unified Process is a popul

33、ar iterative and incremental software development process framework.http:/en.wikipedia.org/wiki/Unified_Process#Unified_Process_CharacteristicsUP：Unified ProcessUnified Process Characteristics：Use Case Driven、Architecture Centric、Iterative and Incremental、Risk Focused 基本特征：“用例驱动、以架构为中心、关注风险的、迭代和增量式开

34、发过程”本节简述要素，第二部分讨论详细方法,3.6 统一过程,20世纪80年代到90年代初期：OO得到广泛认可，春秋战国时代；20世纪90年代早期：James Rumbaugh、Grady Booch、Ivar Jacobson开始研究“统一方法”。成果是UML。接下来几年，建立统一过程模型。UML、统一过程模型在业内被广泛应用（不管是真用还是假用）。,3.6.1 简史,3.6.2 统一过程的阶段,沟通,策划,建模,构建,部署,软件增量,发布,初始,细化,构建,移交,生产,3.6.2 统一过程的阶段,初始阶段：包括沟通和策划活动。目标是为系统建立业务案例并确定项目的边界。细化阶段：包括用户沟通

35、和建模活动。目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。构建阶段：与通用过程框架的构建活动一致。目标是所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。移交阶段：包括构建和部署活动。目标是确保软件对最终用户是可用的。生产阶段：与通用过程框架的部署活动一致。,3.6.2 统一过程的阶段,3.6.2 统一过程的阶段,初次迭代,Iter.#1,阶段,过程工作流,迭代,支持工作流,Iter.#2,Iter.#n,Iter.#n+1,Iter.#n+2,Iter.#m,Iter.#m+1,项目管理,配置和变更管理,细化,移交,初始,构造,环境,

36、时间,内容,3.6.2 统一过程的阶段,UP的时间轴被分解为四个顺序的阶段，分别是：初始阶段(Inception)、细化阶段(Elaboration)构造阶段(Construction)、交付阶段(Transition)每个阶段结束于一个主要的里程碑(Major Milestones)每个阶段本质上是两个里程碑之间的时间跨度在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。,3.6.2 统一过程的阶段,UP的内容轴由两大类核心工作流组成：核心过程工作流、核心支持工作流。RUP中有9个核心工作流，分为6个核心过程工作流(Core

37、Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复。,3.6.2 统一过程的阶段,核心过程工作流（1）业务建模工作流为组织开发一个构想，并基于这个构想在业务用例模型和业务对象模型中定义组织的过程，角色和责任。（2）需求工作流的目标是描述系统应该做什么，并使开发人员和用户就这一描述达成共识。（3）分析和设计工作流将需求转化成未

38、来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。（4）实现工作流的目的包括以层次化的子系统形式定义代码的组织结构；以组件的形式(源文件、二进制文件、可执行文件)实现类和对象；将开发出的组件作为单元进行测试以及集成由单个开发者（或小组）所产生的结果，使其成为可执行的系统。（5）测试工作流要验证对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现,识别、提出缺陷并确认缺陷在软件部署之前被处理。（6）部署工作流的目的是成功的生成版本并将软件分发给最终用户。,3.6.2 统一过程的阶段,核心支持工作流（1）配置和变更管理工作流描绘了如何在多个成

39、员组成的项目中控制大量的产物，管理演化系统中的多个变体，跟踪软件创建过程中的版本。（2）软件项目管理工作流平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。（3）环境工作流的目的是向软件开发组织提供软件开发环境，包括过程和工具。,3.6.2 统一过程的阶段,3.6.3 统一过程工作产品,初始阶段,细化阶段,构建阶段,移交阶段,愿景文档初始用例模型初始项目术语表初始业务用例初始风险评估项目计划、阶段 及迭代业务模型一个或多个原型（如果需要）,用例模型补充需求（包括非功能需求）分析模型软件体系结构描述可执行的体系结构原型初步的设计模型修订的风险列表项目计划（包括迭代计划

40、、调整的工作流、里程碑、技术工作产品）初始用户手册,设计模型软件构件集成的软件增量测试计划及步骤测试用例支持文档（用户手册、安装手册、对于并发增量的描述）,移交的软件增量Beta测试报告综合用户反馈,3.6.3 统一过程工作产品,喷泉模型喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。也是一种线性开发模型与瀑布模型类似，只是从串行改并行。主要用于面向对象方法中，面向对象的分析和设计重叠，交叉、并行进行。,3.7 喷泉模型,喷泉模型,喷泉模型该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各

41、个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的。,3.7 喷泉模型,喷泉模型喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。,3.7 喷泉模型,喷泉模型喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编

42、码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。,3.7 喷泉模型,思考：喷泉模型应用在什么样的开发环境下？,过程模型的分类：经典模型：瀑布模型增量过程模型：增量模型、RAD模型演化过程模型：原型开发、螺旋模型、并发开发模型专用过程模型：基于构件的开发、形式化方法模型、面向方面的软件开发、喷泉模型现代过程模型

43、：统一过程,软件工程的过程模型小结,如何选择软件过程模型？,软件工程的过程模型小结,如何选择软件过程模型？（以下内容仅供参考）在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.在不确定性因素很多,很多东西前面无法计划情况下尽量采用RUP和螺旋模型在需求不稳定情况下尽量采用RUP模型在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型对于全新系统的开发必须在总体设计完成后再开始增量或并行.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则.,软件工程的过程模型小结,作业,P54:3.1、3.2、3.4、3.5、3.14,