UML和模式应用学习笔记-2(迭代和进化式开发)

 

一:什么是迭代和进化式开发

1:迭代和进化式开发:通常会在还没有详细定义所有需求的情况下假设开发开始,同时使用反馈来明确和改进演化中的规格说明;

2:迭代方法与较高的成功率、生产率和低缺陷率具有关系;

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

4:迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化,并以遁环反馈和调整为核心驱动力,使之最终成为适当的系统;

5:因为反馈和调整使规格说明和设计不断进化,所以这种方法也称为迭代和进化式开发。

6:在项目开始为期三周的迭代中,可以用周一上午一个小时的时间与团队成员召开启动会议,明确本次迭代的任务和目标;

7:每次迭代都产生可执行的但不完整的系统,它不是已经准备好可以交付的产品。直到多次迭代(如10次或15次迭代)之后,系统才可能合格地用于产品部署;

8:在复杂、变更系统中,反馈和调整是成功的关键要素;

9:迭代提倡风险驱动与客户驱动相结合,早期的迭代目标要能够识别和降低最高风险,并且能构造客户最关心的可视化特性;

10:来自迭代N的反馈引起在迭代N+1中对需求和设计进行精化和调整;

UML和模式-LMLPHP

每次迭代后系统是增量式增长的,最后是一个完整的产品

二:如何在迭代项目处理变更

1:瀑布式过程是在实现之前,企图全面和正确地规格化、冻结,以及“签署”需求集和设计,以此与软件开发中不可避免的变更进行抗争。

2:迭代和进化式开发抱以接受变更和改写的态度,并以此为真正本质的驱动力。

3:迭代开发并不是提倡不受控制的,明确了其构想或市场变化时如何平衡需求,一方面认同和稳定一组需求,另一方面接受需求不断变更的事实。

4:迭代快速反馈来自用户、开发人员和测试(诸如负载测试和可用性测试)的反馈。

5:迭代是通过一系列有序的构造->反馈->调整遁环向前进展。早期迭代中系统偏离“正解轨迹”的程度会大于后继迭代;

6:在后期迭代中,很少会在需求上产生显著变化,但是存在这种可能性。这种后期的变化可能会给组织带来业务竟争优势;

三:迭代开发的优点

1:减少项目失败可能性,较高的成功率、生产率和低缺陷率具有关系

2:在早期(而不是晚期)缓解高风险(技术、需求、目标、可用性等)

3:早期可见的进展

4:早期反馈、用户参与和调整,会关生更接近涉从真实需求的精化系统

5:可控复杂性,团队不会被“分析瘫痪”或长期且复杂的步骤所淹没;

6:一次涉代中的经验可以被系统地用于改进开发过程本身,并如此反复进行下去;

四:一次迭代的持续时间和时间定量

1:大部分迭方法建议迭代时间在2到6周之间,小步骤、快速反馈和调整是迭代开发的主要思想,迭代时间过长会破坏迭代开发的核心动机并增加项目风险。

2:仅一周的迭代时间不足以获得有意义的产出和反馈,若迭代时间大于6周,则复杂性会变得不可控制,反馈将延期;

3:迭代的一个关键思想是时间定量,如果看起来难以满足期限要求,那么建议从本次迭代中除去一些任务或需求,并将其分配在将来的迭代中而不是推迟完成日期;

五:什么是瀑布生命周期

1:瀑布(或顺序)生命周期过程中,试图在编程之前(详细)定义所有或大部分需求;研究表明瀑布模型和软件项目高失败率具有极大关系;

2:瀑布方法需求中45%的特性从未被使用,期早期时间表和估计与最终实际情况可相差400%;

3:不要让瀑布思维侵蚀迭代项目,初始化阶段进行大量的分析和建模是导致其失败的一个关键原因;

4:瀑布模型有如此的错误倾向是因为典型的软件项目在需求上会经历25%变更,对于大型项目,其变更率甚至高达35%到50%;

5:任何基于事物长期稳定这一假设所作出的分析、建模、开发或管理实践都是具有根本缺陷的,变更对于软件项目来说是永恒。

感谢您的阅读,坚持每天进步一点点,离成功就更进一步;希望本文对您有所帮助;

 
 
05-02 19:19