介绍

系统工程的工序将重点放在一种优雅的领域上，即如何从时间与空间的角度，使项目变化性和复杂性完美地相互作用。正是在这个舞台上，成员与团队的关键因素，方法，过程和工具以及所应用技术成为理想与现实之间的桥梁。在每一道成熟的核心工序中，从艺术到科学再到工程学，正是这种通用的语言和通用的步骤，使得那些实施者间的协作和工序的不断进化成为了一种可能。这种进化的核心是对知识的获取、沟通，共享和有效利用。通用语言建立了想法与行为的边界，它定义了概念；方法和过程则建立这种边界范围内的行为，它们应用这些概念；工具建立这种边界范围内的行为的自动化。显然，如果我们不能够理解它，我们就无法正确的使用它和交流它，更不能使其自动化。在信息系统和技术产业中，统一过程（UP），Rational统一过程（RUP）,统一建模语言(UML)以及软件过程工程元模型（SPEM）是这种进化的核心。

统一过程（UP）与Rational统一过程（RUP）

统一过程（UP）是由用例驱动（Use-case-driven）、以架构为中心的、迭代增量的开发过程框架，它使用对象管理组织（OMG）的UML 并与对象管理组织（OMG）的软件过程工程原模型（SPEM）兼容。统一过程（UP）广泛使用于各种软件系统，无论是小型项目，还是包含各种管理的级别、复杂技术或是跨越应用领域、跨组织文化的大型项目。

1995年Rational 软件公司并购Objectory AB公司，统一过程（UP）是由Objectory AB'公司的Objectory过程和Rational 软件公司的Rational Approach 合并而成。其中Rational Approach是Rational 软件公司通过对各种客户经验进行开发所得到的结果，而Objectory过程则主要来自Ivar Jacobson在瑞典爱立信（Ericsson）的工作经验。

在《统一软件开发过程》（"The Unified Software Development Process"）（ 由Grady Booch, James Rumbaugh 和 Ivar Jacobson共同编写，Addison-Wesley出版社1999出版）一书中详细讲述了统一过程（UP）。Rational统一过程（RUP）是由Rational软件公司开发并投向市场的一种过程产品，它为项目的执行提供了必需的细节：包括指南、模板以及辅助工具；事实上，Rational统一过程（RUP）是为统一过程（UP）架构提供细节实现的商业化过程产品。

在一个应用统一过程（UP）或Rational统一过程（RUP）的项目中，开发案例（Development Case）、过程框架实例将决定哪些应用统一过程（UP）或Rational统一过程（RUP）的元素应被自始至终地使用。基于Rational统一过程（RUP）的开发案例是Rational统一过程（RUP）（和统一过程（UP））的实例，它通过对Rational统一过程（RUP）内容的剪裁（或是拓展）和配置以确定统一过程（UP）框架的广度和深度。而基于统一过程（UP）的开发案例是统一过程（UP）的实例，它确定统一过程（UP）框架的广度和深度。

统一建模语言（UML）与软件过程元模型

统一建模语言（UML）是一种通用的，有工具支持和广泛兼容特性的工业标准化模型语言，或是提供细化、可视化、构造以及生成过程中系统级文档制品的模型技术集合。它广泛的应用于各种类型的系统（软件或非软件），领域（业务与软件），方法和过程。统一建模语言（UML）使这种由用例驱动（Use-case-driven）、以架构为中心的、迭代增量的开发过程的应用成为了可能（但不是必须）。

上世纪九十年代,Rational软件公司和三人组(Grady Booch, James Rumbaugh, and Ivar Jacobson)发起了对信息系统和技术工业的集成,统一建模语言（UML）就诞生于这次集成过程中。此后统一建模语言（UML）通过统一建模语言合作者联盟（UML Partners Consortium）得到了很多组织的工业支持,并于1997年11月被对象管理组织（OMG）采纳，成为标准。

