高级软件工程几种典型的开发模型实例文档资料

《高级软件工程几种典型的开发模型实例文档资料》由会员分享，可在线阅读，更多相关《高级软件工程几种典型的开发模型实例文档资料（56页珍藏版）》请在装配图网上搜索。

1、1 第三章第三章 几种典型的几种典型的开发模型实例简介开发模型实例简介2瀑布模型瀑布模型规定了由前至后、相互衔接的固定规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型为次序，如同瀑布流水，逐级下落。瀑布模型为软件开发提供了一种有效的管理模型。根据这软件开发提供了一种有效的管理模型。根据这一模式制定开发计划，进行成本预算，组织开一模式制定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段发力量，以项目的阶段评审和文档控制为手段的效地对整个开发过程进行指导。因此它是的效地对整个开发过程进行指导。因此它是文文档驱动的档驱动的、适合于需求很明确的软件项目开发、适

2、合于需求很明确的软件项目开发的模型。的模型。瀑布模型瀑布模型3强调阶段的严格性强调阶段的严格性: :严格按照生存周期各个阶段的目严格按照生存周期各个阶段的目标、任务、文档和要求来进行开发。标、任务、文档和要求来进行开发。强调阶段复审与确认强调阶段复审与确认: :通过严格的阶段性复审与确认，通过严格的阶段性复审与确认，得到该阶段的一致、得到该阶段的一致、 完整、准确和无二义性的良好完整、准确和无二义性的良好文档。文档。以文档形式驱动以文档形式驱动: :以文档形式驱动的，为合同双方最以文档形式驱动的，为合同双方最终确认产品规定了蓝本，终确认产品规定了蓝本， 为管理者进行项目开发管为管理者进行项目开

3、发管理提供了基础，为开发过程施加了理提供了基础，为开发过程施加了“政策政策”或纪律或纪律限制，限制， 约束了开发过程中的活动。约束了开发过程中的活动。以里程碑开发原则为基础以里程碑开发原则为基础: :提供各阶段的检查点，提供各阶段的检查点， 确保用户需求，满足预算和时间限制。确保用户需求，满足预算和时间限制。瀑布模型的特点瀑布模型的特点4瀑布模型的瀑布模型的优点优点容易理解、管理成本低。容易理解、管理成本低。文档产生并提供了贯穿生命期的进展过程的文档产生并提供了贯穿生命期的进展过程的充分说明。允许基线和配置早期接受控制。充分说明。允许基线和配置早期接受控制。可强迫开发人员采用规范的方法，例如结

4、构可强迫开发人员采用规范的方法，例如结构化方法。化方法。5瀑布模型的局限性客户必须能够完整、正确和清晰地表达他们的需客户必须能够完整、正确和清晰地表达他们的需要要。可能要花费更多的时间来建立一些用处不大的文档。可能要花费更多的时间来建立一些用处不大的文档。在开始的两个或三个阶段中，很难评估真正的进度在开始的两个或三个阶段中，很难评估真正的进度状态。状态。在一个项目的早期阶段，过分地强调了基线和里程在一个项目的早期阶段，过分地强调了基线和里程碑处的文档。碑处的文档。开发人员一开始就必须理解其应用。开发人员一开始就必须理解其应用。当接近项目结束时，出现了大量的集成和测试工作。当接近项目结束时，出现

5、了大量的集成和测试工作。直到项目结束之前，都不能演示系统的能力。直到项目结束之前，都不能演示系统的能力。6瀑布模型的应用考虑瀑布模型的应用考虑瀑布模型是传统过程模型的典型代表，因为瀑布模型是传统过程模型的典型代表，因为管理简单，常被获取方作为合同上的模型。管理简单，常被获取方作为合同上的模型。当一个项目有稳定的产品定义且很容易被理当一个项目有稳定的产品定义且很容易被理解的技术解决方案时，可以使用瀑布模型。解的技术解决方案时，可以使用瀑布模型。对于那些容易理解但很复杂的项目，采用纯对于那些容易理解但很复杂的项目，采用纯瀑布模型比较合适。瀑布模型比较合适。C瀑布模型适合于功能和性能明确、瀑布模型适

6、合于功能和性能明确、 完整、完整、 无重大变化的软件开发。无重大变化的软件开发。7Infosys过程模型过程模型FInfosys公司其内部采用面向过程管理软件公司其内部采用面向过程管理软件开发，同时不断进行过程改进。开发，同时不断进行过程改进。1993年获年获得得ISO认证，认证，1999年通过年通过CMM5级认证。级认证。FInfosys公司在软件过程改进方面取得的成公司在软件过程改进方面取得的成绩为其企业的良性发展奠定了基础绩为其企业的良性发展奠定了基础。F该公司采用的标准过程模型是对瀑布模型的该公司采用的标准过程模型是对瀑布模型的细化，称之为细化，称之为Infosys模型。该模型每年被模

