TA : Rancang Bangun Aplikasi Pelayanan Pada Restoran Berbasis Mobile Android.

RANCANG BANGUN APLIKASI PELAYANAN PADA

RESTORAN BERBASIS MOBILE ANDROID

TUGAS AKHIR

Program Studi S1 Sistem Informasi

Oleh:

PUSPAYATI RAMADHANIS 08410100421

FAKULTAS TEKNOLOGI DAN INFORMATIKA

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2015

viii

Halaman

ABSTRAK ... v

KATA PENGANTAR ... vi

DAFTAR ISI ... viii

DAFTAR TABEL ... xii

DAFTAR GAMBAR ... xvi

DAFTAR LAMPIRAN ... xxii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 3

1.3 Pembatasan Masalah ... 3

1.4 Tujuan ... 4

1.5 Sistematika Penulisan ... 4

BAB II LANDASAN TEORI ... 6

2.1 Java ... 6

2.2 Android ... 7

2.3 Aplikasi Mobile ... 9

2.4 Smartphone ... 10

2.5 Tablet PC ... 10

2.6 Android SDK (Software Development Kit) ... 11

2.7 Socket ... 11

ix

2.9 Sistem Basis Data ... 14

2.10UML (Unified Modeling Language) ... 15

2.10.1Usecase Diagram ... 16

2.10.2Activity Diagram... 16

2.10.3Sequence Diagram ... 17

2.10.4Class Diagram ... 17

2.10.5Componen Diagram ... 17

2.10.6Deployment Diagram ... 18

2.10.7Statechart Diagram ... 18

2.11 System Development Life Cycle (SDLC) ... 18

2.12 Testing dan Implementasi Sistem ... 21

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 23

3.1 Analisis Sistem ... 24

3.1.1 Identifikasi permasalahan ... 25

3.1.2 Analisis Permasalahan ... 25

3.1.3 Analisis Kebutuhan Sistem ... 27

3.2 Perancangan Sistem ... 32

3.2.1 Usecase Diagram ... 32

3.2.2 Activity Diagram... 44

3.2.3 Sequence Diagram ... 50

3.2.4 Class Diagram ... 55

3.2.5 Component Diagram ... 60

3.2.6 Deployment Diagram ... 61

x

3.4.1 Desain Interface Mobile Application ... 69

3.4.2 Desain Interface Desktop Application ... 73

3.5 Desain Test Case ... 82

BAB IV IMPLEMENTASI DAN EVALUASI ... 92

4.1 Implementasi Sistem ... 92

4.2 Kebutuhan Sistem ... 92

4.2.1 Kebutuhan Perangkat keras ... 93

4.2.2 Kebutuhan Perangkat Lunak ... 94

4.3 Pembuatan Aplikasi ... 96

4.3.1 Mobile Application ... 96

4.3.2 Desktop Application Client ... 96

4.3.3 Desktop Application Server ... 96

4.4 Implementasi Sistem ... 96

4.4.1 Implementasi Mobile Application ... 98

4.4.2 Implementasi Desktop Application ... 104

4.5 Uji Coba Fungsi Aplikasi ... 115

4.5.1 Uji Coba Fungsi Aplikasi pada Pelayan ... 116

4.5.2 Uji Coba Fungsi Aplikasi pada Checker... 123

4.5.3 Uji Coba Fungsi Aplikasi pada Bag. Dapur ... 128

4.5.4 Uji Coba Fungsi Aplikasi pada Kasir ... 130

4.5.5 Uji Coba Fungsi Aplikasi pada Manajer... 133

xi

BAB V PENUTUP ... 150

5.1 Kesimpulan ... 150

5.2 Saran ... 151

DAFTAR PUSTAKA ... 152

1

BAB I PENDAHULUAN

1.1 Latar Belakang Masalah

Restoran yang tersebar di beberapa tempat membuat restoran saling bersaing untuk mendapatkan pelanggan. Untuk menjaga loyalitas pelanggan dan memenangkan persaingan, banyak strategi yang ingin dikembangkan oleh restoran. Salah satu strategi yang ingin ditingkatkan adalah mengenai pelayanan

customer.

Berdasarkan survey pada restoran Malioboro cabang Kartini Surabaya, terdapat 3 (tiga) permasalahan utama pada restoran mengenai proses pelayanan yang lamban. Yang pertama, pelayan mengalami kesulitan dalam melakukan pencarian meja kosong. Pada saat customer memasuki restoran, maka customer akan mencari meja kosong. Jika restoran sedang sepi pengunjung, maka customer bisa segera menemukan sendiri meja kosong. Bila restoran sedang ramai, customer akan meminta bantuan pelayan untuk dicarikan meja kosong. Namun pelayan mengalami kesulitan dalam melakukan pencarian meja kosong tersebut karena terdapat 42 meja dengan kapasitas ±200 pada lantai 1 (satu) dan 10 meja dengan kapasitas ±35 orang pada lantai 2 (dua). Sehingga customer menunggu mendapatkan informasi meja kosong tersebut

Permasalahan yang kedua, pelayan mencatat pesanan customer pada selembar kertas, kemudian pelayan memasukkan data pesanan tersebut pada aplikasi desktop yang tersedia dan mencetaknya sebanyak 3 (tiga) lembar. Lembar pertama diberikan kepada checker , lembar kedua diberikan kepada

bartender, lembar ketiga diletakkan pada meja customer. Rata-rata jumlah pengunjung dalam kondisi normal adalah ±100 orang dan dalam kondisi ramai ±200 orang. Dalam kondisi normal, customer mendapati proses pilih menu hingga menerima menu ± 30 menit. Pelayan akan semakin kerepotan pada saat restoran sedang ramai pengunjung, karena berkeliling dari meja customer ke meja komputer untuk merangkap pesanan, ke checker dan bartender. Hal tersebut menyebabkan proses pencatatan pemesanan menjadi lamban.

Permasalahan yang ketiga, sulitnya pelayan dalam mengingat dan mengatur booking/reservasi meja dikarenakan data reservasi yang tidak tersusun rapi. Sehingga pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan

Berdasarkan permasalahan diatas, pihak restoran membutuhkan aplikasi pelayanan restoran dengan memanfaatkan device Smart Phone Android dan dukungan aplikasi dekstop dengan menggunakan metode pengembangan System

Development Life Cycle (SDLC) model Waterfall. Untuk proses pencarian kursi

kosong, aplikasi mobile menampilkan denah meja per ruangan. Denah meja tersebut menampilkann meja dengan blok warna merah yang artinya terisi dan tanpa blok yang artinya kosong. Kemudian pelayan memilih meja yang kosong agar sistem melakukan penandaan blok warna merah pada denah. Proses selanjutnya pelayanan menampilkan list menu untuk dilakukan proses pencatatan pemesanan menu. Pelayan memilih menu-menu sesuai yang dipesan customer. List pesanan disimpan, maka secara otomatis list pesanan tersebut tampil pada aplikasi desktop checker untuk dilakukan pengontrolan pesanan menu. Checker mengganti status pesanan ”menunggu” menjadi ”proses” agar

3

pesanan tampil pada layar komputer chef dan bartender. Status ”proses” menjadi ”selesai” bila pesanan sudah selesai dibuatkan dan list pesanan tidak muncul

kembali pada layar chef dan bartender kemudian dapat dilakukan proses pembayaran oleh kasir. Penyimpanan data reservasi dilakukan oleh petugas kasir. Sistem akan menampilkan meja yang di-booking dengan blok warna ungu pada denah bila masuk pada 1 (satu) jam sebelum waktu ditentukan.

Dengan adanya aplikasi pelayanan pada restoran ini dapat membantu pihak restoran dalam hal pelayanan mulai dari menangani proses pencarian meja kosong, proses pencatatan pemesanan menu, hingga proses reservasi.

1.2 Perumusan Masalah

Berdasarkan uraian latar belakang masalah tersebut, maka perumusan masalahnya adalah bagaimana merancang dan membangun aplikasi pelayanan pada restoran yang terdiri dari:

1. Proses pencarian meja kosong. 2. Proses pemesanan menu. 3. Proses booking meja.

1.3 _{Pembatasan Masalah}

Adapun yang menjadi batasan-batasan masalah dalam perangkat lunak ini, yaitu:

1. Untuk proses booking, aplikasi ini hanya menampilkan informasi mengenai pemesan, jadwal booking dan lokasi meja yang dipesan. Serta untuk pemesan area Surabaya.

2. Jeda waktu booking pada meja yang sama adalah 3 (tiga) jam.

3. Aplikasi ini diperuntukkan pada restoran secara umum dan data yang dibutuhkan diambil dari restoran Malioboro cabang Kartini Surabaya.

4. Bahasa pemrograman yang digunakan adalah Bahasa Java.

5. Menggunakan database MySql.

1.4 Tujuan

Sesuai dengan permasalahan yang ada maka tujuan dari dibuatnya perangkat lunak ini adalah menghasilkan aplikasi pelayanan pada restoran yang terdiri dari:

1. Proses pencarian meja kosong. 2. Proses pemesanan menu. 3. Proses booking meja.

1.5 Sistematika Penulisan

Penulisan laporan Tugas Akhir ini secara sistematika diatur dan disusun dalam 5 bab, yaitu:

BAB I PENDAHULUAN

Bab ini berisikan mengenai latar belakang masalah yang diangkat pada topik Tugas Akhir, batasan masalah, tujuan yang ingin diacapai dari Tugas Akhirdan sistematika penulisan laporan Tugas Akhir.

BAB II LANDASAN TEORI

Bab ini menjelaskan mengenai teori-teori yang mendukung dalam pembuatan Tugas Akhir Rancang Bangun Aplikasi Pelayanan Restoran

5

Berbasis Mobile Android. Teori yang digunakan adalah mengenai Java, Android, Aplikasi Mobile, Smartphone, Tablet PC, Android SDK

(Software Development Kit), Sistem Pelayanan Restoran, Sistem Basis

Data, UML, System Development Life Cycle (SDLC), Testing dan Implementasi Sistem.

BAB III ANALISIS DAN PERANCANGAN SISTEM

Bab ini menjelaskan tentang tahap-tahap yang akan dilakukan dalam penyelesaian sistem terdiri dari analisis sistem (identifikasi permasalahan, analisis permasalahan, analisis kebutuhan sistem), perancangan sistem (diagram blok, arsitektur aplikasi, Use Case Diagram, Activity Diagram, Sequance Diagram, Class Diagram, Componen Diagram, Deployment Diagram, Entity Relational Diagram) Struktur Tabel dan Desain Interface.

