形形色色的软件生命周期模型

软件生命周期, 项目管理, MSF, RUP摘要：
读大学时，我们曾经学习过不少软件生命周期模型，当时还不是很懂软件开发，你可能会觉得这些东西很新奇。在实际工作中，你会发现这些模型其实很难应用，与此同时你会接触到RUP、MSF等权威软件公司的生命周期模型。本文将向你介绍各种常见的软件生命周期模型及它们的优缺点，文章最后还会介绍吸取了各种模型优点的实用生命周期模型。

大纲：
1.瀑布型
2.增量型
3.进化型
4.原型
5.螺旋型
6.RUP的软件生命周期模型
7.MSF的软件生命周期模型
8.实用软件生命周期模型

正文：

软件生命周期模型，是指软件由开始制作到最后被淘汰掉整个过程的模式。下面我们将逐一介绍各种常见的软件生命周期模型，最开始几种是我们读书时学习到的，后面是各种是实用生命周期模型，而最后一种是我在多年项目管理工作中总结出来的可能是最符合我们现状的开发模式。

瀑布型

瀑布型简单地说就是按照需求、设计、编码、测试、软件维护这个基本的顺序来研发软件，前面一个步骤不完成，后面的步骤不能开始，否则问题会滚到下个阶段，带来更多的问题。瀑布型的图如下：


此图来自互联网

瀑布型是我们说得最多的模型，也最容易理解，但在实际工作中最不能执行。
我们普遍会认为，大型的、严谨程度高的项目应该采用瀑布型，恰恰相反，往往是规模很小的项目才适合这样做。
大型的项目，需求和技术都是很复杂的，如果死板地按照瀑布型，基本不可能适应复杂的需求与技术情况，也会让项目遥遥无期。而规模很小的项目，需求容易在前期就搞得很清楚，技术也不复杂，这时反而适用瀑布型。
但实际情况是规模很小在前期能搞定需求的项目基本上是没有的，能应用瀑布型的情况一般是项目的后期维护小版本，某个很小的升级版本可以用瀑布型的开发模式。

增量型

先看看增量型的图：


此图来自互联网

该模式的特点是一次性地获取全部的需求，然后做出分版本实现各需求的计划，每个版本只实现一部分需求，通过多个版本逐步实现全部需求，而每个版本可以认为是一个“小瀑布”。
该模型的好处是可以尽快让系统上线，让客户先使用部分功能，尽早实现系统的价值。

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

进化型

进化型和增量型类似的地方就是都是分多个版本发布，但区别就是项目初期无法获取全部的需求，用户对需求其实也没有全面了解，需求获取是一个重复的过程。第一个版本实现的是客户的初步想法，然后后续版本不断地调整。


此图来自互联网

这种模式，其实就是边做边看边边调整的模式。这样的方式应该比较受软件公司喜欢，因为客户的想法无时无刻在变啊！
现实没有这样理想啊，我们的项目一般合同价钱是签死的，项目的期限也是限死的，客户当然喜欢你先做出来看看再调整了，但作为软件公司你能经得起这样的折腾吗？
这样的模式，一般只能适用于公司内部研发某产品或者技术时的情况，而和客户签署合同的项目难以应用这样的模式。

原型

原型英文名字叫Prototype，原型开发我们在大学时就应该学习了。

原型就是在客户有初步想法的时候，就“快速设计”和“快速编码”地做出一个可供演示的系统（即原型），用来更好地获取和理解客户的需求。当客户需求比较清晰时，则开始正式的开发工作，而开始做的原型有可能会被完全抛弃掉，也可能会在这个原型的基础上继续开发。

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

螺旋型

螺旋型可以说是综合了以上各种模型优点的一种模型，同时它加入了风险管理的内容。如下图：


此图来自互联网

