Pembangunan Perangkat LUnak Get Trip Di Platform Android

(1)

1

BAB 1 PENDAHULUAN

1.1 Latar Belakang Masalah

Saat ini liburan sudah menjadi kebutuhan semua orang, terutama bagi mereka yang tinggal di kota-kota besar. Kehidupan di kota besar memaksa setiap orang untuk bekerja keras dalam memenuhi kebutuhan dan mengejar kesuksesan. Masa liburan sangat dinantikan untuk beristirahat, berlibur bersama keluarga, atau menikmati hasil kerja keras mereka. Salah satu kegiatan yang dilakukan ketika liburan adalah travelling ke tempat-tempat yang menyenangkan.

Travelling kini sudah menjadi salah satu gaya hidup masyarakat Indonesia maupun dunia, hal ini diperkuat dengan meningkatnya jumlah wisatawan baik asing maupun domestik yang berlibur di Indonesia. Seperti dilansir dari tribunnews.com, peningkatan kunjungan wisatawan mancanegara (wisman) yang sudah mencapai 5,32 juta periode Januari-Juli 2014 atau meningkat 9,37 persen dibandingkan periode yang sama pada tahun 2013 [1].

(2)

responden berpendapat lebih mudah mendapatkan informasi traveling dari teman dan media sosial.

Selain itu sebagian besar traveller mengalami kesulitan dalam melakukan pengelolaan keuangan ketika mereka berlibur. Perencanaan biaya awal yang sudah ditetapkan seringkali tidak sesuai dengan yang diharapkan. Berdasarkan hasil survey yang dilakukan ke 103 responden, 85,3 persen responden tidak selalu mencatat pengeluaran mereka ketika berlibur, sehingga secara tidak sadar traveller tidak dapat mengontrol pengeluarannya ketika berlibur.

Dalam merekomendasikan suatu kegiatan travelling dibutuhkan beberapa kriteria dan hasil rekomendasi berdasarkan pengalaman-pengalaman traveller sebelumnya. Salah satu metode yang cocok untuk memberikan hasil rekomendasi menggunakan solusi masalah-masalah sebelumnya yang serupa yaitu metode Case Based Reasoning (CBR) [2] dan menggunakan algoritma Nearest Neighbor pada tahap retrive untuk menelusuri kasus-kasus lama yang tersimpan di basis pengetahuan. Metode tersebut akan digunakan pada penelitian ini karena dapat menghasilkan rekomendasi travelling berdasarkan pengalaman traveller sebelumnya.

Berdasarkan masalah yang telah dipaparkan, maka dapat disimpulkan perlunya membangun perangkat lunak get trip pada platform mobile. Adapun platform yang digunakan dalam membangun perangkat lunak ini adalah android dengan pertimbangan bahwa saat ini jumlah pengguna android di Indonesia mengalami pertumbuhan yang sangat pesat dengan peningkatan sebesar 150% dari tahun 2014 ke 2015 [3] dan android merupakan sistem operasi yang mendominasi peredaran smartphone di tanah air dengan pembagian pasar sebesar 59,91 persen di tahun 2014 [4] .

1.2 Perumusan Masalah

(3)

1.3 Maksud dan Tujuan

Maksud dari penelitian ini adalah membangun perangkat lunak get trip di platform android. Adapun tujuan dari penelitian ini adalah sebagai berikut:

1. Membantu traveler untuk memperoleh informasi travelling, mulai dari tempat liburan, akomodasi serta biaya yang dibutuhkan dalam satu media informasi.

2. Membantu traveller untuk mengontrol keuangan saat travelling agar tidak melebihi dari biaya yang sudah di rencanakan.

3. Membantu traveller untuk membuat perencanaan personal travelling dan menyimpan riwayat perjalan mereka yang bisa dibagikan ke sesama traveller. 4. Mengimplementasikan metode case-based reasoning untuk memberikan

rekomendasi travelling sesuai dengan biaya dan asal traveller.

1.4 Batasan Masalah

Agar dalam pembahasannya lebih terarah dan sesuai dengan tujuan yang akan dicapai maka diperlukan batasan masalah. Adapun batasan masalah dalam pelaksanaan penelitian ini adalah

1. Perangkat lunak ini dibangun di platform android dengan versi minimum android 3.0 (Honeycomb) untuk pengguna.

2. Perangkat lunak ini dibangun di platform website untuk administrator. 3. Perangkat lunak ini menggunakan database MySQL.

4. Perangkat lunak ini mengguakan konsep user-generated content (UGC). 5. Pendekatan analisis perangkat lunak menggunakan analisis berorientasi

objek.

6. Perangkat lunak ini menggunakan metode Case Based Reasoning (CBR) dan algotitma Nearest Neighbor untuk rekomendasi perencanaan travelling. 7. Perangkat lunak ini digunakan untuk travelling di Indonesia.

8. Perangkat lunak ini menggunakan 2 bahasa, yaitu Bahasa Indonesia dan Bahasa Inggris.

(4)

1.5 Metodologi Penelitian

Penelitian ini menggunakan metode penelitian deskriptif, yaitu metode penelitian yang bertujuan untuk mendapatkan gambaran yang jelas tentang hal-hal yang dibutuhkan dan berusaha menggambarkan serta menginterpretasi objek yang sesuai dengan fakta secara sistematis, faktual dan akurat. Adapun metodolgi yang digunakan dalam penelitian ini menggunakan dua metode, yaitu metode pengumpulan data dan metode pembangunan perangkat lunak.

1.5.1 Metode Pengumpulan Data

Adapun teknik pengumpulan data yang akan digunakan teridiri dari dua cara pengumpulan data, yaitu:

1. Studi Literatur

Studi literatur yang digunakan dalam penelitian ini bersumber dari buku-buku yang berkaitan dengan travelling, pemrograman mobile android dan informatika, serta didukung oleh beberapa jurnal informatika lainnya.

2. Kuesioner

Kuesioner dilakukan dengan memberikan beberapa pertanyaan kepada responden biasa dan penggemar travelling yang disebar melalui sosial media maupun personal chat ke beberapa responden.

1.5.2 Metode Pembangunan Perangkat Lunak

Metode pembangunan sistem yang dipakai untuk membangun perangkat lunak Get Trip di platform Android menggunakan metode Prototype, metode ini merupakan salah satu metode yang banyak digunakan dalam pengembangan perangkat lunak.

(5)

1. Mendengarkan Pengguna (Listen to customer)

Pada tahap ini dilakukan pengumpulan kebutuhan dari sistem dengan cara menanyakan langsung ke pengguna melalui kuesioner serta dengan membaca beberapa buku-buku tentang travelling untuk memenuhi kebutuhan yang diperlukan sistem.

2. Merancang dan Membuat Prototype (Build/revise mockup)

Pada tahap ini, dilakukan perancangan dan pembuatan prototype sistem. Prototype yang dibuat disesuaikan dengan kebutuhan sistem yang telah didefinisikan sebelumnya dari kebutuhan pengguna.

3. Uji Coba (Customer test drive mockup)

Pada tahap ini, prototype dari sistem di uji coba oleh pengguna. Kemudian dilakukan evaluasi kekurangan-kekurangan dari kebutuhan pengguna. Pengembangan kemudian kembali mendengarkan keluhan dari pelanggan atau pengguna untuk memperbaiki prototype yang ada.

Dari berbagai tahapan-tahapan tersebut, untuk lebih jelasnya bisa di lihat pada Gambar I.1 Prototype Model

(6)

1.6 Sistematika Penulisan

Sistematika penulisan tugas akhir ini disusun untuk memberikan gambaran umum tentang penelitian yang dijalankan. Sistematika penulisan tugas akhir ini adalah sebagai berikut :

BAB I PENDAHULUAN

Bab ini menguraikan tentang latar belakang permasalahan, mencoba merumuskan inti permasalahan yang dihadapi, menentukan tujuan dan kegunaan penelitian, yang kemudian diikuti dengan pembatasan masalah, asumsi, serta sistematika penulisan.

BAB II LANDASAN TEORI

Bab ini membahas berbagai konsep dasar dan teori-teori yang berkaitan dengan topik penelitian yang dilakukan. Selain itu dibahas hal-hal yang berguna dalam proses analisis permasalahan pada penelitian yang dilakukan.

BAB III ANALISIS DAN PERANCANGAN

