prototipe aplikasi manajemen darurat berbasis android

PROTOTIPE APLIKASI MANAJEMEN DARURAT BERBASIS

ANDROID

Skripsi

Oleh:

Muchtar Prawira

1113091000038

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOOLOGI

UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH

JAKARTA

2019 M / 1440 H

1

UIN Syarif Hidayatullah Jakarta

PROTOTIPE APLIKASI MANAJEMEN DARURAT BERBASIS

ANDROID

Skripsi:

Sebagai salah satu syarat untuk memperoleh

gelar Sarjana Komputer (S.Kom)

Oleh:

Muchtar Prawira

1113091000038

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOOLOGI

UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH

JAKARTA

2019 M / 1440 H

iii


iv


v


vi


PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI

UNTUK KEPENTINGAN AKADEMIS

Sebagai civitas akademik UIN Syarif Hidayatullah Jakarta, saya yang bertanda

tangan di bawah ini:

Nama : Muchtar Prawira

NIM : 1113091000038

Program Studi : Teknik Informatika

Fakultas : Sains dan Teknologi

Jenis Karya : Skripsi

demi pembuatan ilmu pengetahuan, menyetujui untuk memberikan kepada UIN

Syarif Hidayatullah Jakarta Hak Bebas Royalti Noneksklusif (Non-exclusive

Royalti Free Right) atas karya ilmiah yang berjudul:

Prototipe Aplikasi Manajemen Darurat berbasis Android

beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti

Noneksklusif ini UIN Syarif Hidayatullah Jakarta berhak menyimpan,

mengalihmedia/ formatkan, mengelola dalam bentuk pangkalan data (database),

merawat, dan mempublikasikan tugas akhir saya selama tetap mencantumkan

nama saya sebagai penulis / pencipta dan sebagai pemilik Hak Cipta.

Demikian pernyataan ini saya buat dengan sebenarnya.

Dibuat di: Tangerang Selatan

Pada Tanggal: 19 Februari 2019

Yang Menyatakan

(Muchtar Prawira)

vii


KATA PENGANTAR

Puji syukur penulis panjatkan kehadirat Allah SWT, atas limpahan rahmat

dan hidayahnya penulis dapat menyelesaikan skripsi yang berjudul “PROTOTIPE

APLIKASI MANAJEMEN DARURAT BERBASIS ANDROID,” yang mana

dilakukan dalam rangka memenuhi salah satu syarat guna memperoleh gelar

sarjana komputer dari Program Studi Teknik Informatika di Fakultas Sains dan

Teknologi, Universitas Islam Negri (UIN) Syarif Hidayatullah Jakarta. Dalam

proses penulisan, penulis menyadari bahwa tidak lepas dari berbagai pihak dalam

bentuk bantuan, dukungan, saran, kritik, dan semangat yang hingga kini penulis

dapatkan. Oleh karena itu penulis ingin mengucapkan terima kasih kepada:

1. Bapak Dr. Agus Salim, M.Si., selaku Dekan Fakultas Sains dan Teknologi.

2. Ibu Arini, ST, MT., selaku ketua Program Studi Teknik Informatika, serta

Bapak Feri Fahrianto, M.Sc., selaku sekertaris Program Studi Teknik

Informatika.

3. Bapak Husni Teja Sukmana, Ph.D., selaku Dosen Pembimbing I dan

Bapak Victor Amrizal, M.Kom., selaku Dosen Pembimbing II yang telah

memberikan bimbingan, motivasi, dan arahan kepada penulis hingga

skripsi dapat selesai dengan baik.

4. Bapak Andrew Fiade, M.Kom., selaku Dosen Penguji I dan Bapak Rizal

Broer Bahaweres, S.Si, M.Kom., selaku Dosen Penguji II yang telah

memberikan kritik dan saran, serta memberi arahan kepada penulis.

5. Seluruh Dosen, Karyawan Fakultas Sains dan Teknologi, khususnya pada

Program Studi Teknik Informatika yang telah memberikan ilmu yang

bermanfaat, serta menjadi suri tauladan yang baik.

6. Bapak dan Ibu, yaitu alm. Achmad Sjatari dan Nurhayati Sjatari, serta

saudara dan saudari yang tak henti-henti nya memberikan semangat dan

viii


dukungan baik materil maupun moral.

7. Pihak SUDIN Penanggulangan Kebakaran dan Penyelamatan Jakarta

Selatan, Rama, dan Iptu Winam Agus selaku Kepala Tim Jaguar Polresta

Depok yang telah memberikan gagasan dan membagi pengalaman, serta

masukannya sehingga penulis mendapat sudut pandang lain dalam

menganalisa kebutuhan dalam skripsi yang dikerjakan.

8. Seluruh teman-teman TI UIN Jakarta angkatan 2013 khususnya pada

kelas B yang telah memberi dukungan serta memberi kritik dan saran nya

dalam pengembangan aplikasi yang dikerjakan.

9. Mba Yasmin, Abdurrahman, Muhammad Yusuf, Zainal Muttaqin, dan

Febrian Wahyu Ramadhan yang telah membantu pengujian aplikasi.

10. Seluruh pihak eksternal yang turut membantu baik secara langsung

maupun tidak langsung kepada penulis.

Penulis Menyadari masih terdapat banyak kekurangan dalam penulisan

skripsi ini, untuk itu penulis mengharapkan kritik dan saran yang bersifat

membangun, maupun bagi para penulis yang ingin turut mengembangkan aplikasi

serupa, diharapkan dengan mengirim e-mail ke [email protected] atau

dengan mengirim pesan ke nomor +6285717849479.

Jakarta, Februari 2019

Muchtar Prawira

ix


Nama : Muchtar Prawira

Program Studi : Teknik Informatika

Judul : Prototipe Aplikasi Manajemen Darurat Berbasis Android

ABSTRAK

Maraknya bencana yang menimpa baik bencana alam, bencana non alam, serta

bencana sosial membuat masyarakat harus meningkatkan kewaspadaan diri.

Pelaporan darurat kini dapat dilakukan pada pusat komando 112. Sistem

pelaporan darurat pun turut dikembangkan di berbagai peneliti, yang

mengimplementasikan panic button yang mana tujuannya mempercepat

pelaporan. Pada penelitian ini, penulis merancang prototipe aplikasi manajemen

darurat berbasis android menggunakan penentuan lokasi korban dengan jaringan

maupun GPS, serta dengan mengukur jarak dari penolong dan korban

menggunakan Distance Matrix API. Pelaporan darurat menggunakan aplikasi

dilakukan dengan 3 cara, dengan tombol di dalam aplikasi, tombol daya pada

perangkat, dan perintah suara. Hasil pengujian kelayakan dan performa aplikasi

yang dikembangkan berjalan dengan lancar, dengan rata-rata waktu yang

dibutuhkan aplikasi melakukan pelaporan hingga sampai kepada penolong yaitu

6,96 detik jika menggunakan tombol di dalam aplikasi, 21,08 detik jika

menggunakan tombol daya, dan 20,33 detik menggunakan perintah suara, serta

dibutuhkan 39,9 detik dari pelaporan tercatat hingga sampai kepada penolong

yang berjarak 251 hingga 500 meter. Disarankan pada penelitian selanjutnya,

aplikasi dapat berjalan di berbagai platform, serta terintegrasi kepada pihak

berwenang, serta meningkatkan akurasi lokasi korban.

Kata Kunci : Manajemen Darurat, Bencana, Teror, Kecelakaan,

Kebakaran, Location Based Service, Global Positioning

System, Speech Recognition

Jumlah Referensi : 7 Buku + 11 Jurnal + 21 Situs Web

Jumlah Halaman : VI BAB + XIV Halaman + 138 Halaman

x


Author : Muchtar Prawira

Study Program : Informatics Engineering

Title : Android Based Prototype Application for Emergency

Management

ABSTRACT

There is so many disasters which is by nature, non-nature, and even social

disaster make us to increase our cautious. From now on, emergency can be

reported by calling 112 command centers. Emergency reporting being developed

by many researchers like in Surabaya city, Depok, that implementing panic

button to acquire more time. At this research we developing an emergency

management prototype apps which pinpoint victim location using network based

or GPS, and also measure distance from helper and victim with a help of Distance

Matrix API. Emergency report can be done with 3 ways: with a button inside the

app, power button, and voice command. Result from worthiness and performance

testing shows that application runs smoothly, with average time needed to report

an emergency until it gets to helper 6.96 seconds if using button in app, 21.08

seconds if using power button, and 20.33 seconds if using voice command, also

39,9 seconds from emergency reported until it reach to helper in radius 251 to

500 meters. We suggest for future research that application should be developed

for another platform, integration to the authorities, and increase victim’s location

accuracy.

Keywords : Emergency Management, Disaster, Terror, Accident,

Wildfire, Location Based Service, Global Positioning

System, Speech Recognition.

Number of Reference : 7 Books + 11 Journals + 21 Websites

Number of Pages : VI Chapter + XIV Pages + 138 Pages

xi


DAFTAR ISI

LEMBAR PERSETUJUAN ................................................. Error! Bookmark not defined.

LEMBAR PENGESAHAN .................................................. Error! Bookmark not defined.

PERNYATAAN ORSINALITAS .......................................... Error! Bookmark not defined.

PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI UNTUK

KEPENTINGAN AKADEMIS ..................................................................................... vi

KATA PENGANTAR ................................................................................................... vii

ABSTRAK.................................................................................................................... ix

ABSTRACT .................................................................................................................. x

DAFTAR ISI ................................................................................................................ xi

DAFTAR GAMBAR ................................................................................................... xiv

DAFTAR TABEL ....................................................................................................... xvi

BAB I PENDAHULUAN ............................................................................................ 1

1.1. Latar Belakang ........................................................................................................... 1

1.2. Tujuan Penelitian ........................................................................................................ 6

1.3. Manfaat Penelitian...................................................................................................... 6

1.4. Rumusan Masalah ...................................................................................................... 6

1.5. Batasan Masalah ......................................................................................................... 6

1.6. Metodelogi Penelitian ................................................................................................ 7

1.7. Sistematika Penulisan ................................................................................................. 8

BAB II LANDASAN TEORI ...................................................................................... 9

2.1. Darurat dan Bencana .................................................................................................. 9

2.2. Definisi Terorisme ...................................................................................................... 9

2.3. Kecelakaan Lalu-lintas ............................................................................................... 9

2.4. Emergency Button ....................................................................................................10

2.5. Speech Recognition ..................................................................................................12

2.6. Location Based Service (LBS) ..................................................................................12

2.7. Global Positioning System (GPS) ............................................................................14

2.8. Unified Modelling Language (UML) .......................................................................16

2.9.1. Use Case Diagram ......................................................................................... 17

2.9.3. Sequence Diagram ......................................................................................... 17

2.9.4. Class Diagram ............................................................................................... 17

2.9. Rapid Application Development (RAD) ..................................................................18

2.10.1. Tahap – tahap pengembangan RAD ............................................................18

2.10.2. Keunggulan Menggunakan RAD ................................................................ 20

2.10.3. Kelemahan Menggunakan RAD ................................................................. 20

2.10. Sistem Operasi Android ......................................................................................... 20

2.11. PHP.........................................................................................................................21

2.12. Google Maps Platform ...........................................................................................21

xii


2.12. Distance Matrix API .......................................................................................21

2.13. Studi Literatur Sejenis ............................................................................................23

2.14. Alur Penelitian........................................................................................................24

BAB III METODOLOGI PENELITIAN ..................................................................... 27

3.1. Metode Pengumpulan Data ...................................................................................... 27

3.1.1. Wawancara .................................................................................................... 27

3.1.2. Observasi ....................................................................................................... 27

3.1.3. Studi Pustaka ................................................................................................. 27

3.2. Metode Pengembangan Sistem ................................................................................ 27

3.2.1 Requirements Planning Phase ........................................................................ 27

3.2.2. RAD Design Workshop .................................................................................28

3.2.3. Implementation Phase ...................................................................................29

BAB IV ANALISIS DAN IMPLEMENTASI ............................................................ 30

4.1. Identifikasi Masalah .................................................................................................30

4.2. Pengajuan Model ......................................................................................................35

4.3. Model Aplikasi .........................................................................................................36

4.4. Rancangan Sistem ....................................................................................................41

4.4.1. Use Case Diagram .........................................................................................42

4.4.2. Use Case Table ..............................................................................................44

4.4.3. Sequence Diagram .........................................................................................48

4.4.4. Class Diagram ............................................................................................... 55

4.4.5. Entity Relationship Diagram ......................................................................... 57

4.5. Desain Tampilan Aplikasi ........................................................................................59

4.5.1. Mock-up Design ............................................................................................59

4.6. Pembuatan Aplikasi Manajemen Darurat .................................................................65

4.6.1. Pelaporan Darurat Menggunakan Tombol yang Ada di Dalam Aplikasi .......65

4.6.2. Pelaporan Darurat Menggunakan Tombol Daya pada Perangkat ..................66

4.6.3. Pelaporan Darurat Menggunakan Perintah Suara ..........................................68

4.6.4. Interaksi Penolong Apabila Terdapat Korban di Sekitar ...............................69

BAB V HASIL DAN PEMBAHASAN.......................................................................... 72

5.1. Hasil Tampilan Antarmuka ....................................................................................... 72

5.2. Pengujian Kelayakan Aplikasi ................................................................................. 82

5.2.1. Skenario Pengujian Kelayakan Aplikasi .......................................................83

5.2.2. Hasil Pengujian Kelayakan Aplikasi ...........................................................100

5.3. Pengujian Performa Aplikasi ..................................................................................105

5.3.1. Skenario Pengujian Performa ......................................................................106

5.3.2. Hasil Pengujian Performa Aplikasi .............................................................110

BAB VI PENUTUP ................................................................................................. 115

6.1. Kesimpulan ............................................................................................................115

6.2. Saran .......................................................................................................................116

DAFTAR PUSTAKA ................................................................................................. 117

LAMPIRAN-LAMPIRAN ......................................................................................... 122

xiii


xiv


DAFTAR GAMBAR

Gambar 2.1. Kotak merah yang ada di kota yang diabaikan dari kehidupan

di New York. (metro, 2017) .................................................................................11

Gambar 2.2. Komponen LBS: User, Communication Network, Service Provider,

Content (Steineger et al, 2006) ............................................................................13

Gambar 2.4. Kumpulan satelit (nasa.gov) ...............................................................................14

Gambar 2.6. cara kerja GPS (elprocus.com) ...........................................................................15

Gambar 2.7. Trilaterasi pada GPS (gisgeography.com) ..........................................................16

Gambar 2.8. Desain RAD merupakan inti dari proses penembangan interaktif

(Kendall, 2011) ....................................................................................................19

Gambar 2.9 Alur Penelitian ..................................................................................................... 26

Gambar 4.1. Analisa sebab dan akibat, menggunakan fishbone diagram ...............................33

Gambar 4.2. Model aplikasi .................................................................................................... 37

Gambar 4.3. bencana individu pada korban ............................................................................38

Gambar 4.4. trigger aplikasi ....................................................................................................39

Gambar 4.5. cara kerja aplikasi di sisi korban ........................................................................40

Gambar 4.6. fitur lbs pada aplikasi .........................................................................................40

Gambar 4.7. navigasi penolong terhadap korban ....................................................................41

Gambar 4.8. use case diagram .................................................................................................43

Gambar 4.9. Sequence Diagram: Log in..................................................................................49

Gambar 4.10. Sequence Diagram: Emergency Report – Victim .............................................50

Gambar 4.11. Sequence Diagram: Emergency Report – Helper ............................................. 52

Gambar 4.12. Sequence Diagram: Active Emergency .............................................................54

Gambar 4.13. Class Diagram: Relasi Antar Kelas ..................................................................56

Gambar 4.14. Entity Relationship Diagram ............................................................................58

Gambar 4.15. Mock-up: Log in, Register, Main Activity .......................................................59

Gambar 4.16. Mock-up: Main Activity, History, Log In, Current Emergency - Home ...........61

Gambar 4.17. Mock-up: Current Emergency – Home, Current Emergency – Chat,

Current Emergency – Action, Main Activity ..................................................... 62

Gambar 4.18. Mock-up: Helper Notification, Helper Confirmation, Current Emergency,

Main Activity ....................................................................................................64

Gambar 4.19. Diagram alur proses pelaporan darurat dengan tombol yang ada pada

aplikasi ..............................................................................................................66

Gambar 4.20. Diagram alur pelaporan darurat menggunakan tombol daya pada perangkat .. 67

Gambar 4.21. Diagram alur proses pelaporan darurat menggunakan perintah suara ..............68

Gambar 4.22. Diagram alur proses interaksi penolong terhadap pelaporan darurat di

sekitar. ............................................................................................................... 70

Gambar 5.1. Alur Hasil tampilan antarmuka registrasi user ................................................... 72

Gambar 5.2. Alur Hasil tampilan antarmuka proses log in user ............................................. 74

xv


Gambar 5.4. Alur Hasil tampilan antarmuka membuka halaman pelaporan darurat

terkini, dengan kondisi tidak ada pelaporan darurat yang aktif ...........................75

Gambar 5.5. Alur Hasil tampilan antarmuka pelaporan darurat menggunakan tombol

pada halaman awal aplikasi ................................................................................. 76

Gambar 5.6. Alur Hasil tampilan antarmuka pelaporan darurat menggunakan tombol

daya pada smartphone dan melalui perintah suara ..............................................77

Gambar 5.7. Alur hasil tampilan antarmuka konfirmasi penolong kepada korban ................. 78

Gambar 5.8. Alur Hasil tampilan antarmuka membuka pelaporan darurat .............................79

Gambar 5.9. Alur Hasil tampilan antarmuka melihat dan berinteraksi pada halaman

pelaporan darurat yang sedang aktif ....................................................................80

xvi


DAFTAR TABEL

Tabel 2.2. Studi Literatur Sejenis ............................................................................................23

Tabel 4.1. Formasi Model yang diajukan pada penelitian ini ..................................................35

Tabel 4.2. Use Case Table .......................................................................................................44

Tabel 5.1. Deskripsi form registrasi ........................................................................................ 72

Tabel 5.2. Deskripsi halaman beranda.....................................................................................80

Tabel 5.3. Skenario Pengujian aplikasi ...................................................................................83

Tabel 5.4. Hasil pengujian aplikasi dengan 3 kali percobaan ................................................100

Tabel 5.5. Skenario Pengujian Performa Aplikasi .................................................................106

Tabel 5.6. Hasil pengujian performa aplikasi ........................................................................111

1


BAB I

PENDAHULUAN

1.1. Latar Belakang

“Dan Sungguh akan kami berikan cobaan kepadamu, dengan sedikit

ketakutan, kelaparan, kekurangan harta, jiwa dan buah-buahan, dan berikanlah

berita kabar gembira kepada orang-orang yang sabar. Yaitu orang-orang yang

apabila ditimpa musibah/teror, mereka mengucapkan ‘Inna lillahi wa inna ilaihi

raaji’uun’ (sesungguhnya kami adalah milik Allah dan kepada-Nya lah kami akan

kembali). Mereka itulah yang mendapat keberkatan yang sempurna dan rahmat

dari Tuhan mereka, dan mereka itulah orang-orang yang mendapat petunjuk.”

(Q.S. Al-Baqarah:155-157)

Musibah/krisis yang melanda di dunia dan khusus negeri kita adalah persis

seperti apa yang disebutkan di dalam firman Allah di atas. Maraknya ancaman

bom dan banyaknya kejahatan adalah sebagai pertanda bangsa ini sedang ditimpa

ketakutan. Banyaknya kaum yang kelaparan karena kurang makan, dan

kebutuhan ekonomi nya belum terpenuhi sebagai tanda yang lain bahwa bangsa

ini terlah dicoba dengan kelaparan dan kekurangan harta. Bangsa ini juga dicoba

dengan kekurangan jiwa dengan banyak nya aksi teror yang menewaskan ratusan

korban. (El-Sulthani, 2003)

Dunia kini dilanda ketegangan. Satu pihak ingin damai, di pihak lain ajak

perang. Masyarakat yang ingin damai salah mengambil langkah; langkah yang

ditempuh justru menciptakan peperangan. Pribadi yang berperang ingin damai,

tetapi jalanyang ditempuh menyengsarakan umat manusia. Salah langkah tersebut

menjadikan akumulasi meletusnya gerakan “nekad”. Maka muncullah teror

dimana-mana. (El-Sulthani, 2003)

Tindakan preventif untuk mencegah adanya tingakan radikalisme dan

2


terorisme ialah melalui penyuluhan agama, seperti menurut pernyataan Kepala

Sub Direktorat Pemberdayaan Masyarakat BNPT, Andi Intang Dulung “Penyuluh

agama selalu di garda terdepan memberikan penyuluhan ke masyarakat. Kami

ingin mereka membantu mensosialisasikan bahwa tidak ada ajaran agama apapun

yang mengajarkan terorisme, bahwa terorisme tidak dibenarkan dalam ajaran

agama.” (bnpt.go.id). Diluar itu, elit TNI yang bekerja sama dengan pihak

kepolisian terus melakukan upaya dalam menangani tindak terorisme.

Tidak semua aksi teror dapat ditanggulangi tepat waktu, seperti pada juni

2018 lalu, Nurdiana (66), merupakan korban aksi teror yakni perampokan yang

dialami di rumah setelah usai shalat. Pelaku merampok sejumlah harta milik

korban, dan tidak segan-segan membacok ketika bertemu Nurdiana hingga beliau

bersimbah darah di lantai (regional.kompas.com). Dilansir pada halaman Data

Informasi Bencana Indonesia (DIBI), dalam 10 tahun terakhir setidaknya terdapat

18 korban meninggal & hilang, dan 73 korban luka-luka akibat aksi teror /

sabotase (dibi.bnpb.go.id). Lain hal nya dengan aksi teror, bencana non-alam

lainnya pun merupakan masalah serius yang dihadapi, seperti kecelakaan lalu

lintas dan kesalahan manusia (human error).

Angka kematian dikarenakan kecelakaan lalu lintas terbilang tinggi, jika

dilihat dari angka kematian dan luka akibat kecelakaan. Mendekati 1,3 juta jiwa

secara global tiap tahun nya, juga 20 – 50 juta jiwa mengalami cidera maupun

kelumpuhan (asirt.org). Badan Pusat Statistik (BPS) mencatat angka kecelakaan

yang terjadi di Indonesia dari tahun 2012 hingga 2016, menunjukan jumlah yang

tinggi yaitu berkisar antara 26 ribu jiwa hingga 29 ribu jiwa per-tahun nya

(bps.go.id).

Bencana non-alam merupakan bencana yang diakibatkan oleh peristiwa

atau serangkaian peristiwa non alam antara lain berupa gagal teknologi, gagal

modernisasi, epidemi, dan wabah penyakit. Bencana ini turut menambah korban

jiwa, dengan angka 2.356 kejadian yang mengakibatkan 3.072 meninggal &

3


hilang, serta 3.507 korban mengalami luka-luka dalam 10 tahun terakhir

(dibi.bnpb.go.id). Meskipun angka kematian akibat bencana baik bencana

non-alam, maupun bencana sosial (konflik/ terorisme) fluktuatif cenderung

menurun tiap tahun nya, tindakan preventif dan penanggulangan guna

meminimalisir korban masih perlu dilakukan.

Berbagai cara untuk dapat melaporkan jika terjadi keadaan darurat, salah

satunya dengan menggunakan telepon seluler. Menteri Dalam Negri Tjahyo

Kumolo mengatakan, penyediaan nomor tunggal kedaruratan 112 ini sudah

sangat dibutuhkan masyarakat. Hal ini untuk memudahkan masyarakat dalam

