論 SA/SD 的角色與定位

我常在許多軟體公司與專案經理們討論軟體人員的職掌時，發現到，耶？ 怎麼我所認知的 SA/SD 與他們實際的工作內容大大不同。嗯，所以我想就針對 SA/SD 來給個正名與定位吧。

SA, 系統分析師(System Analyst)，是對設計中(Under Design)的系統來作分析，既然是分析，那麼，應該是需要 "剖開" 系統內容，來對其系統內部的結構組成元素，以分析其脈絡。所以我覺得系統分析師，也可以稱之為 "結構分析師(Structure Analyst)。

系統分析師的工作，是著重在系統的內部，應該是要能找出與描述系統組成結構的靜態(Static)元素，並利用元素，動態組合以滿足系統外部的功能 需求。也就是說，靜態面的結構元素，與功能面的行為(Behavior)描述，均是屬於系統分析師的範疇。幾個主要的產出，包括類別(Class)圖、循 序(Sequence)圖、資料庫的 E-R(Entity-Relationship)圖，是 SA 所該負責的，而且，上述的產出是偏向於建立領域概念的模型(Domain Conceptual Model)，並非為與平台相依的軟體規格模型(Software Specification Model)，與平台相依的軟體模型，是屬於 SD(System Designer) 的範疇。

而一般軟體公司對 SA 的定位，是在於對客戶端操作者(Operator)與領域專家(Domain Expert)的需求訪談。但是，需求面是屬於系統外部的功能面觀點，我一直不認為這是屬於 SA 的工作，正確地來說，這應該是 "需求分析師(RA, Requirement Analyst)" 的範疇。

有趣的是，我發現到，一般對 SA 的要求，還需要包括對使用者介面(User Interface)的設計，為何會需要 UI 的設計？ 我想應該是與 SA 訪談的對象，都比較偏於層級比較低的終端操作者，而這些操作者，會很重視 UI 的操作，卻很少能正確地說明系統真正要的功能，往往都是以局部操作者的角度來看待系統。

我發現到，一般軟體公司對 SA 的角色定位太過模糊，以致於 SA 根本就搞不清楚他們要做的是到底是屬於系統外面的工作，還是屬於系統內部的工作。如果能正確地將系統外部的需求分析與系統內部的結構分析作區分，需求分析 由 RA 負責；結構分析由 SA 負責。如此，才能界定與釐清系統內與外的工作。

至於 SD，系統設計師(System Designer)，焦點仍就於系統內部的結構，與 SA 所不同的是，SA 所建構的是屬於偏向於領域的概念模型；而 SD 則是根據領域模型，再配合實體的平台，如 .NET or J2EE的框架(Framework)，考量其效能、穩定、分散與安全性等，所建構而得的軟體規格模型。SD 的主要產出，仍包括了類別圖、循序圖以及 Database Schema，而這些產出，都會與實體的平台相依。例如，具化的軟體模型是以 J2EE 來實做，而就永續層(Persistent Layer)設計考量，SD 是以 Hibernate Framework 來實做，以橋接領域物件與資料庫的永續儲存。

不過，軟體公司對 SD 的定位，反而僅在於對資料庫 Schema 的設計。其實呢，對於 E-R 與 DB Schema，也並沒有相對切分邏輯(Logical)與實體(Physical)的層次(Layer)。邏輯與實體之分，簡單的說，實體的 DB Schema 會考量到與現實所使用的資料庫系統的特性相關，諸如欄位資料型別的定義、Index and Constraint 的設計等...。

一個基本的結論，系統外部的功能性需求分析，係由 RA 所負責。而系統內部的分析與設計，是交由 SA 與 SD 來負責的，而 SA 與 SD 的界限，可以以是否有與實體的平台相依來界定。我們也可以以兩句話來說明分析與設計的關係：

“Do the right thing (分析)”and “Do the thing right (設計)”。