软件生命周期模型

1. 软件生命周期模型

软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）[1]  。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

1.1. 边做边改模型

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

 

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2） 忽略需求环节，给软件开发带来很大的风险；

（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

1.2. 瀑布模型

瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段，如图所示。

 

瀑布模型中每项开发活动具有以下特点：

(l)从上一项开发活动接受其成果作为本次活动的输入。

(2)利用这一输入，实施本次活动应完成的工作内容。

(3)给出本次活动的工作成果，作为输出传给下一项开发活动。

(4)对本次活动的实施工作成果进行评审。

优点：

当前一阶段完成后，只需要去关注后续阶段。

缺点：

 需求在开始的不确定性，错误到最后才能发现。

1.3. 原型化模型

原型化模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，经过和用户针对原型的讨论和交流，弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后，再在原型基础上开发出用户满意的产品。

如图所示：原型严格来说不算一种软件生命周期模型，它只是一种获取需求的方法，在实际工作中该方法是相当重要的方法。

 

模型要点：瀑布和原型模型相结合，强调版本升级。

该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。

该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。

该模型比较能符合实际的情况，我们往往也是通过多个版本来逐步实现全部需求，但需求是不可能在一开始就完全确定的，实际情况是往往只能确定80%，而后期通过各版本我们还会获取更多的新需求以及需求调整。将此模型稍微调整后，可以适用于大部分的实际项目。

1.4. 增量模型

增量模型也是原型化开发方法。如图所示

 

1.5. 螺旋模型

1.软件分多个版本开发，每个版本就是一次螺旋。

2.每个版本按照这样的顺序进行：

   1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）

   2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）

   3）实施软件开发；（图中右下象限）

   4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）

3.需求不是一次获取和实现的，通过多个螺旋来完善。

4.计划也不是一次成型的，每次螺旋都需要调整。

 

 

图中的螺旋线代表随着时间推进的工作进展；开发过程具有周期性重复的螺旋线形状。4个象限分别标志每个周期所划分的4 个阶段：制定计划、风险分析、实施工程和客户评估。螺旋模型要点：统一了瀑布模型与原型模型，与增量模型相似，更强调风险分析。

优点：

1）设计上很灵活，可以在项目的各个阶段进行变更；

2）以小的分段来构建大型系统，使成本计算变得简单容易；

3）客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性；

4）随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互；

5）客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

缺点：

螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。

因此，这种模型往往适应于内部的大规模软件开发。该模型建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。

1.6. Ｖ模型

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V 模型的优点在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

 

V模型的缺陷及解决思路

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路是，当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

1.7. Ｗ模型

相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。