TA : Estimasi Penentuan Harga Perkiraan Sendiri Untuk Pengembangan Perangkat Lunak Skala Kecil Menengah Dengan Model Prototype.

ESTIMASI PENENTUAN HARGA PERKIRAAN SENDIRI UNTUK PENGEMBANGAN PERANGKAT LUNAK SKALA KECIL MENENGAH DENGAN MODEL PROTOTYPE

TUGAS AKHIR

Program Studi

S1 Sistem Informasi Kekhususan Komputer Akuntansi

Oleh:

Jainudin Putra Perdana 11.41011.0013

FAKULTAS TEKNOLOGI DAN INFORMATIKA

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2016

halaman ABSTRAK ... Error! Bookmark not defined. KATA PENGANTAR ... Error! Bookmark not defined. DAFTAR ISI ... ix DAFTAR GAMBAR ... Error! Bookmark not defined. DAFTAR TABEL ... Error! Bookmark not defined. BAB I PENDAHULUAN ... Error! Bookmark not defined. 1.1 Latar Belakang Masalah ... Error! Bookmark not defined. 1.2 Rumusan Masalah ... Error! Bookmark not defined. 1.3 Batasan Masalah ... Error! Bookmark not defined. 1.4 Tujuan ... Error! Bookmark not defined. 1.5 Sistematika Penulisan ... Error! Bookmark not defined. BAB II LANDASAN TEORI ... Error! Bookmark not defined.

2.1 Penelitian Terdahulu ... Error! Bookmark not defined. 2.1.1 Penelitian Kelompok Aktivitas Pengembangan Perangkat Lunak Sebelumnya ... Error! Bookmark not defined. 2.1.2 Estimasi Penentuan Harga Perkiraan Sendiri Untuk Pengembangan Perangkat Lunak Skala Kecil Menengah ... Error! Bookmark not defined. 2.2 Teori Pendukung ... Error! Bookmark not defined. 2.2.1 Harga Perkiraan Sendiri (HPS) ... Error! Bookmark not defined. 2.2.2 Estimasi Effort ... Error! Bookmark not defined. 2.2.4. Use Case Point (UCP) ... Error! Bookmark not defined.

2.2.5. Perhitungan Nilai Effort Rate ... Error! Bookmark not defined. ix

2.2.8 System Development Life Cycle (SDLC)Error! Bookmark not defined.

2.2.9 Prototipe Model ... Error! Bookmark not defined. 2.2.10. Manajemen Proyek... Error! Bookmark not defined. 2.2.11 Analisis Devisiasi Rata-Rata ... Error! Bookmark not defined. BAB III METODE PENELITIAN ... Error! Bookmark not defined. 3.1. Analisis Penelitian ... Error! Bookmark not defined. 3.1.1. Studi Literatur ... Error! Bookmark not defined. 3.1.2. Identifikasi Masalah ... Error! Bookmark not defined. 3.1.3 Analisis Kebutuhan ... Error! Bookmark not defined. 3.1.4 Metode Pengumpulan Data ... Error! Bookmark not defined. 3.1.5 Tahap Pengembangan ... Error! Bookmark not defined. BAB IV HASIL DAN PEMBAHASAN ... Error! Bookmark not defined. 4.1. Model Penentuan HPS ... Error! Bookmark not defined. 4.2. Komponen – komponen Model Penentuan HPS Perangkat Lunak . Error! Bookmark not defined.

4.2.1 Pententuan Nilai Use Case Point (UCP)Error! Bookmark not defined.

4.2.2 Perhitungan Nilai Estimasi Effort .... Error! Bookmark not defined. 4.2.3 Aktivias Effort/Distribusi Effort ... Error! Bookmark not defined. 4.2.4 Estimasi Effort Peraktivitas... Error! Bookmark not defined. 4.2.5 Biaya Langsung Personil... Error! Bookmark not defined.

4.3 Distribusi Effort dengan Model PrototypeError! Bookmark not defined.

4.3.1 Software Development ... Error! Bookmark not defined. 4.3.2 Ongoing Activity ... Error! Bookmark not defined. 4.3.3 Quality & testing ... Error! Bookmark not defined. 4.4 Uji Coba Model Penentuan HPS ... Error! Bookmark not defined. 4.4.1 Penentuan Aktivitas Proyek dan Distribusi EffortError! Bookmark not defined.

4.4.2 Penentuan Nilai Distribusi Setiap ProyekError! Bookmark not defined.

4.4.3 Penentuan Nilai Distribusi Effort Setiap PersonilError! Bookmark not defined.

4.4.4 Penentuan Nilai Rata – rata Distribusi Effort Setiap Personil dari Seluruh Proyek ... Error! Bookmark not defined. 4.4.5 Tahapan Penentuan Nilai Use Case PointError! Bookmark not defined.

4.4.6 Estimasi Effort ... Error! Bookmark not defined. 4.4.7 Estimasi Effort dan Biaya Langsung Personil Peraktivitas... Error! Bookmark not defined.

4.4.8 Biaya Langsung Non Personil ... Error! Bookmark not defined. 4.4.9 Analisis Deviasi Rata-Rata (Mean Deviation)Error! Bookmark not defined.

5.2 Saran ... Error! Bookmark not defined. DAFTAR PUSTAKA ... Error! Bookmark not defined. LAMPIRAN ... Error! Bookmark not defined. BIODATA PENULIS ... Error! Bookmark not defined. LAMPIRAN A ... Error! Bookmark not defined. LAMPIRAN B ... Error! Bookmark not defined. LAMPIRAN C ... Error! Bookmark not defined. LAMPIRAN D ... Error! Bookmark not defined. LAMPIRAN E ... Error! Bookmark not defined. LAMPIRAN F ... Error! Bookmark not defined. LAMPIRAN G ... Error! Bookmark not defined.

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.

Namun yang terjadi saat ini dalam pelaksanaan pengadaan perangkat lunak banyak perusahaan perorangan maupun badan usaha, pejabat pemerintah dan pengembang perangkat lunak yang melakukan permintaan dan penawaran untuk pengadaan perangkat lunak kesulitan dalam pembuatan HPS, sehingga apabila penetapan harga dalam pengadaan perangkat lunak telalu mahal dari harga wajar maka akan menimbulkan potensi kerugian, akan tetapi apabila ditetapkan lebih rendah dari harga wajar maka berpotensi terjadinya kegagalan dalam pengadaan perangkat lunak karena pengembang perangkat lunak tidak akan berminat. Sehingga dapat disimpulkan untuk mengatasi permasalahan yang terjadi

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).

Dalam metode UCP, estimasi effort didapatkan dari perkalian antara nilai UCP dengan nilai Effort Rate (ER). Nilai effort rate sebesar 20 man-hours dengan menggunakan tiga data proyek pengembangan perangkat lunak (Karner, 1993). Nilai effort rate dari Karner ini sering digunakan oleh beberapa penelitian, antara lain yaitu penelitian (Nageswara, 2001), (Damondara, 2002), (Kasumoto, 2006), (Frohnhoff, 2008), dan (Monteiro dkk, 2008). Dengan diketahuinya nilai dari

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 prototype, 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.