Bab ini berisi analisis dan perancangan sistem. Tahap analisis sistem meliputi analisis masalah, analisis metode Case Based Reasonig dan analisis sistem yang akan dibangun. Sedangkan tahap perancangan sistem meliputi perancangan data, perancangan struktur menu dan perancangan antar muka yang menggambarkan rancangan yang akan dibangun.

BAB IV IMPLEMENTASI DAN PENGUJIAN

Bab ini berisi implementasi dan pengujian sistem. Tahap implementasi merupakan tahap pembangunan sistem yang sudah dianalisis dan dirancang. Kemudian dilakukan pengujian sistem untuk menguji sistem yang telah dibangun. BAB V KESIMPULAN DAN SARAN

(7)

7

BAB 2

LANDASAN TEORI

2.1 Travelling

Travelling adalah aktivitas berpindah dalam satu tempat ketempat lainnya dengan berbagai alasan, seperti bisnis, liburan, dan sebagainya. Aktivitas travelling diharapkan bukan hanya dilakukan saat libur atau waktu senggang, melainkan sudah menjadi kegiatan yang termasuk 'penting' dalam jadwal kesibukan harian, keperluannya setara dengan aktivitas kerja sehari-hari. Di dalam buku travelling karangan Herajeng Gustiayu, terdapat 3 hal dasar yang penting dari membuat perencanaan travelling dan menentukan biaya yang tepat diantaranya adalah transportasi, akomodasi, dan makanan [6].

2.2 Android

Android merupakan sistem operasi mobile yang tumbuh di tengah sistem operasi lainnya yang berkembang dewasa ini. Sistem operasi lainnya seperti Windows Mobile, i-Phone OS, Symbian dan masih banyak lagi juga menawarkan kekayaan isi dan keoptimalan berjalan di atas perangkat hardware yang ada. Akan tetapi, sistem operasi yang ada ini berjalan dengan memprioritaskan aplikasi inti yang dibangun sendiri tanpa melihat potensi yang cukup besar dari aplikasi pihak ketiga. Oleh karena itu, adanya keterbatasan distribusi aplikasi pihak ketiga untuk platform mereka [7].

(8)

2.2.1 Arsitektur Android

Arsitektur Android dapat digambarkan seperti pada Gambar 2.1 Arsitektur Android dan secara garis besar Arsitektur Android dapat dijelaskan sebagai berikut:

Gambar 2. 1 Arsitektur Android [8]

1. Application dan Widget

Application dan Widgets ini adalah layer dimana kita berhubungan dengan aplikasi saja, dimana biasanya kita download aplikasi kemudian kita lakukan instalasi dan jalankan aplikasi tersebut. Di layer terdapat aplikasi inti termasuk klien email, program SMS, kalender, peta, browser, kontak, dan lain-lain. Hampir semua aplikasi ditulis menggunakan bahasa pemrograman Java [7].

2. Application Frameworks

(9)

dimana para pembuat aplikasi melakukan pengembangan/pembuatan aplikasi yang akan dijalankan di sistem operasi Android, karena pada layer inilah aplikasi dapat dirancang dan dibuat, seperti content providers yang berupa sms dan panggilan telepon[14]. Komponen-komponen yang termasuk di dalam Application Frameworks adalah sebagai berikut:

1) Views

2) Content Provider 3) Resource Manager 4) Notification Manager 5) Activity Manager 3. Libraries

Libraries ini adalah layer dimana fitur-fitur Android berada, biasanya para pembuat aplikasi mengakses libraries untuk menjalankan aplikasinya. Berjalan di atas Kernel, layer ini meliputi berbagai library C/C++ inti seperti Libc SSL, serta:

1) Libraries media untuk pemutaran media audio dan video 2) Libraries untuk manajemen tampilan

3) Libraries Graphics mencakup SGL dan OpenGL untuk grafis 2D dan 3D 4) Libraries SQLite untuk dukungan database

5) Libraries SSL dan WebKit terintegrasi dengan web browser dan security 6) Libraries LiveWebcore mencakup modern web browser dengan engine

embedded web view

7) Libraries 3D yang mencakup implementasi OpenGL ES1.0 API’s 4. Android Run Time

Layer yang membuat aplikasi Android dapat dijalankan dimana dalam prosesnya menggunakan Implementasi Linux. Dalvik Virtual Machine (DVM) merupakan mesin yang membentuk dasar kerangka aplikasi Android. Di dalam Android Run Time dibagi menjadi dua bagian yaitu:

1) Core Libraries

(10)

sebuah libraries yang berfungsi untuk menterjemahkan bahasa Java/C yang ditangani oleh Core Libraries

2) Dalvik Virtual Machine

Virtual mesin berbasis register yang dioptimalkan untuk menjalankan fungsi-fungsi secara efisien, dimana merupakan pengembangan yang mampu membuat Linux Kernel untuk melakukan threading dan manajemen tingkat rendah.

5. Linux Kernel

Linux Kernel adalah layer dimana inti dari sistem operasi Android itu berada. Berisi file-file sistem yang mengatur sistem processing, memory, resource, drivers, dan sistem-sistem operasi Android lainnya. Linux Kernel yang digunakan Android adalah Linux Kernel release 2.6.

2.2.2 Android Life Cycle

Apikasi android terdiri dari beberapa fungsi dasar seperti mengedit catatan, memutar file musik, membunyikan alarm, atau membuka kontak telepon. Fungsi-fungsi tersebut dapat diklasifikasikan ke dalam empat komponen android yang berbeda seperti ditunjukan pada tabel, klasifikasi tersebut berdasarkan kelas-kelas dasar java yang digunakan [9].

Tabel 2. 1 Komponen Aplikasi Android

Functionality Java Base Class Example

Focused thing a user can do Activity Edit a note, play a game

Background process Service Play music, update weather icon

Receive messages BroadcastReceiver Trigger alarm upon event

(11)

Setiap aplikasi pasti menggunakan minimal satu dari komponen tersebut, akan tetapi terdapat beberapa komponen yang mengharuskan mencantumkan specified permission sebelum digunakan seperti komponen Service, BroadcastReceiver, ContentProvider [9].

Android memiliki paradigma pemrograman lain tidak seperti paradigma pemrograman biasa di mana aplikasi yang dijalankan pada fungsi main(), sistem android menjalankan kode dalam method Activity dengan menerapkan metode callback tertentu yang sesuai dengan tahap tertentu dari siklus hidup. Setiap aplikasi yang berjalan dalam sistem operasi android memiliki siklus hidup yang berbeda dengan aplikasi dekstop atau web. Hal ini dikarenakan aplikasi mobile memiliki tingkat interupsi proses yang lumayan tinggi seperti ketika handling panggilan masuk aplikasi diharuskan menghentikan proses sementara. Penerapan siklus hidup juga berguna untuk memastikan aplikasi tidak menghabiskan sumber daya baterai pengguna [10].

Gambar 2. 2 Siklus Hidup Android [10]

Terdapat beberapa state dalam siklus hidup android yang terjadi seperti diilustrasikan pada Gambar 2.2 Siklus Hidup Android, akan tetapi hanya beberapa dari state tersebut yang menjadi statis diantaranya:

1. Resumed

(12)

2. Paused

Dalam keadaan ini aktivitas yang terjadi dihentikan secara sementara tetapi masih terlihat oleh pengguna karena terdapat proses yang memiliki prioritas lebih tinggi seperti panggilan telepon. Aplikasi tidak dapat menjalankan perintah apapun ataupun menampilkan apapun dalan state ini [10].

3. Stopped

Dalam keadaan ini, aplikasi benar-benar tidak ditampilkan dan tidak terlihat oleh pengguna tetapi masih meninggalkan service di background [10].

State lain seperti Create and Started bersifat sementara dan sistem dengan cepat menjalankan state berikutnya dengan memanggil metode life cycle callback berikutnya. Artinya, setelah sistem onCreate() dipanggil, dengan cepat sistem akan memanggil method onStart(), kemudian diikuti oleh onResume() [9]

2.2.3 Fitur

Android memiliki beberapa fitur utama yang sering digunakan dalam proses pembangunan aplikasi diantaranya adalah

1. Multi-proses dan App Widget

Sistem operasi android tidak melarang prosesor menjalankan lebih dari satu aplikasi dalam satu waktu. Sistem operasi android dapat mengatur aplikasi dan thread yang berjalan secara multitasking. Keuntungan yang didapat adalah ketika aplikasi berjalan dan berinteraksi dengan pengguna di layer depan sistem operasi, proses dari aplikasi lain dapat berjalan untuk melakukan pembaruan informasi. Sebagai contoh misalnya ketika pengguna memainkan game, proses lain dapat berjalan di belakang aplikasi seperti memeriksa harga saham dan memunculkan peringatan [10].

