02.软件项目生存期模型选择

软件生命周期模型

瀑布模型/改进的瀑布模型虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最展本的和最效的?种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求-〉分析-〉设计?〉编码-> 测试的阶段进行，每-个阶段都可以定义明确的产出物和验证准则.瀑布模型在每?个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下-个阶段. 由于需要对每?个阶段进行验证，瀑布模型要求每?个阶段都有明确的文档产出，对于严格的瀑布模型每?个阶段都不应该重叠,而应该是在评审通过，相关的产出物都己经基线后才能够进入到下?个阶段. 瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够捉前的被发现和解决. 采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性?但对于前期需求不明确,而又很难短时间明确淸楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题. 很多人往往会以进度约束而不选择瀑布模型，这往往是?个错误的观点.导致这种情况的?个关键因素往往是概念需求阶段人力不足.冈此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太人的差别.反而是很多项目对于迭代或嫩捷模型用不好，为了赶进度在前期需求不明确，没有经过?个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度. 架构设计是软件开发中?个重要的关注点.因此在RUP中也捉及到软件开发要以架构为核心.因此在架构设计完成后系统会彼分为相关的f?系统和功能模块.每个功能模块间的接口都可以定义淸楚.在这种情况下，当模块B的详细设计做完成后往往就没有必妥等到其它模块的详细设计都妥完全作完才开始编码，冈此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的?种最重要的改进思路，也可以说这是?种增量开发的模型.

软件生命周期模型选择及WBS分解指南

软件生命周期模型选择及WBS分解指南一、概述同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为“软件生命周期”。软件生命周期模型，通俗说就是，软件开发过程中所遵循的模式，即把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大，结构复杂和管理复杂的软件开发变的容易控制和管理。软件生命周期模型和项目开发过程有非常紧密关系，它是经过多次实践总结出来适合于不同项目使用的经典、有效的软件开发方法，它按照软件生命周期的各个阶段划分任务，依照一定的规则和步骤，有效地进行软件开发。选用恰当的软件生命周期模型进行软件开发，可以提高产品质量；降低项目管理难度；缩短开发进度；便于项目状态跟踪；为过程改进和度量提供基线；改善组织级的过程弱势，提高过程能力成熟度级别。为了便于分类汇总和统计各种生命周期模型的指标和数据，结合公司软件开发过程的实际，我们选择了常用的几种基本模型进行了描述，项目开发小组在进行项目策划时，可以根据模型的适用前提、优缺点和项目的实际需要进行选择，并在《项目实施计划》中，参加评审。二、软件生命周期模型常用的软件生命周期模型有：瀑布模型、迭代模型、增量模型、原型模型等。以上所提到的件生命周期模型病不存在孰优孰劣的问题，每一种模型在实际工作中都有所应用。只要选择了最适合的，并按照此模型的流程来开发软件，都会取得成功。需要强调的是，不管采用什么模型，项目实施中有四项活动是必不可少的——需求、设计、编码和测试。不管是有意识还是无意识，这些活动都会出现在项目过程中。这也是最重要的四项活动，其他的活动其实都是为这些活动服务的，不管是配置管理、风险管理，还是评审等等。以下对各种常用的软件生命周期模型的设计思想、WBS划分（Work Breakdown Structure，即工作分解结构）、优缺点、使用范围进行分析。

软件生命周期模型

