功能點

功能點（），是呈現信息系统提供給使用者功能多寡的「量測單位」。功能點可以用來計算軟體的功能規模度量（，簡稱）。每個單位開發需要的成本（可以用小時或是金錢計算）可以由以往的專案中得知Thomas Cutting, Estimating Lessons Learned in Project Management – Traditional, Retrieved on May 28, 2010。

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

 FiSMA: ISO/IEC 29881:2010 
 : ISO/IEC 20926:2009 
 Mark-II: ISO/IEC 20968:2002 
 Nesma: ISO/IEC 24570:2018 
 : ISO/IEC 19761:2011 
 OMG: ISO/IEC 19515:2019 

上述五項標準是總體標準ISO/IEC 14143的實現。由主導的OMG自動化功能點（AFP）規範，提供了依照的指引自動化計算功能點的標準。不過，目前此標準的實現有一些限制，在沒有預先配置的情形下，無法立刻區分外部輸出（）和外部查詢（）OMG/CISQ Specification "Automated Function Points", February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0。

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

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

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

 和原始碼行數的比較 
原始碼行數（LOC）是最常見估算軟體規模的作法，而提倡功能點的人士認為因為以下的原固，功能點會比原始碼行數要好：
 會有原始碼行數膨脹的風險，若開發者受此影響而讓原始碼行數膨脹，但沒有對應機能的增加，會降低軟體規模估算系統的價值。
 原始碼行數計算對低階的程式語言比較有利，因為需要較多的程式碼才能得到相同的功能Jones, C. and Bonsignour O. The Economics of Software Quality, Addison-Wesley, 2012. pp. 105-109. C. Jones在其著作中有提到一種修正的方式Jones, C.  Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill. June 1996.。
 在開發早期的階段，很難去估算最後提供程式的原始碼行數，因此在開發早期不太適用。而功能點可以從需求中衍生，適用於像之類的方法。

Albrecht在其研究中發現功能點和原始碼行數高度相關Albrecht, A. Software Function, Source Lines of Code, and Development Effort Estimation – A Software Science Validation. 1983.，因此他提出質疑，若有一個更客觀的度量方式（原始碼行數），是否還有功能點的價值。

 後續研究 
針對功能點的缺點，已有許多研究在設法改善，作法包括有強化計數制度Symons, C.R. "Function point analysis: difficulties and improvements." IEEE Transactions on Software Engineering.  January 1988.  pp. 2-111.Hemmstra, F. and Kusters R. "Function point analysis: evaluation of a software cost estimation model."  European Journal of Information Systems.  1991. Vol 1, No 4. pp 229-237.Jeffery, R and Stathis, J. "Specification-based software sizing: An empirical investigation of function metrics."  Proceedings of the Eighteenth Annual Software Engineering Workshop. 1993. p 97-115.Symons, C. Software sizing and estimating: Mk II FPA (Function Point Analysis). John Wiley & Sons, Inc. New York, 1991Demarco, T. "An algorithm for sizing software products." ACM Sigmetrics Performance Evaluation Review.  1984. Volume 12, Issue 2. pp 13-22.Jeffrey, D.R, Low, G.C. and Barnes, M. "A comparison of function point counting techniques." IEEE Transactions on Software Engineering. 1993. Volume 19, Issue 5. pp 529-532.。也有人開發其他方式以迴避其困難點，例如建立代理器來計算所交付的功能Schwartz, Adam. "Using Test Cases To Size Systems: A Case Study." 2012 Ninth International Conference on Information Technology- New Generations. April 2012. pp 242-246.。

 相關條目 
 构造性成本模型（COCOMO）
 軟體開發工作量預估



 原始碼行數


 參考資料 

 外部連結 
 The International Function Point Users Group (IFPUG)

Category:軟體度量