Dahulu orang banyak mengukur volume dari suatu software menggunakan LOC (Lines Of Code), yaitu suatu teknik pengukuran besar software dengan cara menghitung baris kode program yang ada. Teknik ini mempunyai sifat yang menjadi kekurangannya yaitu :
1. Relatif terhadap bahasa/tool pemrograman dan gaya pengkodean programer. LOC sangat tergantung pada karakteristik tool pemrograman yang digunakan dan gaya pengkodean programer. Sebagai contoh dalam bahasa BASIC kode sebagai berikut :
a = a + 1
hanya membutuhkan 1 baris kode. Sedangkan untuk mendapatkan hasil yang sama dalam bahasa PASCAL kode tersebut dikonversi sebagai berikut :
program x;
var
a : integer;
begin
a := a + 1;
end.
yang membutuhkan 6 baris kode.
2. LOC tidak bisa ditentukan sebelum proyek pengembangan menyelesaikan tahapan implementasi (pengkodean). Oleh karena itu, LOC tidak dapat dimanfaatkan untuk merencanakan proses pengembangan dan tidak pula dapat digunakan untuk memperkirakan harga produk. Selesainya tahapan implementasi adalah suatu fase yang sangat terlambat untuk menyusun estimasi sumber daya.
Dari kekurangan tersebut maka timbul keinginan untuk mendapatkan suatu teknik pengukuran volume software yang tidak hanya berdasar pada banyaknya baris kode program, namun lebih kearah sesuatu yang dapat diukur lebih awal pada software development life cycle sehingga kemudian munculah gagasan metode Function Point.
Metode Function Point
Perhitungan dengan metode Function Point menuntut untuk dilakukan oleh seorang profesional yang berpengalaman karena memiliki tingkat subyektifitas yang cukup tinggi. Metode ini sendiri terdiri dari banyak varia. Variasi yang adalah pada langkah/tahapan yang ada maupun pada isi dari tiap tahapan. Varian-varian ini timbul karena metode ini dapat diubah sesuai dengan kebijakan perusahaan pengembang software. Namun apapun varian yang digunakan oleh pengembang, hendaknya digunakan dengan konsisten agar tercipta komparasi yang benar antara softwaresoftware yang dinilai.
Tahapan-tahapan yang ada dalam menentukan function point adalah sebagai berikut :
Langkah 1 : Menghitung crude function points (CFP). Jumlah dari komponen fungsional sistem pertama kali diidentifikasi dan dilanjutkan dengan mengevaluasi kuantitasi bobot kerumitan dari tiap komponen tersebut. Pembobotan tersebut kemudian dijumlahkan dan menjadi angka CFP.
Perhitungan CFP melibatkan 5 tipe komponen sistem software berikut :
- Jumlah macam aplikasi input
- Jumlah macam aplikasi output
- Jumlah macam aplikasi query online – aplikasi ini berhubungan dengan query terhadap data yang tersimpan.
- Jumlah macam file/tabel logic yang terlibat
- Jumlah macam interface eksternal – output atau input yang dapat berhubungan dengan komputer lewat komunikasi data, CD, disket, dan lain-lain.
Kemudian diberikan faktor bobot pada tiap komponen di atas berdasarkan
kompleksitasnya. Tabel di bawah ini merupakan contoh blanko pembobotan
tersebut.
|
Komponen system software |
Level kompleksitas |
Total CFP |
||||||||
|
Sederhana |
Menengah |
Kompleks |
|
|||||||
|
Count |
Faktor bobot |
Point |
Count |
Faktor bobot |
Point |
Count |
Faktor bobot |
Point |
|
|
|
A |
B |
C=AxB |
D |
E |
F=ExF |
G |
H |
I=GxH |
J=C+F+I |
|
|
Input |
|
3 |
|
|
4 |
|
|
6 |
|
|
|
Output |
|
4 |
|
|
5 |
|
|
7 |
|
|
|
Query online |
|
3 |
|
|
4 |
|
|
6 |
|
|
|
File logic |
|
7 |
|
|
10 |
|
|
15 |
|
|
|
Interface external |
|
5 |
|
|
7 |
|
|
10 |
|
|
|
Total CFP |
|
|
|
|
|
|
|
|
|
|
Langkah 2 : Menghitung faktor pengubah kompleksitas relatif/relative complexity adjustment factor (RCAF) untuk proyek tersebut.
RCAF berfungsi untuk menghitung kesimpulan kompleksitas dari sistem software dari beberapa subyek karakteristik. Penilaian berskala 0 sampai 5 diberikan pada tiap subyek yang paling berpengaruh terhadap usaha pengembangan yang dibutuhkan. Blanko penilaian yang diusulkan penulis diberikan seperti table dibawah ini
|
1 |
Tingkat kompleksitas kehandalan backup/recovery |
0 |
1 |
2 |
3 |
4 |
5 |
|
2 |
Tingkat kompleksitas komunikasi data |
0 |
1 |
2 |
3 |
4 |
5 |
|
3 |
Tingkat kompleksitas pemrosesan terdistribusi |
0 |
1 |
2 |
3 |
4 |
5 |
|
4 |
Tingkat kompleksitas kebutuhan akan kinerja |
0 |
1 |
2 |
3 |
4 |
5 |
|
5 |
Tingkat kebutuhan lingkungan operasional |
0 |
1 |
2 |
3 |
4 |
5 |
|
6 |
Tingkat kebutuhan knowledge pengembang |
0 |
1 |
2 |
3 |
4 |
5 |
|
7 |
Tingkat kompleksitas updating file master |
0 |
1 |
2 |
3 |
4 |
5 |
|
8 |
Tingkat kompleksitas instalasi |
0 |
1 |
2 |
3 |
4 |
5 |
|
9 |
Tingkat kompleksitas aplikasi input, output, query online dan file |
0 |
1 |
2 |
3 |
4 |
5 |
|
10 |
Tingkat kompleksitas pemrosesan data |
0 |
1 |
2 |
3 |
4 |
5 |
|
11 |
Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse) |
0 |
1 |
2 |
3 |
4 |
5 |
|
12 |
Tingkat variasi organisasi pelanggan |
0 |
1 |
2 |
3 |
4 |
5 |
|
13 |
Tingkat kemungkinan perubahan/fleksibilitas |
0 |
1 |
2 |
3 |
4 |
5 |
|
14 |
Tingkat kebutuhan kemudahan penggunaan |
0 |
1 |
2 |
3 |
4 |
5 |
|
Total = RCAF |
|||||||
|
FP = CFP x (0.65 + 0.01 x RCAF) |
Langkah 3 : Menghitung Function Point dengan rumus :
FP = CFP x (0.65 + 0.01 x RCAF)
Nilai function point untuk sistem software tersebut kemudian dihitung berdasarkan hasil dari tahap 1 dan 2 yang dimasukkan ke dalam formula
FP = CFP x (0.65 + 0.01 x RCAF)
Contoh Penggunaan – Attend Master
Akan dibangun sebuah sistem presensi karyawan bernama Attend-Master yang direncanakan dapat melayani bisnis kelas kecil sampai menengah dengan karyawan sebanyak 10-100 orang. Sistem tersebut direncanakan akan memiliki interface dengan paket software dari perusahaan lain yaitu Human-Master, yang melayani sumber daya manusia dan Wage-Master yang melayani penggajian. Attend-Master direncanakan dapat menghasilkan beberapa laporan dan query online. Dari dokumentasi requirement sistem software yang direncanakan ini, didapatkan Data Flow Diagram (DFD) yang ditunjukkan pada di bawah ini. Dari gambar tersebut dapat dihitung nilai function point untuk sistem software Attend-Master yang diajukan.
Langkah 1 : Menghitung crude function points (CFP)
- Jumlah aplikasi input – 2
- Jumlah aplikasi output – 3
- Jumlah query online – 3
- Jumlah file logic – 2
- Jumlah interface eksternal – 2
Derajat kompleksitas (sederhana, menengah atau kompleks) kemudian dievaluasi untuk tiap komponen untuk mendapatkan nilai CFP seperti contoh pada diatas.