App Widget adalah mini aplikasi yang dapat embedded dalam aplikasi seperti home screen. App widget dapat menjalankan proses request seperti musik streaming atau mendeteksi suhu ruangan secara background [10].

(13)

2. Touch Gestures dan Multi-touch

Touchscreen adalah user interface intuitif yang digunakan banyak smartphine di dunia. Dengan fitur ini interaksi dapat dibuat lebih mudah karena cukup dengan menggunakan jari tangan. Multi-touch adalah kemampuan yang digunakan untuk interaksi memperbesar atau memutar objek. Selain itu pengembang dapat membuat interaksi baru dengan memanfaatkan fitur tersebut [9].

3. Hard dan Soft Keyboard

Salah satu fitur pada perangkat smartphone adalah tombol fisik dan non fisik, tombol fisik digunakan untuk navigasi pendukung dalam pengoprasian android. Pengembang aplikasi tidak perlu secara manual untuk mengintegrasikan tombol tersebut dalam aplikasi. Tombol non fisik adalah tombol yang diuat oleh sistem operasi seperti keyboard virtual, dan tombol navigasi aplikasi [9].

2.2.4 Prinsip Desain

Andoroid memiliki beberapa prinsip desain yang dapat menjadi acuan dalam membuat desain aplikasi android diantaranya adalah

1. Multiple Assets

(14)

Gambar 2. 3 Klasifikasi Ukuran Ikon

2. Touch Feedback

Touch Feedback dalam android digunakan sebagai repon setiap objek yang ditekan pengguna. Hal ini bertujuan untuk memberi tahu pengguna objek mana yang berinteraksi dengan pengguna [11].

Gambar 2. 4 Touch Feedback

3. Pattern Gesture

Touch gesture berguna untuk meningkatkan experience pengguna dalam menggunakan aplikasi. Terdapat beberapa gesture yang didukung oleh android diantaranya adalah [11]:

1) Touch

(15)

2) Long Press

Biasanya digunakan untuk seleksi data, dengan gesture ini dimungkinkan untuk memilih satu atau lebih item dalam sebuah tampilan dan menjalankan suatu fungsionalitas tertentu [11].

3) Swipe or Drag

Swipe adalah menyentuh sebuah titik pada layar dan menggerakkan jari yang tetap tersentuh pada layar ke titik lain pada layar. Swipe dapat dilakukan dari dan ke arah mana saja [11].

4) Double Touch

Pada smartphone dan tablet android, melakukan dua kali tapping secara berturut-turut pada satu objek, fungsinya berbeda dengan double klik mouse komputer. Pada android, teknik ini biasanya dipakai untuk melakukan zoom in atau memperbesar dan zoom out atau memperkecil sebuah objek gambar [11]. 5) Pinch Open

Teknik lain yang biasa digunakan adalah dengan menggunakan dua jari, di mana kedua jari tersebut menyentuh dua titik pada layar yang terpisah di mana ujung dari dua jari terseut tidak bersentuhan, kemudian kedua jari tersebut sambil teteap menyentuh layar bergerak saling mendekati. Teknik ini digunakan untuk membuka aplikasi tertentu [11].

6) Pinch Close

Teknik Pinch Close adalah kebalikan dari Pinch Open di mana spread dilakukan dengan berawal dua jari bersentuhan pada ujungnya dan ditempelkan sebuah titik yang sama pada layar, kemudian kedua jari tersebut bergerak memisahkan atau menjauhi satu sama lain. Gerakan ini untuk menutup layar [11].

2.3 User-Generated Content

(16)

website tidak lagi dimonopoli oleh profesional media, melainkan dapat dibuat oleh para penggunanya. UGC merupakan salah satu ciri dominan Web 2.0. contoh penerapan pada UGC adalah YouTube hampir semua konten yang dimiliki situs tersebut dibuat dan diupload oleh penggunanya [12].

Konsep UGC pada dasarnya telah banyak merubah cara berinteraksi pengguna dengan internet begitu juga dalam media periklanan. Bagi media periklanan jejaring sosial dengan konsep UGC memiliki potensi besar menyediakan market yang lebih terarah dan terpusat bagi mereka [9].

2.4JSON

JSON (JavaScript Object Notation) adalah format pertukaran data yang ringan, mudah dibaca dan ditulis oleh manusia, serta mudah diterjemahkan dan dibuat (generate) oleh komputer. Format ini dibuat berdasarkan bagian dari Bahasa Pemrograman JavaScript, Standar ECMA-262 Edisi ke 3 – Desember 1999. JSON merupakan format teks yang tidak bergantung pada bahasa pemrograman apapun karena menggunakan gaya bahasa yang umum digunakan oleh programmer keluarga C termasuk C, C++, C#, JavaScript, Perl, Python dll. Oleh karena sifat-sifat tersebut, menjadikan JSON ideal sebagai bahasa pertukaran data. JSON terbuat dari dua struktur:

1. Kumpulan pasangan nama/nilai. Pada beberapa bahasa, hal ini dinyatakan sebagai objek (object), rekaman (record), daftar berkunci (keyed list), atau associative array[10].

2. Daftar nilai terurutkan (an ordered list of values). Pada kebanyakan bahasa, hal ini dinyatakan sebagai larik (array), vektor (vector), daftar (list), atau urutan (sequence) [13].

(17)

1. Objek

Objek adalah sepasang nama / nilai yang tidak terurutkan. Objek dimulai dengan { (kurung kurawal buka) dan diakhiri dengan } (kurung kurawal tutup). Setiap nama diikuti dengan : (titik dua) dan setiap pasangan nama/nilai dipisahkan oleh , (koma). Objek biasanya digunakan untuk menyimpan data tunggal dalam bentuk JSON [13].

Gambar 2. 5 Objek JSON [13]

2. Larik

Larik adalah kumpulan nilai yang terurutkan. Larik dimulai dengan [ 9kurung kotak buka) dan diakhiri dengan ] (kurung kotak tutup). Setiap nilai dipisahkan oleh , (koma). Larik dalam JSON dapat digunakan sebagai value dari JSON object hal ini dapat berguna jika JSON menyimpan data bertingkat [13].

Gambar 2. 6 Array JSON [13]

Bentuk data JSON objek dan larik dapat saling dikombinasikan untuk mendukung struktur data yang lebih kompleks. JSON mendukung beberapa tipe data untuk menjadi value seperti Angka, String, Bollean dan Nilai NULL [13].

2.5 MySQL

(18)

membuat elemen dalam database, memasukan, mengubah dan menghapus data dari database. Dengan memanfaatkan bahasa web seperti HTML, dan PHP, SQL merupakan tool penting yang tidak dapat ditinggalkan untuk pengembangan aplikasi database berbasis web. Query dasar yang sering digunakan adalah create, read, update dan delete.

Create digunakan untuk menginputkan data kesebuah tabel di database, contoh querynya sebagai berikut:

INSERT INTO anggota(nama_anggota, umur) VALUES(‘Asep’, 21)

Read digunakan untuk menampilakan data sesuai dengan ketentuan tertentu, contoh querynya sebagai berikut :

SELECT * FROM anggota

Update digunakan untuk mengubah data sesuai dengan apa yang diinginkan, contoh querynya adalah sebagai berikut:

UPDATE anggota SET umur = ‘21’ WHERE id_anggota = 1

Delete digunakan untuk menghapus data yang ingin dihilangkan, contoh querynya sebagai berikut:

DELETE FROM anggota WHERE id_anggota =5

2.6 Object Oriented Analysis Desain

(19)

2.6.1 Unified Modeling Language(UML)

Unified Modeling Language (UML) adalah termasuk ke dalam rumpun jenis pemodelan notasi grafis yang didukung oleh model-model tunggal. Pemodelan ini berguna untuk membantu dalam menjelaskan data rancang perangkat lunak yang dibangun dengan object-oriented (OO). UML merupakan standar terbuka yang dikelola Open Management Group (OMG) yang berada dibawah naungan perusahaan-perusahaan konsorium terbuka. UML merupakan suatu bahasa pemodelan yang terdiri banyak model diantaranya adalah [14]:

1. Use Case Diagram

