本书系统地列出RUP未能解决的业务上和技术上的问题，展示了EUP如何填补这些鸿沟。本书在分析并研究实际案例时引出了过程和规程等概念，涉及企业架构、实施战略重用、过时代码和系统的淘汰、软件项目组合的管理等各方面的内容。本书将帮助读者发现EUP，掌握EUP，实现EUP并且取得成功。
主要内容：
●优化正在进行的经过验证的IT运行和支持过程。
●企业业务建模、企业架构和驾驭IT所有工作的项目组合管理等规程。
●战略重用、人员管理、软件过程改进等规程。
●一个企业资产管理规程包括：数据管理、安全管理、网络管理和设备管理等实践。
●给出了与RUP完全一致的工作流图。
●为在中型到大型企业中引入EUP提供的指导。
●涵盖了角色、工件和术语的详尽附录。
无
那是一个漆黑的、雷雨交加的夜晚，突然一声巨响。信息技术（Information Technology，IT）部门又一次未能成功地交付他们的系统，并且这次交付是企业涉众所期待的最后一根稻草—现在，真的是将整个部门外包的时候了。
类似的事件是不是听起来很熟悉 这种现象在全世界范围内的IT部门内部频繁发生，原因是这些部门不能向他们的业务涉众提供充分的价值。在真正提交全部项目时，企业涉众对迟交、超出预算等情况已经越来越不耐烦了。对同样的功能性项目不断地推迟交付、系统支持不到位、运行的系统相互之间不能协同工作、与IT相关的服务费用不断地增长等等问题已经让他们感到厌烦了。许多IT部门处于十字路口—要么他们改变运作方式，要么做好准备：被能更有效地提供运行软件的其他部门所取代。
自1999 年以来，Ronin国际公司一直在帮助IT企业引进统一过程，以便这些公司能更好地进行软件开发。起初，大多数客户需要引进Rational统一过程（Rational Unified Process，RUP），但他们后来意识到，需要外界帮助他们扩展RUP的范围以处理软件开发范围以外的问题。我们在Ronin国际公司开始注意到这些顾客共同面临的一系列问题，这些问题激励着我们开发企业统一过程（Enterprise Unified Process，EUP），这个过程超越了RUP成为一个完整的IT生命周期。对于许多IT部门而言，RUP是一个具有意义的起点，而EUP则把RUP带入了一个更高的层次。
关于这本书，你会注意到的第一件事情就是，我们给出的方法与统一过程的方法稍有不同。我们不是在为IBM公司工作，并且从结果来看，我们站在一个客观的立场上，描述了在实践中遇到的实际运作情况。不要担心，我们一点也不偏离RUP范围之内的规范，因为，坦率地说IBM公司已经把领域内的工作做得相当好了。这本书的价值是把RUP做了一些扩展—增加了两个新阶段和八个新规程—这使RUP为现实世界的IT部门真正地做好了准备。你可以快速浏览一下本书目录，以便理解我们所说内容的真正含义。
从根本上来说，本书是从整个IT部门这个视角来看待过程，讨论IT专业人员每天面对的疑难问题，而不只看单个项目或系统。本书的特点是广泛地阐述了你所要做的事情。本书详细地描述了你所面对的问题，并且提供解决这些问题的策略，但几分钟的细节描述是不会浪费你宝贵时间的。在我们工作过的每个组织，我们发现，组织拥有知道他们正做着什么的优秀人员， 但缺少的是使这些人有效地协同工作的统一方法。这本书不会把你变成一个项目组合管理专家、企业构架师或别的什么专家，但它将解释在IT组织里这些角色所要解决的根本问题以及解决这些问题的策略。
本书的特点
本书具有以下几个特点，这使它成为对称有价值的资源：
·实用性强：本书提供了浅显易懂的实用建议。
·阐述关键问题：本书重点讲述了你每天面对的根本问题，并且描述了解决这些问题的选择。但是，这不会浪费你关注局外细节的时间，那些细节对你的公司而言无论如何都具有代表性，是独一无二的。
·与RUP保持一致：那些描述新阶段和规程的章节包含了很多工作流图，描述这些工作流图的方法都是与RUP产品中使用的描述方法一致。当前RUP的实践者会立即认出这种方法并且明白这些图的含义。
·包括案例研究：我们与大家分享了我们的经验，大部分是好的（虽然一些是不好的）。这些经验是自1999年以来我们在将RUP和EUP引入公司的实践中所获得的。
·包含阅读回报率（ROI）栏：每一章开头归纳出要点，提供一章内容的快速概览。
·包含推荐资源：每章以建议结束，从推荐资源中可以寻找更多信息。
本书读者对象
本书面向在RUP方面有一定经验、想寻找IT改进和扩展方法的IT专业人员。
即使你是一个有能力的人，能胜任自己的工作，也必须认识到，如果希望在来年继续取得成功，你的组织、也许还包括你，在IT方面需要改进工作方法，这本书会提供一种洞察力，使你发现自己何处出现错误，并且还提供了迎接这些挑战的策略。
致谢
我们想鸣谢以下在本书的撰写过程中经常以敏锐的反馈形式帮助我们的人：Michael Boggs、Susan Burk、Beverley Dawe、Gary K. Evans、John Harrison、Doug Hill、Mauricio Iannini、Ben Lawson、Pete McBreen、Paul Petralia、Gary Pollice、Bob Rhubart、Rebecca Savoie、Graeme Simsion、Michael Thurston、Michelle Vincenti、Kenneth Vizdos、Kenneth Ward、Lars Wendestam和Brad White。
本书系统地列出RUP未能解决的业务上和技术上的问题，展示了EUP如何填补这些鸿沟。本书在分析并研究实际案例时引出了过程和规程等概念，涉及企业架构、实施战略重用、过时代码和系统的淘汰、软件项目组合的管理等各方面的内容。本书将帮助读者发现EUP，掌握EUP，实现EUP并且取得成功。 主要内容： ●优化正在进行的经过验证的IT运行和支持过程。 ●企业业务建模、企业架构和驾驭IT所有工作的项目组合管理等规程。 ●战略重用、人员管理、软件过程改进等规程。 ●一个企业资产管理规程包括：数据管理、安全管理、网络管理和设备管理等实践。 ●给出了与RUP完全一致的工作流图。 ●为在中型到大型企业中引入EUP提供的指导。 ●涵盖了角色、工件和术语的详尽附录。
我的第一份开发工作是20世纪70年代在一家大型保险公司做一个APL程序员。我们必须构建、运行、维护和淘汰很多系统，这些系统是数以百计甚至是数以千计的人使用过的大型系统。从那时起有些事发生了根本变化：当时，IBM计算机主机有了将近8MB的内存，其成本比一些国家国民生产总值还要高，并且占地面积多达一个办公楼整层楼！但是有一些事依然还是保持没变，因为我发现在这个有用的指南中有以前的教训，并且是我应该学到但没有真正学到的教训。虽然正式地讲其主题是企业统一过程，但是不要让它误导你认为它没什么可提供的，除非你是Rational统一过程组织的一员。相反，对于每一个IT业界人士，这本书是非常有价值的学习助手。
Scott、Mechael和John很好地组织、总结并且综合了许多IT企业的运营管理和IT生命周期的关键技能，并提供了大量的进一步学习优秀著作所需的要诀和提示。而且，也许最重要的是他们用敏捷和迭代的精神表达这些提示，推动开发的演进，我们现在知道这种迭代式演变开发对于成功是至关重要的。在我与Scott的交往过程中，感觉他是一个富有激情和智慧的人，同是他又是一个注重实效的人，多年来一直致力于倡导现代开发实践。我一直从他的忠告中受益，可以肯定你也将和我一样会从中受益。
—Craig Larman，Valtech公司首席科学家
2004年12月于意大利 罗马
Scott W.Ambler, John Nalbone, Michael J.Vizdos：Scott W.Ambler: Scott W. Ambler是软件开发方法年轻一代的领军人物之一，在理论和实践上的造诣都很深厚。作为一位高级咨询师，他一直积极参与全球各种大型软件开发和过程改进项目。同时，他还是一位视野广阔的方法学者，是《Software Development》杂志的专栏作家，撰写了多部颇受推崇的著作，其中包括《The Object Primer》、《Agile Modeling》、《The Elements of UML Style》、《More Process Patterns》等。
John Nalbone: John Nalbone 是Ronin公司的高级顾问。他有15年的工作经验，曾担任过软件开发人员、分析师、设计师、架构师、项目经理和过程工程师。
Michael J.Vizdos: Michael J. Vizdos 是Ronin公司的总裁。他在领导专业服务团队帮助提升企业软件开发过程方面具有丰富的经验。他是公认的杰出大师。
方春旭 叶向群 胡协刚：暂无简介
软件产业的不断发展，使人们越来越认识到过程在软件开发和生产中的重要作用，遵循良好的过程是高效率、高质量和低成本地开发和运行软件的必由之路。围绕软件过程改进进行的专题培训、企业内部培训等越来越多，业界的一些专家、学者围绕这一领域编著、翻译的书籍也很多。然而略感遗憾的是，人们在认识到软件过程重要性的时候，对如何有效且高效地实践这些过程却还未找到最佳方法，这方面的专著目前也比较匮乏。本书作者在大量的软件过程经验和长期广泛收集业界杰出人物经验的基础上提出了软件过程最佳实践方法，并将这些方法和统一过程的各阶段对应起来。
公司的总裁们不会因为软件项目按时提交、成本在预算范围内并且缺陷最少就感到高兴，他们需要清楚地看到该项目为组织在业务方面创造了多大的价值。企业统一过程（Enterprise Unified Process，EUP）通过将Rational统一过程（Rational Unified Process，RUP）所关注的系统开发生命周期逐步进行扩展，延伸到单个系统的生命周期、再到组织内多个系统的IT生命周期、最终到组织的业务生命周期，从而帮助组织将软件项目所要达到的目标和业务目标统一起来。两者区别在于：RUP是单个项目的指南针，集中讨论单个项目的开发，而EUP是整个IT的指南针，为整个组织的IT提供了路标。
本书作者综合了RUP、面向对象软件过程（OOSP）、极限编程（XP）等软件过程，形成了一个处理现实中开发软件和产品所需要的更完整、更健壮的统一过程—EUP，EUP涵盖了RUP的全部内容，并且从实现企业系统规划、开发和管理等方面对RUP的范围做了非常有意义的扩展—更为可贵的是本书关注的这些内容在其他软件过程方面的书中很少提及到。本书编排思路是：在分别详细阐述RUP和EUP之后，由于EUP是对RUP的扩充，所以略去RUP中的阶段和规程，只介绍EUP特有的阶段和企业级规程。要点如下：
生产阶段：RUP项目生命周期以移交阶段的产品发布里程碑作为终结。然而，信息技术(IT）的内涵不仅仅是构建和部署系统，真正目的将系统用于生产，必须运行和支持系统，这些工作需要在生产阶段来完成。
退役阶段：退役阶段的目标其实就是从生产环境中删除老系统并且用新系统替代。如果你曾经做过这件事，你就知道这件事有多么复杂。从书中给出的实例你可以感受到作者丰富的实战经验。
运行与支持规程：运行与支持规程的主要目标是在生产环境中运行与支持你的软件。运行的重点是确保软件在正常地运行，网络是可用的而且处于监控之下，相关的数据得到备份，在出现突发事故时可以及时恢复，灾难防备和系统恢复计划始终处于就绪状态。支持关注的焦点是协助最终用户，回答他们提出的问题、分析他们在运用系统进行生产时遇到的问题，记录新的功能请求、开发和部署补丁程序。
企业业务建模规程：RUP业务建模规程提供业务结构描述和特定项目组织过程，关注项目的适应范围和表示系统如何适应和支持业务，这对项目来说是非常重要，但对企业来说还不够，因为在RUP内没有一种机制能够充分描述跨系统问题，没有在概念上做调整，它也没有提供一个清晰的能够在项目之间共享信息的方法，因此在EUP里需要这种规程。企业业务建模为过程、结构和外部业务环境建模时提供了整个组织范围内的视角，为IT部门提供支持和工作的环境。所有业务软件是嵌入在商业过程中，除非业务是成功的，否则业务软件就不可能成功，这就是需要企业业务建模规程的原因。
项目组合管理：项目组合管理的目标是到确保所有的项目可见，有计划，并且共同达到业务目标，从而满足组织战略层面的业务目标。为了完成这个目标，必须对总体项目组合进行规划，项目组合内如何管理程序，执行和演化这些计划，管理企业级的合同，和在管理程序和项目组合层面上管理风险。如果你的组织中有项目正处于策划阶段、开发阶段、系统在线生产阶段，那么项目组合管理可能是你要关注的一个重点。
企业架构规程：有效的企业架构能促进组织内各系统之间保持一致，它将指导开发团队朝着使用一套公共的经过验证的方法开发应用程序架构。这将需要一套公共的机制和跨系统的兼容语义来保证构件或模块既能重用又能集成。企业架构师关注自己的决策对多个系统将产生怎样的影响，既包括当前“现实”模型构建的已有系统，又包括未来的“理想”模型将要构建的系统。他们不仅关注单个应用的需求，而且还评估在架构方面对整个企业内其他系统的影响，为将来的工作打下基础。企业架构师负责明确地阐述、求证企业架构，并为此提供技术支持。企业架构可以由应用项目团队来构建，可以由企业资产管理员来维护，这些资产管理员对网络和硬件基础设施、数据和安全负责。企业架构师不应该只维护这些构建成果，他们更应该积极地参与到构建架构的过程中。
战略重用规程：重用范围很广的资产是可能的—从源代码到模板，到框架以及整个架构—但要使重用获得成功，必须看到超越单个项目的范围。战略重用规程描述了如何通过跨系统的方法提高项目的重用水平。为了使重用获得成功，需要在组织内计划、执行和监控重用方案。有许多种方法可以获得具有潜在重用性的健壮资产，包括收集整理内部资产，下载或购买外部资产以及从头开始开发资产。在重用性上所做的工作必须得到支持；把可重用的工件做得越简单，人们重用它的机会越大；还应当评测重用工作所带来的成功以获得项目的后续资金和管理层的支持。
人员管理规程：当今世界，所有的组织都在两个不同的前沿展开竞争：一是产品或服务，二是雇佣和/或重新培训有才能的人才。软件开发管理工作量比创建技术上的任务和项目计划及项目进度表的制定和实施要多得多。需要管理知识员工，帮助他们成长以及协调他们与他人的互动等。本规程描述了如何组织、监控、教育、训练和激励知识员工，以确保他们很好地在一起工作并成功完成组织内的项目，提高IT组织内的个人工作效率。
企业资产管理规程：企业资产管理规程的目的是定义组织如何以安全的方式创建、维护、管理和部署物理资产和信息资产。企业资产管理员应当在日常管理基础上与项目团队合作协助团队的工作并且确保满足组织的长远需要。
软件过程改进规程：成功的软件过程改进是一个跨越多项目的艰苦工作，必须在整个组织层面进行管理。软件过程改进规程定义了必要的活动，这些活动描述了如何为组织定义软件过程并提供支持。描述如何决定过程需求，如何起草新过程或裁剪已有过程，如何部署和管理过程。软件过程改进是一个迭代的过程，必须根据反馈和实际结果进行调整。
总之，EUP捕获企业的活动的集合以及系统部署之后所要做的所有工作，这些都是RUP定义中未涉及到而又是我们必须要做的工作。EUP把不同的规程按单元分类，包括开发、企业架构、运营、生产阶段的维护和项目组合管理、重用、企业业务过程建模，按照这个框架这些工作将轻松完成。
对IT组织中任何一个从事开发信息系统的团队成员来说：本书是一本必读的书。本书作者把构建真实系统得到的实践经验进行了系统的归纳和整理，为读者提供了大量实用的方法、提示、反模式、活动时机、工具和实践指南，这些经验和方法都在IT领域里使用过，并且为大型企业级项目获得成功，极具参考价值。
对软件架构师来说：这本书用当今最佳实践的实用表达形式和综合方法将现实中企业中软件开发的复杂组件组织在一起。当你希望整个组织里的各个系统更安全稳定地运行，并且高效地互通和协作，而不是像现在这样一直不断地为你那个破旧的系统修修补补，各个系统像一座座烟囱那样独立运行、互不相通，那么EUP的企业级业务建模和企业架构将会为你提供指南。如果你的组织正在学习和实践迭代式软件开发，那么本书就是一本以RUP为起点的完整地图册和交通图。本书所有内容都集中在提交产品和在生产阶段对产品运行的支持。对那些想要获得有效的企业架构的人来说，本书是一本非常优秀的读物。
对项目经理、部门经理等经理人来说：本书会让经理人产生新鲜感，帮助经理人认识到需要把软件安装作为计划、开发和部署过程的一部分，对任何一个希望确保核心的IT规程得以实现的经理人来说，本书是非常优秀的指导书。
对信息总监和企业资产管理员来说：本书让IT部门能够从整体上更好地理解开发，书中的内容非常简单明了，本书组织清晰，便于快速参考，可以像菜谱一样易于查阅，它为信息总监理解如何让IT更好地为企业服务提供了一个框架。对于企业资产管理员来说，不论你是网络工程师、安全工程师还是设备工程师，本书都有详细的工作指导让你受益匪浅。
对过程改进人员来说：当今的企业要求通过过程改进寻求更低的总成本，更好的软件质量，减少风险。达到这些目标需要在人员、过程和工具之间做出巨大的努力。书中无数提示(包括反模式)，可以让你将所有工作都纳入统一过程，单提示这部分内容就让你觉得买这本书物有所值。
对于有一定RUP经验的实践者来说：本书为那些已经实践了RUP，并渴望上一个台阶的实践者编写了一个优秀的、可以轻松掌握的指南。本书采用平实的语言，加上直观的图形，提示和案例研究，勾画了第二代RUP框架，让我们更加从容地应对不断向出现挑战的开发环境。
选择翻译本书的目的是为实践统一过程的专业人员提供最佳实践参考。本书主要读者是企业的信息总监（CIO）或者是负责引进企业统一过程的领导。本书可作为IT项目经理、过程工程师、系统分析师和架构设计师、质量工程师、网络工程师、系统工程师、设备工程师、技术支持工程师和软件工程师等软件从业人员的软件过程实践指导书，也可以作为高等院校计算机及相关专业的研究生和本科高年级学生的教材。
本书的译者，即中国软件架构师网翻译组成员是国内较早引入UML模型驱动开发方法的倡导人，也是最早的统一软件过程的实践者。我们期望将欧美当前主流的软件开发方法、架构技术及软件过程引入国内，为此，专门成立了非盈利的机构—中国软件架构师网。我们非常欢迎大家访问我们的网站：http://www.china architect.org/，我们将把有关的实例模型、文档与代码放置该网站上，以便大家学习交流。
相信本书的翻译出版，对促进国内软件从业人员掌握现代化软件开发与管理的内在规律大有裨益，希望能引起广泛的共鸣。因水平有限，难免存在一些疏漏和差错，恳请各位读者批评指正。
本书由叶向群翻译，方春旭、胡协刚审校，陈智、曾远芳、黎娟也为本书的翻译和审校做了大量工作，在此表示衷心感谢！
中国软件架构师网翻译组
2007.6.6
译者序
序言
前言
关于作者
第一部分 从RUP到EUP
第1章 引论 1
1.1 过程的类型 3
1.2 企业统一过程的历史 4
1.3 为什么需要IT过程 6
1.4 关于本书 6
1.5 本章小结 7
第2章 Rational统一过程 8
2.1 宏观上的连续性 8
2.2 微观上的迭代性 11
2.3 随着时间的推移提供增量版本 12
2.4 经过验证的最佳实践 13
2.5 为什么采用Rational统一过程 14
2.6 作为一个过程的框架 15
2.7 本章小结 16
第3章 企业统一过程引论 17
3.1 从开发到系统生命周期 17
3.2 产品化阶段 19
3.3 退役阶段 19
3.4 运行和支持规程 20
3.5 信息技术生命周期 20
3.6 ZACHMAN框架与企业统一过程 22
3.7 贯穿本书的主要线索 25
3.8 实践中的企业统一过程 28
3.9 本章小结 29
第二部分 超越开发工作
第4章 生产阶段 31
4.1 生产阶段的目标 32
4.2 生产阶段的核心活动 32
4.3 处理并行发布 34
4.4 支持策略 36
4.5 发布退役里程碑 36
4.6 案例研究 37
4.6.1 使用并运行业务应用软件 37
4.6.2 微软支持 38
4.7 本章小结 38
第5章 退役阶段 39
5.1 退役阶段的目标 40
5.2 核心活动 41
5.2.1 分析系统的交互 43
5.2.2 决定退役策略 46
5.2.3 更新文档 47
5.2.4 测试 47
5.2.5 迁移用户 48
5.2.6 删除系统 48
5.3 管理退役工作 49
5.4 发布退役里程碑 50
5.5 案例研究 50
5.5.1 一个大型机系统的移除 50
5.5.2 一套办公软件的退役 51
5.6 本章小结 52
第6章 运行与支持规程 53
6.1 工作流 53
6.1.1 计划运行与支持的部署 54
6.1.2 支持用户 57
6.1.3 运行系统 60
6.1.4 预防灾难 61
6.1.5 灾难后的恢复 63
6.2 案例研究 63
6.2.1 运行 63
6.2.2 支持 64
6.3 反模式 64
6.4 时机 64
6.5 工具集 65
6.6 与其他规程的关系 65
6.7 本章小结 65
第三部分 企业管理规程
第7章 企业业务建模规程 67
7.1 工作流 69
7.1.1 定义企业战略 70
7.1.2 业务过程建模 72
7.1.3 识别过程执行选项 75
7.1.4 领域建模 76
7.1.5 组织模型 78
7.1.6 支撑项目团队 80
7.2 案例研究 81
7.3 反模式 82
7.4 时机 83
7.5 工具 83
7.6 与其他规程的关系 84
7.7 本章小结 84
第8章 项目组合管理规程 86
8.1 工作流 87
8.1.1 当前系统目录清单 88
8.1.2 计划项目组合和规划 89
8.1.3 管理项目组合 91
8.1.4 管理规划 92
8.1.5 管理合同 93
8.1.6 管理企业风险 95
8.1.7 尽早识别风险 97
8.2 案例研究 98
8.3 反模式 98
8.4 时机 99
8.5 工具 99
8.6 与其他规程的关系 99
8.7 本章小结 100
第9章 企业架构规程 101
9.1 工作流 102
9.1.1 定义架构需求 102
9.1.2 定义候选架构 104
9.1.3 优化企业架构 107
9.1.4 定义参考架构 112
9.1.5 支持项目团队 114
9.2 反模式 115
9.3 时机 115
9.4 工具 115
9.5 与其他规程的关系 116
9.6 本章小结 116
第10章 战略重用规程 118
10.1 工作流程 121
10.1.1 计划重用方案 122
10.1.2 获取已有的资产 124
10.1.3 获得外部的资产 126
10.1.4 开发资产 128
10.1.5 改进资产 129
10.1.6 资产发布 130
10.1.7 资产退役 131
10.1.8 对项目团队提供支持 131
10.1.9 评测重用方案 132
10.2 案例研究 134
10.2.1 建立在质量基础之上的数量 134
10.2.2 通过服务域进行架构重用 134
10.2.3 成功的案例 134
10.3 时机 135
10.4 反模式 135
10.5 工具 136
10.6 与其他规程之间的关系 137
10.7 本章小结 137
第11章 人员管理规程 139
11.1 工作流程 139
11.1.1 制定人员需求计划 139
11.1.2 人员安置多样化 141
11.1.3 管理员工 141
11.1.4 指导职业生涯 143
11.1.5 制定接班人计划 145
11.2 案例研究 146
11.3 工具 147
11.4 反模式 147
11.5 时机 147
11.6 与其他规程的关系 148
11.7 本章小结 148
第12章 企业资产管理规程 149
12.1 工作流程 150
12.1.1 管理企业物理资产 150
12.1.2 管理企业信息资产 152
12.1.3 管理企业安全 157
12.1.4 支持项目团队 160
12.2 案例研究 161
12.2.1 数据管理 162
12.2.2 安全 162
12.3 反模式 162
12.4 时机 163
12.5 工具 163
12.6 与其他规程的关系 163
12.7 本章小结 164
第13章 软件过程改进规程 165
13.1 工作流 165
13.1.1 评估过程改进的需求 166
13.1.2 创建过程 169
13.1.3 裁剪过程 171
13.1.4 部署过程 172
13.1.5 支撑项目团队 175
13.2 案例研究 176
13.2.1 “大爆炸式”的软件过程改进
方法 176
13.2.2 增量式软件过程改进方法 176
13.2.3 发布合作指南并提供支持 177
13.2.4 公司管治 177
13.3 反模式 178
13.4 时机 179
13.5 工具 179
13.6 与其他规程的关系 180
13.7 本章小结 180
第四部分 综 合
第14章 引进企业统一过程 181
14.1 软件过程改进的实施 181
14.1.1 增量式推进 182
14.1.2 引进企业统一过程项目的先启
阶段 183
14.1.3 引进企业统一过程项目的精化
阶段 184
14.1.4 引进企业统一过程项目的构建
阶段 185
14.1.5 引进企业统一过程项目的移交
阶段 187
14.1.6 引进企业统一过程项目的产品化
阶段 188
14.1.7 引进企业统一过程项目的退役
阶段 188
14.2 培训 188
14.3 教练 189
14.4 度量进步 190
14.5 是否成功 191
14.6 本章小结 191
第15章 临别的思考 193
附 录
附录A 角色 197
附录B 工件集 199
附录C 术语表 203
附录D 缩略词 214