软件生命周期模型 .软件生命周期对于一个软件的研制，从问题的提出，经过开发、使用、维护、修订，直到最后终止使用而被另一软件所取代，就像是一个生命体从孕育、出生、成长到最后消亡，软件的这个状态变化的过程称为生命周期(life cycle)。软件生命周期的演化具有阶段性，依据一定的原则，可以把软件生命周期划分为若干不同阶段，相邻的阶段既相互区别又相互联系，每个阶段都以其前一阶段的工作成果作为本阶段工作的基础。软件生命周期的划分有助于软件开发和管理人员根据不同阶段的特点进行软件开发及其管理。软件开发的经验表明，软件开发越到后期，改正前期开发工作的失误越困难，因此在软件开发工作中应该对软件开发工作的阶段性给予充分认识，在前期工作不无分的前提下不应过早地进入软件开发的下一阶段。依据不同的原则对软件生命周期的划分也不同，《软件工程国家标准--计算机软件开发规范》(GB8566-88)中将软件生命周期划分为8个阶段：可行性研究与计划、需求分析、概要设计、详细设计、实现(包括单元测试)、组装测试(集成测试)、确认测试、使用和维护。本书按照人们所习惯的粗分方法把上面8个阶段划分为计划、开发和维护3个阶段，在概述其他两个阶段的基础上重点介绍软件的开发过程。2.软件开发方法在规定的投资规模和时间限制内，实现符合用户需求的高质量软件是软件开发的目标，为实现这一目标，人们根据软件开发的特点，提出了多种软件开发策略。通过不同的软件开发模型阐明从问题提出到最终软件实现，软件开发工作过程的阶段性任务分解，并规定了每一个阶段的目标、任务以及工作结果的表达形式。常见的软件设计模型有：瀑布模型(waterfall model)、渐进模型(increamental model)、演化模型(evolutionary model)、螺旋模型(spiral model)、喷泉模型(fountain model)、智能模型(intelligent model)等。这里介绍其中的3种。(1)瀑市模型瀑市模型1970年由W.Royce提出，其开发过程依照固定顺序进行，各阶段的任务与工作结果如图1所示。该模型严格规定各阶段的任务，上一阶段任务输出作为下一阶段工作输入。此模型适合于用户需求明确、开发技术比较成熟、工程管理严格的场合使用，其缺点是：由于任务顺序固定，软件研制周期长，前一阶段工作中造成的差错越到后期越大，而且纠正前期错误的代价高。图1瀑布型开发过程(2)渐进模型从一组简单的基本用户需求出发，首先建立一个满足基本要求的原型系统。通过测试和运行原型系

软件项目管理生存期模型实例

合同登记编号：生存期模型选择项目名称：西安财经学院实验室管理系统委托人（甲方）：西安财经学院研究开发人（乙方）：赵哲签订地点：西安市签订时间：2012年1月1日有效期限：2012年1月1日至2012年5月20日西安市技术市场管理办公室

针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如图1所示：理由如下： 1）西安财经学院实验室管理系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能做出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2）在西安财经学院实验室管理系统需求中，要求系统具有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。 3）“系统要求有可扩充性，可以再现有系统的基础上，可以在前台加挂其他功能模块”----也说明用户可能会增加新的需求。 4）应该从最基础的应用做起，逐步扩充其应用，所以选用增量模型来西安财经学院实验室管理系统系统。 5）本项目具备增量式模型的其他特点： ● 项目复杂程度为中等； ● 预计开发软件的成本为中等； ● 产品和文档的再使用率会很高； ● 项目风险较低。生存期中各阶段的定义如下：项目规划阶段阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。项目规划需求分析设计增量 1 增量 2 增量 3 增量 4 增量 5 系统测试产品提交

软件生存周期模型-瀑布模型

作业要求:除课件中介绍的几种软件生存周期模型，请详细介绍其他一种或几种生存周期模型，也可以是在实践开发过程中使用某种模型的心得体会，或者是针对某种模型的意见建议等。 1.瀑布模型 1.1.瀑布模型定义瀑布模型也称“线性顺序模型”。瀑布模型规定了各项软件工程活动，包括：制定开发计划，进行需求分析和说明，软件设计，程序编码，测试及运行维护。并且规定了它们自上而下，相互衔接的固定次序，如同瀑布流水，逐级下落。由于需要对每一个阶段进行验证，瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过，相关的产出物都已经基线后才能够进入到下一个阶段。 1.2.瀑布模型特点：瀑布模型提供了软件过程模型的基本模板。强调了每一阶段活动的严格顺序。瀑布模型是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。

瀑布模型的优点是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决。采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性。瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。缺点就是不够灵活。但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设计和开发人员往往在项目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题。 1.3.使用心得虽然瀑布模型存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段。很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确,没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度. 架构设计是软件开发中一个重要的关注点.因此在RUP中也提及到软件开发要以架构为核心.因此在架构设计完成后系统会被分为相关的子系统和功能模块.每个功能模块间的接口都可以定义清楚.在这种情况下,当模块B的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才开始编码,因此在架构设计完成后可以将系统分为多个模块并行开发,每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的一种最重要的改进思路,也可以说这是一种增量开发的模型。图示如下：