penanggulangan keadaan darurat. "Selama ini kan nomor panggilan yang ada

milik kepolisian, ambulans, dan pemadam kebakaran berbeda-beda. Ke depan,

akan terintegrasi dalam layanan 112" dengan menggabungkan nomor panggilan

darurat yang sudah ada sebelumnya, seperti layanan kepolisian 110, ambulans

118, dan pemadam kebakaran 113 (republika.co.id).

Bagi masyarakat lanjut usia, menelfon ke nomor darurat merupakan

sistem yang ringkas jika dibandingkan dengan monitoring kondisi tubuh secara

terus-menerus. Desain pelaporan darurat terhadap lansia terus dilakukan, hingga

hanya dengan alat yang berisi tombol seperti Alert1 dan Philips HomeSafe

(Figueiredo, 2016).

Aplikasi darurat telah dikembangkan dengan mengimplementasi

one-touch-call pada smartphone ditunjukan sebagai Knock-to-Panic (KTP)

sebagai deteksi sinyal darurat. Algoritma KTP di desain untuk mengidentifikasi

gerakan knock-to-panic pada smartphone. Menekan dengan tangan sebanyak tiga

atau empat kali kepada smartphone yang berada pada posisi seimbang di kantong

celana panjang, atau di depan sabuk yang dikenakan pada bagian pinggul selama

2,5 detik untuk mengirim sinyal tanda bahaya kepada layanan darurat (Figueiredo,

2016).

Salah satu alasan yang paling umum penyebab kematian seseorang adalah

4


minim nya pertolongan pertama karena layanan darurat tidak mendapat informasi

terhadap kecelakaan tepat pada waktunya. Analisa menunjukan jika mengurangi

respon terhadap kecelakaan 1 menit, dapat meningkatkan kemungkinan

menyelamatkan nyawa seseorang hingga 6% (Evanco. William M. 1996). Guna

mengurangi waktu respon, peningkatan teknologi lalu lintas diperlukan agar

dapat mengurangi korban jiwa.

Sensor akselerasi pada smartphone dapat digunakan untuk mendeteksi

kecelakaan yang dialami korban, dan melaporkan kepada beberapa responden

terdekat yang akan membantu keadaan darurat ini dan menekan angka korban

jiwa sebanyak mungkin. Pengguna dapat mengaktifkan sensor akselerasi pada

background yang akan mendeteksi jika terjadi sentakan pada smartphone, dan

langsung mengirim tanda bahaya kepada responden darurat. Pengguna juga dapat

kesempatan selama 15 detik untuk menggagalkan alert jika terjadi false alert

(Khan, 2018).

Berteriak dapat dibilang salah satu sinyal komunikasi yang paling relevan

bagi manusia untuk bertahan hidup, yaitu dilakukan di berbagai situasi yang salah

satunya merupakan respon dari rasa takut. Teriakan bukan hanya digunakan untuk

menyampaikan bahaya, namun juga menyampaikan rasa takut kepada pendengar,

serta dapat meningkatkan kewaspadaan terhadap pendengar maupun bagi yang

berteriak (Arnal, 2015). Respon ini yang nantinya dapat digunakan sebagai

trigger aplikasi manajemen bencana untuk mengirim sinyal darurat selain dengan

menekan tombol dan menggunakan akselerasi pada smartphone.

Smartphone merupakan alat komunikasi yang sedang marak digunakan untuk

berinteraksi di era modern ini. Terbukti dari riset yang dilakukan oleh Nielsen

(Informate Mobile Insights) bersama Vserv selaku penyedia smart data untuk

mobile marketing and commerce, yaitu “basis pengguna smartphone di Indonesia

dari tahun ke tahun tumbuh 33% sejak 2013. Pertumbuhan pesat di pasar

smartphone Indonesia ini didorong oleh penduduk dengan usia di bawah 30 tahun

5


-- sekitar 61% dari seluruh pengguna”. (inet.detik.com).

Pada statisik global penggunaan smartphone yang dilansir pada situs

www.statista.com, berdasarkan pengamatan prediksi penggunaan smartphone

dari tahun 2013 sampai 2019, menunjukan penggunaan smartphone diprediksi

pada tahun 2017 akan mencapai angka 4.77 miliar pengguna smartphone.

Manajemen darurat menggunakan smartphone guna mempersingkat waktu

respon kepada korban. Masalah yang terjadi umumnya mengalami kendala

kesulitan menghubungi nomor telepon instansi terkait. Menggunakan Location

Based Service (LBS) diimplementasikan dengan mengambil lokasi korban

menggunakan LBS menjadi acuan jarak yang akan digunakan untuk

menampilkan nomor telepon instansi yang terdekat (Retnoningsih, 2016).

Selain menggunakan LBS, penentuan lokasi yang berkembang pada era ini

yaitu menggunakan Global Positioning System (GPS). GPS menyediakan

layanan yang baik ketika digunakan pada ruangan terbuka, namun penggunaan

penentuan lokasi ini kurang efektif ketika digunakan di dalam ruangan karena

masih menggunakan transmisi line-of-sight (LOS). Salah satu teknologi yang

dapat dimanfaatkan untuk indoor location ialah dengan teknologi nirkabel

(wireless) (Erwin Dari, 2018).

Berbagai metode yang dapat digunakan untuk menentukan lokasi pada

ruangan tertutup, yaitu dengan Wireless Local Area Network (WLAN), Bluetooth,

radio, dan lain sebagainya (Jiang, 2015). Metode Received Signal Strength (RSS)

Fingerprint merupakan satu dari berbagai metode popular untuk menentukan

lokasi di ruangan tertutup, yaitu dengan memanfaatkan kekuatan sinyal yang

didapat dari access point (AP) maupun wi-fi yang tersedia. Informasi yang

diperoleh dari RSS digunakan dalam menentukan lokasi menggunakan kekuatan

sinyal yang ada (Erwin Dari, 2018).

Permasalahan ini yang mendorong penulis untuk melakukan sebuah

penelitian yang berjudul “PROTOTIPE APLIKASI MANAJEMEN

6


DARURAT BERBASIS ANDROID.“

1.2. Tujuan Penelitian

Merancang aplikasi yang cocok untuk manajemen darurat dengan

melengkapi dari penelitian sebelumnya dengan menambahkan trigger button dan

voice command, serta menggunakan tools LBS dan GPS dengan

mempertimbangkan bagaimana cara korban melapor, waktu yang dibutuhkan

untuk korban melapor dan respon penolong, serta keakuratan data korban saat

melapor.

1.3. Manfaat Penelitian

Manfaat hasil kegiatan penelitian adalah adanya prototipe aplikasi yang

dijadikan sebagai tindakan preventif dan penanggulangan darurat.

1.4. Rumusan Masalah

1. Aplikasi apa yang cocok untuk dapat digunakan sebagai manajemen

darurat dengan mempertimbangkan bagaimana cara korban melapor,

waktu yang dibutuhkan untuk korban melapor dan respon penolong,

serta keakuratan data korban saat melapor?

2. Bagaimana cara pengguna melapor darurat dan berapa banyak cara yang

digunakan agar pelaporan dapat dilakukan melalui aplikasi?

3. Bagaimana tingkat akurasi data korban serta kecepatan pelaporan pada

aplikasi apabila korban hendak melapor menggunakan aplikasi?

1.5. Batasan Masalah

Agar bahasan masalah tidak keluar konteks, penulis memberikan beberapa

batasan masalah, yaitu:

1. Aplikasi ditunjukan sebagai penghubung antara korban dan pihak

penolong, namun tidak terintegrasi dengan pihak penanganan darurat

(polisi, pemadam kebakaran, dan lainya).

2. Aplikasi bertujuan mengirim informasi kepada penolong saat ada korban

yang membutuhkan pertolongan di sekitar dengan jarak yang telah

7


ditentukan.

3. Sistem diimplementasikan pada smartphone android, dan membutuhkan

koneksi internet dalam pengaplikasiannya.

4. Bahasa yang digunakan untuk mengembangkan aplikasi adalah java

dengan menggunakan tools IDE android studio.

1.6. Metodelogi Penelitian

Dalam menyusun skripsi ini, penulis melakukan beberapa metode untuk

memperoleh data atau informasi dalam menyelesaikan permasalahan:

1. Studi Literatur

Melalui studi ini penulis memperoleh data atau informasi yang ada dengan

mengumpulkan, mempelajari, serta membaca berbagai referensi baik itu

yang bersumber dari ebook, jurnal, makalah, internet, dan berbagai

sumber lainnya yang menunjang dalam penulisan skripsi ini.

2. Wawancara

Wawancara dilakukan guna melengkapi model aplikasi yang akan dibuat.

Wawancara dilakan kepada 3 narasumber, yaitu: Tim Jaguar Polresta

Depok sebagai personel yang ahli dalam menangani teror, Sudin

Penanggulangan Kebakaran dan penyelamatan kota administrasi Jakarta

Selatan guna mengambil sudut pandang petugas saat melakukan

penyelamatan, serta Rama yaitu korban perampokan guna mengambil

perspektif aksi teror yang menimpa beliau.

3. Perancangan Sistem

Merancang sistem mmanajemen darurat yang melibatkan pencarian

korban terdekat menggunakan Distance Matrix API. Pelaporan darurat

dilakukan dengan cara menekan tombol yang ada di dalam aplikasi,

tombol daya, dan perintah suara terhadap perangkat menggunakan bahasa

pemograman java dan IDE android studio.

4. Pengujian Sistem

8


Melakukan pengujian kelayakan dan performa pada aplikasi yang telah

dikembangkan di perangkat yang berbeda-beda.

1.7. Sistematika Penulisan

Dalam penulisan skripsi ini dibagi menjadi beberapa bab, yaitu:

BAB I PENDAHULUAN

Bab ini terdiri dari latar belakang, rumusan masalah, batasan

masalah, tujuan, manfaat, metodelogi penelitain, dan sistematika

penulisan.

BAB II LANDASAN TEORI

Bab ini berisi uraian tentang landasan teori yang diperlukan dalam

perancangan aplikasi manejemen darurat.

BAB III METODELOGI PENELITIAN

Bab ini menguraikan secara rinci metodelogi yang digunakan dalam

implementasi aplikasi manajemen darurat.

BAB IV ANALISIS DAN IMPLEMENTASI

Bab ini akan dijelaskan mengenai pembahasan tentang perancangan

aplikasi manajemen darurat.

BAB V HASIL DAN PEMBAHASAN

Bab ini akan dijelaskan mengenai pembahasan tentang hasil dan

pembahasan penelitian aplikasi manajemen darurat.

BAB VI PENUTUP

Bab ini berisi kesimpulan akhir dan saran-saran untuk penelitian

tentang perancangan aplikasi manajemen darurat.

9


BAB II

LANDASAN TEORI

2.1. Darurat dan Bencana

Darurat menurut Kamus Besar Bahasa Indonesia (KBBI) merupakan keadaan

sukar (sulit) yang tidak tersangka-sangka (dalam bahaya, kelaparan, dan

sebagainya) yang memerlukan penanggulangan segera. Bencana /ben·ca·na/

sesuatu yang menyebabkan (menimbulkan) kesusahan, kerugian, atau penderitaan;

kecelakaan; bahaya. (kbbi.web.id) Bencana dapat di kategorikan menjadi 3

bagian, bencana alam (gunung meletus, gempa, tsunami), bencana non-alam

(kecelakaan, kebakaran, hama), dan bencana sosial (konflik, dan aksi terror)

(dibi.bnpb.go.id).

2.2. Definisi Terorisme

Terorisme secara etimologis berasal dari bahasa latin yaitu ‘terrere’ yang

artinya menakut-nakuti”. Kata teror sendiri berasal dari bahasa latin ‘terrorem’

yang memiliki arti rasa takut yang luar biasa. Pengertian terorisme digunakan

untuk menggambarkan sebuah serangan yang disengaja terhadap ketertiban dan

keamanan umum. Terorisme juga dapat diartikan menakut nakuti atau

menyebabkan ketakutan, sedangkan teroris berarti orang atau pihak yang selalu

menimbulkan ketakutan pada pihak lain. (Purwawidada, 2014).

2.3. Kecelakaan Lalu-lintas

Kecelakaan adalah benturan atau sentuhan benda keras atau benda cair

(kimiawi) atau gas, atau api yang datangnya dari luar, terhadap badan (jasmani)

seseorang, yang mengakibatkan kematian atau cacat atau luka, yang sifat dan

tempatnya dapat ditentukan oleh dokter (kamusbesar.com). Sedangkan

kecelakaan lalu lintas adalah “Suatu peristiwa dijalan yang tidak disangka-sangka

dan tidak disengaja melibatkan kendaraan dengan atau tanpa pemakai jalan

10


lainnya mengakibatkan korban manusia atau kerugian harta benda,” menurut

pasal 93 Peraturan Pemerintah Nomor 43 tahun 1993 ayat 1.

World Health Organization (WHO) mencatat lebih dari 1,25 juta jiwa

meninggal tiap tahun nya akibat kecelakaan lalu lintas, 90% kecelakaan di dunia

terdapat pada negara menengah kebawah. Adapun faktor yang menyebabkan

kecelakaan yaitu (who.int):

1. Berkendara terlalu cepat. Pertambahan akselerasi kendaraan sebanding

lurus dengan terjadi kecelakaan atau penyebab kecelakaan.

2. Perngaruh alcohol dalam berkendara. Mengkonsumsi alcohol dan

semacamnya dapat menanbah resiko kecelakaan hingga 5x jika

disbandingkan dengan yang tidak mengkonsumsi.

3. Tidak menggunakan helm, tidak menggunakan seat-belts, dan tidak

memakai penahan pada anak kecil.

4. Tidak fokus berkendara. Penggunaan ponsel saat berkendara dapat

meningkatkan 4x resiko kecelakaan.

5. Infrastruktur jalanan yang rusak.

2.4. Emergency Button

Berbagai cara untuk melaporkan keadaan darurat kepada pihak terkait. Pada

New York City (NYC) terdapat 15.000 emergency call buttons dengan

penampilannya yang sudah menua berwarna merah yang biasanya berdekatan

dengan lampu merah dan lampu jalan, yang mungkin terlihat tidak modern untuk

melaporkan situasi darurat. (metro, 2017)

11


Gambar 2.1. Kotak merah yang ada di kota yang diabaikan dari kehidupan di

New York. (metro, 2017)

Emergency button pada NYC memang di desaian sangat sederhana, yaitu

guna menghubungi departemen polisi setempat maupun pemadam kebakaran

melalui telefon yang ada pada alat tersebut dengan hanya menekan tombol.

Tombol darurat ini pada desain terbaru terdapat 2 tombol, yaitu tombol untuk

menghubungi polisi berwarna biru muda, dan petugas pemadam kebarakan

berwarna merah. (metro, 2017)

Adapun tombol darurat lainnya yang biasanya terpasang pada tiap Gedung

dan cara kerjanya antara lain (safety.unimelb.edu.au):

1. Fire Break Glass Alarm (BGA)

Gedung yang dilengkapi BGA, memudahkan personel yang ada di dalam

Gedung untuk melaporkan jika terjadi keadaan situasi darurat kepada

petugas pemadam kebakaran. Menekan tombol yang ada di alat ini akan

langsung menghubungi petugas dan petugas dapat langsung menuju

Gedung tersebut, dengan kaca yang mudah hancur dengan satu kepalan

tangan atau dengan pena.

2. Emergency Break Glass Alarm

Sebuah Gedung memungkinkan terdapat alat emergency break glass

12


alarm. Alarm ini berbeda dengan fire break glass alarm, karena dengan alat

ini, tidak lagi menghubungi petugas pemadam kebakaran. Alarm ini

mengaktivasi EWIS (Electrical Wiring Interconnection System) guna

menginisiasikan evakuasi gedung tersebut.

2.5. Speech Recognition

Speech recognition atau Pengenalan ucapan, kemampuan perangkat untuk

menanggapi perintah yang diucapkan. Pengenalan ucapan memungkinkan kontrol

hands-free dari berbagai perangkat dan peralatan (kelebihan bagi banyak

penyandang disabilitas), menyediakan masukan untuk terjemahan otomatis, dan

menciptakan dikte siap cetak. Di antara aplikasi paling awal untuk pengenalan

suara adalah sistem telepon otomatis dan perangkat lunak pendiktean medis. Ini

sering digunakan untuk dikte, untuk query database, dan untuk memberikan

perintah ke sistem berbasis komputer, terutama dalam profesi yang

mengandalkan kosakata khusus. Ini juga memungkinkan asisten pribadi di

kendaraan dan telepon pintar, seperti Apple Siri (britannica.com).

2.6. Location Based Service (LBS)

Location Based Service (LBS) dapat diartikan sebagai service yang

mengintegrasi antara lokasi atau posisi mobile device, dengan informasi lainnya

guna menambah nilai kepada pengguna. (Gray, 2004)

LBS menggunakan lokasi geografis dari perangkat individu baik berupa

Personal Digital Assistant (PDA), smartphone, atau perangkat navigasi. Layanan

ini dapat menggunakan satellite navigation receiver’s yang tertanam pada

perangkat atau menggunakan teknologi network-based, diantaranya

menggunakan indentifikasi melalui seluler. (gsa.europa.eu)

13


Gambar 2.2. Komponen LBS: User, Communication Network, Service Provider,

Content (Steineger et al, 2006)

Ketika user menggunakan LBS, berbagai elemen infrastruktur dibutuhkan.

Pada gambar 2.2, ditunjukan komponen dasar yaitu diantaranya (Steineger et al,

2006):

1. Mobile Device (User) : sebuah alat bagi user mengakses informasi

yang dibutuhkan. Hasilnya dapat berupa suara, foto, teks, dan lain

sebagainya. Perangkat yang dapat digunakan berupa PDA, Mobile

Phone, Laptops, dan juga tidak menutup kemungkinan menggunakan

perangkat navigasi yang disediakan kepada beberapa mobil.

2. Communication Network : komponen yang berguas untuk mentransfer

data user, service request dari mobile terminal ke server dan

mengembalikan informasi tersebut ke user.

3. Positioning Component : dalam proses yang dilakukan pada LBS, pada

umumnya lokasi user harus ditentukan. Posisi user dapat ditentukan

menggunakan mobile connection network atau dapat menggunakan

Global Positioning System (GPS). Kemungkinan untuk menentukan

14


lokasi kedepannya dapat menggunakan stasiun WLAN, active badges,

atau menggunakan radio beacon.

4. Service and Application Provider : service provider memberikan

beberapa servis yang berbeda sesuai permintaan user. Menghitung atau

menentukan lokasi merupakan salah satu servis yang disajikan,

menemukan rute perjalanan, mencari yellow page, yaitu tempat mencari

informasi nomor telefon atau alamat sebuah perusahaan (inet.detik.com).

5. Data and Content Provider : Service provider biasanya tidak

menyimpan dan mengola informasi data yang di request oleh user. Basis

geografis dan informasi data lokasi pada umumnya di request dari pihak

pengelola (e.g. mapping agency) atau pengusaha bisnis dan industry (e.g.

yellow page).

2.7. Global Positioning System (GPS)

Gambar 2.4. Kumpulan satelit (nasa.gov)

Global Positioning System (GPS) merupakan space-based radionavigaation

system dari Amerika Serikat yang membantu dalam menentukan titik dari posisi

3 dimensi dengan akurasi hingga skala meter (Latitude, longitude, dan altitude)

dan menyajikan presisi waktu hingga nano-second di seluruh permukaan bumi.

(nasa.gov)

15


GPS merupakan satelit sistem navigasi yang biasa digunakan untuk

menentukan posisi di permukaan dari sebuah objek. Teknologi GPS pertama kali

digunakan pada pasukan militer amerika pada tahun 1960 dan berkembang

hingga dapat digunakan oleh masyarakat luas beberapa tahun berikutnya.

(techterms.com)

Kumpulan satelit kurang lebih sebanyak 24 satelit dari pemerintahan

Amerika Serikat yang dikerahkan pada luar angkasa 20.200 kilometer diatas

permukaan bumi. Satelit ini yang nantinya mengitari bumi setiap 12 jam ini rata

tersebar yang di distribusi pada 6 pesawat orbit dengan lereng 55 derajat dari

katulistiwa pada Medium Earth Orbit (MEO). (nasa.gov)

Pada tiap satelit GPS, memancarkan pesan yang berupa posisi satelit terkini,

orbit, dan waktu. Sebuah GPS receiver menggabungkan beberapa data dari

beberapa satelit untuk dapat menentukan posisi yang akurat menggunakan proses

yang dinamakan triangulasi. 3 satelit dibutuhkan agar dapat menentukan lokasi

dari penerima (receiver), melalui koneksi hingga 4 satelit guna menambah tingkat

akurasi. (techterms.com)

Gambar 2.6. cara kerja GPS (elprocus.com)

Cara kerja pada GPS ialah berdasarkan konsep ‘trilaterasi”. Posisi ditentukan

oleh pengukuran jarak ke satelit. Pada gambar 2.6 dijelaskan bahwa 4 satelit

digunakan untuk menentukan posisi dari gps receiver di muka bumi. Lokasi

target dikonfirmasi oleh satelit ke-4, sedangkan ketiga satelit lainya mencatat

16


lokasi penerima GPS. GPS receiver mengambil informasi dari satelit dan

menggunakan metode triangulasi untuk menentukan posisi yang tepat.

(elprocus.com)

Gambar 2.7. Trilaterasi pada GPS (gisgeography.com)

Satelit GPS menyiarkan lokasi dan waktu, trilaterasi digunakan untuk

menghitung jarak untuk menentukan posisi dari user yang tepat di muka bumi.

Satelit yang mengitari bumi menyiarkan sinyal berupa lingkaran. Jika posisi dari

GPS Receiver bergerak, maka radius dari tiap satelit akan berubah. Tiap satelit

merupakan titik tengah dari masing-masing lingkaran. Setiap lingkaran yang

bersinggungan, menentukan posisi dari GPS receiver. (gisgeography.com)

2.8. Unified Modelling Language (UML)

Pemodelan merupakan desain awal dari aplikasi perangkat lunak sebelum

memprogram aplikasi tersebut. Merupakan bagian yang esensial dari projek, baik

projek sekala besar, menengah, maupun kecil. Menggunakan model, tanggung

jawab kesuksesan dari pembangunan projek perangkat lunak dapat dipastikan

dengan sendirinya dari fungsi bisnis, selesai dan benar, kebutuhan dari end-user

terpenuhi, dan desain program menyokong persyaratan skalabilitas (uml.org)

UML berguna untuk menspesifikasi, visualisasi, dan model dokumen dari

sistem perangkat lunak, termasuk kepada struktur dan desain demi memenuhi

17


kebutuhan pada pengembagan perangkat lunak. UML memberikan standar

penulisan sebuah sistem blueprint, yang meliputi konsep proses bisnis, skema

basis data, dan komponen lain yang diperlukan. (uml.org)

Terdapat enam yang sering digunakan pada diagram UML, antara lain:

(Kendall, 2011)

1. Use Case Diagram. Menjelaskan bagaimana sebuah sistem digunakan.

Analis memulai dengan membuat use case diagram.

2. Use Case Scenario. Menjelaskan secara verbal dari pengecualian dari

tingkah laku yang dijelaskan pada use case utama.

3. Sequence Diagram. Menunjukan urutan aktifitas dan relasi antar class.

Setiap use cacse dapat membuat satu atau lebih sequence diagram.

4. Class Diagram. Menampilkan relasi antar class.

2.9.1. Use Case Diagram

Use Case Diagram merupakan salah satu diagram yang berguna untuk

pemodelan aspek perilaku sistem. Masing-masing dari use case menunjukan

kepada sekumpulan use case, actor, dan hubungan. Diagram use case

