第3章 软件开发过程

h2 { margin-top: 0.46cm; margin-bottom: 0.46cm; line-height: 173%; page-break-inside: avoid; }h2.western { font-family: "Arial",sans-serif; font-size: 16pt; }h2.cjk { font-family: "黑体","SimHei"; font-size: 16pt; font-style: normal; }h2.ctl { font-family: "DejaVu Sans"; font-size: 16pt; }h3 { margin-top: 0.46cm; margin-bottom: 0.46cm; line-height: 173%; page-break-inside: avoid; }h3.western { font-family: "DejaVu Serif",serif; font-size: 16pt; }h3.cjk { font-family: "DejaVu Sans"; font-size: 16pt; font-style: normal; }h3.ctl { font-family: "DejaVu Sans"; font-size: 16pt; }h4 { margin-top: 0.49cm; margin-bottom: 0.51cm; line-height: 156%; page-break-inside: avoid; }h4.western { font-family: "Arial",sans-serif; font-size: 14pt; }h4.cjk { font-family: "黑体","SimHei"; font-size: 14pt; font-style: normal; }h4.ctl { font-family: "DejaVu Sans"; font-size: 14pt; }p { margin-bottom: 0.21cm; }

第
3
章
软件开发过程

如在第一章所讨论的，每种软件开发方法学都包括两个主要构成部分，即软件开发活动实施过程的描述和对该过程的结果进行文档化的表示法。并且强调了UML
是一种语言而不是方法学，也不是为支持任何特殊过程而专门设计的。UML
定义的图和表示法可以成功地用于各式各样的不同过程。

本章描述有关软件开发过程的一些思想的发展，从第一个广为人知的过程模型开始，以对统一过程的简要描述结束。尽管几乎可以肯定地说，统一过程不是过程建模的最终结论，但是将统一过程和UML
结合起来考虑很有意义，因为二者是由同一组研究人员开发的。本章将以讨论统一过程所强调的不同UML
图之间的逻辑关系而结束。

3.1

瀑布模型

定义一个软件开发过程的早期尝试，主要是以从其他工程学科获得的思想为基础，把这些思想应用于这个新的领域。关键的思想是标识在生产软件中涉及的不同的活动，例如设计、编码和测试，并定义应当以怎样的次序实施这些活动。这导致了过程模型的产生，例如经典的“瀑布”模型，见图3.1
。

图3.1
瀑布模型（Royce,1970
）

虽然这些阶段的确切数目和命名在瀑布模型的不同版本中不尽相同，但是在所有版本中，这个过程总是系统地从高层开始，说明性地描述系统应当做什么，经由详细描述，最终是用代码详细描述系统将如何做，最后，以系统部署和后续运行所涉及的活动的一些阶段的描述而结束。

因此，大多数瀑布模型提供的是软件系统的整个生命周期的一个模型，而不仅仅是软件系统的开发模型。但是，系统的开发构成了模型的很大一部分，无疑地，也是在软件工程文献中受到最多注意的部分。

瀑布模型中的每个阶段定义一个各自独立的活动。瀑布中连续的阶段通过箭头连接，向下的箭头表示阶段的时间次序。因此，模型的基本结构暗示了不同的阶段是依顺序进行的。所设想的过程并不是像建造一所房子那样，电工、水工、屋顶工等等可能同时工作，而是更像一条生产线，比如，分析人员完成他们的工作，接着将产品移交给设计人员进行下一个阶段的工作。这个模型中隐含的是，期望每个阶段完成的工作都以某种方式形成文档，而且该文档将被传递下去，并成为下一阶段要做的工作的基础。

因此，瀑布模型提出了软件开发的一种理想化的构想，项目将从文档化需求开始，经历分析和设计活动，接着是编码和测试系统。在部署之后，只要它还在使用，系统将被维护。这种经过这些阶段的工作流是将这类模型命名为“瀑布”的缘由。

当然，实际上，以这样一种没有疑问的方式开发的项目很少。更典型地是，一个阶段中的工作将暴露前面阶段所做的工作中的问题、错误和遗漏。显然，在继续之前纠正问题是明智的，而不是在有错误的工作的基础上前进。图中向上的箭头表示了这种反馈过程，由此在一个阶段做的工作可能引起前面阶段的修改和返工。

