软件项目生命周期模型分析及选择

张 妍

（北京航空航天大学经济管理学院）

一、引言

一般来说，项目生命周期从时间维度上将项目划分为可行性研究、需求分析、概要设计与详细设计、编码、测试、运行与维护六个阶段，形成一个从启动到收尾推进项目实施的主线, 是项目实施的整个过程。项目阶段的数量取决于项目规模及项目复杂程度，可根据项目的实际情况进行裁剪。项目的生命周期分为：

（1）预测型生命周期是固定且连续的（瀑布式项目）。

（2）适应型生命周期可以细分为：

迭代：项目分解成更小的、逐步迭代的阶段。

增量型：类似于迭代，但阶段更有顺序性和时间限制。

适应型：敏捷风格的项目，以 2-4 周的“Sprint”推进和指导工作。

混合型：将预测型和适应型方法结合在一起满足项目需求。

软件项目的规模、需求、项目负责人的管理能力、开发团队的技术能力都是千差万别的，只有充分了解各生命周期模型的特点，才能选择出一个适合项目的模型。当一个项目确定了生命周期模型后，再综合运用项目管理过程、知识领域等管理方法、工具和技术实施项目管理。

接下来，本文介绍的瀑布模型、快速原型模型、螺旋模型、V模型、迭代模型、增量模型、敏捷模型都是目前在软件行业中通用的项目生命周期模型，这些模型被项目管理者运用于项目或项目的不同阶段。

二、典型项目生命周期模型分析

（一）瀑布模型

瀑布模型也称线性模型，以文档驱动。该模型将软件开发过程分为可行性研究、需求调研与分析、概要设计与详细设计、编码、测试、运行维护六个阶段，阶段之间有清晰地划分并且按此顺序先后衔接，按部就班的推进项目，每个阶段只执行一次，追求“一次成型”。每个阶段都对应着里程碑节点，并规定了需要完成的任务及交付产物。每一阶段结束后，通过严格的阶段评审和确认，得到完整准确的文档，以冻结这些文档为该阶段结束的标志，并作为下一阶段工作的输入；通过每一阶段执行的正确性和完整性来保证最终系统的质量。

瀑布模型如果范围控制和风险控制做的比较好的话，就真的如瀑布一般“飞流直下三千尺”，迅速完成客户期望，部署运行，一般在外包公司常见。

（二）快速原型模型

快速原型模型是以需求驱动的。项目规模大且需求模糊时，产品经理很难一次完成需求分析，应用快速原型模型可以减少因需求不明确带来的系统开发风险。原型法第一步是根据客户的迫切需求在短时间内构建一个可以演示的产品（原型），客户对该原型进行评价，输出具体改进意见以丰富细化软件需求，通过反复评价和改进原型弥补漏洞，直到客户对原型满意认可，最终团队完成需求分析及确认。第二步则是根据原型开发出反映客户真正需求的软件。

因运用原型的目的和方式不同，原型的运用方式可分为抛弃型策略和进化型策略。抛弃策略用于项目目标模糊的情形下，以此策略梳理清楚客户真实需求，探索方案的可行性。一旦需求或者方案确定了，原型随之作废。进化型策略用于需要尽早向客户提交原型的情形下，原型包含系统的核心需求和功能，在得到客户认可后，将原型不断扩充演变为客户满意的最终系统。根据项目特点、原型构建工具、技术成熟度来选择原型的运用方式。如果客户对系统性能、可靠性要求较高，最好采用抛弃策略；如果客户对质量要求不高，期望实现简单功能就可以，可采用进化策略。

（三）螺旋模型

螺旋模型引入了风险分析与规避机制，是瀑布模型、快速原型和风险分析方法的有机结合。该模型由制定计划、风险分析、实施工程和客户评估这四个活动组成一个循环周期，在每个螺旋循环开始前进行风险分析，并在每个螺旋循环中采用瀑布模型并构建原型以降低风险。制定计划活动是指定义软件的里程碑目标及项目边界，选择实施方案。风险分析活动是指分析和评估所选方案，识别风险并确定适当的风险预防措施。实施工程活动是指对软件项目的整个生命周期进行需求分析、设计、编码、测试和实施。客户评估活动是指对此螺旋周期的工作进行评价，根据反馈建议制定下一步计划[1]。

螺旋模型强调的是产品从小到大，不断改进，不断风险分析的过程，特别适合庞大而复杂的、高风险的系统。

（四）V模型

V模型以测试驱动，基本思想是测试和开发同等重要，多个测试级别与开发阶段相对应。整个V模型的活动按先后顺序分别是需求分析→概要设计→详细设计→编码→单元测试→集成测试→系统测试→验收测试。

(1)单元测试：对应详细设计阶段，由开发人员执行，测试每个功能模块，重点测内部业务逻辑。

(2)集成测试：对应概要设计阶段，由开发人员执行，将已测试过的模块组装成系统进行联调测试，检查系统能否成功编译，各个模块之间数据通信是否正常等。

(3)系统测试：对应需求分析阶段，由测试人员执行，将整个系统看为一个整体，对功能、接口、性能、安全进行全方位的测试，验证功能及性能是否满足《需求规格说明书》。

(4)验收测试：对应用户需求阶段，一般由客户来执行，验证系统是否符合合同中规定的要求。

V模型将把测试过程置于编码之后，在验收测试环节才能由客户验证需求最终实现的情况，针对这一弊端，可以安排测试人员在需求分析阶段介入并编写测试用例。这样可以尽快发现需求是否偏离，最大可能的减少返工，从而满足用户的实际软件需求。

（五）迭代模型

