软件生命周期模型选用指南[1].20130321.172544.doc

深圳天源迪科信息技术股份有限公司深圳天源迪科信息技术股份有限公司 文件编号 DIC QMD 851 12 版 本 5 1 软件生命周期模型软件生命周期模型 选用指南选用指南 自批准之日起实施 本文件属深圳天源迪科信息技术股份有限公司所有 未经书面许可 不得以任何形式复印或传播 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 2 页 共 14 页 文件建立文件建立 修改记录修改记录 序号版本建立或修改 建立 修改人 日期 审核人 日期 批准人 日期 14 0 建立 叶茂瑶 2007 7 20 陈庆山 2007 7 30 汪东升 2007 8 30 24 1 修订 陈志强 2007 12 11 陈庆山 2008 01 18 汪东升 2008 1 20 35 0 修订 在原来基础上区分 了模型的优点 缺 点及适用项目的说 明 汪冉冉 2012 8 20 肖征 2012 9 25 肖征 2012 9 25 55 1 修订 在第 3 章模型比较 中 增加了适用项 目类型和团队规模 的说明 汪冉冉 2013 2 20 肖征 2013 2 25 肖征 2013 2 25 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 3 页 共 14 页 目目 录录 1简介 4 1 1目的 4 1 2适用范围 4 1 3背景描述 4 1 4术语表 4 1 5参考资料 4 2软件生命周期模型描述 4 2 1瀑布模型 4 2 2改进的瀑布模型 6 2 3原型 瀑布模型 8 2 4增量模型 9 2 5增量的迭代过程模型 10 2 6V 模型 11 3模型的比较 13 4其它模型采用说明 13 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 4 页 共 14 页 1 1 1 简介简介简介 1 11 11 1 目的目的目的 建立和维护公司内部定义的软件生命周期模型 并供各软件项目组在项目计划时根据 项目的具体情况选择或裁剪使用 由此确定软件项目开发过程的各种不同的阶段以及各 阶段的执行顺序 1 21 21 2 适用范围适用范围适用范围 本文档适用于公司內软件研发类和工程类项目计划 1 31 31 3 背景描述背景描述背景描述 无 1 41 41 4 术语表术语表术语表 软件生命周期 软件生命周期 始于一个软件初始的想法 止于软件产品不再被使用 软件生命周期 一般包括系统分析 软件需求分析 设计 实现 测试 验收 运行和维护各阶段 软件过程 软件过程 有关开发和维护软件及其相关产品 例如 项目计划 设计文档 代码 测试用例 用户手册等 的活动 方法 实践和变更的集合 1 51 51 5 参考参考参考资料资料资料 软件项目管理案例教程 韩万江 姜立新编著 机械工业出版社 2005 年 2 月 2 2 2 软件生命周期模型描述软件生命周期模型描述软件生命周期模型描述 所有的项目软件开发过程都应遵循一个生命周期模型 每个模型都具有能够帮助实际软 件项目进行控制及协调的特征 定义生命周期模型的目的在于将本质上无序的活动有序化 在项目计划期间 必须仔细考虑项目的特征和目标之后 再选择生命周期模型 本指南描 述常用的几个软件生命周期模型 项目可根据实际情况选择或按规定剪裁使用 但应注意 与公司的标准软件开发过程相兼容 2 12 12 1 瀑布模型瀑布模型瀑布模型 2 1 12 1 12 1 1模型描述模型描述模型描述模型描述 瀑布模型又称线性顺序模型 也称为传统模型 要求软件开发严格按照需求 分析 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 5 页 共 14 页 设计 编码 测试 验收 维护的阶段进行 模型中一个阶段的输出是下一阶段的输 入 所以在每个阶段完成后都要组织相关的评审和验证 只有在评审通过 相关的产出 物都已经基线后才能够进入到下一个阶段 瀑布模型中每一个阶段都不应该重叠 一个 阶段完成后 一般不能返回到上一个阶段 瀑布模型的开发流程如图 2 1 系统分析 软件需求分析 设计 实现 测试 验收 维护 用户需求 软件需求 原型 设计文档 代码文件 测试文档 验收文档 维护记录 图图 2 1 瀑布模型 瀑布模型 2 1 22 1 22 1 2模型优点模型优点模型优点模型优点 线性顺序的开发过程 一个过程顺着一个过程进行 简单 易用 直观 项目人员分阶段投入 强调早期计划 及需求获取的完整性和稳定性 一次性开发出一个完整的系统 易于划分里程碑 便于监督和控制 2 1 32 1 32 1 3模型缺点模型缺点模型缺点模型缺点 要求在项目前期就明确需求 产品的运行版本直到项目开发后期方可见 用户直到项目结束方能了解产品的质量 不能逐步的熟悉系统 依赖于早期进行的需求调查 难以适应需求的变化 不允许变更或者限制变更 如果有未定义或未实施的需求 将会引起重复劳动 甚 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 6 页 共 14 页 至开发出的产品不是用户所需要的 2 1 42 1 42 1 4适用项目适用项目适用项目适用项目 同时具备以下三个特点的项目 可以使用瀑布模型 1 需求已经明确 2 软件实现方法是成熟的 3 项目周期较短 2 22 22 2 改进的瀑布模型改进的瀑布模型改进的瀑布模型 2 2 12 2 12 2 1模型描述模型描述模型描述模型描述 瀑布模型中阶段工作不能重叠 开发者常因项目 阻塞状态 而等待组内其他成员 完成任务 导致项目资源过多闲置 并严重影响项目进度 针对以上问题对原有瀑布模 型进行了改进 在需求分析完成后 总体设计是软件开发的重要关注点 总体设计将系 统划分为子系统和功能模块 定义功能模块间的接口 以及集成方案 在这种情况下 当一个模块的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完 才开始编码实现 因此在总体设计完成后可以将系统分为多个模块并行开发 每个模块 仍然遵循先设计和编码测试的瀑布模型思路 改进的瀑布模型的开发流程如图 2 2 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 7 页 共 14 页 系统分析 需求分析 总体设计 详细设计 实现 单元测试 集成测试 系统测试 详细设计 实现 单元测试 详细设计 实现 单元测试 验收 维护 用户需求 软件需求 原型 总体设计说明书 接口设计 集成方案 子系统 模块详细设计说明书 代码文件 测试文档 验收文档 维护记录 图图 2 2 改进的瀑布模型 改进的瀑布模型 2 2 22 2 22 2 2模型优点模型优点模型优点模型优点 系统分子系统和功能模块按照设计 实现 测试过程进行 适当的重叠各个阶段过程 子系统和功能模块间可以并行开发 达到资源的有效利 用 2 2 32 2 32 2 3模型缺点模型缺点模型缺点模型缺点 并行开发方式 对项目经理工作分解能力要求高 使用不当易造成项目开发混乱 要求总体需求及总体设计阶段有产品行业专家及技术专家介入 对公司人才要求较 高 2 2 42 2 42 2 4适用项目适用项目适用项目适用项目 具备下列 1 和 2 或者 2 和 3 特点的项目可以选择改进的瀑布模型作为软件生命 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 8 页 共 14 页 周期模型 1 前期需求明确 系统可以划分为子系统和功能模块 2 软件实现方法是成熟的 3 当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候 这个时候 也可以选择将整个开发过程按独立的需求划分为多个小瀑布进行操作 2 32 32 3 原型 瀑布模型原型 瀑布模型原型 瀑布模型 2 3 12 3 12 3 1模型描述模型描述模型描述模型描述 为了解决在产品开发的早期阶段存在的不确定性 二义性和不完整性等问题 通过 建立原型使开发者进一步确定其应开发的产品 使开发者的想象更具体化 也更易于被 客户所理解 原型可以分为抛弃型的和进化型两种 抛弃型 原型仅仅是需求阶段方面和用户沟 通的 DEMO 原型建立 分析之后要抛弃 整个系统按照瀑布模型重新分析和设计 进 化型则是对需求的定义有清楚的认识 原型建立之后要保留 作为系统逐渐增加的基础 采用进化型一定要重视软件设计的系统性和完整性 并且在质量要求方面没有捷径 因 此 对于描述相同的功能 建立进化型原型比建立抛弃型原型所花的时间要多 原型建 立确认需求之后采用瀑布模型的方式完成项目开发 原型 进化型 瀑布模型的开发 流程如图 2 3 所示 部分系统软件需求 或软件需求分析 原型设计原型实现原型测试瀑布测试 多次迭代原型逐渐完善 图图 2 3 原型 瀑布模型 进化型 原型 瀑布模型 进化型 2 3 22 3 22 3 2模型优点模型优点模型优点模型优点 原型模型从需求收集开始 开发者和用户在一起定义软件的总体目标 标识出已知 的需求 并规划出进一步定义的区域 原型建造 采用 快速设计 集中于软件那些对用户可见部分的表示 使用户能够 感受到实际的系统 原型由用户评估 并进一步精确细化待开发软件的需求 逐步调整原型使其满足客 户的要求 同时开发者对将要做的事情有更好的理解 这个过程是迭代的 开发人员与用户交流直观 可以澄清模糊需求 调动用户的积极参与性 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 9 页 共 14 页 2 3 32 3 32 3 3模型缺点模型缺点模型缺点模型缺点 针对于产品自身结构的不足 需要开发人员做实现上的折中 快速的建造出软件原型 一旦确定客户的真正需求 所建造的原型很可能被丢弃 2 3 42 3 42 3 4适用项目适用项目适用项目适用项目 具有以下情况之一的项目 建议选择原型 瀑布模型 1 需求不明确 用户对系统不了解 难以提出完整需求 用户定义了一组一般性目标 但不能标识出详细的输入 处理及输出需求 2 用户界面对系统成功是很关键的 但不很清楚 3 项目组需要验证技术的可行性 如新的开发语言 新的系统架构 算法的有效性 操作系统的适应性或人机交互的形式 2 42 42 4 增量模型增量模型增量模型 2 4 12 4 12 4 1模型描述模型描述模型描述模型描述 增量模型是一种进化软件过程模型 融合了线性顺序模型的基本成分 重复地应用 和原型模型的迭代特征 当使用增量模型时 第一个增量往往是核心产品 即实现了基 本的需求 核心产品交用户使用 或进行更详细的复审 使用或评估的结果是下一个 增量的开发计划 该计划包括对核心产品的修改 使其能更好的满足用户的需要 并发 布一些新增的特点和功能 增量模型和原型模型不一样 强调每一个增量均要发布一个 可操作产品 早期的增量是最终产品的 可拆卸 版本 但能提供用户服务功能和用户评 估的平台 增量模型开发流程见图 2 4 系统分析 软件需求 分析 软件结构 设计 详细设计1 维护 实现1测试1验收1 详细设计1实现1测试1验收1 详细设计1实现1测试1验收1 增量1 增量2 增量n 图图 2 4 增量模型增量模型 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 10 页 共 14 页 2 4 22 4 22 4 2模型优点模型优点模型优点模型优点 每一个增量均发布一个可操作产品 第一个增量往往是核心产品 早期的增量是最 终产品的 可拆卸 版本 当不能在计划周期内完成工作时 可先发布部分功能给用户 可以避免一次性投资太多带来的风险 将主要的功能或者风险大的功能首先实现 然后逐步完善 保证投入的有效性 2 4 32 4 32 4 3模型缺点模型缺点模型缺点模型缺点 由于增量模型的灵活性 往往容易退化成边做边改方法 使软件过程的控制丧失了 整体性 成为维护人员的恶梦 在增量过程中 存在相交情况下的执行过程且未很好处理 则必须做全盘系统分析 对软件产品的体系结构要求较高 2 4 42 4 42 4 4适用项目适用项目适用项目适用项目 具有以下情况之一的项目 建议选择增量模型 1 项目开始时明确了大部分的需求 但是需求可能会发生变化的项目 2 对于市场和用户把握不是很准 需要逐步了解的项目 3 对于有庞大和复杂功能的系统进行功能改进时需要一步一步实施的项目 2 52 52 5 增量的迭代过程模型增量的迭代过程模型增量的迭代过程模型 2 5 12 5 12 5 1模型描述模型描述模型描述模型描述 增量和迭代有区别但两者又经常一起使用 所以这里要先解释下增量和迭代的概念 假设现在要开发 A B C D 四个大的业务功能 每个功能都需要开发两周的时间 则 对于增量方法而言可以将四个功能分为两次增量来完成 第一个增量完成 A B 功能 第二次增量完成 C D 功能 而对于迭代开发来将则是分两次迭代来开发 第一次迭代 完成 A B C D 四个基本业务功能但不含复杂的业务逻辑 而第二个功能再逐渐细化 补充完整相关的业务逻辑 在第一个月过去后采用增量开始时候 A B 全部开发完成而 C D 还一点都没有动 而采用迭代开发的时候 A B C D 四个的基础功能都已经完 成 增量的迭代过程模型是一个不断迭代和增量的过程 迭代过程首先要处理一组客户 的业务需求 这些业务需求合起来能够确定开发产品的可用性 其次 迭代过程要解决 最突出的风险问题 后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一 一个增量不一定是对原有产品的增加 尤其在生命周期初期 开发人员可能用更加详细 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 11 页 共 14 页 和更加完善的设计来代替最初简单的设计 在较后的阶段 增量通常是对原有产品的增 加 采用此种模型最好是基于构件和有相应的构件开发工具 如 RUP 配置管理工具 等 增量的迭代过程模型的开发流程见图 2 4 系统分析 1 软件需求 分析1 设计1实现1测试1验收1 维护1 系统分析 2 软件需求 分析2 设计2实现2测试2验收2 系统分析 n 软件需求 分析n 设计n实现n测试n验收n 迭代1 迭代2 迭代n 图图 2 4 增量的迭代过程模型增量的迭代过程模型 2 5 22 5 22 5 2模型优点模型优点模型优点模型优点 基于风险前驱的原则 渐进地展开分析 设计及其相关活动 每个迭代都会提供一 次验证和调整模型机会 推动软件质量的提升 2 5 32 5 32 5 32 5 3 模型缺点模型缺点模型缺点模型缺点 每个迭代循环控制不好会变成边做边改模式 2 5 42 5 42 5 4适用项目适用项目适用项目适用项目 增量的迭代过程模型适用于项目中存在有很多风险 较复杂的应用项目 2 62 62 6 V V V 模型模型模型 2 6 12 6 12 6 1模型描述模型描述模型描述模型描述 V 模型是在快速应用开发 RAD Rap Application Development 模型基础上演变而 来 由于将整个开发过程构造成一个 V 字形而得名 V 模型强调软件开发的协作和速度 将软件实现和验证有机地结合起来 在保证较高的软件质量情况下缩短开发周期 下面通过对这种模型的水平和垂直的关联和比较分析 理解软件开发和测试的关系 理解 V 模型具有面向客户 效率高 质量预防意识等特点 能帮助我们建立一套更有效 的 更具有可操作性的软件开发过程 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 12 页 共 14 页 图图 2 5 V 模型模型 从水平对应关系看从水平对应关系看 左边是设计和分析 是软件设计实现的过程 同时伴随着质量保证活动 审核的过程 也就是静态的测试过程 右边是对左边结果的验证 是动态测试的过程 即对设计和分析的结 果进行测试 以确认是否满足用户的需求 如 需求获取的阶段 即业务需求和用户需求对应验收测试 说明在做需求分析 产品功能设 计的同时 测试人员就可以阅读 审查业务需求和用户需求 从而了解产品的设计特性 用户 的真正需求 确定测试目标 可以准备用例 Use Case 并策划验证测试活动 与需求分析对应的是系统测试 因为需求分析的工作是分解用户的功能和性能需求并规格 化 所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现 该测试 把软件作为一个黑盒 针对每个需求规格组织各种输入并根据软件输出来判断该需求规格是否 正确实现 因此系统测试属于黑盒测试 与概要设计对应的是集成测试 因为概要设计的工作 主要是根据功能把大的系统进行模块分解 所以集成测试的工作主要是 把各模块逐步集成在 一起 来测试数据是否能够在各模块间正确流动 以及各模块能否正确同步 因为这种测试依 赖于软件的架构但又不关心每个函数的实现细节 所以该测试又常称为灰盒测试 与详细设计 对应的是单元测试 它主要是详细设计中的每个功能单元 通常是函数或过程 进行逻辑覆盖 测试 因此这种测试属于白盒测试 与从需求到设计 系统测试 于是就形成了一个 V 字形的 结构 质量管理体系软件生命周期模型选用指南 版本 5 1 深圳天源迪科信息技术股份有限公司 第 13 页 共 14 页 从垂直方向看从垂直方向看 水平虚线上部表明 其需求获取 定义和验收测试等主要工作是面向用户 要和用户进行 充分的沟通和交流 或者是和用户一起完成 水平虚线下部的大部分工作 相对来说 都是技 术工作 在开发组织内部进行 主要是由工程师 技术人员完成 从垂直方向看 越在下面 白盒测试方法使用越多 到了集