前言

估算 (Estimation) 在專案規劃初期是非常重要的部份。 在CMMI 模式中的PP專案規劃流程領域 SP 1.2 建立工作產品與工作項目屬性的估計值，提到規模大小( SIZE)是許多模式用來估計工作量、成本及時程的主要輸入。這些估算模式也可根據連結、複雜度及結構做為輸入的基礎。至於SIZE的度量方式包括功能數、功能點、原始碼行數(SLOC)、類別(Class)與物件(Object)數量、需求數、介面的數目與複雜度、文件頁數、輸出及輸入數等。本文將探討功能點分析法（Function Point Analysis）。

功能點分析法（Function Point Analysis）

FPA 最早是在1976年，由IBM工程師Allan Albrecht所提出的方法。具有與開發環境獨立的特性，用以評估專案的生產力與績效。Albrecht發展出的Function Point版本最初提供給 IBM 內部使用，並於1984年發表IBM CIS & A Guideline 313 AD/M Productivity Measurement and Estimate Validation 概念文件 。直到1988年由於使用者眾多而產生了一個非營利的 IFPUG（The International Function Point Users Group）組織的成立，並逐年成長，發展成為目前世界上最大的軟體預估相關機構組織之一。目前最新的版本為IFPUG在 2004年4月發表的Function Point Counting Practice Manual Release 4.2。

功能點分析方法強調由使用者觀點(User View)估算所開發之軟體系統功能性並量化為功能點數，而並不是由技術觀點(Technical View)分析系統之功能。

Function Point 的步驟

第一步驟: 決定欲計算的 Function Point類型

目前 IFPUG標準中將計算功能點之方式依據開發之應用系統特徵專區分為三種：

• 開發型專案（ Development Project）: 開發專案型之功能點數為重新依據使用者需求重新開發符合使用者要求之系統。



• 增修型專案（ Enhancement Project）: 增修專案型的功能點數是指當專案將目前的軟體應用系統加以變動，對現存系統所做的新增、刪除與修改的功能性部分。



• 應用型系統（ Application）: 應用系統類型的功能點數是針對目前已經使用軟體系統，需增加一些功能時計算方式。常被用於維護階段之預估。

第二步驟:決定計算範圍與開發系統之系統邊界

計算範圍為確認使用者之需求功能是否能被計算成為功能點數，也就是判斷使用者的需求可否由功能點分析的五項衡量構面，包括外部輸入(EI)， 外部輸出EO)， 外部查詢(EQ)， 內部檔案(ILF)，外部檔案(EIL) 五種檔案型態所完成並能被計算後需訂出系統邊界 (Boundary)，以使用者觀點指出所需交付之軟體系統與其他外部應用系統或使用者使用領域之分界點。



第三步驟:計算資料功能類(Data Function Type)之複雜度

功能點分析的五項衡量構面又分Data Function Type及Transactional Function Type。內部檔案(IFL)及外部檔案(EIL) 屬於 Data Function type 。系統內部的檔案， 自行維護者稱之為內部檔案 (Internal Logical Files )， 若由其他應用系統維護者， 稱為外部檔案 ( External Interface files )。

『內部檔案 (ILF) 』包括交付之軟體系統之系統邊界內之檔案可以提供使用者設定的控制資訊 (control information)或維護(新增、修改、刪除 )相關資料或檔案能透過外部輸入(EI)控制相關資訊的應用。複雜度是透過計算內部檔案 (ILF)中資料元素 (DET)與記錄元素 (RET)的數量， 經由下圖二複雜度矩陣產生出未調整功能點數 (UFP)。



『外部檔案 (EIF) 』系統邊界外的其他系統所提供，也就是使用系統邊界外資料與系統邊界內溝通之介面，使用外部資料的目的是作為系統邊界內參考使用 ，資料維護由系統邊界外的其他系統執行。此種類型的檔案稱之外部檔案。如同內部檔案 (ILF)的計算其功能點，分析外部介面檔案 (ELF)中資料元素 (DET)與記錄元素(RET)的數目並由下圖三複雜度矩陣產生未調整功能點數 (UFP)。



第四步驟:計算交易功能類(Transactional Function Type)之複雜度

功能點分析的五項衡量構面。外部輸入 (EI)，外部輸出 (EO) 及外部查詢 (EQ)屬於 Transactional Function type。 分述如下 :

『外部輸入 (EI) 』: 外部輸入是一個用來處理系統外部進入資料或控制訊息 (Control information)的基本處理程序，將資料由系統外部進入系統內部為其主要功能。外部輸入的主要功用是更新、維護一或多個內部邏輯檔案 (ILFs)並（或）改變系統的行為 (使用控制資訊執行 )。將外部輸入檔案 (EI)中資料元素 (DET)與參考檔案 (FTR)分析計算個數後由下表三複雜度矩陣得出未調整功能點數(UFP)。



