软件生命周期指南范文

软件生命周期指南

任务名称： 所属项目名称： 代号：

拟制人： 审校： 版本： 审核： 批准： 武汉贝斯特通信集团有限公司

变更记录

章节章节名称 号 变更内容描述 日期 版本号 变更 变更前 批准人 版本1.0 软件生命周期指南

第3页 / 共14页

1 前言

软件生命周期是指软件产品或软件系统从产生、投入使用到被淘汰的全过程。随着软件复杂性的增长，人们认识到软件开发活动应划分为需求分析、设计、实现、测试等若干个活动，并将这些活动以适当的方式分配到不同的阶段中去完成。

软件生命周期模型是描述软件开发全部过程、活动和任务的结构框架。比较常见的软件生命周期模型是瀑布模型、增量模型、原型模型和螺旋模型等。

1.1 目的和适用范围

本文档规定了贝斯特集团软件研发部适用的软件生命周期模型，作为项目经理在制定项目计划时根据项目需求、复杂程度、进度要求等项目特点确定采用何种开发过程的依据。如果确定的生命周期模型不在本文档中规定的范围内，必须经过系统集成部的审批才能使用。

本文档适用于贝斯特集团软件研发部的所有软件项目。

1.2 缩略语

PP 项目计划

PMC 项目监督和控制

PPQA 过程和产品质量保证 CM 配置管理 SOW 工作说明书 WBS 工作分解结构

SRS 软件需求规格说明书

1.3 参考文献

《CMMI 1.1》。

2 瀑布模型

瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织的。开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。

验收和安装 系统测试 软件集成 编码和单 和集成测试 详细设计 元测试 概要设计 需求分析 项目策划 图1 瀑布模型

版本1.0 软件生命周期指南

瀑布模型的每个阶段均具有以下特征：

 从上一阶段接受本阶段工作的对象，作为输入；  对上述输入实施本阶段的活动；

 给出本阶段的工作成果，作为输出传入下一阶段；

 对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返

回前一阶段，甚至更前阶段。

瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。

 优点：近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的

开发复杂度、促进软件开发工程化方面起着显著作用。

 缺点：缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。这些问题可

能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。

2.1 项目策划

项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。 主要输入 入口准则 项目任务书、建议书或工作说明书（SOW） 客户需求/需要 客户需求/需要已被批准 项目任务书、建议书或SOW已被批准 项目经理和相关人员已经到位 参与项目准备和策划的人员接受过相关技能的培训 高层经理、项目经理、PPQA和SCM工程师、测试人员、客户或客户代表、项目组主要成员、领域专家。 [项目应根据具体情况，列出每个角色的职责] 1、可行性分析和研究 2、构建WBS 3、估计项目的规模、工作量、成本和CCR等 4、标识和分析风险 5、计划资源及其获取方式 6、制定项目进度和预算 7、编制项目计划 8、计划验收测试 9、建立需求跟踪矩阵 10、评审和批准项目计划和验收计划 WBS 估计记录 风险分析表和风险评估报告 软件项目计划，包括软件开发计划、PPQA计划、SCM计划等 验收计划 需求跟踪矩阵 角色与职责 活动 主要输出

第5页 / 共14页

出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 项目约定和计划得到受影响的组和个人的认可 软件项目计划和验收计划已被批准并置于配置管理之下 项目策划所花的工作量和资金，评审工作量和返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.2 需求分析

需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。软件需求规格说明

书（SRS）是该阶段的主要输出。需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。需求分析阶段执行的活动主要集中在两个领域：问题分析和产品描述。问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。

主要输入 入口准则 客户需求/需要 项目计划得到评审和批准 项目策划阶段已经结束 参与需求分析的人员接受过相关技能的培训 高层经理、项目经理、需求分析师、测试人员、PPQA、SCM、客户或客户代表、领域专家和技术专家。 [项目应根据具体情况，列出每个角色的职责] 1、 准备需求采集和分析 2、 采集和分析需求 3、准备SRS 4、细化需求跟踪矩阵 5、计划系统测试 6、评审SRS、系统测试计划和测试用例、需求跟踪矩阵 SRS 需求跟踪矩阵 系统测试计划和测试用例 SRS、系统测试计划和测试用例、需求跟踪矩阵得到评审和批准并置于配置管理之下 需求分析所花的工作量和资金，评审工作量和返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] 角色与职责 活动 主要输出 出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 版本1.0 软件生命周期指南

2.3 概要设计

概要设计阶段是从实现的角度开发针对客户需求的解决方案。在这个阶段给出的是高级的抽象方案，这个方案包含两个主要部分，即应用的功能体系结构和数据库设计。

主要输入 入口准则 角色与职责 活动 SRS SRS已经过评审和批准 项目经理、设计人员、测试人员、客户或客户代表、PPQA、SCM [项目应根据具体情况，列出每个角色的职责] 1、 定义标准（编码、文档、用户接口等） 2、 进行功能设计 3、 开发物理数据库设计 4、 编写概要设计文档 5、 计划集成测试 6、 评审概要设计文档、集成测试计划和测试用例 概要设计文档 项目标准 集成测试计划和测试用例 概要设计文档、集成测试计划和测试用例得到评审和批准并置于配置管理之下 概要设计工作量、概要设计缺陷、评审工作量和返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] 主要输出 出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.4 详细设计