7、型。该模型每年被成功地应用于成功地应用于500多个软件项目的开发。多个软件项目的开发。8UPUP的特点的特点 n由用例和风险驱动由用例和风险驱动：用例是捕获需求的方法，：用例是捕获需求的方法，UPUP通过对风险分析预测并关注软件构造。通过对风险分析预测并关注软件构造。n以构架设计为中心以构架设计为中心：开发软件系统的：开发软件系统的UPUP方法是方法是开发和演进一个健壮的系统构架。开发和演进一个健壮的系统构架。n迭代和增量的过程迭代和增量的过程：UPUP的迭代表示把项目划分的迭代表示把项目划分成小的子项目，迭它代提交系统的功能块或者成小的子项目，迭它代提交系统的功能块或者增量，最终产生完整的功

8、能系统。增量，最终产生完整的功能系统。9它是对它是对RUPRUP过程的剪裁，是基于风险的增量和迭过程的剪裁，是基于风险的增量和迭代的开发；代的开发；这一过程是经过实践检验的适合这一过程是经过实践检验的适合C/SC/S、B/SB/S结构结构的软件开发模型；的软件开发模型；它分为四个阶段，每个阶段至少通过它分为四个阶段，每个阶段至少通过3 3次迭代过次迭代过程完成阶段目标；程完成阶段目标；每个迭代有明确的目标和评估标准；每个迭代有明确的目标和评估标准；整个项目划分为整个项目划分为3 3次目标明确的增量开发，每次次目标明确的增量开发，每次增量作为一个可执行版本，提交用户使用。增量作为一个可执行版本，

9、提交用户使用。协同过程模型概述协同过程模型概述10微软开发模型（微软开发模型（ ）FMSF(MSF(微软解决方案框架结构微软解决方案框架结构) )是一组建立、是一组建立、开发和实现分布式企业系统应用的工作模型、开发和实现分布式企业系统应用的工作模型、开发准则和应用指南。它帮助企业融合商业开发准则和应用指南。它帮助企业融合商业和技术的目标，降低采用新技术后系统整体和技术的目标，降低采用新技术后系统整体的费用，以及成功的应用微软技术整合商业的费用，以及成功的应用微软技术整合商业过程的方法。过程的方法。 11MSFMSF的特点的特点 Code ReviewCode Review 原则原则：程序员定期

10、向其他人讲解自己源：程序员定期向其他人讲解自己源程序的活动，这个方法被众多公司采用并被认为是一程序的活动，这个方法被众多公司采用并被认为是一个行之有效的方法。个行之有效的方法。 版本管理方法版本管理方法：采用统一的版本管理服务器管理项目：采用统一的版本管理服务器管理项目源程序，每个人的程序，必须经另外一个程序员检查源程序，每个人的程序，必须经另外一个程序员检查后才能后才能Check inCheck in， 每天晚上都有每天晚上都有buildbuild所有程序，如所有程序，如果果buildbuild不能通过，程序员必须立即修改自己的程序。不能通过，程序员必须立即修改自己的程序。每隔一段时间配合进

11、度里程碑发布一个内部版本。每隔一段时间配合进度里程碑发布一个内部版本。 文档管理文档管理：MSFMSF的文档崇尚的文档崇尚实用简洁实用简洁，尽量避免事后，尽量避免事后没人看的文档，资料的积累和经验的继承通过加强程没人看的文档，资料的积累和经验的继承通过加强程序员的交流来解决（如序员的交流来解决（如Code Review, Check in Code Review, Check in 前的前的互相检查）。互相检查）。12 人员招聘培训人员招聘培训：人员招聘首先注重人格因素，其次是：人员招聘首先注重人格因素，其次是技术因素。人员的培训最有效最方便的手段是利用网技术因素。人员的培训最有效最方便的手段

12、是利用网络以多媒体、电子文档的方式提供。络以多媒体、电子文档的方式提供。 项目角色的组成项目角色的组成：程序管理、产品管理、开发、测试、：程序管理、产品管理、开发、测试、部署、用户培训，但微软并不是每个项目都配全了这部署、用户培训，但微软并不是每个项目都配全了这些角色，尤其是小的项目角色会有重叠。强调最好由些角色，尤其是小的项目角色会有重叠。强调最好由用户来充当产品管理角色。用户来充当产品管理角色。测试人员和开发人员的比例测试人员和开发人员的比例：项目测试人员和开发人项目测试人员和开发人员的比例为员的比例为1:11:1，微软通常是，微软通常是2:12:1，微软通常会雇用大，微软通常会雇用大量的

