当前，软件的趋势是朝着更大更复杂的系统发展。这部分地是因为计算机的处理能力每年都在增大，
导致用户对它的期望更多。同时，这种趋势也受到为交流各种信息（从纯文本到格式化文本到图像到图表再到多媒体）而不断扩大互联网的使用的影响。在产品版本的不断升级过程中，我们了解到产品是如何被改进的，因此我们对越来越复杂的软件的胃口也就越来越大。我们需要更符合我们的需要的软件，但是，这种需要反过来又使得软件越来越复杂。总之，我们需要更多。我们希望软件运行得越来越快捷。推向市场的时间是另一个重要的推动因素 。
然而，要达到这个目的是困难的。我们对强大、复杂软件的需要与软件开发的当前状况并不一致。今
天，大多数人还在使用25 年前使用的旧方法来开发软件。这就是症结所在。除非我们革新我们的方法，否则，我们无法达到开发当前所需的复杂软件的目标 。
我们可以把这个软件问题归结为软件开发人员面临的将一个大型软件项目的众多线索综合在一起的困
难。软件开发界需要一种受控的工作方式。它需要一个过程来集成软件开发的许多方面。它需要一种通用方法 ，该方法能 ：
ω 提供应如何对整个开发团队的开发活动进行组织的指导 ；
ω 综合指导单个开发人员和开发团队 ；
ω 规定开发成果是什么 ；
ω 提供监控和衡量一个项目中的产品和活动的标准 。
一个定义良好且管理良好的过程是区别成效卓著的项目和不成功项目之间的重要指标。“统一软件开
发过程”正是我们在软件开发上面临的难题的解决之道。
“统一过程”概述
第一点也是最重要的一点是，这个“统一过程”是软件开发过程。软件开发过程是将用户的需求转化
为一个软件系统的一系列活动的总称。然而，“统一过程”不仅仅是一个过程。它是一个通用过程框架，可以应付种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项
目规模。
“统一过程”是基于组件的，这意味着利用它开发的软件系统是由组件构成的，组件之间通过定义良
好的接口相互联系 。
在准备软件系统的所有蓝图的时候，“统一过程”使用的是“统一建模语言（Unified Modeling
Language ）”。事实上，UML 是“统一过程”的有机组成部分——它们是被同步开发的 。
然而，真正使“统一过程”与众不同的方面可以用三个句话来表达：它是用例驱动的、以基本架构为
中心的、迭代式和增量性的。正是这些特征使得“统一过程”卓尔不群。
“统一过程”是用例驱动的“统一过程”是用例驱动的“统一过程”是用例驱动的“统一过程”是用例驱动的开发软件系统的目的是要为该软件系统的用户服务。因此，要创建一个成功的软件系统，我们必须明白其潜在用户需要什么 。
“用户”这个术语所指并不仅仅局限于人类用户，还包括其他系统。在这种意义上，“用户”这个术语代表与利用“统一过程”开发出来的系统发生交互的某个人或者某件东西（例如在所要开发的系统之外的另一个系统）。交互的一个例子是使用自动取款机的一个人。他/ 她插入塑料磁卡，回答机器显示器上提出的问题，然后就得到了一笔现金。在响应用户的磁卡和回答时，系统完成一系列的动作，这个动作序列为用户提供了一个有意义的结果，也就是提取了现金。
这个交互就是一个“用例”。一个用例就是系统中向用户提供一个有价值的结果的某项功能。用例捕捉
的是功能性需求。所有用例结合起来就构成了“用例模型”，该模型描述系统的全部功能。这个模型取代了系统的传统的功能规范说明。一个功能规范说明可以描述成对这个问题的回答：需要该系统做什么？而用例战略则可以通过在该问题中添加几个字来描述：需要该系统为每个用户做什么？这几个字有着重大意义。
它们迫使我们从用户的利益角度出发进行考虑，而不仅仅是考虑系统应当具有哪些良好功能 。
然而，用例并不仅仅是定义一个系统的需求的一个工具。它们还驱动系统的设计、实现和测试。也就
是说，它们驱动整个开发过程。基于用例模型，软件开发人员创建一系列的设计和实现模型来实现各种用例。开发人员审查每个后续模型，以确保它们符合用例模型。测试人员将测试软件系统的实现，以确保实现模型中的组件正确实现了用例。这样，用例不仅启动了开发过程，而且与开发过程结合在一起。“用例驱动”意指开发过程将遵循一个流程：它将按照一系列由用例驱动的工作流程来进行。首先是定义用例，然后是设计用例，最后, 用例是测试人员构建测试案例的来源。
尽管确实是用例在驱动整个开发过程，但是我们并不能孤立地选择用例。它们必须与系统架构协同开
发。也就是说，用例驱动系统架构而系统架构反过来又影响用例的选择。因此，随着生命期的继续，系统架构和用例都逐渐成熟。
“统一过程”是以基本架构为中心的“统一过程”是以基本架构为中心的“统一过程”是以基本架构为中心的“统一过程”是以基本架构为中心的软件架构的作用在本质上与基本架构在建筑物结构中所起的作用是一样的。我们从不同的角度来观察建筑物：结构、服务、供热装置、水管装置、电力等。这样，在开始建设之前，建设人员就可以对建筑物有一个完整的把握。同样地，软件系统的基本架构也被描述成要创建的系统的各种不同视图 。
软件基本架构这个概念体现了系统最为静态和动态的方面。基本架构根据企业的需求来设计，而这种
需求则是由用户和其他利益关联人所感知，并反映在用例之中。然而，它还受其他许多因素的影响：软件运行的平台（例如计算机基本结构、操作系统、数据库管理系统和网络通信协议等）、可得到的可再用构件（比如图形用户界面框架）、配置方面的考虑、已有系统和非功能性需求（比如性能和可靠性）等。基本架构是一个关于整体设计的视图，在这个视图中，省略了一些细节，以使软件的更为重要的特征体现得更为明显。由于什么东西是重要的部分取决于主观判断，而这种判断又来自于经验，因此，基本架构的价值取决于被指派完成这一任务的人员。然而，过程有助于架构设计师集中精力于正确的目标，比如可理解性、顺应未来变化的灵活性和可再用性。
用例和基本架构之间的关系如何呢？每个产品都是功能和形式的有机统一。仅仅只有其中之一，都是
不完整的。只有平衡把握这两个方面才能得到一个成功的产品。在这种情况下，功能应与用例相对应，而形式应当与基本架构相对应。用例和基本架构之间必定是相互影响的，这几乎就是一个“鸡和蛋”的问题。
一方面，我们实现的用例必须与基本架构相适应。而另一方面，基本架构必须留有实现现在和未来需要的所有用例的空间。在实践中，基本架构和用例必须平行开发 。
因此，架构设计师将软件系统构筑在一个形式当中。正是这个形式即基本架构必须被设计成让系统不
仅在初始开发期间, 而且在未来的版本进化过程中能不断发展。要找到这样的一个形式，架构设计师必须对系统的关键功能也就是系统的关键用例有一个总体性把握。这些关键用例只占用例总数的5-10%，但是它们却是最重要的，因为它们将构成整个系统的核心功能。下面是这个过程的简单描述：
ω 架构设计师首先从不与特定的用例相关的部分（比如平台）着手来创建基本架构的大致轮廓。尽管
基本架构的这部分是用例无关的，但是，在建立基本架构的轮廓之前，架构设计师必须对用例有一个总体把握。
ω 其次，设计人员应当从已经确认的用例子集着手开始工作，这些用例是指那些代表待开发系统的关
键功能的用例。每个选定的用例都应当被详细描述，并在子系统、类和组件层次上实现。
ω 随着用例已经被定义并且逐渐成熟，基本架构就越来越成形了。而这种状况，反过来又导致更多用
例的成熟。
这个过程会不断持续下去，直至基本架构被认定为稳定了为止。
统一开发过程是迭代式的和增量的统一开发过程
开发一个商业软件产品是一项可能持续几个月、一年甚至更长时间的工作。因此，将此种工作分解成
若干更小的部分或若干小项目是切合实际的 。
每个小项目是指能导致一个增量的一次迭代。迭代指的是工作流中的步骤，而增量指的是产品的成长。
为了更加高效，迭代必须受到控制；也就是说，必须对它们进行选择并有计划地实现它们。这就是为什么它们是小项目的原因 。
开发人员根据两个因素来选择在一次迭代中要实现什么。首先，迭代与一组用例相关，这些用例共同
扩展了到目前为止所开发的产品的可用性。其次，迭代涉及最为重要的风险。后续迭代是建立在先前的迭代完成后的开发成果之上的。它是一个小项目，因此，从用例开始，它还是必须经过下列开发工作：分析、设计、实现和测试，这样，就以可执行代码的形式在迭代中实现了用例。当然，一项增量并不一定就是添加性的。特别是在生命期的早期阶段，开发人员可能会用一个更为详尽或者复杂的设计来取代那种较为简单的设计。在后期，增量通常都是添加性的 。
在每次迭代中，开发人员识认并详细定义相关用例，利用已选定的基本架构作为指导来建立一个设计，
以组件形式来实现该设计，并验证这些组件满足了用例。如果一次迭代达到了它的目标（通常如此），那么开发过程就进入下一次迭代的开发了。当一次迭代没有满足它的目标时，开发人员必须重新审查先前的决定，试行一个新方法 。
为了在开发过程中实现经济效益最大化，项目组必将试图选择为达到项目目标所需要的迭代。它应当
以逻辑顺序排列相关迭代。一个成功的项目所经历的过程通常都只与开发人员当初所计划的有细微的偏差。
当然，考虑到出现不可预见的问题需要额外的迭代或者改变迭代的顺序的影响，开发过程可能需要更多的时间和精力。使不可预见的问题减小到最低限度，也是风险控制的一个目标之一 。
一个受控制的迭代过程的好处有很多 ：
ω 受控制的迭代降低了在一个增量上的开支风险。如果开发人员需要重复该迭代，整个开发团队损失
的只是一个开发有误的迭代的花费而已，而不是整个产品的价值。
ω 受控制的迭代降低了产品无法按照既定进度表进入市场的风险。通过在开发早期就确定风险，人们
就会在开发早期花时间来解决它们，而在这时，人们通常都不会像他们在开发后期那样匆匆忙忙。在“传统”方法中，困难的问题往往是在系统测试阶段才发现的，而解决这些问题所需求的时间通常又比开发进度中剩下的时间要多，因此，产品的延迟发布几乎是必然的 。
文章来源于领测软件测试网 https://www.ltesting.net/
