软件工程敏捷软件开发课件.ppt

1、 软件工程软件工程 极限编程（极限编程（XP）方法）方法 相关敏捷过程模型相关敏捷过程模型 Scrum方法方法 动态系统开发方法动态系统开发方法 敏捷建模敏捷建模 敏捷统一过程敏捷统一过程2 软件工程软件工程 软件开发的新挑战软件开发的新挑战快速的市场进入时间，要求高生产率快速的市场进入时间，要求高生产率快速变化的需求快速变化的需求快速发展的技术快速发展的技术 传统的软件开发方法传统的软件开发方法强调过程和文档强调过程和文档对变化的适应能力偏弱对变化的适应能力偏弱3 Martin Fowler认为：认为：提前预测需求是困难的。同样，对项目进行提前预测需求是困难的。同样，对项目进行过程中客户需求

2、优先级的变更进行预测也很过程中客户需求优先级的变更进行预测也很困难困难对很多项目来说，软件设计和构建是交错进对很多项目来说，软件设计和构建是交错进行的。也就是说，设计需要通过实施构建来行的。也就是说，设计需要通过实施构建来获得验证，而在构建的过程中新获得的知识获得验证，而在构建的过程中新获得的知识又可以帮助设计又可以帮助设计从制定计划的角度来看，分析、设计、构建从制定计划的角度来看，分析、设计、构建和测试活动并不容易预测和测试活动并不容易预测 软件工程软件工程4 软件工程软件工程5 强调强调适应性适应性而不是可预测性而不是可预测性 经典软件开发方法经典软件开发方法：通过控制变化实现软件开发的通

3、过控制变化实现软件开发的可预测性可预测性 敏捷敏捷软件开发方法软件开发方法：变化变化是不可避免的，应该通过是不可避免的，应该通过改善管理实践和工程实践来更好地适应改善管理实践和工程实践来更好地适应变化变化 强调强调人人在在项目中项目中的的关键作用关键作用 敏捷软件开发认为人不是可以互相替换的敏捷软件开发认为人不是可以互相替换的“编程部编程部件件”，而是具有创造力的个体，成功的软件开发活，而是具有创造力的个体，成功的软件开发活动依赖于人的主观能动性动依赖于人的主观能动性 软件工程软件工程6 软件工程软件工程 强调强调“刚刚好刚刚好”（Just enough）在保证软件开发有成功产出的前提下，尽量

4、减少开在保证软件开发有成功产出的前提下，尽量减少开发过程中的活动和制品的方法，即开发中的活动及发过程中的活动和制品的方法，即开发中的活动及制品既不要太多也不要太少制品既不要太多也不要太少7 从从20世纪世纪90年代开始，逐渐产生了一大年代开始，逐渐产生了一大批敏捷软件开发方法批敏捷软件开发方法其中比较有影响的包括：极限编程、其中比较有影响的包括：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发看板方法、精益软件开发方法、水晶软件开发方法（方法（crystal）、自适应软件开发（）、自适应软件开发（adaptive software development，ASD）、动态系统开）、

5、动态系统开发方法（发方法（dynamic system development method，DSDM）等）等 软件工程软件工程8 2001年年2月，月，17位敏捷方法的先驱在美国位敏捷方法的先驱在美国犹他州召开了为期犹他州召开了为期2天的会议，天的会议，成立了敏成立了敏捷软件开发联盟捷软件开发联盟 并并发布了发布了“敏捷宣言敏捷宣言”该宣言由四个价值观声明组成，并提炼出该宣言由四个价值观声明组成，并提炼出敏捷软件开发方法必须遵循的敏捷软件开发方法必须遵循的12条原则条原则 软件工程软件工程9我们我们正通过亲身或者协助他人进行软件开发实践来正通过亲身或者协助他人进行软件开发实践来探索更好的软件