正像统一建模语言（UML）成为系统交流的工业标准模型语言一样,软件过程元模型(SPEM)也成为了过程、过程框架（相关过程集合）之间交流的工业标准模型语言，但软件过程元模型(SPEM)并未描述过程的制定（项目中过程的计划和执行）。软件过程元模型(SPEM)在统一建模语言（UML）的影响下应运而生，它也得到了很多组织的工业支持并且于2001年11月成为对象管理组织（OMG）的标准。

系统开发，系统，模型，视图

系统开发生命周期包括宏观层次上的问题处理过程和微观层次上的科学方法。而问题的解决则包括：对问题的描述、说明以了解问题定义需求；对问题的进一步描述以衍生或细化出对于解决方案的描述，从而解决问题；对解决方案的描述与解决方案集合之间的映射以准确实现和构造系统从而满足需求。在解决问题的每一个步骤中，科学的方法包括：对假设的计划或预计，对假设的执行或经验性测试，依据结果对假设进行的评估。衍生出用来校正假设的结论。无论出自有意或是无意，这些宏观和微观层次的过程在系统的开发中得到了非常普遍的应用。

统一建模语言（UML）使解决问题过程成为可能，它简化了对问题和解决方案的理解、细化、可视化和文档化等工作，同时也有助于问题的获取、交流以及有效利用策略上和操作上的相关知识来解决当前问题。统一建模语言（UML）实现了问题的获取，问题的交流以及对相关系统使用模型、架构视图和图表的有效运用。

系统是由元素或单元有目的地组成的。系统架构需要两个与其相关的尺度：结构尺度和行为尺度。结构（或静态）尺度涉及到哪些组成系统的元素以及它们之间的关系。行为（或动态）尺度涉及到那些组成系统的元素之间为达到系统目标而进行的交互和协作，以及它们的功能与行为。

模型通过对那些为解决问题而获取知识（语义）的系统进行完整抽象得来。架构视图则是对那些负责组织和协调知识与富含经验的用法指南之间关系的模型进行抽象而得来的。图表是那些用来描述问题和解决方案的相关知识（句法）以达到交流目的的模型元素的图形投影。运用统一建模语言（UML）基本元素中的符号来描述概念,而用符号之间的连线来描述概念之间的关系。

方法和过程框架

软件是整个过程的项目业务的集合。项目的目标是提供解决方案。方法为如何管理项目给出了指导和建议。方法对问题和解决方案的所需的知识给出指导和建议。方法说明这些知识如何使用以解决问题。过程是方法在项目中的具体执行， 方法学是一组相关方法的理论，分类和有组织的集合，这些相关方法用来确定由谁在那些产品上进行什么样的活动，包括针对于不同类型的项目，上述活动应该在何时、如何、为什么以及在哪里进行。其中进行活动的人（谁），进行的活动（怎么样），生成的产品（什么）以及对他们的启发都是过程的元素。方法学将各种方法组织成一个集合，方法描述过程，过程在项目中执行方法。

由于运用单独的方法不足以解决不断变化的问题，而使用整套方法又不切合实际，需要为整套方法提供更多的变通性和可测量性。运用整套方法的一部分叫做过程框架，被应用在一个特定工程的实际的方法子集被称作过程实例。过程框架指定或建议了由谁在那些产品上进行什么样的活动，包括针对于不同类型的项目，上述活动应该在何时、如何、为什么以及在哪里进行。而过程实例则就某个特定工程回答了上述的问题。过程框架中的过程实例被描述为一组可变性可测量性更强的一组相关过程集合，而过程实例则执行过程框架的一个子集。因此统一过程（UP）是过程框架，开发案例是过程实例。

统一过程（UP）

为了顺利而高效地应用统一过程。我们必须理解协作、环境和交互等概念。在统一过程中协作主要关注项目中的元素，环境主要关注项目的过程架构，交互主要关注项目的执行。图1中显示了统一过程中的各种元素。

