## Estimasi Biaya Pengembangan Aplikasi Pemantauan Tagihan Menggunakan Metode Function Points
Desinta Ayudia Wanda Putri, Intan Tika Hartiningrum, Renny Sari Dewi *
Fakultas Teknologi Informasi dan Kreatif, Sistem Informasi, Universitas Internasional Semen Indonesia, Gresik, Indonesia Email: 1 desintaayudiawandaputri@gmail.com, 2 tikaintan97@gmail.com, 3,* renny.dewi@uisi.ac.id Email Penulis Korespondensi renny.dewi@uisi.ac.id
Submitted 15-01-2020; Accepted 29-01-2020; Published 15-02-2020

## Abstrak
Sebuah  proyek  estimasi  perangkat  lunak  Enterprise  Resource  Planning  (ERP)  dilakukan  agar  pengalokasian dana  yang  dimiliki  tidak mengakibatkan underestimate atau over-estimate. Under-estimate terjadi karena kurangnya pengalokasian sumber daya sehingga dapat berpotensi kegagalan proyek sedangkan Over-estimate terjadi karena pengalokasian sumber daya yang berlebihan.  Analisis perkiraan biaya  nantinya  akan  didasarkan  pada  penghitungan  Function  Point,  Penelitian  menjelaskan  pembagian  lingkup  kerja  perangkat  lunak Monitoring Tagihan (MONITA) pada perusahaan PT XYZ. Tahap penelitihan dimulai dengan tahap studi literatur, analisis tahapan metode Fuction  Points  memuat  kuesioner,  wawancara  ke  stakeholder,  analisis  data,  perhitungan,  dan  konversi  effort  estimasi  biaya.  Pada perhitungan matematika pada perangkat lunak Monitoring Tagihan (MONITA) menghasilkan estimasi effort sejumlah 1.792,66 orang/jam dan  total  biaya  sebesar    90.457.909.  Analisis  perbandingan  antara  metode  Function  Point  pada  perangkat  lunak  Monitoring  Tagihan (MONITA) dapat menjadi bahan pertimbangan PT XYZ dalam menyelesaikan masalah untuk memperkembangkan perangkat lunak.
Kata Kunci : Estimasi Biaya, Metode Function Point, dan PT XYZ.

## Abstract
An Enterprise Resource Planning (ERP) software estimation project is carried out so that the allocation of funds owned does not result in underestimation or over-estimation. Under-estimation occurs because of the lack of allocation of resources so that it can potentially lead to project failure while Over-estimation occurs because of the allocation of excessive resources. Cost estimation analysis will be based on the  calculation  of  Function  Points.  The  study  explains  the  division  of  work  scope  of  the  Bill  Monitoring  software  (MONITA)  at   the company PT XYZ. The research stage starts with the study of literature, analysis of the stages of the Fuction Points method containing questionnaires,  interviews  with  stakeholders,  data  analysis,  calculations,  and  conversion  of  cost  estimation  efforts.  In  math ematical calculations  on  the  Bill  Monitoring  software  (MONITA)  produces  an  estimated  effort  of  1,792.66  people  /  hour  and  a  total  cost   of 90,457,909.  Comparative  analysis  between  the  Function  Point  method  in  Bill  Monitoring  (MONITA)  software  can  be  taken  into consideration by PT XYZ in solving problems for developing software.
Keywords: Cost Estimation, Function Point Method, and PT XYZ.

