软件生命周期模型
7.什么是软件生命周期模型？试比较瀑布模型，快速原型模型，增量模型和螺旋模型的优缺点，说明。。。
7.什么是软件⽣命周期模型？试⽐较瀑布模型，快速原型模型，
增量模型和螺旋模型的优缺点，说明。
软件⽣命周期？
软件⽣命周期由软件定义，软件开发和运⾏维护3个时期组成。
瀑布模型：
优点：
有利于⼤型软件开发过程中⼈员的组织、管理，有利于软件开发⽅法和⼯具的研究，从⽽提⾼了⼤型软件项⽬开发的质量和效率。
缺点：
瀑布模型是由⽂档驱动的。
范围
⽤户需求稳定的项⽬。
快速原型：
优点：
有助于保证⽤户的真实需要得到满⾜。
缺点：
准确的原型设计⽐较困难。
客户和开发者对原型认识不同。
范围：
对开发领域熟悉，并有开发原型的项⽬。
增量模型：
优点：
能在短时间内向⽤户提交可完成部分的⼯作的产品，逐步增加产品功能可以使⽤户有较充裕的时间学习和适应新产品。
缺点：
并⾏开发控件可能遇到风险。
灵活性使之容易退化为边改边做模型，失去控制。
范围：
进⾏已有产品升级。
螺旋模型：
优点：
设计上的灵活，可在项⽬各阶段修改。
客户始终参与开发各阶段，保证了项⽬的正确⽅向。
缺点：
需要相当丰富的风险评估，多次迭代会提⾼成本，延迟提交时间。
范围：
⼤规模的软件项⽬。
软件工程第2讲 软件生命周期模型
敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较5敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较57P32: 2.9.2P23: 2.2 P25: 2.3P34: 2.9.3模型构造多使用脚本语言、基于现有基础代码库、UI工具制作，制作过程一般不会考虑性能、稳定敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较5迭代-递增生命周期模型递增也是软件工程的一个固有特性P27P26: 2.5P28P29P30 2.7敏捷开发4软件生命周期模型1瀑布模型及几个衍生模型2迭代和递增3其他生命周期模型及模型比较58个体和交互胜过过程和工具以人为本我相信没有比面对面交流更高效的沟通渠道了•尊重和信任激发个人内心的责任感和使命感，激发了个体的潜能。
•基于互相信任的前提，敏捷提倡自治的全功能团队。
在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。
•要摒弃这种重流程和重工具，提倡轻量级流程和轻量级工具，而这些流程和工具又在促进个体交互。
比如，我们在日常工作中会使用Trello、Jira、Keynote等工具。
可以工作的软件胜过面面俱到的文档价值导向为客户交付可工作的软件是我们的核心目标•我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上。
•但这不代表我们要抵制任何文档。
实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
•在开发过程中，交互设计原型也是一种轻量级文档，交互设计师交付可以尽早地跟团队和客户进行确认验收的核心业务场景的原型，快速收集反馈。
客户合作胜过合同谈判客户团队帮助客户实现他们真正想要的价值•让客户也作为团队的一分子，跟客户建立信任的合作关系取代敌对的谈判关系。
•需求的变化往往来自客户，让客户参与进来可以在开发的过程中尽早的发现变化，从而尽早采取解决方案。
02-1 软件生命周期与开发模型
6
二、瀑布模型
7
• 1970年W.Royce提出瀑布模型 • 1.模型的本意：阶段间具有顺序性和依赖性
2.模型的特点：
文档驱动 过程不可逆转
（1）在开发时间内需求没有或很少变化。 （2）分析设计人员对应用领域很熟悉。 （3）低风险项目（对目标、环境很熟悉）。 （4）用户使用环境很稳定。 （5）用户除提出需求以外，很少参与开发工作。
•原型可作为单独的过程模型，也常被作为一 种方法或实现技术应用于其它过程模型中。
25
五、 迭代模型 （Iterative Model）
• 代表：RUP（Rational Unified Process）模型
26
• 这里所讲的迭代模型是RUP推出的一种 “逐步求精”的面向对象的软件开发过程 模型，被认为软件界迄今为止最完善的、 商品化的开发过程模型。
快速计划 交流 快速设计方式 建模
部署交付和 反馈
构建原型
17
原型模型
• 软件企业界的主流开发模型. • 1．模型的本意 • 原型模型（Prototype Model）的本意是： 在初步需求分析之后，马上向客户展示一个 软件产品原型(样品)，对客户进行培训，让 客户试用，在试用中收集客户意见，根据客 户意见立刻修改原型，之后再让客户试用， 反复循环几次，直到客户确认为止。
14
• 4．模型的优点 • （1）由于将一个大系统分解为多个小系统， 这就等于将一个大风险分解为多个小风险， 从而降低了开发难度。 • （2）人员分配灵活，刚开始不用投入大量 人力资源。如果核心模块产品很受欢迎， 则可增加人力实现下一个增量。当配备的 人员不能在设定的期限内完成产品时，它 提供了一种先推出核心产品的途径。即可 先发布部分模块给客户，对客户起到镇静 剂的作用。
熟悉常用的软件开发生命周期模型
熟悉常用的软件开发生命周期模型软件开发生命周期模型是指在软件开发过程中，按照一定的步骤和阶段进行开发的方法论。
不同的生命周期模型适用于不同的开发需求和开发团队，但它们都以确保软件质量和满足用户需求为目标。
本文将介绍几种常用的软件开发生命周期模型，帮助读者更好地理解和应用于实际开发项目中。
瀑布模型瀑布模型是最经典的开发生命周期模型之一，它被认为是一种线性顺序模型。
瀑布模型将软件开发过程划分为几个阶段，如需求分析、系统设计、编码、测试和维护等。
每个阶段的输出会成为下一个阶段的输入，确保整个开发过程的连续性和一致性。
该模型适用于需求稳定、并能够明确详细的项目。
迭代模型迭代模型将软件开发过程划分为多个迭代周期，每个周期都包含需求分析、设计、编码、测试和发布等阶段。
每个迭代都会获得一个可用的软件产品，并在之后的迭代中不断完善和扩展。
迭代模型适用于需求变化频繁或团队缺乏明确的需求文档的情况。
通过快速迭代和反馈，开发团队能够更快地适应需求变化和改进软件质量。
螺旋模型螺旋模型将软件开发过程看作一系列的螺旋，每个螺旋代表一个开发周期。
在每个周期的开始，开发团队会进行风险评估和需求分析，并根据评估结果制定相应的开发策略。
然后，团队按照该策略进行设计、编码、测试和发布等工作。
螺旋模型适用于需要高风险控制和迭代开发的项目。
通过周期性的风险评估和调整，开发团队能够及时应对风险并提高软件质量。
敏捷模型敏捷模型是一种轻量级和迭代的开发方法论，强调快速适应需求变化和团队合作。
敏捷模型将开发过程划分为多个迭代周期，每个周期通常持续2到4周。
每个周期都包含需求分析、设计、编码、测试和部署等工作。
开发团队和客户之间的高效沟通和合作是敏捷模型的核心。
敏捷模型适用于团队追求快速交付、灵活适应需求变化的项目。
总之，软件开发生命周期模型是指导软件开发过程的重要方法论。
熟悉常用的软件开发生命周期模型有助于开发团队更好地组织和管理开发项目，确保软件质量和满足用户需求。
软件工程——01软件生命周期模型
软件工程——01软件生命周期模型软件工程——01 软件生命周期模型引言软件工程是一门涉及软件开发、维护和管理的学科与技术。
在软件开发过程中，一个关键的概念就是软件生命周期模型。
软件生命周期模型是一种描述软件开发过程的抽象框架，它帮助开发人员理解和组织软件开发的不同阶段，以及在每个阶段中需要执行的任务和活动。
本文将介绍几种常见的软件生命周期模型，包括瀑布模型、原型模型、迭代模型和增量模型。
每种模型都有其特点和适用场景，在实际项目中开发团队可以根据具体需求选择合适的模型。
1. 瀑布模型瀑布模型是最早被提出和广泛使用的软件生命周期模型之一。
它将软件开发过程划分为一系列严格的阶段，每个阶段按顺序进行，只有当前一阶段完成后才能进入下一阶段。
瀑布模型的阶段包括需求分析、设计、编码、和维护。
瀑布模型的优势在于结构清晰、易于管理和追踪进度。
，它也存在一些缺陷，如需求变更困难、开发周期长、风险无法及时评估等。
2. 原型模型原型模型是一种快速开发的软件生命周期模型。
它强调通过快速建立原型来理解用户需求、验证解决方案。
原型模型的过程包括需求收集、原型设计、原型构建、用户反馈和改进。
原型模型的优势在于在开发过程中可以及时掌握用户需求并进行调整，有效减少需求变更带来的影响。
，原型模型也存在一些限制，如原型可能无法完全满足实际系统的要求、原型开发时间较长等。
3. 迭代模型迭代模型是一种灵活的软件生命周期模型，它允许开发人员根据实际情况进行反复迭代。
迭代模型的过程包括需求分析、设计、编码、和评审，每个阶段可能会经历多轮迭代。
迭代模型的优势在于可以通过快速迭代来逐步完善系统，并及时响应用户反馈和需求变更。
，迭代模型也要求开发团队具备较高的灵活性和素质，迭代次数过多也可能导致项目时间和成本的增加。
4. 增量模型增量模型是一种渐进式的软件生命周期模型，它将开发过程划分为多个相互独立的增量。
每个增量包含需求分析、设计、编码、和维护等阶段，开发人员逐步完成系统的不同功能。
软件生命周期模型
1、什么是软件生命周期模型？有哪些主要模
型？
软件生命周期模型也称为软件过程模型，反映软件生存周期各
个阶段的工作如何组织、衔接，常用的有瀑布模型、原型模
型、螺旋模型、增量模型、喷泉模型，还有建造-修补模型、
MSF过程模型、快速原型模型。
生命周期模 型
优点
缺点
适用范围
建造-修补 模型
设计编码过程 简单、方便。
螺旋模型
设计上的灵活 性,可以在项 目的各个阶段 建设周期长， 进行变更，以 而软件技术发 小的分段来构 展比较快，所 建大型系统， 以经常出现软 使成本计算变 件开发完毕 得简单容易， 后，和当前的 客户始终参与 技术水平有了
特别适合于大型 复杂的系统，对 于新近开发，需 求不明确的情况 下，便于风险控
制和需求变更。 增量包足够小， 其影响对整个项 目来说是可以承 受的，不容易破 坏整体结构的。 用户需求容易有 变化的、高风险 项目。
面向对象的软件 开发过程。
适用于电子商 务、分布式WEB 等企业解决方案 的开发和部署 中。 需求复杂、难以 确定、动态变化 的软件系统
2、面向对象的程序设计与结构化程序设计的
进行维护相当 困难、而且发 生回归错误的 机会也相当 大。
适用于不用任何 维护的小程序。
瀑布模型
为项目提供了 按阶段划分的 检查点、当前 一阶段完成 后，只需要去 关注后续阶 段。
在项目各个阶 段之间极少有 反馈、只有在 项目生命周期 的后期才能看 到结果、通过 过多的强制完 成日期和里程 碑来跟踪各个 项目阶段。
增量模型 迭代模型
喷泉模型 MSF过程模
型 快速原型模
型
每个阶段的开 发,保证了项 目不偏离正确 方向以及项目 的可控性。 增大投资的早 期回报。 降低了在一个 增量上的开支 风险。如果开 发人员重复某 个迭代，那么 损失只是这一 个开发有误的 迭代的花费。 该模型的各个 阶段没有明显 的界限，开发 人员可以同步 进行开发。可 以提高软件项 目开发效率， 节省开发时 间。 它是瀑布模型 和螺旋模型的 组合，吸收了 瀑布模型的里 程碑和螺旋模 型的反复迭代 的思想 克服瀑布模型 的缺点，减少 由于软件需求 不明确带来的 开发风险。
软件工程生命周期
软件工程生命周期软件工程生命周期1. 引言软件工程生命周期是指软件开发过程中的一系列阶段和活动，从项目启动、需求分析，到系统设计、编码，再到测试、部署、维护等阶段。
软件工程生命周期的目的是确保软件开发过程的可控性和质量，以提供高质量的软件产品给用户。
2. 软件工程生命周期模型软件工程生命周期模型是指将软件开发过程划分为不同阶段的模型，常见的模型有瀑布模型、迭代模型、敏捷模型等。
2.1 瀑布模型瀑布模型是最早的软件工程生命周期模型之一，它将软件开发过程划分为需求分析、系统设计、编码、测试、部署、维护等严格的阶段。
2.2 迭代模型迭代模型是将软件开发过程划分为多个迭代周期的模型，每个迭代周期包括需求分析、系统设计、编码、测试等阶段，每个迭代周期都可以产生一个可交付的软件版本。
2.3 敏捷模型敏捷模型强调灵活性和快速响应变化，将软件开发过程分为多个短期的迭代周期，每个周期内开发人员和需求方紧密合作，快速迭代开发出可用的软件产品，并根据反馈及时调整需求和开发计划。
3. 软件工程生命周期的阶段无论使用哪种软件工程生命周期模型，软件开发过程都会经历一些共同的阶段。
3.1 需求分析阶段需求分析阶段是确定软件系统的需求和功能的阶段，通过与用户、业务人员的沟通和交流，分析需求，编写需求规格说明书。
3.2 系统设计阶段在系统设计阶段，软件工程师将需求规格说明书转化为可执行的软件设计方案，包括系统架构设计、模块设计、数据结构设计等。
3.3 编码阶段在编码阶段，根据系统设计方案，开发人员进行具体的编码实现。
3.4 测试阶段测试阶段是验证软件产品是否满足需求以及是否存在缺陷和漏洞的阶段，包括单元测试、集成测试、系统测试等。
3.5 部署阶段在软件部署阶段，将已经测试通过的软件产品部署到目标环境中，使用户可以正常使用。
3.6 维护阶段维护阶段是软件工程生命周期中的一个阶段，通过修复缺陷、升级软件版本等方式，确保软件系统持续稳定运行。
软件生命周期模型与选择
软件生命周期模型及选择指南目录1. 目的 (3)2. 适用范围 (3)3. 术语定义 (3)4. 参考资料 (13)5. 概述 (3)6. 重叠瀑布模型（Interleaved Waterfall Model） (4)6.1 定义 (4)6.2 流程图 (4)6.3 重叠瀑布模型的WBS划分 (5)6.4 优缺点 (5)6.5 适用项目 (5)7. 增量模型(Incremental Model) (6)7.1 定义 (6)7.2 流程图 (6)7.3 阶段描述 ..................................................................................................... 错误!未定义书签。
7.4 增量模型的WBS划分............................................................................... 错误!未定义书签。
7.5 优缺点 (7)7.6 适用项目 (7)8. 原型模型（Prototyping Model） (8)8.1 非抛弃型原型模型...................................................................................... 错误!未定义书签。
8.1.1 阶段 .................................................................................................. 错误!未定义书签。
8.1.2 优缺点 (11)8.1.3 适用项目 (11)8.1.4 优缺点............................................................................................... 错误!未定义书签。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
瀑布模型/改进的瀑布模型
虽然瀑布模型仍然存在很多的问题有待解决，但瀑布模型仍然是最展本的和最效的•种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求-〉分析-〉设计・〉编码-> 测试的阶段进行，每-个阶段都可以定义明确的产出物和验证准则.瀑布模型在每•个阶段完成后都可以组织相关的评审和验证，只有在评审通过后才能够进入到下-个阶段.
由于需要对每•个阶段进行验证，瀑布模型要求每•个阶段都有明确的文档产出，对于严格的瀑布模型每•个阶段都不应该重叠,而应该是在评审通过，相关的产出物都己经基线后才能够进入到下•个阶段.
瀑布模型的优点仍然是可以保证整个软件产品较高的质量，保证缺陷能够捉前的被发现和解决. 采用瀑布模型可以保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性•但对于前期需求不明确,而又很难短时间明确淸楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目，需求设计和开发人员往往在项目开始后就会全部投入到项目中，而不是分阶段投入，因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题.
很多人往往会以进度约束而不选择瀑布模型，这往往是•个错误的观点.导致这种情况的•个关键因素往往是概念需求阶段人力不足.冈此在概念需求阶段人力能够得到充分保证的情况下，瀑布模型和迭代模型在开发周期上并不会存在太人的差别.反而是很多项目对于迭代或嫩捷模型用不好，为了赶进度在前期需求不明确，没有经过•个总体的架构设计情况下就开始编码，后期出现大量的返工而严重影响进度.
架构设计是软件开发中•个重要的关注点.因此在RUP中也捉及到软件开发要以架构为核心.因此在架构设计完成后系统会彼分为相关的f•系统和功能模块.每个功能模块间的接口都可以定义淸楚.在这种情况下，当模块B的详细设计做完成后往往就没有必妥等到其它模块的详细设计都妥完全作完才开始编码，冈此在架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的•种最重要的改进思路，也可以说这是•种增量开发的模型.
当•个新系统的开发存在多个完全不相关的独立需求的功能开发的时候，这个时候也可以选择将 整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最人问题就是没有•个完全 总体的设计，架构设计人员无法在洞悉了所有需求后从系统的可扩展性，复用等方而总体规划.
在项目管理中有•种压缩进度的方法叫赶工，因此瀑布模型的另外改进处就在适当的重叠各个阶 段过程，达到资源的有效利用.比如我们通过讨论，会议确定的实现方式就可以开始执导下•个阶 段的工作而不•定完全等到相关的交付物文档化出来.
螺旋模型
首先螺旋模型是遵从瀑布模型的•即需求・> 架构・> 设计・> 开发-〉测试的路线•螺旋模型最人的价
值在于整个开发过程是迭代和风险驱动的•通过将瀑布模型的多个阶段转化到参个迭代过程中, 以减少项目的风险.
螺旋模型的每•次迭代都包含了以下六个步骤
制定计划
决定目标 方
案和限制
累计 成本 客户评估
凤险分祈 评价方案 识别凤险 消除凤险
风险分析 原型*;原型"原型2 ir
详细设计
实施工程 开
发.验证 下1产品
提交线 设计确认
与验证
品设计
风险分析
1•决定目标，替代方案和约束
2.识别和解决项目的风险
3.评估技术方案和替代解决方案
4.开发本次迭代的交付物和验证迭代产出的正确性.
5.计划下•次迭代
6.提交下•次迭代的步骤和方案.
螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪, 在每次迭代结束后都需要对产出物进行评估和验证，当发现无法继续进行下去时可以及早的终止项目.
螺旋模型复杂的地方在于尽资，专心和知识渊博的管理.因为对于每•次迭代我们要制定出清晰的目标，分析出相关的关键风险和计划中可以验证和测试的交付物并不是•件容易的事情. 螺旋模型的每•次迭代只包含了瀑布模型的某•个或两个阶段.如第二次迭代重点是需求，第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP提倡的迭代模型是有区别的,RUP的每
•次迭代都会包含需求，设计，开发和测试等各个阶段的活动・Rl；P迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作.
增量和迭代模型
增量迭代是RUP统•过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常•起使用.所以这里要先解释下增量和迭代的槪念•假设现在要开发A, B, C, D四个人的业务功能，每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增虽来完成，第•个增量完成A,B功能，第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发，第- 次迭代完成A, B, C, D四个基本业务功能但不含复朵的业务逻辑，而第二个功能再逐渐细化补充完整相关的业务逻辑.在第•个月过去后采用增量开始时候扎B全部开发完成而C,D还•点都没有动;而釆用迭代开发的时候A, B, C, D四个的基础功能都已经完成. RUP强调的每次迭代都包含了需求，设计和开发，测试等各个过程，而且每次迭代完成后都是•个可以交付的原型.迭代不是并行，在每次迭代过程中仍然耍遵循需求-〉设计-＞开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很人的关系.小型项目可以•周•次迭代，而对于人型项目则可以2-4周•次迭代.如果项目没有-个很好的架构师，很难规划出每次迭代的内容和要到达的目标，验证相关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付，需求的变化，但确是•个很难真正用好的模型.
Organization
along
Content
就对风险的消除
上，增量和迭代模型都能够很好
的控制前期的风险并解决.但迭
代模型在这方而 更有优势•迭代
模型更参的可以
从总体力面去系统的思考问题，从最早就可以给出相对完善的框 架或原型，后期的每次迭代都是针对上次迭代的逐步秸化.
业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增 量.同时每个增竜也可以是独立发布的小版本•由于系统的总体设计往往对-个系统的架构和可 扩展性有重人的影响，因此我们推荐的增量最好是在架构设计完成后再开始进行增虽，这样可以 更好的保证系统的健壮性和可扩展性. 原型法
原型•般都不是单独采用的•种生命周期模型,往往会结合瀑布和增量迭代等方法•起使用•对 于螺旋模型就可以理解为瀑布+迭代+原型+风险的-种生命周期模型•对于迭代开发来讲，每•个 迭代周期的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲，我们在需求阶 段也可以进行界面和操作建模，形成DEMO 后和用户做进•部的需求沟通和确认.
当你的用户没有信息系统的使用经验，你的系统分析员也没有过多的需求分析和挖掘经验的时候, 需求分析和调研过程则更需要是•个启发式的过程.而原型则是这种很好的启发式方法,可以快 速的挖掘用户需求并达成需求理解上的•致.否则即使双力都签字认可的需求往往仍然不是客户 真正想要的东西.
原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这 种原型•般都建议抛弃掉.而对于迭代开发来将，每次迭代的产出都是可以独立运行和包含基础 功能的系统，是后续细化的基础，这类原型•般都不建议抛弃,后期的设计开发也要基于该原型逐 渐的进行完善.
快速和敏捷开发
我们•般将快速和敬捷开发做为方法论，而很少将其做为•种软件开发生命周期模型.敬捷的目 的是减少繁重和不必耍的工件的输出，捉高效率.而不是妥我们去挑阶段或过程，不是分析设计都 还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敬捷方法论中的•些好的 实践，这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.
关于选择生命周期模型的最后的总结
1•在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2. 在用户无信息系统使用经验，需求分析人员技能不足情况下•定要借助原型.
3. 在不确定性因素很多，很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4. 在需求不稳定情况下尽量采用增量迭代模型
5. 在资金和成本无法•次到位惜况下可以采用增量模型，软件产品分多个版本进行发布
6. 对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
Organization along Time
Disciplines
iness En gingering
Requirements Anal/sis
and Design Imp lomo n
la lion
Test Deployment Configuration and Change
Manngement Project Management Environmenl
▼
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
&对于编码人员经验较少惜况下建议不要采用敬捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用，但每•次增量或迭代都必须有明确的交付和出口准则.。