BAB II LANDASAN TEORI - Library & Knowledge Center 2.pdf · pada sistem operasi perangkat mobile. Bahasa pemograman dan program interface-nya terpapar oleh sistem operasi mobile dari

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)


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.


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.


direferensi dalam formula dari nilai

standar.


direferensi dalam formula dari

kejadian destroy.


direferensi dalam formula

transaksi.


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)


40

1 DET untuk setiap argumen nilai data

dari service.

1 FTR untuk legacy view.


mengirim pesan.


direferensi dalam formula

precondition.

1 DET untuk aksi (terima/batal) dari

service.


direferensi dalam formula eksekusi

dari sebuah integrity constraint.

Tabel 2.9. Aturan Pengukuran untuk Instance Interaction Unit Pattern (Abrahao, Poels, & Pastor, 2006)


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.


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).


direferensi dalam kriteria pengurutan.

1 DET untuk setiap navigasi yang

ditawarkan.


direferensi dalam formula filter.


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


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


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

52

Documents

BAB II LANDASAN TEORI - Library & Knowledge Center 2.pdf · pada sistem operasi perangkat mobile. Bahasa pemograman dan program interface-nya terpapar oleh sistem operasi mobile dari