## 1. PENDAHULUAN
Teknologi  Informasi  dan  Komunikasi  pada  saat  ini  sudah  berkembang  pesat  di  seluruh  bidang  kegiatan.  Perkembangan tersebut  memicu  banyaknya  perangkat  lunak  yang  muncul  sesuai  kebutuhan  bidang  kegiatan,  salah  satunya  perusahaan. Perangkat  lunak  sangat  membantu  perusahaan  dalam  mendukung  proses  bisnisnya.  PT  XYZ  merupakan  salah  satu perusahaan  yang  sudah  menerapkan  perangkat  lunak  untuk  mendukung  proses  bisninya,  seperti  :  Monitoring  Tagihan (MONITA). Dalam mengestimasi biaya perangkat lunak permasalah yang biasa timbul yaitu : Over-Estimates dan Under- Estimates.  Over-Estimates berdampak  pada  alokasi  sumber  daya  lebih  besar  dari  yang  dibutuhkan,  sedangkan Under- Estimates berdampak pada kualitas dari perangkat lunak yang dihasilkan tidak sesuai standar. Oleh karena itu, tingkat akurasi estimasi biaya sangat diperlukan agar tepat waktu, sesuai biaya dan terpenuhinya standar kualitas produk perangkat lunak.
Dalam pengembangan perangkat lunak terdapat beberapa metode estimasi biaya yang biasa digunakan, yaitu : 1. Metode Function Points yang pertamakali dikembangkan oleh A.J. Albrect pada tahun 1983 dan resmi dinyatakan oleh International Function Points User Group (IFPUG) [1]. 2. Metode Cost Constructive Model (COCOMO) yang telah dikembangkan oleh B. Boehm.
3. Metode Use Case Point (UCP) yang dikembangakan oleh Karner pada tahun 1993.
Menurut Renny [2], metode FP dapat digunakan sebagai metode estimasi usaha yang cukup baik. Beberapa penelitian sebelumnya telah merekomendasikan metode FP apabila jangka waktu perencanaan proyek terbatas [3], [4]. Oleh karena itu, dalam estimasi biaya perangkat lunak Monitoring tagihan  ini menggunakan metode Function Points .

## 2. METODE PENELITIAN
Allan J. Albrect merupakan pengembang metode Function Points Analysis sejak tahun 1983 di perusahaan IBM [1].  Metode Function  Point  adalah  metode  dengan  pendekatan  yang  berorientasi  pada  fungsionalitas  dan  kompleksitas  dalam memperkirakan  ukuran  perangkat  lunak  dan  selanjutnya  memperkirakan  upaya  dan  estimasi  biaya  untuk  pengembangan perangkat lunak [5]. Berikut tahapan-tahapan untuk melakukan estimasi biaya dengan menggunakan metode Function Points Analysis : a. Menghitung Unadjusted Function Points (UFP)
Dalam metode Function Points tersusun dari paramater utama yang memiliki bobot masing-masing  Tabel 1. Menurut penelitian Albrect [1] ada lima parameter utama yaitu EI, EO, EQ, ILF dan ELF.  Dalam menghitung UFP setiap nilai dikalikan dengan faktor kali kompleksitas masing-masing Tabel 2.
Tabel 1 . Parameter Menghitung Unadjusted Function Points
Tabel 2 . Level Kompleksitas
Tipe Komponen Level Kompleksitas Total Mudah Sedang Komplek J B P J B P J B P EI - 3 - - 4 - - 6 - - EO - 4 - - 5 - - 7 - - EQ - 3 - - 4 - - 6 - - ILF - 7 - - 10 - - 15 - - ELF - 5 - - 7 - - 10 - - Total UFP - Keterangan : J : Jumlah B : Bobot
P : Poin
b. Menghitung Relative Complexity Adjustment Factor (RCAF)
Dalam  menghitung  RCAF  digunakan  14  karakteristik  RCAF  untuk  menghitung  bobot  kompleksitas  perangkat  lunak. Total  RCAF  merupakan  total  skor  karakteristik.  Karakteristik  dibawah  ini  merupakan  ketetapan  atau  konstanta  yang dibuat oleh International Function Point Users Group (IFPUG).
Tabel 3. Bobot Relative Complexity Adjustment Factor Skor Keterangan 1 T idak pengaruh 2 Insidial 3 Moderat 4 Rata-rata 5 Essential Tabel 4. Bobot Karakteristik Relative Complexity Adjustment Factor No Karakteristik Skor 1 2 3 4 5 1 Tingkat kehandalan dan pemulihan data O O O O O 2 Tingkat komunikasi data O O O O O 3 Tingkat distribusi pemrosesan data O O O O O 4 Tingkat capaian kerja O O O O O 5 Tingkat konfigurasi lingkungan O O O O O 6 Tingkat kapasitas transaksi O O O O O 7 Tingkat efisiensi pengguna O O O O O 8 Tingkat pembaruan file induk O O O O O 9 Tingkat pembaruan real time online O O O O O 10 Tingkat penggunaan kembali O O O O O 11 Tingkat kemudahan instalasi O O O O O 12 Tingkat kemudahan penggunaan O O O O O Parameter Utama Deskripsi External Input (EI) Proses  dasar  yang  mengolah  data  atau  mengontrol  informasi  yang  datang  dari  luar sistem External Output (EO) Sebuah proses yang mengirimkan data atau  informasi  yang diproses terlebih  dahulu melalui process logic atau proses matematik. External Inquiry (EQ) Sebuah proses yang mengirimkan data atau informasi  keluar dari  batas suatu  sistem (hanya menampilkan data dilayar user). Internal Logical File (ILF) Kumpulan data atau informasi yang digunakan dalam aplikasi. Peran ILF adalah proses menyimpan data dalam aplikasi (Database) External Logical File (ELF) Berkas yang dilewatkan atau dibagikan diantara system perangkat lunak yang dihitung sebagai tipe berkas antarmuka eksternal dalam setiap sistem. (Referensi)
13 Tingkat variasi organisasi pengguna O O O O O 14 Tingkat kerentanan terhadap perubahan O O O O O
c. Menghitung Function Points (FP)
Berikut rumus menghitung Function Points (FP) :
FP = UFP x (0,65 + (0,01 x RCAF))
(1)
Keterangan : 0,65 dan 0,01 = Nilai konstan yang dibuat oleh IFPUG
d. Menghitung Effort
Dalam  menghitung  effort  terdapat  nilai  FP  yang  telah  diketahui  dan  pembangunan  berdasarkan  waktu  (Man/Hours). Dalam function point ini untuk Productivity Factor yang bernilai 8.2 [6]
Effort = FP x PF (2)
e. Menghitung Source Lines of Code (SLoC)
Nilai 56 merupakan nilai dari ketetapan atau konstanta dengan indeks bahasa pemograman PHP dalam yang merupakan Productivity Factor dari bahasa pemograman HTML/Javascript
SloC = FP x 56 (3)
f. Menghitung Estimasi Effort