13、学生等临时人员来进行开发和测试。量的学生等临时人员来进行开发和测试。 续续13 强调进行风险管理强调进行风险管理：对项目风险进行确认并全：对项目风险进行确认并全程跟踪。程跟踪。 项目开发过程进行项目开发过程进行里程碑的建立和管理里程碑的建立和管理。 项目总结制度项目总结制度：每个项目完成后，对其失败和：每个项目完成后，对其失败和成功的地方进行总结。成功的地方进行总结。续续14MSFMSF团队模型团队模型MSFMSF组队模型展示了如何组织项目队伍，在时组队模型展示了如何组织项目队伍，在时间控制和连续不断发展计划的要求下，有效的间控制和连续不断发展计划的要求下，有效的交付系统的解决方案。它描述了六

14、种基本的角交付系统的解决方案。它描述了六种基本的角色（程序管理、产品管理、开发、测试、用户色（程序管理、产品管理、开发、测试、用户体验和发布管理）。体验和发布管理）。15产品经理产品经理：了解客户特征，尤其是商业特征，明确客：了解客户特征，尤其是商业特征，明确客户的需求以及需求的期望值。户的需求以及需求的期望值。程序经理程序经理：负责制定计划，每天找出完成该计划的风：负责制定计划，每天找出完成该计划的风险所在，排除风险，每天交付应该完成的内容，确保险所在，排除风险，每天交付应该完成的内容，确保计划按质、按量实施。计划按质、按量实施。 用户体验用户体验：设计友好的用户界面，对用户进行培训，：设计

15、友好的用户界面，对用户进行培训，确保用户能够并且愿意和喜欢使用开发出的产品。确保用户能够并且愿意和喜欢使用开发出的产品。 开发开发：开发者在开发前期就参与用户需求分析和项目：开发者在开发前期就参与用户需求分析和项目计划制定，他最清楚具体的开发过程。计划制定，他最清楚具体的开发过程。测试测试：负责开发出的代码的测试。：负责开发出的代码的测试。发布管理发布管理：平稳地部署，为日常运营作好准备平稳地部署，为日常运营作好准备。MSFMSF团队角色的职责范围团队角色的职责范围16MSFMSF的组队原则的组队原则以产品发布为中心以产品发布为中心明确的目标明确的目标客户的主动参与客户的主动参与分享产品的前景

16、分享产品的前景所有人参与设计所有人参与设计认真从过去的项目中吸取经验认真从过去的项目中吸取经验共同管理，共同决策共同管理，共同决策项目组成员在同一地点办公项目组成员在同一地点办公大型项目组也像小型项目组一样运转大型项目组也像小型项目组一样运转17MSFMSF过程模型过程模型MSFMSF过程模型解释了如何基于：范围、进度和资过程模型解释了如何基于：范围、进度和资源，规划和控制面向结果的项目。它是基于四个源，规划和控制面向结果的项目。它是基于四个可见里程碑交互的、允许修改的过程模型。可见里程碑交互的、允许修改的过程模型。18微软过程的特点微软过程的特点使用使用迭代迭代+ +渐进式渐进式提交的方式可

17、以保持系统良好的可预提交的方式可以保持系统良好的可预见性，也可使客户对项目组实施能力更加信任；见性，也可使客户对项目组实施能力更加信任；迭代周期的选择一定是对一组业务用例的实现而不是其迭代周期的选择一定是对一组业务用例的实现而不是其它。即每一个迭代周期都可以交付一个可以完成一定业它。即每一个迭代周期都可以交付一个可以完成一定业务功能的系统务功能的系统-迭代是针对业务用例的；迭代是针对业务用例的；尽早实现困难的用例（如对服务水平要求高的用例）；尽早实现困难的用例（如对服务水平要求高的用例）；不要使一个迭代周期超过不要使一个迭代周期超过5 5周（周（1 1个月）；个月）；不要试图在这个阶段就确定下

18、来整个开发过程的详细进不要试图在这个阶段就确定下来整个开发过程的详细进度（尤其是大型项目），比较好的做法是对第一个迭代度（尤其是大型项目），比较好的做法是对第一个迭代周期的任务进行比较详细的划分（基于周期的任务进行比较详细的划分（基于WBSWBS），而对后），而对后面迭代周期的适当放宽面迭代周期的适当放宽-计划应是由粗到细的。计划应是由粗到细的。19敏捷开发方法敏捷开发方法 敏捷开发（敏捷开发（Agile DevelopmentAgile Development）是一种）是一种以人以人为核心、迭代、循序渐进的开发方法为核心、迭代、循序渐进的开发方法。在敏捷。在敏捷开发中，软件项目的构建被切分成

