软件开发模型看这一篇就够啦！-CSDN博客

本文链接：https://blog.csdn.net/yoona333/article/details/142049025

软件开发模型有

瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型、基于组件的开发模型、统一软件开发过程模型、敏捷过程与极限编程。

一、瀑布模型

前一阶段的任务完成后，才能开始进行后一阶段的工作不可回溯性文档驱动前一阶段的输出往往就是后一阶段的输入.

（1）瀑布模型的特点

瀑布模型思路简洁、明确，上一阶段的开发结果是下一阶段开发的输入，相邻两个阶段具有因果关系，紧密相联。

为了保障软件开发的正确性，每一阶段任务完成后，都必须对它的阶段性制品（文档、原型、程序等）进行评审，确认之后再转入下一阶段。

瀑布模型的可行性研究、需求、设计、编码、测试分离，有利于软件的体系结构设计，规范了软件开发活动，有利于开发人员的组织、管理。

对于规模较小、软件需求比较稳定的项目或子系统，采用瀑布模型能够显著提高软件开发的质量和效率。

（2）瀑布模型的缺点

①确定软件需求后才能进行后续的软件开发工作，但多数场合给出大型软件项目的全部需求是困难的，甚至是不现实的；

②需求确定后，要等相当长的时间(经过设计、实现、测试、运行)才能得到软件的最初版本，如果用户对这个软件提出比较大的修改意见，将会蒙受巨大的人力、财力和时间损失；

③ “上游”出现“过失” (mistake)会为软件制品带来“缺陷”(fault)并潜伏在软件制品中，缺陷会误导“下游”的开发活动，若未被发现，则软件运行时会造成系统“故障” (failure)。这时必须花力气找到故障原因，修复缺陷，造成不应有的人力、财力和时间损失。

二、反馈的瀑布模型

实践中，对某一阶段软件制品的评审会经常发现缺陷和疏漏，这时不得不暂停这一阶段的活动，反馈到前面的有关阶段修正缺陷、增补疏漏，然后再重复前面的工作，直至该阶段通过评审后再进入下一阶段。

三、V字型瀑布模型

软件的分析、设计过程与软件测试过程一一对应，强化了软件设计和测试的关系，加强了软件的质量保证。

四、快速原型模型

快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。通常，用户试用原型系统之后会提出许多修改意见，开发人员按照用户的意见快速地修改原型系统，然后再次请用户试用……反反复复地改进，直到原型系统满足用户的要求。

原型有两类

(1)抛弃型原型(实验性原型) ：利用原型定义和确认了软件需求后，原型就完成了任务。开发人员就可以按照确认的需求进行软件设计、编码、测试。

(2)应用型原型(进化性原型/演化型原型) ：利用原型确认软件需求后，对原型进一步加工、完善，使之成为系统的一部分。

快速开发原型的三种途径：

①利用计算机模拟软件系统的人机界面和人机交互方式；
②利用敏捷软件开发方法开发一个工作原型，实现软件系统重要的，容易产生误解的部分功能； ③找来若干个类似软件，利用这些软件向客户展示软件需求中的部分或全部功能。

优点：

快速开发出可以演示的系统，强调用户参与和决策，强化了用户与开发人员的沟通采用迭代技术能够使开发者逐步弄清客户的需求，可加快需求的确定，能够处理需求的不确定性和风险简化了项目管理、缩短了开发时间、降低了风险和开发成本。

缺点：

快速建立的系统结构加连续修改可能导致产品质量低下，原型系统的内部结构可能不好，软件可维护性差用户合作要求高，如果合作不好，反而会拖延开发进度不适用于开发大型系统。

对于软件开发前需求基本确定的大型软件项目，采用瀑布模型开发时间长、不能快速占领市场、不能在短期内得到用户的反馈意见。为了解决这些问题，开发人员创建了增量过程模型。

五、增量过程模型

开发人员与用户协商将需求分解，划分为一系列增量，并为增量排序，急需的增量排在前面先开发，不急需的放在后面。第一个阶段的增量构件往往实现软件的基本需求，提供最核心的功能；后面的增量构架逐渐添加系统的功能每个增量都历经需求、设计、编码、测试、移交几个阶段根据增量间的依赖关系、开发人员和项目的实际情况，有些增量可串行开发，有些可并行开发。在此过程中不断开发、不断集成、不断交付，直到完成所有增量的开发，得到最终的软件制品。

实现构件前完成总体的需求分析、规格说明和概要设计，相对来说风险较小。

1、增量过程模型的优点

①在软件开发过程中，按照增量持续不断的发布软件新版本，可及时获得客户的反馈，用于调整后续的软件开发策略；

②由于软件需求是确定的，可先对软件体系结构进行设计，增量开发过程能保持良好的软件体系结构。

2、增量过程模型的缺点

①增量规模不能大（开发不要超过20k行代码），否则会暴露瀑布模型的缺点；

