7

BAB 2 LANDASAN KEPUSTAKAAN

2.1. Penelitian Sebelumnya

Nassif et al (2010) dalam penelitiannya yang berjudul Enhancing Use Case

Points Estimation Method Using Soft Computing Techniques telah membandingkan usaha yang diperoleh dari 7 proyek perangkat lunak, dan menemukan bahwa ukuran proyek yang diperoleh dengan metode Use Case Point yang menggunakan logika fuzzy lebih mendekati ukuran aktual (ukuran sesungguhnya dalam pelaksanaan proyek) daripada ukuran yang diperoleh dengan metode Use Case Point tanpa menggunakan logika fuzzy. Standar deviasi kesalahan metode Use Case Point sebesar 25.33. Sedangkan untuk pendekatan logika fuzzy, standar deviasi sebesar 17 (Nassif et al, 2010). Sehingga standar deviasi kesalahan metode Fuzzy Use Case Points lebih kecil bila dibandingkan

dengan nilai metode Use Case Points.

2.2. Profil PT. Sekawan Media Informatika

PT. Sekawan Media Informatika atau lebih dikenal dengan nama Sekawan Media adalah sebuah perusahaan yang bergerak di bidang Software House dan IT Consultant yang berkedudukan di kota Malang. Bermula dari sebuah mimpi yang dilanjutkan dengan sebuah aksi saat ini Sekawan Media telah menjadi salah satu konsultan teknologi informasi terbaik di Indonesia. Didirikan pada tanggal 1

November 2013 dengan visi menjadi salah satu perusahaan layanan IT terbaik dan bermanfaat bagi bangsa Indonesia, Sekawan Media mulai menawarkan

layanan dalam berbagai bidang di antaranya:

1. Pengembangan aplikasi berbasis web, mobile, maupun desktop. 2. Pengembangan website dalam hal desain, pemeliharaan, dan optimasi. 3. Server dan networking dalam hal instalasi, konfigurasi, troubleshooting,

pemantauan dan pemeliharaan. 4. Konsultasi IT dalam hal analisis, evaluasi, perencanaan dan pemantauan.

Sekawan Media mencapai visinya melalui misi: 1. Menciptakan produk-produk yang dapat bersaing dan berdaya jual tinggi.

2. Menciptakan layanan yang dibutuhkan serta bermanfaat bagi masyarakat umum.

3. Mengembangkan sumber daya manusia yang memiliki pola fikir positif dan berkembang.

2.3. Profil CV. Profile Image

CV. Profile Image adalah sebuah perusahaan yang dibangun oleh sebuah tim yang terdiri dari tenaga profesional muda yang memiliki pengalaman bertahun-

tahun dibidang industri teknologi informasi, desain, dan videografi. Didirikan pada tanggal 19 Juli 2011, CV. Profile Image adalah perusahaan yang tumbuh

sebagai perusahaan unik dengan kompetensi tinggi dalam kombinasi teknologi

8

informasi, Art, Design, Videografi dan pengetahuan mendalam dalam Internet

Business Development.

Dalam upanya membangun dunia digital di Indonesia, CV. Profile Image selalu berupaya membuat terobosan-terobosan baru dalam hal memberikan

solusi tepat bagi perusahaan yang ingin membangun digital business development, mulai dari membangun konsep website, online business strategy,

sampai online campaign. Dengan didukung oleh sumber daya manusia yang mempunyai kompetensi yang tinggi serta jaringan bisnis dalam dunia digital yang

sangat luas maka akan memberikan yang tinggi serta jaringan bisnis dalam dunia digital yang sangat luas maka akan memberikan nilai menfaat yang sangat besar

dalam memberikan kontribusi dalam keberhasilan sebuah strategi baru yang akan di implementasikan. Dalam setiap melaksanakan proyeknya, CV. Profile

Image selalu berpegang pada prinsip utama perusahaan, yaitu : 1) Customer Edited Value Focus yaitu berorientasi pada peningkatan value dari perusahaan

pelanggan sehingga turut dalam peningkatan keberhasilan perusahaan tersebut; 2) Optimalisasi yaitu selalu menemukan solusi untuk meningkatkan dan

memaksimalkan potensi yang dimiliki sehingga memberikan peningkatan nilai yang signifikan; 3) Integritas dan Kompetensi yaitu selalu mengutamakan hasil

akhir yang melebihi harapan pelanggan dari hasil sebuah kombinasi integrasi dan kompetensi yang dimiliki oleh semua sumber daya manusia yang diimiliki.

2.4. Teori Pendukung

2.4.1. Manajemen Proyek

Manajemen adalah proses merencanakan, mengorganisir, memimpin, dan mengendalikan kegiatan anggota serta sumber daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah ditentukan (Koontz dan O’Donnell,

1982). Proyek adalah suatu usaha yang mempunyai awal dan akhir dan dijalankan untuk memenuhi tujuan yang sudah ditetapkan dalam biaya, jadwal

dan sasaran kualitas (Haynes, 2003). Menurut Schwalbe (2006), setiap proyek akan dibatasi dengan ruang lingkup (scope), waktu (time) dan biaya (cost).

Batasan-batasan ini seringkali digunakan ke dalam manajemen proyek sebagai tiga batasan utama.

Menurut Schwalbe (2006), untuk menghasilkan proyek yang berhasil, seorang manajer proyek harus mempertimbangkan :

1. Ruang lingkup pekerjaan apa yang akan dilakukan sebagai bagian dari proyek tersebut, serta produk dan layanan atau hasil apa yang diinginkan

oleh pelanggan (sponsor) yang dapat dihasilkan dalam suatu proyek. 2. Waktu yang dibutuhkan untuk menyelesaikan suatu proyek.

3. Biaya yang dibutuhkan untuk menyelesaikan suatu proyek. Karakteristik utama yang membedakan proyek adalah sebagai berikut

(Hughes dan Cotterel, 2006):

1. Melibatkan pekerjaan yang tidak rutin. 2. Membutuhkan perencanaan.

9

3. Sasarannya bersifat spesifik yaitu untuk memenuhi atau agar produk

khusus tercipta. 4. Proyek memiliki jangka waktu yang telah ditentukan (yang dapat bersifat

mutlak atau relatif). 5. Pekerjaan dilakukan oleh orang tertentu. 6. Pekerjaan melibatkan beberapa keahlian. 7. Sumberdaya yang tersedia untuk penggunaan proyek terbatas. 8. Proyek bersifat besar atau kompleks.

