Fakultas Ilmu Komputer
2649
Evaluasi Biaya Perangkat Lunak Menggunakan
Metode Fuzzy Use Case Point
Rika Priyanti Manik1, Andi Reza Perdanakusuma2, Mochamad Chandra Saputra3 Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya
Email: 1rikapriya@gmail.com, 2andireza@ub.ac.id, 3andra@ub.ac.id
Abstrak
Estimasi biaya perangkat lunak merupakan aspek yang sangat penting dalam proyek teknologi informasi untuk pembuatan anggaran. Software house memproduksi beragam perangkat lunak secara berkelanjutan dalam waktu dan biaya yang terbatas. Oleh sebab itu, dibutuhkan sebuah pembuatan anggaran yang baik, dengan cara melakukan estimasi biaya. Software house PT. Sekawan Media Informatika dan CV. Profile Image pada penelitian ini belum memiliki format standar dalam menentukan estimasi biaya. Estimasi biaya pada penelitian ini menggunakan metode Fuzzy Use Case Point. Estimasi biaya diperoleh setelah mendapatkan estimasi waktu. Kemudian, estimasi biaya dan waktu yang diperoleh dialokasikan ke setiap fase yang terjadi pada tahap pengembangan perangkat lunak (dalam hal ini yaitu SIPAS dan SMTPX) sehingga memberikan saran penjadwalan pengembangan perangkat lunak SIPAS dan SMTPX. Metode Fuzzy Use Case Point, yang digunakan untuk memperoleh estimasi biaya, dievaluasi menggunakan 2 proyek perangkat lunak yang telah selesai. Pada akhir penelitian ini, dilakukan evaluasi biaya pengembangan perangkat lunak, dengan membandingkan hasil estimasi biaya yang diperoleh menggunakan metode Fuzzy Use Case Point dengan alokasi biaya aktual yang dikeluarkan perusahaan. Hasil evaluasi pada penelitian ini bermanfaat untuk memberikan pertimbangan bagi software house dalam mengalokasikan biaya pengembangan perangkat lunak melalui metode estimasi Fuzzy Use Case Point.
Kata kunci: estimasi biaya, use case point, fuzzy use case point
Abstract
Software cost estimation is a very important aspect in information technology project for budgeting. Software house produces various software continously in limited time and cost. Therefore, a good budgeting is required by doing cost estimation. Software house PT. Sekawan Media Informatika dan CV. Profile Image at this research, still do not have a standard format to do cost estimation. Cost estimation in this research utilizes Fuzzy Use Case Point method. Cost estimation is obtained after getting time estimation. Then, the estimated cost and time are allocated to each phase that occurs in the software development (in this research, SIPAS and SMTPX), thus it provides suggestion for scheduling the development of software SIPAS and SMTPX. Fuzzy Use Case Point method, that is used to get the cost estimation, evaluated by using 2 software development projects that had been completed. At the end of this research, evaluation of cost estimation for software development is conducted, by comparing
the cost estimation result which is gotten by using Fuzzy Use Case Point method with software house’s
actual cost allocation. The evaluation result from this research is useful to give such as consideration for software house to allocate cost for software development through estimation method Fuzzy Use Case Point.
Keywords:cost estimation, use case point, fuzzy use case point.
1. PENDAHULUAN
Menurut Kashyap et al (2014), estimasi biaya perangkat lunak bersifat sangat penting untuk tawar-menawar, pembuatan anggaran,
Informatika dan CV.Profile Image melakukan estimasi biaya dengan melakukan perkiraan. Perkiraan biaya ditetapkan dengan pertimbangan manajer terhadap jumlah sumberdaya yang tersedia, tingkat kesulitan pada tahap implementasi perangkat lunak, dan kemampuan keuangan pelanggan. Sehingga tidak ada format standar yang pasti digunakan dalam melakukan estimasi. Perusahaan tempat penelitian penulis juga merupakan perusahaan yang baru saja berdiri 4-5 tahun, sehingga masih membutuhkan banyak pengalaman dalam memperkirakan biaya. Kegagalan estimasi biaya sering terjadi karena kebutuhan yang berubah-ubah dari pihak pelanggan Software House. Maka perlu dilakukan perencanaan yang matang dalam mengestimasi biaya yang diukur melalui pendefinisian kebutuhan pengguna terhadap perangkat lunak.
Untuk memperoleh estimasi biaya, maka harus diketahui estimasi waktu yang diperlukan selama tahap pengembangan perangkat lunak. Estimasi biaya dan waktu yang diperoleh dialokasikan ke dalam fase-fase yang terjadi selama pengembangan, sehingga menghasilkan penjadwalan.Pada akhir penelitian ini, dilakukan evaluasi biaya pengembangan perangkat lunak, dengan membandingkan hasil estimasi yang diperoleh menggunakan metode Fuzzy Use Case Point dengan alokasi aktual yang dikeluarkan perusahaan. Hasil evaluasi pada penelitian ini bermanfaat untuk memberikan pertimbangan bagi software house dalam mengalokasikan biaya pengembangan perangkat lunak melalui metode estimasi Fuzzy Use Case Point.
Metode Use Case Point dapat digunakan untuk mengestimasi usaha pengembangan perangkat lunak berdasarkan use case (Anda, 2002).Metode Fuzzy Use Case Point yaitu metode Use Case Point yang telah ditingkatkan dengan menggunakan logika fuzzy pada penelitian Nassif et al (2010). Metode ini kemudian disebut Fuzzy Use Case Point pada penelitian Hariyanto yang berjudul Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use Case Points pada tahun 2015 (Hariyanto dan Wahono, 2015).
2. LANDASAN KEPUSTAKAAN 2.1. Manajemen Proyek
Menurut Schwalbe (2004), manajemen proyek merupakan penerapan dari ilmu pengetahuan, keterampilan, peralatan, dan
teknik untuk aktifitas suatu proyek dengan maksud memenuhi atau melampaui kebutuhan pemangku kepentingan dan harapan dari sebuah proyek.
2.2. Project Life Cycle
Project Life Cycle (PLC) adalah sekumpulan tahapanlogis yang menggambarkan kehidupan sebuah proyek dari awal hingga akhir untuk mendefinisikan, membangun, dan memberikan produk dari proyek (Marchewka, 2003). Estimasi biaya dilakukan pada salah satu tahap Project Life Cycle, yaitu pada tahap Plan Project. Tahapan yang terdapat dalam siklus hidup proyek ini adalah Define Project Goal, Plan Project, Execute Project Plan, Close Project, dan Evaluate Project.
2.3. System Development Life Cycle
Dalam fase Execute Project Plan pada Project Life Cycle, terdapat Systems Development Life Cycle (SDLC). SDLC adalah kerangka kerja yang digunakan untuk
menggambarkan fase-fase dalam
mengembangkan sistem informasi (Schwalbe, 2012). SDLC merupakan bagian dari Project Life Cycle (PLC) karena beberapa aktivitas untuk mengembangkan sistem informasi terjadi selama fase eksekusi. Terdapat 5 fase dasar yang pada umumnya terdapat dalam pengembangan sistem yaitu Planning, Analysis, Design, Implementation, dan Maintenance and Support.
2.4. Work Breakdown Structure
Menurut Schwalbe (2012), Work Breakdown Structure (WBS) merupakan pengelompokan pekerjaan terkait dalam proyek dan penentuan keseluruhan cakupan proyek. WBS menggambarkan pekerjaan pada proyek dengan menguraikan aktivitas pekerjaan ke dalam tingkatan task yang berbeda-beda.
2.5. Gantt Chart
Menurut Schwalbe (2012), Gantt Chart merupakan format standar untuk menampilkan informasi penjadwalan suatu proyek dengan membuat daftar aktivitas proyek disertai penanggalan awal dan akhir sesuai proyek.
2.6. Metode Fuzzy Use Case Point
2002). Konsep logika fuzzy diperkenalkan oleh Prof. Lotfi Zadeh dari Universitas California di Berkeley pada 1965. Adapun penamaan Fuzzy Use Case Point dikemukakan oleh Hariyanto dan Wahono pada penelitiannya yang berjudul Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use Case Points pada tahun 2015.
Persamaan Use Case Point terdiri dari 3 variabel (Clemmons, 2006):
1. Unadjusted UseCase Points (UUCP) 2. The Technical Complexity Factor (TCF) 3. The Environmental ComplexityFactor
(ECF)
Unadjusted Use Case Points (UUCP) diperoleh dari penjumlahan Unadjusted Actor Weight (UAW) dengan Unadjusted Use Case Weight (UUCW) (Clemmons, 2006) seperti pada persamaan 1 berikut:
𝑈𝑈𝐶𝑃 = 𝑈𝐴𝑊 + 𝑈𝑈𝐶𝑊 (1) Pada Tabel 1, dapat diketahui bobot masing-masing aktor berdasarkan kategorinya.Total Unadjusted Actor Weights (UAW) diperolehdengan menghitung berapa banyak aktor dari masing-masing kategori dan dikalikan dengan bobot aktorseperti persamaan 2 berikut:
𝑈𝐴𝑊 = ∑𝑛𝑖=1𝐵𝑜𝑏𝑜𝑡𝐴𝑘𝑡𝑜𝑟𝑖 (2)
n merupakan jumlah aktor, i merupakan urutan tertentu, sedangkan 𝐵𝑜𝑏𝑜𝑡𝐴𝑘𝑡𝑜𝑟𝑖 merupakan bobot aktor urutan ke-I (lihat Tabel 1). Unadjusted Use Case Weight menunjukkan kompleksitas use case yang diukur dari jumlah transaksi dalam sebuah use case. Setiap use case dalam sistem dikategorikan dalam kategori sederhana,medium, atau kompleks. Unadjusted Use Case Weight diperoleh dari penjumlahan bobot tiap use case menggunakan rumus pada persamaan 3 sebagai berikut:
𝑈𝑈𝐶𝑊 = ∑𝑛𝑖=1𝐵𝑜𝑏𝑜𝑡𝑈𝑠𝑒𝐶𝑎𝑠𝑒𝑖 (3)
n merupakan jumlah use case, i merupakan urutan tertentu, sedangkan 𝐵𝑜𝑏𝑜𝑡𝑈𝑠𝑒𝐶𝑎𝑠𝑒𝑖 merupakan bobot use caseurutan ke-i(lihat Tabel 2).
Tabel 1. Kategori Aktor
Kategori
Aktor Deskripsi
Bobot Aktor
Sederhana Aktor mewakili sistem lain dengan Application
1
Programming Interface (API)
yang ditetapkan.
Medium Aktor mewakili sistem lain yang berinteraksi lewat protokol, seperti
Transmission Control
Protocol/Internet Protocol.
2
Kompleks Aktor merupakan orang yang berinteraksi melalui
Graphical User Interface.
3
Tabel 2. Kompleksitas Use Case
Jumlah Transaksi dalam Use Case Bobot
1 5
Pada Tabel 2, jumlah transaksi dalam setiap use case digunakan untuk menentukan bobotuse case.
Technical Complexity Factor (TCF) adalah salah satu faktor untuk memperkirakan ukuran
software dengan memperhitungkan
pertimbangan teknis pada sistem. 13 technical factor disajikan pada Tabel 3:
Tabel 3. Technical Factor
Ti Technical Factor Bobot
T1 Sistem Terdistribusi 2
T2 Kinerja 1
T3 Efisiensi Pengguna Akhir 1
T4 Pemrosesan Internal yang Kompleks 1
T5 Kemampuan Melakukan Penggunaan Kembali Kode
1
T6 Kemudahan Instalasi 0.5
T7 Kemudahaan Penggunaan 0.5
T8 Dukungan Antar Platform 2
T9 Kemudahan untuk Mengubah 1
T10 Konkurensi 1
T11 Fitur Keamanan Khusus 1
T12 Ketergantungan pada Kode Pihak Ketiga
1
T13 Fasilitas Pelatihan Khusus untuk Pengguna Diperlukan
Perceived complexity pada 13 technical factor ditetapkan antara 0 dan 5. Nilai 0 berarti technical factor tidak berhubungan atau berpengaruh dengan proyek, 3 berarti berpengaruh biasa, 5 berarti berpengaruh kuat. Ketika ragu-ragu, digunakan nilai 3 (Clemmons, 2006).Perceived complexity pada technical factor dikalikan dengan bobot untuk mendapatkan total technical factor seperti yang ditunjukkkan pada persamaan 4 berikut:
𝑇𝐹 = ∑13𝑖=1𝑃𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 ∗ 𝐵𝑜𝑏𝑜𝑡𝑖(4)
TF merupakan ke-13 technical factor, Perceived Complexity merupakan dampak beragam technical factor pada produktivitas proyek,i merupakan urutan technical factor,
𝐵𝑜𝑏𝑜𝑡𝑖 merupakan bobot faktor ke-i yang ditetapkan pada setiap technical factor.
Technical factor (TF) digunakan untuk memperoleh nilai Technical Complexity Factor (TCF) seperti yang ditunjukkan pada persamaan 5 berikut:
𝑇𝐶𝐹 = 0.6 + (0,01 ∗ 𝑇𝐹) (5) TCF merupakan Technical Complexity Factor, TF merupakan ke-13 technical factor.
Menurut Ochodek et al (2010), terdapat masalah dalam melakukan penilaian pada technical factor maupun lingkungan, yaitu kurangnya skala standar. Penelitian yang dilakukan Anda et al (2001) menyatakan kesulitan dalam memberikan penilaian pada technical factor dan environmental factor akibat kurangnya dasar yang menjadi perbandingan, sehingga harus menebak apa yang dimaksud oleh setiap faktor. Ani dan Basri (2013) memberikan solusi untuk masalah ini. Untuk menyederhanakan estimasi, Ani dan Basri memberikan nilai 3 terhadap semua technical factor kecuali faktor 5,8, dan 12. 3 technical factor tersebut diberikan nilai 0 saat tim sedang mengerjakan proyek pengembangan perangkat lunak yang baru. Alasan utama mengapa nilai 3 diberikan pada technical factor lainnya adalah berdasarkan jumlah use case yang kurang dari 50. Jumlah use caseyang kurang dari 50 bermakna sistem yang dikembangkan tidak terlalu kompleks, dan tingkat kompleksitas dianggap rata-rata.
Environmental Complexity Factor (ECF) adalah faktor yang diterapkan untuk memperkirakan ukuran software dengan menghitung pertimbangan lingkungan pada sistem. ECF ditentukan dengan menetapkan skor antara 0 sampai 5 pada setiap 8 Environmental
factor pada tabel 4. Adapun nilai pada setiap environmental factor ditetapkan oleh manajer proyek (Ribu, 2001).
Tabel 4. Environmental Factor
Ei EnvironmentalFactor Bobot
E1 Keakraban dengan metode pengembangan yang digunakan
1,5
E2 Pengalaman Aplikasi 0,5
E3 Pengalaman Berorientasi Objek 1
E4 Menguasai Kemampuan Analis 0,5
E5 Motivasi 1
E6 Kebutuhan yang Stabil 2
E7 Pekerja Paruh Waktu -1
E8 Bahasa Pemrograman yang Sulit -1
𝐸𝐹 = ∑8𝑖=1𝑃𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 ∗ 𝐵𝑜𝑏𝑜𝑡𝑖(6)
Pada persamaan 6 di atas, nilai kompleksitas yang ditetapkan oleh manajer proyek pada enviromental factor (Perceived Complexity) tersebut dikalikan dengan bobot tiap faktor (𝐵𝑜𝑏𝑜𝑡𝑖).
𝐸𝐶𝐹 = 1.4 + (−0.03 ∗ 𝐸𝐹) (7) Pada persamaan 7 di atas, nilai yang diperoleh dijumlahkan untuk mendapatkan total enviromental factor(EF), yang akan digunakan untuk mendapatkan Enviromental Complexity Factor (ECF). Untuk memperoleh nilai total estimasi usaha yang dikeluarkan untuk pembuatan perangkat lunak, maka nilai Fuzzy Use Case Point dikalikan dengan nilai jam yang untuk setiapUse Case Point (Ribu, 2001). Karner mengusulkan nilai jam sebesar 20 staff hours (angka 20 adalah hasil perkalian staff dengan hour) untuk ditetapkan pada setiap Use Case Point. Schneider dan Winter (1998) mengusulkan untuk menetapkan nilai staff hours berdasarkan environmental factor. Jumlah faktor pada faktor lingkungan pertama sampai keenam yang kompleksitasnya di bawah 3 dihitung dan ditambahkan dengan jumlah faktor pada faktor lingkungan ketujuh sampai delapan yang kompleksitasnya di atas 3. Jika total penjumlahannya 2 atau kurang dari 2, maka nilai staff hour yang digunakan adalah 20. Sedangkan apabila penjumlahannya adalah 3 atau 4, maka digunakan nilai 28.
𝐹𝑈𝐶𝑃 = 𝑈𝑈𝐶𝑃 ∗ 𝑇𝐶𝐹 ∗ 𝐸𝐶𝐹 (9) Pada persamaan 9 di atas, usaha yang diperoleh didistribusikan dengan guideline yang dihasilkan oleh penelitian Saleh (2011).
2.7. Estimasi Biaya
Untuk menghitung biaya per aktivitas pelaksanaan proyek, maka penelitian ini menggunakan standar gaji Indonesia Salary Guide 2014 dan 2016 yang diterbitkan oleh Kelly Service.
3. METODOLOGI
Gambar 1 di bawah menunjukkan langkah-langkah yang dilakukan dalam penelitian ini yang akan diuraikan sebagai berikut:
Gambar 1. Metodologi penelitian
3.1.Identifikasi Masalah dan Menentukan Metode Estimasi
Pada tahap ini dilakukan identifikasi masalah yangdihadapi oleh PT. ABC terkait estimasi biaya sebuah proyek perangkat lunak, kemudian menentukan metode estimasi yang paling tepat digunakan sesuai permasalahan yang dihadapi.
3.2.Studi Pustaka
Pada bagian ini, dilakukan kajian terhadap literatur-literatur ilmiah yang berkaitan dengan penelitian.
3.3.Pengumpulan Data
Pada tahap ini dilakukan pengumpulan data dengan metode observasi untuk mendapatkan use case scenario, wawancara untuk mendapatkan pengerjaan dan biaya pengembangan perangkat lunak, dan pengisian lembar penilaian untuk menilai environmental factor oleh manajer proyek. Pada tahap ini juga dilakukan pembuatan use case diagram oleh tim pengembang. Pengumpulan data dilakukan sejak Maret sampai Juni 2017.
3.4.Estimasi Waktu
Dalam melakukan estimasi waktu, perlu diketahui nilai Unadjusted Use Case Point, Technical Complexity Factor, Environmental Complexity Factor, Fuzzy Use Case Point, usaha, dan distribusi usaha yang digambarkan pada gambar 2.
Gambar 2. Tahapan estimasi waktu
3.5.Estimasi Biaya
Estimasi biaya diperoleh dengan mengalikan nilai usaha pada standar gaji. Standar gaji yang digunakan mengacu pada Indonesia Salary Guide yang dikeluarkan oleh Kelly Service.
3.6.Penjadwalan
Penjadwalan terdiri dari sumberdaya manusia, waktu, dan biaya pada setiap aktivitas dalam melakukan pengembangan sistem informasi. Penjadwalan dilakukan dalam Work Breakdown Structure.
3.7.Evaluasi Metode Estimasi
yang telah selesai, yaitu SIPAS dan SMTPX.
3.8.Evaluasi Biaya
Evaluasi biaya dilakukan dengan cara membandingkan hasil estimasi dengan nilai aktual.
4. HASIL
Pada Gambar 3, use case diagram pada SIPAS terdiri dari 6 aktor dan 10 use case. Pada Gambar 4, use case diagram pada SMTPX terdiri dari 5 aktor dan 15 use case. Setiap use casedideskripsikan dalam use case scenarioseperti pada Tabel 5. Melalui use case scenario, diperoleh jumlah transaksi pada setiap use caseseperti pada Tabel 6. Pada bagian ini, diperoleh hasil dari lembar penilaian environmental factor yang telah diisi oleh manajer proyek.
Tabel 5. Use Case Scenario Use Case Login pada SIPAS
Kode Use Case 01
Judul Use Case Login
Actor Guest
Precondition • Aktor Guest belum masuk ke dalam sistem.
• Komputer yang digunakan untuk melakukan login memiliki koneksi ke internet.
• Aktor Guest telah berada pada halaman login sistem.
Main Success Scenario
1) Aktor Guest mengisi formulir
login berupa nama dan sandi
pengguna.
2) Aktor Guest memilih untuk masuk ke halaman pengguna. 3) Sistem memvalidasi data pada
formulir login.
4) Sistem melakukan autentikasi bagi aktor Guest yang akan masuk ke dalam sistem. 5) Sistem menampilkan halaman
pengguna.
Subflow Tidak ada
Extension 3a: Aktor Guest tidak memiliki ijin masuk ke dalam sistem (belum terdaftar).
3a1: Sistem menampilkan pesan kesalahan pada pengisian data di formulir login.
Postcondition Aktor Guest telah masuk ke dalam sistem pada halaman user.
Tabel 6. Transaksi Use Case Login pada SIPAS
Transaksi 1:
1) Aktor Guest mengisi formulir login berupa nama dan sandi pengguna.
2) Aktor Guest memilih untuk masuk ke halaman pengguna.
3) Sistem memvalidasi data pada formulir login. 4) Sistem melakukan autentikasi bagi aktor Guest
yang akan masuk ke dalam sistem.
5) Sistem menampilkan halaman pengguna.
Transaksi 2:
1) Sistem menampilkan pesan kesalahan pada
pengisian data di formulir login.
Jumlah Transaksi: 2
5. PEMBAHASAN
5.1. Menghitung Unadjusted Use Case Point
Nilai Unadjusted Use Case Point diperoleh dari penjumlahan Unadjusted Use Case Weight (UUCW) dengan Unadjusted Actor Weight (UAW). Setiap use case diidentifikasi untuk dikelompokkan di antara 10 tingkatan berdasarkan banyaknya transaksi dalam use case. Unadjusted Use Case Weight dapat dihitung ketika bobot setiap tingkatan transaksi dikalikan dengan banyaknya use case pada setiap tingkatan transaksi.
Setiap aktor dikategorikan berdasarkan antarmuka yang digunakan aktor untuk berinteraksi dengan sistem untuk memperoleh perhitungan nilai Unadjusted Actor Weight pada SIPAS. Maka, dari hasil perhitungan Unadjusted Use Case Weight dan Unadjusted Actor Weight, dapat diperoleh nilai Unadjusted Use Case Point (UUCP) pada SIPAS yang disajikan pada Tabel 7. Pada Tabel 7, nilai Unadjusted Use Case Point sebesar 67,5menunjukkan ukuran
perangkat lunak dengan tidak
mempertimbangkan pengaruh technical factor (faktor teknis) pada produktivitas proyek dan pengaruh environmental factor (faktor lingkungan).
5.2. Menghitung Fuzzy Use Case Point
Nilai Fuzzy Use Case Point dapat diperoleh dengan mengalikan Unadjusted Use Case Point,
Technical Complexity Factor, dan
Environmental Complexity Factor.
Pada Tabel 8 di bawah, diperoleh nilai Fuzzy Use Case Point pada perangkat lunak SIPAS sebesar 51. Angka tersebut akan dikalikan dengan nilai staff-hours per Use Case Point untuk mendapatkan besarnya usaha pengembangan perangkat lunak. Technical Complexity Factor dan Environmental Complexity Factor meningkatkan besarnya Unadjusted Use Case Point sekitar 82 % (55,08/67,5*100).
5.3. Menghitung Estimasi Waktu
Fuzzy Use Case Point dikalikan dengan nilai staff-hours per Use Case Point yang dikemukakan oleh Karner, yaitu sebesar 20. Nilai 20 yang digunakan dalam penelitian ini ditentukan berdasarkan teori penentuan staff hour yang dikemukakan oleh Schneider dan Winter (1998). Jumlah faktor pada faktor lingkungan pertama sampai keenam yang di bawah 3 dihitung dan ditambahkan dengan jumlah faktor pada faktor lingkungan ketujuh sampai delapan yang di atas 3. Jika penjumlahannya adalah 2 atau kurang dari 2, maka nilai staff hour yang digunakan adalah 20. Maka, estimasi usaha pada pengembangan perangkat lunak SIPAS adalah sebesar 20 ×55,08 = 1101,6 staff-hours. Pada Tabel 9, total estimasi usaha tersebut didistribusikan ke dalam berbagai aktivitas dalam pengembangan perangkat lunak lunak sesuai persentase usaha setiap aktivitas.Dari distribusi usaha tersebut,
diperoleh pembagian sumberdaya staf dan waktu (jam) yang disajikan pada Tabel 10.
Gambar 4. Use case diagram SMTPX
Tabel 7. Unadjusted Use Case Point
Perhitungan Hasil
Unadjusted Use Case Weight
(UUCW)
52,5
Unadjusted Acto rWeight (UAW) 15
Unadjusted Use Case Point
(UUCP)
UUCW+UAW=
52,5+15=67,5
Tabel 8. Fuzzy Use Case Point
Perhitungan Hasil
Unadjusted Use Case Point 67,5
Technical Complexity Factor 1,02
Environmental Complexity Factor
0,8
Fuzzy Use Case Point 67,5×1,02× 0,8 =55,08
disesuaikan dengan waktu yang dibutuhkan dalam fase Manajemen Proyek, yaitu 91,87 jam.
5.4. Menghitung Estimasi Biaya
Pengembangan perangkat lunak SIPAS berlangsung dari tahun 2014.Oleh sebab itu, standar gaji yang digunakan pada penelitian ini yaitu standar gaji Indonesia Salary Guide 2014 yang diterbitkan oleh Kelly Service, Inc.
Tabel 9. Distribusi Usaha SIPAS
Aktivitas % Usaha Usaha
Software Phases
Requirements 7.5 82,62
Spesifications 7.5 82,62
Design 10 110,16
Implementation 10 110,16
Integration Testing 7.5 82,62
Acceptance & Deployment 7.5 82,62
Total 550,8
Ongoing life-cycle activities
Project Management 8.34 91,87
Configuration Management 4.16 45,83
Quality Assurance 8.34 91,87
Documentation 4.16 45,83
Training and support 4.16 45,83
Evaluation and Testing 20.84 229,57
Total 550,8
Tabel 10. Estimasi Biaya Setiap aktivitas
Aktivitas Jum
Ongoing Life Cycle Activities
Project estimasi biaya setiap aktivitas dalam pengembangan SIPAS, dengan mengalikan durasi dengan staf setiap aktivitas. Dengan menjumlahkan seluruh estimasi biaya setiap aktivitas, maka diperoleh total estimasi biaya pengembangan SIPAS pada Tabel 11.
Tabel 11. Total Estimasi Biaya Pengembangan SIPAS
Kelompok Aktivitas Total Estimasi Biaya
Software Phases Rp 20.668.500
Ongoing life-cycle activities Rp 25.825.000
TOTAL Rp 46.493.500
Maka total estimasi biaya untuk pengembangan Sistem Informasi Pengelolaan Arsip Surat (SIPAS) dengan menggunakan metode Fuzzy Use Case Point adalah Rp 46.493.500 (Empat puluh enam juta empat ratus sembilan puluh tiga ribu lima ratus rupiah).
5.5. Membuat Estimasi Penjadwalan
Padapenelitianini, WBS digunakan untuk membagi pekerjaan yang terdiri dari 4 tingkatan: 1. Level pertama merupakan perangkat lunak Sistem Informasi Pengelolaan Arsip Surat (SIPAS).
dilakukan pada tahap Execute Project Plan.
3. Level ketiga terdiri dari 2 fase yaitu Software Phase dan Ongoing Activity sesuai guideline distribusi usaha yang dibuat oleh Kassem Saleh (2011), distribusi usaha mencakup aktivitas-aktivitas yang terdapat dalam Software Phases dan Ongoing Activity.
4. Level keempat terdiri dari dari 12 fase yaitu Requirements, Spesifications, Design, Implementation, dan Acceptance & Deployment, Project Management, Configuration Management, Quality Assurance, Documentation, Training & Support, dan Evaluation and Testing.
Pada Tabel 12 di bawah ditampilkan penjadwalan pada pengembangan SIPAS di PT. ABC. Pada Tabel 12 diperoleh estimasi penjadwalan pengembangan SIPAS berdasarkan hasil distribusi usaha yang telah diperoleh sebelumnya. Lamanya pengembangan Sistem Informasi Pengelolaan Arsip Surat (SIPAS) selama 91,87 jam, total biaya sebesar Rp.46.493.500, alokasi sumberdaya sebesar 26 staff, yaitu 6 System Analyst, 9 Software Engineer, 9 Test Analyst, 1 Project Manager , 1 Software Quality Assurance. Sedangkan pada pengembangan SMTPX, pengembangan dilakukan dengan durasi 129,84 jam, total biaya sebesar Rp 76.425.750, alokasi sumberdaya sebesar 26 staff, yaitu 6 System Analyst, 9 Software Engineer, 9 Test Analyst, 1 Project Manager, 1 Software Quality Assurance.
Tabel 12. Estimasi Penjadwalan SIPAS
Aktivitas Staf Durasi
(jam)
Biaya (rupiah)
Requirements 6 13,78 3.617.250,00
Spesifications 6 13,78 3.617.250,00
Design 6 18,37 4.822.125,00
Implementation 6 18,37 3.444.375,00
Integration
Quality Assurance 1 91,87 2.870.937,50
Documentation 1 45,83 1.432.187,50
Training and
5.6. Evaluasi Biaya
Tabel 13 menunjukkan perbandingan antara estimasi alokasi sumberdaya manusia, waktu, dan biaya pengembangan SIPAS menggunakan metode Fuzzy Use Case Point dengan alokasi sumberdaya manusia, waktu, dan biaya pengembangan aktual :
Tabel 13. Perbandingan Hasil Estimasi SIPAS
Fuzzy Use
Biaya Total Rp 46.493.500 Rp.32.000.000
Faktor penyebab perbedaan alokasi sumberdaya manusia, waktu, dan biaya total dari pengembangan perangkat lunak SIPAS disajikan pada Tabel 14.
Tabel 14. Analisis Hasil Esimasi SIPAS
Analisis
Perbedaan alokasi sebesar 20 staf ini terjadi karena pada Fuzzy Use
Case Point dilakukan pembagian
sumberdaya yang lebih merata pada fase pengembangan sesuai keahlian. Sedangkan pada perusahaan PT.ABC, seorang staf dapat memiliki peran ganda, misalnya seorang manajer proyek juga berperan sebagai System Analyst.
Analisis Perbandingan
Waktu (jam)
Perbedaan alokasi waktu sebesar 388,13 ini terjadi karena pada metode Fuzzy Use Case Point, pembagian sumberdaya yang merata menyebabkan seorang staf tidak dieksploitasi secara
berlebihan sehingga
mengakibatkan kinerja yang lebih efisien.
Analisis Perbandingan
Biaya Total
Perbedaan alokasi biaya sebesar Rp.14.493.500 ini terjadi karena pada metode Fuzzy Use Case
Point, alokasi sumberdaya
daripada yang ditetapkan perusahaan.
6. KESIMPULAN
Setelah melakukan penelitian ini, penulis menarik kesimpulan sebagai berikut:
1. Estimasi waktu yang menggunakan metode Fuzzy Use Case Point pada SIPAS adalah 91,7 jam, pada SMTPX adalah 129,84 jam.
2. Estimasi biaya menggunakan metode Fuzzy Use Case Point pada SIPASadalah sebesar Rp 46.493.500,pada SMTPX adalah Rp 76.618.750.
3. Hasil penjadwalan SIPAS dan SMTPX berdasarkan WBS membutuhkan alokasi 26 staf, waktu 91,87 jam, dan biaya sebesar Rp 46.493.500. Sedangkan pada SMTPX, membutuhkan alokasi 26 staf, waktu 129,84 jam, dan biaya sebesar Rp Rp 76.618.750.
4. Estimasi alokasi sumberdaya manusia lebih besar daripada alokasi aktual karena pada metode estimasi, sumberdaya manusia disebar pada berbagai aktivitas pada pengembangan sesuai keahlian masing-masing. Estimasi waktu lebih singkat daripada durasi pengerjaan aktual karena pada estimasi dilakukan pemerataan tugas pada beragam posisi IT sehingga seorang staf lebih fokus dalam melakukan pekerjaannya selama pengembangan. Estimasi alokasi biaya lebih besar daripada alokasi biaya aktual, karena dengan menggunakan Fuzzy Use Case Point, estimasi alokasi sumberdaya yang dibutuhkan lebih besar, dan terdapat standar gaji yang lebih tinggi pada estimasi ini. Kedua hal ini menyebabkan lebih tingginya estimasi biaya dari alokasi biaya aktual.
DAFTAR PUSTAKA
Anda, B. 2002. Comparing effort estimatesbased
on use cases with expert
estimates.Empirical Assessment in SoftwareEngineering (EASE), (p.13). Keele UK.
Anda, B. & Dreiem, H. & Sjøberg, D.&Jørgensen,M. 2001. Estimating software development effort based on use cases - experiences from industry. The Unified Modeling Language. Modeling
Languages, Concepts,and Tools, vol. 2185, pp. 487–502.
Ani, Z.C. & Basri,S. 2013. A Case Study of Effort Estimation in Agile Software Development Using Use Case Points. Special Issue-Agile Symposium, Malaysia, vol.25(4).
Clemmons, R.K. 2006. Project Estimation With Use Case Points, Diversified Technical Services, Inc.
Hariyanto, M. & Wahono, R.S. 2015. Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use Case Points. Journal of Software Engineering, 1(1).
Kashyap,D. & Shukla,D. & Misra, A.K. 2014. Refining the Use Case Classification for Use Case Point Method for Software Effort Estimation. Association of Computer Electronics and Electrical Engineers.
Kelly Service, Inc. Employment Oulook and Salary Guide 2014/15 : A Tool for Workforce Planning.
Kelly Service, Inc. Employment Oulook and Salary Guide 2016 : A Tool for Workforce Planning.
Marchewka, J. 2003.Information Technology Project Management. Hoboken, NJ Wiley.
Nassif, A.& Capretz, L.F.& Ho, D.2010. Enhancing Use Case Points Estimation Method Using Soft Computing Techniques. Journal of Global Research in Computer Science.
Ochodek, M., Nawrocki, J. dan Kwarciak, K., 2010. Simplifying Effort Estimasi Based on Use Case Points, Sciencedirect.
Ribu, K. 2001. Estimating Object-Oriented Software Projects with Use cases. Master of Science Thesis. University of Oslo Department of Informatics.
Saleh, K. 2011. Effort and Cost Allocation in Medium to Large Software Development Projects.Intenational Journal of Computers (1), 74-79.
Schwalbe, K. 2004. Information Technology Project Management, 3th edition. Thompson, Canada.
