[Software] Function Point Analysis

好像很久沒有寫一些正經一點的東西，今天有空就寫一篇吧。

前陣子因為工作上的需求，試著找了一些衡量軟體生產力的方法，希望可以透過這些方法，盡可能的將軟體工程師的工作生產力，做一個可量化以衡量的方法。

其實在軟體業界待過一陣子，就可以知道要衡量軟體的生產力，並不像是硬體代工生產一樣，反正生產出幾台就是幾台。不過雖然難以衡量，但是還是可以看到大家一直試圖的想要透過各種不同的方式，來將軟體開發做量化。

寫程式最常可以聽到的衡量生產力的方式，可以從多個面向來討論，不外乎SLOC(Source Line of Code)、functions/classes數量、defect density(也就是寫多少行的code，造成了多少的bug)、code coverage、test case數量…等等，都是可以衡量一部份的軟體生產力。在這當中，有些指標有著致命的缺點，就像SLOC，寫的code多不代表生產力高，有時候一段好的code，反而是寫的簡單而且更有效率的。

在一個因緣際會的情況之下，我們知道了Function Point Analysis(FPA)這個衡量軟體規模的方法。這個方法是在1979年，由當時在IBM的Allan Albrecht寫的一篇論文 – “A New Way of Looking at Tools”，主要是根據一般使用者的角度，分成Input/Output/Inquiries/Internal Interface/External Interface五個分類，逐一將軟體功能分類。分類完之後，再進行評估跟計算，算出軟體的功能點數，利用這樣的結果來估算軟體的大小規模跟難易度。

估算出軟體的大小規模跟難易度之後，再搭配上所付出的人力，也就變成了估算軟體產出的KPI。藉由觀察KPI的變化，也可以了解到軟體開發者的生產力變化，並根據變化決定是否要採取相對應的行動。

不過這樣的方法也只是一種參考的做法，並無法套用到所有的軟體領域內，例如對於估算改善軟體performance的時候，這個做法就不適用。再者估算先前提到的功能點數，必須要有一定訓練跟評估經驗的人，才有辦法做的比較仔細跟明確。在評估的過程當中，也夾雜了一點人為的主觀判定，並不一定百分之百的客觀。

雖然各種的方法上，不一定能夠精準衡量，也無法一以貫之，但是最少還是可以衡量出一些具某種代表性的數字。雖然沒辦法做到完美，但是至少也可以有一定的及格分數。