图1 UP的元素

协作

协作是环境中的交互。它获取了由谁在哪些产品上做什么样的工作。因此协作建立了项目中的元素。

角色是指进行项目活动和生成工件的个体或小组。活动是指由角色执行的工作单元或步骤。工件是角色职责以及由活动产生或消耗的信息元素。统一过程（UP）定义了多种角色、工件和活动。

环境

环境强调了协作的静态或结构表现，互相协作的元素和它们之间的空间聚集关系。通过环境可以得到何时何处进行那些产生和使用活动的工作。因此它为整个项目建立了一个环境。图2显示了统一过程（UP）的内容。

图2 UP建立的上下文

项目需要一个管理项目进展的管理透视图和一个执行并完成技术工作的技术透视图。项目的生命周期由许多满足规则的迭代阶段所组成。开发周期是由许多连续的阶段组成，这些连续阶段的最终结果就是主系统发布或称作系统生成。例如，系统的生成可能包括1.1,2.0,3.0和后续版本。阶段是一个主要里程碑，它是一个业务风险管理的决定因素。阶段包括那些宏观问题的解决过程；迭代作为辅助里程碑，作为技术风险管理的决定因素。迭代的结果是一个非最终版本系统的发布，叫做系统增量。例如系统增量可能包括1.1,1.2,2.5和后续版本。迭代包括了对科学方法的程序微观级别的描述。工序(discipline)是描述工作流和经常一起完成的详细活动（以及相关的角色和工件）集合的主题域。

统一过程定义了下列四个过程：

（1）先启阶段，以生命周期目标作为结束里程碑，建立项目的范围和版本；确定业务实现的可能性和项目目标的稳定性。

（2）精化阶段，以架构作为结束里程碑，建立系统的需求和架构；即确定技术实现的可行性和系统架构的稳定性。

（3）构建阶段,以最初操作性能作为结束里程碑，完成系统的构造和建立。

（4）产品化阶段，以产品发布作为结束里程碑，完成系统向用户群的产品化和部署。

统一过程（UP）定义了下列三个支持工序（discipline）：

（1）配置变更管理工序，用来管理系统和需求变更的配置。

（2）项目管理工序，用来管理项目。

（3）环境配置工序，用来配置项目的环境，包括所涉及到的过程和工具。

统一过程定义了下列六个核心工序：

（1）业务模型工序，通过业务模型获取相关知识以理解需要系统自动完成的业务。

（2）需求工序，通过用例模型获取相关知识以理解自动完成业务的系统需求。

（3）分析设计工序，通过分析/设计模型以分析需求，设计系统结构。

（4）实现工序，基于实现模型实现系统。

（5）测试工序，通过测试模型进行针对需求的系统测试。

（6）部署工序，通过部署模型部署系统。

各个阶段、迭代和工序的目的在于定位业务和技术上的风险。在先启阶段过程中，业务模型和需求工序将完成大部分工作。在精化阶段大部分的工作是在需求、分析设计和实现工序中完成。而构造阶段的主要任务则涉及到分析设计、实现和测试工序。在移交阶段则是测试和部署工序为主。支持工序贯穿作用于四个阶段。为了实现生成系统这一总体目标，所有的核心工序必须能够在不引入任何风险的前提下得到及时的使用；这就意味着，开发人员必须负责在需要使用这些工序的时候决定使用哪些核心工序。

交互

交互强调了协作的行为，动态表现，相互协作的元素以及它们之间的协作或暂时交流。交互获取了何时、为什么进行这些活动，产生和使用活动的工作。因此它在各种因素的支配下建立项目的执行。

正如辅助里程碑作用于主要里程碑范围之内一样，技术决定因素也作用于管理决定因素的范围之内，从而使技术性的策略和操作适应业务策略和基本目标，在业务与技术之间建立一座桥梁。

