软件过程与改进课现代软件过程模型

《软件过程与改进课现代软件过程模型》由会员分享，可在线阅读，更多相关《软件过程与改进课现代软件过程模型（41页珍藏版）》请在金锄头文库上搜索。

1、第6章 现代软件过程模型,RUP(Rational Unified Process)起源, 面向对象 60年代 Alan Kay 发明OO语言 Smalltalk和面向对象编程（Object-Oriented programming,OOP） 1982年Grady Booch提出面向对象设计（Object-Oriented Design,OOD） 80年代末，Peter Coad创建完整的OOA/D方法 三剑客及其建模方法 JimRumbaugh提出了OMT方法 Grady Booch提出了Booch方法 Ivar Jacobson提出了Objectory（Object Factory）方法,

2、软件过程与改进,UML 1994年Jim Rumbaugh和Grady Booch创建了统一方法（Unified Method），即UML第一个草案 三人加入Rational公司（后被IBM收购），领导了OMG的建模标准制定 1997年UML1.0发布，2004年UML2.0发布，成为OO建模标准,软件过程与改进,统一过程(Unified Process，UP),统一软件过程(UP)是个源于UML作者的软件开发过程。 RUP是Rational在提出UML后开发的统一过程模型，是基于UML及相关过程的一种现代过程模型。 RUP一般从三个视角来描述过程： 动态视角； 静态视角； 实践视角。,软件过

3、程与改进,软件过程与改进,Rational统一过程的基础包括三个关键元素： 角色 活动 工件,软件过程与改进,Rational统一过程是一个风险驱动的，基于用例的，体系结构为中心的迭代式软件开发过程。 Rational统一过程包含工业标准管理和技巧方面的方法和技术以提供一个软件工程过程尤其适合创造和维护基于构件的软件系统解决方案。 Rational统一过程沟通的角色，活动以及工件，它们由过程工作流组织用以在软件工程学科，在运作商业阶段和决策制定里程碑范围内来指导软件开发团队。,软件过程与改进,统一过程模型(Rational Unified Process),软件过程与改进,RUP核心工作流程

4、6个过程工作流 业务建模 需求 分析设计 实现 测试 部署 3个支持工作流 配置和变更管理 项目管理 环境,RUPRUP 阶段模型各阶段,初始(Inception) 大体上的构思、业务案例、确定范围和模糊评估 细化(Elaboration) 已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估 构建(Construction) 对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署 交付(Transition) 进行beta测试（用户测试、变更）和部署,软件过程与改进,每个阶段多次迭代，一次迭代是一个瀑布过程,初始阶段,初始阶段的任务是为系统建立业务模

5、型并确定项目的边界。 在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短,软件过程与改进,细化阶段,细化阶段的任务是分析问题领域，建立健全的体系结构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上， 对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境,软件过程与改进,构建阶段,在构建阶段，要开发所有剩余的构件和应用程序 功能，把这些构件集成为产品，并进行详细测试。 从某种意义上说，构建阶段是一个制造

6、过程，其 重点放在管理资源及控制操作，以优化成本、进 度和质量。 构建阶段的主要任务是通过优化资源和避免不必 要的报废和返工，使开发成本降到最低;完成所有所需功能的分析、开发和测试，快速完成可用的 版本;确定软件、场地和用户是否已经为部署软件 作好准备。 在构件阶段，开发团队的工作可以实现某种程度 的并行,软件过程与改进,交付阶段,当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。 交付阶段的主要任务是进行测试，制作产品发布版本;对最终用户支持文档定稿;按用户的需求确认新系统;培训用户和维护人员;获得用户对当前版本的反馈，基于反馈调

7、整产品，如进行调试、性能或可用性的增强等。 根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。 交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始进化过程，用户对交付的产品是否满意等,软件过程与改进,技术评审,在每个阶段结束时都要进行一次技术评审，以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。 技术评审要考虑的主要问题应该主要与项目管理有关，因为主要的技术问题应该已经在该阶段的最终迭代以及随后的活动中得到解决,软件过程与改进,RUP的特点 符合最佳实践 迭代开发 需求管理

8、构架和构件的使用，软件开发以构架设计为中心 建模和UML 过程质量和产品质量 配置管理和变更管理 其它特征 用例驱动的开发 过程配置 工具支持,软件过程与改进,Driven by Use Case,在系统分析和系统设计中，Use Case被用来将一个复杂的庞大系统分割、定义成一个个小的单元，这个小的单元就是Use Case,然后以每个小的单元为对象进行开发 按照RUP, Use Case贯穿整个软件开发的生命周期,软件过程与改进,构架设计Architectural Design,构架设计（Architectural Design）是系统设计的一个重要组成部分。在构架设计过程中，设计师 (Arc

9、hitect)必须完成对技术和运行平台的选取，整 个项目的基础框架（Framework）的设计，完成 对公共组件的设计，如审计（Auditing）系统，日 志（Log）系统，错误处理（Exception Handling） 系统，安全（Security）系统等。设计师必须对系 统的可扩展性（Extensibility），安全性 （Security），可维护性（Maintainability），可 延拓性（Scalability），可重用性（Reusability） 和运行速度（Performance）提出可行的解决方 案。,软件过程与改进,RUP的适用范围, 大规模软件研发 规模 大规模的软件