berguna dalam menvisualkan, menspesifikasim dan mendokumentasi

kebutuhan dari perilaku sebuah sistem. Interaksi pada use case dilakukan

antara aktor (Ritzkal, 2014)

2.9.3. Sequence Diagram

Sequence Diagram menunjukan interaksi dengan menampilkan setiap

partisipan dengan garis alir (flow line) secara vertikal dan pengurutan pesan

dari atas kebawah. Diagram ini hanya menunjukan barisan kejadian. (Ritzkal,

2016)

2.9.4. Class Diagram

Class Diagram mendeskripsikan tentang jenis – jenis objek dalam

sebuah sistem dan berbagai macam hubungan statis yang terdapat diantara

objek tersebut. Class diagram juga merupakan ciri, operasi sebuah class dan

18


batasan – batasan yang terdapat dalam hubungan objek. UML menggunakan

istilah dan fitur sebagai istilah umum yang meliputi ciri dan operasi sebuah

class. (Ritzkal, 2016)

2.9. Rapid Application Development (RAD)

Software Development Life Cycle (SDLC) merupakan sebuah proses yang

menggambarkan metode dan strategi dari desain pengembangan dari sebuah

projek perangkat lunak dan mempertahankan semua tujuan pencapaian, objektif,

fungsional dan kebutuhan user terpenuhi. (Kushwaha et al, 2006) salah satu

model dari SDLC adalah RAD.

RAD mempunyai fitur kunci dari model inkremental. Model ini

menggunakan pengembangan paralel antara fungsionalitas dan fitur berlangsung

seperti halnya projek yang independen. Pengembangan mempunyai tengat waktu

yang ketat. Setiap pengembangan diserahkan dan digabungkan menjadi satu

kesatuan prototipe. (Laura C. Rodriguez Martinez, Manuel Mora, Francisco, J.

Alvarez, 2009)

2.10.1. Tahap – tahap pengembangan RAD

Perancangan menggunakan RAD mulai dengan pengumpulan analisa,

baik identifikasi masalah, dan perancangan aplikasi. Selanjutnya menuju

tahap pengembangan yang mana pembuatan aplikasi dan desain dilakukan

secara bersama. Fase terakhir merupakan tahap implementasi, ilustrasi

pengembangan menggunakan RAD dapat dilihat pada Gambar 2.7. Desain

RAD merupakan inti dari proses penembangan interaktif (Kendall, 2011).

19


Gambar 2.8. Desain RAD merupakan inti dari proses penembangan interaktif

(Kendall, 2011)

Terdapat tiga fase utama pada RAD yang mengikutsertakan kedua pihak,

yaitu antara user dengan analis pada penilaian, desain, dan implementasi. RAD

melibatkan user pada tiap bagian dari pengembangan, dengan partisipasi yang

intens kepada proses bisnis dalam sebuah perancangan. (Kendall, 2011)

1. Fase perencanaan kebutuhan (Requirement Planning Phase)

User dan analis bertemu guna menentukan objektif dari sebuah

aplikasi atau sistem guna mengindentifikasi kebutuhan-kebutuhan

yang muncul dari objektif tersebut. Fase ini membutuhkan

keterlibatannya antara kedua pihak secara intensif, sehingga tidak

hanya menandatangani proposal atau dokumen, namun ikut andil

dalam perancangan kebutuhan aplikasi atau sistem yang akan

dikembangkan.

2. Fase Desain Workshop (Design Workshop Phase)

Desain workshop merupakan fase desain dan penyaringan yang dapat

dikategorikan sebagai workshop. Selama dalam proses desain, user

merespon kepada prototipe yang sesuai, dan analis bertugas dalam

20


menyaring desain yang berdasar terhadap respon dari user. Keaktifan

dan pengalaman kedua pihak menentukan hasil akhir dari sistem.

3. Fase Implementasi (Implementation Phase)

Tahap sebelumnya, merupakan tahap dimana analis dan user bekerja

sama menentukan desain bisnis atau aspek yang tidak teknis pada sebuah

sistem. Ketika aspek telah disetujui dan sistem telah dibangun dan

disaring atau ditinjau kembali, akan diuji secara keseluruhan maupun

beberapa bagian lalu dikenalkan kepada organisasi tersebut.

2.10.2. Keunggulan Menggunakan RAD

Kelebihan dalam menggunakan modul RAD dalam pengembangan

perangkat lunak antara lain: (Arora, 2016)

1. Pemeriksaan awal dapat dilakukan secepatnya.

2. Pengurangan waktu pengembangan yang cukup besar

3. Integrasi dari awal, dapat memecahkan isu kunci

4. Ulasan balik dari klien memberi nilai tambah.

2.10.3. Kelemahan Menggunakan RAD

Kelemahan dalam menggunakan model RAD dalam pengembangan

perangkat lunak antara lain: (Arora, 2016)

1. Ketergantungan yang cukup besar dari keahlian pembuatan

model

2. Sistem yang modular dapat dikembangkan

3. Biaya dari pembuatan model dan automatisasi pembuatan kode

cukup besar

2.10. Sistem Operasi Android

Android adalah sistem operasi yang bersifat open-source. Merupakan variasi

dari Linux, yang mana memberikan keluasan dalam hal keamanan, modularitas,

dan produktifitas pada level mobile device. Android dikembangkan dan diawasi

oleh organisasi yang bernama “Open Headset Alliance” (OHA). OHA didirikan

21


pada tahun 2007 dengan Google sebagai anggota yang terkemuka. OHA termasuk

dalam banyak perusahaan terkemuka di bidang hardware dan software (Cardle,

2016).

2.11. PHP

Php merupakan singkatan dari Hypertext Preprocessor, yaitu bahasa

pemograman terbuka (open source) yang cocok digunakan untuk

mengembangkan website dan dapat disatukan dengan bahasa pemograman

HTML. Sebagai contoh dalam pengaplikasiannya: (php.net)

<!DOCTYPE HTML>

<html>

<head>

<title>Example</title>

</head>

<body>

<?php

echo “hai, saya skrip PHP!";

?>

</body>

</html>

Alih-alih banyak perintah untuk menghasilkan HTML (seperti yang terlihat

dalam C atau Perl), halaman PHP berisi HTML dengan kode tertanam yang

melakukan "sesuatu" (dalam hal ini, hasilkan "Hai, saya skrip PHP!"). Kode PHP

terlampir dalam instruksi pemrosesan awal dan akhir khusus <? Php dan?> Yang

memungkinkan Anda untuk masuk dan keluar dari "mode PHP." (php.net)

2.12. Google Maps Platform

Google Maps Platform disediakan oleh Google guna membantu pengembang

aplikasi menanamkan Google Maps ke halaman web atau dengan menerima dan

mengolah data yang telah di sediakan oleh Google Maps baik dalam penggunaan

sekala kecil maupun dengan skala besar. (developers.google.com)

2.12. Distance Matrix API

Distance Matrix API merupakan salah satu servis yang dikeluarkan

22


oleh Google Maps Platform, yang mana menyediakan data jarak dan waktu

perjalanan dari matriks asal dan tujuan, dengan rekomendasi rute antara

kedua titik tesebut.

Sebagai contoh, dalam pengapliksaiannya, Distance Matrix API

melalui antarmuka HTTP, dengan permintaan yang dikonstruksikan dalam

bentuk sebuah rangkaian URL (Uniform Resource Locator) dengan

menggunakan asal dan tujuan, disertai dengan kunci API. Adapun format

rangkaian URL dan hasil data dalam berbentuk JSON dalam penggunaan

Distance Matrix API adalah sebagai berikut:

URL:

https://maps.googleapis.com/maps/api/distancematrix/json?origi

ns=[Lokasi_Asal]&destinations=[Lokasi_Tujuan]&key=[Kunci_API]

Hasil:

{

"destination_addresses" : [ "New York, NY, USA" ],

"origin_addresses" : [ "Washington, DC, USA" ],

"rows" : [

{

"elements" : [

{

"distance" : {

"text" : "225 mi",

"value" : 361715

},

"duration" : {

"text" : "3 hours 49 mins",

"value" : 13725

},

"status" : "OK"

}

]

}

],

23


"status" : "OK"

}

2.13. Studi Literatur Sejenis

Studi literatur sejenis ditujukan guna melihat kontribusi penelitian jika

dibandingkan dengan peneliti sebelumnya, tabel perbandingan dapat dilihat pada

Tabel 2.2. Studi Literatur Sejenis.

Tabel 2.2. Studi Literatur Sejenis

N

o Peneliti

Tools Trigger Method

L

B

S

G

P

S

Tekan

tombo

l

Akse

leras

i

Perint

ah

suara

Buka

aplika

si

tel

efo

n

Backgrou

nd

Detection

1 Retnoningsi

h, 2016 √ √ √

2

Khan,

Arsalan.,

2018

√ √ √ √

3

Mohammed,

Osman.,

2018

√ √ √ √ √

4

Figueiredo,

Isabel N.,

2016

√ √ √ √ √

- Kontribusi

Penelitian √ √ √ √ √ √

Pada tabel Tabel 2.2, dijelaskan penelitian sebelumnya yang

mengembangkan aplikasi dengan tujuan manajemen darurat, dengan tanda

centang (√) menunjukan fitur yang terdapat dalam penelitian tersebut. Terlepas

dari 4 studi literatur diatas, pnelitian yang dilakukan oleh Figueiredo, merupakan

penggambaran yang tepat bagi penulis untuk observasi dan sebagai acuan

perancangan manajemen darurat, yang mana menggunakan algoritma

knock-to-panic (KTP) atau dengan mengetuk layar perangkat untuk mengirim

sinyal bahaya. Tak lupa penelitian lainnya turut membantu dalam perumusan

24


prototipe aplikasi manajemen darurat, seperti yang dikemukakan oleh Retnonigsih,

yang mana menggunakan LBS sebagai pengukuran jarak dari korban ke pihak

teerkait, Mohammed yang menggunakan kondisi korban terkini agar dapat

ditangani sementara sebelum datangnya ambulans, dan khan yang

mengembangkan aplikasi pendeteksian darurat dengan 15 detik untuk

membatalkan laporan sehingga tidak terjadi false alert.

2.14. Alur Penelitian

Alur penelitian, yaitu tahapan atau prosedur penelitian untuk menganalisa

masalah, kebutuhan, dan solusi dalam pengembangan prototipe aplikasi

manajemen darurat, yang dijelaskan pada Gambar 2.9 Alur Penelitian. Dibagi

menjadi empat bagian, yaitu perumusan latar belakang, perancangan awal,

implementasi, dan pengujian aplikasi.

Pada perumusan latar belakang, dimulai dari eksplorasi masalah yang

terdapat dalam penanggulangan darurat saat ini (dijelaskan lebih detail pada

gambar 4.1). Eksplorasi masalah dilakukan guna menentukan fokus masalah yang

akan diangkaat pada penelitian kali ini. Selanjutnya pencarian studi literatur

sejenis (tabel 2.2) guna memperkuat teori yang dipaparkan, serta penulis

melakukan wawancara kepada tiga pihak guna mengambil beberapa sudut

pandang, yang diantaranya: Pihak SUDIN Penanggulangan Kebakaran dan

Penyelamatan Kota Administrasi Jakarta Selatan, Bang Rama sebagai salah satu

korban pembegalan, dan Iptu Winam Agus selaku Ketua Tim Jaguar Polresta

Depok. Ketiga perumusan latar belakang ini menghasilkan perancangan solusi

awal yang akan dilanjutkan pada baigan “Perancangan Awal” pada alur

penelitian.

Perancangan awal dilakukan dengan pengumpulan analisa kebutuhan,

pengajuan model berdasarkan analisa tentang manajemen darurat, dan

perancangan kebutuhan lainnya, yaitu: use case diagram, sequence diagram,

class diagram, dan entity relationship diagram. Dari perancangan awal, maka

25


dapat dilakukan implementasi, yaitu pembuatan prototipe aplikasi menggunakan

metode pengembangan RAD atau Rapid Application Development.

Pada tahap implementasi, perancangan desain dan pembuatan aplikasi

dilakukan secara bersamaan. Pada perancangan desain dilakukan pembuatan

mock up desain menggunakan tools balsamiq mockups 3, lalu pembuatan nama

aplikasi, dan perancangan UI atau user interface. Pada saat yang bersamaan,

dilakukan pembuatan aplikasi yaitu: perumusan algoritma inti dan pembuatan

aplikasi pada android sebagai aplikasi utama nya, dan php sebagai penghubung

ke database yang dipakai.

Selesai tahap implementasi, masuk ke tahap pengujian aplikasi. Pengujian

aplikasi, penulis melakukan dua kali penngujian, yaitu pengujian kelayakan, yaitu

pengujian yang bertujuan mengetahui apakah aplikasi terdapat kendala dalam

penggunaannya. Selanjutnya pengujian performa aplikasi, yaitu pengujian yang

ditujukan agar mengetahui kecepatan aplikasi dalam melakukan pelaporan dari

setiap cara pelaporan yang nantinya akan dijelaskan pada bab V.

Aplikasi yang tidak lolos uji coba, akan dilakukan perbaikan terlebih dahulu,

n amun jika lolos uji coba kelayakan, maka hasil dari pengujian kelayakan dan

performa akan menjadi hasil pembahasan dan kesimpulan dari penelitian ini. Alur

penelitian dapat dilihat pada gambar 2.9 Alur Penelitian.

26


Gambar 2.9 Alur Penelitian

27


BAB III

METODOLOGI PENELITIAN

3.1. Metode Pengumpulan Data

Dalam proses penelitian, penulis mengumpulkan data sebagai acuan

penelitan yang dilakukan dengan 3 cara, yaitu: wawancara, observasi, dan studi

literatur.

3.1.1. Wawancara

Wawancara dilakukan dengan tujuan memperbaiki rancangan aplikasi

dari berbagai perspektif yang dituju, diantanya: pihak kepolisian yaitu Tim

Jaguar Polresta Depok, petugas pemadam kebakaran yaitu SUDIN

Penanggulangan Kebakaran dan Penyelamatan Jakarta Selatan, dan salah

satu korban perampasan/begal yaitu Rama.

3.1.2. Observasi

Pengumpulan data yang dilakukan dengan pengamatan dari berbagai

faktor dalam pelaksanaannya. diantaranya aspek komunikasi, kemanan,

maupun dari bagaimana penggunaan smartphone pada masyarakat sebagai

alat komunikasi. Observasi dilakukan secara langsung, maupun dari hasil

pengamatan dengan pedoman literatur sejenis.

3.1.3. Studi Pustaka

Merupakan metode pengumpulan data yang tidak ditunjukan langsung

kepada subjek penelitian.

3.2. Metode Pengembangan Sistem

3.2.1 Requirements Planning Phase

Pada tahap perencanaan kebutuhan (Requirements Planning Phase),

peenggabunngan analisa antara pengguna atau user (dalam hal ini ialah

masyarakat umum pengguna smartphone) menentukan masalah yang ada

28


dari sistem sebelumnya dan tanggapan melalui survei dan wawancara yang

dilakukan dengan penulis, dengan analis (dalam hal ini ialah penulis) melalui

ide dari perancangan sebuah sistem yang akan dibuat. Untuk memudahkan,

maka harus mengidentifikasi hal-hal berikut:

1. Analisa Kebutuhan Masalah

Pada tahap ini bertujuan mengidentifikasi maksud, serta tujuan dari

pengembangan sistem. Proses identifikasi dilakukan melalui

wawancara kepada tiga individu, yaitu kepada petugas pemadam

kebakaran Jakarta selatan, tim jaguar polresta depok, dan Rama

sebagai korban begal. Hasil wawancara menunjukan perlunya

sebuah sistem pelaporan dan manajemen darurat yang terintegrasi

pada smartphone melalui aplikasi, juga sebagai alat perekam guna

mengidentifikasi ciri-ciri pelaku ketika ada aksi teror.

2. Mengidentifikasi Masalah

Mengidentifikasi masalah yang akan diselesaikan. Permasalahan

didapat setelah melakukan wawancara dan analisa terkait

manajemen darurat.

3. Tujuan Informasi

Berdasarkan analisa kebutuhan masalah, dan pengidentifikasi

masalah, penulis menarik kesimpulan untuk mengembangkan

aplikasi yang meggunakan LBS dan GPS sebagai manajemen

darurat, juga tombol daya dan perintah suara untuk mengatifkan

aplikasi.

3.2.2. RAD Design Workshop

Pada tahap RAD Design Workshop, atau tahap desain dan penyaringan

analisa yang dilakukan oleh penulis dengan diiringi dengan ide atau

tanggapan dari responden survei dan wawancara. Dengan waktu yang

bersamaan mengerjakan analisa lanjut dan desain dengan cara start-to-start,

29


yaitu suatu proses yang mengerjakan analisa, dan mengerjakan desain tanpa

menunggu analisa selesai.

3.2.3. Implementation Phase

Pada tahap implementasi, desain dan analisa yang telah disaring, akan di

eksekusi dengan menggunakan IDE Android Studio yang difokuskan kepada

pengembagan dan pembuatan aplikasi smartphone. Hasil implementasi akan

melalui tahap alpha testing (pengujian yang dilakukan oleh user dengan di

dampingi oleh developer yang dalam hal ini ialah penulis) dan tahap beta

testing (yaitu pengujian yang dilakukan dengan user tanpa di dampingi oleh

developer).

30


BAB IV

ANALISIS DAN IMPLEMENTASI

4.1. Identifikasi Masalah

Identifikasi masalah dilakukan guna menentukan batasan masalah dari

berbagai parameter sebagai acuan. Guna mengidentifikasi dengan baik, penulis

melakukan observasi, wawancara dari berbagai sumber yang terkait pada

manajemen darurat, diantaranya Rama (korban begal), petugas SUDIN

Penanggulangan Kebakaran dan Penyelamatan kota administrasi Jakarta Selatan,

dan Iptu Winam Agus (Kepala Tim Jaguar Polresta Depok).

Adapun Narasi wawancara yang didapat dari ketiga sumber wawancara yang

dilakukan penulis:

1. Rama, Korban Begal:

Berdasarkan kejadian yang dialami oleh Rama, yaitu salah satu dari

korban pembegalan yang terjadi di jalan menuju pulang ke rumah

temannya. Jalan yang sepi menjadi pilihan karena jarak yang

ditempuh lebih singkat juga sudah berkali-kali melalui jalur tersebut

dengan aman. Beberapa saat kemudian ada orang mencurigakan yang

menghentikan laju motor nya dan seperti ingin mengajak berkelahi,

walau sudah berpikiran jernih, namun memang orang tersebut ada

niat tidak baik yang ditunjukan oleh beberapa temannya yang mulai

memukul beliau yang dimulai dengan stick baseball. Perkelahian

tidak dapat dihindari, selang beberapa menit akhirnya beliau memilih

untuk cari aman degan menawarkan beberapa uang dan handphone

agar pelaku meninggal kan beliau. Terlepas dari kejadian pembegalan

yang dialami beliau, lapor waga dilakukan dirasa perlu, dibuktikan

warga segera berkumpul dan mencari pelaku. Kejadian ini

31


memberikan ilmu baru, yaitu perlunya cari aman ketika berada di

keadaan sepi yaitu dengan mencari tempat ramai, lapor ke kantor

polisi terdekat, atau dengan berteriak jika memungkinkan. Suasana

dan tindakan pertama kali merupakan hal terpenting guna

meminimalisir resiko.

2. Petugas SUDIN Penanggulangan Kebakaran dan Penyelamatan kota

administrasi Jakarta Selatan:

Waktu merupakan hal terpenting saat terjadi kebakaran. 5 menit

pertama dengan 5 menit selanjutnya menentukan alat dan siapa yang

dapat menolong korban yang rumahnya mengalami bencana

kebakaran. 5 menit awal, api masih kecil dan masyarakat sekitar

dapat langsung membantu mengevakuasi korban, beda halnya dengan

menit selanjutnya ketika api bertambah besar, disitu diperlukan alat

berat berupa water jet yang jumlah airnya di sesuaikan dengan

keadaan di lokasi. Masyarakat sangat dihimbau untuk membantu pada

menit-menit awal ataupun pada api sudah mulai bertambah besar.

Pelaporan dianjurkan kepada cabang yang terdekat dengan rumah

korban guna mempercepat proses penanganan. Meskipun kebakaran

harus dilakukan penanganan secepatnya, namun tetap dirasa perlu

untuk melakukan konfirmasi data kepada korban, yaitu dengan

menelfon balik korban yang menelfon petugas guna menghindari

pelaporan iseng dari masyarakat. Apabila benar datanya maka dapat

langsung melakukan penanganan. Konfirmasi dilakukan pada pusat di

tiap cabang, melakukan alat komunikasi khusus, cabang meminta

pusat untuk mengecek data dan konfirmasi ke korban apakah benar

telah terjadi kebakaran pada area tersebut.

3. Iptu. Winam Agus (Kepala Tim Jaguar Polresta Depok):

Tindak kejahatan di area depok kian meningkat seiring dengan

32


berjalannya waktu namun tidak ada peningkatan yang signifikan dari

polresta membuat Iptu Winam Agus membentuk tim khusus penjaga

anti kerusuhan (Jaguar) dibawah naungan polresta Depok. Fokus tim

yaitu melakukan tindakan preventif kejahatan di jalan (street crime)

yang beragam (begal, jambret, penipuan, tawuran, dll) dengan

pelaporan masyarakat melalui telefon, maupun dengan media sosial.

Menurut beliau sebagai katim (kepala tim) jaguar, penjambretan

merupakan kasus yang membutuhkan perhatian lebih karena pelaku

dapat melancarkan asksinya pada siang hari yang mana lebih lengah

dalam hal kesiap siagaan masyarakat sekitar. Alih-alih melancarkan

aksinya, secara psikologis pelaku kejahatan lebih memilih

mengurungkan niatnya demi menghindari jeratan hukum atau amukan

masa. Kami melakukan olah TKP apabila tidak sempat memburu

pelaku kejahatan. Menurut beliau, apabila masyarakat melihat ada

tindak kejahatan, lebih baik melihat ancamannya dulu. Apabila

pelaku tidak membawa, dan siap untuk memerangi pelaku sebaiknya

dilakukan. Namun, apabila pelaku membawa senjata, lebih baik

gunakan daya ingat, yaitu dengan menghafal ciri-ciri pelaku dan

kendaraan yang digunakan untuk melancarkan aksinya, serta dengan

bantuan CCTV yang banyak terpasang di jalan. Waktu pelaporan

merupakan hal yang utama, dan pelibatan petugas juga menjadi point

penting saat terjadi tindak kejahatan. Beliau mengatakan apabila ada

pelaporan palsu atau hanya sekedar iseng, lebih di rekomendasikan

tetap datang ke lokasi untuk mengecek kebenaran nya guna

meminimalisir korban.

Hasil dari wawancara dari ketiga sumber dijadikan sebagai referensi terhadap

identifikasi masalah yang ada di lapangan. Penulis menggunakan diagram

fishbone diagram atau ishikawa diagram guna melihat dari root cause-and-effect

33


atau akar dari sebab dan akibat dengan 6 parameter, yaitu Machine sebagai

representasi peralatan atau teknologi, Methods sebagai proses, Material sebagai

informasi, Mother Nature sebagai kondisi lingkungan sekitar, Man Power sebagai

keterlibatan fisik ataupun pengetahuan manusia, dan Measurement sebagai acuan.

(Savale, 2018). Diagram dapat dilihat pada gambar 4.1. Analisa sebab dan akibat,

menggunakan fishbone diagram.

Gambar 4.1. Analisa sebab dan akibat, menggunakan fishbone diagram

Fishbone diatas menjelaskan yaitu sebab akibat, yang mana ditunjukan pada

