软件产品WBS分解的指南.doc

软件产品 WBS 分解指南一、概述同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。

软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。

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

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

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

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

以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。

只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。

需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。

不管是有意识还是无意识，这些活动都会出现在项目过程中。

这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。

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

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

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

瀑布模型可以应用于软件工程开发、企业项目开发、产品生产以及市场销售等领域。

瀑布模型的突出特征是文档驱动。

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

采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作，所以项目必须有明确的阶段里程碑，在每个阶段结束时都要进行里程碑评审，以判定是否可以开始下一阶段的工作。

例如：在项目策划没有完成时，需求分析和设计工作就不能进行，同样，在需求分析和设计没有完成时就不开始编码。

瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理，如果发生变更，需要回溯前面所有阶段的工作产品，以便使工作产品保持一致。

定义阶段开发阶段维护阶段UAMUAM策划ATM需求分析ATM概要设计MP详细设计MTP编码UTP集成A 系统分析员UAM测试UAMP M 项目管理员验收维护P程序员（2）WBS 划分图 1瀑布模型的思想示意图说明：图中标记为的阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格的变更控制。

（2）WBS 划分此表仅作为参考，需根据项目所选定的标准过程的活动和任务进一步细化。

阶段和任务工作成果名称ID项目标准过程1 起草项目任务书《项目任务书》2 审批项目任务书已批准的《项目任务书》3 策划准备《项目实施计划》4 启动项目策划产品的功能结构图、 WBS 工作任务分解项目策划阶段《项目实施计划》：工作量估计，进度计划，人力资源计划，软 / 硬件、工具要求，风险管理计划，培训计划，沟通计划，5 项目估计和成果列表《项目策划管交付工作产品清单等理规范》《项目实施计划》（有些客户需要《质量保证计划（方案）》、6 制订项目计划《配置管理计划（方案）》等相关计划）7 项目计划评审按照《项目评审管理规范》的规定，QA 组织对《项目实施计划》组织评审 , 直到通过评审8 审批项目计划《项目实施计划》获得相关领导的审批9 需求调研开始按照《需求调研计划》，采取《需求调研记录表》进行调研，完成《系统需求分析说明书》初稿10 需求分析如果客户需求不清晰需要密切跟踪，要完成《需求调研记录跟踪矩阵》、《需求不一致项列表》需求分析阶段11 需求不一致项相关修订文档，可能包括《系统需求分析说明书》和《需求不协商处理一致项列表》等文件《需求开发与需求规格说明书完善《系统需求分析说明书》正式稿、《需求跟踪管理表》12管理规范》需求同级评审相关记录。

13 需求验证验证后的《系统需求分析说明书》、《需求跟踪管理表》14 需求分析阶段评审按照《项目评审管理规范》的规定，QA 组织对《需求分析说明书的评审》15 里程碑评审（可选）完成《项目里程碑报告》并组织评审16 概要设计概要设计相关技术资料17 设计文档编写《概要设计说明书》18 概要设计评审（可选）《概要设计说明书》的评审（建议详细设计或概要设计必须做一个正式评审）分析设计阶段详细设计详细设计相关工具和技术资料19《分析设计管文档编写《详细设计说明书》20理规范》21 用户界面设计《用户界面设计说明书》22 数据库设计《数据库设计说明书》23 详细设计评审设计评审记录《项目评审报告》24 里程碑评审（可选）完成《项目里程碑报告》并组织评审25 编程源代码实现开发阶段代码走查《代码走查检查单》26《产品实现管单元测试《单元测试报告》27理规范》28 初步完成三大手册初步完成《系统安装手册》《用户操作手册》《项目维护手册》测试阶段《项目测试管理规范》部署运行《系统部署管理规范》验收《项目验收管理规范》结项阶段《项目结项管理规范》维护阶段《项目运行维护管理规范》（ 3 ）优缺点29 集成测试测试 bug 清单30 测试文档项目《测试计划》、《测试用例》、《测试报告》31 部署安装使用《系统部署用户确认书》需要用户确认32 客户培训《客户培训签到表》《客户培训效果调查表》32 内部验收在正式部署之前完成。

《项目内部验收评审报告》33 客户验收《客户验收计划》、《客户验收报告》34 结项申请《结项申请表》35 结项总结《结项总结报告》36 总结会议结项总结37 维护计划审批维护工作启动制定《项目维护计划》并通过审批38 维护报告项目结束维护，完成《项目维护总结报告》该模型的优点：①阶段分明、活动明确，为软件开发工作提供一种结构化、有序的方法；②过程控制可见性较强：按照顺序开展每一个阶段的工作，每一阶段是在上一阶段彻底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工；③开发过程中的各项文档降低了沟通的成本，有利于及早发现问题，降低项目的阶段成本；④文档多，过程记录比较全，有利于后期维护。

该模型的缺点：①不能回溯：项目从开始到发布可见的版本需要较长的周期，用户直到项目开发晚期才能了解产品的真实面貌和质量，不易变更；如果必须回溯，则回溯成本很大。

②缺乏灵活性，不能跨阶段操作；③文档多，花费较多成本。

（ 4 ）适用范围①产品定义（或项目需求）和技术方案非常明确、用户的需求有很好的了解；②对质量的要求高于对成本和进度的要求；③工期相对较宽裕；④开发队伍技术力量较弱或缺乏经验；⑤维护项目。

2、迭代模型（ 1 ）基本思想迭代模型是 RUP （ Rational Unified Process，统一软件开发过程)推荐的周期模型。

在RUP 中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。

在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。

实质上，它类似小型的瀑布式项目。

RUP 认为，所有的阶段都可以细分为迭代。

每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

图 2 迭代模型的思想示意图说明：迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：①制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；②风险分析：分析评估所选方案，考虑如何识别和消除风险；③实施工程：实施软件开发和验证；④客户评估：评价开发工作，提出修正建议，制定下一步计划。

迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

使用迭代模型进行软件开发，项目活动包含以下几个阶段：①初始阶段初始阶段有时也称先启阶段。

初始阶段的目标是为系统建立商业案例并确定项目的边界。

为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。

本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。

对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。

②细化阶段细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。

为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求。

同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。

③构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。

从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。

④交付阶段交付阶段的重点是确保软件对最终用户是可用的。

交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。

在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。

图 3 迭代模型的几个阶段（2）WBS 划分实际采用迭代模型中，项目阶段仍可参考瀑布执行。

迭代模型实施重要的关键点是架构设计（概要设计）、制定迭代开发计划。

阶段和任务工作成果名称项目标准过程项目策划阶段完成《项目实施计划》《项目实施计划》中 WBS 分解要参考本表《项目策划管理规范》必须有架构设计（概要设计）项目迭代计划《项目迭代开发计划》《项目迭代开发计划》必须说明哪些是关键迭（★）代，完成的时机以及预期成果下一个迭代，在前几个迭代基础上需要完善的要点以及完善步骤架构（概要）设计（★）概要设计说明书系统完成架构设计（概要设计）需求分析迭代 1 的需求分析，形成《需求说明书》需求评审关键迭代需要组织评审详细设计直接做详细设计，完成迭代《设计说明书》文档编写《详细设计说明书》用户界面设计《用户界面设计说明书》数据库设计《数据库设计说明书》详细需求分析、设计及编程源代码实现第 1 个迭代代码走查按照《项目实施计划》中质量控制点计划要求完成《代码走查检查单》单元测试按照《项目实施计划》中质量控制点计划要求完成《单元测试报告》第一个迭代部署 / 集成按照《项目迭代开发计划》将迭代开发成果部署到统一架构中。