Function Points and Use Case Points簡介

本週「軟體專案管理實務」志中師弟所報告的【5.5軟體成本的估算方法】，書本中雖然列舉了專家判斷法、類比法、參數模式、功能點分析法、理論模式。但肥蝦以為，現行臺灣業界估算軟體的方法，應該還是以所謂的專家判斷法－老闆就是專家－為多，就算專案經理或者專案辦公室有著十八般武藝，到最後就是要呼應：「老闆是對的，老闆萬歲！」現今大多的專案，都是主事者先概估一下專案的複雜程度，以及所需要產生的畫面與報表數量，進而換算為天數，人天的價格先以軟協建議價格計算，再來跟甲方討價還價。具有規模的公司，或者(為)通過CMMI的公司，在Level 2中就必須導入或使用有一個業界間所認可的方法，如功能點法。但為了搶標，一開始要依據RFP的內容去估算成本，只怕還沒估算完個大概，投標截止日就過了。唉~~手拿著關刀，騎坐木馬，過五關！

因為肥蝦先前上過前精誠資訊專案管理辦公室資深協理李克精先生的快速功能點法(FFPA)課程，因此對於功能點法與快速功能點法有一個初淺的認識。至於使用案例點法，倒是曾經遇到一位顧問對肥蝦說了個大概，肥蝦自己胡亂找了些資料讀讀，因此對於使用案例點法的瞭解更是不足。但為了繳交課堂報告，肥蝦只好厚顏無齒的試著去分別概述兩者的基本觀念與差異，還請  各位前輩多多指教！

(一)功能點法(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)

(2)界定系統中使用案例-計算UUCW (unadjusted use case weights)

(3)技術因素

(4)使用案例點數為

UUCP(unadjusted use case point) = 64 + 55 = 119

UCP = UUCP * TEF = 119 * [ 0.65 + (0.01 *87)]= 180.88

就以上兩種方法，肥蝦以為除了計算點數的困難度之外，對於將點數換算成人月/人日等資源估算的單位，也要仔細估量。此外，使用案例點法並無如功能點法有一國際性組織來規範如何計算點數，因此跨公司、甚至跨專案之使用案例點，並無一個有公信的比較基準。下表為肥蝦就兩者方法間的認知之比較：

不管是功能點法或是使用案例點法，明確界定使用者需求為一切的首要，如果需求無法有效掌控，也就只能把誤差值捉大一點囉！畢竟在專案的時間壓力下，多一點準備總比沒準備要好的多了！