软件生命周期模型选用指引12013032172544

1、深圳天源迪科信息技术股份有限公司版 本：5.1文件编号：DIC-QMD-851-12软件生命周期模型选用指南本文件属深圳天源迪科信息技术股份有限公司所有，未经书面许可，不得以任何形式复印或传播。自批准之日起实施文件建立/修改记录厅P版本建立或修改建立/修改人日期审核人日期批准人日期14.0建立叶茂瑶2007-7-20陈庆山2007-7-30汪东升2007-8-3024.1修订陈志强2007-12-11陈庆山2008-01-18汪东升2008-1-2035.0修订在原来基础上区分 了模型的优点、缺点及适用项目的说明汪冉冉2012-8-20肖征2012-9-25肖征2012-9-2555.1修订在

2、第3章模型比较 中，增加了适用项目 类型和团队规模的 说明汪冉冉2013-2-20肖征2013-2-25肖征2013-2-25目录1 简介41.1 目的41.2 适用范围 41.3 背景描述41.4 术语表41.5 参考资料42 软件生命周期模型描述 42.1 瀑布模型42.2 改进的瀑布模型62.3 原型+瀑布模型82.4 增量模型92.5 增量的迭代过程模型 102.6 V 模型113 模型的比较134 其它模型采用说明131简介1.1 目的建立和维护公司内部定义的软件生命周期模型，并供各软件项目组在项目计划时根据项目的具体情况选择或裁剪使用，由此确定软件项目开发过程的各种不同的阶段以及各

3、阶段的执行顺序。1.2 适用范围本文档适用于公司内软件研发类和工程类项目计划。1.3 背景描述无1.4 术语表软件生命周期：始于一个软件初始的想法，止于软件产品不再被使用。软件生命周期一 般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段。软件过程：有关开发和维护软件及其相关产品（例如：项目计划、设计文档、代码、测 试用例、用户手册等）的活动、方法、实践和变更的集合。1.5 参考资料软件项目管理案例教程，韩万江、姜立新编著，机械工业出版社，2005年2月2软件生命周期模型描述所有的项目软件开发过程都应遵循一个生命周期模型，每个模型都具有能够帮助实际软 件项目进行控制及协调的

4、特征。定义生命周期模型的目的在于将本质上无序的活动有序化， 在项目计划期间，必须仔细考虑项目的特征和目标之后，再选择生命周期模型。本指南描述 常用的几个软件生命周期模型，项目可根据实际情况选择或按规定剪裁使用，但应注意与公 司的标准软件开发过程相兼容。2.1 瀑布模型2.1.1 模型描述瀑布模型又称线性顺序模型，也称为传统模型，要求软件开发严格按照需求-分析21:维护记录一设计一编码一测试一验收一维护的阶段进行。模型中一个阶段的输出是下一阶段的输 入，所以在每个阶段完成后都要组织相关的评审和验证，只有在评审通过，相关的产出 物都已经基线后才能够进入到下一个阶段。瀑布模型中每一个阶段都不应该重叠

5、，一个 阶段完成后，一般不能返回到上一个阶段。瀑布模型的开发流程如图图21 :瀑布模型2.1.2 模型优点线性顺序的开发过程，一个过程顺着一个过程进行，简单、易用、直观;项目人员分阶段投入;强调早期计划，及需求获取的完整性和稳定性，一次性开发出一个完整的系统;易于划分里程碑，便于监督和控制。2.1.3 模型缺点要求在项目前期就明确需求，产品的运行版本直到项目开发后期方可见;用户直到项目结束方能了解产品的质量，不能逐步的熟悉系统;依赖于早期进行的需求调查，难以适应需求的变化;不允许变更或者限制变更，如果有未定义或未实施的需求，将会引起重复劳动，甚 至开发出的产品不是用户所需要的。2.1.4 适用

