Pembangunan Perangkat LUnak Get Trip Di Platform Android

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

Namun demikian, masih banyak orang yang mengalami masalah dalam menghadapi kegiatan travelling. Dibutuhkan perencanaan yang matang dalam merencanakan perjalanan, mulai dari perencanaan destinasi, transportasi, akomodasi serta biaya yang diperlukan. Kurangnya media yang khusus untuk berbagi informasi travelling antar traveller menjadi salah satu faktor yang menghambat traveller untuk membuat perencanaan travelling mereka, karena informasi di internet sangat banyak dan tidak terfokus, informasi yang didapat pun belum tentu sesuai dengan kondisi traveller baik dari biaya dan tujuan. Bagi orang baru maupun yang sudah sering melakukan kegiatan travelling mereka membutuhkan rekomendasi kegiatan travelling yang sesuai dengan biaya dan tujuan mereka untuk membantu dalam membuat perencanaan travelling. Berdasarkan hasil survey yang sudah dilakukan ke 103 responden, 95,4 persen

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

Berdasarkan pemaparan latar belakang masalah, maka perumusan permasalahan yang terdapat pada penelitian ini adalah bagaimana cara membangun perangkat lunak get trip di platform android.

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.

9. Perangkat lunak ini menggunakan mata uang Rupiah (IDR) dan Dollar (USD) 10. Perencanaan travelling yang dibuat ini untuk 1 orang traveller.

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.

Protoype bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dievaluasi dan dimodifikasi kembali. Segala perubahan dapat terjadi pada saat prototype dibuat untuk memenuhi kebutuhan pengguna dan pada saat yang sama memungkinkan pengembang untuk lebih memahami kebutuhan pengguna secara lebih baik. Adapun tahapan dalam metode prototype sebagai berikut :

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

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

Bab ini menjelaskan tentang kesimpulan yang diperoleh dari penelitian yang telah dilaksanakan. Bagian kesimpulan menjelaskan hasil dari penelitian yang telah dilakukan dan bagian saran merupakan masukan untuk penelitian selanjutnya.

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

Android menawarkan sebuah lingkungan yang berbeda untuk pengembang. Setiap aplikasi memiliki tingkatan yang sama. Android tidak membedakan antara aplikasi inti dengan aplikasi pihak ketiga. Application Programming Interface (API) yang disediakan menawarkan akses ke hardware, maupun data-data ponsel sekalipun, atau data sistem sendiri. Bahkan pengguna dapat menghapus aplikasi inti dan menggantikannya dengan aplikasi pihak ketiga [7].

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

Android adalah “Open Development Platform” yaitu Android menawarkan kepada pengembang atau memberi kemampuan kepada pengembang untuk membangun aplikasi yang bagus dan inovatif. Pengembang bebas untuk mengakses perangkat keras, akses informasi resource, menjalankan service background, mengatur alarm, dan menambah status notifikasi, dan sebagainya. Pengembang memiliki akses penuh menuju API framework seperti yang dilakukan oleh aplikasi kategori inti. Arsitektur aplikasi dirancang supaya kita dengan mudah dapat menggunakan kembali komponen yang sudah digunakan (reuse). Sehingga bisa kita simpulkan Application Frameworks ini adalah layer

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

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

Aplikasi Android dibangun dalam bahasa Java, sementara Dalvik sebagai virtual mesinnya bukan Virtual Machine Java, sehingga diperlukan

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 Store and retrive data ContentProvider Open a phone contact

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

Resumed terjadi ketika aplikasi berjalan setelah state paused. State ini akan menjalankan perintah program yang ditulis pada method onResume() [10].

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

Multi-proses dapat memberikan manfaat berupa user experience yang lebih banyak, namun pengguna fitur tersebut dapat menghabiskan banyak energi baterai jika penggunaan tidak benar[6].

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

