第16章-统一软件开发过程(RUP).pptVIP

第16章 统一软件开发过程UP 统一过程（UP） 软件开发过程描述了构造、部署以及维护软件的方式。 统一过程（Unified Process）是一种构造面向对象系统的迭代软件开发过程。其中RUP是对UP的详细精化。 98年RUP 5.0推出 6个最佳开发经验 迭代式开发 管理需求 使用基于构件的体系构架 可视化软件建模 验证软件质量 控制软件变更 迭代和演化式开发 迭代和演化式开发是UP和其它方法中普遍采用的开发方法。 开发被组织成一系列固定的短期小项目（迭代，iteration），每次迭代都产生可执行的局部系统，都具有各自的需求分析、设计、实现和测试活动。 迭代和演化式开发 瀑布式开发 试图在编程之前详细定义出所有的需求，创建出完整的设计（模型集），一次性完成软件系统的分析、设计、实现、测试等 现实情况往往并非如此理想化。迭代式开发更适合处理变更。 迭代开发的优点 减少项目失败可能性，提高生产率，降低缺陷率 在早期（而不是晚期）缓解高风险（技术、需求、目标、可用性等） 早期可见的进展 早期反馈，用户参与调整，会更接近用户需求 可控复杂性；团队不会被长期且复杂的步骤所淹没 一次迭代中的经验可以被系统的用于改进开发过程本身，并反复进行下去 可以提出一个软件体系结构来指导开发 迭代示例 风险驱动和客户驱动 UP提倡风险驱动（risk-driven）和客户驱动（client-driven）相结合的迭代计划 早期的迭代目标要能够识别和降低最高风险 能构造出客户最关心的可视化特性 风险驱动迭代开发更为明确的包含了以架构为中心（architecture-centric）迭代开发的思想，意味着早期迭代要致力于核心架构的构造、测试和稳定，因为没有稳定的架构就会带来高风险。 进化式需求与瀑布式需求 任何试图在开始就固定或者定义所有需求的方法都有本质的缺陷，例如瀑布式需求分析 在UP和进化式方法中，具有产品品质的编程和测试要远早于大多数需求的分析或规格化 结合早期时间定量的迭代开发，进行进化式的需求分析，并且引入频繁的涉众参与、评估和对局部结果的反馈 需求类型和种类 FURPS+ 功能性（Functional）：特性、功能、安全性 可用性（Usability）：人性化因素、帮助、文档 可靠性（Reliability）：故障频率、可恢复性、可预测性 性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率 可支持性（Supportability）：适应性、可维护性、国际化、可配置性 需求类型和种类 （+） 实现：资源限制、语言和工具、硬件 接口：强加于外部系统接口之上的约束 操作：对其操作设置的系统管理 包装：打包形式 授权：许可证… 敏捷方法（agile development） 应用定量时间的迭代和演化式开发方法，提倡增量交付并包含其它敏捷性特征。 敏捷原则 最高优先级：通过早期和持续交付有价值的软件来满足客户； 欢迎变更需求，即使是在开发的后期提出； 以两周到两月为周期，频繁的交付可运行的软件； 在整个项目过程中，每一天开发人员和业务人员合作； 由个体推动项目的建设，为个体提供所需的环境、支持和信任 敏捷方法（agile development） 开发团队中采取面对面的交谈 衡量进展的重要尺度是可运行的软件 不断应用先进的技术提高敏捷性 简洁最重要，尽量减少工作量 最佳的架构、需求来自于自组织的团队 团队要定期反省如何做使工作更有效 敏捷建模（agile modeling） 采用敏捷方法并不意味着不进行任何建模 建模的目的主要用于沟通和理解，而不是构建文档 不要对所有的软件设计建模和应用UML 尽可能使用最简单的工具（白板） 坚持使用简单，常用的UML元素 多人建模 并行建模（交互图，类图） 建模和实现最好是相同的人 UML草图 UP的软件开发生命周期 初始（Inception） 大体的构想、业务案例、范围和模糊评估 细化（Elaboration） 已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求和范围以及进行更为实际的评估 构造（Construction） 对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署 移交（Transition） 进行Beta测试和部署 UP的阶段 UP的软件开发生命周期 RUP初始阶段 RUP细化阶段 RUP构造阶段 RUP交付阶段 开发案例 尚未理解UP和迭代开发 开始设计或者实现前试图定义大多数需求； 编程之前花费数日或数周进行UML建模； 认为初始阶段=需求阶段，细化阶段=设计阶段，构造阶段=实现阶段 认为细化的目的是完整的定义模型，以能够在构造阶段将其转换为代码 坚信合适的迭代时间长度为三个月，而不是三周 认为采用UP就意味着要完成大量可能的