2.2 传统过程模型
传统过程模型又称“惯用”过程模型，最早提出是为了改变软件开发的混乱状况，使软件开发更加有序。历史证明，这些传统模型为软件工程工作增加了大量有用的结构化设计，并为软件团队提供了有效的路线图。
传统过程方法以秩序和一致性作为主要问题，之所以被称为“传统”，是因为它规定了一套过程元素——框架活动、软件工程动作、任务、工作产品、质量保证，以及每个项目的变更控制机制。每个过程模型还定义了过程流（也称为工作流，即过程元素相互之间关联的方式。所有的软件过程模型都支持通用框架活动，但是每一个模型都对框架活动有不同的侧重，并且定义了不同的过程流以不同的方式执行每一个框架活动（以及软件工程动作和任务）。
2.2.1 软件生存周期模型
软件生存周期模型（又称软件开发模型）是软件工程的一个重要概念，它可以定义为：一个框架，它含有遍历系统从确定需求到终止使用这一生存周期的软件产品的开发、运行和维护中需要实施的过程、活动和任务。
软件生存周期模型能清晰、直观地表达软件开发的全过程，明确规定了开发工作各阶段所要完成的主要活动和任务，以作为软件项目开发工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言，让掌握不同技能的人员参与工作、运用不同的管理方法和手段等，并且允许采用不同的软件工具和不同的软件工程环境。软件生存周期模型是稳定有效和普遍适用的。
在软件生存周期过程中，软件生存周期模型仅对软件的开发、运作和维护过程有意义，在信息技术国际标准ISO12207和ISO9000—3中都提到了软件生存周期模型，包括瀑布模型、增量模型、演化模型、协同模型、喷泉模型和智能模型等。
2.2.2 瀑布模型
瀑布模型（又称经典生命周期）是1970年W.Royce提出的软件生存周期开发模型（见图2-3），它将软件开发过程中的各项活动规定为依固定顺序连接的若干阶段工作，形同瀑布流水，最终得到软件系统或软件产品。换句话说，它将软件开发过程划分成若干个互相区别而又彼此联系的阶段，每个阶段中的工作都以上一个阶段工作的结果为依据，同时为下一个阶段的工作提供了前提。
图2-3 软件生存周期的瀑布模型
瀑布模型的一个变体称为V模型（见图2-4），它描述了质量保证动作，同沟通、建模相关动作及早期构建相关的动作之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质是执行了一系列测试（质量保证动作），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。实际上，经典生命周期模型和V模型没有本质区别，V模型提供了一种将验证确认动作应用于早期软件工程工作中的方法。
瀑布模型是软件工程最早的范例，但是，也一直存在着对这一过程模型的批评。在运用瀑布模型的过程中，人们遇到的问题包括以下几个。
1）实际的项目很少遵守瀑布模型提出的顺序。虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果是，随着项目的推进，变更可能造成混乱。
2）客户通常难以清楚地描述所有的需求。而瀑布模型却需要客户明确需求，因此很难适应在许多项目开始阶段必然存在的不确定性。
3）客户必须有耐心，因为只有在项目接近尾声时，他们才能得到可执行的程序。对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能损失惨重。
图2-4 V模型
研究发现，经典生命周期模型的线性特性在某些项目中会导致“阻塞状态”，这是由于任务之间的依赖性，开发团队的一些成员要等待另一些成员完成工作。事实上，花在等待上的时间可能超过花在生产性工作上的时间。在线性过程的开始和结束阶段，这种阻塞状态更容易发生。
软件工作快速进展，经常面临永不停止的特性、功能和信息内容等变化流，瀑布模型往往并不适合这类工作。尽管如此，当需求确定、工作采用线性的方式完成的时候，瀑布模型是一个很有用的过程模型。
2.2.3 增量模型
在许多情况下，初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。在这种条件下，需要选用一种以增量的形式生产软件产品的过程模型。
增量模型（又称渐增模型）综合了线性过程流和并行过程流的特征。如图2-5所示，随着时间的推移，增量模型在每个阶段运用线性序列。每个线性序列以一种演化过程流生产增量类似的方式生产出一个软件的可交付增量。
图2-5 增量模型
例如，采用增量模型开发的文字处理软件，在第一个增量中提供基本的文件管理、编辑和文档生成功能；在第二个增量中提供复杂的编辑和文档生成功能；在第三个增量中提供拼写和语法检查功能；在第四个增量中提供高级页面排版功能。需要注意的是，任何增量的过程流都可能使用原型模型。运用增量模型时，第一个增量往往是核心产品。也就是说，满足了基本的需求，但是许多附加的特性（一些是已知的，一些是未知的）没有提供，客户使用该核心产品进行仔细评价，并根据评价结果制订下一个增量计划。这份计划说明了需要对核心产品进行的修改，以便更好地满足客户的要求，也说明了需要增加的特性和功能。每一个增量的交付都会重复这一过程，直到最终产品的产生。
增量模型侧重于每个增量都提交一个可以运行的产品。早期的增量可以看做是最终产品的片段版本，但是它们确实具备了用户服务能力，也为用户的评价提供了一个平台。
如果在项目既定的商业期限之前不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增量可以由少量的人员实现。如果核心产品的口碑不错，可以为下一个增量投入更多的人力。同时，增量模型可以规避技术风险。例如，一个系统需要利用某个正在开发的新硬件，而这个新硬件的交付日期不确定。因此，可以在早期的增量中避免使用这个硬件，这样可以保证部分功能按时交付给最终用户，不至于造成过分的延期。
在评价该模型时，需要考虑的风险因素有以下几个。
●需求未被很好地理解。
●突然提出一些功能。
●事先打算采用的技术迅速发生变化。
●需求迅速发生变化。
●长时期内仅有有限的资源保证（工作人员/资金）。
2.2.4 演化模型
类似于其他复杂的系统，软件会随着时间的推移而演化。在开发过程中，商业和产品需求经常发生变化，直接导致最终产品难以实现；严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；有时很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。
演化模型（又称进化模型，见图2-6）是迭代的过程模型，通过构造系统的各个可执行的中间版本来开发系统，但是，与增量模型的区别是，承认需求不能被完全了解，且不能在初始时就确定。在该模型中，需求一部分被预先定义，然后在每个相继的中间版本中逐步完善。在该模型中，每个中间版本在开发时，开发过程中的活动和任务顺序地或部分重叠平行地被采用，使得软件开发人员能够逐步开发出更完整的软件版本。
对所有的中间版本，开发过程中的活动和任务通常按同一顺序被重复使用。维护过程和运作过程可以与开发过程平行地使用。获取过程、供应过程、支持过程和组织过程通常与开发过程平行地使用。下面是两种常用的演化过程模型。
1）原型开发。很多时候，客户提出了软件的一些基本功能，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定。在类似情况下，采用原型开发范型是最好的解决办法。
图2-6 演化模型示意
虽然原型可以作为一个独立的过程模型，但是更多的时候是作为一种技术，在其他过程模型中应用。不论人们以什么方式运用它，当需求很模糊时，原型开发模型可帮助软件开发人员和干系人更好地理解究竟需要做什么。
原型开发始于沟通。软件开发人员和干系人进行会晤，定义软件的整体目标，明确已知的需求，并大致勾画出以后进一步定义的东西。然后，迅速策划一个原型开发迭代并进行建模（以快速设计的方式）。快速设计要集中到那些最终用户能够看到的方面，比如人机接口布局或者输出显示格式。快速设计产生了一个原型。对原型进行部署，然后由干系人进行评价。根据干系人的反馈信息，进一步细化软件的需求。在原型系统不断调整以满足各种干系人需求的过程中，采用迭代技术，同时也使开发者逐步清楚用户的需求。
理想状况下，原型系统提供了定义软件需求的一种机制。当需要构建可执行的原型系统时，软件开发人员可以利用已有的程序片段或应用工具（如报告生成器和窗口管理器），快速产生可执行的程序。
在大多数项目中，构建的第一个系统很少是好用的，可能太慢了，太大了，很难使用，或者同时具备上述三点。除了重新开始，没有更好的选择。采用更巧妙的方法是构建一个重新设计的版本，解决上述问题。
尽管许多原型系统是临时系统，会被废弃，而其他一些原型系统将会慢慢演化为实际系统。干系人和软件工程师确实都喜欢原型开发模型。客户对实际的系统有了直观的认识，开发者也迅速建立了一些东西。但是，原型开发也存在一些问题，列举如下。
①干系人看到了软件的工作版本，却未察觉到整个软件是随意搭成的，也未察觉到为了尽快完成软件，开发者没有考虑整体软件质量和长期的可维护性。当开发者告诉客户整个系统需要重建以提高软件质量时，干系人会不愿意，并且要求对软件稍加修改使其变为一个可运行的产品。因此，软件开发管理往往陷入失效。
②软件开发人员为了使一个原型快速运行起来，往往在实现过程中采用折中的手段。他们经常会使用不合适的操作系统或程序设计语言，仅仅因为当时可用和熟悉。他们也经常会采用一种低效的算法，仅为了证明系统的能力。时间长了，软件开发人员可能会适应这些选择，而忽略了这些选择其实并不合适的理由，结果造成并不完美的选择变成了系统的组成部分的情况。
尽管问题经常发生，原型开发对于软件工程来说仍是一个有效的模型。关键是要在游戏开始的时候制定规则，也就是说，所有干系人必须承认原型是为定义需求服务的。然后丢弃原型（至少是部分丢弃），实际的软件系统是以质量第一为目标开发的。
2）螺旋模型。最早由Boehm提出，是一种风险驱动型的演进式软件过程模型。它结合了原型的迭代性质，以及瀑布模型的系统性和可控性特点，具有快速开发越来越完善软件版本的潜力。Boehm这样描述螺旋模型：对于软件集中的系统，螺旋模型可以指导多个干系人协同工作。它有两个显著的特点：一是采用循环的方式逐步加深系统定义和实现的深度，同时降低风险；二是确定一系列里程碑，确保干系人都支持可行的和令人满意的系统解决方案。
运用螺旋模型，把软件开发为一系列演进版本。在早期的迭代中，软件可能是一个理论模型或原型。在后来的迭代中，会产生一系列逐渐完整的系统版本。
螺旋模型被分割成一系列由软件工程团队定义的框架活动。如图2-7所示，每个框架活动代表螺旋上的一个片段。随着演进过程开始，从圆心开始顺时针方向，软件团队执行螺旋上的一圈表示的活动。在每次演进时，都要考虑风险。每个演进过程还要标记里程碑——沿着螺旋路径达到的工作产品和条件的结合体。
图2-7 典型的螺旋模型
螺旋的第一圈一般开发出产品的规格说明，接下来开发产品的原型系统，并在每次迭代中逐步完善，开发不同的软件版本。螺旋的每一圈都会跨过策划区域，此时，需要调整项目计划，并根据交付后用户的反馈调整预算和进度。另外，还需要调整完成软件开发的迭代次数。
其他过程模型当软件交付后就结束了，螺旋模型则不同，它应用在计算机软件的整个生命周期。因此，螺旋上的第一圈可能表示“概念开发项目”，它起始于螺旋的中心，经过多个迭代（沿轴指向中心的箭头区分开了部署和沟通两个区域，表明沿同一个螺旋路径存在潜在的局部迭代），直到概念开发的结束。如果这个概念将被开发成为实际的产品，过程模型将继续沿着螺旋向外伸展，此时称为“新产品开发项目”。新产品可能沿着螺旋通过一系列的迭代不断演进。最后，可以用一圈螺旋表示“产品提高项目”。本质上，当螺旋模型以这种方式进行下去的时候，它将永远保持可操作性，直到软件产品的生命周期结束。过程经常会处于休止状态，但每当有变更时，过程总能够在合适的入口点启动（如产品提高）。
螺旋模型是开发大型系统和软件的理想方法。由于软件随着过程的推进而变化，在每一个演进层次上，开发者和客户都可以更好地理解和应对风险。螺旋模型把原型作为降低风险的机制，更重要的是，开发人员可以在产品演进的任何阶段使用原型方法。它保留了经典生命周期模型中系统逐步细化的方法，但是把它纳入一种迭代框架之中，这种迭代方式与真实世界更加吻合。螺旋模型要求在项目的所有阶段始终考虑技术风险，如果适当地应用该方法，则能够在风险变为问题之前化解风险。
现代计算机软件总是在持续改变，这些变更通常要求在非常短的期限内实现，并且要充分满足用户的要求。许多情况下，及时投入市场是最重要的管理要求。如果市场时间错过了，软件项目自身可能会变得毫无意义。
演化模型的初衷是采用迭代或者增量的方式开发高质量软件。可是，用演化模型也可以做到强调灵活性、可延展性和开发速度。软件团队及其经理所面临的挑战就是在这些严格的项目和产品参数与客户（软件质量的最终仲裁者）满意度之间找到一个合理的平衡点。
2.2.5 协同模型
协同开发模型有时候也称为协同工程，它允许软件团队表述任何模型中的迭代和并发元素。例如，螺旋模型定义的建模活动由一种或几种软件工程动作完成：原型开发、分析及设计。
对于协同模型方法中建模活动的某一软件工程活动，图2-8给出了一种描述。在某一特定时间，建模活动可能处于图中所示的任何一种状态中。其他活动、动作或任务（如沟通或构建）可以用类似的方式表示。所有的软件工程活动同时存在并处于不同的状态。
图2-8 协同过程模型的一种描述
例如，在项目的早期，沟通活动（图2-8中并未标明）完成了第一个迭代，停留在等待变更状态。初始沟通完成后，建模活动一直停留在非活动状态，现在转换到正在开发状态。如果客户要求必须完成需求变更，则建模活动从正在开发状态转换到等待变更状态。
协同模型定义了一系列事件，这些事件将触发软件工程活动、动作或者任务的状态转换。例如，设计的早期阶段（建模活动期间发生的主要软件工程动作）发现了需求模型中的不一致性，于是产生了分析模型修正事件，该事件将触发需求分析动作从完成状态转换到等待变更状态。
协同过程模型可用于所有类型的软件开发，能够提供精确的项目当前状态图。它不是把软件工程活动、动作和任务局限在一个事件的序列，而是定义了一个过程网络。网络上每个活动、行为和任务与其他活动、行为和任务同时存在。过程网络中某一点产生的事件可以触发状态的转换。
2.2.6 喷泉模型
喷泉模型是由B.H.So11ers和J.M.Edwards于1990年提出的一种开发模型，主要用于采用面向对象技术的软件开发项目，“喷泉”一词本身就体现了迭代和无间隙的特性。软件的某个部分常常重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分（见图2-9）。
图2-9 喷泉模型
无间隙是指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限。由于对象概念的引入，表达分析、设计和实现等活动只用对象类和关系，从而可以较为容易地实现活动的选代和无间隙，使其开发自然地包括复用。
2.2.7 智能模型
智能模型也称为基于知识的软件开发模型，它是知识工程与软件工程在开发模型上结合的产物，它有别于上述5种开发模型。
图2-10表示了智能模型与其他模型的不同，它的维护并不在程序一级上进行，这样就大大降低了问题的复杂性，从而可以把精力更加集中于具体描述的表达上，即维护在功能规约一级进行。具体描述可以使用形式功能规约，也可以使用知识处理语言描述等，因而必须将规则和推理机制应用到开发模型中，所以必须建立知识库，将模型本身、软件工程知识和特定领域的知识分别存入知识库，由此构成某一领域的软件开发系统。
图2-10 智能模型