软件工程课件.ppt

《软件工程课件.ppt》由会员分享，可在线阅读，更多相关《软件工程课件.ppt（61页珍藏版）》请在三一文库上搜索。

1、软件工程,第10章 敏捷软件开发,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,2,复旦大学计算机科学技术学院 软件工程（第二版）,敏捷软件开发的产生背景,软件开发的新挑战 快速的市场进入时间，要求高生产率 快速变化的需求 快速发展的技术 传统的软件开发方法 强调过程和文档 对变化的适应能力偏弱,3,提高对变化的适应能力,Martin Fowler认为： 提前预测需求是困难的。同样，对项目进行过程中客户需求优先级的变更进行预测也很困难 对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来获得验

2、证，而在构建的过程中新获得的知识又可以帮助设计 从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测,复旦大学计算机科学技术学院 软件工程（第二版）,4,敏捷方法的基本观点,强调适应性而不是可预测性 经典软件开发方法：通过控制变化实现软件开发的可预测性 敏捷软件开发方法：变化是不可避免的，应该通过改善管理实践和工程实践来更好地适应变化 强调人在项目中的关键作用 敏捷软件开发认为人不是可以互相替换的“编程部件”，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性,复旦大学计算机科学技术学院 软件工程（第二版）,5,复旦大学计算机科学技术学院 软件工程（第二版）,强调“刚刚好”（

3、Just enough） 在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少,6,敏捷方法的产生,从20世纪90年代开始，逐渐产生了一大批敏捷软件开发方法 其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法（crystal）、自适应软件开发（adaptive software development，ASD）、动态系统开发方法（dynamic system development method，DSDM）等,复旦大学计算机科学技术学院 软件工程（第二版）,7,敏捷宣言,2001年2月，17位敏捷

4、方法的先驱在美国犹他州召开了为期2天的会议，成立了敏捷软件开发联盟 并发布了“敏捷宣言” 该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的12条原则,复旦大学计算机科学技术学院 软件工程（第二版）,8,敏捷宣言,我们正通过亲身或者协助他人进行软件开发实践来 探索更好的软件开发方法。 基于此，我们建立了如下的价值观： 个体和交互 重于 过程和工具 工作的软件 重于 详尽的文档 客户合作 重于 合同谈判 响应变化 重于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值,复旦大学计算机科学技术学院 软件工程（第二版）,9,复旦大学计算机科学技术学院 软件工程（第二版）,个体

5、和交互 重于 过程和工具,过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调 软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件 如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很难成功地开发的,10,复旦大学计算机科学技术学院 软件工程（第二版）,工作的软件 重于 详尽的文档,可以工作的软件是软件开发工作的最终目标 好的必要的文档能帮助我们理解软件做什么，怎么做以及如何使用，是有价值的。但是，软件开发的主要目标仍然是创建可运行的软件 敏捷软件开发强调不断地快速地向用户

6、提交可运行的软件（不一定是完整的软件），以得到用户的认可,11,复旦大学计算机科学技术学院 软件工程（第二版）,客户合作 重于 合同谈判,只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以后也可能会改变 由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的 敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求,12,复旦大学计算机科学技术学院 软件工程（第二版）,响应变化 重于 遵循计划,任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然

7、而，随着项目的进展，需求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因会改变 因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化,13,敏捷宣言的12条原则, 我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而接纳变化 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采用较短的周期 业务人员和开发人员必须在项目的整个阶段紧密合作 围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标 在团队内和团队间沟通信息的最有效和最高效的

8、方式是面对面的交流,复旦大学计算机科学技术学院 软件工程（第二版）,14,敏捷宣言的12条原则（续）, 可工作的软件是进度的首要度量标准。 敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。 持续地追求技术卓越和良好设计，可以提高敏捷性 以简洁为本，它是减少不必要工作的艺术。 最好的架构、需求和设计是从自组织的团队中涌现出来的。 团队定期地反思如何变得更加高效，并相应地调整自身的行为。,复旦大学计算机科学技术学院 软件工程（第二版）,15,精益思想的5条原则,识别价值 价值是客户愿意购买产品的原因，也是产品开发的根本价值所在。“是否有助于增加价值”是精益方法衡量过程活

