五花八门的软件生命周期模型（4）——MSF、实用型

形形色色的软件生命周期模型（4）——MSF、实用型

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

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

本系列文章将为分四次为你分享，每次分享两种模型。

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.维护型项目。
以上每种情况都不尽相同，每种情况都可以有自己独特的软件生命周期。

实用软件生命周期模型并不存在固定的模式，我们需要理解上述各种模型的特点，在实际工作中不断体会项目管理的奥妙，灵活应用上述模型。

有人常常问我：你们公司的项目是怎样的生命周期模型？
我往往不知道怎样回答，招无定式，我们的模型往往是“混合型”的！