JURNAL TEKNIK POMITS Vol. 1, No.
1, (2012) 1-6
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
E-mail: holil@is.its.ac.id, sholiq@is.its.ac.id
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
P 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
1
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
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6
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. URAIAN PENELITIAN
Gambaran umum mengenai penelitian ini akan disajikan
dalam bagan berikut ini :
Bagan 1 Gambaran Umum Penelitian
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
2
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)
Sedangkan penilaian terhadap enviromental factor, karena
berkaitan dengan tim pengembang, maka skor yang diberikan
mengacu pada kondisi yang ada pada dokumen Term of
Reference PT. Perkebunan XYZ. Selanjutnya, nilai pada
masing-masing enviromental factor dikalikan dengan bobot
masing-masing, kemudian dijumlah untuk mendapatkan total
enviromental factor (EF), yang kemudian digunakan untuk
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6
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.
3
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. HASIL DAN PEMBAHASAN
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
Gambar 1 Use Case Diagram Modul Manajemen Lahan
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
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6 4

antarmuka pengguna yang sangat interaktif grafisnya, memiliki menentukan tipe kompleksitas use case tersebut (dengan
dampak yang jauh lebih signifikan pada upaya untuk mengacu pada Tabel 3 berikut).
mengembangkan use case. Untuk memberikan perlakuan
Tabel 3 Tipe, Bobot, dan Deskripsi Use Case pada Use Case Point
terhadap perbedaan ini, maka setiap pelaku dalam system atau
Tipe Bobot Deskripsi
aktor diklasifikasikan tipenya ke dalam simple, average, atau
Simple 5 Menggunakan <=3 transaksi.
complex (dapat dilihat pada Tabel 1) dan diberi bobot dengan Average 10 Menggunakan 4 sampai 7 transaksi.
cara yang sama pada setiap use case [6]. Complex 15 Menggunakan >7 transaksi.
Tabel 1 Tipe, Bobot, dan Deskripsi Aktor pada Use Case Point Berikut ini merupakan contoh hasil analisa jumlah transaksi
Tipe Bobot Deskripsi pada skenario salah satu use case dalam modul Manajemen
Simple 1 Berinteraksi melalui Baris Perintah Lahan.
atau Command Prompt.
Average 2 Berinteraksi melalui Protokol, Tabel 4 Skenario Sukses dan Jumlah Transaksi Pada Salah Satu Use
seperti TCP/IP, HTTP, dsb. Case Modul Manajemen Lahan
Complex 3 Berinteraksi melalui GUI atau Web Transaksi 1 :
Page. 1) Setelah berhasil Login, Bag. Tanaman Staff1 membuka modul
Manajemen Lahan pada halaman utama aplikasi.
Dari hasil pembuatan Use Case Diagram diketahui terdapat 2) Sistem menampilkan menu yang ada dalam modul Manajemen Lahan.
sejumlah 12 aktor, yaitu Administrator, Bagian Tanaman Staff Transaksi 2 :
1, Bagian Tanaman Staff 2, Bagian Tanaman Staff 3, Bagian 3) Bag. Tanaman Staff1 memilih menu Pendataan Lahan.
4) Sistem menampilkan pilihan sub-menu dari Pendataan Lahan.
Tanaman Staff 4, Bagian Tanaman Staff 5, Bagian Pengolahan Transaksi 3 :
Staff 1, Bagian Pengolahan Staff 2, Bagian Administrasi 5) Bag. Tanaman Staff1 memilih sub-menu Kebutuhan Lahan.
Keuangan & Umum Staff 1, Bagian Administrasi Keuangan & 6) Sistem menampilkan daftar kebutuhan tanaman berupa taksasi
Umum Staff 2, Bagian Quality Control Staff 1, dan Bagian produksi yang direncanakan oleh Bag. Pengolahan Staff1.
Transaksi 4 :
Quality Control Staff 2.
7) Bag. Tanaman Staff1 memilih kebutuhan tanaman yang belum
Karena kebutuhan aktor yang lebih mudah bekerja dengan diproses, kemudian memilih tombol Konversi ke Kebutuhan Lahan.
GUI/Web Page dalam menjalankan aplikasi yang akan 8) Sistem menampilkan hasil konversi taksasi produksi tanaman ke luas
dikembangkan untuk unit bisnis Pabrik Gula di PT. lahan yang dibutuhkan beserta keterangan luas lahan milik sendiri
yang tersedia saat ini.
Perkebunan XYZ ini, maka 12 aktor tersebut diklasifikasikan Transaksi 5 :
ke dalam tipe “Complex”. 9) Jika luas lahan yang dibutuhkan terpenuhi oleh lahan milik sendiri,
Maka total perhitungan Unadjusted Actor Weight (UAW) maka Bag. Tanaman Staff1 meng-klik tombol Siapkan Lahan.
untuk semua modul didapatkan seperti data yang disajikan 10) Sistem menampilkan data lahan yang akan diolah.
Transaksi 6 :
dalam Tabel 2 berikut. 11) Bag. Tanaman Staff1 memasukkan data yang dibutuhkan dan jika
Tabel 2 Perhitungan Total UAW data sudah sesuai, maka Bag. Tanaman Staff1 memilih tombol
Simpan.
Jumlah Bobot x 12) Sistem akan menyimpan data lahan yang telah dimasukkan, kemudian
Tipe Bobot
Aktor Jumlah Aktor menampilkan kembali halaman awal Pendataan Lahan.
Simple 1 0 0
Average 2 0 0 Setelah mengelompokkan skenario sukses ke dalam
Complex 3 12 36 sejumlah transaksi, maka dapat diketahui bahwa use case
Total UAW 36 tersebut memiliki 6 transaksi, sehingga tipenya termasuk
“Average”.
B. Unadjusted Use Case Weight (UUCW) Dari hasil pembuatan Use Case Diagram diketahui dari
Jika mengacu pada pernyataan Karner (1993), setiap use keseluruhan modul terdapat sejumlah 98 use case. Jika
case terdapat beberapa poin yang dapat menentukan jumlah dilakukan perhitungan total Unadjusted Use Case Weight
transaksi dalam use case. Ivar Jacobson, pengembang use case, (UUCW), maka hasil yang didapatkan yakni sebagai berikut :
menggambarkan transaksi use case sebagai "round trip" dari
Tabel 5 Perhitungan Total UUCW
pengguna ke sistem kembali ke pengguna; transaksi selesai
ketika sistem menanti sebuah stimulus input baru. Dengan kata Bobot x
Jumlah Use
Tipe Bobot Jumlah Use
lain, dalam satu transaksi aktor dapat melakukan beberapa Case
Case
tindakan yang dimasukan untuk sistem. Selanjutnya sistem Simple 5 78 390
bereaksi dan mengembalikan hasilnya ke aktor tersebut. Average 10 20 200
Pernyataan Jacobson juga menyiratkan bahwa transaksi use Complex 15 0 0
case tidak berarti "langkah dalam aliran use case" [7]. Total UUCW 590
Maka, skenario sukses yang telah dibuat pada masing-
C. Unadjusted Use Case Point (UUCP)
masing use case dikelompokkan menjadi sejumlah “round
trip” yang menggambarkan transaksi, sehingga dapat dengan Unadjusted Use Case Point (UUCP) dihitung dengan cara
mudah menghitung jumlah transaksinya yang kemudian dapat menjumlahkan total Unadjusted Actor Weight (UAW) dan
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6 5