9、动的准则 定义价值流 价值流描述了组织为了交付价值所采取的一系列有增值的活动 保持价值流的流动 良好的系统应该让价值迅速流动，从而用较低的成本生产出正确的产品,复旦大学计算机科学技术学院 软件工程（第二版）,16,精益思想的5条原则（续）,拉动系统 拉动系统是基于当前客户的需求，向上游环节逐级反馈，每个环节都基于下一个环节的需求而进行生产 持续改善 持续改善是精益思想的最重要支柱。精益思想的核心就是不断进行改善从而最大化价值,复旦大学计算机科学技术学院 软件工程（第二版）,17,敏捷方法的公共特征,致力于降低变化带来的成本 强调价值 强调人的作用 使用增量和迭代的开发方法,复旦大学计算机科学技

10、术学院 软件工程（第二版）,18,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,19,Scrum的产生历史,1986年，竹内弘高和野中郁次郎在哈佛商业评论上发表了The New New Product Development Game，首次使用Scrum来描述产品开发中的一种新方法 1993年，Jeffery Sutherland和Ken Schwaber将该方法引入软件开发领域，并于1995年在OOPSLA会议上发表了相关论文,复旦大学计算机科学技术学院 软件工程（第二版）,20,Scrum的核心概念,透明 检验

11、适应 尽量在早期暴露软件开发中的问题，进行及时的调整，从而使得软件开发团队在充满不确定的研发领域成功地工作,复旦大学计算机科学技术学院 软件工程（第二版）,21,方法框架,复旦大学计算机科学技术学院 软件工程（第二版）,24小时,2-4周,每日会议,潜在可交付的 产品增量,产品Backlog,团队成员划分的 Backlog任务,22,时间盒,时间盒（time-box）是一个固定的时间段，为软件开发提供了一个节奏 时间盒在Scrum中称为Sprint 在每个Sprint中，都包含完整的需求分析、计划、开发、测试等各个环节。 一般情况下，每个Sprint都应该产生可发布的产品增量。每个Sprint

12、的开发时间是固定的，一般是一个月或者更短的时间,复旦大学计算机科学技术学院 软件工程（第二版）,23,Scrum团队,Scrum团队是自组织、跨职能部门的，其核心目标是提高灵活性和生产能力。 每个Scrum团队都包括三种角色：Scrum Master、产品负责人和开发团队。 Scrum Master负责保证Scrum团队的成员理解并且遵循Scrum框架； 产品负责人指明团队的开发方向，最大化Scrum团队的工作价值； 开发团队负责具体的开发工作，在每个Sprint结束之前将产品负责人的需求转化成为潜在可交付的产品模块。,复旦大学计算机科学技术学院 软件工程（第二版）,24,制品,潜在可交付的产

13、品增量 在每个Sprint的结束，Scrum团队都应该能够产生一个新的、可交付的产品增量，这部分和既有的已开发产品一起形成一个整体，随时准备交付给客户。 产品Backlog 产品负责人对软件开发团队的需求的列表 Sprint的Backlog 开发团队成员为了实现一个Sprint的开发目标而定义的开发任务,复旦大学计算机科学技术学院 软件工程（第二版）,25,完成标准（Definition of Done）,Scrum的规则要求开发团队在每个Sprint的交付物都应该达到“完成”（done） “完成”标准由开发团队定义，并且进行了清晰的描述 只有达到了“完成”标准，开发团队在Sprint的输出才

14、能被看做是合格的交付物，才可以声称完成了某个产品增量,复旦大学计算机科学技术学院 软件工程（第二版）,26,需求管理,复旦大学计算机科学技术学院 软件工程（第二版）,需求是逐步细化的 需求可能在项目中间发生变化 需求应当被估算并指定优先级,27,Sprint计划会议,第1部分 产品负责人介绍产品Backlog中的高优先级的条目 团队基于历史速率，从高到低按照优先级选择将要开发的条目 第2部分 团队分析选择的条目，结合交付标准，讨论需要完成哪些工作,复旦大学计算机科学技术学院 软件工程（第二版）,28,任务墙,复旦大学计算机科学技术学院 软件工程（第二版）,29,燃尽图,复旦大学计算机科学技术学

15、院 软件工程（第二版）,30,每日例会,Scrum团队每天召开的短会，保证团队能够了解和分享全局的项目信息。 每日例会的参加者是开发团队成员和Scrum Master，产品负责人可以根据需要决定是否参加。 团队成员在每日例会上回答3个问题： 上次例会后做了什么？ 遇到了哪些困难？ 计划在下次例会前做些什么？,复旦大学计算机科学技术学院 软件工程（第二版）,31,Sprint评审,Scrum要求开发团队在每个Sprint结束时都对本Sprint完成的功能进行演示.其基本目标是反馈和适应。 Scrum鼓励各种各样的角色参加 演示，而不仅仅局限于客户、产品负责人和开发团队成员。 Scrum建议Spr