Selain belum adanya acuan dalam penentuan HPS untuk pengembangan perangkat lunak, permasalahan lain yang timbul dalam penelitian ini yaitu belum adanya penentuan sub aktivitas yang terjadi dan besarnya persentase nilai effort

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 estimasi penentuan HPS menggunakan UCP untuk pengembangan perangkat lunak skala kecil menengah

dengan model prototype. Dengan diadakannya penelitian ini maka diharapkan 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 prototype?

2. Berapa distribusi effort untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype?

3. Berapa nilai effort untuk masing-masing aktivitas pengembangan perangkat lunak skala kecil menengah dengan model prototype?

4. Apa saja komponen HPS untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype?

5. Berapakah nilai HPS untuk studi kasus pengembangan perangkat lunak skala kecil menengah dengan model prototype?

1.3 Batasan Masalah

Berdasarkan rumusan masalah di atas maka dalam pembuatan Tugas Akhir ini, ruang lingkup permasalahan hanya akan dibatasi pada :

1. Data yang diolah merupakan data proyek pengembangan perangkat lunak skala kecil menengah dengan model prototipe yang sudah pernah diselesaikan oleh

perusahaan software pada studi kasus PT. Kuadran (Jakarta), Otsindo Prima Raya (Semarang), dan PT. Medixsoft (Surabaya).

2. Data yang digunakan untuk penelitan merupakan data pengembangan perangkat lunak berbasis website.

3. Nilai estimasi biaya langsung didapatkan dengan menganalisis berdasarkan kebutuhan proyek mengunakan metode Use Case Point.

4. Distribusi effort untuk pengalokasian anggaran menmgunakan tahapan dari K. Shaleh, 2011.

5. Tarif yang digunakan untuk mengitung nilai Harga Perkiraan Sendiri mengunakan data 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 prototype.

Tujuan pada penelitian ini diturunkan menjadi 5 sub tujuan, antara lain : 1. Mengetahui dan mengklasifikasikan aktivitas pengembangan

perangkat lunak skala kecil menengah dengan model prototype.

2. Menghasilkan distribusi effort untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype.

3. Menghasilkan nilai effort untuk masing-masing aktivitas pengembangan perangkat lunak skala kecil menengah dengan model

4. Mengetahui komponen HPS untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype.

5. Menghasilkan nilai HPS untuk studi kasus pengembangan perangkat lunak skala kecil menengah dengan model prototype.

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

Pada bab ini akan dijelaskan definisi dan penjelasan mengenai pustaka yang menjadi referensi dalam pengerjaan tugas akhir. 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

Pada bab ini berisi kesimpulan dari keseluruhan permasalahan penelitian Tugas Akhir dan saran perbaikan yang dapat dikembangkan di masa mendatang untuk penelitian Tugas Akhir ini.

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

Aktivitas ini akan mengkoordinir aktivitas manajemen berupa manajemen proyek, manajemen konfigurasi proyek, dokumentasi proyek, penerimaan dan penyebaran proyek, terhitung 21 % dari total effort.

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%

2 On Going Activity

a Project Management 7,0% b Configuration

Management 4,0%

c Documentation 4,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.1.2 Estimasi Penentuan Harga Perkiraan Sendiri Untuk Pengembangan Perangkat Lunak Skala Kecil Menengah

Estimasi penentuan harga perkiraan sendiri (HPS) untuk pengembangan perangkat lunak skala menengah kecil-menengah mempunyai beberapa tahapan dengan menggunakan metode Use Case Point (UCP) dalam menentukan estimasi biaya langsung (Sholiq dkk, 2016).

Berikut ini merupakan gambar dari model estimasi penentuan harga perkiraan sendiri untuk pengembangan perangkat lunak

Dari penelitan yang dilakukan oleh (Sholiq dkk, 2016) tidak mengunakan aktivitas secara khusus dalam pengembangan perangkat lunak, dan juga dalam penentuan aktifitas effort dilakukan perhitungan satu dimensi dengan berdasarkan aktivitas yang ada.

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 menggunakan HPS sebagai :

1. Alat untuk menilai kewajaran harga penawaran termasuk rinciannya,

2. Dasar untuk menetapkan batas tertinggi penawaran yang sah untuk Pengadaan Barang/Pekerjaan Konstruksi/Jasa Lainnya dan Pengadaan Jasa Konsultansi yang menggunakan metode evaluasi Pagu Anggaran,

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,

9. Informasi lain yang dapat dipertanggung jawabkan.

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 :

SBOB = Satuan Biaya Orang Bulan (Person Month Rate) SBOM = Satuan Biaya Orang Minggu (Person Week Rate) 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 :

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 :

1. Dokumen Perjalanan ke Luar Negeri 2. Tiket Penerbangan

3. Kelebihan Bagasi (Excess Baggage)

4. Bagasi yang Tidak Dibawa Sendiri (Unaccompanied Baggage) 5. Biaya Perjalanan Darat (Local / Inland Travel)

6. Biaya Pembelian Kebutuhan Proyek 7. 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 :

2.

Sewa Kantor Proyek

3.

Sewa Peralatan Kantor

4.

Sewa Furniture Kantor

5.

Biaya Operasional Kantor Proyek

6.

Biaya ATK (Office Consumables)

7.

Biaya Komputer & Printer Consumables

8.

Biaya Komunikasi

9.

Tunjangan Harian (Per Diem Allowance)

10.

Tunjangan Perumahan (Housing Allowance)

11.

Penempatan Sementara (Temporary Lodging)

12.

Tunjangan Penempatan (Relocation Allowance)

13.

Tunjangan Tugas Luar (Out of Station Allowance / OSA)

14.

Penginapan Tugas Luar

15.

Cuti Tahunan (Annual Leave)

16.

Biaya Pelaporan

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 :

1.

Pengumpulan Data Sekunder

2.

Seminar, Workshop, Sosialisasi, Training, Desiminasi, Loka Karya, Diskusi, Koordinasi antar Instansi, FGD (Focus Group Discussion)

3.

Survey

5.

dst. nya

3. 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).

Estimasi yang dilakukan pada penelitian ini diaplikasikan dalam proyek pengembangan perangkat lunak kepemerintahan skala kecil menengah dengan model prototype. Definisi dari estimasi perangkat lunak yaitu suatu kegiatan 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 Diagram

Use Case Diagram menggambarkan sekumpulan use case dan aktor serta hubungannya (Booch et al, 1999, p234). Yang ditekankan adalah “apa” yang dilakukan terhadap sistem dan bukan “bagaimana”. Sebuah use case

menggambarkan interaksi antara aktor dengan sistem. Dibawah ini dijelaskan bagian use case diagram :

a. Aktor

Aktor adalah segala sesuatu yang melakukan tatap muka dengan sistem, seperti orang, piranti lunak, piranti keras, atau jaringan (Schneider dan Winters, 1997, p12). Tiap-tiap aktor menunjukkan perannya masing-masing. Contohnya, seorang actor dapat memberikan input ke dalam dan menerima informasi dari aplikasi piranti lunak. Notasi aktor dengan nama aktor tersebut dibawahnya:

b. Use Case

Use Case menggambarkan segala sesuatu yang aktor ingin lakukan