19、多个子项目开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是可运行的特征。简言之，就是把一个大项目分把一个大项目分为多个相互联系，但也可独立运行的小项目，为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用并分别完成，在此过程中软件一直处于可使用状态状态。 20敏捷宣言敏捷宣言 注重个体和交互注重个体和交互 胜过胜过 过程和工具过程和工具注重可用的软件注重可用的软件 胜过胜过 面面俱到的文档面面俱到的文档注重客户合作注重客户合作 胜过胜过 合同谈判合同谈判注重响应变化注重

20、响应变化 胜过胜过 恪守计划恪守计划F我们正在通过亲身实践以及帮助他人实践，揭示我们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，我们认为更好的软件开发方法。通过这项工作，我们认为（形成如下（形成如下价值观价值观）：）：F也就是说，虽然右边的条目有价值，但我们更也就是说，虽然右边的条目有价值，但我们更看重左边的条目。看重左边的条目。 www.agilemanifesto.org21如何理解敏捷宣言？如何理解敏捷宣言？C个体和交互胜过过程和工具个体和交互胜过过程和工具人是获得成功的最为重要的因素。人是获得成功的最为重要的因素。合作、沟通以及交互能力要比单纯的编合作、沟通

21、以及交互能力要比单纯的编程能力更为重要。程能力更为重要。22如何理解敏捷宣言？（续）如何理解敏捷宣言？（续）C可用的软件胜过面面俱到的文档可用的软件胜过面面俱到的文档没有文档的软件是一种灾难。没有文档的软件是一种灾难。过多的文档比过少的文档更糟。过多的文档比过少的文档更糟。23如何理解敏捷宣言？（续）如何理解敏捷宣言？（续）C客户合作胜过合同谈判客户合作胜过合同谈判指明了需求、进度以及项目成本的合同指明了需求、进度以及项目成本的合同存在根本上的缺陷。存在根本上的缺陷。成功的项目需要频繁有序的客户反馈。成功的项目需要频繁有序的客户反馈。为开发团队和客户的协同工作方式提供为开发团队和客户的协同工作

22、方式提供指导的合同才是最好的合同。指导的合同才是最好的合同。24如何理解敏捷宣言？（续）如何理解敏捷宣言？（续）C响应变化胜过遵循计划响应变化胜过遵循计划计划赶不上变化。响应变化的能力决定计划赶不上变化。响应变化的能力决定一个项目的成败。一个项目的成败。较好的做计划策略是：为下两周做详细较好的做计划策略是：为下两周做详细的计划，为下三个月做粗略的计划，再的计划，为下三个月做粗略的计划，再以后就做极为粗糙的计划。以后就做极为粗糙的计划。25敏捷过程敏捷过程12条基本原则条基本原则n最优先要做的是通过尽早、持续地交付有价值的最优先要做的是通过尽早、持续地交付有价值的软件来使客户满意。软件来使客户满

23、意。n即使到了开发后期，也欢迎需求变化。即使到了开发后期，也欢迎需求变化。n经常性地交付可以工作的软件。经常性地交付可以工作的软件。n在项目的整个开发期间，业务人员和开发人员必在项目的整个开发期间，业务人员和开发人员必须天天在一起工作。可以工作的软件是主要的进须天天在一起工作。可以工作的软件是主要的进度度量标准。度度量标准。n围绕被激励起的个体来构建项目，为他们提供所围绕被激励起的个体来构建项目，为他们提供所需的环境和支持，并信任他们能胜任工作。需的环境和支持，并信任他们能胜任工作。n在团队内部，最有效果和最有效率的传递信息的在团队内部，最有效果和最有效率的传递信息的方法是面对面地交流。方法是

24、面对面地交流。26敏捷过程敏捷过程12条基本原则（续）条基本原则（续）n工作的软件是首要的进度度量标准。工作的软件是首要的进度度量标准。n敏捷过程提倡可持续的开发速度。敏捷过程提倡可持续的开发速度。n不断地关注最优秀的技术和良好的设计能增强敏不断地关注最优秀的技术和良好的设计能增强敏捷能力。捷能力。n简单是根本的。简单是根本的。n最好的架构、需求和设计来自于自组织的团队。最好的架构、需求和设计来自于自组织的团队。n每隔一定时间，团队都会对如何能有效地工作进每隔一定时间，团队都会对如何能有效地工作进行反省，然后相应地对自己的行为进行调整。行反省，然后相应地对自己的行为进行调整。27敏捷开发的特点

