文章目录1、瀑布模型1.1工艺1.2优缺点1.3适用性2、螺旋模型2.1适用性2.2优缺点3、增量模型3.1概要3.2特点3.3优缺点3.4适用性4、迭代模型4.1概要4.2适用项目4.3优缺点5、阿
软件开发模型主要有瀑布模型、螺旋模型、迭代模型、增量模型和敏捷模型五种。
一.瀑布模型1.1流程
1.2优缺点：
强调强调开发阶段性的早期计划和强调需求调查的产品测试。 缺点：
开发过程中的经验教训无法反馈到适用于本产品的过程中，因为这是一个依赖于早期进行的唯一需求调查而无法适应需求变化的单一过程； 风险往往晚于后期测试阶段显现，失去提前纠正的机会。 1.3适用性适用于需求稳定的项目，因为失去了纠正错误的最佳时机。
项目周期短。 需求可预测，软件实现方法成熟；
二、螺旋模型2.1适用性适合那些规模庞大、复杂度高、风险大的项目。 这种迭代开发的模型给软件测试带来了新的要求，不允许有独立的测试时间和阶段，测试必须随着开发的迭代进行迭代。
2.2优缺点：
强调严格的全过程风险管理。 强调各开发阶段的质量。 提供讨论项目是否值得继续的机会。 缺点：
实施非常严格的风险识别、风险分析和风险控制对风险管理的技能水平提出了很高的要求。 这需要人员、资金和时间的投入。 三.增量模型3.1概述增量模型又称渐增模型。 在使用增量模型开发软件时，将软件产品作为一系列增量组件进行设计、编码、集成和测试。 每个组件可以由多个交互模块组成并完成特定的功能。
使用增量模型时，第一个增量组件满足软件的基本需求，并提供最核心的功能。
增量模型将整个软件产品分解为几个增量组件，并进行拆分，逐步向用户提交产品。
3.2结合特征瀑布模型的顺序特征和快速原型法的迭代特征，将软件视为一系列相互关联的增量，在开发过程的每次迭代中，每次完成其中一个增量3.3优缺点：
通过向用户提交能够在短时间内完成部分工作的产品，开发的软件系统被模块化，能够按批次提交软件产品，从而用户能够及时掌握软件项目的进展并以组件为单位进行开发一个开发周期内的错误不影响整个软件系统开发顺序的灵活性。 开发人员可以对组件的实现顺序进行优先排序，以先完成需求稳定的核心组件。 如果组件优先级更改，也可以及时调整实现顺序的缺点。
因为每个组件都将嵌入到现有的软件体系结构中，所以要添加组件，必须避免破坏构建的系统部分。 这需要软件具有开放的体系结构，开发过程中的需求变化是不可避免的。 增量模型的灵活性使其适应这一变化的能力大大优于瀑布模型和快速原型模型，但容易退化，以便在制作的同时改变模型。 因此，软件过程的控制失去了整体性。 增量包之间有交集，处理不好时，必须进行全面的系统分析。 在该模型中细分功能并分开开发的方法是在需求频繁变化的软件开发过程3.4适用性需求经常改变，开发人员数量不够的项目
四.迭代模型4.1概述开发迭代是指完整通过所有工作流的过程，包括需求工作流、分析设计工作流、实现工作流和测试工作流。 基本上，迭代模型就像小型瀑布式项目。每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
4.2适用项目适合于事先不能完整定义产品的所有需求，计划多期开发的项目。
4.3优缺点：
通过适应需求的变化，降低阶段性支出风险。 在开发的早期发现风险，可以尽早解决风险，因此整个开发的进度会恶化。
高素质的项目管理者指导和高水平的开发团队5、敏捷模式5.1来源于敏捷宣言，强调：
与个人的交互在所有对比中比流程和工具更重要，比完整的文档更重要，比与客户的合作更重要，比合同谈判的响应变化更重要，比遵循计划更重要，后者并不是没有价值，而是重视前者。 5.2摘要敏捷开发以用户需求为核心，采用迭代、序贯的方法进行软件开发。 强调适应性而不是预测，强调以人为中心而不是过程。 在敏捷开发中，软件项目在构建初期被划分为多个子项目，每个子项目的成果都经过测试，具有可视、集成、可执行的特点。 换句话说，就是把一个大项目分成多个相互关联、但也可以独立执行的小项目，分别完成。 在此期间，软件一直处于可用状态。 敏捷开发声明是指尽快、持续地提供有价值的软件，以使客户满意。
5.3原则(1)通过尽早、持续地提供有价值的软件来实现客户满意度。 欢迎不断变化的需求，)2)即使在项目开发后期。 要善于利用需求变化，帮助客户获得竞争优势。 )3)持续提供可用软件。 周期通常为几周，越短越好。 )4)项目中，业务人员和开发人员必须一起工作。 )5)项目要围绕有内在动力的个人打造，他们应该受到信任。 )6)面对面交谈是最好的交流方式。 (7)可用性是衡量进展的主要指标。
（8）提倡可持续的开发，保持稳定的进展速度。（9）不断关注技术是否优秀，设计是否良好。（10）简单性至关重要，尽最大可能减少不必要的工作。（11）最好的架构、要求和设计，来自团队内部自发的认识。（12）团队要定期反思如何更有效，并相应地进行调整。 5.4 特点 1.快速迭代采用复杂问题分解方法，对于小版本的需求、开发和测试更加简单快速。2.让测试人员和开发者参与需求讨论需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员和开发者，这样可以更加轻松地定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。3.编写可测试的需求文档开始就要用“用户故事”（user story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早地提及技术实施方案，会降低对需求的注意力。4.多沟通，尽量减少文档任何项目中，沟通都是一个常见的问题。良好的沟通是敏捷开发的先决条件，强调高效沟通的重要性。团队要确保日常的交流，面对面沟通比邮件更有效。强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。5.响应变更胜过遵循计划在敏捷方法开发软件过程中，接收需求变更，预料系统需求的变更，并快速响应变更，设计系统使之适应变更。主动适应变化，而不是预测6.及早考虑测试及早考虑测试在敏捷开发中很重要。传统软件开发中，测试用例大多都是最后才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。若较早地开始编写测试用例，在需求完成时，可以接受的测试用例也基本同时完成。 5.5 优缺点优点：
是一种非常现实的软件开发方法。促进团队合作和交叉培训。功能可以迅速发展并得到证明。资源要求最低。适合固定或变化的要求提供早期部分工作解决方案。适用于稳定变化的环境的良好模型。最小的规则，易于使用的文档。在整体计划环境中实现并发开发和交付。很少或根本不需要计划。易于管理。为开发人员提供灵活性。缺点：
不适合处理复杂的依赖项。可持续性，可维护性和可扩展性的风险更大。总体规划，敏捷领导者和敏捷的PM实践是必须的，如果没有它，它将无法工作。严格的交付管理决定了范围，要交付的功能以及满足截止日期的调整。在很大程度上取决于客户互动，因此如果客户不清楚，团队可能会被推向错误的方向。由于生成的文档最少，因此存在非常高的个人依赖性。由于缺乏文档，技术转让给新的团队成员可能非常具有挑战性。本篇博客就分享到这里，如有不足请指正！