2、 它是大規模復用的有效基礎。
通過明確闡述它們之間的主要構件和關鍵接口,構架為您決定重復使用提供依據，包括內部復用（確定公用的部分）和外部復用（并入現成的構件）。它還允許更大規模上的復用：構架本身的復用，用于處理同一領域中的不同功能。
3、 構架還可作為項目管理的基礎。
項目計劃和人員配備是根據主要構件的類別組織進行的�；镜慕Y構決策是由一個人員組成相對固定的構架小組作出的，他們不是分散的。而開發活動則被分配給若干個小組，每個小組負責開發系統的一個或若干個部分。
三、 迭代和遞增的開發
迭代式方法一般要優于線性或瀑布式方法，其原因很多。
1、 允許變更需求。需求有時會變化，這常常給項目帶來麻煩，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。
2、 逐步集成元素。在迭代式方法中，集成可以說是連續不斷的。過去在項目結束時要占到整個項目工作量的那段較長的、不確定的且棘手的時期，現在分散到六至九個集成部分中，每一部分要集成的元素都比過去少得多。
3、 及早降低風險。因為風險一般只有在集成階段才能發現或得到處理。在初期迭代時，檢查所有的核心工作流程，對項目使用的工具、市售軟件及人員技能等許多方面進行磨合。過去認定的風險可能被證明不再是風險，而又可能出現一批新的未曾懷疑過的風險。
4、 有助于組織學習和提高。團隊成員有機會在整個生命周期中邊做邊學，各顯其能。測試員可以早一些開始測試，技術文檔編寫員可及早開始編寫，其他人也是如此。如果是非迭代式開發，這些人在初期只能制定計劃或培訓技能，空等著開始他們的工作。培訓需求等也可在評估復審中盡早提出。
5、 提高復用性。因為分部分設計或實施比起預先確定所有共性更容易確定公用部分。確定和開發可重復使用的部分并非易事。早期迭代中的設計復審可使構架設計師確定毋庸置疑的潛在復用部分，并在以后的迭代中開發和完善這些公用代碼。
6、 生成性能更強壯的產品。因為在多次迭代中您總是不斷地糾正錯誤。在產品脫離先啟階段后的初期迭代中仍然可以發現缺陷。性能上的瓶頸可以盡早發現并處理，而不象在交付前夕，此時已來不及處理。
7、 容許產品進行戰術改變。例如同現有的同類產品競爭�？梢詻Q定采用搶先競爭對手一步的方法，提前發布一個功能簡化的產品，或者采用其他廠商的已有技術。
8、 迭代流程自身可在進行過程中得到改進和精煉。一次迭代結束時的評估不僅要從產品和進度的角度來考察項目的情況，而且還要分析組織和流程本身有什么待改進之處，以便在下次迭代中更好地完成任務。
通常在軟件開發過程中，迭代在數量、持續時間和目標上都是按計劃進行的。參與者的任務和職責都已確定好。對進度進行的目標評測都將記錄備查。從一次迭代到下一次迭代確實會存在返工現象，但返工也是嚴格按規定進行的。
四、 使用不當的問題
很多企業員工在使用UML的過程中，只是進行了領域建模，沒有進行用例建模，這樣是不能最大可能地發揮UML的優勢的，因為該組織的軟件開發過程不是用例驅動的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