25、敏捷开发的特点F敏捷方法强调敏捷方法强调以人为本以人为本，专注于交付对客户有价，专注于交付对客户有价值的软件。在高度协作的开环境中，通过快速、值的软件。在高度协作的开环境中，通过快速、短迭代式的开发，不断产出和演化可运行软件，短迭代式的开发，不断产出和演化可运行软件，根据用户的反馈信息作适应性调整，然后进入下根据用户的反馈信息作适应性调整，然后进入下一轮一轮快速短迭代快速短迭代式开发。敏捷开发可以灵敏、快式开发。敏捷开发可以灵敏、快捷地应对软件捷地应对软件需求变化需求变化的特性，其特点包括：的特性，其特点包括： 能迅速交付可工作的软件能迅速交付可工作的软件能适应需求的不断变化能适应需求的不断变

26、化能保护和维持软件开发团队的积极性能保护和维持软件开发团队的积极性通过延期决策来减小风险通过延期决策来减小风险2828敏捷需求分析方法应用情境敏捷需求分析方法应用情境项目系统需求非常急迫，要求开发时间尽可能项目系统需求非常急迫，要求开发时间尽可能的短。的短。软件项目计划开发时间只有短短的软件项目计划开发时间只有短短的4 4个月。个月。初步开发出来的产品需要立即拿到用户现场去初步开发出来的产品需要立即拿到用户现场去做演示，而在这时候用户会针对产品提出更多做演示，而在这时候用户会针对产品提出更多的需求，结果是系统不能满足用户需求，项目的需求，结果是系统不能满足用户需求，项目不得不做多次的需求变更。

27、不得不做多次的需求变更。频繁的需求变更导致项目开发时间往往较长。频繁的需求变更导致项目开发时间往往较长。2929敏捷开发方法的核心思想敏捷开发方法的核心思想 敏捷开发方法的核心思想概括起来就是敏捷开发方法的核心思想概括起来就是“适应变化适应变化”和和“以人为本以人为本”。（1 1）敏捷开发方法是敏捷开发方法是面向人的而非面向过程面向人的而非面向过程的。的。 敏捷开发认为人是软件开发中最重要的因素，敏捷开发认为人是软件开发中最重要的因素，而且人工作的环境很复杂。它希望使软件开发工作而且人工作的环境很复杂。它希望使软件开发工作顺应人的天性而非逆之，强调软件开发应当是一项顺应人的天性而非逆之，强调软

28、件开发应当是一项令人愉悦的活动，因此它们注重调动人的积极性、令人愉悦的活动，因此它们注重调动人的积极性、主动性和创造性，并培养人在工作中的自豪感。敏主动性和创造性，并培养人在工作中的自豪感。敏捷开发的理念就是信任开发团队能够很好地完成任捷开发的理念就是信任开发团队能够很好地完成任务，所有的管理都是围绕这个理念展开的。务，所有的管理都是围绕这个理念展开的。3030敏捷开发方法的核心思想（续）敏捷开发方法的核心思想（续） （2 2）敏捷开发方法是敏捷开发方法是“主动适应主动适应的的”而不是而不是“预先预先设定的设定的”。 瀑布模型等传统软件开发过程试图对一个软件瀑布模型等传统软件开发过程试图对一个

29、软件开发项目在很长的时间跨度内作出详细的计划，并开发项目在很长的时间跨度内作出详细的计划，并形成详细的文档，然后依照计划进行开发。这类方形成详细的文档，然后依照计划进行开发。这类方法在计划制定完成后拒绝变化，后期的需求变化将法在计划制定完成后拒绝变化，后期的需求变化将会花费极大的代价。而敏捷开发方法则乐于迎接变会花费极大的代价。而敏捷开发方法则乐于迎接变化，其实，它的目的就是成为化，其实，它的目的就是成为适应变化的过程适应变化的过程。3131什么是极限编程什么是极限编程XPXP？XPXP是一种是一种轻量轻量、高效、低风险、柔性、可预测、高效、低风险、柔性、可预测、科学而且科学而且充满乐趣充满乐

30、趣的软件开发方式。的软件开发方式。XPXP是一种是一种软件开发规则软件开发规则或最佳实践，说它是一种或最佳实践，说它是一种规则是因为有些东西是规则是因为有些东西是XPXP中必须做的。中必须做的。极限编程中的极限编程中的“Extreme”Extreme”（极限）是指将有效的（极限）是指将有效的软件开发原理和实践应用到极限。软件开发原理和实践应用到极限。F极限编程是一种适用于中小型团队在需求不极限编程是一种适用于中小型团队在需求不明或快速多变的情况下进行软件开发的轻量级明或快速多变的情况下进行软件开发的轻量级方法学。方法学。 解析极限编程解析极限编程，Kent Beck.3232沟通沟通(Comm

31、unication)勇气勇气(Courage)简单简单(Simplicity)(Simplicity)反馈反馈(Feedback)极限编程的核心价值观极限编程的核心价值观3333沟通沟通XP认为项目成员之间的沟通是项目成功的认为项目成员之间的沟通是项目成功的关键，并把沟通看作项目中间协调与合作的关键，并把沟通看作项目中间协调与合作的主要推动因素。主要推动因素。3434简单简单XP假定未来不能可靠地预测，在现在考假定未来不能可靠地预测，在现在考虑它从经济上是不明智的，所以不应该过多虑它从经济上是不明智的，所以不应该过多考虑未来的问题而是应该集中力量解决燃眉考虑未来的问题而是应该集中力量解决燃眉之