迭代可能是一小步，开发过程的一段或是通往目的地的路线。迭代是被计划而不是固定的，它有评估标准，其进展也是可以论证的。迭代过程涉及到重复的工作，在每一次重复中都包含一定增量，在迭代的过程中很多工作都是并行的。

用例是基本的需求。例如，登陆和退出系统，输入数据，处理数据，生成报告等功能。由于统一过程是用例驱动的，用例驱动迭代过程。也就是说，迭代过程将被设计、评估以解决那些大量的功能需求（或其中的一部分）从而与用户达成一致，使项目的所有活动和工件都可以回溯到需求中去。业务因素的统计是通过对那些以功能性需求为目的的迭代过程的计划和评估而得到。非功能性需求（可用性、可靠性、性能以及其他特性）在用例所涉及到工序中逐步递增地考虑。

系统拥有一个架构。例如，系统的架构包括各个元素的集合以及元素之间的协作和相互作用，还应该包括各种子系统以解决安全、输入、输出、数据存储、外部通信、报告等问题。由于统一过程（UP）是以架构为中心的，迭代过程的重点在于架构和系统的不断进化。也就是说迭代的目标主要在于解决大量问题所带来的困惑，从而控制系统的复杂性和完整性。系统技术因素的统计是通过对实际系统的改进或是产品的生成而得到的。

风险是项目成功的阻碍，包括人、业务、技术上的问题。例如，来自人的风险主要是由于人员不足，缺乏培训，缺乏经验等；业务风险主要来自资金不足、时间和来自业务交流中的某种承诺等。技术风险主要是对需求和技术了解得不够充分，或使用了尚未成熟的技术等原因所造成的。统一过程可以规避这些风险，迭代过程规避风险并且根据前期的迭代得到的风险反馈决定开发进度，发现其他未知的风险。也就是说，迭代过程规避那些来自于用例和架构的风险，以确保项目成功。

迭代是一种时间范围，在一系列协作被计划、执行和假设过程中可以调节迭代的时间范围，以达到不断的进展。迭代的开始和结束需要用户，项目管理者以及将影响项目进展或受到其影响的技术人员之间进行协商。应选择风险级别最高的用例驱动迭代过程。用例可能在跨越几个迭代周期并不断完善，也有可能在一个迭代周期内使用多种工序。迭代过程将产生系统的一个或多个过渡版本。它也将产生内部的基线和系统外部的评估。由迭代过程得到的反馈和知识积累将为下一个迭代过程做准备。在迭代的过程中评估指标也是不断迭代变化的，通过反复的迭代过程逐渐建立系统全面的评估指标。迭代过程持续时间的长短应与其相关风险的级别高低成反比。在迭代过程的执行中，迭代过程之间应尽量避免交叉。开发周期和各个阶段也可以制定具体的时间范围。然而，对于开发周期、阶段和迭代过程的计划而言，计划越提前，准确性越差。

迭代过程使用与“纯瀑布开发过程”相同的核心开发工序。瀑布开发过程的原则是，在开始下一个开发工序之前应完成当前开发工序的所有活动和工件。而迭代过程包括迭代协作，不断增量优化的目的，以及在整个项目生命周期内不同详细级别的工件。瀑布开发过程并不为系统的局部开发或向项目生命周期中引入的变化提供明确的时间，事实上瀑布开发过程阻碍了这种变化；而迭代过程则在当前迭代的结束之后，下一个迭代过程开始之前提供了局部开发的时间，从而预见系统的变化并做出相应反应。瀑布开发过程是通过一系列连续的开发工序不断进化的，而迭代过程可以在不同的开发阶段间不断前向或后向进化，以及时调整重点，运用各种不同的开发工序，及时发现项目开发的风险。

迭代

为了顺利而高效的应用统一过程，我们需要理解迭代过程以及如何线性连续地使用迭代过程。