校务通生存期模型案例

案例说明-《校务通管理系统》的生存期模型针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下： 1．校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2．在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”；资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3．“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其它功能模块”。也说明用户可能会增加新的需求。 4．对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5．本项目具备增量式模型的其他特点 a)项目复杂程度为中等。 b)预计开发软件的成本为中等。 c)产品和文档的再使用率会很高, d)项目风险较低图:项目生存期模型

生存期中的各阶段定义如下：项目规划阶段阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。输入：合同文本 SOW 过程：项目规划，计划确认输出：项目计划需求分析阶段阶段目标：确定客户的需求输入：项目计划，SOW 过程：需求获取，需求分析，需求控制输出：原型系统，需求规格设计阶段阶段目标：总体系统结构设计输入：原型系统，需求规格过程：总体设计输出：系统设计说明书，数据库结构定义增量1实现阶段目标：实现系统的通用功能输入：系统设计说明书数据库结构定义过程：详细设计,编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本－1 增量2实现阶段目标：实现系统的招生管理功能输入：系统设计说明书数据库结构定义过程：详细设计,编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本－2 增量3实现阶段目标：实现系统的学生日常管理功能输入：系统设计说明书数据库结构定义过程：详细设计,编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本－3 增量4实现阶段目标：实现系统的教务管理功能输入：系统设计说明书数据库结构定义过程：详细设计,编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本－4 增量5实现阶段目标：实现系统的教师辅助功能输入：系统设计说明书数据库结构定义过程：详细设计,编码，代码走查，代码评审，单元测试

5种项目生命周期模型

5种项目生命周期模型 1.项目生命周期定义 2.一个完整的项目生命周期一般分为：计划、需求分析、设计、编码、测试、发布、实施以及运行维护阶段。参见下图标准过程： 3.软件过程模型是从项目需求定义直至经使用后废弃为止，跨越整个生存期的系统开发、运营维护所经历的全部过程、活动和任务的结构框架。 4.软件过程模型一般分为：瀑布模型、原型模型、螺旋模型、增量模型。 5. 5种项目生命周期模型 a.瀑布模型： 1) 特点 l 阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的输入。对本阶段工作进行评审，若得到确认，则继续下阶段工作，否则返回前一阶段，甚至更前阶段。只有前一阶段输出正确，后一阶段才能正确。 l 推迟实现的观点：在编码之前，设置了需求分析与设计的各个阶段，分析与设计阶段的根本任务规定在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 l 质量保证的观点：每个阶段都坚持两个做法：规定文档，没有文档就没有完成该段任务。每个阶段结束前都要对完成的文档进行评审，以便尽早发现问题，改正错误。 2) 缺点 l 依赖于早期进行的唯一的一次需求调查，不能适应需求的变化； l 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； l 风险往往迟至后期的开发阶段才显露，因而失去及早纠正的机会。 3) 适用项目

l 需求清晰明了且时间要求宽松的软件开发项目； l 规模小，需求简单，功能单一的项目 4) 阶段划分计划阶段需求阶段设计阶段编码阶段测试阶段发布阶段实施阶段运行维护阶段 b.原型模型：原型模型快速建立起来的可以在计算机上运行的程序，他所能完成的功能往往是最终产品能完成的功能的一个子集。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品，这个产品只实现部分功能。原型最重要的是为了确定用户的真正需求。原型模型在克服瀑布模型缺点、减少由于软件需求不明确给开发工作带来风险方面，确有显著效果。软件系统的原型常用有以下形式：抛弃型：开发原型为了获取需求，在原型开发之后，已获取了更为清晰的需求信息，原型无需保留而废弃；渐进型：原型作为软件最终产品的一部分，可满足用户的部分需求，进一步在此基础上开发，则可增加需求，实现后再交付使用； 1) 特点 l 用户需求不完全或不确定；

软件生命周期模型优缺点

