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 Saputra

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