迭代过程包括迭代过程的计划、执行和评估。确定用例和风险的优先级，其中用例的级别是根据可以减小风险的多少来定义的。在迭代过程的计划上，应选择那些可以规避最高等级风险并可以在当前给定的有限条件下（资金、时间、资源等）进行的用例来驱动迭代过程。在迭代过程的执行上，用例通过每一个核心开发工序不断完善的同时，系统和系统的体系也得到不断的完善。当然，用例无需在一个单独的迭代过程中的每一个开发工序上都得到完善。迭代过程的评估，是通过实际的结果与预计的目标相比较而得到的，同时对项目的计划和风险进行调整和更新。项目的最终目标是完成系统，因此所有的核心开发工序应该在不引入新的风险的前提下准确及时地得到应用。也就是说，开发者应该负责在恰当的时候使用恰当的核心开发工序。

线性步骤

无论是在将重点放在业务建模的第一组迭代过程中，还是在将重点放在需求开发的第二组迭代过程中，以及其它同样在核心开发工序之间进行的迭代过程中，开发组都应该坚持在学习解决方案之前更多的理解问题本身，并将其作为整个项目中各个阶段的都需要做的工作。尽管对于整个系统而言，这些工作的成果可能只是在开发周期结束时才能显现出来。作为线性过程，这一点已经被大家所熟知。图3所示为这种必需的工作在线性开发过程中使用的模式。

图3 线性步骤

线性迭代将主要的重点放在开发阶段的宏观层次方面，在这些阶段中各个开发工序被更加分散地跨阶段分布。因此，那些存在于业务与技术之间的平衡将被团队的管理者打破。这些工作常常因为团队的管理者认识到某些必须被立即处理的业务风险，而影响迭代过程多个开发工序中所有的用例。

线性迭代在发现某个与业务相关风险或用例相关风险的时候，将尽量推迟对这些风险的解决或尽量规避它们。同时，这种线性迭代过程也将推迟那些对系统及其架构必要的验证，排除项目开发周期中的机会主义配置。从本质上说，它是一个将各种开发工序分布在各个迭代中的“纯瀑布”开发过程。

连续步骤

用例在一个单独的迭代过程的各个核心开发工序中不断进化，开发组都应该坚持在学习解决方案之前更多的理解问题本身，并将其作为整个项目中各个阶段的都需要做的工作。尽管对于整个系统而言，这种工作仅仅是确定了一部分需求，这些需求也许不能在整个项目开发周期内使用或发布，而只能在整个开发周期结束阶段才能表现出来。图4所示为这种必需的工作在连续开发过程中使用的模式。

图4 连续步骤

连续迭代将主要的重点放在开发阶段的微观层次方面，在这些阶段中各个开发工序在阶段间更加分散地分布。因此，那些存在于业务与技术之间的平衡就将被团队的技术成员打破。这种工作常常因为团队的技术成员认识到某些必须被立即确定的技术风险，而影响迭代过程所有开发工序中所有的用例。

连续迭代倾向于在发现某个与技术相关风险或架构相关风险的时候，将尽量推迟对这些风险的解决或规避这些风险。同时，这种连续迭代也可能增加系统集成和验证的难度，推迟架构演习达到充足的范围。从本质上讲，架构范围的过小很可能导致那种用例使前期迭代过程中衍生的架构失效的情况出现。

迭代步骤

迭代步骤是对以问题为重点的线性步骤和以解决方案为重点的连续步骤的混合应用。图5所示为这种必需工作在迭代步骤中使用的模式，其中四边形代表着那些需要根据具体项目进行调整的并行部分。将四边形中各个边都变成对角线，就是各个工序跨迭代阶段的“纯瀑布”步骤。

图5 迭代步骤

迭代步骤的重点是在项目整个生命周期中逐步精化所涉及到的知识。在先启阶段，线性步骤重点是项目的范围，连续步骤重点是架构定义的证明。在细化阶段，线性步骤确定架构的范围，连续步骤确定架构的风险。在构造阶段，连续步骤提供更多的开发机会。在产品化阶段，线性步骤和连续步骤的重点是系统的完成和项目的终止。

