Function Points and Use Case Points簡介
(一)功能點法(FP)
於1970年代開始研究發展,使用功能點 (FP) 來估算軟體規模,因為軟體開發最主要的工作量是由軟體系統大小(size)來決定。因此界定使用者對功能的需求導出或是推論出軟體的大小。目前由International Function Point User Group (IFPUG)維護此方法論。
功能點法,首要是先要掌握使用者的需求,界定系統的界線,意即如圖一所示。
一旦能界定出應用界限(Application Boundary)之後,就可先行計算出專案軟體開發的工作量,再行考量內含於專案作業的工作量,以及專案管理必須的工作量,即可預估出專案的成本。其流程可簡陳如圖二。
因此使用功能點法最重要的便是要計算出軟體開發直接所需要的工作量,但一般面臨到的最大問題即是專案初始,需求不明確,無法定義出內部邏輯檔案,以及外部介面檔案,更遑論要計算功能點必要還要進一步界定到內部邏輯檔案與外部介面檔案的資料項數(DET, Data Element Type)與紀錄數(RET, Record Element Type)。
(二)使用案例點法(UCP)
使用案例法,就肥蝦有限的瞭解,使用案例點法,重要的是先從界定系統的參與者開始。此處的的參與者為廣義的參與者,意指除使用者之外,也包含如其它的程式介面或資料庫等。接著進一步將系統需求切割為數個使用案例,其實可以反過來說,這一系統是由幾個使用案例構成。再來考量系統所要採用的技術與所在環境的因素,經由調整之後得出軟體的開發成本。其基本觀念肥蝦描述如圖三。
關於UCP的計算,肥蝦試舉一例:
案例:A公司承接了一個產品支援的網際網路開發案。
(1)界定參與者(Actor)-計算UAW(unadjusted actor weights)
參與者 | 參與使用案例數目 | 權重 | UAW |
B | 15 | 2 | 30 |
承包商 | 13 | 2 | 26 |
管理者 | 4 | 2 | 8 |
小計 | | | 64 |
(2)界定系統中使用案例-計算UUCW (unadjusted use case weights)
使用案例 | 難易類型 | 權重 |
登入 | 複雜 | 15 |
支援請求 | 非常複雜 | 20 |
使用者建立 | 一般 | 10 |
支援資源管理 | 簡單 | 5 |
修理通知 | 簡單 | 5 |
小計 | | 55 |
(3)技術因素
因素 | 說明 | 指定數值 | 權重 | 延伸數值 |
T1 | Distributed system | 5 | 3 | 15 |
T2 | Response or throughput performance objectives | 5 | 5 | 25 |
T3 | End-user efficiency | 2 | 1 | 2 |
T4 | Complex internal processing | 3 | 1 | 3 |
T5 | Reusable code | 3 | 2 | 6 |
T6 | Easy to use | 4 | 4 | 16 |
T7 | Includes security features | 2 | 1 | 2 |
T8 | Provides access for third parties | 4 | 2 | 8 |
T9 | Special user training facilities are required | 5 | 2 | 10 |
小計 | | | | 87 |
(4)使用案例點數為
UUCP(unadjusted use case point) = 64 + 55 = 119
UCP = UUCP * TEF = 119 * [ 0.65 + (0.01 *87)]= 180.88
就以上兩種方法,肥蝦以為除了計算點數的困難度之外,對於將點數換算成人月/人日等資源估算的單位,也要仔細估量。此外,使用案例點法並無如功能點法有一國際性組織來規範如何計算點數,因此跨公司、甚至跨專案之使用案例點,並無一個有公信的比較基準。下表為肥蝦就兩者方法間的認知之比較:
方法論 | 國際組織管理 | 對應開發方法 | 困難處 |
功能點法 | 有(IFPUG) | Requirement List | 界定明確的Application Boundary |
使用案例點法 | 無 | Requirement List + Use Case Model | 列示完善的Use Case List |
不管是功能點法或是使用案例點法,明確界定使用者需求為一切的首要,如果需求無法有效掌控,也就只能把誤差值捉大一點囉!畢竟在專案的時間壓力下,多一點準備總比沒準備要好的多了!
沒有留言:
張貼留言