Evaluasi Biaya Perangkat Lunak Menggunakan Metode Fuzzy Use Case Point
Vol. 2, No. 7, Juli 2018, hlm. 2649-2659 http://j-ptiik.ub.ac.id
Evaluasi Biaya Perangkat Lunak Menggunakan
Fuzzy Use Case Point 1 Metode 2 3 Rika Priyanti Manik , Andi Reza Perdanakusuma , Mochamad Chandra SaputraProgram Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya 1 2 3 Email: rikapriya@gmail.com, andireza@ub.ac.id, andra@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.
pengendalian dan perencanaan.Untuk dapat 1. memproduksi berbagai perangkat lunak dalam
PENDAHULUAN
cakupan waktu dan biaya yang terbatas, maka Menurut Kashyap et al (2014), estimasi dibutuhkan sebuah perencanaan yang baik dalam biaya perangkat lunak bersifat sangat penting mengalokasikan biaya. PT.Sekawan Media untuk tawar-menawar, pembuatan anggaran,
Fakultas Ilmu Komputer Universitas Brawijaya
2649
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
Metode Use Case Point dapat digunakan untuk mengestimasi usaha pengembangan perangkat lunak berdasarkan use case (Anda,
2.6. Metode Fuzzy Use Case Point
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.5. Gantt Chart
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.
Breakdown Structure (WBS) merupakan
Menurut Schwalbe (2012), Work
2.4. Work Breakdown Structure
Implementation , dan Maintenance and Support.
untuk mengembangkan sistem informasi terjadi selama fase eksekusi. Terdapat 5 fase dasar yang pada umumnya terdapat dalam pengembangan sistem yaitu Planning, Analysis, Design,
Life Cycle (PLC) karena beberapa aktivitas
kerangka kerja yang digunakan untuk menggambarkan fase-fase dalam mengembangkan sistem informasi (Schwalbe, 2012). SDLC merupakan bagian dari Project
Project Life Cycle , terdapat Systems Development Life Cycle (SDLC). SDLC adalah
Dalam fase Execute Project Plan pada
2.3. System Development Life Cycle
, dan Evaluate Project.
Plan Project , Execute Project Plan, Close Project
hidup proyek ini adalah Define Project Goal,
Project . Tahapan yang terdapat dalam siklus
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
2.2. Project Life Cycle Project Life Cycle (PLC) adalah
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.
Fuzzy Use Case Point s pada tahun 2015 (Hariyanto dan Wahono, 2015).
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
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.
Point dengan alokasi aktual yang dikeluarkan
2. LANDASAN KEPUSTAKAAN
2.1. Manajemen Proyek
Programming Interface (API)
2002). Konsep logika fuzzy diperkenalkan oleh yang ditetapkan. Prof. Lotfi Zadeh dari Universitas California di
Medium Aktor mewakili sistem lain
2 Berkeley pada 1965. Adapun penamaan Fuzzy yang berinteraksi lewat Use Case Point dikemukakan oleh Hariyanto protokol, seperti
dan Wahono pada penelitiannya yang berjudul
Transmission Control
Estimasi Proyek Pengembangan Perangkat Protocol/Internet Protocol. Lunak dengan Fuzzy Use Case Points pada tahun
Kompleks Aktor merupakan orang yang
3 2015. berinteraksi melalui
Persamaan Use Case Point terdiri dari 3 Graphical User Interface. variabel (Clemmons, 2006):
1. Unadjusted UseCase Points (UUCP)
Tabel 2. Kompleksitas Use Case
2. The Technical Complexity Factor (TCF)
Jumlah Transaksi dalam Use Case Bobot
3. The Environmental ComplexityFactor
1
5
(ECF)
2
5 Unadjusted Use Case Points (UUCP)
3
6.45
diperoleh dari penjumlahan Unadjusted Actor
4
7.5 Weight (UAW) dengan Unadjusted Use Case
5
8.55 Weight (UUCW) (Clemmons, 2006) seperti pada
6
10
persamaan 1 berikut:
7
11.4 (1) = +
8
12.5
9
13.6 Pada Tabel 1, dapat diketahui bobot
masing-masing aktor berdasarkan
10
15
kategorinya.Total Unadjusted Actor Weights (UAW) diperolehdengan menghitung berapa
Pada Tabel 2, jumlah transaksi dalam setiap use banyak aktor dari masing-masing kategori dan case digunakan untuk menentukan bobotuse dikalikan dengan bobot aktorseperti persamaan case. 2 berikut:
Technical Complexity Factor (TCF) adalah
salah satu faktor untuk memperkirakan ukuran
(2) = ∑ =1 software dengan memperhitungkan n merupakan jumlah aktor, i merupakan
pertimbangan teknis pada sistem. 13 technical urutan tertentu, sedangkan
factor disajikan pada Tabel 3:
merupakan bobot aktor urutan ke-I (lihat Tabel
Tabel 3. Technical Factor
1). Unadjusted Use Case Weight menunjukkan kompleksitas use case yang diukur dari jumlah
Ti Technical Factor Bobot
transaksi dalam sebuah use case. Setiap use case
T1 Sistem Terdistribusi
2
dalam sistem dikategorikan dalam kategori
T2 Kinerja
1
sederhana,medium, atau kompleks. Unadjusted
T3 Efisiensi Pengguna Akhir
1 Use Case Weight diperoleh dari penjumlahan T4 Pemrosesan Internal yang Kompleks
1
bobot tiap use case menggunakan rumus pada
T5 Kemampuan Melakukan Penggunaan
1
persamaan 3 sebagai berikut:
Kembali Kode (3) = ∑
=1 T6 Kemudahan Instalasi
0.5 T7 Kemudahaan Penggunaan
0.5 n merupakan jumlah use case, i merupakan
urutan tertentu, sedangkan T8 Dukungan Antar Platform
2
merupakan bobot use caseurutan ke-i(lihat Tabel
T9 Kemudahan untuk Mengubah
1 2). T10 Konkurensi
1 T11 Fitur Keamanan Khusus
1 Tabel 1. Kategori Aktor T12 Ketergantungan pada Kode Pihak
1 Kategori Bobot Ketiga Deskripsi Aktor Aktor
T13 Fasilitas Pelatihan Khusus untuk
1 Sederhana Aktor mewakili sistem lain
1 Pengguna Diperlukan dengan Application
Perceived complexity pada 13 technical factor ditetapkan antara 0 dan 5. Nilai 0 berarti technical factor tidak berhubungan atau
untuk mendapatkan Enviromental Complexity
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
Factor (ECF). Untuk memperoleh nilai total
1,5 E2 Pengalaman Aplikasi 0,5 E3 Pengalaman Berorientasi Objek
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.
ℎ = FUCP ∗ ℎ (8)
Pada persamaan 8 di atas,Fuzzy Use Case
1 E4 Menguasai Kemampuan Analis 0,5 E5 Motivasi
Tabel 4. Environmental Factor Ei EnvironmentalFactor Bobot E1 Keakraban dengan metode pengembangan yang digunakan
berpengaruh dengan proyek, 3 berarti berpengaruh biasa, 5 berarti berpengaruh kuat. Ketika ragu-ragu, digunakan nilai 3 (Clemmons, 2006).Perceived complexity pada technical
= 0.6 + (0,01 ∗ ) (5) TCF merupakan Technical Complexity Factor , TF merupakan ke-13 technical factor.
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:
Menurut Ochodek et al (2010), terdapat masalah dalam melakukan penilaian pada
proyek (Ribu, 2001).
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
Point diperoleh dengan mengalikan Unadjusted Use Case Point dengan Technical Complexity Factor dan Environmental Complexity Factor .
= ∗ ∗ (9)
2.7. Estimasi Biaya
Dalam melakukan estimasi waktu, perlu diketahui nilai Unadjusted Use Case Point,
Untuk mengevaluasi metode estimasi yang digunakan, maka dilakukan evaluasi dengan menggunakan hasil estimasi dan nilai aktual dari 2 data proyek pengembangan perangkat lunak
3.7. Evaluasi Metode Estimasi
Breakdown Structure .
Penjadwalan terdiri dari sumberdaya manusia, waktu, dan biaya pada setiap aktivitas dalam melakukan pengembangan sistem informasi. Penjadwalan dilakukan dalam Work
3.6. Penjadwalan
Indonesia Salary Guide yang dikeluarkan oleh Kelly Service.
Estimasi biaya diperoleh dengan mengalikan nilai usaha pada standar gaji. Standar gaji yang digunakan mengacu pada
Estimasi Biaya
Gambar 2. Tahapan estimasi waktu 3.5.
, Fuzzy Use Case Point, usaha, dan distribusi usaha yang digambarkan pada gambar 2.
Technical Complexity Factor , Environmental Complexity Factor
3.4. Estimasi Waktu
Pada persamaan 9 di atas, usaha yang diperoleh didistribusikan dengan guideline yang dihasilkan oleh penelitian Saleh (2011).
dilakukan pembuatan use case diagram oleh tim pengembang. Pengumpulan data dilakukan sejak Maret sampai Juni 2017.
factor oleh manajer proyek. Pada tahap ini juga
mendapatkan pengerjaan dan biaya pengembangan perangkat lunak, dan pengisian lembar penilaian untuk menilai environmental
use case scenario , wawancara untuk
Pada tahap ini dilakukan pengumpulan data dengan metode observasi untuk mendapatkan
3.3. Pengumpulan Data
Pada bagian ini, dilakukan kajian terhadap literatur-literatur ilmiah yang berkaitan dengan penelitian.
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.
Identifikasi Masalah dan Menentukan Metode Estimasi
Gambar 1. Metodologi penelitian 3.1.
Gambar 1 di bawah menunjukkan langkah- langkah yang dilakukan dalam penelitian ini yang akan diuraikan sebagai berikut:
Guide 2014 dan 2016 yang diterbitkan oleh Kelly Service.
Untuk menghitung biaya per aktivitas pelaksanaan proyek, maka penelitian ini menggunakan standar gaji Indonesia Salary
3. METODOLOGI
3.2. Studi Pustaka
4. HASIL
5.1. Menghitung Unadjusted Use Case Point
Jumlah Transaksi: 2 5. PEMBAHASAN
Transaksi 2: 1) Sistem menampilkan pesan kesalahan pada pengisian data di formulir login.
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.
01 Judul Use Case Login
case . Unadjusted Use Case Weight dapat
dihitung ketika bobot setiap tingkatan transaksi dikalikan dengan banyaknya use case pada setiap tingkatan transaksi.
yang telah selesai, yaitu SIPAS dan SMTPX.
3.8. Evaluasi Biaya
Actor Guest Precondition
10 tingkatan berdasarkan banyaknya transaksi dalam use
Kode Use Case
Tabel 5. Use Case Scenario Use Case Login pada SIPAS
diperoleh hasil dari lembar penilaian environmental factor yang telah diisi oleh manajer proyek.
use case dideskripsikan dalam use case scenario seperti pada Tabel 5. Melalui use case scenario , diperoleh jumlah transaksi pada setiap use case seperti pada Tabel 6. Pada bagian ini,
. Setiap
use case
15
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
Evaluasi biaya dilakukan dengan cara membandingkan hasil estimasi dengan nilai aktual.
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
- 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.
Postcondition Aktor Guest telah masuk ke dalam sistem pada halaman user.
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.
Gambar 3. Use case diagram SIPAS
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.
Main Success Scenario 1) Aktor Guest mengisi formulir login berupa nama dan sandi pengguna.
5) Sistem menampilkan halaman pengguna. Setiap aktor dikategorikan berdasarkan diperoleh pembagian sumberdaya staf dan waktu antarmuka yang digunakan aktor untuk (jam) yang disajikan pada Tabel 10. 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 sebesar 67,5menunjukkan ukuran
Point
perangkat lunak dengan tidak mempertimbangkan pengaruh technical factor (faktor teknis) pada produktivitas proyek dan pengaruh environmental factor (faktor lingkungan).
Fuzzy Use Case Point
5.2. Menghitung
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
Gambar 4. Use case diagram SMTPX Point untuk mendapatkan besarnya usaha
pengembangan perangkat lunak. Technical
Complexity Factor dan Environmental Complexity Factor meningkatkan besarnya Tabel 7. Unadjusted Use Case Point
Unadjusted Use Case Point sekitar 82 % Perhitungan Hasil (55,08/67,5*100).
Unadjusted Use Case Weight 52,5 (UUCW)
5.3. Menghitung Estimasi Waktu
15 Unadjusted Acto rWeight (UAW) Fuzzy Use Case Point dikalikan dengan
UUCW+UAW= Unadjusted Use Case Point
nilai staff-hours per Use Case Point yang
(UUCP) 52,5+15=67,5 dikemukakan oleh Karner, yaitu sebesar 20.
Nilai 20 yang digunakan dalam penelitian ini
Tabel 8. Fuzzy Use Case Point
ditentukan berdasarkan teori penentuan staff
Perhitungan Hasil hour yang dikemukakan oleh Schneider dan
67,5 Unadjusted Use Case Point
Winter (1998). Jumlah faktor pada faktor
1,02
lingkungan pertama sampai keenam yang di Technical Complexity Factor bawah 3 dihitung dan ditambahkan dengan 0,8
Environmental Complexity Factor
jumlah faktor pada faktor lingkungan ketujuh sampai delapan yang di atas 3. Jika 67,5×1,02× 0,8
Fuzzy Use Case Point =55,08
penjumlahannya adalah 2 atau kurang dari 2, maka nilai staff hour yang digunakan adalah 20. Maka, estimasi usaha pada pengembangan Pada Tabel 10, lamanya waktu pengembangan mengacu pada lamanya waktu perangkat lunak SIPAS adalah sebesar 20 yang diperlukan pada fase manajemen proyek, ×55,08 = 1101,6 staff-hours. Pada Tabel 9, total yaitu yaitu 91,87 jam. Sehingga waktu yang estimasi usaha tersebut didistribusikan ke dalam dibutuhkan untuk pengembangan SIPAS adalah berbagai aktivitas dalam pengembangan
91,87 jam. Maka, total waktu (jam) pada seluruh perangkat lunak lunak sesuai persentase usaha fase yang terdapat pada bagian Software Phase, setiap aktivitas.Dari distribusi usaha tersebut, disesuaikan dengan waktu yang dibutuhkan dalam fase Manajemen Proyek, yaitu 91,87 jam.
5.4. Menghitung Estimasi Biaya
52 Rp31 .250 2.391.2 50,00
1 91,
87 31.25 2.870.9 37,50 2.870.9
37,50 Docume ntation
1 45,
83
31.25 1.432.1 87,50 1.432.1
87,50 Training and support
1 45,
83
31.25 1.432.1 87,50 1.432.1
87,50 Evaluatio n and
Testing
3 76,
7.173.7 50,00
31.25 1.432.1 87,50 1.432.1
Pada Tabel 10 di atas, diperoleh nilai 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).
2. Level kedua merupakan 3 tahap pertama dari Project Life Cycle yang telah dijelaskan sekilas bab 2. 3 Tahap awal dari siklus hidup proyek adalah Define Project
Goal , Plan Project, dan Execute Project Plan . Estimasi biaya dilakukan pada tahap Plan Project . Pengembangan SIPAS
87,50 Quality Assuranc e
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
37 43.75 803.687 ,50 4.822.1 25,00
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 lah staf Dur asi (ja m) Biaya per jam (Rp) Biaya per Pegawa i (Rp) Biaya per Aktivita s (Rp)
Software Phases Require ments
6 13,
78 43.75 602.875 ,00 3.617.2 50,00
Spesifica tions 6 13,
78 43.75 602.875 ,00 3.617.2
50,00 Design 6 18,
Impleme ntation 6 18,
Manage ment 1 45,
37 31.25 574.062 ,50 3.444.3
75,00 Integrati on
Testing
6 13, 78 31.25 430.625
,00 2.583.7 50,00
Acceptan ce & Deploym ent
6 13, 78 31.25 430.625
,00 2.583.7 50,00
Ongoing Life Cycle Activities Project Manage ment
1 91,
87 125.0 00 11.483.
750,00 11.483.
750,00 Configur ation
83 dilakukan pada tahap Execute Project Plan .
3. Level ketiga terdiri dari 2 fase yaitu
Acceptance & Deployment 6 13,78 2.583.750,00
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.
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.
Tabel 14. Analisis Hasil Esimasi SIPAS Analisis Perbandingan Deskripsi Analisis Perbandingan Alokasi Sumberdaya Manusia (staf)
Faktor penyebab perbedaan alokasi sumberdaya manusia, waktu, dan biaya total dari pengembangan perangkat lunak SIPAS disajikan pada Tabel 14.
26 staf 6 staf Waktu (jam) 91,87 jam 480 jam Biaya Total Rp 46.493.500 Rp.32.000.000
Tabel 13. Perbandingan Hasil Estimasi SIPAS Fuzzy Use Case Point Aktual Sumberdaya Manusia (staf)
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 :
5.6. Evaluasi Biaya
Evaluation and Testing 3 76,52 7.173.750,00
Training and support 1 45,83 1.432.187,50
Quality Assurance 1 91,87 2.870.937,50 Documentation 1 45,83 1.432.187,50
Configuration Management 1 45,83 1.432.187,50
Project Management 1 91,87 11.483.750,00
Integration Testing 6 13,78 2.583.750,00
Software Phase dan Ongoing Activity
Design 6 18,37 4.822.125,00 Implementation 6 18,37 3.444.375,00
Requirements 6 13,78 3.617.250,00 Spesifications 6 13,78 3.617.250,00
Tabel 12. Estimasi Penjadwalan SIPAS Aktivitas Staf Durasi (jam) Biaya (rupiah)
Software Engineer , 9 Test Analyst, 1 Project Manager , 1 Software Quality Assurance.
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
Engineer , 9 Test Analyst, 1 Project Manager , 1 Software Quality Assurance . Sedangkan pada
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
Configuration Management , Quality Assurance , Documentation, Training & Support , dan Evaluation and Testing.
& Deployment, Project Management,
Design, Implementation , dan Acceptance
4. Level keempat terdiri dari dari 12 fase yaitu Requirements , Spesifications ,
Phases dan Ongoing Activity.
sesuai guideline distribusi usaha yang dibuat oleh Kassem Saleh (2011), distribusi usaha mencakup aktivitas- aktivitas yang terdapat dalam Software
Analisis Perbandingan Biaya Total Perbedaan alokasi biaya sebesar Rp.14.493.500 ini terjadi karena pada metode Fuzzy Use Case Point, alokasi sumberdaya manusia lebih besar, dan standar gaji yang digunakan pada penelitian ini juga lebih tinggi daripada yang ditetapkan perusahaan.
6. KESIMPULAN
Setelah melakukan penelitian ini, penulis menarik kesimpulan sebagai berikut:
Journal of Global Research in Computer Science.
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.
Ochodek, M., Nawrocki, J. dan Kwarciak, K., 2010. Simplifying Effort Estimasi Based on Use Case Points, Sciencedirect.
Refining the Use Case Classification for Use Case Point Method for Software Effort Estimation. Association of Computer Electronics and Electrical Engineers.
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. Schwalbe, K. 2012. Information Technology
Project Management , 7th edition. Course Technology, Cengage Learning.
Kelly Service, Inc. Employment Oulook and
Kashyap,D. & Shukla,D. & Misra, A.K. 2014.
1. Estimasi waktu yang menggunakan metode Fuzzy Use Case Point pada SIPAS adalah 91,7 jam, pada SMTPX adalah 129,84 jam.
sebesar Rp 46.493.500,pada SMTPX adalah Rp 76.618.750.
Hariyanto, M. & Wahono, R.S. 2015. Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use Case Points. Journal of
Clemmons, R.K. 2006. Project Estimation With Use Case Points, Diversified Technical Services, Inc.
Special Issue-Agile Symposium , Malaysia, vol.25(4).
Effort Estimation in Agile Software Development Using Use Case Points.
pp. 487 –502. Ani, Z.C. & Basri,S. 2013. A Case Study of
Languages, Concepts,and Tools , vol. 2185,
2. Estimasi biaya menggunakan metode
Software Engineering , 1(1).
Fuzzy Use Case Point pada SIPASadalah
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.
Case Point , estimasi alokasi sumberdaya
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
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.
DAFTAR PUSTAKA
Anda, B. 2002. Comparing effort estimatesbased on use cases with expert estimates.Empirical Assessment in
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
SoftwareEngineering (EASE) , (p.13). Keele UK.
Schneider, G. & Winters, J. 1998. Applying Use
cases
- – A Practical Guide. Addison- Wesley.