6、开发方法。探索更好的软件开发方法。基于此，我们建立了如下的价值观：基于此，我们建立了如下的价值观：个体个体和交互和交互 重于重于 过程和工具过程和工具工作的软件工作的软件 重于重于 详尽的文档详尽的文档客户合作客户合作 重于重于 合同谈判合同谈判响应变化响应变化 重于重于 遵循计划遵循计划也就是说也就是说，尽管右项有其价值，尽管右项有其价值，我们更重视左项的价值我们更重视左项的价值 软件工程软件工程10 软件工程软件工程 过程和工具是重要的，但是软件开发中人的作用和过程和工具是重要的，但是软件开发中人的作用和交流的作用更需要被进一步强调交流的作用更需要被进一步强调 软件是由人组成的团队来开发的

7、，与软件项目相关软件是由人组成的团队来开发的，与软件项目相关的各类人员通过充分的交流和有效的合作，才能成的各类人员通过充分的交流和有效的合作，才能成功地开发出得到用户满意的软件功地开发出得到用户满意的软件 如果光有定义良好的过程和先进的工具，而人员的如果光有定义良好的过程和先进的工具，而人员的技能很差，或者不能很好地交流和协作，软件是很技能很差，或者不能很好地交流和协作，软件是很难成功地开发的难成功地开发的11 软件工程软件工程可以工作的软件是软件开发工作的最终目标可以工作的软件是软件开发工作的最终目标好的好的必要的文必要的文档能档能帮助我们理解软件做什么，怎么帮助我们理解软件做什么，怎么做以

8、及如何使用做以及如何使用，是有价值的。但是，软，是有价值的。但是，软件开发的件开发的主要目主要目标仍然是标仍然是创建可运行的创建可运行的软件软件敏捷敏捷软件开发强调不断地快速地向用户提交可运行软件开发强调不断地快速地向用户提交可运行的软件（不一定是完整的软件），以得到用户的的软件（不一定是完整的软件），以得到用户的认认可可12 软件工程软件工程 只有客户才能明确说明需要什么样的软件，然而，只有客户才能明确说明需要什么样的软件，然而，大量的实践表明，在开发的早期客户常常不能完整大量的实践表明，在开发的早期客户常常不能完整地表达他们的全部需求，有些早期确定的需求，以地表达他们的全部需求，有些早期确

9、定的需求，以后也可能会改变后也可能会改变 由于软件开发的预测性的困难，想通过合同谈判的由于软件开发的预测性的困难，想通过合同谈判的方式，将需求固定下来常常是困难的方式，将需求固定下来常常是困难的 敏捷软件开发强调与客户的协作，通过与客户的交敏捷软件开发强调与客户的协作，通过与客户的交流和紧密合作来发现用户的需求流和紧密合作来发现用户的需求13 软件工程软件工程 任何软件项目的开发都应该制订一个项目计划，以任何软件项目的开发都应该制订一个项目计划，以确定各开发任务的优先顺序和起止日期。然而，随确定各开发任务的优先顺序和起止日期。然而，随着项目的进展，需求、业务环境、技术等都可能变着项目的进展，需

10、求、业务环境、技术等都可能变化，任务的优先顺序和起止日期也可能因种种原因化，任务的优先顺序和起止日期也可能因种种原因会改变会改变 因此，项目计划应具有可塑性，有变动的余地。当因此，项目计划应具有可塑性，有变动的余地。当出现变化时及时做出反应，修订计划以适应变化出现变化时及时做出反应，修订计划以适应变化14 我们的最高优先级是持续不断地、及早地交付有价值的我们的最高优先级是持续不断地、及早地交付有价值的软件来使客户满意软件来使客户满意 拥抱变化，即使是在项目开发的后期。敏捷过程愿意为拥抱变化，即使是在项目开发的后期。敏捷过程愿意为了客户的竞争优势而了客户的竞争优势而接纳接纳变化变化 经常地交付可

11、工作的软件，相隔几星期或一两个月，倾经常地交付可工作的软件，相隔几星期或一两个月，倾向于向于采用采用较短的周期较短的周期 业务人员和开发人员必须在项目的整个阶段紧密合作业务人员和开发人员必须在项目的整个阶段紧密合作 围绕着被激励的个体构建项目。为个体提供所需的环境围绕着被激励的个体构建项目。为个体提供所需的环境和支持，给予信任，从而达成目标和支持，给予信任，从而达成目标 在团队内和团队间沟通信息的最有效和最高效的方式是在团队内和团队间沟通信息的最有效和最高效的方式是面对面的交流面对面的交流 软件工程软件工程15 可工作的软件是进度的首要度量标准。可工作的软件是进度的首要度量标准。敏捷过程倡导可