tanda panah kearah kanan yang tujuannya kepada akibat dari masalah yang

dijelaskan, yaitu kurangnya manajemen darurat. Berbagai sebab dari 6 parameter

yang ada pada diagram ini dijelaskan sebagai berikut:

1. Machine, yaitu keypad pada smartphone, yang mana pada

penggunaan smartphone user harus membuka layar terlebih dulu dan

melihat letak tombol nomor untuk menelfon darurat.

2. Methods, yang pertama yaitu user tidak berusaha meminta

pertolongan ketika terjadi tidak kejahatan dikarenakan ketakutan.

Kedua maraknya modus penipuan dijalan seperti yang dialami oleh

34


salah satu korban begal, Rama, dikatakan pelaku memberhentikan

laju kendaraannya dengan alasan yang tidak jelas. Ketiga yaitu

kurangnya kewaspadaan korban.

3. Material, terjadi tindak kejahatan pada korban dikarenakan korban

memancing secara sadar maupun tidak, yaitu membawa harta

berlebih di tempat yang tidak memungkinkan, seperti perhiasan dan

uang berlebih.

4. Mother Nature, dikatakan oleh Iptu. Winam Agus, yaitu tindak

kejahatan marak terjadi pada malam hari, dikarenakan kondisi yang

memungkinkan bagi pelaku melancarkan aksinya namun dapat tidak

terlihat masyarakat sekitar, oleh sebab itu Tim Jaguar berfokus

melakukan pengawasan pada malam hari.

5. Man Power, dimulai dengan minimnya masyarakat sekitar, Iptu

Winam lanjut menjelaskan peranan masyarakat sekitar merupakan

penting agar penanggulangan dapat dilakukan secara tepat dan cepat.

Selanjutnya jumlah pelaku lebih banyak dari korban, begal yang

dilakukan oleh Rama, dilakukan di tempat yang sepi dengan

perbandingan korban dan pelaku 2 banding 4.

6. Measurement, pengukuran dimulai dengan efisiensi waktu pelaporan.

Petugas DAMKAR Jakarta selatan menjelaskan 5 menit awal,

menentukan penanggulangan selanjutnya, semakin cepat ditangani,

semakin sedikit petugas yang turun ke lapangan serta penentuan

apakah penanggulangan dapat diatasi dengan ringan atau tidak.

Selanjutnya presisi korban, merupakan hal terpenting yaitu presisi

lokasi korban agar dapat tepat di tangani.

Hasil dari diagram ini yaitu menentukan batasan masalah yang akan diteliti,

yang akan menjadi acuan peneliti untuk melakukan pengajuan model, analisa

sistem, serta penembangan sistem.

35


4.2. Pengajuan Model

Pengajuan model dilakukan guna mengevaluasi pemecahan dari masalah

tersebut menggunakan berbagai acuan dari penelitian terdahulu, menggabungkan

dan memperbarui dari model manajemen darurat. Pengajuan model dapat dilihat

pada tabel 4.1. sebagai berikut:

Tabel 4.1. Formasi Model yang diajukan pada penelitian ini

#Problem Proposed Model Emergency

Management

Penggunaan smartphone untuk menelfon

darurat tidak memungkinkan apabila

kondisi korban sedang terancam

sehingga tidak bisa membuka layar.

Sistem dikembangkan bertujuan agar

user dapat melakukan pelaporan darurat

tanpa membuka layar ataupun menekan

tombol nomor untuk telefon darurat.

Melalui tombol di aplikasi, tombol

power, serta voice command.

ketakutan korban untuk meminta

pertolongan apabila sedang terancam,

maraknya modus pelaku kejahatan,

kurangnya kewaspadaan di sekitar.

Sistem yang dikembangkan berfokus

kepada bagaimana korban dapat melapor

darurat dengan aman, serta tetap dapat

melapor walau smartphone berada di

luar jangkauan.

Pada beberapa kondisi, perangkat

korban diluar jangkauan (saat di

jambret) sehingga sulit bagi korban

menelfon darurat.

Sistem dapat bekerja walau berada diluar

jangkauan, menggunakan perintah suara

tertentu, akan men-trigger aplikasi

manajemen darurat

Saat keadaan darurat, minimnya bukti

dan kecepatan melapor mengakibatkan

pelaku akan lebih sulit ditangkap.

Sistem yang dikembangkan dapat

menjadi bukti yaitu dengan saksi yang

didapat dari penolong, rekaman suara

korban.

36


Efisiensi Waktu pelaporan minim

apabila user melakukan telefon darurat.

Korban yang sudah melapor melalui

sistem, akan diteruskan kepada penolong

dengan data yang dikimkan kepada

penolong secara terus menerus.

Presisi Lokasi dirasa kurang apabila

korban tidak mengetahui tempat.

lokasi secara terus menerus di update

guna mempermudah penolong datang ke

tempat korban.

Formasi model dilakukan dengan mengidentifikasi problem yang telah

dijelaskan pada identifikasi masalah, dan pengajuan model guna menjawab dari

masalah tersebut. Adapun masalah yang diangkat yaitu meliputi keamanan

korban, efisiensi waktu pelaporan, serta presisi lokasi korban.

4.3. Model Aplikasi

Selanjutnya formasi model dikembangkan menjadi model aplikasi pada

gambar 4.2. sebagai gambaran umum aplikasi yang akan dikembangkan oleh

penulis yang didapat dari hasil analisa masalah dan solusi dari model yang telah

di bentuk.

37


Gambar 4.2. Model aplikasi

Merupakan salah satu dari aplikasi manajemen darurat menggunakan

smartphone, yaitu korban (victim) melapor melalui aplikasi dengan berbagai

pilihan untuk memacu aplikasi, diantaranya menekan tombol yang ada pada

smartphone, melalui sensor akselerasi yang akan mendeteksi jika terjadi

kecelakaan, serta dengan perintah suara tertentu. Pengiriman sinyal bahaya, serta

lokasi dilakukan guna mempercepat proses penanganan terhadap korban.

38


Gambar 4.3. bencana individu pada korban

Bencana yang difokuskan pada penulisan ini merupakan bencana yang

sifatnya individu, seperti terror, kecelakaan, dan human error (kebakaran,

konsleting, dsb). Korban melakukan trigger atau memicu aplikasi untuk

mempersiapkan pelaporan, dengan waktu 10 detik konfirmasi bagi korban, yang

ditunjukan agar dapat membatalkan lebih awal apabila terjadi kesalahan

(false-alarm), sebelum data pelaporan masuk ke dalam database, dan sistem

mengirim notifikasi kepada calon penolong di sekitar.

39


Gambar 4.4. trigger aplikasi

Reaksi korban menyikapi bencana yang sedang menimpanya beragam.

Reaksi korban ini yang akan dijadikan pemacu aplikasi untuk mengirimkan sinyal

bahaya kepada penolong (helper), dengan waktu konfirmasi ditujukan untuk

membatalkan pelaporan guna mengurangi kemungkinan trigger dilakukan secara

tidak sengaja, apabila dalam waktu yang di tetapkan korban tidak membatalkan,

maka data user dimasukan ke dalam database dan notifikasi dikirim kepada calon

penolong.

40


Gambar 4.5. cara kerja aplikasi di sisi korban

Aplikasi yang sudah di picu oleh korban akan melakukan proses pencarian

penolong terdekat menggunakan LBS, dan mengirim lokasi korban menggunakan

GPS.

Gambar 4.6. fitur lbs pada aplikasi

41


Location Based Service (LBS) bertujuan untuk mencari penolong terdekat

dengan range jarak yang sudah di tentukan menggunakan formula great circle

distance yang akan menkonfersi lokasi latitude dan longitude korban yang

dibandingkan dengan calon penolong, agar hanya yang terdekat yang mendapat

notifikasi.

Gambar 4.7. navigasi penolong terhadap korban

Pengiriman lokasi GPS bertujuan untuk mempermudah penolong untuk pergi

ke tempat korban dengan presisi, yaitu dengan fitur navigasi yang ada pada

smartphone.

4.4. Rancangan Sistem

Berdasarkan hasil dari analisa untuk aplikasi manajemen bencana melalui

komunitas serta referensi lain yang serupa, maka diusulkan suatu rancangan agar

dapat menjadi bahan acuan untuk tahap implementasi dan sebagai gambaran

bagaimana sistem bekerja.

Pengembangan aplikasi menggunakan metode RAD, pada metode tersebut,

dimulai pada fase requirement gathering. Pada fase ini dimulai dengan

42


menggunakan use case diagram, menjelaskan aktor yang terlibat serta

penggunaan pada aplikasi. Use case diagram dapat dilihat pada gambar 4.8.

4.4.1. Use Case Diagram

Perancangan use case dimulai dengan menentukan aktor yang terlibat

pada aplikasi. Aktor yang terlibat antara lain yaitu user – victim (korban),

user – helper (penolong), dan user – Admin. Perbedaan antara korban

dengan penolong yaitu ketika terjadi keadaan darurat, korban yang

merupakan main aktor dapat melakukan pelaporan darurat, pembatalan

darurat dan meng update data terus-menerus. Pada sisi penolong ketika

terjadi situasi darurat, menerima notifikasi bahwa telah terjadi situasi darurat

dari sisi korban. Use case diagram dapat dilihat pada gambar 4.8.

43


Gambar 4.8. use case diagram

Pada sisi korban (victim), user dapat melakukan aktivitas pada aplikasi,

diantaranya: register, validasi user, log in, update lokasi berkala setiap 10

detik, kirim pesan, lapor darurat (didalamnya ada trigger menggunakan

button pada aplikasi, button power, dan voice command), mengirim dan

menerima live report darurat,, dan yang terakhir yaitu membatalkan laporan

darurat.

Pada sisi penolong (helper), user dapat melakukan kegiatan pada

44


aplikasi yaitu register, validasi user, log in, update lokasi berkala setiap 10

detik, kirim pesan, mendapat notifikasi apabila ada user yang dalam

jangkauan membutuhkan bantuan (didalamnya user dapat menolak ataupun

menerima untuk membantu korban), mengirim dan menerima live report

darurat, serta membatalkan menolong korban.

Admin bertugas untuk mengkontrol aplikasi. Hak yang dimiliki admin

antara lain: registrasi akun user, log in, mengirim dan menerima live report

darurat, kirim pesan kepada semua user, validasi user, menonaktifkan user,

merubah status aktif/tidak aktif pada semua tabel, merubah parameter

(contoh: waktu konfirmasi pelaporan darurat).

4.4.2. Use Case Table

Diagram use case selanjutnya dijelaskan pada use case table. Use Case

table dirancang guna memperjelas aksi dari aktor yang ada pada use case

diagram, serta menjadi inti dari requirement gathering, yaitu sebagai acuan

sequence diagram, activity diagram, class diagram, entity relationship

diagram, serta Mock-up aplikasi. Adapun use case table dapat dilihat pada

table 4.2. dibawah ini:

Tabel 4.2. Use Case Table

No Actor Use Case Deskripsi

1 User - Victim,

Helper, Admin

Registrasi Akun User Melakukan Registrasi akun user

agar dapat menggunakan aplikasi

manajemen darurat

Validasi User Validasi data user menggunakan

sms ke nomor yang di registrasi

pada aplikasi, guna mendapat data

diri yang autentik

45


Log In Dilakukan guna menjalankan

background task untuk menangkap

3 trigger utama dalam pelaporan,

serta menangkap notifikasi jika ada

masyarakat sekitar yang

membutuhkan bantuan bagi user

yang berhasil log in

Kirim Pesan Bertujuan agar setiap user baik dari

penolong, korban, maupun admin

2 User - Victim,

Helper

Mengirim dan

Menerima Live Report

Darurat

Bertujuan agar korban dan penolong

mendapat data yang up to date dari

situasi yang ada

Update Lokasi 10

Detik Sekali

Guna mempermudah kalkulasi jarak

antara korba dengan calon penolong

3 User - Victim Lapor Darurat Sebagai acuan dari penolong dan

mengirimkan lokasi kepada calon

penolong terdekat

Menekan Tombol di

Aplikasi

Memicu aplikasi untuk membuat

pelaporan darurat menggunakan

tombol yang ada pada aplikasi

Men-trigger aplikasi

menggunakan perintah

suara

Memicu Aplikasi dengan perintah

suara, agar pelaporan darurat tetap

dapat terlaksana walau smartphone

berada di luar jangkauan korban

Menekan Tombol

power pada

smartphone

Memicu Aplikasi dengan menekan

tombol power yang tertanam pada

smartphone

46


Membatalkan Laporan Pelaporan darurat yang dilakukan

secara tidak sengaja atau situasi

darurat yang dapat ditangani dengan

sendirinya, dapat dibatalkan

4 User - Helper Menerima Notifikasi

Pelaporan Darurat di

Sekitar lokasi

Sebagai tahapan awal bagi calon

penolong untuk dapat menolong

korban, yaitu dengan notifikasi

pemberitahuan bahwa telah terjadi

situasi darurat yang dialami korban

sekitar

Menolak untuk

membantu

Bertujuan agar calon penolong tidak

terus-menerus mendapatkan

notifikasi dari korban

Menerima Membantu

Korban

Masuk ke dalam session, agar

penolong dapat melihat situasi real

time, dan dapat berinteraksi dengan

korban

Membatalkan

Membantu Korban

Bertujuan bagi penolong yang

secara tidak sengaja menerima

membantu, namun tidak dapat

menolong, dapat dibatalkan

5 User - Admin Menonaktifkan User Sebagai bentuk pengawasan akun

yang terindikasi melakukan

kecurangan

Merubah Status

Aktif/Tidak Aktif pada

semua tabel di

database

Meminimalisir terjadi nya lag,

dikarenakan aplikasi terhenti

sebelum merubah status aktif/tidak

aktif

47


Merubah Parameter

(contoh: Waktu

Konfirmasi Pelaporan

Darurat)

Berguna agar aplikasi dapat

mengikuti sesuai dengan

permintaan user

Pada tabel 4.2. Use case tabele, dijelaskan penjabaran antara aktor, use

case, dan goal nya. Kolom aktor di bagi menjadi 5 grup, yaitu semua aktor

yang terlibat di satu use case yang sama, aktor korban dan penolong, aktor

korban, aktor penolong, dan admin.

Registrasi Akun User, Validasi User, Log In, Kirim Pesan merupakan

aksi yang dapat dilakukan oleh semua aktor, dengan penjelasan: registrasi

akun user sebagai pendaftaran akun yang nantinya menjadi identitas diri,

validasi user yang ditujukan guna meminimalisir adanya akun fiktif serta

pelaporan palsu yang dilakukan oleh pihak yang tidak bertanggung jawab,

log in yang dilakukan bertujuan agar sistem dapat menjalankan servis guna

mengirim atau mendapat notifikasi pelaporan darurat, serta kirim pesan yang

dilakukan dari setiap user agar dapat berinteraksi satu dengan lainnya.

Aktor korban dengan penolong memiliki 2 aksi kesamaan yang tidak

ada pada admin, yaitu: mengirim dan menerima live report agar dari kedua

pihak mendapat data yang terbaru, serta update lokasi yang dilakukan pada

sisi background agar mempermudah dalam kalkulasi jarak antara korban

dengan calon penolont.

Aktor korban mempunyai aksi: Lapor Darurat yaitu pelaporan yang

dilakukan oleh korban apabila terjadi situasi darurat dan sebagai acuan awal

bagi si penolong, lapor darurat dilakukan dengan 3 cara yaitu menekan

tombol yang ada pada aplikasi, menekan tombol power, dan melakukan

perintah suara. Korban juga dapat membatalkan pelaporan darurat apabila

terjadi gangguan teknis sehingga terjadi false-alarm, atau korban dapat

48


menangani situasi darurat dengan sendirinya.

Aktor Penolong mempunyai aksi: Menerima Notifikasi dari korban

bahwa telah terjadi situasi darurat yang nantinya penolong dapat menolak

atau menerima membantu korban yang membutuhkan bantuan. Penolong

dapat membatalkan menolong korban apabila terjadi gangguan teknis, atau

hal lain yang mengakibatkan penolong tidak dapat membantu korban.

Aktor admin bertugas dalam mengawasi aktivitas yang ada pada sistem

yaitu dapat menonaktifkan user apabila terlihat ada indikasi kecurangan,

merubah status aktif/tidak aktif apabila terjadi kesalahan pada sistem, serta

merubah parameter. Merubah parameter ditujukan agar aplikasi yang

berjalan dapat mengikuti permintaan dari user, seperti mengubah waktu

konfirmasi pelaporan darurat.

Tahap selanjutnya dalam merancang kebutuhan, menggunakan

sequence diagram, yaitu barisan kejadian yang menunjukan interaksi antara

user, sistem, dan objek.

4.4.3. Sequence Diagram

Sequence diagram diawali dengan aktor sebagai representasi aktor

yaitu user sebagai keseluruhan, korban sebagai pelapor, dan penolong yang

bertugas dalam membantu korban. Barisan kejadian yang dilakukan saat

masuk ke aplikasi (log in) dapat dilihat pada gambar 4.9. Sequence Diagram:

log in.

49


Gambar 4.9. Sequence Diagram: Log in

Proses yang dilakukan pada saat log in yaitu: user mengakses halaman

log in pada aplikasi dengan memasukan username dan password.

Selanjutanya akan dicocokan data dengan database yang ada apakah data

yang dimasukan benar. Data yang telah di cek dan jika benar, diambil data

pendukung yaitu berupa data detil user. Data tersebut akan ditampilkan pada

interface beserta respon dari database, lalu menuju ke main activity.

Akun yang telah berhasil masuk ke dalam aplikasi, otomatis akan

menjalankan proses latar belakang pada perangkat, yang nantinya akan

mendeteksi dari pergerakan pengguna, yaitu apabila pengguna menekan

tombol yang ada di dalam aplikasi, menekan tombol daya pada perangkat,

maupun user berteriak dengan kata-kata yang sudah terdaftar pada aplikasi.

Pelaporan darurat dari sisi korban dapat dilihat pada gambar 4.10. Sequence

Diagram: Emergency Report – Victim.

50


Gambar 4.10. Sequence Diagram: Emergency Report – Victim

Pada pelaporan darurat di sisi korban, dimulai dengan user melakukan

trigger aplikasi, dimana ada 3 jenis untuk memicu aplikasi, yaitu:

1. Tombol yang ada pada aplikasi, yaitu pada saat korban berhasil

masuk ke dalam aplikasi, dan diteruskan ke halaman utama,

51


korban menekan tombol darurat pada antar muka. Korban yang

telah menekan tombol, nantinya akan dikelola oleh controller

untuk dilakukan pelaporan.

2. Tombol daya pada perangkat. Korban yang menekan tombol

daya 3 kali berturut-turut baik di dalam aplikasi, maupun diluar

aplikasi yang bersamaan dengan proses latar belakang

perangkat akan melakukan hitung mundur sesudah pengguna

menekan tombol. Apabila dalam kurun waktu tersebut korban

menekan tombol daya sebanyak 3 kali ataupun lebih, maka

akan dikelola oleh controller untuk dilakukan pelaporan.

3. Perintah suara. Perintah suara dilakukan yaitu saat user

berteriak, sistem akan menganalisa apakah suara tersebut

terdaftar pada aplikasi, apabila terdaftar maka selanjutnya

diserahkan kepada controller untuk melakukan pelaporan.

Sesudah memicu aplikasi. akan dideteksi jenis triggernya. Proses

selanjutnya ialah persiapan notifikasi untuk pembatalan pelaporan yang

disertai dengan hitung mundur, jika user tidak melakukan apa-apa dalam

kurun waktu tersebut, maka menuju proses selanjutnya, yaitu pendaftaran

pelaporan darurat ke dalam database, disertai dengan notifikasi darurat yang

sedang aktif pada perangkat user.

Pelaporan yang masuk ke dalam database, selanjutnya akan diteruskan

kepada calon penolong dengan mengirim notifikasi pada perangkat.

Notifikasi didapat dengan proses looping yang dilakukan pada proses

background. Perancangan guna mendapat notifikasi, serta calon penolong

dapat terdaftar sebagai penolong dapat dilihat pada gambar 4.11. Sequence

Diagram: Emergency Report – Helper.

52


Gambar 4.11. Sequence Diagram: Emergency Report – Helper

Pelaporan pada sisi penolong, dimulai dengan user melakukan log in,

dan pada background aplikasi akan looping setiap 5 detik sekali guna

mendeteksi apakah ada pelaporan darurat di dekat lokasi user, dan jika dalam

pencarian terdapat pelaporan darurat, user akan menerima notifikasi, yang

nantinya akan menentukan apakah akan menolong korban atau tidak. User

bersedia menolong, pada background data user akan dikirim untuk

ditambahkan pada database penolong korban. User yang terdaftar pada

pelaporan tersebut, akan ditampilkan notifikasi pelaporan darurat yang

sedang aktif.

Apabila telah terkumpul beberapa penolong, maka langkah selanjutnya

yaitu memantau pelaporan yang sedang aktif pada aplikasi, baik dari sisi

korban, penolong, maupun admin. User di tempatkan pada 1 aktivitas,

53


dimaksud agar antara user dapat berinteraksi dalam penanganan agar tidak

terjadi miskomunikasi.

Aktivitas pelaporan yang aktif pada aplikasi, terdapat 3 bagian,

diantaranya: beranda, obrolan, serta aksi. Pada beranda, berisi data dari

korban yang disiarkan secara terus-menerus agar semua yang terlibat

mendapat data yang terbaru. Data korban yang ditampilkan berupa nama,

nomor telepon, lokasi terkini, serta status perangkat korban. Halaman

obrolan ditujukan agar semua user dapat berinteraksi, dan pada halaman aksi

ditujukan apabila dari salah satu pihak ingin membatalkan keikutsertaan diri

pada pelaporan daurat yang sedang aktif. Perancangan dapat dilihat pada

Gambar 4.12. Sequence Diagram: Active Emergency.

54


Gambar 4.12. Sequence Diagram: Active Emergency

Pada diagram ini, ialah pada saat korban berhasil mendaftarkan

pelaporan darurat, atau penolong berhasil mendaftarkan diri sebagai

penolong. Dimulai dengan log in, mendapatkan pelaporan darurat yang

sedang aktif, dan menuju activity tersebut dengan menekan notifikasi

tersebut. Terdapat 3 halaman pada activity, yaitu home atau victim data, yang

55


bersisi data-data korban, chat yaitu untuk berinteraksi antara korban dengan

penolong, maupun penolong dengan penolong. Selanjutnya, action yang

bertujuan jika korban atau penolong ingin membatalkan pelaporan darurat

tersebut yang mana saling berinteraksi melalui activity tersebut.

Proses pada beranda dimulai dengan user menekan notifikasi pelaporan

darurat yang sedang aktif, user memberbarui data baik korban maupun

penolong ke dalam database. Selanjutnya sistem akan mengambil data

korban terkini secara terus-menerus, dan ditampilkan kepada user.

Proses pada obrolan, dimulai dengan user menekan tombol obrolan pada

layar perangkat. Selanjutnya sistem akan mengambil semua data pesan yang

telah masuk ke dalam database dengan pesan yang terhubung pada nomor

identitas pelaporan tersebut. Data yang telah diambil oleh sistem, akan

diteruskan pada antar muka perangkat user. User dapat pula mengirimkan

pesan dengan mengisi teks pada bagian bawah antar muka, dan menekan

tombol kirim, nantinya detail pesan akan ditangkap oleh controller, dan pesan

akan ditambahkan ke dalam database. Setelah proses mengirim pesan, maka

sistem akan memperbarui daftar pesan tersebut.

Mode aksi, ditujukan apabila salah satu pengguna berhenti, ataupun

membatalkan keikutsertaannya pada pelaporan darurat tersebut. Proses nya