『外部輸出 (EO) 』將系統中衍生的資料 (Derived Data)由系統邊界內傳輸至系統邊外，透過處理邏輯來產生呈現給使用者的資訊，衍生資料為經過處理邏輯中至少必須包含一種數學公式或計算、產生處理過的資料，以及維護一或多個內部邏輯檔案(ILF)並/或改變系統的行為後需呈現給使用者的資訊。將外部輸出檔案 (EO)中資料元素 (DET)與參考檔案 (FTR)分析計算個數後由下表複雜度矩陣得出未調整功能點數 (UFP)。



『外部查詢 (EQ)』: EQ的主要功用是從內部邏輯檔案 (ILF)或是外部介面檔案 (EIF)中讀取資料或控制訊息給使用者，而處理邏輯中不包含數學計算公式與處理過的資料，且不會修改內部邏輯檔案 (ILF)的內容或是改變系統行為之參數資料。一個 EQ包含了輸入端與輸出端元件，經由系統內部取得相關資料並輸出至系統外部。

將外部查詢檔案 (EQ)中所包含之輸入端與輸出端元件中的資料元素 (DET)與參考檔案 (FTR)分析計算個數後由下表五複雜度矩陣得出未調整功能點數 (UFP)。



第五步驟:決定通用系統特徵(GSC)之功能調整因子值(Value Adjustment Factor) 。

開發軟體系統時會因為其系統特性而增減期開發複雜度，系統的複雜度大小會影響開發的時間。因此功能點分析方法提供了 14項通用系統特徵(GSC)，且每一項 GSC影響程度值(Degree Of Influence)的複雜度區分規範，分析人員可以依據 14項通用系統特徵(GSC)選定每一項之影響程度值(DOI)並加總，使用以下公式既可得出功能調整因子Value Adjustment Factor (VAF)。

VAF = 0.65 + 0.01 * TDI

依據複雜度影響值將原系統之未調整之功能點數做出正負 35%的調整 (區間為 0.65 至 1.35)，平均值為 1。

通用系統特徵(GSC)包括下列 14項:

1.資料通訊：使用哪些通訊協定?
2.分散式資料處理：如何處理分散式資料處理?
3.效能：使用者提出需求軟體系統回應之時間(特殊設計)?
4.硬體需求(Heavily Used Configuration)：軟體系統對於硬體的特殊要求?
5.交易頻率(Transaction Rate)：交易執行的頻率為何(每天、每週、每月)?
6.線上資料輸入：資料透過線上輸入的比重為何?
7.終端使者使用之有效性：使用者使用軟體系統之有效性?(使用者友善設計程度)
8.線上更新：有多少的內部邏輯檔案(ILF)檔案能經由線上更新(On-Line Update)?
9.複雜處理：軟體系統的內部是否有更複雜的邏輯處理或統理計算處理?
10.重用能力(Reusability) ：應用系統中的的程式碼被經過特別的設計，發展與支援於其他的應用系統之中?
11.易於安裝性：資料轉換與安裝的複雜度如何?
12.操作容易( Operational Ease )
13.多個站點( Multiple Sites )　
14.容易修改( Facilitate Change )

每一個技術因子給予0～5 的數值，代表該技術因子對系統影響程度，該影響程度如下：

0 :沒有影響
1 :稍微影響
2 :有部分影響
3 :有平均值的影響
4 :有顯著的影響
5 :有很大的影響

將之前的五項衡量構面 (EI、EO、 EQ、ILF、EIF) 計算功能點數 (FPs)，點稱之為 ”未調整之功能點數(UFP)，必須再加入 14項通用系統特徵 (General System Characteristics)之調整因子的影響程度值 (Degree Of Influence)，增加或減少開發系統之複雜度，因為系統之複雜度會影響開發時程與成本。

結論

功能點分析法Function Point Analysis）是用使用者的觀點( User view )來度量軟體功能大小， 因此不受開發團隊與人員能力、 開發流程成熟度、 開發所採用的分析與設計方法、流程模式、 程式語言等因素影響。更可以搭配其他度量值可用來做各種軟體預測或評估模式。但依筆者瞭解使用 FPA 的會遇到以下的問題：

1.初期學習成本高。因為對於 Elementary process 及五項衡量構面的認知需要訓練及不段練習，才能有正確的資料。

2.FPA比較適用於系統分析階段與系統設計階段，但在 Pre sale 時是很難估算，雖然FPA強調使用者的觀點( User view )非技術的關點 (Technical view ) ， 但對初期尚未很詳細了解需求而能正確判斷 ILF， EIF 及 EO， EI， EQ 是有其困難。

3.FPA 計算出來的是全案的SIZE，無法分配或精算出到每一階段或工作項目的 SIZE。對於後續的某些度量如 Coding Productivity ( SIZE/Effort)的計算是有問題的。

筆者希望借由本文的探討與問題的提出，能得到先進與讀者的不同意見，如能針對本文提出的問題提出解決方案，筆者非常樂於交換意見。

參考文件

‧Function Point Counting Practices V4.2
‧SEI “Capability Maturity ModelR Integration (CMMISM)， Version 12