12、持续开发。项目发起者、开发人员和用户敏捷过程倡导可持续开发。项目发起者、开发人员和用户应该维持一个可持续的步调。应该维持一个可持续的步调。持续地追求技术卓越和良好设计，可以提高敏捷性持续地追求技术卓越和良好设计，可以提高敏捷性 以简洁为本，它是减少不必要工作的艺术。以简洁为本，它是减少不必要工作的艺术。最好的架构、需求和设计是从自组织的团队中涌现出来的最好的架构、需求和设计是从自组织的团队中涌现出来的。团队定期地反思如何变得更加高效，并相应地调整自身的团队定期地反思如何变得更加高效，并相应地调整自身的行为。行为。软件工程软件工程16 致力于降低变化致力于降低变化带来带来的成本的成本 强调强调价

13、值价值 强调强调人的人的作用作用 使用增量和迭代的开发方法使用增量和迭代的开发方法 软件工程软件工程17 软件工程软件工程 敏捷软件开发概述敏捷软件开发概述 相关敏捷过程模型相关敏捷过程模型 Scrum方法方法 动态系统开发方法动态系统开发方法 敏捷建模敏捷建模 敏捷统一过程敏捷统一过程18 软件工程软件工程1996年，年，Kent Beck等人在等人在Chrysler的的C3项项目的开发过程中逐步产生了极限编程的基本概目的开发过程中逐步产生了极限编程的基本概念念1999年，年，Kent Beck撰写了撰写了解析极限编程：解析极限编程：拥抱变化拥抱变化，对极限编程的价值观、原则和实，对极限编程

14、的价值观、原则和实践进行了阐述践进行了阐述19 软件工程软件工程20 XP 策划策划 开始于倾听，倾听产生一系列开始于倾听，倾听产生一系列“用户故事用户故事”。团队成员评估每一个故事，并给出以开发周数为度量单团队成员评估每一个故事，并给出以开发周数为度量单位的位的成本成本。团队共同决定如何将故事分组，并置于将要开发的下一团队共同决定如何将故事分组，并置于将要开发的下一个个软件增量软件增量中中。给出对给出对下一个发布版本的基本承诺（就包括的故事、交下一个发布版本的基本承诺（就包括的故事、交付日期和其他项目事项）付日期和其他项目事项）项目的第一个发行版本（也称为一个软件增量）交付之项目的第一个发行

15、版本（也称为一个软件增量）交付之后，后，XP团队计算团队计算项目的速度项目的速度，用于帮助估计后续发行版用于帮助估计后续发行版本的发布日期和进度安排。本的发布日期和进度安排。软件工程软件工程21 XP设计设计 严格遵循KIS（Keep It Simple，保持简洁）原则。鼓励使用CRC卡。如果在设计中碰到困难，推荐使用“Spike解决方案”鼓励“重构”以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。XP编程编程 推荐在编码开始之前建立单元测试。鼓励“结对编程”。XP测试测试 所有单元测试应当使用一个可以自动实施的框架。“验收测试”由客户规定技术条件，并且着眼于客户可见的系统级特

16、征和功能。22 结对编程结对编程提高了设计的可靠性和质量提高了设计的可靠性和质量 在做任何设计的时候在做任何设计的时候，都有两个程序员一起思考，都有两个程序员一起思考，可以汇集两个程序员的设计思想可以汇集两个程序员的设计思想 在代码编写完成的时候同时也通过了代码审查在代码编写完成的时候同时也通过了代码审查 这种方式有助于减少程序中的错误，降低测试这种方式有助于减少程序中的错误，降低测试时间和测试成本时间和测试成本 软件工程软件工程23 软件工程软件工程 故事是对团队应该完成的工作的陈述故事是对团队应该完成的工作的陈述。极限编程。极限编程通过故事来体现价值观中的通过故事来体现价值观中的“沟通沟通

