1.1 何謂MDA?
根據Standish Group 的調查顯示，在美國，專案失敗的因素中，有12.8%因為使用者的資訊輸入不足，12.3%對於使用者需求及規格分析不完整，11.8% 起因於需求及規格的改變，這些近四成的失敗因素，都是在需求分析階段可以被避免及控制的，這也間接指出需求分析與管理在軟體開發的重要性。
看來SA 工作是一件繁雜又具挑戰性的工作，如能在一套有系統的方法下展開工作，應可節省不少時間與成本。MDA(Model-Driven Architecture)開發程序，講的是在開發過程將開發程序分為:
| 計算無關模型(Computation Independent Model;CIM) | 對應的開發階段為「客戶需求分析」，聚焦於業務系統及客戶需求，但不涉及系統的細節。 |
| 平台無關模型(Platform Independent Model;PIM) | 對應的開發階段為「系統需求分析」，聚焦於系統的行為，但不涉及與任何特殊技術平台(technology platform)的關係，如EJB，.NET或關聯性資料庫等。 |
| 平台特定模型(Platform Specific Model;PSM) | 對應的開發階段為「系統設計」,結合PIM所擬定的規格來顯示系統將如何在特殊技術平台進行設計，聚焦於系統落實於特定實體平台的技術細節。例如，Spring、EJB2 或.NET 都是一種實體平台。 |
| 實現相關模型（Implementation Specific Model, ISM）。 | 根據一組轉換規則，透過工具將PSM 轉換為可執行的應用系統，或是由人為遵循 PSM 編寫出程式碼。 |
<表一:MDA 說明>
系統分析師執行了前述的CIM與PIM步驟，並且獲得高品質的產出之後，設計師會依據實作平台進一步產出PSM 階段的設計，並交由程式設計師按圖編碼，編寫出適用於特定實體平台的程式碼。本系統分析作業程序，將 CIM 階段分為五個步驟；PIM 階段分為九個步驟，每個步驟都是都以一個任務(Task)的形式呈現，以供所有系統分析人員參考。
這個流程指引框架並不是絶對的，每個專案應依它實際上的須要來進行調適。
但如果試著依照這個流程指引去做，而不是毫無章法，就會離合理的流程更近一些。如果我們同意一致的標準流程，專案進度的測量工作就容易多了。另外需加以說明的是，流程與軟體發展生命週期並不是指同一件事。舉例來說，如果系統開發生命週期採” 瀑布式 (WaterFall)” 開發，本指引的每一個步驟間的關係，都要在前一步驟完成與系統有關的作業後才能住下走，而且每一步驟在整個專案中，理論上只會執行一次。但如果是採 反覆 (Iteration) 與 漸增 (Incremental) 的開發方式，則會以功能來區分，每個功能有如各自獨立的小型瀑布式 (WaterFall)專案，也就是本指引的每一步驟有時會在不同時期由不同功能所採用；有時是不同功能由不同開發小組在同一時期併行開發。
1.2 需求管理與系統分析發展流程圖
依據MDA，本發展指引所提及的步驟及產出，皆歸屬於 CIM 與PIM 階段，並未涉及PSM 及 ISM 階段。
各步驟對應的產出如下：
| 步 驟 | 產 出 |
| CIM-1：定義關鍵人員 | 產出關鍵人員清單。 |
| CIM-2：定義客戶需求 | 產出客戶需求表及非功能性需求表。 |
| CIM-3：定義資料字典 | 產出 Glossary Term List、資料字典列表及類別資料。 |
| CIM-4：定義企業規則 | 產出企業規則列表。 |
| CIM-5：分析業務流程 | 產出業務活動圖。 |
| PIM-1：定義系統範圍 | 產出系統使用案例圖。 |
| PIM-2：定義系統需求 | 產出系統使用案例敘述。 |
| PIM-3：定義內外部介面 | 產出內外部介面表格。 |
| PIM-4：分析領域模型 | 產出分析類別圖。 |
| PIM-5：分析系統流程 | 產出穩健圖。 |
| PIM-6：分析使用者介面 | 產出使用者介面雛型資訊(包含雛型畫面及欄位規則說明)。 |
| PIM-7：定義系統測試規格 | 產出系統測試規格表及系統測試路徑分析圖。 |
| PIM-8：定義系統操作模型 | 產出狀態圖。 |
| PIM-9：定義功能架構圖 | 產出系統選單功能說明表格。 |
<表三:各步驟產出對應表>
根據這個流程，我們可以將 SRS 分成二部份，粉紅色步驟的產出資料，是可以直接拿來與第一線的使用者討論的，因為這幾個步驟的產出是使用者比較容易懂和可以接受的。黃色步驟的產出資料則比較屬於技術性的東西，可做為內部溝通與設計的基礎。當然如果有需要也是可以將所有步驟的產出資料都放進給使用者的 SRS 裡。
沒有留言:
張貼留言