迭代和渐进发展
迭代和增量开发是迭代设计或迭代方法的任何组合以及用于开发的增量构建模型。
该术语的用法始于软件开发，长期以来将两个术语迭代和渐进的术语结合在一起，已被广泛建议进行大规模开发工作。例如，1985年DOD-STD-2167提到（在第4.1.2节中）：“在软件开发期间，软件开发周期的多个迭代可能同时进行。” “此过程可以描述为'进化获取'或'增量构建方法。”在软件中，迭代和增量之间的关系取决于整个软件开发过程。
概述
这种方法背后的基本思想是通过重复的循环（迭代）和较小的部分（增量）来开发系统，从而使软件开发人员可以利用在系统的早期部分或系统的开发过程中所学到的东西。学习既来自系统的开发和使用，在可能的过程中可能的关键步骤从简单的软件需求子集的简单实现开始，并迭代地增强了不断发展的版本，直到实施完整的系统为止。在每次迭代时，都会进行设计修改，并添加新的功能功能。
该过程本身包括初始化步骤，迭代步骤和项目控制列表。初始化步骤创建了系统的基本版本。此初始实现的目标是创建用户可以反应的产品。它应该为问题的关键方面提供一个抽样，并提供一个足够简单的解决方案，可以轻松理解和实施。为了指导迭代过程，创建了一个项目控制列表，其中包含所有需要执行的任务的记录。它包括要实施的新功能之类的项目以及现有解决方案的重新设计领域。由于分析阶段，控制列表正在不断修订。
迭代涉及重新设计和实现，这是简单，直接且模块化的，在该阶段进行支持重新设计，或者作为将来的任务添加到项目控制列表中。设计细节的水平不是由迭代方法决定的。在一个轻巧的迭代项目中，该代码可能代表系统文档的主要来源；但是，在关键的迭代项目中，可以使用正式的软件设计文档。迭代的分析基于用户反馈和程序分析设施可用。它涉及对目标的结构，模块化，可用性，可靠性，效率和实现的分析。根据分析结果，对项目控制列表进行了修改。
阶段
增量开发将系统功能切成增量（部分）。在每个增量中，从要求到部署都通过跨学科工作来提供一段功能。统一的过程组将阶段递增/迭代：成立，阐述，构造和过渡。
- Inception确定了项目范围，需求（功能和非功能性）以及高水平的风险，但在足够的详细信息中可以估算工作。
- 精心设计提供了一种工作架构，可减轻最佳风险并满足非功能要求。
- 通过分析，设计，实现和测试功能要求产生的生产准备代码，构造逐步填充了体系结构。
- 过渡将系统传递到生产操作环境中。
每个阶段都可以分为1个或以上的迭代，通常是耗时的，而不是功能盒。建筑师和分析师在开发人员和测试人员之前进行一次迭代，以使他们的工作产品保持积压。
用法/历史
克雷格·拉曼（Craig Larman）和维克多·巴西利（Victor Basili ）的文章“迭代和增量发展：简短的历史”提供了许多早期用法的例子，其中最早的是NASA 1960年代的Mercury 。
后来，一些水星工程师在IBM内形成了一个新的部门，“在这里取得了重大成功的另一个早期且引人注目的例子[]是NASA航天飞机软件的核心- 主要的航空航天型软件系统，它们[它们]从1977年构建了到1980年。该团队在31个月的17个迭代中应用了IID，平均每个迭代约为8周。他们避免瀑布生命周期的动机是，班车计划在软件开发过程中的要求改变了。”
一些组织，例如美国国防部，偏爱迭代方法，从MIL-STD-498开始，“显然鼓励进化获取和IID”。
DOD指令5000.2于2000年发布了对IID的明显偏爱：
有两种方法，即进化和单步[瀑布]，以完全能力。进化方法是首选。 …[在这种方法中，传递给用户的最终能力分为两个或更多块，并具有越来越多的能力的增量...软件开发将遵循迭代性螺旋开发过程，在该过程中，不断扩展的软件版本基于从中学习较早的发展。也可以分阶段完成。
最近对DODI 5000.02的修订不再是指“螺旋开发”，而是提倡通用方法作为软件密集型开发/采购计划的基准。此外，美国国际发展机构（USAID）还采用迭代和渐进的发展方法来设计，监视，评估，学习，学习和适应国际发展项目，以项目管理方法着重于合并协作，学习，以及适应迭代和适应编程的策略。
与瀑布发展形成对比
软件开发项目故障的主要原因是该模型的选择，因此应非常谨慎。
例如，瀑布发展范式在一步中完成了每个学科的项目范围内的工作成果，然后在随后的一步中继续进入下一个学科。商业价值一次就可以一次交付，并且只有在项目的最后，而在迭代方法中进行回溯。比较两种方法，一些模式开始出现：
- 用户参与：在瀑布模型中，用户参与模型的两个阶段，即要求和接受测试，并可能创建用户教育材料。而在增量模型中，每个阶段都涉及客户端。
- 可变性：仅在生命周期的构建阶段完成后，该软件才能将其交付给用户。另一方面，每个增量均交付给用户，在用户批准后，开发人员被允许朝下一个模块移动。
- 人力资源：与瀑布模型相比，在增量模型中，可能需要更少的员工。
- 时间限制：几个月后，在增量模型中，将在几周内将产品提供给用户。
- 项目规模：瀑布模型不适合小型项目，而增量模型适用于小型项目。
实施准则
推动软件实施和分析的指南包括：
- 设计，编码和测试修改的任何困难都应表示需要重新设计或重新编码。
- 修改应易于适合孤立且易于找到的模块。如果不这样做，则可能需要一些重新设计。
- 对桌子的修改应该特别容易制作。如果没有快速和轻松地进行任何表修改，则指示重新设计。
- 随着迭代的进行，修改应该变得更容易进行。如果不是，则存在一个基本问题，例如设计缺陷或补丁的扩散。
- 通常只允许一个或两个迭代存在补丁。在实施阶段避免重新设计可能需要补丁。
- 应经常分析现有的实施，以确定其衡量项目目标的效果。
- 程序分析设施应随时使用以帮助分析部分实施。
- 应征求用户反应并分析当前实施中缺陷的指示。
用于硬件和嵌入式系统
虽然术语迭代和增量开发在软件行业开始，但许多硬件和嵌入式软件开发工作正在使用迭代和增量技术。
可以在许多行业中看到这样的例子。最近有一个思维转变影响的一个领域是太空发射行业，其工作正在为更快，更广泛的技术创新带来的实质性新竞争力量，这是由于追求太空发射的私人公司的形成而带来的。这些公司（例如SpaceX和Rocket Lab ）现在在过去十年中都提供商业轨道发射服务，这是十年前六个国家所做的。技术开发方法，定价和服务产品的新创新（包括自2016年以来一直存在的能力，才能在先前飞出的（可重复使用的）助推器阶段飞往太空的能力- 降低了获得空间访问的价格。
SpaceX已经明确努力将迭代设计实践带入太空行业，并在航天器，发射车，电子和航空电子设备以及操作飞行硬件操作上使用该技术。
随着行业的开始变化，其他发射竞争者也开始改变其与政府机构的长期发展实践。例如，美国大型发布服务提供商联合发射联盟（ULA）始于2015年，一个长达十年的项目，旨在重组其发射业务 - 将两辆Lau NCH车辆置于一辆- 使用一种迭代和增量的方法来进行部分回顾以及接下来的十年中的低成本发射系统。