软件生命周期指南范文Word格式.docx
《软件生命周期指南范文Word格式.docx》由会员分享，可在线阅读，更多相关《软件生命周期指南范文Word格式.docx（18页珍藏版）》请在冰点文库上搜索。
本文档适用于贝斯特集团软件研发部的所有软件项目。
1.2缩略语
PP项目计划
PMC项目监督和控制
PPQA过程和产品质量保证
CM配置管理
SOW工作说明书
WBS工作分解结构
SRS软件需求规格说明书
1.3参考文献
《CMMI1.1》。
2瀑布模型
瀑布模型是最常用的软件开发模型，它的各个阶段是按线性序列组织的。
开发过程中的阶段划分为项目策划、需求分析、概要设计、详细设计、编码和单元测试、软件集成和集成测试、系统测试、验收和安装等（图1）。
尽管开发过程中定义了各个阶段的顺序，但这些阶段有时是相互交迭进行的，阶段间的依赖性由入口准则来确定。
图1瀑布模型
瀑布模型的每个阶段均具有以下特征：
●从上一阶段接受本阶段工作的对象，作为输入；
●对上述输入实施本阶段的活动；
●给出本阶段的工作成果，作为输出传入下一阶段；
●对本阶段工作进行评审，如果本阶段工作得到确认，那么继续下阶段工作，否则返回前一阶段，甚至更前阶段。
瀑布模型为软件开发与维护提供了一种有效的管理模式，根据这一管理模式制订开发计划、进行成本预算、组织开发人员，以阶段评审和文档控制为手段有效地对整个开发过程进行指导，从而保证了软件产品的质量。
●优点：
近30年来之所以广为流行，是因为它在支持开发结构化软件、控制软件的开发复杂度、促进软件开发工程化方面起着显著作用。
●缺点：
缺乏灵活性，无法通过开发活动澄清本来不够确切的软件需求。
这些问题可能导致开发出的软件并不是用户真正需要的软件，并且这一点在开发过程完成后才有所察觉。
2.1项目策划
项目策划是每个项目的初始阶段，目的是为开发过程和过程管理做好必要的准备。
项目策划的主要工作是进行可行性分析和研究，进行估计和制定管理项目的计划。
主要输入
项目任务书、建议书或工作说明书（SOW）
客户需求/需要
入口准则
客户需求/需要已被批准
项目任务书、建议书或SOW已被批准
项目经理和相关人员已经到位
参与项目准备和策划的人员接受过相关技能的培训
角色与职责
高层经理、项目经理、PPQA和SCM工程师、测试人员、客户或客户代表、项目组主要成员、领域专家。
[项目应根据具体情况，列出每个角色的职责]
活动
1、可行性分析和研究
2、构建WBS
3、估计项目的规模、工作量、成本和CCR等
4、标识和分析风险
5、计划资源及其获取方式
6、制定项目进度和预算
7、编制项目计划
8、计划验收测试
9、建立需求跟踪矩阵
10、评审和批准项目计划和验收计划
主要输出
WBS
估计记录
风险分析表和风险评估报告
软件项目计划，包括软件开发计划、PPQA计划、SCM计划等
验收计划
需求跟踪矩阵
出口准则
项目约定和计划得到受影响的组和个人的认可
软件项目计划和验收计划已被批准并置于配置管理之下
度量
项目策划所花的工作量和资金，评审工作量和返工工作量
可应用的标准和规范
[根据项目情况列出本阶段应该遵循的过程和产品的标准和规范]
可应用的规程、方法、工具和资源
[根据项目情况列出本阶段其它可应用的规程、方法、工具和资源]
2.2需求分析
需求分析阶段的主要目的是生成一个正确说明客户所有需求的文档。
软件需求规格说明书（SRS）是该阶段的主要输出。
需求分析的主要工作是需求提炼及分析、需求归档和需求评审等。
需求分析阶段执行的活动主要集中在两个领域：
问题分析和产品描述。
问题分析活动分准备、采集需求和分析等，而产品描述活动分准备SRS和评审SRS等。
项目计划得到评审和批准
项目策划阶段已经结束
参与需求分析的人员接受过相关技能的培训
高层经理、项目经理、需求分析师、测试人员、PPQA、SCM、客户或客户代表、领域专家和技术专家。
1、准备需求采集和分析
2、采集和分析需求
3、准备SRS
4、细化需求跟踪矩阵
5、计划系统测试
6、评审SRS、系统测试计划和测试用例、需求跟踪矩阵
SRS
系统测试计划和测试用例
SRS、系统测试计划和测试用例、需求跟踪矩阵得到评审和批准并置于配置管理之下
需求分析所花的工作量和资金，评审工作量和返工工作量
2.3概要设计
概要设计阶段是从实现的角度开发针对客户需求的解决方案。
在这个阶段给出的是高级的抽象方案，这个方案包含两个主要部分，即应用的功能体系结构和数据库设计。
SRS已经过评审和批准
项目经理、设计人员、测试人员、客户或客户代表、PPQA、SCM
1、定义标准（编码、文档、用户接口等）
2、进行功能设计
3、开发物理数据库设计
4、编写概要设计文档
5、计划集成测试
6、评审概要设计文档、集成测试计划和测试用例
概要设计文档
项目标准
集成测试计划和测试用例
概要设计文档、集成测试计划和测试用例得到评审和批准并置于配置管理之下
概要设计工作量、概要设计缺陷、评审工作量和返工工作量
2.4详细设计
在详细设计阶段，概要设计阶段开发的整体应用被分成几个模块和程序。
为每个程序进行逻辑设计，然后归档作为程序规格。
同时，为每个程序生成一个单元测试计划。
详细设计阶段的活动包括通用例程和程序的确定（如数据有效性例程、框架程序的开发及用于提高生产率的实用程序和工具的开发）。
概要设计文档经过评审和授权
项目经理、设计人员、测试人员、PPQA、SCM
1、将功能分成小的构件
2、设计/开发代码框架
3、开发例程和工具
4、进行程序设计
5、编写详细设计文档
6、计划单元测试
7、评审详细设计文档、单元测试计划和测试用例
详细设计文档
单元测试计划和测试用例
详细设计文档、单元测试计划和测试用例得到评审和批准并置于配置管理之下
详细设计工作量、详细设计缺陷、单元测试缺陷、程序框架缺陷以及评审和返工工作量
2.5编码和单元测试
在编码阶段，根据详细设计用编程语言和合适的编码规范产生源代码、可执行代码和数据库。
这个阶段的输出是随后测试和验证的主体。
详细设计文档、项目标准、单元测试计划和测试用例
详细设计文档经过评审和授权
项目经理、开发人员、测试人员
1、生成测试数据库
2、对程序进行编码
3、代码评审
4、记录和修正缺陷
5、代码自测
6、进行独立的单元测试
测试数据
可执行代码
代码评审报告/评审记录
独立的单元测试报告和评审记录
成功执行所有单元测试计划中的测试用例
编码和单元测试的工作量、代码评审缺陷、独立的单元测试缺陷以及评审和返工工作量
2.6软件集成和集成测试
软件集成是把设计阶段制定的，已通过单元测试的模块构建成一个完整的软件结构的系统方法。
在该阶段，同时要进行集成测试，以发现和接口相关的缺陷。
集成按集成计划中制定的顺序进行，并执行每个集成阶段的相应测试用例。
概要设计文档和程序、集成测试计划和测试用例
被集成的模块通过了单元测试
项目经理、集成人员、测试人员、开发人员
1、确定集成环境和集成规程
2、进行集成和集成测试
集成计划、集成后的完整软件产品、集成测试报告
完成软件集成，并成功地执行了集成测试计划中的所有测试用例
软件集成和集成测试的工作量、集成测试中发现的缺陷、返工工作量
2.7系统测试
系统测试是依据需求规格说明书验证软件产品有效性的活动。
这个阶段是为了发现那些只有通过测试整个系统才能暴露的缺陷，像外部接口、性能、安全和可靠性等只有在这个阶段才能判断其是否有效。
软件需求规格说明书、集成后的完整软件产品、系统测试计划和测试用例
软件产品通过了集成测试
项目经理、系统测试人员、开发人员
1、确定系统测试环境和测试规程
2、进行系统测试
系统测试报告
成功地执行了系统测试计划中的所有测试用例
系统测试的工作量、系统测试中发现的缺陷、返工工作量
2.8验收和安装
在验收和安装阶段，软件产品被集成到它的操作环境中，并在这个环境中经受测试，以确保它按需求执行。
这个阶段包括两个基本任务：
使软件得以验收和在客户处安装。
验收指的是用户根据早期准备的验收测试计划而进行正式的测试，并对测试结果进行分析，以确定系统是否满足验收准则。
当分析结果满足验收准则时，用户接受软件。
安装指的是把接受的软件置于实际的产品环境中。
系统测试后的软件产品、验收计划
软件产品通过了系统测试
项目经理、安装队伍、客户、开发人员
1、按计划执行验收
2、执行安装
验收报告、安装后的软件
客户在验收报告上签字、软件运行在实际的产品环境中
验收和安装的工作量、验收中发现的缺陷、返工工作量
3其他生命周期模型
3.1原型模型
原型模型从需求采集开始，开发者和客户一起定义软件的总体目标，标识出已知需求并规划出进一步定义的范围。
然后是进行快速设计，快速设计集中于软件中那些对客户可见部分的表示（如输入方式和输出格式）。
快速设计导致原型的建造。
原型由客户进行评价，并进一步精化待开发的软件需求。
逐步调整原型使其满足客户的要求，同时也使开发者对将要做的事情有更好的理解，这个过程是迭代的。
图2原型模型
原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。
软件系统的原型有多种形式：
●丢弃型——原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃；
●演示型——开发原型仅以演示为目标；
●样品型——原型规模与最终产品相同，只是原型仅供研究用；
●增长式演式型——原型作为软件最终产品的一部分，可以满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用；
●粗陋型——用较短时间开发的简易原型。
原形模型适合：
客户能提出一般性的目标，但不能标出详细的输入、处理及输出需求；
或开发者不能确定算法的有效性、操作系统的适应性及人机交互的形式。
3.2螺旋模型
螺旋模型是将瀑布模型与进化模型相结合，并增加了两者所忽略的风险分析。
它将软件项目开发分别划分为四类活动,沿着螺线旋转，在笛卡儿坐标的四个象限上分别表达了四个方面的活动，即：
●制订计划——确定软件目标，选定实施方案，弄清项目开发的限制条件；
●风险分析——分析所选方案，考虑如何识别和消除风险；
●实施工程——实施软件开发；
●客户评估——评价开发工作，提出修正建议。
沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。
螺旋模型通常用以指导大型软件项目的开发，如果开发风险过大，开发者和客户无法承受，项目有可能因此终止。
多数情况下会沿着螺线继续下去，自内向外逐步延伸，最终得到满意的软件。
如果对所开发项目的需求已有了较好的理解或较大的把握，无需开发原型，便可采用普通的瀑布模型。
这在螺旋模型中可认为是单圈螺线。
与此相反，如果对所开发项目的需求理解较差，需要开发原型，甚至需要不止一个原型的帮助，那就要经历多圈螺线。
在这种情况下，外圈的开发包含了更多的活动。
也可能某些开发采用了不同的模型。
和其它模型相比螺旋模型的优越性较为明显，但要求许多客户接受和相信进化方法并不容易。
本模型的使用需要具有相当丰富的风险评估经验和专门知识。
如果项目风险较大，又未能及时发现，势必造成重大损失。
图3螺旋模型
3.3增量模型
增量模型融合了瀑布模型的基本成分和原型的迭代特征。
增量模型采用随着日程时间的进展而交错的线性序列。
每一个线性序列产生软件的一个可发布的“增量”。
每一个增量的处理流程均可以采用原型模型。
在使用增量模型时，第一个增量往往是核心产品，以后每次交付可使用的部分功能，每次交付包含前一次交付的功能和一些新功能，最后一次交付一个完整的系统。
增量模型适用于业务高速发展的用户应用系统。
使用该模型时，首次交付的内容通常完成了最基本的需求，其它需求通过交付内容的使用情况和评价来制定下一次交付内容的开发计划，此过程不断重复，直到满足整个系统需求。
这种模型适用于需求逐渐清晰的软件项目。
需求
概要设计
增量2增量3
详细设计详细设计详细设计
增量1
编码及单元测试编码及单元测试编码及单元测试
集成测试集成测试集成测试
系统测试
图4增量模型
3.4RAD模型
快速应用开发模型（RAD模型）是瀑布模型的一个“高速”变种，强调极短的开发周期。
通过使用基于构件的建造方法获得快速开发。
如果需求理解的好，且约束了项目范围，RAD过程使得项目组能够在很短时间内（如60到90天）创建出功能完善的系统。
小组3
小组2业务建模
小组1业务建模
业务建模数据建模
数据建模
数据建模处理建模
处理建模
处理建模应用生成
应用生成
应用生成测试及反复
测试及反复
测试及反复
60-90天
图5RAD模型
RAD主要用于信息系统应用软件的开发，它包含如下几个开发阶段：
●业务建模：
业务活动中的信息流被模型化，以回答如下的问题：
什么信息驱动业务流程？
生成什么信息？
谁生成信息？
该信息流往何处？
谁处理它？
●数据建模：
业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需要的数据对象。
标识出每个对象的特征，并定义这些对象之间的关系。
●处理建模：
数据建模阶段定义的数据对象变换成为要完成一个业务功能所需的信息流。
创建处理描述以便增加、修改、删除或获取某个数据对象。
●应用生成：
RAD是复用已有的程序构件（如果可能的话）或是创建可复用的构件（如果需要的话）来创建软件。
●测试及反复：
由于RAD过程强调复用，许多程序构件已经是测试过的，这样就减少了测试时间。
但新的构件必须测试，所有接口也必须测试到。
RAD方法的缺陷是：
●对于大型的、但可伸缩的项目，RAD需要足够的人力资源以创建足够多的RAD组。
●RAD要求承担必要的快速活动的开发者和用户在一个很短的时间框架下完成一个系统，如果两方中的任何一方没有完成约定，都会导致RAD项目的失败。
RAD方法并不适用于所有的应用软件的开发。
如果一个系统难以被适当地模块化，那么建造所需要的构件就会有问题。
如果高性能是一个指标，且该指标必须通过调整接口使其适当应系统构件才能赢得，RAD方法就可以失败。
此外，RAD方法不适合技术风险很高的情况，当一个应用需要采用很多新技术，或者当新软件要求与已有计算机程序有很高的互操作性时，RAD方法就不适用。
升级会员 