2.4.2. Project Life Cycle

Gambar 2.1 Project Life Cycle

Menurut Marchewka (2003), Project Life Cycle (PLC) adalah sekumpulan tahap logis yang menggambarkan kehidupan sebuah project dari awal hingga

akhir dalam rangka untuk mendefinisikan, membangun, dan memberikan produk dari proyek. 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, yang diuraikan sebagai berikut Marchewka (2003):

1. Define Project Goal merupakan tahapan yang mendefinisikan seluruh tujuan proyek. Tujuan proyek terfokus pada penyediaan nilai bisnis kepada

perusahaan. Tujuan yang ditetapkan dengan baik memberikan tim proyek sebuah fokus yang jelas dan menggerakkan tim ke fase lain proyek.

2. Plan Project merupakan tahapan perencanaan proyek yang menjawab pertanyaan berupa apa yang akan dilakukan, mengapa melakukan hal

tersebut, bagaimana melakukannya, siapa yang terlibat, berapa lama waktu yang dibutuhkan, berapa banyak biaya yang diperlukan, apa hal yang dapat

menjadi salah dan bagaimana menanganinya, bagaimana mengestimasi anggaran dan biaya, mengapa membuat keputusan tertentu, bagaimana

mengetahui kesuksesan.

3. Execute Project Plan merupakan tahapan untuk melaksanakan proyek sesuai

dengan tujuan dan perencanaan yang telah ditentukan. Pada akhir tahap ini, tim proyek menyampaikan atau mengimplementasikan produk kepada organisasi. Pada tahap ini, terdapat siklus hidup pengembangan sistem

(Systems Development Life Cycle).

4. Close Project merupakan tahapan penutupan proyek untuk memastikan

bahwa semua pekerjaan telah terselesaikan sesuai dengan yang

10

direncanakan dan disetujui oleh tim proyek dan sponsor. Tahap ini biasanya

diakhiri dengan laporan akhir proyek dan mempresentasikan dokumen yang berisi bahwa segala deliverable yang dijanjikan telah diselesaikan seperti

yang telah ditetapkan kepada pelanggan.

5. Evaluate Project merupakan tahapan untuk mengevaluasi proyek untuk menentukan apakah proyek berhasil memenuhi tujuan proyek. Evaluasi

proyek dapat dilakukan melalui dokumentasi pengalaman tim proyek yang dijadikan bahan pelajaran. Berdasarkan hal tersebut, maka dapat dilakukan

perbaikan pada proyek selanjutnya.

2.4.3. System Development Life Cycle

Dalam fase Execute Project Plan pada Project Life Cycle, terdapat Systems

Development Life Cycle (SDLC). SDLC adalah kerangka kerja untuk menggambarkan fase-fase dalam mengembangkan sistem informasi (Schwalbe,

2012). SDLC merupakan bagian dari Project Life Cycle (PLC) karena beberapa aktivitas untuk mengembangkan sistem informasi terjadi selama fase eksekusi

(Marchewka, 2003). Menurut Marchewka (2003), terdapat 5 fase dasar yang pada umumnya terdapat dalam pengembangan sistem yaitu Planning, Analysis, Design, Implementation, dan Maintenance and Support.

1. Fase Planning mencakup identifikasi dan penanganan masalah atau kesempatan dan menggabungkan manajemen proyek dengan proses dan

aktivitas pengembangan sistem. Pada tahap ini dilakukan proses perencanaan resmi yang menjamin tujuan, cakupan, anggaran,

penjadwalan, teknologi, proses pengembangan, metode, dan tool sudah tersedia.

2. Fase Analysis bertujuan untuk menyelidiki masalah atau peluang. Fase ini dilakukan dengan mengidentifikasi dan mendokumentasikan masalah

atau hambatan pada sistem yang sedang digunakan oleh pelanggan. Kebutuhan spesifik sistem baru diidentifikasi dan didokumentasikan.

3. Fase Design bertujuan untuk merancang arsitektur untuk mendukung sistem informasi baru dengan menggunakan kebutuhan yang telah diperoleh pada fase Analysis. Arsitektur yang dimaksud mencakup perancangan jaringan, konfigurasi perangkat keras, database, antarmuka pengguna, dan program aplikasi.

4. Fase Implementation mencakup konstruksi sistem, pengujian, dan istalasi.

5. Fase Maintenance and Support mencakup pemeliharaan dan perbaikan yang dilakukan untuk menangani perubahan sistem.

2.4.4. Guideline Distribusi Usaha

Beberapa aktivitas yang dilakukan dalam pengembangan perangkat lunak

berdasarkan guideline Kassem Saleh terdiri dari 2 jenis aktivitas yaitu Software Phases dan Ongoing Life Cycle Activities (Saleh, 2011), yang diuraikan sebagai berikut:

11

1. Software Phases. Kegiatan ini terdapat dalam model siklus hidup

pengembangan perangkat lunak khusus seperti model waterfall atau model object oriented. Berikut penjelasan singkat tentang kegiatan-kegiatan

bertahap:

a. Analysis. Fase ini mencakup aktivitas Requirements dan Spesifications. Aktivitas utama dalam fase ini termasuk pendefinisian kebutuhan,

pendefinisian antarmuka, dan prioritas dari persyaratan perangkat lunak yang diidentifikasi. Pencapaian utama dari tahap ini adalah ruang lingkup

dan dokumen visi, dokumen spesifikasi kebutuhan perangkat lunak, dan dokumen perencanaan pengujian penerimaan.

b. Design. Kegiatan tahap Design meliputi arsitektur tingkat tinggi, database, iantarmuka, dan desain. Pencapaian utama dari tahap ini berupa desain

tingkat tinggi dan dokumen desain yang bersifat detail.

c. Implementation. Aktivitas utama dari tahap ini adalah proses perubahan desain ke dalam kode yang dapat dijalankan. Kode ini dikembangkan sesuai dengan standar pengkodean yang diadopsi oleh perusahaan pembangunan. Selain itu, desain database diimplementasikan dan terintegrasi dengan baik dengan kode yang dihasilkan.

d. Integration Testing. Segera sesudah modul kode dapat dijalankan dan diuji secara individu, modul-modul yang dikembangkan diintegrasikan

