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