软件生命周期模型优缺点瀑布模型把每个阶段当成瀑布中的一个阶梯，强调由上而下，互相衔接、逐级下落，固定次序。优点：开发阶段清晰，便于评审、审计、跟踪、管理和控制缺点：不可逆或很难可逆问题会积累，错误会传递发散扩大，导致成本和质量失控快速原型模型（原型模型）快速原型模型的第一步是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。优点：克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险缺点：所选用的开发技术和工具不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。增量模型增量模型也称为渐增模型。增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性系列产生软件的一个可发布的增量。优点：人员分配灵活，开始不用投入大量的人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。增量能够有计划的管理技术风险。缺点：由于各个构件是逐渐并入已有的软件体系结构中，所以加入构件必须不破坏以构好的的系统部分，这需要软件具备开放式的体系结构。在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改的模型，从而使软件过程的控制失去整体性。如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。螺旋模型螺旋模型采用一种周期性的方法来进行系统开发。优点：设计上的灵活，可以在项目的各个阶段进行变更。以小的分段来构建大型系统，使成本计算变得简单容易。客户始终参与每个阶段的开发，保证了项目部偏离正确方向以及项目的可控性。缺点：建设周期长，而软件技术发展比较快，所以经常出现软件开发完毕后，和当前的技术水平有了较大的差距，无法满足当前用户需求。喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。优点：需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

软件项目生命周期模型

软件项目生命周期模型当一个软件产品在没有规格说明或主要设计的情况下被开发时，开发者往往不得不重新对产品编码多次直到他们得到正确稳定的产品。这种开发模型就是编码-修补模型。开发者们首先开发出一个产品的最初版本给客户验收，然后开发团队开发一个新的版本再次给客户验收。这个过程一直持续到客户感觉产品满意为止。这种开发模型有几个缺点。最重要的缺点是存在于需求，设计和实现中的错误要到整个产品被构建出来后才能被发现。如果因为客户的验收，已经完成的模块需要重大的改变，那么整个开发的时间和花费将会大得多。编码-修补模型对于大于 100行代码的软件系统来说是个很坏的选择。另一个缺点就是这种模型开发出来的产品很难去理解和维护，因为他们缺乏任何需求和设计文档。因为这种模型没有包括编码前的开发阶段，所以它不被认为是一个完整的生命周期模型。然而在某些场合这种简单的方式非常有用。对于需求非常简单和容易明白，软件期望的功能行为容易定义，实现的成功或失败容易检验的工程可以使用这种模型。瀑布模型直到十九世纪八十年代早期，唯一被广泛接受的模型就是瀑布模型。瀑布模型包括了全部的开发阶段（需求，规格说明，设计，实现，集成，操作和维护）。这些阶段被安排成一定的顺序。当每个阶段完成了，它将被检验和测试，也就是说每个阶段在被认为完成之前必须由软件质量保证小组认可。瀑布模型的主要特征是它支持下一个阶段到上一阶段的反馈。假如，原是设计阶段的一个错误在实现阶段被发现。在瀑布模型中，设计所需的改变被输入设计阶段的第二次迭代，在工作继续之前这些改变需要被调整和经历一个额外的检验步骤。所有后继的阶段必须适应设计的改变。一个正式反馈机制的出现保证了开发周期中的调整可以在最小破坏的范围内得到解决。然而瀑布模型有个重要的潜在缺陷。这种模型依赖详细的文档同客户关于软件的需求功能达成一致意见。因为它需要技术能力去明白详细的软件规约，可能会出现客户与开发者对软件理解不同的风险。这会导致开发者开发出的软件满足了规格说明，但是那不是客户所期望的。快速原型模型瀑布模型假设大多数，并不是所有的需求分析和规格说明发生在代码编码和模块测试之前。这个假设当客户缺少技术知识，不能写出一份详细的需求清单或者不能完全参与到需求分析过程时就没有作用了。快速原型模型快速创建一个软件系统原型。它可能包括期望功能或用户界面的一个子集，但是它可能在范畴，健壮性，性能和平台方面受限。快速原型的优点是它可以使用户集中精力参与到需求的讨论中来。即使客户缺乏技术知识用软件工程术语来描述需求，客户也能够谈论用户界面，它是怎么样组织的，它提供了什么功能等等。如果开发者能够创建一个将要被开发系统的工作模型，

软件生存周期模型及特点