在图3.1
中没有明确这种反馈是否可以往回延伸越过多个阶段。瀑布模型的一些最初的版本限制只能反馈到过程中的前一个阶段。尽管从管理的角度这显得很有吸引力，但是看来这可能像是一个相当武断的限制。例如，如果编码暴露了该系统设计中的重大问题，完全可以想象的是这些问题本身可能严重到了需要改变分析阶段所作的工作。如果说事实上问题是在编码阶段碰巧发现的，而不是在设计审查阶段，这似乎并不是拒绝考虑对分析进行必要修改的非常有说服力的理由。

总之，瀑布模型代表了一种直观的、切合实际的、通用的工程方法在软件工程中的应用。它强调在执行活动之前先进行设计的重要性，并因此提供了一种有价值的平衡，平衡软件开发中对总体体系结构或程序结构不作任何考虑就开始编码的普遍倾向。与此相关，它建议一种自顶向下的方法，由此一个系统最初在一个高的抽象层次上描述，随着开发的继续增加更多的细节。最后，至少在理论上，它提供了控制软件过程的一种有力的管理工具：使用该模型，能够给予项目一个清晰的结构，在每个阶段的最后有一个里程碑，标志着该阶段的完整文档的产生并为下一阶段做好了准备。

然而，实际上，瀑布模型的应用并没有真正做到它所承诺的那样，提供一种组织软件项目的方法，使得项目将会是可控制的，按时产生在预算内交付功能正确的系统。造成这种失败的两个主要原因是，该模型对项目中涉及的风险的管理的方式和模型中对系统需求的处理。

3.1.1
瀑布模型中的风险管理

与瀑布模型建议的相反，在软件开发中，尤其是新系统或者复杂系统的开发中，存在着高度不可预知的活动。有许多软件项目失败或取消，是因为含有需要花很大代价去更正的错误或者由于性能问题而使系统不能使用，或者很简单只是因为它们不能可靠地工作。任何开发过程的一个主要目标是，寻找方法，使导致项目以彻底失败告终的风险最小化。

尽管已经有很多相关工作是关于开发可证明正确的软件的技术，但在任何软件开发过程中，测试仍然是极其重要的部分。虽然远不够完美，但是，保证在合理的时间内程序做的是假定要做的事情，测试是最有效的方法，并且没有意外的副作用。

在找不到其他技术的情况下，只有测试一个系统，开发者才能获得关于系统实际行为的信息，而不是计划的信息。如果系统的功能或性能存在严重问题，它们只有到测试时才会被发现。

在瀑布模型中，测试活动一直推迟到开发的最后一个阶段。某些测试能够早于模型建议的时间进行，比如在编码阶段，程序员可以测试他们开发的模块，但是瀑布模型建议，只有在过程中的早期阶段完成之后，才将系统作为一个整体测试。

那么，就其本质而言，瀑布模型提出的过程就把项目中的多数风险推迟到开发周期将近结束时才能发现。如果测试是所知的揭露问题最有效的方法，而如果测试在很大程度上推迟到其他活动已经完成才进行，那么跟随而来的是，在根据瀑布原理进行管理的项目中，总是存在着只有在开发末期才能发现严重问题的重大风险
。

测试中揭露的问题决不只是由编码错误引起的。测试暴露出分析阶段是建立在错误假设的基础上，或者指导整个后续开发的选择被证明是不可行的，也并非不常见。

因而，潜在地，测试能够暴露一直追溯到项目一开始的问题。在最坏的情况下，这可能意味着所有后续工作都是无效的，不得不重做。在成本方面，这意味着没有实际设置修复测试中所暴露问题的成本，这当然会给软件项目管理和控制带来严重的后果。

3.1.2
瀑布模型中的系统需求

瀑布模型假设的是，需求获取，如同测试一样，是过程中一个独立的步骤，只不过是出现在项目一开始。并且假设它能够产生关于系统需求的明确陈述，并作为后续开发的基础。经验表明这是与实际不符的假设，并且会导致系统开发中的很多问题和失败。

为什么在软件项目开始制定一个确定的需求陈述比在其他领域更困难，这看来有很多原因。首先，许多软件系统的需求非常复杂，要明确地预见每种必须考虑的情况并定义合适的响应是很困难的。这意味着期望在项目开始能达成一个稳定的需求陈述，通常很不现实。

其次，许多软件项目被要求适应动态的和快速变化的环境。例如，考虑正由财务公司编写的一个复杂的贸易系统。对这样一个系统的需求将会受到许多外部因素的影响，包括公司的商业惯例以及贸易所处的法律体制。在系统开发期间，作为正常经营活动的一部分，很有可能这两个因素都发生重大改变，但是这两类改变典型地都将意味着系统的需求陈述需要重大更改。