Android mendukung jutaan smartphone, tablet dan perangkat lain dalam berbagai ukuran layar dan ukuran, untuk itu Multiple Assets sangat disarankan digunakan untuk mengatasi fragmentasi dapa android. Seperti ilustrasi pada Gambar 2.3 Klasifikasi Ukuran Ikon, android menciptakan beberapa klasifikasi ukuran icon yaitu MDPI, HDPI, XHDPI, XXHDPI dan XXXHDPI. MDPI dan HDPI dikhususkan untuk icon yang akan digunakan pada device berukuran smartphone sedangkan untuk XHDPI, XXHDP dan XXXHDPI digunakan pada device berukuran tablet[8].

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

Touch adalah gesture default sebagai event untuk item tertentu yang paling sering digunakan dalam perangkat android, hampir seluruh kontrol utama aplikasi ini menggunakan touch.

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

User-generated Content (UGC) dikenal dengan istilah consumer-generated media (CGM) atau user-created content (UCC) adalah merujuk pada berbagai tipe konten materi atau media yang tersedia untuk umum dan diproduksi oleh end-user atau para non-media profesional. Kemajuan teknologi web memungkinkan konten

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

Struktur-struktur data ini disebut sebagai struktur data universal. Pada dasarnya, semua bahasa pemrograman modern mendukung sruktur data ini dalam bentuk yang sama maupun berlainan. Hal ini pantas disebut demikian karena format data mudah dipertukarkan dengan bahasa-bahasa pemrograman yang juga berdasarkan pada struktur data ini. JSON menggunakan bentuk sebagai berikut:

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

Structur Query Language disingkat SQL awalnya digunakan untuk mengambil atau meminta (query) informasi dari database, proses pembuatan tabel, pengguna, memasukan data, membeuat stored procedure, trigger, fungsi, pengaturan keamanan hak akses juga dapat dikerjakan SQL. SQL tidak hanya mengambil informasi dari tabel-tabel database SQL dapat digunakan dalam

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

Konsep OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan objek, yaitu analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). OOA adalah metode analisis yang memeriksa requirement (syarat/keperluan) yang harus dipenuhi sebuah sistem dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup sistem. Sedangkan OOD adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem [14].

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

Mengidentifikasi fitur kunci dari sistem. Tanpa fitur ini, sistem tidak akan memenuhi permintaan user/actor. Setiap use case mengekspresikan goal dari sistem yang harus dicapai. Diberi nama sesuai dengan goal-nya dan digambarkan dengan elips dengan nama di dalamnya. Fokus tetap pada goal bukan bagaimana mengimplementasikannya walaupun use case berimplikasi pada prosesnya nanti. Setiap use case biasanya memiliki trigger/pemicu yang menyebabkan use case.

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

2. Digambarkan serupa dengan dependensi <<include>> kecuali arah panah berlawanan.

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

Konsep sistem rekomendasi telah digunakan secara luas oleh hampir semua area bisnis dimana seorang konsumen memerlukan informasi untuk membuat suatu keputusan [15]. Sistem rekomendasi pariwisata atau perjalanan menggunakan konsep ini untuk menolong para wisatawan untuk memutuskan tujuan perjalanan mereka, akomodasi dan aktivitas di tempat tujuan.

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

Komponen penyelesaian masalah CBR memiliki dua bagian utama : case retriever dan case reasoner. Case retriever bertugas untuk mencari masalah-masalah yang mirip dengan masalah-masalah yang dimasukkan pengguna di dalam basis pengetahuan (case base), sementara case reasoner bertugas untuk mencari solusi masalah pengguna dengan melihat atau menyesuaikan solusi masalah yang ditemukan case retriever.

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.

Tidak semua bagian case retriever dan case reasoner harus diotomatis. Ada banyak program aplikasi CBR yang hanya melakukan case retriever dan memberikan hasil case retriever ke pengguna. Pengguna sendiri yang selanjutnya menafsirkan data tersebut dan mengambil keputusan. Dalam hal ini proses case retrieve dikerjakan oleh komputer, namun case reasoning-nya diserahkan pada pengguna [17].

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:

S = similarity (nilai kemiripan) W = weight (bobot yang diberikan)

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

Di tempat seperti ini akan banyak bangunan tua dengan sejarahnya masing-masing. Gaya hidup penduduk lokalnya juga masih asli dan menjunjung tinggi budaya lokal. Wilayah sekitar peninggalan sejarah dilindungi baik oleh negara maupun dun ia internasional. Pilihan makanan dan transportasinya masih banyak yang lokal. Kalau tertarik dengan sejarah atau berniat kabur dari ingar bingar kota dan kantor yang super sibuk, biasanya heritage menjadi pilihan [20].

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

CodeIgniter merupakan salah satu dari sekian banyak framework PHP yang sudah ada. CodeIgniter dikembangkan itu sendiri di kembangkan oles Rick Ellis. CodeIgniter adalah aplikasi opensource (Gratis) berupa framework dengan model MVC (Model, View, Controller) yang di fungsikan untuk membuat sebuah website dinamis bebasis PHP. CodeIgniter dirilis pertama kali pada 28-02-2006. Versi stabil yang akhir ialah V 2.1.3.

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.

2. Controller untuk logika aplikasi yang merupakan bagian pengatur dari bagian model & bagian view, controller memiliki fungsi sebagai penerima

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

3. View merupakan bagian yang menangani proses presentationlogic. 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]

Lisensi yang digunakan oleh Bootstrap yaitu lisensi Apache 2.0, sebuah lisensi yang sangat terbuka sehingga kita dapat dengan bebas dan mudah menggunakan Bootstrap, tanpa perlu khawatir akan ancaman legal dari Twitter atau pihak lainnya.

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.

4. Menggunakan struktur data internal untuk menjamin validitas jalur keputusan.

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

5. Kecepatan data apa dan volume data apa yang akan ditoleransi oleh system 6. Apa pengaruh kombinasi tertentu dari data terhadap system operasi.

2.15 Skala Likert

Skala Likert ditemukan dan dikembangkan oleh Rensis Likert pada tahun 1932 di mana skala Likert merupakan metode skala bipolar karena dapat digunakan untuk mengukur tanggapan positif ataupun negatif. Riduwan [23] menyatakan bahwa skala Likert digunakan untuk mengukur sikap, pendapat dan persepsi seseorang atau sekelompik orang tentang fenomena sosial. Pada skala Likert, variable yang akan diukur dijabarkan menjadi indikator variable. Setiap jawaban dihubungkan dengan bentuk pernyataan atau dukungan sikap yang diungkapkan dengan kata-kata misalnya untuk pernyataan positif [23].

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.

Bab ini akan menguraikan proses analisis sistem dan penerapan aplikasi sebagai sistem yang dapat membantu dalam proses merekomendasikan perencanaan travelling dengan menggunakan metode Case Based Reasoning (CBR) sebagai metode pendukung untuk menyelesaikan permasalahan pada penelitianini.

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.

3. Riwayat perjalanan pengguna dapat diperoleh bila pengguna sudah selesai menyimpan semua pengeluaran perjalannanya.

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.

Pencarian solusi kasus di lakukan pada tahapan retrieve dan reuse. Tahapan retrieve melakukan pencarian tingkat kemiripan kasus inputan perencanaan travelling yang diberikan pengguna dengan kasus-kasus yang ada pada knowledge base untuk mencari kasus yang memiliki persamaan (similaritas) tertinggi. Hanya kasus yang memiliki persamaan (similaritas) dengan basis kasus yang akan diproses di tahapan reuse untuk disarankan solusi bagi kasus baru. Tahapan revise dan retain merupakantahapan dimana solusi yang diberikan pada kasus inputan pengguna sebelumnya di revisi dan diputuskan untuk dijadikan knowledge baru atau tidak. Untuk lebih jelasnya dalam tahapan metode case based reasoning ini dapat dilihat pada gambar dibawah ini.