dengan modul eksternal, sistem, dan komponen. Rencana uji integrasi dijalankan. Hasil uji yang diperoleh dianalisis, dan kesalahan ditangani dengan sesuai. Pencapaian dari fase ini berupa perangkat lunak terintegrasi.

e. Installation. Saat perangkat lunak terintegrasi dengan baik, perangkat lunak disampaikan pada pelanggan dan diinstal sesuai rencana instalasi dan penyebaran. Pelanggan menjalankan rencana pengujian penerimaan dan menerima perangkat lunak. Deliverable pada fase ini berupa dokumen penerimaan resmi yang ditandatangani oleh klien beserta sistem perangkat lunak yang diinstal dengan tepat.

2. Ongoing Life Cycle Activities. Kegiatan ini adalah kegiatan yang dilakukan terus menerus saat kegiatan bertahap dilakukan.

a. Project Management. Selama kemajuan aktivitas siklus hidup, manajer proyek terus melakukan aktivitas yang berhubungan dengan manajemen

proyek. Kemajuan aktivitas erat dipantau menggunakan prosedur pelaporan yang sesuai. Risiko terus dipantau dan tindakan perbaikan dilakukan bila diperlukan. Selain itu, risiko baru diidentifikasi dan dipantau. Jadwal proyek diperbaharui secara teratur sesuai kebutuhan.

b. Quality Assurance. Selama tiap fase, tim jaminan kualitas melakukan

aktivitasnya, termasuk mengkaji ulang pencapaian tiap fase dan menjamin penggunaan dan kesesuaiannya dengan standar internal dan eksternal.

12

c. Evaluation and Testing. Proses dan kegiatan evaluasi dan pengujian

mencakup kegiatan validasi dan verifikasi, dan dilakukan di sepanjang berbagai fase pengembangan produk. Pada akhir setiap fase, deliverable

fase dievaluasi dan diuji. Saat deliverable disetujui, fase berikutnya dimulai. Proses formal dan informal digunakan untuk tujuan evaluasi dan pengujian. Proses evaluasi formal meliputi penggunaan teknik formal dan alat otomatis untuk memverifikasi deliverable fase. Alat dan teknik untuk verifikasi desain dan pengujian kode dapat digunakan untuk tujuan ini.

d. Configuration Management. Aktivitas manajemen konfigurasi mencakup identifikasi dokumen perangkat lunak, deliverable, dan artefak (misalnya

use case, class diagram, dan model UML lainnya) yang akan dihasilkan, dimanipulasi, dan dipelihara selama pengembangan dan pemeliharaan

perangkat lunak. Aktivitas pengendalian konfigurasi kemudian dilakukan secara berkelanjutan selama fase pengembangan dan setelah

pengembangan perangkat lunak.

e. Technical Support and Internal Training. Selama pengembangan dan

pemeliharaan produk perangkat lunak, pengembang dapat membutuhkan beberapa dukungan teknis dan pelatihan. Teknisi pendukung membantu pengembang dalam memecahkan masalah teknis yang muncul saat mengembangkan perangkat lunak. Pada fase ini, sebuah perencanaan dapat dilakukan untuk menangani pelatihan staf teknis pada proses

pengembangan, atau pada tool dan teknologi baru yang diperlukan selama pengembangan.

f. Dokumentasi. Selama pengembangan produk, beragam dokumen dihasilkan. Beberapa di antaranya merupakan dokumen teknis internal

yang diperlukan untuk aktivitas pemeliharaan perangkat lunak masa depan. Dokumen lainnya menargetkan pengguna eksternal yang

mencakup petunjuk pengguna, petunjuk instalasi, dan petunjuk operasi.

Hasil penelitian Saleh (2011) memberikan panduan distribusi usaha untuk

mengalokasikan biaya ke dalam setiap kelompok aktivitas yang telah dijelaskan di atas dalam mengembangkan proyek perangkat lunak. Persentase distribusi usaha pada hasil penelitian Saleh adalah sebagai berikut:

Tabel 2.1 Distribusi usaha setiap aktifitas

Aktivitas % Usaha

Software Phases

Requirements 7.5

Spesifications 7.5

Design 10

Implementation 10

Integration Testing 7.5

Acceptance & Deployment 7.5

13

Aktivitas % Usaha

Ongoing life-cycle activities

Project Management 8.34

Configuration Management 4.16

Quality Assurance 8.34

Documentation 4.16

Training and support 4.16

Evaluation and Testing 20.84

2.4.5. Work Breakdown Structure (WBS)

Menurut Schwalbe (2004), Work Breakdown Structure (WBS) merupakan

pengelompokan pekerjaan, berorientasi pada deliverable, yang terkait dalam proyek dan menentukan total cakupan proyek. WBS menggambarkan pekerjaan

pada proyek dengan menguraikan aktivitas pekerjaan ke dalam tingkatan task yang berbeda-beda. Elemen-elemen yang terkandung dalam WBS bersifat 1)

Didefinisikan, dapat dijelaskan dan mudah dipahami tim proyek 2) Dikelola, suatu pekerjaan atau tanggungjawab tertentu dapat ditugaskan kepada seorang

pekerja 3) Perkiraan, durasi dan biaya dapat diperkirakan 4)Bebas, tidak tergantung pada elemen lainnya yang sedang berlangsung 5) Terintegrasi, terintegrasi dengan elemen-elemen pekerjaan proyek, perkiraan biaya, dan jadwal 6)Terukur, dapat digunakan untuk mengukur kemajuan proyek 7) Fleksibel, sehingga apabila ada penambahan atau penghapusan, pekerjaan dapat ditampung dalam WBS.

2.4.6. Gantt Chart

Gantt Chart merupakan format standar untuk menampilkan informasi

penjadwalan proyek dengan membuat daftar aktivitas proyek dan penanggalan awal dan akhir yang sesuai dengan proyek (Schwalbe, 2012). Menurut

Marchewka (2003), memecah proyek ke dalam berbagai fase-fase dan sub fase mengurangi kompleksitas dan resiko. Dalam banyak kasus, lebih mudah untuk

fokus pada potongan-potongan pekerjaan daripada keseluruhan pekerjaan.

Setiap fase seharusnya fokus untuk menyediakan setidaknya satu deliverable spesifik. Menurut Marchewka (2003), deliverable merupakan potongan pekerjaan yang nyata dan dapat diverifikasi. Sedangkan milestone merupakan kejadian atau pencapaian signifikan yang menandai penerimaan deliverable dan