Diagram use case merupakan pemodelan untuk menggambarkan kelakuan (behavior) sistem secara keseluran yang akan dibuat. Diagram use case mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan sistem yang akan dibuat. Dengan pengertian yang cepat, diagram use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut. Yang ditekankan pada diagram ini adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Use case menjelaskan secara sederhana fungsi sistem dari sudut pandang user. Adapun komponen-komponen dalam use case diagram anataranya [14]:

1) Actor

Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut untuk melakukan sesuatu. Bisa merupakan manusia, sistem, atau device yang memiliki peranan dalam keberhasilan operasi dari system.

2) Use Case

(20)

3) System

Menyatakan batasan sistem dalam relasi dengan actor-actor yang menggunakannya (di luar sistem) dan fitur-fitur yang harus disediakan (dalam sistem). Digambarkan dengan segi empat yang membatasi semua use case dalam sistem terhadap pihak mana sistem akan berinteraksi. Sistem disertai label yang menyebutkan nama dari sistem, tapi umumnya tidak digambarkan karena tidak terlalu memberi arti tambahan pada diagram.

4) Association

Mengidentifikasikan interaksi antara setiap actor tertentu dengan setiap use case tertentu. Digambarkan sebagai garis antara actor terhadap use case yang bersangkutan. Asosiasi bisa berarah (garis dengan anak panah) jika komunikasi satu arah, namun umumnya terjadi kedua arah (tanpa anak panah) karena selalu diperlukan demikian.

5) Dependency

Dependensi <<include>>

1. Mengidentifikasi hubungan antar dua use case di mana yang satu memanggil yang lain.

2. Jika pada beberapa use case terdapat bagian yang memiliki aktivitas yang sama maka bagian aktivitas tersebut biasanya dijadikan use case tersendiri dengan relasi dependensi setiap use case semula ke use case yang baru ini sehingga memudahkan pemeliharaan.

3. Digambarkan dengan garis putus-putus bermata panah dengan notasi <<include>> pada garis.

4. Arah mata panah sesuai dengan arah pemanggilan

Dependensi <<extend>>

1. Jika pemanggilan memerlukan adanya kondisi tertentu maka berlaku dependensi <<extend>>.

(21)

3. Note: konsep “extend” ini berbeda dengan “extend” dalam Java. 6) Generalization

Mendefinisikan relasi antara dua actor atau dua use case yang mana salah satunya meng-inherit dan menambahkan atau override sifat dari yang lainnya. Penggambaran menggunakan garis bermata panah kosong dari yang meng-inherit mengarah ke yang di-inherit.

2. Class Diagram

Class diagram merupakan diagram yang selalu ada di pemodelan system berorientasi objek. Class diagram menunjukkan hubungan antar class dalam system yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk mencapai satu tujuan. Kelas pada kelas diagram terdiri dari 3 bagian utama yaitu nama kelas, isi property dari kelas beserta metode yang ada pada kelas tersebut. Kelas juga memiliki jenis-jenis hubungan seperti asosiatif, dependensi, agregasi, komposisi, spesifikasi dan generalisasi. Hubungan ini digunakan untuk menggambarkan bagaimana hubungan dan interaksi yang terjadi antar kelas. Masing-masing komponen penyusun kelas memiliki hak akses seperti public, private dan protected [14].

3. Sequence Diagram

Sequence diagram menjelaskan secara detail urutan proses yang dilakukan dalam system untuk mencapai tujuan dari use case, interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan antar operasi dan informasi yang diperlukan oleh masing-masing operasi [14].

2.7 Sistem Rekomendasi

(22)

Sistem rekomendasi merupakan model aplikasi dari hasil observasi terhadap keadaan dan keinginan pelanggan. Oleh karena itu sistem rekomendasi memerlukan model rekomendasi yang tepat agar yang direkomendasikan sesuai dengan keinginan pelanggan, serta mempermudah pelanggan mengambil keputusan yang tepat dalam menentukan produk yang akan digunakannnya [16].

2.8 Case Base Reasoning (CBR)

Case-Based Reasoning (CBR) adalah metode penyelesaian masalah dengan menggunakan solusi masalah-masalah sebelumnya yang serupa [2]. CBR sendiri adalah metode yang umum digunakan manusia dalam menyelesaiakan masalah sehari-hari. Layaknya metode penyelesaian masalah lainnya, computer dapat meniru CBR.

Gambar 2. 7 Komponen Case Based Reasoning

(23)

Gambar 2. 8 Siklus Metode Case Based Reasoning

Dalam eksekusinya, ada empat tahapan dalam proses CBR [2]:

1. Retrieve: mengambil kasus-kasus lama dari case base yang mirip dengan kasus yang dihadapi.

2. Reuse: menggunakan solusi kasus-kasus lama hasil retrieve tersebut untuk menyelesaikan kasus yang baru tersebut.

3. Revise: jika diperlukan, mengadaptasi solusi kasus lama agar sesuai dengan kondisi masalah baru.

4. Retain: menyimpan solusi hasil revise yang telah divalidasi ke dalam basis data, agar dapat digunakan untuk menyelesaikan masalah serupa di masa depan.

(24)

2.9 Algoritma Nearest Neighbor Retrieval

Algoritma Nearest Neighbor Retrieval (k-nearest neighbor atau k-NN) sebuah algoritma untuk melakukan klasifikasi terhadap objek berdasarkan data pembelajaran yang jaraknya paling dekat dengan objek tersebut. Kasus khusus di mana klasifikasi diprediksikan berdasarkan data pembelajaran yang paling dekat (dengan kata lain, k = 1) disebut algoritma nearest neighbor [18].

Algoritma nearest neighbor berdasarkan pada proses pembelajaran menggunakan analogi / learning by analogi. Training sampelnya dideskripsikan dalam bentuk atribut numerik n-dimensi. Tiap sampel mewakili sebuah titik pada ruang n- dimensi. Dengan cara ini, semua training sampel disimpan pada pola ruang n-dimensi. Ketika diberikan “unknown” sampel, k- nearest neighbor classifier mencari pola ruang K training sampel yang paling dekat “unknown” sampel tersebut. K training sampel ini adalah k nearest neighbor dari unknown sampel. Unknown sampel ditetapkan dengan class yang paling umum diantara k nearest neighbors-nya. Ketika k = 1, unknown sampel ditetapkan dengan class dari training sampel yang paling dekat dengan pola ruangnya.

Algoritma nearest neighbor retrieval menyimpan semua training sampel dan tidak. Membangun classifier sampai sampel baru (unlabeled) perlu diklasifikasikan, sehingga algoritma nearest neighbor retrieval sering disebut dengan instance-based atau lazy learners.

Rumus untuk menghitung bobot kemiripan (similarity) dengan nearest neighbor Retrieval adalah

Similarity (problem,case) =

(1)

Keterangan:

(25)

2.10 Rank Order Centroid (ROC)

Teknik pembobotan ROC adalah teknik memberikan bobot pada setiap kriteria sesuai dengan ranking yang dinilai berdasarkan tingkat prioritas kriterianya [19]. Biasanya dibentuk dengan pernyataan “Kriteria 1 lebih penting dari kriteria 2, yang lebih penting dari kriteria 3” dan seterusnya hingga kriteria ke n, jika ditulis menjadi :

Cr1 >= Cr2 >= Cr3 … >= Crn

Untuk memberikan bobotnya, diberikan aturan yang sama yaitu : W1 >= W2 >= W3 … >= Wn,

Dimana W1 merupakan bobot untuk kriteria Cr1. Secara umum pembobotan ROC dapat dirumuskan seperti persamaan (2) sebagai berikut :

Wk = 1/k ∑ (2)

Keterangan:

Wk = Bobot atribut n k = banyaknya atribut

2.11 Jenis Liburan

Sebelum melakukan kegiatan travelling, sangat penting untuk menentukan jenis tujuan wisata. Menentukan tujuan wisata seharusnya sesuai dengan minat dan hobi. Setidaknya, ada 4 jenis tujuan wisata yang bisa dijadikan pilihan sesuai minat dan hobi [20]. Berikut ini adalah 4 jenis tujuan wisata :

a. Warisan Budaya atau Heritage

(26)

b. Lingkungan Alam

Bagi pecinta alam, tidaklah harus berpetualang di hutan atau naik gunung. Jika harus membawa keluarga atau tidak memiliki persiapan yang memadai berpetualang di alam bebas, masih bisa menikmati taman kota atau alun-alun, kebun buah, cagar alam atau kebun binatang [20].

c. Kota Besar Metropolitan