6有哪些生存周期模型？各有什么特点？（1）瀑布模型瀑布模型（Waterfall Model）是1970年由著名软件工程专家Winston Royce提出的，直到20世纪80年代早期，它一直视为已被广泛采用的软件开发模型。瀑布模型将软件生存周期中各活动（制定计划、需求分析、系统设计、编码、测试和维护）规定为依线性顺序的若干阶段，各项活动自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。瀑布模型的特点： <1>瀑布模型具有顺序性和依赖性,即后一阶段工作必须在前一阶段工作完成后才能开始。 <2>推迟实现的观点；把逻辑设计与物理设计清楚地划分开，尽可能推迟物理模型的实现，这是瀑布模型的重要指导思想。 <3>质量保证的观点。瀑布模型强调的是优质，即每一步都循序渐进，及早消除隐患，从而保证软件质量。 <4>致命缺点是只有做出精确的需求分析，才能取得预期的结果。由于各种客观、主观的原因，需求分析往往不很精确，常常给日后的开发带来隐患。（2）原型模型原型模型（Prototype Model）又称为演化模型，主要针对实现不能完整定义需求的软件项目开发而言。它是以一个“样品”为雏形，通过不断改进、完善样品，使得最后得到的产品就是客户所需要的。主要思想：先借用已有系统作为原型模型，通过“样品”不断改进，使得最后的产品就是用户所需要的。原形模型的特点： <1>开发人员和用户在“原型”上达成一致。这样可以减少设计中的错误和开发中的风险，以及对用户培训的时间，而提高了系统的实用、正确性以及用户的满意程度。 <2>缩短开发周期，加快工程进度。 <3>降低成本。 <4>原型模型的缺点：当告诉用户，还必须重新生产该产品时，用户是很难接受的。这往往给工程继续开展带来不利因素。（3）增量模型在增量模型（Incremental Model）中，软件被视为一系列的增量构建来设计、实现、集成和测试。增量模型是把整个软件系统分解为若干个软件构件，开发过程中，逐个实现每个构件，实现一个构件，展示一个构件。如果发现问题可以及早进行修正，逐步进行完善，最终获得满意的软件产品。增量模型特点： <1>增量模型是一种非整体开发的模型。软件在该模型中是“逐渐”开发出来的，开发出一部分，向用户展示一部分，让用户及早看到部分软件，及早发现问题。或者先开发一个“原型”软件，完成部分主要功能，展示给用户征求意见，然后逐步完善，最终后的满意的软件产品。 <2>该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。 <3>缺点：要求软件具有开放的结构是这种模型固有的困难，可能会导致设计差、效率低、维护难。（4）螺旋模型 1998年，Barry Boehm发表了“螺旋模型（Spiral Model）”，它将瀑布模型和快速原型模型集合起来，强调其他模型所忽视的风险，特别适合于大型复杂系统。该模型分为4个环

软件工程4种生命周期模型优缺点

实验一比较4种生命周期模型优缺点一、实验目的与要求比较4种生命周期模型优缺点及适用背景二、实验内容分析每一种生命周期模型优缺点、利用Internet搜索相关软件项目所使用生命周期模型并分析特点，从而更进一步的了解各生命周期模型的适用背景 1.瀑布模型：背景：在20实际80年代之前，瀑布模型一直被广泛采用的生命周期模型，现在它仍然是软件工程中应用得最广泛的过程模型。传统软件工程方法学的软件过程，基本上可以用瀑布模型来描述。特点： A.阶段间具有顺序性和依赖性：必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档，因此只有前一阶段的输出文档正确，后一阶段的工作才能获得正确的结果。 B.推迟实现的观点：瀑布模型在编码之前设置了系统分析与系统设计的各个阶段，分析与设计阶段的基本任务规定，在这个两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要指导思想。 C.质量保证的观点：软件工程的基本目标是优质、高产。瀑布模型的每个阶段都应坚持两个重要做法： a.每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。完整、准确的合格文档不仅是软件开发时期各类人员之间相互通信的媒介，也是运行时期对软件进行维护的重要依据。 b．每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。总之，瀑布模型胡完全依赖于书面的规格说明。 D．可强迫开发人员采用规范的方法；严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。缺点： A.各个阶段产生的文档时维护软件产品时必不可少的，没有文档的软件几乎是不可能维护的。 B.瀑布模型是由文档驱动的，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。 C.由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。 2.快速原型模型背景：快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型的第一步是快速建立一个能反馈用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……一旦用户认为这个圆形系统确实能做他们所需要的工作，开发人员便可据此书写规格说明文档，根据这份文档开发出的软件便可以满足用户的真实需求。特点：