最后，已经注意到，用户参与软件开发过程可能会改变他们对系统需要的是什么的感知。即使系统是按照最初的需求说明书开发的，用户也会频频抱怨结果不是他们预期的或要求的。这暗含着许多原因。例如，可能是与用户商议获取原始需求的过程有问题：用户所做的假设没有明显地说明，或者譬如可能被写需求文档的人曲解了。此外，目睹一个具体系统的经历也会暗示用户，他们可能以另外的方式使用系统，这样，当系统交付时，对系统的业务需求实际上已经改变。

3.2
非瀑布模型

瀑布模型的两个主要问题已经确认为是项目中的风险管理和能够在项目一开始产生确定的需求陈述的假设。这两个问题，至少在理论上，都来自于瀑布模型所强调的，开发在很大程度上是一个以或多或少确定的次序执行固定的一组活动的过程。

作为对这些问题的回应，产生了许多其他软件开发过程的描述，本节介绍其中的两个。这些新模型提出的新观念已经被当前的过程模型所采纳，其中也包括统一过程。

3.2.1
演化模型

作为对瀑布模型过于严格的结构的认识的回应，提出了许多建议，认为软件应该以一种更“演化”的方式开发。典型地，这意味着开发应该从产生一个实现，也许只是模拟完整系统的一小部分核心功能的原型系统开始。

然后，可以和用户讨论这个原型，用户也能够获得使用系统的第一手经验。于是，来自用户的反馈将指导后续的开发，随着在每个给定阶段小规模的功能性增量的增加以及与用户反复商讨，原型将演化为一个更完整的系统。

演化方法希望通过用户参与开发过程，避免在项目结束时才发现开发的系统不是用户所需要的问题，从而克服了瀑布模型的一个缺点。同样地，强调开发一系列可用的原型意味着演化中的系统从项目的早期阶段就已经被测试，使得在项目早期确定问题成为可能，并将风险分散到了生命周期的各个部分。

演化模型的缺点在很大程度上与进行中的项目的管理及其可预测性有关。由于模型的特性，很难看出项目经理如何能够明智地规划一个项目
，或者进行项目的工作分配。此外，该模型也没有保证演化过程实际上总是会向着一个稳定的系统汇聚
，而且没有如果事实上未能如此汇聚时的应对策略。最后，演化过程也不能保证，所形成的系统的整个体系结构将会使维护活动能够有效进行，
比如修复错误和实现系统的变更。

3.2.2
螺旋模型

螺旋模型的开发是为了尝试开发一个明确的软件过程，克服瀑布模型的缺点，但与演化模型相比又保留了瀑布模型传统的面向管理的优点。图3.2
说明了螺旋模型的结构。

图
3.2

螺旋模型（after
Boehm
，1988
）

螺旋模型，如同它的名字告诉我们的一样，脱离了瀑布模型提出的线性结构，而将软件开发描绘为以一系列
迭代

不断进展的过程，重复地修正相同的阶段和活动
。项目的进展被形象化为沿着图3.2
中的螺旋顺时针移动，从图的中心开始，在外围的一个点结束，项目完成。

图3.2
中虚线箭头表示了该模型的两个主要方面。距中心的距离指出项目到一个确定的点所需要的成本。图3.2
是解释性的图，其中将成本表示为按恒定的速度增长，但描绘实际项目的螺旋将不是这么规则的结构。

从开始点渐增的角位移显示了自项目一开始所经过的时间，同样，这不是一个线性的度量，而是每完成旋转一圈表示项目的一次单独迭代，但不同的迭代将包含不同的活动，并且不会消耗同样的时间。

图中的四个象限表示在每次迭代中应该保证模型提出的四个主要活动。每次迭代从左上象限开始，考虑本次迭代的目标
，各种应该考虑的可选的解决方案，以及开发解决方案必须遵守的约束。一旦确定了这些，如第二个象限所示，就进行风险分析
。这样做的目的是保证对项目每次迭代集中于形成威胁的最高风险
。跟在风险分析之后，在提交到具体开发之前
，应该先构造原型，以帮助评估解决风险的可能方法
。

