本文档将概要介绍什么是OpenUP，它的目标和生命周期。在了解这些基本信息之后，你可以阅读“如何在团队中推广OpenUP”了解采用什么方式进行学习和使用。本文牵涉的一些具体的例子以企业应用架构涉及业务为主。

面向小型团队      OpenUP是面向小型团队的，这种小型团队可以在一起工作，并且开展广泛的沟通和交流。团队成员包括干系人、开发工程师、架构师、项目经理和测试工作成。他们一起作出决策，并且决定开展哪些工作，同时决定如何更好地解决干系人的需求。
      注意，在这个团队中，业务干系人应该作为团队的成员，而不是独立于团队之外，因为这对于项目成功很关键。至少应该有业务的接口人作为业务方的代表，如果无法实现相同的地理场所办公，那么必须建立定期的沟通机制，比如每周一到两次例会。项目团队内部一般通过“每日立会”，通过每天简短而明确的交流沟通项目的进度、风险和目标。
       当然，在你了解了OpenUP的内容后可以进行相应的扩展，以面向更加复杂的业务和大型的开发团队，你可以直接了解UP的其他版本，例如EUP、RUP。

风险驱动开发     一开始就识别风险，并且把记录一份风险列表。在开发的整个生命周期就是不断消除风险交付价值的过程。如果你开发的项目是开发团队没有接触过的领域，那么对于业务的熟悉程度就是最大的风险，我们应该排定相关的业务培训计划，或者相应的业务熟悉计划；如果你开发的是一个面向生产过程的条码系统，那么和打印机的打印联调应该成为一个风险，不至于开发出完整的业务流程确发现无法打印。当然，具体什么是风险，取决于团队当前的业务和技术水平。

用例驱动开发     OpenUP采用用例的方式描述需求，编写良好的用例是团队必备的技巧。用例是结构化的组织需求的方法，干系人负责评估和检查用例的正确性。

架构驱动开发     架构相关的需求需要尽早识别出来并且在精化阶段稳定下来，尽管后续会可能发生变更，但风险会大大减小。同时架构也能让团队成员之间围绕着一致的核心开发模型开展工作，这对于有效的沟通很重要。

迭代演进     每个迭代过程可以多次执行测试，具体的频率可以根据团队的人力投入有效性而定。良好的测试可以保证每个迭代的构建版本的质量。例如，对于复杂的产品可以划分为多个版本进行迭代推进，每个版本可以划分为几个迭代进行，每个迭代建议不要超过两个星期，以获得短期及时的反馈。

其他      OpenUP不关注部署、配置管理和开发环境（例如流程定制和开发环境设置），不关注这些组织级别或者企业级别的处理的内容。当然，我们可以对OpenUP加入这些内容进行扩展。

四项核心原则     OpenUP 是一个迭代软件开发过程，具有最小化、完整性和可扩展性。整个流程基于以下四个核心原则进行组织管理。

  • 平衡，在竞争优先级以及最大化干系人利益之间，建立平衡 。
  • 协作，协作以协调利益，以及保证理解一致。
  • 关注，从开始起，就将注意力放在软件架构上，以减轻风险，并组织软件开发。
  • 演化，持续演进并且不断获得反馈

流程基本元素

    在OpenUP中人们以角色（Role）存在，通过角色执行任务(Task)，执行任务过程中使用了交付件(artifact)，并且输出交付件。OpenUP描述了最小化的一组角色，任务（以科目的方式组织）和交付件（通过工作产品领域组织）。

生命周期    OpenUP的迭代开发流程分布并且贯穿在几个阶段中：启始（Inception）、精化（Elaboration）、构建（Construction）和移交（Transition）阶段。每个阶段包含一道多个迭代，每个迭代开发和发布稳定的可工作的软件版本，每个迭代的完成都标志着达成了一些小的里程碑，同时，这些小里程碑的达成也有助于每个阶段主要里程碑的达成，即阶段目标的达成。各个阶段对应的阶段里程碑目标如下：

  • 启始阶段: 确保项目目标和范围已经明确。
  • 精化阶段：开发整体架构框架，确保架构已经稳定。
  • 构建阶段：从摸索到可部署产品的开发，转向功能模块的开发。
  • 移交阶段：确保软件被最终用户接受。