1.4.2 典型生存周期模型

软件生存周期模型提供了一个框架，以便描述在软件生存周期内进行软件开发、操作和维护所需要实施的过程、活动和任务。由于工作对象和范围的不同，软件开发人员经验的差异，所采用的软件生存周期模型也有所不同。

软件工程过程没有规定一个特定的软件生存周期模型或软件开发方法，各个软件开发机构可以为自己的开发项目选择一种生存周期模型，并将软件工程过程所包含的各种过程、活动和任务映射到该模型中，也可以选择和使用软件开发方法来执行适合于其软件项目的活动和任务。

美国国家航空航天局（NASA）指出：“在整个 NASA 中，从多年的软件工程实践中吸取的一个重要教训是，没有一个单一的解决方法能够解决所有的问题。没有一个生存周期、分析和设计方法、测试方法、产品评估方法适合于所有的NASA软件项目。”因此，在实际应用中，应根据具体情况选择适当的软件生存周期模型。

在GB/T 8566—2007《信息技术 软件生存周期过程》中描述了软件生存周期过程的体系结构，但没有规定一个特定的生存周期模型或软件开发方法。该标准指出“采用本标准的各方负责为软件项目选择一个生存周期模型，并把本标准所述的过程、活动和任务映射到该模型中。各参与方还有责任选择和应用软件开发方法，并执行适合于软件项目的活动和任务”。

下面介绍几种典型的软件生存周期模型。

1.瀑布模型

军用软件工程最初采用的软件设计模型，就是根据GJB 437规定反映生存周期法的瀑布模型，也称线性顺序模型、传统生存周期模型。该模型提出了软件开发系统化、顺序化的方法。

瀑布模型规定了各项软件工程活动，包括制订开发计划、进行需求分析和说明、软件设计、程序编码、测试及运行维护，并且规定了它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。如图1.1所示。

然而软件开发的实践表明，上述各项活动之间并非完全是自上而下，呈线性图式。实际情况是，每项开发活动均处于一个质量环（输入—处理—输出—评审）中。从上一项活动接受本项活动的工作对象，作为输入；利用这一输入实施本项活动应完成的内容；给出本项活动的工作成果，作为输出传给下一项活动；对本项活动实施的工作进行评审。

只有当其工作得到确认，才能继续进行下一项活动，在图1.1中用向下的箭头表示；否则返工，在图1.1中用向上的箭头表示。

软件维护在软件生存周期中有它的特点。一方面，维护的具体要求是在软件投入运行以后提出来的，经过评价，确定变更的必要性，才进入维护工作。另一方面，所谓维护中对软件的变更仍然要经历上述软件生存周期在开发中已经历过的各项活动。事实上，有人把维护称为软件的二次开发，正是出于这种考虑。由于软件在投入使用以后可能经历多次变更，为把开发活动和维护活动区别开来，便有了b形的软件生存周期表示，如图1.2所示。它与前述的软件生存周期循环一样，都是软件生存周期瀑布模型的变种。

瀑布模型为软件开发和软件维护提供了一种有效的管理模式。根据这一模式制订开发计划、进行成本预算、组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证软件产品及时交付，并达到预期的质量要求。与此同时，瀑布模型在大量的软件开发实践中也逐渐暴露出它的缺点。其中最为突出的缺点是该模型缺乏灵活性，特别是无法解决软件需求本身不明确或不准确的问题。

这些问题的存在会给软件开发带来严重影响，最终可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。面对这些情况，无疑需要进行返工或是不得不在维护中纠正需求的偏差。但无论上述哪种情况都必须付出高额的代价，并将为软件开发带来不必要的损失。另外，随着软件开发项目规模的日益庞大，由于瀑布模型不够灵活等缺点引发出的上述问题显得更为严重。

为弥补瀑布模型的不足，近年来已经提出了多种其他模型。

2.演化模型

由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰，因而使得开发项目难于做到一次开发成功，出现返工再开发在所难免。因此，可以先做试验开发，其目标只是在于探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。通常把第一次得到的试验性产品称为原型，如图1.3所示。

演化模型又称为增量模型。软件在该模型中是被逐渐开发出来的，开发出一部分，向用户展示一部分，可使用户及早看到部分软件，及早发现问题。或者先开发一个原型软件，完成部分主要功能，展示给用户并征求意见，然后逐步完善，最终获得满意的软件产品。该模型具有较大的灵活性，适合于软件需求不明确，设计方案有一定风险的软件项目。