总的来说，这种工作的进行在项目的开始阶段将比较困难，之后则逐渐实现并行应用所有核心开发工序，恰当运用所有辅助的核心开发工序，在开发周期的结束阶段则比较简单。在迭代的执行中， 在那些有着生成和消耗的关系活动中角色、活动以及工件的协作 一旦生成活动足够成熟后及时地进行更迭 。在迭代的执行中，其内容将包括生成和消耗的关系活动中角色、活动以及工件之间的协作，同时，将满足产生消费关系的活动联系起来，并及时地迭代以使得消费活动可以生成活动中的输入变得足够成熟后及时开始。

高效成功地运用统一过程

为了高效成功地使用统一过程，我们需要理解很多过程框架的应用指南（通过培训）。

发生在给定角色、活动、工件间的协作，其主要动力来自于项目经理、架构师和过程工程师等角色。其余的角色并不是次要的，而是辅助上述这些角色。项目经理负责整个项目；架构师负责系统架构；过程工程师负责统一过程的运用和开发案例。项目中各种角色的交流与协作是高效成功运用统一过程的关键因素。这些协作包括架构师所定义的系统架构，过程工程师所建议角色，活动以及提交系统所需的工件，项目经理为上述工件进行活动提供所需资源。这些架构、角色、活动、工件以及资源之间的交互包括也将包括其他相关知识的高效成功地运用。这些角色重点是平衡一个步骤范围内的多种相关因素的同时，弥合目标和实际版本之间的差异。也就是说，这些协作必须有重点地，平衡地，迭代地运用以获得成功。另一方面，项目经理过于教条死板会导致过分的线性迭代；系统架构师过于教条死板会导致过分的连续迭代；过程工程师过于教条死板会导致混乱的状态。上述角色的问题最终将导致迭代步骤的优势无法体现。一般来说，在那些包括项目经理，过程工程师等角色的项目中往往会曲解这些主要的动态性能，（由于每一个角色都有明确的压力，目标）导致这些角色的直接利益冲突；以至于增加了项目失败的潜在威胁。

图6 UP的动态特性

本文讲述了焦点、平衡和迭代过程的知识，那些关于特定角色、活动以及工件的应用指南（通过培训）超出了本文的范围。

焦点

在应用统一过程的项目中，我们应关注并遵循下列指导步骤：

（1）鉴于统一过程中所有内容都是可选的，应根据不同的因素及其可能的分支做出相应的决定。一个经常要问的问题是：“为什么？”——没有必要执行统一过程中所有的内容，而只需要进行那些需要进行的。一个过程工程师将解释为什么角色、活动和工件这样被利用。另一个经常要问的问题是“如果这样，那么会怎么样？”也就是说，确定我们应该做什么。过程工程师将解释如果一个角色、活动以及工件被利用会有什么可能。还有一个问题经常要问：“接下来做什么？”在给定“如果这样，那么会怎样”的条件下“接下来做什么？”。过程工程师将解释接下来什么样的角色、活动以及工件应该被应用。如果无法回答这些问题，则表明其对特定项目了解得不够充分。

（2）聚焦于项目环境（context），然后是基本内容，并迭代地，增量地尽力弥合项目环境（context）与内容之间的差距。不具备对某个项目的环境（context）相关知识或是不具备统一过程的基本知识，而使用统一过程，都将增大项目失败的可能性。过程工程师需要能够弥合项目与统一过程之间的差距；也就是说能够将统一过程的基本元素运用到特定项目的环境（context）中去，其中关于统一过程的基本元素，本文已经着重强调了。

