Analisis Estimasi Biaya Pembuatan Perangkat Lunak Menggunakan

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Vol. 1, No. 10, Oktober 2017, hlm. 1220-1229

e-ISSN: 2548-964X http://j-ptiik.ub.ac.id

Analisis Estimasi Biaya Pembuatan Perangkat Lunak Menggunakan Metode COCOMO II di Inagata Technosmith (Studi Kasus : Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang) Della Eko Damayanti1, Suprapto2, Andi Reza Perdanakusuma3 Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya Email: [email protected], [email protected], [email protected] Abstrak Dalam mengerjakan suatu proyek perangkat lunak, keberhasilan proyek harus dimulai dengan perencanaan yang benar. Jika perencanaannya buruk maka akan menyebabkan kegagalan proyek. Kegagalan proyek dapat berupa pembengkakan waktu proyek atau proyek tidak selesai sesuai waktu yang telah ditentukan di awal perencanaan. Pembengkakan waktu bisa mengakibatkan pembengkakan biaya proyek. Untuk mengurangi resiko pembengkakan biaya proyek dibutuhkan estimasi biaya yang tepat. Estimasi biaya proyek merupakan perkiraan waktu, biaya serta jumlah pegawai yang mengerjakan proyek. Estimasi biaya pada penelitian ini menggunakan metode COCOMO II. Metode COCOMO II menyediakan sebuah teknik estimasi biaya yang bertujuan untuk mengetahui berapa lamanya proses pengembangan perangkat lunak serta berapa jumlah pegawai yang dibutuhkan untuk menyelesaikan proyek perangkat lunak tersebut. Untuk menggambarkan karakteristik proyek, metode COCOMO II menggunakan kuesioner Scale Driver dan Effort Multipliers yang di bagikan kepada seluruh tim proyek. Untuk menggambarkan kompleksitas sistem yang akan dikerjakan, menggunakan nilai Unadjusted Function Point setiap proses Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang yang didapatkan dari analisis Data Flow Diagram. Hasil dari penelitian ini adalah estimasi biaya (waktu, biaya, jumlah pegawai) untuk menyelesaikan proyek Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang. Kata Kunci: estimasi biaya, COCOMO II, Data Flow Diagram, scale driver, effort multipliers, Unadjusted Function Point

Abstract In conducting a software project, the success of the project should begin with a proper planning. If the planning is considered as bad, it will cause the failure of the project. One of the example of failure projects takes place on the time swelling of the Time swelling can lead to the swelling of the project cost. One of the project planning phase is the project cost estimation. Project cost estimation constitutes time, cost and number estimation of employees working on the project. The cost estimation of this research uses COCOMO II method. COCOMO II method provide a cost estimation technique which aims to determine how long is the process of software development and the number of employees needed to finish the software project. To describe the characteristics of the project, COCOMO II method uses Scale Driver and Effort Multipliers questionnaires which are distributed to the entire project team. To illustrate the complexity of the system that will be done, the value of Unadjusted Function Point is used in each process of Monitoring Information System and Evaluation of Achieved-Student Scholarship Enrollment of UIN Malang which are obtained from Data Flow Diagram analysis. The research result is the cost estimation (time, cost, number of employees) to finish the Monitoring Information System project and Evaluation of Achieved-Student Scholarship Enrollment of UIN Malang. Keywords: cost estimation, COCOMO II, Data Flow Diagram, scale driver, effort multipliers, Unadjusted Function Point

Fakultas Ilmu Komputer Universitas Brawijaya

1220

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer

1. PENDAHULUAN Dalam mengerjakan suatu proyek sistem informasi, keberhasilan suatu proyek harus dimulai dengan perencanaan dan penyusunan tahap yang benar (Noerlina, 2008). Karena jika dengan perencanaan yang buruk, maka akan menyebabkan terjadinya kegagalan suatu proyek. Salah satu aktifitas dari perencanaan proyek perangkat lunak yaitu estimasi sumber daya, biaya serta jadwal proyek (Bertalya, 2009). Inagata Technosmith merupakan perusahaan pembuatan perangkat lunak yang berdiri sejak tahun 2014. Perusahaan tersebut masih terhitung baru sehingga sumber daya yang dimiliki oleh Inagata Technosmith masih terbatas. Dengan keterbatasan tersebut perusahaan seharusnya dapat memanfaatkannya dengan lebih efektif dan efisien sehingga dapat mencapai tujuan perusahaan serta nilai-nilai perusahaan. Berdasarkan wawancara yang telah dilakukan oleh peneliti dengan CEO Inagata Technosmith, perusahaan ini mengalami beberapa permasalahan dalam mengerjakan proyek pembuatan perangkat lunak yaitu proyek-proyek yang pernah dikerjakan sebelumnya mengalami pembengkakan waktu dalam menyelesaikan suatu proyek dikarenakan Inagata Technosmith menggunakan mekanisme perkiraan terhadap estimasi biaya, penjadwalan serta jumlah pegawai yang mengerjakan proyek. Sehingga seringkali hal tersebut diatasi dengan solusi penambahan personal (outsourcing) pada saat pengerjaan proyek. Selain itu gaji outsourcing tidak termasuk dalam biaya proyek, sehingga perusahaan sendiri yang harus mengatasi pembengkakan biaya tersebut dimana gaji outsourcing lebih tinggi dari gaji pegawai perusahaan. Namun untuk nominal outsourcing dan pembengkakan biaya pada proyek-proyek sebelumnya tidak bisa disebutkan dikarenakan Inagata Technosmith belum melakukan dokumentasi untuk nominal keduanya. Melihat begitu besarnya kerugian yang dihasilkan akibat buruknya perencanaan proyek, maka Inagata Technosmith perlu melakukan perbaikan dalam perencanaan proyek. Cara untuk memperbaiki perencanaan proyek tersebut yaitu dengan melakukan estimasi biaya pada proyek pengembangan perangkat lunak menggunakan metode yang tepat. Definisi dari estimasi biaya perangkat lunak (software cost estimation) yaitu suatu kegiatan melakukan prediksi atau ramalan mengenai jumlah biaya, Fakultas Ilmu Komputer, Universitas Brawijaya

1221

waktu dan jumlah anggota yang diperlukan untuk membangun perangkat lunak (Ahmed et al., 2004). Ada beberapa model estimasi biaya, pada penelitian ini menggunakan COCOMO II karena memiliki kelebihan dibandingkan dengan model yang lain yaitu dapat digunakan untuk memprediksi biaya, waktu, dan jumlah pegawai yang dibutuhkan dalam menyelesaikan proyek pembuatan perangkat lunak (Boehm, 2001). Seperti penelitian yang dilakukan oleh T.N.Sharma yang berjudul “Analysis Software Cost Estimation using COCOMO II”. Pada penelitian tersebut menunjukkan bagiamana membuat perkiraan biaya menggunakan COCOMO II pada proyek sampel, COCOMO II mempermudah untuk mengklarifikasi biaya, durasi serta semua sisi dasar perangkat lunak dengan ringkas dan jelas sehingga mengurangi resiko proyek (Sharma, 2011). Model COCOMO II ini akan di implementasikan untuk proyek yang sedang dikerjakan oleh Inagata Technosmith agar tidak mengalami kerugian yang sama dengan proyekproyek sebelumnya dikarenakan estimasi biaya yang salah. Proyek tersebut adalah Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi (SIMONEV PBSB) UIN Malang. Hasil estimasi biaya menggunakan COCOMO II akan dibandingkan dengan estimasi biaya yang digunakan oleh Inagata Technosmith. 2. LANDASAN KEPUSTAKAAN 2.1. Estimasi Biaya Estimasi biaya perangkat lunak adalah proses yang sangat penting dalam pengembangan perangkat lunak karena estimasi biaya perangkat lunak digunakan untuk mengontrol dan mengatur efisiensi pada seluruh proses yang dilakukan dalam pengembangan perangkat lunak. Sehingga akurasi biaya perangkat lunak sangat dibutuhkan. Ada banyak metode untuk menghitung estimasi biaya. Namun bisa dikelompokkan menjadi 2 model yaitu model algoritmik dan non-algoritmik. Model algoritmik yaitu model matematika yang menghasilkan estimasi biaya sebagai fungsi dari komponen biaya. Sedangkan model non-algoritmik merupakan model yang menggunakan informasi estimasi biaya dari proyek sebelumnya yang memiliki kemiripan dengan proyek yang akan di analisis (Bintiri,


2012). 2.2. Metode COCOMO II COCOMO (Constructive Cost Model) II merupakan model Algoritmik yang membantu seseorang maupun kelompok dalam melakukan estimasi biaya, usaha dan penjadwalan proyek pada saat merencanakan aktivitas pengembangan perencanaan perangkat lunak. COCOMO II merupakan metode yang menyempurnakan metode sebelumnya yaitu COCOMO 81 yang dikeluarkan pada tahun 1981. Model estimasi COCOMO telah digunakan oleh ribuan manajer proyek suatu proyek perangkat lunak, dan berdasar pada pengalaman dari ratusan proyek sebelumnya. Model ini menggunakan rumus regresi dasar, dengan parameter yang berasal dari karakteristik proyek-proyek saat ini. Model COCOMO yang asli menjadi salah satu model estimasi biaya perangkat lunak yang paling banyak digunakan dan dibahas dalam industri. Model ini menghitung usaha pengembangan perangkat lunak sebagai fungsi ukuran program dan serangkaian pengendali biaya yang menyangkut penilaian subyektif terhadap produk, perangkat keras, personel dan atribut proyek (Boehm, 2001). 2.3. Tahap implementasi COCOMO II 1.

