《软件生命周期模型选用指南[1].20130321.172544(精品)》由会员分享，可在线阅读，更多相关《软件生命周期模型选用指南[1].20130321.172544(精品)（13页珍藏版）》请在金锄头文库上搜索。
1、质量管理体系软件生命周期模型选用指南 版本：5.1深圳天源迪科信息技术股份有限公司文件编号：DIC-QMD-851-12 版 本：5.1 软件生命周期模型选用指南本文件属深圳天源迪科信息技术股份有限公司所有，未经书面许可，不得以任何形式复印或传播。自批准之日起实施文件建立/修改记录序号版本建立或修改建立/修改人日期审核人日期批准人日期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肖征2
2、012-9-25肖征2012-9-2555.1修订在第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.6V模型113模型的比较134其它模型采用说明131 简介1.1 目的建立和维护公司内部定义的软件生命周期模型，并供各软件项目组在项目计划时根据项目的具体情况选择或裁剪使用，由此确定软件项目开发过程的各种不同的
3、阶段以及各阶段的执行顺序。1.2 适用范围本文档适用于公司內软件研发类和工程类项目计划。1.3 背景描述无1.4 术语表软件生命周期：始于一个软件初始的想法，止于软件产品不再被使用。软件生命周期一般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段。软件过程：有关开发和维护软件及其相关产品（例如：项目计划、设计文档、代码、测试用例、用户手册等）的活动、方法、实践和变更的集合。1.5 参考资料软件项目管理案例教程，韩万江、姜立新编著，机械工业出版社，2005年2月2 软件生命周期模型描述 所有的项目软件开发过程都应遵循一个生命周期模型，每个模型都具有能够帮助实际软件项目进行控制
4、及协调的特征。定义生命周期模型的目的在于将本质上无序的活动有序化，在项目计划期间，必须仔细考虑项目的特征和目标之后，再选择生命周期模型。本指南描述常用的几个软件生命周期模型，项目可根据实际情况选择或按规定剪裁使用，但应注意与公司的标准软件开发过程相兼容。2.1 瀑布模型2.1.1 模型描述瀑布模型又称线性顺序模型，也称为传统模型，要求软件开发严格按照需求分析设计编码测试验收维护的阶段进行。模型中一个阶段的输出是下一阶段的输入，所以在每个阶段完成后都要组织相关的评审和验证，只有在评审通过，相关的产出物都已经基线后才能够进入到下一个阶段。瀑布模型中每一个阶段都不应该重叠，一个阶段完成后，一般不能返
5、回到上一个阶段。瀑布模型的开发流程如图21：图21：瀑布模型2.1.2 模型优点l 线性顺序的开发过程，一个过程顺着一个过程进行，简单、易用、直观；l 项目人员分阶段投入；l 强调早期计划，及需求获取的完整性和稳定性，一次性开发出一个完整的系统；l 易于划分里程碑，便于监督和控制。2.1.3 模型缺点l 要求在项目前期就明确需求，产品的运行版本直到项目开发后期方可见；l 用户直到项目结束方能了解产品的质量，不能逐步的熟悉系统；l 依赖于早期进行的需求调查，难以适应需求的变化；l 不允许变更或者限制变更，如果有未定义或未实施的需求，将会引起重复劳动，甚至开发出的产品不是用户所需要的。2.1.4
6、适用项目同时具备以下三个特点的项目，可以使用瀑布模型：1) 需求已经明确；2) 软件实现方法是成熟的；3) 项目周期较短。2.2 改进的瀑布模型2.2.1 模型描述瀑布模型中阶段工作不能重叠，开发者常因项目“阻塞状态”而等待组内其他成员完成任务，导致项目资源过多闲置，并严重影响项目进度。针对以上问题对原有瀑布模型进行了改进，在需求分析完成后，总体设计是软件开发的重要关注点，总体设计将系统划分为子系统和功能模块，定义功能模块间的接口，以及集成方案。在这种情况下，当一个模块的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才开始编码实现，因此在总体设计完成后可以将系统分为多个模块并
7、行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路。改进的瀑布模型的开发流程如图22：图22：改进的瀑布模型2.2.2 模型优点l 系统分子系统和功能模块按照设计实现测试过程进行；l 适当的重叠各个阶段过程，子系统和功能模块间可以并行开发，达到资源的有效利用。 2.2.3 模型缺点l 并行开发方式，对项目经理工作分解能力要求高，使用不当易造成项目开发混乱；l 要求总体需求及总体设计阶段有产品行业专家及技术专家介入，对公司人才要求较高。2.2.4 适用项目具备下列1）和2），或者2）和3）特点的项目可以选择改进的瀑布模型作为软件生命周期模型：1） 前期需求明确，系统可以划分为子系统和功能模块
8、；2） 软件实现方法是成熟的；3） 当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候，这个时候也可以选择将整个开发过程按独立的需求划分为多个小瀑布进行操作。2.3 原型瀑布模型2.3.1 模型描述为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型可以分为抛弃型的和进化型两种。抛弃型，原型仅仅是需求阶段方面和用户沟通的DEMO，原型建立、分析之后要抛弃，整个系统按照瀑布模型重新分析和设计。进化型则是对需求的定义有清楚的认识，原型建立之后要保留，作为系统逐渐增加的基础，采
9、用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发，原型（进化型）瀑布模型的开发流程如图23所示：图23原型瀑布模型（进化型）2.3.2 模型优点l 原型模型从需求收集开始，开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域；l 原型建造，采用“快速设计”，集中于软件那些对用户可见部分的表示，使用户能够感受到实际的系统；l 原型由用户评估，并进一步精确细化待开发软件的需求，逐步调整原型使其满足客户的要求。同时开发者对将要做
10、的事情有更好的理解，这个过程是迭代的；l 开发人员与用户交流直观，可以澄清模糊需求，调动用户的积极参与性。2.3.3 模型缺点l 针对于产品自身结构的不足，需要开发人员做实现上的折中；l 快速的建造出软件原型，一旦确定客户的真正需求，所建造的原型很可能被丢弃。2.3.4 适用项目具有以下情况之一的项目，建议选择原型瀑布模型：1) 需求不明确，用户对系统不了解，难以提出完整需求；用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求；2) 用户界面对系统成功是很关键的，但不很清楚；3) 项目组需要验证技术的可行性，如新的开发语言、新的系统架构、算法的有效性、操作系统的适应性或人机交互的
11、形式。2.4 增量模型2.4.1 模型描述增量模型是一种进化软件过程模型，融合了线性顺序模型的基本成分（重复地应用）和原型模型的迭代特征。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用或评估的结果是下一个增量的开发计划，该计划包括对核心产品的修改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但能提供用户服务功能和用户评估的平台。增量模型开发流程见图24：图24增量模型2.4.2 模型优点l 每一个增量均发布一个可操作产
12、品，第一个增量往往是核心产品，早期的增量是最终产品的“可拆卸”版本；l 当不能在计划周期内完成工作时，可先发布部分功能给用户；l 可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性。2.4.3 模型缺点l 由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，成为维护人员的恶梦；l 在增量过程中，存在相交情况下的执行过程且未很好处理，则必须做全盘系统分析；l 对软件产品的体系结构要求较高。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四个的基础功能都已经完成。增量的迭代过程模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够确定开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具（如：RUP、配置管理工具等），增量的迭代过程模型的开发流程见图24：图24增量的迭代过程模型2.5.2 模型优点l 基于风险前驱的原则，渐进地展开分析、设计及其相关活动，每个迭代都会提供一次验证和调整模型机会，推动软件质量的提升。2.5.3 模型缺点l 每个迭代循环控制不好会变成边做边改模式。2.5.4 适用项目增量的迭代过程模型适用于项目中存