演化模型从需求分析开始。软件开发人员与用户一起定义待开发软件系统的总目标，定义需求，确定软件的工作范围。然后快速设计软件中对使用者可见部分的表示，进而建造原型，再让用户或客户评估原型，根据评估结果，修改和细化待开发软件系统的需求，使之满足用户的需求。这个过程是一个迭代的过程。

演化模型的优点是：

（1）演化模型与传统的软件生存周期法比较，能够得到更良好的软件需求，它不仅能够处理模糊的需求，而且开发人员与用户可通过原型充分进行交流。

（2）原型系统可作为培训环境。它有利于使用户的培训和开发同步。

（3）演化模型给用户提供了机会，以更改用户原来设想的不尽合理的最终系统。

（4）演化模型可以低风险地开发柔性较大的计算机系统。

（5）演化模型使得开发出来的最终系统更容易维护，对用户更友好。

（6）演化模型可以降低总的开发费用，缩短开发时间。

演化模型的缺点是：

（1）对于开发人员不熟悉的领域，演化模型可能误导开发者把系统的次要部分当作主要框架，开发出不切题的原型。

（2）原型迭代不收敛于开发者预定的目标。为了消除错误，每次更改使得次要部分越来越大，淹没了系统的主要部分。

（3）原型过快地收敛于需求集合，使得某些基本方面被忽视。

（4）资源规划和管理比较困难，随时更新文档也会带来许多麻烦。

（5）长期在原型环境下开发，只注意得到令人满意的原型，容易遗忘用户环境与实际客户环境之间的差别。

3.螺旋模型

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型与演化模型结合起来，并且加入两种模型均忽略了的风险分析。

软件风险是普遍存在于任何软件开发项目中的实际问题。对于不同的项目，其差别只是风险有大有小而已。在制订软件开发计划时，系统分析员必须回答：项目的需求是什么，需要投入多少资源，以及如何安排开发进度等一系列问题。然而，若要他们当即给出准确无误的回答是不容易的，甚至几乎是不可能的，但系统分析员又不可能完全回避这一问题。凭借经验的估计出发给出初步的设想便难免带来一定风险。实践表明，项目规模越大，问题越复杂，资源、成本、进度等因素的不确定性越大，承担项目所冒的风险也越大。因此，风险是软件开发不可忽视的潜在不利因素，它可能在不同程度上损害软件开发过程或软件产品的质量。软件风险控制的目标是在造成危害之前，及时对风险进行识别、分析，采取对策，进而消除或减少风险的损害。

螺旋模型沿着螺线旋转，如图1.4所示，笛卡儿坐标系的4个象限上分别表达了4个方面的活动。

（1）制订计划——确定软件目标，选定实施方案，弄清项目开发的限制条件。

（2）风险分析——分析评价所选方案，考虑如何识别和消除风险。

（3）实施工程——实施软件开发。

（4）客户评估——评价开发工作，提出修正建议。

沿螺线自内向外，每旋转一圈便开发出更为完善的一个新软件版本。例如，在第一圈，确定了初步的目标、方案和限制条件以后，转入第Ⅰ象限，对风险进行识别和分析。如果风险分析表明，需求有不确定性，那么在工程象限（第Ⅳ象限）内，所建的原型会帮助开发人员和客户，考虑其他开发模型，并对需求做进一步修正。客户对工程成果做出评价之后，给出修正建议。在此基础上需要再次计划，并进行风险分析。在每圈螺线上，风险分析的终点做出是否继续下去的判断。假如风险过大，开发者和用户无法承受，项目有可能终止。在多数情况下沿螺线的活动会继续下去，自内向外，逐步延伸，最终得到所期望的系统。

如果软件开发人员对所开发项目的需求已有了较好的理解或较大的把握，则无须开发原型，可采用普通的瀑布模型，这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目的需求理解较差，则需要开发原型，甚至需要不止一个原型的帮助，那就需要经历多圈螺线。在这种情况下，外圈的开发包含了更多的活动，也可能某些开发采用了不同的模型。

螺旋模型适合大型软件的开发，应该说它是最为实际的方法，它吸收了软件工程演化的概念，使得开发人员和客户对每个演化层出现的风险有所了解，继而做出应有的反应。图1.5给出了螺旋模型的另一图式。

螺旋模型的优越性比起其他模型来说是明显的，但并不是绝对的。要求许多客户接受和相信演化方法并不容易。这个模型的使用需要具有相当丰富的风险评估经验和专门知识。如果项目风险较大，又未能及时发现，势必造成重大损失。