Estimasi Usaha

Dalam metode COCOMO II, usaha dinyatakan dalam satuan person-month. Berikut ini merupakan tahapan menghitung perkiraan usaha menggunakan Metode COCOMO II. A. Mendapatkan nilai UFP (Unadjusted Function Point) Function Point digunakan untuk mengatasi kesulitan yang berhubungan dengan baris kode sebagai ukuran suatu perangkat lunak, serta untuk membantu dalam mengembangkan mekanisme prediksi usaha yang terkait dengan pengembangan perangkat lunak. Dalam melakukan analisis Function Point, sistem dibagi menjadi lima kelas besar sistem yang menilai fungsional umum dari sistem. Berikut ini merupakan 5 komponen yang digunakan untuk mengukur jumlah kompleksitas dan fungsionalitas dalam sebuah perangkat lunak. Tabel 1 merupakan komponen Function Point.

Fakultas Ilmu Komputer, Universitas Brawijaya

1222 Tabel 1. Komponen Function Point

Komponen External Input (EI) External Output (EO)

External Inquiry (EQ) Internal Logical File (ILF) External Interface File (EIF)

Keterangan Fungsi yang memindahkan data dari luar ke dalam aplikasi tanpa menyajikan manipulasi data. Fungsi yang memindahkan data dari dalam ke pengguna dan menyajikan beberapa data yang telah dimanipulasi. Fungsi yang memindahkan data dari dalam ke pengguna dan menyajikan beberapa data yang tanpa dimanipulasi. Logika dalam bentuk data tetap, yang dikelola oleh aplikasi melalui penggunaan masukan dari luar. Logika dalam bentuk data tetap, yang digunakan oleh aplikasi tetapi tidak berjalan dalam aplikasi tersebut.

Setiap komponen Function Point diklasifikasikan tingkat kompleksitasnya. Tingkat kompleksitas menentukan kuantitas Unadjusted Function Point. Bobot kompleksitas diklasifikasikan berdasarkan DET, RET, dan FTR. Berikut ini merupakan penjabaran DET, RET, dan FTR. 1. RET (Record Element Types) RET merupakan subgrup data yang dikenali oleh pengguna dalam Internal Logical File atau External Logical File. 2. DET (Data Elements Types) DET dikenali oleh pengguna sebagai sesuatu yang unik dan tidak berulang. Elemen data yang unik untuk membedakan komponen Functiont Point yang satu dengan komponen Functiont Point yang lainnya. Berupa data input untuk EI. 3. FTR (Files Type References) FTR berupa ILF atau EIF. Setiap ILF yang berupa EI dihitung sebagai FTR. Setiap ILF atau EIF yang direferensikan oleh EI atau EO atau EQ untuk memelihara (insert, update, delete) dianggap sebagai FTR. Setelah menganilisis DET, RET, dan FTR setiap fungsi, dinilai sesuai dengan bobot kompleksitas UFP. Nilai UFP yang diperoleh, akan dikalikan dengan nilai Quantitative Software Management untuk mendapatkan nilai SLOC sesuai dengan bahasa pemrograman yang digunakan. Setelah itu nilai SLOC dibagi dengan 1000 untuk mendapatkan nilai KSLOC yang bisa