memberikan manajer proyek dan tim persetujuan untuk memulai pekerjaan pada deliverable berikutnya. Milestone menjelaskan bahwa sebuah deliverable tidak hanya selesai, tapi juga dikaji ulang dan diterima. Contoh deliverable berupa presentasi atau laporan, rencana, prototype, dan sistem aplikasi akhir.

Sedangkan milestone harus fokus pada pencapaian. Misalnya deliverable dapat berupa prototype dari antarmuka pengguna, sedangkan milestone berupa penerimaan resmi pemangku kepentingan pada antarmuka pengguna.

14

2.4.7. Posisi dan Standar Gaji Staf IT

Berbagai posisi staf dalam pengembangan perangkat lunak dideskripsikan sebagai berikut:

Tabel 2.2 Deskripsi posisi staf IT

Posisi Deskripsi Posisi

System Analyst

System Analyst bertanggungjawab dalam menjamin agar kebutuhan pelanggan bisnis tercakup dan didokumentasikan dengan benar sebelum sebuah solusi yang dikembangkan dan diterapkan

(TenStep, Inc).

Software Engineer

Software Engineer bertanggungjawab merancang dan mengembangkan aplikasi perangkat lunak. Melakukan coding, debugging, pengujian, dan troubleshooting selama proses pengembangan aplikasi (CompAnalyst, 2017).

Project

Manager

Project Manager bertanggungjawab dalam mengelola proyek.

Perannya termasuk memimpin perencanaan dan pengembangan seluruh deliverable proyek. Project Manager bertanggungjawab dalam mengatur anggaran, penjadwalan, dan seluruh prosedur dalam manajemen proyek (TenStep, Inc).

Software QA Software QA bertangungjawab dalam mengawasi setiap fase pada

pengembangan perangkat lunak dan menjamin kualitas perancangan, menjamin bahwa perangkat lunak sesuai dengan standar yang ditetapkan perusahaan pengembang. Software QA juga menjamin bahwa produk baru telah berhasil sebelum

diluncurkan ke publik (Sokanu, 2017).

Test Analyst Test Analyst bertangungjawab dalam mengidentifikasi dan menentukan pengujian yang diperlukan, mengawasi kemajuan pengujian dan hasilnya dalam setiap siklus dan mengevaluasi

keseluruhan kualitas yang dialami sebagai hasil dari aktivitas pengujian (Rational Software Corporation, 1997-2001).

Untuk menghitung biaya setiap aktivitas pengembangan perangkat lunak, maka penelitian ini menggunakan standar gaji Indonesia Salary Guide 2014 dan 2016 yang diterbitkan oleh Kelly Service, Inc sebagai berikut:

Tabel 2.3 Standar gaji Kelly Service 2014

Segmentasi Peran Posisi dalam Salary Guide Standar Gaji (per-bln) (Rp)

Requirements System Analyst 7.000.000

Spesifications & Design

System Analyst 7.000.000

Coding Software Engineer 5.000.000

Integration Testing

Test Analyst 5.000.000

Project Manajement

Project Manager 20.000.000

15

Configuration Manajement

Software Engineer 5.000.000

Documentation Software Engineer 5.000.000

Acceptance &

Deployment

Software Engineer 5.000.000

Quality Assurance Software QA 5.000.000

Evaluation and

Testing

Test Analyst 5.000.000

Training and support

Software Engineer 5.000.000

Berikut merupakan standar gaji Indonesia Salary Guide tahun 2016 yang dikeluarkan oleh Kelly Service:

Tabel 2.4 Standar gaji Kelly Service 2016

Segmentasi Peran Posisi dalam Salary Guide Standar Gaji (per-bln) (Rp)

Requirements System Analyst 7.000.000

Spesifications &

Design

System Analyst 7.000.000

Coding Software Engineer 5.000.000

Integration

Testing

Test Analyst 8.000.000

Project Manajement

Project Manager 20.000.000

Configuration Manajement

Software Engineer 5.000.000

Documentation Software Engineer 5.000.000

Acceptance & Deployment

Software Engineer 5.000.000

Quality Assurance Software QA 8.000.000

Evaluation and Testing

Test Analyst 8.000.000

Training and

support

Software Engineer 5.000.000

2.5. Metode Fuzzy Use Case Point

Use case memberikan cakupan fungsional proyek, menganalisisnya memberikan wawasan bernilai untuk memperoleh usaha dan ukuran yang

diperlukan untuk merancang dan mengimplementasikan sebuah proyek. Pada

umumnya, proyek dengan use case yang banyak dan rumit membutuhkan lebih banyak usaha untuk merancang dan mengimplementasikan dibandingkan

16

dengan proyek kecil dengan use case yang kurang rumit. Menurut Clemmons

(2006), waktu untuk menyelesaikan proyek dipengaruhi oleh hal-hal berikut:

1. Jumlah tahapan menyelesaikan use case.

2. Jumlah dan kompleksitas aktor.

3. Kebutuhan teknis use case seperti keamanan dan kinerja.

4. Berbagai environmental factor seperti pengetahuan dan pengalaman tim pengembang.

4 hal yang mempengaruhi waktu penyelesaian proyek di atas menjadi bahan

analisis dalam memperoleh estimasi usaha pengerjaan suatu proyek dengan menggunakan metode Use Case Point. Metode Use Case Point merupakan suatu

metode untuk mengestimasi usaha pengembangan perangkat lunak berdasarkan use case (Anda, 2002). Sedangkan menurut Nassif et al (2010), Use

Case Point merupakan sebuah model estimasi usaha dan ukuran perangkat lunak. Metode ini memberikan sebuah estimasi yang mendekati estimasi

sebenarnya yang dihasilkan dari pengalaman pembuatan atau pengembangan perangkat lunak. Hal tersebut dibuktikan oleh beberapa penelitian yang pernah

dilakukan sebelumnya, dan menghasilkan pernyataan sebagai berikut (Dewi et al, 2015):

1. UCP memiliki deviasi sebesar 6%. Persamaan UCP menghasilkan estimasi usaha367 man-days, sedangkan hasil usaha sesungguhnya390 man-days

sehingga terdapat deviasi sebesar 6 persen. 2. UCP memiliki deviasi sebesar 19%, sementara estimasi para ahli memiliki