Cocok bagi yang tujuannya belanja, menikmati gemerlap malam, melihat-lihat gaya dan busana penduduk lokal dari pendatang dari berbagai negara, termasuk mempelajari tata kota dan kehidupan perkotaannya. Sistem transportasi lokal, tempat belanja, dan kehidupan malamnya sangat mudah didapat di penjuru kotanya [20].

d. Wisata Religi atau Agama

Mengunjungi tempat tempat ibadah atau tempat yang memiliki latar belakang keagamaan, baik dari sisi kegiatan atau sejarahnya. Wisata religi tidak harus ke tujuan utama ibadah, misalnya ke Arab Saudi atau ke Israel. Bisa juga ke banyak tempat yang terkait dengan sejarah penyebaran agama [20].

2.12 CodeIgniter

(27)

Gambar 2. 9 CodeIgniter [21]

Framework secara sederhana dapat diartikan kumpulan dari fungsi-fungsi/prosedur-prosedur dan class-class untuk tujuan tertentu yang sudah siap digunakan sehingga bisa lebih mempermudah dan mempercepat pekerjaan seorang programer, tanpa harus membuat fungsi atau class dari awal.

Model MVC merupakan konsep yang cukup populer dalam pembangunan aplikasi web. MVC (Model, View, Controller) itu memisahkan antara logika pembuatan kode dengan pembuatan template website/tampilan dari web. Jika kita menggunakan Model-View-Controller (MVC) menjadikan pembuatan sebuah website akan menjadi lebih terstruktur, lebih singkat atau menyingkat koding dalam pengkodingan dan lebih sederhana. Secara sederhana konsep MVC terdiri dari 3 bagian yaitu bagian pertama yaitu Model, lalu View dan yang terakhir adalah bagian Controller. Di dalam sebuah web yang dinamis paling tidak terdiri dari 3 hal utama yang menyusunya, yaitu basis data, logika aplikasi & cara menampilkan halaman web. 3 hal itu direpresentasikan menggunakan MVC yaitu: 1. Model untuk basis data biasanya berhubungan langsung ke-database untuk

memanipulasi data (insert, update, delete, search), menangani validasi dari controller, tetapi tidak controller itu tidak berhubungan langsung dengan bagian view.

(28)

request & data dari pengguna (user) kemudian menentukan apa yang akan diproses oleh aplikasi.

3. View merupakan bagian yang menangani proses presentation logic. Pada web bagian ini biasanya berupa file template HTML, yang diatur controller. Sedangkan view berfungsi sebagai penerima dan merepresentasikan data kepada pengguna (user). Nah pada bagian ini tidak memiliki hak akses langsung di bagian model.

2.13 Bootstrap

Bootstrap merupakan sebuah framework CSS dari twitter, yang menyediakan kumpulan komponen-komponen antarmuka dasar pada web yang telah dirancang sedemikian rupa untuk digunakan bersama-sama. Selain komponen antarmuka, Bootstrap juga menyediakan sarana untuk membangun layout halaman dengan mudah dan rapi, serta modifikasi pada tampilan dasar HTML untuk membuat seluruh halaman web yang dikembangkan senada dengan komponen-komponen lainnya.

Gambar 2. 10 Bootstrap [22]

(29)

2.14 Metode Pengujian

Metode pengujian adalah cara atau teknik untuk menguji perangkat lunak, mempunyai mekanisme untuk menentukan data uji yang dapat menguji perangkat lunak secara lengkap dan mempunyai kemungkinan tinggi untuk menemukan kesalahan.

Perangkat lunak dapat diuji dengan dua cara, yaitu:

1. Pengujian dengan menggunakan data uji untuk menguji semua elemen program (data internal, loop, logika, keputusan dan jalur). Data uji dibangkitkan dengan mengetahui struktur internal (kode sumber) dari perangkat lunak.

2. Pengujian dilakukan dengan mengeksekusi data uji dan mengecek apakah fungsional perangkat lunak bekerja dengan baik. Data uji dibangkitkan dari spesifikasi perangkat lunak.

2.14.1 White-Box Testing

Pengujian white box (glass box) adalah pengujian yang didasarkan pada pengecekan terhadap detil perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Penentuan kasus uji disesuaikan dengan struktur system, pengetahuan mengenai program digunakan untuk mengidentifikasikan kasus uji tambahan.

Tujuan penggunaan white box untuk menguji semua statement program. Penggunaan metode pengujian white box dilakukan untuk:

1. Memberikan jaminan bahwa semua jalur independen suatu modul digunakan minimal satu kali.

2. Menggunakan semua keputusan logis untuk semua kondisi true atau false. 3. Mengeksekusi semua perulangan pada batasan nilai dan operasional pada

setiap kondisi.

(30)

2.14.2 Black-Box Testing

Pengujian black box merupakan pendekatan komplementer dari teknik white box, karena pengujian black box diharapkan mampu mengungkap kelas kesalahan yang lebih luas dibandingkan teknik white box. Pengujian black box berfokus pada pengujian persyaratan fungsional perangkat lunak, untuk mendapatkan serangkaian kondisi input yang sesuai dengan persyaratan fungsional suatu program.

Pengujian black box adalah pengujian aspek fundamental sistem tanpa memperhatikan struktur logika internal perangkat lunak. Metode ini digunakan untuk mengetahui apakah perangkat lunak berfungsi dengan benar. Pengujian black box merupakan metode perancangan data uji yang didasarkan pada spesifikasi perangkat lunak. Data uji dibangkitkan, dieksekusi pada perangkat lunak dan kemudian keluaran dari perangkat lunak dicek apakah telah sesuai dengan yang diharapkan.

Pengujian black box berusaha menemukan kesalahan dalam kategori : 1. fungsi-fungsi yang tidak benar atau hilang

2. kesalahan interface

3. kesalahan dalam struktur data atau akses database eksternal 4. kesalahan kinerja

5. inisialisasi dan kesalahan terminasi.

Berbeda dengan pengujian white box, pengujian black box cenderung diaplikasikan selama tahap akhir pengujian. Pengujian black box harus dapat menjawab pertanyaan sebagai berikut:

1. Bagaimana validitas fungsional diuji

2. Kelas input apa yang akan membuat kasus pengujian menjadi lebih baik 3. Apakah system akan sangat sensitive terhadap harga input tertentu 4. Bagaimana batasan dari suatu data diisolasi

(31)

2.15 Skala Likert

(32)

(33)

33

BAB 3

ANALISIS DAN PERANCANGAN SISTEM

3.1 Analisis Sistem

Analisis sistem dapat didefinisikan sebagai penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponenya dengan maksud untuk mengidentifikasi dan mengevaluasi permasalahan-permasalahan, kesempatan-kesempatan, hambatan-hambatan yang terjadi dan kebutuhan-kebutuhan yang diharapakan sehingga dapat diusulkan perbaikan-perbaikanya. Di dalam tahap analisis sistem terdapat langkah-langkah yang harus dilakukan, antara lain :

1. Identify, yaitu mengidentifikasi masalah.

2. Understand, yaitu memahami kerja dari sistem yang ada. 3. Analyze, yaitu menganalisis sistem.

4. Report, yaitu membuat laporan analisis

Analisis sistem merupakan tahap untuk mempelajari interaksi sistem yang terdiri dari pelaku proses dalam sistem, prosedur, data serta informasi yang terkait. Analisis dilakukan terhadap sistem yang sedang berjalan sebagai dasar perancangan atau perbaikan sistem lama. Dalam analisis sistem dilakukan penguraian dari suatu sistem informasi yang utuh ke dalam bagian- bagian komponen dengan tujuan untuk mengindentifikasi dan mengevaluasi permasalahan- permasalahan sehingga ditentukan kelemahan-kelemahan yang diharapkan dapat diusulkan perbaikannya.

(34)

3.1.1 Analisis Masalah

Kegiatan travelling di Indonesia saat ini mulai digemari oleh banyak orang, mulai dari anak muda sampai orang tua dan dari berbagai profesi. Tujuan travelling mereka pun bervariasi, mulai dari dalam kota sampai dengan ke luar pulau di Indonesia. Namun sebagian besar masih bermasalah dalam hal perencanaan kegiatan travelling dan mengatur keuangan ketika travelling.

Membuat perencanaan yang matang sebelum melakukan kegiatan travelling sangat diperlukan untuk kelancaran kegiatan dan sesuai dengan kemampuan keuangan. Perencanaan dibutuhkan untuk membantu memaksimalkan waktu liburan untuk pergi ketempat-tempat yang ingin dikunjungi, sehingga kegiatan travelling lebih terarah dan waktu tidak terbuang untuk memikirkan destinasi selanjutnya.