|
Komponen system software |
Level kompleksitas |
Total CFP |
||||||||
|
Sederhana |
Menengah |
Kompleks |
|
|||||||
|
Count |
Faktor bobot |
Point |
Count |
Faktor bobot |
Point |
Count |
Faktor bobot |
Point |
|
|
|
A |
B |
C=AxB |
D |
E |
F=ExF |
G |
H |
I=GxH |
J=C+F+I |
|
|
Input |
1 |
3 |
3 |
- |
4 |
- |
1 |
6 |
6 |
9 |
|
Output |
- |
4 |
- |
2 |
5 |
10 |
1 |
7 |
7 |
17 |
|
Query online |
1 |
3 |
3 |
1 |
4 |
4 |
1 |
6 |
6 |
13 |
|
File logic |
1 |
7 |
7 |
- |
10 |
- |
1 |
15 |
15 |
22 |
|
Interface external |
- |
5 |
- |
- |
7 |
- |
2 |
10 |
20 |
20 |
|
Total CFP |
|
|
|
|
|
|
|
|
|
81 |
Langkah 2 : Menghitung relative complexity adjustment factor (RCAF)
Evaluasi terhadap karakteristik kompleksitas dari Attend-Master dan perhitungan dari RCAF digambarkan pada table di bawah ini.
|
1 |
Tingkat kompleksitas kehandalan backup/recovery |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
2 |
Tingkat kompleksitas komunikasi data |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
3 |
Tingkat kompleksitas pemrosesan terdistribusi |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
4 |
Tingkat kompleksitas kebutuhan akan kinerja |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
5 |
Tingkat kebutuhan lingkungan operasional |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
6 |
Tingkat kebutuhan knowledge pengembang |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
7 |
Tingkat kompleksitas updating file master |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
8 |
Tingkat kompleksitas instalasi |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
9 |
Tingkat kompleksitas aplikasi input, output, query online dan file |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
10 |
Tingkat kompleksitas pemrosesan data |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
11 |
Tingkat ketidakmungkinan penggunaan kembali dari kode (reuse) |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
12 |
Tingkat variasi organisasi pelanggan |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
13 |
Tingkat kemungkinan perubahan/fleksibilitas |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
14 |
Tingkat kebutuhan kemudahan penggunaan |
0 |
1 |
2 |
3 |
4 |
5 |
|
|
Total = RCAF |
41 |
|||||||
Langkah 3 : Menghitung Function Point (FP)
Dengan menggunakan rumus FP maka didapat :
FP = CFP x (0.65 + 0.01 x RCAF) = 81 x (0.65 + 0.01 x 41) = 85.86
Kelebihan dan Kekurangan Metode Function Point
Kelebihan utama :
· Perkiraan dapat disiapkan pada tahap pra-proyek dan oleh karena itu maka manajemen dapat didukung dalam usaha persiapan proyek.
· Karena metode ini berbasiskan pada dokumen spesifikasi requirement (tidak berdasarkan pada tool pengembangan atau gaya pengkodean programer), kehandalan metode ini relatif tinggi.
Kekurangan utama:
· Hasil perhitungan FP tergantung pada manual penggunaan function point yang digunakan.
· Terkadang ada beberapa proyek yang tidak memiliki dokumen spesifikasi requirement mendetail pada tahap pra-proyek.
· Seluruh proses penghitungan memerlukan profesional yang berpengalaman
· Banyaknya evaluasi yang dibutuhkan berdampak pada hasil yang terlalu subyektif
· Penghitungan FP dilakukan hanya didasarkan pada sistem pemrosesan data. Padahal aspek-aspek lain dari pengembangan sistem software juga ikut berpengaruh terhadap pengembangan itu sendiri. Oleh karena itu metode FP tidak dapat diterapkan secara universal atau masih membutuhkan dukungan perhitungan faktor lainn untuk memperkuat perkiraan
Kesimpulan
Dari uraian di atas dapat ditarik beberapa kesimpulan :
- Metode function point dapat dijadikan salah satu alternatif untuk menghitung volume software berdasarkan kompleksitasnya.
- Penggunaan metode function point memerlukan campur tangan professional yang berpengalaman karena perhitungannya sangat subyektif.
- Karena perhitungannya hanyak berdasarkan pada gambaran pemrosesan data, metode function point harus pula didukung data-data tambahan untuk memperkuat perkiraan volume sistem software yang dihasilkan.
Referensi utama : dosen.amikom.ac.id/downloads/artikel/
Referensi lain :
Gramus, D. dan Herron, D., 1996, Measuring the Software Process – A Practical Guide to Functional Measurements, Yourdon Press, Prentice Hall, New Jersey, US IEEE, 2000, IEEE Std 1061-1998 – Standard for Software Quality Metrics Methodology, The Institure of Electrical and Electronics Engineers, New York, US
Caldiera, G., Antoniol, G., Fiuterm, R. dan Lokan, C., 1998, Definition and Experimental Evaluation of Function Points for Object-Oriented Systems, Proceedings of The Fifth International Software Metrics Symposium, California, US
DISUSUN OLEH :
Nama : Dedi Agung Kristanto
NIM : 22064082