17、”的原则。好的原则。好的用户故事应该能够触发客户和开发团队之间的的用户故事应该能够触发客户和开发团队之间的沟通沟通 作为和客户的良好沟通的成果，故事拥有清楚的作为和客户的良好沟通的成果，故事拥有清楚的完成标准。一种常见的策略是，从用户的角度描完成标准。一种常见的策略是，从用户的角度描述一组验收测试用例，开发团队使用该验收测试述一组验收测试用例，开发团队使用该验收测试用例来验证是否已经完成了某个用例来验证是否已经完成了某个故事故事24 软件工程软件工程 估算是极限编程中隐含的实践，很多应用极限编估算是极限编程中隐含的实践，很多应用极限编程的团队使用估算来帮助沟通、制定迭代和发布程的团队使用估算来

18、帮助沟通、制定迭代和发布计划计划 估算不仅仅是帮助确定故事的规模，更重要的是估算不仅仅是帮助确定故事的规模，更重要的是通过对故事点的讨论，团队可以发现需求或实现通过对故事点的讨论，团队可以发现需求或实现中可能存在的问题中可能存在的问题25 软件工程软件工程 完成了定义的功能完成了定义的功能,能通过所有的测试能通过所有的测试 该设计描述了程序员的重要意图，便于理解和沟该设计描述了程序员的重要意图，便于理解和沟通；设计和实现没有冗余、没有重复的逻辑通；设计和实现没有冗余、没有重复的逻辑 在满足以上条件的前提下，没有多余的类和方法在满足以上条件的前提下，没有多余的类和方法26 软件工程软件工程 重构

19、是在不改变代码的外部行为的情况下，通过重构是在不改变代码的外部行为的情况下，通过调整内部的结构，来持续保持代码的可理解、可调整内部的结构，来持续保持代码的可理解、可维护特征维护特征27 软件工程软件工程测试驱动开发的测试驱动开发的3个快速循环的步骤：个快速循环的步骤：编写一个测试编写一个测试该测试试图发现代码中有一处功能没有实现，或该测试试图发现代码中有一处功能没有实现，或者代码中存在一个需要修复的问题者代码中存在一个需要修复的问题 编写代码编写代码使用尽可能快的方式编写产品代码，使这个测试使用尽可能快的方式编写产品代码，使这个测试得以通过得以通过 对代码进行重构对代码进行重构28 软件工程软

20、件工程 结对编程提高了设计的可靠性和质量结对编程提高了设计的可靠性和质量 在做任何设计的时候在做任何设计的时候，都有两个程序员一起思考，可以都有两个程序员一起思考，可以汇集两个程序员的设计汇集两个程序员的设计思想思想 在代码编写完成的时候同时也通过了在代码编写完成的时候同时也通过了代码审查代码审查 这种方式有助于减少程序中的错误，降低测试时这种方式有助于减少程序中的错误，降低测试时间和测试间和测试成本成本29 瀑布模式：瀑布模式：重型开发方式，每个阶段都要求完美，无法适应变更 迭代开发迭代开发 不要求每个阶段的任务都完美，逐步完善 螺旋开发螺旋开发 风险驱动的开发方式 敏捷开发敏捷开发 相比迭

21、代，开发周期更短，并强调沟通合作 软件工程软件工程30 沟通沟通 简单简单 反馈反馈 勇气勇气 谦逊谦逊 强调把列出的每个方法和思想做到极限强调把列出的每个方法和思想做到极限 软件工程软件工程31 软件工程软件工程 敏捷软件开发概述敏捷软件开发概述 极限编程（极限编程（XP）方法）方法 动态系统开发方法动态系统开发方法 敏捷建模敏捷建模 敏捷统一过程敏捷统一过程32 以人为中心、迭代、循序渐进的开发方法以人为中心、迭代、循序渐进的开发方法 不以文档作为驱动，强调人与人之间的面对面的沟通交不以文档作为驱动，强调人与人之间的面对面的沟通交流流 迭代：把复杂并且开发周期长的开发任务，分解成很多迭代：

