我目前職務是以寫程式為主，有過一些做SA/SD的經驗，之前做SA/SD使用UML的專案經驗都是依循著別人訂好的規範去進行，算是以文件為主，確認需求為輔。因為種種原因，未來想系統分析甚至專案管理的方向發展，為了這一目的，學習方向就比較偏系統分析的東西，自己也有做一些練習，我對之前專案經驗中與自己練習的UML用法都感到有問題，但我並不知道該怎麼解決問題，也不知道該怎麼做才是對的。我最近看了「SA前進UML專案現場」，這本書解決了一些我覺得有問題的地方。以下是我對這本書的心得感想：
我這本書並非在教正規的UML或RUP用法，而是在敘述怎麼在專案實務上使用UML。如果是為了在那種很重視文件的專案中使用UML，我想這本書的幫助並不大。但如果是做系統分析想把需求弄清楚，但又不知道怎麼做，那我想這本書的內容是值得看的。
這本書採用以下項目作為來源進行系統分析：
1.業務流程
2.功能架構
3.DDD(domain driven design)
關於功能架構的部分，我第一次看到有書或文章把這跟UML關聯在一起，但在實務上這是很可能遇到的情況。
對於DDD，我之前是有看過些文章，但其實我一直搞不太懂，這本書對DDD的描述有可能不太正規，但用法解決了一個困惑我好幾年的問題，之後我可能會再多找找DDD的文章或書籍做些了解。
這本書雖然是為了專案實務而寫，但並不一定適合實務上的使用。原因可以說有很多個，其中一部分書中也有提到，就是專案時程時常很趕。要我說的話，系統分析的相關角色也未必能配合，比如文件寫好了，該懂業務邏輯的業務單位就只說他看不懂或者沒時間看，就算SA文件的業務邏輯有問題也沒法發現，最後出問題就是推卸了。換另一種說法，不適合實務的原因也可以說只有一個，就是人的問題。但我絕對不是批評這本書不好，因為任何方法只要遇到人的問題，很容易就完蛋，而且是等於無解的完蛋。
一般我看書常常都會一頁看過一遍就過去了，有時可能這樣翻過一遍後過很久再翻一遍看，這本書有些章節我是翻了好幾遍看，不然無法理解，但我覺得還挺值得我花時間這樣看。
留言列表