rata-rata deviasi sebesar 20% (Anda, 2002). 3. UCP memiliki deviasi sebesar 9% (Carrol, 2005).

Konsep logika fuzzy diperkenalkan oleh Zadeh (1965) dari Universitas

California di Berkeley. Pada penelitian Hariyanto dan Wahono (2015) yang berjudul Estimasi Proyek Pengembangan Perangkat Lunak dengan Fuzzy Use

Case Points, dilakukan estimasi biaya menggunakan Use Case Point yang sudah ditingkatkan dengan logika fuzzy, sehingga disebut Fuzzy Use Case Point.

Hasil penelitian Nassif et al (2010) menunjukkan bahwa metode Use Case Point memiliki keterbatasan saat mengkategorikan use case berdasarkan jumlah

transaksi. Unadjusted Use Case Point (UUCP) dikalkulasikan dengan menambah Unadjusted Use case Weight (UUCW) dengan Unadjusted ActorWeight (UAW).

UAW dapat dengan mudah ditentukan. Sedangkan UUCW dikalkulasikan berdasarkan jumlah transaksi dalam setiap use case. Berdasarkan jumlah transaksi, maka sebuah use case akan dikategorikan ke dalam kategori simple,

average, dan complex. Namun, terjadi permasalahan saat jumlah transaksi lebih dari 7. Seluruh use case dengan jumlah transaksi yang melebihi 7 dianggap

memiliki kategori yang sama meskipun jumlah transaksi memiliki perbedaan yang cukup signifikan. Nassif juga menyatakan ketidaktepatan metode Use Case

Point ketika sebuah proyek B memiliki 10 use case dengan jumlah transaksi

17

masing-masing 4 , dianggap memiliki ukuran 2 kali lebih besar daripada proyek A

dengan 10 use case yang memiliki masing-masing 3 transaksi.

Oleh karena itu, Nassif mengusulkan pendekatan untuk mengatasi keterbatasan Use Case Point. Nassif mengusulkan untuk tidak mengklasifikasikan

use case hanya ke dalam 3 kategori, yaitu simple, average, dan complex, tetapi ke dalam 10 kategori menurut jumlah transaksi tiap use case. Tujuan pendekatan

ini adalah untuk meningkatkan model Use Case Point yang diusulkan Karner, bukan untuk memodifikasi metode tersebut secara keseluruhan. Oleh karena itu,

diasumsikan bahwa use case terbesar memiliki 10 transaksi. Logika fuzzy dengan keanggotaan segitiga digunakan untuk menyelesaikan masalah di atas.

Tabel 2.5 Bobot yang diterapkan

Jumlah transaksi dalam use case

Bobot Karner Bobot yang diterapkan

1 transaksi 5 5

2 transaksi 5 5

3 transaksi 5 6.45

4 transaksi 10 7.5

5 transaksi 10 8.55

6 transaksi 10 10

7 transaksi 10 11.4

8 transaksi 15 12.5

9 transaksi 15 13.6

10 transaksi 15 15

Tabel berikut menunjukkan perbandingan bobot antara metode Karner (Use Case Point) dengan pendekatan yang diusulkan Nassif (metode Use Case Point yang telah ditingkatkan dengan logika fuzzy). Dari tabel tersebut dapat dilihat bahwa, dengan pendekatan yang diusulkan, bobot use case secara bertahap meningkat, berbeda dengan metode Karner yang melakukan peningkatan secara tiba-tiba.

Hasil pendekatan dengan menggunakan logika fuzzy menunjukkan bahwa model yang diajukan meningkatkan estimasi usaha perangkat lunak dimana dalam MRE terjadi peningkatan keakuratan estimasi sebesar 22% dan MER meningkat sebesar 9 %. Menurut Clemmons (2006), persamaan Use Case Point terdiri dari 3 variabel:

1. Unadjusted Use Case Points (UUCP) 2. The Technical Complexity Factor (TCF) 3. The Environment Complexity Factor (ECF) Setiap variabel di atas dijelaskan dan dihitung secara terpisah menggunakan

nilai bobot, nilai subyektif, dan konstanta wajib. Bobot dan konstanta diinisiasi oleh Albrecht, sedangkan nilai subyektif ditentukan oleh tim pengembang

berdasarkan persepsinya pada kompleksitas teknis dan efisiensi proyek.

2.5.1. Use Case Scenario

Pemodelan use case pertama sekali diajukan oleh Jacobson. Use case diagram menunjukkan bagaimana pengguna berinteraksi dengan sistem. Use case

18

diagram terdiri dari use case dan aktor. Use case menyajikan kebutuhan

fungsional dimana aktor merupakan peran yang dimainkan oleh pengguna.

Menurut Ribu (2001), use case scenario adalah kejadian use case, alur tindakan spesifik yang mengilustrasikan perilaku. Use case scenario terdiri dari

aktor yang terlibat dalam skenario (actor), precondition sistem, skenario keberhasilan utama (main success scenario), ekstensi (extension) dan

postcondition sistem (Nassif et al, 2010). Berikut merupakan pengertian dari beberapa hal di atas:

Tabel 2.6 Use Case Scenario

Nama Fungsi

Actor Merepresentasikan seseorang atau sesuatu (seperti perangkat sistem lain) yang berinteraksi dengan sistem.

Precondition Sebagai pernyataan persyaratan yang harus ada sebelum sebuah use case dijalankan.

Main success scenario Menjelaskan apa yang terjadi dalam kasus paling umum ketika

tidak ada kesalahan yang terjadi. Subflow Bagian teks yang berdiri sendiri yang merupakan hasil dari

pemecahan bagian dari flow. Subflow terjadi saat use case menjadi lebih detail, sehingga teks dari aliran peristiwa menjadi terlalu lama.

Extension Menggambarkan alternatif atau penambahan skenario keberhasilan utama, dan ditulis secara terpisah. Extension

berisi nomor langkah di bagian main success scenario dimana extension diterapkan, suatu keadaan yang harus diuji sebelum langkah itu, dan sejumlah urutan langkah-langkah yang

membentuk extension.

Postcondition Sebagai sebuah pernyataan yang menjelaskan keadaan sistem saat use case berakhir

Sumber: Diadaptasi dari Bittner dan Spence Ian (2002) dan Ribu (2001).