10、研发（50人以上） 职责明确的小组划分或分布式团队 大项目特点：高度管理复杂性，高度技术复杂性 项目持续时间 软件研发过程复杂，时间1年以上 特点 规范、严格的软件开发过程 以文档为中心，因为各阶段的里程碑是文档提交物， 重点在过程管理与提升,软件过程与改进,RUP可裁剪适应小规模的软件开发过程,惯例方法的问题？, 为提高软件产品质量，不断增加过程管理控制 时间成本质量？ 庞大的重型的过程方法是否有效？ 变化是软件的本质，软件开发必须适应变化 惯例模型忽视了软件开发中人的弱点，敏捷开发，重视人 的作用，以人为本的软件开发方法 人的弱点：不能一贯地、连续地做同一件事情,软件过程与改进,什么是敏捷

11、？,什么是敏捷？有效地（快速、适应）响应变化 参与者之间有效沟通 使客户加入团队 项目计划灵活调整 目标：快速、增量地发布软件,软件过程与改进,敏捷选择方案： 提前预测哪些需求是稳定的和哪些需求会变化非常困难 对很多软件来说，设计和构建是交错进行的。通过构建验证之前很难估计应该设计到什么程度。 从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。,软件过程与改进,敏捷过程,敏捷过程很容易适应变化并迅速做出自我调整，在保证质量的前提下，实现企业效益的最大化。 敏捷过程在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品Just enough 2001年2月，新

12、方法的一些创始人在美国犹他州成立Agile 联盟(www.agilealliance.org),软件过程与改进,敏捷宣言,个体及交互 胜过 过程和工具 可运行的软件 胜过 面面俱到无所不及的文档 客户合作 胜过 合同谈判 响应需求变化 胜过 按计划行事,软件过程与改进,敏捷过程的核心理念,基于适应而非预测 Agile方法通过快速、短迭代式的开发，不断产出和演化可运行软件，根据用户的反馈信息作适应性调整，然后进入下一轮快速短迭代式开发 以人为导向而非过程导向 努力营造诚信、开放的组织氛围，根据项目中信息流通的具体情况，按高内聚、松耦合的原则，将项目组划分为若干个小组（每个小组以不超过10人为宜，

13、组员均在一个工作间内工作），通过小组内各种渠道的沟通，来减少中间制品的工作负担，提高应变能力 -Martin Fowler “New Methodology”,软件过程与改进,敏捷12条原则,优先级最高的工作是通过尽早地、持续地交付有价值的 软件来使客户满意 欢迎改变需求，即使已经到了开发后期。敏捷过程利用 变化来为客户创造竞争优势 经常性地交付可以工作的软件，交付的间隔可以从几个 星期到几个月，交付的时间间隔越短越好 整个项目开发期间，业务人员和开发人员必须天天都在 一起工作 构建项目要靠积极性被激励起来的人员，要给他们提供 所需的环境和支持，信任他们能够完成工作 在团队内部，最富有效果和效

14、率的信息传递方法，就是 面对面交谈,软件过程与改进,工作进度的主要衡量标准是能工作的软件 敏捷过程提倡可持续发展。出资方，开发团队和用户应能持续保持稳定的工作节拍 不断使技术保持领先和良好的设计会增强敏捷性 使要做的工作尽可能简单是根本 最好的架构、需求和设计出自自组织的团队 团队定期反思如何才能更有效地工作，然后相应地对自己的行为进行调整,软件过程与改进,敏捷过程的适用范围,Martin Fowler认为：新方法不是到处可适用的 适合采用敏捷过程的情况： 需求不确定、易挥发 有责任感和积极向上的开发人员 用户容易沟通并能参与 小于10个人的项目团队,软件过程与改进,敏捷宣言背后遵循的原则：小

15、步快跑，及时反馈,不强调文档，转向强调可运行的软件片段； 开发者与顾客之间的频繁沟通； 快速开发，快速反馈，快速修改； 连续不断的短周期迭代；,软件过程与改进,极限编程（XP）,由Kent Beck、Ward Cunningham、Ron Jeffries等人提出反响最大、最为完善的敏捷过程方法。 价值观：沟通、反馈、简化、勇气 特点： 测试成为开发的核心 纪律性与灵活性巧妙结合.,软件过程与改进,极限编程（XP）的过程,软件过程与改进,极限编程（XP）的过程, 策划：用户故事、迭代计划 设计：保持简洁的原则，使用CRC卡设计，原型 编码：与设计同步进行，通过重构改进设计，结对编程方法 测试：

16、测试驱动开发，先于编码建立单元测试,软件过程与改进,极限编程（XP，eXtreme Programming）, 极限编程是一种轻量级的、灵巧的、简单的软件工程方法 与传统的开发过程不同，极限编程的核心活动体现在 需求设计测试编码 过程中 适用于规模小、进度紧、需求变化大、质量要求严的项目 它希望以最高的效率和质量来解决用户目前的问题，以最大的灵活性和最小的代价来满足用户未来的需求,软件过程与改进,XP关键做法,现场客户（On-site Customer） 计划博弈（Planning Game） 系统隐喻（System Metaphor） 简化设计（Simple Design） 集体拥有代码（Collective Code Ownership） 结对编程（Pair Programming） 测试驱动（Test-driven） 小型发布（Small Releases） 重构（Refactoring） 持续集成（Continuous integration） 每周40小时工作制（40-hour Weeks） 代码规范（CodingStandards）,