disubstitusikan dalam persamaan usaha. B. Mendapatkan Nilai Scale Driver Untuk mendapatkan nilai Scale Driver, terdapat 5 parameter pengukuran untuk submodel Early Design. Penilaian dilakukan dengan pengisian kuesioner Scale Driver oleh tim proyek. Tabel 2 merupakan deskripsi parameter Scale Driver. Tabel 2. Scale Driver Scale Factor PREC

FLEX

RESL

TEAM

PMAT

Deskripsi Faktor skala yang menggambarkan pengalaman organisasi terhadap proyek-proyek sebelumnya yang sejenis Faktor skala yang menggambarkan kemampuan klien dalam menentukan tujuan dan menyampaikan serta mengkomunikasikan kebutuhan perangkat lunak kepada tim pengembang perangkat lunak Faktor skala yang menggambarkan identifikasi resiko yang terkait dengan proyek Faktor skala yang menggambarkan kemampuan setiap anggota tim proyek dalam berkomunikasi dan bekerjasama Faktor skala yang menggambarkan kematangan proses pengembangan perangkat lunak dalam organisasi. Hal ini didasarkan pada Model Kematangan Kemampuan Rekayasa Perangkat Lunak atau Capability Maturity Model (CMM).

PERS (Personnel Capability)

C.

Mendapatkan Nilai Effort Multiplier Untuk mendapatkan penilaian Effort Multiplier, metode yang digunakan sama dengan mendapatkan nilai pada Scale Driver yaitu dengan pengisian kuesioner Effort Multiplier yang berisi 7 parameter, oleh tim proyek. Tabel 3 merupakan parameter Effort Multiplier. Tabel 3 Effort Multipliers EM

RCPX (Product Reliability and Complexity)

DESKRIPSI Penilaian cost driver terkait beberapa faktor yaitu : 1. Sejauh mana perangkat lunak menjalankan aplikasi sesuai fungsinya selama periode waktu (RELY). 2. Ukuran database yang digunakan. Ukuran dapat dihitung menggunakan D/P (DATA).


RUSE (Developed for Reusability)

PDIF (Platform Difficulty)

1223 3. Perangkat lunak dan perangkat keras dalam melakukan tugasnya seperti platform (arsitektur, sistem operasi, bahasa pemrograman dan antarmuka yang terkait), sistem manajemen database, browser yang sesuai digunakan dalam menjalankan aplikasi ini (CPLX). 4. Kesesuaian dokumentasi proyek terhadap kebutuhan siklus hidup perangkat lunak (DOCU). Penilaian cost driver terkait beberapa kemampuan personel yaitu : 1. Kemampuan personel dalam analisis dan desain, efisiensi dan ketelitian, serta kemampuan untuk berkomunikasi dan bekerja sama. Dalam hal ini, dapat dinilai dari sertifikasi yang sudah didapatkan personel atau pengalaman kerja tim dalam suatu proyek (ACAP). 2. Kemampuan programmer dalam efisiensi penulisan kode program, ketelitian dan kemampuan untuk berkomunikasi dan bekerja sama sebagai sebuah tim. Dengan kata lain, berapa banyak proyek dimana programmer tersebut terlibat (PCAP). 3. Pergantian personel tiap tahun pada proyek. Semakin sedikit pergantian maka semakin tinggi skala (PCON). Penilaian cost driver terkait tingkat upaya yang diperlukan untuk mengembangkan komponen yang dimaksudkan untuk digunakan kembali pada proyek-proyek yang sedang berjalan atau proyek di masa mendatang. Penilaian cost driver terkait beberapa kendala yaitu : 1. Persentase kendala waktu eksekusi yang diharapkan dapat digunakan pada sistem perangkat lunak (TIME). 2. Persentase tingkat kendala penyimpanan utama yang


PREX (Personnel Experience)

FCIL (Facilities)

SCED (Required Development Schedule)

