开发方法 · 统一过程UP：二维模型与四个里程碑

先给它上户口：统一过程，英文 Unified Process，缩写 UP，是由 Rational 公司开发的一种迭代的软件过程，是一个优秀的软件开发模型，提供了完整的开发过程解决方案，可以有效地降低软件开发过程的风险，经过裁剪的 UP 可以适应各种规模的团队和系统。这段介绍里有两个钩子后面要用——「降低风险」和「经过裁剪适应各种规模」。

对，UP 本身是一个二维的结构。横轴是时间主线，就是阶段：随着时间的流逝，软件开发活动总要经过初始、细化、构建和交付这 4 个阶段方能完成。纵轴是工作流程，描述在不同的阶段需要进行的主要工作。你可以想象一张网格图：从左往右是时间，从下往上是不同工种，每个格子表示这个时段这项工作干多少。

不行，因为这正是它和瀑布的本质区别。原文拿初始阶段举例：在初始阶段，软件组织需要进行大量的调研，对软件进行业务建模、需求，同时进行一些设计以验证建模的合理性，还要进行一些实施甚至测试和部署的工作，用以验证需求和设计的工作及开发系统原型；当然配置与变更管理、项目管理和环境是在任何阶段都不能缺少的。你听——同一个阶段里，建模、需求、设计、实施、测试、部署全都有份，只是量不同。瀑布里「需求阶段只做需求」那种泾渭分明，在 UP 里不存在。

总结得可以。原文说，从这个模型中可以看出 UP 迭代的特点：任何一个阶段的工作都不是绝对的，都是相互交叠配合的，但每一个阶段都有其侧重点。我们按阶段过一遍侧重点，这是填空题的素材。初始阶段：开发者刚刚接入系统，此时最重要的工作是界定系统范围，明确系统目的；在这一阶段，业务建模和需求工作成了重头戏。

细化阶段：开发者需要抽象出软件的逻辑模型，设计出软件的架构，在这一阶段，分析设计工作是最主要的工程活动。构建阶段：开发者需要基本完成系统的构建，使之成为一个完整的实体，并进行测试和部署，在这一阶段，实施和测试是最主要的活动。交付阶段——注意这个阶段也经常被称为转移阶段——软件系统需求已经完全成熟或产品化，或进入下一个版本，在这一阶段不可避免地要对软件系统进行重构、修改、测试和部署。

好眼力，这正是这道题的陷阱所在，我一会儿讲里程碑时专门说。先把四个阶段的侧重点配对连好：初始配界定范围、业务建模和需求；细化配抽象逻辑模型、设计架构、分析设计；构建配完成构建、测试部署、实施和测试；交付配重构修改测试部署。考试问「UP 的细化阶段最主要的活动是什么」，答分析设计——这个最常考。

原文还补了两层。第一层：在这 4 个阶段中，各有侧重点，但也不是像瀑布模型那样完全不允许其他活动的存在。初始阶段为了验证开发者的想法，就需要进行一部分的实施和测试；即使到了交付阶段，需求也可能会发生变化，仍然需要进行部分业务建模、需求和设计的活动。第二层：每个阶段中系统推进不是一蹴而就的——细化阶段可以划分为第 1 次细化和第 2 次细化，构建阶段也可以划分为 3 个小阶段，实际开发中可根据需要划分为更多的小阶段。

九个核心工作流，一口气数完：业务建模、需求、分析设计、实施、测试、部署、配置与变更管理、项目管理、环境。原文给了一个帮助记忆的分类：前六个——业务建模、需求、分析设计、实施、测试、部署——是工程活动；后三个——配置与变更管理、项目管理和环境——是管理活动。考「以下哪个不属于工程活动」时，就用这条线切。

问到点子上了，原文说在这 9 个工作流中，前 8 个可以说是绝大多数人都耳熟能详的东西，而「环境」工作流则相对难以理解。「环境」工作流很重要，也可以称之为「环境管理」，俗语说「巧妇难为无米之炊」，「环境」工作流就是为软件开发准备「米」的活动：在软件开发中，需要为各种工作准备相应的工作环境，工作环境中要包含必需的工具、活动的指南、活动的流程规范、工作产品的模板、基本的开发设施等。

原文的态度很坚决：在很多组织中，「环境」工作流没有得到应有的重视，或者完全被忽视，以为为开发者提供了工作台和计算机就万事大吉了，其实这种做法是错误的。每一个开发团体都有自己特定的活动准则和规范，这些准则和规范是团体协作的基础，万万少不得。没有合理的工具配备，没有充分的指南、规范和模板，软件开发的活动肯定是放羊式的管理，管理者除了一些「羊毛」外什么也收获不到。还有一个形态细节：观察 UP 模型就可以发现，在每一阶段的最开始，「环境」工作流都有一个小小的波峰——开发团队需要为开发环境进行相应的准备，并在后续活动中为开发环境提供支持。

