Post on 28-Mar-2019
7
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
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.
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
Fuzzy Logic + (OOmFPWeb + Metrics Web + Faktor Aplikasi Mobile)
13
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.
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 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
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) aplikasi yang
diusulkan oleh FiSMA (Forselius, 2004):
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
32
Fung
sion
al W
eb
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
Hyp
erm
edia
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
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
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)
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
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.
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
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)
Tipe Element Data File Type Referenced
40
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.
41
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)
42
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:
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
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:
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.
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
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 IF-
THEN 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) (2.8c)
Gambar 2.8. Fuzzy Membership Functions