Estimasi Biaya Pembuatan Modul Enterpris
JURNAL TEKNIK POMITS Vol. 1, No. 1, (2012) 1-6
1
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
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. Masingmasing 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 :
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 masingmasing 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 masingmasing tipenya.
Total perhitungan dari UAW dan UUCW yang selanjutnya
dijumlahkan untuk mendapatkan hasil UUCP atau dengan
rumus sebagai berikut :
UUCP = UAW + UUCW
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
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 masingmasing 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 masingmasing 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
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].
menentukan tipe kompleksitas use case tersebut (dengan
mengacu pada Tabel 3 berikut).
Tabel 1 Tipe, Bobot, dan Deskripsi Aktor pada Use Case Point
Berikut ini merupakan contoh hasil analisa jumlah transaksi
pada skenario salah satu use case dalam modul Manajemen
Lahan.
Tipe
Simple
Bobot
1
Average
2
Complex
3
Deskripsi
Berinteraksi melalui Baris Perintah
atau Command Prompt.
Berinteraksi melalui Protokol,
seperti TCP/IP, HTTP, dsb.
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
Simple
Average
Complex
Bobot
1
2
3
Total UAW
Jumlah
Aktor
0
0
12
Bobot x
Jumlah Aktor
0
0
36
36
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 masingmasing use case dikelompokkan menjadi sejumlah “round
trip” yang menggambarkan transaksi, sehingga dapat dengan
mudah menghitung jumlah transaksinya yang kemudian dapat
Tabel 3 Tipe, Bobot, dan Deskripsi Use Case pada Use Case Point
Tipe
Simple
Average
Complex
Bobot
5
10
15
Deskripsi
Menggunakan 7 transaksi.
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
Simple
Average
Complex
Bobot
5
10
15
Total UUCW
Jumlah Use
Case
78
20
0
Bobot x
Jumlah Use
Case
390
200
0
590
C. Unadjusted Use Case Point (UUCP)
Unadjusted Use Case Point (UUCP) dihitung dengan cara
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
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 masingmasing 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
2
4
8
1
5
5
1
4
4
1
4
4
1
2
2
6
7
8
9
Distributed System
Required
Response Time Is
Important
End User Efficiency
Complex Internal
Processing Required
Reusable Code Must Be
A Focus
Installation Ease
Usability
Cross-Platform Support
Easy To Change
0,5
0,5
2
1
3
5
3
4
1,5
2,5
6
4
10
Highly Concurrent
1
4
4
11
Custom Security
Dependence On ThirdParty Code
1
4
4
1
3
3
1
3
3
1
2
3
4
5
12
13
User Training
TOTAL TCF =
51
Total TF
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
Familiarity With The
1
Project
Application
2
Experience
OO Programming
3
Experience
Lead Analyst
4
Capability
5
Motivation
6
Stable Requirements
7
Part Time Staff
Difficult
8
Programming
Bobot
Skor
(0-5)
BxS
1,5
5
7,5
0,5
5
2,5
1
5
5
0,5
5
2,5
1
2
-1
3
3
0
3
6
0
-1
3
-3
Environmental Complexity
Factor
Language
TOTAL ECF
Bobot
Skor
(0-5)
BxS
Total EF
23,5
1,4 – (0,03 * 23,5) = 0,695
F. Use Case Point (UCP)
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
Unadjusted Actor Weight (UAW)
Unadjusted Use Case Weight (UUCW)
Unadjusted Use Case Point (UUCP)
Technical Complexity Factor (TCF)
Environmental Complexity Factor (ECF)
Use Case Point (UCP)
Hasil
36
590
626
1,11
0,695
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
1
A
B
C
D
Software Development
Requirement
Specifications & Design
Coding
Integration Testing
2
a
b
c
d
On Going Activity
Project Management
Configuration Management
Documentation
Acceptance & Deployment
3
a
b
Total
Quality and Testing
Quality Assurance & Control
Evaluation and Testing
Total
Total
Hours
of
Effort
7,5%
17,5%
10,0%
7,0%
42,0%
725
1691
966
676
4057
7,0%
4,0%
4,0%
6,0%
21,0%
676
483
386
483
2029
12,5%
24,5%
37,0%
1192
2382
3574
B. Biaya per-kelompok aktivitas
Dengan mengacu pada Indonesia Salary Guide 2011/2012
[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
tabel di bawah ini :
Tabel 10 Estimasi Biaya per-Aktivitas Pembuatan ERP
No.
1
a
b
c
d
%
Effort
Hours
of
Effort
Standar
Gaji/jam
(Rp)
Biaya
(org/jam)
(Rp)
7,5%
725
31.250
5.580
17,5%
1691
31.250
13.021
10,0%
966
18.750
4.464
7,0%
676
18.750
3.125
42,0%
4057
7,0%
676
62.500
20.833
4,0%
483
43.750
10.417
4,0%
386
18.750
3.571
6,0%
483
25.000
5.952
Total
Quality and
Testing
Quality
Assurance &
Control
Evaluation and
Testing
21,0%
2029
12,5%
1192
18.750
6.253
24,5%
2382
18.750
12.497
Total
37,0%
3574
Kelompok
Aktivitas
Software
Development
Requirement
Specifications &
Design
Coding
Integration
Testing
Total
2
a
b
c
d
3
a
b
On Going
Activity
Project
Management
Configuration
Management
Documentation
Acceptance &
Deployment
26.190
40.774
18.750
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 :
Software
Development
Ongoing
Activity
Quality and
Testing
Total
Hours of
Effort
Total Biaya
(orang/jam)
(Rp)
Kesimpulan yang dapat diambil dari penelitian ini
yakni sebagai berikut:
1. Pembuatan modul ERP didasarkan pada kebutuhan
fungsional yang tergambar dari proses bisnis masingmasing 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.
DAFTAR PUSTAKA
[1]
[2]
[3]
Tabel 11 Estimasi Biaya Total
Kelompok
Aktivitas
IV. KESIMPULAN/RINGKASAN
Estimasi Biaya
Total (Rp)
[4]
[5]
4057
26.190,00
106.260.000,00
2029
40.774,00
82.713.750,00
[6]
[7]
3574
18.750,00
67.016.250,00
[8]
TOTAL
255.990.000,00
[9]
Suharjito. 2008. Estimasi Usaha Proyek Pengembangan Software Yang
Berorientasi Objek Dengan Use Case Point Metric. Prosiding Seminar
Nasional Sains dan Teknologi-II 2008.
Sarno, R., Buliali, J. L., & Maimunah, S. (2002). Pengembangan
Metode Analogy untuk Estimasi Biaya Rancang Bangun Perangkat
Lunak. Makara, Teknologi, Vol.6, No.2.
Khatibi, V., & Jawawi, D. N. 2010. Software Cost Estimation Methods:
A Review. Emerging Trends in Computing and Information Sciences,
21-29.
Karner, Gustav. 1993. Resource Estimation for Objectory Projects.
Objective Systems SF AB.
Saleh, K. 2011. Effort and Cost Allocation in Medium to Large
Software Development Projects. Intenational Journal of Computers (1),
74-79.
Cohn, Mike. Estimating With Use Case Point.
Jacobson, Ivar et al., Object-Oriented Software Engineering. A Use
Case Driven Approach, revised printing, Addison-Wesley 1993.
M. Ochodek., et al. 2011. Improving the reliability of transaction
identification in use cases. Information and Software Technology 53
(2011) 885–897.
Kelly Service, Inc. Employment Oulook and Salary Guide 2011/12 : A
Tool for Workforce Planning.
1
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
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. Masingmasing 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 :
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 masingmasing 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 masingmasing tipenya.
Total perhitungan dari UAW dan UUCW yang selanjutnya
dijumlahkan untuk mendapatkan hasil UUCP atau dengan
rumus sebagai berikut :
UUCP = UAW + UUCW
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
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 masingmasing 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 masingmasing 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
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].
menentukan tipe kompleksitas use case tersebut (dengan
mengacu pada Tabel 3 berikut).
Tabel 1 Tipe, Bobot, dan Deskripsi Aktor pada Use Case Point
Berikut ini merupakan contoh hasil analisa jumlah transaksi
pada skenario salah satu use case dalam modul Manajemen
Lahan.
Tipe
Simple
Bobot
1
Average
2
Complex
3
Deskripsi
Berinteraksi melalui Baris Perintah
atau Command Prompt.
Berinteraksi melalui Protokol,
seperti TCP/IP, HTTP, dsb.
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
Simple
Average
Complex
Bobot
1
2
3
Total UAW
Jumlah
Aktor
0
0
12
Bobot x
Jumlah Aktor
0
0
36
36
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 masingmasing use case dikelompokkan menjadi sejumlah “round
trip” yang menggambarkan transaksi, sehingga dapat dengan
mudah menghitung jumlah transaksinya yang kemudian dapat
Tabel 3 Tipe, Bobot, dan Deskripsi Use Case pada Use Case Point
Tipe
Simple
Average
Complex
Bobot
5
10
15
Deskripsi
Menggunakan 7 transaksi.
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
Simple
Average
Complex
Bobot
5
10
15
Total UUCW
Jumlah Use
Case
78
20
0
Bobot x
Jumlah Use
Case
390
200
0
590
C. Unadjusted Use Case Point (UUCP)
Unadjusted Use Case Point (UUCP) dihitung dengan cara
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
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 masingmasing 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
2
4
8
1
5
5
1
4
4
1
4
4
1
2
2
6
7
8
9
Distributed System
Required
Response Time Is
Important
End User Efficiency
Complex Internal
Processing Required
Reusable Code Must Be
A Focus
Installation Ease
Usability
Cross-Platform Support
Easy To Change
0,5
0,5
2
1
3
5
3
4
1,5
2,5
6
4
10
Highly Concurrent
1
4
4
11
Custom Security
Dependence On ThirdParty Code
1
4
4
1
3
3
1
3
3
1
2
3
4
5
12
13
User Training
TOTAL TCF =
51
Total TF
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
Familiarity With The
1
Project
Application
2
Experience
OO Programming
3
Experience
Lead Analyst
4
Capability
5
Motivation
6
Stable Requirements
7
Part Time Staff
Difficult
8
Programming
Bobot
Skor
(0-5)
BxS
1,5
5
7,5
0,5
5
2,5
1
5
5
0,5
5
2,5
1
2
-1
3
3
0
3
6
0
-1
3
-3
Environmental Complexity
Factor
Language
TOTAL ECF
Bobot
Skor
(0-5)
BxS
Total EF
23,5
1,4 – (0,03 * 23,5) = 0,695
F. Use Case Point (UCP)
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
Unadjusted Actor Weight (UAW)
Unadjusted Use Case Weight (UUCW)
Unadjusted Use Case Point (UUCP)
Technical Complexity Factor (TCF)
Environmental Complexity Factor (ECF)
Use Case Point (UCP)
Hasil
36
590
626
1,11
0,695
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
1
A
B
C
D
Software Development
Requirement
Specifications & Design
Coding
Integration Testing
2
a
b
c
d
On Going Activity
Project Management
Configuration Management
Documentation
Acceptance & Deployment
3
a
b
Total
Quality and Testing
Quality Assurance & Control
Evaluation and Testing
Total
Total
Hours
of
Effort
7,5%
17,5%
10,0%
7,0%
42,0%
725
1691
966
676
4057
7,0%
4,0%
4,0%
6,0%
21,0%
676
483
386
483
2029
12,5%
24,5%
37,0%
1192
2382
3574
B. Biaya per-kelompok aktivitas
Dengan mengacu pada Indonesia Salary Guide 2011/2012
[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
tabel di bawah ini :
Tabel 10 Estimasi Biaya per-Aktivitas Pembuatan ERP
No.
1
a
b
c
d
%
Effort
Hours
of
Effort
Standar
Gaji/jam
(Rp)
Biaya
(org/jam)
(Rp)
7,5%
725
31.250
5.580
17,5%
1691
31.250
13.021
10,0%
966
18.750
4.464
7,0%
676
18.750
3.125
42,0%
4057
7,0%
676
62.500
20.833
4,0%
483
43.750
10.417
4,0%
386
18.750
3.571
6,0%
483
25.000
5.952
Total
Quality and
Testing
Quality
Assurance &
Control
Evaluation and
Testing
21,0%
2029
12,5%
1192
18.750
6.253
24,5%
2382
18.750
12.497
Total
37,0%
3574
Kelompok
Aktivitas
Software
Development
Requirement
Specifications &
Design
Coding
Integration
Testing
Total
2
a
b
c
d
3
a
b
On Going
Activity
Project
Management
Configuration
Management
Documentation
Acceptance &
Deployment
26.190
40.774
18.750
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 :
Software
Development
Ongoing
Activity
Quality and
Testing
Total
Hours of
Effort
Total Biaya
(orang/jam)
(Rp)
Kesimpulan yang dapat diambil dari penelitian ini
yakni sebagai berikut:
1. Pembuatan modul ERP didasarkan pada kebutuhan
fungsional yang tergambar dari proses bisnis masingmasing 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.
DAFTAR PUSTAKA
[1]
[2]
[3]
Tabel 11 Estimasi Biaya Total
Kelompok
Aktivitas
IV. KESIMPULAN/RINGKASAN
Estimasi Biaya
Total (Rp)
[4]
[5]
4057
26.190,00
106.260.000,00
2029
40.774,00
82.713.750,00
[6]
[7]
3574
18.750,00
67.016.250,00
[8]
TOTAL
255.990.000,00
[9]
Suharjito. 2008. Estimasi Usaha Proyek Pengembangan Software Yang
Berorientasi Objek Dengan Use Case Point Metric. Prosiding Seminar
Nasional Sains dan Teknologi-II 2008.
Sarno, R., Buliali, J. L., & Maimunah, S. (2002). Pengembangan
Metode Analogy untuk Estimasi Biaya Rancang Bangun Perangkat
Lunak. Makara, Teknologi, Vol.6, No.2.
Khatibi, V., & Jawawi, D. N. 2010. Software Cost Estimation Methods:
A Review. Emerging Trends in Computing and Information Sciences,
21-29.
Karner, Gustav. 1993. Resource Estimation for Objectory Projects.
Objective Systems SF AB.
Saleh, K. 2011. Effort and Cost Allocation in Medium to Large
Software Development Projects. Intenational Journal of Computers (1),
74-79.
Cohn, Mike. Estimating With Use Case Point.
Jacobson, Ivar et al., Object-Oriented Software Engineering. A Use
Case Driven Approach, revised printing, Addison-Wesley 1993.
M. Ochodek., et al. 2011. Improving the reliability of transaction
identification in use cases. Information and Software Technology 53
(2011) 885–897.
Kelly Service, Inc. Employment Oulook and Salary Guide 2011/12 : A
Tool for Workforce Planning.