terhadap sistem.

Use Case harus merupakan “apa” yang dikerjakan piranti, bukan

“bagaimana” aplikasi piranti lunak mengerjakannya. Suatu sistem yang kompleks memiliki banyak use case, sehingga perlu diorganisasi.

Notasi use case :

Untuk menghubungkan antara aktor dengan use case digunakan simbol garis yang disebut sebagai relationship. Dengan adanya sebuah use case diagram

maka akan membantu dalam menyusun kebutuhan sebuah sistem dan mengkomunikasikannya dengan klien.

2.2.4. Use Case Point (UCP)

Metode use case point (UCP) adalah metode yang mempunyai kemampuan untuk memberikan estimasi effort yang diperlukan untuk membuat suatu proyek berdasarkan jumlah dan kompleksitas use case yang dimiliki oleh proyek perangkat lunak tersebut (Karner, 1993). Menurut pendapat lain, UCP adalah metode yang dapat menganalisa actor, use case, dan berbagai faktor teknis dan faktor lingkungan hingga menjadi suatu persamaan (Clemmons, 2006).

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:

a. UCP memiliki deviasi sebesar 6% (Nageswaran, 2001),

b. UCP memiliki deviasi sebesar 19%, sementara estimasi para ahli memiliki deviasi sebesar 20% (Anda, 2002),

c. 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. 2 Langkah-langkah Metode Use Case Point (UCP) 1. Unjusted Use Case Point (UUCP)

a. Unadjusted Actor Weights (UAW)

Langkah pertama adalah menentukan terlebih dahulu aktor sebagai simple,

average, atau complex sesuai tabel 2.2. seperti berikut:

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

1. Application Program Interface (API)

API adalah singkatan dari Application Program Interface, yakni serangkaian instruksi dan standar pemrograman untuk mengakses aplikasi atau layanan berbasis web. Sebuah perusahaan software atau penyedia layanan berbasis web merilis API mereka kepada publik. Dengannya, pengembang lain dapat mendesain aplikasi yang memanfaatkan layanan mereka.

API memungkinkan sebuah aplikasi berkomunikasi dengan aplikasi lain di Internet melalui serangkaian panggilan (call). Sebuah API, berdasarkan definisinya, adalah sesuatu yang mendefinisikan cara dua entitas untuk berkomunikasi. Entitas di sini adalah sebuah software yang nyata berbeda (dalam layanan) dengan software lain.

Dengan API, panggilan-panggilan yang bolak-balik antar aplikasi diatur melalui web service. Web service adalah kumpulan standar teknis dan protokol, termasuk XML (Extensible Markup Language), bahasa umum yang digunakan oleh aplikasi-aplikasi tersebut selama berkomunikasi di Internet.

API sendiri merupakan sekumpulan kode software yang ditulis sebagai serangkaian pesan XML. Setiap pesan XML berhubungan dengan fungsi spesifik dari aplikasi yang akan diajak berkomunikasi. Sebagai contoh, pada API Facebook, terdapat pesan XML yang berhubungan dengan fungsi spesifik wall post, wall comment, wall like.

Pengembang aplikasi pihak ketiga menggunakan pesan-pesan XML yang berhubungan dengan fungsi-fungsi spesifik dari layanan web yang akan diajak berkomunikasi. Pengembang bebas memilih fungsi khusus apa saja yang akan diajak berkomunikasi, dan ditampilkan pada aplikasi rancangannya. Sebagai

contoh, kita bisa membuat Facebook client yang hanya menampilkan update status teman-teman kita.

Dengan demikian, API adalah standar komunikasi yang dibuka oleh perusahaan software, agar dapat dimanfaatkan oleh pengembang pihak ketiga untuk mendesain aplikasi yang memanfaatkan layanan mereka dengan mudah. 2. Transmission Control Protocol/Internet Protocol (TCP/IP )

TCP/IP (singkatan dari Transmission Control Protocol/Internet Protocol) adalah standar komunikasi data yang digunakan oleh komunitas internet dalam proses tukar-menukar data dari satu komputer ke komputer lain di dalam jaringan

Internet. Protokol ini tidaklah dapat berdiri sendiri, karena memang protokol ini berupa kumpulan protokol (protocol suite). Protokol ini juga merupakan protokol yang paling banyak digunakan saat ini. Data tersebut diimplementasikan dalam bentuk perangkat lunak (software) di sistem operasi. Istilah yang diberikan kepada perangkat lunak ini adalah TCP/IP stack.

Protokol TCP/IP dikembangkan pada akhir dekade 1970-an hingga awal 1980-an sebagai sebuah protokol standar untuk menghubungkan komputer-komputer dan jaringan untuk membentuk sebuah jaringan yang luas. TCP/IP merupakan sebuah standar jaringan terbuka yang bersifat independen terhadap mekanisme transport jaringan fisik yang digunakan, sehingga dapat digunakan di mana saja. Protokol ini menggunakan skema pengalamatan yang sederhana yang disebut sebagai alamat IP 6.

3. Graphical User Interface (GUI)

Pengertian GUI adalah Graphical User Interface dalam dunia komputer. Pada komputer terdapat GUI atau antarmuka pengguna secara grafis. Istilah ini

bukan hal yang lumrah pada saat awal kemunculan komputer. Namun setelah komputer generasi keempat mulai diciptakan, munculnya televisi berwarna (yang mendorong pada penciptaan layar monitor berwarna) serta evolusi pada perangkat penampil gambar (graphic adapter atau graphic card atau video card) membuat komputer mulai mendapatkan suatu sistem baru.

Secara sederhana, GUI adalah suatu media virtual yang dapat membuat pengguna memberikan perintah tertentu pada komputer tanpa mengetik perintah tersebut, namun menggunakan gambar yang tersedia. Pengguna tidak mengetikkan perintah seperti pada komputer dengan Shell atau teks. Dengan GUI, perintah dapat dikonversi menjadi ikon dalam layar monitor yang dapat diklik untuk memulai fungsinya. Sebagai contoh, tentu anda paham dengan sebuah ikon berbentuk kertas dengan huruf W diatasnya kan? Itu adalah ikon untuk menjalankan Microsoft Word, sebuah aplikasi yang digunakan untuk mengetik. Atau anda pasti familiar dengan tombol di pojok kiri bawah, yakni tombol bertuliskan Start atau logo Windows itu. Segala sesuatu yang anda lihat di Komputer anda saat ini adalah GUI.

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. 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 :

���� = ��� + ����

3. 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 : a. Technical Complexity Factor (TCF)

b. Environmental Complexity Factor (ECF)

Berikut penjelasan masing-masing dari complexity factor :

a. 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

Technical Factor Bobot

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

Nilai-nilai pada technical factor tersebut dikalikan dengan bobot nilai masing-masing. Bobot nilai yang diberikan pada setiap factor tergantung dari seberapa besar pengaruh dari factor 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

Technical Factor (TF), yang kemudian digunakan untuk mendapatkan Technical Complexity Factor (TCF).

TCF = 0.6 + (0.01*TF)

b. 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.

UCP = UUCP * TCF * ECF 2.2.5. 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.6. Perangkat Lunak