terbagi menjadi 2, yaitu pada sisi korban, ataupun pada sisi penolong. Pada

sisi korban, menekan tombol batal, maka sistem akan merubah flag atau

bendera pada database pelaporan darurat. Flag yang dimaksud adalah kode

status yang ada pada tiap kelas. Sebaliknya, pada sisi penolong, menekan

tombol batal, sistem akan merubah flag pada database penolong, yaitu

statusnya sebagai penolong akan dinonaktifkan.

4.4.4. Class Diagram

Perancangan class diagram didapat sesudah merancang sequence

diagram. Pada sequence diagram, telah dijabarkan relasi antara kelas serta

56


metode pada tiap kelas. Relasi ini yang digabung menjadi semua relasi antar

class dengan tipe asosiasi nya. Class diagram dapat dilihat pada gambar

Gambar 4.13. Class Diagram: Relasi Antar Kelas.

Gambar 4.13. Class Diagram: Relasi Antar Kelas

Perancangan aplikasi difokuskan pada bagaimana interaksi antara kelas

data satu dengan yang lainnya. Penolong dan korban terdapat pada table yang

sama, table user. Kelas User terhubung kepada User_Detail, dimana

merupakan rincian data user. Current_Location_Log terhubung kepada user,

yaitu lokasi terkini dari user yang berisi id, user_id, gps_location, created_at,

dan flag.

Emergency_Report merupakan kelas yang menampung pelaporan

darurat yang dibuat oleh korban. Kelas Emergency_Report berisi

Emergency_ID, User_ID yaitu korban, GPS_Location yaitu lokasi gps pada

57


saat melakukan pelaporan, created_at, modified_at, dan flag. Sesudah

pelaporan darurat telah dilaksanakan, maka kelas yang menampung data

realtime adalah Realtime_Report_Log yang berisi Realtime_Report_Log_ID,

Emergency_Report_ID, User_ID, GPS_Location, Interval_in_Sec sebagai

konfigurasi interval waktu perbaruan data, created_at, dan flag.

Kelas Helper_Log berfungsi dalam pencatatan penolong, yang

berasosiasi dengan emergency_report. Helper_Log berisi atribut

Helper_Log_ID sebagai id kelas, User_ID sebagai id penolong,

Emergency_Report_ID sebagai id dari pelaporan darurat, created_at,

modified_at, serta flag sebagai status.

Chat_Room merupakan kelas yang merepresentasikan suatu grup chat,

yang berisi Chat_Room_ID, User_ID sebagai batasan siapa saja yang dapat

masuk ke dalam grup obrolan, Chat_Type_ID, Created_At, Modified_At, dan

Flag. Chat_Room_Message merupakan isi dari pesan yang dikirim oleh user,

yang berhubungan dengan Chat_Room.

4.4.5. Entity Relationship Diagram

Class Diagram yang dirancang menjadi acuan untuk membuat Entity

Relationship Diagram (ERD). ERD dapat dilihat pada gambar Gambar 4.14.

Entity Relationship Diagram.

58


Gambar 4.14. Entity Relationship Diagram

Pada perancangan database, didapat nama tabel antara lain: app_logs

sebagai pencatatan kejadian, app_logs_type sebagai tipe pencatatan kejadian

pada sistem, chat_room sebagai representasi dari grup obrolan,

chat_room_message sebagai isi obrolan, chat_type yaitu tipe obrolan apakah

hanya obrolan antar user atau obrolan saat keadaan darurat,

current_location_log yaitu pencatatan lokasi yang di update berkala,

emergency_report atau tempat untuk menampung pelaporan darurat,

helper_log sebagai pencatatan bagi user yang mendaftarkan diri sebagai

penolong, kontak_darurat_type yaitu tipe kontak darurat bagi tiap user,

realtime_report_log pencatatan realtime pada situasi darurat, sequence_table

59


yaitu tolak ukur apabila hendak membuat id baru pada tiap tabel,

trigger_type yaitu tipe pemicu saat pelaporan darurat, user sebagai tabel data

user, user_detail sebagai tabel data rinci user, user_type sebagai tipe user.

4.5. Desain Tampilan Aplikasi

4.5.1. Mock-up Design

Perancangan tampilan, dimulai degan halaman log in, yaitu halaman

yang dimuat pada saat pengguna pertama kali membuka aplikasi setelah

memasang pada perangkatnya. Perancangan dapat dilihat pada gambar

Gambar 4.15. Mock-up: Log in, Register, Main Activity

Halaman log in terdapat text input untuk username, dan password.

Ketika user sudah mengisi text input tersebut, dan menekan tombol log in,

aplikasi akan memproses data apakah ada di dalam database. Jika data

berhasil ditemukan, maka pengguna akan diteruskan ke halaman main

activity, namun jika data tidak ditemukan, maka aplikasi akan memunculkan

tombol register untuk mendaftar user baru.

User yang menekan tombol register, akan dialihkan ke halaman register

dengan username dan password yang sudah terisi otomatis dari halaman

sebelumnya. User mengisi data-data yang berkaitan dengan user yaktu

berupa username, password, nama, alamat, nomor handphone, ciri-ciri,

60


nomor kontak darurat, tipe user, photo dan lain sebagainya. Ketika user

sudah melakukan register, maka proses selanjutnya yaitu konfirmasi

menggunakan sms yang berisi kode rahasia. Konfirmasi dilakukan agar tidak

ada 1 nomor handphone yang digunakan untuk 2 atau lebih user, juga

memungkinkan agar user tidak melakukan pelaporan darurat palsu.

Selanjutnya ketika user berhasil mendaftarkan diri, akan diteruskan ke

halaman log in untuk masuk ke dalam aplikasi. Jika pengguna berhasil

masuk ke dalam aplikasi, dan diteruskan ke halaman main activity, maka

pengguna dapat menggunakan layanan aplikasi yaitu pelaporan darurat.

Perincian halaman main activity dijelaskan pada Gambar 4.16. Mock-up:

Main Activity, History, Log In, Current Emergency - Home

.

61


Gambar 4.16. Mock-up: Main Activity, History, Log In, Current Emergency -

Home

Halaman main activity terdapat tombol menu pada pojok kiri atas yang

apabila ditekan akan menampilkan menu. Menu berisi data user yaitu

username dan nomor handphone user , active emergency yaitu untuk melihat

pelaporan darurat yang sedang aktif baik dari sisi korban maupun penolong,

history yang berisi riwayat pelaporan darurat, update user data yang

bertujuan untuk mengubah data user, dan sign out untuk keluar aplikasi dan

menuju halaman log in. Terdapat juga menu setting pada kanan atas, tombol

sos yang bertujuan untuk pelaporan darurat baru, dan tombol plus pada pojok

kanan bawah yang menuju untuk lapor admin / menanyakan pertanyaan

kepada admin.

Pada halaman main activity apabila user menekan menu history, maka

akan ditampilkan halaman riwayat penggunaan aplikasi dengan status

sebagai korban ataupun sebagai penolong. Halaman ini ditujukan untuk

melihat riwayat-riwayat user dari pelaporan darurat yang sudah selesai

dilakukan. Pada list tersebut terdapat tipe berupa korban atau pennolong, dan

nomor id dari pelaporan darurat tersebut. Jika dalam pelaporan darurat salah

satu pihak membatalkan (korban/penolong) maka pada history ditunjukan

dengan warna lebih pudar yang menandakan pelaporan tidak jadi dilakukan

62


oleh user tersebut.

Pengguna yang menekan tombol s.o.s di halaman main activity atau

pengguna yang menekan menu active emergency / current emergency, maka

akan diteruskan ke halaman current emergency. Pada halaman ini berisi

data-data korban yang di perbarui secara berkala terus-menerus (realtime).

Perincian halaman current emergency dapat dilihat pada Gambar 4.17.

Mock-up: Current Emergency – Home, Current Emergency – Chat, Current

Emergency – Action, Main Activity.

Gambar 4.17. Mock-up: Current Emergency – Home, Current Emergency – Chat,

Current Emergency – Action, Main Activity

Halaman Current Emergency – Home berisi Data korban yang

63


ditampilkan yaitu username korban, nama korban, emergency ID, emergency

status, last position (jika di klik maka akan otomatis membuka google maps

untuk navigasi ke tempat korban), last update, serta status perangkat user

yaitu status battery, connection status, dan recorded voice jika tersedia yang

mana data akan diperbarui secara terus-menerus. Menu chat pada bagian atas

akan menampilkan halaman chat jika di tekan.

Pada halaman Current Emergency – Chat, bertujuan agar user yang

terhubung pada pelaporan darurat dapat berinteraksi baik korban dengan

penolong, maupun penolong dengan penolong lainnya. Fitur chat ini

ditujukan agar penanggulangan darurat dapat berjalan lebih efektif dan tidak

ada miss komunikasi, korban dan penolong dibedakan dengan warna chat

nya. Menu Action pada bagian atas akan menampilkan halaman action jika

ditekan.

Halaman terakhir dari Current Emergency Activity yaitu Current

Emergency - Action. Halaman action bertujuan jika user membutuhkan

action kepada pelaporan darurat tersebut. Dimulai dengan tampilan

username korban, emergency ID. Tombol cancel bertujuan apabila korban

ingin membatalkan pelaporan darurat, atau penolong membatalkan untuk

menolong. Pengguna yang membatalkan keikutsertaan pada pelaporan

darurat akan diteruskan ke halaman main activity.

Tombol Update pada halaman action bertujuan apabila ada beberapa hal

seperti note pada pelaporan darurat dapat diperbarui. Combobox telefon,

ditujukan apabila salah satu user baik dari sisi penolong ataupun korban

ingin langsung menelfon pihak yang berwenang, ataupun kepada kontak

darurat yang telah di save pada halaman awal register.

Pada sisi penolong, apabila telah terjadi situasi darurat di sekitar

penolong, maka akan ditampilkan notifikasi. Notifikasi ini yang nantinya

akan memunculkan data korban, dan kesediaan penolong untuk membantu

64


korban. Perincian dapat dilihat pada Gambar 4.18. Mock-up: Helper

Notification, Helper Confirmation, Current Emergency, Main Activity.

Gambar 4.18. Mock-up: Helper Notification, Helper Confirmation, Current

Emergency, Main Activity

Servis latar belakang yang dimulai oleh sistem akan mendeteksi apabila

ada korban di sekitar yang membutuhkan bantuan. Apabila ditemukan korban

yang memerlukan bantuan, maka pada sisi penolong, akan ditampilkan

notifikasi. Notifikasi yang ditekan oleh pengguna, akan diteruskan ke

halaman Helper Confirmation, yaitu halaman bagi si penolong untuk melihat

data korban dan menentukan apabila hendak menolong korban atau tidak.

Penolong yang menekan ok pada halaman Helper Confirmation, akan

65


didaftarkan sebagai penolong untuk pelaporan darurat tersebut dan

diteruskan ke halaman Current Emergency – Home, yang mana penolong

dapat melihat data korban secara terus-menerus, berinteraksi melalui fitur

chat, dan membatalkan menolong korban.

Tombol selain ok, yaitu tombol ‘sorry, no’ merupakan tombol penolakan

bagi penolong untuk membantu korban. Penolong yang menekan tombol

tersebut akan dihentikan dari notifikasi pelaporan darurat tersebut dan akan

diteruskan ke halaman main activity

4.6. Pembuatan Aplikasi Manajemen Darurat

Pada tahap ini, aplikasi manajemen darurat diubat sesuai dengan hasil

observasi penulis, perancangan dan desain pada tahap sebelumnya. Pembuatan

aplikasi dibagi menjadi 4 inti utama pembahasan, yaitu: pelaporan darurat

menggunakan tombol yang ada di dalam aplikasi, pelaporan menggunakan

tombol daya pada perangkat, pelaporan dengan perintah suara, dan interaksi

penolong apabila ada korban di sekitar.

Aplikasi dikembangkan dalam bahasa inggris, guna menjaga konsistensi

bahasa yang ada pada aplikasi dan saat perumusan kode. Aplikasi dinamakan

“Kayfa,” diambil dari bahasa arab (كيف) yang jika diartikan ke dalam bahasa

Indonesia yaitu “bagaimana,” yaitu kata tanya untuk menanyakan akibat suatu

tindakan (kbbi.co.id).

4.6.1. Pelaporan Darurat Menggunakan Tombol yang Ada di Dalam

Aplikasi

Pelaporan darurat menggunakan tombol yang ada di dalam aplikasi dimulai

pada saat user menekan tombol darurat di halaman awal (gambar 5.5). Proses

pelaporan darurat dapat dilihat pada gambar 4.19. Diagram alur proses pelaporan

darurat dengan tombol yang ada pada aplikasi.

66


Gambar 4.19. Diagram alur proses pelaporan darurat dengan tombol yang

ada pada aplikasi

Proses selanjutnya ketika user telah menekan tombol, yaitu sistem

sebagaimana aplikasi manajemen darurat, akan mengirim data berupa id,

lokasi, jarak dan cara pelaporan ke web server. Jika lokasi yang ditangkap

terdapat kendala, maka sistem akan mengambil lokasi terakhir user yang ada

pada database. Apabila merupakan pelaporan baru, maka data akan

dimasukan ke dalam database sebagai data baru, dan apabila sebaliknya,

maka data yang sudah ada akan diperbarui.

Source code pelaporan darurat menggunakan tombol yang ada pada

aplikasi, dapat dilihat pada lampiran 1, dengan urutan nomor 1, yaitu proses

saat user menekan tombol, nomor 2, proses selanjutnya setelah aplikasi

menangkap aktivitas penekanan tombol yang ada pada aplikasi, dan nomor 3,

yaitu proses memasukan data ke dalam database.

4.6.2. Pelaporan Darurat Menggunakan Tombol Daya pada Perangkat

Pelaporan darurat menggunakan tombol daya berbeda dengan tombol

yang ada pada aplikasi, yaitu pelaporan dapat dilakukan pada background

67


aplikasi, dan terdapat hitung mundur untuk membatalkan pelaporan darurat

(gambar 5.6). Diagram alur proses pelaporan dapat dilihat pada gambar 4.20.

Diagram alur pelaporan darurat menggunakan tombol daya pada perangkat.

Gambar 4.20. Diagram alur pelaporan darurat menggunakan tombol daya

pada perangkat

Pelaporan darurat menggunakan tombol daya dimulai ketika user

menekan tombol daya sebanyak 4 kali atau lebih dalam 4 detik. Perolehan

angka 4 kali dan 4 detik didapat dari hasil observasi penulis saat melakukan

percobaan berulang, baik penulis pribadi maupun kerabat terdekat. Pada

lampiran 2, poin nomor 1, dijelaskan bahwa perhitungan mundur dimulai

pada saat terjadi perubahaan status layar dari menyala menjadi mati ataupun

sebaliknya, dan hitung mundur dimulai pada saat user pertama kali menekan

tombol daya pada perangkat.

Apabila user menekan tombol daya 4 kali atau lebih dalam waktu 4

detik, maka akan dicatat sebagai pelaporan darurat, dan memulai proses

hitung mundur untuk membatalkan pelaporan. Pada lampiran 2, poin nomor

2, jelaskan ketika sistem telah menuntaskan hitung mundur selama 4 detik,

68


maka akan dicek apakah user menekan tombol sebanyak 4 atau lebih yang

ditaruh pada class WebConfig, variable screenOnOffButtonCount. Jika user

menekan lebih dari 4 atau lebih, maka akan dilakukan pehitungan mundur

untuk membatalkan laporan.

Proses selanjutnya dapat dilihat pada lampiran 2, poin nomor 3, yaitu

menjalankan hitung mundur untuk pembatalan, yang ditujukan notifikasi

pembatalan yang muncul (lihat gambar 5.6). Setelah hitung mundur selesai

(onFinish), maka sistem memeriksa apakah user melakukan pembatalan atau

tidak, apabila user tidak melakukan pembatalan, maka data user diambil

untuk dijadikan pelaporan darurat yang baru seperti yang dimuat pada

lampiran 1, poin nomor 1 dan 2.

4.6.3. Pelaporan Darurat Menggunakan Perintah Suara

Pelaporan darurat menggunakan perintah suara dilakukan dengan

memicu aplikasi dengan tingkat kebisingan suara lebih dari 70dB, dan

mengucapkan kata darurat yang telah disimpan pada database lokal di

aplikasi. Diagram alur dapat dilihat pada gambar 4.21. Diagram Alur proses

pelaporan darurat menggunakan perintah suara.

Gambar 4.21. Diagram alur proses pelaporan darurat menggunakan perintah

69


suara

Dijelaskan pada lampiran 3, poin nomor 1, bahwa aplikasi menjalankan

thread khusus untuk melakukan penangkapan tingkat kebisingan suara pada

aplikasi yaitu pada method updatedBMeter(). Pada gambar 4.21. dinyatakan

bahwa sistem memeriksa apabila tingkat kebisingan berada diatas 70dB,

aplikasi akan terpicu untuk menangkap kata yang akan dilontar kan user,

proses dapat dilihat pada lampiran 3, poin nomor 2, apabila

currdBMeter>=noiseLevel, maka akan memanggil method

startNewSpeechRecognition().

Method startNewSpeechRecognition() dijelaskan pada lampiran 3, poin

nomor 3, yaitu saat aplikasi memulai pengenalan suara, yang mana

disediakan oleh perangkat android, tidak menggunakan API yang disediakan

oleh google. Kata yang dilontarkan selanjutnya diperiksa apakah kata

tersebut termasuk kata yang disimpan di dalam database. Apabila kata

tersebut tercatat sebagai kata pelaporan darurat, maka akan dimulai proses

hitung mundur dan dicatat sebagai pelaporan darurat seperti yang disebutkan

pada lampiran 2, poin nomor 3.

4.6.4. Interaksi Penolong Apabila Terdapat Korban di Sekitar

Interaksi antara penolong dengan korban, dimulai saat user ditampilkan

notifikasi bahwa ada korban di sekitar user yang membutuhkan pertolongan,

dengan tentunya ada konfirmasi apakah akan menolong atau tidak. Diagram

alur dapat dilihat pada gambar 4.22. Diagram alur proses interaksi penolong

terhadap pelaporan darurat di sekitar.

70


Gambar 4.22. Diagram alur proses interaksi penolong terhadap pelaporan

darurat di sekitar.

Interaksi dimulai dengan proses update lokasi berkala, dijelaskan pada

lampiran 4, poin nomor 1, pada perbaruan lokasi berkala, aplikasi akan

melihat dengan provider apa aplikasi lebih akurat dalam menentukan titik

kordinat. Tingkat akurasi yang lebih tinggi, dipilih sebagai pnentuan lokasi

user, dan diperbarui ke dalam database melalui class LocationUpdate.

Aplikasi akan melakukan proses hitung mundur berkala, yang

tujuannya agar dapat melihat apabila ada korban di sekitar membutuhkan

bantuan. Pemeriksaan dimulai dengan aplikasi mengirim data user ke web

server yang tersedia (lihat pada lampiran 4, poin nomor 2), data yang dikirim

berupa id user, dan id darurat yang diblokir ataupun yang telah ditolak oleh

user.

Proses selanjutnya pada web server, gambar 4.22 menjelaskan apabila

terdapat pelaporan darurat yang aktif seperti pada proses lampiran 4 poin

nomor 3, yaitu pelaporan darurat yang aktif, namun korban bukan user yang

71


saat ini, dan id darurat tidak termasuk kedalam id yang sudah di blokir oleh

user. Apabila terdapat pelaporan darurat, maka proses selanjutnya dilihat

satu-persatu untuk diukur jaraknya terhadap user.

Proses pengukuran jarak dapat dilihat pada lampiran 4, poin nomor 4.

Pengukuran dilakukan menggunakan API yang tersedia oleh google cloud

platform, yatu distance matrix API, dan dengan perhitungan manual apabila

terdapat kendala. Pengukuran dengan API dilakukan dengan mengangkap

hasil dari tautan

https://maps.googleapis.com/maps/api/distancematrix/json?origi

ns=$lat1,$long1&destinations=$lat2,$long2&key=$apiKey , dengan

memasukan lokasi latitude dan longitude asal serta tujuannya, dan

memasukan API Key yang didapat saat melakukan registrasi api.

Apabila jarak yang didapat kurang dari jarak yang telah ditentukan

pada database, maka pelaporan darurat tersebut akan dikirim melalui

notifikasi di perangkat user seperti yang ditampilkan pada gambar 5.7.

data yang dikirimkan ke user berupa data lengkap pelaporan darurat, lokasi

korban, jarak korban, estimasi waktu ke korban serta data pribadi korban

berupa nama, nomor handphone, dan kontak darurat korban.

Selanjutnya konfirmasi user, yaitu apakah user akan membantu korban

atau tidak, disimbolkan dengan tombol berwarna merah dan hijau (gambar

5.7). Dijelaskan pada gambar 4.22, diagram alur interaksi penolong, bahwa

jika user tidak membantu korban, maka proses interaksi selesai, id darurat

dimasukan ke dalam id yang diblokir. Sebaliknya apabila user akan

membantu korban, maka user diteruskan ke halaman darurat terkini, yakni

halaman untuk berinteraksi dengan user yang tergabung dalam id darurat

tersebut, dan dapat melihat data korban secara terus-menerus.

72


BAB V

HASIL DAN PEMBAHASAN

5.1. Hasil Tampilan Antarmuka

Tampilan antarmuka dijelaskan dari setiap alur, dengan urutan dari kiri ke

kanan. Hasil tampilan antarmuka dimulai dengan halaman log in, yaitu halaman

pertama yang ditampilkan jika pengguna baru memasang aplikasi pada

smartphone. Pengguna yang telah melakukan registrasi, selanjutnya dapat

melanjutkan ke halaman log in. Alur hasil antar muka register dapat dilihat pada

Gambar 5.1. Alur Hasil tampilan antarmuka registrasi user.

Gambar 5.1. Alur Hasil tampilan antarmuka registrasi user

Proses registrasi pengguna dimulai dengan halaman log in, user

menekan tautan yang bertuliskan “register now.” Selanjutnya pengguna dituju ke

halaman registrasi dengan form registrasi yang ada. Perincian form registrasi

antara lain dapat dilihat pada tabel 5.1. Deskripsi form registrasi:

Tabel 5.1. Deskripsi form registrasi

73


No Nama Deksripsi

1 Username digunakan sebagai alias user saat melakukan log

in.

2 Password digunakan sebagai autentikasi user saat melakukan

log in.

3 Confirm Password konfirmasi password, agar tidak ada kesalahan

input pada saat registrasi

4 User Type sebagai tipe user.

5 Nama nama yang akan ditampilkan pada saat melakukan

pelaporan darurat.

6 Ciri-ciri

7 Alamat data yang akan ditampilkan pada saat melakukan

pelaporan darurat.

8 Kode Pos data yang akan ditampilkan pada saat melakukan

pelaporan darurat.

9 E-mail guna mempermudah bagi admin mengirim pesan

jika ada masalah dalam penggunaan aplikasi.

10 Nomor Handphone

sebagai salah satu syarat registrasi, sebagai

pembeda dari user lainnya selain username dan

e-mail.

11 Nomor Handphone2 sebagai nomor handphone cadangan.

12 TTL data tempat, tanggal lahir.

13 Kontak Darurat Type tipe kontak darurat yang disimpan ke dalam data

user.

14 Nomor Handphone

Kontak Darurat

sebagai penghubung bagi penolong dengan kontak

darurat yang disimpan oleh korban.

74


User yang telah melakukan registrasi, maka user dapat melakukan log in

dengan username dan password yang telah didaftarkan. Hasil tampilan dapat

dilihat pada Gambar 5.2. Alur Hasil tampilan antarmuka proses log in user.

