UML小结--RUP


1.RUP简介

  RUP(Rational UnifiedProcess,统一软件开发过程,统一软件过程)是一个面向对象且基于网络的程序开发方法论。

2.RUP的核心概念 

角色:描述某个人或者一个小组的行为与职责。RUP预先定义了很多角色。

活动:是一个有明确目的的独立工作单元。

工件:是活动生成、创建或修改的一段信息。

                                                                                      

 

3.RUP 所能处理的问题 

  • 有缺陷的/无法预见结果的/高度依赖于个别"英雄"程序员的/不可重复的开发过程
  • 开发的软件难以适应用户的要求
  • 在应对需求的变更方面无能为力
  • 需要单调乏味和昂贵的测试流程
  • 项目开发中出现的严重缺陷发现的太迟
  • 开发的软件难以维护和扩充

4.RUP开发的六大经验

  • 1.迭代式开发      

        1. 迭代式开发在软件开发的早期阶段就想完全、准确的捕获用户的需求几乎是不可能的。实际上,我们经常遇到的问题是需求在整个软件开发工程中经常会改变。迭代式开发允许在每次迭代过程中需求可能有变化,通过不断细化来加深对问题的理解。迭代式开发不仅可以降低项目的风险,而且每个迭代过程都可以执行版本结束,可以鼓舞开发人员。    

       2.迭代式开发的特征                                                                            

  • 在进行大规模的投资之前就解决了关键的风险问题
  • 使得早期的用户反馈在初始迭代中就能出现
  • 连续进行测试和集成
  • 各个目标里程碑提供了短期的焦点 
  • 对里程碑的测量是通过对实现的评定来进行的
  • 可以对局部的实现进行部署 

        3.风险分析                                                                                    


  •  2.管理需求



    确定系统的需求是一个连续的过程,开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述了如何提取、组织系统的功能和约束条件并将其文档化,用例和脚本的使用已被证明是捕获功能性需求的有效方法。


       需求管理技巧

 

1:分析问题

 

进行问题分析是为了理解业务问题,确定涉众的最初需要,并提出高层解决方案。这些推理和分析行为找出“隐藏在问题背后的问题”。

在问题分析过程中,将对实际问题的说明取得一致,并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候,项目的商业理由还分析期望从系统获得的投资回报。

 2:理解涉众需要

 

需求有许多来源。它们可能来自于对项目结果感兴趣的任何人。客户、合作伙伴、最终用户以及领域专家都是某些需求的来源。而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。

获取需求的手段包括访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。需求获取的结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出。

 3:定义系统

 

定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明。在系统定义初期,需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。

4:管理系统规模

 

项目规模由分配给它的需求集定义。管理项目规模,使之适合可用资源(时间、人力和资金),是成功管理项目的关键。管理规模是一个持续不断的活动,需要迭代式和递增式开发,这就将项目细分为更易于管理的若干个小部分。

使用需求属性(如优先级、工作量和风险)作为协商应包含需求的基础,对管理规模而言是相当有用的技巧。侧重于属性,而不是需求自身,将减少通常对敏感问题的争论。

这也有助于培养小组负责人的谈判技巧,还有助于在项目中为组织培养推介人,对于客户而言也是如此。产品/项目推介人应能够代表组织拒绝那些超出可用资源的规模变更,也应有相应能力扩展资源以适应扩大的规模。

 5:改进系统定义

 

对高层系统定义达成一致并充分理解了系统初始规模后,投入资源改进系统定义不仅有可能,而且也是经济的。改进系统定义包括两个重要的考虑事项:制定更详细的高层系统说明和验证系统是否符合涉众需要,是否按说明运行。

说明通常是项目团队的重要参考材料。在制定说明时一定要考虑受众。人们常会犯一个错误,那就是用复杂定义表示构建起来很复杂的东西,尤其是在受众无法或不愿意耗费精力去思考某些重要的需要取得一致认识时候。这就难以向项目团队内外的人员解释系统目的。相反,你可能会发现需要为不同的受众编制不同类型的说明。

 6:管理变更的需求

 

不管您多么认真地定义需求,需求终将改变。实际上,一些变更是非常值得的!这意味着您的团队需要与涉众保持密切联系。能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度 - 敏感度和灵活性都是对项目成功有贡献的团队特征。变更不是敌人,而没有管理的变更才是真正的敌人。