Kekompleksitasan sebuah use case ditentukan oleh jumlah transaksi pada use case scenario. Tidak ada standar pendefinisian sebuah transaksi (Kashyapet al, 2014). Menurut Nassif et al (2010), transaksi yang dihitung mencakup transaksi dalam main success scenario beserta dalam extension. Menurut Jacobson et al, 1992, transaksi didefinisikan sebagai sebuah round trip (perjalanan dari pengguna ke sistem kembali ke pengguna). Transaksi selesai ketika sistem menanti stimulus masukan baru. Dengan kata lain, dalam satu transaksi aktor dapat melakukan beberapa tindakan yang dimasukkan untuk sistem. Selanjutnya

sistem bereaksi dan mengembalikan hasilnya ke aktor tersebut. Pernyataan Jacobson juga menyiratkan bahwa satu transaksi use case tidak‎ berarti‎ “satu‎langkah dalam aliran use case”,‎ kecuali‎ apabila‎ satu‎ langkah‎ dalam‎ aliran use case terdiri dari satu round trip (Collaris dan Dekker, 2009). Pada penelitian

Kashyap et al (2014), sebuah transaksi ditentukan sesuai pendefinisian Ivar Jacobson. Namun, Kashyap menambahkan beberapa aturan dalam menghitung sebuah transaksi, yaitu sebagai berikut:

19

1. Transaksi yang terlalu sederhana diabaikan. Misalnya memasukkan nama

pengguna, nama ditampilkan di layar.

2. Transaksi yang hanya berbeda pada instansiasi dianggap sebagai transaksi yang sama. Misalnya mencari buku obat-obatan dan buku arsitektural dapat

menjadi 2 skenario berbeda dalam spesifikasi use case namun merupakan operasi yang sama dalam database, maka keduanya dianggap sebagai

transaksi yang sama.

3. Semua skenario pengecualian dalam use case dianggap satu transaksi,

dengan menganggap sebuah framework dirancang untuk menangani semua jenis pengecualian.

4. Semua transaksi pada use case untuk memvalidasi kolom pada layar dianggap sebagai satu transaksi, dengan menganggap framework dirancang untuk memvalidasi.

2.5.2. Unadjusted Use Case Points

Unadjusted Use Case Points (UUCP) diperoleh dari penjumlahan Unadjusted Actor Weight (UAW) dengan Unadjusted Use Case Weight (UUCW) (Clemmons,

2006). 𝑈𝑈𝐶𝑃 = 𝑈𝐴𝑊 + 𝑈𝑈𝐶𝑊 (2.1)

2.5.3. Perhitungan Unadjusted Actor Weights (UAW)

Aktor setiap use case dikategorikan dalam sederhana, medium, atau kompleks (Clemmon, 2006). Perhitungan Unadjusted Actor Weight (UAW)

dilakukan berdasarkan kompleksitas yang digabungkan pada semua aktor dalam semua use case.

Tabel 2.7 Kategori aktor

Kategori Aktor

Deskripsi Bobot Aktor

Sederhana Aktor mewakili sistem lain dengan Application Programming Interface (API) yang ditetapkan.

1

Medium Aktor mewakili sistem lain yang berinteraksi lewat protokol, seperti Transmission Control Protocol/Internet Protocol.

2

Kompleks Aktor merupakan orang yang berinteraksi melalui

Graphical User Interface.

3

Pada Tabel 2.7 di atas, dapat diketahui bobot masing-masing aktor berdasarkan kategorinya. Total Unadjusted Actor Weights (UAW) didapat dari menghitung berapa banyak aktor dari masing-masing kategori dan dikali dengan

bobot aktor, seperti persamaan 2.2 berikut:

20

UAW= ∑ 𝐵𝑜𝑏𝑜𝑡𝐴𝑘𝑡𝑜𝑟𝑖𝑛𝑖=1 (2.2)

Dimana n = jumlah aktor

i = urutan tertentu

𝐵𝑜𝑏𝑜𝑡𝐴𝑘𝑡𝑜𝑟𝑖 = bobot aktor urutan ke-i (lihat Tabel 2.7)

2.5.4. Perhitungan Unadjusted Use Case Weights (UUCW)

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 sebagai berikut:

UUCW=∑ 𝐵𝑜𝑏𝑜𝑡𝑈𝑠𝑒𝐶𝑎𝑠𝑒𝑖𝑛𝐼=1 (2.3)

Dimana n= jumlah use case

i = urutan tertentu

𝐵𝑜𝑏𝑜𝑡𝑈𝑠𝑒𝐶𝑎𝑠𝑒𝑖=bobot use case urutan ke-i (lihat Tabel 2.8)

Tabel 2.8 Kompleksitas use case

Jumlah Transaksi dalam Use Case

Bobot

1 5

2 5

3 6.45

4 7.5

5 8.55

6 10

7 11.4

8 12.5

9 13.6

10 15

Jumlah transaksi dalam setiap use case digunakan untuk mengklasifikasikan tingkat kesulitan use case. Dalam Ochodek et al (2011) transaksi use dapat didefinisikan‎sebagai‎“perjalanan‎pulang‎pergi”,‎‎dimana‎aktor‎memberi‎stimulus‎pada sistem, dan sistem memberikan respon pada stimulus tersebut.

2.5.5. Technical Complexity Factor

Technical Complexity Factor (TCF) adalah salah satu faktor untuk

memperkirakan ukuran perangkat lunak dengan memperhitungkan pertimbangan teknis pada sistem. 13 technical factor bermanfaat untuk

memperkirakan dampak berbagai persoalan teknis pada produktivitas proyek (Clemmons, 2006).

Tabel 2.9 Technical factor

Ti Technical Factor Bobot

T1 Sistem Terdistribusi 2

21

Ti Technical Factor Bobot

T2 Kinerja 1

T3 Efisiensi Pengguna Akhir 1

T4 Pemrosesan Internal yang Kompleks 1

T5 Kemampuan Melakukan Penggunaan Kembali Kode 1

T6 Kemudahan Instalasi 0.5

T7 Kemudahaan Penggunaan 0.5

T8 Dukungan Antar Platform 2

T9 Kemudahan untuk Mengubah 1

T10 Konkurensi 1

T11 Fitur Keamanan Khusus 1

T12 Ketergantungan pada Kode Pihak Ketiga 1

T13 Fasil itas Pelatihan Khusus untuk Pengguna Diperlukan 1

