CMMI-过程管理-OPD-软件生命周期模型描述-V1.0

1、 软件生命周期模型描述软件生命周期模型描述文档编号：GZCY_OPD_PRS-V1.0文档信息：文档名称：文档类别：CMMI模板密 级：机密版本信息：V1.0建立日期：创 建 人：审 核 者：批 准 人： 批准日期：保 管 人：存放位置：编辑软件：Microsoft Office 2003 英文版CONFIDENTIAL文档修订记录版本编号或者更改记录编号变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人V1.0C初次创建2004-07-21CMM事业部*变化状态：C创建，A增加，M修改，D删除文档审批信息序号审批人角色审批日期签字备注前 言本文描述组织级定义的软件生命周期模型，供

2、项目策划时根据项目的具体情况选择或裁剪使用，由此确定软件项目开发过程的各种不同的阶段以及各阶段的执行顺序。但是“所有的模型都是错误，有些模型是有用的”。模型是对它们所代表的真实世界的简化，这种简化更多的是为了规范管理的需要，它只能够照顾大多数。如果它不适合你的项目或者有更能真实表达现实世界的模型出现，因为涉及到组织管理方式的变化，任何模型的修改或新模型的加入都需要通过组织的审批。目 录第一章 简介11.1 目的11.2 适用范围11.3 术语表11.4 参考资料1第二章 过程概述3第三章 生命周期模型描述43.1 V字模型43.1.1 概述43.1.2 阶段定义53.1.3 适用情况53.1.

3、4 优点63.1.5 缺点63.1.6 本企业适合项目类型63.2 中等简化V字模型63.2.1 概述63.2.2 阶段定义73.2.3 适用情况73.2.4 优点73.2.5 缺点73.2.6 本企业适合项目类型73.3 最简化V字模型83.3.1 概述83.3.2 阶段定义83.3.3 适用情况83.3.4 优点93.3.5 缺点93.3.6 本企业适合项目类型93.4 迭代模型93.4.1 概述93.4.2 阶段定义113.4.3 适用情况113.4.4 优点113.4.5 缺点123.4.6 本企业适合项目类型123.4.7 以需求、计划、设计为重点的迭代模型123.4.8 以计划、设

4、计、编码、测试为重点的迭代模型133.5 原型瀑布模型143.5.1 概述143.5.2 阶段定义153.5.3 适用情况153.5.4 优点153.5.5 缺点163.5.6 本企业适合的项目类型163.6 增量模型163.6.1 概述163.6.2 阶段定义173.6.3 适用情况183.6.4 优点183.6.5 缺点183.6.6 本企业适合的项目类型183.7 增量的迭代过程模型183.7.1 概述183.7.2 阶段定义193.7.3 适用情况203.7.4 优点203.7.5 缺点203.7.6 本企业适合的项目类型203.8 快速应用开发模型203.8.1 概述203.8.2

5、阶段定义213.8.3 适用情况223.8.4 优点223.8.5 缺点223.8.6 本企业适合的项目类型223.9 螺旋模型233.9.1 概述233.9.2 阶段定义243.9.3 适用情况243.9.4 优点243.9.5 缺点243.9.6 本企业适合的项目类型24 第 25 页第一章 简介软件生命周期由制定计划、需求开发、设计、编码、测试、维护等各项活动组成，而如何将这些活动合理、有效地衔接组织起来，就需要在软件项目策划阶段选择合适的软件生命周期模型。正如每个项目的目的是唯一的，每个项目的软件生命周期模型也将是唯一的，定义软件生命周期是项目计划的一个重要步骤，它将直接影响到WBS及

6、软件开发计划的制定。1.1 目的本文的目的是为了指导软件项目策划人员如何选用软件生命周期模型。1.2 适用范围本文档适用于公司中的所有软件项目。1.3 术语表l 软件生命周期(Software life cycle)：从软件产品的设想开始到软件不再使用而结束的时间周期。软件生命周期一般包括需求阶段、设计阶段、实现阶段、测试阶段、运行和维护阶段，有时还包括退役阶段。l 软件过程：有关开发和维护软件及其相关产品（例如：项目计划、设计文档、代码、测试用例、用户手册等）的活动、方法、实践和变更的集合。l CASE工具：计算机辅助软件工程工具，为与软件过程相关的每个活动中的软件工程管理者和实践者提供帮助

