|
原理
Function Point Estimation 功能點估算是一種用來估算項目大小的技術。
功能點是對軟件功能和規模的間接定量測量，它基於客觀的外部應用接口和主觀的內部應用複雜度以及總體的性能特徵。
功能點法和專家法估算最大的不同點在於對估算規模的細化的定量分析上面．我們在用專家法估算的時候往往會直接去估算工作量，或在規模的估算中摻雜了生產率的數據，導致估算數據出現問題．專家法估算雖然有時候也很準確，但不能提升爲組織級可以參考和借鑑的同樣規則．其實專家法的估算要做準確也是遵循了功能點法估算的思路，在考慮一個軟件功能究竟涉及到哪些操作，涉及到多少數據文件的存在，每個操作需要訪問哪些數據文件等相關問題．只是這些想法停留在專家頭腦裏面而沒有量化出來．
我們的預測，分析和決策能力要提升，就必須對我們的經驗進行模型化和定量分析．功能點法正好就起到了這個作用．其實功能點發也有不完善的地方，這可以根據我們項目實際的使用情況去不斷的改進．
功能點發進行估算的時候具體過程是：
1.對估算功能單元的類型進行識別
2.計算每種類型的複雜度．
3.計算總體的調整前的功能點數
4.根據調整因子對功能點數進行調整
功能點估算中有5種信息域需要進行描述：其中事務類的有EI,EO和EQ，數據存儲類有ILF和EIF.
外部輸入(EI):通過界面等的輸入，插入更新等操作都是典型外部輸入
外部輸出(EO):僅僅輸出，入導出，報表，打印等輸出
外部查詢(EQ):先要輸入數據，在根據輸入數據計算輸出，如查詢
內部邏輯文件(ILF):可以理解爲業務對象，可能對應多個數據表
外部接口文件(EIF):其它應用提供的接口數據
A.對事務類功能點的估算：
對事務類的功能點估算需要確定DET和FTR兩個指標：
DET:可以理解爲界面的錄入具體數據項，按鈕也要作爲數據項
FTR:事務功能需要操作的數據文件的數目
對EI的複雜度的計算：
![]()
對EO和EQ複雜度的計算：
![]()
B.對數據存儲類功能點的估算
對數據存儲類功能點的估算需要確定DET和RET兩個指標
DET:具體數據存儲文件的數據項的數目
RET:數據文件是複合文件時候關聯或引用的個數．如訂單數據文件由於存在訂單頭和明細關聯引用,RET應該算2.
對ILF和EIF複雜度的計算：
![]()
信息域數據估算完成後可以開始考慮調整因子：
調整因子是一種補償機制，即通過五個信息域和複雜度都還沒有辦法考慮到的因素就應該做爲調整因子．如同樣一個軟件系統一種是系統要支持分佈式和自動更新，而另一種是不考慮這種需求，如果不考慮調整因子這兩者的規模是一樣的，但很明細第一種情況複雜度和規模都會更大些．
![]()
有了調整因子後最終可以得到調整後的功能點數:
AFP(調整後功能點)= UFP (未調整功能點數目)* AF (影響因子)
實例
需求：實現一個訂單的錄入，更新，刪除和查詢功能．訂單信息是指一個用戶訂購的公司產品的情況．其中訂單頭包含了具體的類型，訂購時間，發運地址，客戶名稱等信息．訂單明細包含了訂購的具體產品的數量的情況．
假設：
1.用戶表和產品數據表已經建立，本次訂單功能開發僅僅是引用和取這些數據．
2.暫不考慮其它特殊業務邏輯和權限
功能界面情況：
![]()
![]()
STEP1:計算出EI,EO和EQ事務功能
舉例：對於訂單保存功能，項目自我約定對於組合框DET算2,對於GRID的DET算3.其餘界面控件DET都算1,所以可以數出DET數目爲15.再來考慮FTR數目，這裏需要操作訂單數據文件，客戶數據文件和產品數據文件FTR數應該算3.
STEP2:計算出ILF和EIF事務功能
1.這裏訂單文件只算一個DET，但後臺數據表會涉及到兩個數據表．由於訂單頭和訂單明細有關聯關係，所以這裏RET取2.
2.客戶文件和產品文件雖然不是外部系統文件，但本次開發的功能並不需要再去設計該數據文件和數據表，所以這裏把其作爲EIF來處理．
STEP3:根據對應表計算各個信息域複雜度的情況．
最終的估算情況如下：
![]()
最終的未調整的功能點數目爲:61
調整因子在這裏不再舉例說明了,如項目調整因子爲1.08，則最終功能點數爲：
AFP = 61*1.08 = 66.
還有些沒有細化考慮的，如具體的DET數量的計算規則等，還請指正．
|
