UML學習筆記（四）

迭代研發過程：

由四個階段構成，每個階段都包含軟體研發的每個過程：分析、設計、實現和測試階段

四個階段：初始階段、細化階段、構造階段、移交階段

通常在移交階段後進行總體測試、效能測試、使用者培訓等

1.       初始階段：

項目的總體需求、可行性分析等，並確認是否啟動該項目

2.       細化階段：（1/5周期）

啟動該項目後，

（1）、實際要做什嗎？

（2）、怎樣做？

（3）、將採用什麼技術？

風險分析和風險管理

       （1）、需求風險：不能偏離使用者需要，要充分瞭解使用者需求及各需求的相對最佳化程度

                處理需求風險：用例分析技術。列出該系統的任何用例，安排研發人員和客戶交流，以便收集用例。其中要對領域概念性模型作充分說明（行業術語，如電信中的產品）。

         建立領域模型：類圖、活動圖表

       （2）、技術風險：您是否有相關技術經驗，熟悉程度怎樣？

                使用類圖和互動圖來描述構件間的通訊

          使用包圖來描述構件的高層結構

          使用配置圖來描述系統功能的分配

       （3）、技能風險：能否得到相關技術人才或專家？

       （4）、政策風險：是否存在一些政策性因素影響整個項目的進行

細化階段的重要結果之一：建立系統的基準體繫結構

       （1）、用例表：用於描述系統需求

       （2）、領域模型：用於擷取應用領域中的關鍵類的起點，反映您對系統將要提供的業務和服務的理解

       （3）、技術平台：描述重要的實現技術連同技術間的協作和整合

細化階段何時結束：

       （1）、研發人員能給項目估算

       （2）、考慮任何的風險，並定製出相應對策和計劃

計劃：

    1.第一階段：

       用例是定製專案計劃的基chu，對用例進行分類：

       （1）、使用者應當列出用例的優先順序。通常為三級，首先要實現的，短期內能夠沒有，長期內能夠沒有的

       （2）、對於每一個用例，研發人員都應考慮體繫結構風險。三級：高風險，可能的風險，完全不可能的風險

       （3）、研發人員還應評價自己對每個用例研發工作量的做算，稱之為進度風險。三級：確信自己對時間的估算，只能估算到人月，無法估算

       注意：估算應由研發人員估算，專案經理只是評審複核作用。由些研發人員能夠充分理解用例，應估算到人周

       2.第二階段：

       確定每次迭代的研發周期，每次迭代的工作量（迭代次數3至5次）

3.       構造階段

兩個概念：（1）、程式重組：指對程式中和新添功能相關的成分進行適當改造，使其在結構上完全適合新功能的加入。（2）、模式：

構造階段是通過一系列迭代過程建設系統。每次迭代研發都是個小項目，需要對任何需要的用例進行分析、設計、編碼、測試和整合。完成一次迭代後，應向使用者示範，並完成系統測試，以表明所需要的用例已正確實現。

4.       移交階段：

迭代式研發關鍵在於正常化地進行整個研發過程。在移交階段，不能再研發新的功能（除了個別小功能或很基本的以外），而只是集中精力進行錯誤修正工作，最佳化工作。