Perceived complexity pada 13 technical factor ditetapkan antara 0 dan 5. Perceived Complexity merupakan dampak beragam technical factor pada produktivitas proyek. Nilai 0 berarti technical factor tidak berhubungan dengan

proyek, 3 berarti berpengaruh biasa, sampai 5 berarti berpengaruh kuat. Ketika ragu-ragu, digunakan nilai 3 (Clemmons, 2006). Perceived complexity pada technical factor dikalikan dengan bobot untuk mendapatkan total technical

factor seperti yang ditunjukkkan pada persamaan berikut:

𝑇𝐹 = ∑ 𝑃𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 ∗ 𝐵𝑜𝑏𝑜𝑡𝑖131 (2.4)

Technical Factor (TF) digunakan untuk memperoleh nilai Technical Complexity Factor dengan persamaan berikut:

𝑇𝐶𝐹 = 0.6 + (0,01 ∗ 𝑇𝐹) (2.5)

Pada persamaan di atas, 2 konstanta dihitung dengan total technical factor untuk menghasilkan nilai TCF. Konstanta tersebut membatasi dampak yang dimiliki TCF pada persamaan dengan rentang 0,60 (semua faktor kompleksitas yang dipersepsikan bernilai 0) sampai maksimum 1,30 (semua faktor kompleksitas yang dipersepsikan bernilai 5). Nilai TCF (Technical Complexity Factor ) yang kurang dari 1 mengurangi Fuzzy Use Case Point. Misalnya 100

dikalikan dengan 0,60 menghasilkan 60 , dimana terjadi reduksi sebesar 40%. Sedangkan apabila nilai TCF lebih besar dari 1, maka akan meningkatkan hasil

Fuzzy Use Case Point. Misalnya 100 dikalikan dengan 1,30 menghasilkan 130, dimana terjadi peningkatan sebesar 30 % (Clemmons, 2006).

Menurut Ochodek et al (2010), terdapat masalah dalam melakukan penilaian pada technical factor maupun lingkungan, yaitu kurangnya skala standar.

Penelitian yang dilakukan Anda et al (2001) menyatakan kesulitan dalam memberikan penilaian pada technical factor dan environmental factor akibat

kurangnya dasar yang menjadi perbandingan, sehingga harus menebak apa yang dimaksud oleh setiap faktor. Ani dan Basri (2013) memberikan solusi untuk

22

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.

2.5.6. Environmental Complexity Factor

Environmental Complexity Factor (ECF) adalah sebuah faktor yang diterapkan

untuk memperkirakan ukuran perangkat lunak dengan menghitung pertimbangan lingkungan pada sistem. ECF ditentukan dengan menetapkan skor

antara 0 sampai 5 pada setiap 8 Environmental factor pada Tabel 2.10. Adapun nilai pada setiap technical factor ditetapkan oleh manajer proyek dengan

bantuan 2 orang pengembang senior (Ribu, 2001). Tabel 2.10 Environmental factor

Ei EnvironmentalFactor Bobot

E1 Keakraban dengan metode pengembangan yang digunakan

1,5

E2 Pengalaman Aplikasi 0,5

E3 Pengalaman Berorientasi Objek 1

E4 Menguasai Kemampuan Analis 0,5

E5 Motivasi 1

E6 Kebutuhan yang Stabil 2

E7 Pekerja Paruh Waktu -1

E8 Bahasa Pemrograman yang Sulit -1

Kirsten Ribu dalam Estimating Object-Oriented Software Projects with Use

Cases, menjelaskan pengertian dari environmental factor beserta nilainya sebagai berikut:

1. Keakraban dengan metode pengembangan yang digunakan. Dalam usulan Karner, faktor ini disebut keakraban RUP (Rational Unified Process). Namun, pengalaman dari industri menunjukkan walupun secara ideal, proyek

seharusnya menggunakan RUP, kenyataannya seringkali tidak demikian. Satu atau lebih anggota tim dapat menggunakan elemen dari RUP, sedangkan

anggota lainnya sangat tidak akrab dengan RUP. Di sisi lain, tim dapat menggunakan proses pengembangan lain yang sudah biasa dalam tim. Oleh

karena itu, lebih baik mengukur pengalaman tim dengan metode yang sebenarnya dipakai pada proyek.

a. Nilai 0: Tim tidak terbiasa dengan proses pengembangan aplikasi.

b. Nilai 1: Tim memiliki pengetahuan teoritis terhadap proses pengembangan.

23

c. Nilai 2-3: Satu atau lebih anggota tim telah menggunakan metode

tersebut sekali atau beberapa kali.

d. Nilai 3-4: Setidaknya setengah dari anggota tim memiliki pengalaman menggunakan metode tersebut pada proyek yang berbeda.

e. Nilai 5: Seluruh anggota tim memiliki pengalaman menggunakan metode tersebut pada beberapa proyek berbeda.

2. Pengalaman Aplikasi. Faktor ini mengindikasikan pengalaman dengan jenis aplikasi yang dibangun atau pengalaman dengan jenis aplikasi yang berbeda.

a. Nilai 0: Semua anggota tim merupakan pemula.

b. Nilai 1-2: Beberapa anggota tim memiliki beberapa pengalaman,

contohnya 1 sampai 1 ½ tahun, anggota tim lainnya pemula.

c. Nilai 3: Semua anggota tim memiliki lebih dari 1 ½ tahun pengalaman.

d. Nilai 4: Hampir semua anggota tim memiliki 2 tahun pengalaman.

e. Nilai 5: Semua anggota tim berpengalaman.

3. Pengalaman Berorientasi Obyek. Faktor ini mengukur pengalaman tim dengan analisis dan desain berorientasi obyek. Faktor ini mengukur pengalaman pemodelan, contohnya pemodelan use case pada fase analisis, dan pemodelan kelas dan komponen

a. Nilai 0: Tim sungguh-sungguh tidak terbiasa dengan analisis dan desain berorientasi obyek.

b. Nilai 1: Semua anggota tim memiliki kurang dari 1 tahun pengalaman

c. Nilai 2-3: Semua anggota tim memiliki 1 sampai 1 ½ tahun pengalaman.

d. Nilai 4: Hampir semua anggota tim memiliki lebih dari 2 tahun

pengalaman

e. Nilai 5: Semua pengembang berpengalaman (lebih dari 2 tahun)\

