《UML软件开发过程》由会员分享，可在线阅读，更多相关《UML软件开发过程（15页珍藏版）》请在金锄头文库上搜索。
1、第第 3 3 章章 软件开发过程软件开发过程如在第一章所讨论的，每种软件开发方法学都包括两个主要构成部分，即软件开发活动实施过程的描述和对该过程的结果进行文档化的表示法。并且强调了 UML 是一种语言而不是方法学，也不是为支持任何特殊过程而专门设计的。UML 定义的图和表示法可以成功地用于各式各样的不同过程。本章描述有关软件开发过程的一些思想的发展，从第一个广为人知的过程模型开始，以对统一过程的简要描述结束。尽管几乎可以肯定地说，统一过程不是过程建模的最终结论，但是将统一过程和 UML 结合起来考虑很有意义，因为二者是由同一组研究人员开发的。本章将以讨论统一过程所强调的不同 UML 图之间的逻
2、辑关系而结束。3.1 瀑布模型定义一个软件开发过程的早期尝试，主要是以从其他工程学科获得的思想为基础，把这些思想应用于这个新的领域。关键的思想是标识在生产软件中涉及的不同的活动，例如设计、编码和测试，并定义应当以怎样的次序实施这些活动。这导致了过程模型的产生，例如经典的“瀑布”模型，见图 3.1。图 3.1 瀑布模型（Royce,1970）虽然这些阶段的确切数目和命名在瀑布模型的不同版本中不尽相同，但是在所有版本中，这个过程总是系统地从高层开始，说明性地描述系统应当做什么，经由详细描述，最终是用代码详细描述系统将如何做，最后，以系统部署和后续运行所涉及的活动的一些阶段的描述而结束。因此，大多数
3、瀑布模型提供的是软件系统的整个生命周期的一个模型，而不仅仅是软件系统的开发模型。但是，系统的开发构成了模型的很大一部分，无疑地，也是在软件工程文献中受到最多注意的部分。瀑布模型中的每个阶段定义一个各自独立的活动。瀑布中连续的阶段通过箭头连接，向下的箭头表示阶段的时间次序。因此，模型的基本结构暗示了不同的阶段是依顺序进行的。所设想的过程并不是像建造一所房子那样，电工、水工、屋顶工等等可能同时工作，而是更像一条生产线，比如，分析人员完成他们的工作，接着将产品移交给设计人员进行下一个阶段的工作。这个模型中隐含的是，期望每个阶段完成的工作都以某种方式形成文档，而且该文档将被传递下去，并成为下一阶段要做
4、的工作的基础。因此，瀑布模型提出了软件开发的一种理想化的构想，项目将从文档化需求开始，经历分析和设计活动，接着是编码和测试系统。在部署之后，只要它还在使用，系统将被维护。这种经过这些阶段的工作流是将这类模型命名为“瀑布”的缘由。当然，实际上，以这样一种没有疑问的方式开发的项目很少。更典型地是，一个阶段中的工作将暴露前面阶段所做的工作中的问题、错误和遗漏。显然，在继续之前纠正问题是明智的，而不是在有错误的工作的基础上前进。图中向上的箭头表示了这种反馈过程，由此在一个阶段做的工作可能引起前面阶段的修改和返工。在图 3.1 中没有明确这种反馈是否可以往回延伸越过多个阶段。瀑布模型的一些最初的版本限制
5、只能反馈到过程中的前一个阶段。尽管从管理的角度这显得很有吸引力，但是看来这可能像是一个相当武断的限制。例如，如果编码暴露了该系统设计中的重大问题，完全可以想象的是这些问题本身可能严重到了需要改变分析阶段所作的工作。如果说事实上问题是在编码阶段碰巧发现的，而不是在设计审查阶段，这似乎并不是拒绝考虑对分析进行必要修改的非常有说服力的理由。总之，瀑布模型代表了一种直观的、切合实际的、通用的工程方法在软件工程中的应用。它强调在执行活动之前先进行设计的重要性，并因此提供了一种有价值的平衡，平衡软件开发中对总体体系结构或程序结构不作任何考虑就开始编码的普遍倾向。与此相关，它建议一种自顶向下的方法，由此一个
6、系统最初在一个高的抽象层次上描述，随着开发的继续增加更多的细节。最后，至少在理论上，它提供了控制软件过程的一种有力的管理工具：使用该模型，能够给予项目一个清晰的结构，在每个阶段的最后有一个里程碑，标志着该阶段的完整文档的产生并为下一阶段做好了准备。然而，实际上，瀑布模型的应用并没有真正做到它所承诺的那样，提供一种组织软件项目的方法，使得项目将会是可控制的，按时产生在预算内交付功能正确的系统。造成这种失败的两个主要原因是，该模型对项目中涉及的风险的管理的方式和模型中对系统需求的处理。3.1.1 瀑布模型中的风险管理与瀑布模型建议的相反，在软件开发中，尤其是新系统或者复杂系统的开发中，存在着高度不
7、可预知的活动。有许多软件项目失败或取消，是因为含有需要花很大代价去更正的错误或者由于性能问题而使系统不能使用，或者很简单只是因为它们不能可靠地工作。任何开发过程的一个主要目标是，寻找方法，使导致项目以彻底失败告终的风险最小化。尽管已经有很多相关工作是关于开发可证明正确的软件的技术，但在任何软件开发过程中，测试仍然是极其重要的部分。虽然远不够完美，但是，保证在合理的时间内程序做的是假定要做的事情，测试是最有效的方法，并且没有意外的副作用。在找不到其他技术的情况下，只有测试一个系统，开发者才能获得关于系统实际行为的信息，而不是计划的信息。如果系统的功能或性能存在严重问题，它们只有到测试时才会被发现
8、。在瀑布模型中，测试活动一直推迟到开发的最后一个阶段。某些测试能够早于模型建议的时间进行，比如在编码阶段，程序员可以测试他们开发的模块，但是瀑布模型建议，只有在过程中的早期阶段完成之后，才将系统作为一个整体测试。那么，就其本质而言，瀑布模型提出的过程就把项目中的多数风险推迟到开发周期将近结束时才能发现。如果测试是所知的揭露问题最有效的方法，而如果测试在很大程度上推迟到其他活动已经完成才进行，那么跟随而来的是，在根据瀑布原理进行管理的项目中，总是存在着只有在开发末期才能发现严重问题的重大风险。测试中揭露的问题决不只是由编码错误引起的。测试暴露出分析阶段是建立在错误假设的基础上，或者指导整个后续开
9、发的选择被证明是不可行的，也并非不常见。因而，潜在地，测试能够暴露一直追溯到项目一开始的问题。在最坏的情况下，这可能意味着所有后续工作都是无效的，不得不重做。在成本方面，这意味着没有实际设置修复测试中所暴露问题的成本，这当然会给软件项目管理和控制带来严重的后果。3.1.2 瀑布模型中的系统需求瀑布模型假设的是，需求获取，如同测试一样，是过程中一个独立的步骤，只不过是出现在项目一开始。并且假设它能够产生关于系统需求的明确陈述，并作为后续开发的基础。经验表明这是与实际不符的假设，并且会导致系统开发中的很多问题和失败。为什么在软件项目开始制定一个确定的需求陈述比在其他领域更困难，这看来有很多原因。首
10、先，许多软件系统的需求非常复杂，要明确地预见每种必须考虑的情况并定义合适的响应是很困难的。这意味着期望在项目开始能达成一个稳定的需求陈述，通常很不现实。其次，许多软件项目被要求适应动态的和快速变化的环境。例如，考虑正由财务公司编写的一个复杂的贸易系统。对这样一个系统的需求将会受到许多外部因素的影响，包括公司的商业惯例以及贸易所处的法律体制。在系统开发期间，作为正常经营活动的一部分，很有可能这两个因素都发生重大改变，但是这两类改变典型地都将意味着系统的需求陈述需要重大更改。最后，已经注意到，用户参与软件开发过程可能会改变他们对系统需要的是什么的感知。即使系统是按照最初的需求说明书开发的，用户也会
11、频频抱怨结果不是他们预期的或要求的。这暗含着许多原因。例如，可能是与用户商议获取原始需求的过程有问题：用户所做的假设没有明显地说明，或者譬如可能被写需求文档的人曲解了。此外，目睹一个具体系统的经历也会暗示用户，他们可能以另外的方式使用系统，这样，当系统交付时，对系统的业务需求实际上已经改变。3.2 非瀑布模型瀑布模型的两个主要问题已经确认为是项目中的风险管理和能够在项目一开始产生确定的需求陈述的假设。这两个问题，至少在理论上，都来自于瀑布模型所强调的，开发在很大程度上是一个以或多或少确定的次序执行固定的一组活动的过程。作为对这些问题的回应，产生了许多其他软件开发过程的描述，本节介绍其中的两个。
12、这些新模型提出的新观念已经被当前的过程模型所采纳，其中也包括统一过程。3.2.1 演化模型演化模型作为对瀑布模型过于严格的结构的认识的回应，提出了许多建议，认为软件应该以一种更“演化”的方式开发。典型地，这意味着开发应该从产生一个实现，也许只是模拟完整系统的一小部分核心功能的原型系统开始。然后，可以和用户讨论这个原型，用户也能够获得使用系统的第一手经验。于是，来自用户的反馈将指导后续的开发，随着在每个给定阶段小规模的功能性增量的增加以及与用户反复商讨，原型将演化为一个更完整的系统。演化方法希望通过用户参与开发过程，避免在项目结束时才发现开发的系统不是用户所需要的问题，从而克服了瀑布模型的一个缺
13、点。同样地，强调开发一系列可用的原型意味着演化中的系统从项目的早期阶段就已经被测试，使得在项目早期确定问题成为可能，并将风险分散到了生命周期的各个部分。演化模型的缺点在很大程度上与进行中的项目的管理及其可预测性有关。由于模型的特性，很难看出项目经理如何能够明智地规划一个项目，或者进行项目的工作分配。此外，该模型也没有保证演化过程实际上总是会向着一个稳定的系统汇聚，而且没有如果事实上未能如此汇聚时的应对策略。最后，演化过程也不能保证，所形成的系统的整个体系结构将会使维护活动能够有效进行，比如修复错误和实现系统的变更。3.2.2 螺旋模型螺旋模型螺旋模型的开发是为了尝试开发一个明确的软件过程，克服
14、瀑布模型的缺点，但与演化模型相比又保留了瀑布模型传统的面向管理的优点。图 3.2 说明了螺旋模型的结构。图图 3.2 螺旋模型（after Boehm，1988）螺旋模型，如同它的名字告诉我们的一样，脱离了瀑布模型提出的线性结构，而将软件开发描绘为以一系列迭代不断进展的过程，重复地修正相同的阶段和活动。项目的进展被形象化为沿着图 3.2 中的螺旋顺时针移动，从图的中心开始，在外围的一个点结束，项目完成。图 3.2 中虚线箭头表示了该模型的两个主要方面。距中心的距离指出项目到一个确定的点所需要的成本。图 3.2 是解释性的图，其中将成本表示为按恒定的速度增长，但描绘实际项目的螺旋将不是这么规则的
15、结构。从开始点渐增的角位移显示了自项目一开始所经过的时间，同样，这不是一个线性的度量，而是每完成旋转一圈表示项目的一次单独迭代，但不同的迭代将包含不同的活动，并且不会消耗同样的时间。图中的四个象限表示在每次迭代中应该保证模型提出的四个主要活动。每次迭代从左上象限开始，考虑本次迭代的目标，各种应该考虑的可选的解决方案，以及开发解决方案必须遵守的约束。一旦确定了这些，如第二个象限所示，就进行风险分析。这样做的目的是保证对项目每次迭代集中于形成威胁的最高风险。跟在风险分析之后，在提交到具体开发之前，应该先构造原型，以帮助评估解决风险的可能方法。一旦当前的风险已经被确认和解决，每次迭代接着是一个产品的
16、开发和验证阶段。这个阶段可能由不同的活动组成，这取决于项目到达的时期。图 3.2 显示了随后的迭代遵循一个传统的轨迹，从需求到分析到编码，但是这个顺序不是螺旋模型的必备特征。每个开发阶段包括一个验证步骤，例如测试该阶段所写的代码。最后，每次迭代都以对本次迭代中所做工作的评审结束，同时制定随后的迭代计划。螺旋模型主要的创新在于，它提出了开发应当被作为正规的一系列迭代来组织，每次迭代包含对项目风险的明确考虑，并且该次迭代中所做的工作的意图就是要解决所认识到的最大的风险。根据项目的种类，风险可能各种各样，并且也不局限于可能的技术问题，类似进度安排和预算控制等因素也是风险的重要来源。由此可以得出结论，螺旋模型没有像瀑布模型那样以简单的方式提出一个单程的确定的过程模型。而是提出项目计划编制的进行应该贯穿于项目的生命期，而且经理必须准备好按照进度和发现的风险随时修改计划。根据影响给定项目的风险的种类，在某些情况下螺旋模型可能看来与其他过程模型类似。例如，如果对一个特殊的项目，与需求获取相关的风险较低，但项目管理被认为是较大的风险，那么应用于该项目的螺旋模型可能和瀑布模型非常接近。然而，如果最大的
