RUP开发过程

第10章RUP开发过程·什么是RUP·RUP过程模型与特点·软件开发的要素·用例驱动过程·以架构为中心的过程·迭代和增量过程【学习目标】软件开发过程是指为生产某个软件产品或系统，需要什么人在什么时候以何种方式进行何种活动的集合。传统的瀑布式开发过程模型瀑布式开发过程模型存在的风险满足社会需求的软件密集型系统在规模、复杂度、分布性和重要性上都在不断地进行着扩张，这给传统软件开发过程带来挑战：•系统的异构性•系统的分布性•系统的复杂性•系统的安全性•系统交付的快速性•大量遗留系统软件开发项目失败的共同症状：①对于最终用户的需求理解得不够精确。②不能处理需求变更。③模块之间不兼容。④软件不易维护和扩展。⑤对项目的严重缺陷发现较晚。⑥软件质量低劣。⑦软件性能无法令人接受。⑧团队中人员按各自的开发方式工作，这使得对谁在何时、何处做什么不完全清楚，系统更改与重构难以进行。⑨一个不可靠的构造和发布过程。尽管各个项目失败的原因是不同的，但是基本上大多数项目失败是由于以下几个原因的组合造成的：①需求管理非规范。②模糊和不精确的交流。③脆弱的架构。④系统过度复杂。⑤未检测出需求、设计和实现中的不一致。⑥测试不足。⑦对项目状况的评估过于主观。⑧未解决存在的风险。⑨无法控制变化的传播。⑩自动化程度不足。10.1RUP模型与特点一、RUP概念统一软件开发过程(RUP)是一种迭代的、可预测的方式来开发和维护高质量软件产品的活动集合，如下图所示。RUP具有四种作用：1）为开发团队的活动顺序提供指导。2）详细说明开发涉及哪些制品以及何时开发。3）指导每一个开发人员和整个开发团队的任务。4）为监控和度量项目的产品和活动提供标准。迭代式开发过程模型二、RUP的精髓1.软件的迭代开发软件迭代开发的特点：在软件开发的早期，强制性地进行风险控制，及时、高效地解决系统开发可能存在的风险。该模型的软件开发方法是一种持续地发现、创造和实现的过程，每一次迭代过程都会使开发团队以一种可预测和循环方式来完善项目产品。软件迭代开发能够解决什么？①可以在生命周期早期发现严重的需求理解错误，这时还可以修正这些错误。②这种方法允许并鼓励用户反馈信息，从而抽取出系统的真正需求。③这种方法使开发团队将注意力集中到项目中最关键的问题上，并屏蔽掉那些分散注意力的问题。④持续的、迭代的测试可以为项目状况给出客观评估。⑤需求、设计和实现中的不一致能够在早期被发现。⑥在整个项目的生命周期中可以更加平均地分配整个团队，尤其是可以平均分配测试团队的工作量。⑦团队可以在过程中总结经验教训，不断地改善开发过程。⑧在整个生命周期中，项目相关人员可以通过具体证据来了解项目情况。2.需求管理软件开发的挑战：需求的改变必须意识到需求在整个软件项目的生命周期中会发生变化。另外，明确一个系统的真正需求是一个持续的过程。除了一些非常小的系统之外，开发人员在开发之前完全不可能详尽地描述系统的需求。实际上，当一个新的或者进化的系统改变时，用户对系统需求的理解也会改变。需求管理的主要内容：①抽取、组织系统所需要的功能和约束并将其文档化②估计需求的变化并评估这些变化所带来的影响③跟踪并记录所做出的权衡和决定项目需求管理可提供一系列解决软件开发问题的方案：①在需求管理中构造原则性方法。②人员之间的交流建立在已定义的需求之上。③区分需求优先级，并进行过滤与跟踪。④对系统功能需求和性能需求做出客观的评估。⑤尽早检测出来需求中的不一致性。⑥借助适当的工具支持，与外部文档的自动链接，可以为系统的需求、属性和轨迹提供库支持。3.架构和组件的使用在项目的整个生命周期中，每一个人（最终用户、分析人员、开发人员、系统集成人员、测试人员、文档撰写人员和项目经理）在不同的时间以不同的角度来审视这个系统。一个系统的架构就是最重要的可交付产品，它可以用来管理这些不同的视点，从而在系统的整个生命周期中控制系统迭代与增量开发过程。基于组件的软件架构一个系统的架构包含关于以下元素：①软件系统的组织。②组成系统的结构元素以及它们之间的接口。③它们的行为，通过这些元素之间的协作来说明。④这些结构元素和行为元素组合成为较大的子系统。⑤指导组织的架构风格：这些元素和它们的接口，它们的协作和组合。建立一个富有弹性的架构是非常重要的，因为它可以非常经济地提高软件复用率，能在开发团队中确定一个非常明确的划分，分离硬件和软件间易于变化的依赖，从而提高可维护性。对于软件架构来讲，基于组件的开发是一种非常重要的方法。基于组件的架构模型标准：•微软的COM/COM+/DCOM•对象管理组织（OMG）的CORBA•SUN公司的EJB使用基于组件的架构可以提供一系列的解决软件开发根本问题的方案：①组件有利于创建灵活性强的架构。②模块化可以清晰地分离出系统中易于变化的元素。③通过应用标准化的框架（如COM+、EJB、CORBA）和商业上可获取的组件使软件复用更加容易。④组件为配置管理提供一个非常自然的基础。⑤可视化建模工具为基于组件的开发提供自动化支持。4.为软件建立可视化模型系统的可视化模型建模的作用：建模是非常重要的，它可以帮助开发团队将一个系统架构的结构和行为可视化、具体化，并可构造系统架构以及构建文档。建模通常使用一种标准的建模语言来实现，例如统一建模语言（UML），开发小组中的每个成员使用标准UML可以与其他人员进行清楚的、无二义性的交流。可视化建模的优点：可视化建模工具可以比较方便地对这些模型进行管理，能够在必要的时候隐藏或者展现一些细节。可视化建模还可以帮助你在系统的制品之间（如需求、设计和实现）保持一致性。简而言之，可视化建模有助于提高开发团队管理软件复杂性的能力。软件可视化模型可以提供一系列解决软件开发根本问题的方案：①通过用例和场景模型可以无二义性地详细说明行为。②通过类图模型可以无二义性地理解软件设计。③可视化模型能暴露出架构中的非模块化与不灵活之处。④可视化模型在必要时可以隐藏细节。⑤无二义性的设计可以更容易地反映出不一致性。⑥可视化建模工具提供对UML建模的支持。5.对软件质量进行持续的验证修复问题的代价从上图所示，在完成部署之后再去查找和修复软件问题，所付出的代价要比在早期进行这项工作高出100~1000倍。因此，从功能、可靠性、应用性能和系统性能等多方面持续地对系统质量进行评估是非常重要的。对软件质量进行验证可以提供一系列解决软件开发根本问题的方案：①对于项目状况的评估是客观而非主观的，因为评价是基于测试结果而非书面文档。②这个客观的评估可以暴露出需求、设计和实现中的不一致性。③测试和验证工作关注的是高风险区域，因此增加了这些区域的质量水平和效率。④可以尽早发现缺陷，从根本上降低修复它们的代价。⑤自动化测试工具提供了对功能、可靠性和性能的测试。6.控制软件的变更控制软件的需求变更是软件密集型系统开发的一个关键挑战：①想要将开发人员、开发团队的活动和制品协调一致，就要建立用于管理软件变更和其他开发制品变更的工作流。这样就可以更好地基于项目的优先级和风险分配资源，并在迭代过程中根据变更动态地管理工作与发现问题，并做出反应。②想要将迭代过程和发布协调一致，就要在每次迭代结束时建立并发布一个已测试过的基线。在每个发布版本元素之间和多重并行发布版本元素之间保持可跟踪性，对于评估和动态管理变更造成的影响是十分重要的。控制软件的变更可以提供一系列解决软件开发根本问题的方案：①定义需求变更的工作流，且需求变更的工作流是可重复的。②变更请求使交流更加清晰。③独立的工作空间减少了并行工作团队成员之间的相互干涉。④变更率统计为客观评估项目状况提供了很好的度量。⑤工作空间包含了所有制品，这样有利于保持一致性。⑥变更的传播是可评估和可控制的。⑦可以在一个健壮的、可定制的系统中维护变更。三、RUP的模型RUP是一种二维结构的软件开发过程模型，如下图所示。1.时间轴在RUP中，项目生命周期被划分为四个阶段：（1）初始阶段（Inception）（2）细化阶段（Elaboration）（3）构造阶段（Construction）（4）交付阶段（Transition）每个阶段开始时都有特定的目标，结束时有里程碑。在每个阶段中存在一个或多个迭代。在每个迭代中，可以有多个工作流。1)初始阶段初始阶段的目标：①确定项目的软件范围和边界条件②识别出系统的关键用例③展示系统的侯选架构④估计整个项目需要的费用和时间安排，并为细化阶段给出详细的计划⑤评估项目风险初始阶段的主要活动：①建立系统的业务模型②捕获系统的基本需求③确定系统的边界④识别关键任务⑤确定系统验收标准⑥进行项目风险评估⑦进行项目资源的估计与效益分析⑧制定项目开发计划与重要里程碑。初始阶段的里程碑——生命期目标初始阶段的制品：•项目蓝图文档：系统的核心需求、关键特性与主要约束•初始的用例模型（完成10％～20％）•初始的项目术语表•业务用例模型，包括商业环境、验收标准和财政预测•初始的风险评估•一个可以显示阶段和迭代的项目计划•一个或多个原型•初始的架构文档初始阶段的重点：初始阶段的重点是需求分析与系统分析。如果需要构造原型系统，则需做一些设计与实现。可以用如下标准来评价初始阶段是否成功：•风险承担者是否赞成项目的范围定义、成本以及进度估计。•是否通过主要用例证实对需求的理解。•成本与进度预测的评估以及优先级、风险和开发过程的可信度。•所开发软件原型的深度和广度。•实际开支与计划开支的比较。•架构的轮廓是否合理如果无法达到这些标准，可能取消项目或重新对项目进行仔细的考虑。2）细化阶段细化阶段的目标——创建系统的架构基线细化阶段的主要活动：•细化构想，建立对大多数关键用例的确定理解•分析问题域，建立坚实的架构•细化架构并选择组件•捕获80%的功能需求用例•精化风险评估•建立可执行的软件原型•定义非功能需求•制定过程迭代计划和迭代的评价标准细化阶段的里程碑——生命期架构细化阶段的主要制品：•系统架构基线•UML静态模型•UML动态模型•UML用例模型•修订的风险评估•修订的用例•修订的项目计划•可执行的原型细化阶段的重点：细化阶段主要关注需求、分析和设计工作流。每个工作流关注如下各项。•需求——精化系统范围和需求•分析——确定构造什么•设计——创建稳定的架构•实现——构造架构基线•测试——测试架构基线细化阶段的评价是通过回答下述问题来完成的：•软件的构想是否稳定？•架构是否稳定？•可执行的原型是否表明风险要素已被处理并可靠地解决了？•构造阶段的计划是否足够详细和精确？是否有可靠的基础？•如果在当前架构上下文中执行计划并开发出整个系统，是否所有的风险承担人都同意系统达到了当前的需求？•实际的费用支出与计划支出是否可以接受？如果无法达到这些标准，可能取消项目或对项目进行重新考虑。3）构造阶段构造阶段的目标——将架构基线演进为最终系统构造阶段的主要活动：•资源管理、资源控制和过程优化•完成组件开发并根据已定义的评价准则进行测试•利用构想制定的准则对发布的产品进行评估构造阶段的重点：构造阶段主要关注系统的实现工作流。每个工作流关注如下各项。•需求——揭示任何遗漏的需求•分析——完成分析模型•设计——完成设计模型•实现——构造初始运作功能•测试——测试初始运作功能构造阶段的里程碑——初始运作功能构造阶段的制品：•可运行的软件系统•UML模型•测试用例•用户手册•发布描述构造阶段的结束是项目开发的第三个重要的里程碑。这个阶段产生的版本通常被称为β版。评价构造阶段需要回答以下问题：•软件是否足够稳定和成熟，从而可以发布给用户？•是否所有的风险承担人都准备好了向用户交付软件产品？•实际费用与计划费用的对比是否仍可被接受？如果项目无法达到这些要求，必须推迟进入交付阶段。4）交付阶段交付阶段的目标——将开发完成的系统提交给客户交付阶段的主要活动：•将软件系统部署到用户环境•修复软件的缺陷•编制用户手册和其它文档•培训用户和维护人员•提供用户咨询交付阶段的重点：交付阶段主要关注系统的测试和配置工作流。每个工作流关注如下各项。•设计——如果β测试中出现问