我第一次学习螺旋型时，觉得比较难以理解，其实没有这样复杂，该模型简单地说是这样的：
1.软件分多个版本开发，每个版本就是一次螺旋。
2.每个版本按照这样的顺序进行：
   1）确定软件目标，选取定实施方案，弄清项目开发的限制条件；（图中左上象限）
   2）分析所选取方案，考虑如何识别和消除风险；（图中右上象限）
   3）实施软件开发；（图中右下象限）
   4）评价开发工作，提出修正建议，调整计划。（图中右下象限、左下象限）
3.需求不是一次获取和实现的，通过多个螺旋来完善。
4.计划也不是一次成型的，每次螺旋都需要调整。

该模型在实际工作中实用性还是相当高的，但可能是该模式很多资料都说得不太清楚，让很多人会有一些误解。

RUP的软件生命周期模型

RUP是统一软件过程的缩写，英文全写为：Rational Unified Process。

前面提到增量、进化、螺旋的共同特点是多个版本，而每个版本可以认为是一个“小瀑布”，对于每个版本，我们可以认为还是要先完成前一步才能做下一步。而RUP认为项目中的工作可以分成好几类，而每一类工作在整个项目周期都是持续进行的，只是不同工作在项目的不同时期比重不太一样，如下图：


此图来自互联网

按照时间顺序，项目分为初始（inception）、细化（Elaboration）、构造（Construction）、交付（Transition）四个阶段，
每个阶段会有很多个小迭代。这四个阶段其实很难说有明显界限的，我觉得大家大概了解每个阶段的工作内容就可以了。

按照工作的性质，项目的工作可以分为以下几类：
商业建模（Business Modeling）
需求（Requirements）
分析和设计（Analysis & Design）
实现（Implementation）
测试（Test）
部署（Deployment）
配置管理与变更管理（Configuration & Change Mgmt）
项目管理（Project Management）
环境（Environment）

以上这些工作，在项目的不同时期工作量分布是不太一样的，如：商业建模、需求这些工作往往是头大尾小，分析与设计、实现等是中间大两头小，项目管理、环境方面的工作一直都会持续进行。

RUP的思想打破了“需求-设计-编码-测试”这样的传统瀑布模式，需求、设计、编码、测试这些工作其实一直都在进行的，只是不同时间比重不一样。这个思想是很符合“敏捷”的特点，也和实际情况非常吻合。

大家理解这个意思后，我觉得完全可以按照自己公司的实际情况重新定义时间上的阶段，也可以自己重新定义项目的各类工作，以及思考各类工作在项目不同时间的工作量分布。

《敏捷开发》中也介绍了RUP，想了解更多敏捷开发，可参考《敏捷开发》一文。

MSF的软件生命周期模型

MSF，全称是Microsoft Solution Framework，微软解决方案框架，是微软进行研发活动的方法论。
关于MSF，大家可以参考此文《解开MSF团队管理的秘密》。

在《项目团队模型》一文中，我们介绍了MSF的团队模型，这里介绍MSF的软件生命周期模型。

MSF的软件生命周期模型与螺旋型很相似，同样也是多版本螺旋前进，只是每次螺旋（每个版本）阶段划分不太一样，而且每次螺旋都会有至少5个大里程碑，如下图：


本图来自互联网


本图来由MSF官方资料整理出来

第一个图反应了MSF生命周期模型的概貌，多版本的连续开发，每个版本实现部分功能，最后实现全部的功能。

第二个图详细说明了每一个版本（即每一次螺旋）的阶段划分及里程碑：
阶段：远景（Envisioning）
里程碑：远景/范围被批准（Vision/Scope Approved）
阶段：计划（Planning）
里程碑：计划被批准（Project Plans Approved）
阶段：开发（Developiing）
里程碑：范围完成（Scope Complete）
阶段：稳定（Stabilizing）
里程碑：发布被批准（Release Readiness Approved）
阶段：部署（Deploying）
里程碑：部署完成（Deployment Complete）

如果某软件开发时间的工作比较类似，我们往往可以将该时期定为某某阶段，阶段是某个时间段上的概念。而里程碑不是时间段上的概念，而是指某个时间点上发生的标志性事件。MSF的每个阶段都以相应的里程碑标记，阶段必须达致里程碑才算结束。如第一个阶段远景，必须有书面的经过审批的远景相关文档才算结束。

