软件生存期模型

4种软件生命周期模型的特点和选择条件展开全文•瀑布模型1.模型的本意瀑布模型的本意是:软件生存周期是由立项、需求分析、策划、概要设计、详细设计、编程、测试、发布、维护等阶段所组成的，把每个阶段当做瀑布中的一个台阶(阶梯)，把软件生存过程比喻成瀑布中的流水，软件生存过程在这些台阶中由上向下地奔流。

瀑布模型规定了各项关键软件工程活动，自上而下、相互衔接、逐级下落，如同瀑布的固定次序。

当发现某阶段的上游存在缺陷时，可以通过追溯，予以消除或改进，但要付出很大代价，因为水要在瀑布台阶上倒过来向上流动，需要消耗很多能源或动力。

瀑布模型认为:项目经理或软件管理人员，只要控制好每级台阶的高度和宽度，在每个台阶处设立里程碑或基线，并组织好对基线的评审与审计，就可以控制好项目的开发成本、进度和质量。

2.模型的特点瀑布模型的特点是: (1)里程碑或基线驱动，或者说文档驱动。

(2)过程逆转性很差或者说不可逆转，因为根据上流的错误会在下流进行发散性传播的原理，所以逆转将会延误工期，增加成本，造成重大损失。

3.选择模型的条件(1)在开发时间内需求没有或很少变化。

(2)分析设计人员对应用领域很熟悉。

(3)低风险项目(对目标、环境很熟悉)。

(4)用户使用环境很稳定。

(5)用户除提出需求以外，很少参与开发工作。

4.模型的缺点瀑布模型的缺点是:传统的项目组织方法是按顺序完成每个工作流程，即瀑布式生存周期。

瀑布只能—个个台阶地往下流，不可能倒着往上流，这就是它致命的缺点。

瀑布式生存周期通常会导致在项目后期，如实施阶段(当第一次构建产品并开始测试时)出现“问题堆积”，在整个分析、设计和实现阶段隐藏下来的问题，会在这个时候逐步暴露出来。

更可怕的是，错误的传递会采取发散扩大的方式，比如，在需求阶段中的一个错误或遗漏，在编程阶段就可能引发几十个错误或遗漏。

因为项目有较长的开发周期，其进度会被严重拖延，最终导致成本和质量的失控。

•增量模型1.模型的本意增量模型的本意是:要开发一个大的软件系统，先开发其中的一个核心模块(或子系统)，然后再开发其他模块(或子系统)，这样一个个模块(或子系统)地增加上去，就像搭积木一样，直至整个系统开发完毕为止。

软件工程软件生命周期模型在软件工程领域，软件生命周期模型是一种重要的框架，用于指导软件开发的过程。

它为软件开发团队提供了一种结构化的方法，以确保软件的开发能够高效、高质量地完成。

软件生命周期模型就像是一张地图，指引着开发人员从项目的启动到最终的交付。

它涵盖了软件从概念形成到退役的整个过程，包括一系列的阶段、活动和任务。

常见的软件生命周期模型有瀑布模型、快速原型模型、增量模型、螺旋模型和敏捷模型等。

瀑布模型是最早出现的软件生命周期模型之一。

它将软件开发过程分为明确的几个阶段，如需求分析、设计、编码、测试和维护。

每个阶段都必须在前一个阶段完成且经过评审后才能开始。

这种模型的优点是流程清晰，文档规范。

但它的缺点也很明显，如果在后期发现前期的错误，修改成本会很高，而且不适应需求的频繁变更。

快速原型模型则是在获取基本需求后，快速构建一个原型系统。

用户通过使用原型来进一步明确需求，开发人员根据反馈进行修改和完善。

这个模型的好处是能够快速获得用户的反馈，尽早发现问题。

但由于原型往往不够完善，可能会给用户造成误解。

增量模型是把软件系统逐步分解为多个增量构件，每个构件分别开发和交付。

这样可以在较短的时间内交付部分功能，让用户逐步看到成果。

但它对软件的架构设计要求较高，需要很好地规划各个增量之间的接口。

螺旋模型则是将瀑布模型和快速原型模型结合起来，并加入了风险分析。

它沿着螺旋线不断迭代，每一轮迭代都包括制定计划、风险分析、实施工程和客户评估等步骤。

这种模型适用于大型、复杂且高风险的项目，但管理成本相对较高。

近年来，敏捷模型在软件开发中越来越受欢迎。

敏捷开发强调团队的快速响应和持续交付，通过短周期的迭代来不断完善软件。

常见的敏捷方法有 Scrum 和 Kanban 等。

敏捷模型注重人与人之间的沟通和协作，能够更好地适应需求的变化，但对团队成员的素质和自组织能力要求较高。

在选择软件生命周期模型时，需要考虑多个因素。

首先是项目的特点，比如项目的规模、复杂度、需求的稳定性等。

软件生存周期模型的特点,及实践中采用的模型软件生存周期模型是描述软件开发过程中各种活动如何执行的模型。

软件生存周期模型确立了软件开发和演绎中各阶段的次序限制以及各阶段或机动的准则，确立开发过程所遵守的规定和限制，便于各种活动的协调，便于各种人员的有效通信，有利于活动重用，有利于活动管理。

常见的软件生存周期模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。

（一）瀑布模型特点：●阶段间的顺序性和依赖性●推迟实现的观点●质量保证的观点（文档驱动性）优点✓可强迫开发人员采用规范的方法✓严格地规定了每个阶段必须提交的文档✓要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证缺点▪周期长：顺序推进，环环审查▪需求难以准确把握(不能准确提出和沟通、不能快速适应变化的需求)，导致返工甚至推倒重来▪无法预测新引入模块的影响▪最终的形式难以预料▪不适合需求模糊的系统瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。

将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

从本质来讲，它是一个软件开发架构，开发过程是通过一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好“返回”上一个阶段并进行适当的修改，开发进程从一个阶段“流动”到下一个阶段，这也是瀑布开发名称的由来。

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。

其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。

同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。