（3）聚焦于“统一过程的精髓”而不是统一过程的形式。统一过程既不松散混乱，也不死板迟钝，而是具有很强的灵活性，动态性。统一过程仅仅是说明或建议开发人员应该如何决定和执行。如果无法平衡其中的关系，则表明过分的关注“统一过程的形式”，而不是“精髓”。这一点是很多过程工程师运用统一过程的通病，也就是说，他们无法平衡“形式”与“精髓”。

（4）对项目经理，系统架构师以及过程工程师充分地授权以弥合交流中目标与项目实际版本之间的差距。在授权的同时，确定上述角色与整个团队中其他角色之间相互影响的因素，从而提高项目成功的可能性。项目经理应该是一个领导者，而不是简单的项目管理者，或是教条死板的执行者。系统架构师应该是一个领导者，而不是简单的理论家或是技术人员，既不过分教条也不过分关注细节。过程工程师应使过程的应用成为可能并且应用顺利，而不是强迫过程的实施。团队应该可以迎接挑战，把握机会而不是停滞不前。每一个工序都应该有一个角色来领导工序内全部的工作，得到并维护工序相关模型（宏观图），同时每个工序也都有其他的角色来获得并维护模型的细节（微观图）。

虽然有很多指南的应用明确针对于过程工程师，但是这些指南也可以应用于其他角色。除此之外，其他的指南也可以作为上述指南的一种补充。

平衡

在应用统一过程的项目中，我们应遵循下列指导步骤进行项目平衡：

（1）不断寻找平衡；这一点毋庸置疑，过程工程师必须考虑角色、活动和工件的必要性、充分性和一致性，确定风险以保证项目成功。对必要性的判断主要是考虑其是否是项目不可或缺的；对充分性判断主要是考虑其是否满足给定的目标；对一致性判断主要是考虑其是否与其它事务前后矛盾，相互冲突。其中，一致性可以使用指南进行判断。对统一过程基本元素重视程度的不足和对过程框架中各个过程元素的认识的不足通常表现为对必要性、充分性和一致性的判断错误。过程工程师应该提供建议，从而尽可能地考虑到项目潜在的风险，以确保项目中没有任何事情被忽略而导致无法实现目标，并给出相应论证。

（2）对于角色而言，在项目中，使用全部角色，或不使用任何角色；给团队中每一个成员都分配角色，或不分配任何角色的情况都很少见。应根据每个角色的意义做出决定。

（3）对于活动而言，在项目中，进行全部活动，或不进行任何角色；团队面面俱到的进行全部活动，或仅仅进行那些最必要的活动的情况都很少见。应根据每个活动的意义而做出决定。

（4）对于工件而言，在项目中，生成全部工件，或不生成任何工件；团队面面俱到的生成全部工件，或仅仅生成那些最必要的工件的情况都很少见。应根据每个工件的意义而做出决定。

（5）对于重复而言，在项目中，保持进行固定数量的重复，或不进行任何重复和改变；对于变化本身而言，没有原因而产生变化，或每一个原因都产生一个变化的情况都很少见。应根据每个重复的意义而做出决定。

（6）不要相信一个可以在没有任何前提条件下证明一切的过程工程师。这种情况下，对于上述元素意义方面的问题，他们经常回答：“嗯，这个……！”。不要相信无法证明任何事情的过程工程师。这种情况下，对于上述的“原始问题”，他们经常回答：“相信我……！”。

（7）不要相信那些只注重统一过程的形式而不是精髓的“纯理论家”。从实用的角度来说，这些“纯理论家”迟早都会为项目的成功结束而做出某些折衷和平衡，因为没有折衷和平衡，意味着项目存在重大的风险。对于大多数过程工程师而言，无法正确地折衷和平衡是他们的通病。

虽然有很多指南的应用明确地针对于过程工程师，但是这些指南也可以应用于其他角色。除此之外，其他的指南也可以作为上述指南的一种补充。

迭代

在应用统一过程的项目中，我们应遵循下列指南进行迭代开发：