Selain itu pengontrolan pengeluaran ketika kegiatan travelling berlangsung pun sangat dibutuhkan agar pengeluaran selama travelling bisa terkontrol dan bisa dievaluasi untuk kegiatan travelling berikutnya. Untuk memperoleh informasi travelling yang lengkap dan sesuai dengan keuangan masih sulit untuk dicari dan diperlukan usaha yang lebih untuk mencari dari berbagai sumber yang tersebar di internet.

3.1.2 Analisis Aturan Bisnis

Analisis aturan bisnis berisi tentang pemaparan proses bisnis perangkat lunak get trip. Adapun aturan bisnis yang ada yaitu:

1. Pengguna harus memiliki akun Get Trip untuk dapat membuat perencanaan, menyimpan pengeluaran.

2. Simpan pengeluaran dapat dilakukan bila pengguna sudah membuat perencanaan dan dapat menambah perencanaan lainnya di luar perencanaan yang suah dibuat.

(35)

4. Informasi riwayat perjalanan pengguna lainnya dapat diakses oleh pengguna tanpa harus memiliki akun Get Trip.

5. Setiap penyimpanan pengeluaran, pengguna wajib mengambil foto dan lokasi kegiatan travelling.

6. Tanggal pembuatan perencanaan minimal pada tanggal saat pembuatan perencanaan.

7. Lama waktu konfirmasi pendaftaran adalah 7 hari, setelah itu data pengguna akan dihapus.

3.1.3 Analisis Metode Case Based Reasoning (CBR)

Dalam penelitian ini telah diterapakan suatu metode untuk mengatasi ketidakpastian dengan sistem penalaran berbasis kasus (case-based reasoning). Yang menjadi basis pengetahuan pada case-based reasoning adalah fakta-fakta berupa kasus-kasus sebelumnya yang pernah ada dan serangkaian alur untuk memeriksa, menghitung, serta menyimpulkan suatu solusi dari permasalahan yang diberikan. Tahapan pada case-based reasoning ada 4 yaitu: retrieve, reuse, revise dan retain.

(36)

Gambar 3. 1 Tahapan Metode Case Based Reasonig

3.1.3.1 Retrieval

(37)

Tabel 3. 1 Data Atribut Dan Nilainya

NO. Nama Atribut Nilai Atribut

1 Budget Liburan

g. BL7 : Budget lebih dari Rp. 3.000.000

2

Asal

Keberangkatan

Liburan

Kota dari traveller ketika memulai perjalanan travellingnya

3 Jenis Liburan

(38)

Tabel 3. 2 Perhitungan Nilai Bobot Atribut

Nama Atribut (k) Tingkat Kepentingan

Dari hasil perhitungan maka di peroleh nilai-nilai bobot untuk ke empat atribut. Berikut ini adalah tabel bobot atribut.

Tabel 3. 3 Bobot Atribut

Nama Atribut Bobot Persentase (bobot x 100%)

(39)

dimana nilai 0 artinya kedua kasus tidak mirip sedangkan nilai 1 artinya kedua kasus mirip. Penelusuranan pada aplikasi ini menggunakan teknik Similarity (problem,case) pada algoritma k-nearest neighbor sebagai berikut :

Similarity (problem,case) =

Keterangan:

S1 : similarity (nilai kemiripan) budget liburan yaitu 1 (sama) dan 0 (beda) S2 : similarity (nilai kemiripan) asal keberangkatan liburan yaitu 1 (sama) dan 0

(beda)

S3 : similarity (nilai kemiripan) jenis liburan yaitu 1 (sama) dan 0 (beda) S4 : similarity (nilai kemiripan) lama liburan yaitu 1 (sama) dan 0 (beda) W1 : bobot budget liburan yaitu 0,52

W2 : bobot asal keberangkatan liburan yaitu 0,27 W3 : bobot jenis liburan yaitu 0,15

W4 : bobot lama liburan yaitu 0,06

Berikut ini contoh kasus perencanaan travelling, dimana sudah terdapat 4 buah kasus sebagai base pengetahuan dapat dilihat pada Tabel 3.4 Contoh base Pengetahuan Perencanaan Travelling, dan 1 buah kasus baru yang akan dicari kemiripannya dapat dilihat pada Tabel 3.5 Contoh Kasus baru .

Tabel 3. 4 Contoh Base Pengetahuan Perencanaan Travelling

No Id Kasus Judul Jenis

Budaya Bandung 1.200.000

4

4 4 Trip to Lombok Lingkungan

Alam Bandung 2.500.000

(40)

Tabel 3. 5 Contoh Kasus Baru

No Id Kasus Judul Jenis Liburan Asal Budget Rp

Lama

Liburan

/hari

1 X Lingkungan

Alam Bandung 2.200.000

3

1. Perhitungan Kasus 1

Tabel 3. 6 Nilai Similarity Atribut Kasus X dan 1

Id Kasus : X Similarity (X,1) Id Kasus : 1

Lingkungan Alam 1 Lingkungan Alam

Bandung 1 Bandung

BL5 : Rp. 2.200.000 0 BL1 : Rp. 500.000

HR3 : 3 Hari 0 HR2: 2 Hari

Bobot Atribut :

Budget Liburan : 0,52 Asal Keberangkatan Liburan : 0,27 Jenis Liburan : 0, 15 Lama Liburan : 0,06 Similarity (X,1) =

=

(41)

2. Perhitungan Kasus 2

Bandung 0 Jakarta

BL5 : Rp. 2.200.000 0 BL1 : Rp. 200.000

Bobot perencanaan travelling X :

=

= 0,27

3. Perhitungan kasus 3

Lingkungan Alam 1 Warisan Budaya

Bandung 1 Bandung

BL5 : Rp. 2.200.000 0 BL3 : Rp.1. 200.000

(42)

=

= 0,42

4. Perhitungan kasus 4

Bandung 1 Bandung

BL5 : Rp. 2.200.000 1 BL5 : Rp .2.500.000

=

(43)

3.1.3.2 Reuse

Dari hasil perhitungan di tahap retrive kemudian diperoleh nilai-nilai kemiripan tiap kasus yang ditunjukan pada tabel berikut ini

Tabel 3. 10 Nilai Similarity Perbandingan Kasus

Id Kasus Nilai Similarity dengan kasus baru (X)

Persentase (nilai similarity x 100%)

1 0,42 42%

2 0,27 27%

3 0,42 42%

4 0,94 94%

Nilai-nilai tersebut kemudian dibandingkan dengan jumlah nilai bobot dengan nilai bobot asal yaitu 0,79 dan nilai kemiripan yang lebih tinggi atau sama akan menjadi solusi yang akan diberikan. Dari tabel diatas nilai kemiripan yang lebih dari 0,79 ditunjukan pada id kasus 4 yaitu, Judul : trip to lombok, Asal Keberangkatan Liburan : Bandung, Jenis Liburan : Wisata Alam, Budget : Rp. 2.500.000 dan Lama Liburan : 4 hari. Selanjutnya pengguna sendiri yang menafsirkan solusi tersebut dan mengambil keputusan. Dalam hal ini proses case retrieve dikerjakan oleh komputer, namun case reasoning-nya diserahkan pada pengguna [17].

3.1.3.3 Revise

(44)

(tabel revise) yang selanjutnya akan dievaluasi dan diperbaiki kembali oleh pakar untuk menemukan solusi yang tepat.

3.1.3.4 Retain

Pada tahap ini pakar mulai menambah aturan dengan memasukkan data kasus baru yang sudah ditemukan solusinya tersebut ke dalam basis pengetahuan yang nantinya dapat digunakan untuk kasus berikutnya yang memiliki permasalahan yang sama.

3.1.4 Analisis Kebutuhan Non Fungsional

Analisis kebutuhan non-fungsional merupakan analisis yang dibutuhkan untuk dapat menentukan spesifikasi dari kebutuhan sistem. Spesifikasi ini meliputi elemen atau perangkat-perangkat yang dibutuhkan untuk sistem yang akan dibangun sampai sistem tersebut dapat diimplementasikan. Analisis kebutuhan ini juga menentukan spesifikasi masukan yang diperlukan sistem, keluaran yang akan dihasilkan sistem dan proses yang dibutuhkan untuk mengolah masukan sehingga dapat menghasilkan suatu keluaran yang diinginkan. Kebutuhan non-fungsional terbagi menjadi beberapa analisis yaitu analisis perangkat keras, analisis perangkat lunak dan analisis pengguna.