需求变更表明多少需要耗费一些时间来实施某个特定的功能,而且对一个需求的变更对其他需求可能有影响。管理需求变更包括这样一些活动:设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等。

 

 


  • 3.体系结构


   组件使重用成为可能,系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于降低管理复杂性,提高重用率。RUP描述了如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。

    采用构件架构的优势  

  • 对体系结构进行自下而上的设计/实现和测试
  • 用一种系统化的做法来定义好的体系结构
  • 采用定义明确的接口来使得变更有弹性
  • 采用现成的和通过逆向工程得到的构件
  • 由高级别的用例来驱动
  • 易于直观上的理解

          上述就是才有构件结构的优势

  • 4.可视化建模                                                                             

    RUP往往和UML联系在一起,对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力。RUP告诉我们如何可视化的对软件系统建模,获取有关体系结构于组件的结构和行为信息。


  • 5、验证软件质量

    在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动,而是内建于过程中的所有活动,这样可以及早发现软件中的缺陷。


  • 6、控制软件变更


          迭代式开发中如果没有严格的控制和协调,整个软件开发过程很快就陷入混乱之中,RUP描述了如何控制、跟踪、监控、修改以确保成功的迭代开发。RUP通过软件开发过程中的制品,隔离来自其他工作空间的变更,以此为每个开发人员建立安全的工作空间。

 

 

 

  • 5.RUP的开发过程    

RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)。每个阶段结束于一个主要的里程碑(MajorMilestones);每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。

  • 1 初始阶段

初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体,在较高层次上定义交互的特性。本阶段具有非常重要的意义,在这个阶  段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲,初始阶段可能很短。初始阶段结束时是第一个重要的里程碑:生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑评价项目基本的生存能力。

 初始阶段  

          意图  

            建立业务模型用例

            明确项目范围

          结果 

           项目的实际需求 

                 ---初始用例模型和领域模型

           初始的业务案例,包括

                ---成功准则

                ---风险评估

                ---所需资源评估

                ---显示主要里程碑进度表的阶段计划

在初始阶段的最后,检查项目的生命周期目标,决定是否继续进行全范围的开发

  • 2 细化阶段

细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰项目中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系结构作出决策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。细化阶段结束时第二个重要的里程碑:生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。

  细化阶段

        意图  

           分析问题域

           建立一个健全的合理的体系结构基础

        结果 

           用例图和领域模型 

           一个可执行的体系结构和文档

           一个修订的用例图和风险评估

           一个针对整个项目的开发计划

在这个阶段的最后已经细化的系统目标和范围,体系结构的选择以及主要风险的解决办法,并决定是否需要进行构造

  • 3 构造阶段

在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量。构建阶段结束时是第三个重要的里程碑:初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻,要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版。

构造阶段

     意图      

       迭代增量的开发一个完整的软件系统,该产品是准备提交给用户使用的

     产品

  •  完整的用例图和设计模式
  • 用户手册
  • 可执行代码
  • 开发文档
  • 每次迭代的评测标准
  • 改进的开发计划

4. 交付阶段

交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。在生命周期的这一点上,用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。在交付阶段的终点是第四个里程碑:产品发布(Product Release)里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

交付阶段

      意图

          为用户安装部署软件

      产品

  •    可执行的程序
  •   改进的系统模型
  • 每次迭代的评测标准
  • 改进的用户文档
  • 改进的开发文档
  •  

 

  • 6.RUP软件开发与生命周期

                                           

 

  • 7 RUP带来观念的变化

 

1. 更强的计划性: 迭代开发意味着要有更强的预见性和计划性,阶段的划分,阶段内的迭代都需要仔细的规划,这要求香米管理者承担更大的责任,而所换来的则是开发任务的具体化和可预见性

2. 坦然面对迭代过程中一部分中间制品的推倒重来: 不要恐惧这样的现实,由于迭代过程的细化和相应工具的支持,其影响是可以控制的

3. 把软件放在首位:过分强调规格说明的作用是不恰当的,因为用户所购买的是软件而不是规格说明,在开发过程中,需求和规格说明都是允许变化的

4. 尽早进行困难的工作:强调与实现的关系密切,而将困难工作放在开发后进行是十分有害的,会使开发后期突然遇到"集成地狱"而使开发过程失去控制

5. 确定迭代的数量,持续时间的内容: RUP 给出了一定的指南,但主要靠项目管理者根据实际情况确定,因而责任更加重大

即需要好的项目管理者,也需要好的体系结构设计师,一个成功的软件项目同时需要者两种人,而且项目管理者本人就应当懂得体系结构设计

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章