来。先立框架：UP 的生命周期是与阶段一一对应的，在 UP 的生命周期中共有 4 个里程碑。第一个，目标里程碑，对应着先启阶段的结束，当开发者可以明确软件系统的目标和范围时即达到了该里程碑。

这就是我要你抓的坑。原文里这两个名字都出现了：讲二维模型时四阶段叫初始、细化、构建、交付；讲里程碑时把初始阶段又叫成了「先启阶段」。它们是同一个阶段的两个译名，考题两边都可能出现，你得知道初始等于先启。还有交付阶段，前面说了它也经常被称为转移阶段。四个阶段一共三个别名：初始等于先启，交付等于转移，细化和构建没有别名。

继续。第二个，架构里程碑，它是 UP 生命周期中的第二个里程碑，在这个里程碑前，开发者需要确定稳定的系统架构。注意「前」这个字——架构里程碑之前要干的事是确定稳定架构，也就是说这个里程碑收的是架构的尾。

第三个，能力里程碑：当系统已经足够的稳定和成熟并完成 Alpha 测试后，认为达到了第 3 个里程碑。Alpha 测试这四个字是它的独有标记。第四个，发布里程碑：在达到发布里程碑前，需要完成系统的测试、完成系统发布和用户培训等工作。经过这 4 个里程碑后，即为一个完整的生命周期，开发出一个新的版本；此时可以关闭该产品的开发，也可以迭代进入下一版本。

细化阶段结束。把四个配对连成一条链：目标里程碑对应初始阶段的结束，条件是明确目标和范围；架构里程碑对应细化阶段，之前要确定稳定架构；能力里程碑在构建阶段，条件是系统足够稳定成熟并完成 Alpha 测试；发布里程碑对应交付阶段结束，之前要完成系统测试、发布和用户培训。这道题的干扰项会把「架构」配给构建阶段——因为直觉上「构建」听起来才谈架构，但原文明确架构里程碑是细化阶段的收官。直觉和教材打架时，听教材。

网上吵没用，考试听原文，而且这道题考过：关于统一过程的特点，以下描述错误的是——错误项就是「UP 属于敏捷方法」。原文原话：虽然 UP 是一个迭代的开发模型，但 UP 本身并不属于敏捷方法；相反，一般认为，未经裁减的 UP 是一个重载过程。注意「未经裁减」四个字，它和开篇那句「经过裁剪的 UP 可以适应各种规模的团队和系统」是一对：不裁剪就是重载，裁剪了才能瘦身。

对，都是对的，所以选「属于敏捷方法」这个错项。把 UP 的特点清单完整过一遍，原文列了五条：第一，UP 是一个迭代的二维开发模型，在生命周期的每一阶段都可以进行需求、设计等活动，UP 不但给出了迭代的生命周期，还给出了生命周期每一阶段的迭代指南；第二，采用不同迭代方式的 UP 可以演变为演化模型或增量模型——这条很妙，UP 居然是演化、增量这一族的上游；第三，UP 的迭代特点使得更容易控制软件开发的风险；第四，UP 本身并不属于敏捷方法，未经裁减的 UP 是一个重载过程；第五，在实际应用中可以根据具体问题对 UP 进行裁减，从而使其可以适应各种规模的软件和开发团队。

会。比如「关于 UP 的描述错误的是」里放一句「UP 只能在初始阶段进行需求分析」——错，每一阶段都可以进行需求、设计等活动；再放一句「UP 无法适用于小团队」——错，裁减后适应各种规模。你只要把「二维、迭代、每阶段都有九流的活动、可裁减、不敏捷、重载」六个标签焊死在 UP 身上，这类题就翻不了车。

来自架构设计师在 UP 中的角色。原文说，架构设计师在 UP 活动中承担着非常重要的角色，除了需要建立系统架构模型外，还需要：第一，同需求人员和项目管理人员密切协作；第二，细化软件架构；第三，保持整个架构的概念完整性——具体地说，架构设计师不但需要设计系统架构，还需要定义设计方法、设计指南、编码指南、评审设计等工作。因此，有人也称 UP 是一个以架构为中心的开发模型。给架构师考生的彩蛋：你在这套流程里不只是画图的人，还要定方法、定指南、做评审、护住概念完整性。

本集必背清单：UP 是 Rational 公司开发的迭代过程，二维结构，横轴四阶段初始、细化、构建、交付——初始又称先启、交付又称转移；纵轴九个核心工作流，前六是工程活动、后三配置与变更管理、项目管理、环境是管理活动；「环境」工作流为开发准备工具、指南、流程规范、模板、设施，每阶段开头有个小波峰；四阶段侧重点——初始界定范围、细化设计架构、构建完成构建和测试部署、交付重构修改测试部署；四个里程碑——目标对应初始阶段结束、架构对应细化阶段之前确定稳定架构、能力对应构建阶段完成 Alpha 测试、发布对应交付阶段结束。

对，敏捷方法。先是 2001 年那份 17 个人签的宣言，然后是 XP 极限编程——四大价值观、十二个最佳实践，一个都不能少，其中「集体代码所有制」是真题考点，下集见。