UML和模式应用(2):迭代、进化和敏捷

  1. 云栖社区>
  2. 博客>
  3. 正文

UML和模式应用(2):迭代、进化和敏捷

技术小阿哥 2017-11-15 10:40:00 浏览576
展开阅读全文
学习笔记:1小时
 
一、迭代
 
建模(构件UML草图。。。)的目的是为了理解,而非文档。
 
迭代开发是OOA、OOD称为最佳实践的核心。
敏捷实践是有效应用UML的关键。
UP是相对流行的、示范性的的迭代方法。
 
相对于顺序或瀑布声明周期,迭代和进化式开发对系统及早的引入了编程和测试,并重复这一循环。这种情况通常在没有确定所有详细需求的情况下开始,同时使用反馈来明确和改进演化中的规格说明。
 
在迭代开发中,依赖于短时快速的开发步骤、反馈和改写来不明确需求和设计。研究实践证明,迭代方法与较高的成功率、生产率和低缺陷率具有关系。
 
二、UP
 
软件开发过程描述了构造、部署以及维护软件的方式。
统一过程(UP)是一种流行的构造面向对象系统的迭代软件开发过程。RUP是对统一过程的详细精化,并且被广泛采纳。
 
UP对于采用OOA/D的项目来说是相对流行的迭代过程。
UP是通用的,是被公认为最佳实践。
UP是十分灵活和开发的,并且鼓励引进其他迭代方法中的有用实践,诸如XP、重构和持续集成等实践。
 
三、迭代和进化式开发
 
迭代开发是UP和大多数其他现代方法中的关键实践。在这种声明周期方法中,开发被组织为一系列固定的短期小项目,称为迭代;每次迭代都产生过测试、继承并可执行的局部系统。每次迭代都有各自的需求分析、设计、实现和测试驱动。
 
迭代声明周期急于对经过多次迭代的系统进行持续扩展和精化,并以循环反馈和调整为核心动力,使之最终成为适当的系统。随着时间和迭代次数的递进,下次同增量式地发展完善,因此这一方法也被成为迭代和增量开发。因为反馈和调整使规格说明和设计不断进化,所以这种方法也称为迭代和进化式开发。
 
迭代接受变更。瀑布式过程在实现之前,企图全面和正确地规格化、冻结软件的需求集和设计,最终与软件开发中不可避免的变更发生抗争。与其相反,迭代和进化式开发抱以接受变更和改写的态度,并以此为真正的本质的驱动力。
 
迭代的有点:
减少项目是失败的可能性,提高生产率,降低缺陷率。
在早期缓解高风险(技术、需求、目标、可用性等等)。
早期可见的进展。
早期反馈、用户参与和调整,会产生更接近涉众需求的精化系统。
可控复杂性;团队不会被“分析瘫痪”和长期且复杂的步骤所淹没。
以此迭代中的经验可以被系统地用于改进开发过程本身,并如此反复进行下去。
 
一般来说,迭代周期范围为2~6周。小步骤、快速反馈和调整是迭代开发的主要思想,迭代时间过长会破坏迭代开发的核心动机并增加项目风险。太短时间(比如一周)不足以获得有意义的产品和反馈。
 
瀑布模型最失败的地方是假设软件规格说明是可预知和稳定的,并且能在项目开始时就正确定义,同时,具有低变更率。----实际这种假设就是错误的。任何有项目开发经验的人都知道:变更对于软件项目来说是永恒的。
 
四、敏捷方法及观点
 
UP提倡风险驱动与客户驱动相结合的迭代计划。这意味着早期的迭代目标要能够识别和降低最高风险,并且能构造客户最关心的可视化特性。
 
风险驱动迭代开发更为明确地包含了以架构为中心迭代开发的实践,意味着早期迭代要致力于核心架构的构造、测试和稳定。因为没有稳定的架构就会带来高风险。
 
五、敏捷方法及其观点
 
敏捷开发通常应用实践定量和进化式开发、使用自适应计划、提倡增量交付并包含其他敏捷性(快速和灵活的响应变更)的价值和实践。
 
由于特定实践的多样性,因此不可能很精确定义敏捷方法。然而,具备进化式精化的计划、需求和设计的短时间定量迭代是这些方法所公有的基本实践。除此之外,它们还倡导反映简易、轻量、沟通、自组织团队等更多敏捷性的实践和原则。
 
敏捷宣言:
个体和迭代,超越过程和工具
工作的软件,超越完整的文档
客户协助,超越合同谈判
响应变更,超越履行计划。
 
本文转自 leizhimin 51CTO博客,原文链接:http://blog.51cto.com/lavasoft/101179,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
技术小阿哥
+ 关注