台灣最具影響力的-資訊專家社群 - 讓您成為最有價值的IT專業人才
線上人數
815
 
會員總數:230680
接案會員:6774
文章總數:2320
討論主題:176469
歡迎您免費加入會員
討論區列表 >> 軟體專案管理 >> 建立使用案例模型的 80/20 法則

[變換順序]
[我要回覆]


回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
建立使用案例模型的 80/20 法則
價值 : 10 QP  點閱數:2452 回應數:0

點圖分享到Plurk吧!
樓主

寸心千里
初學者
20 132
874 4
發送站內信

使用案例模型(Use Case Model)係由 使用案例圖(Use Case Diagram) + 使用案例敘述(Use Case Description) 所組成的。任何事物,若是運用 80/20 法則,將主要精力集中於 20% 的重點上,可以節省及避免耗費太多的精力於錯誤的細節上。

一開始,先利用使用案例圖,找出最接近本質性(Essential)的元素:使用案例(橢圓型圖示)、參與者(棒形人偶圖示)及系統範圍(套件圖示)。

一開始就做對的事情,免得因太早落入細節的使用案例描述,結果回頭才發現團隊對系統範圍、目的等有見解上的分歧,而耗費太多不必要的精力與時間。

對系統全貌有了共識,再由需求分析師針對使用案例來描述參與者與系統之間溝通的對話。需求分析師最重要的一個心態,在於描述對話的過程期間,謹記要把系統當黑盒子,只能看到系統的外觀。如此才能避免不知不覺會描述到系統內部的實做細節。

仍然利用 80/20 法則,先利用散文、簡潔易讀的文筆來書寫使用案例敘述,專心把最常發生(most of time)的情景描述下來,成為使用案例敘述內的基本事件流程(Basic course of event)。

凡事總有例外(Exception)及意外(Accident)發生,最重要、必須防範處理的例外,需要有相對應的措施處理。將許多必要的例外情況記錄在使用案例敘述的替代(alternative)及例外處理的流程欄位上。

可以想得到而先採取防範措施的情況,稱之為 "例外";而完全無法預料的,稱之為 "意外"。不要也不可能想要窮盡紀錄所有的例外情節,因為,總是會有意想不到的 "意外" 發生。反而,在無常的情況中,如何讓系統有 "應變" 的能力,這會比較重要。

有了表達全貌的使用案例圖、一份簡潔易讀的使用案例敘述,需求分析師的工作暫時告一段落,由系統分析師接手,來負責實現(Realize)該使用案例。

實現(Realize)使用案例就是代表了要開始做系統內部的結構分析與設計。此時系統分析師的角色,會很像電影導演的角色,要安排劇本,找適當的演員來演一齣戲(Use Case)。這又是另外一段故事了...

基本的心得,建立使用案例模型,從低精確度逐漸地至高精密的細節,在階段過程中,用最少的精力,找出最重要的精華與本質,一開始把焦點集中在對的目標(Goal)上,勝過於忙忙碌碌,結果花在太多沒有必要的工作上。

* 建立使用案例圖—界定系統範圍、找出參與者、找出使用案例
* 利用自然語言記錄使用案例敘述—將系統當黑盒子,描述參與者與系統之間的操作對話過程。關心的是,系統 "做什麼(What to do)"
* 實現(Realize)使用案例。開始探討系統要 "如何做(how to do)"


=$∼寸心千里∼$=
= msn: kenming.wang@msa.hinet.net
= blog: http://www.kenming.idv.tw/
= 軟體設計討論: http://www.hsdc.com.tw/
本篇文章發表於2005-04-11 23:46
= 寸心千里=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
什麼是iT Power資訊報 新手會員瞧一瞧
目前尚無任何回覆
[變換順序]
 

回覆
如要回應,請先登入.