Unadjusted Use Case Weight (UUCW), sehingga nilai UUCP Environmental Complexity Skor
Bobot BxS
ialah 36 + 590 = 626. Factor (0-5)
Language
D. Technical Complexity Factor (TCF)
Sampel yang digunakan sejumlah 30 buah berdasar atas Total EF 23,5
ketentuan statistik untuk mengikuti distribusi normal dengan TOTAL ECF 1,4 – (0,03 * 23,5) = 0,695
menggunakan pendekatan “Participants” [8] yaitu mengambil
F. Use Case Point (UCP)
responden dari mahasiswa yang familiar dengan aplikasi ERP.
Setelah hasil kuesioner telah valid dan reliable, selanjutnya Hasil akhir Use Case Point yang didapatkan dari pengalian
hasil penilaian tiap faktor tersebut dirata-rata pada masing- UUCP dengan TCF dan juga ECF. Maka, hasilnya diperoleh
masing parameternya untuk mendapatkan nilai/skor yang sebagai berikut :
digunakan untuk pengalian bobot. Untuk rekap hasil dan Tabel 8 Perhitungan Akhir UCP
perhitungan pada masing-masing Technical Factor yaitu Perhitungan Hasil
seperti yang disajikan pada tabel berikut : Unadjusted Actor Weight (UAW) 36
Tabel 6 Perhitungan Total TCF Unadjusted Use Case Weight (UUCW) 590
Unadjusted Use Case Point (UUCP) 626
Skor Technical Complexity Factor (TCF) 1,11
Technical Complexity Factor Bobot BxS
(0-5)
Environmental Complexity Factor (ECF) 0,695
Distributed System
1 2 4 8 Use Case Point (UCP) 483
Required
Response Time Is Untuk merubah nilai UCP yang didapatkan menjadi nilai
2 1 5 5
Important effort yaitu Hours of Effort, maka nilai UCP harus dikalikan
3 End User Efficiency 1 4 4 dengan nilai staff-hour per use case point, Karner (1993)
Complex Internal
4
Processing Required
1 4 4 mengemukakan nilai 20 staff hours untuk setiap use case point
Reusable Code Must Be untuk estimasi akhir sebuah proyek.
5 1 2 2 Maka, Hours of Effort = 483 x 20 = 9660.
A Focus
6 Installation Ease 0,5 3 1,5
3) Estimasi Biaya
7 Usability 0,5 5 2,5
8 Cross-Platform Support 2 3 6 A. Effort pada Tiap Kelompok Aktivitas
9 Easy To Change 1 4 4 Dengan mengacu pada Penelitian Kassem Shaleh (2011),
10 Highly Concurrent 1 4 4 maka didasarkan pada 3 kelompok aktivitas, hasil akhir Hours
11 Custom Security 1 4 4
of Effort ini dibagi ke dalam masing-masing segmentasi peran
Dependence On Third-
dalam tiap kelompok aktivitasnya, seperti yang disajikan
12 1 3 3 dalam Tabel berikut ini.
Party Code
13 User Training 1 3 3 Tabel 9 Pembagian Effort ke Aktivitas Pengembangan Perangkat
Total TF 51 Lunak
TOTAL TCF = 0,6 + (0,01 * 51) = 1,11 Hours
No. Kelompok Aktivitas %Effort of
E. Environmental Complexity Factor (ECF) Effort
Untuk rekap hasil dan perhitungan pada masing-masing 1 Software Development
Environmental Factor yaitu seperti yang disajikan pada tabel A Requirement 7,5% 725
berikut : B Specifications & Design 17,5% 1691
C Coding 10,0% 966
Tabel 7 Perhitungan Total ECF D Integration Testing 7,0% 676
Environmental Complexity Skor Total 42,0% 4057
Bobot BxS
Factor (0-5) 2 On Going Activity
Familiarity With The a Project Management 7,0% 676
1 1,5 5 7,5
Project b Configuration Management 4,0% 483
Application c Documentation 4,0% 386
2 0,5 5 2,5
Experience d Acceptance & Deployment 6,0% 483
OO Programming Total 21,0% 2029
3 1 5 5
Experience 3 Quality and Testing
Lead Analyst a Quality Assurance & Control 12,5% 1192
4 0,5 5 2,5
Capability b Evaluation and Testing 24,5% 2382
5 Motivation 1 3 3 Total 37,0% 3574
6 Stable Requirements 2 3 6
7 Part Time Staff -1 0 0 B. Biaya per-kelompok aktivitas
Difficult Dengan mengacu pada Indonesia Salary Guide 2011/2012
8 -1 3 -3
Programming [9] yang diterbitkan oleh Kelly Service, maka biaya per-
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6 6