BAB IV IMPLEMENTASI DAN EVALUASI

Bab ini menjelaskan tentang implementasi sistem, kebutuhan sistem, pembuatan aplikasi pelayanan pada restoran, implementasi sistem ,uji coba fungsi aplikasi pelayanan pada restoran untuk mencapai tujuan yang diharapkan dan evaluasi aplikasi pelayanan pada restoran.

BAB V PENUTUP

Bab ini membahas tentang kesimpulan dan saran dari hasil penelitian. Kesimpulan dan saran dalam bab ini diperoleh dari hasil evaluasi pada bab empat. Kesimpulan diperoleh dari hasil evaluasi sistem dan saran menjelaskan mengenai masukan terhadap sistem sebagai pengembangan lebih lanjut.

6 2.1 Java

Menurut Rickyanto (2003). Java adalah suatu teknologi di dunia software komputer. Selain merupakan suatu bahasa pemrograman, Java juga merupakan suatu platform. Java merupakan teknologi dimana teknologi tersebut mencakup java sebagai bahasa pemrograman yang memiliki sintaks dan aturan pemrograman sendiri. Juga mencakup java sebagai platform dimana teknologi ini memiliki virtual machine dan library yang diperlukan untuk menulis dan menjalankan program yang ditulis dengan bahasa pemrograman Java.

Java merupakan suatu teknologi yang unik dan revolusioner dan merupakan teknologi pertama di dunia software yang memiliki semboyan “write once, run anywhere”. Semboyan tersebut telah terbukti karena banyak program java dapat dijalankan diberbagai platform sistem operasi seperti Linux, Windows maupun Unix.

Adapun karakteristik Java menurut Rickyanto (2003) adalah:

a. Sederhana: Java tidak memiliki sintaks yang aneh tetapi banyak menggunakan sintaks c++ yang sudah banyak dikenal, sehingga java tidak menyulitkan bagi para programmer. Bahkan java memberikan banyak keunggulan dan kemudahan dibanding C++

b. Berorientasi objek: Java merupakan pemrograman berorientasi objek yang murni. Dalam pemrograman Java semua adalah objek, terkecuali tipe primitif

7

c. Dapat didistribusikan Dengan mudah: Sifat distribusi dari Java sangat tampak sebagai applet dan library yang mampu bekerja dalam jaringan dan bekerja dengan objek terdistribusi (RMI) dengan sangat baik.

d. Aman: Program Java memiliki library security serta policy yang membatasi akses applet di komputer client.

e. Diinterpretasi oleh interpreter: Java memerlukan virtual machine yang bertindak sebagai interpreter yang menterjemahkan bytecode (file class) menjadi bahasa mesin yang dimengerti oleh komputer host.

f. Portabel: Java dapat dijalankan diberbagai platform tanpa perubahan kode. g. Multi threading: Java memiliki banyak kemampuan untuk menangani dan

menjalankan banyak thread sekaligus.

h. Dinamis: Java merupakan teknologi yang terus berkembang dan hal ini tampak nyata sekali dengan library yang terus ditingkatkan kemampuan dan kelengkapannya.

i. Netral terhadap arsitektur hardware: Java dapat dijalankan dengan baik pada komputer yang memiliki arsitektur berbeda-beda.

j. Robust: Java merupakan teknologi yang mampu menolong programmer untuk menghasilkan program secara cepat dan handal karena Java mencegah adanya memori leaking, meniadakan pointer serta mencegah berbagai eror yang mungkin terjadi dengan adanya proses pengecekan awal pada kompilasi.

2.2 Android

Menurut Suprianto (2012), Android adalah sistem operasi bergerak (mobile operating system) yang mengadopsi sistem operasi Linux, namun telah

dimodifikasi. Android diambil alih oleh Google pada tahun 2005 dari Android, Inc.

Gambar 2.1 Arsitektur Sistem Operasi Android Secara garis besar sistem operasi Android terbagi menjadi lima tingkatan:

a. Linux kernel: Adalah kernel dasar Android. Tingkat ini berisi semua driver perangkat tingkat rendah untuk komponen hardware perangkat Android

b. Libraries: Berisi semua kode program yang menyediakan layanan-layanan utama sistem operasi Android.

c. Android Runtime: Kedudukannya setingkat dengan libraries. Android Runtime menyediakan kumpulan pustaka inti yang dapat diaktifkan oleh pengembang untuk menulis kode aplikasi Android dengan bahasa pemrograman Java.

d. Application Framework: Adalah semacam kumpulan class built-in yang tertanam dalam sistem operasi Android, sehingga pengembang dapat memanfaatkannya untuk aplikasi yang sedang dibangun.

9

e. Applications: Pada tingkat inilah kita akan bekerja. Seperti aplikasi Android pada umumnya yang dapat di-download dan di-instal dari market Android.

2.3 Aplikasi Mobile

Menurut Buyens (2001) aplikasi mobile berasal dari kata application dan mobile. Application yang artinya penerapan, lamaran, penggunaan. Secara istilah aplikasi adalah program siap pakai yang direka untuk melaksanakan suatu fungsi bagi pengguna atau aplikasi yang lain dan dapat digunakan oleh sasaran yang dituju, sedangkan mobile dapat diartikan sebagai perpindahan dari suatu tempat ke tempat yang lain.

Maka aplikasi mobile dapat diartikan sebuah program aplikasi yang dapat dijalankan atau digunakan walaupun pengguna berpindah-pindah dari satu tempat ke tempat yang lain serta mempunyai ukuran yang kecil. Aplikasi mobile ini dapat diakses melalui perangkat nirkabel, pager, PDA, telepon seluler, smartphone, dan perangkat sejenisnya. Perangkat mobile memiliki banyak jenis dalam hal ukuran, desain dan layout, tetapi memiliki karakteristik yang sangat berbeda dari sistem desktop. Berikut karakteristik perangkat mobile, diantaranya: a. Ukuran yang kecil: Perangkat mobile memiliki ukuran yang kecil. Konsumen menginginkan perangkat yang terkecil untuk kenyamanan dan mobilitas mereka.

b. Memory yang terbatas: Perangkat mobile juga memiliki memori yang kecil, yaitu primary (RAM) dan secondary (disk).

c. Daya proses yang terbatas: Sistem mobile tidaklah setangguh rekan mereka yaitu desktop.

d. Mengkonsumsi daya yang rendah: Perangkat mobile menghabiskan sedikit daya dibandingkan dengan mesin desktop

e. Kuat dan dapat diandalkan: Karena perangkat mobile selalu dibawa kemana saja, mereka harus cukup kuat untuk menghadapi benturan-benturan, gerakan, dan sesekali tetesan-tetesan air.

f. Konektivitas yang terbatas: Perangkat mobile memiliki bandwith rendah, beberapa dari mereka bahkan tidak tersambung.

2.4 Smartphone

Menurut Williams & Sawyer (2007), Smartphone adalah telepon selular dengan mikro prosesor, memori, layar dan modem bawaan. Smartphone merupakan ponsel multimedia yang menggabungkan fungsionalitas PC dan handset sehingga menghasilkan gadget yang mewah, dimana terdapat pesan teks, kamera, pemutar musik, video, game, akses email, TV digital, search engine, pengelola informasi pribadi, fitur GPS, jasa telepon internet dan bahkan terdapat telepon yang juga berfungsi sebagai kartu kredit.

2.5 Tablet PC

Komputer tablet adalah komputer yang punya layar minimal 4,8 inchi dan memiliki konektifitas Wi-Fi. Selain itu karena tab-tab punya layanan 3G.maka juga bisa dianggap sebagai sebuah smartphone. Komputer tablet android biasanya memiliki hard drive asli untuk data storage. Beberapa merek awal yang muncul contohnya adalah Dell Streak dan Galaxy Tab dengan ukuran 7 inchi dan 10 inchi (Winarno, 2012).

11

2.6 Android SDK (Software Development Kit)

Menurut Suprianto (2012) SDK Android berisi debugger, library, emulator, dokumentasi, contoh kode program dan tutorial. SDK Android adalah mesin utama untuk mengembangkan aplikasi Android. Sedangkan menurut Safaat (2012) Android SDK adalah tools API (Application Programming Interface) yang diperlukan untuk mulai mengembangkan aplikasi pada platform Android menggunakan bahasa pemrograman Java. Sebagai platform aplikasi netral, Android memberi kesempatan untuk membuat aplikasi yang dibutuhkan yang bukan merupakan aplikasi bawaan handphone/ smartphone.

Cara kerjanya adalah Android SDK memberi library yang nantinya dapat digunakan oleh pembuat aplikasi untuk membuat applikasi Android. Aplikasi tersebut dapat di-debug dengan debugger yang sudah disediakan oleh SDK. Kemudian aplikasi tersebut dijalankan dengan menggunakan emulator yang juga sudah disediakan oleh Android SDK

2.7 Socket

Menurut Kenneth (2002) Socket adalah suatu abtraksi yang mana aplikasi dapat mengirim dan menerima data seperti sama halnya dengan membuka suatu file untuk dibaca dan ditulis pada tempat penyimpanan file. Socket memungkinkan aplikasi untuk masuk kedalam jaringan dan berkomunikasi dengan aplikasi lain yang juga masuk kedalam jaringan yang sama. Informasi yang ditulis kedalam socket pada suatu aplikasi pada suatu mesin dapat dibaca oleh aplikasi lain pada mesin yang berbeda dan sebaliknya.

Berbagai jenis socket berhubungan dengan berbagai rangkaian protokol yang mendasari dan berbagai susunan protokol dalam sebuah rangkaian. Salah satunya adalah rangkaian protokol TCP/IP. Jenis utama dari socket dalam TCP/IP adalah stream socket dan datagram socket. Stream socket menggunakan TCP sebagai protokol ujung ke ujung (dengan menggunakan IP sebagai dasarnya) dan memberikan jasa byte-stream yang reliable (terpercaya). Datagram socket menggunakan UDP (sekali lagi dengan IP sebagai dasarnya) dan memberikan datagram service paling mudah yang dapat digunakan oleh aplikasi untuk mengirim pesan individu sampa dengan panjang 65.500 byte. Sebuah TCP/IP socket diidentifikasi secara unik dengan Internet Address (alamat internet / IP), protokol ujung ke ujung (TCP/UDP) dan sebuah nomor port. Gambar 2.2 mengambarkan hubungan logika antara aplikasi, abstraksi socket protokol dan nomor port dalam sebuah host

