迭代和增量过程
软件过程要做到更为有效，需要就有一系列非常清晰的里程碑，以便为项目经理和项目组的其他人员提供一个准则，他们需要以此来认可产品周期是否可以从一个阶段计入下一个阶段。
在每个阶段中，过程需要经历一系列的迭代和增量来满足这些准则。
初始阶段的根本准则使可行性，它通过以下方式达到：
- 确定并降低影响系统可行性的关键风险
- 通过用况建模将需求的关键子集转化为候选架构
- 在宽限条件下对成本、工作流、进度和产品质量进行初步估计
- 在宽限条件下，开始对从经济上考虑值得做的项目创建业务案例。
细化阶段的根本准则是在经济框架内构造系统的能力，它通过一下方式达到：
- 确定并降低对系统构造有重大影响的风险
- 确定代表待开发功能的大部分用况
- 将候选构架扩展为可执行的基线部分
- 指定足够详细的项目计划来指导构造阶段
- 在较严的条件下进行估计，以便调整项目的商业报价
- 对值得做的项目确定业务案例的最终方案
构造阶段的根本准则是使系统能够在用户环境下完成最初的操作，它通过一下方式达到：
- 通过一系列迭代，得到周期性的构造和增量，这样在完成该阶段时，系统可行性便会以可执行的形式明确表现出来
移交阶段的根本准则是一个达到最终操作能力的系统，它通过以下方式达到：
- 修改产品以缓解在早期阶段没有发现的问题
- 修正缺陷。
迭代和增量概述
用况驱动开发意味着在驱动中产生最终产品的每个阶段都能回顾一下为用户实际上做了什么，从而使开发人员能确保系统满足用的真正需要。
以构架为中心意味着早期阶段开发工作侧重于建立指导系统构造的构架模式，保证不仅对当前产品版本、而且对整个产品的生命都有一个顺利的发展。
在用况和构架间达到恰当的平衡很像产品开发中功能和表现形式的平衡，开发人员通过一系列迭代有意识地做到在用况和构架间的平衡。
以细小的步骤开发
迭代和增量过程提出了以细小的可管理的步骤开发软件产品的策略：
- 计划一小步
- 说明、设计和实现一小步。
- 集成、测试和运行每次迭代。
如果你对这一步感到满意，就进行下一步。在每步之间会得到反馈，并一次来调整下一步的侧重点。然后开始另一步，接着再一步。当处理完计划的所有步骤后，便开发处理可以向客户和用户发布的产品。
每次迭代均包括软开发项目所具备的一切：规划，通过一系列工作流进行处理，最后准备发布。但是迭代不是一个完全独立的实体，它使项目的一个阶段，它在很大程度上是作为项目的一部分而得到的。
早期的迭代增进了对需求、问题、风险和方案领域的了解，而后期迭代产生的附加增量最终构成了外部版本。
迭代不是什么
为什么采用迭代和增量的开发方法
为了达到用来控制开发的主要里程碑和次要里程碑：
- 为了尽早处理关键风险和重要风险。
- 为了建立一个构架来指导软件开发。
- 为了更好地处理不可避免的需求以及其他变化而提供的一个框架。
- 为了随时间而递增地构建系统，而不是在临近结束时才一下子建成一个系统，那时候的改变需要付出很大的代价。
- 为了提供一个开发过程，使所有工作人员可更高效地工作。
降低风险
风险是将先有资源头像未来期望结果的委托行为中固有的。我们通过在开发中尽可能早地确定风向并作出迅速处理来解决这个显示问题。
统一过程在最初两个阶段中便致力于解决主要的风险，并在构造阶段的早期按照风险重要顺序逐个解决其余风险。因此，未经确定的或忽略的风险不会再后期突然出现并危害整个项目。
获得一个健壮的构架
得到一个健壮的构建本身是早期阶段迭代的结果。
处理不断变化的需求
在早期阶段，系统部分地运行就可以使用户和其他项目相关人员提供建议并指出可能被忽略的需求。计划-预算和进度表-还没有最终确定下来，开发人员可以容易地进行修正。所以响应反馈或进行修改时只是对一个增量的修改。
允许灵魂改变
开发人员可以解决前期构造中发现的问题，并能立刻改变来纠正这些问题。
实现持续集成
每次迭代后，项目组均交付递增的功能，这使与项目相关的所有人员能够清楚地看到项目的进展情况。
尽早得到有关知识
经过几次迭代之后，开发组的每个人都对不同工作流的含义有了深入的理解。
培训新的人员会更容易一些，因为他们能够通过工作本身得到训练。
迭代方法还有助于处理非技术风险，如组织风险。
迭代方法使风险驱动的
风险时威胁或阻碍项目成功的一个不定因素。它是一个项目将经历不希望的事件（如进度延期、成本超支或彻底放弃）的可能性。
依据风险及其重要性的先后顺序确定、排序并执行迭代。在一下集中情况下都需要这样做：
- 在评价新技术时；
- 为满足客户的需要而工作时
- 在早期阶段正在建立一个健壮的构架时。
其他严重的风险时性能、可靠性、可用性、系统界面一致性、适应性和可一致性方面的问题。许多这类风险指导实现和测试底层功能时财报了出来。
原则上，所有技术分析按都能够映射到用况或用况脚本。映射的意思时：如果具有功能性和非功能性需求的用况得以实现，就能够降低风险。这不仅适用于与需求和构架有关的风险，而且适用于检验底层的硬件和软件。
降低风险时初始和细化阶段迭代工作的核心。在构造阶段，在很大程序上风险已经降低到了一个常规的级别。
迭代降低了技术风险
风险可以划分为很多种。然而，对我们来说只需提出一些就足够了：
- 与新技术有关的风险。
- 与构架有关的风险。尽早建立能承受风险的构架。
- 与创建适当的系统有关的风险。尽早确定最重要的功能并确保尽早予以实现时非常重要的。在选择用况时，我们根据它们潜在风险来决定处理它们的顺序。
- 某些与性能有关的风险。
管理对非技术性风险负责
非技术性风险是哪些机警的管理人员能够发觉并解决的风险：软件组织应该确定它们，应指定管理措施跟踪每个风险范围内的开发工作，并确保这类风向发生时具体负责的经理能够采取具体行动取缓解风险。
处理风险
一旦确定了风险并对其排定先后次序后，开发组下一步就是决定如何逐个进行处理。基本上有四种选择：
- 避免，也许通过重新规划项目或改变需求，有些风险能够而且应当得到避免。
- 限制，其他的风险加以限制，即进行约束，以使这些风险指影响项目或系统的一小部分。
- 减轻，有些风险可以通过实验看他们是出现还是小猪而餐区缓解措施。
- 监控，有些风险无法缓解，开发组只能监控它们，看它们是否出现。如果某个风险确实出现了，开发组必须按照应急计划进行处理。
处理风险需要花费时间，一个项目组很少能同时处理所有风险，这就是为什么区分迭代先后次序是必要的。
通用迭代过程
迭代是什么
一次迭代是一个能够产生内部版本的袖珍项目
可以把迭代看作是一个工作流，这表明它是一种使用和生产制品的工作要之间的协作。在统一过程中，我们区分核心工作流和迭代工作流。
规划迭代过程
迭代方法在初始阶段并不对整个项目进行详细规划，而只是对最初的几步进行规划。指导细化阶段建立了事实的基础，项目组才视图对构造和移交阶段进行规划。当然，在最初两个阶段有工作计划，但不太详细。
除了在项目的最开始，通常规划工作要考虑以前的迭代结果、与新的迭代相关的用况选取、出现在下一次迭代中的风险限制移交模型集合的最新版本。
在细化阶段后期，已经有了对项目的其余部分进行规划并为构造阶段的每次迭代确定详细计划的基础。其中第一次迭代的计划将会十分清晰；而后面的迭代不太详细，它们将在早期迭代中慢慢积累的成功和知识的基础上不断进行修正。同样，也应该制品移交阶段的计划，但要根据开发组从构造阶段迭代中得到的经验或教训来进行修改。
确定迭代次序
用况设定了一个目标，而构架建立了一个模式。记住这个目标和模式，开发人员便可以规划出进行产品开发的顺序。
在一次迭代将要结束而另一次迭代即将开始时，迭代过程可能出现交叠。
一次迭代产生一个增量的结果
一个增量是一次迭代的内部版本与下一次迭代的内部版本之间的差别。
迭代过程的最后，代表系统的模型集合处于一种特定的状态。这种状态或状况称为基线。每种模型都移交到达一条基线；每个基本模型的元素处于基线状态。
在整个生命周期上的迭代
四个阶段中的每一个阶段都以一个主要里程碑结束：
- 初始：生命周期里程碑
- 细化：生命周期构架
- 构造：最初的可操作能力
- 移交：产品发布
每个阶段内有更小的里程碑，也就是适用于每个迭代过程的准则。
每个阶段结束时的主里程碑处，经理作出继续或不继续前进的重大决定，并确定进度、预算和需求。在次里程碑（第一次迭代最后发布版本的时刻）处，经理和开发人员决定如何进行后续的迭代。主次里程碑之分主要在业务级别。
主里程碑时管理层和技术领域的结合点。
主里程碑划分有助于管理层和其他项目相关人员对在低成本的初始和细化阶段所完成的工作进行评价，然后再决定是否进入到高成本的构造阶段。
一个软件开发项目可以粗略地画风为两大块：初始和细化阶段与构造和移交阶段。再初始和细化阶段，我们建立业务案例，缓解最主要的风险，创建构架基线，并精确规划项目的其他部分。然后项目进入到构造阶段，此时的目标时实现规模经济。此时，参与项目的人数有所增加，他们通过再细化阶段建立的构架基线上进行构造来开发大部分的系统功能；并尽量重用现有的软件。
由迭代过程来进化模型
迭代过程是以逐渐递增的方式构造出最终模型。
