成功的软件开发过程 --迭代,进化和敏捷
成功的软件开发过程
迭代,进化和敏捷
介绍
相对于顺序或“瀑布”生命周期,迭代和进化式开发(iterative and evolutionary development)对部分系统及早地引入了编程和测试,并重复这一循环。这种方式通常会在还没有详细定义所有需求的情况下假设开发开始,同时使用反馈来明确和改进演化中的规格说明。
迭代开发是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中,开发被组织成一系列固定的短期(如三个星期)小项目,称为迭代(iteration);每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。
示例
1. 在第一次迭代之前,召开明确为2天的需求工作会议,该会议的出席人员包括业务人员和开发人员(包括首席架构师)。
l 在第一天上午,只进行high-level的需求分析,例如只确定用例和特性的名称,以及关键的非功能性需求。注意:这种分析绝不可能是完美的。
l 通过咨询首席架构师和业务人员,从high-level 列表中选择10%-20%比例的用例准备进行详细的分析,选择的依据为具有重要的架构意义;具有高业务价值;具有高风险。
l 在剩下的一天半内,对选出的用例的功能和非功能性需求进行详细的分析。
2. 在第一次迭代之前,召开迭代计划会议,对细化好的用例,在特定时间内进行设计、构造(Build)和测试。要注意的是,因为其中包含大量的工作,所以并不是在第一次迭代中就要构造(Build)出全部的已经细化的用例。
3. 在三到四周内完成第一次迭代
l 在开始的两天内,开发者和其他成员进行分组的建模和设计工作,在首席架构师(或项目经理)的带领和指导下,在足够大的白板上画出UML的草图并用数码相机记录。
[注意:UML只是用于交流和理解设计,并不是必要并且必须细化到能够生成代码的地步的那种UML文档。]
l 然后,剩余的时间几乎全部用于编程、测试和集成工作,开发者应将建模草图作为其灵感的起点,并且要清楚这些模型是局部并且概念模糊的。
l 进行大量的测试,包括单元测试,验收测试,负载测试和可用性测试等。
l 在结束前一周确认能够完成初始的迭代目标,否则缩小迭代的范围,将次要目标置回任务列表中。
l 在最后一周的星期二,Check In全部代码,并集成和测试所有代码,建立迭代的基线。
l 星期三上午,向外部演示此局部系统,展示早期可视进展,同时要求反馈。
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>>)