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