## Nilai estimasi effort ini digunakan untuk pembangunan berdasarkan Man/Hour
𝐸𝑓𝑓𝑜𝑟𝑡 18 𝑥  ∑ ℎ𝑘 𝑥 𝑗𝑘
(4)
g. Menghitung Pendistribusian Effort ke Aktivitas
Setiap effort yang telah diketahui di distribusikan ke dalam setiap aktivitas yang bertujuan untuk mencari estimasi biaya yang dibutuhkan dalam membangun perangkat lunak.
Persentase x SLoC ke Effort (5)
Untuk menghitung Cost ke dalam setiap aktivitas menggunakan rumus sebagai berikut :
Effort * EffortPayrate /hr
(6) Tabel 5. Persentase Aktivitas No Aktivitas Persentase (%) 1 Requirements 1,6 2 Specifications 7,5 3 Design 6 4 Implementation 52 5 Integration Testing 7 6 Acceptance & deployment 5,5 7 Project Management 3,8 8 Configuration Management 4,3 9 Quality Assurance 0,9 10 Documentation 8,4 11 Training & Support 1 12 Evaluation & Testing 2 Total 100

## 3. ANALISA DAN PEMBAHASAN
Untuk mengetahui nilai estimasi biaya pengembangan perangkat lunak MONITA maka perlu dilakukan perhitungan. Berikut tahap-tahap menghitung estimasi biaya dengan mmenggunakan metode Function Point seperti berikut ini : a. Unadjusted Function Points (UFP)
Tabel 6. Unadjusted Function Points MONITA Tipe Komponen Level Kompleksitas Total Mudah Sedang Komplek
J B P J B P J B P EI 10 3 30 4 4 16 4 6 24 70 EO 10 4 40 4 5 20 4 7 0 60 EQ 1 3 3 0 4 0 0 6 0 3 ILF 4 7 0 3 10 30 0 15 0 30 ELF 3 5 15 0 7 0 0 10 0 15 Total UFP 178
b. Relative Complexity Adjustment Factor (RCAF)
Tabel 7. Relative Complexity Adjustment Factor
No Karakteristik Skor 1 2 3 4 5 1 Tingkat kehandalan dan pemulihan data O O O O O 2 Tingkat komunikasi data O O O O O 3 Tingkat distribusi pemrosesan data O O O O O 4 Tingkat capaian kerja O O O O O 5 Tingkat konfigurasi lingkungan O O O O O 6 Tingkat kapasitas transaksi O O O O O 7 Tingkat efisiensi pengguna O O O O O 8 Tingkat pembaruan file induk O O O O O 9 Tingkat pembaruan real time online O O O O O 10 Tingkat penggunaan kembali O O O O O 11 Tingkat kemudahan instalasi O O O O O 12 Tingkat kemudahan penggunaan O O O O O 13 Tingkat variasi organisasi pengguna O O O O O 14 Tingkat kerentanan terhadap perubahan O O O O O Total RCAF 38
c. Menghitung Function Points (FP)
FP = UFP x (0,65 + (0,01 x RCAF))
= 178 x (0,65 + 0,01 x 38)) = 183,34 d. Menghitung Effort Effort   = FP x PF = 183,34x 8,2 = 1503,39 e. Menghitung Source Lines of Code (SloC)
SloC = FP x 56
= =183,34 x 56 = 10.267,04
f. Menghitung Estimasi Effort
Estimasi Effort = 𝐸𝑓𝑓𝑜𝑟𝑡 18 𝑥 22 ℎ𝑎𝑟𝑖 𝑘𝑒𝑟𝑗𝑎 𝑥 8 𝑗𝑎𝑚 𝑘𝑒𝑟𝑗𝑎
= 1.503,39
18 𝑥 22 ℎ𝑎𝑟𝑖 𝑘𝑒𝑟𝑗𝑎 𝑥 8 𝑗𝑎𝑚 𝑘𝑒𝑟𝑗𝑎
= 1.792,66
g. Menghitung Pendistribusian Effort ke Aktivitas