7、，它们自动化项目管理活动，管理所有在过程中产生的工作产品并且辅助工程师完成他们的分析、设计、编码和测试工作。1.4 参考资料l 软件工程Java语言实现，Stephen R. Schach著，袁兆山等译，机械工业出版社，1999年9月l 软件工程实践者的研究方法，Roger S. Pressman著，梅宏等译，机械工业出版社，2002年9月l 实用软件工程郑人杰、殷人昆、陶永雷著，清华大学出版社，1997年4月l 软件需求，Karl E. Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000年7月l 统一软件开发过程，Ivar Jacobson、Grady Booch、Jam

8、es Rumbaugh著，周伯生、冯学民、樊东平等译，机械工业出版社，2002年1月第二章 过程概述为了使项目在定义软件过程时能够依据其特性选择适用的软件生命周期，使得项目开发过程流程化、易于管理、提高开发速度和产品质量，以达到更好的满足客户的要求，组织规定了以下几种适于本组织使用的生命周期模型：l V字模型l 中等简化V字模型l 最简化V字模型l 迭代模型l 以需求、计划、设计为重点的迭代模型l 以计划、设计、编码、测试为重点的迭代模型l 原型+瀑布模型l 增量模型l 增量的迭代过程模型l 快速应用开发模型l 螺旋模型注：1. 在组织中有些需求不清晰的项目中也会使用快速原型法，但这主要起到需

9、求获取的作用，通常不作为生命周期模型描述，开发过程使用的生命周期模型以上述几种为主。第三章 生命周期模型描述3.1 V字模型3.1.1 概述V字模型其实就是瀑布模型，它是一种线型顺序模型，是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用，它提供了一种结构化的、自顶向下的软件开发方法，每阶段主要工作成果从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作，各阶段相互独立、不重叠。V字模型是所有软件生命周期模型的基础。V字模型的开发流程如下图：图 1 V字模型示意图3.1.2 阶段定义No阶段入口标准任务出口标准1需求开发项目立项报告已经由高

10、层经理签字，项目开始启动。需求访谈及分析系统测试设计软件需求规格说明书及系统测试设计完成并形成基线2概要设计软件需求规格说明书已经完成并形成基线。进行数据库设计各模块的概要设计集成测试设计概要设计说明书及集成测试设计完成并形成基线。3详细设计概要设计已完成并形成基线进行详细设计及单元测试用例编写。详细设计及单元测试用例编写完成并形成基线。4实现详细设计完成并形成基线进行编码及单元测试编码及单元测试完成并形成基线。5测试系统测试设计完成集成测试设计完成编码及单元测试完成用户文档完成（安装、操作、维护）进行集成、系统测试集成、系统测试完成并形成基线6运行维护测试已经完成系统安装、运行、维护组织不再

11、对产品进行维护3.1.3 适用情况l 充分理解用户需求,且需求是确定不变的l 用户有一定的能力，对需求的表述是确切的 l 充分理解该解决方案的技术和体系 l 需要一个可维护性和可支持性较高的解决方案 l 所有过程工作产品的控制基线，需要有可见度和可靠性 l 适用于新的有较多用户的产品、平台/中间件开发项目，或者是用户对开发过程有严格要求的工程定制项目 l 项目经理有一定的项目管理经验 l 要求开发周期时间较充分3.1.4 优点l 强调开发的阶段性l 强调早期的计划及需求调查与分析 l 强调产品测试的完备性 l 过程文档齐全，便于追溯和重用l 过程的可见性强，便于过程质量控制l 只要需求是稳定的

12、，则进度也是稳定的3.1.5 缺点l 无法解决软件需求不明确或不准确的问题l 灵活性差，依赖于早期进行的需求调查，不能适应需求的变化 l 由于是单一流程，开发中的经验教训不能及时反馈并应用于本产品的过程改进3.1.6 本企业适合项目类型组织所熟悉领域的应用系统开发；例如：联行子系统的开发。3.2 中等简化V字模型3.2.1 概述针对组织中项目的实际情况，对V字（瀑布）模型进行演化是必要的。中等简化V字模型就是在标准瀑布模型基础上根据组织中一些小项目等的实际需要演化来的。流程图如下所示：图 2 中等简化V字模型示意图3.2.2 阶段定义参见V字模型。3.2.3 适用情况l 项目的复杂度、团队的规

