ESTIMASI PENENTUAN HARGA PERKIRAAN SENDIRI
MENGGUNAKAN USE CASE POINT UNTUK PENGEMBANGAN PERANGKAT LUNAK SKALA KECIL MENENGAH DENGAN MODEL AGILE
TUGAS AKHIR
Program Studi
S1 Sistem Informasi Kekhususan Komputer Akuntansi
Oleh:
Aris Juliyono 11.41011.0035
FAKULTAS TEKNOLOGI DAN INFORMATIKA
ix
1.5 Sistematika Penulisan ... 6
BAB II LANDASAN TEORI ... 8
2.1 Penelitian Terdahulu ... 8
2.2 Teori Pendukung ... 10
2.2.1 Harga Perkiraan Sendiri (HPS) ... 10
2.2.2 Estimasi Effort ... 15
2.2.3 Use Case Point (UCP) ... 16
2.2.4 Perhitungan Nilai Effort Rate ... 20
2.2.5 Perangkat Lunak ... 21
2.2.6 Skala Perangkat Lunak ... 21
2.2.7 Agile Development ... 22
2.2.8 Analisis Devisiasi Rata-Rata ... 24
BAB III METODE PENELITIAN ... 26
3.1 Studi Literatur ... 27
3.2 Pengumpulan Data ... 27
3.3 Distribusi Effort Peraktivitas ... 30
3.4 Perhitungan Use Case Point ... 31
3.4.1 Perhitungan Unadjusted Use Case Point (UUCP) ... 31
x
3.4.3 Perhitungan Enviromental Complexity Factor (ECF) ... 31
3.5 Penyusunan Harga Perkiraan Sendiri (HPS) ... 32
3.5.1 Biaya Langsung Personil ... 32
3.5.2 Biaya Langsung Non Personil... 33
3.5.3 Pajak Pertambahan Nilai (PPN) ... 33
3.6 Alat Bantu (Tools) ... 33
BAB IV HASIL DAN PEMBAHASAN ... 35
4.1 Penentuan Aktivitas Utama Proyek dengan Model Agile dan Distribusi Effort Peraktivitas ... 35
4.2 Use Case Diagram ... 63
4.3 Perhitungan Use Case Point ... 63
4.3.1 Unadjusted Use Case Point (UUCP) ... 63
4.3.2 Technical Complexity Factor (TCF) ... 65
4.3.3 Environmental Complexity Factor (ECF) ... 67
4.3.4 Use Case Point (UCP) ... 69
4.4 Penyusunan Harga Perkiraan Sendiri ... 69
4.4.1 Biaya Langsung Personil ... 69
4.4.2 Biaya Langsung Non Personil... 73
4.4.3 Pajak Pertambahan Nilai ... 74
4.5 Analisis Deviasi Rata-Rata (Mean Deviation) ... 74
BAB V PENUTUP ... 76
5.1 Kesimpulan Penelitian ... 76
xi
1 1.1 Latar Belakang Masalah
Pada tahun 2015 belanja TI (teknologi infomasi) di Indonesia telah meningkat menjadi Rp 176,3 T, naik 15,1% dari tahun 2014 (BMI research, 2015). Dan salah satu kebutuhan belanja TI tersebut digunakan untuk pengadaan perangkat lunak (software). Pada dasarnya bahwa untuk setiap pelaksanaan pengadaan barang/jasa perlu untuk dibuatkan Harga Perkiraan Sendiri yang merupakan hasil perkiraan (estimasi) harga suatu pekerjaan (barang/jasa) yang akan diadakan, hal ini sesuai dengan Peraturan Presiden Republik Indonesia No. 70 Tahun 2012 Tentang Pengadaan Barang/Jasa, pada Pasal 66 Angka (5) Butir a. Adapun maksud dan tujuan disusunnya HPS adalah supaya harga atau nilai proyek tersebut dalam batas kewajaran dan untuk menetapkan besaran tambahan nilai jaminan pelaksanaan bagi penawaran yang dinilai terlalu rendah.
tersebut maka perlu dibuat acuan dalam penentuan Harga Perkiraan Sendiri (HPS) dalam proyek pengembangan perangkat lunak menggunakan metode yang tepat. Metode yang akan digunakan dalam penelitian ini adalah metode use case point (UCP) karena metode UCP memiliki kemampuan untuk memberikan estimasi effort dan biaya yang diperlukan untuk membuat suatu proyek perangkat lunak
berdasarkan jumlah dan kompleksitas use case yang dimiliki oleh proyek tersebut (Karner, 1993).
Berdasarkan hasil penelitian menunjukkan bahwa metode UCP dapat berhasil digunakan untuk memperkirakan effort pengembangan perangkat lunak dan metode UCP lebih baik dari perkiraan para ahli, berikut hasil penelitian yang telah dilakukan :
1. Perbandingan estimasi effort dengan upaya yan sebenarnya menggunakan metode UCP memiliki deviasi sebesar 19%, sementara estimasi para ahli memiliki deviasi sebesar 20% (Anda, 2002),
2. Penelitian lain menunjukkan terjadi deviasi sebesar 6% (Nageswaran, 2001),
3. Pendapat terkahir menunjukkan terjadi deviasi sebesar 9% (Carroll, 2005).
estimasi effort tersebut, maka dapat dilanjutkan untuk perhitungan selanjutnya, yaitu perhitungan estimasi biaya. Dimana untuk perhitungan estimasi biaya diperlukan persentase aktivitas effort, dimana dalam aktivitas effort 3 kelompok aktivitas yaitu software development, ongoing activity, quality and testing. Masing-masing kelompok tersebut mempunyai segmentasi peran dan presentase nilai effort yang berbeda (Shaleh, 2011).
Pengelompokan sub aktivias di aktivitas software developmnet dalam penelitian ini akan menggunakan model agile, dimana dalam agile software development interaksi dan personel lebih penting daripada proses dan alat,
software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting daripada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana (Ambler, 2001). Agile software development mempunyai kelebihan yaitu :
1. 82% menambah produktivitas tim,
2. 77% menambah kualitas perangkat lunak, 3. 78% menambah kepuasan klien,
4. 37% menghemat biaya (Silvelburg, 2002).
Setelah diketahui persentase aktivitas effort maka bisa dilakukan perhitungan estimasi biaya dengan mengkalikannya dengan estimasi effort. Langkah terakhir yaitu dapat dilakukan perhitungan Total Biaya HPS dalam proyek pengembangan perangkat lunak.
dalam pengembangan perangkat lunak skala kecil menengah di Indonesia. Dalam beberapa penelitian yang terjadi menggunakan dasar penentuan sub aktivitas pengembangan perangkat lunak berdasarkan penelitian milik Shaleh, dimana penelitian milik Shaleh subaktivitas yang digunakan untuk pengembangan perangkat lunak adalah skala menengah ke besar. Berdasarkan penjabaran tersebut perlunya dibuat penentuan sub aktivitas dan Harga Perkiraan Sendiri (HPS) pengembangan perangkat lunak skala kecil menegah di Indonesia dengan aktivitas utama mengacu pada penelitian milik Shaleh.
Oleh karena itu penelitian ini mengangkat topik estimasi penentuan HPS menggunakan UCP untuk pengembangan perangkat lunak skala kecil menengah dengan model agile. Hasil dari penelitian ini yaitu mengetahui tingkat akurasi model perhitungan estimasi dalam penentuan HPS, jika tingkat akurasi model perhitungan tinggi maka dapat dijadikan acuan bagi pemerintah, perusahaan perorangan maupun badan usaha dan pengembang perangkat lunak untuk melakukan estimasi HPS dalam proyek pengembangan perangkat lunak di masa mendatang.
1.2 Rumusan Masalah
Berdasarkan latar belakang yang sudah dijelaskan maka rumusan masalah pada penelitian ini adalah, sebagai berikut :
1. Apa saja aktivitas pengembangan perangkat lunak skala kecil menengah dengan model agile?
3. Berapa nilai effort untuk masing-masing proyek pengembangan perangkat lunak skala kecil menengah dengan model agile?
4. Apa saja komponen HPS untuk pengembangan perangkat lunak skala kecil menengah dengan model agile?
5. Berapakah nilai HPS untuk studi kasus pengembangan perangkat lunak skala kecil menengah dengan model agile?
1.3 Batasan Masalah
Berdasarkan rumusan masalah di atas maka dalam pembuatan Tugas Akhir ini, ruang lingkup permasalahan hanya akan dibatasi pada :
1. Penelitian ini bertujuan untuk penentuan estimasi nilai HPS terhadap proyek pengembangan perangkat lunak skala kecil menengah tidak untuk pengembangan perangkat lunak skala menengah keatas.
2. Penelitian ini hanya menggunakan 5 data sebagai bahan penelitian.
3. Penelitian ini hanya menganalisis kebutuhan berdasarkan aktivitas proyek pengembangan perangkat lunak.
4. Penentuan standar gaji dan biaya langsung personil yang dipakai mengacu pada Inkindo 2014.
1.4 Tujuan
Berdasarkan rumusan masalah di atas, maka tujuan dari penyusunan Tugas Akhir ini, yaitu : Mengetahui nilai HPS menggunakan UCP untuk studi kasus pengembangan perangkat lunak skala kecil menengah dengan model Agile.
Tujuan pada penelitian ini diturunkan menjadi 5 sub tujuan, antara lain : 1. Mengetahui dan mengklasifikasikan aktivitas pengembangan
perangkat lunak skala kecil menengah dengan model agile.
2. Menghasilkan distribusi effort untuk pengembangan perangkat lunak skala kecil menengah dengan model agile.
3. Menghasilkan nilai effort untuk masing-masing proyek pengembangan perangkat lunak skala kecil menengah dengan model agile.
4. Mengetahui komponen HPS untuk pengembangan perangkat lunak skala kecil menengah dengan model agile.
5. Menghasilkan nilai HPS untuk studi kasus pengembangan perangkat lunak skala kecil menengah dengan model agile.
1.5 Sistematika Penulisan
Laporan Tugas Akhir ini ditulis berdasarkan sitematika penulisan sebagai berikut :
BAB I : PENDAHULUAN
Pada bab ini berisi uraian latar belakang, rumusan masalah, batasan masalah, tujuan tugas akhir, dan sistematika penulisan.
BAB II : LANDASAN TEORI
BAB III : METODE PENELITIAN
Pada bab ini akan dijelaskan metode penelitian yaitu tahapan-tahapan yang dijalankan dalam pengerjaan tugas akhir.
BAB IV : HASIL DAN PEMBAHASAN
Pada bab ini akan dicantumkan hasil dari proses yang dijalankan tiap tahapnya sesuai dengan metode penelitian. Pembahasan terhadap hasil yang diperoleh digunakan untuk menjawab rumusan masalah yang diangkat dalam tugas akhir ini.
BAB V : PENUTUP
8
LANDASAN TEORI
Pada bab ini dijelaskan mengenai teori-teori dan penelitian terdahulu yang terkait dalam pengerjaan tugas akhir ini.
2.1 Penelitian Terdahulu
2.1.1 Penelitian Kelompok Aktivitas Pengembangan Perangkat Lunak Sebelumnya
Aktivitas SDLC (Software Development Life Cycle) memiliki beberapa tahapan/aktivitas utama yaitu: analisis kebutuhan dan spesifikasi, arsitektur, desain, membangun dan menguji unit, serta uji integrasi sistem. Selain itu terdapat sumber daya manusia (tim proyek) yang memiliki peran penting untuk setiap aktivitas proyek meliputi: Project Manager, Technical Architect, Business Analyst, Programers dan Testers (Parthasarathy, 2007).
Aktivitas pengembangan perangkat lunak dikelompokkan menjadi tiga aktivitas utama dan ditambahkan effort disetiap aktivitasnya sebagai berikut (Shaleh, 2011):
a. Ongoing Activity
b. Software Development
Aktivitas ini akan mengkoordinir aktivitas pembangunan perangkat lunak berupa kebutuhan perangkat lunak, spesifikasi perangkat lunak, desain serta implementasi (pengkodean), terhitung 42 % dari total effort.
c. Quality & testing
Aktivitas ini merupakan aktivitas yang biasanya ada setelah dua aktivitas sebelumnya dikerjakan. Aktivitas ini akan mengkoordinir aktivitas pengujian terintegrasi, penjaminan kualitas serta evaluasi, terhitung 37 % dari total effort.
Untuk lebih jelasnya, presentase nilai effort tersebut dapat dilihat pada tabel 2.1. Seperti berikut :
Tabel 2. 1 Pembagian Kelompok Aktivitas Pembuatan Proyek No Kelompok Aktivitas %Effort
1 Software Development
a Requirement 7,5%
b Specification & Design 17,5%
c Coding 10,0%
d Integration Testing 7,0%
Total 42,0%
d Acceptance & Deployment 6,0%
Total 21,0%
3 Quality & Testing a Quality Assurance &
Control 12,5%
b Evaluation & Testing 24,5%
Dari penelitian diatas, maka dapat disimpulkan bahwa pengelompokan aktivitas pengembangan yang perangkat lunak yang dilakukan oleh Shaleh terdapat 3 aktivitas utama yang masing-maing mempunyai segementasi peran dan presentase effort disetiap aktivitasnya. Namun dalam penelitian tersebut pengelompokan aktivitas pengembangan perangkat lunak yang dilakukan oleh Shaleh mempunyai segmentasi peran dan persentase effort untuk pengembangan perangkat lunak skala menengah ke besar, sedangkan dalam penelitian ini segmentasi peran dan persentase effort yang digunakan yaitu skala kecil ke menengah. Maka dari itu penelitian terdahulu tersebut perlu dilakukan penyesuaian terhadap penelitian yang akan dilakukan.
2.2 Teori Pendukung
2.2.1 Harga Perkiraan Sendiri (HPS)
HPS merupakan total harga yang diperkirakan cukup untuk membiayai pekerjaan yang akan dilaksanakan dalam pengadaan barang/jasa, dan ditetapkan oleh PPK, kecuali untuk Kontes/Sayembara.
Nilai total HPS sebagaimana tersebut diatas adalah hasil perhitungan seluruh volume pekerjaan dikalikan dengan Harga Satuan ditambah dengan seluruh beban pajak dan keuntungan. HPS disusun paling lama 28 (dua puluh delapan) hari kerja sebelumbatas akhir pemasukan penawaran. Dalam proses pemilihan penyedia barang/jasa, ULP/PP menggunakan HPS sebagai :
1. Alat untuk menilai kewajaran harga penawaran termasuk rinciannya,
3. Dasar untuk menetapkan besaran nilai Jaminan Pelaksanaan bagi penawaran yang nilainya lebih rendah dari 80% (delapan puluh perseratus) nilai total HPS.
HPS bukan sebagai dasar untuk menentukan besaran kerugian negara. Penyusunan HPS didasarkan pada data harga pasar setempat, yang diperoleh berdasarkan hasil survei menjelang dilaksanakannya pengadaan, dengan mempertimbangkan informasi yang meliputi :
1. Informasi biaya satuan yang dipublikasikan secara resmi oleh Badan Pusat Statistik (BPS),
2. Informasi biaya satuan yang dipublikasikan secara resmi oleh asosiasi terkait dan sumber data lain yang dapat dipertanggung jawabkan,
3. Daftar biaya/tarif barang/jasa yang dikeluarkan oleh pabrikan/distributor tunggal dan instansi yang berwenang,
4. Biaya kontrak sebelumnya atau yang sedang berjalan dengan mempertimbangkan faktor perubahan biaya,
5. Inflasi tahun sebelumnya, suku bunga berjalan dan/atau kurs tengah Bank Indonesia,
6. Hasil perbandingan dengan Kontrak sejenis, baik yang dilakukan dengan instansi lain maupun pihak lain,
7. Perkiraan perhitungan biaya yang dilakukan oleh konsultan perencana (engineer’s estimate),
8. Norma indeks; dan/atau,
HPS disusun dengan memperhitungkan keuntungan dan biaya overhead yang dianggap wajar, antara lain untuk kebutuhan dalam penerapan manajemen Keselamatan dan Kesehatan Kerja (K3) serta penerapan manajemen mutu (LKPP, 2012).
Komponen Harga Perkiraan Sendiri (HPS) untuk pengembangan perangkat lunak terdiri dari biaya-biaya, sebagai berikut :
1. Biaya Lagsung Personil (Remunerasi)
a. Biaya untuk pengadaan tenaga ahli (Professional staff), asisten tenaga ahli (sub professional staff) dan tenaga pendukung (supporting staff);
b. Biaya Langsung personil dihitung berdasarkan jumlah orang bulan (man month) dari masing-masing tenaga ahli, asisten tenaga ahli, dan tenaga
pendukung yang diperlukan;
c. Harga Satuan untuk biaya tenaga ahli, asisten tenaga ahli ditentukan berdasarkan tingkat pendidikan dan lamanya pengalaman sesuai bidang keahlian masing-masing tenaga ahli, dan mengikuti harga pasar (LKKP, 2012).
Perhitungan Konersi Minuimum Biaya Langsung Personil menurut satuan waktu adalah sebagai berikut :
SBOM = SBOB / 4.1 SBOH = (SBOB / 22) x 1.1 SBOJ = (SBOH / 8) x 1.3 Catatan :
SBOH = Satuan Biaya Orang Hari (Person Day Rate) SBOJ = Satuan Biaya Orang Jam (Person Hour Rate)
Perhitungan Biaya Langsung Personil (BLP) dilakukan sebagai berikut : BLP = GD + BBS + BBU + T + K
Dimana :
GD = Gaji Dasar (Basic Salary)
BBS = Beban Biaya Sosial (Social Cost) BBU = Beban Biaya Umum (Overhead Cost) T = Tunjangan (Allowance)
K = Keuntungan (Profit) (Inkindo, 2014). 2. Biaya Langsung Non Personil
Biaya Langsung Non Personil adalah biaya lansung yang diperlukan untuk menunjang pelaksanaan kegiatan proyek yang dibuat dengan mempertimbangkan dan berdasarkan Harga Pokok Pasar yang wajar dan dapat dipertanggungjawabkan sera sesuai dengan perkiraan kegiatan. Biaya Langsung Non Personil ini terdiri dari 3 (tiga) komponen yaitu :
a. Reimbusable adalah biaya yang dapat diganti yang sebenarnya
dikeluarkan oleh konsultan untuk pengeluaran-pengeluaran yang sesungguhnya (at cost) dan kegiatan yang ditetapkan, seperti :
- Dokumen Perjalanan ke Luar Negeri - Tiket Penerbangan
- Kelebihan Bagasi (Excess Baggage)
- Biaya Pembelian Kebutuhan Proyek - Biaya Instalasi Telepon / Internet
b. Fixed Unit Rate adalah biaya yang sebenarnya dikeluarkan oleh konsultan berdasarkan harga satuan yang pasti dan tetap untuk setiap item/unsur pekerjaan dengan volume yang diperkirakan, seperti :
-
Sewa Kendaraan dan O&M-
Sewa Kantor Proyek-
Sewa Peralatan Kantor-
Sewa Furniture Kantor-
Biaya Operasional Kantor Proyek-
Biaya ATK (Office Consumables)-
Biaya Komputer & Printer Consumables-
Biaya Komunikasi-
Tunjangan Harian (Per Diem Allowance)-
Tunjangan Perumahan (Housing Allowance)-
Penempatan Sementara (Temporary Lodging)-
Tunjangan Penempatan (Relocation Allowance)-
Tunjangan Tugas Luar (Out of Station Allowance / OSA)-
Penginapan Tugas Luar-
Cuti Tahunan (Annual Leave)c. Lump Sum adalah biaya satuan atau beberapa item/unsur pekerjaan dalam batas waktu teretentu, dengan jumlah harga yang pasti dan tetap serta dibayarkan sekaligus, seperti :
-
Pengumpulan Data Sekunder-
Seminar, Workshop, Sosialisasi, Training, Desiminasi, Loka Karya, Diskusi, Koordinasi antar Instansi, FGD (Focus Group Discussion)-
Survey-
Biaya Test Laboratorium-
dst. nya3. Pajak Pertambahan Nilai (PPN) (Inkindo, 2014).
2.2.2 Estimasi Effort
Salah satu aspek terpenting dalam tahapan perencanaan adalah melakukan estimasi atau perkiraan, baik dari segi biaya, waktu maupun sumber daya. Definisi dari estimasi adalah sebuah pengukuran yang didasarkan pada hasil secara kuantitatif atau dapat diukur dengan angka tingkat akurasinya (Tockey, 2004).
Sisi penting estimasi dalam perencanaan proyek adalah munculnya jadwal serta anggaran yang tepat, meski tidak sepenuhnya sebuah estimasi akan berakhir dengan tepat. Tetapi, tanpa sebuah estimasi dalam pelaksanaan proyek perangkat lunak maka dapat dikatakan bahwa proyek perangkat lunak tersebut adalah sebuah blind project. Yang diibaratkan seperti seorang buta yang harus berjalan di sebuah jalan raya yang sangat ramai (Rizky, 2011).
melakukan prediksi atau ramalan mengenai keluaran dari sebuah proyek dengan meninjau jadwal, usaha, biaya bahkan hingga ke resiko yang akan ditanggung dalam proyek tersebut (Galorath, 2006). Meski estimasi tidak mungkin dapat menghasilkan sebuah hasil yang sangat akurat, tetapi ketidakakuratan tersebut dapat diminimalkan dengan menggunakan beberapa metode yang sesuai dengan proyek yang akan dilakukan estimasi.
Effort (usaha) dari sebuah proyek pengembangan perangkat lunak dapat didefinisikan sebagai waktu yang dikonsumsi oleh proyek yang dinyatakan dengan hitungan orang dalam jam, hari, bulan atau tahun tergantung pada ukuran proyek, sebagai contoh adalah effort = people * time (Chatters,1999) dalam (Haapio, 2011).
Dari pengertian estimasi dan effort di atas, maka dapat disimpulkan bahwa estimasi effort adalah suatu kegiatan melakukan prediksi atau ramalan mengenai berapa banyak pekerja dan berapa lama waktu yang diperlukan untuk menyelesaikan proyek tersebut. Estimasi effort pada penelitian ini akan didapatkan setelah melakukan perhitungan menggunakan metode use case point (UCP).
2.2.3 Use Case Point (UCP)
Kelebihan dari metode use case point yaitu dapat memberikan estimasi yang hampir mendekati estimasi sebenarnya yang dihasilkan dari pengalaman pembuatan atau pengembangan software. Hal tersebut dibuktikan oleh beberapa penelitian yang pernah dilakukan sebelumnya, dan menghasilkan pernyataan sebagai berikut:
1. UCP memiliki deviasi sebesar 6% (Nageswaran, 2001),
2. UCP memiliki deviasi sebesar 19%, sementara estimasi para ahli memiliki deviasi sebesar 20% (Anda, 2002),
3. UCP memiliki deviasi sebesar 9% (Carroll, 2005).
Langkah-langkah yang dilakukan dalam proses estimasi effort dengan use case point digambarkan dalam gambar 2.1. berikut ini (Karner, 1993) :
Gambar 2. 1 Langkah-langkah Metode Use Case Point (UCP) 2.2.3.1.1 Unadjusted Actor Weights (UAW)
Tabel 2. 2 Tipe, Bobot, dan Deskripsi Actor
Actor Weight Description
Simple 1 Didefinisikan degan API
Medium 2 Berinteraksi dengan protokol TCP/IP Complex 3 Berinteraksi dengan GUI atau Web Page
Total Unadjusted Actor Weights (UAW) didapat dari menghitung jumlah actor dari masing-masing jenis (tingkat kompleksitas), dikali dengan total faktor
berat masing-masing sesuai dengan tabel.
2.2.3.1.2 Unadjusted Use Case Weights (UUCW)
Cara menghitung UUCW sama dengan cara menghitung UAW, yaitu masing-masing use case dibagi menjadi 3 kelompok yaitu simple, average, dan complex, tergantung dari jumlah transaksi yang dilakukan. Untuk penjelasan lebih
detil tentang deskripsi use case dapat dilihat pada tabel 2.3. seperti berikut : Tabel 2. 3 Tipe, Bobot, dan Deskripsi Use Case
Use Case Weight Description
Simple 5 Menggunakan <=3 transaksi Medium 10 Menggunakan 4 sampai 7 transaksi Complex 15 Menggunakan >7 transaksi
Total Unadjusted Use Case Weights (UUCW) didapat dari menghitung jumlah use case dari masing-masing tingkat kompleksitas dikali dengan total faktor setiap use case. Kemudian jumlahkan UAW dan UUCW untuk mendapatkan Unadjusted Use Case Point (UUCP), seperti rumus berikut :
2.2.3.2 Menghitung Technical Complexity Factor (TCF) dan Enviromental Complexity Factor (ECF)
Pada perhitungan nilai Use Case Point (UCP) terdapat nilai complexity factor. Pengertian dari complexity factor adalah faktor-faktor yang berpengaruh
secara langsung dalam proses pengerjaan proyek perangkat lunak tersebut. Complexity factor dibagi menjadi 2 kelompok, yaitu :
1. Technical Complexity Factor (TCF)
2. Environmental Complexity Factor (ECF)
Berikut penjelasan masing-masing dari complexity factor : 2.2.3.2.1 Technical Complexity Factor (TCF)
Tabel 2. 4 Technical Factor dan Bobot
Technical Factor Bobot
1 Distributed System Required 2
2 Response time is Important 1
3 End User Effficiency 1
4 Complex Internal Processing Required 1 5 Reusable Code Must Be a Focus 1
6 Installation Easy 0.5
7 Usability 0.5
8 Cross-Platform Support 2
9 Easy to Change 1
10 Highly Concurrent 1
11 Custom Security 1
12 Dependence on Third-part Code 1
13 User Training 1
Technical Factor (TF), yang kemudian digunakan untuk mendapatkan Technical
Complexity Factor (TCF).
TCF = 0.6 + (0.01*TF)
2.2.3.2.2 Environmental Complexity Factor (ECF)
Tabel 2. 5 Environmental Factor dan Bobot
Environmental Factor Bobot
1 Familiarity with the Project 1.5
2 Application Experience 0.5
3 OO Programming Experience 1
4 Lead Analyst Capability 0.5
5 Motivation 1
6 Stable Requirements 2
7 Part Time Staff -1
8 Difficult Programming Language -1
Nilai-nilai pada environmental factor tersebut dikalikan dengan bobot nilai masing-masing. Bobot nilai yang diberikan pada setiap factor tergantung dari seberapa besar pengaruh dari faktor tersebut. 0 berarti tidak mempengaruhi, 3 berarti rata-rata, dan 5 berarti memberikan pengaruh yang besar. Hasil perkalian nilai dan bobot tersebut kemudian dijumlahkan untuk mendapatkan total Environmental Factor (EF), yang kemudian digunakan untuk mendapatkan
Environmental Complexity Factor (ECF).
ECF = 1.4 + (-0.03x EF)
Sehingga akhirnya kita bisa mendapatkan nilai dari Use Case Point (UCP) yang didapatkan melalui perkalian UUCP, TCF, dan ECF.
2.2.4 Perhitungan Nilai Effort Rate
Effort rate didefinisikan sebagai jumlah usaha per use case point.
Pendekatan yang dijelaskan bersifat umum dan dapat digunakan untuk menganalisa berbagai data, tidak hanya data untuk pengembangan perangkat lunak, tetapi juga data pemeliharaan perangkat lunak dan jenis lain dari rekayasa perangkat lunak (Stewart, 2002).
Effort rate adalah rasio jumlah jam orang per use case point berdasarkan
proyek-proyek di masa lalu. Jika proyek tersebut merupakan proyek baru dan tidak terdapat data histori yang telah terkumpul, maka digunakan nilai yang berkisar antara 15 sampai 30. Namun, nilai yang paling sering dipakai adalah angka 20 (Clemmons, 2006).
Rumus perhitungan estimasi effort menggunakan metode UCP adalah sebagai berikut :
Estimasi Effort = UCP x ER
Apabila nilai ER dihitung dari satu proyek saja maka nilai ER didapatkan dari pembagian antara nilai actual effort dengan nilai UCP, sebagai berikut :
Effort Rate = Actual Effort/UCP
2.2.5 Perangkat Lunak
2.2.6 Skala Perangkat Lunak
Ukuran atau skala dari proyek perangkat lunak diperkirakan berdasarkan beberapa parameter, yaitu jumlah programmer, durasi waktu penyelesaian, dan jumlah baris kode (Donna, 2006). Kategori dalam ukuran proyek perangkat lunak dapat dilihat pada tabel 2.6 sebagai berikut :
Tabel 2. 6 Ukuran Proyek Perangkat Lunak No Category ∑Programmer Time
Required ∑Lines
Kata Agile berarti bersifat cepat, ringan, bebas bergerak, waspada. Kata ini digunakan sebagai kata yang mengambarkan konsep model proses yang berbeda dari konsep model-model proses yang sudah ada (Beck, 2000). Konsep Agile Software Development dicetuskan oleh Kent Beck dan 16 rekannya.
Dalam Agile Software Development interaksi dan personel lebih penting dari pada proses dan alat, software yang berfungsi lebih penting daripada dokumentasi yang lengkap, kolaborasi dengan klien lebih penting dari pada negosiasi kontrak, dan sikap tanggap terhadap perubahan lebih penting daripada mengikuti rencana. Namun demikian, sama seperti model proses yang lain, Agile Software Development memiliki kelebihan dan tidak cocok untuk semua jenis
model proses yang toleransi terhadap perubahan kebutuhan sehingga perubahan dapat cepat ditanggapi.
Agile Software Development juga melihat pentingnya komunikasi antara
anggota tim, antara orang-orang teknis dan businessman, antara developer dan managernya. Ciri lain adalah klien menjadi bagian dari tim pembangun software. Ciri-ciri ini didukung oleh 12 prinsip yang ditetapkan oleh Agile Alliance. Menurut Agile Alliance, 12 prinsip ini adalah bagi mereka yang ingin berhasil dalam penerapan Agile Software Development (Ambler, 2001) :
1. Prioritas tertinggiadalah memuaskan pelanggan melaluipenyerahan awal dan berkelanjutan perangkat lunak yang bernilai,
2. Menerima perubahan requirements meskipun perubahan tersebut diminta pada akhir pengembangan,
3. Memberikan perangkat lunak yang sedang dikerjakan dengan sering, beberapa minggu atau beberapa bulan, dengan pilihan waktu yang paling singkat,
4. Pihak bisnis dan pengembang harus bekerja sama setiap hari selama pengembangan berjalan,
5. Bangun proyek bersama individu-individu yang bermotivasi tinggi dengan memberikan lingkungan dan dukungan yang diperlukan, dan mempercayai mereka sepenuhnya untuk menyelesaikan pekerjaannya,
8. Proses agile memberikan proses pengembangan yang bisa ditopang. Sponsor, pengembang, dan user harus bisa menjaga ke-konstanan langkah yang tidak pasti,
9. Perhatian yang terus menerus terhadap rancangan dan teknik yang baik meningkatkan agility,
10.Kesederhanaan seni untuk meminimalkan jumlah pekerjaan adalah penting, 11.Arsitektur, requirements, dan rancangan terbaik muncul dari tim yang
mengatur sendiri,
12.Pada interval reguler tertentu, tim merefleksikan bagaimana menjadi lebih efektif, kemudian menyesuaikannya.
Model-model proses yang termasuk agile process model :
1. Extreme Programming (XP),
2. Adaptive Software Development (ASD),
3. Dynamic Systems Development Method,
4. Scrum,
5. Agile Modeling.
Gambar 2. 2 Aktivitas dalam Agile Development
2.2.8 Analisis Devisiasi Rata-Rata
Deviasi rata (Mean Deviation atau Average Deviation) adalah rata-rata dari deviasi nilai-nilai dari mean dala suatu distribusi, diambil nilainya yang absolute. Yang dimaksut dengan deviasi absolute adalah nilai-nilai yang negatif.
Secara aritmatika mean deviasi dapat didefinisikan sebagai mean dari harga mutlak dari deviasi nilai-nilai individual.
deviasi tanda minus ditiadakan. Dalam statistika, deviasi diberi simbol dengan huruf-huruf kecil seperi x, y, d, dan sebagainya. Rumus adalah x = X – M atau y = Y – M, d = D – M, dan sebagainya.
Adapun rumus dari Mean deviasi adalah sebagai berikut (Samsudi, 2008) :
Dimana : MD = Mean Deviasi
26
Metode penelitian ini diperlukan sebagai panduan agar tahapan pengerjaan penelitian tugas akhir ini dapat berjalan secara terarah dan sistematis. Adapun tahapan pengerjaan penelitian tugas akhir ditunjukkan melalui gambar 3.1, seperti berikut :
3.1 Studi Literatur
Studi literatur ini dilakukan untuk memperoleh dan lebih memahami teori-teori yang berhubungan dengan pemecahan masalah. Selain itu juga untuk mengetahui penelitian-penelitian terdahulu yang telah dilakukan untuk menyakinkan bahwa yang diteliti saat ini belum pernah dilakukan atau merupakan pengembangan dari penelitian terdahulu. Adapun konsep utama yang dibutuhkan dalam penelitian ini yaitu konsep menganai aktivitas pengembangan perangkat lunak dan konsep mengenai komponen HPS. Output dari studi literatur ini adalah terkoleksinya referensi yang relefan dengan perumusan masalah.
3.2 Pengumpulan Data
Pada tahapan ini akan dilakukan pengumpulan data dengan cara wawancara dan survei. Pengumpulan data dilakukan untuk mendapatkan data-data yang dibutuhkan dalam pengerjaan tugas akhir ini. Data yang dibutuhkan dalam tugas akhir ini meliputi jumlah pegawai dan jumlah waktu, daftar kebutuhan perangkat lunak, nilai Technical Complexity Factor (TCF) dan Enviromental Complexity Factor (ECF) berikut penjelasannya :
Gambar 3. 2 Desain kuesioner
2. Daftar kebutuhan pengembangan perangkat lunak yaitu daftar yang berisi data use case dan actor yang terlibat dalam proses pengembangan perangkat lunak.
Daftar kebutuhan perangkat lunak diperoleh langsung dari tim pengembang perangkat lunak skala kecil menengah yang diteliti oleh penulis pada Tugas akhir ini.
Gambar 3. 4 Desain kuesioner Enviromental Complexity Factor (ECF)
3.3 Distribusi Effort Peraktivitas
Effort (usaha) dari sebuah proyek pengembangan perangkat lunak dapat
Pada tahap ini akan dilakukan pendistribusian persentase nilai effort, tapi sebelum itu terlebih dahulu harus dikatehui nilai actual effort dalam pengembangan perangkat lunak dengan rumus sebagai berikut :
Actual Effort = ∑ Pekerja x ∑ Waktu
Setelah dikatahui nilai actual effort dapat dilakukan pendistribusian nilai persentase effort ke dalam masing-masing aktivitas pengembangan perangkat lunak skala kecil menengah dengan rumus sebagai berikut :
Distribusi % effort peraktivitas = nilai actual effort peraktivitas/total actual effort x 100%
3.4 Perhitungan Use Case Point
3.4.1 Perhitungan Unadjusted Use Case Point (UUCP)
Untuk mendapatkan nilai unadjusted use case point, maka perlu dilakukan pembobotan dan skoring terkait kompleksitas actor dan use case ditinjau dari use case diagram yang telah didapatkan dari tim pengembang perangkat lunak.
Skoring dihitung berdasarkan parameter-parameter yang telah ditentukan.
3.4.2 Perhitungan Technical Complexity Factor (TCF)
3.4.3 Perhitungan Enviromental Complexity Factor (ECF)
Dalam perhitungan nilai environmental complexity factor juga diperlukan nilai dari kuisioner yang telah dibagikan kepada pihak pengembang. Hasil dari kuisioner tersebut kemudian dikalikan dengan masing-masing bobot pada faktor environmental complexity factor sesuai dengan ketentuan yang ada. Kemudian
dilakukan perhitungan environmental complexity factor sesuai dengan rumus yang sudah ditentukan.
3.5 Penyusunan Harga Perkiraan Sendiri (HPS) 3.5.1 Biaya Langsung Personil
Setelah mengetahui nilai dari persentase aktivitas effort dan nilai UCP maka selanjutnya nilai UCP yang dijadikan ke dalam nilai effort atau estimasi effort, dengan rumus sebagai berikut :
Estimasi Effort = UCP x Effort Rate
Nilai Effort Rate (ER) atau staff-hour per use case point yang digunakan adalah 20 staff-hour (Karner, 1993).
Setelah mendapatkan nilai estimasi effort, maka nilai estimasi effort akan dibagi ke dalam segementasi peran dalam tiap kelompok aktivitas pengembangan perangkat lunak skala kecil menengah dengan rumus sebagai berikut :
Estimasi effort peraktivitas = %Aktivitas effort x Estimasi effort
Jika estimasi effort peraktivitas sudah diketahui maka biaya langsung personil dapat disusun. Penyusunan biaya langsung personil perkativitas dapat dilakukan dengan rumus sebagai berikut :
Untuk standar biaya/tarif personil menggunakan faktor sosial ekonomi yang dikeluarkan pemerintah tahun 2013 dan sebagian tahun 2014 yang mengacu pada INKINDO. Setelah biaya langsung personil peraktivitas diketahui, maka selanjutnya akan dihitung total dari kebutuhan biaya langsung personil dengan rumus sebagai berikut :
Total biaya langsung personil = ∑ Biaya langsung personil perkativitas 3.5.2 Biaya Langsung Non Personil
Biaya langsung Non Personil adalah biaya langsung yang diperlukan untuk menunjang pelaksanaan kegiatan proyek yang dibuat dengan mempertimbangkan dan berdasarkan Harga Pasar yang wajar dan dapat dipertanggung jawabkan serta sesuai dengan perkiraan kegiatan (Inkindo, 2014).
Untuk mendapatkan total biaya langsung non personil, terlebih dahulu harus mengetahui volume atau waktu dari masing-masing kegiatan, kemudian dapat dihitung dengan rumus sebagai berikut :
Biaya Langsung Non Personil = Volume/waktu x biaya satuan
Setelah direkap biaya satuan dari masing-masing komponen biaya non personil, maka akan mendapatkan total biaya langsung non personil. Acuan untuk menentukan biaya satuan biaya non personil menggunakan acuan dari Inkindo. 3.5.3 Pajak Pertambahan Nilai (PPN)
Setelah total biaya langsung personil dan biaya langsung non personil diketahui maka kedua biaya tersebut di jumlahkan dan akan mendapatkan nilai dari HPS sebelum pajak. Untuk mendapatkan nilai HPS setelah pajak maka harus dilakukan perhitungan dengan rumus sebagai berikut :
3.6 Alat Bantu (Tools)
Untuk memudahkan proses estimasi harga perkiraan sendiri, maka dibuatlah prototype alat bantu dengan menggunakan Microsoft Excel berupa tabel hitung. Tabel hitung merupakan halaman yang diperlukan dari awal proses perhitungan sampai akhir proses perhitungan hingga akhirnya menghasilkan keluaran yang sesuai. Berikut merupakan jenis tabel hitung yang dipersiapkan :
1. Tabel hitung Distribusi Effort 2. Tabel hitung UUCP
3. Tabel hitung TCF 4. Tabel hitung ECF
5. Tabel hitung Estimasi Effort 6. Tabel hitung Biaya Langsung
76 PENUTUP
Bab ini berisi kesimpulan dari keseluruhan permasalahan penelitian tugas akhir dan saran perbaikan yang dapat dikembangkan di masa mendatang.
5.1 Kesimpulan Penelitian
Kesimpulan yang dapat diambil dari pengerjaan tugas akhir ini yakni sebagai berikut :
1. Klasifikasi aktivitas pengembangan perangkat lunak skala kecil menengah dalam tugas akhir ini menggunakan model Agile, dimana aktivitas utama terdiri dari aktivitas penggalian kebutuhan (envisioning) dan Iteration Development yang mempunyai sub aktivitas Iterasi Pemodelan, Model Storming, dan Implementasi via Test Driven Development.
2. Nilai distribusi effort untuk pengembangan perangkat lunak skala kecil menengah dalam tugas akhir ini untuk aktivitas utama yaitu Software Development 66.8%, On Going Activity 23.9%, dan Quality and Testing
9.5%
3. Nilai Effort untuk masing-masing proyek pengembangan perangkat lunak dalam tugas akhir ini diketahui untuk Proyek A effort 6160, Proyek B effort 5240, Proyek C effort 3760, Proyek D effort 3880, dan Proyek E
effort 3240.
5. Nilai HPS dalam pengembangan perangkat lunak skala kecil menengah dalam tugas akhir ini untuk masing-masing proyek yaitu Proyek A sebesar Rp. 842.232.940, Proyek B sebesar Rp. 716.444.904, Proyek C sebesar 514.090.236, Proyek D Rp. 530.497.372, dan Proyek E sebesar Rp.442.992.650.
5.2 Saran
Beberapa hal yang diharapkan dapat dikembangkan untuk penelitian dimasa mendatang, yaitu :
1. Penelitian ini menggunakan model agile dalam penentuan aktivitas utama pengembangan perangkat lunak di fase pengembangan, untuk penelitian selanjutnya disarankan dapat menggunakan model lainnya dalam penentuan aktivitas pengembangan perangkat lunak.
2. Penelitian ini dalam penentuan estimasi HPS menggunakan metode Use Case Point, untuk penelitian selanjutnya disarankan dapat menggunakan
metode yang lainnya agar dapat mengetahui tingkat perbedaan biaya yang ada dalam penentuan HPS.
DAFTAR PUSTAKA
Amsyah, Zulkifi. 2005. Manajemen Sistem Informasi. Gramedia Pustaka Utama. Jakarta
Anda, B. 2002. Comparing Effort Estimates Based on Use Case with Expert Estimates. Empirical Asessment in Software Engineering (EASE), (p. 13). Keele UK.
Beck, Kent., Jeffries, Ron., and Ward Cunningham. 2000. Extreme Programming: Embrace Change. Addison-Wesley.
BMI Research. 2015. Indonesia Information Technology Report publish 11 July
2015. Online :
http://store.bmiresearch.com/indonesia-information-technology-report.html. Diakses pada tanggal 13 Juli 2015.
Bull Survey. 1998. Failure Causes. Online :
http://www.itcortex.com/Stat_Failure_Cause.htm#surveys. Diakses pada tanggal 13 Juli 2015
Carroll, Edward R. 2005. Estimating Software Based on Use Case Points. ObjectOriented, Programming, Systems, Languages, and Object Oriented
Programming Systems Languages and Applications (OOPSLA)
Conference 20th : 257-265.
Clemmons, Roy K. 2006. Project Estimation With Use Case Point. Diversified Technical Services, Inc. San Antonio, Texas
Damodaran, Mel. 2002. Estimation Using Use Case Points. Computer Science Program, University of Houston-Victoria.
da Silva, Caio Monteiro Barbosa., Loubach, Denis Silva., da Cunha, Adilson Marques. 2008. An Estimation Model to Measure Computer Systems Development Based on Hardware and Software. Digital Avionics Systems Conference, IEEE/AIAA 28th : 6.C.2-1 - 6.C.2-12.
Donna L, Johnson. 2006. The LOGOS Trailored CMM for Small Business, Small Organizations, and Small Projects. LOGOS Internasional, IncNashville
Frohnhoff, S. 2008. Revised Use Case Point Method-Effort Estimation in Development Projects for Business Applications. Offenbach. Jerman.
Haapio, Topi. 2011. Improving Effort Management in Software Development Project. University of Eastern Finland. Finlandia.
Ikatan Nasional Konsultasi Indonesia (INKINDO). 2014. Pedoman standar Minimal 2014 Biaya Langsung Personil dan Biaya Langsung Non
Personil untuk Kegiatan Jasa Konsultasi. Online :
http://www.inkindo.org. Diakses pada tanggal 01 Agustus 2015
Karner, Gustav. 1993. Resource Estimation for Objectory Projects. Objective Systems SF AB Torshamnsgatan. Kista, Swedia.
Lembaga Kebijakan Pengadaan Barang/Jasa Pemerintahan. 2012. Rancangan Pedoman Umum Perencanaan Pengadaan Barang/Jasa Pemerintahan di
Lingkungan Kementrian/Lembaga/Satuan Kerja Perangkat
Daerah/Institusi Lainnya. Online :
http://www.lpse.manggaraitimurkab.go.id/edproc/index.filedownload:dow nload/3132383436313b31. Diakses pada tanggal 15 Juli 2015.
Mulder, H., Kontakos, I., & Standish, G. 2015. Rethinking The Public Spending on ICT projects. The Standish Group. Boston.
Nageswaran, Surech. 2001. Test Effort Estimation Using Use Case Points. Online:
http://www.cognizant.com/cogcommunity/presentations/Test_Effort_Esti mation.pdf. Diakses pada tanggal 13 Juli 2015.
Ochodek, M., Nawrocki, J., Kwarciak, K. 2011. Simplifying Effort Esimation Based on Use Case Points. Information and Software Technology, volume 53, issue 3 : 200-213.
Page. 2001-2008. Online :
http://www.agilemodelling.com/essays/introductionToAM.html. Diakses pada tanggal 15 Juli 2015.
Parthasarathy, M.A. 2007. Partical Software Esimaion : Function Point Methods for Insourced and Outsorced Projects. Infosys.
Peraturan Presiden Republik Indonesia No 70 Tahun 2012. Online : http://www.lkpp.go.id/v2/files/content/file/09082012110709BT%20Perpre s%200702012.pdf. Diakses pada tanggal 15 Juli 2015.
Rizky. Soetam. 2008. Konsep Dasar Rekayasa Perangkat Lunak Software Reengineering. Prestasi Pustaka.
Samsudi. 2008. Statistika. Jurnal Teknik Mesin-Fakultas Negeri Semarang. Semarang.
Silverburg, A. 2002. Agile Analytics in Higher Education. USA. Phytorion.
Schneider, G. And Winters, J. 1998. Applying Use Cases-A Practical Guide. Addison-Wesley.
Sholiq., Puji Widodo, Arifin., Sutanto, Teguh., & P. Subriadi, Apol. 2016. A Model to Determine Cost Estimation for Software Development Projects of Small and Medium Scales Using Use Case Points. JATIT Vol.85. No.1 : 87-94.
