软件产品WBS分解指南.pdf

《软件产品WBS分解指南.pdf》由会员分享，可在线阅读，更多相关《软件产品WBS分解指南.pdf（23页珍藏版）》请在三一文库上搜索。

1、蚇软件产品 WBS 分解指南 薇一、概述 蒂同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般 称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件 生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的 容易控制和管理。 蒁软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使 用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有 效地进行软件开发。 蚈选用恰当的软件生命周期模型进行软件开发，可以提高产品质量

2、；降低项目管理难度；缩短开发进 度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。 蚆为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选 择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺 点和项目的实际需要进行选择，并在项目实施计划中，参加评审。 羁二、软件生命周期模型 芁常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。 螀以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只 要选择了最适合的，并按照此模型的流程来开发

3、软件，都会取得成功。 袄需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的需求、设计、编码和 测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活 动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。 蚅以下对各种常用的软件生命周期模型的设计思想、WBS 划分（ Work Breakdown Structure，即工作分 解结构）、优缺点、使用范围进行分析。 羂1、瀑布模型 薇（1）基本思想 膇瀑布模型（ Waterfall Model）是最基本也最常用的一种生命周期模型，又称线性模型。 肄瀑布模型是一个项目开发架构，开发过

4、程是通过设计一系列阶段顺序展开的，从系统需求分析开始 直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最 好 “ 返回 ” 上一个阶段并进行适当的修改，项目开发进程从一个阶段“ 流动 ” 到下一个阶段， 这也是瀑布模型 名称的由来。瀑布模型可以应用于软件工程开发、企业项目开发、产品生产以及市场销售等领域。 螂瀑布模型的突出特征是文档驱动。从需求分析到系统维护，每一项活动的工作成果就是此项活动所 产生的工作文档，以及在此基础上形成的产品。 薈采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作 的输入，每一个阶段只有在上

5、一个阶段通过检查，确认完成后才开始新的阶段工作，所以项目必须有明确 的阶段里程碑，在每个阶段结束时都要进行里程碑评审，以判定是否可以开始下一阶段的工作。例如：在 项目策划没有完成时，需求分析和设计工作就不能进行，同样，在需求分析和设计没有完成时就不开始编 码。瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线 变更进行管理，如果发生变更，需要回溯前面所有阶段的工作产品，以便使工作产品保持一致。 芅 袆（2）WBS 划分 螃说明： 莁图中标记为 的阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格 的变更控制。 芇（2）WBS 划分 羄此

6、表仅作为参考，需根据项目所选定的标准过程的活动和任务进一步细化。 膃阶段和 荿ID 莆任务薂工作成果名称 螂A 系统分析员 芆图 1 瀑布模型的思想示意图 膂项目标准过 程 袂项目策划阶 段 膆项目策划管 理规范 蒅1 羁起草项目任务书蚂项目任务书 袇2 蚅审批项目任务书腿已批准的项目任务书 羅3 膄策划准备衿项目实施计划 肄4 薃启动项目策划蕿产品的功能结构图、 WBS 工作任务分解 蒆5 羃项目估计和成果列表 莀项目实施计划：工作量估计，进度计划，人力资源计划， 软/硬件、工具要求，风险管理计划，培训计划，沟通计划， 交付工作产品清单等 薄6 莂制订项目计划 肀项目实施计划 （有些客户需要

7、 质量保证计划 （方案） 、 配置管理计划（方案）等相关计划） 羇7 袂项目计划评审 袁按照项目评审管理规范 的规定， QA 组织对 项目实施计 划组织评审 ,直到通过评审 肅8 薅审批项目计划薁项目实施计划获得相关领导的审批 聿需求分析阶 段 膄需求开发与 管理规范 羄9 莁需求调研袇开始按照需求调研计划，采取需求调研记录表进行 调研，完成系统需求分析说明书初稿 莄 10 肂需求分析 羈如果客户需求不清晰需要密切跟踪，要完成需求调研记录 跟踪矩阵、需求不一致项列表 袃 11 螂需求不一致项 罿协商处理 肇相关修订文档，可能包括系统需求分析说明书和需求 不一致项列表等文件 薂 12 螇需求规格