Gambar 5.2. Alur Hasil tampilan antarmuka proses log in user

Proses log in dimulai dengan user memasukan username dan password,

lalu menekan tombol log in berwarna hijau tua. Sistem akan mengirim data ke

web server yang tersedia, guna melihat apakah data yang dimasukan oleh user

tersedia pada database. Apabila tersedia, maka web server akan mengirim

data-data user yang akan digunakan aplikasi.

User yang telah berhasil melakukan log in, akan diteruskan ke halaman

awal aplikasi. Yaitu halaman awal yang ditampilkan apabila user telah log in.

user yang berhasil log in juga secara otomatis menjalankan background

service aplikasi dengan ditandai notifikasi berjudul “Application Service

Activated,” yaitu servis yang menjalankan proses update lokasi ke dalam

database setiap 10 detik sekali, dan cek apabila terdapat korban di sekitaran

user yang butuh pertolongan.

Terdapat 2 menu yang terdapat pada halaman awal aplikasi. Menu pertama

berada pada ujung kanan atas guna membuka halaman about us, yaitu halaman

75


yang berisi versi dan deskripsi aplikasi. Menu kedua merupakan menu yang

berada di sisi bagian kiri atas, yang merupakan menu untuk membuka pelaporan

darurat yang sedang aktif, menghapus data pelaporan yang sedang aktif, serta

untuk log out. Menu kedua pada halaman awal aplikasi yaitu yang berada pada

sisi kiri atas berbentuk 3 garis datar di samping nama aplikasi.

Adapun hasil tampilan antarmuka saat menekan menu pelaporan darurat

yang aktif dengan kondisi tidak ada pelaporan aktif dapat dilihat pada Gambar

5.4. Alur Hasil tampilan antarmuka membuka halaman pelaporan darurat terkini,

dengan kondisi tidak ada pelaporan darurat yang aktif.

Gambar 5.4. Alur Hasil tampilan antarmuka membuka halaman pelaporan darurat

terkini, dengan kondisi tidak ada pelaporan darurat yang aktif

Adapun hasil tampilan antarmuka saat user melakukan pelaporan darurat

menggunakan tombol bulat yang berada pada sisi bagian kanan bawah, dapat

dilihat pada Gambar 5.5. Alur Hasil tampilan antarmuka pelaporan darurat

menggunakan tombol pada halaman awal aplikasi.

76


Gambar 5.5. Alur Hasil tampilan antarmuka pelaporan darurat menggunakan

tombol pada halaman awal aplikasi

User yang menekan tombol pelaporan darurat yang ada pada aplikasi, akan

langsung ditampilkan notifikasi pelaporan darurat yang sedang aktif dengan judul

“Check Current Emergency” dengan dibarengi penyimpanan data pelaporan

tersebut ke dalam database. Notifikasi tersebut selalu aktif selama user masih

aktif dan pelaporan darurat belum dibatalkan.

Berbeda dengan tombol yang ada di aplikasi, pelaporan darurat yang

dilakukan dengan tombol daya pada smartphone ataupun melalui perintah suara,

dapat dilakukan di background aplikasi, yaitu user dapat melakukan pelaporan

meskipun tidak dalam membuka aplikasi. Pelaporan menggunakan tombol daya

dan perintah suara, terdapat notifikasi untuk membatalkan pelaporan selama 6

detik. Jika user yang tidak membatalkan laporan, maka oleh sistem akan

dimasukan datanya sebagai pelaporan darurat yang akif. Adapun hasil tampilan

saat user melakukan pelaporan menggunakan tombol daya ataupun melalui

perintah suara, dapat dilihat pada Gambar 5.6. Alur Hasil tampilan antarmuka

pelaporan darurat menggunakan tombol daya pada smartphone dan melalui

perintah suara.

77


Gambar 5.6. Alur Hasil tampilan antarmuka pelaporan darurat menggunakan

tombol daya pada smartphone dan melalui perintah suara

Pelaporan darurat yang sudah dilakukan menggunakan tombol daya pada

smartphone maupun perintah suara, akan disimpan datanya sementara dengan

ditampilkan notifikasi untuk membatalkan pelaporan darurat. Jika laporan

dibatalkan, maka tidak ada user lain yang mendapat notifikasi bahwa telah terjadi

kejadian darurat. Namun jika user tidak membatalkan pelaporan darurat, maka

data yang disimpan sementara tersebut akan dimasukkan ke dalam database

sebagai pelarporan aktif, dan notifikasi pelaporan darurat terkini muncul di layar

smartphone.

Pada sisi penolong, apabila telah dimasukkan ke dalam database, dan dicatat

sebagai pelaporan aktif, maka akan ditampilkan berupa notifikasi berjudul “help,”

yang mana ditujukan sebagai konfirmasi penolong apakah akan menolong korban

atau tidak. Hasil tampilan dapat dilihat pada Gambar 5.7. Alur hasil tampilan

antarmuka konfirmasi penolong kepada korban.

78


Gambar 5.7. Alur hasil tampilan antarmuka konfirmasi penolong kepada korban

Konfirmasi penolong dilakukan guna mencatat data dan dilakukan guna

membatasi penolong yang dapat membantu korban. Apabila notifikasi konfirmasi

penolong ditekan, maka akan memunculkan halaman konfirmasi penolong

lengkap dengan data korban, lokasi terkini, serta alamat dimana korban

melakukan pelaporan darurat. Apabila tombol merah ditekan maka user tidak

akan mendapat notifikasi dari pelaporan darurat tersebut, namun apabila user

menekan tombol hijau, maka user dicatat sebagai penolong korban dan

ditampilkan notifikasi pelaporan darurat yang sedang aktif.

Notifikasi pelaporan yang sedang aktif ditujukan agar user baik penolong

ataupun korban dapat melihat bahwa dirinya menjadi bagian dari pelaporan

tersebut. Terdapat 2 cara untuk melihat serta berinteraksi ke halaman pelaporan

darurat yang aktif, yang mana dapat dilihat pada Gambar 5.8. Alur Hasil tampilan

antarmuka membuka pelaporan darurat terkini yang sedang aktif melalui

notifikasi ataupun melalui menu pada halaman awal.

79


Gambar 5.8. Alur Hasil tampilan antarmuka membuka pelaporan darurat

terkini yang sedang aktif melalui notifikasi ataupun melalui menu pada halaman

awal

Cara yang pertama untuk melihat pelaporan darurat yang aktif dapat

dilakukan dengan membuka menu yang berada pada sisi kiri atas di halaman awal

aplikasi, lalu menekan “Current Emergency.” Cara kedua yaitu dengan menekan

notifikasi pelaporan darurat aktif yang berjudul “Check Current Emergency.”

Kedua cara dilakukan dengan hasil menampilkan halaman beranda di pelaporan

darurat. Rincian halaman pelaporan darurat yang sedang aktif dapat dilihat pada

Gambar 5.9. Alur Hasil tampilan antarmuka melihat dan berinteraksi pada

halaman pelaporan darurat yang sedang aktif.

80


Gambar 5.9. Alur Hasil tampilan antarmuka melihat dan berinteraksi pada

halaman pelaporan darurat yang sedang aktif

Halaman beranda terdapat beberapa data korban, dapat dilihat pada tabel 5.2.

Deskripsi halaman beranda:

Tabel 5.2. Deskripsi halaman beranda

No Nama Deksripsi

81


1 Nama nama korban yang dimasukan pada saat awal

melakukan registrasi.

2 Username sebagai alias user.

3 Last Update penunjuk waktu kapan terakhir kali data tersebut

diperbarui oleh sistem.

4 Trigger Type :sebagai gambaran bagaimana korban melakukan

pelaporan darurat.

5 User’s Handphone

Number nomor handphone korban yang terdaftar.

6 Emergency Contact

Number

nomor handphone kontak darurat korban yang

dimasukan pada saat registrasi.

7 Emergency Contact

Type

tipe kontak darurat yang dimasukan oleh user pada

saat registrasi.

8 Feature Charateristic sebagai ciri-ciri korban.

9 Victim’s Address alamat korban yang disimpan pada saat registrasi

10 Emergency Location alamat korban pada saat melaporkan kejadian.

Halaman berikutnya adalah halaman chat dan action. Chat ditujukan agar

user yang tergabung dalam pelaporan darurat tersebut dapat berinteraksi baik

korban maupun penolong. Halaman terakhir yaitu halaman action, merupakan

halaman apabila user membutuhkan aksi berupa membatalkan keikutsertaan

pelaporan darurat, menelfon korban, menelfon kontak darurat korban, menelfon

82


darurat 112, dan navigasi ke lokasi korban.

5.2. Pengujian Kelayakan Aplikasi

Uji kelayakan aplikasi dilakukan sebagai acuan keberhasilan penggunaan

aplikasi sebagai manajemen darurat menggunakan smartphone. Pengujian

dilakukan sebanyak 3 kali di setiap aksi dengan blackbox testing, menggunakan

perangkat smartphone yang berbeda, serta koneksi internet menggunakan wi-fi

ataupun mobile data. Adapun pengujian yang dilakukan oleh penulis antara lain:

1. Keberhasilan user melakukan log in dan log out.

2. Keberhasilan user melakukan registrasi dan validasi via sms.

3. Keberhasilan user melakukan pelaporan darurat menggunakan tombol

yang ada pada aplikasi.

4. Keberhasilan user melakukan pelaporan menggunakan tombol daya pada

smartphone yang dilakukan baik dari aplikasi maupun background.

5. Keberhasilan aplikasi menangkap kata yang dilontarkan oleh user saat

melakukan pelaporan suara dan melakukan pelaporan menggunakan

perintah suara.

6. Keberhasilan aplikasi menampilkan notfikasi: notifikasi bahwa aplikasi

aktif pada background, notifikasi membatalkan pelaporan, notifikasi

pemberitahuan bahwa terdapat pelaporan darurat di sekitar, dan

notifikasi pelaporan darurat yang sedang aktif.

7. Keberhasilan penolong untuk konfirmasi untuk membantu korban.

8. Keberhasilan memperbarui data pada beranda pelaporan darurat yang

aktif selama 3-10 detik sekali.

9. Keberhasilan memperbarui data pada chat selama 3-10 detik sekali.

10. Keberhasilan mengirim pesan pada menu chat.

11. Keberhasilan membatalkan pelaporan pada halaman aksi.

12. Keberhasilan menelfon korban dan kontak darurat korban.

13. Keberhasilan navigasi ke lokasi korban.

83


5.2.1. Skenario Pengujian Kelayakan Aplikasi

Pengujian dilakukan dengan minimal 2 aktor, yaitu sebagai korban

yang melakukan pelaporan darurat, dan sebagai penolong. Pengujian

aplikasi dilakukan sebanyak 3 kali pengujian, dengan variasi perangkat dan

versi android yang digunakan. Adapun skenario pengujian dapat dilihat

pada tabel Tabel 5.1. Skenario Pengujian aplikasi.

Tabel 5.3. Skenario Pengujian aplikasi

No Test Title Description Test Case Steps Expected

Result

1 Log in Test Menguji

fungsionalit

as log in

1. membuka aplikasi menuju

halaman log

in

2.memasukan username

dan password (user

yang sudah aktif)

3. klik tombol log in user berhasil

log in, masuk

ke halaman

awal aplikasi

2 Log out

Test

Menguji

fungsinalita

s log out


halaman awal

aplikasi

2. klik menu berbentuk 3

garis horizontal bagian

kiri atas

menu terbuka

pada sisi kiri

3. klik log out log out

sukses,

84


menuju

halaman log

in

4. keluar aplikasi, dan

membuka aplikasi

kembali

masuk ke

halaman log

in, bukan ke

halaman awal

aplikasi

3 Registratio

n Test

Menguji

fungsionalit

as

registraasi


halaman log

in

2. klik tautan 'register

now'

menuju

halaman

registrasi

3. mengisi data lengkap log in failed

with error

message.

Shows

register

button instead

4. klik tombol save terdapat pesan

validasi data

apabila

terdapat

masukan yang

salah. Apabila

data benar,

maka form

85


terhapus

4 Validation

Test

Menguji

fungsionalit

as validasi

user


halaman log

in

2. memasukan username

dan password (user

yang belum aktif)

4. klik tombol log in muncul

tombol

validasi via

sms jika user

belum aktif

5. klik tombol validasi

via sms

menuju

halaman

validasi via

sms dan sms

dikirim

menggunakan

pulsa user

6. memasukan kode

yang telah dikirim via

sms

7. klik tombol validasi masuk ke

halaman log

in

5 Emergency

Report Test

- Button in

menguji

fungsionalit

as

1. membuka aplikasi go to main

activity

2. menekan tombol pelaporan

86


app melaporkan

keadaan

darurat

menggunak

an tombol

yang ada di

halaman

awal

aplikasi

berwarna merah muda

pada sisi bagian kanan

bawah

darurat

berhasil

ditunjukan

dengan

muncul

notifikasi

pelaporan

darurat yang

aktif

6 Emergency

Report Test

- Power

Button

mennguji

fungsionalit

as

melaporkan

keadaan

darurat

menggunak

an tombol

daya pada

smartphone

baik pada

saat

membuka

aplikasi,

dan pada

background

aplikasi

1. menekan tombol daya

3x atau lebih dalam

waktu 4 detik

muncul

notifikasi

untuk

melakukan

pembatalan

laporan

selama 6 detik

di sertai

dengan

vibrasi

perangkat per

detik

3. tidak menekan

notifikasi pembatalan

pelaporan

notifikasi

pembatalan

laporan

hilang, dan

pelaporan

darurat

berhasil,

87


ditunjukan

dengan

notifikasi

pelaporan

darurat yang

aktif

7 Emergency

Report Test

- Voice

Command

menguji

fungsionalit

as

melaporkan

keadaan

darurat

menggunak

an perintah

suara, baik

dalam

keadaan

layar

perangkat

terbuka,

maupun

terkunci

1. mengeluarkan suara

(tepuk

tangan/teriak/jentikan

jari) yang menghasilkan

suara dengan kisaran

>70 dB

terdengar

bunyi nada

bahwa

aplikasi siap

menangkap

perintah suara

2. melakukan perintah

suara dengan kata 'help'

dengan intonasi suara

yang jelas

perintah suara

ditangkap

oleh aplikasi

dan ditangkap

sebagai kata

'help', di

tandai dengan

notifikasi

pembatalan

pelaporan,

vibrasi pada

perangkat per

detik, dan

suara "right

away"

3. tidak menekan notifikasi

88


notifikasi pembatalan

pelaporan

pembatalan

laporan

hilang, dan

pelaporan

darurat

berhasil,

ditunjukan

dengan

notifikasi

pelaporan

darurat yang

aktif

8 Helper

Confirmati

on Test -

Reject

menguji

fungsionalit

as

konfirmasi

penolong

dengan

kondisi

menolak

untuk

membantu

korban

1. log in ke dalam

aplikasi / mengaktifkan

aplikasi

apabila ada

pelaporan

darurat di

sekitar user,

maka muncul

notifikasi

berjudul 'help'

2. menekan notifikasi

pada perangkat dengan

judul 'help'

masuk ke

halaman

konfirmasi

penolong

yang

berisikan data

korban, dan

tombol

pilihan pada

89


bagian bawah

apakah akan

menolong

atau tidak

3. menekan tombol

'sorry, but no.'

notifikasi

hilang, dan

tidak akan

muncul lagi

pada

pelaporan

tersebut, serta

menuju

halaman awal

aplikasi

9 Helper

Confirmati

on Test -

Accept

menguji

fungsionalit

as

konfirmasi

penolong

dengan

kondisi

menerima

untuk

membantu

korban

1. log in ke dalam

aplikasi / mengaktifkan

aplikasi

apabila ada

pelaporan

darurat di

sekitar user,

maka muncul

notifikasi

berjudul 'help'

2. menekan notifikasi

pada perangkat dengan

judul 'help'

masuk ke

halaman

konfirmasi

penolong

yang

berisikan data

korban, dan

90


tombol

pilihan pada

bagian bawah

apakah akan

menolong

atau tidak

3. menekn tombol 'OK,

Bring it on.'

notifikasi

hilang dan

user tercatat

sebagai

penolong

dengan

ditunjugkan

notifikasi

berganti

notifikasi

pelaporan

darurat yang

aktif, dan

menuju

halaman

pelaporan

darurat yang

sedang aktif

10 Current

Emergency

- Home

menguji

fungsionalit

as aplikasi

pada

1. membuka menu 3

garis horizontal pada

halaman awal aplikasi,

dan memilih menu

masuk ke

halaman

pelaporan

darurat yang

91


halaman

pelaporan

darurat

yang sedang

aktif, di

beranda

(home)

'currrent emergency' sedang aktif,

di bagian

beranda /

home

1a. Menekan notifikasi

dengan judul 'Check

Current Emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home

2. scroll halaman sampai

bagian bawah

terdapat data

korban serta

lokasi pada

saat melapor

yang

diperbarui

selama 3-10

detik sekali

secara

otomatis

11 Current

Emergency

- Chat

menguji

fungsionalit

as aplikasi

pada

halaman

pelaporan

1. membuka menu 3



dan memilih menu

'currrent emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

92


darurat

yang sedang

aktif, di

obrolan

(chat)

beranda /

home


dengan judul 'Check

Current Emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home

2. menekan menu 'chat'

pada bagian atas

ditampilkan

halaman chat

/ obrolan, dan

pesan jika

sudah ada

yang

mengirim

terlebih

dahulu

3. mengisi pesan dan

menekan tombol panah

ke arah kanan

pesan

disimpan pada

database,

ditandai

dengan pesan

muncul pada

layar

4. membiarkan

membuka halaman ini

pesan akan

diperbarui

93


selama 3-10 detik

dengan kondisi user

yang tergabung

mengirim pesan

secara

otomatis

dalam 3-10

detik sekali

jika user lain

berhasil

mengirim

pesan

12 Current

Emergency

- Action:

Cancel

menguji

fungsionalit

as

membatalka

n pelaporan

pada

halaman

pelaporan

darurat

aktif, di

bagian aksi

(action)

1. membuka menu 3



dan memilih menu


masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home


dengan judul 'Check

Current Emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home

2. menekan menu

'Action' pada bagian atas

ditampilkan

halaman

action / aksi

yang berisi

94


tombol

cancel,

telefon

korban,

telefon kontak

darurat

korban,

telefon 112,

dan 'start

navigation'

3. menekan tombol

'cancel'

keikutsertaan

user dalam

pelaporan

darurat

tersebut

dibatalkan,

dicatat ke

dalam

database

ditunjukan

aplikasi

mengirim ke

halaman awal

aplikasi,

notifikasi

menghilang,

dan apabila

user menuju

95


menu 'current

emergency'

maka muncul

halaman

bertulis "no

current

emergency

active"

13 Current

Emergency

- Action:

Call Victim

&

Emergency

Contact

menguji

fungsionalit

as aplikasi

untuk dapat

menelfon

korban &

kontak

darurat

korban

melalui

tombol

yang ada

pada

halaman

pelaporan

darurat

yang aktif,

di bagian

aksi

(action)

1. membuka menu 3



dan memilih menu


masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home


dengan judul 'Check

Current Emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home

2. menekan menu


ditampilkan

halaman

action / aksi

yang berisi

96


tombol

cancel,

telefon

korban,

telefon kontak

darurat

korban,

telefon 112,

dan 'start

navigation'

3. Menekan tombol call

victim (dari sisi

penolong)

aplikasi akan

mengirim ke

halaman

telefon

dengan nomor

telefon yang

tercatat baik

nomor telefon

korban dan

nomor telefon

kontak darurat

korban

3. Menekan tombol call

emergency contact

sesuai tipe yang di

registrasi (orang

tua/saudara/anak/teman/

dll)

aplikasi akan

mengirim ke

halaman

telefon

dengan nomor

telefon yang

97


tercatat baik

nomor telefon

korban dan

nomor telefon

kontak darurat

korban

14 Current

Emergency

- Action:

Start

Navigation

Menguji

fungsionalit

as aplikasi

untuk dapat

penolong

navigasi ke

lokasi

korban

menggunak

an google

maps

1. membuka menu 3



dan memilih menu


masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home


dengan judul 'Check

Current Emergency'

masuk ke

halaman

pelaporan

darurat yang

sedang aktif,

di bagian

beranda /

home

2. menekan menu


ditampilkan

halaman

action / aksi

yang berisi

tombol

cancel,

98


telefon

korban,

telefon kontak

darurat

korban,

telefon 112,

dan 'start

navigation'

3. Menekan tombol 'start

navigation' pada bagian

bawah halaman

aplikasi akan

membuka

google maps

yang langsung

memperlihatk

an arah

(direction) ke

lokasi korban

Pengujian aplikasi dimulai dengan percobaan log in dan log out

apabila telah mempunyai akun yang sudah aktif, atau registrasi dan validasi

jika belum memiliki akun yang aktif. Validasi dilakukan setelah melakukan

registrasi dengan mengirim kode one time password, yaitu kode yang

dikirim via sms kepada nomor telefon pengguna yang didaftarkan, validasi

ditujukan agar tidak ada akun palsu karena sesuai Peraturan Menteri

Komunikasi dan Informatika Nomor 14 Tahun 2017 tanggal 5 September

2017 bahwa nomor telefon wajib divalidasi menggunakan nomor induk

kependudukan (NIK) dan nomor kartu keluarga (KK).

Pengujian berikutnya yaitu pengujian sebagai korban, melakukan

pelaporan darurat menggunakan aplikasi dengan cara: tombol yang ada di

99


aplikasi, tombol daya perangkat, dan perintah suara. Pelaporan yang

dilakukan dengan tombol di dalam aplikasi, akan langsung dicatat

pelaporannya dan masuk ke dalam database, sedangkan pelaporan darurat

menggunakan tombol daya perangkat ataupun perintah suara, terdapat

konfirmasi pelaporan selama 10 detik. Konfirmasi pelaporan ditujukan

guna menghindari false alarm atau kesalahan pelaporan yang dilakukan

secara tidak sengaja. Apabila user tidak membatalkan pelaporan, maka akan

dicatat dan disimpan ke dalam database.

Pelaporan dengan tombol daya dilakukan dengan cara pengguna

menekan tombol daya sebanyak 3 kali atau lebih dalam 4 detik, baik user

sedang membuka aplikasi, ataupun tidak. Pelaporan yang dilakukan dengan

perintah suara dilakukan dengan pengguna memproduksi suara dengan

tingkat kebisingan 70dB atau lebih, guna memicu aplikasi membuka servis

penangkapan kata yang dilontarkan oleh pengguna. Apabila perintah suara

dikenal oleh aplikasi, maka konfirmasi pelaporan akan muncul yang

nantinya akan dicatat sebagai pelaporan baru.

Selain pengujian aplikasi dilakukan pada sisi korban, selanjutnya

pengujian dilakukan pada sisi penolong, dimulai dengan konfirmasi

penolong. Konfirmasi penolong dibagi 2, yaitu: pengguna tidak menolong,

dikatakan berhasil apabila tidak muncul notifikasi oleh pelaporan darurat

tersebut, dan pengguna konfirmasi akan menolong yang ditunjukan terdapat

notifikasi pelaporan darurat yang aktif, dan penolong dapat berinteraksi

oleh korban, ataupun dengan penolong lainnya.

Pengujian pada halaman pelaporan darurat yang aktif dibagi menjadi

3, yaitu:

1. Halaman beranda pada pelaporan darurat yang aktif.

Halaman beranda berisi dengan data korban yang telah

diregistrasi sebelumnya, lokasi korban terkini yang diperbarui

100


berkala, serta tipe pengguna apakah sebagai korban atau sebagai

penolong guna meminimalisir kekeliruan.