32、急。之急。3535反馈反馈XP认为系统本身及其代码是报告系统开发认为系统本身及其代码是报告系统开发进度和状态的可靠依据。系统开发状态的反进度和状态的可靠依据。系统开发状态的反馈可以作为一种确定系统开发进度和决定系馈可以作为一种确定系统开发进度和决定系统下一步开发方向的手段。统下一步开发方向的手段。3636勇气勇气XP认为人是软件开发中最重要的一个方面认为人是软件开发中最重要的一个方面。勇气意味着敢于突破、敢于坚持，也敢于放。勇气意味着敢于突破、敢于坚持，也敢于放弃。极限编程要求一切围绕软件开发的终极目弃。极限编程要求一切围绕软件开发的终极目标标向用户及时交付可以满足需求的软件向用户及时交付可以

33、满足需求的软件来进行软件开发，因此需要勇气来实践许多来进行软件开发，因此需要勇气来实践许多看起来非常极端的做法。看起来非常极端的做法。表明了表明了XP对对“人让项目取得成功人让项目取得成功”的基本的基本信任态度。信任态度。37XP的最佳实践和原则的最佳实践和原则 成功执行成功执行XP活动的技术活动的技术n现场客户（现场客户（On-site Customer）n计划游戏（计划游戏（Planning Game）n系统隐喻（系统隐喻（System Metaphor）n简单设计（简单设计（Simple Design）n代码集体所有（代码集体所有（Collective Code Ownership）n结

34、对编程（结对编程（Pair Programming）n测试驱动（测试驱动（Test-driven）n小型发布（小型发布（Small Releases）n重构（重构（Refactoring）n持续集成（持续集成（Continuous integration）n每周每周40小时工作制（小时工作制（40-hour Weeks）n代码规范（代码规范（Coding Standards）38客户是客户是TeamTeam成员，在开发现场和开发人员一成员，在开发现场和开发人员一起工作。现场客户的工作：起工作。现场客户的工作：写写User StoryUser Story，回答问题，回答问题评估评估User St

35、oryUser Story的商业优先级的商业优先级编写验收测试编写验收测试运行验收测试运行验收测试指导迭代指导迭代接受版本接受版本现场客户现场客户39结对编程结对编程XPXP认为在项目中采用结对编程比独自编程更加认为在项目中采用结对编程比独自编程更加有效。结对编程是由两个开发人员在同一台电脑上有效。结对编程是由两个开发人员在同一台电脑上共同编写解决同一问题的代码，通常共同编写解决同一问题的代码，通常一个人负责写一个人负责写编码，而另一个负责保证代码的正确性与可读性。编码，而另一个负责保证代码的正确性与可读性。不是两个人做一个人的事情！不是两个人做一个人的事情！40测试驱动测试驱动先测试，再编码

36、；代码未动，测试先行。先测试，再编码；代码未动，测试先行。XPXP强调强调“测试先行测试先行”。在编码开始之前，首。在编码开始之前，首先将测试写好，而后再进行编码，直至所有的先将测试写好，而后再进行编码，直至所有的测试都得以通过。测试都得以通过。41重构重构重构是重构是XPXP的一个重要组成部分。所谓重构的一个重要组成部分。所谓重构是指在不改变代码外在行为的前提下对代码是指在不改变代码外在行为的前提下对代码做出的修改，以改进代码的内部结构。从本做出的修改，以改进代码的内部结构。从本质上说，重构就是在代码写好之后改进它的质上说，重构就是在代码写好之后改进它的设计。设计。42持续集成持续集成XP提

37、倡在一天中集成系统多次，而且随提倡在一天中集成系统多次，而且随着需求的改变，要不断的进行回归测试。因着需求的改变，要不断的进行回归测试。因为，这样可以使得团队保持一个较高的开发为，这样可以使得团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦。速度，同时避免了一次系统集成的恶梦。43XPXP适用范围适用范围XPXP有一个非常关键的假设就是：开发人员只注重眼前有一个非常关键的假设就是：开发人员只注重眼前需求，依赖重构来适应需求的变动，这样所带来的风险需求，依赖重构来适应需求的变动，这样所带来的风险、开销要小于需求变化使得事先充分设计失效的代价；、开销要小于需求变化使得事先充分设计失效的代价