Gambar 2.2 Socket, Protocol dan Port

2.8 Sistem Pelayanan Restoran

Menurut Marsum (2005), Restoran adalah suatu tempat atau bangunan yang diorganisasi secara komersial yang menyelenggarakan pelayanan yang baik kepada semua tamunya baik berupa makan maupun minum.

13

Tujuan operasi restoran adalah untuk mencari untung. Selain bertujuan bisnis atau mencari untung, membuat puas para tamu pun merupakan tujuan operasi restoran yang utama. Urutan-urutan kerja di restoran waktu buka/ operasi adalah:

a. Menyambut dan mengucapkan salam: Memberi ucapan salam kepada tamu atau lebih lazim disebut greeting’s kepada tamu waktu masuk restoran.

b. Mendudukkan tamu: Tamu kita antarkan ke tempat duduk. Penerima tamu harus tahu pasti dimana atau meja-meja nomor berapa yang masih kosong atau belum dipesan tamu dan berapa kapasitas masing-masing.

c. Memberikan daftar minuman (waktu makan siang atau malam): Yang dimaksud daftar minuman disini ialah minuman yang diminum tamu sebelum memulai makan dengan tujuan untuk membangkitkan nafsu makan.

d. Memberi daftar makanan: Penerima tamu juga dituntut untuk memahami benar-benar makanan/produk yang dijual sehingga dapat menyarankan kepada tamu dengan baik dan penjualan dapat meningkat.

e. Menuangkan air es: Untuk memberikan kesempatan kepada tamu untuk mempelajari daftar makanan atau menu yang telah diberikan, Waiter lalu menuangkan air es ke gelas tamu.

f. Mengambil pesanan tamu: Dalam restoran kecil, pesanan tamu diambil-dicatat dengan atau dalam memo, kemudian dipindahkan ke sebuah check/bill. Di dalam restoran yang lebih besar, pesanan diambil dan ditulis di atas sebuah Kitchen Order Tiket (KOT), dibuat rangkap sejumlah system control restoran itu.

g. Menuliskan pesanan tamu: Kadang-kadang ada restoran yang memakai sistem lain dalam menuliskan order/pesanan tamu. Ada juga yang pesanan tamu langsung disalin dari memo kedalam cek/ bill oleh captain. Cek sudah carbonized, dibuat rangkap tiga atau empat.

h. Periksalah kebersihan dan kondisi piring: Yang cacat, retak atau gempil harus disingkirkan. Sedangkan yang kurang bersih/flek dikembalikan lagi tempat pencucian piring.

i. Periksa makanan pesanan tamu: Setiap pesanan tamu yang kita terima dari dapur, sebelum masuk restoran perlu diperiksa terlebih dahulu.

j. Periksalah makanan penghias (Garnir): Setiap makanan yang dipesan tamu pasti diberi makanan penghias, pelengkap dan penyerta/ garner.

k. Menghidangkan makanan pada tamu: Untuk menghidangkan makanan pada tamu lazimdipergunakan bagi persegi panjang.

l. Memberikan bill/cek: Bill atau cek dapat diberikan kepada tamu beberapa saat setelah tamu selesai makan makanan penutup serta meminum teh/kopinya. Atau kadang-kadang kita tunggu sesaat sampai tamu meminta billnya.

2.9 Sistem Basis Data

Menurut Marlinda (2004:1), sistem basis data adalah suatu sistem menyusun dan mengelola record-record menggunakan komputer untuk menyimpan atau merekam serta memelihara operasional lengkap sebuah organisasi/perusahaan sehingga mampu menyediakan informasi optimal yang diperlukan pemakai untuk proses mengambil keputusan.

15

2.10 UML (Unified Modeling Language)

Menurut Fowler (2005). Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun pemrograman berorientasi objek (OO)

Menurut Rosa (2011) pada perkembangan teknik pemrograman berorientasi objek, muncullah sebuah standarisasi bahasa pemodelan untuk membangun perangkat lunak yang dibangun dengan menggunakan teknik pemrograman berorientasi objek yaitu Unified Modeling Language (UML). UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun dan dokumentasi dari sistem perangkat lunak. UML merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram dan teks-teks pendukung.

Pada gambar UML terdiri dari 13 macam diagram dikelompokkan dalam 3 kategori. Pembagian kategori dan macam-macam diagram tersebut dapat dilihat pada gambar 2.3.

UML 2.3 Diagram

Structure Diagram _DiagramsBehavior Intraction Diagram Class Diagram

Object Diagram Component

Diagram Composite Structure Diagram Package Diagram

Deployment Diagram

Usecase Diagram Activity Diagram

State Machine Diagram

Sequence Diagram Communication

Diagram Timing Diagram

Interaction Diagram

Berikut ini penjelasan singkat dari pembagian kategori tersebut.

a. Structur diagram yaitu kumpulan diagram yang digunakan untuk menggambarkan suatu struktur statis dari sistem yang dimodelkan

b. Behavior Diagram yaitu kumpulan diagram yang digunakan untuk menggambarkan kelakuan sistem atau rangkaian perubahan yang terjadi pada sistem

c. Interaction diagram yaitu kumpulan diagram yang digunakan untuk menggambarkan interaksi sistem dengan sistem lain maupun interaksi antar subsistem pada suatu sistem

Dalam pembuatan Tugas Akhir ini, menggunakan beberapa jenis diagram yaitu: use Case Diagram, Activity Diagram, Sequance Diagram, Class Diagram, Componen Diagram, Deployment Diagram dan Statechard Diagram

2.10.1 Usecase Diagram

Usecase diagram menyajikan interaksi antar usecase dan actor. Dimana actor dapat berupa orang, peralatan atau sistem lain yang berinteraksi dengan sistem yang sedang dibagun. Usecase menggambarkan fungsionalitas sistem atau persyaratan-persyaratan yang harus dipenuhi sistem dari pandangan pemakai. Sholiq (2006),

2.10.2 Activity Diagram

Menggambarkan aliran fungsionalitas sistem. Pada tahap pemodelan bisnis,diagram aktivitas dapat digunakan untuk menunjukkan aliran kerja bisnis

17

(business work flow). Dapat juga digunakan untuk menggambarkan aliran kejadian (flow of event) dalam use case. Sholiq (2006).

2.10.3.Sequance Diagram

Digunakan untuk menunjukkan aliran fungsionalitas dalam use case yang disusun berdasarkan urutan waktu. Alur pembacaan diagram ini adalah dari atas ke bawah.Diagram ini dapat dibaca dengan memperhatikan objek-objek dan pesan-pesan yang ada pada diagram. Sholiq (2006).

2.10.4.Class Diagram

Menunjukkan interaksi anatar kelas dalam sistem. Kelas mengandung informasi dan tingkah laku (behavior) yang berkaitan dengan informasi tersebut. Sebuah kelas pada diagram kelas dibuat untuk setiap tipe obyek pada diagram sequensial atau diagram kolaborasi. Sholiq (2006).

2.10.5.Componen Diagram

Menunjukkan model secara fisik komponen perangkat lunak pada sistem dan hubungannya antar mereka. Diagram komponen digunakan oleh siapapun yang bertanggung jawab untuk melakukankompilasi sistem. Diagram ini juga menunjukkan komponen apa yang dibutuhkan saat proses kompilasi dan menampilkan komponen run-time apa saja yang dibuat sebagai hasil dari proses kompilasi. Sholiq (2006).

2.10.6.Deployment Diagram

Menampilkan rancangan fisik jaringan dimana berbagai komponen akan terdapat disana. Diagram deployment digunakan oleh manajer proyek, arsitek sistem dan karyawan distribusi untuk memahami rancangan fisik sistem dan dimana saja terdapat subsistem yang akan dibuat. Diagram ini membantu manajer proyek mengkomunikasikan tentang apa yang sistem inginkan terhadap pemakai, juga membantu bagian pengembangan untuk merencanakan distribusi yang akan ditawarkan. Sholiq (2006).

2.10.7.Statechart Diagram

Diagram Statechart diagram atau Statechart diagram menyediakan sebuah cara untuk memodelkan bermacam-macam keadaan yang mungkin dialami oleh sebuah objek. Jika dalam diagram kelas menunjukkan gambaran statis kelas-kelas dan relasinya,diagram statechart digunakan untuk memodelkan tingkah laku dinamik sistem. Sholiq (2006).

2.11 Sytem Development Life Cycle (SDLC)

System Development Life Cycle (SDLC) adalah pendekatan bertahap untuk melakukan analisa dan membangun rancangan sistem dengan menggunakan siklus yang spesifik terhadap kegiatan pengguna. Pengembangan sistem informasi dapat dilakukan dengan berbagai metode. Proses pengembangan sistem yang dimulai dari tahap perencanaan sampai implementasinya disebut dengan istilah System Development Life Cycle (SDLC). Tahapan-tahapan SDLC menurut Kendall (2003) adalah sebagai berikut:

19

a. Mengidentifikasi masalah, peluang dan tujuan.

Menentukan permasalahan-permasalahan apa yang terjadi dan apa yang menyebabkan sasaran pada sistem lama belum tercapai. Kemudian mengidentifikasi peluang pengembangan sistem termasuk fisibilitas secara teknis, ekonomis dan operasional bahwa peningkatan dapat dilakukan melalui penggunaan sistem informasi terkomputerisasi, selanjutnya pada tahap ini juga dilakukan identifikasi tujuan dari pengembangan sistem informasi.

b. Menentukan kebutuhan informasi

Memahami informasi apa yang dibutuhkan pemakai agar bisa ditampilkan dalam pekerjaan. Serta mengetahui detil fungsi-fungsi dalam sistem termasuk mengetahui siapa saja yang terlibat, kegiatan apa saja yang ada, lingkungan kerja yang mana, waktu yang diperlukan serta bagaimana mekanisme atau prosedur yang berlaku.

c. Menganalisis kebutuhan sistem.

Dilakukan penguraian suatu sistem informasi yang utuh ke dalam komponen-komponennya untuk mengidentifikasi dan mengevaluasi permasalahan-permasalahan, peluang-peluang, maupun hambatan-hambatan yang terjadi dan kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya.

d. Merancang sistem yang direkomendasikan.

Memberikan gambaran yang jelas dari rancang bangun yang lengkap. Terdapat dua bagian dalam perancangan sistem, yaitu rancangan sistem secara umum atau desain makro dan rancangan sistem secara terinci atau rancangan fisik. Kegiatan yang dilakukan dalam tahap ini meliputi:

