模型增量模型也如下图所示，为渐增模型。
使用增量模型开发软件时，将软件产品作为一组增量组件进行设计、编码、集成和测试。 各组件由多个相互作用的模块构成，可以实现特定的功能。 使用增量模型时，第一个增量组件满足软件的基本需要，并提供最核心的功能。
例如，使用增量模型开发文字处理软件时，第一个增量组件提供基本的文件管理、编辑和文档生成功能。 第二个增量组件提供了更高级的编辑和文档生成功能。 第三个增量组件实现拼写和语法检查功能； 第四个增量组件提供了高级页面布局功能。 将软件产品分解为增量构件时，所用构件规模适中，规模过大或过小均可。 最佳分解方法根据软件产品的特点和开发者的习惯而不同。 分解时必须遵守的唯一限制是，将新部件集成到现有软件中时，完成的产品必须可测试。
使用瀑布模型或快速原型模型开发软件时，目标是一次向用户提交满足所有需求的产品。 与增量模型相反，它将产品分阶段提交给用户，整个软件产品被分解为多个增量组件，开发者逐个将产品提交给用户。 从第一个零件交货的那天起，用户可以做一些有用的工作。 显然是能在较短时间内向用户提交可完成部分工作的产品，是怎量模型的一个优点。
增量模式的另一个优点是，通过逐步添加产品功能，用户可以有更多的时间学习和适应新产品，减少新软件对客户组织的冲击。
使用增量模型的困难在于，将新的增量组件集成到现有软件体系结构中时，必须确保不破坏已经开发的产品。 此外，软件体系结构的设计必须便于扩展，并且向现有产品添加新组件的过程必须简单方便。 这意味着软件体系结构必须是开放的。
但从长远角度看，具有开放架构的软件具有真正的优势，这类软件的可维护性明显优于封闭架构的软件。 因此，与采用瀑布模型和快速原型模型相比，采用增量模型需要更精密的设计，但在设计阶段会付出更多的精力，并且在维护阶段会得到回报。 如果设计非常灵活且足够开放以支持增量模型，则这些设计可以在不损坏产品的情况下进行维护。 事实上，使用增量模型时，软件开发和软件功能扩展(完整性维护)没有本质区别，而是向现有产品中添加新组件的过程。
从某种意义上说，增量模型本身是矛盾的。 这一方面要求开发者将软件视为一个整体，另一方面要求开发者将软件视为部件序列，每个部件在本质上是独立于其他部件的。 除非开发人员有足够的技术能力来协调这一明显的矛盾，否则以增量模式开发的产品可能无法满足。
上图所示的增量模型表明，在开始实现每个组件之前，必须完成所有需求分析、规格说明和概要设计工作。 由于在开始构建第一个组件之前进行了总体设计，因此风险较低。
下图显示了一个更具风险的增量模型。
用户需求确定后，开始编写第一个组件的规格说明文件，完成后，规格说明组将转移到第二个组件的规格说明。 与此同时，设计组开始设计第一个组件……这样开发软件的话，不同的组件会并行构筑，从而可以提高工程的速度。
但是，这样的方法有部件无法集成的风险，除非仔细监视整个开发过程，否则整个项目可能会被破坏。