Komputer atau perangkat keras dapat beroperasi mengikuti instruksi manusia secara persis melalui perangkat lunak. Perangkat lunak sendiri merupakan kumpulan program komputer yaitu dalam bentuk sistem pengoperasian komputer yang berbentuk instruksi tertulis dalam bahasa komputer (Amsyah, 2005).

2.2.7. 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

1 Trivial 1 1-4 week 500

2 Small 1 1-6 month 1K-2K

3 Medium 2-5 1-2 year 5K-50K

4 Large 5-20 2-3 year

50K-100K 5

Very

Large 100-1K 4-5 year 1M

6

Extra

Large 2K-5K 5-10 year 1M-10M

2.2.8 System Development Life Cycle (SDLC)

System Development Life Cycle (SDLC) adalah suatu kerangka yang

menggambarkan kegiatan-kegiatan yang dilakukan pada setiap tahap pembuatan sebuah software (Fatta, 2007: 24). Terdapat banyak metode untuk mendeskipsikan

SDLC ini, pada dasarnya setiap metode menggambarkan tahap-tahap sebagai berikut:

1. Identifikasi, seleksi dan perencanaan

Tahap ini merupakan tahap preliminary dari pembuatan suatu software. Pada tahap ini, dikembangkan suatu rancang bangun dari suatu software. Langkah-langkah yang dilakukan dalam tahap ini antara lain.

a) Mengidentifikasi kebutuhan user.

b) Menyeleksi kebutuhan user dari proses identifikasi diatas, dengan menyesuaikan dengan kapasitas teknologi yang tersedia serta efisiensi.

c) Merencanakan sistem yang akan digunakan pada software yang dibuat, Dengan kebutuhan-kebutuhan sebagai berikut: kebutuhan fungsional dan non-fungsional, kebutuhan user, kebutuhan sistem, kebutuhan dokumen dan perangkat lunak.

2. Analisis sistem

Tahap ini merupakan tahap penyempurnaan, yang bertujuan memperoleh kebutuhan software dan user secara lebih spesifik dan rinci. Tujuan dilakukan tahap ini adalah untuk mengetahui posisi dan peranan teknologi informasi yang paling sesuai dengan kebutuhan perusahaan yang bersangkutan, serta mempelajari fungsi-fungsi manajemen dan aspek-aspek bisnis terkait yang akan berpengaruh atau memiliki dampak tertentu terhadap proses desain, konstruksi dan implementasi software. Analisis sistem terbagi dua, yaitu.

a. Permodelan data, yang mencakup Entity Relationship Diagram (ERD),

Conceptual Data Model (CDM), dan Physical Data Model (PDM). b. Permodelan proses, dengan Unified Modeling Language.

3. Desain sistem

Setelah melakukan identifikasi serta analisis sistem, tahap selanjutnya adalah menerjemahkan konsep-konsep tersebut kedalam suatu sistem yang berwujud. Tahap ini meliputi pembuatan dan pengembangan sebagai berikut.

a. Desain form dan laporan (reports). b. Desain antarmuka dan dialog (message). c. Desain basis data dan file (framework). d. Desain proses (process structure).

Pada tahap ini akan dihasilkan sebuah dokumen berupa Software

Architecture Document (SAD). SAD ini adalah dokumen yang menjelaskan

tentang arsitektur proyek perangkat lunak yang berhubungan dengan project. 4. Implementasi sistem

Tahap implementasi sistem ini diawali dengan pengetesan software yang telah dikembangkan. Beberapa tahap pengetesan adalah sebagai berikut.

a. Developmental, yakni pengetesan error per module oleh programmer. b. Alpha testing, yakni error testing ketika software digabungkan dengan

antarmuka user.

c. Beta testing, yakni pengetesan dengan lingkungan dan data yang

sebenarnya. 5. Pemeliharaan sistem

Tahap pemeliharaan sistem adalah sebagai berikut.

a. Korektif, yaitu memperbaiki desain dan error pada program

b. Adaptif, yaitu memodifikasi sistem untuk beradaptasi dengan perubahan lingkungan.

c. Perfektif, yaitu melibatkan sistem untuk menyelesaikan masalah baru atau menambah fitur baru pada sistem yang telah ada.

d. Preventif, yaitu menjaga sistem dari kemungkinan masalah di masa yang akan datang.

2.2.9 Prototipe Model

Merupakan model pengembangan system yang proses iterative dalam pengembangan sistem dimana requirement diubah ke dalam sistem yang bekerja (working system) yang secara terus menerus diperbaiki melalui kerjasama antara user dan analis. Prototype juga bisa dibangun melalui beberapa tool pengembangan untuk menyederhanakan proses. Prototyping merupakan bentuk dari Rapid Application Development (RAD). Dalam metode ini, pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan system (Pressman, 2002).

Analisis Requierment Design

Build prototipe

Costumer Evaluation

Development Testing

Maintenaince

Gambar 2. 3 Tahapan model prototype pengembangan perangkat lunak Tahapan-tahapan dalam Prototyping adalah sebagai berikut:

1. Analisis Requierment

Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2. Design

Pengembang membuat design sesuai dengan hasil analisis sesuai dengan kebutuhan pelanggan agar lebih mudah dalam pembuatan prototipe untuk pelanggan.

3. Build Prototipe

Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)

4. Costumer Evalution

Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 5 akan diambil. Jika tidak prototyping direvisi dengan mengulang langkahb 1, 2, dan 3.

5. Mengkodekan sistem

Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai

6. Menguji system

Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White 7. Maintaince

Setelah aplikasi diterapkapan oleh perusahaan maka pihak pengembang akan melakukan pemeliharaan aplikasi agar dapat memperbaiki sistem apabila terjadi kerusakan atau ketidaksesuain sistem.

Keunggulan dan kelemahan model prototyping Keunggulan prototyping adalah :

1. Adanya komunikasi yang baik antara pengembang dan pelanggan

2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

3. Pelanggan berperan aktif dalam pengembangan sistem 4. Lebih menghemat waktu dalam pengembangan sistem

5. Penerapan lebih mudah karena pemakai mengetahui apa yang diharapkanya Kelemahan prototyping adalah :

1. Pelanggan terkadang tidak mengetahui atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu yang lama.

2. Pengembang biasanya ingin cepat menyelesaikan proyek sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya cetak biru sistem.

3. Hubungan sistem dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik.

2.2.10.Manajemen Proyek

Manajemen proyek adalah suatu teknik yang digunakan untuk merencanakan, mengerjakan, dan mengendalikan aktivitas suatu proyek untuk memenuhi kendala waktu dan biaya proyek (Muslich, 2009). Teknik ini berorientasi pada pencapaian tujuan, di mana tujuan tersebut mungkin pembangunan gedung, pembukaan kantor baru, atau pengendalian kegiatan penelitian dan pengembangan. Perencanaan suatu proyek terdiri dari tiga tahap (Prasetya, Hery dan Lukiastuti, Fitri 2009), yaitu:

a. Perencanaan. Membuat uraian kegiatan-kegiatan, menyusun logika urutan kejadian-kejadian, menentukan syarat-syarat pendahuluan, menguraikan interaksi dan interdependensi antara kegiatan-kegiatan.

