UML和模式應用（2）迭代進化和敏捷

uml和模式應用（2）：迭代、進化和敏捷

學習筆記：1小時

一、迭代

建模（構件uml草圖。。。）的目的是為了理解，而非文件。

迭代開發是ooa、ood稱為最佳實踐的核心。

敏捷實踐是有效應用uml的關鍵。

up是相對流行的、示範性的的迭代方法。

相對於順序或瀑布宣告週期，迭代和進化式開發對系統及早的引入了程式設計和測試，並重複這一迴圈。這種情況通常在沒有確定所有詳細需求的情況下開始，同時使用反饋來明確和改進演化中的規格說明。

在迭代開發中，依賴於短時快速的開發步驟、反饋和改寫來不明確需求和設計。研究實踐證明，迭代方法與較高的成功率、生產率和低缺陷率具有關係。

二、up

軟體開發過程描述了構造、部署以及維護軟體的方式。

統一過程（up）是一種流行的構造物件導向系統的迭代軟體開發過程。rup是對統一過程的詳細精化，並且被廣泛採納。

up對於採用ooa/d的專案來說是相對流行的迭代過程。

up是通用的，是被公認為最佳實踐。

up是十分靈活和開發的，並且鼓勵引進其他迭代方法中的有用實踐，諸如xp、重構和持續整合等實踐。

三、迭代和進化式開發

迭代開發是up和大多數其他現代方法中的關鍵實踐。在這種宣告週期方法中，開發被組織為一系列固定的短期小專案，稱為迭代；每次迭代都產生過測試、繼承並可執行的區域性系統。每次迭代都有各自的需求分析、設計、實現和測試驅動。

迭代宣告週期急於對經過多次迭代的系統進行持續擴充套件和精化，並以迴圈反饋和調整為核心動力，使之最終成為適當的系統。隨著時間和迭代次數的遞進，下次同增量式地發展完善，因此這一方法也被成為迭代和增量開發。因為反饋和調整使規格說明和設計不斷進化，所以這種方法也稱為迭代和進化式開發。

迭代接受變更。瀑布式過程在實現之前，企圖全面和正確地規格化、凍結軟體的需求集和設計，最終與軟體開發中不可避免的變更發生抗爭。與其相反，迭代和進化式開發抱以接受變更和改寫的態度，並以此為真正的本質的驅動力。

迭代的有點：

減少專案是失敗的可能性，提高生產率，降低缺陷率。

在早期緩解高風險（技術、需求、目標、可用性等等）。

早期可見的進展。

早期反饋、使用者參與和調整，會產生更接近涉眾需求的精化系統。

可控複雜性；團隊不會被「分析癱瘓」和長期且複雜的步驟所淹沒。

以此迭代中的經驗可以被系統地用於改進開發過程本身，並如此反覆進行下去。

一般來說，迭代週期範圍為2~6周。小步驟、快速反饋和調整是迭代開發的主要思想，迭代時間過長會破壞迭代開發的核心動機並增加專案風險。太短時間（比如一周）不足以獲得有意義的產品和反饋。

瀑布模型最失敗的地方是假設軟體規格說明是可預知和穩定的，並且能在專案開始時就正確定義，同時，具有低變更率。----實際這種假設就是錯誤的。任何有專案開發經驗的人都知道：變更對於軟體專案來說是永恆的。

四、敏捷方法及觀點

up提倡風險驅動與客戶驅動相結合的迭代計畫。這意味著早期的迭代目標要能夠識別和降低最高風險，並且能構造客戶最關心的視覺化特性。

風險驅動迭代開發更為明確地包含了以架構為中心迭代開發的實踐，意味著早期迭代要致力於核心架構的構造、測試和穩定。因為沒有穩定的架構就會帶來高風險。

五、敏捷方法及其觀點

敏捷開發通常應用實踐定量和進化式開發、使用自適應計畫、提倡增量交付幷包含其他敏捷性（快速和靈活的響應變更）的價值和實踐。

由於特定實踐的多樣性，因此不可能很精確定義敏捷方法。然而，具備進化式精化的計畫、需求和設計的短時間定量迭代是這些方法所公有的基本實踐。除此之外，它們還倡導反映簡易、輕量、溝通、自組織團隊等更多敏捷性的實踐和原則。

敏捷宣言：

個體和迭代，超越過程和工具

工作的軟體，超越完整的文件

客戶協助，超越合同談判

響應變更，超越履行計畫。

UML和模式應用（2） 迭代 進化和敏捷