迭代、进化和敏捷
什么是UP？其他方法能否对其进行补充？
软件开发过程描述了构造、部署以及维护软件的方式。统一过程是一种构造面向对象系统的迭代软件开发过程。
- UP是迭代过程
- UP 实践提供了如果实施OOA/D的示范结构。
- UP 具有灵活性，可以应用于轻量级和敏捷方法。
什么是迭代和进化式开发
在迭代开发生命周期方法中，开发被组织成一系列固定的短期小项目，称为迭代；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。
迭代生命周期基于对经过多次迭代的系统进行持续扩展和精华，并以循环反馈和调整为核心驱动器，使之最终政委适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代和增量式开发。因为反馈和调整使规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发。
每次迭代都产生可执行的但不完整的系统，它不是以及准备好可以交付的产品。直到多次迭代之后，系统才可能合格地用于产品部署。
如何在迭代项目中处理变更
迭代开发抱以接受变更和改写的太不，并以此为正真本质的驱动力。
这并不是说迭代开发和UP提倡不受控制的、反应式的“特性蔓延”驱动的过程。UP在涉众明确了其构想或市场变化时，一方面认同和稳定一组需求，另一方面接受需求不断变更的事实。
每次迭代选择一小组需求，并快速设计、实现和测试。快速地实施一小步的方式可以得到快速反馈以改进软件和发现什么对涉众有真正价值。
除了明确需求，负载测试将严重局部设计和实现是否正确。及早解决和严重具有风险、关键的设计决策。
迭代开发的优点
- 减少项目失败可能性，提高生产率，降低缺陷率。
- 在早期缓解高风险。
- 早可见的进展。
- 早期反馈、用户参与和调整，会阐述更接近涉众真实需求的精化系统。
- 可控复杂性；团队不会被“分析瘫痪”或长期且复杂的不知所淹没。
- 一次迭代中的精英可以被系统地用于改进开发过程本身，并如此反复进行下去。
一次迭代的持续实践和时间定量
大部分迭代方法建议迭代实践在2-6周之间。小步骤、快速反馈和调整是迭代开发的主要思想，迭代时间过短，时间不足以获得有意义的产出和反馈。迭代时间过长，则复杂性会变得不可控制，反馈将延迟。
迭代的一个关键思想是时间定了。如果一次看起来难以满足期限要求，那么建议从本次迭代中除去一些任务或需求。
什么是瀑布生命周期
在瀑布生命周期过程中，试图在编程之前定义所有或大部分需求。而且通常于编程之前创建出完整的设计。同意，会试图在开始前定义“可靠”的计划或时间表，但常常事与愿违。
提倡瀑布方法源于推出和风闻，而非实践证实。与之相反，迭代和进化式开发为实际证据所支持，研究表明其失败的机率更小，与更理想的生产力和缺陷率相关。
准则：不要让瀑布思维侵蚀迭代或UP项目
为什么瀑布模型具有如此的错误倾向
与错误的假设有关：规格说明是可预知的和稳定的，并且能够在项目开始时就正确定义，同时具有低变更率。
反馈和改写的必要性
- 来自早期开发中的反馈，有助于程序设计人员理解规格说明，客户演示也有助于精化需求。
- 来自测试中的反馈，有助于开发者精化设计或模型。
- 来自团队处理早期特性过程中的反馈，有助于精化时间表和估计。
- 来自客户和市场的反馈，有助于重新定义下一次迭代实现特性的优先级。
如何进行迭代和进化式分析和设计
这里有个简短的例子，用以说明在运转良好的UP项目中，迭代方法是如何被运用的。这里假设项目交付前，最终酱油20次迭代。
- 在第1次迭代之前，召开第一个时间定了的需求工作会议，例如确切的定义为两天时间。业务和开发人员（包括首席架构师）需要出席。
- 在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种分析不可能是完美的。
- 通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项（例如，30个用例名中的10%），这些项目要具备以下三种性质：1.具有重要的架构意义（如果要实现，我们必须时间、构造和测试的核心架构），2.具有高业务价值（业务真正关心的特性），3.具有高风险（例如“能够处理500个并发交易”）。所选的三个用例可能被标识为：UC2、UC11和UC14.
- 在剩下的一天半内，对着三个用例的功能和非功能性需求进行消息的分析。完成这一过程后，对10%进行了深入分析，90%进行了高阶分析。
- 在第1次迭代之前，召开迭代计划会议，选择UC2、UC11和UC14的子集，在特定时间内（例如四周的时间定量迭代）进行设计、构造和测试，要注意的是，因为其中包含大量工作，所以并不是在第1次迭代中就要构造出全部三个用例。在选择了特定子集目标后，在开发团队的帮助下，将其分解为一些列更为消息的迭代任务。
- 在三到四周内完成第1次迭代（选择时间定量，并严格遵守时间）。
- 在开始的两天内，开发者和其他成员分组进行建模和设计工作，在首席架构师的带领和指导下，于“公共作战室”的众多白板上，画出UML的草图（及其他的模型）。
- 然后，开发者摘掉“建模帽子”并戴上“编程帽子”，开始编程、测试和继承工作并且剩余的时间均用于完成这项工作。开发者将建模草图作为其灵感的起点，但是要清楚这些模型只是局部的，并且通常是含糊的。
- 在进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。
- 在结束前的一周，检查示范能够完成初始的迭代目标；如果不能，则缩小迭代的范围，将次要的目标置回任务列表中。
- 在最后一种的星期二，冻结代码：必须检入、继承和测试所有代码，以建立迭代的基线。
- 在星期三的上午，想外部涉众验收此局部系统，展示早期可视进展，同时要求反馈。
- 在第1次迭代即将结束时（如最后一周的星期三和星期四），召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析。这项工作完成后，会详细记录下大概25%的用例和非功能性需求。当然，这也不是完美的。
- 于周五上午，举行下一次迭代的迭代计划会议。
- 以相同不知进行第2次迭代。
- 反复进行四次迭代和五次需求工作会，这样在第4次迭代结束时，可能以及详细记录了约80%-90%的需求，但只实现了系统的10%。（注意：这些大量的、详细的需求集时基于反馈和进化的，因此其质量远高于纯粹依靠推出而得出的瀑布式规格说明）。
- 我们大概推荐了整个项目过程的20%。在UP的术语里，这是细化阶段的结束。此时，可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、返回结论并进行了早期编程和测试，因此估计能够做什么和需要多长时间的结果会更为可靠。
- 此后，一般不需要召开需求工作会；需求以及稳定了（尽管需求永远不会被冻结）。接下来时一系列为期三周的迭代，在最后一个周五招待的迭代计划会上选择适宜的下一步工作，每次迭代都要反复询问：“就我们现在所知，下一次三周应该完成的、最关键的技术和业务特性时什么。”
利用这种方式，经过早期探索式开发的几次迭代之后，团队将能够更准确地回答“什么、多少、何时”。
什么是风险驱动和客户驱动的迭代计划
UP 提倡风险驱动与客户驱动相结合的迭代计划。这意味着早期的迭代目标要能够失败和降低最高风险，并且能构造客户最关心的可视化特性。
风险驱动迭代开发更为明确地包含了以架构为中心迭代开发的实践，意味着早期迭代要致力于核心架构的构造、测试和稳定。为什么？业务没有稳固的架构就会带来高风险。
什么是敏捷方法及其观点
敏捷开发方法通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性的架构和实践。
什么是敏捷建模
建模的目的主要时为理解，而非文档。
建模的真正行为能够并且时应该能够对理解问题或解决方案空间提供更好的方式。为良好的OO设计快速探索可选的方案和途径。
敏捷建模：
- 采用敏捷方法并不意味着不进行任何建模。
- 建模和模型的目的主要用于理解和沟通，而不是构建文档。
- 不要对所有或大多数软件设计建模或应用UML。
- 尽可能使用最简单的工具。
- 不要单独建模，而是结对在白板上建模，同时要记住建模的目的时发现、理解和共享大家的理解。
- 并行地创建模型。
- 在白板上用笔画草图时，应使用“足够好”的简单表示法。
- 要知道所有模型都可能时不准确的，最总代码或设计会与模型有差异，甚至具有极大的差异。
- 开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他编程者去实现。
什么是敏捷UP
UP 可以采纳和应用可适应性和轻量级的精神--敏捷UP。一下时应用的一些示例：
- 推荐使用UP活动和制品的简集。
- UP 时迭代和不断进化的，所有在实现前的续期和设计时不完整的。它们是在一系列迭代中，基于反馈而产生的。
- 以面积建模实践应用UML
- 对于整个项目不应有详细的计划。
UP的其他关键实践
UP 所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。其他一些UP的最佳实践和关键概念包括：
- 在早期迭代中解决高风险和高价值的问题。
- 不断地让用户参与评估、反馈和需求。
- 在早期迭代中建立内疚的核心架构。
- 不断地严重质量：提早、经常和实际地测试。
- 在适当的地方使用用例。
- 进行一些可视化建模。
- 认真管理需求。
- 实行变更请求和配置管理。
什么是UP的阶段
UP项目将其工作和迭代组织为四个主要阶段：
- 初始：大体上的构想、业务案例、范围和模糊的评估。
- 细化：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。
- 构造：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。
- 移交：进行beta测试和部署。
什么是UP科目
UP 描述了科目中的工作活动。科目是在一个主题域中的一组活动。在UP中，制品是对所有工作产品的通常。
UP中有几个科目，本书之关注一下三个科目中的制品：
- 业务建模：领域模型制品，使应用领域中的重要概念可视化。
- 需求：用以铺货功能需求和非功能需求的用例模型及其不成形的规格说明制品。
- 设计：设计模型制品，用于对软件对象进行设计。
科目和阶段之间的关系
一次迭代的工作会遍历大部分或全部科目。然而，跨越这些科目的相对工作量会随着时间发生变化。
UP 阶段和科目对本书结构的影响
前面几章介绍初始阶段的活动，随后几章讨论细化阶段中的几个跌打：
- 初始极端对应的章介绍需求分析的基本内容。
- 迭代1介绍OOA/D基础和如何为对象分配职责。
- 迭代2的重点使对象设计，特别介绍一些经常使用的“设计模式”。
- 迭代3介绍各种主题，例如架构分析和框架设计。
如何定制过程和UP开发案例
UP中有可选制品或世界吗
几乎所有制品和实践都是可选的。也就是说，某些UP实践和原则使一成不变的。然而UP的一个关键内涵使，所有活动和制品都是可选的--除了代码。
定义：什么使开发案例
为项目选择实践和UP制品可以编写为简短文档，这称为开发案例。
判断你是否理解迭代开发或UP
- 在开始设计或实现之前试图定义大多数需求。同样，在开始实现之前试图定义大多数设计；试图在迭代编程和测试之前定义和提交完整的架构。
- 在编程之前花费数日或数周进行UML建模，或者认为在绘制UML图和进行设计时要准确完整地定义及其详细的设计和模型。
- 任务初始阶段=需求阶段，细化阶段=设计阶段，构造阶段= 实现阶段。
- 认为细化的目标时完整仔细地定义模型，以能够在构造阶段将其转换为代码。
- 匠心合适的迭代实践长度为三个月之久，而不是三周。
- 认为采用UP就意味着要完成大量可能的活动可创建大量的文档，并且任务UP时需要遵循大量步骤的、整个和繁琐的过程。
- 试图对项目从开始到结束执行详细计划；试图预测所有迭代，以及每个迭代中可能发生的事情。