2. Halaman obrolan pada pelaporan darurat yang aktif.

Halaman obrolan ditujukan agar pengguna yang terdaftar pada

pelaporan yang aktif tersebut dapat berinteraksi satu dengan

yang lainnya.

3. Halaman aksi pada pelaporan darurat yang aktif.

Halaman aksi berisi aksi yang dapat dilakukan oleh pengguna,

yaitu pembatalan pelaporan jika sebagai korban dan pembatalan

menolong jika sebagai penolong. Aksi berikutnya aksi untuk

menelfon korban, menelfon kontak darurat, serta menelfon

telefon darurat 112. Aksi lainnya yaitu aksi untuk navigasi yang

dapat dilakukan dengan membuka google maps, atau maps yang

terdapat pada perangkat.

5.2.2. Hasil Pengujian Kelayakan Aplikasi

Hasil dari pengujian yang dilakukan sebanyak 3 kali, dengan

perangkat berbeda dan versi android yang berbeda. Pengujian dilakukan pada

hari 13 Januari 2019, mulai pukul 16:00. Pengujian aplikasi dilakukan

selama 30 menit. Adapun hasil pengujian dapat dilihat pada tabel 5.2. Hasil

pengujian aplikasi dengan 3 kali percobaan.

Tabel 5.4. Hasil pengujian aplikasi dengan 3 kali percobaan

No Pengujian

Percobaan 1

(Samsung

SM-T111,

Android 4.2.2)

Percobaan 2

(Sony Xperia

LT28h ,

Android 4.1.2)

Percobaan 3

(Samsung

SM-T111,

Android 4.2.2)

1 Log in berhasil - tidak

masuk ke

berhasil - tidak

masuk ke

berhasil - tidak

masuk ke

101


halaman log in

apabila

membuka

aplikasi

kembali

halaman log in

apabila

membuka

aplikasi

kembali

halaman log in

apabila

membuka

aplikasi

kembali

2 Log out berhasil - tidak

muncul

notifikasi

apabila ada

pelaporan

darurat

berhasil - tidak

muncul

notifikasi

apabila ada

pelaporan

darurat

berhasil - tidak

muncul

notifikasi

apabila ada

pelaporan

darurat

3 Register berhasil -

dengan validasi

bahwa 1 user 1

username dan 1

nomor

handphone

berhasil -

dengan validasi

bahwa 1 user 1

username dan 1

nomor

handphone

berhasil -

dengan validasi

bahwa 1 user 1

username dan 1

nomor

handphone

4 Validasi user berhasil -

vaildasi

dilakukan

dengan

mengirim

pesan sms

berupa kode

dan dengan

pulsa user

berhasil -

vaildasi

dilakukan

dengan

mengirim

pesan sms

berupa kode

dan dengan

pulsa user

berhasil -

vaildasi

dilakukan

dengan

mengirim

pesan sms

berupa kode

dan dengan

pulsa user

102


5 Pelaporan

darurat

menggunakan

tombol pada

aplikasi

berhasil -

pelaporan

darurat

langsung

terdaftar ke

dalam database

tanpa notifikasi

pembatalan

laporan

berhasil -

pelaporan

darurat

langsung

terdaftar ke

dalam database

tanpa notifikasi

pembatalan

laporan

berhasil -

pelaporan

darurat

langsung

terdaftar ke

dalam database

tanpa notifikasi

pembatalan

laporan

6 Pelaporan

darurat

menggunakan

tombol daya

perangkat

berhasil (saat

membuka

aplikasi

maupun

backgorund)

berhasil (saat

membuka

aplikasi

maupun

backgorund)

berhasil (saat

membuka

aplikasi

maupun

backgorund)

7 Pelaporan

darurat

menggunakan

perintah

suara

berhasil dengan

kendala

pelafalan kata

harus benar

(menggunakan

bahasa inggris)

berhasil dengan

kendala

pelafalan kata

harus benar

(menggunakan

bahasa inggris)

berhasil dengan

kendala

pelafalan kata

harus benar

(menggunakan

bahasa inggris)

8 Menolak

membantu

korban

berhasil (tidak

muncul

notifikasi

pelaporan

darurat tersebut

kembali)

berhasil (tidak

muncul

notifikasi

pelaporan

darurat tersebut

kembali)

berhasil (tidak

muncul

notifikasi

pelaporan

darurat tersebut

kembali)

9 Menerima

membantu

berhasil (masuk

kedalam

berhasil (masuk

kedalam

berhasil (masuk

kedalam

103


korban pelaporan

darurat yang

aktif)

pelaporan

darurat yang

aktif)

pelaporan

darurat yang

aktif)

10 Pelaporan

darurat aktif -

data terupdate

berkala

Berhasil pada

sisi penolong

berhasil pada

sisi korban

berhasil pada

sisi penolong

11 Pelaporan

darurat aktif -

obrolan

Berhasil pada

sisi penolong

dengan catatan:

pesan pertama

tidak masuk

berhasil pada

sisi korban

dengan catatan:

pesan pertama

tidak masuk

berhasil pada

sisi penolong

dengan catatan:

pesan pertama

tidak masuk

12 Pelaporan

darurat aktif -

aksi

membatalkan

laporan

berhasil pada

percobaan

kedua, pada

percobaan

pertama

notifikasi

muncul

kembali (pada

sisi penolong)

berhasil (sisi

korban)

berhasil pada

percobaan

pertama (sisi

penolong)

13 Pelaporan

darurat aktif -

aksi menelfon

korban

Berhasil pada

sisi penolong

berhasil pada

sisi korban -

terdapat pesan

bahwa saya

adalah korban

berhasil pada

sisi penolong

14 Pelaporan

darurat aktif -

berhasil berhasil berhasil

104


aksi menelfon

kontak

darurat

15 Pelaporan

darurat aktif -

aksi menelfon

112

berhasil berhasil berhasil

16 Pelaporan

darurat aktif -

navigasi ke

lokasi korban

berhasil dengan

catatan:

navigasi

dilakukan oleh

aplikasi pihak

ketiga, sesuai

aplikasi yang

tersedia pada

perangkat

berhasil dengan

catatan:

navigasi

dilakukan oleh

aplikasi pihak

ketiga, sesuai

aplikasi yang

tersedia pada

perangkat

berhasil dengan

catatan:

navigasi

dilakukan oleh

aplikasi pihak

ketiga, sesuai

aplikasi yang

tersedia pada

perangkat

Dari pengujian yang dilakukan, maka terdapat beberapa temuan yang

menjadi hasil keberhasilan aplikasi yang dikembangkan dan yang menjadi

fokus penulis,:

1. Proses log in, log out, registrasi, dan validasi berjalan lancar.

2. Proses pelaporan darurat menggunakan tombol yang ada pada

perangkat berjalan lancar.

3. Pelaporan yang dilakukan menggunakan tombol daya dapat

dilakukan baik saat pengguna membuka aplikasi, maupun tidak

dalam membuka aplikasi.

4. Pelaporan yang dilakukan menggunakan perintah suara dapat

dilakukan baik dalam aplikasi ataupun pada saat tidak membuka

105


aplikasi, dan perintah suara dapat dilakukan dengan layar mati atau

terkunci.

5. Pelaporan darurat menggunakan perintah suara ditemukan kendala

pada saat pengguna melakukan perintah suara, yaitu kata yang

diucapkan tidak terbaca oleh aplikasi, pelafalan kata harus jelas

dengan bahasa inggris yang benar.

6. Pembatalan pelaporan degan waktu 10 detik sebelum pelaporan

darurat dicatat, berjalan dengan baik, yaitu apabila pengguna

membatalkan atau tidak melakukan apapun.

7. Konfirmasi penolong berjalan dengan lancar, ditandai apabila

pengguna menolak, maka tidak akan muncul notifikasi dari

pelaporan darurat tersebut, dan ditandai pengguna akan terdaftar

dalam pelaporan darurat tersebut.

8. Pembatalan pelaporan terdapat kendala, apabila koneksi internet

tidak bagus, maka notifikasi akan terus muncul, dan akan hilang

apabila dilakukan kembali pembatalan pelaporan darurat.

5.3. Pengujian Performa Aplikasi

Pengujian Performa Aplikasi dilakukan guna mengetahui performa aplikasi

yang dikembangkan. Pengujian dilakukan sebanyak 5 kali dari setiap aksi, yang

dilakukan oleh 4 user berbeda, dan dengan perangkat yang berbeda. Adapun

pengujian yang dilakukan antara lain :

1. Button in App - waktu hingga pelaporan tercatat (detik)

2. Button in App - waktu hingga pelaporan sampai ke penolong (detik)

3. Button in App - banyaknya melakukan pelaporan hingga berhasil

4. Power Button - waktu hingga pelaporan tercatat (detik)

5. Power Button - waktu hingga pelaporan sampai ke penolong (detik)

6. Power Button - banyaknya melakukan pelaporan hingga berhasil

7. Voice Command - waktu hingga pelaporan tercatat (detik)

106


8. Voice Command - waktu hingga pelaporan sampai ke penolong (detik)

9. Voice Command - banyaknya melakukan pelaporan hingga berhasil

10. Waktu hingga chat terkirim (detik)

11. Waktu dari pelaporan tercatat, hingga sampai ke penolong dalam jarak

251 meter hingga 500 meter dari korban

5.3.1. Skenario Pengujian Performa

Pengujian dilakukan dengan minimal 2 aktor, yaitu sebagai korban

yang melakukan pelaporan darurat, dan sebagai penolong. Pengujian aplikasi

dilakukan sebanyak 5 kali pengujian, dengan 4 penguji berbeda sesuai

dengan perangkat dan versi android yang digunakan. Adapun skenario

pengujian dapat dilihat pada tabel Tabel 5.5. Skenario Pengujian Performa

Aplikasi.

Tabel 5.5. Skenario Pengujian Performa Aplikasi

No parameter

pengujian

langkah pengujian Tujuan

1 2 3

1

Button in

App - waktu

hingga

pelaporan

tercatat

(detik)

Korban

menekan

tombol

yang ada

aplikasi

pencatatan

waktu

dimulai pada

saat user

menekan

tombol

pencatatan

waktu

berhenti

ketika muncul

notifikasi

"Current

Emergency

Active"

Menghitung

waktu yang

dibutuhkan

dari korban

menekan

tombol, hingga

pelaporan

tercatat

2

Button in

App - waktu

hingga

pelaporan

sampai ke

Korban

menekan

tombol

yang ada

aplikasi

pencatatan

waktu

dimulai pada

saat user

menekan

pencatatan

waktu

berhenti

ketika muncul

notifikasi

Menghitung

waktu yang

dibutuhkan

dari korban

menekan

107


penolong

(detik)

tombol "Help!" pada

sisi penolong

tombol, hingga

notifikasi

masuk ke

penolong

3

Button in

App -

banyaknya

melakukan

pelaporan

hingga

berhasil

Korban

menekan

tombol

yang ada

aplikasi

jika

pelaporan

tidak

tercatat,

maka user

menekan

tombol

kembali

hingga

berhasil

Pencatatan

dimulai pada

saat pertama

kali

percobaan,

hingga

berhasil

banyak nya

user menekan

tombol hingga

berhasil

4

Power

Button -

waktu hingga

pelaporan

tercatat

(detik)

Korban

menekan

tombol

daya pada

perangkat

pencatatan

waktu

dimulai pada

saat user

menekan

tombol daya

pencatatan

waktu

berhenti

ketika muncul

notifikasi

"Current

Emergency

Active"

Menghitung

waktu yang

dibutuhkan

dari korban

menekan

tombol, hingga

pelaporan

tercatat

5

Power

Button -

waktu hingga

pelaporan

sampai ke

Korban

menekan

tombol

daya pada

perangkat

pencatatan

waktu

dimulai pada

saat user

menekan

pencatatan

waktu

berhenti

ketika muncul

notifikasi

Menghitung

waktu yang

dibutuhkan

dari korban

menekan

108


penolong

(detik)

tombol daya "Help!" pada

sisi penolong

tombol, hingga

notifikasi

masuk ke

penolong

6

Power

Button -

banyaknya

melakukan

pelaporan

hingga

berhasil

Korban

menekan

tombol

daya pada

perangkat

jika

pelaporan

tidak

tercatat,

maka user

menekan

tombol

kembali

hingga

berhasil

Pencatatan

dimulai pada

saat pertama

kali

percobaan,

hingga

berhasil

banyak nya

user menekan

tombol hingga

berhasil

7

Voice

Command -

waktu hingga

pelaporan

tercatat

(detik)

Korban

melakukan

perintah

suara

pencatatan

waktu

dimulai pada

saat user

melakukan

perintah

surar

pencatatan

waktu

berhenti

ketika muncul

notifikasi

"Current

Emergency

Active"

Menghitung

waktu yang

dibutuhkan

dari korban

melakukan

perintah suara,

hingga

pelaporan

tercatat

109


8

Voice

Command -

waktu hingga

pelaporan

sampai ke

penolong

(detik)

Korban

melakukan

perintah

suara

pencatatan

waktu

dimulai pada

saat user

melakukan

perintah

surar

pencatatan

waktu

berhenti

ketika muncul

notifikasi

"Help!" pada

sisi penolong

Menghitung

waktu yang

dibutuhkan

dari korban

melakukan

perintah suara,

hingga

notifikasi

masuk ke

penolong

9

Voice

Command -

banyaknya

melakukan

pelaporan

hingga

berhasil

Korban

melakukan

perintah

suara

jika

pelaporan

tidak

tercatat,

maka user

melakukan

perintah

suara

kembali

hingga

berhasil

Pencatatan

dimulai pada

saat pertama

kali

percobaan,

hingga

berhasil

banyak nya

user

melakukan

perintah suara

hingga

berhasil

10

waktu hingga

chat terkirim

(detik)

user

mengirim

pesan

melalui

fitur

obrolan

pencatatan

waktu

dimulai

ketika user

menekan

tombol

"send"

pencatatan

waktu

berhenti

ketika pesan

masuk

kedalam

halaman

waktu yang

dibutuhkan

sampai pesan

masuk

110


berlogo

kertas lipat

obrolan

11

Waktu dari

pelaporan

tercatat,

hingga

sampai ke

penolong

dalam jarak

251 meter

hingga 500

meter dari

korban

Korban

melakukan

pelaporan

darurat

pencatatan

waktu

dimulai

pada saat

pelaporan

tercatat ke

dalam

database

pencatatan

waktu

berhenti

ketika muncul

notifikasi

"Help!" pada

sisi penolong

yang berjarak

251 meter

hingga 500

meter dari

korban

Menghitung

waktu yang

dibutuhkan

untuk

pelaporan

darurat jika

penolong

berada pada

jarak 251

meter hingga

500 meter dari

korban

Pengujian aplikasi dimulai dengan pelaporan darurat menggunakan

tombol yang ada pada aplikasi, pelaporan darurat menggunakan tombol daya

pada perangkat, pelaporan menggunakan perintah suara. Pengujian peforma

pada pelaporan darurat yaitu pada saat user melakukan pelaporan, berapa

waktu yang digunakan hingga pelaporan tercatat, berapa waktu yang

digunakan hingga pelaporan sampai kepada penolong, serta banyaknya

percobaan hingga berhasil. Pengujian performa selanjutnya merupakan

pengujian fitur obrolan pada aplikasi, yaitu mengukur waktu yang

dibutuhkan dari user mengirim pesan, hingga pesan sampai kepada user

lainnya.

5.3.2. Hasil Pengujian Performa Aplikasi

Pengujian dilakukan terhitung mulai tanggal 27 januari 2019 hingga 5

111


februari 2019 dengan 4 perangkat yang berbeda dan versi android yang

digunakan. Hasil pengujian performa selanjutnya akan dihitung rata-rata dari

5 kali percobaan yang dilakukan, adapun hasil pengujian dapat dilihat pada

tabel Tabel 5.6. Hasil pengujian performa aplikasi.

Tabel 5.6. Hasil pengujian performa aplikasi

No Parameter

Pengujian

Rata-rata Sony

Xperia

Lt28h

Samsung

SM-T111

Xiaomi

Redmi

Note 4x

Andromax

A16C3H

1

Button in App -

waktu hingga

pelaporan

tercatat (detik)

0,48 0,64 0,7 1 0,89

2

Button in App -

waktu hingga

pelaporan

sampai ke

penolong

(detik)

7,68 5,84 6,4 7,2 6,96

3

Button in App -

banyaknya

melakukan

pelaporan

hingga berhasil

1 1 1 1 1,00

4

Power Button -

waktu hingga

pelaporan

tercatat (detik)

15,76 15,86 15,48 18,14 16,63

112


5

Power Button -

waktu hingga

pelaporan

sampai ke

penolong

(detik)

20,08 19,42 18,58 22,2 21,08

6

Power Button -

banyaknya

melakukan

pelaporan

hingga berhasil

1 1 1 1 1,15

7

Voice

Command -

waktu hingga

pelaporan

tercatat (detik)

13,72 14,28 11,86 14,78 14,21

8

Voice

Command -

waktu hingga

pelaporan

sampai ke

penolong

(detik)

20,78 19,82 17,16 20,74 20,33

9

Voice

Command -

banyaknya

melakukan

pelaporan

1,6 1,6 1 1,4 1,50

113


hingga berhasil

10

waktu hingga

chat terkirim

(detik)

1,42 1,88 2,4 2,32 2,06

11

Waktu dari

pelaporan

tercatat, hingga

sampai ke

penolong dalam

jarak 251 meter

hingga 500

meter dari

korban

39,2 38,8 39,9 41,8 39,925

Dari pengujian yang dilakukan, maka terdapat beberapa temuan yang

menjadi hasil performa aplikasi yang dikembangkan dan yang menjadi fokus

penulis :

1. Pengujian aplikasi pelaporan darurat menggunakan tombol yang

ada pada aplikasi, berjalan lancar pada percobaan pertama, dengan

waktu rata-rata dari mulai korban menekan tombol hingga tercatat

dibawah 1 detik, yaitu 0,89 detik. Waktu yang dibutuhkan hingga

pelaporan sampai kepada penolong yaitu 6,96 detik.

2. Pengujian aplikasi pelaporan darurat menggunakan tombol daya

yang ada pada perangkat, berjalan lancar pada percobaan ke 1,15

dengan waktu rata-rata dari mulai korban menekan tombol daya

hingga tercatat adalah 16,63 detik dan 21,08 detik hingga sampai

kepada penolong yang mana waktu tersebut sudah termasuk 10

114


detik hitung mundur untuk membatalkan pelaporan.

3. Pengujian aplikasi pelaporan darurat menggunakan perintah suara,

berjalan lancar pada percobaan ke 1,5. Waktu rata-rata yang

dibutuhkan bagi korban dari mulai melakukan perintah suara

hingga tercatat yaitu 14,21 detik dan 20,33 detik hingga pelaporan

sampai ke penolong yang mana waktu tersebut sudah termasuk 10

detik hitung mundur untuk membatalkan pelaporan.

4. Fitur chat pada aplikasi yang ditujukan agar sesama user dapat

berinteraksi satu dengan yang lainnya, membutuhkan waktu

rata-rata 2,06 detik dari user menekan tombol kirim, hingga pesan

tersebut sampai kepada user lainnya.

5. Pengujian aplikasi untuk pelaporan darurat dengan kondisi

penolong berjarak 251 meter hingga 500 meter dari korban

berjalan dengan lancar, dengan 2 kali testing dari tiap user, didapat

hasil 39,9 detik dari pelaporan tercatat, hingga muncul notifikasi

ke penolong.

115


BAB VI

PENUTUP

6.1. Kesimpulan

Berdasarkan dari hasil penelitian yang telah dijelaskan, maka dapat diambil

kesimpulan, bahwa aplikasi manajemen darurat menggunakan pelaporan darurat

tombol yang ada pada aplikasi, tombol daya, dan perintah suara berjalan dengan

lancar sesuai dengan koneksi internet yang digunakan dalam pengoperasian

aplikasi, dan Pelaporan yang dilakukan oleh tombol daya dan perintah suara

dapat dilakukan pada background dan layar terkunci, namun keberhasilan pada

pelaporan menggunakan perintah suara ditentukan oleh jelasnya pelafalan kata

yang diatur menggunakan bahasa inggris yang dilakukan setelah aplikasi

mendapat fokus untuk menangkap kata yang dilontarkan oleh pengguna.

Tingkat keakuratan data korban pada saat melapor ditentukan dari jenis

perangkat dan jenis koneksi internet yang digunakan, dengan waktu pelaporan

darurat menggunakan tombol yang ada aplikasi yaitu 6,96 detik hingga sampai ke

penolong berjalan lancar pada percobaan pertama. Percobaan pelaporan darurat

menggunakan tombol daya didapat 21,08 detik hingga sampai ke penolong,

berjalan lancar pada percobaan rata-rata ke 1,15 kali. Pelaporan menggunakan

perintah suara didapat 20,33 hingga sampai ke penolong, berjalan lancar dengan

rata-rata percobaan ke 1,5 kali.

Pelaporan darurat yang dilakukan oleh korban dengan kondisi penolong

berada di jarak 251 hingga 500 meter dari korban, didapat waktu hingga

notifikasi muncul di penolong adalah 39,9 detik, hal tersebut dikarenakan dalam

30 detik pertama, aplikasi hanya mengirim notifikasi ke penolong terdekat dalam

jarak 250 meter, namun jika dalam 30 detik tidak ada penolong, maka aplikasi

akan menambah jarak dengan kelipatan 250 meter.

116


6.2. Saran

Aplikasi yang dikembangkan masih terdapat beberapa kekurangan dan

keterbatasan. Oleh karena itu, penulis menyarankan:

1. Aplikasi mengimplementasikan Firebase yang disediakan oleh Google

sebagai penampung data realtime, guna mempercepat proses pelaporan

darurat.

2. Diharapkan aplikasi dapat terintegrasi oleh pihak yang berwenang, guna

mempercepat proses penanggulangan.

3. Meningkatkan akurasi lokasi korban saat melakukan pelaporan darurat.

4. Aplikasi dikembangkan pada platform lain yang tersedia selain android,

yakni IOS, windows phone, dan sebagainya.

5. Pembaruan desain aplikasi agar sesuai dengan user experience (UX) dan

aplikasi dapat mudah dimengerti dalam pengoprasiannya.

117


DAFTAR PUSTAKA

Buku dan Jurnal:

Arnal, Luc H., Adeen Flinker, Andreas Kleinschmidt, Anne Lise Giraud, and

David Poeppel. 2015. “Human Screams Occupy a Privileged Niche in the

Communication Soundscape.” Current Biology 25 (15): 2051–56.

https://doi.org/10.1016/j.cub.2015.06.043.

Arora, Ritika, and Neha Arora. 2016. “Analysis of SDLC Models.” International

Journal of Current Engineering and Technology 6 (1): 268–72.

http://inpressco.com/category/ijcet.

Badan Nasional Penanggulangan Bencana (BNPB). 2017. “Panduan Saku

Satpam.”

Cradel, Paul J. 2016. “Android App Development in Android Studio: Java.”

https://www.amazon.co.uk/Android-App-Development-Studio-Beginners/dp

/1542885841/ref=sr_1_1?ie=UTF8&qid=1490951026&sr=8-1&keywords=a

ndroid+app+development+in+java.

Dari, Yohanes Erwin, Suyoto Suyoto Suyoto, and Pranowo Pranowo Pranowo.

2018. “CAPTURE: A Mobile Based Indoor Positioning System Using

Wireless Indoor Positioning System.” International Journal of Interactive

Mobile Technologies (IJIM) 12 (1): 61.

https://doi.org/10.3991/ijim.v12i1.7632.

El-Sulthani, K.H. Mawardi Labay. 2003. "Upaya Canggih Melawan Terror;