Gambar 3. 1 Tahapan Metode Case Based Reasonig

3.1.3.1 Retrieval

Retrieval yang digunakan dalam penelitian ini adalah menelusuri kembali kasus (riwayat perencanaan travelling) lama yang paling menyerupai/relevan dengan kasus baru. Pencocokan dilakukan dengan cara menginputkan data perencanaan travelling. Jika pencocokan nilai bobot kasus sama atau hampir sama dengan basis kasus, maka akan dilakukan tahap reuse yaitu melakukan perhitungan similarity dari bobot tiap atribut yang menghasilkan kemungkinan perencanaan travelling solusi dari kasus baru. Asumsi pada penelusuran ini adalah kasus yang mirip akan memiliki solusi yang mirip. Nilai bobot ini diberikan sebagai gambaran seberapa penting atribut tersebut dalam penentuan solusi dari kasus yang sama. Atribut yang dimiliki oleh tiap-tiap kasus adalah budget liburan, asal keberangkatan liburan, jenis liburan dan lama liburan. Nilai bobot mulai dari angka 0 sampai dengan angka 1 dimana angka 0 merupakan nilai terendah dan angka 1 merupkan nilai tertinggi. Berikut ini adalah tabel data atribut dan nilainya.

Tabel 3. 1 Data Atribut Dan Nilainya

NO. Nama Atribut Nilai Atribut

1 Budget Liburan

a. BL1 : Budget dari Rp.0 – Rp. 500.000

b. BL2 : Budget dari Rp. 500.001 – Rp. 1.000.000 c. BL3 : Budget dari Rp. 1.000.001 – Rp. 1.500.000 d. BL4 : Budget dari Rp. 1.500.001 – Rp. 2.000.000 e. BL5 : Budget dari Rp. 2.000.001 – Rp. 2.500.000 f. BL6 : Budget dari Rp. 2.500.001 – Rp. 3.000.000 g. BL7 : Budget lebih dari Rp. 3.000.000

2

Asal Keberangkatan

Liburan

Kota dari traveller ketika memulai perjalanan travellingnya

3 Jenis Liburan

a. Warisan Budaya b. Lingkungan Alam c. Kota Metropolitan d. Wisata Religi

4 Lama Liburan

a. HR1 : 1 Hari b. HR2 : 2 hari c. HR3 : 3 hari d. HR4 : 4 Hari e. HR5 : 5 hari

f. HR6 : lebih dari 5 hari

Dalam penelitian ini pembobotan budget liburan, asal keberangkatan liburan, jenis liburan dan lama liburan dihitung menggunakan metode pembobotan Rank Order Centroid (ROC) dimana pendefinisian bobot berdasarkan pada atribut yang paling berpengaruh untuk menentukan jenis rekomendasi, budget liuran >= asal liburan >= jenis liburan >= lama liburan . Berikut ini adalah perhitungan nilai bobot menggunakan metode ROC.

Tabel 3. 2 Perhitungan Nilai Bobot Atribut

Nama Atribut (k) Tingkat Kepentingan

Persamaan ROC Wk = 1/k ∑

Bobot (W)

Budget Liburan 1

W1 =

=

0,52

Asal Liburan 2

W2 =

=

0,27

Jenis Liburan 3

W3 =

=

0,15

Lama Liburan 4

W4 =

=

0,06

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

Budget

0,52 52%

Asal Liburan _0,27 27%

Jenis Liburan

0,15 15%

Lama Liburan

0,06 6%

Dalam pencarian Nearest Neighbor, kedekatan fitur-fitur kasus juga akan dihitung. Nilai kedekatan biasanya berada pada nilai 0 sampai dengan 1

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

Liburan Asal Budget Rp

Lama Liburan

/hari