b. Penjadwalan. Penaksiran waktu yang diperlukan untuk melaksanakan tiap kegiatan, menegaskan kapan suatu kegiatan berlangsung dan kapan berakhir.

c. Pengendalian. Menetapkan alokasi biaya dan peralatan guna pelaksanaan tiap kegiatan.

2.2.11 Analisis Devisiasi Rata-Rata

Deviasi rata-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.

Yang Pertama dilakukan adalah menghitung mean, kemudian ditentukan berapa besarnya penyimpangan tiap-tiap nilai dari mean itu. Misalnya, jika seorang mempunyai IQ 110, sedangkan mean Iq dari kelompoknya = 100, maka deviasi IQ orang tersebut adalah 110 – 100 = +10. Jika orang lain dalam grup itu mempunyai IQ 85, maka deviasi orang itu adalah 85 – 100 = -15. Deviasi yang bertanda plus menunjukkan deviasi di atas mean, sedangkan yang bertanda minus menunjukkan deviasi di bawah mean. Akan tetapi dalam perhitungan mean 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

= Jumlah deviasi dalam harga mutlaknya N = Jumlah individu/kasus

3.1. Analisis Penelitian

Untuk memudahkan penelitian dan memperoleh hasil yang diharapkan, maka perlu dibuat langkah-langkah penelitian. Langkah-langkah penelitian pembuatan Estimasi penentuan harga perkiraan sendiri untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype ini digambarkan pada gambar 3.1 sebagai berikut :

Tahap Awal Studi Literatur Identifikasi Masalah

Pengumpulan Data Analisis Masalah

Tahap Pengembangan Kontruksi Penelitian

Ujicoba

Distribusi Effort

Biaya Langsung Personil Biaya Langsung Non Personil

Pajak Pertambahan Nilai UCP

HPS

Tahap Akhir Evaluasi Kesimpulan

Saran

Gambar 3. 1 Langkah-langkah penelitian estimasi penentuan HPS 35

3.1.1. Studi Literatur

Studi literatur dalam penelitian ini dilakukan dengan mempelajari tentang literatur definisi Harga Perkiraan Sendiri (HPS), Use Case Point (UCP), Software Development Life Cycle (SDLC), Model Pengembangan Prototype, Function Point Analysis, Jones’s Exponent, Effort Distribution, Oppourtunity Cost, BEP, Proses Estimasi Biaya Perangkat Lunak, UML.

3.1.2. Identifikasi Masalah

Berdasarkan tahapan pengumpulan data yang sudah dilaksanakan sebelumnya, maka dapat dilakukan identifikasi masalah yang melatarbelakangi penelitian estimasi Harga Perkiraan Sendiri (HPS) perangkat lunak adalah belum adanya metode yang tepat untuk membuat perkiraan sendiri sesuai dengan nilai wajar. Namun saat ini perusahaan perorangan maupun badan usaha, pejabat pemerintah dan pengembang perangkat lunak yang melakukan permintaan dan penawaran untuk pengadaan perangkat lunak kesulitan dalam pembuatan HPS, penetapan harga dalam pengadaan perangkat lunak telalu mahal dari sehingga harga wajar maka akan menimbulkan potensi kerugian, akan tetapi apabila ditetapkan lebih rendah dari harga wajar maka berpotensi terjadinya kegagalan dalam pengadaan perangkat lunak karena pengembang perangkat lunak tidak akan berminat. Sehingga dapat disimpulkan untuk mengatasi permasalahan yang terjadi tersebut maka perlu dibuat acuan dalam penentuan Harga Perkiraan Sendiri (HPS) dalam proyek pengembangan perangkat lunak.

2.1.3 Analisis Kebutuhan

Melalui identifikasi masalah yang ada, dapat dibuat analisis kebutuhannya sebagai berikut:

1. Mengetahui klasifikasi aktivitas pengembangan perangkat lunak skala kecil menengah dengan model prototipe.

2. Menghasilkan nilai distribusi effort untuk pengembangan perangat lunak skala kecil menengah dengan model prototipe.

3. Menghasilkan nilai effort untuk masing – masing akivitas pengembangan perangkat lunak dengan model prototipe.

4. Mengetahui komponen HPS untuk pengembangan perangkat lunak dengan model prototipe.

5. Menghasilkan nilai HPS untuk studi kasus perangkat lunak dengan model prototipe

2.1.4 Metode Pengumpulan Data 1. Observasi

Observasi merupakan metode pengumpulan data dimana peneliti mencatat data dan informasi sebagaimana yang disaksikan selama penelitian yang kemudian dicatat, diamati serta didengarkan dengan seobyektif mungkin (Gulo:2000). Beberapa data sumber pada tabel 3.1 didapatkan melalui tahapan observasi ini dan akan dijadikan pedoman untuk mendapatkan gambaran umum dalam menerapkan model penelitian.

Tabel 3. 1. Sumber Data Penelitian No Sumber Data yang didapat

1. Kepala Perusahaan 1. Data jumlah proyek berhasil dan proyek gagal 2. Proses bisnis

No Sumber Data yang didapat

2. Project Manager 1. Use case diagram proyek

2. Data tim proyek 2. Wawancara & Kuisioner

Wawancara merupakan bentuk komunikasi langsung antara peneliti dan responden dimana komunikasi berlangsung dalam bentuk tanya jawab dalam hubungan tatap muka untuk menangkap pemahaman dan ide dalam membuat penelitian (Gulo:2000). Wawancara dalam penelitian ini dilakukan dengan komunikasi tanya jawab yang melibatkan kepala Perusahaan dan Project Manager (PM) dari proyek yang dikerjakan. Tujuan dari wawancara ini adalah untuk menggali data mengenai proses bisnis pengembangan perangkat lunak dengan model prototype, hambatan yang terjadi hingga aktivitas pengembangan perangkat lunak. Wawancara yang dilakukan pada penelitian ini dilaksanakan secara terstruktur dengan berpedoman pada daftar pertanyaan yang telah disiapkan.

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 : 1. Jumlah pegawai dan jumlah waktu digunakan sebagai bahan untuk

perhitungan nilai actual effort. Nilai actual effort merupakan nilai yang dibutuhkan oleh tim pengembang perangkat lunak untuk menyelesaikan proyek dari awal pengerjaan sampai selesai. Pada penelitian ini, actual effort

didapatkan melalui kegiatan pemberian kuesioner kepada responden yaitu pihak pengembang perangkat lunak. Desain kuesioner dapat dilihat pada gambar 3.2 seperti berikut :

No

Fase Pengembangan

1 Pengalian Kebutuhan Hari Pekerja %Effort Hari Pekerja % Effort Hari Pekerja % Effort Hari Pekerja % Effort Hari Pekerja % Effort Hari Pekerja % Effort

Survey ke SKPD terkait

Analisis Proses Bisnis berdasarkan kebutuhan aplikasi Rapat hasil analisis berdasarkan kebutuhan User 2 Pembuatan Prototype

Desain

a Pemilihan desain template

b Membuat perancangan desain sesuai dengan analisis kebutuhan User

c Membuat desain sesuai perancangan

Build Prototype

a Membuat prototype sesuai desain analisis kebutuhan b Membuat desain input dan ouput prototype