Berperannya Agama." Jakarta: Penulis.

Evanco, William M. 2010. “The Impact of Rapid Incident Detection on Freeway

Accident Fatalities.” Freeway Accident Fatalities.

Fallis, A.G. 2013. GLOBAL POSITIONING SYSTEM Theory and Applications

Volume1. Journal of Chemical Information and Modeling. Vol. 53.

118


https://doi.org/10.1017/CBO9781107415324.004.

Figueiredo, Isabel N., Carlos Leal, Luís Pinto, Jason Bolito, and André Lemos.

2016. “Smartphone Application for Emergency Signal Detection.” Medical

Engineering and Physics. https://doi.org/10.1016/j.medengphy.2016.05.002.

Halpin, Terry, Ken Evans, Patrick Hallock, Bill Maclean, Jim Melton, Jim Melton,

Alan R Simon, and Malcolm Chisholm. 1999. Location-Based Services to

the Wider World.

Jiang, Pei, Yunzhou Zhang, Wenyan Fu, Huiyu Liu, and Xiaolin Su. 2015.

“Indoor Mobile Localization Based on Wi-Fi Fingerprint’s Important Access

Point.” International Journal of Distributed Sensor Networks.

https://doi.org/10.1155/2015/429104.

KENNETH E. KENDALL, and JULIE E. KENDALL. 2011. System Analysis

and Design 8th Edition. Edited by Sally Yagan. 8th Editio. New Jersey:

S4Carlisle Publishing Services, Inc.

Khan, Arsalan, Farzana Bibi, Muhammad Dilshad, Salman Ahmed, Zia Ullah,

and Haider Ali. 2018. “Accident Detection and Smart Rescue System Using

Android Smartphone with Real-Time Location Tracking.” IJACSA)

International Journal of Advanced Computer Science and Applications.

https://doi.org/10.14569/IJACSA.2018.090648.

Purwawidada, Fajar. 2014. “Jaringan Baru Teroris Solo.” Jakarta: Gramedia.

Reichenbacher, Tumasch. 2004. “PD196 Mobile Cartography – Adaptive

Visualisation of Geographic Information on Mobile Devices.” Fakultat Fur

Bauingenieur– Und Vermessungswesen.

Retnoningsih, Endang. 2016. “APLIKASI INFORMASI TELEPON DARURAT

MENGGUNAKAN ANDROID BERBASIS LOCATION BASED

SERVICE (LBS).” Seminar Nasional Sains Dan Teknologi Fakultas Teknik

Universitas Muhammadiyah Jakarta.

Ritzkal. 2017. “Modul UML Dengan Studi Kasus,” no. September 2014.

119


Savale, Sagar. 2018. “6M Method for Cause and Effect Analysis,” no. November:

1. https://www.edrawsoft.com/6m-method.php.

Internet:

Annual Global Road Crash Statistic. ASIRT (Association for Save International

Roal Travel).

http://asirt.org/Initiatives/Informing-Road-Users/Road-Safety-Facts/Road-

Crash-Statistics. (Diakses pada September 2018)

Badan Penanggulangan Bencana Daerah Provinsi DKI Jakarta.

http://bpbd.jakarta.go.id. (Diakses pada Juni 2018)

BNPT Libatkan Ribuan Penyuluh Agama dalam Pencegahan Terorisme.

https://www.bnpt.go.id/bnpt-libatkan-ribuan-penyuluh-agama-dalam-penceg

ahan-terorisme.html. (Diakses pada juli 2018)

Britannica. Speech Recognition.

https://www.britannica.com/technology/speech-recognition. (Diakses pada

September 2018)

Data Informasi Bencana Indonesia. Badan Nasional Penanggulangan Bencana.

http://dibi.bnpb.go.id/. (Diakses pada September 2018)

DPR sahkan revisi UU Terorisme, Perppu tak lagi diperlukan.

http://www.bbc.com/indonesia/indonesia-44248953. (Diakses pada juni

2018)

Emergency Call Buttons: Outdated system or necessary protocol?

https://www.metro.us/news/local-news/new-york/do-emergency-call-buttons

-work. (Diakses pada juli 2018)

Global Positioning System.

https://www.nasa.gov/directorates/heo/scan/communications/policy/GPS.ht

ml. (Diakses pada Oktober 2018)

GPS. https://techterms.com/definition/gps. (Diakses pada Oktober 2018)

http://bpbd.jakarta.go.id/

120


Hubungi Nomor 112, Panggilan Darurat Versi Indonesia. Republika.

https://www.republika.co.id/berita/koran/kesra/16/04/29/o6dso610-hubungi-

nomor-112-panggilan-darurat-versi-indonesia. (Diakses pada September

2018)

Health & Safety: Building Emergency Fittings – Visual Guide. Safety.

https://safety.unimelb.edu.au/__data/assets/word_doc/0009/2327742/Buildin

g-emergency-fittings-visual-guide.docx. (Diakses pada juli 2018)

How GPS System Works. https://www.elprocus.com/how-gps-system-works/.

(Diakses pada Oktober 2018)

Jumlah Kecelakaan, Koban Mati, Luka Berat, Luka Ringan, dan Kerugian Materi

yang Diderita Tahun 1992-2016. Badan Pusat Statistik.

https://www.bps.go.id/linkTableDinamis/view/id/1134. (Diakses pada

September 2018)

Introduction to OMG (Object Management Group) Unified Modelling Language

(UML). http://www.uml.org/what-is-uml.htm. (Diakses pada November

2018)

LiveScience. Accelerometers: What They Are & How They Work.

https://www.livescience.com/40102-accelerometers.html. (Diakses pada

September 2018)

Location Based Service: Mobile Applications.

https://www.gsa.europa.eu/library/case-studies/location-based-services-lbs-

mobile-applications. (Diakses pada Oktober 2018)

Road Traffic Injuries. World Health Organization.

http://www.who.int/news-room/fact-sheets/detail/road-traffic-injuries.

(Diakses pada September 2018)

Tentang Badan Nasional Penanggulanan Terorisme.

https://www.bnpt.go.id/tentang-bnpt. (Diakses pada juli 2018)

Tergusur Internet, Yellow Pages Berhenti Cetak.

121


https://inet.detik.com/cyberlife/d-3627553/tergusur-internet-yellow-pages-be

rhenti-cetak. (Diakses pada Oktober 2018)

Trilateration vs Triangulation – How GPS Receivers Work.

https://gisgeography.com/trilateration-triangulation-gps/. (Diakses pada

Oktober 2018)

Usai Shalat, Seorang Nenek Dibacok Perampok di Rumah Korban.

https://regional.kompas.com/read/2018/06/11/19201851/usai-shalat-seorang-

nenek-dibacok-perampok-di-rumah-korban. (Diakses juli 2018)

122


LAMPIRAN-LAMPIRAN

LAMPIRAN 1

1. Android – proses saat user menekan tombol pelaporan darurat

FloatingActionButton fab = (FloatingActionButton)

findViewById(R.id.fab);

fab.setOnClickListener(new View.OnClickListener() {

@Override

public void onClick(View view) {

reportAnEmergency();

}

});

2. Android – proses pelaporan darurat pada aplikasi

private void reportAnEmergency(){

locationManager = (LocationManager)

getSystemService(Context.LOCATION_SERVICE);

if (ActivityCompat.checkSelfPermission(this,

Manifest.permission.ACCESS_FINE_LOCATION)

!= PackageManager.PERMISSION_GRANTED &&

ActivityCompat.checkSelfPermission(this,

Manifest.permission.ACCESS_COARSE_LOCATION)

!= PackageManager.PERMISSION_GRANTED) {

return;

}

final Location location =

locationManager.getLastKnownLocation(LocationManager.NETWOR

K_PROVIDER);

String status = new

DoSomething().selectStatusIfNewEmergency(MainActivity.this)

;

Integer distance = new

DoSomething().selectEmergencyDistance(MainActivity.this);

EmergencyHandler emergencyHandler = new

EmergencyHandler(userID, WebConfig.buttonInApps,

123


WebConfig.activeFlag, status, distance, location,

MainActivity.this);

emergencyHandler.registerNewEmergency();

}

124


LAMPIRAN 2

1. Android – proses perhitungan saat user menekan tombol power, dan

proses mulai perhitungan waktu

public void onReceive(Context context, Intent intent) {

this.context = context;

if(!isCdtRunning){

if (new DoSomething().checkIsUserLogin(context)){

startCountdownTimer();

}

}

switch (intent.getAction()){

case Intent.ACTION_SCREEN_OFF :

isScreenOn = Boolean.FALSE; break;

case Intent.ACTION_SCREEN_ON :

isScreenOn = Boolean.TRUE; break;

default: ; break;

}

count++;

}

2. Android – proses perhitungan jumlah berapa kali user menekan tombol

power

public void startCountdownTimer(){

cdt = new CountDownTimer(cdtTimesMillisLeft,1000) {

@Override

public void onTick(long millisUntilFinished) {

}

@Override

public void onFinish() {

isCdtRunning = Boolean.FALSE;

if(count>=WebConfig.screenOnOffButtonCount){

StartCancelCountdown();

}

resetTimer();

}

}.start();

isCdtRunning = Boolean.TRUE;

}

125


3. Android – proses hitung mundur untuk pembatalan laporan

public void StartCancelCountdown(){

if(!isCdtRunning2){

showCancelNotification();

startEmergencyCancelCountdown();

}

}

public void startEmergencyCancelCountdown(){

cdt2 = new CountDownTimer(cdtTimesMillisLeft2,1000) {

@Override

public void onTick(long millisUntilFinished) {

vibrateDevice();

}

@Override

public void onFinish() {

SharedPreferences sharedPreferences =

context.getSharedPreferences(EmergencyEnum.emergencySharedP

references.name(),MODE_PRIVATE);

Boolean isCancelEmergency =

sharedPreferences.getBoolean(NotificationEnum.isCancelEmerg

ency.name(),Boolean.FALSE);

if(!isCancelEmergency){

sendButtonEmergency(WebConfig.activeFlag);

}else{

}

clearNotification(WebConfig.cancelNotificationID);

resetTimer2();

}

}.start();

}

126


LAMPIRAN 3

1. Android – proses memulai service untuk mendeteksi tingkat kebisingan

public void startRunner() {

if(new

DoSomething().checkIsUserLogin(BackgroundService.this)){

if (runner == null) {

runner = new Thread() {

public void run() {

while (runner != null) {

try {

Thread.sleep(1000);

} catch (InterruptedException e) {

e.printStackTrace();

} catch (Exception e){


Toast.makeText(BackgroundService.this, e.toString(),

Toast.LENGTH_SHORT).show();

}

handler.post(updater);

}

}

};

runner.start();

}else{

}

}

}

final Runnable updater = new Runnable() {

@Override

public void run() {

updatedBMeter();

}

};

2. Android – proses menghitung tingkat kebisingan, dan memulai pelaporan

darurat jika kebisingan lebih dari yang ditentukan

127


private void updatedBMeter() {

if(!isPrepareStopping){

if(isVoiceRecorderActive && isSignIn &&

mediaRecorder!=null){

double currdBMeter = getAmplitudeEMA();

if(currdBMeter>=noiseLevel &&

!isSpeechRecognition && isSignIn ){

stopRecorder();

startNewSpeechRecognition();

}

}

}

}

private double getAmplitude() {

if(mediaRecorder!=null){

double maxAmp = mediaRecorder.getMaxAmplitude();

return maxAmp;

}else{

return 0;

}

}

3. Android – proses pengenalan suara dari perintah yang sudah disimpan ke

dalam aplikasi

private void startNewSpeechRecognition() {

Intent intent = new

Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH);

intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL,Recog

nizerIntent.LANGUAGE_MODEL_FREE_FORM);

intent.putExtra(RecognizerIntent.EXTRA_MAX_RESULTS,1);

speechRecognizer.startListening(intent);

}

private void processResult(String command) {

if(command != null){

command = command.toLowerCase();

//Help

if(command.indexOf(emergencyWords)!=-1){

startCancelCountdown();

128


speak("Right Away.");

}

isSpeechRecognition = Boolean.FALSE;

startRecorder();

}

129


LAMPIRAN 4

1. Android – proses pengambilan lokasi berupa titik kordinat latitutde dan

longitude serta update ke dalam database

public Location getLastKnownLocations() {

locationManager = (LocationManager)

getApplicationContext().getSystemService(LOCATION_SERVICE);

Location bestLocation = null;

List<String> providers =

locationManager.getProviders(true);

for (String provider : providers) {

Location loc =

locationManager.getLastKnownLocation(provider);

if(loc == null){

continue;

}

if(bestLocation == null || loc.getAccuracy() >

bestLocation.getAccuracy() ){

bestLocation = loc;

}

}

return bestLocation;

}

class LocationUpdate extends AsyncTask<Void, Void, String> {

@Override

protected String doInBackground(Void... voids) {

String s = new String();

HashMap<String, String> locHash = new HashMap<>();

locHash.put(LocationEnum.GPS_LOCATION_LAT.name(),

String.valueOf(location.getLatitude()));

locHash.put(LocationEnum.GPS_LOCATION_LONG.name(),

String.valueOf(location.getLongitude()));

locHash.put(UserEnum.USER_ID.name(), userID);

while (s.isEmpty()) {

RequestHandler requestHandler = new

RequestHandler();

s =

requestHandler.sendPostRequest(WebConfig.URL_LOCATION_SET,

130


locHash, getApplicationContext());

}

return s;

}

}

2. Android – proses pengecekan apabila terdapat korban di sekitar

class NearbyVictimCheck extends AsyncTask<Void, Void, String>

{

@Override

protected String doInBackground(Void... voids) {


getSharedPreferences(EmergencyEnum.emergencySharedPreferenc

es.name(), MODE_PRIVATE);

String blockedEmergency =

sharedPreferences.getString(EmergencyEnum.BLOCKED_EMERGENCY

.name(), "");

String result = new String();

HashMap<String, String> hashMap = new HashMap<>();

hashMap.put(UserEnum.USER_ID.name(), userID);

hashMap.put(EmergencyEnum.BLOCKED_EMERGENCY.name(),

blockedEmergency);

while (result.isEmpty()) {

RequestHandler requestHandler = new

RequestHandler();

result =

requestHandler.sendPostRequest(WebConfig.URL_EMERGENCY_NEAR

BYCHECK, hashMap, getApplicationContext());

}

return result;

}

}

3. Php – proses pengecekan database serta menghitung jarak dari pelaporan

darurat yang aktif dengan lokasi terakhir user

$sql = "SELECT ER.EMERGENCY_REPORT_ID, ER.TRIGGER_TYPE_ID,

ER.GPS_LOCATION_LAT, ER.GPS_LOCATION_LONG, ER.DISTANCE,

ER.CREATED_AT, ER.MODIFIED_AT, ER.FLAG, U.USERNAME, UD.NAMA,

131


UD.NO_HP, UD.KONTAK_DARURAT,

UD.KONTAK_DARURAT_TYPE_ID,UD.CIRI_CIRI, UD.ALAMAT,

UD.KODE_POS FROM emergency_report ER JOIN user U ON U.USER_ID

= ER.USER_ID JOIN user_detail UD ON UD.USER_ID = ER.USER_ID

WHERE ER.USER_ID <> '$USER_ID' AND ER.FLAG = 1";

if(!empty($BLOCKED_EMERGENCY)){

$sql = $sql." AND ER.EMERGENCY_REPORT_ID NOT

IN ($BLOCKED_EMERGENCY)";

}

if(!mysqli_query($connection,$sql)){

echo mysqli_error($connection);

}

$result_query = mysqli_query($connection,$sql);

4. Php – proses perhitungan jarak antara user dengan korban

include "../location/current_location-getByID.php";

$lat1 = $GPS_LOCATION_LAT;

$long1 = $GPS_LOCATION_LONG;

$lat2 = $vGPS_LOCATION_LAT;

$long2 = $vGPS_LOCATION_LONG;

$dist = 10000;

if(!empty($lat1) && !empty($long1) && !empty($lat2) &&

!empty($long2)){

$apiKey = 'API KEY';

$link =

"https://maps.googleapis.com/maps/api/distancematrix/json?o

rigins=$lat1,$long1&destinations=$lat2,$long2&key=$apiKey";

$ch = curl_init();

132


curl_setopt($ch, CURLOPT_URL, $link);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

curl_setopt($ch, CURLOPT_FOLLOWLOCATION, TRUE);

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

$json = curl_exec($ch);

curl_close($ch);

$jsonDecode = json_decode($json);

$status = $jsonDecode->status;

if($status == "OK"){

$rows = $jsonDecode->rows;

$elements =

$rows[0]->elements;

$dist =

$elements[0]->distance->value;

$distText =

$elements[0]->distance->value;

$durText =

$elements[0]->duration->value;

}else{}

133


LAMPIRAN 5

1. Android – pengiriman notifikasi ke penolong apabila terdapat korban di

sekitar (menyambung Lampiran 4, poin nomor 2)

protected void onPostExecute(String s) {

super.onPostExecute(s);

if (s.contains(OthersEnum.JSON_RESULT.name()) &&

!s.equals(WebConfig.emptyJSON)) {


EmergencyHandler(getApplicationContext());

emergencyHandler.helperEmergencyNotification(s);

}

}

public void helperEmergencyNotification(String

emergencyJSON){

Intent intent = new Intent(context,

HelperConfirmationActivity.class);

intent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TASK|Intent.FLAG

_ACTIVITY_CLEAR_TOP);

intent.putExtra(EmergencyEnum.emergencyJSON.name(),emergenc

yJSON);

PendingIntent pendingIntent =

PendingIntent.getActivity(context,0,intent,PendingIntent.FL

AG_UPDATE_CURRENT);

Integer icon = R.drawable.kayfa_icon;

134


NotificationHandler notificationHandler = new

NotificationHandler(context);

notificationHandler.SendNotification(pendingIntent,WebConfi

g.helperValidationNotificationID,icon);

}

2. Android – konfirmasi penolong apakah akan membantu korban atau tidak

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_helper_confirmation);

tv_name_h = findViewById(R.id.tv_name_h);

tv_username_h =

findViewById(R.id.tv_username_h);

tv_handphone_no_h =

findViewById(R.id.tv_handphone_no_h);

tv_modifiedAt_h =

findViewById(R.id.tv_modifiedAt_h);

tv_trigger_type_h =

findViewById(R.id.tv_trigger_type_h);

tv_emergency_contact_no_h =

findViewById(R.id.tv_emergency_contact_no_h);

tv_emergency_contact_type_h =

findViewById(R.id.tv_emergency_contact_type_h);

tv_ciri_ciri_h =

findViewById(R.id.tv_ciri_ciri_h);

tv_alamat_h =

findViewById(R.id.tv_alamat_h);

tv_emergency_location_h =

findViewById(R.id.tv_emergency_location_h);

tv_user_distance_h =

findViewById(R.id.tv_user_distance_h);

btn_helper_no_h =

findViewById(R.id.btn_helper_no_h);

btn_helper_ok_h =

135


findViewById(R.id.btn_helper_ok_h);

btn_helper_no_h.setOnClickListener(this);

btn_helper_ok_h.setOnClickListener(this);

emergencyJSON =

getIntent().getStringExtra(EmergencyEnum.emergencyJSON.name

());

try {

JSONObject jsonObject = new JSONObject(emergencyJSON);

JSONArray jsonArray =

jsonObject.getJSONArray(OthersEnum.JSON_RESULT.name());

JSONObject jo = jsonArray.getJSONObject(0);

emergencyID =

jo.optString(EmergencyEnum.EMERGENCY_REPORT_ID.name(),"");

username =

jo.optString(UserEnum.USERNAME.name(),"");

name =

jo.optString(UserEnum.NAMA.name(),"");

handphone_no =

jo.optString(UserEnum.NO_HP.name(),"");

trigger_type =

jo.optString(EmergencyEnum.TRIGGER_TYPE_ID.name(),"");

emergency_contact_no =

jo.optString(UserEnum.KONTAK_DARURAT.name(),"");

emergency_contact_type =

jo.optString(UserEnum.KONTAK_DARURAT_TYPE_ID.name(),"");

ciri_ciri =

jo.optString(UserEnum.CIRI_CIRI.name(),"");

alamat =

jo.optString(UserEnum.ALAMAT.name(),"");

kode_pos =

jo.optString(UserEnum.KODE_POS.name(),"");

gps =

jo.optString(EmergencyEnum.GPS_LOCATION_LAT.name(),"") +","+

jo.optString(EmergencyEnum.GPS_LOCATION_LONG.name(),"");

modifiedAt =

136


jo.optString(EmergencyEnum.MODIFIED_AT.name(),"");

emergencyFlag =

jo.optString(EmergencyEnum.FLAG.name(),"0");

user_distance =

jo.optString(EmergencyEnum.USER_DISTANCE.name(),"0");

user_distance_text =

jo.optString(EmergencyEnum.USER_DISTANCE_TEXT.name(),"0 m");

user_duration_text =

jo.optString(EmergencyEnum.USER_DURATION_TEXT.name(), "0

s");

status_api =

jo.optString(OthersEnum.STATUS_API.name(), "");

distance = Double.parseDouble(user_distance);

if(!status_api.equals(OthersEnum.OK.name())){

user_distance = user_distance + " m";

}else{

user_distance = user_distance_text + " , (about " +

user_duration_text+")";

}

tv_name_h.setText(name);

tv_username_h.setText("@"+username);

tv_handphone_no_h.setText(handphone_no);

tv_modifiedAt_h.setText(modifiedAt);

tv_trigger_type_h.setText(new

DoSomething().selectTriggerType(Integer.parseInt(trigger_ty

pe)));

tv_emergency_contact_no_h.setText(emergency_contact_no);

tv_emergency_contact_type_h.setText(new

DoSomething().selectEmergencyContactType(Integer.parseInt(e

mergency_contact_type)));

tv_ciri_ciri_h.setText(ciri_ciri);

tv_alamat_h.setText(alamat);

tv_emergency_location_h.setText(kode_pos);

tv_user_distance_h.setText(user_distance);

setAddressLine(Double.parseDouble(jo.optString(EmergencyEnu

137


m.GPS_LOCATION_LAT.name(),"0")),Double.parseDouble(jo.optSt

ring(EmergencyEnum.GPS_LOCATION_LONG.name(),"0")));

} catch (JSONException e) {


}

}

private void setAddressLine(Double gpsLat, Double gpsLong) {

Geocoder geocoder = new

Geocoder(HelperConfirmationActivity.this,

Locale.getDefault());

List<Address> addresses;

try {

addresses =

geocoder.getFromLocation(gpsLat,gpsLong,1);

String emergencyAddress =

addresses.get(0).getAddressLine(0);

tv_emergency_location_h.setText(emergencyAddress);

} catch (IOException e) {


}

}

@Override

public void onClick(View v) {

switch (v.getId()){

case R.id.btn_helper_no_h:

setBlockedEmergenccy();

break;

case R.id.btn_helper_ok_h:

registerNewHelper();

138


break;

}

}

private void setBlockedEmergenccy() {


EmergencyHandler(this);

emergencyHandler.setBlockedEmergency(emergencyID);

}

private void registerNewHelper() {


getSharedPreferences(OthersEnum.userSession.name(),MODE_PRI

VATE);

String userID =

sharedPreferences.getString(OthersEnum.userID.name(),"");

String status = OthersEnum.add.name();

if(userID.isEmpty()){

Toast.makeText(this, "Please click again.",

Toast.LENGTH_SHORT).show();

}else{

139



EmergencyHandler(HelperConfirmationActivity.this);

emergencyHandler.registerNewHelper(emergencyID,userID,statu

s,emergencyFlag);

}

}

140


prototipe aplikasi manajemen darurat berbasis android

Documents