橫軸 Tab 選單

2011/8/26

[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的時候,這個做法就不適用。再者估算先前提到的功能點數,必須要有一定訓練跟評估經驗的人,才有辦法做的比較仔細跟明確。在評估的過程當中,也夾雜了一點人為的主觀判定,並不一定百分之百的客觀。

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

沒有留言:

張貼留言