1 1 Trip to pangandaran

Lingkungan

Alam Bandung 500.000

2

2 2 Trip to papandayan Lingkungan

Alam Jakarta 200.000

2

3 3 Trip to yogyakarta Warisan

Budaya Bandung 1.200.000

4

4 4 Trip to Lombok Lingkungan

Alam Bandung 2.500.000

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

=

=

=

=

0,42

2. Perhitungan Kasus 2

Tabel 3. 7 Nilai Similarity Atribut Kasus X dan 2

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

Lingkungan Alam 1 Lingkungan Alam

Bandung 0 Jakarta

BL5 : Rp. 2.200.000 0 BL1 : Rp. 200.000

HR3 : 3 Hari 0 HR2: 2 Hari

Bobot perencanaan travelling X :

Budget Liburan : 0,52 Asal Keberangkatan Liburan : 0,27 Jenis Liburan : 0, 15 Lama Liburan : 0,06

Similarity (X,2) =

=

=

=

=

0,27

3. Perhitungan kasus 3

Tabel 3. 8 Nilai Similarity Atribut Kasus X dan 3

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

Lingkungan Alam 1 Warisan Budaya

Bandung 1 Bandung

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

Bobot perencanaan travelling X :

Budget Liburan : 0,52 Asal Keberangkatan Liburan : 0,27 Jenis Liburan : 0, 15 Lama Liburan : 0,06

Similarity (X,3) =

=

=

=

=

0,42 4. Perhitungan kasus 4

Tabel 3. 9 Nilai Similarity Atribut Kasus X dan 4

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

Lingkungan Alam 1 Lingkungan Alam

Bandung 1 Bandung

BL5 : Rp. 2.200.000 1 BL5 : Rp .2.500.000

HR3 : 3 Hari 0 HR4: 4 Hari

Bobot perencanaan travelling X :

Budget Liburan : 0,52 Asal Keberangkatan Liburan : 0,27 Jenis Liburan : 0, 15 Lama Liburan : 0,06

Similarity (X,4) =

=

=

=

=

0,94

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

Pada contoh ini id kasus 4 sudah menghasilkan solusi dengan tingkat kemiripan 94%, jadi rekomendasi yang dihasilkan dapat langsung diberikan. Tetapi jika ternyata setelah dilakukan proses perhitungan dan tidak ada kasus yang mirip dengan kasus baru tersebut maka dilakukan proses revise. Informasi berupa masukan rencana pada kasus baru yang tidak ditemukan kemiripannya dengan basis pengetahuan (rule) tersebut ditampung pada suatu tabel khusus

(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

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

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 :

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

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.

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} 008 Sistem mampu memperbarui data pengeluaran

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 007 _{Sistem mampu menyimpan banyak riwayat perjalanan pengguna}

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

Use Case Diagram merupakan konstruksi untuk mendeskripsikan hubungan - hubungan yang terjadi antar actor dengan aktifitas yang terdapat pada sistem. Sasaran pemodelan use case diantaranya adalah mendefinisikan kebutuhan fungsional dan operasional sistem dengan mendefinisikan scenario penggunaan

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

Use Case Scenario menjelaskan skenario dari setiap proses bisnis yang digambarkan pada use case diagram. Berdasarkan use case diagram pada Gambar 3. 1 Use Case Diagram Perangkat Lunak Get Trip di Platform Mobile Android, maka use case scenario untuk aplikasi yang akan dibangun akan dijelaskan sebagai berikut :

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

Use case scenario menambah perencanaan menggambarkan langkah-langkah pengguna untuk menambah perencanaan travelling. Use case scenario memperbarui perencanaan dapat dilihat pada Tabel 3.16 Use Case Scenario Menambah Perencanaan.

Tabel 3. 16 Use Case Scenario Menambah Perencanaan

Use Case Name Menambah Perencanaan

Related

Requirements SKPL-F-02

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

Main Flow Step Action

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