在详细设计阶段，概要设计阶段开发的整体应用被分成几个模块和程序。为每个程序进

行逻辑设计，然后归档作为程序规格。同时，为每个程序生成一个单元测试计划。详细设计阶段的活动包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生产率的实用程序和工具的开发）。 主要输入 入口准则 角色与职责 概要设计文档 概要设计文档经过评审和授权 项目经理、设计人员、测试人员、PPQA、SCM [项目应根据具体情况，列出每个角色的职责]

第7页 / 共14页

活动 1、 将功能分成小的构件 2、 设计/开发代码框架 3、 开发例程和工具 4、 进行程序设计 5、 编写详细设计文档 6、 计划单元测试 7、 评审详细设计文档、单元测试计划和测试用例 详细设计文档 单元测试计划和测试用例 详细设计文档、单元测试计划和测试用例得到评审和批准并置于配置管理之下 详细设计工作量、详细设计缺陷、单元测试缺陷、程序框架缺陷以及评审和返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] 主要输出 出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.5 编码和单元测试

在编码阶段，根据详细设计用编程语言和合适的编码规范产生源代码、可执行代码和数

据库。这个阶段的输出是随后测试和验证的主体。 主要输入 入口准则 角色与职责 活动 详细设计文档、项目标准、单元测试计划和测试用例 详细设计文档经过评审和授权 项目经理、开发人员、测试人员 [项目应根据具体情况，列出每个角色的职责] 1、 生成测试数据库 2、 对程序进行编码 3、 代码评审 4、 记录和修正缺陷 5、 代码自测 6、 进行独立的单元测试 测试数据 可执行代码 代码评审报告/评审记录 独立的单元测试报告和评审记录 成功执行所有单元测试计划中的测试用例 编码和单元测试的工作量、代码评审缺陷、独立的单元测试缺陷以及评审和返工工作量 主要输出 出口准则 度量 版本1.0

可应用的标准和规范 可应用的规程、方法、工具和资源 软件生命周期指南