6、项目同时具备以下三个特点的项目，可以使用瀑布模型：1） 需求已经明确；2）软件实现方法是成熟的；3）项目周期较短。2.2 改进的瀑布模型2.2.1 模型描述瀑布模型中阶段工作不能重叠，开发者常因项目“阻塞状态”而等待组内其他成员 完成任务，导致项目资源过多闲置，并严重影响项目进度。针对以上问题对原有瀑布模 型进行了改进，在需求分析完成后，总体设计是软件开发的重要关注点，总体设计将系 统划分为子系统和功能模块，定义功能模块间的接口，以及集成方案。在这种情况下， 当一个模块的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完 才开始编码实现，因此在总体设计完成后可以将系统分为多个模块

7、并行开发，每个模块 仍然遵循先设计和编码测试的瀑布模型思路。改进的瀑布模型的开发流程如图2-2:2.2.2 模型优点系统分子系统和功能模块按照设计一实现一测试过程进行；适当的重叠各个阶段过程，子系统和功能模块间可以并行开发，达到资源的有效利用。2.2.3 模型缺点并行开发方式，对项目经理工作分解能力要求高，使用不当易造成项目开发混乱；要求总体需求及总体设计阶段有产品行业专家及技术专家介入，对公司人才要求较2.2.4 适用项目具备下列1）和2）,或者2）和3）特点的项目可以选择改进的瀑布模型作为软件生命周期模型：1）前期需求明确，系统可以划分为子系统和功能模块；2）软件实现方法是成熟的；3）当一

8、个新系统的开发存在多个完全不相关的独立需求的功能开发的时候，这个时候也可以选择将整个开发过程按独立的需求划分为多个小瀑布进行操作。2.3 原型+瀑布模型2.3.1 模型描述为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过 建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被 客户所理解。原型可以分为抛弃型的和进化型两种。抛弃型，原型仅仅是需求阶段方面和用户沟 通的DEMO ,原型建立、分析之后要抛弃，整个系统按照瀑布模型重新分析和设计。进 化型则是对需求的定义有清楚的认识，原型建立之后要保留，作为系统逐渐增加的基础， 采用进化型一定要重视软件设计

9、的系统性和完整性，并且在质量要求方面没有捷径，因 此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建 立确认需求之后采用瀑布模型的方式完成项目开发，原型（进化型）+瀑布模型的开发 流程如图23所示：多次迭代原型逐渐完善部?可求 一L 原型设计-L 原型实现 L原型测试 L 瀑布测试图23原型+瀑布模型（进化型）2.3.2 模型优点原型模型从需求收集开始，开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域；原型建造，采用 快速设计”，集中于软件那些对用户可见部分的表示，使用户能够感受到实际的系统；原型由用户评估，并进一步精确细化待开发软件的

10、需求，逐步调整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解，这个过程是迭代的；开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与性。深圳天源迪科信息技术股份有限公司第8页共13页2.3.3 模型缺点针对于产品自身结构的不足，需要开发人员做实现上的折中；快速的建造出软件原型，一旦确定客户的真正需求，所建造的原型很可能被丢弃。2.3.4 适用项目具有以下情况之一的项目，建议选择原型+瀑布模型：1）需求不明确，用户对系统不了解，难以提出完整需求；用户定义了一组一般性目标， 但不能标识出详细的输入、处理及输出需求；2）用户界面对系统成功是很关键的，但不很清楚；3）项目组需要验

11、证技术的可行性，如新的开发语言、新的系统架构、算法的有效性、 操作系统的适应性或人机交互的形式。2.4 增量模型2.4.1 模型描述增量模型是一种进化软件过程模型，融合了线性顺序模型的基本成分（重复地应用）和原型模型的迭代特征。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用或评估的结果是下一个增量的开发计划，该计划包括对核心产品的修改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的可拆卸”版本，但能提供用户服务功能和用户评估的平台。增量

12、模型开发流程见图24:图24增量模型2.4.2 模型优点每一个增量均发布一个可操作产品，第一个增量往往是核心产品，早期的增量是最终产品的可拆卸”版本；当不能在计划周期内完成工作时，可先发布部分功能给用户；可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性。2.4.3 模型缺点由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，成为维护人员的恶梦；在增量过程中，存在相交情况下的执行过程且未很好处理，则必须做全盘系统分析；对软件产品的体系结构要求较高。2.4.4 适用项目具有以下情况之一的项目，建议选择增量模型：1）项