dikenakan pada sistem perangkat lunak (STOR). 3. Perubahan yang terjadi pada hardware dan software dalam kurun waktu tertentu (PVOL). Penilaian cost driver terkait beberapa pengalaman yaitu : 1. pengalaman kerja tim proyek pada suatu proyek pengembangan aplikasi sistem perangkat lunak atau subsistem (APLEX). 2. pemahaman tim proyek dalam menggunakan platform, interface database, jaringan, middleware (PLEX). 3. pengalaman tim proyek dalam pemrograman dengan bahasa tertentu dan pemanfaatan CASE tool dalam mengembangkan perangkat lunak (LTEX). Penilaian cost driver terkait penggunaan CASE tool dalam pengembangan perangkat lunak pada proyek, seperti dari mengubah kode yang sederhana menjadi terintegrasi dan bagaimana cara komunikasi yang digunakan dalam pengembangan perangkat lunak pada proyek (TOOL, SITE). Penilaian cost driver terkait tingkat persentase dari percepatan atau kemunduran jadwal terhadap jadwal suatu proyek yang telah ditetapkan sebelumnya.

Setelah mendapatkan estimasi usaha yang dinyatakan dengan Person-Month. Dari estimasi usaha tersebut akan dimasukkan ke dalam persamaan estimasi biaya sehingga menghasilkan perkiraan waktu, orang serta biaya yang dibutuhkan untuk menyelesaikan proyek SIMONEV PBSB UIN Malang. 3. METODOLOGI PENELITIAN Metode penelitian yang dilakukan dimulai dari studi literatur, kemudian mengidentifikasi masalah sesuai dengan topik yang akan diteliti. Setelah masalah di identifikasi, mengumpulkan data yang dibutuhkan untuk bahan analisis estimasi biaya pembuatan perangkat lunak. Bahan yang telah dikumpulkan di analisis menggunakan metode COCOMO II. Hasil Fakultas Ilmu Komputer, Universitas Brawijaya

1224

analisis estimasi biaya dengan metode COCOMO II dibandingkan dengan metode estimasi biaya yang digunakan oleh perusahaan selama ini. Setelah dibandingkan maka didapatkan kesimpulan.

Gambar 1 Metodologi Penelitian

4.

ANALISIS DAN PEMBAHASAN

Berikut ini adalah proses analisis estimasi biaya menggunakan metode COCOMO pada proyek SIMONEV PBSB beserta hasil analisisnya. 1.

Analisis Data Flow Diagram

Analisis Data Flow Diagram digunakan untuk menggambarkan kompleksitas SIMONEV PBSB UIN Malang yang diukur pada setiap fungsi. Terdapat 6 fungsi dalam SIMONEV PBSB UIN Malang yaitu Pengguna, Wisuda, Dokumen, Pengumuman, Laporan serta Tabungan. Berikut ini merupakan uraian salah satu proses SIMONEV PBSB UIN Malang, yaitu mengelola data wisuda. Proses untuk mengelola data wisuda mendapatkan input dari admin sistem berupa proses update (tambah, ubah, dan hapus) data wisuda untuk setiap mahasiswa (misal tanggal untuk wisuda) yang akan disimpan pada data store wisuda. Proses ini menghasilkan output informasi untuk mahasiswa berupa data wisuda, informasi untuk admin sistem dan pengelola berupa data alumni mahasiswa. 2.

Estimasi Usaha

A. Analisis Function Point Analisis Function Point memecah sistem menjadi komponen yang lebih kecil, sehingga lebih mudah dipahami. Tabel 4 merupakan


1225

Gambar 2 Data Flow Diagram level 1 SIMONEV PBSB UIN Malang

analisis Function Point pada fungsi mengelola data wisuda. Tabel 4. Analisis Function Point ILF Wisuda

EI F -

EI

EQ

EO

Update wisuda

-

Jadwal wisuda mahasiswa, Data alumni

Hasil analisis Function Point fungsi wisuda terdapat 1 ILF yaitu Wisuda yang berisi data yang perlu dipelihara melalui pengaksesan insert, update, atau delete di dalam sistem aplikasi, data tersebut adalah wisuda. Dan disimpan dalam file, file tersebut adalah wisuda. ILF wisuda memiliki 1 EI yaitu update (tambah, ubah dan hapus) wisuda dan 2 EO yaitu jadwal wisuda mahasiswa dan data alumni. Tidak memiliki EIF karena semua data yang diperlukan oleh sistem disimpan di dalam sistem dan tidak ada yang disimpan di luar sistem. Serta tidak memiliki EQ karena dalam proses wisuda Fakultas Ilmu Komputer, Universitas Brawijaya