8、说明书完善膅系统需求分析说明书正式稿、需求跟踪管理表 聿 13 袈需求验证 芃需求同级评审相关记录。 肁验证后的系统需求分析说明书、需求跟踪管理表 罿 14 蚆需求分析阶段评审 螅按照项目评审管理规范 的规定， QA 组织对 需求分析说 明书的评审 蚇 15 螄里程碑评审（可选）芄完成项目里程碑报告并组织评审 芀分析设计阶 肇 蚃概要设计羀概要设计相关技术资料 段 螈分析设计管 理规范 16 芅 17 肃设计文档编写螁概要设计说明书 薇 18 蒂概要设计评审 （可选） 蒁概要设计说明书的评审（建议详细设计或概要设计必须 做一个正式评审） 蚆 19 羁详细设计芁详细设计相关工具和技术资料 袄 2

9、0 蚅文档编写羂详细设计说明书 膇 21 肄用户界面设计螂用户界面设计说明书 芅 22 蒄数据库设计腿数据库设计说明书 蚇 23 袃详细设计评审罿设计评审记录项目评审报告 螆 24 莂里程碑评审（可选）虿完成项目里程碑报告并组织评审 蕿实现开发阶 段 袄产品实现管 理规范 螂 25 蒀编程薀源代码 膁 26 膀代码走查莇代码走查检查单 袅 27 羀单元测试葿单元测试报告 芄 28 蚁初步完成三大手册 芆初步完成系统安装手册用户操作手册项目维护手 册 袆测试阶段 螃项目测试管 理规范 莁 29 芇集成测试羄测试 bug 清单 膂 30 荿测试文档莆项目测试计划、测试用例、测试报告 薂部署运行 袂

10、系统部署管 理规范 膆 31 蒅部署安装使用羁系统部署用户确认书需要用户确认 膈 32 袇客户培训蚅客户培训签到表客户培训效果调查表 腿验收 羅 32 膄内部验收衿在正式部署之前完成。项目内部验收评审报告 艿项目验收管 理规范 肄 33 薃客户验收蕿客户验收计划、客户验收报告 膈结项阶段 蒆项目结项管 理规范 羃 34 莀结项申请腿结项申请表 莂 35 肀结项总结羆结项总结报告 袂 36 袁总结会议肈结项总结 肅维护阶段 薅项目运行维 护管理规范 薁 37 维护计划审批维护工作启动制定项目维护计划并通过审批 38 维护报告项目结束维护，完成项目维护总结报告 （3）优缺点 该模型的优点： 阶段分

11、明、活动明确，为软件开发工作提供一种结构化、有序的方法； 过程控制可见性较强：按照顺序开展每一个阶段的工作，每一阶段是在上一阶段彻底完成的情况下 才启动，可以保证每一个阶段的开发质量都有保证，减少了返工； 开发过程中的各项文档降低了沟通的成本，有利于及早发现问题，降低项目的阶段成本； 文档多，过程记录比较全，有利于后期维护。 该模型的缺点： 不能回溯： 项目从开始到发布可见的版本需要较长的周期，用户直到项目开发晚期才能了解产品的 真实面貌和质量，不易变更；如果必须回溯，则回溯成本很大。 缺乏灵活性，不能跨阶段操作； 文档多，花费较多成本。 （4）适用范围 产品定义（或项目需求）和技术方案非常明

12、确、用户的需求有很好的了解； 对质量的要求高于对成本和进度的要求； 工期相对较宽裕； 开发队伍技术力量较弱或缺乏经验； 维护项目。 2、迭代模型 （1）基本思想 迭代模型是 RUP （Rational Unified Process，统一软件开发过程) 推荐的周期模型。在RUP 中，迭代 被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所 有其他外围元素。在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实 施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP 认为，所有的阶段都可以细分为迭代。每一 次的迭代都会产生一个可以

13、发布的产品，这个产品是最终产品的一个子集。 图 2 迭代模型的思想示意图 说明： 迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； 风险分析：分析评估所选方案，考虑如何识别和消除风险； 实施工程：实施软件开发和验证； 客户评估：评价开发工作，提出修正建议，制定下一步计划。 迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目 标融入产品开发之中。 使用迭代模型进行软件开发，项目活动包含以下几个阶段： 初始阶段 初始阶段有时也称先启阶段。初始阶段的目标是为系统建立商业案例并确定项目的