软件生存周期模型的特点,及实践中采用的模型

软件生存周期模型的特点,及实践中采用的模型软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。（一）瀑布模型特点： ●阶段间的顺序性和依赖性 ●推迟实现的观点 ●质量保证的观点（文档驱动性）优点 ?可强迫开发人员采用规范的方法 ?严格地规定了每个阶段必须提交的文档 ?要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证缺点 ?周期长：顺序推进，环环审查 ?需求难以准确把握(不能准确提出和沟通、不能快速适应变化的需求)，导致返工甚至推倒重来 ?无法预测新引入模块的影响 ?最终的形式难以预料 ?不适合需求模糊的系统瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是

瀑布开发名称的由来。瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。对于经常变化的项目而言，瀑布模型毫无价值。（二）演化模型（适用于大型软件的开发）优点 ?能在较短的时间内向用户提交部分功能的构件； ?逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，减少一个全新软件可能给用户带来的冲击。缺点 ?增量构件的划分依赖于系统功能的构成和软件开发人员的经验； ?要求软件系统的体系结构具有高度的可扩充性和开放性。演化模型是一种全局的软件(或产品)生存周期模型。属于迭代开发风范。模型可以表示为：第一次迭代(需求->设计->实现->测试->集成)->反馈->第二次迭代(需求->设计->实现->测试->集成)->反馈->…… 即根据用户的基本需求，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称之为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。采用演化模型的开发过程，实际上就是从初始的原型逐步演化成最终软件产品的过程。演化模型特别适用于对软件需求缺乏准确认识的情况。（三）螺旋模型螺旋模型的每一个周期都包括需求分析、风险分析、工程实现和评审4个步骤。螺旋模型主要适用于内部开发的大规模软件项目。当风险过大时，可方便的终止项目。特点

OPD-3-01 软件开发生命周期模型

本资料仅供内部使用！软件开发生命周期模型东南融通集团 2006年4月30日

软件开发生命周期文件编号：OPD-3-01 版本：B 修改记录

目录 1目的 (1) 2范围 (1) 3软件开发生命周期模型 (1) 3.1.1标准V-瀑布生命周期(SVW) (2) 3.1.2V-瀑布生命周期为关键产品(VC) (3) 3.1.3阶段V-瀑布生命周期(V4) (5) 3.1.4阶段V-瀑布生命周期(V3) (6) 3.1.5编码和修正生命周期(C&F) (7) 3.1.6阶段交付模型 (8) 3.1.7交叠瀑布模型 (9)

1目的描述组织范围内使用的软件开发生命周期模型； 2范围本文档主要描述软件项目开发生命周期模型,适用于集团内部研发项目、为客户开发系统的项目、推广移植的项目、维护项目等。 3软件开发生命周期模型每种模型都用图形的方式来描述，显示了它们应用的阶段和阶段评审检查点。描述了在何种条件下使用该模型，需要注意风险和应用裁剪的指导。每一幅图都指出了运用于该模型的阶段和阶段评审检查点。用粗体和斜体表示的阶段评审检查点推荐要有高层经理参加。所有的阶段评审检查点都要由项目经理签字。主要阶段: ●项目售前/定义(PD) ●项目立项/启动(PI) ●需求分析和计划(RA&P) ●概要设计(HLD) ●详细设计(DD) ●编码和单元测试(CUT) ●集成测试(IT) ●系统测试(ST) ●发布/上线(REL) ●关闭(CLS) 阶段评审检查点 ●顾客签字(CUSTSO) ●开始(KO) ●需求签字(RSO) ●架构签字(ASO) ●设计签字(DSO) ●编码签字(CSO) ●功能完成(FC) ●系统完成(SC) ●发布完成(RC) 利用这节提供的细节来最终选择软件开发生命周期的模型。对大多数的项目，从前面的部分表格来看可能有不止一种适合的模型。利用本节所详细描述的模型，有适应或裁剪地最终