3.1.4.1 Analisis Perangkat Keras (Hardware)

Komponen perangkat keras yang digunakan untuk membuat perangkat lunak menggunkan laptop dengan spesifikasi sebagai berikut :

1. Processor Intel Core I3 – 2350M, 2.3GHz. 2. VGA Nvidia Geforce 610M

(45)

Spesifikasi perangkat keras yang disarankan untuk menjalankan perangkat lunak di platform mobile sebagai berikut :

1. Processor 830 MHz ARMv6

2. Memory Internal : Free Space 512 MB 3. Memory Eksternal : Free Space 512 MB 4. RAM 512 MB

5. Layar 3,5 in

6. OS Android 4.2 Jelly Bean

Spesifikasi perangkat keras yang disarankan untuk menjalankan perangkat lunak di platform website sebagai berikut :

1. Processor Intel Dual Core 2.3 Ghz 2. RAM 1 GB

3. Harddisk dengan free space 1 GB 4. Monitor 15 in

5. Keyboard dan Mouse

Spesifikasi perangkat keras yang digunakan untuk implementasi di platform mobile mengunakan smartphone Android, dengan spesifikasi sebagai berikut :

1. Processor Quad-core 1.2 GHz. 2. Memory Internal : 8 GB 3. RAM 1 GB.

4. Memory Eksternal : 16 GB. 5. OS Android 4.4.2 Kitkat.

6. Layar IPS LCD capacitive touchscreen, 16M colors (720 x 1280 pixel, 4.7 inches (~312 ppi pixel density)).

Spesifikasi perangkat keras yang digunakan untuk implementasi di platform website mengunakan laptop, dengan spesifikasi sebagai berikut :

(46)

3. RAM DDR3 6GB. 4. Harddisk 500GB

3.1.4.2 Analisis Perangakat Lunak (Software)

Komponen perangkat lunak yang digunakan untuk membuat aplikasi dan simulasi program adalah sebagai berikut :

1. Sistem Operasi Microsoft Windows 8.1 Profesional 64-bit. 2. Browser Google Chrome

3. Java Runtime Environment 1.8 4. Java Development Kit 1.8 5. IDE Android Studio

6. Android Development Tools (ADT) 23.0.6 7. Android SDK 4.4 (Kitkat)

8. Adobe Illustrator CS 6 9. Microsoft Visio 2010 10. Star UML 5.0.2

3.1.4.3 Analisis Pengguna

Suatu aplikasi akan berjalan dengan optimal apabila ditunjang oleh perangkat pikir yang memiliki kemampuan dalam menjalankan aplikasi yang bersangkutan. Perangkat lunak ini akan digunakan oleh 2 jenis pengguna yaitu administrator dan pengguna umum. Karakteristik pengguna yang dibutuhkan adalah sebagai berikut :

Tabel 3. 11 Karakteristik Pengguna

Pengguna Karakteristik yang dibutuhkan

Administrator 1. Mengerti dalam menggunakan komputer

2. Mengerti cara mengoperasikan perangkat lunak get trip.

(47)

2. Menguasai Bahasa Indonesia atau Bahasa Inggris.

3. Mampu melakukan kegiatan travelling.

4. Terbiasa menggunakan aplikasi-aplikasi mobile social media.

3.1.5 Analisis Kebutuhan Fungsional

Analisis sistem yang dilakukan menggunakan tools UML, adapun tahapan analisis sistem menggunakan UML meliputi use case diagram, Use Case Scenario, activity diagram, dan class diagram. Analisis kebutuhan fungsional di perangkat lunak get trip meliputi 2 platform yaitu : platform mobile android untuk antar muka ke pengguna dan platform website untuk antar muka ke administrator. Berikut ini adalah spesifikasi kebutuhan perangkat lunak fungsional dan non fungsional di platform mobile dan website perangkat lunak get trip.

Tabel 3. 12 Spesifikasi Perangkat Lunak Fungsional di Platform Mobile

Spesifikasi Kebutuhan Perangkat Lunak Fungsional di Platform Mobile

SKPL-F Keterangan

001 Sistem menyediakan Sign Up

002 Sistem menyediakan Login

003 Sistem mampu membuat perencanaan

004 Sistem mampu memperbarui data perencanaan

005 Sistem mampu menghapus data perencanaan

006 Sistem mampu membuat rekomendasi

007 _{Sistem mampu menambah data pengeluaran}

(48)

009 Sistem mampu menghapus data pengeluaran

010 Sistem mampu menambah lokasi

011 _{Sistem mampu mengambil foto melalui kamera}

012 _{Sistem mampu mengambil data lokasi melalui API Google}

013 Sistem mampu mencari data riwayat

014 Sistem mampu menampilkan data riwayat pengguna

015 Sistem mampu menampilkan profil pengguna

016 Sistem mampu menampilkan tips travelling

Tabel 3. 13 Spesifikasi Perangkat Lunak Non Fungsional di Platform Mobile

Spesifikasi Kebutuhan Perangkat Lunak Non Fungsional di Platform Mobile

SKPL-NF Keterangan

001 Sistem bisa diakses selama 24 jam tanpa berhenti

002 sistem dapat dijalankan di versi minimum android 2.2 (Froyo)

003 Sistem dapat dijalankan optimal di smartphone yang memiliki kamera

004 sistem menyediakan 2 bahasa, yaitu bahasa inggris dan bahasa indonesia

005 Sistem menyediakan 2 mata uang, yaitu IDR dan USD

006 Sistem hanya dapat digunakan oleh satu akun di satu smartphone

(49)

Tabel 3. 14 Spesifikasi Perangkat Lunak Fungsional di Platform Website

Spesifikasi Kebutuhan Perangkat Lunak Fungsional di Platform Website

017 Sistem mampu menampilkan data pengguna

018 Sistem mampu menampilkan data riwayat travelling

019 Sistem mampu membuat tips travelling

020 Sistem mampu memperbarui tips travelling

021 Sistem mampu menghapus tips travelling

Spesifikasi Kebutuhan Perangkat Lunak Non Fungsional di Platform Website

008 Sistem dapat diakses 24 jam tanpa berhenti

009 Sistem hanya dapat digunakan oleh pengguna administrator

010 Sistem mampu mengelola banyak pengguna

3.1.5.1 Analisis Kebutuhan Fungsional di Platform Mobile

Analisis kebutuhan fungsional perangkat lunak get trip di platform mobile android dilakukan menggunakan tools UML, adapun tahapan analisis sistem menggunakan UML meliputi use case diagram, Use Case Scenario, activity diagram, dan class diagram. Analisis kebutuhan perangkat lunak get trip di platform mobile android akan dijelaskan sebagai berikut :

3.1.5.1.1 Use Case Diagram

(50)

yang disepakati antara pemakai dan pengembang. Dari analisis pengguna aplikasi yang ada maka use case diagram untuk perangkat lunak get trip di platform mobile dapat dilihat pada gambar 3.2 Use Case Diagram Perangkat Lunak Get Trip di Platform Mobile Android.

Gambar 3. 2 Use Case Diagram Perangkat Lunak Get Trip di Platform Mobile Android

3.1.5.1.2 Use Case Scenario

(51)

1. Use Case Scenario Membuat Perencanaan

Use case scenario membuat perencanaan menggambarkan langkah-langkah pengguna untuk membuat perencanaan travelling. Use case scenario membuat perencanaan dapat dilihat pada Tabel 3.15 Use Case Scenario Membuat perencanaan.

Tabel 3. 15 Use Case Scenario Membuat Perencanaan

Use Case Name Membuat Perencanaan

Related

Requirements SKPL-F-01

Goal In Context Pengguna membuat perencanaan travelling Precondition Pengguna belum membuat perencanaan travelling Successful End

Condition Pengguna berhasil menyimpan data perencanaan travelling Failed End

Condition Pengguna gagal menyimpan data perencanaan travelling

Actors Pengguna

Trigger Pengguna mengetap tombol buat rencana

Main Flow Step Action

1 Pengguna mengetap tombol buat perencanaan 2 Sistem menampilkan form buat perencanaan

travelling

3 Pengguna mengisi form buat perencanaan travelling 4 Pengguna mengetap tombol selesai

5 Sistem melakukan validasi data perencanaan travelling

6 Sistem menampilkan halaman perencanaan saya Extension Step Branching Action

5.1 Sistem tidak melakukan validasi data perencanaan travelling

