寫給SA的UML/MDA實務手冊
----------
第1章-Why系統分析師需要學習UML
1.2-UML並非萬能
有些系統分析師對UML懷有高度期望,希望採用UML來蒐集及編寫需求之後,可以不再誤解或遺漏需求,或者可以降低需求變動。不難想見,系統分析師經常得面對這些的問題,當然期望學了UML之後,可以一勞永逸地解決掉這些問題。可是UML並非萬能,無法根除這些本質性的問題,不過也不必悲觀,總是有對策可以來處置需求誤解、遺漏或變動的情況。
人跟人的溝通,本來就會產生誤解,更何況使用者與系統分析師的專業背景不同,當然在訪談的過程中,充滿大大小小的誤解,既是在所難免,也就無法避免。再者,人腦並非電腦,談著談著,總是有多多少少的遺漏,無法在區區幾次匆忙的訪談中,明確又清晰地條理分明,這無疑是強人所難。
既然,訪談之中,會有誤解與遺漏,那日後反反覆覆多次地透過電話、電郵、會面來變動需求,或者是經過展示之後,才發現錯誤而變動需求的煩人事件,也就不可抗拒地自然而然地發生了。
雖然,UML無法根除這些本質性的問題,但我們還是有對策可以來面對這樣的現象,試圖減輕系統分析師的工作壓力。對策如下:
1.使用UML圖(Diagram)引導訪談,降低遺漏需求的情況。UML提供10多款不同功能的圖,可以讓系統分析師在訪談過程中,透過多款不同的圖來釐清需求各種不同角度的面貌,降低遺漏。而且,每款圖都有它獨特的組成圖示,在繪製每一個圖示時,都將引導系統分析師提出適時且重要的問題,以便蒐集與釐清需求。
2.快速產出可執行的程式片段,透過展示來突顯誤解。
3.封裝變動,讓需求發生變動時,可以追蹤到變動之處,迅速改版,並且不讓變動起漣漪效應,向外擴散。
所以,在本書裡,我們將要求系統分析師學習多款UML圖,並且在編寫需求時,不僅得產出讓使用者簽字的文件,還得同時產出讓設計師能接續設計的UML圖件。這樣的要求對於系統分析師確實相當為難,但是想要跟使用者確認需求、簽字同意,除了提交使用者能夠看懂的文字(Text)之外,別無選擇。然而,想要滿腦子OO概念的設計師和程式設計師,可以高效率且零誤解地看懂系統分析師產出的需求文件,除了透過具OO概念的UML圖外,目前看來似乎別無它法。
沒有留言:
張貼留言