软件工程软件工程软件工程软件工程第5章 敏捷软件开发 软件工程软件工程内容摘要内容摘要敏捷敏捷软件开件开发概述概述极限极限编程（程（XP）方法）方法相关敏捷相关敏捷过程模型程模型Scrum方法方法动态系统开发方法动态系统开发方法敏捷建模敏捷建模敏捷统一过程敏捷统一过程2 软件工程软件工程敏捷软件开发的产生背景敏捷软件开发的产生背景软件开件开发的新挑的新挑战快速的市场进入时间，要求高生产率快速的市场进入时间，要求高生产率快速变化的需求快速变化的需求快速发展的技术快速发展的技术传统的的软件开件开发方法方法强调过程和文档强调过程和文档对变化的适应能力偏弱对变化的适应能力偏弱3提提高对变化的适应能力高对变化的适应能力Martin Fowler认为：提前预测需求是困难的同样，对项目进行提前预测需求是困难的同样，对项目进行过程中客户需求优先级的变更进行预测也很过程中客户需求优先级的变更进行预测也很困难困难对很多项目来说，软件设计和构建是交错进对很多项目来说，软件设计和构建是交错进行的也就是说，设计需要通过实施构建来行的也就是说，设计需要通过实施构建来获得验证，而在构建的过程中新获得的知识获得验证，而在构建的过程中新获得的知识又可以帮助设计又可以帮助设计从制定计划的角度来看，分析、设计、构建从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测和测试活动并不容易预测 软件工程软件工程4 软件工程软件工程5敏捷方法的基本观点敏捷方法的基本观点强调强调适应性适应性而不是可预测性而不是可预测性经典软件开发方法经典软件开发方法：通过控制变化实现软件开发的通过控制变化实现软件开发的可预测性可预测性敏捷敏捷软件开发方法软件开发方法：变化变化是不可避免的，应该通过是不可避免的，应该通过改善管理实践和工程实践来更好地适应改善管理实践和工程实践来更好地适应变化变化强调强调人人在在项目中项目中的的关键作用关键作用敏捷软件开发认为人不是可以互相替换的敏捷软件开发认为人不是可以互相替换的“编程部编程部件件”，而是具有创造力的个体，成功的软件开发活，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性动依赖于人的主观能动性 软件工程软件工程6 软件工程软件工程强调强调“刚刚好刚刚好”（Just enough）在保证软件开发有成功产出的前提下，尽量减少开在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少制品既不要太多也不要太少7敏捷方法的产生敏捷方法的产生从从20世世纪90年代开始，逐年代开始，逐渐产生了一大生了一大批敏捷批敏捷软件开件开发方法方法其中比其中比较有影响的包括：极限有影响的包括：极限编程、程、Scrum、看板方法、精益看板方法、精益软件开件开发方法、水晶方法、水晶软件开件开发方法（方法（crystal）、自适）、自适应软件开件开发（adaptive software development，ASD）、）、动态系系统开开发方法（方法（dynamic system development method，DSDM）等）等 软件工程软件工程8敏捷宣言敏捷宣言2001年年2月，月，17位敏捷方法的先位敏捷方法的先驱在美国在美国犹他州召开了犹他州召开了为期期2天的会天的会议，成立了敏成立了敏捷捷软件开件开发联盟盟 并并发布了布了“敏捷宣言敏捷宣言”该宣言由四个价宣言由四个价值观声明声明组成，并提成，并提炼出出敏捷敏捷软件开件开发方法必方法必须遵循的遵循的12条原条原则 软件工程软件工程9敏捷宣言敏捷宣言我们我们正通过亲身或者协助他人进行软件开发实践来正通过亲身或者协助他人进行软件开发实践来探索更好的软件开发方法。
探索更好的软件开发方法基于此，我们建立了如下的价值观：基于此，我们建立了如下的价值观：个体个体和交互和交互 重于重于 过程和工具程和工具工作的工作的软件件 重于重于 详尽的文档尽的文档客客户合作合作 重于重于 合同合同谈判判响响应变化化 重于重于 遵循遵循计划划也就是说也就是说，尽管右项有其价值，尽管右项有其价值，我们更重视左项的价值我们更重视左项的价值 软件工程软件工程10 软件工程软件工程个体和交互个体和交互 重于重于 过程和工具过程和工具过程和工具是重要的，但是程和工具是重要的，但是软件开件开发中人的作用和中人的作用和交流的作用更需要被交流的作用更需要被进一步一步强调软件是由人件是由人组成的成的团队来开来开发的，与的，与软件件项目相关目相关的各的各类人人员通通过充分的交流和有效的合作，才能成充分的交流和有效的合作，才能成功地开功地开发出得到用出得到用户满意的意的软件件如果光有定如果光有定义良好的良好的过程和先程和先进的工具，而人的工具，而人员的的技能很差，或者不能很好地交流和技能很差，或者不能很好地交流和协作，作，软件是很件是很难成功地开成功地开发的的11 软件工程软件工程工作的软件工作的软件 重于重于 详尽的文档详尽的文档可以工作的可以工作的软件是件是软件开件开发工作的最工作的最终目目标好的好的必要的文必要的文档能档能帮助我帮助我们理解理解软件做什么，怎么件做什么，怎么做以及如何使用做以及如何使用，是有价，是有价值的。
但是，的但是，软件开件开发的的主要目主要目标仍然是仍然是创建可运行的建可运行的软件件敏捷敏捷软件开件开发强调不断地快速地向用不断地快速地向用户提交可运行提交可运行的的软件（不一定是完整的件（不一定是完整的软件），以得到用件），以得到用户的的认可可12 软件工程软件工程客户合作客户合作 重于重于 合同谈判合同谈判只有客只有客户才能明确才能明确说明需要什么明需要什么样的的软件，然而，件，然而，大量的大量的实践表明，在开践表明，在开发的早期客的早期客户常常不能完整常常不能完整地表达他地表达他们的全部需求，有些早期确定的需求，以的全部需求，有些早期确定的需求，以后也可能会改后也可能会改变由于由于软件开件开发的的预测性的困性的困难，想通，想通过合同合同谈判的判的方式，将需求固定下来常常是困方式，将需求固定下来常常是困难的的敏捷敏捷软件开件开发强调与客与客户的的协作，通作，通过与客与客户的交的交流和流和紧密合作来密合作来发现用用户的需求的需求13 软件工程软件工程响应变化响应变化 重于重于 遵循计划遵循计划任何任何软件件项目的开目的开发都都应该制制订一个一个项目目计划，以划，以确定各开确定各开发任任务的的优先先顺序和起止日期。
然而，随序和起止日期然而，随着着项目的目的进展，需求、展，需求、业务环境、技境、技术等都可能等都可能变化，任化，任务的的优先先顺序和起止日期也可能因种种原因序和起止日期也可能因种种原因会改会改变因此，因此，项目目计划划应具有可塑性，有具有可塑性，有变动的余地当的余地当出出现变化化时及及时做出反做出反应，修，修订计划以适划以适应变化化14敏捷宣言的敏捷宣言的12条原则条原则 我们的最高优先级是持续不断地、及早地交付有价值的我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意软件来使客户满意 拥抱变化，即使是在项目开发的后期敏捷过程愿意为拥抱变化，即使是在项目开发的后期敏捷过程愿意为了客户的竞争优势而了客户的竞争优势而接纳接纳变化变化 经常地交付可工作的软件，相隔几星期或一两个月，倾经常地交付可工作的软件，相隔几星期或一两个月，倾向于向于采用采用较短的周期较短的周期 业务人员和开发人员必须在项目的整个阶段紧密合作业务人员和开发人员必须在项目的整个阶段紧密合作 围绕着被激励的个体构建项目为个体提供所需的环境围绕着被激励的个体构建项目为个体提供所需的环境和支持，给予信任，从而达成目标和支持，给予信任，从而达成目标 在团队内和团队间沟通信息的最有效和最高效的方式是在团队内和团队间沟通信息的最有效和最高效的方式是面对面的交流面对面的交流 软件工程软件工程15敏捷宣言的敏捷宣言的12条原则（续）条原则（续）可工作的软件是进度的首要度量标准。
可工作的软件是进度的首要度量标准敏捷过程倡导可持续开发项目发起者、开发人员和用敏捷过程倡导可持续开发项目发起者、开发人员和用户应该维持一个可持续的步调户应该维持一个可持续的步调持续地追求技术卓越和良好设计，可以提高敏捷性持续地追求技术卓越和良好设计，可以提高敏捷性 以简洁为本，它是减少不必要工作的艺术以简洁为本，它是减少不必要工作的艺术最好的架构、需求和设计是从自组织的团队中涌现出来最好的架构、需求和设计是从自组织的团队中涌现出来的团队定期地反思如何变得更加高效，并相应地调整自身团队定期地反思如何变得更加高效，并相应地调整自身的行为软件工程软件工程16敏捷方法的公共特征敏捷方法的公共特征致力于降低致力于降低变化化带来来的成本的成本强调价价值强调人的人的作用作用使用增量和迭代的开使用增量和迭代的开发方法方法 软件工程软件工程17 软件工程软件工程内容摘要内容摘要敏捷敏捷软件开件开发概述概述极限极限编程（程（XP）方法）方法相关敏捷相关敏捷过程模型程模型Scrum方法方法动态系统开发方法动态系统开发方法敏捷建模敏捷建模敏捷统一过程敏捷统一过程18 软件工程软件工程XP(eXtreme Programming)方法方法1996年，年，Kent Beck等人在等人在Chrysler的的C3项目的开目的开发过程中逐步程中逐步产生了极限生了极限编程的基本概程的基本概念念1999年，年，Kent Beck撰写了撰写了解析极限解析极限编程：程：拥抱抱变化化，对极限极限编程的价程的价值观、原、原则和和实践践进行了行了阐述述19极限编程过程极限编程过程 软件工程软件工程20XP方法方法XP 策划策划开始于倾听，倾听产生一系列开始于倾听，倾听产生一系列“用户故事用户故事”。
团队成员评估每一个故事，并给出以开发周数为度量单团队成员评估每一个故事，并给出以开发周数为度量单位的位的成本成本团队共同决定如何将故事分组，并置于将要开发的下一团队共同决定如何将故事分组，并置于将要开发的下一个个软件增量软件增量中中给出对给出对下一个发布版本的基本承诺（就包括的故事、交下一个发布版本的基本承诺（就包括的故事、交付日期和其他项目事项）付日期和其他项目事项）项目的第一个发行版本（也称为一个软件增量）交付之项目的第一个发行版本（也称为一个软件增量）交付之后，后，XP团队计算团队计算项目的速度项目的速度，用于帮助估计后续发行版用于帮助估计后续发行版本的发布日期和进度安排本的发布日期和进度安排软件工程软件工程21XP方法方法XP设计设计严格遵循KIS（Keep It Simple，保持简洁）原则鼓励使用CRC卡如果在设计中碰到困难，推荐使用“Spike解决方案”鼓励“重构”以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程XP编程编程推荐在编码开始之前建立单元测试鼓励“结对编程”XP测试测试所有单元测试应当使用一个可以自动实施的框架验收测试”由客户规定技术条件，并且着眼于客户可见的系统级特征和功能。
22结对编程结对编程结对编程程提高了提高了设计的可靠性和的可靠性和质量量在做任何设计的时候在做任何设计的时候，都有两个程序员一起思考，都有两个程序员一起思考，可以汇集两个程序员的设计思想可以汇集两个程序员的设计思想在代码编写完成的时候同时也通过了代码审查在代码编写完成的时候同时也通过了代码审查这种方式有助于减少程序中的种方式有助于减少程序中的错误，降低，降低测试时间和和测试成本成本 软件工程软件工程23 软件工程软件工程XP核心实践：用户故事核心实践：用户故事故事是故事是对团队应该完成的工作的完成的工作的陈述述极限编程程通通过故事来体故事来体现价价值观中的中的“沟通沟通”的原的原则好的用用户故事故事应该能能够触触发客客户和开和开发团队之之间的的沟通沟通作作为和客和客户的良好沟通的成果，故事的良好沟通的成果，故事拥有清楚的完有清楚的完成成标准一种常准一种常见的策略是，从用的策略是，从用户的角度描述一的角度描述一组验收收测试用例，开用例，开发团队使用使用该验收收测试用例来用例来验证是否已是否已经完成了某个完成了某个故事故事24 软件工程软件工程XP核心实践核心实践：估算：估算估算是极限估算是极限编程中程中隐含的含的实践，很多践，很多应用极限用极限编程程的的团队使用估算来帮助沟通、制定迭代和使用估算来帮助沟通、制定迭代和发布布计划划估算不估算不仅仅是帮助确定故事的是帮助确定故事的规模，更重要的是通模，更重要的是通过对故事点的故事点的讨论，团队可以可以发现需求或需求或实现中可中可能存在的能存在的问题25 软件工程软件工程XP核心实践：简单设计核心实践：简单设计完成了定完成了定义的功能的功能,能通能通过所有的所有的测试该设计描述了程序描述了程序员的重要意的重要意图，便于理解和沟通；，便于理解和沟通；设计和和实现没有冗余、没有重复的没有冗余、没有重复的逻辑在在满足以上条件的前提下，没有多余的足以上条件的前提下，没有多余的类和方法和方法26 软件工程软件工程XP核心实践：重构核心实践：重构重构是在不改重构是在不改变代代码的外部行的外部行为的情况下，通的情况下，通过调整内部的整内部的结构，来持构，来持续保持代保持代码的可理解、可的可理解、可维护特征特征27 软件工程软件工程XP核心实践：测试驱动开发核心实践：测试驱动开发测试驱动开开发的的3个快速循个快速循环的步的步骤：编写一个写一个测试该测试试图发现代代码中有一中有一处功能没有功能没有实现，或，或者代者代码中存在一个需要修复的中存在一个需要修复的问题 编写代写代码使用尽可能快的方式使用尽可能快的方式编写写产品代品代码，使，使这个个测试得以通得以通过 对代代码进行重构行重构28 软件工程软件工程XP核心实践核心实践：结对编程：结对编程结对编程提高了程提高了设计的可靠性和的可靠性和质量量在做任何设计的时候在做任何设计的时候，都有两个程序员一起思考，可以都有两个程序员一起思考，可以汇集两个程序员的设计汇集两个程序员的设计思想思想在代码编写完成的时候同时也通过了在代码编写完成的时候同时也通过了代码审查代码审查这种方式有助于减少程序中的种方式有助于减少程序中的错误，降低，降低测试时间和和测试成本成本29瀑布模式：瀑布模式：重型开发方式，每个阶段都要求完美，无法适应变更迭代开迭代开发不要求每个阶段的任务都完美，逐步完善螺旋开螺旋开发风险驱动的开发方式敏捷开敏捷开发相比迭代，开发周期更短，并强调沟通合作 软件工程软件工程30极限编程的核心价值极限编程的核心价值沟通沟通简单反反馈勇气勇气谦逊强调把列出的每个方法和思想做到极限把列出的每个方法和思想做到极限 软件工程软件工程31 软件工程软件工程内容摘要内容摘要敏捷敏捷软件开件开发概述概述极限极限编程（程（XP）方法）方法相关敏捷相关敏捷过程模型程模型Scrum方法方法动态系统开发方法动态系统开发方法敏捷建模敏捷建模敏捷统一过程敏捷统一过程32敏捷开发的本质敏捷开发的本质以人以人为中心、迭代、循序中心、迭代、循序渐进的开的开发方法方法不以文档作不以文档作为驱动，强调人与人之人与人之间的面的面对面的沟通交面的沟通交流流迭代：把复迭代：把复杂并且开并且开发周期周期长的开的开发任任务，分解成很多，分解成很多小周期可完成的任小周期可完成的任务，这样的每个小周期就是一个迭代的每个小周期就是一个迭代过程，每次迭代都程，每次迭代都产生一个可交付的生一个可交付的产品品快速迭代快速迭代 拥抱抱变化化敏捷是一种指敏捷是一种指导思想，思想，Scrum和和XP就是具体的开就是具体的开发方式方式了，了，Scrum偏重于偏重于过程，而程，而XP重在重在实践践Scrum,橄橄榄球运球运动的的专业术语，表示，表示“争球争球”动作，作，软件工程软件工程33Scrum方法方法Scrum90年代中期，敏捷过程模型年代中期，敏捷过程模型Scrum 橄榄球比赛橄榄球比赛；Sprint 比赛中的冲刺比赛中的冲刺框架性过程活动框架性过程活动需求需求分析分析设计设计演化演化交付交付 软件工程软件工程34过程流过程流35Scrum开发过程开发过程 软件工程软件工程36 软件工程软件工程37Scrum开发过程开发过程确定确定Product Backlog（按（按优先先顺序排列的一个序排列的一个产品需求列表品需求列表；Scrum Team根据根据Product Backlog列表，做工作量的列表，做工作量的预估和安估和安排；排；根据根据Product Backlog列表，通列表，通过 Sprint Planning Meeting来从来从中挑中挑选出出一个一个Story作作为本次迭代完成的目本次迭代完成的目标，该目目标的的时间周周期是期是14个星期，然后把个星期，然后把这个个Story进行行细化，形成一个化，形成一个Sprint Backlog；Sprint Backlog是由是由Scrum Team去完成的，每个成去完成的，每个成员根据根据Sprint Backlog再再细化成更小的任化成更小的任务（细到每个任到每个任务的工作量在的工作量在2天内能完成）；天内能完成）；软件工程软件工程38在在Scrum Team完成完成计划会划会议上上选出的出的Sprint Backlog过程中，程中，需要需要进行行 Daily Scrum Meeting（每日站立会（每日站立会议），），每次会每次会议控控制在制在15分分钟左右左右，每个人向所有成，每个人向所有成员当面当面汇报你昨天完成了什么，你昨天完成了什么，并且向所有成并且向所有成员承承诺你今天要完成什么，同你今天要完成什么，同时遇到不能解决的遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的也可以提出，每个人回答完成后，要走到黑板前更新自己的Sprint burn down（Sprint燃尽燃尽图）每日集成，每天都要有一个可以成功每日集成，每天都要有一个可以成功编译、并且可以演示的版本、并且可以演示的版本(自自动工具工具实现)当一个当一个Story完成，也就是完成，也就是Sprint Backlog被完成，也就表示一被完成，也就表示一次次Sprint完成，要完成，要进行行Srpint Review Meeting（演示会（演示会议），），也称也称为评审会会议，产品品负责人和客人和客户都要参加每一个都要参加每一个Scrum Team的成的成员都要向他都要向他们演示自己完成的演示自己完成的软件件产品品Sprint RetrospectiveMeeting（回（回顾会会议），也称），也称为总结会会议，以，以轮流流发言方式言方式进行，每个人都要行，每个人都要发言，言，总结并并讨论改改进的的地方，放入下一地方，放入下一轮Sprint的的产品需求中；品需求中；软件工程软件工程39 软件工程软件工程40Scrum的的33553个角色个角色Product Owner：产品品负责人，清楚的知道人，清楚的知道产品的愿景，品的愿景，需要需要对产品待品待办列表的梳理，列表的梳理，优化，化，优先先级排序等排序等负责。
决定决定团队每个冲刺要完成哪些任每个冲刺要完成哪些任务，负责产品的功能和品的功能和达到要求的达到要求的标准，指定准，指定软件的件的发布日期和交付内容布日期和交付内容Scrum Master是是Scrum教教练和和团队带头人，确保人，确保团队合理的运作合理的运作Scrum，并帮助，并帮助团队扫除除实施中的障碍，施中的障碍，负责流程在流程在项目中的目中的顺利利实施和施和进行行Team是开是开发团队，能，能够交付一个端到端的真正交付一个端到端的真正对客客户有价有价值的的产品品 软件工程软件工程413个工件个工件Product Backlog：是指是指产品待品待办事事项的集合，其中事的集合，其中事务有有优先先级判断，先判断，先处理理优先先级高的事高的事项Sprint Backlog：每个迭代的功能开每个迭代的功能开发列表，列表，PO会根会根据据团队的能力并按照的能力并按照产品待品待办列表中的列表中的优先先级来来选取每取每个冲刺要做的事情个冲刺要做的事情团队可以可以专注在每个迭冲刺要走的注在每个迭冲刺要走的事情上而不被打断事情上而不被打断Burn down chart:燃尽燃尽图，在每个迭代，在每个迭代显示剩余工作示剩余工作时间和任和任务完成情况完成情况 软件工程软件工程425种活动种活动Sprint:冲刺冲刺,一个固定的一个固定的时间周期（通常周期（通常为2w-4w）,团队要尽可能在要尽可能在这个周期内交付可以工作的个周期内交付可以工作的软件件给客客户sprint planning meeting:冲刺开始的冲刺开始的时候，候，PO会和会和团队一起从一起从PB中中选择本次要做的任本次要做的任务/故事，并且会故事，并且会对团队提出的疑提出的疑问进行解行解释和澄清。
同和澄清同时团队会估算故事并分解成任会估算故事并分解成任务，最后会形成本次的，最后会形成本次的Sprint Backlog.daily standup meeting:每日站会，每日站会，scrum为了加了加强团队沟通，每天沟通，每天团队都要都要选择一个一个时间站在一起，互相交流彼此的站在一起，互相交流彼此的进展和展和问题,以便及以便及时解决解决出出现的的问题，同，同时也能也能让团队随随时了解我了解我们离冲刺目离冲刺目标还有多有多远sprint review:在在sprint周期最后，需要周期最后，需要进行一次行一次评审会会议，让团队向向产品品负责人和利益相关者展示已完成的功能人和利益相关者展示已完成的功能sprint审核的大部分核的大部分实践用于践用于团队成成员展示功能、回答利益相关者展示功能、回答利益相关者对展示的疑展示的疑问并并记录所期望的更改所期望的更改评审会会议可以吸引相关利益者的关注，可以吸引相关利益者的关注，让其他人了解其他人了解团队在做些什么，在做些什么，并得到重要反并得到重要反馈做演示也会迫使开做演示也会迫使开发团队真正完成一些工作真正完成一些工作retrospective meeting:回回顾会会议，通常在，通常在reivew会会议之后开始，有之后开始，有团队成成员在冲刺在冲刺结束之后束之后对上个迭代上个迭代进行行总结，同，同时提出一些改提出一些改进方案，方案，这是一个持是一个持续改改进的的过程程 软件工程软件工程435个价值观个价值观承承诺 愿意愿意对目目标做出承做出承诺专注注 把你的心思和能力都用到你承把你的心思和能力都用到你承诺的工的工作上去作上去开放开放 Scrum 把把项目中的一切开放目中的一切开放给每个人每个人看看尊重尊重 每个人都有他独特的背景和每个人都有他独特的背景和经验勇气勇气 有勇气做出承有勇气做出承诺，履行承，履行承诺，接受，接受别人的尊重人的尊重 软件工程软件工程4445动态系统开发方法动态系统开发方法(DSDM)在可控在可控项目目环境中使用增量原型开境中使用增量原型开发模式以完模式以完全全满足足对时间有有约束的系束的系统的构建和的构建和维护是一种是一种过程框架，程框架，使用迭代使用迭代软件件过程程，Pareto原原则(20%的的时间完成完成80%的功能的功能)三个迭代周期三个迭代周期功能模型迭代设计和构建迭代实现 增量不需要100%完成46敏捷建模敏捷建模对于大型，业务关键型系统，传统建模以及文档：对于大型，业务关键型系统，传统建模以及文档：完美完美 庞大庞大 难以维护难以维护由由Scott Ambler提出，以轻量级方式对待软件提出，以轻量级方式对待软件建模的标准、原则和实践建模的标准、原则和实践敏捷建模原则敏捷建模原则有目的的建模有目的的建模使用多个模型，不同模型表达系统不同方面使用多个模型，不同模型表达系统不同方面轻装上阵，只保留能提供长期价值的模型轻装上阵，只保留能提供长期价值的模型内容重于表述形式；内容重于表述形式；理解模型及工具；建模方法适应本地团队需要理解模型及工具；建模方法适应本地团队需要47敏捷统一过程敏捷统一过程(AUP)Agile Unified Process,在大型上连续，在小型在大型上连续，在小型上迭代上迭代采用经典采用经典UP阶段活动：起始、细化、构建和转换阶段活动：起始、细化、构建和转换每个活动中，迭代使用敏捷，尽快交付软件增量每个活动中，迭代使用敏捷，尽快交付软件增量每个每个AUP迭代执行以下活动：迭代执行以下活动：建模建模实现实现测试测试部署部署配置及项目管理配置及项目管理环境管理环境管理。