UML和模式应用（2）：迭代、进化和敏捷

UML和模式应用（2）：迭代、进化和敏捷

 

学习笔记：1小时

 

一、迭代

 

建模（构件UML草图。。。）的目的是为了理解，而非文档。

 

迭代开发是OOA、OOD称为最佳实践的核心。

敏捷实践是有效应用UML的关键。

UP是相对流行的、示范性的的迭代方法。

 

相对于顺序或瀑布声明周期，迭代和进化式开发对系统及早的引入了编程和测试，并重复这一循环。这种情况通常在没有确定所有详细需求的情况下开始，同时使用反馈来明确和改进演化中的规格说明。

 

在迭代开发中，依赖于短时快速的开发步骤、反馈和改写来不明确需求和设计。研究实践证明，迭代方法与较高的成功率、生产率和低缺陷率具有关系。

 

二、UP

 

软件开发过程描述了构造、部署以及维护软件的方式。

统一过程（UP）是一种流行的构造面向对象系统的迭代软件开发过程。RUP是对统一过程的详细精化，并且被广泛采纳。

 

UP对于采用OOA/D的项目来说是相对流行的迭代过程。

UP是通用的，是被公认为最佳实践。

UP是十分灵活和开发的，并且鼓励引进其他迭代方法中的有用实践，诸如XP、重构和持续集成等实践。

 

三、迭代和进化式开发

 

迭代开发是UP和大多数其他现代方法中的关键实践。在这种声明周期方法中，开发被组织为一系列固定的短期小项目，称为迭代；每次迭代都产生过测试、继承并可执行的局部系统。每次迭代都有各自的需求分析、设计、实现和测试驱动。

 

迭代声明周期急于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心动力，使之最终成为适当的系统。随着时间和迭代次数的递进，下次同增量式地发展完善，因此这一方法也被成为迭代和增量开发。因为反馈和调整使规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发。

 

迭代接受变更。瀑布式过程在实现之前，企图全面和正确地规格化、冻结软件的需求集和设计，最终与软件开发中不可避免的变更发生抗争。与其相反，迭代和进化式开发抱以接受变更和改写的态度，并以此为真正的本质的驱动力。

 

迭代的有点：

减少项目是失败的可能性，提高生产率，降低缺陷率。

在早期缓解高风险（技术、需求、目标、可用性等等）。

早期可见的进展。

早期反馈、用户参与和调整，会产生更接近涉众需求的精化系统。

可控复杂性；团队不会被“分析瘫痪”和长期且复杂的步骤所淹没。

以此迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。

 

一般来说，迭代周期范围为2~6周。小步骤、快速反馈和调整是迭代开发的主要思想，迭代时间过长会破坏迭代开发的核心动机并增加项目风险。太短时间（比如一周）不足以获得有意义的产品和反馈。

 

瀑布模型最失败的地方是假设软件规格说明是可预知和稳定的，并且能在项目开始时就正确定义，同时，具有低变更率。----实际这种假设就是错误的。任何有项目开发经验的人都知道：变更对于软件项目来说是永恒的。

 

四、敏捷方法及观点

 

UP提倡风险驱动与客户驱动相结合的迭代计划。这意味着早期的迭代目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。

 

风险驱动迭代开发更为明确地包含了以架构为中心迭代开发的实践，意味着早期迭代要致力于核心架构的构造、测试和稳定。因为没有稳定的架构就会带来高风险。

 

五、敏捷方法及其观点

 

敏捷开发通常应用实践定量和进化式开发、使用自适应计划、提倡增量交付并包含其他敏捷性（快速和灵活的响应变更）的价值和实践。

 

由于特定实践的多样性，因此不可能很精确定义敏捷方法。然而，具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所公有的基本实践。除此之外，它们还倡导反映简易、轻量、沟通、自组织团队等更多敏捷性的实践和原则。

 

敏捷宣言：

个体和迭代，超越过程和工具

工作的软件，超越完整的文档

客户协助，超越合同谈判

响应变更，超越履行计划。

 

本文出自 “熔 岩” 博客，转载请与作者联系！