14、边界。为了达到该 目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。本阶段具有非常重要的意义， 在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。对于建立在原有系统基础上的开 发项目来讲，初始阶段可能很短。 细化阶段 细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划， 淘汰项目中最高风险的 元素。为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和 诸如性能等非功能需求。同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。 构造阶段 在构建阶段， 所有剩余的构件和应用程序功能被开发并集成为产品，所

15、有的功能被详细测试。从某种 意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化成本、进度和质量。 交付阶段 交付阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的 产品测试， 基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、 安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。 图 3 迭代模型的几个阶段 （2） WBS划分 实际采用迭代模型中，项目阶段仍可参考瀑布执行。迭代模型实施重要的关键点是架构设计（概要设 计）、制定迭代开发计划。 阶段和 项目标准过程 任务工作成果名称 项目

16、策划阶段完成项目实施计划项目实施计划中WBS 分解要参考本表 项目策划管理规范 项目迭代计划 （） 项目迭代开发计划 必须有架构设计（概要设计） 项目迭代开发计划必须说明哪些是关键迭 代，完成的时机以及预期成果 下一个迭代，在前几个迭代基础上需要完善的要 点以及完善步骤 架构（概要）设计（）概要设计说明书系统完成架构设计（概要设计） 详细需求分析、设计及 实现第 1个迭代 需求分析迭代 1的需求分析，形成需求说明书 需求评审关键迭代需要组织评审 详细设计直接做详细设计，完成迭代设计说明书 文档编写详细设计说明书 用户界面设计用户界面设计说明书 数据库设计数据库设计说明书 编程源代码 代码走查

17、按照 项目实施计划 中质量控制点计划要求完成代 码走查检查单 单元测试 按照 项目实施计划 中质量控制点计划要求完成单 元测试报告 第一个迭代部署/集成 按照项目迭代开发计划将迭代开发成果部署到统 一架构中。 第一个迭代集成测试迭代后的开发成果部署到统一架构后做集成测试 详细需求分析、设计及按照项目迭代开发计划中的规划实现， 如果实现 实现第 2个迭代计划有变化需要变更该计划。 详细需求分析、设计及 实现第 N个迭代 按照项目迭代开发计划中的规划实现， 如果实现 计划有变化需要变更该计划。 测试阶段 项目测试管理规范 所有迭代按照 项目迭代开发计划全部实现后， 需 要做系统测试。 （3）优缺点

18、 与传统的瀑布模型相比较，迭代模型具有以下优点： 降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭 代的花费； 降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不 至于在开发后期匆匆忙忙； 加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率； 由于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断细化的。因此， 迭代过程这种模式使适应需求的变化会更容易些。 迭代模型的缺点： 风险管理成本较高：迭代模型本身强调风险，但风险管理本身也存在成本问题；如果风险管理成本 过大，将会严重

19、影响项目的利润； 对项目组成员的要求非常高：在风险分析、 进度管理等方面，需要有较高层次的人员配置及丰富的 项目管理和项目实施的经验。这对于开发队伍技术力量较弱或缺乏经验的团队很难实施。 （4）适用范围 在项目开发早期需求可能有所变化； 分析设计人员对应用领域很熟悉； 高风险项目； 用户可不同程度地参与整个项目的开发过程； 使用面向对象的语言或统一建模语言（Unified Modeling Language，UML ）； 使用 CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具， 如Rose（ Rose 是非常受欢迎的物件软体开发工具）；

20、 具有高素质的项目管理者和软件研发团队。 3、增量模型 （1）基本思想 增量模型是通过对用户需求的判断，在定义了用户要求和系统需求, 进行总体构架设计后，采用序列 化地创建产品的方法进行开发的过程。每一个线性序列产生软件的一个可发布的“增量”，第一个建立 的增量完成预计功能/ 性能的一部分（往往包含了核心功能，即实现了基本的需求），下一个增量实现另 外的部分，增加更多的功能/ 性能，然后与前面实现的增加进行集成，如此循环，直到系统完全实现。 增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可 进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，