1. Desain model dari sistem informasi yang akan dikembangkan.

2. Desain output adalah keluaran dari sistem informasi yang dapat dilihat, dapat berupa tampilan dilayar, kertas laporan dan sebagainya.

3. Desain input yang perlu didesain secara rinci dari input adalah bentuk dari dokumen dasar yang digunakan dan bentuk tampilan dari input di alat input.

4. Desain basis data ini adalah mengintegrasikan kumpulan dari data yang saling berhubungan antara satu dengan lainnya dan membuatnya tersedia untuk aplikasi yang bermacam-macam di dalam suatu organisasi, yang terdiri dari beberapa file yang diperlukan dalam suatu proses pengolahan data.

5. Desain tehnologi digunakan untuk menerima input, menjalankan model, menyimpan dan mengakses data, menghasilkan dan mengirimkan keluaran dan membantu pengendalian sistem secara keseluruhan. Tehnologi ini perlu dirancang untuk menyesuaikan dengan sistem informasi yang akan digunakan dengan memperhatikan tiga hal pokok, yaitu perangkat keras, perangkat lunak dan teknisi.

e. Mengembangkan dan mendokumentasikan perangkat lunak.

Tahap ini dilakukan untuk mengembangkan suatu perangkat lunak yang diperlukan, dalam kegiatannya diperlukan kerjasama antara penganalisis dan pemrograman.

f. Menguji dan mempertahankan sistem.

Sebelum sistem informasi dapat digunakan, maka harus dilakukan pengujian terlebih dahulu.

21

g. Mengimplementasikan dan mengevaluasi sistem.

Implementasi sistem dilakukan setelah rancangan selesai dan melakukan evaluasi untuk revisi dengan segera terhadap sistem untuk memastikan kesesuaian dengan kebutuhan. Evaluasi diharapkan bahwa sistem baru lebih efisien operasionalnya dan efektif dalam pencapaian tujuan dan lebih mudah digunakan.

2.12 Testing dan Implementasi Sistem

Menurut Romeo (2003:3), Testing software adalah proses mengoperasikan software dalam suatu kondisi yang dikendalikan untuk:

a. Verifikasi. Apakah telah berlaku sebagaimana yang ditetapkan (menurut spesifikasi)?

b. Mendeteksi error.

c. Validasi. Apakah spesifikasi yang ditetapkan telah memenuhi keinginan atau kebutuhan pengguna yang sebenarnya?

Menurut Romeo (2003:33), Test Case merupakan tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya.

a. White Box Testing

White box testing atau glass box testing atau clear box testing adalah suatu metode disain test case yang menggunakan struktur kendali dari disain prosedural. Metode disain test case ini dapat menjamin:

2. Semua logika keputusan dapat dites dengan jalur yang salah atau jalur yang benar.

3. Semua loop dapat dites terhadap batasannya dan ikatan operasionalnya. 4. Semua struktur internal data dapat dites untuk memastikan validasinya.

b. Black Box Testing

Black box testing atau behavioral testing atau specification-based testing, input/output testing atau functional testing dilakukan tanpa sepengetahuan detil struktur internal dari sistem atau komponen yang dites. Black box testing berfokus pada kebutuhan fungsional pada software, berdasarkan spesifikasi kebutuhan dari software.

Menggunakan black box testing, perekayasa software dapat menggunakan sekumpulan kondisi masukan yang dapat secara penuh memeriksa keseluruhan kebutuhan funsional pada suatu program. Kategori error dapat diketahui melalui black box testing, antara lain:

1. Fungsi yang hilang atau tidak benar. 2. Error dari antar-muka.

3. Error dari struktur data atau akses eksternal database. 4. Error dari kinerja atau tingkah laku.

23 BAB III

ANALISIS DAN PERANCANGAN SISTEM

Pada tahap ini dilakukan analisis dan perancangan sistem. Menurut pressman (2001), model waterfall adalah model klasik yang besifat sistematis, berurutan dalam membangun software. Disebut dengan Waterfall karena tahap demi tahap yang harus dilalui harus menuggu selesainya tahap sebelumnya dan berjalan berurutan. Terdiri dari tahap analisis, desain, pengkodean dan pengujian.

Tahap analisis yaitu proses pengumpulan kebutuhan khususnya pada perangkat lunak. Pada tahap analisis menjelaskan tahap analisis sistem yang didalamnya terdiri dari identifikasi permasalahan, analisis permasalahan dan analisis kebutuhan sistem.

Tahap desain digunakan untuk mengubah kebutuhan-kebutuhan analisis menjadi representasi ke dalam bentuk “blueprint” perangkat lunak. Pada tahap ini, terdiri dari desain model sistem, desain basis data, desain input output.

Pengkodean yaitu untuk dapat dimengerti oleh mesin (computer), maka desain harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin yaitu ke dalam bahasa pemrograman melalui proses coding.

Pengujian dilakukan untuk memastikan semua pernyataan sudah diuji, serta menemukan kesalahan-kesalahan dan memastikan inputan dapat memberikan hasil yang sesuai dengan yang dibutuhkan. Untuk lebih jelasnya dapat dilihat pada gambar 3.1.

Output Output Analisis

Identiifkasi masalah

Analisis permasalahan

3 permasalahan restoran

Usulan aplikasi untuk restoran

Analisis kebutuhan sIstem Spesifikasi kebutuhan perangkat lunak

Desain

Desain model sistem

Desain basis data

Blok diagram aplikasi pelayanan restoran Usecase Diagram Activity Diagram Sequence Diagram Class Diagram Component Diagram Deployment Diagram State Diagram

Desain input output

Physical Data Model (PDM)

Struktur Tabel

Desain Interface

Pengkodean

Aplikasi pelayanan pada restoran

Pengujian

Uji coba fungsi aplikasi Test Case Evaluasi aplikasi Quesioner

Output

Output

Gambar 3.1 Tahap Pengembangan Rancang Bangun Aplikasi Pelayanan pada Restoran

3.1 Analisis Sistem

Analisis sistem untuk aplikasi pelayanan restoran pada restoran meliputi identifikasi permasalahan, analisis permasalahan dan analisis kebutuhan sistem.

25

3.1.1 Identifikasi Permasalahan

Proses pelayanan yang terjadi saat ini yaitu pelayan mencarikan kursi kosong dengan menengok langsung meja mana yang masih kosong, apabila meja yang berada di lantai 1 (satu) tidak tersedia, maka pelayan berjalan menengok meja yang ada di lantai 2 (dua) pada restoran. Sehingga pelayan mengalami kesulitan dalam pencarian kursi.

Permasalahan yang kedua, pelayan mencatat pesanan customer pada selembar kertas, kemudian pelayan memasukkan data pesanan tersebut pada aplikasi desktop yang tersedia dan mencetaknya sebanyak 3 (tiga) lembar. Lembar pertama diberikan kepada checker , lembar kedua diberikan kepada bartender, lembar ketiga diletakkan pada meja customer. Rata-rata jumlah pengunjung dalam kondisi normal adalah ±100 orang dan dalam kondisi ramai ±200 orang. Dalam kondisi normal, customer mendapati proses pilih menu hingga menerima menu ± 30 menit. Pelayan akan semakin kerepotan pada saat restoran sedang ramai pengunjung, karena berkeliling dari meja customer ke meja komputer untuk merangkap pesanan, ke checker dan bartender.

Sulitnya pelayan dalam mengingat dan mengatur booking/reservasi meja dikarenakan data reservasi yang tidak tersusun rapi. Sehingga pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan.

3.1.2 Analisis Permasalahan

Terdapat beberapa permasalahan yang didapatkan dari proses pelayanan pada restoran, diantaranya adalah:

1. Pelayan masih harus menengok langsung atau menyisiri ruangan restoran untuk dapat menemukan meja kosong yang sesuai baik yang ada di lantai 1 (satu) maupun lantai 2 (dua) pada resroran tersebut. Sehingga customer harus menunggu hingga pelayan menemukan meja kosong yang sesuai.

2. Pelayan masih menulis pesanan pada selembar kertas. Kemudian menginputkan menu pesanan pada aplikasi desktop untuk dirangkapkan 3 (tiga) lembar menu pesanan. Lembar pertama diberikan kepada checker , lembar kedua diberikan kepada bartender, lembar ketiga diletakkan pada meja customer. Pelayan harus benar-benar mengingat menu mana yang pada hari itu sedang kosong. Sehingga pelayan kesulitan dalam melakukan estimasi waktu pelayanan karena masih berkeliling kesana kemari.

3. Pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan. Dengan cara mengingat kembali lembaran jadwal booking/pesanan yang tertempel pada meja kasir.

Setelah dilakukan identifikasi permasalahan, maka diperoleh gambaran mengenai hal-hal yang dapat membantu menyelesaikan permasalahan yang terjadi. Diantaranya adalah:

1. Membuat aplikasi yang dapat menampilkan denah meja kosong maupun terisi. Sehingga pelayan tidak perlu menyisiri ruangan baik yang ada di lantai 1 (satu) maupun lantai 2 (dua) pada restoran.

2. Membuat aplikasi yang dapat menampilkan menu pesanan, yang pada saat itu tersedia, menampilkan informasi stok menu yang habis, dan total harga pesanan.

27

3. Membuat aplikasi yang dapat mencatat menu pesanan yang dapat terintegrasi ke bagian checker, dan kasir.

4. Membuat aplikasi yang dapat menampilkan menu pesanan pada bartender dan chef yang dikontrol oleh checker.

5. Membuat aplikasi yang dapat menangani proses pembayaran berdasarkan nomor meja.

6. Membuat aplikasi yang dapat menangani proses penjadwalan booking/pemesanan meja. Sehingga pelayan segera mengetahui meja yang sedang di-booking.

7. Membuat aplikasi yang dapat memberikan informasi berupa laporan penjualan, laporan menu favorit, dan laporan utility meja berdasarkan harian maupun bulanan.

3.1.3 Analisis Kebutuhan Sistem

Berdasarkan permasalahan diatas maka dibutuhkan sistem aplikasi yang diantaranya dapat melakukan:

1. Proses Login:

a.Mengisi id dan password login berdasar hak akses user 2. Mengolah data master:

a.Menyimpan, ubah, hapus data master user b.Menyimpan, ubah, hapus data master menu c.Menyimpan, ubah, hapus data master ruangan d.Mengatur denah meja per-ruangan

a.Mengisi jumlah stok per item menu b.Mengisi jumlah stok secara keseluruhan 4. Proses pemilihan meja:

