BAB II LANDASAN TEORI
2.1
Tinjauan Literatur Tabel 2.1. Kronologi Pengembangan Model Estimasi Tahun Metode Penulis 1979
Function Point Analysis (FPA)
Albrecht
1981
Constructive Cost Model (COCOMO)
Barry W. Boehm’s
1992
3-D Function Points
Whitmire
1993
Use Case Points UCP
Gustav Karner
1994
Object Points
Banker et al.
1997
Full Function Points (FPP)
University of Quebec
1998
Object Oriented Function Points (OOFPs)
Caldiera et al.
2001
Object Oriented Method Function Points (OOmFP)
Pastor et al.
2003
Web Application Metrics
Mendes
2006
Functional Size Measurement Method for Object – Oriented Conceptual Schemas: Desain and Evaluation Issue
Abrahao, Poels, Pastor
2009
A Family of Experiments to Evaluate a Functional Size Measurement Procedure for Web Applications
Abrahao, Poels, Pastor
2012
An Effort Estimation Model for Web Application (FHSWebEE)
Rosmina, Suharjito
2014
Estimating The Effort of Mobile Application Development (FiSMA + Mobile Application Characteristics)
Laudyson, Gibeon
Pada
tabel
2.1
menampilkan
beberapa
urutan
kronologi
pengembangan model utama estimasi. Tabel 2.1 menunjukan tahun 7
8
pembuatan, nama metode dan nama penulis. Untuk setiap metode diidentifikasi, diringkas dan dideskripsikan karakteristiknya seperti dapat dilihat pada berikut ini: •
Function Point Analysis (FPA) adalah sebuah metode pengukuran ukuran dalam function point berdasarkan dari pemberitahuan pengguna, dengan mempertimbangkan fungsi diimplementasikan. Metode ini teknologi independen dan dirancang untuk memperkirakan sistem informasi bisnisnya. Karakteristiknya adalah: perkiraan fungsi yang diminta oleh pengguna, menghitung ukuran dan biaya; mengestimasi proyek pengembangan dan pemeliharaan perangkat lunak, terlepas dari teknologi yang digunakan; memperkirakan fungsi yang diterima oleh pengguna, setelah perkembangannya; diperikasa apakah ukuran dan biaya sesuai dengan apa yang diperkirakan.
•
COnstructive COst Model (COCOMO) adalah model biaya untuk prose perencanaan dan pelaksaan proyek-proyek perangkat lunak. Karakterisktiknya adalah: kerangka kerja untuk komunikasi keputusan bisnis antara semua orang yang terlibat dalam proyek ini, sehingga memungkinkan untuk memperkirakan usaha dan biaya dan menindak lanjuti jadwal proyek.
•
3-D
Function
Point
adalah
metode
yang
dirancang
untuk
memperkirakan ukuran sistem real-time. Karakteristiknya adalah: independen dari teknologi, mirip dengan FPA tetapi menggunakan dua pendekatan baru yakni transformasi dan transisi. Namun,
9
penggunaannya tidak praktis dalam tahap desain awal, oleh karena itu dibutuhkan tingkat yang lebih besar untuk merinci sistem. •
Use Case Points (UCP) adalah metode yang dikembangkan untuk mengukur proyek tahap awal. Selama menentukan kebutuhan penggunaan sistem sedang dikembangkan, UCP dirancang untuk mengukur proyek perangkat lunak berorientasi objek dan menentukan beberapa faktor yang akan dibutuhkan untuk memperhitungkan pengalaman pengembang.
•
Object Points adalah metode mirip dengan FPA, tetapi menghitung objek
bukan
fungsinya.
Karakteristiknya
adalah:
lebih
baik
mendefinisikan faktor penyesuaian kompleksitas dan juga menambah jumlah presentasi kode yang digunakan kembali. •
Full Function Points (FFP) adalah suatu metode yang dirancang untuk memperkirakan real-time dan embedded system. Karakteristikanya adalah: ketika pengukuran sedang buat, ia akan menambahkan enam jenis fungsi yang dibandingkan dengan FPA.
•
Object Oriented Function Points (OOFPs) adalah adaptasi dari FPA, yang digunakan untuk memperkirakan software berorientasi objek. Karakteristiknya adalah: dari pada menggunakan file logis dan operasi seperti FPA, metode ini menggunakan kelas dan metode. OOFPs juga memperhitungkan kode yang digunakan kembali.
•
Object Oriented Method Function Points (OOmFP) dirancang berdasarkan aturan FPA, tetapi diarahkan untuk sistem berorientasi objek. Karakteristiknya adalah: kelas file logis dipertimbangkan
10
sebagai internal dan konsep-konsep seperti inheritance dan agregasi juga relevan untuk estimasi. •
Finnish Software Metrics Association FSM, atau disingkat FiSMA, adalah metode pengukuran software. Karakteristiknya adalah lebih kearah service-oriented dari pada process-oriented, dengan kata lain semua serivices diidentifikasi untuk dihitung ukuran fungsional pada software.
•
Web Application Metrics merupakan suatu faktor-faktor yang diusulkan pada Mendes dan teman-temannya yang memengaruhi ukuran dalam estimasi biaya aplikasi web.
•
An Effort Estimation Model for Web Application (FHSWebEE) adalah adaptasi
dari
OomFPWeb
dan
Web
Matrix
dari
Mendes.
Karakteristiknya adalah: suatu model untuk menghitung effort pada pembuatan aplikasi berbasis website yang mengunakan object oriented. •
Estimating The Effort of Mobile Application Development, merupakan penggabungan antara FiSMA (Finnish Software Metrics Association FSM) dan karakteristik aplikasi mobile yang telah di-survey sebelumnya oleh Laudyson dan Gibeon. Pertama kali kita lihat, metode utama yang ada ini masih sedikit
yang merancang untuk mempertimbangkan persyaratan aplikasi mobile. Bahkan sebagaian besar developer ada yang sudah membuat aplikasi mobile seperti yang kita kenal sekarang. Hal ini menunjukan bahwa penggunaan metode ini untuk memperkirakan usaha pengembangan
11
proyek yang melibatkan sistem atau aplikasi perangkat ponsel akan menyebabkan kegagalan untuk mengukur kompleksitas beberapa fitur. Oleh karena itu, metode ini kurang menghasilkan estimasi yang memadai. Dengan adanya permasalahan tersebut, penulis mengusulkan sebuah model untuk menentukan estimasi usaha pada pengembangan web mobile. Dengan menggabungkan FHSWebEE (OOmFPWeb & metrik hypermedia) dan metrik karakteristik aplikasi mobile yang diusulkan oleh Laudson dan Gibeon dengan menggunakan logika fuzzy. Terdapat beberapa penelitian sebelumnya mengenai logika fuzzy. Salah satunya ialah penelitian yang dilakukan oleh (Ziauddin, Kamal, Khan, & Nasir, 2013), yang menggunakan logika fuzzy untuk mengestimasi biaya pada aplikasi software. Penelitian ini menggunakan Tringular Membership Function (TMF) untuk mengubah data inputnya menjadi variabel fuzzy. Menggunakan TMF dikarenakan pada penelitian yang dilakukan oleh (Prasad, Sudha, & Rama, 2011), menyimpulkan menggunakan metode fuzzy menggunakan TMF lebih baik dari pada metode fuzzy menggunakan GBeIIMF atau Intermediate COCOMO. Pada penelitian yang dilakukan oleh (Sharma & Verma, 2010) yang menggunakan logika fuzzy untuk mengoptimalkan estimasi usaha pada pengembangan perangkat lunak, menyebutkan bahwa logika fuzzy membantu
untuk
menangani
ketidakpastian
dan
ketidaktepatan
dibandingkan dengan model estimasi biaya populer lainnya. Sama halnya dengan penelitian yang dilakukan oleh (Kad & Chopra, 2011) yang
12
menggunakan framework logika fuzzy untuk pengembangan software estimasi usaha. Logika fuzzy yang diterapkan mampu memberikan hasil evaluasi yang menggunakan metode MMRE (Mean of Magnitude of Relative Error) dan Pred(n) jauh lebih baik dari pada MMRE dengan model algoritma lainnya. Dari beberapa hasil penelitian terkait estimasi tersebut, metode Fuzzy Logic dipilih untuk mengestimasi usaha. Pada penelitian ini, akan difokuskan pada penelitian estimasi usaha untuk proyek aplikasi berbasis web mobile.
Publication
Tabel 2.2. Study Literature Problem
Method
Fuzzy Logic Sharma & Verma (2010)
Pengoptimalan logika fuzzy pada Fuzzy Logic & estimasi usaha dalam pengembangan COCOMO software
Kad & Chopra (2011)
Membuat model estimasi usaha dalam Fuzzy Logic & pengembangan software menggunakan COCOMO II Fuzzy Logic
Ziauddin, Kamal, Khan, Membuat model untuk meng-improve Fuzzy Logic & Nasir (2013) keakuratan dari mengestimasi usaha (COCOMOII+Alaa pada software Setha) Mobile Application Laudson, Gibeon (2014)
Membuat model estimasi usaha untuk FiSMA + Faktor aplikasi mobile. Aplikasi Mobile
Web Application (Rosmina & Suharjito, Membuat model estimasi usaha untuk OOmFPweb, 2012) aplikasi web dengan menggunakan Metric Web & Case Base FHSWebEE. Reasoning Fuzzy Logic + (OOmFPWeb + Metrics Web + Faktor Aplikasi Mobile)
13
Stefani Agusta Suharjito (2015)
Logic, & Model estimasi usaha pengembangan Fuzzy aplikasi mobile menggunakan Fuzzy OOmFPWeb, Metric Web, Logic Faktor Aplikasi Mobile (Laudson)
Dari study literatur pada tabel diatas, dapat disimpulkan bahwa metode logika fuzzy dapat digabungkan dengan beberapa metode untuk mendapatkan estimasi usaha. Oleh karena itu penulis mengusulkan suatu model dengan menggabungkan metode OOmFPWeb, metric web dan faktor aplikasi mobile dengan logika fuzzy mamdani.
2.2
Estimasi Usaha Software Estimasi Usaha Software telah didefinisikan setidaknya sejak tahun 1969 sebagai jumlah waktu dalam jam yang diperlukan manusia untuk merancang, coding, dan menguji sebuah proyek perangkat lunak. Proses pengembangan usaha terdiri dari kegiatan-kegiatan spesifik sebagai berikut: 1.
Mendapatkan data dari proyek-proyek sebelumnya.
2.
Generasi model estimasi.
3.
Memeriksa dan memvalidasi model berdasarkan akurasi. Salah satu kegiatan perencanaan proyek perangkat lunak adalah
estimasi dari usaha pengembangan. Para peneliti bertujuan untuk (1) menentukan teknik akurasi prediksi usaha terbesar, atau (2) mengusulkan teknik baru atau kombinasi yang bisa memberikan estimasi yang lebih baik.
14
Beberapa teknik Software Developmet Effort Estimation (SDEE) yang telah diajukan lebih dari 30 tahun terakhir dalam bidang piranti lunak. dapat diklasifikasikan kedalam dua kategori umum (Shepperd, Schofield, & Kitchenham, 1996): 1.
Penilaian pendapat ahli Proses estimasi teknik ini dilakukan dengan melalui pendapat para ahli secara subjektif berdasarkan pada pengalaman di masa lalu dari mengatur proyek yang sama sebelumnya. Proses estimasi usaha menggunakan pendapat ahli terdiri dari: a. Ahli melihat faktor-faktor yang mempengaruhi estimasi usaha dan biaya yang berhubungan dengan proyek, baru dimana usaha yang butuh diestimasi. b. Berdasarkan data yang diingat atau yang diambil dari proyek yang sudah selesai di masa yang usahanya sudah diketahui. c. Berdasarkan data dari poin (a) dan (b), dilakukan estimasi usaha untuk proyek baru secara subjektif. Estimasi usaha yang tepat bisa diberikan jika terdapat proyek yang sama dengan proyek di masa lalu.
2.
Berdasarkan model dasar Berdasarkan pada langkah kuantifikasinya dapat dibagi menjadi dua subkategori berikut: a.
Model berdasarkan statistik: bentuk umum model regresi statistik.
15
b.
Model berdasarkan kecerdasan komputer: teknik-teknik ini meliputi logika fuzzy, artificial neural network, genetic programming, dan genetic algorithms.
2.3
Aplikasi Mobile Aplikasi mobile adalah perangkat lunak tambahan untuk perangkat genggam, seperti smartphone dan personal digital assistantas (PDA). Aplikasi mobile yang paling popular adalah games, jaringan sosial media, peta, berita, bisnis, cuaca dan informasi wisata (Adolph, 2009). Berdasarkan
tipenya,
perkembangan
aplikasi
mobile
dapat
dibedakan menjadi tiga kategori yaitu aplikasi native, mobile web dan hybrid. 1.
Aplikasi native Merupakan aplikasi yang khusus dirancang untuk berjalan pada sistem operasi perangkat mobile. Bahasa pemograman dan program interface-nya terpapar oleh sistem operasi mobile dari jenis perangkat tertentu. Sebagai contoh, aplikasi native untuk iPhone akan ditulis dengan menggunakan bahasa Objective-C dan sistem operasi IOS Application Programming Interface (API) yang Apple sediakan dan mendukung. Karena API yang digunakan adalah pada tingkat yang rendah dan aplikasinya dibuat khusus untuk perangkat mobile, aplikasi dapat mengambil keuntungan penuh dari semua ditur dan layanan yang terdapat pada perangkat tersebut. Kelemahan pada aplikasi ini, jika berasal dari aplikasi iOS
16
harus benar-benar ditulis ulang jika ingin berjalan pada perangkat Android. Hal ini membuat aplikasi menjadi sangat mahal dan membutuhkan usaha yang tidak sedikit. Aplikasi native harus diunduh dan diinstal dari berbagai jenis “App Store”, seperti yang didapatkan di Apple iTunes atau Google’s Android Marketplace (IBM Corporation, 2012) (IBM Corporation, 2012).
Gambar 2.1. Aplikasi Native – Interaksi dengan Perangkat Mobile (WorkLight, 2011) 2.
Aplikasi web mobile Aplikasi web mobile biasanya menggunakan HTML, JavaScript, CSS dan berjalan pada browser perangkat. Dikarenakan berjalan di web browser aplikasi ini memiliki keunggulan yaitu dapat berjalan di perangkat mobile apa saja yang memiliki browser. Kekurangan dari implementasi aplikasi web yaitu aplikasi tersebut tidak memiliki akses fungsi dan fitur yang berjalan secara langsung
17
pada perangkat mobile, seperti kamera, daftar kontak, dan lainlainnya. Pada gambar 2.2 menjelaskan bagaimana aplikasi web berjalan pada perangkat mobile (IBM Corporation, 2012) (IBM Corporation, 2012).
Gambar 2.2. Aplikasi Web Mobile – Interaksi dengan Perangkat Mobile (WorkLight, 2011) 3.
Aplikasi hybrid Aplikasi hybrid adalah bentuk kolaborasi antara native dengan web mobile. Aplikasi hybrid terhubung dengan library native yang memungkinkan aplikasi memiliki akses ke fitur perangkat. Sebagian besar aplikasi hybrid diimplementasikan menggunakan teknologi spesifik, dan sebagian lainnya kode yang buat dapat dibuka oleh semua perangkat melalui mobile browser (IBM, 2012). Pada gambar 2.3 menjelaskan bagaimana aplikasi
18
hybrid berjalan pada aplikasi mobile (IBM Corporation, 2012) (IBM Corporation, 2012).
Gambar 2.3. Aplikasi Hybrid – Interaksi dengan Perangkat Mobile (WorkLight, 2011)
Berdasarkan karakteristiknya, (Souza & Aquino Jr., 2014) melalukan survei pada berbagai sumber yang membahas aplikasi mobile, yakni: 1.
Energi Terbatas: setiap perangkat mobile didukung oleh baterai dan karena ini ia memiliki periode hidup tertentu.
2.
Layar Kecil: layar perangkat mobile cukup kecil dan arena ini desain interface terbatas.
3.
Kinerja Terbatas: karena ukuran dan kemajuan teknologi semua perangkat mobile, bahkan yang paling maju dikelasnya, memiliki
19
keterbatasan sumber daya tertentu seperti kekuatan pemrosesan, memori dan konektivitas. 4.
Bandwidht: mengingat aplikasi ada yang memerlukan bandwidht maksimum,
minimum
atau
rata-rata,
kita
harus
mempertimbangkannya. 5.
Perubahan Konteks: Perubahan konteks terjadi sesuai dengan lingkungan.
6.
Pengurangan Memori: karena ukuran dan kemajuan teknologi, semua perangkat mobile yang bahkan paling canggih dikelasnya, memiliki keterbatasan sumber daya yang spesifik termasuk ukuran memori.
7.
Konektivitas: jenis konektivitas bahwa aplikasi akan digunakan seperti 3G, bluetooth, infrared, dan Wi-Fi.
8.
Interaktivitas: apa yang akan menjadi jenis input pengguna.
9.
Penyimpanan: aplikasi harus mempertimbangkan bagaimana hal itu akan dilakukan.
10. Software Portabilitas: aplikasi harus dilakukan pada semua jenis sistem operasi. 11. Peralatan Portabilitas: aplikasi harus dilakukan pada semua jenis perangkat. 12. Usability: adalah seperangkat atribut yang mempengaruhi upaya yang diperlukan untuk penggunaan, dimana itu harus seintuitif dan sealami mungkin untuk membuat atau meneruma panggilan atau pesan teks.
20
13. Keterediaan: aplikasi harus tersedia untuk mengakses dimana saja, dan kapan saja. 14. Keamanan: harus mencegah akses yang tidak sah disengaja atau disengaja untuk aplikasi dan data. 15. Keandalan: adalah seperangkat atribut yang mempengaruhi kemampuan aplikasi untuk mempertahankan tingkat kinerja dan di bawah kondisi yang ditetapkan untuk jangka waktu tertentu. 16. Efisiensi: adalah seperangkat atribut yang berhubungan dengan hubungan antara tingkat aplikasi kinerja dan jumlah sumber daya yang digunakan dalam kondisi lain. 17. Native vs. Web Mobile: harus diidentifikasikan jika aplikasi akan dirancang untuk diinstal pada perangkat itu sendiri, yang dikenal sebagai aplikasi Native, atau digunakan pada web. 18. Interoperabilitas: aplikasi harus dapat berinteraksi dengan sistem spesifik lainnya, dengan kata lain harus memiliki interoperabilitas dengan layanan lainnya. 19. Response Time: aplikasi harus diinisialisasi dan diselesaikan segera. 20. Privasi: Aplikasi harus menunjukan kepada pengguna bagaimana informasi pribadi dikumpulkan, digunakan dan dibagi. 21. Kegiatan Jangka Pendek: kegiatan dalam aplikasi mobile cenderung memiliki durasi pendek, mulai dari beberapa detik hingga beberapa menit.
21
22. Intergritas Data: memastikan bahwa jika aplikasi dimatikan sengaja atau mati sendiri, aplikasi akan menjamin integritas data. 23. Karakteristik Kunci: aplikasi cenderung lebih terfokus pada karakteristik kunci daripada menawarkan eksplorasi yang umum digunakan. 24. Integritas
Kompleks
Real-Time:
aplikasi
mobile
harus
menyediakan integrasi antara penerapan berbagai sumber (native atau web). 25. Gangguan Kegiatan yang Konstan: ketika menggunakan aplikasi mobile, kegiatan yang terus menerus terganggu seperti ketika menerima panggilan, kehilangan koneksi atau memiliki baterai lemah yang merupakan contoh dari gangguan tersebut. 26. Daerah Fungsional: data, kolaborasi, komunikasi, jasa informasi dan layanan produktivitas seperti aplikasi bisnis dan kantor. 27. Harga: gratis atau berbayar. 28. Terget Pengguna: aplikasi untuk aplikasi bisnis atau konsumsi pribadi. 29. Jenis Provider: bisnis, professional atau penyedia layanan lainnya.
Pada pengembangan aplikasi mobile ada beberapa hal yang sama dengan pengembangan aplikasi perangkat lunak lainnya. Namun aplikasi mobile menyajikan beberapa persyaratan yang jarang ditemukan pada perangkat lunak lainnya (Wasserman, 2010), yaitu:
22
1. Potensi interaksi dengan aplikasi lain – Sebagian besar perangkat embedded hanya memiliki perangkat lunak yang di-install oleh pabrik, namun perangkat mobile memiliki berbagai aplikasi dari berbagai sumber, dengan demikian kemungkinan adanya aplikasi yang saling berinteraksi.
2. Sensor handling – Smartphone memiliki accelerometer yang merespon setiap pergerakan perangkat, layar sentuh yang merespon banyak gerakan, memiliki vitual/real keybord, global positioning system, microphone, kamera, dan beberapa protokol jaringan.
3. Aplikasi native dan hybrid (mobile web) – Kebanyakan perangkat embedded hanya menggunakan perangkat lunak yang di-install langsung pada perangkat, tetapi perangkat mobile biasanya termasuk aplikasi yang memanggil layanan melalui telepon jaringan atau internet melalui browser web dan mempengaruhi data dan menampilkan pada perangkat.
4. Hardware dan Software Platform – perangkat embedded mengeksekusi code yang dibangun sesuai dengan sifat perangkat. Namun perangkat mobile harus dapat mendukung aplikasi yang dibuat untuk semua OS perangkat yang bervariasi. Misalkan pengembangan aplikasi di Android, harus memutuskan apakah akan membangun aplikasi tunggal atau beberapa versi untuk berjalan di berbagai perangkat Android dan OS lirisnya.
23
5. Keamanan – Ponsel merupakan platform yang terbuka, yang memungkinkan untuk menginstal aplikasi “Malware” yang dapat mempengaruhi keseluruhan pengoprasian perangkat, termasuk secara diam-diam mentrasmisi data lokal dengan aplikasi tersebut.
6. User Interface – Pada embedded, pengembang dapat mengotrol semua aspek dari pengalaman pengguna, tetapi aplikasi mobile harus berbagi elemen umum dari antarmuka pengguna dengan aplikasi lainnya dan harus mematuhi pedoman antarmuka pengguna.
7. Kompleksitas Pengujian – Aplikasi native dapat diuji dengan cara tradisional atau melalui PC emulator, namun aplikasi web mobile agak sulit untuk diuji. Tidak hanya memiliki banyak masalah yang sama ditemukan dalam pengujian aplikasi web, tetapi terdapat masalah dengan transmisi melalui gateway dan jaringan telepon.
8. Konsumsi Daya – Banyak aspek aplikasi mempengaruhi penggunaan daya perangkat (baterai). Perangkat dedicated dapat mengoptimalkan maksimun daya tahan baterai, tetapi aplikasi mobile secara tidak sengaja membuat ekstensif menggunakan sumber daya baterai.
2.4
Metode Pengukuran Aplikasi Mobile Berdasarkan cara mengukurnya, pendekatan untuk mengukur ukuran suatu software terbagi menjadi dua (Gencel, et al., 2006), yaitu:
24
1. Dengan menggunakan atribut panjang code. Panjang code bisa diukur dengan menggunakan line of code (LOC) atau menggunakan jumlah karakter, dan lainnya. Kekurangan dari LOC adalah LOC bersifat bergantung pada bahasa pemrograman yang digunakan sehingga program yang dibuat dengan bahasa pemrograman yang berbeda, tidak bisa dibandingkan secara langsung (Gencel, et al., 2006). 2. Dengan menggunakan jumlah fungsionalitas. Pendekatan ini pertama kali diteliti oleh Allan Albrecht pada tahun 1979. Albrecht mendesain metrik Function Point (FP) dan menghubungkannya dengan FPA untuk mengukur ukuran fungsional dari suatu sistem perangkat lunak (Albrecht, 1979). FPA ini kemudian dikembangkan lagi dan dipelihara oleh International Function Point User Group (IFPUG, 1999).
2.4.1 Faktor Aplikasi Mobile Pada penelitian yang dilakukan pada (Souza & Aquino Jr., 2014) yang melakukan estimasi usaha pada aplikasi mobile, mengusulkan faktor produktivitas baru yang akan menjadi karakteristik khusus dari aplikasi mobile. Sebelumnya terdapat faktor yang telah ditentukan oleh FiSMA (Forselius, 2004) mengenai priduktivitas, namun hanya enam yang diusulkan dan tidak menjelaskan faktor karakteristik aplikasi mobile. Faktor produktivitas (Productivity Factors) diusulkan oleh FiSMA (Forselius, 2004):
aplikasi yang
25
Persyaratan Fungsi (Funtionality Requirement): Kompatibilitas dengan pengguna akhir dan kompleksitas kebutuhan. •
(- -) Aplikasi kompleks dan kritis (ribuan FP), beberapa jenis pengguna dan sistem multikultural.
•
( - ) Aplikasi dapat dioperasikan dengan beberapa karakteristik yang rumit, membutuhkan pemahaman khusus dari pengguna dan pengembang.
•
(+/-) Aplikasi sebagian otomatis dan terintegrasi dan ukuran aplikasi medium (600 sampai 1000 FP) dengan kebutuhan keamanan standar.
•
( + ) Aplikasi sebagian besar otomatis dan memiliki kurang dari 5 antar muka dengan sistem lainnya, ada kebutuhan keamanan tertentu.
•
(+ +) Aplikasi yang sangat matang, sederhana, dan mudah, aplikasi yang berdiri sendiri (kurang dari 200 FP), untuk sekelompok kecil pengguna. Persyaratan keandalan (Reliability Requirement): kematangan,
toleransi terhadap kesalahan dan pemulihan untuk berbagai jenis kasus pengguna. •
(- -) Kegagalan atau kesalahan dapat membahayakan kehidupan manusia dan menyebabkan kerugian ekonomi dan lingkungan yang signifikan.
26
•
( - ) Perangkat lunak bagian dari sistem real-time besar di mana semua kegagalan operasi akan menyebabkan masalah untuk banyak aplikasi lainnya.
•
(+/-) Dapat diterima jika tidak lebih dari dua jam downtime, tetapi rutinitas pemulihan sistem sesuai.
•
( + ) Kebutuhan untuk operasi tidak setiap hari.
•
(+ +) Kebutuhan untuk operasi periodik. Berhenti selama beberapa hari tidak akan menyebabkan kerusakan pada organisasi. Persyaratan Kegunaan (Usability Requirement): Pengertian dan
kemudahan untuk mempelajari antar muka pengguna dan logika alur kerja. •
(- -) Berbagai jenis pengguna di seluruh dunia.
•
( - ) Dua atau tiga jenis pengguna dengan keahlian yang berbeda.
•
(+/-) Sebagian besar pengguna memiliki kemampuan yang sama.
•
( + ) Tidak lebih dari puluhan atau ratusan pengguna, mungkin lebih dari satu lokasi.
•
(+ +) Hanya beberapa pengguna, semua terletak di satu situs. Persyaratan Efisiensi (Effeciency Requirement): Penggunaan
sumber daya secara efektif dan kinerja yang memadai dalam setiap kasus penggunaan dan di bawah beban kerja yang wajar. •
(- -) Basis data yang kompleks dengan jutaan catatan data dan transaksi per hari, ribuan pengguna menggunakan secara bersamaan.
27
•
( - ) Basis data besar, ratusan pengguna menggunakan secara bersamaan, tanggapan kritis di beberapa waktu tertentu.
•
(+/-) Basis data yang besar, kurang dari jutaan data dan kurang dari ratusan pengguna yang menggunakan secara bersamaan.
•
( + ) Basis data dalam volum dan struktur medium, permintaan data dari beberapa pengguna serhana dan dapat diprediksi.
•
(+ +) Basis data sederhana dan kecil tanpa pengguna yang menggunakan secara bersamaan dan tidak ada permintaan data yang kompleks. Persyaratan Pemeliharaan (Maintainability Requirement): masa
pakai aplikasi, kekritisan diagnosis kesalahan dan uji kinerja. •
(- -) Perangkat lunak strategis yang sangat besar (lebih dari 20 tahun masa pakai) di daerah volatile bisnis, dengan sering adanya perubahan peraturan dan aturan bisnis.
•
( - ) Perangkat lunak besar (10-20 tahun masa pakai) dan sering berubah-ubah dalam peraturan dan aturan bisnis.
•
(+/-) Perangkat lunak ukuran sedang (5-10 tahun masa pakai) perubahan peraturan dan aturan bisnis setiap bulan.
•
( + ) Perangkat lunak kecil (2-5 tahun masa pakai) jarang terjadi perubahan.
•
(+ +) Perangka lunak sementara (kurang dari 2 tahun masa pakai) tanpa perubahan.
28
Persyaratan Portabilitas (Portability Requirement): adaptasi dan ketidakstabilan lingkungan yang berbeda, untuk arsitektur dan komponen struktural. •
(- -) Pengguna perangkat lunak terdapat dalam beberapa jenis organisasi, dengan berbagai platform (perangkat keras, browser, sistem operasi, middleware, protokol, dll), berbagai versi dan berbagai frekuensi pembaruan.
•
( - ) Perangkat lunak harus beroperasi pada beberapa platform yang berbeda (perangkat keras, browser, sistem operasi, middleware, protokol, dll) dan dalam berbagai versi masing-masing.
•
(+/-) Setiap versi perangkat lunak harus berjalan di beberapa versi platform tertentu (perangkat keras, browser, sistem operasi, middleware, protokol, dll) dan frekuensi pembaruan dari pengguna cukup bisa diprediksi.
•
( + ) Perangkat lunak harus dijalankan pada platform tertentu (perangkat keras, browser, sistem operasi, middleware, protokol, dll) tetapi penggunaan tingkat layanan sistem terbatas karena proses upgrade secara parsial.
•
(+ +) Perangkat lunak harus dijalankan pada platform tertentu (perangkat keras, browser, sistem operasi, middleware, protokol, dll), tetapi proses upgrade benar-benar dikontrol.
Keterangan: •
”+ +” = [0.9] Situasi sangat baik, keadaan jauh lebih baik daripada dalam kasus rata-rata.
29
•
” + ” = [0.95] Situasi baik, keadaan yang lebih baik daripada dalam kasus rata-rata.
•
”+/-” = [1.0] Situasi normal
•
” - ” = [1.05] Situasi buruk, keadaan lebih buruk daripada dalam kasus rata-rata.
•
”- -” = [1.1] Situasi sangat buruk, keadaan jauh lebih buruk daripada dalam kasus rata-rata.
Faktor karakteristik aplikasi mobile yang diusulkan oleh (Souza & Aquino Jr., 2014) dapat dilihat berikut ini: 1.
Faktor Performa • ( - ) Aplikasi harus peduli dengan optimalisasi sumber daya untuk efisiensi dan waktu respon yang lebih baik. • (+/-) Optimalisasi sumber daya untuk efisiensi dan waktu respon yang lebih baik mungkin ada atau tidak ada. • ( + ) Optimalisasi sumber daya untuk efisiensi dan waktu respon yang lebih baik tidak seharusnya dipertimbangkan.
2.
Faktor Daya • ( - ) Aplikasi harus peduli dengan optimalisasi sumber daya untuk konsumsi pemakaian baterai yang lebih rendah. • (+/-) Optimalisasi sumber daya untuk konsumsi pemakaian baterai yang lebih rendah mungkin ada atau tidak ada. • ( + ) Optimalisasi sumber daya untuk konsumsi pemakaian baterai yang lebih rendah tidak seharusnya dipertimbangkan
30
3.
Faktor Bandwidth • ( - ) Aplikasi menggunakan bandwidth maksimum. • (+/-) Aplikasi menggunakan bandwidth standart. • ( + ) Aplikasi menggunakan bandwidth minimum.
4.
Faktor Konektivitas • ( - ) Aplikasi
memiliki
ketersediaan
maksimum
untuk
menggunakan koneksi seperti 3G, Wi-Fi, Wireless, Bluetooth, Infrared, dan lain-lain. • (+/-) Aplikasi memiliki kecendrungan wajar untuk menggunaka koneksi seperti 3G, Wi-Fi, dan Wireless. • ( + ) Aplikasi hanya memiliki kecendrungan untuk menggunakan salah satu koneksi. 5.
Faktor Konteks • ( - ) Aplikasi bekerja secara offline dan melakukan sinkronisasi. • (+/-) Aplikasi bekerja secara online dan tidak melakukan sinkronisasi. • ( + ) Aplikasi tidak bekerja secara offline.
6.
Faktor Grafis Antarmuka • ( - ) Aplikasi ini memiliki keterbatasan ukuran layar, karena diutamakan utuk pengguna telepon seluler. • (+/-) Aplikasi ini memiliki keterbatasan ukuran layar yang wajar, karena akan digunakan baik melalui telepon seluler dan tablet. • ( + ) Aplikasi memiliki sedikit keterbatasan ukuran layar, karena diutamakan untuk pengguna tablet.
31
7.
Faktor Input Antarmuka • ( - ) Aplikasi harus memiliki antar muka input untuk layar sentuh, suara, video, keyboard, dan lainnya. • (+/-) Aplikasi harus memiliki antar muka input standar untuk keyboard. • ( + ) Aplikasi harus memiliki salah satu dari input antar muka, seperti: layar sentuh, suara, video, keyboard atau lainnya.
Faktor-faktor tersebut memiliki bobot, yakni: •
” + ” = [1.05] Situasi yang baik, keadaan yang lebih baik daripada kasus rata-rata.
•
”+/-” = [1.0] Situasi normal.
•
” - ” = [0.95] Situasi yang buruk, keadaan yang lebih buruk daripada kasus rata-rata.
2.4.2 Metrik Aplikasi Web Dari hasil penelitian yang dilakukan oleh (Rosmina & Suharjito, 2012), yang diadaptasi dari penelitian Mendes et al. (2003) & Abraho et al. (2006) terdapat variable yang digunakan dalam perhitungan usaha pada aplikasi web. Variabel-variabel yang digunakan oleh Rosmina adalah: Tabel 2.3.Variabel-variabel yang diajukan oleh (Rosmina & Suharjito, 2012) Tipe Variabel Deskripsi
Hypermedia Web
Fungsional Web
32
FPd
Jumlah data fungsional berdasarkan pada class dan legacy view yang ada dalam aplikasi yang ingin dibuat.
EI
Jumlah service atau fungsi yang didefinisikan dalam class atau legacy view.
EQ
Jumlah Instance Interaction Unit, Population Interaction Unit, dan Master Detai Interaction Unit yang didefinisikan dimodel presentasi.
EO
Jumlah Instance Interaction Interation Unit, dan Master Unit yang didefinisikan di dengan mengelolah informasi dahulu.
FP
Total fungsional yang ada pada sistem yang merupakan gabungan dari FPd + EI + EQ + EO
TypeProj
Tipe proyek
TypeApp
Tipe aplikasi web yang dikembangkan
DocProc?
Apakah proyek diikuti dengan proses definisi dan dokumentasi?
Devteam
Ukuran dari tim developer
Teamexp
Rata-rata pengalaman tim dengan bahasa yang digunakan
Webpages
Jumlah halaman web
newWP
Jumlah halaman web baru
Wpcustom
Jumlah halaman web yang diberikan oleh pelanggan
Wpout
Jumlah halaman web yang dikembangkan oleh orang lain
WpOwnCo
Jumlah halaman web yang digunakan kembali dari perusahaan yang lama
txtTyped
Jumlah halaman teks yang diketik (~600 kata)
txtElec
Jumlah format elektronik dari halaman teks
txtScan
Jumlah halaman teks yang di-scan
Unit, Population Detail Interaction model presentasi yang ada terlebih
33
imgNew
Jumlah gambar baru
Img3rdP
Jumlah gambar yang dikembangkan oleh orang lain
imgScan
Jumlah gambar yang di-scan
imgLib
Jumlah gambar yang digunakan kembali oleh perusahaan sendiri
imgOwnCo
Jumlah gambar yang digunakan kembali oleh perusahaan sendiri
Animnew
Jumlah animasi baru
animLib
Jumlah animasi yang digunakan kembali dari sebuah library
AVNew
Jumlah audio/video baru
AVLib
Jumlah audio/video yang digunakan kembali
2.4.3 Fuction Point Analysis Function Point (FP) adalah suatu pengukuran standar dari perangkat lunak untuk kuantifikasi fungsionalitas yang ditawarkan oleh program ke pengguna. Fuction Point Analysis (FPA) pertama kali dikembangkan oleh Allan Albrecht untuk IBM (Albrecht, 1979) ,yang kemudian dikembangkan oleh IFPUG . Metode perhitungan IFPUG berdasarkan pada identifikasi fungsi yang seharusnya dilakukan oleh sistem dan memberikan tingkat kompleksitas ke setiap fungsi. Setiap fungsi yang berbeda-beda diklasifikasikan (IFPUG, 1999) (Abrahao, Poels, & Pastor, 2006) menjadi: 1. Fungsi tentang penyimpanan data (Data Functions) yang terdiri dari : a. Internal Logical Files (ILF) jika data yang dibuat, dipelihara dan diatur oleh sistem.
34
b. External Interface Files (EIF) jika data yang digunakan diatur di luar ruang lingkup aplikasi. 2. Fungsi yang berinteraksi dengan pengguna (Transaction Functions) terdiri dari : a. External Inputs (EI), jika tujuannya adalah mengumpulkan informasi dari pengguna. b. External Queries (EQ), jika tujuannya adalah untuk mengambil informasi yang diminta oleh pengguna. c. External Outputs (EO), jika memberikan informasi kepada pengguna akibat dari suatu aksi atau elaborasi.
Gambar 2.4. Pandangan FPA pada Ukuran Fungsional (Abrahao, Poels, & Pastor, 2006)
2.4.4 OOmFPWeb OomFPWeb (OO-method Function Point for the Web) memiliki beberapa pandangan perspektif untuk aplikasi web yang terdiri dari (Abrahao & Poels, 2009):
35
1.
Data : data yang digunakan dan dipelihara oleh aplikasi web. Data didefinisikan dengan menggunakan model objek. Model class memrepresentasikan data logikal yang dipelihara oleh aplikasi dan legacy views memrepresentasikan data logikal yang direferensikan oleh aplikasi.
2.
Process : komputasi yang seharusnya dilakukan oleh aplikasi web yang didefinisikan oleh model objek dengan definisi semantik yang jelas yang berhubungan dengan perubahan state pada model fungsional.
3.
Behavior : interaksi dinamis daris istem yang berhubungan dengan objek yang hidup dan interaksi antar objek yang didefinisikan di dalam model dinamis.
4.
Navigation : struktur navigasi dari aplikasi yang didefinisikan di dalam model navigasi.
5.
Presentation : interaksi pengguna dengan antarmuka aplikasi web, yang didefinisikan di model presentasi.
36
Gambar 2.5. Prosedur Model Pengukuran OOmFPWeb (Abrahao & Poels, 2009)
2.4.3.1 Aturan Perhitungan OOmFPWeb OOmFPWeb merupakan suatu metode yang melakukan mapping antara konsep yang dideskripsikan di metamodel IFPUG (ISO/IEC, 2003a)
37
dan konsep yang ada di metamodel OOWS (Abrahao & Poels, 2009) (Abrahao, Poels, & Pastor, 2006): Tabel 2.4. Mapping antara konsep FPA dan konsep OOWS Fungsi FPA OO-Method Class yang mengenkapsulasi ILF Data logikal yang kumpulan atribut data yang diidentifikasi oleh merepresentasikan state dari pengguna yang objek dari setiap class. dipelihara di dalam ruang lingkup sistem. EIF Data logikal yang Legacy view yang direferensikan oleh didefinisikan sebagai filter sistem dan dipelihara yang ditempatkan di class dalam ruang lingkup oleh sistem yang sudah ada sistem. sebelumnya. EI Sebuah proses yang Service yang didefinisikan memproses data atau di dalam class atau legacy informasi kontrol dari view. luar sistem. EO Sebuah proses untuk Instance Interaction Unit mengirim data atau (IIU), Population mengontrol informasi ke Interaction Unit (PIU), dan luar ruang lingkup Master Detail Interaction Unit (MDIU) yang sistem. didefinisikan di model presentasi. EQ Sebuah proses yang Model di dalam model memberikan informasi presentasi, memberikan ke pengguna melalui informasi ke pengguna tanpa penarikan data atau mengubah kelakukan sistem. informasi kontrol.
Kompleksitas dari fungsi transaksional adalah fungsi dari jumlah Data Element Types (DET_Transaction) dan jumlah File Types Referenced (FTR). FTR adalah fungsi data yang direferensikan selama eksekusi dari fungsi transaction (Abrahao, Poels, & Pastor, 2006)
38
Kompleksitas dari fungsi data adalah fungsi dari jumlah Data Element Type (DET) dan jumlah Record Element Type (RET). DET merupakan suatu field yang unik dan tidak berulang-ulang. RET adalah elemen data yang dikenalin oleh pengguna dalam file logikal (ILF atau EIF) (Abrahao, Poels, & Pastor, 2006) Aturan perhitungan total DET RET untuk class dan legacy view dapat dilihat pada tabel 2.5 dan tabel 2.6. Sedangkan aturan umum perhitungan total DET dan FTR untuk service pada class dan legacy view, IIU (Instance Interaction Unit), dan PIU (Population Interaction Unit) bisa dilihat pada tabel 2.7, tabel 2.8, tabel 2.9, dan tabel 2.10. Tabel 2.5. Aturan Pengukuran untuk Kompleksitas Class (Abrahao, Poels, & Pastor, 2006) Tipe Element Data Record Element Type 1 DET untuk setiap atribut dari class
1 RET untuk class
1 DET untuk setiap atribut di IF dari
1 RET untuk setiap hubungan
sebuah
multi-valued agregasi (class atau
class
atau
legacy
direferensikan oleh sebuah hubungan
legacy view)
agregasi banyak. 1 DET untuk setiap atribut di IF dari class induk dari sebuah class
Tabel 2.6. Aturan Pengukuran Kompleksitas dari Legacy View (Abrahao, Poels, & Pastor, 2006) Tipe Element Data Record Element Type 1 DET untuk setiap atribut dari legacy
1 RET untuk legacy view.
view. 1 DET untuk setiap atribut di IF dari
1 RET untuk setiap hubungan
class
multi-valued
yang
berhubungan
hubungan agregasi univalued.
dengan
sebuah class.
agregasi
dengan
39
Tabel 2.7. Aturan Pengukuran untuk Kompleksitas dari Service (Abrahao, Poels, & Pastor, 2006) Tipe Element Data File Type Referenced 1 DET untuk setiap argumen nilai data
1 FTR untuk class.
dari service. 1 DET untuk kapasitas sistem untuk
1 FTR untuk setiap class baru yang
mengirim data.
direferensi dalam argumen nilai objek dari service.
1 DET untuk aksi (terima/batal) dari
1 FTR untuk setiap class baru yang
eksekusi service.
direferensi dalam formula dari nilai standar. 1 FTR untuk setiap class baru yang direferensi dalam formula dari kejadian destroy. 1 FTR untuk setiap class baru yang direferensi
dalam
formula
transaksi. 1 FTR untuk setiap class baru yang direferensi dalam formula kondisi dari spesialisasi. Untuk spesialisasi oleh kejadian, hitung 1 FTR untuk setiap class baru yang kejadian adalah carrier dan liberator. 1 FTR untuk setiap class baru direferensi dalam formula batasan integritas.
Tabel 2.8. Aturan Pengukuran untuk Kompleksitas dari Service Legacy View (Abrahao, Poels, & Pastor, 2006) Tipe Element Data File Type Referenced
40
1 DET untuk setiap argumen nilai data
1 FTR untuk legacy view.
dari service. 1 DET untuk kapasitas sistem untuk
1 FTR untuk setiap class baru
mengirim pesan.
direferensi
dalam
formula
precondition. 1 DET untuk aksi (terima/batal) dari
1 FTR untuk setiap class baru
service.
direferensi dalam formula eksekusi dari sebuah integrity constraint.
Tabel 2.9. Aturan Pengukuran untuk Instance Interaction Unit Pattern (Abrahao, Poels, & Pastor, 2006) Tipe Element Data File Type Referenced 1 DET untuk setiap atribut yang unik.
1 FTR untuk setiap class atau legacy view dalam tampilan.
1 DET untuk setiap atribut unik yang ditampilkan (hanya jika atributnya berbeda dari OID). 1 DET untuk
setiap
aksi yang
ditawarkan. 1 DET untuk setiap navigasi yang ditawarkan. 1 DET untuk kapasitas sistem untuk menampilkan pesan. Tabel 2.10. Aturan Pengukuran untuk Population Interaction Unit Pattern (Abrahao, Poels, & Pastor, 2006) Tipe Element Data Record Element Type 1 DET untuk setiap variabel nilai data
1 FTR untuk setiap class atau
yang unik dari sebuah filter.
legacy view dalam tampilan.
1 DET untuk setiap atribut dalam
1 FTR untuk setiap variabel nilai
tampilan
objek yang unik dari filter.
(hanya
berbeda dari filter).
jika
atributnya
41
1 DET untuk ditawarkan
setiap
(standarnya
aksi yang 1 FTR untuk setiap class baru service direferensi dalam kriteria pengurutan.
class/legacy view). 1 DET untuk setiap navigasi yang 1 FTR untuk setiap class baru ditawarkan.
direferensi dalam formula filter.
1 DET untuk kapasitas sistem untuk menampilkan pesan.
Untuk menentukan tingkat kompleksitas dari ILF dan EIF bisa dilihat pada aturan yang disebutkan pada tabel 2.10. untuk menentukan tingkat kompleksitas dari EI bisa dilihat pada aturan yang disebutkan pada tabel 2.11. untuk menentukan tingkat kompleksitas dari EO dan EQ bisa dilihat pada aturan yang disebutkan pada tabel 2.12 (Alexander, 2004). Tabel 2.11. Level Kompleksitas untuk ILF dan EIF (Alexander, 2004) Data Element Type (DET’s) RET’s 1-19 20-50 51+ 1
Low
Low
Average
2-5
Low
Average
High
High
High
6 or more Average
Tabel 2.12. Level Kompleksitas untuk EI (Alexander, 2004) Data Element Type (DET’s) FTR’s 1-4 5-15 16+ 0-1
Low
Low
Average
2
Low
Average
High
High
High
3 or more Average
Tabel 2.13. Level Kompleksitas untuk EO dan EQ (Alexander, 2004) FTR’s Data Element Type (DET’s)
42
1-5
6-19
20+
0-1
Low
Low
Average
2-3
Low
Average
High
High
High
4 or more Average
Untuk setiap fungsi yang ditemukan, diberi bobot sesuai dengan tingkat kompleksitasnya yang bisa dilihat pada tabel 2.13. Tabel 2.14. Bobot Kompleksitas (Alexander, 2004) Tipe Fungsi Low Average High ILF 7 10 15 EIF 3 4 6 EI 3 4 6 EO 4 5 7 EQ 3 4 6
2.4.3.2 Perhitungan OOmFPWeb Dengan diberikan sebuah skema konseptual yang dibuat pada saat langkah pemodelan OO-Method konseptual, OOmFP dapat dihitung dengan menggunakan rumus (Abrahao, Poels, & Pastor, 2006):
dimana:
dimana:
43
n adalah total class didefinisikan dalam proyek yang akan diukur, m adalah total legacy view yang ditemukan dalam proyek, x adalah total service yang ditemukan di semua class, dan y adalah jumlah interface yang ditemukan dalam proyek.
2.4.5 Expert Choice pada Aplikasi Analytical Hierarchy Process (AHP) Metode Analytical Hierarchy Process (AHP) dikembangkan untuk bertujuan membuat suatu model permasalahan yang tidak mempunyai struktur, biasanya ditetapkan untuk masalah yang terukur (kuantitatif), masalah yang memerlukan pendapat (judgement) maupun pada situasi yang kompleks atau tidak terkerangka, pada siuasi dimana data statik sangat minimum atau tidak ada sama sekali dan hanya bersifat kualitatif yang didasari oleh presepsi, pengalaman atau intuisi. Dalam menyelesaikan persoalan dengan AHP ada beberapa prinsip dasar yang ada, antara lain: 1.
Dekomposisi Setelah mendefinisikan permasalah atau persoalan maka perlu dilakukan dekomposisi, dekomposisi yakni memecahkan persoalan yang utuh menjadi unsur-unsurnya. Oleh karena itu, proses analisis ini dinamakan hierarki (hierarchy). Struktur hierarki AHP dapat dilihat pada gambar dibawah ini.
44
Gambar 2.6. Struktur Hierarki AHP
2.
Penilaian Komparasi (Comparative Judgement) Prinsip ini berarti membuat penilaian tentang relative dua elemen pada suatu tingkat tertentu dalam kaitannya dengan tingkatan di atasnya. Hasil dari penilaian ini lebih mudah disajikan dalam
bentuk
matriks
perbandingan
berasangan
(Parwise
Comparation).
3.
Penentuan Prioritas (Synthesis of Priority) Dari setiap matriks pairwise comparation akan didapatkan prioritas lokal. Karena matriks pairwise comparation terdapat pada setiap tingkat, maka untuk menentukan prioritas global harus dilakukan sintesis di antara prioritas lokal. Prosedur melakukan sintesis berbeda tergantung dari bentuk hierarkinya. Untuk berbagai persoalan, skala 1 sampai 9 adalah skala terbaik dalam mengekspresikan pendapat. Nilai dan definisi
45
pendapat kualitatif dari skala pembanding (Saaty, 1987) dapat dilihat pada tablel berikut. Tabel 2.15. Nilai dan Definisi Skala Pembanding (Saaty, 1987) Intesitas Keterangan Kepentingan Kedua elemen sama pentingnya 1 3
Elemen yang satu lebih sedikit penting daripada elemen yang lainnya
5
Elemen yang satu lebih penting dari pada yang lainnya
7
Satu elemen jelas lebih mutlak penting daripada elemen lainnya
9
Satu elemen mutlak penting daripada elemen lainnya
2,4,6,8
4.
Nilai-nilai antara dua nilai pertimbanganpertimbangan yang berdekatan.
Konsistensi Logis (Logical Consistency) Konsistensi memiliki dua makna. Pertama adalah bahwa objek-objek yang serupa dapat dikelompokkan sesuai keseragaman dan elevansinya. Kedua adalah tingkat hubungan antara objekobjek yang didasarkan pada kriteria tertentu.
2.5
Metode Estimasi Usaha Estimasi usaha digunakan untuk memprediksi jumlah waktu yang diperlukan
oleh
seseorang
atau
sekelompok
untuk
mencapai
tugas/aktivitas/proses yang diberikan. Proses dalam mengestimasi usaha terdiri dari:
46
1.
Membuat model usaha
2.
Membuat sebuah perkiraan usaha
Lebih dari 30 tahun terakhir, beberapa teknik untuk melakukan estimasi usaha sudah diajukan. Teknik untuk melakukan estimasi usaha dibagi menjadi tiga ketegori (Shepperd, Schofield, & Kitchenham, 1996), yaitu: 1. Pendapat ahli Proses estimasi teknik ini dilakukan dengan melalui pendapat para ahli secara subjektif berdasarkan pada pengalaman di masa lalu dari mengatur proyek yang sama sebelumnya. Proses estimasi usaha menggunakan pendapat ahli terdiri dari: a. Ahli melihat faktor-faktor yang mempengaruhi estimasi usaha dan biaya yang berhubungan dengan proyek baru dimana usaha yang butuh diestimasi. b. Berdasarkan data yang diingat atau yang diambil dari proyek yang sudah selesai di masa yang usahanya sudah diketahui. c. Berdasarkan data dari poin (a) dan (b), dilakukan estimasi usaha untuk proyek baru secara subjektif. Estimasi usaha yang tepat bisa diberikan jika terdapat proyek yang sama dengan proyek di masa lalu. 2. Model algoritma Salah satu model algoritma adalah COnstructive COst MOdel (COCOMO):
dimana:
47
Nilai a dan b merupakan jenis atau mode proyek yang sedang berjalan, EstSizeNewProject merupakan estimasi ukuran dari proyek baru dan Effort Adjustment Factor (EAF) berdasarkan pada 15 pemicu biaya yang dihitung dan dijumlahkan. (Boehm, 1981) mengusulkan tiga tipe proyek, yakni: a. Organic mode – proyek sederhana yang melibatkan tim kecil yang bekerja di lingkungan yang dikenal dan stabil. b. Semi-detached mode – proyek yang melibatkan tim dengan pengalaman yang bervariasi. Jenis ini di antara organic mode dan embedded mode. c. Embedded mode – proyek kompleks yang dikembangkan dibawah pengawasa ketat dan biasanya memiliki hambatan yang cukup besar. Tim sebagian besar terdiri dari tenaga yang berpengalaman. Tabel 2.16. Usaha Pengembangan pada Intermediate COCOMO Development mode
Intermediate Effort Equation
Organic
DE = EAF * 3.2 * (SIZE)1.05
Semi-deteched
DE = EAF * 3.0 * (SIZE)1.12
Embedded
DE = EAF * 2.8 * (SIZE)1.2
EAF merupakan hasil dari 15 pemicu biaya yang dapat dilihat di tabel 2.17. Multipliers dari pemicu biaya adalah Very Low, Low, Nominal, High, Very High and Extra High. Misalkan untuk sebuah proyek, jika RELY adalah Low, Data adalah High, CPLX adalah Extra High, TIME adalah Very High, STOR adalah High, dan parameter lainnya adalah nominal makan EAF = 0.75 * 1.08 * 1.65 * 1.30 * 1.06 * 1.0. Jika nilai-
48
nilai kategori semua 15 pemicu biaya adalah “Nominal”, maka EAF adalah sama dengan 1.
No 1
Tabel 2.17. 15 Pemicu Biaya pada Intermediate COCOMO Cost Very Extra Very Driver Low Nominal High High High Low Symbol RELY 0.75 0.88 1.00 1.15 1.40 ─
2
DATA
─
0.94
1.00
1.08
1.16
─
3
CPLX
0.70
0.85
1.00
1.15
1.30
1.65
4
TIME
─
─
1.00
1.11
1.30
1.66
5
STOR
─
─
1.00
1.06
1.21
1.56
6
VIRT
─
0.87
1.00
1.15
1.30
─
7
TURN
─
0.87
1.00
1.07
1.15
─
8
ACAP
─
0.87
1.00
1.07
1.15
─
9
AEXP
1.29
1.13
1.00
0.91
0.82
─
10
PCAP
1.42
1.17
1.00
0.86
0.70
─
11
VEXP
1.21
1.10
1.00
0/90
─
─
12
LEXP
1.14
1.07
1.00
0.95
─
─
13
MODP
1.24
1.10
1.00
0.91
0.82
─
14
TOOL
1.24
1.10
1.00
0.91
0.83
─
15
SCED
1.23
1.08
1.00
1.10
1.10
─
15 pemicu biaya secara luas diklasifikasikan menjadi 4 kategori (Boehm, 1981) (Xu & Khoshgoftaar, 2004): a) Product:
RELY - Required software reliability DATA - Data base size CPLX - Product complexity
b) Platform: TIME - Execution time STOR - Main storage constraint VIRT - Virtual machine volatilit
49
TURN - Computer turnaround time c) Personel: ACAP - Analyst capability AEXP - Applications experience PCAP - Programmer capability VEXP - Virtual machine experience LEXP - Languange experience d) Project:
MODP - Modern programing TOOL - Use of software tools SCED - Require developmet schedule
Bergantung pada proyek, multiplikator pemicu biaya akan bervariasi dan dengan demikian EAF mungkin lebih besar dari atau kurang dari 1, sehingga mempengaruhi usaha. (Xu & Khoshgoftaar, 2004).
3. Teknik kecerdasan buatan Salah satu jenis teknik kecerdasan buatan adalah logika fuzzy. Menurut (Li, 1997) logika fuzzy merupakan basis pengetahuan atau sistem basis aturan-aturan. Inti dari sistem fuzzy adalah basis pengetahuan yang terdiri dari apa yang disebut aturan fuzzy IF-THEN. Aturan fuzzy adalah pernyataan IF-THEN di mana beberapa kata yang ditandai dengan fungsi keanggotaan yang berkelanjutan. Sebagai contoh dari aturan fuzzy IFTHEN adalah: IF the speed of a car is high, THEN apply less force to the accelerator. Logika fuzzy merupakan sebuah metodologi sistem kontrol penyelesaian masalah yang cocok diimplementasikan dalam sistem, mulai
50
dari sistem yang sederhana, kecil, embedded micro-controllers, hingga yang besar, jaringan, multi channel PC dan sistem kontrol. Logika fuzzy menyediakan sebuah cara yang sederhana untuk mendapatkan kesimpulan berdasarkan informasi yang kabur, ambigu, tidak tepat atau bahkan yang hilang. Umumnya, logika fuzzy adalah metode cukup efektif untuk sistem yang model matematikanya tidak diketahui atau tidak dapat dibuat (Aydin, Karakose, & Akin, 2009). Sebuah sistem menggunakan logika fuzzy memiliki hubungan langsung dengan konsep fuzzy (seperti fuzzy sets, variable linguistic, dll) dan logika fuzzy. Yang paling populer sistem logika fuzzy dapat dikategorikan menjadi tiga jenis: Pure fuzzy logic systems, Takagi and Sugeno’s fuzzy system, dan fuzzy logic system with fuzzier dan defuzzifier (Ziauddin, Kamal, Khan, & Nasir, 2013). Logika Fuzzy dimulai dengan konsep teori himpunan fuzzy. Ini adalah teori kelas dengan batas-batasan yang tidak tajam, dan dianggap sebagai perpanjangan dari teori himpunan klasik. Keanggotaan µ dari elemen x dari himpunan klasik A, sebagai bagian dari alam semesta X, didefinisikan sebagai berikut (Ziauddin, Kamal, Khan, & Nasir, 2013):
Menurut (Emami, 1997) pemodelan Fuzzy merupakan suatu pendekatan untuk membentuk sistem model degan menggunakan bahasa deskriptif berdasarkan logika fuzzy dengan proporsi fuzzy. Logika fuzzy menggunakan tiga langkah untuk mencapai sebuah solusi crips untuk
51
banyak persoalan: a crips-to-fuzzy transformation (“fuzzification”), mekanisme
inferensi
aturan
yang
berlaku,
dan
fuzzy-to-crips
transformation (“defuziffication”). Yang terlihat di gambar, Crips Input ditransformasikan ke fuzzy domain, data dimanipulasi, dan hasilnya ditransformasikan kembali kedalam domain chips. (Attaran, 1996).
Gambar 2.7. Struktur dan Komponen Sistem Fuzzy (Attaran, 1996) Pada gambar 2.8 merupakan Fuzzy Membership Function dengan Kurva 2.8a adalah tringular fuzzy number, kurva di gambar 2.8b adalah trapezoidal fuzzy number, dan pada kurva 2.8c adalah bell sharped fuzzy number (Ziauddin, Kamal, Khan, & Nasir, 2013).
(2.8a)
(2.8b) Gambar 2.8. Fuzzy Membership Functions
(2.8c)
52