21、但只要这个增量包足够小，其影 响对整个项目来说是可以承受的。其实现过程简图如下所示： 图 4 增量模型的思想示意图 说明： 在策划阶段，项目经理需要与客户协商确定增量的数目、规模、每一增量发布的时间表，在概要设计 阶段需要考虑各增量集成的顺序、接口等问题，制定集成策略。 增量循环的循环体可以根据项目的实际情况进行控制。 增量模型本质上是迭代的，但其强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可 拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。 （2） WBS划分 阶段和 项目标准过程 任务工作成果名称 概要设计 概要设计概要设计相关技术资料、 设计文档编写概要

22、设计说明书 概要设计评审（必须）设计评审记录 设计实现 开发第一个增量 （如 A模块） 详细设计A模块详细设计 文档编写详细设计说明书 用户界面设计用户界面设计说明书 数据库设计数据库设计说明书 编程源代码 代码走查代码走查检查单 单元测试单元测试报告 第一个增量测试增量产品测试 发布第一个增量增量产品发布和部署 设计实现 开发第二个增量 （如 B模块） 详细设计B模块详细设计 文档编写详细设计说明书 用户界面设计用户界面设计说明书 数据库设计数据库设计说明书 编程源代码 代码走查代码走查检查单 单元测试单元测试报告 第一个增量测试增量产品测试 发布第一个增量增量产品发布和部署 开发第 N个增

23、量 （3）优缺点 该模型的优点： 在达到初始需求之前可降低成本：采用增量模型可以灵活分配人员，刚开始不用投入大量人力资源。 如果核心产品很受欢迎，则可增加人力实现下一个增量； 可快速生产出可使用的系统：它提供了一种先推出核心产品的途径，这样即可先发布部分功能给客 户，对客户起到镇静剂的作用； 能够有计划地管理技术风险。 该模型的缺点： 系统集成难度大：由于各个构件是逐渐并入已有的软件体系结构中的，各增量的集成难度增大，所 以在概要设计阶段需要制定详细的集成策略； 项目管理风险加大：在开发过程中， 需求的变化是不可避免的，增量模型的灵活性可以使其适应这 种变化的能力大大优于瀑布模型和快速原型模型

24、，但也很容易退化为边做边改模型，从而使软件过 程的控制失去整体性。 （4）适用范围 用户核心需求非常清楚； 项目人员不足； 产品可以分割成不同的阶段分别完成。 4、原型模型 （1）基本思想 原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需求。同时， 原 型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发 过程中难以对用户的反馈做出快速的响应。相对瀑布模型而言，原型模型更符合人们开发软件的习惯，使 目前较流行的一种实用软件生存期模型。 原型模型是一种用户需求驱动的方法，使得用户在系统生存周期的设计阶段起到积极的作用；它能减 少

25、系统开发的风险，特别是在大型项目的开发中, 由于对项目需求的分析难以一次完成，应用原型法效果 更为明显。 图 5 原型模型的思想示意图 原型模型根据其最终保留情况分为非抛弃型和抛弃型两种： 非抛弃型原型是先根据用户的最主要的要求，开发出能实现系统最基本功能的一个原型，再根据用户 对原型使用与评价的意见，反复修改完善原型，直到等到用户满意的最终系统为止。 原型模型从需求收集开始，软件开发组与目标用户一起定义软件的总体目标，标识出已知的需求，并 规划出进一步定义的区域。然后是“快速设计”。快速设计建立软件中对用户可见的部分，即“原型”。原型由 用户评估，并据此进一步精化用户需求。逐步调整原型使其满

26、足用户的要求，同时也使开发组对该软件有 更好的理解，这个过程是迭代的，每一个迭代完成后均可生成一个可用的产品版本。 抛弃型原型模型一般用来描述和验证用户需求，可以采用与实际开发所不同的开发工具，建立模拟的 数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再继续开发此原型。 与非抛弃型原型模型的主要区别在于： 目的不同，抛弃型原型模型的目的是为了与用户更好的沟通； 手段不同，抛弃型原型模型采用的技术手段与正式开发可以完全不同； 结果不同，抛弃型原型模型的工作产品不会在软件研发中使用或大量使用，而多用于开发demo 及 验证用户需求的复合性。 使用原型模型进行软件开发，项目活动包含