4. Menguasai Kemampuan Analis. Faktor yang mengukur pengalaman dengan analisis kebutuhan dan pemodelan.

a. Nilai 0: Analis utama adalah seorang pemula.

b. Nilai 1-2: Pengalaman dari sedikit proyek.

c. Nilai 3-4 : Setidaknya 2 tahun pengalaman dari beberapa proyek.

d. Nilai 5: Setidaknya 3 tahun pengalaman dengan beragam proyek.

24

5. Motivasi. Faktor ini menjelaskan total motivasi tim.

a. Nilai 0: Tidak termotivasi.

b. Nilai 1-2: Sedikit motivasi.

c. Nilai 3-4: Tim termotivasi melakukan pekerjaan baik.

d. Nilai 5: Tim sangat termotivasi dan terinspirasi.

6. Kebutuhan yang Stabil. Faktor ini mengukur tingkatan perubahan kebutuhan

dan ketidakkukuhan perwujudan kebutuhan.

a. Nilai 0: Kebutuhan sangat tidak stabil, perubahan secara terus -menerus.

b. Nilai 1-2: Kebutuhan tidak stabil. Pelanggan meminta berbagai perubahan dilakukan pada berbagai selang waktu.

c. Nilai 3-4: Kestabilan kebutuhan secara menyeluruh, namun masih membutuhkan perubahan kecil.

d. Nilai 5: Kebutuhan yang selalu stabil selama pengembangan aplikasi.

7. Pekerja Paruh Waktu. Harus melatih orang baru atau tidak memiliki tim yang

stabil mempengaruhi produktivitas secara negatif.

a. Nilai 0: Tidak ada pekerja paruh waktu.

b. Nilai 1-2: Sedikit (20 persen) pekerja paruh waktu.

c. Nilai 3-4: Sebagian dari tim adalah pekerja paruh waktu.

d. Nilai 5: Keseluruhan tim adalah pekerja paruh waktu.

8. Bahasa Pemrograman yang Sulit. Faktor ini mengindikasikan pengalaman

dengan alat pengembangan dasar serta bahasa pemrograman yang dipilih.

a. Nilai 0: Semua anggota tim adalah programmer berpengalaman.

b. Nilai 1: Hampir semua anggota tim memiliki pengalaman lebih dari 2

tahun.

c. Nilai 2: Semua anggota tim memiliki lebih dari 1 ½ tahun pengalaman.

d. Nilai 3: Hampir semua anggota tim memiliki lebih dari 1 tahun pengalaman.

e. Nilai 4: Sedikit anggota tim yang berpengalaman, contohnya 1 tahun, dan anggota tim lainnya masih pemula.

f. Nilai 5: Semua anggota tim merupakan pemula.

Tim yang lebih berpengalaman akan lebih besar dampaknya pada

perhitungan Use Case Point dibanding tim yang kurang pengalaman. Pada persamaan 2.6, nilai kompleksitas pada enviromental factor

(PerceivedComplexity) dikalikan dengan bobot tiap faktor, kemudian dijumlahkan untuk mendapatkan total enviromental factor, yang kemudian digunakan untuk

mendapatkan Enviromental Complexity Factor (ECF).

25

𝐸𝐹 = ∑ 𝑃𝑒𝑟𝑐𝑒𝑖𝑣𝑒𝑑𝐶𝑜𝑚𝑝𝑙𝑒𝑥𝑖𝑡𝑦 ∗ 𝐵𝑜𝑏𝑜𝑡𝑖81 (2.6)

𝐸𝐶𝐹 = 1.4 + (−0.03 ∗ 𝐸𝐹) (2.7)

2 Konstanta dihitung dengan total environmental factor untuk menghasilkan nilai ECF. Konstanta tersebut membatasi dampak yang dimiliki ECF pada persamaan dengan rentang 0,425 (environmental factor pekerja paruh waktu dan bahasa pemrograman yang sulit bernilai 0, dan faktor lainnya bernilai 5) sampai maksimum 1,4 (semua faktor kompleksitas yang dipersepsikan bernilai 0). Oleh sebab itu, nilai ECF dapat mengurangi Fuzzy Use Case Point sampai 57,5

% dan meningkatkan UCP sampai 40%.

2.5.7. Perhitungan Fuzzy Use Case Point

Fuzzy Use Case Point diperoleh dengan mengalikan Unadjusted Use Case

Point dengan Technical Complexity Factor dan Environmental Complexity Factor seperti berikut:

𝐹𝑈𝐶𝑃 = 𝑈𝑈𝐶𝑃 ∗ 𝑇𝐶𝐹 ∗ 𝐸𝐶𝐹 (2.8)

2.5.8. Perhitungan Usaha

Karner mengusulkan nilai jam sebesar 20 staff hours untuk ditetapkan pada setiap Use Case Point. Pengalaman langsung menunjukkan bahwa nilai jam yang

ditetapkan per Use Case Point berkisar antara 15 sampai 30 jam (Ribu, 2001). Schneider dan Winter (1998) merekomendasikan untuk menetapkan nilai staff

hours berdasarkan environmental factor. Jumlah faktor pada faktor lingkungan pertama sampai keenam yang di bawah 3 dihitung dan ditambahkan dengan

jumlah faktor pada faktor lingkungan ketujuh sampai delapan yang di atas 3. Jika penjumlahannya adalah 2 atau kurang dari 2, maka nilai staff hour yang

digunakan adalah 20. Sedangkan apabila penjumlahannya adalah 3 atau 4, maka digunakan nilai 28 staff hour.

Usaha=FUCP*staff hours (2.9)

2.6. Evaluasi Metode Estimasi Fuzzy Use Case Point

MMRE (Mean of the Magnitude of Relative Error) merupakan kriteria yang sangat umum digunakan untuk mengevaluasi model estimasi biaya perangkat lunak (Kitchenham et al, 2001). Semakin rendah nilai MMRE, semakin akurat metode yang dievaluasi (Foss et al, 2002). Pengukuran dasar dalam MMRE adalah MRE (Magnitude of Relative Error) yang dapat didefinisikan pada persamaan berikut:

𝑀𝑅𝐸 =| 𝑥𝑖−𝑥|

𝑥𝑖 (2.10)

dimana 𝑥𝑖 adalah nilai sesungguhnya, dan

𝑥 adalah nilai variabel terkait yang diestimasi