13、模、工作量和周转时间都是中等程度的l 需求和技术都已被充分理解l 项目经理有较高的项目管理和控制的经验3.2.4 优点l 可以适应中等和较小项目的较灵活的管理需要l 提供中度的进度控制，相对标准V字模型，可以减少部分项目管理工作量和开支l 在产品交付方面进行合理的控制3.2.5 缺点l 因项目开发流程相对简化，项目的风险增大，质量隐患增大3.2.6 本企业适合项目类型在已经运行过的成型系统之上，根据客户的不同需求进行客户化改造的项目，客户对原系统有充分的了解，能够提出比较成熟的需求，则项目过程可以采用中等简化V字模型。例如：廊坊农信综合业务系统客户化改造项目。3.3 最简化V字模型3.3.1

14、概述针对组织中项目的实际情况，对V字（瀑布）模型进行演化是必要的。最简化V字模型就是在标准瀑布模型基础上根据组织中的小项目和维护项目等的实际需要演化出来的。一般情况下，不建议使用此种模型。流程图如下所示：图 3 最简化V字模型示意图3.3.2 阶段定义参见V字模型。3.3.3 适用情况l 项目的规模和工作量都比较小 l 项目具有较小的开发团队 l 需求和技术都是被充分确定和理解的 l 系统具有低复杂度，不需要独立的设计阶段 l 产品的体系结构是稳定的 l 项目经理经验丰富，对项目有较好的管理控制能力 l 项目开发周期较短3.3.4 优点l 可以适应小项目的灵活性 l 减少过程复杂带来的产品提交

15、时间延长 l 过程相对简单，项目管理控制的工作量相对较少l 提供中度的进度控制 l 减少开支3.3.5 缺点l 对阶段性的控制较弱，问题不能及时发现 l 项目前期控制较弱，使得项目产品质量留有隐患3.3.6 本企业适合项目类型单项功能的修改或增加的项目，开发时间小于10天的项目可以选用最简化V字模型；例如：综合业务系统中储蓄批量自动结息的效率优化项目。3.4 迭代模型3.4.1 概述在项目做计划的过程中，选用迭代模型时，有如下要求：l 进行第一次项目计划时，确定所选择的生命周期模型为迭代模型时，要求在计划中明确进行迭代流程阶段、迭代的次数、每次迭代所选的生命周期模型以及每次迭代的起止日期。l

16、每次迭代所选的生命周期模型，可以根据本次迭代的重点，选择瀑布型-标准V模型、中等简化V字模型、最简化V字模型中的一种，或者是某种瀑布模型的某几个流程阶段，确定为本次迭代的工作流程阶段。l 对项目WBS的要求：以下表格可以与WBS结合，用于明确各流程阶段的工作任务、该任务在本次迭代中的重要程度（强、中、弱）、该流程阶段的控制点及控制手段（如重要程度为“强”的任务须进行评审，“中”的任务可以通过变更过程进行控制，“弱”的任务可以通过批准直接在文档的修订页中注明）。迭代次数流程阶段工作任务重要程度（强、中、弱）工作产品控制点及控制手段         

17、;                     l 根据每次迭代的WBS任务和各WBS任务在本次迭代中的重要程度（强、中、弱），参照迭代模型样例图，绘制本项目的迭代模型图。l 从第二次到第N次的迭代，在不与第一次计划冲突的基础上，制定本次迭代的小计划，也可以直接在项目的PROJECT图上进行本次迭代计划的细化。l 如果后几次迭代对第一次计划的内容有变动，如进度的调整，控制点的变化等，则须进行变更及批准。迭代模型的开发流程图如下：图 4 迭代模型示意图3.4.2 阶段定义参见V字模型。3.4.3 适用

18、情况l 规模较大的项目或产品 l 需求的清晰度低，且需要进一步的调查 l 技术或体系结构方面的知识匮乏3.4.4 优点l 允许变更需求，中途的修改是容易的，如果在项目组内部和外部之间有良好的沟通渠道l 有助于项目组的学习和提高，团队成员有机会在整个生命周期中边做边学，各显其能 l 迭代流程自身可在进行过程中得到改进和精炼 l 生成性能更强壮的产品l 风险管理比较容易，可及早降低风险，前提是存在良好的信息传递渠道 l 与其他生命周期模型相比，它在开发周期内具有更好的性能 3.4.5 缺点l 因本模型较为灵活，对管理的要求较高，项目经理需要有丰富的项目管理经验 l 迭代的次数和任务规划难把握，对项

