Abstrak— Estimasi biaya merupakan salah satu faktor penentu keberhasilan proyek pembuatan perangkat lunak. Estimasi biaya digunakan sebagai rujukan bagi manajer proyek dalam menentukan besarnya anggaran biaya dan sumber daya yang harus dialokasikan untuk keberlangsungan proyek. Perhitungan estimasi biaya didasarkan pada usaha yang dilakukan (effort) untuk pembuatan perangkat lunak dan tarif biaya standar aktivitas tenaga ahli SI/TI. Perhitungan estimasi biaya yang dibahas pada penelitian ini berfokus pada pembuatan perangkat lunak Enterprise Resource Planning (ERP). Proyek pembuatan ERP umumnya mencakup banyak modul yang dikembangkan pada unit-unit bisnis yang ada dalam perusahaan, namun studi kasus pada penelitian ini hanya akan dibuat modul ERP untuk unit bisnis Pabrik Gula yang ada di PT. Perkebunan XYZ. Metode yang digunakan dalam penelitian ini yaitu Use Case Point untuk menghitung besarnya effort dengan berdasar pada pendekatan kebutuhan fungsional perangkat lunak yang akan dijelaskan melalui Use Case Diagram. Effort yang didapatkan nantinya akan dibagi ke dalam 3 aktivitas utama pembuatan perangkat lunak, yaitu Software Development, Ongoing, dan Quality Assurance + Testing. Kemudian, dengan mengacu pada standar gaji/tarif biaya aktivitas tenaga ahli SI/TI, maka hasil perhitungan akhir yang diperoleh dapat memberikan estimasi biaya yang diperlukan dalam pembuatan modul ERP. Hasil dari penelitian ini bersifat kuantitatif yang merepresentasikan jumlah biaya (dalam satuan Rupiah) yang dibutuhkan dalam membuat modul ERP untuk 1 (satu) unit bisnis Pabrik Gula di PT. Perkebunan XYZ.
Kata Kunci— Estimasi biaya, Pembuatan, Enterprise Resource Planning (ERP), Pabrik Gula, Use Case Point.
I. PENDAHULUAN
ERMASALAHAN yang sering dihadapi dalam proyek pembuatan perangkat lunak yaitu over-estimates dan under-estimates. Over-estimates (estimasi berlebihan) akan menimbulkan penambahan alokasi sumberdaya dari yang dibutuhkan. Sedangkan under-estimates (estimasi yang kurang) secara tidak langsung dapat mengurangi kualitas produk, karena untuk menekan biaya, maka perangkat lunak bisa dibuat tidak sesuai dengan standar [1]. Kedua permasalahan tersebut menunjukkan bahwa estimasi biaya merupakan salah satu faktor penting yang harus diperhatikan sebelum menjalankan proyek pembuatan perangkat lunak. Sebelum lebih jauh menentukan estimasi biaya, terlebih dahulu dilakukan perhitungan estimasi usaha yang dikeluarkan (effort) untuk pembuatan perangkat lunak, karena effort
merupakan komponen biaya utama yang akan berpengaruh pada hampir semua obyek biaya. Dengan demikian teknik estimasi biaya di dalamnya meliputi juga metode estimasi effort [2]. Terdapat beberapa metode estimasi effort pembuatan perangkat lunak yang telah ada, diantaranya yaitu Constructive Cost Model (COCOMO), Function Point (FP), Use Case Point (UCP), Neural Network, dan Fuzzy. Masing-masing metode mempunyai kelebihan dan kekurangan, tetapi tidak ada satupun teknik yang terbaik untuk semua kondisi pengembangan perangkat lunak [3].
Penggunaan metode yang tepat untuk menghitung estimasi effort perlu disesuaikan dengan kebutuhan perangkat lunak yang akan dibuat. Hal tersebut yang mendasari pemilihan metode Use Case Point dalam penelitian kali ini untuk proyek pembuatan perangkat lunak Enterprise Resource Planning (ERP). Proyek pembuatan ERP umumnya mencakup banyak modul yang dikembangkan untuk mengintegrasikan proses bisnis pada unit-unit bisnis yang ada dalam perusahaan, namun untuk studi kasus pada penelitian ini hanya akan dibuat modul ERP kustomisasi untuk unit bisnis Pabrik Gula yang ada pada PT. Perkebunan XYZ. Pembuatan modul ERP yang dimaksudkan yaitu mengacu ke kebutuhan fungsional yang ada pada unit bisnis Pabrik Gula tersebut. Maka, metode Use Case Point tepat digunakan untuk menerjemahkan kebutuhan fungsional tersebut ke dalam Use Case Diagram sebelum dilakukan perhitungan estimasi effort dan biayanya. Metode yang dikembangkan oleh Gustav Karner (1993) ini bertujuan untuk menyediakan metode estimasi sederhana yang disesuaikan dengan orientasi pada objek proyek [4].
Perhitungan estimasi biaya tidak hanya melalui penerapan metode Use Case Point saja namun juga dengan mengadaptasi penelitian Kassem Shaleh (2011) untuk membagi effort berdasarkan per-kelompok aktivitas yang dijalankan dalam proyek pembuatan perangkat lunak [5]. Sedangkan untuk menghasilkan estimasi biaya (dalam satuan Rupiah) dilakukan dengan mengkalkulasikan effort yang telah dibagi ke dalam tiap aktivitas dengan standar gaji tenaga ahli SI/TI yang sesuai.
Penelitian-penelitian yang telah ada sebelumnya lebih banyak membahas biaya implementasi ERP dengan menggunakan paket ERP yang ada di pasaran yang sudah memiliki harga standar, sehingga tidak membahas proses estimasi biaya pembuatannya. Oleh karena itu, penelitian ini penting dilakukan untuk memenuhi kebutuhan manajemen
Estimasi Biaya Pembuatan Modul Enterprise
Resource Planning (ERP) Untuk Unit Bisnis Pabrik Gula
Di PT. Perkebunan XYZ Dengan Metode Use Case Point
Grandys Frieska Prassida, Achmad Holil Noor Ali, dan Sholiq
Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS)
Jl. Raya ITS Kampus ITS Sukolilo, Surabaya 60111
puncak PT. Perkebunan XYZ dalam menunjang pengambilan keputusan terkait pengalokasian biaya dalam proyek pembuatan ERP kustomisasi untuk unit bisnis Pabrik Gula yang ada pada perusahaan tersebut.
II. URAIANPENELITIAN
Gambaran umum mengenai penelitian ini akan disajikan dalam bagan berikut ini :
Dalam uraian penelitian ini akan dijelaskan lebih detil mengenai prosesnya yaitu sebagai berikut :
1) Identifikasi Proses Bisnis dan Pembuatan Use Case Diagram
A. Identifikasi Proses Bisnis Pada Unit Bisnis Pabrik Gula
Dalam tahap awal identifikasi proses bisnis ini digunakan sumber data dari Buku Cetak Biru dan Tata Kelola TI PT. Perkebunan XYZ. Di dalam buku tersebut, terdapat penjelasan mengenai Arsitektur Sistem Enterprise/Pabrik Gula yang dijabarkan dalam beberapa bagian yaitu Arsitektur Sistem dan Aplikasi. Identifikasi proses bisnis ini dilakukan dengan memetakan aktivitas mana saja pada proses bisnis yang dapat ditangani oleh aplikasi berikut juga siapa saja aktor yang mengoperasikannya. Hal ini akan memudahkan dalam pengerjaan tahap berikutnya yaitu pembuatan use case diagram.
B. Pembuatan Use Case Diagram
Pembuatan use case diagram mengacu pada kebutuhan fungsi-fungsi perangkat lunak yang akan dikembangkan yang diterjemahkan melalui proses bisnis pada setiap sub-unit yang ada pada unit bisnis Pabrik Gula. Use Case Diagram yang perlu didefinisikan pada proses kali ini yaitu terkait dengan transaksi use case yang dijalankan oleh aktor yang berperan dalam sistem.
2) Perhitungan Effort dengan Use Case Point
A. Menghitung Unadjusted Use Case Point
Unadjusted Use Case Point (UUCP) diperoleh dengan menganalisis use case diagram yang telah dibuat, dimana
terlebih dahulu dilakukan penilaian terkait kompleksitas aktor dan use case dalam sistem.
Penilaian kompleksitas aktor disebut dengan Unadjusted Actor Weight (UAW). Total Unadjusted Actor Weight (UAW) didapat dari menghitung berapa banyak aktor dari masing-masing tipe kompleksitas (simple, average, atau complex) kemudian dikali dengan bobot masing-masing tipenya.
Sedangkan penilaian kompleksitas use case dinamakan Unadjusted Use Case Weight (UUCW). Total Unadjusted Use Case Weight (UUCW) didapat dari menghitung berapa banyak use case dari masing-masing tipe kompleksitas (simple, average, atau complex) kemudian dikali dengan bobot masing-masing tipenya.
Total perhitungan dari UAW dan UUCW yang selanjutnya dijumlahkan untuk mendapatkan hasil UUCP atau dengan rumus sebagai berikut :
UUCP = UAW + UUCW
B. Menghitung Technical dan Environmental Complexity Factor
Pada metode use case point ini juga terdapat faktor teknikal yang mengacu pada faktor-faktor Technical Complexity Adjustment yang terdapat pada metode Function Point Analysis, dan faktor kompleksitas enviromental yang digunakan untuk menghitung fungsi-fungsi yang tidak fungsional yang biasa digunakan untuk mempermudah pekerjaan seorang programmer [1].
Faktor-faktor tersebut memiliki bobot dan skor. Skor yang diberikan pada setiap faktor bergantung dari seberapa besar pengaruh dari faktor tersebut terhadap sistem. 0 menandakan tingkat paling rendah, 3 berarti rata-rata, hingga 5 yang menandakan tingkat paling maksimal [1]. Pemberian skor terhadap faktor teknikal didapatkan melalui metode survey kepada responden atau partisipan dengan kriteria tertentu. Maka, dalam tahap ini nantinya akan disebar kuisioner untuk memberikan penilaian terhadap paramater dalam technical complexity factor sesuai dengan kaidah statistika serta penentuan respondennya yaitu dengan pendekatan mahasiswa yang telah memiliki kompetensi terhadap hal-hal yang akan dinilai tersebut.
Nilai pada masing-masing technical factor dikalikan dengan bobot masing-masing, kemudian dijumlah untuk mendapatkan total technical factor (TF), yang kemudian digunakan untuk mendapatkan Techinal Complexity Factor (TCF), dengan rumus sebagai berikut :
TCF = 0,6 + (0,01 * TF)
mendapatkan Enviromental Complexity Factor (ECF), dengan rumus sebagai berikut :
ECF = 1,4 + (-0,03 * EF)
C. Menghitung Estimasi Effort
Estimasi effort didapatkan dengan metode Use Case Point (UCP) yaitu melalui perkalian antara Unadjusted Use Case Point (UUCP) dengan Technical Complexity Factor (TCF) dan Environmental Complexity Factor (ECF), seperti rumus berikut ini :
UCP = UUCP * TCF * ECF
Untuk merubah nilai UCP yang didapatkan menjadi nilai effort yaitu Hours of Effort, maka nilai UCP harus dikalikan dengan nilai staff-hour per use case point, Karner mengemukakan nilai 20 staff hours untuk setiap use case point untuk estimasi akhir sebuah proyek. Pengalaman langsung telah menunjukkan bahwa nilai staff-hour dapat berkisar dari 15 sampai 30 jam untuk setiap use case point, dimana nilai ini akan mengubah secara langsung use case point ke dalam waktu estimasi yang mungkin masih belum memiliki kepastian [3].
Hours of Effort = UCP * Staff-hour per use case point
3) Perhitungan Biaya per-aktivitas dan Biaya Total
A. Membagi Effort ke dalam 3 Aktivitas Pembuatan Perangkat Lunak
Effort yang telah didapatkan pada tahap sebelumnya dapat dikelompokkan ke dalam aktivitas pembuatan perangkat lunak [8], mengacu pada penelitian Kassem Shaleh (2011), yakni sebagai berikut :
1) Software Development
Meliputi analisis kebutuhan berupa permintaan dan spesifikasi, desain, implementasi (pengkodean), dan termasuk pengujian integrasi, terhitung 42% dari total effort.
2) Ongoing Activity
Meliputi manajemen proyek, manajemen konfigurasi, dokumentasi, penerimaan dan penyebaran, terhitung 21% dari total effort.
3) Quality dan Testing
Meliputi pengujian integrasi, penjaminan kualitas (termasuk warranty), evaluasi dan pengujian, terhitung 37% dari total effort.
B. Menghitung Estimasi Biaya per-aktivitas
Selanjutnya, menghitung estimasi biaya per-aktivitas yang didapatkan dari penjumlahan hasil pengalian hours of effort dengan standar gaji dari personil yang berada pada masing-masing kelompok aktivitas pembuatan perangkat lunak. Standar gaji yang digunakan mengacu pada Indonesia Salary Guide yang dikeluarkan oleh Kelly Service.
C. Menghitung Estimasi Biaya Total
Estimasi biaya total yang dibutuhkan untuk pembuatan modul ERP pada unit bisnis Pabrik Gula didapatkan dengan cara menjumlahkan seluruh estimasi biaya per-aktivitas atau dari 3 aktivitas yang telah didefinisikan sebelumnya.
III. HASILDANPEMBAHASAN
Hasil analisa dan perhitungan metode Use Case Point berupa besar estimasi effort yang diolah dengan mengacu pada guideline Penelitian Kassem Shaleh (2011) akan menghasilkan hasil akhir berupa besar estimasi biaya pembuatan modul ERP untuk unit bisnis Pabrik Gula di PT. Perkebunan XYZ. Pembahasan hasil pada setiap prosesnya akan dijelaskan berikut.
1) Use Case Diagram
Pada tahap pembuatan Use Case Diagram ini yang dibutuhkan ialah hasil identifikasi dari proses bisnis masing-masing modul, yang telah dilakukan pada tahapan sebelumnya. Setelah mengetahui aktor yang berperan, selanjutnya yaitu mendapatkan apa saja proses yang dapat diotomatisasi menggunakan aplikasi dalam setiap modulnya, maka untuk selanjutnya dapat dituangkan ke dalam use case.
Use Case Diagram dibuat per-paket yang menggambarkan modul yang tersedia dalam aplikasi ERP. Terdapat 10 modul, yaitu Manajemen Umum, Manajemen Akun, Manajemen Lahan, Manajemen Bibit, Manajemen Tanaman, Manajemen Tebang/Angkut, Manajemen Timbang Bahan, Manajemen Produksi, Manajemen Gudang, dan Manajemen Bagi Hasil.
Gambar 1 berikut salah satu contoh hasil pembuatan Use Case Diagram untuk salah satu modul, yaitu Manajemen
Lahan.
2) Estimasi Effort
A. Unadjusted Actor Weight (UAW)
Seorang aktor, seperti pengguna yang bekerja dengan antarmuka command-line, memiliki kebutuhan yang sangat sederhana dan hanya sedikit mempengaruhi kompleksitas use case. Aktor lain, seperti pengguna yang bekerja dengan
antarmuka pengguna yang sangat interaktif grafisnya, memiliki dampak yang jauh lebih signifikan pada upaya untuk mengembangkan use case. Untuk memberikan perlakuan terhadap perbedaan ini, maka setiap pelaku dalam system atau aktor diklasifikasikan tipenya ke dalam simple, average, atau complex (dapat dilihat pada Tabel 1) dan diberi bobot dengan cara yang sama pada setiap use case [6].
Tabel 1 Tipe, Bobot, dan Deskripsi Aktor pada Use Case Point
Tipe Bobot Deskripsi
Simple 1 Berinteraksi melalui Baris Perintah
atau Command Prompt.
Average 2 Berinteraksi melalui Protokol,
seperti TCP/IP, HTTP, dsb.
Complex 3 Berinteraksi melalui GUI atau Web
Page.
Dari hasil pembuatan Use Case Diagram diketahui terdapat sejumlah 12 aktor, yaitu Administrator, Bagian Tanaman Staff 1, Bagian Tanaman Staff 2, Bagian Tanaman Staff 3, Bagian Tanaman Staff 4, Bagian Tanaman Staff 5, Bagian Pengolahan Staff 1, Bagian Pengolahan Staff 2, Bagian Administrasi Keuangan & Umum Staff 1, Bagian Administrasi Keuangan & Umum Staff 2, Bagian Quality Control Staff 1, dan Bagian Quality Control Staff 2.
Karena kebutuhan aktor yang lebih mudah bekerja dengan GUI/Web Page dalam menjalankan aplikasi yang akan dikembangkan untuk unit bisnis Pabrik Gula di PT. Perkebunan XYZ ini, maka 12 aktor tersebut diklasifikasikan ke dalam tipe “Complex”.
Maka total perhitungan Unadjusted Actor Weight (UAW) untuk semua modul didapatkan seperti data yang disajikan dalam Tabel 2 berikut.
Tabel 2 Perhitungan Total UAW
Tipe Bobot Jumlah
B. Unadjusted Use Case Weight (UUCW)
Jika mengacu pada pernyataan Karner (1993), setiap use case terdapat beberapa poin yang dapat menentukan jumlah transaksi dalam use case. Ivar Jacobson, pengembang use case, menggambarkan transaksi use case sebagai "round trip" dari pengguna ke sistem kembali ke pengguna; transaksi selesai ketika sistem menanti sebuah stimulus input baru. Dengan kata lain, dalam satu transaksi aktor dapat melakukan beberapa tindakan yang dimasukan untuk sistem. Selanjutnya sistem bereaksi dan mengembalikan hasilnya ke aktor tersebut. Pernyataan Jacobson juga menyiratkan bahwa transaksi use case tidak berarti "langkah dalam aliran use case" [7].
Maka, skenario sukses yang telah dibuat pada masing-masing use case dikelompokkan menjadi sejumlah “round trip” yang menggambarkan transaksi, sehingga dapat dengan mudah menghitung jumlah transaksinya yang kemudian dapat
menentukan tipe kompleksitas use case tersebut (dengan mengacu pada Tabel 3 berikut).
Tabel 3 Tipe, Bobot, dan Deskripsi Use Case pada Use Case Point
Tipe Bobot Deskripsi
Simple 5 Menggunakan <=3 transaksi.
Average 10 Menggunakan 4 sampai 7 transaksi.
Complex 15 Menggunakan >7 transaksi.
Berikut ini merupakan contoh hasil analisa jumlah transaksi pada skenario salah satu use case dalam modul Manajemen Lahan.
Tabel 4 Skenario Sukses dan Jumlah Transaksi Pada Salah Satu Use Case Modul Manajemen Lahan
Transaksi 1 :
1) Setelah berhasil Login, Bag. Tanaman Staff1 membuka modul Manajemen Lahan pada halaman utama aplikasi.
2) Sistem menampilkan menu yang ada dalam modul Manajemen Lahan.
Transaksi 2 :
3) Bag. Tanaman Staff1 memilih menu Pendataan Lahan. 4) Sistem menampilkan pilihan sub-menu dari Pendataan Lahan.
Transaksi 3 :
5) Bag. Tanaman Staff1 memilih sub-menu Kebutuhan Lahan.
6) Sistem menampilkan daftar kebutuhan tanaman berupa taksasi produksi yang direncanakan oleh Bag. Pengolahan Staff1.
Transaksi 4 :
7) Bag. Tanaman Staff1 memilih kebutuhan tanaman yang belum
diproses, kemudian memilih tombol Konversi ke Kebutuhan Lahan. 8) Sistem menampilkan hasil konversi taksasi produksi tanaman ke luas
lahan yang dibutuhkan beserta keterangan luas lahan milik sendiri yang tersedia saat ini.
Transaksi 5 :
9) Jika luas lahan yang dibutuhkan terpenuhi oleh lahan milik sendiri, maka Bag. Tanaman Staff1 meng-klik tombol Siapkan Lahan. 10) Sistem menampilkan data lahan yang akan diolah.
Transaksi 6 :
11) Bag. Tanaman Staff1 memasukkan data yang dibutuhkan dan jika data sudah sesuai, maka Bag. Tanaman Staff1 memilih tombol Simpan.
12) Sistem akan menyimpan data lahan yang telah dimasukkan, kemudian menampilkan kembali halaman awal Pendataan Lahan.
Setelah mengelompokkan skenario sukses ke dalam sejumlah transaksi, maka dapat diketahui bahwa use case tersebut memiliki 6 transaksi, sehingga tipenya termasuk “Average”.
Dari hasil pembuatan Use Case Diagram diketahui dari keseluruhan modul terdapat sejumlah 98 use case. Jika dilakukan perhitungan total Unadjusted Use Case Weight (UUCW), maka hasil yang didapatkan yakni sebagai berikut :
Tabel 5 Perhitungan Total UUCW
Tipe Bobot Jumlah Use
C. Unadjusted Use Case Point (UUCP)
Unadjusted Use Case Weight (UUCW), sehingga nilai UUCP ialah 36 + 590 = 626.
D. Technical Complexity Factor (TCF)
Sampel yang digunakan sejumlah 30 buah berdasar atas ketentuan statistik untuk mengikuti distribusi normal dengan menggunakan pendekatan “Participants” [8] yaitu mengambil responden dari mahasiswa yang familiar dengan aplikasi ERP.
Setelah hasil kuesioner telah valid dan reliable, selanjutnya hasil penilaian tiap faktor tersebut dirata-rata pada masing-masing parameternya untuk mendapatkan nilai/skor yang digunakan untuk pengalian bobot. Untuk rekap hasil dan perhitungan pada masing-masing Technical Factor yaitu seperti yang disajikan pada tabel berikut :
Tabel 6 Perhitungan Total TCF
Technical Complexity Factor Bobot Skor
(0-5) BxS
1 Distributed System
Required 2 4 8
2 Response Time Is
Important 1 5 5
3 End User Efficiency 1 4 4
4 Complex Internal
Processing Required 1 4 4
12 Dependence On
Third-Party Code 1 3 3
13 User Training 1 3 3
Total TF 51 TOTAL TCF = 0,6 + (0,01 * 51) = 1,11 E. Environmental Complexity Factor (ECF)
Untuk rekap hasil dan perhitungan pada masing-masing Environmental Factor yaitu seperti yang disajikan pada tabel berikut :
Tabel 7 Perhitungan Total ECF
Environmental Complexity
Factor Bobot
Skor
(0-5) BxS
1 Familiarity With The
Project 1,5 5 7,5
2 Application
Experience 0,5 5 2,5
Hasil akhir Use Case Point yang didapatkan dari pengalian UUCP dengan TCF dan juga ECF. Maka, hasilnya diperoleh sebagai berikut :
Tabel 8 Perhitungan Akhir UCP
Perhitungan Hasil
Unadjusted Actor Weight (UAW) 36
Unadjusted Use Case Weight (UUCW) 590
Unadjusted Use Case Point (UUCP) 626
Technical Complexity Factor (TCF) 1,11
Environmental Complexity Factor (ECF) 0,695
Use Case Point (UCP) 483
Untuk merubah nilai UCP yang didapatkan menjadi nilai effort yaitu Hours of Effort, maka nilai UCP harus dikalikan dengan nilai staff-hour per use case point, Karner (1993) mengemukakan nilai 20 staff hours untuk setiap use case point untuk estimasi akhir sebuah proyek.
Maka, Hours of Effort = 483 x 20 = 9660.
3) Estimasi Biaya
A. Effort pada Tiap Kelompok Aktivitas
Dengan mengacu pada Penelitian Kassem Shaleh (2011), maka didasarkan pada 3 kelompok aktivitas, hasil akhir Hours of Effort ini dibagi ke dalam masing-masing segmentasi peran dalam tiap kelompok aktivitasnya, seperti yang disajikan dalam Tabel berikut ini.
Tabel 9 Pembagian Effort ke Aktivitas Pengembangan Perangkat Lunak
No. Kelompok Aktivitas %Effort
Hours of Effort 1 Software Development
A Requirement 7,5% 725
B Specifications & Design 17,5% 1691
C Coding 10,0% 966
D Integration Testing 7,0% 676
Total 42,0% 4057
2 On Going Activity
a Project Management 7,0% 676
b Configuration Management 4,0% 483
c Documentation 4,0% 386
d Acceptance & Deployment 6,0% 483
Total 21,0% 2029
3 Quality and Testing
a Quality Assurance & Control 12,5% 1192
b Evaluation and Testing 24,5% 2382
Total 37,0% 3574
B. Biaya per-kelompok aktivitas
per-aktivitas yang diperoleh yakni seperti yang ditunjukkan dalam tabel di bawah ini :
Tabel 10 Estimasi Biaya per-Aktivitas Pembuatan ERP
No. Kelompok
C. Biaya Pembuatan Modul ERP untuk Unit Bisnis Pabrik Gula
Hasil akhir dari perhitungan estimasi biaya ini yaitu berupa jumlah total biaya pembuatan modul ERP untuk 1 (satu) unit bisnis Pabrik Gula. Hal tersebut karena jumlah total unit bisnis Pabrik Gula di PT. Perkebunan XYZ sejumlah 11 unit, sehingga untuk biaya pembuatannya hanya terhitung pada 1 unit bisnis saja. Berikut ini hasil akhir perhitungan estimasi biaya pembuatan modul ERP pada unit bisnis Pabrik Gula :
Tabel 11 Estimasi Biaya Total
Kelompok
Development 4057 26.190,00 106.260.000,00
Ongoing
Activity 2029 40.774,00 82.713.750,00
Quality and
Testing 3574 18.750,00 67.016.250,00
TOTAL 255.990.000,00
IV. KESIMPULAN/RINGKASAN
Kesimpulan yang dapat diambil dari penelitian ini yakni sebagai berikut:
1. Pembuatan modul ERP didasarkan pada kebutuhan fungsional yang tergambar dari proses bisnis masing-masing sub-unit yang ada dalam unit bisnis Pabrik Gula di PT. Perkebunan XYZ.
2. Besarnya estimasi biaya pembuatan modul ERP dihitung dari total biaya yang dibutuhkan untuk masing-masing fase/kelompok aktivitas yang dibebankan untuk 1 (satu) unit bisnis Pabrik Gula.
3. Hasil estimasi biaya yang diperoleh dalam penelitian ini dapat memberikan justifikasi terkait pengalokasian biaya untuk melaksanakan proyek pembuatan modul ERP pada unit bisnis Pabrik Gula di PT. Perkebunan XYZ.
Beberapa hal yang diharapkan dapat dikembangkan di masa mendatang adalah sebagai berikut:
1. Untuk penelitian selanjutnya, perlu diperkuat mengenai landasan perhitungan untuk mendapatkan nilai konstanta Hours of Effort per Use Case Point yang dijadikan faktor pengali untuk mendapatkan hasil akhir estimasi effort (dalam satuan jam).
2. Ke depannya perlu dipertimbangkan mengenai penggunaan indeks standar gaji tenaga ahli SI/TI yang berlaku pada setiap daerah di Indonesia, karena dapat mempengaruhi perhitungan akhir estimasi biaya.
3. Jika ingin mengetahui biaya yang dibutuhkan untuk semua unit bisnis Pabrik Gula, sebanyak 10 unit lainnya, perhitungan perlu disesuaikan lagi, bukan dengan langsung mengkalkulasikan estimasi biaya yang telah didapatkan ke 11 unit bisnis yang ada.
DAFTARPUSTAKA
[1] Suharjito. 2008. Estimasi Usaha Proyek Pengembangan Software Yang
Berorientasi Objek Dengan Use Case Point Metric. Prosiding Seminar
Nasional Sains dan Teknologi-II 2008.
[2] Sarno, R., Buliali, J. L., & Maimunah, S. (2002). Pengembangan
Metode Analogy untuk Estimasi Biaya Rancang Bangun Perangkat Lunak. Makara, Teknologi, Vol.6, No.2.
[3] Khatibi, V., & Jawawi, D. N. 2010. Software Cost Estimation Methods:
A Review. Emerging Trends in Computing and Information Sciences,
21-29.
[4] Karner, Gustav. 1993. Resource Estimation for Objectory Projects. Objective Systems SF AB.
[5] Saleh, K. 2011. Effort and Cost Allocation in Medium to Large
Software Development Projects. Intenational Journal of Computers (1),
74-79.
[6] Cohn, Mike. Estimating With Use Case Point.
[7] Jacobson, Ivar et al., Object-Oriented Software Engineering. A Use
Case Driven Approach, revised printing, Addison-Wesley 1993.
[8] M. Ochodek., et al. 2011. Improving the reliability of transaction
identification in use cases. Information and Software Technology 53
(2011) 885–897.
[9] Kelly Service, Inc. Employment Oulook and Salary Guide 2011/12 : A