一旦当前的风险已经被确认和解决，每次迭代接着是一个产品的开发和验证
阶段。这个阶段可能由不同的活动组成，这取决于项目到达的时期。图3.2
显示了随后的迭代遵循一个传统的轨迹，从需求到分析到编码，但是这个顺序不是螺旋模型的必备特征。每个开发阶段包括一个验证步骤，例如测试该阶段所写的代码。

最后，每次迭代都以对本次迭代中所做工作的评审
结束，同时制定随后的迭代计划。

螺旋模型主要的创新在于，它提出了开发应当被作为正规的一系列
迭代

来组织，每次迭代包含对项目风险的明确考虑，并且该次迭代中所做的工作的意图就是要解决所认识到的最大的风险。
根据项目的种类，风险可能各种各样，并且也不局限于可能的技术问题，类似进度安排和预算控制等因素也是风险的重要来源。

由此可以得出结论，螺旋模型没有像瀑布模型那样以简单的方式提出一个单程的确定的过程模型。而是提出项目计划编制的进行应该贯穿于项目的生命期，而且经理必须准备好按照进度和发现的风险随时修改计划。

根据影响给定项目的风险的种类，在某些情况下螺旋模型可能看来与其他过程模型类似。例如，如果对一个特殊的项目，与需求获取相关的风险较低，但项目管理被认为是较大的风险，那么应用于该项目的螺旋模型可能和瀑布模型非常接近。然而，如果最大的风险在于开发一个复杂的新的用户界面，螺旋模型最终将类似于一种演化的方法，因为需要尽快开发能够尽可能由用户测试的可操作的代码。

最后，值得注意的是瀑布模型和螺旋模型之间的另一层关系。如图3.2
所示，螺旋模型中单个迭代自身可能遵循的一系列阶段会让人联想到瀑布模型。

3.2.3

迭代和增量开发

演化模型和螺旋模型确定了一个改进的软件开发过程应该具有的两个重要特性。第一，软件开发应该增量地

进行：与其把完成整个系统开发的全部工作集中在一次冲刺中进行，不如首先开发核心功能，得到一个虽然是有限的但是能够运行的工作的系统，然后再以一系列增量的方式逐部地增加剩余的功能。

这种方法的优点是在项目生命周期的早期就产生可以运行的代码，除了通过示范论证项目的可行性降低了风险之外，还解决了需求说明的问题。用户能够获得对运行系统的体验，并用这样的体验对随后的开发反馈修改和建议。

第二，螺旋模型提出软件过程应该被作为一系列迭代

管理，而不是一次性地经过瀑布模型确定的各种活动。尽管原本的螺旋模型明确地作为管理项目中风险的一种方法被提出，但它也能够解决管理需求变化的问题：如果需求变化被确定为是一个重大风险，迭代将包含构造一个合适的原型，以引出来自用户的反馈。

当前的过程模型试图把增量和迭代开发的优点与瀑布模型提供的传统的过程结构结合起来，如今最著名的这类模型是统一软件开发过程（Unified
Software Development Process
），将在下一节中讨论。

3.3

统一过程

为了利用从软件开发的历史中所学到的东西，软件过程不得不寻求一种方法来集成初看上去相当矛盾的两种理解。尽管对瀑布模型有一些批评，但是它对软件开发中包含的不同活动的确认，以及每个活动产生的特有的制品，
仍被广泛采用。例如在编码开始之前进行的需求分析和设计活动似乎具有永恒的价值。

但是，这些活动应该如何适合一个迭代和增量的过程
并不清楚。在这些方法强调及早产生代码的情况下，它们似乎没有为独立的分析和设计活动留下多少空间。

统一过程试图用图3.3
所示的开发过程的整体模型来调和这两方面的影响。在图3.3
中，时间流从左到右，项目通过一些阶段和迭代而进展。图中的垂直轴表示了一个有些像传统的开发活动列表，或以统一过程的术语称为工作流
（workflows

）。这个图中最值得注意的思想，对应于每个工作流的阴影区指示的，是每个活动可能在任何迭代中发生，但是在一次迭代中这些活动的比例的协调将会随着项目从开始到完成的进展而变更。

图
3.3


统一过程概览 (Jacobson
等.
,
1999)

这四个阶段均以里程碑
（milestones

）结束，在图中没有表示出来，里程碑的意图是捕捉项目生命周期中的点，在这些点上可能进行重大的管理决策和进展评估。初始阶段主要关注项目计划和风险评估。细化阶段关心定义系统的总体架构。构造阶段是建立系统，以一个能够交付给客户进行β
测试的版本结束。移交阶段包含了β
测试时期，以发布完整的系统而终止。