软件项目生存期模型确定实验1

南京信息工程大学实验（实习）报告实验名称软件项目生存期模型确定实验（实习）日期 9.30 得分指导教师徐旦华系计算机与软件学院专业软件工程年级班次姓名学号一、实验目的 1. 学习软件项目生存期模型的内容及特点；重点掌握预测型生存期模型及迭代型生存期模型、增量型生存期模型及敏捷模型的内容。 2.掌握各生存期模型的特点及项目适用范围。 3.学习利用所学知识，分析软件项目特性，确定合适的生存期模型。二、实验内容对仓库管理系统确定生存期模型。软件项目基本情况如下：甲方对软件项目开发时间要求是２０１９年１１月－２０２０年４月，请根据软件项目具体内容分析项目特性，根据己方资源，确定采用的生存期模型，要求给出项目分析过程，详细给出选择某生存期模型的理由，并给出生存期各阶段的相应的任务。三、实验结果（1）选择增量模型原因 1.首先，甲方要求的系统为仓库管理系统，时间为半年，而仓库管理系统全部功能大致可以分为：人员管理和货物管理两大部分，因此可以先基于这两个部分做出一个最小的使用版本，再逐渐根据用户使用的反馈来添加一些新的功能，有助于下一阶段的开发，也大大地减少了开发的风险。 2.对于仓库管理系统，可能存在货物变动，或者人员变动，因此应该默认要求系统有可扩充性。使用增量模型，可以保证系统的可扩充性，用户明确了一部分需求，但仍然有一部分隐藏的需求需要在后序的使用中慢慢反馈，进而添加或者修改功能。 3.对于一个管理方式可能已经固化的企业，要舍弃原有的仓库管理方式，用该系统完全代替是不太容易实现的，因此可以先完成基础的版本，逐步通过实际的使用来扩充应用，所以我选用了增量模型来研发仓库管理系统。 4.本项目具备增量模型的一些特点：完成期限要求严格的产品；对于市场和用户把握不是很准，需要逐步了解（2

案例说明-《校务通管理系统》的生存期模型

《校务通管理系统》的生存期模型针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下： 1．校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2．在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如：“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”；资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3．“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其它功能模块”。也说明用户可能会增加新的需求。 4．对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5．本项目具备增量式模型的其他特点 a)项目复杂程度为中等。 b)预计开发软件的成本为中等。 c)产品和文档的再使用率会很高, d)项目风险较低

软件生命周期之需求分析和设计说明

软件生命周期之需求分析和设计什么是软件生命周期？软件生命周期又称为软件生存周期或系统开发生命周期，是指从软件的产生直到报废的整个过程，它包括问题定义，可行性分析，总体描述，系统设计，编码，调试和测试，验收与运行，维护升级到废弃等阶段。每一个阶段都有确定的任务，并产生一定规格的文档，提交给下一个周期作为继续工作的依据。常用开发模型？需求分析：需求分析过程如何做需求分析？设计: 设计过程如何做设计？ 1.软件生命周期 1.1什么事软件生命周期软件生命周期又称为软件生存周期或系统开发生命周期，是指从软件的产生直到报废的整个过程软件生命周期过程包括： ?问题定义：用户需要计算机解决的问题是什么？电商系统：要计算机实现一个平台，商家通过平台销售自己的商品，一般用户通过平台购买商品。 ?可行性分析用户需要计算机解决的问题是否可行？需要进行可行性分析。市场可行性分析，是否有市场价值。技术可行性分析，使用什么技术解决用户提出的问题。 ?需求分析

将用户提出的问题进行细化。先确定大模块：比如电商系统包括：前台的用户购买平台，后台商家维护平台。再对每一个大模块进行细化。。。。 ?设计确定细化问题的实现方法 ?编码解决问题，依据需求和设计，文档进行开发。 ?测试验证是否已经解决用户提出的问题。单元测试集成测试（测试业务整体流程）功能用例测试（对功能点进行测试）性能测试（使用专业工具进行压力和稳定性测试） ?维护修改性维护：前期没有测试出的问题，正式上线运行后bug显现出来，对这些bug进行修改。完善性维护：在现有功能的基础上增加或完善功能。预防性维护：后期根据正式运行的情况对系统进行优化。

