1. 什麼是功能點分析法（FPA）
功能點分析法，簡稱FPA，與代碼行分析法是近年來最流行的兩種基礎軟件規模估算和度量方法。代碼行估算法側重技術角度，需要一定的基準數據支撐。基準數據越多，估算難度較小。代碼行估算法與實現的技術，計算機語言密切相關。
功能點分析法側重功能，在基準數據缺乏時也能進行，不過估算流程比較複雜。它完全獨立於技術，且可以給用戶量化的概念。
這裏所說的功能點分析法，由Allan J Albrecht首先提出，又稱Albrecht功能點分析法。除此之外，還有Mark II FPA和完全功能點等。但習慣上，人們說的功能點分析法就是Albrecht功能點分析法。
1.1. 功能點分析法的定義
官方文檔IFPUG CPM 4.2.1給出功能點分析法的定義是：Function point analysis is a standard method for measuring software development from the user’s point of view.
具體來說，FPA有這麼幾個特點：
l 它是一種適用於軟件開發的度量方法。
l 它是一種標準的度量方法，由國際功能點用戶組（IFPUG）維護和推動。
l 它從用戶視角來度量產品規模。
l 它不注重產品的內部結構和技術複雜度。不過也並非完全無視這些因素。
FPA標準的維護組織是國際功能點用戶組IFPUG ([url]http://www.ifpug.org[/url])，它不定期的發佈Counting Practices Manual，簡稱CPM來統一不同公司和產品的功能點計算模型。這套模型基於大量已完成項目的分析數據，非常全面和精確。對於同一個產品，不同的公司，不同的人，參照CPM計算出來的功能點數應當是一樣的。目前最新版本是2005的CPM 4.2.1，現在三年未更新，計算模型已相當成熟。
1.2. 功能點的定義
什麼是功能點？就是客戶提出的一條條的需求嗎？答案是否定的。在FPA中，客戶提出的需求，是功能，功能組和產品；但不是功能點。
l 功能點是一個的度量單位，用於度量工作產品的規模。就像公斤和千米一樣，僅僅是一個抽象化的單位。
l 功能點不直接度量軟件的內部架構和技術複雜度。
l 單個功能點對用戶沒有意義，但一個功能包含多少個功能點對用戶有意義。
l 一個系統，一個功能包含多少個功能點，是由一系列可見的要素分析計算得來，而不是拍腦袋的經驗數字。
功能點分爲兩種：未調整功能點和調整功能點。未調整功能點是隻記用戶可見功能的中間結果，調整功能點是最終結果，在未調整後功能點基礎上加入了系統實現和內部架構方面的因素。一般說一個系統包含多少個功能點，是指調整功能點。
1.3. 那些功能是用戶可見的？
簡而匯之，如下功能是用戶可見的。
l GUI，如頁面和窗體。
l 報表。
l 主要文件。
l 參考文件，引用文件。
l 控制文件。
l 數據輸入。
2. 爲什麼使用功能點分析法
FPA可以應用於所有的軟件項目和軟件身，包括新開發項目，升級項目，應用程序，維護項目等。FPA的基本目的有兩個：
l 度量用戶要求和接收到的功能
l 爲軟件的開發和維護而度量其技術獨立度。
2.1. 功能點分析法的用途
軟件度量的用途非常廣泛，從客戶，老闆，管理人員，到程序員，都需要軟件度量數據。FPA作爲一種軟件度量方法，主要有三方面的用途：持續的過程改進，軟件資產管理，項目管理。
2.1.1. 持續的過程改進
FPA支持用於軟件質量分析與生產力分析的量化指標，比如每功能點的平均bug數，每功能點的平均人天數，等等。
分析這些量化指標，可以找到過程改進的機會；可以度量改進的效果。無論是組織還是個人，都需要持續的過程改進。具體來說，FPA可這個過程中發揮如下作用：爲現狀提供基線數據。
1) 爲改進決策提指明方向。
2) 爲具體行動提供指南。
3) 度量改進的結果。
4) 將改進的結果基線化，進入下一輪改進。
可能改進的機會，英語是Improvement Opportunities。這裏的Opportunities用的很好，可惜中文的譯詞“機會”很難讓人理解。習慣上是說“值得改進的地方”。
2.1.2. 軟件資產管理
FPA爲組織的軟件資產提供了量化的指標。
l 軟件資產的總規模
l 軟件資產的增長率
l 軟件資產的維護成本
l 軟件資產的代換成本
對於軟件開發和服務組織，這些指標可爲軟件資產的維護策略提供決策依據：是重新開發，重構系統，重寫代碼但不改結構，還是繼續維護。
對於使用軟件的組織，這些指標可作爲採購的參考：是自行開發，還是採購？採購的合理價格區間，目標採購包的功能符合度。
FPA爲應用軟件之間的功能比較提供了規範化指標。
2.1.3. 項目管理
(1) 估算開發或維護的成本，資源，爲項目計劃提供依據。
(2) 估算需求變更的成本和對項目的影響。
(3) 控制需求範圍。
2.2. 功能點分析法的優點
l 基於定義良好的計算標準。
l 基於客戶視角。容易理解和接受。
l 可應用於新項目，升級項目和維護項目。
l 與技術和計算機語言無關。
l 簡單，易於計算，只需花費較少的工作量。
l 一致的規模度量尺度。可用來比較不同組織和技術之間的比較。
2.3. 功能點分析法的缺點
l 只考慮可見部分的複雜度，對系統內部複雜性考慮太少。
l 功能複雜度三級劃分比較武斷。對一些比較複雜的功能，統計誤差較大。
l FPA知識簡單假設全部是部分的和，沒有考慮系統集成帶來的額外開銷。
在FPA的基礎上，還有一種MARK II 功能點分析法，它能克服一些功能點法的缺陷。
2.4. 功能點分析法的度量描述舉例
(1) 今年我們的生產率提高了20%，從每月10個功能點提高到12個功能點。
(2) 通過質量檢視，我們交付的軟件缺陷率由每功能點2個缺陷，減少到每功能點0.5個缺陷。
(3) 我們的項目進度估算準確率顯著提高，實際人天數和估算人天數的誤差+45%減小到+15% 。
(4) 我們的應用軟件包對相關業務的支持增加了10%，原來是50K功能點，現在是55K功能點.
(5) 由於我們調整了維護策略，工程師人均維護的功能點數從1000提高到1500.從而節省了$3M的成本
(6) 由於提高了客戶需求技術，我們把需求蔓延率從35%降到10%。
(7) 根據功能點分析的結果，我們購買一個軟件包，比自己開發節省了$1M.
3. 功能點分析法與軟件生命週期
功能點分析必須***於作爲軟件生命週期的全部，而不僅僅是項目開發階段。不同階段的功能點分析有不同的目的，參與人員和相關材料。
3.1. 軟件生命週期
FPA將軟件生命週期劃分爲六個階段，與通常意義的軟件生命週期基本相同。只不過有些具體名稱上不同。比如：方案階段又叫概念階段，構建階段又叫實現階段。
| 構建階段 Construction |
| 交付階段 Delivery |
| 維護階段 Maintenance |
| 設計階段 Design |
| 需求階段 Requirement |
| 方案階段 Proposal |
有四個階段應當進行功能點分析：方案階段，需求或設計階段，交付階段，維護階段。每個階段的功能點分析都有不同的目的。
FPA不是某一個人的工作，而是整個團隊的工作。無論哪個階段的FPA，都需要多種角色的參與。主要參與角色有：
l 客戶或客戶代表
l 項目經理
l 系統架構師
l 程序員（方案階段可能沒有程序員）
l 文檔專家：負責整理文檔的苦力。
l 應用方案經理：可能是項目經理，也可能管理好幾個項目經理。
l 應用方案專家：估計Reviewer, 挑刺的傢伙。
l 度量分析員：可能和文檔專家是同一個人。
l 功能點分析專家：一般是QA，主持分析過程。
l 功能點委員會：估計是Reviewer, 挑刺的傢伙。
每次進行FPA時，除了需要相應的項目文檔外，還建議準備好如下FPA的指導文檔：
n IFPUG Counting Practices Manual
n 所在組織的FAP指導文檔。
n FPA分析表。
n 自制一張簡明指南卡：Quick Reference Card。
3.2. 在方案階段估算功能點
在方案階段後期，可以採用FPA方法來估算軟件的規模和項目的開發成本。具體來說有三個目的：
l FPA的過程可協助雙方（用戶和開發人員）把高層需求條理化。
l 得到較爲明朗的項目的範圍。
l 粗略的估算功能點數，並折算爲開發成本和進度。爲制定項目計劃提供依據。
在此階段只有一些非常原始，抽象的客戶需求。所以估算的精度有限。此階段可參考的項目文檔有：
l 高層需求文檔
n 高層系統架構（功能，數據存儲，接口）。
n 高層邏輯數據模型。
n 高層業務模型。
n 業務用例（可選）。
l 歷史項目或應用軟件的功能點統計數據（可選）。
3.3. 需求或設計階段二次估算功能點
在完成需求規格或概要設計時，如發現需求和範圍較之方案階段有較大的變化，估算的功能點不夠精確，可在設計階段的進行二次估算。其目的有三：
l 重新定義客戶需求。
l 重新估算開發進度和成本。
l 度量項目範圍的變更，如需求蔓延率。
實際上，只要項目範圍發生了大的變化，就應當重新估算，最好不要超過三次。在設計完成後，項目範圍已經基線化，如發生需求變更，只需估算變更部分，不要全部推到重來。
二次估算，除了需要初次估算的所有文檔外，還需要如下項目文檔：
l 需求規格。
n 業務用例
n 屏幕界面規劃（Layout）
n 報表規劃（Layout）
n 文件和數據庫規劃（Layout）
n 數據流：系統接收和發出的數據。
l 功能設計，也就是概要設計。
3.4. 交付階段度量最終功能點
交付階段，所有的開發工作都已結束，需求和功能設計自然也就全部凍結。此時應進行最終的實際功能點度量。其目的有四：
l 在交付文件中報告實際的功能點數。
l 度量項目範圍的變更，如需求蔓延率。
l 回顧項目實施情況。
l 發佈統計數據，作爲組織的基線。
度量功能點，需要參考項目的全部需求和設計文檔。同二次估算相比，可能增加了如下文檔：
l 功能設計規格。
l 詳細設計規格。
l 用戶手冊。
3.5. 維護階段度量資產功能點
系統交付後，就會進入公司的IT資產庫。此時需要從資產管理的角度度量一些數據。
l 審計資產功能點。
l 文檔化。
l 確定維護策略。