（1）开发阶段以迭代为主。脱离特定阶段的环境而进行的迭代活动将失去灵活动态的特性，或松散混乱，或迟钝死板。不考虑或是过分考虑环境（context）的迭代都将阻碍统一过程优势的发挥。在对某个项目的迭代进行计划，执行，评估的过程中，应充分考虑迭代的阶段，确定这些阶段的具体目标以及如何在特定环境中达到这些目标。

（2）迭代的开始和结束应该取决于时间范围而不是涉众。在迭代中，涉众是否积极参与将直接影响涉众在整个项目中所起的作用。

（3）突出重点且兼顾平衡是项目迭代成功的关键。没有明确的目标，客户将无法分出轻重缓急，无法正确地交流，更不可能互相达成一致。当然，客户上述能力的积累是具有顺序性的，没有明确的目标，用户就不可能确定问题的优先级；不确定优先级，也就无法和其他用户进行建设性的交流；没有交流便无法协商讨论，也就没办法达成一致。因此，要确保客户具有这样的能力。

（4）不要无谓地去掉迭代过程！也就是说不要过早终止一次迭代，因为这将影响到迭代附属物的产生和用户对项目真实状态的了解。除非是由于灾难性的突变而终止那些既耗费资源而又没有任何成果的迭代过程。例如：如果当前正在进行的迭代可以被证明对于项目需求或是技术假设是不可能的，那么就应该终止它。

（5）不要无谓地修改迭代过程！也就是说不要为增加用例而修改迭代过程的作用范围，因为这将影响到迭代附属物的产生和用户对项目真实状态的了解。除非是由于那些未预料和计划的需求的增加——如果不增加这些需求会导致灾难性的后果——，而必须对当前迭代过程进行修改。——虽然更好的做法是将新增加的需求加入到后期的迭代过程中。例如：如果不增加这些未得到预见的需求，将会导致项目资金的减少，那么应该修改当前的迭代过程。

（6）不要无谓地延长迭代过程！也就是说不要为适应某个用例而推迟迭代过程的结束，因为这将影响到迭代附属物的产生和用户对项目真实状态的了解。除非是由于那些需求的确定——如果不增加这些需求会导致灾难性后果——，而必须对当前的迭代过程进行延长。——虽然更好的做法是将这些需求加入到后期的迭代过程中。例如：如果不确定这些在当前迭代过程中未确定的需求，将会导致项目资金的减少，那么应该延长当前的迭代过程。

（7）不要“拖延”（或者允许整个团队的拖延）而要不断取得进展。也就是说迭代过程将使整个团队具有成就感。

（8）在整个生命周期的各个迭代过程之间敏捷地（具有易适应性和对团队，个人，过程以及工具发展的前瞻性）进行计划，执行和评估。也就是说，运用给定的资源（团队，个人，过程以及工具）以达到局部目标，并尽可能多地取得整体上的优势。变压力为动力，突出重点，兼顾平衡，反复迭代地缩小和弥合现实与理想之间的差距，就一定会获得成功。

此外，其他的指导步骤也可以与上述步骤一起使用。

结论

显而易见的，人是项目获得成功的"最根本要素"。不要把统一过程教条化，也不要强制执行它，而是应该依赖人来运用统一过程！应把重点放在团队上而不是某个特定项目上，因为正是团队本身运用他们的过程并最终获得成功。同样地，统一过程（UP）应该被科学地定义，被艺术地运用。

统一过程（UP）是由用例驱动的、以架构为中心的、迭代增量的开发过程框架，它使用对象管理组织（OMG）的统一建模语言（UML）并与对象管理组织（OMG）的软件过程工程原模型（SPEM）兼容。通过正确地理解统一过程（UP），掌握各种指导步骤（通过培训）从而获得成功与高效，使得统一过程（UP）受到广泛赞誉！与此同时，也正是通过对统一过程及其各种元素的不断探索，运用和积累，使统一过程（UP）实现了其自身的价值。