13、目开始时明确了大部分的需求，但是需求可能会发生变化的项目；2）对于市场和用户把握不是很准，需要逐步了解的项目；3）对于有庞大和复杂功能的系统进行功能改进时需要一步一步实施的项目。2.5 增量的迭代过程模型2.5.1 模型描述增量和迭代有区别但两者又经常一起使用，所以这里要先解释下增量和迭代的概念。假设现在要开发 A, B, C, D四个大的业务功能，每个功能都需要开发两周的时间。则对于增量方法而言可以将四个功能分为两次增量来完成，第一个增量完成A, B功能，第二次增量完成 C, D功能；而对于迭代开发来将则是分两次迭代来开发，第一次迭代完成A, B, C, D四个基本业务功能但不含复杂的业务逻

14、辑，而第二个功能再逐渐细化补充完整相关的业务逻辑。在第一个月过去后采用增量开始时候A, B全部开发完成而 C, D还一点都没有动；而采用迭代开发的时候A, B, C, D四个的基础功能都已经完成。增量的迭代过程模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够确定开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构

15、件和有相应的构件开发工具（如：RUP、配置管理工具深圳天源迪科信息技术股份有限公司第10页共13页等)，增量的迭代过程模型的开发流程见图2 4:图24增量的迭代过程模型2.5.2 模型优点基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一 次验证和调整模型机会，推动软件质量的提升。2 . 5.3模型缺点每个迭代循环控制不好会变成边做边改模式。3 .5.4适用项目增量的迭代过程模型适用于项目中存在有很多风险，较复杂的应用项目。2.6 V模型2.6.1 模型描述V模型是在快速应用开发(RAD , Rap Application Development)模型基础上演变而来,由于

16、将整个开发过程构造成一个V字形而得名。V模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软件质量情况下缩短开发周期。下面通过对这种模型的水平和垂直的关联和比较分析，理解软件开发和测试的关系，理解V模型具有面向客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效 的、更具有可操作性的软件开发过程。确认熟成图25 V模型噩求出取业外需求租用I 、：.血球工、需求：H-i创建使用 HyperSnap-DX5她歌许筠金瞽除此林记.宿民用如帆件http:/www. hyperio nic n/我统飒试从水平对应关系看左边是设计和分析，是软件设计实现的过程，同时伴随着质量保

17、证活动一一审核的过程，也 就是静态的测试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进 行测试，以确认是否满足用户的需求。如：需求获取的阶段，即业务需求和用户需求对应验收测试，说明在做需求分析、产品功能设计 的同时，测试人员就可以阅读、审查业务需求和用户需求，从而了解产品的设计特性、用户的真 正需求，确定测试目标，可以准备用例 （Use Case）并策划验证测试活动。与需求分析对应的是系统测试。因为需求分析的工作是分解用户的功能和性能需求并规格 化，所以系统测试的工作主要就是测试这些功能和性能指标是否都在软件中正确实现。该测试把 软件作为一个黑盒，针对每个需求规格组织各

18、种输入并根据软件输出来判断该需求规格是否正确 实现，因此系统测试属于黑盒测试。与概要设计对应的是集成测试。因为概要设计的工作主要是 根据功能把大的系统进行模块分解，所以集成测试的工作主要是，把各模块逐步集成在一起，来 测试数据是否能够在各模块间正确流动，以及各模块能否正确同步。因为这种测试依赖于软件的 架构但又不关心每个函数的实现细节，所以该测试又常称为灰盒测试。与详细设计对应的是单元 测试。它主要是详细设计中的每个功能单元（通常是函数或过程）进行逻辑覆盖测试，因此这种 测试属于白盒测试。与从需求到设计、系统测试，于是就形成了一个V字形的结构。从垂直方向看水平虚线上部表明，其需求获取、定义和验收测试等主要工作是面向用户，要和用户进行充 分的沟通和交流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工 作，在开发组织内部进行，主要是由工程师、技