1、1软件产品WBS分解指南一、概述 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有效地进行软件开发。 选用恰当的软件生命周期模型进行软件开发，可以提高产品质量；降低项目管理难度；缩短开
2、发进度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。 为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺点和项目的实际需要进行选择，并在项目实施计划中，参加评审。 二、软件生命周期模型常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。需要强调的是，不管采用什么
3、模型，项目实施中有四项活动是必不可少的需求、设计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure，即工作分解结构）、优缺点、使用范围进行分析。21、瀑布模型 （1 ）基本思想 瀑布模型（Waterfall Model）是最基本也最常用的一种生命周期模型，又称线性模型。瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每
4、个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动” 到下一个阶段，这也是瀑布模型名称的由来。瀑布模型可以应用于软件工程开发、企业项目开发、产品生产以及市场销售等领域。瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以及在此基础上形成的产品。采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作，所以项目必须有明确的阶段里程碑，在每个阶段结束时都要进行
5、里程碑评审，以判定是否可以开始下一阶段的工作。例如：在项目策划没有完成时，需求分析和设计工作就不能进行，同样，在需求分析和设计没有完成时就不开始编码。 瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理，如果发生变更，需要回溯前面所有阶段的工作产品，以便使工作产品保持一致。（2）WBS划分说明：图中标记为 的阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格定义阶段 维护阶段策划需求分析概要设计详细设计编码集成测试验收维护开发阶段A 系统分析员M 项目管理员P 程序员T 高级程序员U 用户UAMUAMATMATMMPMTPU
6、TPUAMUAMP图 1 瀑布模型的思想示意图3的变更控制。 （2 ） WBS 划分此表仅作为参考，需根据项目所选定的标准过程的活动和任务进一步细化。 阶段和项目标准过程 ID 任务 工作成果名称1 起草项目任务书 项目任务书 2 审批项目任务书 已批准的项目任务书 3 策划准备 项目实施计划 4 启动项目策划 产品的功能结构图、WBS工作任务分解 5 项目估计和成果列表项目实施计划：工作量估计，进度计划，人力资源计划，软/硬件、工具要求，风险管理计划，培训计划，沟通计划，交付工作产品清单等6 制订项目计划项目实施计划（有些客户需要质量保证计划（方案）、配置管理计划（方案）等相关计划） 7 项
7、目计划评审按照项目评审管理规范的规定，QA组织对项目实施计划组织评审,直到通过评审项目策划阶段项目策划管理规范8 审批项目计划 项目实施计划获得相关领导的审批 9 需求调研开始按照需求调研计划，采取需求调研记录表进行调研，完成系统需求分析说明书初稿10 需求分析如果客户需求不清晰需要密切跟踪，要完成需求调研记录跟踪矩阵、需求不一致项列表 需求分析阶段需求开发与管理规范11需求不一致项协商处理相关修订文档，可能包括系统需求分析说明书和需求不一致项列表等文件 412 需求规格说明书完善 系统需求分析说明书正式稿、需求跟踪管理表 13 需求验证需求同级评审相关记录。 验证后的系统需求分析说明书、需求
8、跟踪管理表 14 需求分析阶段评审按照项目评审管理规范的规定，QA组织对需求分析说明书的评审 15 里程碑评审（可选） 完成项目里程碑报告并组织评审 16 概要设计 概要设计相关技术资料 17 设计文档编写 概要设计说明书 18概要设计评审（可选） 概要设计说明书的评审（建议详细设计或概要设计必须做一个正式评审）19 详细设计 详细设计相关工具和技术资料 20 文档编写 详细设计说明书 21 用户界面设计 用户界面设计说明书 22 数据库设计 数据库设计说明书 23 详细设计评审 设计评审记录项目评审报告 分析设计阶段分析设计管理规范24 里程碑评审（可选） 完成项目里程碑报告并组织评审 25
9、 编程 源代码 26 代码走查 代码走查检查单 27 单元测试 单元测试报告 实现开发阶段产品实现管理规范28 初步完成三大手册初步完成系统安装手册用户操作手册项目维护手册 测试阶段 29 集成测试 测试bug 清单5项目测试管理规范30 测试文档 项目测试计划、测试用例、测试报告31 部署安装使用 系统部署用户确认书需要用户确认部署运行系统部署管理规范32 客户培训 客户培训签到表客户培训效果调查表32 内部验收 在正式部署之前完成。项目内部验收评审报告验收项目验收管理规范33 客户验收 客户验收计划、客户验收报告 34 结项申请 结项申请表 35 结项总结 结项总结报告 结项阶段项目结项管
10、理规范 36 总结会议 结项总结 37 维护计划审批 维护工作启动制定项目维护计划并通过审批 维护阶段项目运行维护管理规范38 维护报告 项目结束维护，完成项目维护总结报告 （3 ）优缺点该模型的优点： 阶段分明、活动明确，为软件开发工作提供一种结构化、有序的方法；过程控制可见性较强：按照顺序开展每一个阶段的工作，每一阶段是在上一阶段彻底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工；开发过程中的各项文档降低了沟通的成本，有利于及早发现问题，降低项目的阶段成本；文档多，过程记录比较全，有利于后期维护。该模型的缺点： 6不能回溯：项目从开始到发布可见的版本需要较长的周期，用
11、户直到项目开发晚期才能了解产品的真实面貌和质量，不易变更；如果必须回溯，则回溯成本很大。缺乏灵活性，不能跨阶段操作；文档多，花费较多成本。（4 ）适用范围产品定义（或项目需求）和技术方案非常明确、用户的需求有很好的了解； 对质量的要求高于对成本和进度的要求； 工期相对较宽裕；开发队伍技术力量较弱或缺乏经验；维护项目。2、迭代模型（1 ）基本思想迭代模型是RUP（Rational Unified Process，统一软件开发过程)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。在某种程度上，开发迭代是一次
12、完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。7图 2 迭代模型的思想示意图说明：迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；风险分析：分析评估所选方案，考虑如何识别和消除风险；实施工程：实施软件开发和验证；客户评估：评价开发工作，提出修正建议，制定下一步计划。迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产
13、品开发之中。使用迭代模型进行软件开发，项目活动包含以下几个阶段：初始阶段初始阶段有时也称先启阶段。初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。细化阶段8细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立
14、支持环境，包括创建开发案例，创建模板、准则并准备工具。 构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 交付阶段交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。图 3 迭代模型的几个阶段（2 ） WBS 划分实际采用迭代模型中，项目阶段仍可参考瀑布执行。
15、迭代模型实施重要的关键点是架构设计（概要设计）、制定迭代开发计划。阶段和项目标准过程 任务 工作成果名称9项目策划阶段项目策划管理规范完成项目实施计划项目实施计划中WBS分解要参考本表 项目迭代计划（）项目迭代开发计划 必须有架构设计（概要设计） 项目迭代开发计划必须说明哪些是关键迭代，完成的时机以及预期成果 下一个迭代，在前几个迭代基础上需要完善的要点以及完善步骤架构（概要）设计（）概要设计说明书 系统完成架构设计（概要设计） 需求分析 迭代1的需求分析，形成需求说明书 需求评审 关键迭代需要组织评审 详细设计 直接做详细设计，完成迭代设计说明书 文档编写 详细设计说明书 用户界面设计 用户
16、界面设计说明书 数据库设计 数据库设计说明书 编程 源代码 代码走查按照项目实施计划中质量控制点计划要求完成代码走查检查单 单元测试按照项目实施计划中质量控制点计划要求完成单元测试报告 详细需求分析、设计及实现第 1个迭代第一个迭代部署/集成按照项目迭代开发计划将迭代开发成果部署到统一架构中。 10第一个迭代集成测试 迭代后的开发成果部署到统一架构后做集成测试 详细需求分析、设计及实现第 2个迭代按照项目迭代开发计划中的规划实现，如果实现计划有变化需要变更该计划。 详细需求分析、设计及实现第N个迭代按照项目迭代开发计划中的规划实现，如果实现计划有变化需要变更该计划。 测试阶段项目测试管理规范所
17、有迭代按照项目迭代开发计划全部实现后，需要做系统测试。 （3 ）优缺点与传统的瀑布模型相比较，迭代模型具有以下优点： 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费；降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙；加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率；由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。迭代模型的缺点：风险管理成本较高：迭代模型本身强调风险，但风险管理本身也存在成本问题；如果风险管理成本过大，将会严重影响项目的利润；对项目组成员的要求非常高：在风险分析、进度管理等方面，需要有较高层次的人员配置及丰富的项目管理和项目实施的经验。这对于开发队伍技术力量较弱或缺乏经验的团队很难实施。
