内容发布更新时间 : 2024/12/23 22:19:55星期一 下面是文章的全部内容请认真阅读。

软件生命周期模型选择及WBS分解指南

一、概述

同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。

软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有效地进行软件开发。

选用恰当的软件生命周期模型进行软件开发，可以提高产品质量；降低项目管理难度；缩短开发进度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。

为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺点和项目的实际需要进行选择，并在《项目实施计划》中，参加评审。

二、软件生命周期模型

常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。

以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。

需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。

以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure，即工作分解结构）、优缺点、使用范围进行分析。

1

1、瀑布模型

（1）基本思想

瀑布模型（Waterfall Model）是最基本也最常用的一种生命周期模型，又称线性模型。

瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。瀑布模型可以应用于软件工程开发、企业项目开发、产品生产以及市场销售等领域。

瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。

采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作，所以项目必须有明确的阶段里程碑，在每个阶段结束时都要进行里程碑评审，以判定是否可以开始下一阶段的工作。例如：在项目策划没有完成时，需求分析和设计工作就不能进行，同样，在需求分析和设计没有完成时就不开始编码。 瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理，如果发生变更，需要回溯前面所有阶段的工作产品，以便使工作产品保持一致。

定义阶段 UAM 策划 UAM 需求分析 ATM 概要设计 ATM 详细设计 MP 编码 A 系统分析员 M 项目管理员 P 程序员 T 高级程序员 U 用户 （2）WBS划分

说明： 图中标记为

的阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格

2

开发阶段 维护阶段 MTP 集成 UTP 测试 UAM 验收 UAMP 维护 图 1 瀑布模型的思想示意图

的变更控制。

（2）WBS划分

此表仅作为参考，需根据项目所选定的标准过程的活动和任务进一步细化。 阶段和 ID 项目标准过程 1 2 3 4 项目策划阶段 《项目策划管理规范》 5 任务 起草项目任务书 审批项目任务书 策划准备 启动项目策划 《项目任务书》 已批准的《项目任务书》 《项目实施计划》 产品的功能结构图、WBS工作任务分解 工作成果名称 《项目实施计划》：工作量估计，进度计划，人力资源计划，项目估计和成果列表 软/硬件、工具要求，风险管理计划，培训计划，沟通计划，交付工作产品清单等 制订项目计划 项目计划评审 审批项目计划 需求调研 需求分析 需求不一致项 协商处理 《项目实施计划》（有些客户需要《质量保证计划（方案）》、《配臵管理计划（方案）》等相关计划） 按照《项目评审管理规范》的规定，QA组织对《项目实施计划》组织评审,直到通过评审 《项目实施计划》获得相关领导的审批 开始按照《需求调研计划》，采取《需求调研记录表》进行调研，完成《系统需求分析说明书》初稿 如果客户需求不清晰需要密切跟踪，要完成《需求调研记录跟踪矩阵》、《需求不一致项列表》 相关修订文档，可能包括《系统需求分析说明书》和《需求不一致项列表》等文件 需求同级评审相关记录。 验证后的《系统需求分析说明书》、《需求跟踪管理表》 按照《项目评审管理规范》的规定，QA组织对《需求分析说明书的评审》 概要设计相关技术资料 《概要设计说明书》 《概要设计说明书》的评审（建议详细设计或概要设计必须做一个正式评审） 详细设计相关工具和技术资料 《详细设计说明书》 《用户界面设计说明书》 《数据库设计说明书》 设计评审记录《项目评审报告》 源代码 3

6 7 8 9 10 需求分析阶段 11 《需求开发与12 管理规范》 13 14 15 16 17 需求规格说明书完善 《系统需求分析说明书》正式稿、《需求跟踪管理表》 需求验证 需求分析阶段评审 里程碑评审（可选） 完成《项目里程碑报告》并组织评审 概要设计 设计文档编写 18 概要设计评审（可选） 分析设计阶段 19 《分析设计管20 理规范》 21 22 23 24 实现开发阶段 25 详细设计 文档编写 用户界面设计 数据库设计 详细设计评审 编程 里程碑评审（可选） 完成《项目里程碑报告》并组织评审