22、把复杂并且开发周期长的开发任务，分解成很多小周期可完成的任务，这样的每个小周期就是一个迭代小周期可完成的任务，这样的每个小周期就是一个迭代过程，每次迭代都产生一个可交付的产品过程，每次迭代都产生一个可交付的产品 快速迭代快速迭代 拥抱变化拥抱变化 敏捷是一种指导思想，敏捷是一种指导思想，Scrum和和XP就是具体的开发方就是具体的开发方式了，式了，Scrum偏重于过程，而偏重于过程，而XP重在实践重在实践 Scrum,橄榄球运动的专业术语，表示橄榄球运动的专业术语，表示“争球争球”动作，动作，软件工程软件工程33 Scrum90年代中期，敏捷过程模型年代中期，敏捷过程模型 Scrum 橄榄球比

23、赛橄榄球比赛；Sprint 比赛中的冲刺比赛中的冲刺 框架性过程活动框架性过程活动 需求需求 分析分析 设计设计 演化演化 交付交付 软件工程软件工程3435 软件工程软件工程36 软件工程软件工程37 确定确定Product Backlog（按（按优先顺序排列的一个产品需求列表优先顺序排列的一个产品需求列表；Scrum Team根据根据Product Backlog列表，做工作量的预估和安列表，做工作量的预估和安排；排；根据根据Product Backlog列表，通过列表，通过 Sprint Planning Meeting来来从中挑选出从中挑选出一个一个Story作为本次迭代完成的目标作为

24、本次迭代完成的目标，该目标的时间，该目标的时间周期是周期是14个星期，然后把这个个星期，然后把这个Story进行细化，形成一个进行细化，形成一个Sprint Backlog；Sprint Backlog是由是由Scrum Team去完成的，每个成员根据去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在再细化成更小的任务（细到每个任务的工作量在2天内能完成）；天内能完成）；软件工程软件工程38在在Scrum Team完成计划会议上选出的完成计划会议上选出的Sprint Backlog过程中，过程中，需要进行需要进行 Daily Scrum Meeting

25、（每日站立会议），（每日站立会议），每次会议每次会议控制在控制在15分钟左右分钟左右，每个人向所有成员当面汇报你昨天完成了什，每个人向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的的Sprint burn down（Sprint燃尽图燃尽图）每日集成，每天都要有一个可以成功编译、并且可以演示的版本每日集成，每天都要有一个可以成功编译、并且可以演示的版本(自动工具实现自动工具实现)当一个当

26、一个Story完成，也就是完成，也就是Sprint Backlog被完成，也就表示一被完成，也就表示一次次Sprint完成，要进行完成，要进行Srpint Review Meeting（演示会议），（演示会议），也称为评审会议，产品负责人和客户都要参加每一个也称为评审会议，产品负责人和客户都要参加每一个Scrum Team的成员都要向他们演示自己完成的软件产品的成员都要向他们演示自己完成的软件产品Sprint RetrospectiveMeeting（回顾会议），也称为总结会（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的议，以轮流发言方式进行，每个人都要发言

27、，总结并讨论改进的地方，放入下一轮地方，放入下一轮Sprint的产品需求中；的产品需求中；软件工程软件工程39 软件工程软件工程40 3个角色个角色 Product Owner：产品负责人，清楚的知道产品的愿景产品负责人，清楚的知道产品的愿景，需要对产品待办列表的梳理，优化，优先级排序等负，需要对产品待办列表的梳理，优化，优先级排序等负责。决定团队每个冲刺要完成哪些任务，负责产品的功责。决定团队每个冲刺要完成哪些任务，负责产品的功能和达到要求的标准，指定软件的发布日期和交付内容能和达到要求的标准，指定软件的发布日期和交付内容 Scrum Master是是Scrum教练和团队带头人，确保团队教练

28、和团队带头人，确保团队合理的运作合理的运作Scrum，并帮助团队扫除实施中的障碍，负，并帮助团队扫除实施中的障碍，负责流程在项目中的顺利实施和进行责流程在项目中的顺利实施和进行 Team是开发团队，能够交付一个端到端的真正对客户是开发团队，能够交付一个端到端的真正对客户有价值的产品有价值的产品 软件工程软件工程41 3个工件个工件 Product Backlog：是指产品待办事项的集合，其中事是指产品待办事项的集合，其中事务有优先级判断，先处理优先级高的事项。务有优先级判断，先处理优先级高的事项。Sprint Backlog：每个迭代的功能开发列表，每个迭代的功能开发列表，PO会根会根据团队的