生存期模型

“软件项目关理在线学习网站”生存期模型案例分析本项目采用增量式生存期模型，整个项目可分为4个增量，本项目的生存期定义图如下所示：户需求用需求分析系统设计第一增量第二增量第三增量第四增量项目规划核心功能核心功能核心功能核心功能 1 1 2 1 2 1 2 3 3 4 集成测试确认测试产品提交项目生存期示意图生存期中的各阶段定义如下

1、需求分析阶段阶段目标」确定费求的功能和服务。进入条件:用户提出初始需求。输入;演示系统。输出:关键特性表(KeyFeatureLis,KFL) 、s务过程定义Cbasiness 国求定义文档。完成标志:输出通过用户确认。 2系统设计阶段阶段目标:根据已有的系统结构确定应用運辑结构、数据库结构和页面进入条件:提交费求分析初步結果。输入:关键特性表、商务过程定义文档、需求定义文档。输出:系统设计报告、DataMede 和数据库、页面流 (pageflow) 完成标志:设计通过专家的对等评审。 3.项目规划阶段阶段目标:根据需求分析和系统设计结果确定本阶段的时间计划，资源进入条件:提交響求分析初步结果。输入:需求定义文档、系统设计文档。输出:项目计划。完成标志:项目计划经合同管理者审批。 4.增量1设计阶段目标:进行界面设计。进入条件:设计通过专家的对等评审，

输入:系统设计文件、数据库结构定义。输出:源代码，可运行版本-1 完成标志:增量1集成与网站系统集成调试完毕。5增量2设计阶段目标:进行学生登录等功能的添加进入条件:实现增量 1，输入:系统设计文件、数据库结构定义。输出:源代码，可运行版本-2 完成标志:增量2集成与网站系统集成调试完毕。6增量3设计阶段目标:注册等算法的实现。进入条件:实现增量 2 输入:系统设计文件、数据库结构定义。输出:源代码，可运行版本-3 完成标志:增量3集成与网站系统集成调试完毕。7增量4设计阶段目标:查询成绩，网上测试，联系我们等操作。进入条件:实现增量 3 输入:系统设计文件、数据库结构定义。输出:源代码，可运行版本-4 完成标志:增量4集成与网站系统集成调试完毕。8集成测试

软件项目工程管理生存期模型选择

软件项目工程管理生存期模型选择 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】

合同登记编号：生存期模型选择项目名称：新新图书管理系统委托人（甲方）：新新图书馆研究开发人（乙方）：实习生开发团队签订地点：西安市签订日期： 2011-3-16 有效限期： 2011-3-16至 2011-10-16 西安市信息技术管理办公室针对本项目的开发特点，参考企业的生存期说明和软件过程体系，觉得采用增量模型，如图所示。

理由如下：（1）《图书管理系统》的全部功能分成通用功能和日常业务管理功能两大类。因此可以先基于通用功能做出一个最小的使用版本，在逐步添加其余的功能。这样一来，用户可以在先使用最小版本的同时，提出更多明确的需求。这有助于下一阶段的开发，大大减小了开发的风险。（2）在图书管理系统中，要求系统有扩展性。若使用增量式模型，，可以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方，通过客户使用这个可用的产品，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性，直至产生最终完善的产品。（3）“系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂其他功能模块”——即用户可能会增加新的需求。

（4）对一个管理方式已经比较成熟的图书管理，要完全舍弃原有的管理方式，用该图书管理系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量式模型来开发系统。（5）本项目具备增量式模型的其他特点： 1）项目复杂程度为中等 2）预计开发软件的成本为中等 3）产品和文档的再使用率会很高 4）项目风险较低生存期中的和阶段定义如下：项目规划阶段阶段目标：根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。输入：合同文本、Sow 过程：项目规划、计划确认输出：项目计划需求分析阶段阶段目标：确定客户的需求输入：项目计划、Sow 过程：需求获取、需求分析、需求控制输出：原型系统、需求规格设计阶段阶段目标：总体系统结构设计