aktivitas yang diperoleh yakni seperti yang ditunjukkan dalam IV. KESIMPULAN/RINGKASAN
tabel di bawah ini : Kesimpulan yang dapat diambil dari penelitian ini
Tabel 10 Estimasi Biaya per-Aktivitas Pembuatan ERP yakni sebagai berikut:
Kelompok %
Hours Standar Biaya 1. Pembuatan modul ERP didasarkan pada kebutuhan
No. of Gaji/jam (org/jam) fungsional yang tergambar dari proses bisnis masing-
Aktivitas Effort
Effort (Rp) (Rp)
Software masing sub-unit yang ada dalam unit bisnis Pabrik Gula di
1 Development PT. Perkebunan XYZ.
a Requirement 7,5% 725 31.250 5.580 2. Besarnya estimasi biaya pembuatan modul ERP dihitung
Specifications & dari total biaya yang dibutuhkan untuk masing-masing
17,5% 1691 31.250 13.021
b Design fase/kelompok aktivitas yang dibebankan untuk 1 (satu)
c Coding 10,0% 966 18.750 4.464 unit bisnis Pabrik Gula.
Integration 3. Hasil estimasi biaya yang diperoleh dalam penelitian ini
7,0% 676 18.750 3.125
d Testing
dapat memberikan justifikasi terkait pengalokasian biaya
Total 42,0% 4057 26.190
untuk melaksanakan proyek pembuatan modul ERP pada
On Going
2 Activity unit bisnis Pabrik Gula di PT. Perkebunan XYZ.
Project Beberapa hal yang diharapkan dapat dikembangkan di masa
7,0% 676 62.500 20.833
a Management mendatang adalah sebagai berikut:
Configuration 1. Untuk penelitian selanjutnya, perlu diperkuat mengenai
4,0% 483 43.750 10.417
b Management
landasan perhitungan untuk mendapatkan nilai konstanta
c Documentation 4,0% 386 18.750 3.571
Hours of Effort per Use Case Point yang dijadikan faktor
Acceptance &
6,0% 483 25.000 5.952 pengali untuk mendapatkan hasil akhir estimasi effort
d Deployment
21,0% 2029 40.774 (dalam satuan jam).
Total
Quality and 2. Ke depannya perlu dipertimbangkan mengenai penggunaan
3 Testing indeks standar gaji tenaga ahli SI/TI yang berlaku pada
Quality setiap daerah di Indonesia, karena dapat mempengaruhi
Assurance & 12,5% 1192 18.750 6.253
perhitungan akhir estimasi biaya.
a Control
Evaluation and 3. Jika ingin mengetahui biaya yang dibutuhkan untuk semua
24,5% 2382 18.750 12.497
b Testing unit bisnis Pabrik Gula, sebanyak 10 unit lainnya,
Total 37,0% 3574 18.750 perhitungan perlu disesuaikan lagi, bukan dengan langsung
mengkalkulasikan estimasi biaya yang telah didapatkan ke
C. Biaya Pembuatan Modul ERP untuk Unit Bisnis Pabrik
Gula 11 unit bisnis yang ada.
Hasil akhir dari perhitungan estimasi biaya ini yaitu berupa
jumlah total biaya pembuatan modul ERP untuk 1 (satu) unit DAFTAR PUSTAKA
bisnis Pabrik Gula. Hal tersebut karena jumlah total unit bisnis [1] Suharjito. 2008. Estimasi Usaha Proyek Pengembangan Software Yang
Pabrik Gula di PT. Perkebunan XYZ sejumlah 11 unit, Berorientasi Objek Dengan Use Case Point Metric. Prosiding Seminar
Nasional Sains dan Teknologi-II 2008.
sehingga untuk biaya pembuatannya hanya terhitung pada 1 [2] Sarno, R., Buliali, J. L., & Maimunah, S. (2002). Pengembangan
unit bisnis saja. Berikut ini hasil akhir perhitungan estimasi Metode Analogy untuk Estimasi Biaya Rancang Bangun Perangkat
biaya pembuatan modul ERP pada unit bisnis Pabrik Gula : Lunak. Makara, Teknologi, Vol.6, No.2.
[3] Khatibi, V., & Jawawi, D. N. 2010. Software Cost Estimation Methods:
Tabel 11 Estimasi Biaya Total A Review. Emerging Trends in Computing and Information Sciences,
Total Total Biaya 21-29.
Kelompok Estimasi Biaya [4] Karner, Gustav. 1993. Resource Estimation for Objectory Projects.
Hours of (orang/jam)
Aktivitas Total (Rp) Objective Systems SF AB.
Effort (Rp)
[5] Saleh, K. 2011. Effort and Cost Allocation in Medium to Large
Software Software Development Projects. Intenational Journal of Computers (1),
4057 26.190,00 106.260.000,00
Development 74-79.
Ongoing [6] Cohn, Mike. Estimating With Use Case Point.
2029 40.774,00 82.713.750,00
Activity [7] Jacobson, Ivar et al., Object-Oriented Software Engineering. A Use
Quality and Case Driven Approach, revised printing, Addison-Wesley 1993.
3574 18.750,00 67.016.250,00 [8] M. Ochodek., et al. 2011. Improving the reliability of transaction
Testing
identification in use cases. Information and Software Technology 53
TOTAL 255.990.000,00 (2011) 885–897.
[9] Kelly Service, Inc. Employment Oulook and Salary Guide 2011/12 : A
Tool for Workforce Planning.