背景
衆所周知，軟體系統的複雜性是相當高的，以下幾個場景是比較常見的：
1.作為軟體公司，要研發一個新的産品，功能需求大概明确了，需要确定下研發成本、資源需求等。
2.作為企業，實施軟體系統，需要與軟體廠商商談具體的工期與費用等。
3.作為軟體公司或企業的管理方，需要對多個軟體系統進行橫向對比、衡量與評價等。
以上幾個問題，實際都指向一個核心問題，即如何客觀估算與衡量一個軟體系統的規模。隻有具備了軟體規模的基本資料，與之相關的工作量(人天）、工期、報價、項目成本才能計算。
概述
目前評估軟體規模的方法主要分為兩種：基于技術視角和基于業務視角。
基于技術視角的方法是從開發者角度出發，如：基于軟體源代碼行、資料庫表、函數數量等。
基于業務視角的方法是從使用者角度出發，與軟體開發技術無關，如：功能點、故事點、用例點、對象點等。
基于技術視角的評估方法更多地局限于軟體開發團隊内部，由經驗豐富的技術人員估算，經常也被稱之為專家估算法。這種估算法标準很難量化和達成一緻，不同的人，估算出來的結果可能差異很大，局限性比較大。
如果要在業務部門與開發部門、企業與軟體廠商等外部組織商定軟體開發的工期或費用等關鍵項目目标，客觀上需要從業務視角出發，對軟體項目規模進行衡量、一緻的評價與估算。而且，在系統初始階段，使用者功能需求是唯一真正可以得到的資訊。
基于業務視角來評估軟體規模，國際上有一套方法論，稱之為功能點分析法。該方法論内容不少，本篇對該方法論做一下大概介紹，點到即止，如感興趣建議自行深入了解。
簡介
功能點分析法度量的是軟體的規模，主要從邏輯設計的角度出發對提供給客戶的功能進行量化。
功能點分析方法的主要目标是度量使用者要求和能夠接收到的功能，并提供一種與具體實施方法和技術無關的、對軟體開發和維護進行度量的手段。
此外，功能點分析方法還是一種相對來說比較簡單的對規模進行度量的手段；在不同的項目群組織之間能夠保持一緻的度量方法；基于資料流，使用行業标準資料，是比較客觀的估算，容易得到認同。
功能點分析法，實際不隻一種，用的比較多的是國際功能點使用者組（IFPUG）的标準功能點分析法，這種方法相對複雜一些。荷蘭軟體度量協會（NESMA）提供了兩種簡化後的方法：快速功能點分析法和初步功能點分析法。這三種方法往往結合使用，用在不同的項目階段。需求分析階段，使用快速功能點分析法；系統設計階段，使用初步功能點分析法；系統實施階段，使用标準功能點分析法。
基本概念
功能點分析法将軟體的功能分為五個基本要素：
内部邏輯檔案（Internal Logical Files，簡稱内部檔案ILF）
外部接口檔案(External Interface Files，簡稱外部檔案EIF)
外部輸入(External InPuts，EI)
外部輸出(External Outputs，EO)
外部查詢(External Inquiries，EQ)
以上描述從字面上不太好了解，用大白話來說，業務實體是内部邏輯檔案（ILF），外部系統接口是外部接口檔案（EIF），對業務實體的新增、删除、修改是外部輸入（EI），對業務實體的查詢是外部查詢（EQ），對外提供接口或報表，是外部輸出（EO）。
内部邏輯檔案（ILF）和外部接口檔案（EIF）是靜态的資料；外部輸入（EI）、外部輸出（EO）和外部查詢（EQ）是運動中的資料。
以下是具體的識别要素，供參考。
内部邏輯檔案（ILF）
- ILF 指在待開發系統内部邏輯上的、使用者可識别的一組資料
- 對單個ILF 一般執行6 種左右的操作，且一定包含寫操作
- 資料集合必須是邏輯相關的并且是使用者可以識别的
- 資料或者控制資訊必須是在本應用的邊界内被維護
外部接口檔案（EIF）
- 這一組資料或者控制資訊必須是在本應用内被引用，但并非是在本應用邊界範圍之内的
- 這一組資料或者控制資訊的維護工作不是在本應用内進行的
- 這一組資料或者控制資訊是另一個應用的ILF
外部輸入（EI）
- 是獲得資料的過程，對終端使用者的輸入進行相關的處理
- 對内部資料的增/删/改均為EI
- 從外部接口中讀取并存儲到内部資料中
- 接受某個控制信号并使軟體狀态改變
外部輸出（EO）
- 輸送資料到應用程式邊界外部的過程
- 處理過程必須包含至少一個數學公式或計算方法，或生成派生資料
- 對内部資料的複雜報表（含計算内容）/統計分析等
- 一個EO也可以維護一個或多個ILF，并/或改變系統行為
外部查詢（EQ）
- 向應用程式邊界外發送資料基本處理的過程
- 從ILF或EIF中通過恢複資料資訊來向使用者呈現
- 該處理邏輯不包括任何數學公式或計算方法（但可以分組或排序），也不會生成任何派生資料
- EQ不會維護任何一個ILF，也不會改變應用程式的系統行為
計算方法
快速功能點法（2點法）
根據立項前期的需求分析及可研報告内容，确定計算範圍、劃定應用程式的邊界；對項目中涉及到的内部檔案（ILF）、外部檔案（EIF）的數量進行評估；對ILF和EIF分别與一個權重因子相乘，計算出功能點數。
FP = ∑(35 * ILF + 15 * EIF)
即1個業務實體算35個功能點，1個外部資料接口算15個功能點，累加求和即可，非常簡單，因為是粗略估算，誤差也可能比較大。
初步功能點法（5點法）
設計階段的軟體開發工作量估算可采用初步功能點法，依據确定的内部檔案（ILF）、外部檔案（EIF）、使用者輸入（EI）、使用者輸出（EO）、使用者查詢（EQ）的個數來計算。
•FP = ∑(15 * ILF + 10 * EIF + 4 * EI + 5 * EO + 4 * EQ)
納入了五要素，給予了不同的權重，比快速功能點法的進了一步，評估工作量變大，評估結果通常更準确一些。
标準功能點法
相比前面兩種方法，标準功能點法引入了更多的控制因子來處理差異性，進行更細顆粒度的衡量，以求更準确的衡量和評估。
首先，不同業務實體的屬性數量是有差異的，一個8個屬性的實體，和一個35個屬性的實體，直覺上就可以判斷出來開發工作量是有差異的。針對這種情況，标準功能點引入了功能複雜度來計算權重因子。功能複雜度按照高(H) 、平均(A) 或低(L)進行劃分。功能複雜度高、中、低分别對應不同的功能單元權重因子取值，也就是功能點個數值。
| 功能單元類型 | 功能複雜度 | ||
|---|---|---|---|
| 低（L） | 平均（A） | 高（H） | |
| 内部邏輯檔案(ILF) | 7 | 10 | 15 |
| 外部接口檔案(EIF) | 5 | 7 | 10 |
| 外部輸入(EI) | 3 | 4 | 6 |
| 外部輸出(EO) | 4 | 5 | 7 |
| 外部查詢(EQ) | 3 | 4 | 6 |
上表中的中位值，實際就對應着初步功能點估算法的權重值FP = ∑(15 * ILF + 10 * EIF + 4 * EI + 5 * EO + 4 * EQ)，是以初步功能點法就是放大了評估的粒度，降低估算的工作量。
至于如何具體評估某一個功能的功能複雜度，應該是低、中還是高，标準功能點法同樣提供了一個參考标準，引入了DET（可簡單了解為字段數量）和RET（可簡單了解為表數量），以下是示例，不做詳細展開。
其次，不同的需求，對系統要求是有差異的，例如有的系統對性能要求很高，有的系統對易用性有一定要求，這些因素同樣會影響到系統實作的難度。标準功能點法，通過調整因子來處理差異性。
标準功能點法抽象出14個通用系統特性，具體如下：
- 資料通信：描述軟體直接同處理器進行通信的程度；
- 分布式資料處理：描述軟體的各部件間資料傳輸的程度；
- 性能：描述響應時間和資料吞吐量對軟體研制的影響程度；
- 系統配置要求：描述計算機資源限制對軟體研制的影響程度；
- 事務率：描述事務處理率對軟體研制的影響程度；
- 線上資料輸入：描述通過互動處理輸入資料的程度；
- 最終使用者效率：描述對各種人為因素和最終使用者易用性的考慮程度；
- 線上更新： 描述内部邏輯檔案被線上更新的程度；
- 複雜處理：描述，處理邏輯對軟體研制的影響程度；
- 可重用性：描述經過專門設計、開發和支援的軟體，可在其他軟體中重用的程度；
- 易安裝性：描述軟體在不同環境下轉換和安裝操作的簡便程度；
- 易操作性：描述軟體在操作方面的滿足程度，如:啟動、備份和恢複過程；
- 多工作場所：描述軟體用于多個使用者組織、多種場所的程度；
- 易變更性：描述軟體的資料結構和處理邏輯易于修改的程度；
每一個特性都有一些規則來進行評分，以判斷該特性對這個應用的影響程度。評分的範圍是從0到5，分别代表沒有影響到影響很大。
以性能參數為例：
| 描述 | 分數 |
|---|---|
| 使用者沒有提出性能方面的要求 | |
| 使用者提出了性能和設計方面的要求，但不需要采取特定措施 | 1 |
| 響應時間和吞吐量在系統峰值時是關鍵的，但是不需要采取相應的CPU 使用方面的特殊設計。處理的最後期限是在下一個工作日。 | 2 |
| 在任何時候響應時間和吞吐量都是關鍵的，但是不需要采取相應的CPU 使用方面的特殊設計。處理的完成期限比較嚴格 | 3 |
| 除了上面一項的要求外，由于對需求的要求比較嚴格，在設計階段就要進行性能分析 | 4 |
| 除了上面一項的要求之外，在設計和實施階段需要使用性能分析工具來判斷性能要求的完成情況 | 5 |
标準功能點法，評估每一個通用系統特性，并且為它們确定影響程度（Degree of influence - DI），然後将所有通用系統特性的DI 相加，得到整體影響程度（Total Degree of Influence - TDI），最後代入公式VAF（調整因子）=0.65+0.01×TDI。
通過公式可以得知，該系數會在正負35%的幅度上調整功能點數。
假設未經過調整因子計算前的功能點數是100，走兩個極端情況，14個通用系統屬性，打分都是0或者都是5，則調整後的功能點數，分别為65和135，即項目規模可能相差1倍。
延伸計算
如開篇所說，我們最終的關注點，往往不是項目規模，而是工作量、成本、工期等，而項目規模是其計算基礎。現在，我們通過功能點法得到了功能點數量，怎麼來進行後續計算呢？這裡僅以工作量為例，其他計算類似，不再贅述。
隻要稍微深入思考下，我們再拿到每個功能點需要花費的工時，則二者相乘就能算出來，該軟體系統需要多少工時。每個功能點需要花費的工時，資料從哪裡來呢？如果是軟體公司，在長期踐行功能點法這套方法論，那麼通常會有公司自己的經驗資料來支撐。如果是沒有積累的軟體公司，或者企業與軟體廠商之間商談軟體系統實施工作量時，這時候就需要一個相對客觀權威的資料做為計算依據。這裡推薦《中國軟體行業基準資料報告》，最新一版是2022年9月1日釋出，下圖是統計結果。
該報告同時提供了可以進行延伸計算的多項基礎資料，如分行業生産率、維護型生産率、缺陷密度（缺陷數/功能點）、工作量分布（需求、設計、建構、測試、實施占比）、部分城市人員費率、功能點單價等。
優缺點
前面說了功能點分析法的不少優點，最後總結下，同時，也提一下其缺點。
優點
基于定義良好的計算标準。
基于客戶視角，容易了解和接受。
可應用于新項目，更新項目和維護項目。
與技術和計算機語言無關。
簡單，易于計算，隻需花費較少的工作量。
一緻的規模度量尺度。可用來比較不同組織和技術之間的比較。
缺點
隻考慮可見部分的複雜度，對系統内部複雜性考慮太少。
功能複雜度三級劃分比較粗，對一些比較複雜的功能，統計誤差較大。
總結
功能點分析法是一套優秀的評估項目規模的方法論，特别是從業務視角出發，與技術，特别是開發語言無關。基于該方法論評估軟體規模，如果軟體廠商有自己的成熟的開發平台，能大幅提升開發效率，或有成熟産品進行二次開發定制，則能大幅降低自己的成本，在市場競争占據優勢。