IMPLEMENTASI METODE FUNCTION POINT UNTUK PREDIKSI BIAYA DEVELOPMENT
PERANGKAT LUNAK
Wendi Wirasta,S.T.,M.T1, Abdul Wahid Khoeruddin2 Program Studi Teknik Informatika, STMIK LPKIA Bandung
Jl. Soekarno Hatta No.456 Kota Bandung, Jawa Barat 40266 Tlp. (022) 7564283, Fax.(022) 7564282
1wendi@lpkia.ac.id, 2abdul_wahid@fellow.lpkia.ac.id
__________________________________________________________________
ABSTRAK
Function Point adalah metoda pengukuran sekaligus satuan ukuran sebuah perangkat lunak. Function Point mengukur dengan cara mengkuantifikasi fungsionallitas perangkat lunak yang disediakan untuk pengguna berdasar pada disain logic. Pada umumnya prediksi biaya development adalah memberikan gambaran di masa yang akan datang mengenai biaya perangkat lunak yang akan dibangun sesuai dengan kebutuhan pengguna. Perangkat lunak adalah suatu subkelas perangkat lunak computer yang memanfaatkan kemampuan komputer langsung untuk melaksanakan sebuat tugas yang di instruksikan pengguna, perangkat lunak juga menjadi media untuk pengolahan data yang akhirnya menjadi informasi. Setiap pengembang yang akan membuat perangkat lunak harus memenuhi kebutuhan pengguna dan sulit memutuskan berapa biaya yang sesuai dengan fasilitas yang dimiliki perangkat lunak. Maka dari itu perlunya untuk menganalisa kembali data kebutuhan dan fasilitas perangkat lunak untuk memperoleh pengetahuan atau informasi berupa pengumpulan nilai kebutuhan dan fasilitas pada perangkat lunak yang akan dibangun dan akan menghasilkan prediksi lamanya kerja dalam membangun perangkat lunak serta biaya pengembangan menggunakan Metode Function Point.
Kata kunci :Biaya Development, Metode Function Point, Perangkat Lunak
I. PENDAHULUAN
Perangkat lunak sudah menjadi kebutuhan bagi perusahaan untuk membantu pekerjaan manusia dan menghasilkan informasi berdasarkan permasalahan yang ada. Kebutuhan perangkat lunak menjadi elemen penting dalam pembuatan perangkat lunak yang bertujuan untuk berapa banyak fungsi dalam perangkat lunak, begitu juga dengan fasilitas yang akan di miliki perangkat lunak untuk membuat perangkat lunak tersebut mudah digunakan oleh perusahaan. Perangkat lunak harus memenuhi kedua elemen tersebut agak memenuhi kepuasan dalam menggunakan perangkat lunak.
Salah satu metode pengukuran perangkat lunak yaitu Function Point yang
memanfaatkan hasil analisa data kebutuhan dan fasilitas pada perangkat lunak.
Maka dari itu perusahaan dapat menggunakan metode function point dan memudahkan menganalisa data kebutuhan dan fasilitas perangkat lunak yang akan di buat sesuai tahapan – tahapan pada metode ini untuk memprediksikan biaya beserta jam kerja development.
II. DASAR TEORI
II.1. Kualitas Perangkat Lunak Selama seseorang dapat berdebat tentang perbedaan antara kebutuhan, keinginan dan kemauan, definisi kualitas harus mempertimbangkan prespektif pemakai tersebut. Kualitas perangkat lunak bisa dilihat dari sudut pandang proses
perangkat lunak dan hasil produk yang dihasilkan. [1]
II.2. Function Point
Function point adalah salah satu pendekatan pengukuran perangkat lunak untuk mengukur ukuran sistem berdasar kebutuhan dan fasilitas sistem. Function Point dikembangkan pertama kali oleh Allan J. Albrecht di pertengahan tahun 1970-an, Albrecht memperbaiki metode ini dan sejak 1986, ketika International Function Point User Group (IFPUG) dibentuk, beberapa versi Function Point Counting Practices Manual diterbitkan oleh IFPUG. Hasil dari metode Function Point akan lebih mudah dipahami oleh pengguna non teknis yang dapat membantu mengkomunikasikan informasi ukuran perangkat lunak ke pengguna atau client.
Function Point telah diterima dalam industri perangkat lunak lebih dari 40 tahun sebagai pengukuran standar perangkat lunak. [2]
Adapun tahapan dari metode function point, yaitu sebagai berikut ;
Tahapan 1. menghitung crude function points.
Tahapan 2. menghitung relative complexity adjustment factor.
Tahapan 3. menghitung nilai function point.
II.3. Metodologi Pengembangan Pada penelitian ini menggunakan metodologi pengembangan sistem Extreme Programming, Exterme Programming (XP) dikenal dengan metode atau
“technical how to” bagaimana suatu tim teknis mengembangkan perangkat lunak secara efisien melalui berbagai prinsip dan teknik praktis pengembangan perangkat lunak. XP menjadi dasar bagaimana tim bekerja sehari – hari. XP (Extreme Programming) Life Cycle, terdapat empat fase yaitu Planning, Design, Coding, dan Testing. [3]
II.4. Biaya
Biaya merupakan kas yang habis untuk membeli barang atau jasa dan diharapkan memberikan manfaat bagi perusahaan.
Biaya bisa di artikan kas atau nilai setara kas yang dikorbankan untuk barang atau jasa yang diharapkan memberi manfaat pada saat ini atau di masa mendatang bagi organisasi. [4]
II.5. Functional Requirement
Analisis Function Requiremnet adalah penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasi – situasi tertentu. Selain itu terkadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem. Function requirement menggambarkan system requirement secara detil seperti input, output, dan pengecualian yang berlaku. [5]
II.6. Non- Functional Requirement Analisis kebutuhan non-fungsional secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunana, standar-standar tertentu.
Karena berkaitan dengan kebutuhan sistem secara keseluruhan, maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. [5]
II.7. Unified Modeling Language UML (Unified Modeling Language) adalah metodologi kolaborasi antara metoda- metoda Booch, OMT (Object Medeling Technique), serta OOSE (Object Oriented Software Enggineering) dan beberapa metoda lainnya, merupakan metodologi yang paling sering digunakan saat ini untuk analisa dan perancangan sistem dengan metodologi berorientasi objek mengadaptasi maraknya penggunaan bahasa “pemrograman berorientasi objek”
(OOP). [6]
Gambar III.1 Model Generik Diagram
III. ANALISA DAN
PERANCANGAN
III.1. Model Generik Diagram
Pada tahap ini akan menjelaskan proses tahapan dari Model Generik Diagram seperti pada gambar III.1 yang dimana tahapannya sebagai berikut :
III.I.1 Identifikasi Permasalahan Pada fase ini yang pertama adalah memfokuskan untuk mengidentifikasi permasalahan yang timbul dan melakukan wawancara kebutuhan perangkat lunak yang akan dibuat. Pada penelitian ini dilakukan di CV Inovindo yang dimana perusahaan tersebut bergerak di bidang konsultan TI.
III.I.2 Analisis Kesesuaian Data dan Metode
Pada fase ini akan di lakukan proses planning yang dimana tahapan ini di rumuskan atau didapatkan sesuai dengan fase pada metodologi pengembangan Extreme Programming. Tahap planning dimulai dengan membuat user stories yang menggambarkan output, fitur, dan fungsi – fungsi dari perangkat lunak yang akan dibuat. Lalu mengolah data kebutuhan perangkat lunak dan memisahkan Function
Requiremnet merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem ,bagaimana sistem menerima dan mengolah masukkan dan bagaimana sistem mengatasi situasi – situasi tertentu dan pada kebutuhan ,yang akan jadi bahan perhitungan Crude Function Points dan Non-Function Requiremnet sendiri adalah mengatasi batasan – batasan pada pelayanan atau fungsi yang disediakan oleh sistem seperti batasan waktu proses keamanan sistem ,yang akan jadi bahan perhitungan Relative Complexity Adjustment Factor dalam tahapan metode Function Point.
III.I.3 Penerapan Metode dan Pengkodean
Fase selanjutnya adalah proses coding.
Proses koding pada XP diawali dengan membangun serangkaian unit teset. Setelah itu pengembang akan berfokus untuk mengimplementasikannya. Dalam XP diperkenalkan istilah pair programming dimana proses penulisan program dilakukan secara berpasangan. Dua orang programmer saling bekerjasama di satu komputer untuk menulis program. Dengan melakukan ini akan didapat real-time problem solving dan real-time quality
assurance. Dengan adanya data kebutuhan perangkat lunak maka akan di implementasikan perhitungan metode Function Point dengan menggunakan rumus sebagai berikut :
FP = CFP x (0.65 + 0.01 x RCAF).
III.I.4 Perancangan Sistem
Fase selanjutnya adalah proses design.
Desain di XP mengikuti prinsip Keep It Simple. Untuk desain yang sulit, XP akan menggunakan Spike Solution dimana pembuatan desain dibauat langsung ke tujuannya. XP juga mendukung adanya refactoring dimana software system dibuat sedemikian rupa dengan cara mengubah struktur kode dan menyederhanakan namun hasil dari kode tidak berubah.
Melakukan perancangan kebutuhan perangkat lunak yang sudah didapat, menggambarkan mock up sistem hingga membangun perangkat lunak dan sebagai gambaran ini adalah gambaran use case pada Gambar III.2.
III.I.5 Implementasi Sistem dan Pemeliharaan
Fase terakhir dalam metodologi XP adalah Testing. Tapan ini dilakukan pengujian kode pada unit tes. Dalam XP diperkenalkan XP acceptance test atau biasa disebut customer test. Tes ini dilakukan oleh customer yang berfokus kepada fitur dan fungsi sistem secara keseluruhan. Acceptance test ini berasal dari user stories yang telah diimplementasikan. Fase dimana perangkat lunak sudah dibangun dan melakukan pemeliharaan sistem.
III.2. Crude Function Points
Yaitu tahapan pertama yang menghitung berapa jumlah kebutuhan pada perangkat lunak, di antara memiliki tipe komponen yaitu :
a. External Input, menyimpan jumlah input
b. External Output, menyimpan jumlah output
c. External Inquiry, inisialisasi berapa jumlah interaksi aplikasi dan database d. Internal Logical File, menampung
jumlah tabel dan field pada database dan tidak termasuk primary key
e. External Interface File, inisialisasi jumlah data pemicu yang akan menampilkan data lain
III.3. Relative Complexity Adjustment Factor
Ada empat belas kriteria yang menjadi ciri untuk fasilitas perangkat lunak, masing – masing mempunyai nilai dari nol yang artinya tidak berpengaruh pada sistem sampai lima yang artinya sangat berpengaruh pada sistem. [7]
III.4. Use Case Diagram
Dalam menganalisa kebutuhan perangkat lunak sesuai dengan keinginan pengguna, ada dua aktor yang terlibat dalam perangkat lunak yaitu Administrator dan Analis. Semua aktor sangat berperan membantu proses analisa yang dilakukan oleh perangkat lunak agar dapat berjalan dengan baik.
Gambar III.2 Usecase Diagram Berdasarkan Gambar III.2 maka usecase dibagi menjadi sebagai berikut :
a. Use case Kelola Akun akan melayani aktor Administrator
b. Use case Input Komponen Aplikasi, Kelola Data Aplikasi, Input Kompleksitas Aplikasi dan Hasil Prediksi akan melayani aktor Analis
Gambar IV.1 Tarif Projek
IV. IMPLEMENTASI
Adapun rumus perhitungan yang akan menghasilkan nilai dari function point : FP = CFP x (0.65 + 0.01 x RCAF)
0.01 x RCAF | 0.01 x 45 = 4.5 | 4.5 + 0.65
= 5.15 | CFP x 5.15 | 26 x 5.15 = 133.9 Adapun rumus perhitungan prediksi biaya development perangkat lunak yg melihatkan Gambar IV.1, yaitu :
Development = Tarif/fp x FP 40.000 x 133.9 = Rp. 5.356.000
Tarif Projek pada Gambar IV.1 hanya ilustrasi saja karena tarif projek akan selalu berubah
Adapun rumus untuk menghasilkan prediksi lamanya waktu kerja dalam pembuatan perangkat lunak, yaitu :
Waktu Kerja = 1 Jam x FP 1 x 133.9 = 133 Jam
Hari Kerja = Waktu Kerja / 8 133 / 8 = 16 Hari
Asumsi satu hari kerja sama dengan delapan jam
V. KESIMPULAN
Berdasarkan analisa perancangan dan implementasi, maka dapat ditarik kesimpulan sebagai berikut :
1. Dengan adanya nilai bobot komponen perangkat lunak, analis bisa mengukur
berapa banyak kebutuhan pada perangkat lunak.
2. Dengan adanya nilai bobot kompleksitas perangkat lunak, analis bisa mengukur berapa banyak fasilitas yang di miliki perangkat lunak.
3. Dengan adanya nilai function point, akan menjadi patokan untuk prediksi biaya development beserta jam kerja pembuatan perangkat lunak.
4. Dengan adanya nilai prediksi biaya development, akan memudahkan perusahaan menentukan harga perangkat lunak.
DAFTAR PUSTAKA [
1 ]
Crosby, “Kualitas Software,” 5 November 2014. [Online]. Available:
http://soniamargaretha.weblog.esaunggul .ac.id/2014/11/05/kualitas-software/.
[ 2 ]
W. Pradani, "Jurnal," Kajian Metode Perhitungan Metrik Function-Point dan, pp. Vol. 2, No.1, 2013.
[ 3 ]
S.A_Prabowo, Metode Pengembangan Extreme Programming, Muqtadiroh, 2013.
[ 4 ]
H. Simamora, Konsep Biaya, Warta Warga Student Jurnalis, 2010.
[ 5 ]
I. Sommerville, Software Engineering 6TH Edition, United States: Addison Wesley, 2005.
[ A. Nugroho, Rekayasa Perangkat Lunak
6 ]
Menggunakan UML dan Java, Yogyakarta: Andi, 2009.
[ 7 ]
I. f. p. u. group, "GSC," [Online].
Available:
http://www.functionpointmodeler.com/fp m-
infocenter/index.jsp?topic=%2Fcom.func tionpointmodeler.fpm.help%2Fditafiles
%2Fconcepts%2Fcon-99.html.
[ 8 ]
Pressman, Metodologi Extreme Programming, 2010.
