软件开发过程 --迭代，进化和敏捷

介绍

相对于顺序或“瀑布”生命周期，迭代和进化式开发(iterative and evolutionary development)对部分系统及早地引入了编程和测试，并重复这一循环。这种方式通常会在还没有详细定义所有需求的情况下假设开发开始，同时使用反馈来明确和改进演化中的规格说明。

迭代开发是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代（iteration）；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。

示例

1. 在第一次迭代之前，召开明确为2天的需求工作会议，该会议的出席人员包括业务人员和开发人员（包括首席架构师）。

• 在第一天上午，只进行high-level的需求分析，例如只确定用例和特性的名称，以及关键的非功能性需求。注意：这种分析绝不可能是完美的。
• 通过咨询首席架构师和业务人员，从high-level 列表中选择10%-20%比例的用例准备进行详细的分析，选择的依据为具有重要的架构意义；具有高业务价值；具有高风险。
• 在剩下的一天半内，对选出的用例的功能和非功能性需求进行详细的分析。

2. 在第一次迭代之前，召开迭代计划会议，对细化好的用例，在特定时间内进行设计、构造(Build)和测试。要注意的是，因为其中包含大量的工作，所以并不是在第一次迭代中就要构造(Build)出全部的已经细化的用例。

3. 在三到四周内完成第一次迭代

• 在开始的两天内，开发者和其他成员进行分组的建模和设计工作，在首席架构师（或项目经理）的带领和指导下，在足够大的白板上画出UML的草图并用数码相机记录。
  [注意：UML只是用于交流和理解设计，并不是必要并且必须细化到能够生成代码的地步的那种UML文档。]
• 然后，剩余的时间几乎全部用于编程、测试和集成工作，开发者应将建模草图作为其灵感的起点，并且要清楚这些模型是局部并且概念模糊的。
• 进行大量的测试，包括单元测试，验收测试，负载测试和可用性测试等。
• 在结束前一周确认能够完成初始的迭代目标，否则缩小迭代的范围，将次要目标置回任务列表中。
• 在最后一周的星期二，Check In全部代码，并集成和测试所有代码，建立迭代的基线。
• 星期三上午，向外部演示此局部系统，展示早期可视进展，同时要求反馈。

4. 在第一次迭代即将结束时，召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。再选择具有重要架构意义和高业务价值的另外一定比例的用例，用1到2天对其进行详细分析。等这项工作完成后，会详细记录下大概40%的用例和非功能性需求。

5. 于周五上午，举行下一迭代的迭代计划会议。

6. 以相同步骤进行第二次迭代。

7. 反复进行4次迭代和五次需求工作会，这样在第4次迭代结束时，基本上已经记录了大概80%-90%的需求，但是很可能只实现了其中的40%左右。

注意：需求集是基于反馈和进化的，因此其质量远高于纯粹依靠推测而得出的瀑布式规格说明。

8. 用UP的术语来说就是细化阶段的结束，以后基本不再需要什么需求工作会议，需求已经稳定了。正式进入UP术语的构造阶段！接下来是一系列为期三周的迭代，在最后一周的周五的迭代计划会上选择适宜的下一步工作。

9. 待项目全部完成后，进行Beta测试和移交。

UP项目开发的四个主要阶段

1. 初始(Inception):

大体上的构想，业务案例、范围和模糊评估。

2. 细化(Elaboration):

已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的需求。

3. 构造(Construction):

对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。

4. 移交(Transition):

进行Beta测试和部署。

用例

资料来源：

l 《UML和模式应用》(第三版) (<<Applying UML and Patterns –An Introduction to Object-Oriented Analysis and Design and Iterative Development>>)