高级软件工程(第三章)几种典型的开发模型实例教学课件

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

最新文档


当前位置:首页 > 管理文书 > 施工组织


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!