5.2 Data perencanaan travelling ditolak

2. Use Case Scenario Menambah Perencanaan

(52)

Tabel 3. 16 Use Case Scenario Menambah Perencanaan

Use Case Name Menambah Perencanaan

Related

Goal In Context Pengguna menambah perencanaan travelling Precondition Pengguna sudah membuat perencanaan travelling Successful End

Condition Pengguna berhasil menambah data perencanaan travelling Failed End

Condition Pengguna gagal menambah data perencanaan travelling

Actors Pengguna

Trigger Pengguna mengetap tombol buat rencana

1 Pengguna mengetap tombol tambah perencanaan 2 Sistem menampilkan form tambah perencanaan

travelling

3 Pengguna mengisi form tambah perencanaan travelling

4 Pengguna mengetap tombol selesai

5.1 Sistem tidak melakukan validasi data perencanaan travelling

5.2 Data perencanaan travelling ditolak

3. Use Case Scenario Memperbarui Perencanaan

(53)

Tabel 3. 17 Use Case Scenario Memperbarui Perencanaan

Use Case Name Memperbarui Perencanaan

Related

Goal In Context Pengguna mengubah data perencanaan travelling Precondition Menampilkan data perencanaan travelling

Successful End

Condition Pengguna berhasil mengubah data perencanaan travelling Failed End

Condition Pengguna gagal memperbarui data perencanaan travelling

Actors Pengguna

Trigger Pengguna mengetap tombol perbarui

1 Pengguna mengetap tombol perbarui

2 Sistem menampilkan form perbarui perencanaan travelling

3 Pengguna mengisi form perbarui perencanaan travelling

5 Sistem melakukan validasi data perencanaan travelling yang baru

6 Data perencanaan travelling yang baru berhasil disimpan

5.1 Sistem tidak melakukan validasi data perencanaan travelling yang baru

5.2 Data perencanaan travelling yang baru ditolak

4. Use Case Scenario Menghapus Perencanaan

(54)

Tabel 3. 18 Use Case Scenario Menghapus Perencanaan

Use Case Name Menghapus Perencanaan

Related

Goal In Context Pengguna menghapus perencanaan travelling Precondition Menampilkan data perencanaan travelling Successful End

Condition Pengguna berhasil menghapus data perencanaan travelling Failed End

Condition Pengguna gagal menghapus data perencanaan travelling

Actors Pengguna

Trigger Pengguna mengetap tombol hapus

1 Pengguna mengetap tombol hapus

2 Sistem menampilkan pesan konfirmasi penghapusan data perencanaan travelling

3 Pengguna melakukan konfirmasi penghapusan data perencanaan travelling

4 Data perencanaan travelling berhasil di hapus 5 Sistem menampilkan halaman perencanaan saya Extension Step Branching Action

3.1 Pengguna membatalkan penghapusan data perencanaan travelling

5. Use Case Scenario Mendapatkan Rekomendasi

Use case scenario mendapatkankan rekomendasi menggambarkan langkah-langkah pengguna untuk mendapatkan rekomendasi perencanaan travelling. Use case scenario mendapatkan rekomendasi dapat dilihat pada Tabel 3.19 Use Case Scenario Mendapat Rekomendasi.

Tabel 3. 19 Use Case Scenario Mendapat Rekomendasi

Use Case Name Mendapatkan Rekomendasi

Related

Goal In Context Pengguna mendapat rekomendasi perencanaan travelling Precondition Menampilkan data perencanaan travelling

Successful End

Condition Pengguna mendapat rekomendasi perencanaan travelling Failed End

(55)

Actors Pengguna

Trigger Pengguna mengetap tombol rekomendasi

1 Pengguna mengetap tombol rekomendasi

2 Sistem menampilkan data rekomendasi perencanaan travelling

3 Pengguna memilih data rekomendasi perencanaan travelling

4 Sistem menampilkan data rekomendasi yang dipilih 5 Pengguna mengetap tombol selesai

2.1 Data rekomendasi perencanaan travelling tidak ditemukan

6. Use Case Scenario Menyimpan Pengeluaran

Use case scenario menyimpan pengeluaran menggambarkan langkah-langkah pengguna untuk menambah data pengeluaran selama travelling. Use case scenario menambah pengeluaran dapat dilihat pada Tabel 3.20 Use Case Scenario Menyimpan Pengeluaran.

Tabel 3. 20 Use Case Scenario Menambah Pengeluaran

Use Case Name Menyimpan Pengeluaran

Related

Goal In Context Pengguna menambah pengeluaran travelling Precondition Pengguna sudah membuat perencanaan travelling Successful End

Condition Pengguna berhasil menambah data pengeluaran Failed End

Condition Pengguna gagal menyimpan data pengeluaran

Actors Pengguna

Trigger Pengguna mengetap tombol tambah pengeluaran

1 Pengguna mengetap tombol tambah

pengeluaran

2 Sistem menampilkan form tambah pengeluaran

3 Pengguna mengisi form tambah pengeluaran

(56)

Include::

7 Sistem melakukan validasi data tambah

pengeluaran

8 Sistem menampilkan halaman riwayat saya

Extension Step Branching Action

7.1 Sistem tidak melakukan validasi data tambah pengeluaran

7.2 Data tambah pengeluaran ditolak

7. Use Case Scenario Memperbarui Pengeluaran

Use case scenario memperbarui pengeluaran menggambarkan langkah-langkah pengguna untuk memperbarui data pengeluaran selama travelling. Use case scenario memperbarui pengeluaran dapat dilihat pada Tabel 3.21 Use Case Scenario Memperbarui Pengeluaran

Tabel 3. 21 Use Case Scenario Memperbarui Pengeluaran

Use Case Name Memperbarui Pengeluaran

Related

Goal In Context Pengguna memperbarui pengeluaran travelling Precondition Menampilkan data pengeluaran

Successful End

Condition Pengguna berhasil memperbarui data pengeluaran Failed End

Condition Pengguna gagal memperbarui data pengeluaran

Actors Pengguna

Trigger Pengguna mengetap tombol perbarui

1 Pengguna mengetap tombol perbarui

2 Sistem menampilkan form perbarui pengeluaran travelling

(57)

5 Sistem melakukan validasi data pengeluaran travelling

6 Data pengeluaran travelling yang baru berhasil disimpan

7 Sistem menampilkan halaman riwayat saya Extension Step Branching Action

5.1 Sistem tidak melakukan validasi data pengeluaran travelling yang baru

5.2 Data pengeluaran travelling yang baru ditolak

8. Use Case Scenario Menghapus Pengeluaran

Use case scenario menghapus pengeluaran menggambarkan langkah-langkah pengguna untuk menghapus data pengeluaran selama travelling. Use case scenario menghapus pengeluaran dapat dilihat pada Tabel 3.22 Use Case Scenario Menghapus Pengeluaran.

Tabel 3. 22 Use Case Scenario Menghapus Pengeluaran

Use Case Name Menghapus Pengeluaran

Related

Goal In Context Pengguna menghapus pengeluaran travelling Precondition Menampilkan data pengeluaran travelling Successful End

Condition Pengguna berhasil menghapus data pengeluaran travelling Failed End

Condition Pengguna gagal menghapus data pengeluaran travelling

Actors Pengguna

Trigger Pengguna mengetap tombol hapus

1 Pengguna menekan tombol hapus

2 Sistem menampilkan pesan konfirmasi penghapusan data pengeluaran travelling

3 Pengguna melakukan konfirmasi penghapusan data pengeluaran travelling

4 Data pengeluaran travelling berhasil di hapus 5 Sistem menampilkan halaman riwayat saya Extension Step Branching Action

(58)

9. Use Case Scenario Menambah Lokasi

Use case scenario menambah lokasi menggambarkan langkah-langkah pengguna untuk menambah data lokasi travelling. Use case scenario menambah lokasi dapat dilihat pada Tabel 3.23 Use Case Scenario Menambah Lokasi.

Tabel 3. 23 Use Case Scenario Menambah Lokasi

Use Case Name Menambah Lokasi

Related

Goal In Context Pengguna menambah lokasi travelling

Precondition Pengguna akan menambah pengeluaran travelling Successful End

Condition Pengguna berhasil menambah data lokasi Failed End

Condition Pengguna gagal menambah data lokasi

Actors Pengguna

Trigger Pengguna mengetap tombol tambah lokasi

1

Include:: Mengambil Data Lokasi

Pengguna mengetap tombol tambah lokasi