7
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
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,
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
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
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
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.
Tabel 2.2. Study Literature
Publication Problem Method
Fuzzy Logic
Sharma & Verma (2010) Pengoptimalan logika fuzzy pada estimasi usaha dalam pengembangan software
Fuzzy Logic & COCOMO Kad & Chopra (2011) Membuat model estimasi usaha dalam
pengembangan software menggunakan Fuzzy Logic
Fuzzy Logic & COCOMO II Ziauddin, Kamal, Khan,
& Nasir (2013)
Membuat model untuk meng-improve keakuratan dari mengestimasi usaha pada software
Fuzzy Logic (COCOMOII+Alaa Setha)
Mobile Application
Laudson, Gibeon (2014) Membuat model estimasi usaha untuk
aplikasi mobile. FiSMA + Faktor Aplikasi Mobile
Web Application
(Rosmina & Suharjito, 2012)
Membuat model estimasi usaha untuk aplikasi web dengan menggunakan FHSWebEE.
OOmFPweb,
Metric Web & Case Base Reasoning
Stefani Agusta & Suharjito (2015)
Model estimasi usaha pengembangan aplikasi mobile menggunakan Fuzzy Logic Fuzzy Logic, OOmFPWeb, Metric Web, 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.
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.
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
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
pada perangkat mobile, seperti kamera, daftar kontak, dan lain-lainnya. 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
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
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.
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.
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:
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 yangmerespon 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 embeddedmengeksekusi 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.
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 mengotrolsemua 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:
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) aplikasi yang diusulkan oleh FiSMA (Forselius, 2004):
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.
• ( - ) 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.
• ( - ) 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.
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.
• ” + ” = [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
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
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)
Fun
g
sion
al
Web
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 Unit, Population
Interation Unit, dan Master Detail Interaction Unit yang didefinisikan di model presentasi dengan mengelolah informasi yang ada terlebih dahulu.
FP Total fungsional yang ada pada sistem yang merupakan gabungan dari FPd + EI + EQ + EO
Hyperme
d
ia
Web
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
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.
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):
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.
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)
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
ILF Data logikal yang
diidentifikasi oleh pengguna yang dipelihara di dalam ruang lingkup sistem.
Class yang mengenkapsulasi kumpulan atribut data yang merepresentasikan state dari objek dari setiap class.
EIF Data logikal yang
direferensikan oleh sistem dan dipelihara dalam ruang lingkup sistem.
Legacy view yang didefinisikan sebagai filter yang ditempatkan di class oleh sistem yang sudah ada sebelumnya.
EI Sebuah proses yang memproses data atau informasi kontrol dari luar sistem.
Service yang didefinisikan di dalam class atau legacy view.
EO Sebuah proses untuk mengirim data atau mengontrol informasi ke luar ruang lingkup sistem.
Instance Interaction Unit (IIU), Population Interaction Unit (PIU), dan Master Detail Interaction
Unit (MDIU) yang
didefinisikan di model presentasi.
EQ Sebuah proses yang memberikan informasi ke pengguna melalui penarikan data atau informasi kontrol.
Model di dalam model presentasi, memberikan informasi ke pengguna tanpa mengubah kelakukan sistem.
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)
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 sebuah class atau legacy direferensikan oleh sebuah hubungan agregasi banyak.
1 RET untuk setiap hubungan multi-valued agregasi (class atau legacy view)
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
view.
1 RET untuk legacy view.
1 DET untuk setiap atribut di IF dari class yang berhubungan dengan hubungan agregasi univalued.
1 RET untuk setiap hubungan multi-valued agregasi dengan sebuah class.
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
dari service.
1 FTR untuk class.
1 DET untuk kapasitas sistem untuk mengirim data.
1 FTR untuk setiap class baru yang direferensi dalam argumen nilai objek dari service.
1 DET untuk aksi (terima/batal) dari eksekusi service.
1 FTR untuk setiap class baru yang 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)
1 DET untuk setiap argumen nilai data dari service.
1 FTR untuk legacy view.
1 DET untuk kapasitas sistem untuk mengirim pesan.
1 FTR untuk setiap class baru direferensi dalam formula precondition.
1 DET untuk aksi (terima/batal) dari service.
1 FTR untuk setiap class baru 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
yang unik dari sebuah filter.
1 FTR untuk setiap class atau legacy view dalam tampilan.
1 DET untuk setiap atribut dalam tampilan (hanya jika atributnya berbeda dari filter).
1 FTR untuk setiap variabel nilai objek yang unik dari filter.
1 DET untuk setiap aksi yang ditawarkan (standarnya service class/legacy view).
1 FTR untuk setiap class baru direferensi dalam kriteria pengurutan.
1 DET untuk setiap navigasi yang ditawarkan.
1 FTR untuk setiap class baru 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) RET’s Data Element Type (DET’s)
1-19 20-50 51+
1 Low Low Average
2-5 Low Average High
6 or more Average High High
Tabel 2.12. Level Kompleksitas untuk EI (Alexander, 2004) FTR’s Data Element Type (DET’s)
1-4 5-15 16+
0-1 Low Low Average
2 Low Average High
3 or more Average High High
Tabel 2.13. Level Kompleksitas untuk EO dan EQ (Alexander, 2004) FTR’s Data Element Type (DET’s)
1-5 6-19 20+
0-1 Low Low Average
2-3 Low Average High
4 or more Average High High
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:
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.
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
pendapat kualitatif dari skala pembanding (Saaty, 1987) dapat dilihat pada tablel berikut.
Tabel 2.15. Nilai dan Definisi Skala Pembanding (Saaty, 1987) Intesitas
Kepentingan
Keterangan
1 Kedua elemen sama pentingnya
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 Nilai-nilai antara dua nilai pertimbangan-pertimbangan yang berdekatan.
4. 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 objek-objek 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:
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):
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-nilai kategori semua 15 pemicu biaya adalah “Nominal”, maka EAF adalah sama dengan 1.
Tabel 2.17. 15 Pemicu Biaya pada Intermediate COCOMO
No
Cost Driver Symbol
Very
Low Low Nominal High Very High Extra High 1 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
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 IF-THEN adalah: IF the speed of a car is high, IF-THEN apply less force to the accelerator.
Logika fuzzy merupakan sebuah metodologi sistem kontrol penyelesaian masalah yang cocok diimplementasikan dalam sistem, mulai
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
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) (2.8c)