29、能力并按照产品待办列表中的优先级来选取每据团队的能力并按照产品待办列表中的优先级来选取每个冲刺要做的事情。团队可以专注在每个迭冲刺要走的个冲刺要做的事情。团队可以专注在每个迭冲刺要走的事情上而不被打断。事情上而不被打断。Burn down chart:燃尽图，在每个迭代显示剩余工作燃尽图，在每个迭代显示剩余工作时间和任务完成情况时间和任务完成情况 软件工程软件工程42Sprint:冲刺冲刺,一个固定的时间周期（通常为一个固定的时间周期（通常为2w-4w）,团队要尽可能在这团队要尽可能在这个周期内交付可以工作的软件给客户个周期内交付可以工作的软件给客户sprint planning meetin

30、g:冲刺开始的时候，冲刺开始的时候，PO会和团队一起从会和团队一起从PB中选中选择本次要做的任务择本次要做的任务/故事，并且会对团队提出的疑问进行解释和澄清。同故事，并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务，最后会形成本次的时团队会估算故事并分解成任务，最后会形成本次的Sprint Backlog.daily standup meeting:每日站会，每日站会，scrum为了加强团队沟通，每天团队为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题都要选择一个时间站在一起，互相交流彼此的进展和问题,以便及时解决以便及时解决出现的问题，同时也能

31、让团队随时了解我们离冲刺目标还有多远。出现的问题，同时也能让团队随时了解我们离冲刺目标还有多远。sprint review:在在sprint周期最后，需要进行一次评审会议，让团队向产周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，

32、并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。么，并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。retrospective meeting:回顾会议，通常在回顾会议，通常在reivew会议之后开始，有团会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程这是一个持续改进的过程 软件工程软件工程43 承诺承诺 愿意对目标做出承诺愿意对目标做出承诺 专注专注 把你的心思和能力都用到你承诺的工把你的心思和能力都用到你承诺的工作上去作上去 开放开放 Scrum 把项目中的

33、一切开放给每个人把项目中的一切开放给每个人看看 尊重尊重 每个人都有他独特的背景和经验每个人都有他独特的背景和经验 勇气勇气 有勇气做出承诺，履行承诺，接受别有勇气做出承诺，履行承诺，接受别人的尊重人的尊重 软件工程软件工程4445 在可控项目环境中使用增量原型开发模式以完在可控项目环境中使用增量原型开发模式以完全满足对时间有约束的系统的构建和维护全满足对时间有约束的系统的构建和维护 是一种过程框架，是一种过程框架，使用迭代软件过程使用迭代软件过程，Pareto原则原则(20%的时间完成的时间完成80%的功能的功能)三个迭代周期三个迭代周期 功能模型迭代 设计和构建迭代 实现 增量不需要100

34、%完成46 对于大型，业务关键型系统，传统建模以及文档：对于大型，业务关键型系统，传统建模以及文档：完美完美 庞大庞大 难以维护难以维护 由由Scott Ambler提出，以轻量级方式对待软件提出，以轻量级方式对待软件建模的标准、原则和实践建模的标准、原则和实践 敏捷建模原则敏捷建模原则 有目的的建模有目的的建模 使用多个模型，不同模型表达系统不同方面使用多个模型，不同模型表达系统不同方面 轻装上阵，只保留能提供长期价值的模型轻装上阵，只保留能提供长期价值的模型 内容重于表述形式；内容重于表述形式；理解模型及工具；建模方法适应本地团队需要理解模型及工具；建模方法适应本地团队需要47 Agile Unified Process,在大型上连续，在小型在大型上连续，在小型上迭代上迭代 采用经典采用经典UP阶段活动：起始、细化、构建和转换阶段活动：起始、细化、构建和转换 每个活动中，迭代使用敏捷，尽快交付软件增量每个活动中，迭代使用敏捷，尽快交付软件增量 每个每个AUP迭代执行以下活动：迭代执行以下活动：建模建模 实现实现 测试测试 部署部署 配置及项目管理配置及项目管理 环境管理环境管理