tidak ada fungsi yang memindahkan data dari dalam sistem ke pengguna dan menyajikan beberapa data yang tanpa dimanipulasi. Bobot kompleksitas dari masing-masing Function Point pada setiap proses dinilai sesuai aturan DET, RET, dan FTR. Tabel 5 merupakan perhitungan DET, RET, dan FTR pada fungsi mengelola wisuda. Tabel 5 Perhitungan DET, RET, dan FTR Fungsi ILF

EIF

EI

RET Data Wisuda

Total 1 RET Total 0 RET -

DET id_wisuda, id_mahasiswa, tgl_wisuda, no_ijasah, nomor_syahadah, tgl_wisuda_hafizh Total 6 DET Total 0 DET nama, no_ijasah, no_syahadah,

FTR -

Total 0 FTR Total 0 FTR Data wisuda


EQ

EO

Total 0 RET Total 0 RET -

Total 0 RET

tgl_wisuda_kampus , tgl_wisuda_hafizh Total 5 DET Total 0 DET nim, nama, nama_jurusan, IPK, no_ijasah, no_syahadah, tgl_wisuda_kampus , tgl_wisuda_hafizh Total 8 DET

1226

Malang sebesar 12.88. B. Total 1 FTR Total 0 FTR Wisuda

Perhitungan Faktor Eksponen

Berikut ini merupakan persamaan Faktor Eksponen. E = B + 0.01 x SF

(1)

Keterangan : B : 0.91 (for COCOMO II.2000) SF : Nilai Scale Driver Tabel 8 merupakan perhitungan Scale Driver dari tim proyek SIMONEV PBSB. Tabel 8 Penilaian Scale Driver

Total 1 FTR

Dari Tabel diatas, penilaian UFP fungsi Wisuda dijabarkan pada Tabel 6. Tabel 6 Perhitungan UFP Wisuda

SF PREC FLEX RESL TEAM PMAT Total

R1 N L N EH VH

R2 H VL N EH VH

R3 H N N EH VH

R4 H VL N EH L

Nilai 2.79 4.31 4.24 0.00 2.73 14.07

Keterangan : R = Responden VL = Very Low, L = Low, N = Normal, H = High, VH = Very High, EH = Extra High

Perhitungan Total UFP seluruh fungsi SIMONEV PBSB UIN Malang dijabarkan pada Tabel dibawah ini. Tabel 7 Perhitungan KSLOC

Setelah didapatkan nilai Scale Driver, dimasukkan kedalam persamaan Faktor Eksponen. Sehingga didapatkan E sebesar 1.05. C.

Perhitungan Effort Multiplier

Tabel 9 merupakan perhitungan Effort Multiplier tim proyek SIMONEV PBSB. Tabel 9 Tabel Penilaian Effort Multiplier

Tabel diatas merupakan penjabaran UFP seluruh fungsi, kemudian hasil UFP dikalikan dengan standar konversi Source Line Of Code sesuai dengan bahasa pemrograman yang digunakan untuk pembuatan SIMONEV PBSB UIN Malang. Bahasa pemrograman yang digunakan adalah HTML, sehingga UFP setiap fungsi dikalikan dengan nilai 40. Untuk mendapatkan nilai size dalam satuan KSLOC yang bisa digunakan dalam persamaan Faktor Eksponen, SLOC harus dibagi 1000 sehingga didapatkan satuan KSLOC setiap fungsi. Hasil total KSLOC atau size SIMONEV PBSB UIN Fakultas Ilmu Komputer, Universitas Brawijaya

CD R1 R2 R3 RCPX N L L PERS N N N RUSE L EH EH PDIF H VH H PREX N N H FCIL H H H SCED N N L Total Penilaian Effort Multipliers

R4 L L N H VL H L

Nilai 0.87 1.06 1.11 1.41 1.05 0.87 1.07 1.06

Keterangan : R = Responden VL = Very Low, L = Low, N = Normal, H = High, VH = Very High, EH = Extra High Hasil Effort Multipliers sebesar 1.06. D. Perhitungan Usaha (Person Month) Berikut ini merupakan persamaan Person


Month. PM = A x

(2)

Diketahui bahwa nilai A = 2.94 (for COCOMO II.2000). Size merupakan nilai keseluruhan UFP dalam satuan KSLOC yaitu sebesar 12.88. Size dipangkatkan dengan E yang merupakan Faktor Eksponen. Nilai E sebesar 1.05. EM merupakan nilai rata-rata nilai Effort Multiplier sebesar 1.06. Maka didapatkan nilai PM sebesar 45.59. 2.