c Melakukan testing input - output prototype Evaluaisi User

a Sosisalisasi hasil prototype

b Melakukan evaluasi prototype dengan User 3 Pengembangan aplikasi

Iteration 1

a Pengembangan database sesuai dengan prototype yang dibuat b Eksekusi kode program

c melakukan pengujian dengan metode black box dan white box

d Peluncuran versi beta e Peluncuran user guide

Iteration 2

∑Pekerja Project Manager System Analyst/ Design ProgrammerJabatan Pekerja (Hari)System Testing Technical Support Dokumentator

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.

3. Nilai TCF dan ECF dapat diketahui dengan penulis memberikan kuesioner kepada masing-masing anggota tim pengembang perangkat lunak skala kecil menengah. Sehingga didapatkan nilai TCF dan ECF sesuai kondisi yang dialami oleh tim pengembang perangkat lunak. Desain kuesioner dapat dilihat pada gambar 3.3 dan 3.4 seperti berikut :

3. Data dan Dokumen Perusahaan 1. Data Primer

Data primer merupakan data yang diperoleh secara langsung berdasarkan hasil wawancara pada Kepala Perusahaan dan Project Manager pengembangan perngkat lunak adalah data jumlah proyek berhasil dan proyek gagal, proses bisnis pengembangan perngkat lunak model prototype, nilai proyek sebelumnya.

2. Data Sekunder

Data sekunder merupakan data yang diperoleh melalui studi dokumentasi, antara lain: data tim proyek Use Case Diagram pengembangan perangkat lunak model prototype.

2.1.5 Tahap Pengembangan

Pada tahap ini akan dilakukan pembuatan kerangka penelitian yang akan digunakan untuk menghitung estimasi Harga Perkiraan Sendiri (HPS) untuk pengembangan perangkat lunak skala kecil – menengah dengan mengunakan model prototype. Model estimasi penentuan harga perkiraan sendiri untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype, model penentuan estimasi harga perkiraan sendiri ini pengembangan dari model penelitian Sholiq dkk, 2016.

3.1.6. Tahap Akhir 1. Evaluasi

Melakukan ujicoba terhadap metode dan analisis estimasi Harga Perkiraan Sendiri (HPS) utuk pengembangan perangkat lunak yang telah digunakan dalam penelitian dengan nilai actual pada proyek pengembangan perangkat lunak yang sudah dilaksanakan untuk mengetahui tingkat nilai devisiasi.

2. Kesimpulan

Kesimpulan berupa nilai dari estimasi harga perkiraan sendiri untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype dan nilai tingkat devisiasi.

Diharapkan besaran nilai devisasi tidak diatas 20% sehingga metode dan analisis dalam penentuan estimasi Harga Perkiraan Sendiri (HPS) untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype layak diterapkan.

3. Saran

Analisis dan metode estimasi Harga Perkiraan Sendiri (HPS) untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype bisa di implentasikan dengan membuat aplikasi agar lebih maksimal.

Pada bab ini akan dicantumkan hasil dari proses yang dijalankan tiap tahapnya sesuai dengan metode penelitian yang digunakan untuk menghasilkan tahapan dalam menghitung nilai estimasi biaya pembuatan pembuatan perangkat lunak menengah-kecil dengan model prototipe:

4.1. Model Penentuan HPS

Cost of personil

Tax Cost of

Non personil UCP

Persentase of effort per activity UUCP

TCF

ECF UAW

UUCW

Software Development (model Prototipe)

On going Activity

Quality & Control

Our estimate Cost

Tax = ( Cost of personil + Cost of Non personil) * 10 % Reimbusable

Lump Sum Fixed Unit Rate TF

EF ER

Effort

Effort per activity

Pay rate Cost per activity

personil

Gambar 4. 1 Model HPS untuk pengembangan perangkat lunak

Pada tahap ini akan dilakukan pembuatan kerangka penelitian yang akan digunakan untuk menghitung estimasi Harga Perkiraan Sendiri (HPS) untuk pengembangan perangkat lunak skala kecil – menengah dengan mengunakan

model prototype. Model estimasi penentuan harga perkiraan sendiri untuk pengembangan perangkat lunak skala kecil menengah dengan model prototype. Pembuatn model penentuan HPS sesuai dengan Peraturan Presiden Republik Indonesia No. 70 Tahun 2012 Tentang Pengadaan Barang/Jasa, pada Pasal 66 Angka (5) Butir a dengan mengunakan Metode UCP, dan juga model penentuan estimasi harga perkiraan sendiri ini pengembangan dari model penelitian pada paper (Sholiq, et.al, 2016).

Dalam penentuan Aktivitas ini akan mengkoordinir aktivitas pembangunan perangkat lunak berupa kebutuhan perangkat lunak dengan mengunakan model prototype, sehingga aktivitas yang terdapat pada pengembangan perangkat lunak dengan mengunakan aktivitas model prototipe dari Pressman, 2002 dan juga hasil kuisioner dilapangan. Dengan melakukan penyesuaian antara teori tentang model prototype dan juga implementasi dilapangan maka menghasilkan aktivitas seperti table dibawah ini

Tabel 4. 1. Aktivitas Pengembangan Perangkat Lunak Model Prototipe Aktivitas Pengembangan Perangkat Lunak Model Prototipe No Project Manager

Software Development A Requirement

Survey ke SKPD terkait

Analisis Proses Bisnis berdasarkan kebutuhan aplikasi Rapat hasil analisis berdasarkan kebutuhan User

B Specification & Design Pembuatan Prototype Desain

a Pemilihan desain template

b Membuat perancangan desain sesuai dengan analisis kebutuhan User

c Membuat desain sesuai perancangan Build Prototype

Aktivitas Pengembangan Perangkat Lunak Model Prototipe b Membuat desain input dan ouput prototype

c Melakukan testing input - output prototype

Evaluaisi User

a Sosisalisasi hasil prototype

b Melakukan evaluasi prototype dengan User

C Coding

Pengembangan aplikasi Iteration 1

a Pengembangan database sesuai dengan prototype yang dibuat b Eksekusi kode program

c melakukan pengujian dengan metode black box dan white box

d Peluncuran versi beta e Peluncuran user guide

Iteration 2

a Analisis evaluasi aplikasi

b Pengembangan database sesuai dengan hasil evaluasi user c Eksekusi kode program

d Melakukan pengujian dengan metode black box dan white box

e Peluncuran versi beta setelah evaluasi f Pembaruan userguide setelah dievaluasi D Integration Testing

a Membuat checklist integrasi sistem b membuat useracceptancetestplan

c Pengujian dan Intergrasi dengan metode whitebox dan blackbox

d Perbaikan dan pelengkapan user guide

Penyerahan dan Implementasi

a Rapat penerimaan kesiapan aplikasi dengan Stakeholder b Instalasi ke server SKPD

c User traning ke SKPD

d Serah terima aplikasi dan database

4.2. Komponen – komponen Model Penentuan HPS Perangkat Lunak 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 ataupun terlalu tinggi. Ada 3 komponen yang membentuk nilai HPS adalah:

a. Biaya langsung Perosnil (Remunerasi)