②将客户需求分解成增量序列必须对系统需求十分了解，并有顶层设计的经验；

③多数系统都需要基本服务，如何为基本服务定义增量，何时实现这些增量，处理起来比较困难。

3、增量过程模型的注意事项

增量构件规模适中；

分解的约束条件是当把新构件集成到现有软件中时，所形成的产品必须是可测试的；

软件体系必须是开放的，即在对现有系统添加新增量构件时，不能破坏系统原有功能。

问题：缺乏丰富而强有力的软件工具和开发环境

六、增量模型 VS. 瀑布模型

相同点：需求明确

不同点：瀑布是一次把满足所有需求产品提交给用户，增量模型是分批向用户提交产品

七、增量模型 VS. 迭代模型

八、增量模型 VS. 螺旋模型

九、螺旋模型

（一）简单的螺旋模型

大型软件开发面临的重要问题：软件风险开发进度落后开发成本超出预算; 产品交付给用户之后，用户不满意；产品完成前关键的开发人员跳槽; 在产品投人市场前，竞争对手发布了一个功能相近，价格更低的软件……… 1988年B.Boehem提出的迭代模型，加入风险分析，常指导大型软件项目。

螺旋模型改进了原型模型，在每个阶段都加入风险分析。

（二）完整的螺旋模型

螺旋模型是从里向外，螺旋线每个回路表示的软件过程都由四个阶段组成

(1)定义目标：确定目标、选定方案、设定约束条件。

(2)风险分析：评估方案，识别和消除风险。

(3)开发和验证：软件开发。

(4)规划：评价开发工作，计划下一阶段工作。

沿螺线自内向外每旋转一圈开发出更完善新版本。

（三）螺旋模型的优缺点

优点： 大型软件开发项目有较好的风险控制；强调可选方案和约束条件，有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险；

缺点： 需要开发人员具有相当丰富的风险评估经验和专门知识；进行风险分析的费用可能较大。由于需求的不确定性，软件开发初期无法进行软件体系结构设计，多次迭代会导致软件体系结构变坏，为软件理解和维护带来困难普及不如前述模型

十、喷泉模型

1、喷泉模型的优点：可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

２、喷泉模型的缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

３、喷泉模型适用场所：适应于面向对象的软件开发过程。

十一、敏捷开发计划驱动 vs. 敏捷

1、计划驱动与敏捷：适用条件与优缺点

计划驱动的过程：所有过程活动均事先计划，按照计划衡量进度需求可以事先清楚、完整定义，且不会有太大变化最终得到的软件系统有较高的可靠性、安全性要求涉及多个部门或团队，涉及复杂的协调和沟通

敏捷开发：只做增量的短期计划并根据变化和反馈不断进行调整需求不确定且经常变化（变化蕴涵着竞争优势）对于最终软件系统的可靠性和安全性要求没那么高开发团队规模较小且能够充分沟通。

在实践中二者经常会有所结合

2、敏捷产生的背景

十二、极限编程XP

极限编程（eXtreme Programming,XP）是一种强调高质量和响应性的软件开发方法。注重团队合作、灵活应变和持续改进，目标是以最小的成本和时间开发出高质量的软件。目前，极限编程已经成为一种典型的开发方法，广泛应用于需求模糊且经常改变的场合。敏捷过程能够较好地适应商业竞争环境下对小型项目提出的有限资源和有限开发时间的约束。适用于需求经常变化且开发时间紧迫的小型项目。

十三、Scrum

SCRUM是一个适用于增量式产品开发的管理框架，由一个5-10人左右的跨职能和自组织的团队组成。

1、基本术语

冲刺周期（Sprint）：中文译为冲刺、短跑，是Scrum的专有术语。冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。

用户故事（User Story）：用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。

开发任务（Task）：由故事拆分成的具体开发任务。

2、基本角色

产品负责人（Product Owner）：主要负责确定产品的功能和达到要求的标准，制定软件的发布日期和交付的内容，同时有权利接收或拒绝开发团队的工作成功。

流程管理员（Scrum Master）：主要负责整个Scrum流程再项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）：主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5-10人左右，每个成员可能负责不同的技术方面，但要求每个成员必须要有很强的自我管理能力。同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

3、三个工件

产品需求列表（Product Backlog）：产品首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理确定需求文档。产品待办列表就是产品的“what”。PO（产品负责人）通过讲故事的方式，让团队理解产品的目标，帮助整个团队对用户故事有充分和统一的理解。

迭代需求列表（Sprint Backlog）：有了Product Backlog，我们需要通过Sprint Planning Meeting（Sprint计划会议）挑选出用户故事（Story）作为每次迭代完成的目标。

冲刺燃尽图（Sprint burn down）：它表示的是剩余工作量与剩余时间的关系，用于提醒大家项目进度和要完成的任务。说白了就是记录当前周期的需求完成情况。