软件产品WBS分解指南.docx

1、软件产品WBS分解指南WBS分解指 南-CAL-FENGHAI.-(YICAI)-Company One 1软件产品WBS分解指南一、 概述同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等 阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵 循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模 大，结构复杂和管理复杂的软件开发变的容易控制和管理。软件生命周期模型和项LI开发过程有非常紧密关系，它是经过多次实践总结出来适合于 不同项U使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依 照一定

2、的规则和步骤，有效地进行软件开发。选用恰当的软件主命周期模型进行软件开发，可以提高产品质量；降低项LI管理难度； 缩短开发进度；便于项L1状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势， 提高过程能力成熟度级别。为了便于分类汇总和统讣各种生命周期模型的指标和数据，结合公司软件开发过程的实 际，我们选择了常用的儿种基本模型进行了描述，项U开发小组在进行项LI策划时，可以根 据模型的适用前提、优缺点和项U的实际需要进行选择，并在项LI实施计划中，参加评 审。二、 软件生命周期模型常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。以上所提到的件生命周期模型病不存在孰优孰劣

3、的问题，每一种模型在实际工作中都有 所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。需要强调的是，不管釆用什么模型，项目实施中有四项活动是必不可少的一一需求、设 计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项U过程中。这也是最重 要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是 评审等等。以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure,即工作分解结构）、优缺点、使用范围进行分析。1、瀑布模型(1)基本思想瀑布模型(Waterfall Model)是最基本也最常用的一种

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

5、 个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工 作，所以项U必须有明确的阶段里程碑，在每个阶段结束时都要进行里程碑评审，以判定是 否可以开始下一阶段的工作。例如：在项U策划没有完成时，需求分析和设计工作就不能进 行，同样，在需求分析和设计没有完成时就不开始编码。瀑布模型中，每个阶段完成后， 可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理，如果发生说明:图中标记为的阶段为选定的里程碑，该阶段完成时需进行里程碑评审活动，并对其输出进行严格的变更控制。（2）WBS划分此表仅作为参考，需根据项IJ所选定的标准过程的活动和任务进一步细化。阶段和

6、 项目标准过程ID任务工作成果名称项目策划阶段 项目策划管 理规范1起草项目任务书项目任务书2审批项目任务书已批准的项目任务书3策划准备项目实施计划4启动项目策划产品的功能结构图、WBSI：作任务分解5项目估计和成果列表项目实施计划：工作量估计，进度计划，人力资源计 划，软/硬件、工具要求，风险管理讣划，培训计划，沟通计 划，交付工作产品淸单等6制订项目计划项目实施il划（有些客户需要质量保证计划（方 案）.配置管理计划（方案）等相关计划）7项目计划评审按照项目评审管理规范的规立，QA组织对项目实施计 划组织评审,直到通过评审8审批项目计划项目实施计划获得相关领导的审批需求分析阶段 需求开发与

7、 管理规范9需求调研开始按照需求调研讣划，釆取需求调研记录表进行 调研，完成系统需求分析说明书初稿10需求分析如果客户需求不淸晰需要密切跟踪，要完成需求调研记录 跟踪矩阵、需求不一致项列表11需求不一致项 协商处理相关修订文档，可能包括系统需求分析说明书和需求 不一致项列表等文件12需求规格说明书完善系统需求分析说明书正式稿、需求跟踪管理表13需求验证需求同级评审相关记录。验证后的系统需求分析说明书.需求跟踪管理表14需求分析阶段评审按照项目评审管理规范的规立，QA组织对需求分析说 明书的评审15里程碑评审（可选）完成项目里程碑报告并组织评审分析设计阶段 分析设计管 理规范16概要设计概要设计

8、相关技术资料17设计文档编写概要设计说明书18概要设计评审（可 选）概要设计说明书的评审（建议详细设讣或概要设汁必须 做一个正式评审）19详细设计详细设计相关工具和技术资料20文档编写详细设计说明书21用户界而设计用户界而设计说明书22数据库设计数据库设计说明书23详细设计评审设计评审记录项目评审报告24里程碑评审（可选）上成项目里程碑报告并组织评审实现开发阶段 产品实现管 理规范25编程源代码26代码走查代码走查检查单27单元测试单元测试报告28初步完成三大手册初步完成系统安装手册用户操作手册项目维护手 册测试阶段 项目测试管理规范29集成测试测试bug淸单30测试文档项目测试计划、测试用例

9、、测试报告部署运行 系统部署管理规范31部署安装使用系统部署用户确认书需要用户确认32客户培训客户培训签到表客户培训效果调査表验收 项目验收管 理规范32内部验收在正式部署之前完成。项目内部验收评审报告33客户验收客户验收计划、客户验收报告结项阶段 项目结项管理规范34结项申请结项申请表35结项总结结项总结报告36总结会议结项总结维护阶段 项目运行维 护管理规范37维护计划审批维护工作启动制定项目维护计划并通过审批38维护报告项目结束维护，完成项目维护总结报告（3） 优缺点该模型的优点：1阶段分明、活动明确，为软件开发工作提供一种结构化、有序的方法；2过程控制可见性较强：按照顺序开展每一个阶段