a.Menampilkan denah meja berdasarkan ruangan b.Menampilkan tanda meja yang isi dan kosong

c.Menandai meja sementara saat customer sedang pilih menu d.Menggabungkan meja dan pindah meja

5. Proses mencatat menu pesanan :

a.Menampilkan menu berdasarkan jenis menu b.Menampilkan informasi menu yang stoknya habis c.Menampilkan harga pemesanan menu

d.Merubah pesanan (menambah dan mengurangi jumlah menu) e.Mencatat pemesanan menu spesial

f. Mengirimkan list pesanan ke checker g.Menampilkan status pesanan

6. Proses checking pesanan a.Menampilkan list pesanan b.Merubah status pesanan c.Menampilkan riwayat pesanan 7. Proses pembayaran:

a.Menampilkan biaya yang harus dibayarkan berdasarkan nomor meja b.Memotong total pembayaran dengan menggunakan voucer

c.Melakukan pembayaran d.Mencetak struk

29

8. Proses reservasi:

a.Menyimpan data reservasi b.Menghapus data reservasi c.Mengubah data reservasi d.Memilih meja

e.Menandai meja reservasi 9. Proses membuat laporan

a.Memilih jenis laporan b.Menampilkan laporan harian c.Menampilkan laporan bulanan

Gambar 3.2 Arsitektur Aplikasi Pelayanan pada Restoran Berbasis Android

Terdapat 2 (dua) aplikasi yang akan dibangun seperti yang terlihat pada gambar 3.2, yaitu mobile application untuk pelayan dengan menggunakan tablet

dan desktop application menggunakan komputer yang dioperasikan checker, kasir, petugas dapur (bartender dan chef) dan manajer. Tablet dan komputer tersebut terhubung dengan server lokal yang berisikan database dengan menggunakan jaringan Wifi. Semua data yang masuk disimpan didalam database milik server lokal.

