高级软件工程(第三章)几种典型的开发模型实例(2017课件)PPT课件.ppt

第三章几种典型的开发模型实例简介 1 瀑布模型规定了由前至后 相互衔接的固定次序 如同瀑布流水 逐级下落 瀑布模型为软件开发提供了一种有效的管理模型 根据这一模式制定开发计划 进行成本预算 组织开发力量 以项目的阶段评审和文档控制为手段的效地对整个开发过程进行指导 因此它是文档驱动的 适合于需求很明确的软件项目开发的模型 瀑布模型 2 强调阶段的严格性 严格按照生存周期各个阶段的目标 任务 文档和要求来进行开发 强调阶段复审与确认 通过严格的阶段性复审与确认 得到该阶段的一致 完整 准确和无二义性的良好文档 以文档形式驱动 以文档形式驱动的 为合同双方最终确认产品规定了蓝本 为管理者进行项目开发管理提供了基础 为开发过程施加了 政策 或纪律限制 约束了开发过程中的活动 以里程碑开发原则为基础 提供各阶段的检查点 确保用户需求 满足预算和时间限制 瀑布模型的特点 3 瀑布模型的优点 容易理解 管理成本低 文档产生并提供了贯穿生命期的进展过程的充分说明 允许基线和配置早期接受控制 可强迫开发人员采用规范的方法 例如结构化方法 4 瀑布模型的局限性 客户必须能够完整 正确和清晰地表达他们的需要 可能要花费更多的时间来建立一些用处不大的文档 在开始的两个或三个阶段中 很难评估真正的进度状态 在一个项目的早期阶段 过分地强调了基线和里程碑处的文档 开发人员一开始就必须理解其应用 当接近项目结束时 出现了大量的集成和测试工作 直到项目结束之前 都不能演示系统的能力 5 瀑布模型的应用考虑 瀑布模型是传统过程模型的典型代表 因为管理简单 常被获取方作为合同上的模型 当一个项目有稳定的产品定义且很容易被理解的技术解决方案时 可以使用瀑布模型 对于那些容易理解但很复杂的项目 采用纯瀑布模型比较合适 瀑布模型适合于功能和性能明确 完整 无重大变化的软件开发 6 Infosys过程模型 Infosys公司其内部采用面向过程管理软件开发 同时不断进行过程改进 1993年获得ISO认证 1999年通过CMM5级认证 Infosys公司在软件过程改进方面取得的成绩为其企业的良性发展奠定了基础 该公司采用的标准过程模型是对瀑布模型的细化 称之为Infosys模型 该模型每年被成功地应用于500多个软件项目的开发 7 UP的特点 由用例和风险驱动 用例是捕获需求的方法 UP通过对风险分析预测并关注软件构造 以构架设计为中心 开发软件系统的UP方法是开发和演进一个健壮的系统构架 迭代和增量的过程 UP的迭代表示把项目划分成小的子项目 迭它代提交系统的功能块或者增量 最终产生完整的功能系统 8 它是对RUP过程的剪裁 是基于风险的增量和迭代的开发 这一过程是经过实践检验的适合C S B S结构的软件开发模型 它分为四个阶段 每个阶段至少通过3次迭代过程完成阶段目标 每个迭代有明确的目标和评估标准 整个项目划分为3次目标明确的增量开发 每次增量作为一个可执行版本 提交用户使用 9 协同过程模型概述 微软开发模型 MSF MSF 微软解决方案框架结构 是一组建立 开发和实现分布式企业系统应用的工作模型 开发准则和应用指南 它帮助企业融合商业和技术的目标 降低采用新技术后系统整体的费用 以及成功的应用微软技术整合商业过程的方法 10 MSF的特点 CodeReview原则 程序员定期向其他人讲解自己源程序的活动 这个方法被众多公司采用并被认为是一个行之有效的方法 版本管理方法 采用统一的版本管理服务器管理项目源程序 每个人的程序 必须经另外一个程序员检查后才能Checkin 每天晚上都有build所有程序 如果build不能通过 程序员必须立即修改自己的程序 每隔一段时间配合进度里程碑发布一个内部版本 文档管理 MSF的文档崇尚实用简洁 尽量避免事后没人看的文档 资料的积累和经验的继承通过加强程序员的交流来解决 如CodeReview Checkin前的互相检查 11 人员招聘培训 人员招聘首先注重人格因素 其次是技术因素 人员的培训最有效最方便的手段是利用网络以多媒体 电子文档的方式提供 项目角色的组成 程序管理 产品管理 开发 测试 部署 用户培训 但微软并不是每个项目都配全了这些角色 尤其是小的项目角色会有重叠 强调最好由用户来充当产品管理角色 测试人员和开发人员的比例 项目测试人员和开发人员的比例为1 1 微软通常是2 1 微软通常会雇用大量的学生等临时人员来进行开发和测试 续 12 强调进行风险管理 对项目风险进行确认并全程跟踪 项目开发过程进行里程碑的建立和管理 项目总结制度 每个项目完成后 对其失败和成功的地方进行总结 续 13 MSF团队模型 MSF组队模型展示了如何组织项目队伍 在时间控制和连续不断发展计划的要求下 有效的交付系统的解决方案 它描述了六种基本的角色 程序管理 产品管理 开发 测试 用户体验和发布管理 14 产品经理 了解客户特征 尤其是商业特征 明确客户的需求以及需求的期望值 程序经理 负责制定计划 每天找出完成该计划的风险所在 排除风险 每天交付应该完成的内容 确保计划按质 按量实施 用户体验 设计友好的用户界面 对用户进行培训 确保用户能够并且愿意和喜欢使用开发出的产品 开发 开发者在开发前期就参与用户需求分析和项目计划制定 他最清楚具体的开发过程 测试 负责开发出的代码的测试 发布管理 平稳地部署 为日常运营作好准备 MSF团队角色的职责范围 15 MSF的组队原则 以产品发布为中心明确的目标客户的主动参与分享产品的前景所有人参与设计认真从过去的项目中吸取经验共同管理 共同决策项目组成员在同一地点办公大型项目组也像小型项目组一样运转 16 MSF过程模型 MSF过程模型解释了如何基于 范围 进度和资源 规划和控制面向结果的项目 它是基于四个可见里程碑交互的 允许修改的过程模型 17 微软过程的特点 使用迭代 渐进式提交的方式可以保持系统良好的可预见性 也可使客户对项目组实施能力更加信任 迭代周期的选择一定是对一组业务用例的实现而不是其它 即每一个迭代周期都可以交付一个可以完成一定业务功能的系统 迭代是针对业务用例的 尽早实现困难的用例 如对服务水平要求高的用例 不要使一个迭代周期超过5周 1个月 不要试图在这个阶段就确定下来整个开发过程的详细进度 尤其是大型项目 比较好的做法是对第一个迭代周期的任务进行比较详细的划分 基于WBS 而对后面迭代周期的适当放宽 计划应是由粗到细的 18 敏捷开发方法 敏捷开发 AgileDevelopment 是一种以人为核心 迭代 循序渐进的开发方法 在敏捷开发中 软件项目的构建被切分成多个子项目 各个子项目的成果都经过测试 具备集成和可运行的特征 简言之 就是把一个大项目分为多个相互联系 但也可独立运行的小项目 并分别完成 在此过程中软件一直处于可使用状态 19 敏捷宣言 注重个体和交互胜过过程和工具注重可用的软件胜过面面俱到的文档注重客户合作胜过合同谈判注重响应变化胜过恪守计划 我们正在通过亲身实践以及帮助他人实践 揭示更好的软件开发方法 通过这项工作 我们认为 形成如下价值观 也就是说 虽然右边的条目有价值 但我们更看重左边的条目 www agilemanifesto org 20 如何理解敏捷宣言 个体和交互胜过过程和工具人是获得成功的最为重要的因素 合作 沟通以及交互能力要比单纯的编程能力更为重要 21 如何理解敏捷宣言 续 可用的软件胜过面面俱到的文档没有文档的软件是一种灾难 过多的文档比过少的文档更糟 22 如何理解敏捷宣言 续 客户合作胜过合同谈判指明了需求 进度以及项目成本的合同存在根本上的缺陷 成功的项目需要频繁有序的客户反馈 为开发团队和客户的协同工作方式提供指导的合同才是最好的合同 23 如何理解敏捷宣言 续 响应变化胜过遵循计划计划赶不上变化 响应变化的能力决定一个项目的成败 较好的做计划策略是 为下两周做详细的计划 为下三个月做粗略的计划 再以后就做极为粗糙的计划 24 敏捷过程12条基本原则 最优先要做的是通过尽早 持续地交付有价值的软件来使客户满意 即使到了开发后期 也欢迎需求变化 经常性地交付可以工作的软件 在项目的整个开发期间 业务人员和开发人员必须天天在一起工作 可以工作的软件是主要的进度度量标准 围绕被激励起的个体来构建项目 为他们提供所需的环境和支持 并信任他们能胜任工作 在团队内部 最有效果和最有效率的传递信息的方法是面对面地交流 25 敏捷过程12条基本原则 续 工作的软件是首要的进度度量标准 敏捷过程提倡可持续的开发速度 不断地关注最优秀的技术和良好的设计能增强敏捷能力 简单是根本的 最好的架构 需求和设计来自于自组织的团队 每隔一定时间 团队都会对如何能有效地工作进行反省 然后相应地对自己的行为进行调整 26 敏捷开发的特点 敏捷方法强调以人为本 专注于交付对客户有价值的软件 在高度协作的开环境中 通过快速 短迭代式的开发 不断产出和演化可运行软件 根据用户的反馈信息作适应性调整 然后进入下一轮快速短迭代式开发 敏捷开发可以灵敏 快捷地应对软件需求变化的特性 其特点包括 能迅速交付可工作的软件能适应需求的不断变化能保护和维持软件开发团队的积极性通过延期决策来减小风险 27 28 敏捷需求分析方法应用情境 项目系统需求非常急迫 要求开发时间尽可能的短 软件项目计划开发时间只有短短的4个月 初步开发出来的产品需要立即拿到用户现场去做演示 而在这时候用户会针对产品提出更多的需求 结果是系统不能满足用户需求 项目不得不做多次的需求变更 频繁的需求变更导致项目开发时间往往较长 28 29 敏捷开发方法的核心思想 敏捷开发方法的核心思想概括起来就是 适应变化 和 以人为本 1 敏捷开发方法是面向人的而非面向过程的 敏捷开发认为人是软件开发中最重要的因素 而且人工作的环境很复杂 它希望使软件开发工作顺应人的天性而非逆之 强调软件开发应当是一项令人愉悦的活动 因此它们注重调动人的积极性 主动性和创造性 并培养人在工作中的自豪感 敏捷开发的理念就是信任开发团队能够很好地完成任务 所有的管理都是围绕这个理念展开的 29 30 敏捷开发方法的核心思想 续 2 敏捷开发方法是 主动适应的 而不是 预先设定的 瀑布模型等传统软件开发过程试图对一个软件开发项目在很长的时间跨度内作出详细的计划 并形成详细的文档 然后依照计划进行开发 这类方法在计划制定完成后拒绝变化 后期的需求变化将会花费极大的代价 而敏捷开发方法则乐于迎接变化 其实 它的目的就是成为适应变化的过程 30 31 什么是极限编程XP XP是一种轻量 高效 低风险 柔性 可预测 科学而且充满乐趣的软件开发方式 XP是一种软件开发规则或最佳实践 说它是一种规则是因为有些东西是XP中必须做的 极限编程中的 Extreme 极限 是指将有效的软件开发原理和实践应用到极限 极限编程是一种适用于中小型团队在需求不明或快速多变的情况下进行软件开发的轻量级方法学 解析极限编程 KentBeck 31 32 沟通 Communication 勇气 Courage 简单 Simplicity 反馈 Feedback 极限编程的核心价值观 32 33 沟通 XP认为项目成员之间的沟通是项目成功的关键 并把沟通看作项目中间协调与合作的主要推动因素 33 34 简单 XP假定未来不能可靠地预测 在现在考虑它从经济上是不明智的 所以不应该过多考虑未来的问题而是应该集中力量解决燃眉之急 34 35 反馈 XP认为系统本身及其代码是报告系统开发进度和状态的可靠依据 系统开发状态的反馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段 35 36 勇气 XP认为人是软件开发中最重要的一个方面 勇气意味着敢于突破 敢于坚持 也敢于放弃 极限编程要求一切围绕软件开发的终极目标 向用户及时交付可以满足需求的软件 来进行软件开发 因此需要勇气来实践许多看起来非常极端的做法 表明了XP对 人让项目取得成功 的基本信任态度 36 XP的最佳实践和原则 成功执行XP活动的技术 现场客户 On siteCustomer 计划游戏 PlanningGame 系统隐喻 SystemMetaphor 简单设计 SimpleDesign 代码集体所有 CollectiveCodeOwnership 结对编程 PairProgramming 测试驱动 Test driven 小型发布 SmallReleases 重构 Refactoring 持续集成 Continuousintegration 每周40小时工作制 40 hourWeeks 代码规范 CodingStandards 37 客户是Team成员 在开发现场和开发人员一起工作 现场客户的工作 写UserStory 回答问题评估UserStory的商业优先级编写验收测试运行验收测试指导迭代接受版本 现场客户 38 结对编程 XP认为在项目中采用结对编程比独自编程更加有效 结对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码 通常一个人负责写编码 而另一个负责保证代码的正确性与可读性 不是两个人做一个人的事情 39 测试驱动 先测试 再编码 代码未动 测试先行 XP强调 测试先行 在编码开始之前 首先将测试写好 而后再进行编码 直至所有的测试都得以通过 40 重构 重构是XP的一个重要组成部分 所谓重构是指在不改变代码外在行为的前提下对代码做出的修改 以改进代码的内部结构 从本质上说 重构就是在代码写好之后改进它的设计 41 持续集成 XP提倡在一天中集成系统多次 而且随着需求的改变 要不断的进行回归测试 因为 这样可以使得团队保持一个较高的开发速度 同时避免了一次系统集成的恶梦 42 XP适用范围 XP有一个非常关键的假设就是 开发人员只注重眼前需求 依赖重构来适应需求的变动 这样所带来的风险 开销要小于需求变化使得事先充分设计失效的代价 反之 实施XP就是不明智的 对于执行者的要求是比较高的 要求开发团队必须具备熟练的代码设计技能和严格的测试保障技术 了解面向对象和模式 掌握了重构和OO测试技术 习惯测试先行的开发方式等 43 什么是Scrum方法 Scrum是一种迭代式增量软件开发过程 是一种敏捷软件开发方法 Scrum的原意是橄榄球比赛里的争球 Scrum提供了一种经验方法 它使得团队成员能够独立地 集中地在创造性的环境下工作 它发现了软件工程的社会意义 44 Scrum是迭代的 增量型的流程 Scrum构造的产品迭代周期为Sprints 工作的迭代时间一般为一到四周 并且是相互衔接的 Sprints是有固定的周期 结束于固定明确的日期 无论该工作完成与否 从不延长 在每一Sprint的启始阶段 一个多职能的团队从已优先化的要求列表中挑选若干项目 并承诺在Sprint的末期完成这些项目 在Sprint中 任务的内容不会变化 每一工作日 团队成员互相通告工作进度 并更新简易的剩余工作量直观表示图表 在Sprint的末期 团队将对这一阶段工作结果作一展示并取得相关的反馈 为下一Sprint做好准备 Scrum过程简介 45 Scrum 猪 角色的职责 ScrumMaster 确保参与者都遵守Scrum的流程和规则 团队 Team 自组织 自管理寻找最优方案实现需求 产品所有者 ProductOwner 规划产品需求和发布计划 收集相关于产品的所有信息 并将信息转化为优先权项目列表 督促团队开发最具价值的功能 46 Scrum的第一步是产品所有者给出项目中待完成的工作列表 称为ProductBacklog 产品订单 该列表按商业价值排序 是唯一具有权威性的 以优先权排序为准 需要完成的所有任务 的概况 ProductBacklog由产品所有者随时更新 以反映客户需求的变化 Scrum过程 启始 47 Sprint计划会议在每一Sprint的启始阶段进行 在Sprint计划会议的第一部分 产品所有者和Scrum开发团队 在ScrumMaster的协助下 共同评审ProductBacklog 讨论Backlog中各项目的目标和背景 并提供Scrum开发团队深入了解产品所有者想法的机会 在会议的第二部分 Scrum开发团队从ProductBacklog中挑选项目并承诺在Sprint的末期完成任务 团队估算每一成员拥有的完成Sprint相关工作的时间 Scrum过程 Sprint计划会议 48 每天的Scrum会议 每日 站立 例会是Sprint期间在每个工作日特定的时间举行的短小 15分钟 的会议 Scrum开发团队的每一成员都将参与 与会成员都保持站立 以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍 49 团队成员需要回答3个问题 在每日的 站立 例会中不容许讨论 只是将以上三个重点信息做一汇报 如果需要讨论 将在会后进行 在