10、的工作，每一阶段是在上一阶段彻 底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工；3开发过程中的各项文档降低了沟通的成本，有利于及早发现问题，降低项LI的阶段成 本；4文档多，过程记录比较全，有利于后期维护。该模型的缺点：1不能回溯：项LI从开始到发布可见的版本需要较长的周期，用户直到项LI开发晚期 才能了解产品的真实面貌和质量，不易变更；如果必须回溯，则回溯成本很大。2缺乏灵活性，不能跨阶段操作；3文档多，花费较多成本。（4） 适用范围1产品定义（或项U需求）和技术方案非常明确、用户的需求有很好的了解；2对质量的要求高于对成本和进度的要求；3工期相对较宽裕；4开发队伍技

11、术力量较弱或缺乏经验；5维护项LI。2、迭代模型（1）基本思想迭代模型是RUP （Rational Unified Process,统一软件开发过程）推荐的周期模型。在RUP 中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和 要使用该发布必需的所有其他外圉元素。在某种程度上，开发迭代是一次完整地经过所有工 作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项 Uo RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产 品，这个产品是最终产品的一个子集。说明：迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了以下

12、活动：1制定计划：确定软件U标，选定实施方案，弄清项LI开发的限制条件；2风险分析：分析评估所选方案，考虑如何识别和消除风险；3实施工程：实施软件开发和验证；4客户评估：评价开发工作，提出修正建议，制定下一步计划。迭代模型山风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质 量作为特殊U标融入产品开发之中。使用迭代模型进行软件开发，项LI活动包含以下儿个阶段：1初始阶段初始阶段有时也称先启阶段。初始阶段的U标是为系统建立商业案例并确定项U的边 界。为了达到该LI的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。 本阶段具有非常重要的意义，在这个阶段中所关注的是整个

13、项进行中的业务和需求方面的 主要风险。对于建立在原有系统基础上的开发项U来讲，初始阶段可能很短。2细化阶段细化阶段的U标是分析问题领域，建立健全的体系结构基础，编制项LT计划，淘汰项U 中最高风险的元素。为了达到该LI的，必须在理解整个系统的基础上，对体系结构做出决 策，包括其范圉、主要功能和诸如性能等非功能需求。同时为项口建立支持环境，包括创建 开发案例，创建模板、准则并准备工具。3构造阶段在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细 测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制运作以优化 成本、进度和质量。4交付阶段交付阶段的重点是

14、确保软件对最终用户是可用的。交付阶段可以跨越儿次迭代，包括为 发布做准备的产品测试，基于用户反馈的少量的调整。在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项LI生命 周期的早期阶段解决了。魏 蛇 部痔 核补支菇工住逐配 現甘言理 达代图3迭代模型的几个阶段（2）WBS划分实际采用迭代模型中，项LI阶段仍可参考瀑布执行。迭代模型实施重要的关键点是架构设计（概要设计）、制定迭代开发计划。阶段和 项目标准过程任务工作成果名称项目策划阶段 项目策划管理规范完成项目实施计 划项目实施计划中WBS分解要参考本表项目迭代计划（）项目迭代开发计 划必

15、须有架构设计（概要设计）项目迭代开发计划必须说明哪些是关键迭 代，完成的时机以及预期成果下一个迭代.在前几个迭代基础上需要完善的 要点以及完善步骤架构（概要）设计（）概要设计说明书系统完成架构设计（概要设计）详细需求分析.设计及 实现第1个迭代需求分析迭代2的需求分析，形成需求说明书需求评审涯迭代需要组织评审详细设计直接做详细设计，完成迭代设计说明书文档编写详细设计说明书用户界而设计用户界而设计说明书数据库设计数据库设计说明书编程源代码代码走查按照项目实施计划中质量控制点计划要求完成 代码走查检查单单元测试按照项目实施计划中质量控制点计划要求完成 单元测试报告第一个迭代部署/集成按照项目迭代开

16、发计划将迭代开发成果部署到 统一架构中。第一个迭代集成测试迭代后的开发成果部署到统一架构后做集成测试详细需求分析、设计及 实现第2个迭代按照项目迭代开发计划中的规划实现，如果实 现计划有变化需要变更该计划。 详细需求分析.设计及 实现第N个迭代 按照项目迭代开发计划中的规划实现，如果实 现计划有变化需要变更该计划。测试阶段项目测试管理规范所有迭代按照项目迭代开发计划全部实现后， 需要做系统测试。（3）优缺点与传统的瀑布模型相比较，迭代模型具有以下优点：1降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一 个开发有误的迭代的花费；2降低了产品无法按照既定进度进入市场的风险。