27、以下几个阶段： 确定用户需求阶段 软件项目负责人员根据用户意向或市场调研等前期准备的资料、文档， 对用户需求进行分析，编写用 户需求文档。 建造 /修改原型阶段 项目组根据原型评价结果对设计原型进行建立、修改和完善，并记录相关过程。 运行 /评价原型阶段 项目负责人协同市场人员与用户对设计原型进行评价和讨论，明确设计原型中要保留的和需去除的原 型设计部分，提出需要进一步补充和完善的需求内容。重复上述过程，直至用户需求全部明确为止。各 阶段需要遵循的项目标准过程参见PD项目标准过程裁剪指南。 图 6 原型模型开发的几个阶段 （2） WBS划分 非抛弃型原型模型的WBS 划分 阶段和过程ID 从过

28、程中选取任务工作成果名称 用户需求分析 需求开发与管理规范 1 获取用户需求需求调研记录单 2 建立系统需求需求分析说明书 3 验证需求已经验证的软件系统需求 建造 / 修改原型 产品实现管理规范 4 搭建开发环境开发环境 5 编写代码源代码、产品原型 运行 / 评价原型6 运行评价原型更新后需求分析说明书 抛弃型原型模型的WBS 划分 任务类型ID 任务工作成果名称 用户需求分析1 需求调查和分析需求调研记录单 建造 / 修改原型 2 用户界面设计原型界面 3 与用户交流修改界面修改后的原型界面 4 建立模拟数据库模拟数据库 5 开发源代码，原型 6 功能测试及修改测试记录和通过测试的工作产

29、品 运行 / 评价原型 7 原型运行问题记录表 8 评价原型原型评价表 （3）优缺点 该模型的优点： 符合人们认识事物的规律，系统开发循序渐进，反复修改，确保较好的用户满意度； 开发周期短，费用相对少； 由于有用户的直接参与，系统更加贴近实际，易学易用，减少用户的培训时间； 该模型的缺点： 开发过程管理要求高，整个开发过程要经过“修改评价再修改”的多次反复； 用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心； 开发人员易将原型取代系统分析； 缺乏规范化的文档资料，不利于系统的后期维护。 （4）适用范围 该模型适合于： 处理简单过程明确、涉及面窄的小型系统； 大型系统的需求阶段，用

30、原型去跟用户交流，需求分析会更加明确和细化。 该模型 不适合于： 大型、复杂系统，难以模拟； 存在大量运算、逻辑性强的处理系统； 管理基础工作不完善、处理过程不规范的系统； 大量批处理的系统。 三、软件生命周期模型的选择 在众多的开发模型和过程方法中，企业应选择什么样的开发模型，应从以下几方面进行慎重考虑： 1、实施推广的难度 虽然各种开发模型的内容极其丰富，定义项目各个阶段的活动，并提供了一大堆的文档模板，但是各 个开发模型的实施最终还是依靠人。项目管理团队的管理能力和系统开发团队的技术能力决定了所选择开 发模型的实施难度。选择一个适合项目团队特点的开发模型尤为重要。 2、项目管理的侧重点

31、以上各个开发模型的过程特点也各不相同，如瀑布模型是文档驱动型的，迭代模型是风险驱动型的， 增量模型是任务驱动型的，原型模型是需求驱动型的。 项目不同，其侧重点也不同，如侧重于进度、质量、成本控制、风险管理等等。根据项目的侧重点， 可以选择不同的开发模型。 总之，选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项目的成功是至关重要。企 业在选择开发模型应从项目时间要求、需求明确程度、风险状况等选择合适的生命周期模型。 仅供个人用于学习、研究；不得用于商业用途。 For personal use only in study and research; not for commercial

32、 use. Nur f r den pers?nlichen fr Studien, Forschung, zu kommerziellen Zwecken verwendet werden. Pour l tude et la recherche uniquement des fins personnelles; pas des fins commerciales. , , . 以下无正文 仅供个人用于学习、研究；不得用于商业用途。 For personal use only in study and research; not for commercial use. Nur f r den pers?nlichen fr Studien, Forschung, zu kommerziellen Zwecken verwendet werden. Pour l tude et la recherche uniquement des fins personnelles; pas des fins commerciales. , , . 以下无正文