非書評::寫給SA的UML/MDA實務手冊[Roy]

先完整說一下在下目前的經驗。我去年於大陸參與一個小型軟硬體的系統整合專案(基於既有ERP上開發生產回報系統，類似於小型的MES)，負責ERP資料庫分析以及系統功能分析。這是人生第一次執行的系統分析案子，也是目前僅有的一次。

當時不具備完整物件觀念的我，使用了使用案例圖(Use Case Diagram)、活動圖(Activity Diagram)和循序圖(Sequence Diagram)這三種圖型做為與研發小組間溝通的工具。而來自於湖南技術學院的研發小組也並沒有學過UML，我需要與他們大概先溝通一下這幾張UML圖型的意義。但很不幸的，因為我不具備coding能(僅止於教學校作業)，所以對於他們的code我也無從驗證是否與UML的規畫相當。

當然，最後產品是做出來交貨，也成功結案了。案子雖然不完美，但確實讓我看到了UML在溝通上的方便度，特別是循序圖(Sequence Diagram)，無論對上或對下都是很方便的溝通工具。

這本書應該是給有具備完整OO概念(沒有完整OO概念，只能把UML當做是程序式系統分析工具而已)，且有導過少數專案的system analyst newbie看的。

書中，老師基於多年的實務經驗，清楚告訴system analyst應該做些甚麼之外，最重要的是提醒使用者「提問」的技巧。(以前在美商時，看過一本國外寫給dataware house consultant的書，專講user interview，書中列了一大堆情境問答範例，讓consultant確認requirement。)

對於「確認requirement」這件事情，CMMI也僅是這樣表示：用一切可能的方法確認需求。這就代表了「提問」是一門非常重要課題。老師基於多年的經驗，寫出來的模擬情境問答，值得像我這種新手研究，而這是我認為本書最精華的部分之一。

個人認為，如果是完全沒有導過專案的，但想要朝向SA發展的人，不適合直接看此書。因為會完全不知所云，要不就是先去聽老師講過一次[1] ，或者是有不懂的地方寫信問老師，否則新手自己看真的會看不懂，或者是沒有多大的感覺。[2]

這本書另外也是在告訴讀者要：守、破、離！不要死守規則，在時間、人力與資源的有限的專案中，更是如此。挑最重要的做，完成一定要完成的事(不管SA是自己或是團隊的人)。

-----
邱郁惠注：
[1] 廣告一下：180分鐘課程實錄。
[2] 讓我聯想到《與鯊共泳》書中的一句話：老師並不只是幫助您熟悉工作的工具，老師本身便是你的工具之一，不管你從事的是什麼，每個人永遠都需要老師。[p.118]