17、通过在开发早期就确定风险，可以 尽早来解决而不至于在开发后期匆匆忙忙；3加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率；4山于用户的需求并不能在一开始就做出完全的界定，它们通常是在后续阶段中不断 细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。迭代模型的缺点：1风险管理成本较高：迭代模型本身强调风险，但风险管理本身也存在成本问题；如 果风险管理成本过大，将会严重影响项LI的利润；2对项LI组成员的要求非常高：在风险分析、进度管理等方面，需要有较高层次的人 员配置及丰富的项II管理和项U实施的经验。这对于开发队伍技术力量较弱或缺乏 经验的团队很难实施。（

18、4）适用范围1在项U开发早期需求可能有所变化；2分析设汁人员对应用领域很熟悉；3高风险项U；4用户可不同程度地参与整个项口的开发过程；5使用面向对象的语言或统一建模语言（Unified Modeling Language, UML）；6使用CASE （Computer Aided Software Engineering,讣算机辅助软件工程）工具，如 Rose （Rose是非常受欢迎的物件软体开发工具）；7具有高素质的项LI管理者和软件研发团队。3、增量模型（1）基本思想增量模型是通过对用户需求的判断，在定义了用户要求和系统需求，进行总体构架设汁 后，采用序列化地创建产品的方法进行开发的过程。

19、每一个线性序列产生软件的一个可发布 的“增量”，笫一个建立的增量完成预计功能/性能的一部分（往往包含了核心功能，即实 现了基本的需求），下一个增量实现另外的部分，增加更多的功能/性能，然后与前面实现 的增加进行集成，如此循环，直到系统完全实现。增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增 量包出来即可进行开发。虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只 要这个增量包足够小，其影响对整个项口来说是可以承受的。其实现过程简图如下所示：图4增量模型的思想示总图说明：在策划阶段，项U经理需要与客户协商确定增量的数U、规模、侮一增量发布的时间 表，在概要设

20、计阶段需要考虑各增量集成的顺序、接口等问题，制定集成策略。增量循环的循环体可以根据项L1的实际情况进行控制。增量模型本质上是迭代的，但其强调每一个增量均发布一个可操作产品。早期的增量是 最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。（2）WBS划分阶段和 项目标准过程任务工作成果名称概要设计概要设计概要设计相关技术资料、设计文档编写概要设计说明书概要设计评审（必须）设计评审记录设计实现开发第一个增量（如A模块）详细设计A模块详细设计文档编写详细设计说明书用户界面设计用户界面设计说明书数据库设计数据库设计说明书编程源代码代码走查代码走查检查单单元测试单元测试报告

21、第一个增量测试增量产品测试发布第一个增虽增量产品发布和部署设计实现 开发第一个增量（如B模块）详细设计B模块详细设计文档编写详细设计说明书用户界面设计用户界面设计说明书数据库设计数据库设计说明书编程源代码代码走查代码走查检查单单元测试单元测试报告第一个增量测试增量产品测试发布第一个增疑增星产品发布和部署 开发第N个增咼 - (3)优缺点该模型的优点：1在达到初始需求之前可降低成本：采用增量模型可以灵活分配人员，刚开始不用投 入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量；2可快速生产出可使用的系统：它提供了一种先推出核心产品的途径，这样即可先发 布部分功能给客户，对客户起到镇

22、静剂的作用；3能够有计划地管理技术风险。该模型的缺点：1系统集成难度大：由于各个构件是逐渐并入已有的软件体系结构中的，各增量的集 成难度增大，所以在概要设计阶段需要制定详细的集成策略；2项口管理风险加大：在开发过程中，需求的变化是不可避免的，增量模型的灵活性 可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化 为边做边改模型，从而使软件过程的控制失去整体性。(4)适用范围1用户核心需求非常清楚；2项目人员不足；3产品可以分割成不同的阶段分别完成。4、原型模型(1)基本思想原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正反映用户的需 求。同时，原型模型釆用逐

23、步求精的方法完善原型，使得原型能够“快速”开发，避免了像 瀑布模型一样在冗长的开发过程中难以对用户的反馈做出快速的响应。相对瀑布模型而言， 原型模型更符合人们开发软件的习惯，使U前较流行的一种实用软件生存期模型。原型模型是一种用户需求驱动的方法，使得用户在系统生存周期的设计阶段起到积极的 作用；它能减少系统开发的风险，特别是在大型项U的开发中川1于对项U需求的分析难以 一次完成，应用原型法效果更为明显。原型模型根据其最终保留情况分为非抛弃型和抛弃型两种：非抛弃型原型是先根据用户的最主要的要求，开发出能实现系统最基本功能的一个原 型，再根据用户对原型使用与评价的意见，反复修改完善原型，直到等到用

