软件生命周期模型选择及WBS分解指南Word文件下载.docx
《软件生命周期模型选择及WBS分解指南Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件生命周期模型选择及WBS分解指南Word文件下载.docx（18页珍藏版）》请在冰豆网上搜索。
瀑布模型（WaterfallModel）是最基本也最常用的一种生命周期模型，又称线性模型。
瀑布模型是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
瀑布模型可以应用于软件工程开发、企业项目开发、产品生产以与市场销售等领域。
瀑布模型的突出特征是文档驱动。
从需求分析到系统维护，每一项活动的工作成果就是此项活动所产生的工作文档，以与在此基础上形成的产品。
采用瀑布模型的项目依照该模型选定的阶段顺序进行，每一个阶段的工作产品都是下一个阶段工作的输入，每一个阶段只有在上一个阶段通过检查，确认完成后才开始新的阶段工作，所以项目必须有明确的阶段里程碑，在每个阶段结束时都要进行里程碑评审，以判定是否可以开始下一阶段的工作。
例如：
在项目策划没有完成时，需求分析和设计工作就不能进行，同样，在需求分析和设计没有完成时就不开始编码。
瀑布模型中，每个阶段完成后，可以在下一个阶段修改上一个阶段的工作产品，但是必须按照基线变更进行管理，如果发生变更，需要回溯前面所有阶段的工作产品，以便使工作产品保持一致。
图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
初步完成三大手册
初步完成《系统安装手册》《用户操作手册》《项目维护手册》
测试阶段
《项目测试管理规范》
29
集成测试
测试bug清单
30
测试文档
项目《测试计划》、《测试用例》、《测试报告》
部署运行
《系统部署管理规范》
31
部署安装使用
《系统部署用户确认书》需要用户确认
32
客户培训
《客户培训签到表》《客户培训效果调查表》
验收
《项目验收管理规范》
内部验收
在正式部署之前完成。
《项目内部验收评审报告》
33
客户验收
《客户验收计划》、《客户验收报告》
结项阶段
《项目结项管理规范》
34
结项申请
《结项申请表》
35
结项总结
《结项总结报告》
36
总结会议
结项总结
维护阶段
《项目运行维护管理规范》
37
维护计划审批
维护工作启动制定《项目维护计划》并通过审批
38
维护报告
项目结束维护，完成《项目维护总结报告》
（3）优缺点
该模型的优点：
①阶段分明、活动明确，为软件开发工作提供一种结构化、有序的方法；
②过程控制可见性较强：
按照顺序开展每一个阶段的工作，每一阶段是在上一阶段彻底完成的情况下才启动，可以保证每一个阶段的开发质量都有保证，减少了返工；
③开发过程中的各项文档降低了沟通的成本，有利于与早发现问题，降低项目的阶段成本；
④文档多，过程记录比较全，有利于后期维护。
该模型的缺点：
①不能回溯：
项目从开始到发布可见的版本需要较长的周期，用户直到项目开发晚期才能了解产品的真实面貌和质量，不易变更；
如果必须回溯，则回溯成本很大。
②缺乏灵活性，不能跨阶段操作；
③文档多，花费较多成本。
（4）适用范围
①产品定义（或项目需求）和技术方案非常明确、用户的需求有很好的了解；
②对质量的要求高于对成本和进度的要求；
③工期相对较宽裕；
④开发队伍技术力量较弱或缺乏经验；
⑤维护项目。
2、迭代模型
（1）基本思想
迭代模型是RUP（RationalUnifiedProcess，统一软件开发过程）推荐的周期模型。
在RUP中，迭代被定义为：
迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：
需求、分析设计、实施和测试工作流程。
实质上，它类似小型的瀑布式项目。
RUP认为，所有的阶段都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
图2迭代模型的思想示意图
迭代模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
①制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件；
②风险分析：
分析评估所选方案，考虑如何识别和消除风险；
③实施工程：
实施软件开发和验证；
④客户评估：
评价开发工作，提出修正建议，制定下一步计划。
迭代模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
使用迭代模型进行软件开发，项目活动包含以下几个阶段：
①初始阶段
初始阶段有时也称先启阶段。
初始阶段的目标是为系统建立商业案例并确定项目的边界。
为了达到该目的必须识别所有与系统交互的外部实体，在较高层次上定义交互的特性。
本阶段具有非常重要的意义，在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风险。
对于建立在原有系统基础上的开发项目来讲，初始阶段可能很短。
②细化阶段
细化阶段的目标是分析问题领域，建立健全的体系结构基础，编制项目计划，淘汰项目中最高风险的元素。
为了达到该目的，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求。
同时为项目建立支持环境，包括创建开发案例，创建模板、准则并准备工具。
③构造阶段
在构建阶段，所有剩余的构件和应用程序功能被开发并集成为产品，所有的功能被详细测试。
从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源与控制运作以优化成本、进度和质量。
④交付阶段
交付阶段的重点是确保软件对最终用户是可用的。
交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量的调整。
在生命周期的这一点上，用户反馈应主要集中在产品调整，设置、安装和可用性问题，所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
图3迭代模型的几个阶段
实际采用迭代模型中，项目阶段仍可参考瀑布执行。
迭代模型实施重要的关键点是架构设计（概要设计）、制定迭代开发计划。
完成《项目实施计划》
《项目实施计划》中WBS分解要参考本表
项目迭代计划
（★）
《项目迭代开发计划》
●必须有架构设计（概要设计）
●《项目迭代开发计划》必须说明哪些是关键迭代，完成的时机以与预期成果
●下一个迭代，在前几个迭代基础上需要完善的要点以与完善步骤
架构（概要）设计（★）
概要设计说明书
系统完成架构设计（概要设计）
详细需求分析、设计与实现第1个迭代
迭代1的需求分析，形成《需求说明书》
需求评审
关键迭代需要组织评审
直接做详细设计，完成迭代《设计说明书》
《用户界面设计说明书
升级会员 