## Tabel 8. Distribusi Effort ke Aktivitas MONITA
No Aktivitas Persentase (%) Effort = SLoC x % Payrate/hr (IDR) Cost = effort x payrate (IDR) 1 Requirements 1.6 28,68 39.773 1.140.782 2 Specifications 7.5 134,45 39.773 5.347.416 3 Design 6 107,56 45.455 4.889.066 4 Implementation 52 932,18 45.455 42.371.906 5 Integration Testing 7 125,49 45.455 5.703.910 6 Acceptance & deployment 5.5 98,60 45.455 4.481.644
7 Project Management 3.8 68,12 113.636 7.741.022 8 Configuration Management 4.3 77,08 113.636 8.759.577 9 Quality Assurance 0.9 16,13 45.455 733.360 10 Documentation 8.4 150,58 45.455 6.844.693 11 Training & Support 1 17,93 45.455 814.844 12 Evaluation & Testing 2 35,85 45.455 1.629.689 Total 100 1.792,66 90.457.909

## 4. KESIMPULAN
Dari penelitian yang telah dilakukan, estimasi biaya pengembangan perangkat lunak MONITA PT  XYZ, maka disimpulkan apabila  bahwa  PT  XYZ  ingin  mengembangkan  perangkat  lunak  MONITA  maka  dibutuhkan  kurang  lebih  sebesar  IDR 90.457.909  atau  setara  dengan effort 1.792,66  orang/jam. Penulis  mengabaikan  faktor-faktor  eksternal  terutama  kesiapan insfrakstruktur  dakam  mengimplementasikan  MONITA.  Oleh  karena  itu,  perhitungan  estimasi effort dan  biaya  juga disesuaikan dengan kondisi pemilik perangkat lunak

## REFERENCES
[1] A. J. Albrecht and J. E. Gaffney, “Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation,” IEEE Trans. Softw. Eng. , 1983.
[2] R. S. Dewi, “Implementasi Metode Function Points Untuk Mengestimasi Usaha Pada Proyek Pembangunan Aplikasi Layanan Publik,” J. Sist. Inf. Indones. , vol. 2, no. 1, pp. 1–8, 2017.
[3] R. S. Dewi, A. P. Subriadi, and Sholiq, “A Modification Complexity Factor in Function Points Method for Software Cost Estimation Towards Public Service Application,” in Procedia Computer Science , 2017.
[4] R. S. Dewi, T. W. Andari, M. B. A. Rasyid, and R. Candra A.P., “Ekstraksi Faktor Kompleksitas Game Menggunakan Metode Function Points,” J. Teknol. dan Sist. Inf. , 2018.
[5] A. Yhurinda, P. Putri, and A. P. Subriadi, “Software Cost Estimation Using Function Point Analysis,” IPTEK J. Proc. Ser. , vol. 0, no. 1, pp. 79–83, 2019.
[6] P. L. Primandaria and Sholiq, “Effort Distribution to Estimate Cost in Small to Medium Software Development Project with Use  Case Points,” in Procedia Computer Science , 2015.