增量，是强调软件在发布不同的版本时，每次都多发布一点点，是软件功能数量渐增地发布的过程。

增量开发，又叫增量式开发，是软件工程当中，一种常用的软件开发过程思想。其中增量是指在软件开发过程中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品。比如，需要开发一个类似WORD的软件，应该首先开发出文件管理（保存、读取文件）、基本编辑功能、打印等，而其它不太常用的功能可以最后开发。增量式开发，就是首先把大型程序分解成若干小的模块，然后对每个模块按照某种过程模型进行开发，最后把这些模块逐步集成为完整的软件产品。

采取增量式开发，会倾向于创建更小的方法和更具内聚性的类。你不是等埋头盲目地一次性编写一大堆代码。相反，你会经常评估代码质量，并不时地进行许多小调整。而不是一次修改许多东西。

增量式开发是20世纪70年代早期由Mills提出的。但直到80年代末，当Mills和他的助手们的净室论文和专项报告开始出现的时候才获得认同。Fred Brooks描述了增量式开发方法的深刻影响，针对该方法在软件实践方面的作用，给出了影响广泛的评论：“没有银弹：软件工程的本质和偶然性。”

Brooks的观察在工业实践中得到了证实。增量式开发有助于早期的和连续的质量评估、用户反馈和方便的开发进度的过程改进。增量式设计方法避免了在开发周期中部件集成之后风险的继承。而且增量式开发允许在整修开发周期过程中需求变化的系统协调。

增量式开发的技术基础是引用透明性特征。在软件开发的前后，这种特征要求规范及其实现定义了同样的数学函数。当拥有了这种特征时，设计就能显示出与它的规范的一致性。

大的软件系统由各个部分组成。系统各个部分组成的方式对项目的成功有重要的影响。增量式自顶向下的开发途径表现为软件系统的已开发和已测试部分作为功能累积子集的序列。在最早增量中开发了一个小系统，然后把功能添加到每一个后续增量中直到系统完成。这种软件系统的控制增长方式有利于客房、管理者，同样有利于技术人员。

进展的可见性

利用增量式开发，每一步增量实现了一个或多个最终用户功能。每一步增量包含所有早期的已开发的功能集加上一些新的功能；系统在逐步累积的增量中增长。例如，在早期增量结束时，开发者很有信心地说：系统的20%已100%完成了，而不是推测系统已完成了20%。

智能控制

增量式开发通过引用透明性，实现了整个系统开发过程中的智能控制。当在后续增量待实现的函数的子规范被嵌入当前增量流程逻辑中时，这种特性，即等式的等量替换令人满意。当拥有引用透明性时，一个系统的部件无需回溯就能根据其子规范得以实现。无需重做前期增量。这里策略有利于在一个完整系统中对每个增量进行正确性验证。

增量系统集成

净室增量式开发允许在整修开发生命期引用透明的用户函数增量的连续集成。因为每一步增量设计基于一个已验证的子规范和前期增量已测试的接口，因此几乎没有更深的设计和接口错误。较好的定义增量贯穿于整修系统开发过程，系统在良好定义的增量中深化。测试和验证工作始于开发周期早期。

连续质量反馈贯穿统计过程控制

已在净室中实践的增量式开发为统计过程控制提供了基础。每一个净室增量都是过程的一个完整周期，包含规范、开发和新的用户函数的验证，加上所有已工作的测试。作为统计过程控制的典型，把过程的每一次反复的性能度量与性能目标相比较，以决定是否过程一直在控制之下(即：是否正如所期望的那样发生)。

净室软件小组常使用在测试中的开发性能度量作为过程控制的标准。通常使用的度量包括每千行代码的错误数、失效的间隔时间(MTTF)、可靠性及可信性。其他过程控制方法或许依赖于所管理的事务，而不是产品的质量。进度一致性一、预算一致性瑟整体计划的一致性等等，都是按增量的实际性能与目标性能相比较而言。净室增量度量依据的标准描述了过程控制的具体级别，要按计划继续该项目，开发小组要求此级别。如果标准不符合，开发小组能从增量中检测执行数据，确定问题所在，必要时调整项目计划，修改软件开发过程，避免此类问题的再次发生。例如，如果增量的测试提示过程失去控制(如：质量标准不符合)，开发者们应停止测试，返回设计阶段，如果过程是在控制之下，下一歨增量工作才能继续。

统计过程控制(Statistical Process Control ,SPC)是为数据悼念和分析提供较好的开发技术的成熟的工程实践。丰富的方法和工具支持是希望从事更高实践的设计者可利用的。然而，SPC的基本实践要求少量的投资和努力就能产生充足的回报。统计过程控制应用的基本任务很简单：每一过程周期的性能度量，比较实际性能与预先定义的目标性能，确定不可接受偏差的原因，以及通过过程改变改进将来的性能。

例如，如果一个净室小组开发的一个产品在测试中习惯于每千行代码有三个或更少失效，那么一个增量每千行有5个失效或许认为是不可接收的偏差。在调查中，小组或许发现失效是由错误引起的，实际上在验证过程中错误才能被发现，不能证实代码改变的正确性。从这种分析中，小组认识到直到所有错误代码的改变被验证为正确之前这种验证不视为完整的。小组相应地修改验证过程，决心在将来的增量设计中避免因不正确的补丁而引起的失效。以这种方式，每步增量中产生的反馈用于改进下一歨增量过程。

统计过程控制的能力取决于针对正在进行的计划性能与实际性能的对比检验。确定造成不可接受的偏差的原因，制定专门过程改进措施，以重新获得控制或改善控制。净室软件小组实践这些基本原理，并加以发展。每个净室增量都是针对完善的期望来测试，任何失效都被认为是不可接受的。仔细分析由错误发生的失效与开发过程的关系，错误的来源是什么？为什么在小组评审中错误被忽视？如何改进过程避免相同错误站起来重犯？统计过程控制是衡量和提高小组成果的工程规范。

用户使用中不断的功能反馈

增量式开发有助于用户对一个进货系统的执行功能做出尽早的不断的反馈，必要时允许改变。因为增量执行于系统环境并代表了用户功能的子集，早期的增量能通过用户对系统功能性和实用性的检测来反馈。这种反馈有助于避免开发出失效的系统和建立用户可接受的最终产品。

变更的适应性

在系统需求和项目环境中增量式开发允许不可避免变更的系统适应性。在每一步增量完成时，系统需求的积累变更所产生的影响能根据当前规范和增量设计来评估。如果变更与将来增量想到独立，则通常与现已存在的增量开发计划相合并，并对进度和资源进行可能的调整。如果变更影响已完成的增量，自顶向下修改系统开发，通常重用绝大多数已存在的增量代码(通常是全部)，按照要求的进度和资源来进行相应调整。

进度与资源管理

项目资源在增量式开发全过程中能在可控制的方式下分配。可用进度是决定待开发的增量数据和其规模的一个因素。在短进度中，小规模增量将有助于在增量交付与认证组之间维持充分的时间段，允许一个有序的测试过程。然而，这将给项目开发小组设计和实现更大、更复杂的增量带来更多负担。进度和复杂性的折衷能够反映增量式开发计划。另外，从后续增量得到的反馈，为过程和产品性能的目标度量提供了管理，以允许在开发和测试中对不足和意外收获的适应。