Dalam penentuan nilai biaya langsung personil pengembangan perangkat lunak mempunyai 3 komponen untuk menentukan nilai biaya personil dari jurnal (Sholiq dkk, 2016) yang digambarkan pada model HPS diatas yaitu:

1. Menghitung estimasi effort dengan mengunakan metode Use Case Point (UCP) pada section 4.2.1.

2. Perhitungan Nilai Estimasi Effort

Rumus perhitungan estimasi effort menggunakan metode UCP adalah sebagai berikut:

Estimasi Effort = UCP x Effort Rate (ER)

Effort rate adalah rasio jumlah jam orang per use casepoint

berdasarkan proyek-proyek di masa lalu, nilai ER yang digunakan sebesar 8,6 hasil dari penelitian (Sholiq, et.al , 2016). Setelah nilai estimasi effort dengan metode UCP di temukan selanjutnya menghitang nilai aktivitas effort.

3. Menentukan nilai Aktivitas Effort dengan model prototype pada section 4.2.2

Jika estimasi effort peraktivitas sudah diketahui maka biaya langsung personil dapat disusun. Penyusunan biaya langsung personil perkativitas dapat dilakukan dengan rumus sebagai berikut :

Biaya langsung personil perkativitas = Estimasi effort peraktivitas x biaya/tarif personil

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

b. Biaya 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

c. 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:

HPS setelah pajak = HPS sebelum pajak x PPN 1.2.1 Pententuan Nilai Use Case Point (UCP)

a. Perhitungan Unadjusted Use Case Point (UUCP)

Untuk mendapatkan nilai Unadjusted Use Case Point (UCP), maka perlu dilakukan pembobotan dan skoring terkait kompleksitas actor/Unadjusted Actor Weights (UAW) dan Unadjusted Use Case Weights (UUCW) ditinjau dari use case diagram yang telah didapatkan dari tim pengembang perangkat lunak.

Skoring dihitung berdasarkan parameter-parameter yang telah ditentukan. untuk mendapatkan Unadjusted Use Case Point (UUCP), seperti rumus berikut :

���� = ��� + ����

a. Unadjusted Actor Weights (UAW)

Langkah pertama adalah menentukan terlebih dahulu aktor sebagai simple,

average, atau complex sesuai tabel 4.2. seperti berikut:

Tabel 4. 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.

Dari data yang dikumpulkan pada pengembangan proyek perangkat lunak diketahui berdasarkan UAW mempunyai bobot 3 atau complex dikarenakan aktor langsung berinteraksi terhadap GUI dan Web page.

b. 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 4.3. seperti berikut:

Tabel 4. 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).

b. Perhitungan Technical Complexity Factor (TCF)

Untuk mengetahui technical complexity factor, telah ada beberapa parameter pengukuran dengan disertai bobotnya. Namun untuk pemberian nilai terhadap masing-masing parameter tersebut membutuhkan penilaian obyektif yang didapatkan melalui tim pengembang perangkat lunak. Maka, dalam tahap ini nantinya akan disebar kuisioner untuk memberikan penilaian terhadap paramater dalam technical complexity factor. Kemudian hasil dari kuisioner tersebut dapat dijadikan acuan untuk menghitung nilai technicalcomplexity factor sesuai dengan rumus yang sudah ditentukan.

Tabel 4. 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

Technical Factor Bobot

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

c. 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.

Tabel 4. 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

Sehingga akhirnya kita bisa mendapatkan nilai dari Use Case Point (UCP) yang didapatkan melalui perkalian UUCP, TCF, dan ECF.

UCP = UUCP * TCF * ECF 1.2.2 Aktivias Effort/Distribusi Effort

Aktivitas pengembangan perangkat lunak dikelompokkan menjadi tiga aktivitas utama dan ditambahkan effort disetiap aktivitasnya sebagai berikut (Shaleh, 2011):

a. Software Development

Aktivitas ini akan mengkoordinir aktivitas pembangunan perangkat lunak berupa kebutuhan perangkat lunak, spesifikasi perangkat lunak, desain serta implementasi (pengkodean) dengan mengunakan model prototype.

b. Ongoing Activity

Aktivitas ini akan mengkoordinir aktivitas manajemen berupa manajemen proyek, manajemen konfigurasi proyek, dokumentasi proyek, penerimaan dan penyebaran proyek.

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.

Tabel 4. 6. PembagianKelompok Aktivitas Pembuatan Proyek Penelitian No Kelompok Aktivitas

1 Software Development a Requirement

b Specification & Design c Coding

d Integration Testing 2 On Going Activity a Project Management b Configuration

No Kelompok Aktivitas c Documentation

d Acceptance & Deployment 3 Quality & Testing

a Quality Assurance & Control

b Evaluation & Testing

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 presentase effort yang digunakan untuk pengembangan perangkat lunak skala menengah ke besar, sedangkan dalam penelitian ini segmentasi peran dan persentase effort yang digunakan yaitu skala kecil ke menengah dan juga menggunakan model prototype.

Penentuan nilai % effort peraktivitas yang dilakukan oleh Shaleh juga mengunakan perhitungan 1 dimensi dimana hanya bedasarkan dengan aktivitas yang ada didalam pengembangan proyek perangkat lunak sehingga untuk penentuan effort setiap personil tidak akurat, dalam penelitian ini menggunakan 2 dimensi dimana dihitung dari setiap aktivitas dalam pengembangan perangkat lunak dengan model prototype dan juga personil yang terlibat dalam proyek. Maka dari itu penelitian terdahulu tersebut perlu dilakukan penyesuaian terhadap penelitian yang akan dilakukan.

Tabel 4. 7. PembagianKelompok Aktivitas Pengembangan Perangakat Lunak 2 Dimensi No Aktivitas Jabatan Pekerja Project Manager System Analyst/

Design Programmer

System Testing

Technical

Support Dokumentator 1 Software Development Requirement Specification & Design Coding Integration Testing Acceptance & Deployement

2 On Going

Activity Manajemen Proyek Manajemen Konfigurasi Pendokumentasian 3 Quality & Testing Penjaminan Mutu Pelatihan & Dukungan Teknis Evaluasi dan Pengujian Total Effort

1.2.3 Estimasi Effort Peraktivitas

Setelah mendapatkan nilai estimasi effort dengan metode UCP dan aktivias effort dengan model prototipe maka nilai estimasi effort akan dibagi ke dalam segementasi peran dalam tiap kelompok aktivitas effort pengembangan perangkat lunak skala kecil menengah dengan rumus sebagai berikut :

1.3 Distribusi Effort dengan Model Prototype

Aktivitas pengembangan perangkat lunak dikelompokkan menjadi tiga aktivitas utama:

1.3.1 Software Development

Aktivitas ini akan mengkoordinir aktivitas pembangunan perangkat lunak berupa kebutuhan perangkat lunak, spesifikasi perangkat lunak, desain serta implementasi (pengkodean) dengan mengunakan model prototype, sehingga aktivitas yang terdapat pada pengembangan perangkat lunak dengan mengunakan aktivitas dari model prototipe dari Pressman, 2002 dan juga hasil kuisioner dilapangan. Dibawah ini merupakan table dari sofware developmnet dengan model prototype

