一个受控制的迭代过程的好处有很多 ：
ω 受控制的迭代降低了在一个增量上的开支风险。如果开发人员需要重复该迭代，整个开发团队损失
的只是一个开发有误的迭代的花费而已，而不是整个产品的价值。
ω 受控制的迭代降低了产品无法按照既定进度表进入市场的风险。通过在开发早期就确定风险，人们
就会在开发早期花时间来解决它们，而在这时，人们通常都不会像他们在开发后期那样匆匆忙忙。在“传统”方法中，困难的问题往往是在系统测试阶段才发现的，而解决这些问题所需求的时间通常又比开发进度中剩下的时间要多，因此，产品的延迟发布几乎是必然的 。
ω 受控制的迭代加快了整个开发工作的进度，这是因为开发人员很清楚焦点所在，而不是在一个漫长
而不断变化的进度安排下工作，因此, 他们的工作会更有效率。
ω 受控制的迭代承认了通常都被忽略的一个事实：用户的需要和相应的需求并不能在一开始就作出完
全的界定。它们通常都是在后续迭代中不断被细化的。此种作业模式使得适应需求的变化更为容易。
这些概念即用例驱动的、以基本架构中心的、迭代式和增量性的开发是同等重要的。基本架构提供了
指导迭代中的工作的结构，而用例则确定了开发目标并推动每次迭代工作。缺乏这三个概念中的任何一个，都将严重降低“统一过程”的价值。这就好像一个三脚凳一样，一旦缺了任何一条腿，凳子都会翻倒。
以上我们已经介绍了三个主要概念，现在让我们来看看整个过程、它的生命期、成果、工作流程、阶
段和迭代。
“统一过程”的生命期
“统一过程”将重复一系列生命期，这些生命期构成了一个系统的寿命。每个生命期都以向客户推出
一个产品版本而结束。
每个周期包括四个阶段：开始阶段、确立阶段、构建阶段和移交阶段。正如上文已经讨论的，每个阶段可以进一步划分为多次迭代。
产品每个生命期都产生系统的一个新版本，而每个版本是一个能立即推向市场的产品。它包括体现在组件中的可被编译和执行的源代码，还有说明手册及其他可交付的相关产品。然而，最终产品也必须符合相关需要，此种需要并不仅仅是指用户的需要，而且指所有利益关联人的需要，也就是指那些将利用该产品来进行工作的所有人。软件产品应当不仅仅只是可执行的机器代码。
最终产品包括需求、用例、功能性需求和测试案例。它包括基本架构和可视模型( 由统一建模语言构摸
的产物) 。事实上，它包括我们正在这里讨论的所有元素，因为它正是所有利益关联人（包括客户、用户、分析人员、设计人员、实现人员、测试人员和管理人员）要详细定义、设计、实现、测试和使用一个系统所需要的东西。此外，正是这些东西，才使得利益关联人能使用并逐代修改系统 。
即使在用户看来，可执行组件是最重要的产物，但是，仅仅有这些产物是不够的。这是因为环境会不
断发生变化。操作系统、数据库系统和作为系统基础的机器在不断发展。随着任务被更好地理解，需求本身也会发生变化。事实上，需求不断发生变化是软件开发领域里的诸常量之一。这样，开发人员就必须开始一个新的开发生命期，管理人员则必须为之提供资金。为了有效地实施下一个生命期，开发人员需要该软件产品的所有表现形式
ω 用例模型，这个模型表明了所有用例和这些用例与用户之间的关系
ω 分析模型，该模型有两个目的：更加详尽地细化用例，以及将系统的行为初步分配给一组提供这些
行为的对象。
ω 设计模型，该模型（a ）以子系统、类和接口的形式定义系统的静态结构，（b ）以子系统、类和接口
之间的协作来定义用例的实现。
ω 实现模型，该模型包括组件（代表源代码）和类向组件的映射。
ω 配置模型，该模型定义计算机的物理节点和组件向这些节点的映射。
ω 测试模型，该模型描述那些用来验证用例的测试实例。
ω 还包括基本架构的表示。
系统还应当有一个域模型或业务模型来描述系统的业务上下文。
所有这些模型都是彼此相关的。它们一起表达了整个系统。在一个模型中的元素可向前或向后追溯到
其它模型中。例如，（用例模型中的）一个用例可以被追溯到（设计模型中的）一项用例实现，再追溯到（测试模型中的）一个测试案例。可追踪性有利于理解和处理变化 。
一个生命期中的诸阶段一个生命期中的诸阶段一个生命期中的诸阶段一个生命期中的诸阶 段
每个生命期都持续一段时间。这段时间反过来又可以分成四个阶段（见下图 ）。通过一系列的模型，利益相关人可以直观地看到这些阶段的进展状况。在每个阶段中，经理人员或开发人员还可能进一步对工作进行细分：分成多次迭代并确保增量。每个阶段都结束于一个里程碑。我们以一组获得的成果来定义每个里程碑。亦即特定的模型或者文档已经达到了预定的状态。
里程碑用于许多目的。最重要的是，在工作进入下一个阶段之前，管理人员必须作出某些关键决策。
里程碑还能帮助管理人员以及开发人员在开发工作经过这四个关键点时监控工作进度。最后，通过对每个阶段上花费的时间和精力进行追踪，我们还能获得一组数据。这些数据在评估其他项目需要多少时间和人员、计划项目期间内需要的项目人员和根据这个计划来控制工作进度上是非常有用的 。
下图左边一栏列出了工作流程——需求、分析、设计、实现和测试。曲线大致（不能认为此种曲线就完全代表了实际情况）表示了每个阶段中工作流程被执行的内容。注意，每个阶段通常都被分解为迭代或称小项目。如图中的确立阶段所示，一次典型的迭代要经历全部五个工作流程。
在开始阶段，一个好的理念被开发成对最终产品的设想，并且该产品应用的业务用例被提出来。最重要的是，这个阶段回答了如下问题 ：
ω 这个系统将为其每个主要用户做些什么？
ω 该系统的基本架构应是什么样子 ？
ω 开发这个产品的计划是什么，费用是多少？
包括最关键的用例的一个简化的用例模型回答了第一个问题。在这个阶段，基本架构还是试验性的，
通常它只是一个包括关键子系统的轮廓而已。在这个阶段，最重要的风险被确认，并按优先次序进行了排列；对确立阶段进行详细的计划；对整个系统进行粗略的评估。
在确立阶段，产品中的大部分用例被详细地定义下来，系统基本架构也被设计出来。系统的基本架构
和系统本身之间的关系是极为重要的。简单地说，基本架构就像一个裹着皮肤但是肌肉很少的骨架：
只有一些能让该骨架作一些基本运动的必要的肌肉。而系统则是由骨架、皮肤和肌肉组成的有机整体 。
因此，基本架构被表示为系统中所有模型的视图，这些视图共同表达了整个系统。这意味着，存在用
例模型、分析模型、设计模型、实现模型和配置模型的基本架构视图。实现模型的视图包括能证明基本架构是可执行的组件。在这个开发阶段，在确立阶段确定的最关键的用例被实现。这个阶段的成果是基本架构基线 。
在确立阶段的末期，项目经理要计划活动并估算完成该项目需要的资源。在这里，关键的问题是，用
例、基本架构和计划是否足够稳定，风险是否已经处在有效控制之下，从而能够提交合同中规定的整个开发工作？
在构建阶段，产品被建构——肌肉（即完工的软件）被添加到骨架（即基本架构）上。在这个阶段，
基本架构基线已经成长为一个羽翼丰满的系统。最初对产品的设想已经演化成了准备交付给用户的一个产品。在这个开发阶段，项目所需求的大部分资源被使用。尽管系统的基本架构是稳定的，但是，由于开发人员可能发现结构化系统的更好的方式，因此，他们可能会建议架构设计师对基本架构进行一些小修小补。
在这个阶段的最后，产品已经包括了管理人员和客户同意为这个产品开发的所有用例。然而，它可能不是完全没有缺陷的。在移交阶段，会发现并修正更多的缺陷。这个里程碑的问题是，该产品是否有效地满足了客户的需求，可以向某些客户提前交付该产品？
移交阶段是指产品发布测试版的阶段。在测试版中，由少数有经验的用户来使用该产品，并报告他们
发现的缺陷和不足。开发人员则更正这些缺陷和不足，并将有些改进建议融入到向更大的用户群发布的一般产品中。移交阶段涉及诸如制造、培训客户人员、提供热线帮助和修正产品发布后发现的缺陷等活动。
维护队伍通常将这些缺陷划分为两类：那些对后续的正式版本的正常操作有一定的缺陷，和那些可以在下一个正式版本中更正的缺陷。
“统一过程”是基于组件的。它利用了新的可视建模标准UML ，并依赖于三个关键观点：用例、基本
架构、迭代和增量开发。要使这些观点可用，需求一个多层面的过程，该过程应当考虑到生命期、阶段、工作流程、风险缓和、质量控制、项目管理和配置控制等。“统一过程”确立了一个集成了所有这些因素的框架。这个框架就像一把雨伞，在它下面，工具提供商和开发者可以构建工具来支持该过程的自动化、支持各个工作流程、构建所有不同的模型，并在整个生命期和所有的模型中集成这些工作 。
文章来源于领测软件测试网 https://www.ltesting.net/