Perhitungan Estimasi Biaya

Untuk mendapatkan nilai estimasi biaya yang berisi perkiraan waktu, pegawai, dan total biaya yang dibutuhkan untuk menyelesaikan proyek SIMONEV PBSB, nilai PM dimasukkan kedalam persamaan berikut ini. TDEV = [3.67 x 𝑷𝑴(𝟎.𝟐𝟖+𝟎.𝟐 (𝑬−𝟎.𝟗𝟏)) ]

(3)

Diketahui nilai PM sebesar 45.59. Nilai E sebesar 1.05. Maka didapatkan perkiraan waktu untuk menyelesaikan proyek SIMONEV PBSB selama 11.89 bulan atau 12 bulan. Kemudian untuk mendapatkan nilai perkiraan pegawai digunakan persamaan berikut. Average Staff = PM/TDEV

(4)

Diketahui nilai PM sebesar 45.59. Nilai TDEV sebesar 12. Maka didapatkan perkiraan jumlah pegawai yang dibutuhkan untuk menyelesaikan proyek SIMONEV PBSB sebanyak 3.83 orang atau 4 orang. Maka total estimasi biaya pembuatan SIMONEV PBSB dalam satuan rupiah digunakan persamaan berikut ini. Biaya Total = Avg Staff x Avg Labor Cost

(5)

Average Labor Cost didapatkan dari standar gaji Kabupaten Malang sebesar Rp 2.099.000. Sehingga didapatkan hasil perhitungan biaya sebagai berikut. Biaya Total = 4 orang x Rp 2.099.000 = Rp 8.396.000 3.

Analisis Perbandingan Metode COCOMO II dengan Metode Perkiraan

Tabel 10 merupakan perbandingan hasil estimasi biaya menggunakan metode COCOMO II dengan metode Perkiraan yang selama ini digunakan oleh Inagata Technosmith.


1227

Tabel 10 Perbandingan Estimasi Biaya menggunakan metode COCOMO II dan metode Perkiraan

Waktu pengerjaan proyek Jumlah pegawai yang mengerjakan proyek Jumlah biaya dalam satuan bulan Biaya total

Metode Perkiraan

Metode COCOMO II

2 bulan

12 bulan

4 orang

4 orang

8.396.000

8.396.000

16.792.000 100.752.000

Inagata Technosmith memperkirakan waktu untuk menyelesaikan proyek SIMONEV PBSB UIN Malang selama 2 bulan. Menurut analis proyek SIMONEV PBSB UIN Malang, proyek ini dapat diselesaikan dalam waktu 2 bulan dengan melihat sumber daya manusia yang ada. Tetapi dengan metode COCOMO II, proyek diperkirakan akan selesai dalam waktu 12 bulan. Terdapat selisih yang cukup jauh pada perkiraan waktu untuk menyelesaikan proyek ini, karena metode COCOMO II menilai kompleksitas sistem yang diukur pada setiap fungsi dengan menggunakan nilai UFP dari analisis DFD. Selain itu metode COCOMO II juga menilai karakteristik proyek dengan kuesioner Scale Factor dan Effort Multiplier yang di isi oleh seluruh tim proyek. Setiap tim proyek memberikan penilaian yang berbeda sesuai dengan subyektif masingmasing. Ada beberapa penilaian faktor yang mempunyai selisih yang cukup jauh antara satu sama lain tim proyek yang berpengaruh terhadap selisih perkiraan waktu untuk menyelesaikan proyek ini. Jadi pada Tabel tersebut dapat disimpulkan perbedaan total biaya proyek disebabkan oleh perbedaan waktu penyelesaian proyek. Perbedaan tersebut dipengaruhi oleh 3 faktor yang tidak dilakukan dalam metode Perkiraan yang digunakan Inagata Technosmith, yaitu penilaian kompleksitas sistem setiap fungsi melalui analisis Data Flow Diagram dan penilaian karakteristik proyek melalui kuesioner Scale Driver dan Effort Multipliers. Sehingga didapatkan hasil estimasi biaya yang lebih akurat menggunakan metode COCOMO II dibandingkan dengan metode Perkiraan.


5.

KESIMPULAN