3. Use Case Scenario Memperbarui Perencanaan

Use case scenario memperbarui perencanaan menggambarkan langkah-langkah pengguna untuk memperbarui perencanaan travelling. Use case scenario memperbarui perencanaan dapat dilihat pada Tabel 3.17 Use Case Scenario Memperbarui Perencanaan.

Tabel 3. 17 Use Case Scenario Memperbarui Perencanaan

Use Case Name Memperbarui Perencanaan

Related

Requirements SKPL-F-03

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

Main Flow Step Action

1 Pengguna mengetap tombol perbarui

2 Sistem menampilkan form perbarui perencanaan travelling

3 Pengguna mengisi form perbarui perencanaan travelling

4 Pengguna mengetap tombol selesai

5 Sistem melakukan validasi data perencanaan travelling yang baru

6 Data perencanaan travelling yang baru berhasil disimpan

7 Sistem menampilkan halaman perencanaan saya

Extension Step Branching Action

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

Use case scenario menghapus perencanaan menggambarkan langkah-langkah pengguna untuk menghapus perencanaan travelling. Use case scenario menghapus perencanaan dapat dilihat pada Tabel 3.18 Use Case Scenario Mengahapus Perencanaan.

Tabel 3. 18 Use Case Scenario Menghapus Perencanaan

Use Case Name Menghapus Perencanaan

Related

Requirements SKPL-F-04

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

Main Flow Step Action

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

Requirements SKPL-F-05

Goal In Context Pengguna mendapat rekomendasi perencanaan travelling

Precondition Menampilkan data perencanaan travelling

Successful End

Condition Pengguna mendapat rekomendasi perencanaan travelling

Failed End

Actors Pengguna

Trigger Pengguna mengetap tombol rekomendasi

Main Flow Step Action

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

6 Sistem melakukan validasi data perencanaan travelling

7 Sistem menampilkan halaman perencanaan saya

Extension Step Branching Action

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

Requirements SKPL-F-06

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

Main Flow Step Action

1 Pengguna mengetap tombol tambah pengeluaran

2 Sistem menampilkan form tambah pengeluaran 3 Pengguna mengisi form tambah pengeluaran 4 Pengguna menambahkan foto

Include:: Mengambil Foto 5 Include:: Menambah Lokasi

Pengguna menambahkan lokasi

6 Pengguna mengetap tombol selesai 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

Requirements SKPL-F-07

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

Main Flow Step Action

1 Pengguna mengetap tombol perbarui

2 Sistem menampilkan form perbarui pengeluaran travelling

3 Pengguna mengisi form perbarui pengeluaran travelling

178

Springer-Verlag, Ed. Berlin, 2010.

[18] K. R. P. P. L. T. I. Rudy Chandra, "Implementasi Case Based Reasoning pada Fitur Rekomendasi Nakamnakam.com Berbasis Android di Kota Malang," Symbol, vol. I, Jul. 2014.

[19] K. R. A. Agung Nugroho, "Sistem Pendukung Keputusan Kredit Usaha Rakyat PT. Bank Rakyat Indonesia Unit Kaliangkrik Magelang," Citec Journal, vol. 2, p. 6, Jan. 2015.

[20] F. Abdurachman. (2013, Aug.) kompas.com. [Online]. http://travel.kompas.com/read/2013/08/01/0856222/Mau.Berlibur.Kenali. Dulu.Jenis.dan.Tujuan.Wisata

[21] EllisLab. (2006) CodeIgniter. [Online]. http://www.codeigniter.com [22] c. team. (2011, Aug.) Bootstrap. [Online]. http://getbootstrap.com

[23] N. M. Asmara, "Path analysis (Analisis Lintas) Dan Generalized Structured Component Analysis (GSCA) Pada Skala Likert," Jurnal Mahasiswa Statistik, vol. II, 2014.

iii

KATA PENGANTAR

