统一过程
特点
- 统一过程是用例驱动的
-
用户（User）：软件系统是为了解决用户的需求的，因此对于一个系统必须首先确定它的用户，即参与者。这个User不仅仅指人，也可以是其他系统。即用户是与系统进行交互的事物。
-
用例（User Case）：是用户对系统的业务需求，即用例是能够向用户提供有价值结果的系统中的一种功能。
所有的用户和用例组合在一起就是用例模型，它描述了系统的全部功能。用例促使我们从系统对用户的价值方面来考虑问题，是站在用户的角度出发，以人为本。并且用例不仅能确定用户的需求，还可以驱动系统设计、实现和测试的进行，也就是说用例可以驱动开发过程。用例驱动表明开发过程是沿着一个流——一系列从用例得到的工作流前进的：用例被确定、用例被设计、最后用例又称为测试人员构造测试用例的基础。
- 统一过程是以构架为中心的
-
什么是软件构架？
软件构架的作用与建筑构架所起的作用类似。软件系统的构架是从不同的角度描述即将构造的系统。
注意：软件架构（Software Architecture），是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。它描述的对象是直接构成系统的抽象组件，各个组件之间的连接明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，在面向对象领域中，组件之间的连接通常用接口来实现。
软件构架包含了系统中最重要的静态和动态特征。构架刻画了系统的整体设计，去掉了细节部分，突出了系统的重要特性，然而“究竟什么是重要的”部分依赖于判断，而判断又来自于经验，所以构架的价值也就依赖于执行该任务的人的素质，在构架的过程中可以帮助构架师确定正确的目标。 -
用例和架构之间是什么关系？
每一种产品都具有功能和表现形式两个方面，其中功能与用例相对应，表现形式与构架相对应。因此用例在实现时必须适应于构架，然而随着系统的发展，用例也在不断的进化，所以构架必须设计得使系统能够进化，不仅要考虑系统的初始开发，而且要考虑将来的发展。为了能够找到这样的一种表现形式（构架），构架师必须从全面了解系统的主要功能（即主要用例）入手，这些主要的用例构成了系统的核心功能。
-
构架应该遵循什么步骤？
首先，从不是专门针对用例的那部分架构开始，如平台，创建一个粗略的构架轮廓。
其次，着手处理已经确定重要的用例子集，这些用例代表着即将开发系统的主要功能，详细描述每一个用例，并通过子系统、类和构件来实现。随着用例的描述趋于完善，构架的更多部分便会显现出来，从而也使更多的用例趋于完善。最后，迭代这个工程直到确信得到一个稳定的构架为止。
-
统一过程是迭代和增量的过程
迭代即工作流中的步骤；增量即产品中增加的部分。软件开发是一项复杂的过程，因此可以将这些项目划分为切实可行并能够产生一个增量的迭代过程。为了获得最佳的效果，迭代过程必须是受控的（Controlled），也就是说必须按照计划好的步骤有选择地执行。
那么如何确定迭代过程中要实现的目标呢？
首先迭代过程就是用来处理一组用例的，这些用例组合起来就能够扩展所开发产品的可用性。
其次迭代过程要解决最突出的风险问题。只有这样后续的迭代过程才能建立在前一次迭代过程的基础上。
统一软件开发过程的每个阶段可以进一步被分解为迭代过程。迭代过程是导致可执行产品版本（内部和外部）的完整开发循环，是最终产品的一个子集，从一个迭代过程到另一个迭代过程递增式增长形成最终的系统。
迭代过程具有的优点
- 减小了风险
- 更容易对变更进行控制
- 高度的重用性
- 项目小组可以在开发中学习
- 较佳的总体质量
统一过程的软件生命周期
（1） 统一过程的软件生命周期就是从软件的产生到消亡期间进行的一次次迭代，每次迭代都会产生一个产品版本，并且本次迭代是基于上次迭代的。产品就是软件系统的一个构件，但是只有这些是仅仅不够的，因为环境（操作系统、数据库系统）在变化，此外随着更好的理解任务，需求本身也在变化。因此统一开发过程中每次迭代要依据一些模型来产生产品。
用例模型： 包含用例与用户之间的关系
分析模型： 更详细的提炼用例，将系统的行为初步分配给提供行为的一组对象
设计模型： 将系统静态结构定义为子系统、类和接口，并定义由子系统、类和接口之间的协作所实现的用例。
实现模型： 包括构件（表现为源代码）和类到构件的映射。
实施模型： 定义计算机的物理节点和构件到这些节点的映射。
测试模型： 描述用于验证用例的测试用例。
业务模型： 描述系统业务预警的领域模型。
所有的这些模型都是相关的，它们合起来表示整个系统。由图1从上往下看，下面的模型对上面的模型有跟踪依赖关系。这有利于系统的理解和修改。
（2）迭代阶段
每次迭代分为四个阶段：初始、细化、构造和移交 ；在每个阶段，管理人员或开发人员又可以将本阶段的工作进一步划分为多次迭代过程以及每次迭代过程所产生的增量。每个阶段都以一个里程碑作为结束标记，并可以获得一组可用的制品来定义每个里程碑。迭代的每个阶段通常又进一步细分为多次迭代过程，一次典型的迭代阶段（初始、细化、构造、移交）都要经历多种工作流：需求、分析、设计、实现和测试。
初始阶段：这个阶段最主要的是确定项目的风险及其优先次序，并对细化阶段进行详细规划和对整个项目进行粗略计算。
细化阶段：根据主要的用例描述设计出详细的系统构架。构架包括了用例模型、分析模型、设计模型、实现模型（包含一些构件）和实施模型的视图。
这个阶段主要是解决用例、构架和计划是否足够稳定可靠，风险释放得到充分控制，以便能够按照合同的规定完成整个开发任务。
构造阶段：将构造出最终产品。
移交阶段：包括产品进入beta版后的整个阶段。开发人员改正用户报告产品的缺陷和不足。
敏捷过程
何为敏捷开发过程？
敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程称为“敏捷过程”。
在这一过程中，软件项目的构建被切分成多个子项目，各个子项目的成功都经过测试，具备集成和可运行的特征。
在2001年年初，一些业界专家成立了敏捷联盟，起草了敏捷软件开发宣言。该宣言针对一些企业的现状，提出了让软件开发团队具有快速工作、快速应变能力的若干价值观和原则，其中包括4个简单的价值观以及敏捷开发方法应遵循的12条原则。
敏捷开发过程，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
敏捷过程的4个价值观
（1）个人和交互胜过过程和工具。
（2）可以运行的软件胜过面面俱到的文档。
（3）客户合作胜过合同谈判。
（4）响应变化胜过遵循计划。
敏捷开发应遵循的12条原则
（1） 通过尽早的、不断地提交有价值的软件来使客户满意。
（2） 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
（3） 以从几个星期到几个月为周期，尽快、不断地提交可运行的软件。
（4） 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
（5） 以积极向上的员工为中心，建立项目组，给他们提供所需的环境和支持，并对他们的工作予以充分的信任。
（6） 在团队内部，最有效、效率最高的传递信息的方法，就是面对面的交流。
（7） 测量项目进展的首要依据是可运行软件。
（8） 敏捷过程提倡可持续的开发，责任人、开发者和用户应该为能够保持一个长期的、恒定的开发速度而努力。
（9） 时刻关注技术上的精益求精和好的设计，以增强敏捷能力。
（10） 简单是最根本的。
（11） 最好的构架、需求和设计出于自组织的团队。
（12） 每隔一定时间，团队要反省如何才能更有效地工作，然后相应地调整自己的行为。