Berdasarkan hasil penelitian yang dilakukan pada Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang menggunakan metode COCOMO II. Kesimpulan yang dapat diambil sebagai berikut: 1. Estimasi biaya yang diperoleh dari hasil penelitian ini, dapat memberikan rekomendasi untuk proyek-proyek selanjutnya. Perkiraan waktu untuk menyelesaikan Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang ini menggunakan metode COCOMO II selama 12 bulan. Perkiraan pegawai untuk mengerjakan proyek ini sebanyak 4 orang, perkiraan biaya dalam 1 bulan sebesar Rp 8.396.000. Sehingga perkiraan biaya total proyek ini sebesar Rp 100.752.000. 2. Hasil analisis estimasi biaya menggunakan metode COCOMO II menunjukkan bahwa waktu yang diperlukan untuk menyelesaikan Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang lebih lama dibandingkan dengan metode Perkiraan yang digunakan oleh Inagata Technosmith. Menghasilkan perkiraan waktu yang lebih lama juga menyebabkan perkiraan biaya total proyek menjadi lebih banyak dibandingkan dengan metode Perkiraan. Hal ini dikarenakan metode COCOMO II menghitung estimasi biaya dengan terstruktur. Metode COCOMO II menggunakan analisis DFD untuk menggambarkan kompleksitas sistem yang di ukur pada setiap fungsi. Selain itu metode COCOMO II juga menilai karakteristik proyek melalui kuesioner Scale Factor dan Effort Multiplier yang di isi oleh seluruh tim proyek sehingga menghasilkan perkiraan jumlah pegawai yang mengerjakan, waktu untuk menyelesesaikan dan total biaya yang dibutuhkan untuk Sistem Informasi Monitoring dan Evaluasi Penerimaan Beasiswa Santri Berprestasi UIN Malang yang lebih akurat dibandingkan dengan menggunakan metode Perkiraan. Berdasarkan hasil penelitian yang dilakukan, maka saran yang dapat diajukan untuk penelitian selanjutnya adalah sebagai berikut : 1. Untuk penelitian selanjutnya, dalam melakukan estimasi biaya perangkat Fakultas Ilmu Komputer, Universitas Brawijaya

1228

lunak, diharapkan untuk menggunakan submodel selain Early Design agar mendapatkan pemahaman lebih terhadap metode COCOMO II ini. 2. Penelitian selanjutnya dapat mengembangkan penelitian ini dengan menambahkan metode estimasi biaya yang lainnya sebagai pembanding dengan hasil penelitian ini. DAFTAR PUSTAKA Ahmed, M.A., Saliu, M.O. & Alghamdi, J., 2004. Adaptive Fuzzy Logic-Based Framework for Software Development Effort Prediction. Information and Software Technology, 47, pp.31-48. Bertalya, 2009. Perencanaan Proyek Perangkat Lunak. [Online] http://staffsite.gunadarma.ac.id/bertalya Available at: http://staffsite.gunadarma.ac.id/bertalya [Diakses 2 December 2016]. Bintiri, G.M., SN, A. & Dillak, R.Y., 2012. Perbandingan Model Algoritmik dan Non Algoritmik Untuk Estimasi Biaya Perangkat Lunak. Seminar Nasional Aplikasi Teknologi Informasi 2012. Boehm, B., 2001. Software Cost Estimation with COCOMO II. Center for Software Engineering, 2000. COCOMO II Model Definition Manual. [Online] USC Available at: http://csse.usc.edu/csse/research/COCOMOI I/cocomo2000.0/CII_modelman2000.0.pdf [Diakses 6 November 2016]. Daniel, G., 2004. Software Quality Assurance. Tottenham Court Road, London. Longstreet, D., n.d. Function Point Analysis Training Course. [Online] www.SoftwareMetrics.com Longstreet Consulting Inc Tersedia di: http://www.softwaremetrics.com/Function% 20Point%20Training%20Booklet%20New.p df [Diakses 15 Januari 2017]. Merlo, N., 2002. COCOMO (Constructive Cost Model). Seminar on Cost Estimation WS 02/03, p.8. Noerlina, 2008. Perencanaan Manajemen Proyek Sistem Informasi Dan Teknologi Informasi Online Bisnis. Piranti Warta, 11, pp.440-50.


Sharma, T.N., 2011. Analysis of Software Cost Estimastion using COCOMO II. International Journal of Scientific & Engineering Research, 2.


1229

Analisis Estimasi Biaya Pembuatan Perangkat Lunak Menggunakan

Recommend Documents