chapter 2 - 迭代、进化和敏捷.ppt

Chapter 2 迭代、进化和敏捷 本章目标 定义迭代(iterative)过程和敏捷(agile)过程 迭代/瀑布 敏捷/重型 定义统一过程中的基本概念 软件过程 什么是软件过程软件过程定义了软件开发、部署和维护的步骤。 软件过程本身就是软件软件过程是一种被由人构成的虚拟机执行的软件。 软件过程为什么重要（为什么不应该那么重要） 软件过程的谱系 软件过程 软件过程描述开发、部署和维护软件系统的步骤。 迭代式开发迭代式开发将软件开发过程分解为一系列小的，固定周期的(比如，4个星期)的小项目，每个小项目称为一个迭代。 统一过程 (Unified Process) 一种采用OOA/D方法学开发项目的过程(Ivar Jacobson)。 敏捷建模UP( Agile UP ) 引入了敏捷概念的UP,是UP的一个简集。 Software Processes Water Fall Others… Iterative Processes XP Unified Process RUP Agile UP 迭代式开发 瀑布生命周期 在瀑布生命周期过程中，试图在编写代码之前定义几乎所有的需求，以及明确详尽的时间表。 迭代式的生命周期 通过多次的迭代获得周期性的反馈，以这些反馈为驱动力，对系统进行不断的扩展和精化。 迭代式开发将软件开发过程分解为一系列小的，固定周期的(比如，4个星期)的小项目，每个小项目称为一个迭代。 迭代式开发 每一次迭代的周期 迭代的一个关键思想是时间定量，即时间长度固定。 大部分迭代方法建议迭代时间在2到6周之间。 示例 在项目开始为期3周的迭代中 周一启动会议，明确本次迭代的任务和目标。其间一小时制作UML图，打印最重要的部分。 其他时间团队成员结对在白板上用UML图建模。 开发，测试。 发布，给客户Review本次迭代的成果，获取反馈。 计划下一次的迭代。 注意： 没有匆忙地开始编码，也没有长期的，试图完全定义系统的设计。 迭代的成果不是用完后就抛弃的原型，而是最终产品的子集。 获取用户反馈并不断改进是项目的主要驱动力量。 迭代的过程 After a series of structured, build-feedback-adapt cycles, the system will be stable. 拥抱变化 现实 变化不可避免 变化非常昂贵 方案 A 仔细地分析和设计 和客户签订合同 抱怨 方案 B 迭代式的开发 欢迎变化 与客户一起成功 拥抱变化 仅仅有态度并不够：软件并不是想大多数人的直觉那样容易变化的。 迭代式的开发不比瀑布式开发容易。 我们应该构造能不断演化的软件系统。 迭代式开发的优势 能够较早地对付风险高的内容。 能够让人明确地看到进展，给客户信心，给开发队伍成就感。 能够较早获得反馈，鼓励用户参与开发，使系统能够更接近用户需求。 控制复杂性。 统一过程：Unified Process( UP ) UP是迭代过程的一种。提出人： Ivar Jacobson UP提供了如何实施OOA/D(和如何介绍OOA/D)的示范结构。这也形成了本书的结构。 UP具有灵活性，可以应用于敏捷（轻量级）方法。 UP的阶段 UP项目将其工作和迭代组织为4个主要的阶段: 初始(Inception)— 大体上的构想，业务用例，范围和初步的估计。 细化(Elaboration)— 进一步细化的构想，以迭代的方式实现风险较高的核心架构，识别出大部分需求和范围，作更为准确地估计。 构造(Construction)— 以迭代的方式实现剩下的低风险，易实现的部分，为发布做好准备。 移交(Transition)— beta 测试，部署 UP 科目(Disciplines) UP中定义了下列的科目: 业务建模(Business Modeling) 需求(Requirements) 设计(Design) 其他(实现/测试/部署….) 科目和迭代 (Disciplines and Iterations) 科目和阶段(Disciplines and Phases) 判断你是否理解迭代开发或UP 你是否认为 初始 = 需求 细化 = 设计 构造 = 实现 你是否认为制作UML图的设计过程是用来精确地定义系统，而开发和编码只不过是将他们机械地变换为源程序的过程 根据UP的科目和阶段设计的课程结构 敏捷宣言 个体和交流(Individuals and interactions) 工作的软件(Working software) 与客户协作(Customer collaboration) 积极响应变更(Responding to change) 过程和工具(processes and tools) 完善的文