每个阶段中可能有不同次数的迭代。如图所表明的，一次迭代一般将被组织为一个小的瀑布过程。一次迭代应该导致对所构造产品的一个增量的改进。

通常，尤其是接近项目结束时，每次迭代将会产生一个已经完全实现的功能性的增量，但是也可能是其他结果。例如，导致对系统体系结构的一些方面修改的一次迭代，如果它意味着后续的迭代能够更有效地进行，那么将会非常有价值。

3.4
模型在开发中的作用

统一过程认为，模型的使用在任何软件开发活动中都有重要作用。模型用在各种工作流所包含的不同的详细级别上，建立演化系统的文档。统一过程是和UML
一起开发的，它包括非常明确的建议，说明如何使用和在什么情况下能够使用各种UML
图，以支持每个工作流中包含的活动。

3.5
节描述了统一过程认定的各种UML
图之间的关系。即使没有使用这个完整的过程，这些关系对于如何最佳地使用UML
建立开发的文档，也提供了很有价值的观点。但是，在仔细考虑各种UML
图之间的关系之前，简单考虑一下在软件开发中使用模型的其他观点是值得的。

在3.2
节中简要讨论的演化过程很少使用软件模型，而是更多集中于系统代码的开发，并且在某些情况下极力地反对使用软件模型。这样的思考方法最近被极限编程（XP
）运动再次承接。如同较早的演化模型，XP
把自己视为在软件开发中广泛使用模型的过程和清楚划分过程的反对者。但是XP
的这两个方面是独立的，值得分别考虑。

模型的传统使用是，在编码之前产生模型，然后依照模型中包含的概要来编写代码。后续的开发，即在后面的迭代中，应该从更新模型开始，然后继续以一种有秩序的方式根据模型再更新代码。显然，这个过程只有在模型和代码保持一致
时才会有用。

但是，一种典型的情景是在一次迭代的编码时，编程人员会根据他们的经验，在实现时以或多或少有意义的方式来修改设计。在这种情况下设计模型很少会和代码保持一致，结果是在下一次迭代开始时设计模型和代码不一致，因而不能保证对设计的修改能够有效地应用到代码。

这对开发团队是一个现实问题。一种回答是强调
双向工程

（round-trip
engineering

）的概念。这个概念建议应该开发工具，该工具能够使设计和代码保持一致，并且随着项目的发展共同演化。另一种回答是XP
和相关方法提议的，通过只维护一套文档
来消除这个问题，因为源代码是任何开发的基本产品，XP
建议所有的工作都应该只是在代码上进行。如果团队认为模型的使用有帮助，那么在迭代中可以使用模型，但是它们不保留，并且不构成系统永久文档的一部分。

因此，在软件开发的基于模型的描述和另一种只集中注意于代码的描述之间存在一个重大的鸿沟，这两种倾向从多年以来的软件开发方面的著述中可以得到确认。

另一方面，在统一过程和XP
之间也有很多类似之处。例如，二者都强调将开发建立在需求陈述
基础上的重要性，这种需求陈述是围绕着用户使用系统执行的任务的描述进行组织的。这些陈述在UML
中被称为用例
（use
cases

），在XP
中称为情节
（stories

）。二者显然都是迭代的和增量
的方法，并建议尽可能早地实现和测试核心功能
。二者都确认，随着加入更多的增量，系统的设计可能需要完全出人意料的演化，在XP
中这一过程称为重构（refactoring

）。

XP
明确地是针对小型到中型的开发。通常提到的大约是十个人的团队，而且XP
的核心是一组工作经验，例如结对编程、在编码之前开发自动化的测试用例和非常频繁的产品集成，这些可以在一个小的、有凝聚力团队的环境中采用。对比之下，统一过程声称适用于各种规模的项目，并且对这类项目自顶向下的全面管理有更多表述。

3.5
UML

在统一过程中的运用

统一过程考虑了各种UML
图在一个开发项目环境中的典型使用，在UML
图之间存在着的某些关系是逻辑上的必然结果，即使将这些图独立地用于一个结构化过程时，也值得记住这些关系。本节将讨论和概述这些关系并将应用于后续章节的案例开发中。

3.5.1

需求

统一过程非常强调通过用例来捕获系统需求。UML
支持这一过程的略图在图3.4
中给出。

图
3.4


用UML
捕获需求