User pelayan bertugas mencarikan meja apabila customer kesulitan mencari meja sesuai dengan yang dibutuhkan, mencatat menu pesanan customer, serta menyiapkan meja yang sudah dibooking/dipesan pada 1 (satu) jam sebelum jadwal agar meja tersebut tidak dapat digunakan oleh customer lain. Mobile application yang diakses oleh pelayan dapat menampilkan denah meja (tampak meja isi/kosong/terpesan sesuai dengan jenis ruangan, menampilan menu tersedia, mencatat menu pesanan yang kemudian sistem akan otomatis mengirimkan menu pesanan ke Checker dan dapat melihat jadwal booking/pemesanan meja. Sistem akan otomatis menampilkan meja yang dipesan/ booking pada 1 (satu) jam sebelum jadwal dengan tanda meja berwarna ”ungu” dan data pemesan (nama pemesan dan jam pemesanan)

User Checker bertugas dalam mengisi data master (menu, user, ruangan), mengisi data stok menu harian yang tersedia setiap harinya, mengontrol antrian menu pesanan (menampilkan beberapa pesanan ke layar bagian Dapur dan melakukan pengecekan menu pesanan yang sudah dibuatkan oleh petugas dapur). Desktop aplication pada checker berfungsi sebagai maintenance data master, pengisian stok menu harian guna menentukan jumlah stok menu yang akan disediakan, pengontrolan pesanan (merubah status pesanan ”menunggu” menjadi

31

status pesanan ”selesai” agar pesanan yang selesai dibuat tidak tampil pada layar bagian dapur). Checker dapat mengecek riwayat dari menu pesanan yang sudah selesai dibuat.

User bagian dapur bertugas hanya dalam membuatkan menu pesanan. Bagian dapur cukup hanya melihat menu pesanan pada layar bagian dapur (chef dan atau bartender). Desktop application yang ada dibagian dapur hanya digunakan untuk melihat menu pesanan yang akan dibuatkan. Menu-menu yang muncul pada layar dapur dikontrol oleh checker. Menu pesanan yang muncul pada layar dapur hanya beberapa item pesanan. Sebelum jam operasional dimulai, petugas dapur (chef dan bartender) dapat memilih jenis tampilan sesuai kebutuhan

pada ”form tampilan dapur” diantaranya adalah: makanan dan minuman

digabung, makanan dan minuman dipisah, makanan saja dan minuman saja

User kasir bertugas dalam melakukan proses pembayaran dan menangani proses reservasi/booking/pemesanan meja. Pemesanan dapat dilakukan via telepon yang dilayani oleh petugas kasir maupun langsung di tempat. Aplikasi dekstop pada kasir berfungsi sebagai transaksi pembayaran dan transaksi reservasi dengan cara mencatat data pemesanan (nama pemesan, jadwal, lokasi meja dan no telepon yang bisa dihubungi). Jadwal reservasi otomatis akan muncul meja terblok warna ”ungu’ pada denah meja di mobile application pada 1 (satu) jam sebelum jadwal pemesanan.

Serta user manajer bertugas dalam melihat laporan-laporan baik laporan harian maupun bulanan yang diperoleh dari data yang tersimpan pada database. Manajer dapat memilih jenis laporan: penjualan, utility meja dan menu favorit. Desktop application yang ada pada manajer berfungsi untuk memilih jenis laporan

yang diinginkan seperti laporan penjualan, laporan utility meja dan menu favorit baik harian maupun bulanan.

3.2 Perancangan Sistem

Perancangan sistem adalah tahap untuk memberikan gambaran yang jelas dari rancangan aplikasi yang akan dibuat, sehingga memudahkan pemahaman mengenai sistem yang dibangun. Tahap perancangan sistem ini meliputi: UML (meliputi use Case Diagram, Activity Diagram, Sequance Diagram, Class Diagram, Statechart Diagram, Componen Diagram, Deployment Diagram, Statechart diagram) , Physical Data Model (PDM), struktur tabel, Rancangan Desain Input dan Output dan rancangan quesioner

3.2.1 Use Case Diagram

Use case diagram menyajikan interaksi antar use case dan actor. Use case digunakan untuk mengetahui yang terdapat didalam sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut. Dalam tahap ini, penggambaran use case tampak pada gambar 3.3.

Setelah melakukan analisa terhadap sistem, diketahui bahwa restoran memiliki pegawai pelayan, checker, bagian dapur, kasir dan manager, serta melayani pelanggan dalam proses bisnisnya. Untuk mencari actor, dilakukan identifikasi yang ada di dalam ruang lingkup (Business Worker) dan berada di ruang lingkup (Business Actor). Setelah melakukan identifikasi, ditemukan satu Business Actor yaitu pelanggan dan ditemukan 5 Business Worker yaitu pelayan, checker, bagian dapur, kasir dan manajer.

33

Pelayan bertugas mencarikan meja kosong untuk pelanggan, kemudian mencatat menu pesanan, selanjutnya mengirimkan list pesanan tersebut ke checker dan bartender. Pelayan dapat menunjukkan list pesanan yang sudah di pesan customer. Pelayan mencatat nomor meja jika pelanggan melakukan pindah meja atau menggabung meja. Checker bertugas mengontrol stok dan mengontrol pesanan (menentukan menu yang dibuat oleh bagian dapur). Bagian dapur menerima list menu pesanan yang harus dibuat untuk diproses. Kasir bertugas menerima pembayaran dan mencatat reservasi. Sedangkan manajer bertugas membuat laporan. Dari uraian diatas, dapat diidentifikasi beberapa usecase, yaitu login, mengolah data master, memilih meja, mencatat menu pesanan, checking pesanan, pembayaran, reservasi meja, membuat laporan. Setelah ditemukan actor dan usecase, maka dapat digambar usecase diagram seperti pada gambar 3.3.

Berikut adalah penjelasan singkat dari masing-masing use case diagram aplikasi pelayanan pada restoran:

Tabel 3.1 Tabel Flow of Event Usecase Login Use case Name Login

Brief Description Use case ini mengatur proses login user Primary Actor Pelayan

Manajer Checker Bag. Dapur Kasir Secondary Actor - Pre-Condition -

Post-Condition User masuk ke dalam sistem Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1.User

memasukkan username dan password

kemudian mengklik tombol login

2.Sistem mengecek username dan password apakah sudah benar dengan cara mengambil data sesuai username yang dimasukkan user dari database dan membandingkan apakah password yang dimasukkan user setelah dienkripsi dengan MD5 sama dengan password yang tersimpan pada database

3. Jika username dan password benar, sistem menampilkan tampilan utama Alternate Flow of

Events

3a. Jika username dan password salah, maka sistem akan menampilkan tampilan login dengan informasi login gagal Extension Points -

Tabel 3.2 Tabel Flow of Event Usecase Mengolah Data Master Use case Name Mengolah data master

Brief Description Use case ini mengatur proses memasukkan, mengubah dan menghapus data master

Primary Actor Checker Secondary Actor -

Pre-Condition Checker sudah login ke dalam sistem Post-Condition Data master tersimpan dalam sistem

35

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Checker memilih menu data master 3.Checker

memasukkan, mengubah atau menghapus data master

2. Sistem menampilkan form data master

4. Sistem menyimpan/menghapus data master pada database

5.Jika sistem berhasil menyimpan/menghapus data master, data akan muncul/hilang pada tabel

Alternate Flow of Events

5a. Jika sistem gagal menyimpan/menghapus data master, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.3 Tabel Flow of Event Usecase Memasukkan Stok Menu Harian Use case Name Memasukkan stok menu harian

Brief Description Use case ini untuk memasukkan stok menu setiap hari Primary Actor Checker

Secondary Actor Pelayan

Pre-Condition -Checker sudah login ke dalam sistem -Stok hari ini belum dimasukkan Post-Condition Data stok tersimpan dalam sistem Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Checker memilih menu stok

3. Checker memasukkan jumlah stok tiap menu dan mengklik tombol simpan

2. Sistem menampilkan tabel stok hari ini yang datanya diambil dari tabel menu dan diberi nilai awal setiap stok sejumlah 0.

4. Sistem menyimpan data stok menu yang memiliki jumlah stok lebih dari 0 ke database. 5. Jika sistem berhasil menyimpan data stok, data akan tampil pada tabel dan tombol simpan serta set semua tidak dapat digunakan

Alternate Flow of Events

5a. Jika sistem gagal menyimpan data stok, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.4 Tabel Flow of Event Usecase memilih meja Use case Name Memilih meja

Brief Description Use case ini digunakan untuk memilih meja yang akan digunakan oleh customer

Primary Actor Pelayan Secondary Actor -

Pre-Condition -Pelayan sudah login ke dalam sistem

-Data master ruangan dan meja sudah diisi oleh checker Post-Condition Meja terpilih dan diberi penanda warna merah

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan

menyentuh gambar meja dan mengklik tombol pilih meja

2. Sistem menyimpan data meja sesuai dengan meja yang dipilih. Meja ditandai dengan status terpakai. 3. Sistem menampilkan halaman pemesanan menu

Alternate Flow of Events

-

Extension Points -Pindah meja -Gabung meja

Tabel 3.5 Tabel Flow of Event Usecase Mencatat Menu Pesanan Use case Name Mencatat menu pesanan

Brief Description Use case ini digunakan untuk melakukan proses pemesanan menu

Primary Actor Pelayan Secondary Actor -

Pre-Condition -Pelayan sudah login ke dalam system -Data master menu sudah diisi oleh checker -Data stok harian sudah diisi oleh checker -Pelayan sudah memilih meja

Post-Condition Menu pesanan customer tersimpan dalam di dalam system Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan mengklik menu yang ingin dipesan dan mengklik tombol simpan

2. Sistem meverifikasi menu pesanan dengan cara mengecek apakah jumlah stok tersisa lebih

37

besar/sama dengan jumlah yang dipesan

3. Sistem menyimpan data pesanan pada database

4. Jika pesanan tersimpan, sistem akan menampilkan halaman utama

Alternate Flow of Events

2a. Jika menu pesanan kehabisan stok, maka sistem akan menampilkan pesan kesalahan

3a. Jika sistem gagal menyimpan pesanan, maka sistem akan menampilkan pesan kesalahan

Extension Points -Memesan menu special -Merubah pesanan

-Menampilkan status pesanan

Tabel 3.6 Tabel Flow of Event Usecase Memesan Menu Spesial Use case Name Memesan menu spesial

Brief Description Use case ini digunakan untuk memberi catatan pada pesanan customer jika customer menginginkan menu dengan penanganan khusus

Primary Actor Pelayan Secondary Actor -

Pre-Condition Pelayan telah mengklik menu yang diinginkan Post-Condition Catatan menu khusus tesimpan dalam system Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan mengklik tombol jumlah pesanan pada menu yang ingin ditambahkan catatan

3. Pelayan memasukkan catatan menu special dan mengklik tombol ubah

2. Sistem menampilkan dialog pesanan special

4. Sistem menyimpan catatan menu special pada list pesanan

Alternate Flow of Events

- Extension Points -

Tabel 3.7 Tabel Flow of Event Usecase Menampilkan Status Pesanan Use case Name Menampilkan status pesanan

Brief Description Use case ini digunakan untuk menampilkan pesanan customer

Primary Actor Pelayan Secondary Actor Checker

Pre-Condition Pelayan telah melakukan pemesanan menu Post-Condition Tampil halaman list pesanan

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan memilih meja yang telah dipakai dan mengklik tombol lihat meja

2. Sistem mengambil data pesanan pada database berdasarkan id meja yang dipilih 3. Sistem menampilkan list pesanan customer

Alternate Flow of Events

2a. Jika sistem gagal mengambil data pesanan, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.8 Tabel Flow of Event Usecase Gabung Meja Use case Name Gabung meja

Brief Description Use case ini digunakan untuk melakukan penggabungan meja

Primary Actor Pelayan Secondary Actor -

Pre-Condition -Pelayan telah melakukan pemesanan menu -Pelayan telah masuk ke halaman list pesanan

Post-Condition Meja yang digabung akan disimpan di sistem dan diberi tanda merah

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan mengklik tombol gabung meja 3. Pelayan memilih meja yang akan digabung dan mengklik tombol pilih

2. Sistem akan menampilkan halaman peta meja

4. Sistem menyimpan data meja yang digabung pada database. Meja ditandai dengan status terpakai.

5. Jika sistem berhasil menyimpan data meja digabung, meja yang digabung (berstatus terpakai) akan bertanda merah.

6. Sistem menampilkan halaman list pesanan

39

Events sistem akan menampilkan pesan kesalahan Extension Points -

Tabel 3.9 Tabel Flow of Event Usecase Pindah Meja Use case Name Pindah meja

Brief Description Use case ini digunakan untuk melakukan pindah meja Primary Actor Pelayan

Secondary Actor -

Pre-Condition -Pelayan telah melakukan pemesanan menu -Pelayan telah masuk ke halaman list pesanan

Post-Condition Meja berpindah dari meja awal ke meja yang dipilih (penanda merah pada meja awal hilang dan muncul pada meja yang dipilih)

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan mengklik tombol gabung meja

3. Pelayan memilih meja yang akan ditempati dan mengklik tombol pilih

2. Sistem akan menampilkan halaman peta meja

4. Sistem menyimpan data meja yang dipindah dan mengubah data meja lama. Meja lama diupdate dengan status selesai dan meja baru ditandai dengan status dipakai 5. Jika sistem berhasil menyimpan data meja dipindah, meja yang dipindah (berstatus dipakai) akan ditandai merah dan meja lama (berstatus selesai) tidak ditandai merah.

6. Sistem menampilkan halaman list pesanan

Alternate Flow of Events

4a. Jika sistem gagal menyimpan data meja dipindah, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.10 Tabel Flow of Event Usecase Mengubah Pesanan Use case Name Mengubah pesanan

Brief Description Use case ini dilakukan untuk mengubah pesanan Primary Actor Pelayan

Secondary Actor -

Pre-Condition -Pelayan telah melakukan pemesanan menu -Pelayan telah masuk ke halaman list pesanan

Post-Condition Pesanan yang disimpan sistem berubah sesuai perubahan yang dilakukan

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Pelayan menambah atau mengurangi

pesanan 2. Sistem meverifikasi menu pesanan dengan mengecek apakah jumlah yang ditambah lebih kecil/sama dengan sisa stok menu jika pelayan melakukan penambahan. Jika melakukan pengurangan, maka tidak dilakukan verifikasi

3. Sistem menyimpan data pesanan yang sudah diupdate pada database 4. Jika pesanan tersimpan, sistem akan menampilkan halaman list pesanan

Alternate Flow of Events

2a. Jika menu pesanan kehabisan stok, maka sistem akan menampilkan pesan kesalahan

3a. Jika sistem gagal menyimpan pesanan, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.11 Tabel Flow of Event Usecase Checking Pesanan Use case Name Checking pesanan

Brief Description Use case ini digunakan untuk mengontrol pesanan Primary Actor Checker

Secondary Actor Bag. Dapur

Pre-Condition Pelayan sudah melakukan pemesanan menu

Post-Condition Status pesanan sesuai dengan yang ditentukan checker Included Use case Mengubah status pesanan

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Checker mengatur tampilan tabel pesanan dengan mengklik judul

tabel 2. Sistem mengambil data

pesanan hari ini dari database dan menampilkan data sesuai dengan pengaturan checker Alternate Flow of -

41

Events

Extension Points -

Tabel 3.12 Tabel Flow of Event Usecase Mengubah Status Pesanan Use case Name Mengubah status pesanan

Brief Description Use case ini digunakan untuk mengubah status pesanan sesuai dengan kondisi actual

Primary Actor Checker Secondary Actor Dapur Pre-Condition -

Post-Condition Status pesanan berubah sesuai dengan status saat ini Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Checker memilih pesanan yang ingin diubah statusnya dan mengklik tombol ubah status

2. Sistem mengubah status pesanan. Jika status saat ini adalah menunggu, maka akan diubah menjadi proses. Jika status saat ini adalah proses maka diub

3. Jika status berhasil diubah, sistem akan menampilkan data pada tabel Alternate Flow of

Events

2a. Jika sistem gagal mengubah status pesanan, sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.13 Tabel Flow of Event Usecase Pembayaran Use case Name Pembayaran

Brief Description Use case ini digunakan dalam proses pembayaran Primary Actor Kasir

Secondary Actor -

Pre-Condition Status seluruh pesanan customer telah diubah menjadi selesai Post-Condition -Pembayaran disimpan dan meja diset menjadi tidak terpakai Included Use case -Mencetak struk

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Kasir memasukkan nomor meja dan

mengklik tombol cari 2. Sistem akan mencari dan mengambil data pesanan berdasarkan nomor meja yang diinputkan

3. Sistem menampilkan data pesanan, harga tiap menu dan

4. Kasir memasukkan jumlah pembayaran dan mengklik tombol bayar

menghitung total harga

5. Sistem menyimpan data pembayaran pada database dan mengubah status data meja dari dipakai menjadi selesai

6. Sistem menampilkan struk pembayaran

Alternate Flow of Events

2a. Jika nomor meja yang dicari tidak memiliki pesanan, maka sistem akan menampilkan pesan kesalahan

4a. Jika kasir memasukkan jumlah pembayaran yang salah, maka sistem akan menampilkan pesan kesalahan

5a. Jika sistem gagal menyimpan data pembayaran, maka sistem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.14 Tabel Flow of Event Usecase Mencetak Struk Use case Name Mencetak struk

Brief Description Use case ini digunakan untuk melakukan cetak struk Primary Actor Kasir

Secondary Actor -

Pre-Condition Kasir telah melakukan proses pembayaran Post-Condition Struk tercetak

Included Use case - Basic Flow of Events

Actor’s Action Sistem’s Response

1. Kasir mengklik tombol cetak saat sistem menampilkan struk pada use case memproses

pembayaran 2. Sistem mencetak struk

Alternate Flow of Events

- Extension Points -

Tabel 3.15 Tabel Flow of Event Usecase Memproses Reservasi Meja Use case Name Memproses reservasi meja

Brief Description Use case ini digunakan untuk melakukan proses reservasi Primary Actor Kasir

Secondary Actor Pelayan Pre-Condition -

Post-Condition Data reservasi tersimpan dalam sistem Included Use case Menandai meja pesanan

43

Events 1. Kasir

memasukkan

data reservasi 2. Sistem meverifikasi data reservasi dengan mengecek apakah meja yang akan direservasi sudah dipesan atau belum dan apakah pesanan dengan meja yang sama sudah ada tapi pada rentang lebih dari 3 jam

3. Jika meja dan waktu yang diinginkan tersedia, maka sistem menyimpan data reservasi pada database

4. Sistem menampilkan data reservasi pada tabel

Alternate Flow of Events

2a. Jika waktu dan atau meja yang dipilih sudah dipesan sebelumnya, maka sisem akan menampilkan pesan kesalahan 3a. Jika sistem gagal menyimpan reservasi, maka sisem akan menampilkan pesan kesalahan

Extension Points -

Tabel 3.16 Tabel Flow of Event Usecase Menandai Meja Use case Name Menandai meja pesanan

Brief Description Use case ini digunakan untuk menandai meja yang telah digunakan

Primary Actor Kasir Secondary Actor Pelayan

Pre-Condition Data reservasi telah tersimpan pada system Post-Condition Data meja yang dipesan disimpan pada system Included Use case -

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Kasir melakukan reservasi sesuai use case memproses

reservasi meja 2. Sistem akan memberikan tanda warna ungu pada meja yang statusnya dibooking dan waktu saat ini berada pada rentang 1 jam sebelum jam booking sampai jam booking.

Alternate Flow of Events

- Extension Points -

Tabel 3.17 Tabel Flow of Event Usecase Membuat Laporan Use case Name Membuat laporan

Primary Actor Manager Secondary Actor -

Pre-Condition Manager telah login ke dalam system Post-Condition Tampil laporan

Included Use case Memilih jenis laporan Basic Flow of

Events

Actor’s Action Sistem’s Response

1. Manajer memilih menu laporan yang diinginkan 3. Manajer memasukkan data filter yang diinginkan dan mengklik tombol lihat laporan

2. Sistem menampilkan filter laporan

4. Sistem mengambil data dari database sesuai filter dan menampilkan dalam bentuk laporan

Alternate Flow of Events

- Extension Points -

Tabel 3.18 Tabel Flow of Event Usecase Memilih Jenis Laporan Use case Name Memilih jenis laporan

Brief Description Use case ini digunakan untuk memilih jenis laporan yang akan dilihat

Primary Actor Manajer Secondary Actor -

Pre-Condition -Manajer telah memilih menu laporan yang diinginkan Sistem telah menampilkan filter laporan

Post-Condition Jenis laporan terpilih Included Use case

Basic Flow of Events

Actor’s Action Sistem’s Response

1. Manajer memilih jenis laporan dari salah satu pilihan pada combobox

2. Filter terset sesuai jenis laporan

Alternate Flow of Events

- Extension Points -

3.2.2 Activity Diagram

Activity Diagram atau Diagram aktivitas menggambarkan aliran kerja/ aktifitas dari sistem atau proses bisnis, bukan apa yang dilakukan oleh aktor.

45

Berikut beberapa penjelasan singkat mengenai activity diagram proses yang berkaitan dengan pelayanan restoran:

a. Activity Diagram Proses Login Mobile Application

Proses Login diawali oleh user pelayan memasukkan data username dan password. Data inputan dikirim oleh mobile application ke server dengan menggunakan jaringan internet lokal. Server mengecek data inputan tersebut apakah ada atau tidak pada database user. Jika data login tidak sesuai maka mobile application menampilkan pesan bahwa login gagal dan meminta untuk memasukkan username dan password yang benar. Jika data login yang dimasukkan sudah benar maka mobile application menampilkan denah meja Untuk lebih jelasnya dapat dilihat pada gambar 3.4.

User Client Server

Input username dan password _{Mengirim data ke server Mengecek data login}

Muncul pesan login salah

Tampil form denah

Salah

Benar

Gambar 3.4 Activity Diagram Proses Login

b. Activity Diagram Proses Pilih Meja

Mobile application menampilkan denah meja, pelayan memilih meja yang artinya mobile application menandai meja sementara untuk disimpan pada server. Mobile application meminta list menu pada server, server memberikan data menu yang tersedia sehingga tampil list menu pada mobile application. Apabila pelayan memilih menu maka dilakukan proses pemesanan menu. Jika

pelayan memilih batal pilih menu kemudian memilih simpan meja, maka sistem akan melakukan lock (penguncian tanda merah pada meja), jika tidak disimpan maka akan keluar dari sistem yang artinya tanda sementara akan hilang.

Pelayan Mobile Server

Tampil form denah meja Pilih meja

Penandaan meja sementara Simpan tanda sementara

Minta list menu Ambil data menu

Tampil list menu Pesan menu

Lock Meja Batal pilih menu

Simpan meja

Tidak Pilih menu

Gambar 3.5 Activity Diagram Proses Pilih Meja

c. Activity Diagram Proses Pemesanan Menu

Mobile application menampilkan list menu yang tersedia, kemudian pelayan melakukan pemesanan menu (mencatat pesanan). Apabila ada pesanan menu spesial maka di lakukan pencatatan pesanan spesial jika tidak pesan maka sistem akan mengirimkan list pesanan ke server untuk disimpan. Kemudian menghasilkan entitas bisnis daftar pesanan baru. Mobile application akan menampilkan status pesanan. Apabila pelayan tidak ingin mengubah pesanan maka proses pemesanan dapat diakhiri. Jika ingin mengubah pesanan maka sistem akan mengirimkan data pesanan yang dirubah ke server untuk dilakukan simpan data update, maka menghasilkan entitas bisnis daftar pesanan modif. Alur proses seperti pada gambar 3.6.

47

Gambar 3.6 Activity Diagram Proses Pemesanan

d. Activity Diagram Proses Pembayaran

Proses pembayaran dilakukan oleh kasir dengan menggunakan aplikasi desktop. Aplikasi desktop menampilkan form pembayaran, petugas kasir mengisi nomor meja, kemudian aplikasi desktop mengirim data meja tersebut ke server. Server mengecek data meja yang diterima kemudian server mengambil data pembelian. Data pembelian tersebut tampil pada aplikasi desktop, sehingga menghasilkan entitas bisnis struk baru. Bila membayar dengan uang cash maka diminta memasukkan nominal uang yang diterima kemudian sistem akan mengirimkan data pembayaran ke server. Server menyimpan data pembayaran tersebut yang menghasilkan entitas bisnis struk lunas. Kemudian sistem dapat melakukan cetak struk pembayaran. Apabila menggunakan voucher maka dilakukan pengisian nomor voucer. Gambar dapat dilihat pada gambar 3.7.

Gambar 3.7 Activity Diagram Proses Pembayaran

e. Activity Diagram Proses Reservasi /Booking Meja

Proses reservasi dilakukan oleh petugas kasir. Petugas kasir melayani reservasi melalui telepon atau bisa juga dengan melayani secara langsung di restoran. Desktop application akan menampilkan form reservasi, kemudian pelayan menginputkan data yang diperlukan untuk dilakukan reservasi/ booking/ pesan meja. Desktop application mengirimkan data reservasi tersebut ke server untuk dilakukan pengecekan ketersediaan booking. Jika tidak tersedia, maka akan gagal reservasi. Jika tersedia server menyimpan data reservasi tersebut, kemudian menampilkan daftar reservasi pada list reservasi. Server melakukan pengecekan jadwal reservasi, apabila masuk pada 1(satu) jam sebelum jadwal yang dipesan, maka akan tampil tanda meja sedang booking/ dipesan pada mobile application dengan tanda warna ungu. Meja yang sama hanya bisa di booking dengan beda waktu 3 (tiga) jam. Dapat dilihat pada gambar 3.8.

49

Kasir Desktop Application Server Mobile Application

Tampil Form reservasi Isi data reservasi

Mengirim data reservasi

Menyimpan data reservasi Mengecek ketersediaan booking

gagal booking

tidak tersedia

tersedia Tampil daftar reservasi

Mengecek jadwal reservasi

tampil tanda booking Masuk renatang 1 jam sebelum jadwal tidak masuk rentang1 jam sebelum jadwal

Gambar 3.8 Activity Diagram Proses Reservasi /Booking Meja

f. Activity Diagram Proses Laporan

Proses pembuatan laporan dilakukan oleh manajer. Desktop application menampilkan tampilan aplikasi utama. Jika manager memilih laporan penjualan, kemudian pilih jenis laporan harian, maka desktop application akan meminta laporan harian ke server. Server mengambil data laporan, menampilkan laporan harian pada desktop application. Jika manajer memilih laporan berdasarkan bulanan, maka akan meminta laporan harian pada server, server mengambil data laporan bulanan yang muncul pada desktop application. Laporan bulanan dan harian menghasilkan entitas bisnis laporan. Gambar terlihat pada gambar 3.9.

3.2.3 Sequence Diagram

Sequence diagram menggambarkan kegiatan objek pada use case dengan mendeskripsikan waktu hidup objek dan message yang dikirim dan diterima antar objek

a. Sequence Diagram Proses Login

User (Pelayan / Checker / Bagian Dapur / Kasir / Manajer) melakukan proses login pada login view setiap akan menggunakan aplikasi mobile/desktop. Proses login dilakukan dengan cara input data login (nama &password). Database mengecek data login tersebut, ke Db helper kemudian memvalidasi data yang menghasilkan pesan login.

Gambar 3.10 Sequence Diagram Proses Login

b. Sequence Diagram Proses Pilih Meja

Pelayan membuka aplikasi pelayanan pada form menu meja, kemudian dilakukan ambil data ruangan, push manager ambil data ruangan pada Db Helper. Db Helper mengirim data ruangan ke push manager untuk dikirimkan ke form menu meja. Pelayan memilih ruangan, form menu meja mengambil data meja. Push manager mengmbil data meja pada db helper. Db helper mengirimkan data meja ke push manager yang kemudian diterukan ke form menu meja. Pelayan

51

memilih meja pada form menu meja. Kemudian dilakukan penandaan meja pada push manager . Db helper melakukan update data meja yang menghasilkan data meja. Data meja di kirim ke push manajer untuk di tampilkan pada form menu meja. Form menu meja mengirimkan tampilan menu order pada form order Seperti pada gambar 3.11.

Gambar 3.11 Sequence Diagram Proses Pilih meja c. Sequence Diagram Proses Pemesanan Menu

Form order mengambil data stok pada push manager kemudian mengambil data stok pada Db helper. Db helper mengirim data stok pada push manager kemudian ke form order. Pelayan memesan menu pada form order, kemudian menampilkan list pesanan. Pelayan menyimpan pesanan pada form order kemudian dikirimkan ke push manager dan Db helper. Db helper mengirimkan menu terpesan pada push manager dan form order. Form order mengirimkan pemesanan selesai pada form menu meja.

Gambar 3.12 Sequence Diagram Proses Pilih Meja dan Pesan Menu

d. Sequence Diagram Proses Checking Pesanan

Checker mengambil data pesanan pada form chacker main view, kemudian ke push manager dan Db Helper. Db helper mengirimkan data pesanan kemudian ke push manajer dan pada form chacker main view. Pelayan mengubah status pesanan “proses” pada form cheicking, kemudian dikirimkan ke push manager dan db helper melakukan update status pesanan. Db helper mengirimkan data pesanan ke push manager dan form checking melakukan update tampilan dapur. Checker mengubah status pesanan “selesai” pada form checking, push manager dan db helper melakukan update status kemudian mengirimkan data pesanan pada push manager dan form checking melakukan update form tampilan dapur. Push manager update form riwayat pesnan pada form histori.

53

Gambar 3.13 Sequence Diagram Proses Checking Pesanan

e. Sequence Diagram Proses Pembayaran

Petugas kasir membuka form pembayaran, kemudian input nomor meja pada form kasir. Nomor meja dikirim ke push manager dan db helper mengambil data pembelian. Data pembelian dikirim ke push manager dan form kasir view. Kasir melakukan pembayaran, menghasilkan data pembayaran untuk dikirim ke push manager dan db helper melakukan simpan data pembayaran. Db helper mengirimkan data pembayaran beserta melakukan update status meja. Kemudian muncul data pembelian pada form kasir dan dilakukan cetak struk.

f. Sequence Diagram Proses Reservasi

Petugas kasir membuka form reservasi. Memilih meja pada form reservasi, kemudian mengambil data ruangan pada push manager dan db helper. Db helper mengirimkan data ruangan ke push manager dan form resrvasi. Kemudian mengambil data meja ke db helper dan menghasilkan data meja. Data meja dikirimkan ke form reservasi. Kasir mengisi data reservasi kemudian menyimpan data reservasi. Data reservasi dikirim push manajer ke db helper untuk dilakukan simpan data reservasi. Db helper menampilkan data reservasi ke form reservasi melalui push manager sehingga menampilkan update tampilan.

Gambar 3.15 Sequence Diagram Proses Reservasi

g. Sequence Diagram Proses Pembuatan laporan

Manajer membuka form laporan dan memfilter laporan. Kemudian lihat laporan pada form laporan. Form laporan mengirim data filter laporan pada show laporan. Jesper report mengambil data sesuai filter yang diterima untuk kemudian

55

dikirimkan data sesuai filter dan ditampilkan data laporan pada form laporan. Pelayan melakukan cetak laporan, maka form laporan mencetak laporan tersebut.

Gambar 3.16 Sequence Diagram Proses Pembuatan Laporan

3.2.4 Class Diagram

Menunjukkan interaksi antar kelas dalam sistem. Class mengandung informasi dan tingkah laku (behavior) yang berkaitan dengan informasi tersebut. Sebuah kelas pada diagram kelas dibuat untuk setiap tipe obyek pada diagram sequensial atau diagram kolaborasi.

Class diagram dibagi menjadi 3 (tiga) bagian berdasarkan program yang dibagun, yaitu client pada aplikasi desktop, client pada aplikasi mobile android dan server. Class diagram tersebut digambarkan seperti pada gambar 3.17, 3.18 dan 3.19.

a. Client Desktop

3. Bentuk tampilan aplikasi 5 100% Sangat Baik

4. Pemahaman informasi aplikasi 4 80% Baik

B. _Kecepatan

1. Mengambil data transaksi 3 60% Sedang

C. _Keakuratan

1. Keakuratan data transaksi 4 80% Baik

2. Informasi yang diberikan sistem 4 80% Baik D. _Persepsi

1. Aplikasi memudahkan proses

pembuatan laporan 4 80% Baik

Tabel 4.34 Tabel Quesioner Fungsionalitas Manajer

No Pertanyaan Ya Tidak

1 Apakah dapat login ke dalam sistem? V

2 Apakah dapat membuka form Laporan Penjualan? V 3 Apakah dapat menampilkan dan mencetak Laporan Penjualan

Harian?

V 4 Apakah dapat menampilkan dan mencetak Laporan Penjualan

Bulanan?

V 5 Apakah dapat membuka form Laporan Utilitas Meja? V 6 Apakah dapat menampilkan dan mencetak Laporan Utilitas

Meja Harian?

V 7 Apakah dapat menampilkan dan mencetak Laporan Utilitas

Meja Bulanan?

V 8 Apakah dapat membuka form Laporan Menu Favorit? V 9 Apakah dapat menampilkan dan mencetak Laporan Menu

Favorit Harian?

V 10 Apakah dapat menampilkan dan mencetak Laporan Menu

Favorit Bulanan?

V

Dari kesimpulan yang didapat pada tabel 4.32, dapat disimpulkan bahwa:

1. Rata-rata Skor untuk vaiarbel kemudahan yaitu 95%, yang artinya responden memiliki interpretasi yang sangat baik untuk kemudahan dalam penggunaan aplikasi desktop pembuatan laporan untuk manajer.

2. Rata-rata Skor untuk vaiarbel kecepatan yaitu 60%, yang artinya responden memiliki interpretasi yang sedang untuk kecepatan dalam penggunaan aplikasi desktop pembuatan laporan untuk manajer.

149

3. Rata-rata Skor untuk vaiarbel keakuratan yaitu 80%, yang artinya responden memiliki interpretasi yang baik untuk keakuratan dalam penggunaan aplikasi desktop pembuatan laporan untuk manajer.

4. Rata-rata Skor untuk vaiarbel persepsi yaitu 80%, yang artinya responden memiliki interpretasi yang baik untuk keakuratan dalam persepsi aplikasi desktop pembuatan laporan untuk manajer.

5. Interpretasi secara keseluruhan untuk aplikasi desktop pembuatan laporan untuk manajer pada restoran adalah baik, dengan skor rata-rata sebesar 78,75% dari semua variable.

Setelah dilakukan quesioner fungsionalitas manajer, dapat disimpulkan bahwa seluruh fungsionalitas manajer telah berjalan sesuai dengan dengan yang dibutuhkan manajer

150 PENUTUP

5.1 Kesimpulan:

Berdasarkan uji coba terhadap fungsi aplikasi dan didukung dari hasil kuesioner yang disebarkan ke responden, didapatkan kesimpulan:

1. Dari hasil uji coba fungsi aplikasi, mobile application dapat menghasilkan informasi mengenai status meja yang kosong, terisi dan sedang di-booking. . 2. Dari hasil uji coba fungsi aplikasi, mobile application dapat menangani

proses pemesanan menu tanpa perlu merangkap list pesanan kembali.

3. Dari hasil uji coba fungsi aplikasi, mobile application dapat menampilkan informasi meja yang di-booking pada 1 (satu) jam sebelum waktu yang dipesan secara otomatis.

4. Menghasilkan skor uji coba pada responden dengan hasil rata-rata pada variabel kemudahan sebesar 82%, rata-rata pada variabel kecepatan sebesar 87%, rata-rata pada variabel keakuratan sebesar 81%, rata-rata pada variabel persepsin sebesar 77%. Sehingga rata-rata ke 4 (empat) variabel menghasilkan 83% pada aplikasi pelayanan restoran berbasis mobile android. Sehingga dapat menghasilkan suatu rekomendasi bagi pihak restoran dalam hal pelayanan

5. Setelah dilakukan quesioner fungsionalitas dapat disimpulkan bahwa seluruh fungsionalitas user pelayan, checker, bagian dapur, kasir dan manajer telah berjalan sesuai dengan dengan yang dibutuhkan masing-masing user tersebut

151

5.2 Saran

Setelah dilakukan evaluasi mengenai aplikasi yang dibangun baik mobile application maupun desktop application, diperoleh saran yang dapat diberikan kepada peneliti berikutnya apabila dilakukan pengembangan dari sistem yang dibangun ini agar menghasilkan sistem yang lebih baik. Adapun saran yang diberikan kepada peneliti adalah:

1. Mobile Application yang dibangun dapat menangani jumlah persediaan menu

secara nyata berdasarkan perhitungan persediaan bahan baku yang ada.

2. Desktop Application yang dibangun dapat menangani proses reservasi yang dapat terhubung dengan proses pembayaran uang muka dan reservasi terhadap menu sekaligus.

3. Aplikasi yang dibangun dapat menangani proses pemesanan menu dan reservasi secara online

152

Buyens, Jim, 2001, Web Database Development, Elex Media Komputindo, Jakarta.

Fowler, Martin, 2005. UML Distilled, edisi 3, penerbit Andi, Yogyakarta. Hague, Paul. 1995. Merancang Kuesioner. Jakarta: Pustaka Binaman Pressindo. Kendall, K.E., dan J.E. Kendall., 2003, Analisis dan Perancangan Sistem,

AlihBahasa oleh Thamir Abdul Hafedh Al-Hamdany, Jilid 2, Edisi Ke-5,PT. Prenhallindo, Jakarta

Kenneth L. Calvert and Michael J. Donahoo., 2002, TCP/IP Sockets in Java: Practical Guide for Programmers, Academic Press, United States of America

Marlinda, Linda, S.Kom, 2004, Sistem Basis Data, ANDI OFFSET, Yogyakarta Marsum. 2005. Restoran dan Segala Permasalahannya, Penerbit Andi,

Yogyakarta

Pressman, Roger S. 2001. Software Engineering A Practitioner’s Approach. Edisi kelima. New York, Amerika: McGraw-Hill

Rickyanto, Isak. 2003. Dasar Pemrograman Berorientasi Objek Dengan Java 2 (JDK 1.4). Penerbit Andi, Yogyakarta.

Romeo, 2003, Testing Dan Implementasi Sistem, Edisi Pertama, STIKOM, Surabaya.

Rosa A.S dan M. Shalahuddin, 2011. Modul Pembelajaran Rrekayasa Perangkat Lunak, penerbit Modula, Bandung.

Safaat H, Nazruddin, 2012, Android (Pemograman Aplikasi Mobile Smartphone dan Tablet PC Berbasis Android). Bandung: Informatika.

Sholiq, 2006. Pemodelan Sistem Informasi Berorientasi Obyek dengan UML, edisi pertama, penerbit Graha Ilmu, Yogyakarta.

Suprianto, Dodit. Rini Agustina. 2012. Pemrograman Aplikasi Android. Penerbit Mediakom, Yogyakarta.

Williams, B.K., & Sawyer, S. C. 2007.Using Information technology: Pengenalan Praktisi Dunia Komputer dan Komunikasi. Yogyakarta: Andi.

153

Winarno, Edy., Ali Zaki, SmitDev.2012.Comunity. Hacking & Programming dengan Android SDK Advance. Penerbit Elex Media Komputindo