38、；反之，实施反之，实施XPXP就是不明智的。就是不明智的。对于执行者的要求是比较高的：对于执行者的要求是比较高的：要求开发团队必须具备熟练的代码设计技能和严格要求开发团队必须具备熟练的代码设计技能和严格的测试保障技术；的测试保障技术；了解面向对象和模式，掌握了重构和了解面向对象和模式，掌握了重构和OOOO测试技术；测试技术；习惯测试先行的开发方式等。习惯测试先行的开发方式等。44什么是什么是ScrumScrum方法？方法？Scrum是一种迭代式增量软件开发过程，是是一种迭代式增量软件开发过程，是一种敏捷软件开发方法。一种敏捷软件开发方法。Scrum的原意是橄榄的原意是橄榄球比赛里的争球球比赛里

39、的争球。ScrumScrum提供了一种经验方法，它使得团队成员提供了一种经验方法，它使得团队成员能够独立地，集中地在创造性的环境下工作。能够独立地，集中地在创造性的环境下工作。它发现了软件工程的社会意义它发现了软件工程的社会意义。45 Scrum Scrum是迭代的，增量型的流程。是迭代的，增量型的流程。ScrumScrum构造的产构造的产品迭代周期为品迭代周期为Sprints,Sprints,工作的迭代时间一般为一到工作的迭代时间一般为一到四周，并且是相互衔接的。四周，并且是相互衔接的。SprintsSprints是有固定的周是有固定的周期期结束于固定明确的日期，无论该工作完成与结束于固定明

40、确的日期，无论该工作完成与否，从不延长。在每一否，从不延长。在每一SprintSprint的启始阶段，一个多的启始阶段，一个多职能的团队从已优先化的要求列表中挑选若干项目，职能的团队从已优先化的要求列表中挑选若干项目，并承诺在并承诺在SprintSprint的末期完成这些项目；在的末期完成这些项目；在SprintSprint中，中，任务的内容不会变化。每一工作日，团队成员互相任务的内容不会变化。每一工作日，团队成员互相通告工作进度，并更新简易的剩余工作量直观表示通告工作进度，并更新简易的剩余工作量直观表示图表。在图表。在SprintSprint的末期，团队将对这一阶段工作结的末期，团队将对这一

41、阶段工作结果作一展示并取得相关的反馈，为下一果作一展示并取得相关的反馈，为下一SprintSprint做好做好准备。准备。Scrum过程简介过程简介46ScrumScrum“猪猪”角色的职责角色的职责Scrum MasterScrum Master确保参与者都遵守确保参与者都遵守ScrumScrum的流程和规则的流程和规则团队（团队（TeamTeam）自组织，自管理寻找最优方案实现需求自组织，自管理寻找最优方案实现需求产品所有者（产品所有者（Product OwnerProduct Owner）规划产品需求和发布计划；规划产品需求和发布计划；收集相关于产品收集相关于产品的所有信息，并将信息转化

42、为优先权项目列的所有信息，并将信息转化为优先权项目列表，表，督促团队开发最具价值的功能。督促团队开发最具价值的功能。47ScrumScrum的第一步是产品所有者给出项目中待完的第一步是产品所有者给出项目中待完成的工作列表成的工作列表称为称为Product BacklogProduct Backlog（产品（产品订单）订单）, , 该列表按商业价值排序，是唯一具有该列表按商业价值排序，是唯一具有权威性的权威性的“以优先权排序为准，需要完成的所以优先权排序为准，需要完成的所有任务有任务”的概况；的概况； Product BacklogProduct Backlog由产品所有者随时更新，以由产品所有

43、者随时更新，以反映客户需求的变化。反映客户需求的变化。ScrumScrum过程：过程：启始启始48SprintSprint计划会议在每一计划会议在每一SprintSprint的启始阶段进行。的启始阶段进行。在在SprintSprint计划会议的第一部分，产品所有者计划会议的第一部分，产品所有者 和和ScrumScrum开发团队（在开发团队（在ScrumScrum MasterMaster的协助下）共同的协助下）共同评审评审ProductProduct BacklogBacklog，讨论，讨论BacklogBacklog中各项目的目中各项目的目标和背景，并提供标和背景，并提供ScrumScrum

44、开发团队深入了解产品所开发团队深入了解产品所有者想法的机会有者想法的机会； 在会议的第二部分，在会议的第二部分，ScrumScrum开发团队从开发团队从ProductProduct BacklogBacklog中挑选项目并承诺在中挑选项目并承诺在SprintSprint的末期完成任的末期完成任务务，团队估算每一成员拥有的完成团队估算每一成员拥有的完成SprintSprint相关工作相关工作的时间的时间。ScrumScrum过程：过程：SprintSprint计划会议计划会议49每天的每天的ScrumScrum会议会议每日（站立）例会是每日（站立）例会是SprintSprint期间期间在每个工作