19、目策划要求较高3.4.6 本企业适合项目类型新领域、新技术的研发项目。3.4.7 以需求、计划、设计为重点的迭代模型此种模型是根据组织目前的实际情况制定的，常用于需求不明确的项目：使用此模型的要求与迭代模型相同，流程图如下所示图 5 以需求、计划、设计为重点的迭代模型示意图3.4.8 以计划、设计、编码、测试为重点的迭代模型此种模型是根据组织目前的实际情况制定的，常用于算法型等技术难度较高的项目：使用此模型的要求与迭代模型相同，流程图如下所示图 6 以计划、设计、编码、测试为重点的迭代模型示意图3.5 原型瀑布模型3.5.1 概述原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在

20、的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发。图表 7原型瀑布模型开发流程图3.5.2 阶

21、段定义No阶段入口标准任务出口标准1需求开发项目立项报告已经由高层经理签字，项目开始启动。需求访谈及分析软件需求说明2原型设计软件需求说明快速设计系统原型原型设计说明3原型实现原型设计说明快速进行原型的制作系统原型4原型测试系统原型用户测试评估原型，进一步精化需求，开发人员制作新的软件需求 改进后的软件需求，并作为下个原型的设计入口5瀑布开发原型得到用户认可按照V字瀑布模型进行产品开发参照V字模型3.5.3 适用情况l 项目包含一种新技术，例：新硬件、新的开发语言、新的系统架构等；l 需求不很清楚；l 存在关于性能、可靠性和可行性方面的主要的、未解决的问题；l 用户界面对系统成功是很关键的，但

22、不很清楚。3.5.4 优点l 开发者可以很快的构建系统，客户也可以尽快的感受到实际的系统。l 客户和开发者对系统有更好的理解。l 客户充分参与，可以减少部分培训的工作。3.5.5 缺点l 由于原型并非最终产品，如果原型不能利用，可能导致成本的增加；同时会引起客户的误解，以为产品即将完成。l 开发者为了使原型能够尽早工作，常常会采取一些临时性的做法，而不管这些做法是否合理，如：使用一个效率低的算法仅仅是为了演示功能。在经过一段时间后，开发者对这些做法已经习惯了，忘记了它们不合理的原因。于是这些不合理的做法就成了系统的组成部分。3.5.6 本企业适合的项目类型新领域的应用项目的开发；如企业应用系统

23、开发项目等。3.6 增量模型3.6.1 概述增量模型是一种进化软件过程模型，融合了线性顺序模型的基本成分（重复地应用）和原型模型的迭代特征，如下图所示。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用和/或评估的结果是下一个增量的开发计划，该计划包括对核心产品的修改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但能提供用户服务功能和用户评估的平台。图表 8 增量模型开发流程图3.6.2 阶段定义No阶段入口标准任务出口标

24、准1需求开发项目立项报告已经由高层经理签字，项目开始启动。需求访谈及分析系统分析软件需求规格说明书完成并形成基线2软件结构设计软件需求规格说明书已经完成并形成基线。进行系统总体结构设计和概要设计系统结构设计及概要设计说明书3增量1立项报告已经由高层经理签字，并进行了总体的需求开发及概要设计。进行第一阶段的详细设计、编码、测试及发布。第一阶段产品完成。4增量2增量1产品已经完成并完善了本阶段的需求开发及概要设计。进行第二阶段的详细设计、编码、测试及发布。第二阶段产品完成。5增量3增量2产品已经完成并完善了本阶段的需求开发及概要设计。进行第三阶段的详细设计、编码、测试及发布。第三阶段产品完成。6维