24、户满意的最终系 统为止。原型模型从需求收集开始，软件开发组与U标用户一起定义软件的总体U标，标识出已 知的需求，并规划出进一步定义的区域。然后是“快速设计”。快速设计建立软件中对用户 可见的部分，即“原型”。原型由用户评估，并据此进一步精化用户需求。逐步调整原型使 其满足用户的要求，同时也使开发组对该软件有更好的理解，这个过程是迭代的，每一个迭 代完成后均可生成一个可用的产品版本。抛弃型原型模型一般用来描述和验证用户需求，可以釆用与实际开发所不同的开发工 具，建立模拟的数据库系统，从而达到与用户交流的最好效果。到用户需求确定之后即不再 继续开发此原型。与非抛弃型原型模型的主要区别在于：1U的不

25、同，抛弃型原型模型的U的是为了与用户更好的沟通；2手段不同，抛弃型原型模型釆用的技术手段与正式开发可以完全不同；3结果不同，抛弃型原型模型的工作产品不会在软件研发中使用或大量使用，而多用于 开发dem。及验证用户需求的复合性。使用原型模型进行软件开发，项U活动包含以下儿个阶段：1确定用户需求阶段软件项LI负责人员根据用户意向或市场调研等前期准备的资料、文档，对用户需求进行分析，编写用户需求文档。2建造/修改原型阶段项U组根据原型评价结果对设计原型进行建立、修改和完善，并记录相关过程。3运行/评价原型阶段项LI负责人协同市场人员与用户对设讣原型进行评价和讨论，明确设计原型中要保留的 和需去除的原

26、型设计部分，提出需要进一步补充和完善的需求内容。重复上述过程，直至 用户需求全部明确为止。各阶段需要遵循的项U标准过程参见pd项LI标准过程裁剪指 南。图6原型模型开发的几个阶段（2）WBS划分非抛弃型原型模型的WBS划分阶段和过程ID从过程中选取任务工作成果名称用户需求分析 需求开发与管理规 范1获取用户需求需求调研记录单2建立系统需求需求分析说明书3验证需求已经验证的软件系统需求建造/修改原型 产品实现管理规范4搭建开发环境开发环境5编写代码源代码.产品原型运行/评价原型6运行评价原型更新后需求分析说明书抛弃型原型模型的WBS划分任务类型ID任务工作成果洛称用户需求分析1需求调查和分析需求

27、调研记录单建造/修改原型2用户界面设计原型界面3与用户交流修改界面修改后的原型界面4建立模拟数据库模拟数据库5开发源代码，原型6功能测试及修改测试记录和通过测试的工作产品运行/评价原型7原型运行问题记录表8评价原型原型评价表（3）优缺点该模型的优点：1符合人们认识事物的规律，系统开发循序渐进，反复修改，确保较好的用户满意度；2开发周期短，费用相对少；3山于有用户的直接参与，系统更加贴近实际，易学易用，减少用户的培训时间；该模型的缺点：1开发过程管理要求高，整个开发过程要经过“修改一评价一再修改”的多次反复；2用户过早看到系统原型，误认为系统就是这个模样，易使用户失去信心；3开发人员易将原型取代

28、系统分析；4缺乏规范化的文档资料，不利于系统的后期维护。（4）适用范围该模型适合于：1处理简单过程明确、涉及面窄的小型系统：2大型系统的需求阶段，用原型去跟用户交流，需求分析会更加明确和细化。该模型不适合于：1大型、复杂系统，难以模拟；2存在大量运算、逻辑性强的处理系统；3管理基础工作不完善、处理过程不规范的系统；4大量批处理的系统。三、软件生命周期模型的选择在众多的开发模型和过程方法中，企业应选择什么样的开发模型，应从以下儿方面进行 慎重考虑：1实施推广的难度虽然各种开发模型的内容极其丰富，定义项各个阶段的活动，并提供了一大堆的文档 模板，但是各个开发模型的实施最终还是依靠人。项LI管理团队的管理能力和系统开发团队 的技术能力决定了所选择开发模型的实施难度。选择一个适合项U团队特点的开发模型尤为 重要。2、项LI管理的侧重点以上各个开发模型的过程特点也各不相同，如瀑布模型是文档驱动型的，迭代模型是风 险驱动型的，增量模型是任务驱动型的，原型模型是需求驱动型的。项U不同，其侧重点也不同，如侧重于进度、质量、成本控制、风险管理等等。根据项 U的侧重点，可以选择不同的开发模型。总之，选择一个合适的生命周期模型，并应用正确的方法，对于任何软件项LI的成功是 至关重要。企业在选择开发模型应从项U时间要求、需求明确程度、风险状况等选择合适的 生命周期模型。