MSF的生命周期模型是螺旋型模型的进一步优化，既保持了软件开发的灵活性，同时在每一次螺旋中均有里程碑的要求，增强了软件开发的严谨性。

实用软件生命周期模型

我个人觉得MSF和RUP的软件生命周期模型和我们实际工作比较贴切，不过当然不是100%都可以执行了，但以下几个重要思想是可以贯彻的：
1.整个项目应该通过多版本推进。我们公司项目不算很大，每个版本周期在一个月内，甚至只有两到三周。
2.各类文档和代码应该持续更新。这些文档包括：需求、设计、测试、实施方面的文档，也包括计划方面的文档。
3.需求、计划、设计、测试等重要文档均需通过评审，并用通过评审的文档来指导工作。
4.通过评审后的文档应该因应变化而及时调整，不要走两个极端：任何修改都需要重型的变更审查；文档写了就算不根据实际情况作任何调整。

但MSF、RUP等软件生命周期模型，都没有考虑到中国项目的一些重要的特点：
1.签订了需求不明确的合同。
2.合同的价钱是死的。
3.合同要求的项目完成时间是死的。

这些特点决定了我们无法完全采用以上任何软件生命周期模型，我们的软件开发难以“敏捷”，我们很多IT从业员天天在为项目而“煎熬”。我们需要提出一种能适应中国特色的、能针对性解决实际问题的实用软件生命周期模型。

我觉得这种实用软件生命周期模型应该有这样的特点：
1.需求应当在项目初期至少明确80%以上。
2.采用多版本方式逐步满足需求，让已确定需求尽快稳定，并尽快搞清楚未确定的需求。
3.需求、设计、编码、测试、实施等工作应一步一脚印做好，文档应及时评审并要及时更新。

我定义了一种软件生命周期模型：多线程多版本式软件生命周期模型，如下图：



此图与RUP的图很类似，主要区别有：
1.横向以多版本来划分。实际项目中每个版本的周期一般也只有1-2个月，而我们公司往往少于1个月，故每个版本我就不再划分阶段。
2.工作分类不太一样，我以中国人更容易理解的角度来划分，并且补充了RUP没有的活动。
商务：指跟客户商定合同、谈判、验收、收款等与钱直接相关的工作。
工作环境：为保障项目组顺利运作而准备的软硬件环境，保障项目组的工作、沟通能顺利进行。
技能管理：完成项目需要满足一定的技能要求，在整个项目过程中要针对性地安排培训、自学、研究等工作，保证项目组整体具备完成工作所需的技能。
3.计划、需求、设计、编码、测试、实施这些红色字的活动，尽管在整个项目周期中是持续进行的，但需要及时安排工作产品评审，并要及时更新文档。
以计划为例，往往我们在项目初期只能定出近期的详细计划以及远期的大致计划，随着项目开展应随时更新近期计划和明确远期计划，计划应不断细化。同样道理。需求、设计、测试、实施等文档也是需要不断细化的。

其实软件开发情况千变万化，没有一种模型能应对全部情况。下面我列举几种典型的项目情况，每种情况的软件生命周期模型都不尽相同。
1.从新开始做一个项目。
2.在一期的基础上开发二期项目。
3.在产品的基础上做项目。
4.公司独立自主研发产品。
5.互联网开发。
6.维护型项目。
以上每种情况都不尽相同，每种情况都可以有自己独特的软件生命周期。

实用软件生命周期模型并不存在固定的模式，我们需要理解上述各种模型的特点，在实际工作中不断体会项目管理的奥妙，灵活应用上述模型。
有人常常问我：你们公司的项目是怎样的生命周期模型？
我往往不知道怎样回答，招无定式，我们的模型往往是“混合型”的！

软件生命周期模型只是项目管理的其中一个部分，想深入学习项目管理知识，请参考《超级项目管理》课程。