功能點

功能點是呈現信息系統提供給使用者功能多寡的「量測單位」。功能點可以用來計算軟體的功能規模度量（functional size measurement，簡稱FSM）。每個單位開發需要的成本（可以用小時或是金錢計算）可以由以往的專案中得知^[1]。

標準

有關依功能點度量軟體規模的方式，有幾個受大眾認可的標準或是公開規範。

• FiSMA: ISO/IEC 29881:2010 Information technology – Systems and software engineering – FiSMA 1.1 functional size measurement method.
• IFPUG（英語：IFPUG）: ISO/IEC 20926:2009 Software and systems engineering – Software measurement – IFPUG functional size measurement method.
• Mark-II: ISO/IEC 20968:2002 Software engineering – Ml II Function Point Analysis – Counting Practices Manual
• Nesma: ISO/IEC 24570:2018 Software engineering – Nesma functional size measurement method version 2.3 – Definitions and counting guidelines for the application of Function Point Analysis
• COSMIC（英語：COSMIC functional size measurement）: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.
• OMG: ISO/IEC 19515:2019 Information technology — Object Management Group Automated Function Points (AFP), 1.0

上述五項標準是軟體度量總體標準ISO/IEC 14143的實現^[2]。由軟體品質聯盟（英語：CISQ）主導的OMG自動化功能點（AFP）規範，提供了依照國際功能點用戶群（英語：IFPUG）的指引自動化計算功能點的標準。不過，目前此標準的實現有一些限制，在沒有預先配置的情形下，無法立刻區分外部輸出（External Output）和外部查詢（External Inquiries）^[3]。

簡介

功能點是由IBM的llan J. Albrech於1979年在Measuring Application Development Productivity論文中所定義的^[4]。會先識別軟體功能性使用者需求，將需求分為五類：輸出、查詢、輸入、內部檔案、外部介面。只要識別出功能，並且找到其分類，就可以評估其複雜度，並且給定功能點。每一個功能性使用者需求都可以對應終端用戶的業務功能，例如一個輸入中的資料輸入欄位，或是查詢中的使用者查詢欄位。這個差異很重要，一般比較容易將用功能點度量的功能對應用戶導向的需求，不過其缺點是會忽略同樣需要資源才能實現的內部功能（演算法）。

有關演算法的規模度量

在目前ISO認可的功能規模度量方法中，還沒有在度量中考慮演算法複雜度的方法。目前已有許多不同的作法試圖要考慮演算法複雜度，也已出現在一些商用軟體產品裡，但都還有一些弱點。Albrecht為基礎的IFPUG方法設法要處理這些弱點，其方法包括有:

• 早期和簡單的功能點：用二個問題考量問題和資料的複雜度，不過二個問題是某程度主觀的複雜度量度，去除了資料元素的計算，簡化其量測。
• 工程功能點：計算元素（變數名稱）和運算元（算術、等式或不等式、布林運算）。此變體強調運算功能^[5]。此作法有點類似以運算元和運算子為基礎的霍爾斯特德複雜度量測。
• Bang measure：依12個會影響或是呈現出Bang的初級計數來定義功能度量。Bang的定義是「使用者可以收到或是感受到真正功能的度量」。若是要用軟體單元提供給使用者機能的有用程度來評估軟體單元，Bang measure很適。不過在這方面應用上，文獻的佐證很少。若是在進行（部份或是完整）軟體再造時，可以用Bang measure，正如Maintenance of Operational Systems—An Overview中所述的一樣。
• 特徵點（Feature point）：有進行修改，可以適用在有重大內部處理（例如作業系統、通訊系統）的系統中，可以考慮到一些使用者不一定會感受到，但是在正常運作中必要的功能。
• 加權微功能點（英語：Weighted Micro Function Points）：在2009年的一個版本中有用加權方式調整功能點，加權來自程式流複雜度、運算子和運算元字彙、物件使用量，以及演算法。
• 模糊功能點：在低到中之間的複雜度，以及中到高之間的複雜度中，加入模糊且漸進式的變換^[6]

和原始碼行數的比較

原始碼行數（LOC）是最常見估算軟體規模的作法，而提倡功能點的人士認為因為以下的原固，功能點會比原始碼行數要好：

• 會有原始碼行數膨脹的風險，若開發者受此影響而讓原始碼行數膨脹，但沒有對應機能的增加，會降低軟體規模估算系統的價值。
• 原始碼行數計算對低階的程式語言比較有利，因為需要較多的程式碼才能得到相同的功能^[7] C. Jones在其著作中有提到一種修正的方式^[8]。
• 在開發早期的階段，很難去估算最後提供程式的原始碼行數，因此在開發早期不太適用。而功能點可以從需求中衍生，適用於像estimation by proxy之類的方法。

Albrecht在其研究中發現功能點和原始碼行數高度相關^[9]，因此他提出質疑，若有一個更客觀的度量方式（原始碼行數），是否還有功能點的價值。

後續研究

針對功能點的缺點，已有許多研究在設法改善，作法包括有強化計數制度^{[10][11][12][13][14][15]}。也有人開發其他方式以迴避其困難點，例如建立代理器來計算所交付的功能^[16]。

相關條目

• 構造性成本模型（COCOMO）
• 軟體開發工作量預估
• Mark II方法（英語：MK II FPA）
• 物件點（英語：Object point）
• 軟體規模（英語：Software Sizing）
• 原始碼行數
• 使用案例點（英語：Use Case Points）