与瀑布模型不同，迭代模型不再强调工作的序列化过程，而是将这些过程并行化，分为多个阶段，每个阶段都包含这些工作且在不同阶段所占比例不同，接纳需求变更，允许通过需求细化来加深对问题的理解，是需求从模糊到清晰、功能反复求精的开发过程，并且每次迭代都产生一个可以发布的产品。

迭代模型一个二维的生命周期模型，以横轴代表时间，分为初始、细化、构造、交付四个阶段；以纵轴代表核心工作流程，即业务建模、需求、分析和设计、实现、测试、部署。初始阶段的任务是确定项目边界，估计项目成本和时间，展示系统候选架构，评估业务和需求风险，建立业务模型。细化阶段的任务是分析问题，对架构做出决策（范围、主要功能及非功能需求），确定技术实现的可行性和系统架构的稳定性，编制项目计划。构造阶段的任务是构件开发，组装集成为产品，测试产品所有的功能，确定是否已经为部署软件做好准备。交付阶段的任务是组织验收评审，获取客户反馈，基于反馈对系统进行调试，最终将软件产品交付给客户。

（六）增量模型

增量模型亦称渐增模型，软件功能数量逐渐增加，产品逐步发布交付。该模型将软件视为一系列的增量组件来设计、开发、集成测试，每个组件由多个相互作用的模块构成，并且能够完成特定的功能。第一个增量组件通常实现最基本的软件需求，提供最核心的功能。与瀑布模型相比，增量模型具有更短的周期，并且是分批向客户交付产品。

增量模型的工作流程分为以下三个阶段：

（1）在项目初期，为了确保系统具备稳定的架构，需要对整个系统进行需求分析和架构设计。以增量组件来确定系统的需求框架，再根据需求框架中组件的关系完成架构设计。（2）系统架构设计完成后，可执行增量组件的开发。首先对组件的需求进行细化分析，然后进行组件的设计、编码、测试。（3）将开发完成的增量组件集成至系统，对集成后的系统进行重新验证，验证通过方能启动下一个增量组件的开发[2]。

（七）敏捷模型

敏捷模型采用迭代规划、增量交付的开发方法，开发评估以工作量为导向，任务评估采用相对估算，主张拥抱需求变化和面对面交流，简化了繁琐的流程和文档管理。在敏捷开发中，项目被划分为几个连续的子项目，这些子项目可以独立运行。各子项目的工作成果均通过测试，并且可集成和可操作。该模型面对瞬息万变的市场环境和持续发展的技术时变得非常友好，适用于需求和范围难以确定的项目。

敏捷模型有许多成熟的框架，并且各有自己的原则，比如软件统一过程（RUP）、Scrum、看 板（kanban）、 极 限 编 程（XP)、精益软件开发、功能驱动开发（FDD)，其中Scrum应用最广泛。Scrum是固定周期的短迭代，Scrum中的迭代称为冲刺Sprint，Scrum团队由一名产品负责人（PO）、开发团队（TM，至少3人）和一名Scrum Master（SM）组成。

敏捷项目管理分为5个阶段：（1）构想：确定产品及项目范围、项目参与者、项目团队工作方式。（2）推测：收集产品初始要求，梳理出产品功能清单，估算项目成本，分析风险并制订相应的应对措施，编写基于功能的迭代交付计划。（3）探索：组建协作的项目团队，对项目干系人的期望值进行沟通，注重沟通效果的反馈，按期交付经测试通过的产品功能。（4）适应：检查项目状态和流程绩效，与原计划比对，分析差异原因，及时调整工作以开始新的迭代。（5）结束：终止项目、交流主要的学习成果并融入下一迭代工作[3]。产品在每次迭代中不断优化，循环通常是推测→探索→适应，而构思需要定期修正。

近年来，持续集成已成为敏捷开发的最佳实践。然而，敏捷和持续集成的理念并没有很好的解决从“开发完成”迅速实现“上线发布”环节，即持续交付。DevOps恰好拓展和完善了持续集成（CI）、持续部署（CD），来优化开发、测试、系统部署等环节。DevOps很好地补充了敏捷，与敏捷模型配合可以实现更快、更持续的生产部署，加速交付更高质量和更可靠的软件产品和功能。

三、项目生命周期模型的对比分析（见表1）

表1 项目生命周期模型的对比分析

四、结语

如今，软件行业有多个通用的项目生命周期模型，每个过程模型都遵循其所独有的一系列阶段，以确保软件开发步骤中的成功。但是，它们都不是完美的，会给项目带来积极影响，同时伴随而来的也会有不可预知的风险。项目规划阶段，项目管理者需要考虑项目背景、范围、预算、干系人、风险、资源等众多因素，决定采用何种项目生命周期管理方式，为管理项目提供基础框架，从而更加有效地做好项目管理。

项目管理者可以通过几个方面来选择适合的项目生命周期模型：

（1）根据项目管理的侧重点（进度、质量、成本控制、风险管理等）选择适合的模型。

（2）模型是否适合项目规模及其复杂性？

（3）模型是否适合公司文化、组织原则？

（4）模型是否适合团队的规模和他们的技能？

（5）模型是否适合项目中使用的技术？

（6）如果选择这种模式，是否存在项目风险？

（7）需求是固定的还是灵活的？

若项目选择适合的生命周期模型来设计和开发，可以起到事半功倍的效果。软件项目过程具有随机性以及不确定性的特点，任何一种模型可能都无法完全匹配实际的项目过程，所以在实际工作中，项目管理者不必拘泥于某一种模型，可以根据项目风险情况，适当借鉴其它生命周期的管理方式。