在UML
用例模型中捕获和记录的是系统的用例和参与者以及它们之间的关系。这通常是受到领域模型
（domain
model

）的支持，即把重要的业务概念及其关系文档化了的简单类图。领域模型的重要性在于，它确定了书写用例描述所使用的术语，并为消除这些描述中的不明确和不清楚提供了可能。通常，它也有助于产生列出和定义系统中关键词语的词汇表
（glossary

）。

然而，需求文档中最重要的部分是用例的文本描述，系统功能的重要细节在这里考虑并形成文档。但是UML
没有定义用例描述的标准形式，所以对一个项目来说，定义用于书写这些的模板是必要的。已经逐渐形成了许多不同的模板，在第4.3
节将对用例描述可能的内容进行详细讨论。

3.5.2

用例驱动的过程

统一过程被描述为“用例驱动”的过程，这就意味着在统一过程后面的各个阶段要系统地
使用用例。在分析和设计中对用例的主要使用如图3.5
所示。

图
3.5


使用用例进行实化和细化

这里最重要的活动是用例的
实化

（realization

）。实化是用例的高层实现，用UML
交互图
表示。它表示了系统如何将用例的功能作为对象之间的一系列交互来提供。实化中的对象来自领域模型中定义的类。

领域模型自然不会定义实化用例所需要的一切。实化一般揭示了对添加的类和重新确定类之间关系的需要，并强制设计人员更详细地指定支持交互所需要的属性和操作。这个细化
（refinement

）过程把最初的领域模型发展成为一个更全面的类图，其中包含了足够的细节以形成实现的基础。

这里重要的一点是，类模型的开发不是孤立地进行的，对类模型需要做出的修改完全是由实化用例的过程推动
的。这意味着，类图是以这种使设计人员能够确信，详细指定的类实际上将会支持所需要的功能的方式演进的。如果脱离对象交互的考虑产生复杂的类图，情况将不会是这样。

最后，以用例的实化和详细的类图为基础，可以为需要状态图的类开发出状态图
，作为那些类的实例的生命周期的文档。图3.5
概括地表示了用例模型的内容如何直接渗透到主要的UML
模型产品中。

一旦产生了图3.5
所示的模型，可以直接用这些模型来指导系统的实现，在第7
章和第13
章将更详细地研究这个过程。用例模型对开发过程的最后一个重大影响是产生系统的测试用例。
为了准备对系统的验收测试，可以从用例中系统地导出测试：能够成功执行这些用例，是系统实现了某些对用户有用的业务功能的合理保证。

3.6

小结

·

瀑布模型
把软件的开发过程设想为一个高度结构化的不同活动或阶段的序列，从需求分析开始，到测试和部署结束。
·

由于瀑布模型建议在生命周期的晚期进行测试，就将一个无法接受的风险量推迟到了项目的末尾，这时要经济地解决它通常已经太晚。
·

基于瀑布模型的项目的另一个问题是假设在项目开始就能够产生一个明确的需求陈述。
·

其他模型，例如演化
模型和螺旋
模型，尝试通过建议在软件开发中使用增量
和迭代
方法解决瀑布模型的问题。
·

当前的方法学已经采纳了这些思想，最著名的是统一过程。
·

统一过程广泛使用UML
定义的模型，这间接地表明许多关系可以用来组织系统的文档。

3.7

习题

3.1
3.1
节讨论了在软件开发晚期测试一个系统所带来的风险。这是软件工程中特有的问题，还是在工程的其他分支中也面临类似问题？设计的制品的本性中有什么会导致这成为一个问题？其他领域的工程师是如何避免这个问题的？
3.2
3.1
节中提出，如果一个软件开发过程假定能够在项目开始产生一个确定的需求陈述会有问题。这对其他工程领域也是一个同样重大的问题吗？如果是，那么在设计的制品的本性中有什么会导致这成为特定领域的一个问题？其他领域的工程师是如何避免这个问题的？
3.3

为什么螺旋模型提出每次迭代应该包含产生下次迭代计划的活动？
3.4

你能找到增量的但没有迭代的过程或者迭代而没有增量的过程的例子吗？
3.5

开放源代码开发被作为对传统开发方法的根本改变而广泛讨论，而且它能够声称例如Linux
操作系统这样的显著成功。讨论如何使用本章提出的过程概念来刻画开放源代码开发。在本书最后的参考文献部分可以找到关于开放源代码的建议阅读材料。