一个软件项目可以有多个生命周期模型吗？
一个软件项目只能有一个生命周期模型。
因为每产生一个新的周期模型，都是因为原有的生命周期模型存在这样或那样的缺点（见下表），并不适合某种类型软件的开发。
| 生命周期模型 | 缺点 |
|---|---|
| 瀑布模型 | 瀑布模型的缺点是只能按顺序完成每个阶段的工作任务 |
| 增量模型 | 若软件系统的组装和拆卸性不强，或开发人员全局把握水平不高，或者客户不同意分阶段提交产品，都不宜采用这种模型 |
| 迭代模型 | 迭代模型是采取循环的工作方式，每次循环均使工作产品更靠近目标产品一次，这就要求项目组成员具有很高的水平井掌握先进的开发工具 |
| 原型模型 | 必须事先有一个展示性的产品原型，不利于开发人员的创新 |
所以，每个软件项目都应该根据自身的特点去选择适合自己的生命周期模型。生命周期模型选择条件见下表：
| 生命周期模型 | 选择条件 |
|---|---|
| 瀑布模型 | (1)在开发时间内需求没有或很少变化。 (2)分析设计人员对应用领域很熟悉。 (3)低风险项目(对目标、环境很熟悉)。 (4)用户使用环境很稳定。 (5)用户除提出需求以外，很少参与开发工作。 |
| 增量模型 | (1)在整个项目开发过程中，需求都可能发生变化，客户接受分阶段交付。 (2)分析设计人员对应用领域不熟悉，难以一步到位。 (3)中等或高风险项目(工期过紧且可分阶段提交的系统或目标、 环境不熟悉)。 (4)用户可参与到整个软件开发过程中。 (5)软件公司自己有较好的类库、构件库。 |
| 迭代模型 | (1)在项目开发早期需求可能有所变化。 (2)分析设计人员对应用领域很熟悉。 (3)高风险项目。 (4)用户可不同程度地参与整个项目的开发过程。 (5)具有高素质的项目管理者和软件研发团队。 |
| 原型模型 | (1)已有产品或产品的原型，只需客户化的工程项目。 (2)简单而熟悉的行业或领域。 (3)有快速原型开发工具。 (4)进行产品移植或升级。 |
不同的生命周期模型适用于不同的项目。
如果非要把不同的生命周期模型放到一个项目中，只能给项目管理带来混乱——瀑布模型需求稳定，所以你可以像瀑布那样做完需求开发、需求确认之后再开始设计、实现和测试；而增量和迭代的需求不稳定，它们都是先确认部分需求，就完成设计、实现和测试，再确认另一部分需求，再完成设计、实现和测试，那么如果一个项目中既有瀑布模型，又有增量或迭代模型，就会出现这样情况：瀑布模型在项目初期需求分析阶段就可以拿出完整的需求规格说明，增量或迭代模型却是要到项目后期才会有完整的需求规格说明，那么项目的阶段和里程碑怎么做？
PS：也许有些组织定义的生命周期模型并不是像瀑布模型、原型模型、增量模型这种意义上的模型，他们所定义的模型实际上是瀑布模型的变种，即基本模型是瀑布模型，但却因为项目的重要程度等原因实施了不同的裁剪，由此得出的模型（据说有些组织的生命周期模型有100多种），那就是另外的概念了。
当然，一个软件项目是可以有管理多个软件配置项的。多个软件配置项的开发统一管理，这样可以降低很多管理成本。但是，这种做法也不是没有任何限制的，否则可能会带来更多的管理成本，失去了多个软件配置项统一管理的意义。
要建立一个包含多个软件配置项的项目，建议考虑以下条件：
软件数不宜太多；
软件适用同一个生命周期模型；
软件隶属于同一个组件/子系统。
这正是：
一个项目一模型，模型多了可不中
管理混乱难操作，管理成本可不轻
作者简介：王小双，长期从事GJB5000推广、实施、评价、改进的工作，创建《软件工程之思》微信公众号，一直在《软件工程之思》分享GJB5000、CMMI、软件工程的知识和感悟。现致力于GJB5000咨询以及软件过程改进、软件工程能力提升的研究工作。
赞 (0)