16、int评审尽量使用非正式的方式进行。,复旦大学计算机科学技术学院 软件工程（第二版）,32,Sprint回顾,参加者： 开发团队、产品负责人和Scrum Master 步骤 准备 数据收集 问题分析 确定方案 结束,复旦大学计算机科学技术学院 软件工程（第二版）,33,复旦大学计算机科学技术学院 软件工程（第二版）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,34,复旦大学计算机科学技术学院 软件工程（第二版）,XP方法,1996年，Kent Beck等人在Chrysler的C3项目的开发过程中逐步产生了极限编程的基本概念 1999年，Kent Beck撰写了解

17、析极限编程：拥抱变化，对极限编程的价值观、原则和实践进行了阐述,35,复旦大学计算机科学技术学院 软件工程（第二版）,XP方法的开发过程,36,复旦大学计算机科学技术学院 软件工程（第二版）,探索阶段 探索阶段的主要工作是开发初始的用户故事（User Stories ）和体系结构骨架（architecture spike） 用户故事描述了系统高层的需求，它是制订发布计划的输入 在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用 探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用,37,复旦大学计算机

18、科学技术学院 软件工程（第二版）,计划阶段 计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划 使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之间的关系 通常图形方式（可以是草图）比文字描述更直观 尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定其工作量估算,38,复旦大学计算机科学技术学院 软件工程（第二版）,迭代到发布阶段 迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本 根据在探索阶段编写

19、的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作 在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或调整,39,复旦大学计算机科学技术学院 软件工程（第二版）,产品化阶段 产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备 在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等 另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调“可运行软件高于详尽的文档”，但是，必要的文档仍是需要的,40,复旦大学计算机科学技术学院 软件工程（第二版）,维护阶段 维护阶段涵盖了计

20、划阶段、迭代到发布阶段和产品化阶段 通常这个阶段主要包括面向产品的活动，如系统的运行和支持,41,复旦大学计算机科学技术学院 软件工程（第二版）,XP方法的价值观,交流（Communication） 实践表明，项目失败的重要原因之一是交流不畅，使得客户的需求不能准确地传递给开发人员，造成开发人员不能充分理解需求；模型或设计的变动未能及时告知相关人员，造成系统的不一致和集成的困难 所有项目相关人员之间充分的有效的交流是软件开发成功所必不可少的 XP方法提倡面对面的交流，这是一种有效的也是效率最高的交流方式,42,复旦大学计算机科学技术学院 软件工程（第二版）,简单（Simplicity） 指在确

21、保得到客户满意的软件的前提下，做最简洁的工作（简单的过程、模型、文档、设计和实现） 在开发中不断优化设计，时刻保持代码简洁、无冗余 体现了敏捷开发的“刚刚好(Just enough)”思想，即开发中的活动及制品既不要太多也不要太少，刚好即可,43,复旦大学计算机科学技术学院 软件工程（第二版）,反馈（Feedback） 及时有效的反馈能确定开发工作是否正确，及时发现开发工作的偏差并加以纠正。 强调各种形式的反馈，如非正式的评审（走查，Walkthrough）、小发布等,44,复旦大学计算机科学技术学院 软件工程（第二版）,勇气（Courage） 采用敏捷软件开发需要勇气： 信任合作的同事，也相

22、信自己 做能做到的最简单的事 只有在绝对需要的时候才创建文档 让业务人员制定业务决策，技术人员制定技术决策 用可能的最简单的工具，例如白板和纸，只有在复杂建模工具能提供可能的最好价值时才去使用它们 相信程序员能制定设计决策，不需要给他们提供过多的细节 需要勇气来承认自己是会犯错误的，需要勇气来相信自己明天能克服明天出现的问题。,45,复旦大学计算机科学技术学院 软件工程（第二版）,尊重（Respect） 沟通、简单、反馈和勇气都和尊重相关 在实际的项目团队中，认可团队中的每个人的专业技能和价值，如实反映和他人利益相关的情况，构建整个团队的共同目标，都体现尊重这一价值观,46,复旦大学计算机科学