Tabel 4. 8. Aktivitas Effort Software Development untuk pengembangan Perangkat Lunak model Prototipe

No Aktivitas Pengembangan Perangkat Lunak Jabatan Pekerja Total Effort Project Manager System Analyst/

Design Programmer

System Testing

Technical

Support Dokumentator

1

Software

Development

A Requirement

Survey ke

SKPD terkait 0,3% 0,4% 0,7% 0,2% 0,2% 1,7%

Analisis Proses Bisnis berdasarkan kebutuhan aplikasi

0,5% 0,5%

1,0%

Rapat hasil analisis berdasarkan kebutuhan User

0,5% 0,3%

0,8% 1,6%

Total Mandays

Requirement 1,3% 1,2% 1,5% 0,2% 0,2% 0,0% 4,3%

B Specification & Design Pembuatan Prototype Desain a Pemilihan

No Aktivitas Pengembangan Perangkat Lunak Jabatan Pekerja Total Effort Project Manager System Analyst/

Design Programmer

System Testing

Technical

Support Dokumentator

b

Membuat perancangan desain sesuai dengan analisis kebutuhan User

0,5% 0,7%

1,2%

c

Membuat desain sesuai perancangan

0,5% 0,8%

0,1% 1,5%

Build Prototype

a

Membuat prototype sesuai desain analisis kebutuhan

1,0% 1,3%

3,4% 5,6%

b

Membuat desain input dan ouput prototype

0,8%

1,6% 2,5%

c

Melakukan testing input - output prototype

0,4%

1,0% 0,4% 1,8%

Evaluaisi User 0,0%

a

Sosisalisasi

hasil prototype 0,5% 0,3% 1,4% 0,3% 2,6%

b

Melakukan evaluasi prototype dengan User

0,3% 0,3%

0,7% 0,2% 1,5%

Total Mandays Specification &

Design

3,1% 5,0% 9,2% 0,9% 0,0% 0,0%

18,3%

C Coding

Pengembangan aplikasi Iteration 1 a Pengembangan database sesuai dengan prototype yang dibuat 0,7%

1,6% 2,4%

b

Eksekusi kode

program 9,9% 9,9%

c

melakukan pengujian dengan metode black box dan white box

0,6% 0,4%

0,5% 1,5%

d

Peluncuran

versi beta 0,3% 0,3% 0,7% 1,3%

e

Peluncuran user

guide 0,3% 0,8% 0,1% 0,9% 2,0%

No Aktivitas Pengembangan Perangkat Lunak Jabatan Pekerja Total Effort Project Manager System Analyst/

Design Programmer

System Testing

Technical

Support Dokumentator

a

Analisis evaluasi aplikasi

0,7% 0,7%

1,3% 2,6%

b Pengembangan database sesuai dengan hasil evaluasi user 0,5%

0,7% 1,2%

c

Eksekusi kode

program 2,3% 2,3%

d

Melakukan pengujian dengan metode black box dan white box

0,3% 0,3%

0,2% 0,5% 1,3%

e

Peluncuran versi beta setelah evaluasi

0,3% 0,5%

0,7% 1,4%

f

Pembaruan user guide setelah dievaluasi

0,5% 0,5%

Total Mandays

Coding 2,2% 3,6% 17,1% 1,4% 0,5% 1,4% 26,4%

D Integration Testing a Membuat checklist integrasi sistem 1,1%

1,7% 2,9%

b

membuat user acceptancetest plan

0,7%

1,6% 2,3%

c

Pengujian dan Intergrasi dengan metode whitebox dan blackbox

0,5% 0,8%

1,3% d Perbaikan dan pelengkapan user guide 0,7%

0,4% 1,0%

Total Mandays

Integration Testing 0,5% 3,3% 3,4% 0,4% 0,0% 0,0% 7,5%

E Acceptance & Deployement a Rapat penerimaan kesiapan aplikasi dengan Stakeholder

0,5% 0,5%

1,4% 0,4% 2,7%

b

Instalasi ke

server SKPD 1,3% 0,7% 2,0%

c

User traning ke

SKPD 0,5% 1,6% 2,1%

53

tingkat akurasi yang cukup. Hal ini sesuai dengan penelitian terdahulu tekait dengan estimasi effort yang menunjukkan tingkat deviasi sebesar 6% (Nageswaran, 2001) 6.89% (Sholiq et.al, 2016), 9% (Carrol, 2015), dan 19% (Anda, 2002). Namun dalam penelitian tersebut masih dalam tahap estimasi effort dan penentuan biaya berdasarkan aktivitas pengembangan perangkat lunak, sedangkan dalam penelitian tugas akhir ini penelitian dimulai dari melakukan estimasi pendistribusian nilai persentase effort berdasarkan aktivitas model prototype.

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. Model Penentuan Harga Perkiraan Sendiri (HPS) pengembangan perangkat lunak skala menengan kecil dengan model prototype telah dibuat dengan mengunakan metode Use Case Point (UCP).

2. Nilai distribusi effort untuk pengembangan perangkat lunak skala kecil menengah dengan model prototipe dalam tugas akhir ini untuk aktivitas utama yaitu Software Development 64.7%, On Going Activity 16.2%, dan Quality and Testing 18.6%

3. Nilai HPS dalam pengembangan perangkat lunak skala kecil menengah dalam tugas akhir ini untuk masing-masing proyek yaitu Proyek A sebesar Rp. 186,773,570, Proyek B sebesar Rp. 178,624,349, Proyek C sebesar 142,405,587, Proyek D Rp. 180,023,710, dan Proyek E sebesar Rp. 218,053,410.

4. Nilai dari deviasi antara penentuan estimas HPS dengan nilai sebenarnya mempunyai nilai devisiasi maksimal sebesar 11,1%, rata-rata sebesar 9,4%, dan nilai minimal sebesar 7,6%. Ini menunjukkan bahwa estimasi perhitungan HPS dalam tugas akhir ini memiliki tingkat akurasi yang cukup

87

5.2 Saran

Beberapa hal yang diharapkan dapat dikembangkan untuk penelitian dimasa mendatang, yaitu :

1. Penelitian ini menggunakan model prototipe 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.

3. Data yang digunakan dalam penelitian ini bisa bervariasi tidak hanya mengunakan data pengembangan perangkat lunak berbasis website.

4. Penelitian ini dapat dilanjutkan ketahap selanjutnya menjadi penelitian pembuatan software dalam penentuan HPS.

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. Galorath, Daniel D and Evans, Michael W. 2006. Software Sizing, Estimation and

Risk Management : When Performance is Measured Performance Improves. Auerbach Publications. Boca Raton, Florida.

89

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.

Saleh, K. 2011. Effort and Cost Allocation in Medium to Large Software Development Projects. International Journal of Computers (1), 74-79. Samsudi. 2008. Statistika. Jurnal Teknik Mesin-Fakultas Negeri Semarang.

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.

Yavari, Y., Afsharchi, M., & Karami, M. 2011. Software Complexity Level Determination Using Software Effort Estimation Use Case Points Metrics. Digital Avionics Systems Conference, IEEE/AIAA 5th Malaysian Conference in Software Engineering : 257-262.