软件生命周期指南范文

文档编号：日期：

软件生命周期指南

武汉贝斯特通信集团有限公司

变更记录

版本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项目策划

项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。项目

第5页/ 共14页

2.2需求分析

需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。软件需求规格说明书（SRS）是该阶段的主要输出。需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。需求分析阶段执行的活动主要集中在两个领域：问题分析和产品描述。问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。

版本1.0 软件生命周期指南

2.3概要设计

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

2.4详细设计

在详细设计阶段，概要设计阶段开发的整体应用被分成几个模块和程序。为每个程序进行逻辑设计，然后归档作为程序规格。同时，为每个程序生成一个单元测试计划。详细设计阶段的活动包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生

第7页/ 共14页

2.5编码和单元测试

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

在编码阶段，

版本1.0 软件生命周期指南

2.6软件集成和集成测试

软件集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整的软件结构的系统方法。在该阶段，同时要进行集成测试，以发现和接口相关的缺陷。集成按集成计划中制

2.7系统测试

系统测试是依据需求规格说明书验证软件产品有效性的活动。这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷，像外部接口、性能、安全和可靠性等只有在这个阶段才能判断其是否有效。

第9页/ 共14页

2.8验收和安装

在验收和安装阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。这个阶段包括两个基本任务：使软件得以验收和在客户处安装。验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。当分析结果满足验收准则时，用户接受软件。安装指的是把接受的

3其他生命周期模型

3.1原型模型

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

版本1.0 软件生命周期指南

图2 原型模型

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

●丢弃型——原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃；

●演示型——开发原型仅以演示为目标；

●样品型——原型规模与最终产品相同，只是原型仅供研究用；

●增长式演式型——原型作为软件最终产品的一部分，可以满足用户的部分需求，进

一步在此基础上开发，则可增加需求，实现后再交付使用；

●粗陋型——用较短时间开发的简易原型。

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

3.2螺旋模型

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

●制订计划——确定软件目标，选定实施方案，弄清项目开发的限制条件；

●风险分析——分析所选方案，考虑如何识别和消除风险；

●实施工程——实施软件开发；

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

沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。

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

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

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

第11页/ 共14页

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

图3 螺旋模型

3.3增量模型

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

版本1.0 软件生命周期指南

图4 增量模型

3.4RAD模型

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

图5 RAD模型

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

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

流程？生成什么信息？谁生成信息？该信息流往何处？谁处理它？

●数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需要

的数据对象。标识出每个对象的特征，并定义这些对象之间的关系。

●处理建模：数据建模阶段定义的数据对象变换成为要完成一个业务功能所需的信息

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

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

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

第13页/ 共14页

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

少了测试时间。但新的构件必须测试，所有接口也必须测试到。

RAD方法的缺陷是：

●对于大型的、但可伸缩的项目，RAD需要足够的人力资源以创建足够多的RAD组。

●RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个

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

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