45、在每个工作日特定的时间举行的短小（日特定的时间举行的短小（1515分钟）的会议分钟）的会议。ScrumScrum开发团队的每一成员都将参与开发团队的每一成员都将参与，与会与会成员都保持站立。以此提供给开发团队机会成员都保持站立。以此提供给开发团队机会来汇报交流成果和阐述任何存在的障碍。来汇报交流成果和阐述任何存在的障碍。50团队成员需要回答团队成员需要回答3 3个问题个问题在每日的（站立）例会中不容许讨论，只是将以上在每日的（站立）例会中不容许讨论，只是将以上三个重点信息做一汇报；如果需要讨论，将在会后三个重点信息做一汇报；如果需要讨论，将在会后进行进行。在会议结束后，开发团队成员将对其负责的

46、在会议结束后，开发团队成员将对其负责的SprintSprint BacklogBacklog中的项目做剩余时间的更新中的项目做剩余时间的更新。昨天你做了什么昨天你做了什么? ?1 1今天你将要做什么今天你将要做什么? ?2 2在工作进行中存在哪些障碍在工作进行中存在哪些障碍? ?3 351SprintSprint评审评审在在SprintSprint结束后，将进行评审，团队在此期间结束后，将进行评审，团队在此期间展示他们所构造的产品。展示他们所构造的产品。全体人员参加。全体人员参加。通常会议不会需要超过通常会议不会需要超过3030分钟的准备时间分钟的准备时间，只只是简单的展示工作结果，所有与会人

47、员可以提是简单的展示工作结果，所有与会人员可以提出问题和建议。出问题和建议。会议目的只是对工作结果的展示和听取反馈。会议目的只是对工作结果的展示和听取反馈。52SprintSprint回顾回顾在在SprintSprint评审之后评审之后, ,开发团队会进行开发团队会进行SprintSprint回顾回顾，总结工作中的经验和教训；，总结工作中的经验和教训；一般一般15-30 15-30 分钟；分钟；在每个在每个SprintSprint迭代结束时开始做；迭代结束时开始做；整个团队都需要参加：整个团队都需要参加：nScrumMasterScrumMastern产品所有者产品所有者n团队团队n可能还包括

48、客户可能还包括客户53ScrumScrum工件工件小结小结产品订单产品订单：是整个项目的概要文档，它包含已划分优：是整个项目的概要文档，它包含已划分优先等级的、项目要开发的系统或产品的需求清单，包先等级的、项目要开发的系统或产品的需求清单，包括功能和非功能性需求及其他假设和约束条件。括功能和非功能性需求及其他假设和约束条件。SprintSprint订单订单：是细化了的任务，定义团队在：是细化了的任务，定义团队在SprintSprint中中的任务清单，这些任务会将当前冲刺选定的产品订单的任务清单，这些任务会将当前冲刺选定的产品订单转化为完整的产品功能增量。转化为完整的产品功能增量。燃尽图燃尽图：

49、是一个公开展示的图表，纵轴代表剩余工作：是一个公开展示的图表，纵轴代表剩余工作量，横轴代表时间，显示当前量，横轴代表时间，显示当前SprintSprint中随时间变化而中随时间变化而变化的剩余工作量。变化的剩余工作量。新的功能增量新的功能增量：ScrumScrum团队在每个团队在每个SprintSprint周期内完成的周期内完成的、可交付的产品功能增量。、可交付的产品功能增量。54课堂练习课堂练习简述瀑布模型的优缺点和适用条件。简述瀑布模型的优缺点和适用条件。协同过程的特性？协同过程的特性？微软过程中持续集成体现在哪里？微软过程中持续集成体现在哪里？MSFMSF团队模型中有哪些角色？团队模型中

50、有哪些角色？微软过程的主要特点是什么微软过程的主要特点是什么？敏捷宣言的内容是什么？敏捷宣言的内容是什么？简述敏捷开发方法的核心思想？简述敏捷开发方法的核心思想？敏捷方法的应用情境敏捷方法的应用情境？55课堂练习课堂练习在在XP中中什么是结对编程？什么是结对编程？什么是重构？什么是重构？XP不编写文档吗？团队成员之间如何沟通？不编写文档吗？团队成员之间如何沟通？XP的价值观是什么？的价值观是什么？简述极限编程的适用情景。简述极限编程的适用情景。56课堂练习课堂练习在在Scrum中中有哪些主要活动？有哪些主要活动？主要文档有哪些？主要文档有哪些？“猪猪”的角色有哪些？的角色有哪些？什么是什么是Sprint BacklogSprint Backlog？什么是什么是Product Backlog？