[根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.6 软件集成和集成测试

软件集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整的软件结构的系

统方法。在该阶段，同时要进行集成测试，以发现和接口相关的缺陷。集成按集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。 主要输入 入口准则 角色与职责 活动 主要输出 出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 概要设计文档和程序、集成测试计划和测试用例 被集成的模块通过了单元测试 项目经理、集成人员、测试人员、开发人员 [项目应根据具体情况，列出每个角色的职责] 1、 确定集成环境和集成规程 2、 进行集成和集成测试 集成计划、集成后的完整软件产品、集成测试报告 完成软件集成，并成功地执行了集成测试计划中的所有测试用例 软件集成和集成测试的工作量、集成测试中发现的缺陷、返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.7 系统测试

系统测试是依据需求规格说明书验证软件产品有效性的活动。这个阶段是为了发现那些

只有通过测试整个系统才能暴露的缺陷，像外部接口、性能、安全和可靠性等只有在这个阶段才能判断其是否有效。

主要输入 入口准则 角色与职责 活动 主要输出 出口准则

软件需求规格说明书、集成后的完整软件产品、系统测试计划和测试用例 软件产品通过了集成测试 项目经理、系统测试人员、开发人员 [项目应根据具体情况，列出每个角色的职责] 1、 确定系统测试环境和测试规程 2、 进行系统测试 系统测试报告 成功地执行了系统测试计划中的所有测试用例 第9页 / 共14页

度量 可应用的标准和规范 可应用的规程、方法、工具和资源 系统测试的工作量、系统测试中发现的缺陷、返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 2.8 验收和安装

在验收和安装阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以

确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和在客户处安装。验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收准则时，用户接受软件。安装指的是把接受的软件置于实际的产品环境中。 主要输入 入口准则 角色与职责 活动 主要输出 出口准则 度量 可应用的标准和规范 可应用的规程、方法、工具和资源 系统测试后的软件产品、验收计划 软件产品通过了系统测试 项目经理、安装队伍、客户、开发人员 [项目应根据具体情况，列出每个角色的职责] 1、 按计划执行验收 2、 执行安装 验收报告、安装后的软件 客户在验收报告上签字、软件运行在实际的产品环境中 验收和安装的工作量、验收中发现的缺陷、返工工作量 [根据项目情况列出本阶段应该遵循的过程和产品的标准和规范] [根据项目情况列出本阶段其它可应用的规程、方法、工具和资源] 3 其他生命周期模型

3.1 原型模型

原型模型从需求采集开始，开发者和客户一起定义软件的总体目标，标识出已知需求并

规划出进一步定义的范围。然后是进行快速设计，快速设计集中于软件中那些对客户可见部分的表示（如输入方式和输出格式）。快速设计导致原型的建造。原型由客户进行评价，并进一步精化待开发的软件需求。逐步调整原型使其满足客户的要求，同时也使开发者对将要做的事情有更好的理解，这个过程是迭代的。

版本1.0 用户反馈 软件生命周期指南

需求分析 快速设计 原型评价 最终系统设计 最终系统实现 图2 原型模型

原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。软件系统的原型有多种形式：

 丢弃型——原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃；  演示型——开发原型仅以演示为目标；

 样品型——原型规模与最终产品相同，只是原型仅供研究用；  增长式演式型——原型作为软件最终产品的一部分，可以满足用户的部分需求，进

一步在此基础上开发，则可增加需求，实现后再交付使用；  粗陋型——用较短时间开发的简易原型。

原形模型适合：客户能提出一般性的目标，但不能标出详细的输入、处理及输出需求；或开发者不能确定算法的有效性、操作系统的适应性及人机交互的形式。

3.2 螺旋模型

螺旋模型是将瀑布模型与进化模型相结合，并增加了两者所忽略的风险分析。它将软件项目开发分别划分为四类活动, 沿着螺线旋转，在笛卡儿坐标的四个象限上分别表达了四个方面的活动，即：

 制订计划——确定软件目标，选定实施方案，弄清项目开发的限制条件；  风险分析——分析所选方案，考虑如何识别和消除风险；  实施工程——实施软件开发；

 客户评估——评价开发工作，提出修正建议。

沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。 螺旋模型通常用以指导大型软件项目的开发，如果开发风险过大，开发者和客户无法承受，项目有可能因此终止。多数情况下会沿着螺线继续下去，自内向外逐步延伸，最终得到满意的软件。

如果对所开发项目的需求已有了较好的理解或较大的把握，无需开发原型，便可采用普通的瀑布模型。这在螺旋模型中可认为是单圈螺线。与此相反，如果对所开发项目的需求理解较差，需要开发原型，甚至需要不止一个原型的帮助，那就要经历多圈螺线。在这种情况下，外圈的开发包含了更多的活动。也可能某些开发采用了不同的模型。

和其它模型相比螺旋模型的优越性较为明显，但要求许多客户接受和相信进化方法并不

第11页 / 共14页

容易。本模型的使用需要具有相当丰富的风险评估经验和专门知识。如果项目风险较大，又未能及时发现，势必造成重大损失。

图3 螺旋模型

3.3 增量模型

增量模型融合了瀑布模型的基本成分和原型的迭代特征。增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。每一个增量的处理流程均可以采用原型模型。在使用增量模型时，第一个增量往往是核心产品，以后每次交付可使用的部分功能，每次交付包含前一次交付的功能和一些新功能，最后一次交付一个完整的系统。增量模型适用于业务高速发展的用户应用系统。使用该模型时，首次交付的内容通常完成了最基本的需求，其它需求通过交付内容的使用情况和评价来制定下一次交付内容的开发计划，此过程不断重复，直到满足整个系统需求。这种模型适用于需求逐渐清晰的软件项目。

版本1.0

需求 概要设计 详细设计 增量1 编码及单元测试 集成测试

软件生命周期指南

增量2 详细设计 增量3 详细设计 编码及单元测试 集成测试 编码及单元测试 集成测试 系统测试 图4 增量模型

3.4 RAD模型

快速应用开发模型（RAD模型）是瀑布模型的一个“高速”变种，强调极短的开发周期。通过使用基于构件的建造方法获得快速开发。如果需求理解的好，且约束了项目范围，RAD过程使得项目组能够在很短时间内（如60到90天）创建出功能完善的系统。

小组3 小组2 业务建模 数据建模 处理建模 应用生成 测试及反复 数据建模 处理建模 应用生成 测试及反复 业务建模 小组1 业务建模 数据建模 处理建模 应用生成 测试及反复 60-90天 图5 RAD模型

RAD主要用于信息系统应用软件的开发，它包含如下几个开发阶段：

 业务建模：业务活动中的信息流被模型化，以回答如下的问题：什么信息驱动业务

流程？生成什么信息？谁生成信息？该信息流往何处？谁处理它？  数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需要

的数据对象。标识出每个对象的特征，并定义这些对象之间的关系。  处理建模：数据建模阶段定义的数据对象变换成为要完成一个业务功能所需的信息

流。创建处理描述以便增加、修改、删除或获取某个数据对象。

 应用生成：RAD是复用已有的程序构件（如果可能的话）或是创建可复用的构件

（如果需要的话）来创建软件。

第13页 / 共14页

 测试及反复：由于RAD过程强调复用，许多程序构件已经是测试过的，这样就减

少了测试时间。但新的构件必须测试，所有接口也必须测试到。 RAD方法的缺陷是：  对于大型的、但可伸缩的项目，RAD需要足够的人力资源以创建足够多的RAD组。  RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个

系统，如果两方中的任何一方没有完成约定，都会导致RAD项目的失败。

RAD方法并不适用于所有的应用软件的开发。如果一个系统难以被适当地模块化，那么建造所需要的构件就会有问题。如果高性能是一个指标，且该指标必须通过调整接口使其适当应系统构件才能赢得，RAD方法就可以失败。此外，RAD方法不适合技术风险很高的情况，当一个应用需要采用很多新技术，或者当新软件要求与已有计算机程序有很高的互操作性时，RAD方法就不适用。