概述
软件工程是一个很庞杂的系统工程，而我们面对的软件需求也很复杂：
面对不同规模（复杂度，模块量，用户量，开发周期等等）的软件项目，人员储备不尽不同的开发团队也会采用不同的软件开发方法或者说软件开发模型。
本文算是软考高级之系统架构师系列之软件开发模型的续篇，或者严格来说，是部分标题的精讲篇。
UP
Unified Process，统一软件开发过程，是一个二维的软件开发模型，一种面向对象且基于网络的程序开发方法论，一种过程方法，迭代模型。
UP的三个特点：用例驱动、以体系结构（架构）为中心、迭代和增量的软件开发过程。将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。
RUP
Grady Booch，Ivar Jacobson和James Rumbaugh三人共同提出UP理论。后来三人共同成立Rational公司，并开发用于承载其理论体系的软件过程管理平台与工具集Rational。UP基于Rational平台的具象化成果就是RUP，Rational Unified Process。其他开发管理和辅助工具，如Rational Rose、ClearCase、Robot、Requisite等都是Rational平台中的组件。
UP和RUP可以混为一谈。
核心工作流
分为6个核心过程工作流（Core Process Workflows）和3个核心支持工作流（Core Supporting Workflows）。尽管6个核心过程工作流可能使人想起传统瀑布模型中的几个阶段，但应注意迭代过程中的阶段是完全不同的，这些工作流在整个生命周期中一次又一次被访问。9个核心工作流在项目中轮流被使用，在每一次迭代中以不同的重点和强度重复：
- 商业建模：也叫业务建模，理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响
- 需求：定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础
- 分析与设计：把需求分析的结果转化为分析与设计模型
- 实现：把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统
- 测试：检查各子系统的交互与集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议
- 部署：打包、分发、安装软件，升级旧系统;培训用户及销售人员，并提供技术支持
- 配置与变更管理：跟踪并维护系统开发过程中产生的所有制品的完整性和一致性
- 项目管理：为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架
- 环境：为软件开发机构提供软件开发环境，即提供过程管理和工具的支持
核心概念
角色：描述某个人或小组的行为与职责。RUP预先定义很多角色
活动：是一个有明确目的的独立工作单元
工件：是活动生成、创建或修改的一段信息
四个阶段
阶段 |
工作 |
产物 |
初始 |
确定项目范围和边界，识别关键用例、制订项目计划、展示候选架构、预估费用和时间、预估风险、阶段技术评审 |
项目蓝图文档（核心需求，关键特性，主要约束）、用例模型、项目计划 |
细化 |
分析问题领域、制订构建阶段计划、确定基础架构、选择构件、淘汰最高风险元素、阶段技术评审 |
完成架构设计、淘汰高风险元素 |
构建 |
开发构件、构件组装与测试、阶段技术评审 |
UML设计模型、测试用例 |
交付 |
进行β测试、制作发布版本、用户文档定稿、确认新系统，培训、调整产品、阶段技术评审 |
可运行的软件产品、用户手册、用户支持计划 |
UP把软件开发生存周期划分为多个循环，每个循环生成产品的一个新版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务：
- 初始阶段（Inception）：定义最终产品视图和业务模型，并确定系统范围。必须识别所有与系统交互的外部实体（执行者），定义系统与外部实体交互的特性。在这个阶段中，所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。
- 细化阶段（Elaboration）：设计及确定系统的体系结构，制定工作计划及资源要求；任务：分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。此阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。在细化阶段，可执行的原型依赖于项目的范围、规模和风险等因素。必须至少处理初始阶段中识别的关键用例，因为关键用例通常揭示项目的主要技术风险。
- 构造阶段（Construction）：即构建阶段，构造产品并继续演进需求、体系结构、计划直至产品提交；要开发所有剩余的构件和应用程序功能，把这些构件集成为产品。要开发所有剩余的构件和应用程序功能，将这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已经为部署软件作好准备。当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。
- 移交阶段（Transition）：即交付阶段，把可用的产品提交给用户使用。重点是确保软件对最终用户是可用的。主要任务是进行β测试，制作产品发布版本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。
每个阶段都有一个或多个连续的迭代组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对工作流中的行为进行裁剪。在每个阶段结束前有一个里程碑评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续该阶段的工作。
基于UP的软件过程是一个迭代过程，通过初始、细化、构建和移交4个阶段就是一个开发周期，每次经过这4个阶段就会产生一代产品，在每一轮迭代中都要进行测试与集成。
每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。通过初始、细化、构建和移交4个阶段就是一个开发周期，每次经过这4个阶段就会产生一代软件。除非产品退役，否则通过重复同样的4个阶段，产品将演化为下一代产品，但每一次的侧重点都将放在不同的阶段上。好处是在软件开发的早期就可以对关键的、影响大的风险进行处理。
在大多数传统的生命周期中，阶段是以其中的主要活动命名的：需求分析、设计、编码、测试。传统的软件开发工作大部分强调过程的串行执行，也就是一个活动需要在前一个活动完成后才开始，从而形成一个过程串，该过程串就组成了软件项目的生命周期。
在迭代模型中，每个阶段都执行一次传统的、完整的串行过程串，执行一次过程串就是一次迭代。每次迭代涉及的过程都包括不同比例的所有活动。
每个阶段结束于一个主要的里程碑（Major Milestones）；每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意，可以允许项目进入下一个阶段。UP是一个通用过程框架，它是基于构件的，在为软件系统建模时，UP使用的是UML。
每个阶段结束时都要安排一次技术评审，以确定本阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。基于UP的软件过程是一个迭代过程，每次经过四个阶段就会产生一代软件。除非产品退役，否则通过重复同样的四个阶段，产品将演化为下一代产品，但每一次的侧重点都将放在不同的阶段上。初始阶段的任务是为系统建立业务模型并确定项目的边界。
二维软件开发模型
横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构，用来描述它的术语主要包括周期（Cycle）、阶段（Phase）、迭代（Iteration）和里程碑（Milestone）；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动（Activity）、产物（Artifact）、工作者（Worker）和工作流（Workflow）。
迭代开发模型
每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行的产品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为最终的系统。
与传统的瀑布模型相比较，迭代过程具有以下优点：
- 降低在一个增量上的开支风险
- 降低产品无法按照既定进度进入市场的风险
- 加快整个开发工作的进度
十大要素
适合RUP的十大要素：
- 开发前景
- 达成计划
- 标识和减小风险
- 分配和跟踪任务
- 检查商业理由
- 设计组件构架
- 对产品进行增量式的构建和测试
- 验证和评价结果
- 管理和控制变化
- 提供用户支持
六大经验
- 迭代式开发：迭代式开发允许在每次迭代过程中需求可能有变化，通过不断细化来加深对问题的理解。不仅可以降低项目的风险，而且每个迭代过程以可以执行版本结束，可以鼓舞开发人员。
- 管理需求。确定系统的需求是一个连续的过程，开发人员在开发系统之前不可能完全详细的说明一个系统的真正需求。RUP描述如何提取、组织系统的功能和约束条件并将其文档化，用例和脚本的使用以被证明是捕获功能性需求的有效方法。
- 基于组件的体系结构。组件使重用成为可能，系统可以由组件组成。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。RUP描述如何设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构。
- 可视化建模。RUP往往和UML联系在一起，对软件系统建立可视化模型帮助人们提供管理软件复杂性的能力，获取有关体系结构于组件的结构和行为信息。
- 验证软件质量。在RUP中软件质量评估不再是事后进行或单独小组进行的分离活动，而是内建于过程中的所有活动，这样可以及早发现软件中的缺陷。
- 控制软件变更。迭代式开发中如果没有严格的控制和协调，整个软件开发过程很快就陷入混乱之中，RUP描述如何控制、跟踪、监控、修改，隔离来自其他工作空间的变更，以此为每个开发人员建立安全的工作空间。
裁剪
RUP是一个通用的过程模板，包含很多开发指南、制品、开发过程所涉及到的角色说明，非常庞大。所以对具体的开发组织和项目，用RUP时还要做裁剪，也就是要对RUP进行配置。通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看作RUP的具体实例。RUP裁剪步骤：
- 确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以取舍
- 确定每个工作流需要哪些制品
- 确定4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要那些工作流，每个工作流执行到什么程度，制品有那些，每个制品完成到什么程度
- 确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的内容
- 规划工作流内部结构。工作流涉及角色、活动及制品，他的复杂程度与项目规模即角色多少有关。最后规划工作流的内部结构，通常用活动图的形式给出。
UML
UP诞生时附带的产物，最终人们发现UML还可以独立的使用并产生巨大价值，由OMG组织维护。
对比Agile
优点：提高团队生产力，为每个开发成员提供必要的准则、模板和工具指导，建立简洁和清晰的过程结构
缺点：不能快速适应需求的变化、缺少开发商的支持、仅仅包含开发过程、并没有完全覆盖软件过程。
由于太过于庞大和复杂，相对于轻量级的敏捷方法来说，显得死板和难以实施。UP不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和很多额外的工作。对于较小的组织和项目来说，使用敏捷方法可能比较合适，而使用UP似乎有些费力不讨好。
4+1视图
Philippe kruchten在《Rational统一过程引论》提出：
架构视图是对于从某一视角或某一点上看到的系统所做的简化描述，描述中涵盖系统的某一特定方面，而省略与此方面无关的实体。
被RUP采纳。其思想即为关注点分离。现在已经成为架构设计的结构标准。
- 逻辑视图：Logical View，逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的辅助功能模块；它们可能是逻辑层、功能模块等。从系统的静态结构和动态行为角度显示系统内部如何实现系统的功能。
- 开发视图：Development View，实现视图，开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。显示的是源代码以及实际执行代码的组织结构。
- 进程视图：Process View，过程视图，处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。显示程序执行时并发的状态。
- 物理视图：Physical View，部署视图，Deployment View。物理视图关注目标程序及其依赖的运行库和系统软件最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。展示软件到硬件的映射。
- 场景视图：scenarios，用例视图，Use Cases View。架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例或场景来说明，从而形成第五个视图。显示外部参与者观察到的系统功能。
当采用面向对象的设计方法描述对象模型时，通常使用类图表达类的内部属性和行为，以及类集合之间的交互关系；采用状态图定义对象的内部行为。
不同的人员会关心不同的视图：
- 分析人员和测试人员关心的是系统的行为，侧重于用例视图
- 最终用户关心的是系统的功能，侧重于逻辑视图
- 程序员关心的是系统的配置、装配等问题，侧重于实现视图
- 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，侧重于进程视图
- 系统工程师关心的是系统的发布、安装、拓扑结构等问题，侧重于部署视图
JAD
联合应用开发，Joint Application Development，一个方法论，它通过一连串的合作研讨会，也叫JAD会议（Joint Application Design Sessions），它使得一个应用程序的设计和开发中的客户或最终用户参与其中。IBM的Chuck Morris和Tony Crawford在20世纪70年代末开发JAD，并且在1980年开始通过研讨会讲授这个观念。
比起更传统的方法，JAD观念被认为其成倍地加快开发的速度，并增大客户的满足感，因为客户参与开发的全过程。相比之下，在系统开发的传统观念中，开发者利用通过一系列面对面的交谈而得到的客户输入信息来调研系统需求并且开发应用程序。
JRP
联合需求计划，Joint Requirement Planning，JRP是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（JAD）的一部分。是一种相对来说成本较高的但十分有效的需求获取方法（而非需求分析与验证的方法）
JAD以小组形式定义和建立系统，由企业主管部门经理、会议主持人、用户、协调人员、IT人员、秘书等共同组成的专题讨论组，由这个讨论组来定义并详细说明系统的需求和可选的技术方案。JRP通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。通常参会人数6 ~ 18人，时间1 ~ 5小时。
JRP相对来说成本较高，但是一种十分有效的一种需求获取方法：
- 加快需求获取进度，降低需求获取成本，尤其对有歧义、最不清晰的领域十分有效
- 提升用户参与积极性，提高开发效率
- 采用原型确认系统需求并获取设计审批，具有原型化开发方法的优点
JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：
- 在JRP实施之前，应制定详细的议程，并严格遵照议程进行
- 按照既定的时间安排进行
- 尽量完整地记录会议期间的内容
- 在讨论期间尽量避免使用专业术语
- 充分运用解决冲突的技能
- 会议期间应设置充分的间歇时间
- 鼓励团队取得一致意见
- 保证参加JRP的所有人员能够遵守实现约定的规则
JRP将会起到群策群力的效果，对于一些问题最有歧义时、对需求最不清晰的领域都是十分有用的一种方法。这种方法最大的难度是会议的组织和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果。
JRP的一般步骤：
- 让与会者互相认识，力求会议在轻松气氛中进行
- 列举问题，逐一讨论或按照议程，逐一进行
- 鼓励大家对现有系统或现状畅所欲言
- 鼓励大家对新系统畅想，形成清单
- 对清单进行整理，明确优先级，评审，最后形成结论或结议
RAD
快速应用开发（Rapid Application Development，RAD）是一种比传统生存周期法快得多的开发方法，强调极短的开发周期。RAD模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发。如果需求理解得很好，且约束好项目范围，利用这种模型可以很快地开发出功能完善的信息系统。
JAD的一个变种，通过例如使用更少的形式方法学和重用软件组件从而更快地创作出一个应用程序。
局限性：
- 并非所有应用都适合RAD。RAD对模块化要求比较高，如果有哪一项功能不能被模块化，那么RAD所需要的构建就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则RAD也有可能不能奏效
- 开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致RAD项目失败
- RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统与现有系统有较高的互操作性时，就不适合使用RAD。
RAD是一种开发模式，相对于冗长的开发和测试周期，它提倡快速的原型设计和即时反馈。在快速应用开发模式的帮助下，程序员可以在短时间内对软件进行多次迭代和修改，而不必每次都从头开始。这有助于确保最终结果更加注重质量，并与最终用户的需求同步。
可以分解为四个不同的部分。以下是这些阶段的概要：
- 明确必要的要求
项目组成员，包括经理、IT人员成员和用户，都聚集在一起确定目标，其中包括项目的需要、项目的范围、可能发展的潜在困难以及项目的目标和需要。为了保持项目的适应性，开发过程确保需求的边界保持宽泛。 - 用户的输入
在开发过程的第二阶段，根据包括开发人员和最终用户在内的团队提供的规格创建原型。预计这一阶段将持续进行，在此期间，消费者将使用软件，以便向开发者提供反馈。 - 构建
构建阶段和用户输入共同创建应用开发的最终产品或雷达模型。在构建阶段，用户在用户输入阶段提供的反馈被考虑在内。编码和测试是为实现这一目标而采取的典型方法。构建阶段和用户输入阶段都将继续进行，直到用户对结果达到满意的程度。 - 最终确定
在用户输入阶段和建设期都结束后，假设用户对成品完全满意，下一个阶段就是最终确定。产品从所进行的测试和培训等活动中得到了最后的修饰。在产品交付给消费者后，它要经过测试，以了解它能持续多久，以及它的稳定性如何。
何时使用RAD模型：
- 当创建产品的时间较少时，例如在几天的时间内
- 当已经就可交付的产品和要求作出决定时
- 当最终用户或客户可以选择参与产品生命周期的所有阶段时，这被称为 “客户或用户参与”。
- 如果预算足够多，就可以雇用设计师。为了用自动化工具开发代码，这需要更大的预算。
最适合用于哪些项目
RAD模式对于设计由用户界面需求驱动的软件特别有用，而这并不是唯一可以使用它的应用。用于创建图形用户界面的工具经常被称为RAD工具。
RAD有何不同？
使用快速应用开发模式开发软件的过程与其他软件开发模式所采用的方法有很大不同。
优点
- 加强风险管理
- 减少用于开发的时间，提高交付率
- 提高适应性和灵活程度
- 持续的用户输入，既中肯又实时
- 对手工编码的需求将减少，测试所需时间也将减少
- 需求容易在任何时候被修改
- 在减少劳动力的情况下，生产力水平更高
- 原型和修订之间的时间最小