Puji Syukur penulis panjatkan kehadirat Ida Sang Hyang Widi Wasa (Tuhan Yang Maha Esa) karena atas asung kertha wara nugraha-Nya penulis dapat menyelesaikan skripsi ini dengan baik dan tepat waktu. Skripsi yang berjudul “Pembangunan Perangkat Lunak Get Trip Di Platform Android” ini diajukan sebagai salah satu syarat kelulusan Program Sarjana Teknik di Jurusan Teknik Informatika, Fakultas Ilmu dan Teknik Komputer, Universitas Komputer Indonesia.

Pada kesempatan ini, penulis ingin mengucapkan rasa terima kasih banyak kepada semua pihak yang telah memberikan bantuan baik dalam bentuk moril atau material sehingga skripsi ini dapat terselesaikan dengan baik. Secara khusus saya ingin mengucapkan terima kasih kepada :

1. Ida Sang Hyang Widi Wasa yang selalu memberikan kelancaran dalam pengerjaan skripsi ini sehingga penulis bisa menyelesaikan skripsi dengan baik.

2. Bapak, Ibu, Kakak-kakak, Adik-adik dan Ponakan-ponakan tercinta serta seluruh keluarga besar yang selalu memberikan dorongan agar penulis dapat menyelesaikan skripsi ini tepat waktu.

3. Bapak I Nengah Seroma dan Ibu Made Sumirah yang telah memberikan fasilitas dan membimbing penulis selama menempuh pendidikan strata 1 di Bandung.

4. Bapak Alif Finandhita, S.Kom., M.T. selaku dosen pembingbing yang telah banyak membantu penulis dalam menyelesaikan skripsi ini. Terima kasih karena Bapak telah banyak membantu dalam berbagai hal baik terkait bidang akademik maupun non-akademik.

5. Bapak Eko Budi Setiawan, S.Kom., M.T. selaku dosen wali dan reviewer yang telah banyak membantu dalam menyelesaikan skripsi ini. Terima kasih atas bimbingan dan motivasi Bapak selama penulis masuk dan beraktivitas di Jurusan Teknik Informatika, Universitas Komputer Indonesia.

iv

6. Teman-teman kelas IF6 angkatan 2011, terima kasih atas semua dukungan dan kerja sama yang sudah kita lakukan selama ini.

7. Teman-teman internshipIF6, terima kasih atas semua dukungan dan kerja sama yang sudah kita lakukan selama ini.

8. Teman-teman UKM Glosarium Photography, terimakasih atas dukungannya selama ini dan terima kasih atas pengalaman-pengalaman yang sangat berharga yang penulis dapatkan selama bergabung di UKM Glosarium Photography.

9. Bapak Iwan Gunawan dan keluarga yang telah memberikan dukungan dan doa selama penulis menyelesaikan tugas akhir ini.

10. Indomaret Point Dipatiukur yang membantu penulis untuk meyelesaikan tugas akhir ini.

11. Imam, Ricky Adlin, Syahir, Keng Gilang, Babeh Tita Sasmita, Keng Ariris, Doni, Haris, Unang, Dekape Delapan dan teman-teman lainnya yang tidak bisa disebutkan satu persatu yang telah memberi dukungan, doa dan membantu penulis selama menyelasikan tugas akhir ini.

12. Riky Lutfi Hamzah, Dian Gunawan, Arief Hidayat Sutomo, Reynaldi Januar Dwi Putra dan Handika, terimakasih atas kerjasamanya selama satu semester ini berjuang bersama menyelesaikan tugas akhir ini.

13. Mustika Pratama, Sulton, Fajri dan teman-teman kost kubang sari, terimakasih selama ini telah membantu penulis menyelesaikan tugas akhir ini.

Akhir kata, semoga skripsi ini dapat bermanfaat bagi para pembaca maupun penulis sendiri untuk bahan studi selanjutnya. Astungkara.

Bandung, 27 Juli 2015