25、护产品全部投入运行进行系统维护组织不再对产品进行维护3.6.3 适用情况l 当项目可清晰地划分为多个功能独立的子项目，或采用阶段开发时，适合选择增量模型。l 市场期限或资源非常紧迫，不可能完成一个完善的产品时，但可以提交一个有限的版本以应付竞争和商业压力时，适合选择增量模型。l 核心产品或系统需求能够被很好的理解，但是细节尚需要进一步明确时，适合选择增量模型。3.6.4 优点l 有利于控制成本，可以用较少的成本先生成“产品核心”，然后根据需要适时生成完善的产品。l 可以有计划的管理技术风险，新的技术可以在增量版本中使用，减少在最初就采用新技术的风险。l 提供了用户评估的平台，能够更好的满足用户

26、需求。3.6.5 缺点由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，最终的产品也不是开放的，而是成为维护人员的恶梦。3.6.6 本企业适合的项目类型各种中、大规模的项目类型；已有系统技术路线发生改变但需求明确的移植类项目。3.7 增量的迭代过程模型3.7.1 概述该模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够辨别所开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的

27、设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具。图表 9增量的迭代模型3.7.2 阶段定义No阶段入口标准任务出口标准1迭代1立项报告已经由高层经理签字，并进行了总体的需求开发及概要设计。进行第一阶段的详细设计、编码、测试及发布。第一阶段产品完成。2迭代2迭代1产品已经完成并完善了本阶段的需求开发及概要设计。进行第二阶段的详细设计、编码、测试及发布。第二阶段产品完成。3迭代3迭代2产品已经完成并完善了本阶段的需求开发及概要设计。进行第三阶段的详细设计、编码、测试及发布。第三阶段产品完成。3.7.3 适用情况l 规模较大的项目

28、或产品，但是需求的清晰度低，且需要进一步的调查。 l 新领域或有大量新技术的应用。l 项目可清晰地划分为多个功能独立的子项目，或可以采用阶段开发。l 市场期限或资源非常紧迫，不可能完成一个完善的产品时，但可以提交一个有限的版本以应付竞争和商业压力。3.7.4 优点l 允许变更需求，中途的修改是容易的。 l 有助于项目团队的建设，团队成员有机会边做边学，积累知识和经验。 l 有利于控制成本，可以用较少的成本先生成“产品核心”，然后根据需要适时生成完善的产品。l 可以有计划的管理技术风险，新的技术可以在增量版本中使用，减少在最初就采用新技术的风险。l 提供了用户评估的平台，能够更好的满足用户需求。

29、3.7.5 缺点需要相当的风险评估的技术；每个迭代循环控制不好会变成边做边改模式。3.7.6 本企业适合的项目类型较复杂的应用项目，如：新一代银行综合业务系统。3.8 快速应用开发模型3.8.1 概述快速应用开发模型（RAD）是一个线性顺序的软件开发模型，强调极短的开发周期（23个月）。该模型是线性顺序模型的一个“高速”变种，如果需求理解得很好，且约束了项目范围，就可通过使用基于构件或可得用软件包的建造方法获得快速开发。主要适用于信息系统应用软件的开发。图表 10快速应用开发模型3.8.2 阶段定义No阶段入口标准任务出口标准1业务建模立项报告已经由高层经理签字，并对客户需求进行充分的理解和进

30、行可系统的结构设计分析业务信息流程，建立业务模型业务模型获得批准2数据建模业务模型已经建立根据业务模型，对信息进行细化，形成一组支持业务所需要的数据对象，标识出每个对象的属性，并且定义对象间的关系，形成数据模型数据模型获得批准3处理建模数据模型已经建立把数据模型定义的数据对象变换，以实现完成一个业务功能所需要的信息流处理模型获得批准4应用生成模型已经建立根据模型，使用自动化辅助工具和构造系统构件构件构造完成5测试构件构造完成反复进行构件和构件接口的测试，根据测试结果修改自动生成的代码，以达到设计要求，如效率和可维护性等构件测试通过，达到设计要求6集成和测试构件测试通过反复进行系统集成和测试，以达到设计要求系统测试通过7验收系统测试通过用户进行系统验收用户验收通过8维护用户验收通过，系统投入运行进行系统维护组织不在对产品进行维护3.8.3 适用情况当项目必须在最短的时间内完成，而且需求理解的很好且约束了项目范围，适合选择该模型。3.8.4 优点开发周期短。3.8.5 缺点对大型的、但可伸缩的项目，RAD需要足够的人力以创建足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD项目失败。3.8.6 本企业适合的项目类型