Evaluasi Biaya Perangkat Lunak Menggunakan Metode Fuzzy Use Case Point

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: 2548-964X Vol. 2, No. 7, Juli 218, hlm. 2649-2659 http://j-ptiik.ub.ac.id Evaluasi Biaya Perangkat Lunak Menggunakan Metode Fuzzy Use Case Point Rika Priyanti Manik 1, Andi Reza Perdanakusuma 2, Mochamad Chandra Saputra 3 Program Studi Sistem Informasi, Email: 1 rikapriya@gmail.com, 2 andireza@ub.ac.id, 3 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. 1. PENDAHULUAN Menurut Kashyap et al (214), estimasi biaya perangkat lunak bersifat sangat penting untuk tawar-menawar, pembuatan anggaran, pengendalian dan perencanaan.untuk dapat memproduksi berbagai perangkat lunak dalam cakupan waktu dan biaya yang terbatas, maka dibutuhkan sebuah perencanaan yang baik dalam mengalokasikan biaya. PT.Sekawan Media Fakultas Ilmu Komputer Universitas Brawijaya 2649

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 265 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, 22).Metode Fuzzy Use Case Point yaitu metode Use Case Point yang telah ditingkatkan dengan menggunakan logika fuzzy pada penelitian Nassif et al (21). 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 215 (Hariyanto dan Wahono, 215). 2. LANDASAN KEPUSTAKAAN 2.1. Manajemen Proyek Menurut Schwalbe (24), 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, 23). 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, 212). 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 (212), 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 (212), 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 Metode Use Case Point dapat digunakan untuk mengestimasi usaha pengembangan perangkat lunak berdasarkan use case (Anda,

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2651 22). 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 215. Persamaan Use Case Point terdiri dari 3 variabel (Clemmons, 26): 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, 26) seperti pada persamaan 1 berikut: UUCP = UAW + UUCW (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: n UAW = i=1 BobotAktor i (2) n merupakan jumlah aktor, i merupakan urutan tertentu, sedangkan BobotAktor i 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: n UUCW = i=1 BobotUseCase i (3) n merupakan jumlah use case, i merupakan urutan tertentu, sedangkan BobotUseCase i merupakan bobot use caseurutan ke-i(lihat Tabel 2). Kategori Aktor Sederhana Tabel 1. Kategori Aktor Deskripsi Aktor mewakili sistem lain dengan Application Bobot Aktor 1 Medium Kompleks Programming Interface (API) yang ditetapkan. Aktor mewakili sistem lain yang berinteraksi lewat protokol, seperti Transmission Control Protocol/Internet Protocol. Aktor merupakan orang yang berinteraksi melalui Graphical User Interface. Tabel 2. Kompleksitas Use Case Jumlah Transaksi dalam Use Case 2 3 Bobot 1 5 2 5 3 6.45 4 7.5 5 8.55 6 1 7 11.4 8 12.5 9 13.6 1 15 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 T6 Kemudahan Instalasi.5 T7 Kemudahaan Penggunaan.5 T8 Dukungan Antar Platform 2 T9 Kemudahan untuk Mengubah 1 T1 Konkurensi 1 T11 Fitur Keamanan Khusus 1 T12 T13 Ketergantungan pada Kode Pihak Ketiga Fasilitas Pelatihan Khusus untuk Pengguna Diperlukan 1 1 1

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2652 Perceived complexity pada 13 technical factor ditetapkan antara dan 5. Nilai berarti technical factor tidak berhubungan atau berpengaruh dengan proyek, 3 berarti berpengaruh biasa, 5 berarti berpengaruh kuat. Ketika ragu-ragu, digunakan nilai 3 (Clemmons, 26).Perceived complexity pada technical factor dikalikan dengan bobot untuk mendapatkan total technical factor seperti yang ditunjukkkan pada persamaan 4 berikut: 13 TF = i=1 PerceivedComplexity Bobot i (4) TF merupakan ke-13 technical factor, Perceived Complexity merupakan dampak beragam technical factor pada produktivitas proyek,i merupakan urutan technical factor, Bobot i 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: TCF =.6 + (,1 TF) (5) TCF merupakan Technical Complexity Factor, TF merupakan ke-13 technical factor. Menurut Ochodek et al (21), terdapat masalah dalam melakukan penilaian pada technical factor maupun lingkungan, yaitu kurangnya skala standar. Penelitian yang dilakukan Anda et al (21) 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 (213) 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 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 5. Jumlah use caseyang kurang dari 5 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 sampai 5 pada setiap 8 Environmental factor pada tabel 4. Adapun nilai pada setiap environmental factor ditetapkan oleh manajer proyek (Ribu, 21). Tabel 4. Environmental Factor Ei EnvironmentalFactor Bobot E1 Keakraban dengan metode pengembangan yang digunakan 1,5 E2 Pengalaman Aplikasi,5 E3 Pengalaman Berorientasi Objek 1 E4 Menguasai Kemampuan Analis,5 E5 Motivasi 1 E6 Kebutuhan yang Stabil 2 E7 Pekerja Paruh Waktu -1 E8 Bahasa Pemrograman yang Sulit -1 8 EF = i=1 PerceivedComplexity Bobot i (6) Pada persamaan 6 di atas, nilai kompleksitas yang ditetapkan oleh manajer proyek pada enviromental factor (Perceived Complexity) tersebut dikalikan dengan bobot tiap faktor (Bobot i ). ECF = 1.4 + (.3 EF) (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, 21). Karner mengusulkan nilai jam sebesar 2 staff hours (angka 2 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 2. Sedangkan apabila penjumlahannya adalah 3 atau 4, maka digunakan nilai 28. Usaha = FUCP staffhours (8) Pada persamaan 8 di atas,fuzzy Use Case Point diperoleh dengan mengalikan Unadjusted Use Case Point dengan Technical Complexity Factor dan Environmental Complexity Factor.

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2653 FUCP = UUCP TCF ECF (9) Pada persamaan 9 di atas, usaha yang diperoleh didistribusikan dengan guideline yang dihasilkan oleh penelitian Saleh (211). 2.7. Estimasi Biaya Untuk menghitung biaya per aktivitas pelaksanaan proyek, maka penelitian ini menggunakan standar gaji Indonesia Salary Guide 214 dan 216 yang diterbitkan oleh Kelly Service. 3. METODOLOGI Gambar 1 di bawah menunjukkan langkahlangkah yang dilakukan dalam penelitian ini yang akan diuraikan sebagai berikut: 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 217. 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 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.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 Untuk mengevaluasi metode estimasi yang digunakan, maka dilakukan evaluasi dengan menggunakan hasil estimasi dan nilai aktual dari 2 data proyek pengembangan perangkat lunak

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2654 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 1 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 1 Judul Use Case Actor Precondition Main Success Scenario Login Guest 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. 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. 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 1 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. Subflow Extension Postcondition Tidak ada 3a: Aktor Guest tidak memiliki ijin masuk ke dalam sistem (belum terdaftar). 3a1: Sistem menampilkan pesan kesalahan pada pengisian data di formulir login. Aktor Guest telah masuk ke dalam sistem pada halaman user. Gambar 3. Use case diagram SIPAS

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2655 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,8/67,5*1). 5.3. Menghitung Estimasi Waktu Fuzzy Use Case Point dikalikan dengan nilai staff-hours per Use Case Point yang dikemukakan oleh Karner, yaitu sebesar 2. Nilai 2 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 2. Maka, estimasi usaha pada pengembangan perangkat lunak SIPAS adalah sebesar 2 55,8 = 111,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 1. Gambar 4. Use case diagram SMTPX Tabel 7. Unadjusted Use Case Point Perhitungan Unadjusted Use Case Weight (UUCW) Hasil 52,5 Unadjusted Acto rweight (UAW) 15 Unadjusted Use Case Point (UUCP) Tabel 8. Fuzzy Use Case Point Perhitungan UUCW+UAW= 52,5+15=67,5 Hasil Unadjusted Use Case Point 67,5 Technical Complexity Factor 1,2 Environmental Complexity Factor,8 Fuzzy Use Case Point 67,5 1,2,8 =55,8 Pada Tabel 1, lamanya waktu pengembangan mengacu pada lamanya waktu yang diperlukan pada fase manajemen proyek, yaitu yaitu 91,87 jam. Sehingga waktu yang dibutuhkan untuk pengembangan SIPAS adalah 91,87 jam. Maka, total waktu (jam) pada seluruh fase yang terdapat pada bagian Software Phase,

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2656 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 214.Oleh sebab itu, standar gaji yang digunakan pada penelitian ini yaitu standar gaji Indonesia Salary Guide 214 yang diterbitkan oleh Kelly Service, Inc. Software Phases Tabel 9. Distribusi Usaha SIPAS Aktivitas % Usaha Usaha Requirements 7.5 82,62 Spesifications 7.5 82,62 Design 1 11,16 Implementation 1 11,16 Integration Testing 7.5 82,62 Acceptance & Deployment 7.5 82,62 Total 55,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 2.84 229,57 Aktivitas Require ments Spesifica tions Total 55,8 Tabel 1. Estimasi Biaya Setiap aktivitas Jum lah staf Dur asi (ja m) 6 13, 78 6 13, 78 Design 6 18, 37 Impleme ntation Integrati on Testing Acceptan ce & Deploym ent 6 18, 37 6 13, 78 6 13, 78 Biaya per jam (Rp) Software Phases 43.75 43.75 43.75 31.25 31.25 31.25 Biaya per Pegawa i (Rp) Biaya per Aktivita s (Rp) 62.875, 3.617.2 5, 62.875, 3.617.2 5, 83.687,5 4.822.1 25, 574.62,5 43.625, 43.625, Ongoing Life Cycle Activities 3.444.3 75, 2.583.7 5, 2.583.7 5, Project Manage ment Configur ation Manage ment Quality Assuranc e Docume ntation Training and support Evaluatio n and Testing 1 91, 87 1 45, 83 1 91, 87 125. 11.483. 75, 31.25 1.432.1 87,5 31.25 1 45, 83 31.25 1 45, 83 31.25 3 76, 52 Rp31.25 2.87.9 37,5 1.432.1 87,5 1.432.1 87,5 2.391.2 5, 11.483. 75, 1.432.1 87,5 2.87.9 37,5 1.432.1 87,5 1.432.1 87,5 7.173.7 5, Pada Tabel 1 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 2.668.5 Ongoing life-cycle activities Rp 25.825. TOTAL Rp 46.493.5 Maka total estimasi biaya untuk pengembangan Sistem Informasi Pengelolaan Arsip Surat (SIPAS) dengan menggunakan metode Fuzzy Use Case Point adalah Rp 46.493.5 (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

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2657 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 (211), distribusi usaha mencakup aktivitasaktivitas 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.5, 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.75, 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.25, Spesifications 6 13,78 3.617.25, Design 6 18,37 4.822.125, Implementation 6 18,37 3.444.375, Integration Testing Acceptance & Deployment Project Management Configuration Management 6 13,78 2.583.75, 6 13,78 2.583.75, 1 91,87 11.483.75, 1 45,83 1.432.187,5 Quality Assurance 1 91,87 2.87.937,5 Documentation 1 45,83 1.432.187,5 Training and support Evaluation and Testing 5.6. Evaluasi Biaya 1 45,83 1.432.187,5 3 76,52 7.173.75, 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 Sumberdaya Manusia (staf) Fuzzy Use Case Point Aktual 26 staf 6 staf Waktu (jam) 91,87 jam 48 jam Biaya Total Rp 46.493.5 Rp.32.. 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 Perbandingan Analisis Perbandingan Alokasi Sumberdaya Manusia (staf) Analisis Perbandingan Waktu (jam) Analisis Perbandingan Biaya Total Deskripsi Perbedaan alokasi sebesar 2 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. 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 biaya sebesar Rp.14.493.5 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

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2658 6. KESIMPULAN daripada yang ditetapkan perusahaan. 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.5,pada SMTPX adalah Rp 76.618.75. 3. Hasil penjadwalan SIPAS dan SMTPX berdasarkan WBS membutuhkan alokasi 26 staf, waktu 91,87 jam, dan biaya sebesar Rp 46.493.5. Sedangkan pada SMTPX, membutuhkan alokasi 26 staf, waktu 129,84 jam, dan biaya sebesar Rp Rp 76.618.75. 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. 22. 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. 21. Estimating software development effort based on use cases - experiences from industry. The Unified Modeling Language. Modeling Languages, Concepts,and Tools, vol. 2185, pp. 487 52. Ani, Z.C. & Basri,S. 213. 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. 26. Project Estimation With Use Case Points, Diversified Technical Services, Inc. Hariyanto, M. & Wahono, R.S. 215. Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use Case Points. Journal of Software Engineering, 1(1). Kashyap,D. & Shukla,D. & Misra, A.K. 214. 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 214/15 : A Tool for Workforce Planning. Kelly Service, Inc. Employment Oulook and Salary Guide 216 : A Tool for Workforce Planning. Marchewka, J. 23.Information Technology Project Management. Hoboken, NJ Wiley. Nassif, A.& Capretz, L.F.& Ho, D.21. Enhancing Use Case Points Estimation Method Using Soft Computing Techniques. Journal of Global Research in Computer Science. Ochodek, M., Nawrocki, J. dan Kwarciak, K., 21. Simplifying Effort Estimasi Based on Use Case Points, Sciencedirect. Ribu, K. 21. Estimating Object-Oriented Software Projects with Use cases. Master of Science Thesis. University of Oslo Department of Informatics. Saleh, K. 211. Effort and Cost Allocation in Medium to Large Software Development Projects.Intenational Journal of Computers (1), 74-79. Schwalbe, K. 24. Information Technology Project Management, 3th edition. Thompson, Canada. Schwalbe, K. 212. Information Technology Project Management, 7th edition. Course Technology, Cengage Learning.

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2659 Schneider, G. & Winters, J. 1998. Applying Use cases A Practical Guide. Addison- Wesley.