23、技术学院 软件工程（第二版）,XP核心实践：用户故事,故事是对团队应该完成的工作的陈述 。极限编程通过故事来体现价值观中的“沟通”的原则。好的用户故事应该能够触发客户和开发团队之间的沟通 作为和客户的良好沟通的成果，故事拥有清楚的完成标准。一种常见的策略是，从用户的角度描述一组验收测试用例，开发团队使用该验收测试用例来验证是否已经完成了某个故事,47,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：估算,估算是极限编程中隐含的实践，很多应用极限编程的团队使用估算来帮助沟通、制定迭代和发布计划 估算不仅仅是帮助确定故事的规模，更重要的是通过对故事点的讨论，团队可以发现需求或实现中可

24、能存在的问题,48,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：简单设计,完成了定义的功能, 能通过所有的测试 该设计描述了程序员的重要意图，便于理解和沟通；设计和实现没有冗余、没有重复的逻辑 在满足以上条件的前提下，没有多余的类和方法,49,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：重构,重构是在不改变代码的外部行为的情况下，通过调整内部的结构，来持续保持代码的可理解、可维护特征,50,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：测试驱动开发,测试驱动开发的3个快速循环的步骤： 编写一个测试 该测试试图发现代码中有一处功能没有实现，或者

25、代码中存在一个需要修复的问题 编写代码 使用尽可能快的方式编写产品代码，使这个测试得以通过 对代码进行重构,51,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：结对编程,结对编程提高了设计的可靠性和质量 在做任何设计的时候，都有两个程序员一起思考，可以汇集两个程序员的设计思想 在代码编写完成的时候同时也通过了代码审查 这种方式有助于减少程序中的错误，降低测试时间和测试成本,52,复旦大学计算机科学技术学院 软件工程（第二版）,XP核心实践：持续集成,开发者,代码库,持续集成服务器,提交 代码,监控,编译,测试,发布 报告,构建,53,复旦大学计算机科学技术学院 软件工程（第二版

26、）,内容摘要,敏捷软件开发概述 Scrum方法 极限编程（XP）方法 看板方法,54,看板方法,“看板”一词来源于日语，本意是“可视卡片” 在生产系统中，人们使用看板来发布生产指令。在丰田，看板专指将整个精益生产系统连接在一起的可视化物理信号系统 软件开发中的看板方法使用了和生产系统相类似的思想,复旦大学计算机科学技术学院 软件工程（第二版）,55,看板方法的定义,“看板是一种增量的、演进的改变技术开发和组织运作的方法。看板通过限制WIP的数量，形成了一个以拉动系统为核心的机制，暴露系统中的问题，激发协作来改善系统。”,复旦大学计算机科学技术学院 软件工程（第二版）,David J. Ande

27、rson,56,可视化工作流,复旦大学计算机科学技术学院 软件工程（第二版）,需求清单,分析,开发准备,完成,进行中,实现,完成,进行中,完成,系统测试,客户确认,上线,A,B,N,O,P,C,D,E,F,G,H,J,K,L,M,Q,57,限制“在制品”（WIP）数量,WIP是一个精益的概念，是指正在加工的产品或者准备加工的原料或半成品 由于WIP占用了资金和资源而不能立即交付给客户，在精益生产中被看做一种浪费 凡是已经开始且没有完成的制品，例如开发准备、实现、系统测试、客户确认阶段的制品，都属于WIP 通过限制WIP，可以实现拉动系统,复旦大学计算机科学技术学院 软件工程（第二版）,58,度

28、量并管理周期时间,周期时间是一个需求在整个开发环节流动的时间。周期时间越短，对客户的响应越迅速 通过度量周期时间，软件开发组织能够了解当前的现状，并且为下一步的改善设定目标,复旦大学计算机科学技术学院 软件工程（第二版）,59,明确过程准则,过程准则明确的约定了制品在不同阶段之间跳转的规则。例如： 开发准备阶段应该做到什么程度？ 实现阶段是否应该包含代码质量检查？是否应该包含自动化测试 ？ 过程准则帮助软件团队准确了解项目状态，进行进一步的改善,复旦大学计算机科学技术学院 软件工程（第二版）,60,改善工作流,看板中的工作流并不是一成不变的 看板方法不会告诉软件团队应该如何做，但是它会要求软件团队就这个问题进行讨论，然后提出解决方案 软件团队会在实践中逐步发现更好的工作流,复旦大学计算机科学技术学院 软件工程（第二版）,61,