BAB I-VI_Harsy Tamimi_1113091000075

i 

UJI KEAKURATAN WAKTU TEMPUH PADA APLIKASI 

EMERGENCY CALL BERBASIS CROWDSOURCE GOOGLE MAPS API 

DENGAN PARAMETER ESTIMATED TRAVEL TIME 

SKRIPSI 

Diajukan Sebagai Salah Satu Syarat untuk Memperoleh Gelar 

Sarjana Komputer (S.Kom) 

Oleh : 

Harsy Tamimi 

1113091000075 

PROGRAM STUDI TEKNIK INFORMATIKA 

FAKULTAS SAINS DAN TEKNOLOGI 

UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH 

JAKARTA 

2018 M / 1439 H 

UIN Syarif Hidayatullah Jakarta

ii 


iii 

PENGESAHAN UJIAN 


iv 

PERNYATAAN ORISINALITAS 

DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR- 

BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN 

SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI 

ATAU LEMBAGA MANAPUN. 

Jakarta, April 2018 



v 

PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI 

Sebagai civitas akademik UIN Syarif Hidayatullah Jakarta, saya yang 

bertanda tangan dibawah ini: 

Nama : Harsy Tamimi 

NIM : 1113091000075 

Program Studi : Teknik Informatika 

Fakultas : Sains Dan Teknologi 

Jenis Karya : Skripsi 

demi pengembangan ilmu pengetahuan, menyetujui untuk memberikan kepada 

Universitas Islam Negeri Syarif Hidayatullah Jakarta Hak Bebas Royalti 

Noneksklusif (Non-exclusive Royalty Free Right) atas karya ilmiah saya yang 

berjudul: 

UJI KEAKURATAN WAKTU TEMPUH PADA APLIKASI EMERGENCY 

CALL BERBASIS CROWDSOURCE GOOGLE MAPS API DENGAN 

PARAMETER ESTIMATED TRAVEL TIME 

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

Noneksklusif ini Universitas Islam Negeri Syarif Hidayatullah Jakarta berhak 

menyimpan, mengalih media/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. 

Demikian pernyataan ini saya buat dengan sebenarnya. 

Dibuat di : Jakarta 

Pada tanggal : April 2018 

Yang menyatakan 

(Harsy Tamimi) 


vi 

ABSTRAK 

Harsy Tamimi – 1113091000075, “UJI KEAKURATAN WAKTU 

TEMPUH PADA APLIKASI EMERGENCY CALL BERBASIS 

CROWDSOURCE GOOGLE MAPS API DENGAN PARAMETER 

ESTIMATED TRAVEL TIME” dibimbing oleh Arini, M.T. dan Feri Fahrianto, 

M.Sc 

Banyak aplikasi yang menggunakan teknik Crowdsource dalam 

memperoleh data khususnya data tentang kepadatan lalu lintas kendaraan pada 

ruas jalan tertentu, contoh aplikasi yang sudah menerapkan konsep Crowdsourced 

Data seperti Google Maps,Waze, , Bing Maps, dll. Namun, dari data crowdsouce 

itu akan timbul pertanyaan, apakah data yang diberikan valid? atau seberapa 

akurat data yang diberikan oleh “kerumunan orang” tersebut? Dari permasalahan 

tersebut, penulis melakukan penelitian untuk membuktikan seberapa akurat data 

yang diberikan oleh aplikasi tersebut dengan melakukan perbandingan data antara 

data yang diperoleh dari aplikasi yang penulis buat (berasal dari data 

Crowdsource Matrix Distance dari Google Maps API) dengan data yang diperoleh 

dari perhitungan manual menggunakan metode estimasi waktu tempuh. Penulis 

menggunakan RAD (Rapid Application Development) sebagai metode untuk 

mengembangkan aplikasi. Metode penarikan data dari sumber Crowdsource 

Matrix Distance dari Google Maps API dan menggunakan tools GPS tracking 

untuk melacak keberadaan petugas di aplikasi emergency call. Penulis 

menggunakan teknik Modeling and Simulation untuk melakukan pemodelan 

simulasi pada tahap pengujian data. Setelah dilakukan perbandingan 

menggunakan uji hipotesis T-test, didapatkan ternyata data hasil perhitungan 

manual dengan data pada aplikasi hampir sama. 

Kata Kunci: Crowdsource Matrix Distance Google Maps API, Emergency 

call, GPS tracking,Estimated Travel Time 


vii 

Nama : Harsy Tamimi – 1113091000075 

Program Studi : Teknik Informatika 

Judul : “Uji Keakuratan Waktu Tempuh Pada Aplikasi 

Emergency Call Berbasis Crowdsource Google 

Maps Api Dengan Parameter Estimated Travel 

Time” 

ABSTRACT 

Many applications use Crowdsource techniques in obtaining data, 

especially data about vehicle traffic density on certain streets, examples of 

applications that already implement the concept of Crowdsourced Data such as 

Google Maps, Waze, Bing Maps, etc. However, from crowdsouce data that will 

arise the question, whether the data provided valid? or how accurate is the data 

given by the "crowd"? From these problems, the authors conducted research to 

prove how accurate the data provided by the application by doing a comparison of 

data between the data obtained from the application that the author created 

(derived from the data Crowdsource Matrix Distance from Google Maps API) 

with data obtained from manual calculations using estimation method of travel 

time. The author uses RAD (Rapid Application Development) as a method for 

developing applications. The method of recalling data from the source 

Crowdsource Matrix Distance from Google Maps API and using GPS tracking 

tools to track the presence of officers in emergency call applications. The author 

uses the technique of Modeling and Simulation to perform simulation modeling in 

the data testing phase. After a comparison using the T-test hypothesis test, it was 

found that the data of manual calculations with data on the application is almost 

the same. 

Keywords: Crowdsource Matrix Distance Google Maps API, Emergency 

call, GPS tracking,Estimated Travel Time 


viii 

KATA PENGANTAR 

Assalamu’alaikum Wr. Wb. 

Puji syukur penulis panjatkan kehadirat Allah SWT yang telah 

melimpahkan rahmat, taufik serta hidayah-Nya sehingga penulis dapat 

melaksanakan dan menuliskan skripsi ini pada waktu dan tempat yang tepat dan 

menyelesaikan tugas akhir skripsi dengan baik. Sholawat dan salam penulis 

haturkan kepada junjungan kita baginda Nabi Muhammad SAW beserta 

keluarganya, para sahabatnya serta umatnya hingga akhir zaman. Skripsi ini 

merupakan salah satu tugas akhir wajib bagi mahasiswa sebagai persyaratan untuk 

mendapatkan gelar Sarjana Komputer (S.Kom) pada program studi Teknik 

Informatika, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif 

Hidayatullah Jakarta. Sebagai bahan penulisan skripsi ini, penulis melakukannya 

berdasarkan hasil penelitian, pengembangan aplikasi, observasi dan beberapa 

sumber literatur. Tak lupa pula penulis ingin mengucapkan banyak terima kasih 

kepada pihak-pihak terkait lainnya yang telah banyak membimbing penulis dalam 

melakukan penulisan skripsi ini, karena tanpa bimbingan dan dorongan dari 

semua pihak, maka penulisan skripsi ini tidak akan berjalan dengan lancar. 

Selanjutnya penulis menyampaikan ucapan terima kasih kepada : 

1. Orang Tua tercinta yang telah memberikan dukungan moril dan materil ke 

penulis. Tiada tutur kata selain terima kasih kepada ayah, ibu, kakak, 

abang, adik, dan keponakan – keponakan tersayang dan rasa syukur 

kepada Allah S.W.T yang telah menitipkan penulis di keluarga yang 

sangat penulis cintai. Terima kasih, Alhamdulillah. 

2. Bapak Dr. Agus Salim, M.Si selaku dekan Fakultas Sains dan Teknologi. 

3. Ibu Arini, ST, MT. selaku Ketua Program Studi Teknik Informatika. 

4. Ibu Arini, ST, MT. dan Feri Fahrianto, M.Sc selaku Dosen Pembimbing I 

dan II yang telah senantiasa membimbing penulis. 

5. Seluruh dosen dan staff UIN Jakarta khususnya Fakultas Sains dan 

Teknologi yang telah memberikan ilmu dan pengalaman yang sangat 

berharga bagi penulis. 


ix 

6. Calon pendamping hidup Siti Annisya Baharsyah yang telah memberikan 

motivasi dan semangat dalam mengerjakan penelitian ini. 

7. Teman-teman SMA (Teguh,Fadli,Riano) yang telah memberikan motivasi 

dan semangat dalam mengerjakan penelitian ini. 

8. Seluruh sahabat-sahabat terbaik dari Teknik Informatika angkatan 2013, 

khususnya semua anak kelas TI C 2013 (Dodi, Ucup, Nando, Cahyo, 

Angga, Macia, Sisca, Calysta, Rais, Irsyad, Lay, Didi, Jamal, Abi, Ojay, 

Habibi, Taufik, Ames, Anto), senior di kampus (bg kiki,bg yoni dan bg 

farhan) abang-abang di bengkel Ali Performance Terima kasih atas 

semangatnya! 

9. Kepada “BPBD Jakarta” yang telah membantu saya dalam penelitian ini 

dan mengizinkan untuk melakukan studi kasus di BPBD Jakarta 

Serta seluruh pihak yang tidak dapat disebutkan oleh penulis satu persatu 

didalam selembar kertas A4. Penulis menyadari bahwa penulisan skripsi ini masih 

jauh dari kata sempurna. Untuk itu, penulis memohon kritik dan saran yang 

membangun untuk penulis. 

Akhir kata, semoga laporan skripsi ini dapat bermanfaat bagi penulis dan 

orang banyak. 

Wassalamualaikum, Wr. Wb. 

Jakarta, April 2018 

Penulis 


1113091000075 


x 

DAFTAR ISI 

PENGESAHAN UJIAN..................................................................................... iii 

PERNYATAAN ORISINALITAS ..................................................................... iv 

PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI ................................. v 

ABSTRAK ......................................................................................................... vi 

ABSTRACT ...................................................................................................... vii 

DAFTAR ISI ....................................................................................................... x 

DAFTAR GAMBAR ........................................................................................ xvi 

DAFTAR TABEL .......................................................................................... xviii 

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

4.1 Latar Belakang Masalah......................................................................... 1 

4.2 Rumusan Masalah .................................................................................. 4 

4.3 Batasan Masalah .................................................................................... 5 

4.4 Tujuan Penelitian ................................................................................... 5 

4.5 Manfaat Penelitian ................................................................................. 6 

1. Bagi Penulis ....................................................................................... 6 

2. Bagi Masyarakat ................................................................................ 6 

4.6 Sistematika Penulisan ............................................................................ 6 

BAB II LANDASAN TEORI ............................................................................. 8 


xi 

5.1 Analisis.................................................................................................. 8 

5.2 Emergency Call ..................................................................................... 8 

5.3 Crowsource dan Matrix distance API ..................................................... 9 

5.4 Pengembangan ..................................................................................... 11 

5.4.1 Metode Analisa ............................................................................. 11 

5.4.2 Pengertian RAD (Rapid Appication Development) ....................... 12 

5.4.3 Tahapan Rapid Aplication Development ....................................... 12 

5.4.4 Perencanaan Syarat-Syarat (Requirement Planning) ...................... 13 

5.4.5 Proses Desain ............................................................................... 17 

5.4.6 Impelementasi .............................................................................. 17 

5.5 Unified Modeling Language (UML) .................................................... 18 

5.5.1 Use Case Diagram ........................................................................ 18 

5.5.2 Activity Diagram .......................................................................... 20 

5.5.3 Sequence Diagram ........................................................................ 23 

5.5.4 Class Diagram .............................................................................. 26 

5.6 Aplikasi ............................................................................................... 30 

5.6.1 Aplikasi Mobile ............................................................................ 30 

5.7 Android ............................................................................................... 31 

5.7.1 Versi Android ............................................................................... 31 

5.7.2 Android Studio ............................................................................. 32 


xii 

5.8 Java ..................................................................................................... 33 

5.9 GPS Tracking ...................................................................................... 34 

5.10 Application Programming Interface (API) ........................................ 35 

5.11 Google Maps API ............................................................................. 36 

5.11.1 Manfaat Google Maps API ........................................................... 37 

5.12 JSON (java script object notation) .................................................... 38 

5.13 PHP.................................................................................................. 39 

5.14 XML (extensible Markup Language) ................................................ 40 

5.15 Framework CodeIgniter.................................................................... 40 

5.16 Menentukan Ruang Lingkup Penelitian ............................................ 42 

5.17 Waktu Tempuh ................................................................................. 44 

5.17.1 Definisi Kecepatan dan Waktu Tempuh Perjalanan (Travel Time) 44 

5.17.2 Rumus Estimasi Waktu Tempuh Perjalanan .................................. 44 

5.17.3 Rumus Time-Mean Speed ............................................................. 45 

5.17.4 Rumus Space-Mean Speed ............................................................ 45 

5.17.5 Rumus Average Running Speed .................................................... 46 

5.17.6 Rumus Standar Deviasi dan Variansi Data .................................... 46 

5.17.7 Hubungan Time-Mean Speed dengan Space-Mean Speed ............. 47 

5.17.8 Teknik Uji Kendaraan ................................................................... 47 

5.18 Pemodelan dan Simulasi ................................................................... 48 


xiii 

5.18.1 Skema Studi Simulasi ................................................................... 48 

5.18.2 Simulation Model ......................................................................... 49 

5.18.3 Simulation Experiment ................................................................. 49 

5.18.4 Simulation Analysis ...................................................................... 50 

5.18.5 Keuntungan Pemodelan dan Analisis Simulasi .............................. 50 

5.19 Uji Hipotesis T Sampel Independen.................................................. 50 

5.20 Gambaran Umum Instansi pemerintah .............................................. 51 

5.20.1 Sejarah Singkat Instansi pemerintah .............................................. 51 

5.20.2 Visi dan Misi Instansi pemerintah ................................................. 52 

5.20.3 Struktur Organisasi Instansi pemerintah ........................................ 53 

5.20.4 Tugas Pokok dan Fungsi ............................................................... 53 

BAB III METODOLOGI PENELITIAN........................................................... 55 

6.1 Metode Pengumpulan Data .................................................................. 55 

6.2 Studi Lapangan .................................................................................... 55 

6.2.1 Observasi ...................................................................................... 55 

6.2.2 Wawancara ................................................................................... 56 

6.3 Studi Pustaka ....................................................................................... 57 

6.3.1 Studi Literatur............................................................................... 57 

6.4 Metodologi Pengembangan Sistem ...................................................... 62 

6.4.1 Fase Requirement Planning........................................................... 63 


xiv 

6.4.2 Fase Workshop Design ................................................................. 64 

6.4.3 Fase Implementasi ........................................................................ 65 

6.5 Kerangka Berpikir Penelitian ............................................................... 66 

BAB IV ANALISIS DAN PERANCANGAN SISTEM .................................... 68 

4.1 Requirement Planning ......................................................................... 68 

7.1.1 Analisis Sistem ............................................................................. 68 

7.2 Workshop Design ................................................................................. 77 

7.2.1 Desain Proses ............................................................................... 77 

7.2.2 Perancangan User Interface ......................................................... 102 

BAB V HASIL DAN PEMBAHASAN ........................................................... 112 

8.1 Implementasi ..................................................................................... 112 

8.1.1 Aplikasi Emergency Call ............................................................ 112 

8.1.2 Pembuatan kode program............................................................ 122 

8.1.3 Server ......................................................................................... 123 

8.2 Pengujian Aplikasi (Blackbox Testing) .............................................. 123 

8.2.1 Pengujian Fungsionalitas Aplikasi .............................................. 123 

8.2.2 Kesimpulan Hasil Pengujian Blackbox ....................................... 126 

8.3 Pengujian Data Estimasi Waktu Tempuh ........................................... 126 

8.4 Simulation Model .............................................................................. 127 

8.4.1 Simulation Experiment ............................................................... 130 


xv 

8.4.2 Simulation Analysis .................................................................... 130 

BAB VI PENUTUP ........................................................................................ 152 

9.1 Kesimpulan........................................................................................ 152 

9.2 Saran ................................................................................................. 152 

DAFTAR PUSTAKA ...................................................................................... 153 

LAMPIRAN .................................................................................................... 157 

Lampiran 1 Wawancara ................................................................................... 157 

Lampiran 2 Data dari Kantor Polisi,Pemadam Kebakaran,Rumah Sakit Jakarta 

Selatan ............................................................................................................. 159 

Lampiran 3 Perhitungan Uji-T menggunakan Excel ......................................... 165 

Lampiran 4 Prosisi Kendaraan Kearah Gandaria City ....................................... 167 

Lampiran 5 Source Code .................................................................................. 168 

Lampiran 6 Surat izin penelitian ...................................................................... 176 


xvi 

DAFTAR GAMBAR 

Gambar 2.1 diagram konsep dan defenisi crowdsource ...................................... 10 

Gambar 2.2 Siklus RAD (Sumber: Kendall and Kendall, 2010) .......................... 13 

Gambar 2.3 Use Case Diagram (sumber : Kendall dan Kendall, 2010) .............. 20 

Gambar 2.4 Activity Diagram ............................................................................ 23 

Gambar 2.5 Contoh Sequence Diagram (Sumber: Kendall dan Kendall, 2010)... 26 

Gambar 2.6 Contoh Class Diagram .................................................................. 30 

Gambar 2.7 Tampilan Android Studio ............................................................... 32 

Gambar 2.8 Pemograman pada java .................................................................. 34 

Gambar 2.9 cara kerja GPS (sumber : AKARI GPS) .......................................... 35 

Gambar 2.10 Alur Application Programming Interface (API) (sumber : Maruti 

Techlabs di twitter) ............................................................................................ 36 

Gambar 2.11 source code Google Maps Android API untuk memasukan peta 

pada android (sumber : developer google) .......................................................... 38 

Gambar 2.12 contoh Source code JSON ........................................................... 39 

Gambar 2.13 Contoh source code PHP .............................................................. 40 

Gambar 2.14 Ilustrasi Running Time dan Stopped Delay Time (sumber : Turner, 

Eisele, Benz, & Holdener, 1998) ........................................................................ 44 

Gambar 2.15 Struktur Organisasi BPBD Jakarta ................................................ 53 

Gambar 4.4.1 Rich Picture Sistem Berjalan ....................................................... 69 

Gambar 4.4.2 Sistem Usulan .............................................................................. 76 

Gambar 4.4.3 Usecase Diagram......................................................................... 79 

Gambar 4.4 Activity Diagram registrasi ............................................................. 91 

Gambar 4.5 Activity Diagram Login ................................................................... 92 

Gambar 4.6 Activity Diagram pilih instansi ........................................................ 93 

Gambar 4.7 Activity Diagram list opsi route ...................................................... 94 

Gambar 4.8 Activity Diagram lihat posisi petugas .............................................. 95 

Gambar 4.9 Sequence Diagram mengisi biodata ................................................ 96 

Gambar 4.10 Sequence Diagram login ............................................................... 97 

Gambar 4.11 Sequence Diagram memilih instansi gawat darurat ....................... 98 

Gambar 4.12 Sequence Diagram lihat list opsi route .......................................... 99 


xvii 

Gambar 4.13 Sequence Diagram lihat posisi petugas ....................................... 100 

Gambar 4.14 Class Diagram ............................................................................ 101 

Gambar 4.15 Rancangan tampilan menu login ................................................. 102 

Gambar 4.16 Rancangan tampilan menu daftar ................................................ 103 

Gambar 4.17 Rancangan tampilan menu home ................................................. 104 

Gambar 4.18 Rancangan tampilan menu kirim lokasi ....................................... 105 

Gambar 4.19 Rancangan tampilan menu kejadian ............................................ 106 

Gambar 4.20 Rancangan tampilan menu tracking ............................................ 107 

Gambar 4.21 Rancangan tampilan menu login aplikasi petugas ........................ 108 

Gambar 4.22 Rancangan tampilan menu kejadian aplikasi petugas................... 109 

Gambar 4.23 Rancangan tampilan menu route aplikasi petugas ....................... 110 

Gambar 5.1 Gambar tampilan menu login ........................................................ 112 

Gambar 5.2 Tampilan menu daftar ................................................................... 113 

Gambar 5.3 Tampilan menu home ................................................................... 114 

Gambar 5.4 Tampilan menu kejadian ............................................................... 115 

Gambar 5.5 Tampilan menu kirim lokasi ......................................................... 116 

Gambar 5.6 Menu telepon ................................................................................ 117 

Gambar 5.7 Tampilan menu login aplikasi petugas .......................................... 118 

Gambar 5.8 Rancangan tampilan menu tracking .............................................. 119 

Gambar 5.9 Tampilan menu login aplikasi petugas .......................................... 120 

Gambar 5.10 Tampilan menu kejadian aplikasi petugas ................................... 121 

Gambar 5.11 tampilan menu route aplikasi petugas .......................................... 122 

Gambar 5.12 Alur skenario Pengujian Estimasi Waktu Tempuh ....................... 127 

Gambar 5.13 Alur kerangka perhitungan manual tahap Simulation Model ........ 128 

Gambar 5.14 Grafik Perbandingan Waktu Tempuh .......................................... 149 


xviii 

DAFTAR TABEL 

Tabel 2.1 Perbandingan analisis metode PIECES dan SWOT ............................. 11 

Tabel 2.2 Simbol-Simbol Use Case Diagram (Sumber : Sugiarti, 2013)............. 19 

Tabel 2.3 Simbol-Simbol Activity Diagram (Sumber: Kendall dan Kendall, 2010) 

.......................................................................................................................... 21 

Tabel 2.4 Simbol-Simbol Sequence Diagram (Kendall dan Kendall, 2010) ........ 24 

Tabel 2.5 Contoh Potential Objek ...................................................................... 27 

Tabel 2.6 Simbol-Simbol Class Diagram (Sugiarti, 2013) .................................. 28 

Tabel 2.7 Versi android dan liris ........................................................................ 31 

Tabel 2.8 Klasifikasi Umum Jalan (sumber : PP 34/2006 tentang Jalan) ............. 42 

Tabel 4.1 Analisis PIECES ................................................................................ 72 

Tabel 4.2 Identifikasi Actor ................................................................................ 77 

Tabel 4.3 Identifikasi Usecase ........................................................................... 77 

Tabel 4.4 Narasi Use case Mengisi biodata ........................................................ 80 

Tabel 4.5 Narasi Use Case Login ....................................................................... 81 

Tabel 4.6 Narasi Use Case Pilih instansi ............................................................ 82 

Tabel 5.1 Pengujian Fungsionalitas Aplikasi .................................................... 123 

Tabel 5.2 Informasi Pengujian ......................................................................... 129 

Tabel 5.3 Data Waktu Tempuh Aplikasi Emergency Call menggunakan 

Crowdsource google maps API. ....................................................................... 130 

Tabel 5.4 Hasil Observasi Semua Time Element ............................................... 148 

Tabel 5.5 Hasil Perhitungan Case A dan Case B .............................................. 149 


4.1 Latar Belakang Masalah 

BAB I 

PENDAHULUAN 

Bencana alam tak henti-hentinya melanda bangsa kita setiap hari bencana 

alam atau musibah silih berganti melanda bangsa kita merupakan sebuah 

peringatan Allah S.W.T bagi kita yang terlalu banyak dosa, Adapun bagi 

masyarakat yang merasakan langsung dampak dari bencana-bencana tersebut 

adapun juga tidak merasakan langsung tapi merasakan kesedihan melihat orang 

yang terkena bencana,itu semua bencana terjadi karena umat manusia itu 

أَصَابَ‏ مَا Q.S,al-Hadid: 22 sendiri.dalam pandangan islam yang telah di jelaskan di 

“Tiada يَسِ‏ ير 

‏َللاّ‏ ِ عَلَى ذَ‏ ‏َٰلِكَ‏ إِنّ‏ ۚ نَب رَ‏ أَهَا ن ‏ََأ قَب لِ‏ مِن كِتَاب فِي إِلّ‏ أَن فُسِكُم فِي وَ‏ لَ‏ اْل ‏َر ضِ‏ فِي مُصِ‏ يبَة مِن 

suatu bencana pun yang menimpa di bumi dan (tidak pula) pada dirimu sendiri 

melainkan telah tertulis dalam kitab (Lauh Mahfuzh) sebelum 

menciptakannya. Sesungguhnya yang demikian itu adalah mudah bagi Allah.” 

Badan Penanggulangan Bencana Daerah (BPBD) adalah 

Kami 

lembaga 

pemerintah non-departemen yang melaksanakan tugas penanggulangan bencana di 

daerah baik Provinsi maupun Kabupaten/ Kota dengan berpedoman pada 

kebijakan yang ditetapkan BNPB (Badan Nasional Penanggulangan Bencana). 

BPBD dibentuk berdasarkan Peraturan Presiden Nomor 8 Tahun 2008, 

menggantikan Satuan Koordinasi Pelaksana Penanganan Bencana (Satkorlak) di 

tingkat Provinsi dan Satuan Pelaksana Penanganan Bencana (Satlak PB) di tingkat 

Kabupaten / Kota, yang keduanya dibentuk berdasarkan Peraturan Presiden 

Nomor 83 Tahun 2005. 

Dengan Terbentuknya BPBD Provinsi DKI Jakarta sejak tahun Februari 

2011 untuk menghadapi bencana di daerah kota Jakarta yang selalu memiliki 

permasalahan kebencanaan yang kompleks. Dengan luas 661,52 km2, 40% atau 

24.000 hektar merupakan dataran rendah dengan ketinggian rata-rata di bawah 

permukaan air laut. DKI Jakarta juga merupakan pertemuan sungai dari bagian 

selatan dengan kemiringan dan curah hujan tinggi. Terdapat 13 sungai yang 

melewati dan bermuara ke Teluk Jakarta. Secara alamiah, kondisi ini 

1

2 

memosisikan wilayah DKI Jakarta memiliki kerawanan yang tinggi terhadap 

banjir. Beberapa wilayah DKI Jakarta, pada musim penghujan menjadi wilayah 

banjir. Dari catatan sejarah kejadian banjir, banjir besar pernah terjadi pada tahun 

1621, 1654 dan 1918. Banjir besar juga terjadi pada tahun 1976, 1996, 2002, 2007 

dan 2013. Banjir tahun 1996 menggenangi hampir seluruh penjuru kota. Kejadian 

ini menjadi tragedi nasional dan mendapat perhatian dunia. Banjir tahun 2007 

juga memiliki cakupan wilayah genangan lebih luas. Berulangnya kejadian banjir 

per lima tahun menyebabkan banyak kalangan memercayai sebagai siklus lima 

tahunan. Kerusakan dan kerugian terhadap aset terkena banjir yang melanda DKI 

Jakarta, Bogor, Depok, tangerang dan Bekasi (Jabodetabek) tahun 2007, baik 

milik pemerintah, aset dunia usaha dan aset masyarakat diperkirakan senilai 

Rp5,16 trilyun. Selain ancaman bencana banjir, DKI Jakarta juga memiliki 

ancaman bencana lain berupa cuaca ekstrim, gelombang ekstrim, gempa bumi, 

tanah longsor maupun ancaman bencana non alam dan sosial seperti konflik 

sosial, kegagalan teknologi, epidemi, dan wabah penyakit, kebakaran gedung dan 

pemukiman. 

Untuk menghadapi bencana di kota Jakarta maka dari itu BPBD Jakarta 

yang mana penulis sebelumnya melakukan peninjauan bahwa BPBD Jakarta 

masih menggunakan via telepon (112) sebagai layanan panggilan darurat ketika 

masyarakat mendapatkan bencana, namun layanan ini kurang efektif untuk 

masyarakat dan instasi yang bertugas untuk menghadapi bencana di Jakarta maka 

dari itu penulis menerapkan Aplikasi Emergency Call sebagai penyempurnaan 

layanan BPBD jakarta. 

Crowsource data atau “data kerumunan” adalah data yang bersumber dari 

banyak orang (lebih lanjut di Bab 2) 

Aplikasi ini akan terhubung langsung pada server pusat di mana data yang 

akan dikirim oleh user (community) akan langsung dikirim ke server dan server 

akan mencari intansi gawat darurat terdekat dengan menggunakan tools google 

maps API dari keberadaan user (community) mengirim lokasi dan server akan 

mengirim kembali data ke user(officer), dengan menggunakan tools GPS tracking 

para user (community) akan melihat keberadaan posisi kendaraan petugas di 


3 

dalam maps dengan mengunakan tools GPS tracking. Untuk menentukan jalur 

dan waktu tercepat penulis menggunakan Crowdsource Matrix Distance Google 

Maps API. 

Namun, data Crowdsource Matrix Distance Google Maps API tersebut 

belum mendapatkan keakuratan waktu tempuh (travel time) yang di pengaruhi 

oleh kemacetan (traffic jam) di Jakarta. Penulis menggunakan data waktu tempuh 

(travel time) untuk perbandingan dan perhitungan pada aplikasi emergency call 

karena untuk aplikasi sejenis (lihat Tabel 3.2 Studi Litelatur Sejenis ) telah 

menggunakan Crowdsource waze 

Penerapan Crowdsource pada aplikasi ini menggunakan API Google Maps. 

Aplikasi akan mengirim request API ke server ,kemudian server akan merespon 

hasil permintaan dalam bentuk struktur data JSON dan diterapkan pada 

aplikasi.Untuk membuktikan keakuratan data hasil pengambilan dari 

Crowdsource Matrix Distance Google Maps API,penulis melakukan 

perbandingan data dari aplikasi yang menggunkan Crowdsource Matrix Distance 

Google Maps API dengan perhitungan manual menggunakan metode E.T.T 

(Estimated Travel Time ). 

Metode pengembangan sistem penulis gunakan yaitu RAD (Rapid 

Application Develoment) untuk tahap awal pengembangan , metode ini terbukti 

menghasilkan aplikasi yang cepat karma dapat diubah sesuai dengan kebutuhan 

pengembangan aplikasi ini. Penulis menggunakan analisis metode PIECES 

sebagai metode untuk menganalisis pembuatan aplikasi ini. 

Banyak aplikasi sejenis yang dikembangkan dengan konsep penarikan data 

crowdsouse,seperti pada penelitian Hidayatullah Suryaputra, Universitas Islam 

Indonesia yang berjudul “Aplikasi Crowdsourcing Estimasi Waktu Kedatangan 

Bus Transjogja Berbasis Android” tahun 2016 di aplikasi ini kelebihan telah 

menghitung Crowdsource dengan waktu kedatangan bis ke halte namun 

penghitungan estimasi waktu kedatangan hanya berlaku buat tempat yang telah di 

tentukan , selanjutnya penelitian yang dilakukan oleh Andi Wahju Rahardjo 

Emanuel Anthony Salim, Universitas Kristen Maranatha yang berjudul 

“Pembuatan Sistem Pelayanan Taksi dengan Menggunakan Android, Google 


4 

Maps, dan Ruby on Rails” tahun 2013 di sistem ini kelebihan telah menggunakan 

matrix distance google maps API namun kekurangan sistem ini belum 

menggunakan metode estimed time travel untuk menghitung waktu secara manual 

walaupun telah menggunakan matrix distance google maps API. selanjutnya 

penelitian yang dilakukan oleh Riyadhush Sholichin dan Mohamad Yasindan 

Lucky Tri Oktoviana dengan judul “Implementasi Algoritma Dijkstra Dalam 

Pencarian Lintasan terpendek Lokasi Rumah Sakit, Hotel Dan Terminal Kota 

Malang Berbasis Web” tahun 2017 memiliki kelebihan menggunakan 

Implementasi Algoritma Dijkstra Dalam Pencarian Lintasan terpendek namun 

kekurangan jurnal ini menggunakan masih berbasib website 

Dari permasalahan dan evaluasi literatur, maka penulis berinisiatif untuk 

membuat sistem dengan konsep tersendiri yang terkomputerisasi. Diharapkan dari 

sistem ini, maka penulis berinisiatif dan menjadikan alasan untuk mengangkat 

topik dengan judul “UJI KEAKURATAN WAKTU TEMPUH PADA 

APLIKASI EMERGENCY CALL BERBASIS CROWDSOURCE GOOGLE 

MAPS API DENGAN PARAMETER ESTIMATED TRAVEL TIME” 

4.2 Rumusan Masalah 

Berdasarkan Penjabaran Latar Belakang di atas maka permasalahan yang 

dapat dikaji dalam penelitian sebagai berikut : 

1) Bagaimana membangun aplikasi emergency call dengan 

mengimplementasi Crowdsource Matrix Distance Google Maps API 

2) Bagaimana menghitung keakuratan data waktu tempuh total(stop 

delay) di aplikasi dengan perhitungan manual menggunakan metode 

Estimed Travel Time 

3) Bagaimana menganalisis perbandingan hasil dari penghitugan 

metode Estimed Travel Time dan Aplikasi Emergency Call yang 

menggunakan crowddessource dengan analisis statistik Uji 

Hipotesis T-test 


5 

4.3 Batasan Masalah 

Berdasarkan rumusan masalah yang telah diuraikan diatas, maka batasan 

masalah dari aplikasi ini adalah: 

1) Studi kasus adalah BPBD (Badan Penanggulangan Bencana 

Daerah jakarta ) 

2) Lokasi peneltian didaerah Jakarta selatan 

3) Berfokus pada perhitungan waktu tempuh total yang sudah 

termasuk delay stop 

4) Penghitungan waktu tempuh dan jarak tercepat pada aplikasi 

menggunakan Crowdsource Matrix Distance 

5) Crowdsource Matrix Distance yang digunakan adalah 

Crowdsource Matrix Distance Google Maps API 

6) Metode pengembangan sistem menggunakana sistem RAD 

7) Analisis kebutuhan sistem menggunakan metode analisis PIECES 

8) Aplikasi yang dikembangkan masih berbasis android 

9) Jenis layanan darurat yang menjadi object penelitian dalam 

pembuatan tugas akhir ini adalah rumah Sakit, ambulance, kantor 

polisi, dan kantor pemadam kebakaran 

10) Tools yang di gunakan adalah Google maps API dan GPS tracking 

11) Pembuatan aplikasi menggunakan XML, java(mobile), PHP, 

HTML, dan website (dashboard) 

12) Informasi yang diterima pihak intansi gawat darurat untuk ditindak 

lanjuti dengan menggunakan data yang valid atau dapat 

dipertanggung jawabkan. 

4.4 Tujuan Penelitian 

Berdasarkan rumusan masalah, dapat diketahui tujuan dari pengembangan 

aplikasi ini, ialah sebagai berikut : 

Membangun aplikasi emergency call untuk menanggulangi bencana 

di daerah Jakarta 


6 

Membangun aplikasi emergency call dengan mengimplementasi 

Crowdsource Matrix Distance Google Maps API dan metode 

PIECES untuk menganalisis pembuatan aplikasi 

Menghitung keakuratan data waktu tempuh total(stop delay pada 

aplikasi emergency call 

4.5 Manfaat Penelitian 

Adapun manfaat yang didapatkan adalah sebagai berikut : 

1. Bagi Penulis 

1) Menerapkan ilmu-ilmu yang sudah didapat saat perkuliahan. 

2) Membandingkan teori yang telah didapat saat kuliah dengan masalah 

yang sebenarnya. 

3) Mengamati teknik-teknik yang diterapkan dilapangan dalam bidang 

Teknik Informatika. 

2. Bagi Masyarakat 

1) Membantu masyrakat untuk melaporkan kejadian situasi darurat di kota 

Jakarta secara cepat 

2) Masyarakat akan memberikan data kejadian gawat darurat lebih akurat 

4.6 Sistematika Penulisan 

BAB I 

PENDAHULUAN 

Dalam bab ini membahas mengenai latar belakang 

penulisan, perumusan masalah, batasan masalah, tujuan dan 

manfaat, metode dan sistematika penulisan yang 

merupakan gambaran menyeluruh dari penulisan skripsi ini 


7 

BAB II 

BAB III 

BAB IV 

BAB V 

BAB VI 

LANDASAN TEORI 

Dalam bab ini membahas mengenai berbagai teori yang 

mendasari analisis permasalahan yang berhubungan dengan 

pembahasan. 

METODOLOGI PENELITIAN 

Bab ini berisi pembahasan atau pemaparan metode yang 

penulis pakai dalam pencarian data maupun perancangan 

sistem yang dilakukan pada penelitian. 

ANALISIS DAN PERANCANGAN SISTEM 

Bab ini membahas mengenai hasil dari analisa, 

perancangan, implementasi dan pengujian sistem selama 

penelitian ini berlangsung. 

HASIL DAN PEMBAHASAN 

Bab ini membahas mengenai hasil perbandingan keakuratan 

waktu menggunakan metode E.T.T(estimated travel time) 

dan tampilan aplikasinya. 

PENUTUP 

Pada bab ini kesimpulan dari hasil pembahasan seluruh bab 

serta saran-saran yang kiranya dapat diperhatikan serta 

dipertimbangkan untuk pengembangan sistem dimasa 

mendatang 


BAB II 

LANDASAN TEORI 

5.1 Analisis 

Analisis adalah aktivitas yang memuat sejumlah kegiatan seperti mengurai, 

membedakan, memilah sesuatu untuk digolongkan dan dikelompokkan kembali 

menurut kriteria tertentu kemudian dicari kaitannya dan ditafsirkan maknanya. 

Dalam pengertian yang lain, analisis adalah sikap atau perhatian terhadap 

sesuatu (benda, fakta, fenomena) sampai mampu menguraikan menjadi bagianbagian, 

serta mengenal kaitan antarbagian tersebut dalam keseluruhan. Analisis 

dapat juga diartikan sebagai kemampuan memecahkan atau menguraikan suatu 

materi atau informasi menjadi komponen-komponen yang lebih kecil sehingga 

lebih mudah dipahami. 

Dapat disimpulkan bahwa analisis adalah sekumpulan aktivitas dan proses. 

Salah satu bentuk analisis adalah merangkum sejumlah besar data yang masih 

mentah menjadi informasi yang dapat diinterpretasikan. Semua bentuk analisis 

berusaha menggambarkan pola-pola secara konsisten dalam data sehingga 

hasilnya dapat dipelajari dan diterjemahkan dengan cara yang singkat dan penuh 

arti. 

5.2 Emergency Call 

Kamus Besar Bahasa Indonesia Darurat dapat diartikan adalah keadaan 

sukar (sulit) yang tidak tersangka-sangka yang cepat bagi masyarakat pada 

kondisi mendesak yang melibatkan masyarakat, petugas penyelamat dan 

komunikasi. 

Nomor telepon darurat adalah satu atau beberapa nomor telepon yang dapat 

dihubungi dalam keadaan darurat oleh masyarakat umum untuk mendapatkan 

bantuan dari berbagai pihak seperti polisi, pemadam kebakaran dan pertolongan 

medis atau pengangkutan (evakuasi) ke rumah sakit. Di banyak negara hanya ada 

1 nomor telepon darurat sehingga mudah diingat. Nomor darurat tunggal ini 

8

9 

disebut nomor telepon darurat universal atau nomor telepon jasa-jasa penanganan 

keadaan darurat. Dengan nomor telepon darurat tunggal ini, masyarakat umum 

yang memerlukan bisa meminta bantuan dari jasa-jasa penanganan keadaan 

darurat setempat. 

Nomor telepon darurat bisa berbeda-beda dari satu negara ke negara 

lainnya. Ada nomor telepon darurat yang sama di semua negara lewat telepon 

satelit global. Biasanya nomor telepon darurat terdiri dari 3 nomor yang bisa 

diingat dengan mudah dan bisa dihubungi dengan cepat. Di beberapa negara 

terdapat nomor telepon darurat yang berbeda-beda untuk setiap jasa penanganan 

keadaan darurat. Biasanya nomor-nomor telepon darurat ini mirip satu dengan 

lainnya dan hanya berbeda pada digit terakhir saja. 

5.3 Crowsource dan Matrix distance API 

Crowdsourcing diartikan secara kata perkata mempunyai terjemahan bebas 

yakni: Crowd: kerumunan orang, Sourcing (kata kerja dari Source): sumberdaya. 

Apabila digabungkan (masih dalam terjemahan bebas) akan berarti sebagai 

sesuatu sistem atau konsep yang sumber daya berbasis kerumunan. 

Konsep umum crowdsourcing dimaksudkan adanya pelibatan yang tidak 

terbatas dan tanpa memandang latar belakang pendidikan, kewarganegaraan , 

agama, amatir atau professional, bagi setiap orang yang ingin memberikan 

kontribusinya atau solusinya atas suatu permasalahan yang dilemparkan oleh 

individu, perusahaan atau institusi, baik dibayar/royalti atau secara cuma-cuma. 

Konsep khusus crowdsourcing suatu perusahaan atau institusi ingin 

mendapatkan solusi atas permasalahan yang mereduksi birokrasi dengan biaya 

yang rendah dibandingkan dengan membayar tenaga kerja secara konvensional, 

sedemikian hingga permasalahan dapat ditangani secara cepat, tepat dan hemat 

biaya, yang pada akhirnya baik secara langsung maupun tidak langsung akan 

meningkatkan daya saing perusahaan atau institusi tersebut. 

Matrix distance API adalah adalah layanan yang menyediakan jarak dan 

waktu perjalanan untuk matriks asal dan tujuan, berdasarkan rute yang disarankan 

antara titik awal dan akhir. 


10 

Gambar 5.1 diagram konsep dan defenisi crowdsource 

Berikut penjelasan dari gambar di atas : 

1. crowdsource adalah group besar internet yang terdiri dari banyak orang 

dari latar belakang yang berbeda yang memberikan data lalu lintas melalui 

aplikasi google maps 

2. dari sisi google maps API meminta dan mengelolah data crowd dari para 

pengguna dan menghasilakan respon yang digunakan oleh pengembang 

aplikasi maupun pengguna akhir (end User) 

aplikasi yang penulis buat (emergency call) akan mengirim HTTP request 

kepada google maps API dan google maps API merespon dalam bentuk struktur 

data JSON yang akan dikomplikasikan oleh aplikasi.untuk data instansi 

,emergency call akan mengambil data dari database 


11 

5.4 Pengembangan 

Menurut Undang-Undang Republik Indonesia Nomor 18 Tahun 2002 

Pengembangan adalah kegiatan ilmu pengetahuan dan teknologi yang bertujuan 

memanfaatkan kaidah dan teori ilmu pengetahuan yang telah terbukti 

kebenarannya untuk meningkatkan fungsi, manfaat,dan aplikasi ilmu pengetahuan 

dan teknologi yang telah ada, atau menghasilkan teknologi baru. 

5.4.1 Metode Analisa 

Adapun jenis-jenis metode analisis dalam pengembangan sistem 

Tabel 5.1 Perbandingan analisis metode PIECES dan SWOT 

Metode PIECES 

• Penjelasan tentang PIECES 

Bagaimana 

kinerja(performance) 

menghasilkan jumlah 

informasi(information) dalam 

jangka waktu tertentu, agar 

perluasan pemasaran dalam 

membutuhkan akses informasi 

yang cepat dan tepat. 

Bagaimana control (control) 

mampu mendeteksi secara dini 

terhadap kesalahan sistem atau 

kinerja(performance) dan 

melakukan pengontrolan 

terhadap ekonomi (economic) 

agar mengalami peningkatan 

keuntungan dan tidak terjadi 

penularan biaya. Bagaimana 

kinerja dapat mencapai sasaran 

dan tidak mengeluarkan 

banyak waktu atau efisiensi 

(efficiency) serta mendapatkan 

pelayanan (service) terbaik. 

Metode SWOT 

• pengertian 

yaitu sebuah bentuk 

analisa situasi dan juga kondisi 

yang bersifat deskriptif 

(memberi suatu gambaran). 

Analisa ini menempatkan 

situasi dan juga kondisi 

sebagai sebagai faktor 

masukan, lalu kemudian 

dikelompokkan menurut 

kontribusinya masing-masing 

• penjelasan tentang SWOT 

Bagaimana 

kekuatan(strengths) mampu 

mengambil 

keuntungan(Advantage) dari 

peluang (opportunities) yang 

ada, bagaimana cara mengatasi 

kelemahan (weaknesses) yang 

mencegah keuntungan dari 

peluang yang ada selanjutnya 

bagaimana keuntungan mampu 

menghadapi ancaman(threats) 

yang ada, dan terakhir adalah 

bagaimana cara mengatasi 

kelemahan yang mampu 

membuat ancaman menjadi 

nyata atau menciptakan sebuah 

ancaman baru. 


12 

5.4.2 Pengertian RAD (Rapid Appication Development) 

Rapid application development (RAD) atau rapid prototyping adalah 

model proses pembangunan perangkat lunak yang tergolong dalam teknik 

incremental(bertingkat). RAD menekankan pada siklus pembangunan 

pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang 

penting untuk model ini. Rapid application development menggunakan 

metode iteratif (berulang) dalam mengembangkan sistem di mana working 

model (model bekerja) sistem dikonstruksikan di awal tahap 

pengembangan dengan tujuan menetapkan kebutuhan (requirement)user 

dan selanjutnya disingkirkan. Working model digunakan kadang-kadang 

saja sebagai basis desain dan implementasi sistem final. Jadi RAD dapat 

disimpulkan Menjadi berikut: 

Rapid Aplication Development (RAD) adalah sebuah proses 

perkembangan perangkat lunak sekuensial linier yang menekankan siklus 

perkembangan dalam waktu yang singkat. 

5.4.3 Tahapan Rapid Aplication Development 

Terdapat tiga fase dalam RAD yang melibatkan penganalisis dan dalam 

tahap penilaian, perancangan dan penerapan (Kendall dan Kendall, 2010). Adapun 

ketiga fase tersebut adalah Perencanaan Syarat-Syarat (Requirement Planning), 

Proses Desain (Workshop Design) dan Implementasi (Implementation). Berikut 

ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan 

aplikasi (Kendall dan Kendall, 2010). 


13 

Gambar 5.2 Siklus RAD (Sumber: Kendall and Kendall, 2010) 

5.4.4 Perencanaan Syarat-Syarat (Requirement Planning) 

Dalam fase ini, pengguna dan penganalisis bertemu untuk 

mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk 

megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan- tujuan 

tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah 

perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian 

dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian 

tujuan-tujuan perusahaan. Fase ini memerlukan peran aktif mendalam dari 

seorang pengguna dan penganalisa. Orentasi dalam fase ini adalah menyelesaikan 

masalah-masalah perusahaan (Kendall dan Kendall, 2010). Tahapan pada fase ini 

seperti: 

1. Memahami Gambaran Umum PerusahaanUntuk 

menganalisis dan merancang sistem informasi yang sesuai, 

sistem analis perlu memahami organisasi atau perusahaan 

tempat mereka bekerja sebagai sistem yang terbentuk 

melalui interaksi dari tiga elemen utama : tingkat 

manajemen, desain organisasi, dan budaya 

organisasi(lampiran 1). Organisasi adalah sistem yang 

besar yang terdiri dari subsistem yang saling terkait. 


14 

Organisasi dan anggotanya berguna untuk 

dikonseptualisasikan sebagai sistem yang dirancang untuk 

mencapai tujuan yang telah ditentukan dan tujuan melalui 

orang dan sumber daya lain yang mereka terapkan. 

Organisasi terdiri dari elemen yang lebih kecil, yaitu sistem 

yang saling terkait (departemen, unit, divisi, dll) yang 

melayani fungsi khusus. fungsi khas termasuk akuntansi, 

pemasaran, produksi, pengolahan data, dan manajemen. 

fungsi khusus (sistem yang lebih kecil) yang akhirnya 

diintegrasikan melalui berbagai cara untuk membentuk 

suatu keseluruhan organisasi yang efektif. Signifikansi 

konseptualisasi organisasi sebagai sistem yang kompleks 

adalah bahwa prinsip-prinsip sistem memungkinkan 

wawasan tentang bagaimana organisasi bekerja. Untuk 

memastikan kebutuhan informasi dengan benar dan 

merancang sistem informasi yang tepat, itu adalah 

kepentingan utama untuk memahami organisasi secara 

keseluruhan (Kendall dan Kendall, 2010). 

2. Analisis Terdapat tiga tahapan analisis sistem pada alur 

pengembangan sistem RAD (Whitten dan Bentley, 2008), 

yaitu: 

a. Problem Analysis, Analisa masalah merupakan tahap 

mempelajari sistem yang sudah ada dan menganalisa 

temuan- temuan agar dapat menemukan pemahaman 

yang lebih mendalam atas masalah yang memicu 

adanya penelitian ini. Tujuan tahapan problem 

analysis adalah mempelajari dan memahami bidang 

masalah dengan cukup baik secara menyeluruh 

menganalisis masalah, kesempatan dan batasannya. 

b. Requirement Analysis, Analisa kebutuhan merupakan 

tahap yang mendefinisikan dan memprioritaskan 


15 

kebutuhan bisnis. Dengan kata lain memahami 

pengguna untuk mengetahui apa yang dibutuhkan atau 

inginkan dari sistem baru, dengan menghindari 

pembahasan tentang teknologi atau teknis pelaksanaan. 

Ini mungkin merupakan tahap terpenting 

pengembangan sistem karena kesalahan dan kelalaian 

dari hasil analisis ini mengakibatkan ketidakpuasan 

pengguna dengan sistem final dan modifikasi yang 

mahal. Adapun tahapan yang terdapat pada analisis 

persyaratan ini antara lain sebagai berikut: 

1. Analisis Pieces Analisis PIECES 

(Performance, Information, Economic, 

Control, Efficiency dan Service) merupakan 

kerangka kerja dalam mengklarifikasi 

masalah yang terjadi dalam sebuah organisasi. 

Kerangka kerja analisis PIECES (Whitten dan 

Bentley, 2008) ialah sebagai berikut : 

- Performance(Kinerja) Kebutuhan untuk memperbaiki 

atau meningkatkan kinerja. 

- Information(Informasi) Kebutuhan untuk memperbaiki 

atau meningkatkan informasi dan data. 

- Economic(Ekonomi) Kebutuhan untuk memperbaiki atau 

meningkatkan ekonomi, biaya kontrol, atau meningkatkan 

keuntungan. 

- Control(Kontrol) Kebutuhan untuk memperbaiki atau 

meningkatkan kontrol atau keamanan. 

- Eficiency(Efisien) Kebutuhan untuk memperbaiki atau 

meningkatkan efisiensi orang dan proses. 

- Services (Pelayanan) Kebutuhan untuk memperbaiki atau 

meningkatkan layanan kepada pelanggan, pemasok, 

mitra, karyawan dan sebagainya. 


16 

2. Functional Requirement Yaitu deskripsi 

mengenai aktivitas dan layanan yang harus 

diberikan atau disediakan oleh sebuah sistem 

(Whitten dan Bentley, 2008). Persyaratan 

fungsional sering diidentifikasi dalam istilah 

input, output, proses dan data tersimpan yang 

dibutuhkan untuk memenuhi sasaran 

peningkatan sistem. 

3. Unfunctional Requirement Yaitu deskripsi 

mengenai fitur, karakteristik dan batasan 

lainnya yang menentukan apakah sistem 

memuaskan atau tidak (Whitten dan Bentley, 

2008). Persyaratan nonfungsional mengacu 

pada kualitas yang harus dimiliki oleh sistem 

berdasarkan temuan pada analisis PIECES. 

c. Decision Analysis (Analisis Keputusan). Tujuan dari 

tahap ini adalah untuk mengidentifikasi pilihan solusi 

teknis, menganalisis solusi atas kelayakan dari pilihan 

tersebut dan merekomendasikan pilihan sistem yang 

akan dirancang (Whitten dan Bentley, 2008). Berikut 

adalah tahapan yang terdapat pada analisis keputusan: 

1. Menentukan Sistem Usulan Yaitu 

menentukan sistem usulan yang sesuai dengan 

temuan pada analisis persyaratan pada tahap 

sebelumnya. 

2. Menentukan Teknologi Yaitu menentukan 

teknologi yang akan diterapkan pada Sistem 

Informasi yang diusulkan. 

3. Gambaran Sistem Usulan Yaitu 

menggambarkan sistem usulan dengan Rich 


17 

Picture dan SOP (Standard Operating 

Procedures) dalam bentuk flowchart dan 

dijelaskan secara rinci. 

4. Menentukan Pengguna Yaitu menentukan 

pengguna (user) pada sistem usulan. 

5. Menentukan Komponen Sistem Yaitu 

menentukan komponen sistem usulan yang 

meliputi management user, data master, 

proses dan sistem pelaporan. 

5.4.5 Proses Desain 

Fase ini adalah fase untuk merancang dan memperbaiki yang dapat 

digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja 

membangun dan menunjukkan representasi visual desain dan pola kerja kepada 

pengguna. Workshop desain ini dapat dilakukan selama beberapa hari tergantung 

dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain RAD, 

pengguna merespon prototipe yang ada dan penganalisis memperbaiki modulmodul 

yang dirancang berdasarkan respon pengguna. Apabila seorang 

pengembangnya merupakan pengembang atau pengguna yang berpengalaman 

(Kendall dan Kendall, 2010). 

5.4.6 Impelementasi 

Pada fase implementasi ini, penganalisis bekerja dengan para pengguna 

secara intens selama workshop dan merancang aspek- aspek bisnis dan nonteknis 

perusahaan. Segera setelah aspek- aspek ini disetujui dan sistem-sistem dibangun 

dan disaring, sistem- sistem baru atau bagian dari sistem diuji coba dan kemudian 

diperkenalkan kepada organisasi (Kendall dan Kendall, 2010). 

Tahap ini terdiri atas dua tahapan, yaitu tahap pengimplementasian sistem 

ke dalam bahasa pemrograman (coding) dan testing oleh beberapa owner, analyst 

dan developer dengan tujuan apakah sistem yang dibangun sudah berjalan dengan 

baik pada saat pengoperasiannya atau masih terdapat kesalahan. 

1. Pemrograman (Coding) Tujuan fase konstruksi adalah untuk membangun 

dan menguji sebuah sistem fungsional yang memenuhi persyaratan bisnis 


18 

dan desain dan untuk mengimplementasi antarmuka sistem yang baru. 

Aspek utama dari fase ini ialah pemrograman sistem (Whitten dan Bentley, 

2008) 

2. Black Box Testing Yaitu tahap uji coba terhadap aplikasi atau software yang 

telah dibangun. Adapun metode yang digunakan dalam testing ini yaitu 

dengan black box testing. Pengujian black box disebut juga pengujian 

behavioral, yang berfokus pada kebutuhan fungsional software (Pressman, 

2010). Black box mencoba untuk menemukan kesalahan dalam kategori 

berikut: (1) fungsi- fungsi yang tidak benar atau hilang, (2) kesalahan 

interface, (3) kesalahan dan struktur data atau akses database eksternal (4) 

kesalahan kinerja atau tingkah laku dan (5) inisialisasi dan kesalahan 

terminasi. 

5.5 Unified Modeling Language (UML) 

UML adalah ‘bahasa’ pemodelan untuk sistem atau perangkat lunak yang 

berparadigma ‘berorientasi objek’. Pemodelan sesungguhnya digunakan untuk 

penyederhanaan permasalahan-permasalahan yang kompleks sedemikian rupa 

sehingga lebih mudah dipelajari dan dipahami (Sugiarti, 2013). 

UML menyediakan satu set standar alat untuk mendokumentasikan analisis 

dan desain sistem perangkat lunak. Seperangkat alat UML termasuk diagram yang 

memungkinkan orang untuk memvisualisasikan pembangunan sistem berorientasi 

objek, mirip dengan cara satu set blueprint yanng memungkinkan orang untuk 

memvisualisasikan pembangunan gedung. Dokumentasi yang dibuat dengan UML 

menyediakan sarana komunikasi yang efektif antara tim pengembangan dan tim 

bisnis pada sebuah proyek (Kendall dan Kendall, 2010). 

5.5.1 Use Case Diagram 

Use Case adalah salah satu diagram yang ada dalam UML (Unified 

Modeling Language). Use case atau diagram use case merupakan pemodelan 

untuk kelakuan (behavior) aplikasi perangkat lunak yang akan dibuat. Use case 

mendeskripsikan sebuah interaksi antara satu atau lebih aktor dengan aplikasi 

yang akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi atau 


19 

proses apa saja yang ada didalam sebuah aplikasi dan siapa saja yang berhak 

menggunakan fungsi-fungsi itu . 

Berikut adalah tabel penjelasan dari simbol-simbol yang ada pada use case 

diagram: 

Tabel 5.2 Simbol-Simbol Use Case Diagram (Sumber : Sugiarti, 2013) 

Simbol 

Usecase 

Deskripsi 

fungsionalitas yang disediakan 

sistem sebagai unit-unit yang saling 

bertukar pesan antar unit atau actor. 

Actor 

orang, proses, atau sistem lain yang 

berinteraksi dengan sistem informasi yang 

akan dibuat diluar sistem informasi yang 

akan dibuat itu sendiri. 

Asosiasi 

komunikasi antar actor dan use case 

yang berpartisipasi pada use case, atau use 

case memiliki interaksi dengan actor. 

 

 

Relasi use case tambahan ke sebuah 

use case dimana use case yang 

ditambahkan dan dapat berdiri sendiri 

walau tanpa use case tambahan itu. 

Relasi use case tambahan ke sebuah 

use case dimana use case yang 

ditambahkan dan memerlukan use case ini 

untuk menjalankan fungsinya atau sebagai 

syarat dijalankan use case ini. 


20 

Berikut ini adalah contoh dari use case diagram: 

Gambar 5.3 Use Case Diagram (sumber : Kendall dan Kendall, 2010) 

5.5.2 Activity Diagram 

Activity diagram menunjukkan urutan kegiatan dalam proses, termasuk 

sekuensial dan paralel kegiatan, dan keputusan yang dibuat. 

Diagram aktivitas biasanya dibuat untuk satu use case dan dapat 

menunjukkan skenario yang mungkin berbeda (Kendall dan Kendall, 2010). 


21 

diagram: 

Berikut adalah tabel penjelasan dari simbol-simbol yang ada pada Activity 

Tabel 5.3 Simbol-Simbol Activity Diagram (Sumber: Kendall dan Kendall, 2010) 

Simbol 

Keterangan 

Status awal aktivitas sistem, status 

ketika mengawali diagram. 

Fork adalah keadaan dimana satu 

aktivitas dipecah lebih dari satu karena 

adanya pilihan. 

Join adalah asosiai penggabungan 

dimana lebih dari satu aktivitas 

digabungkan digabungkan menjadi satu. 

Akitivitas yang dilakukan sistem, 

aktivitas biasanya diawali dengan kata 

kerja 

Decision (keputusan) adalah 

asosiasi percabangan dimana jika ada 

pilihan aktivitas lebih dari 

sSattautu.s akhir yang silakukan 

sistem, status akhir ketika mengakhiri 


22 

diagram. 

Control Flow Menunjukkan arah ke 

action state berikutnya. 

Swimlane, menujukkan siapa yang 

bertanggung jawab melakukan aktivitas 

dalam suatu diagram 


23 

Berikut adalah contoh Activity Diagram: 

Gambar 5.4 Activity Diagram (sumber : 

https://ardiasari.wordpress.com/2013/06/08/activity-diagram/) 

5.5.3 Sequence Diagram 

Sequence diagram menggambarkan interaksi antara kelas atau contoh objek 

dari waktu ke waktu. Sequence diagram sering digunakan untuk menggambarkan 

proses yang dijelaskan dalam skenario use case. Dalam prakteknya, diagram 

urutan yang berasal dari analisis use case dan digunakan dalam desain sistem 

untuk menurunkan interaksi, hubungan, dan metode dari objek dalam sistem. 


24 

Sequence diagram digunakan untuk menunjukkan pola keseluruhan dari kegiatan 

atau interaksi dalam kasus penggunaan. Setiap skenario use case mungkin 

membuat satu sequence diagram, meskipun sequence diagram tidak selalu 

diciptakan untuk skenario kecil (Kendall dan Kendall, 2010). 

Berikut ini adalah tabel penjelasan dari simbol-simbol yang digunakan pada 

sequence diagram: 

Tabel 5.4 Simbol-Simbol Sequence Diagram (Kendall dan Kendall, 2010) 

Simbol 

Keterangan 

Boundary biasanya berupa tepi dari sistem, 

seperti user interface atau suatu alat yang 

berinteraksi dengan sistem lain 

Control merupakan elemen yang mengatur 

aliran dari informasi untuk sebuah scenario. 

Perilaku bisnis umumnya diatur oleh objek ini 

Entity biasanya elemen yang bertanggung 

jawab menyimpan data atau informasi. Ini dapat 

berupa model objek 


25 

Merepresentasikan entitas yang berada di 

luar sistem, mereka bisa berupa manusia, atau 

perangkat sistem lain. 


26 

Berikut ini adalah contoh dari sequence diagram: 

Gambar 5.5 Contoh Sequence Diagram (Sumber: Kendall dan Kendall, 2010) 

5.5.4 Class Diagram 

Diagram kelas atau class diagram menggambarkan struktur aplikasi 

berorientasi objek dari sisi pendefinisian kelas-kelas yang akan dibuat untuk 

membangun aplikasi. Kelas memiliki apa yang disebut atribut dan metode atau 

operasi 

Untuk membuat diagram kelas, terlebih dahulu membuat potential object. 

Potential object merupakan salah satu teknik untuk menemukan objek-objek 

potensial yang digunakan untuk membuat class diagram. Daftar objek-objek yang 

potensial dicari dalam narasi use case yang berupa kata benda. Di dalam daftar 


27 

tersebut, setelah memasukkan kata-kata benda kemudian dimasukkan juga atributatribut 

dari setiap kata benda (Whitten dan Bentley, 2008). Untuk menyaring 

daftar objek potensial agar dapat ditentukan sebagai kelas, maka setiap objek 

harus diajukan pertanyaan sebagai berikut (Whitten dan Bentley, 2008): 

1. Apakah kandidat objek adalah sinonim dari objek lain? 

2. Apakah kandidat objek berada di luar lingkup sistem? 

3. Apakah kandidat objek adalah peran eksternal? 

4. Apakah kandidat objek tidak jelas atau membutuhkan fokus? 

5. Apakah kandidat objek sebuah action atau atribut dari objek lain? 

Jika di setiap pertanyaan jawabannya “ya”, maka objek tersebut dicoret 

dari daftar potensial objek. Setelah semua objek telah disaring melalui pertanyaanpertanyaan 

di atas, barulah ditemukan final object potential list yang akan 

dijadikan sebagai kelas di class diagram. Untuk atribut yang telah dicoret dari 

object potential list, maka akan dimasukkan kembali ke dalam class diagram 

untuk menjadi atribut dari setiap kelas. 

Berikut ini adalah contoh dari Potential Object: 

Tabel 5.5 Contoh Potential Objek 

Potensial Objek 

Admin 

Cek 

√ 

Alasan 

Data user sebagai 

administrator 

Data material 

√ 

proyek 

Bagian penting dari data 

Login 

× Merupakan aktifitas 

Logout × Merupakan atktifitas 


28 

Manajer Proyek 

√ Data user sebagai 

administrator 

Class diagram yaitu gambar grafis mengenai struktur objek statis dari suatu 

sistem, menunjukkan kelas-kelas objek yang menyusun sebuah sistem dan juga 

hubungan antara kelas objek tersebut (Whitten dan Bentley, 2008). 

Berikut ini adalah tabel penjelasan dari simbol-simbol yang digunakan pada 

class diagram: 

Tabel 5.6 Simbol-Simbol Class Diagram (Sugiarti, 2013) 

Simbol 

Keterangan 

Class adalah kelas pada struktur sistem. 

Terdiri dari tiga elemen : 

- Class Name, nama dari sebuah objek kelas 

- Attribute adalah properti dari sebuah class 

melukiskan batas nilai yang mungkin ada pada 

objek dari class. 

- Operation, sesuatu yang dapat dilakukan 

oleh sebuah kelas 

Association, relasi antar kelas dengan makna 

umum, asosiasi juga biasanya juga disertai dengan 

multipicity. 

Directed Association relasi antar kelas 

dengan makna kelas yang digunakan oleh kelas 

kalin, asosiasi juga biasanya juga disertai dengan 

multipicity. 

Generalization, relasi antar kelas dnegna 

makna generalisasi-spesialiasi (umum-khusus) 


29 

Dependency, relasi antar kelas dengan 

makna kebergantungan antar kelas 

Agregation, relasi antar kelas dnegan makna 

semua- bagian (whole-part) 

Hubungan antar objek dalam class terdapat multiplisitas, yang menunjukkan 

jumlah suatu objek yang bisa berhubungan dengan objek lain antara lain (Sugiarti, 

2013): 

- 1 (pasti 1), 

- 0...1 (nol atau satu), 0...* (nol atau lebih) atau 1...* (satu atau lebih), 

- Tidak ada batasan (bisa 0, 1, ..., n), 

- Biasanya didefinisikan batas bawah dan atas, kecuali untuk yang pasti 

bernilai 1. 

Berikut ini adalah contoh dari Class diagram: 


30 

Gambar 5.6 Contoh Class Diagram (sumber : https://haidibarasa.wordpress.com) 

5.6 Aplikasi 

Aplikasi berasal dari kata application yang artinya 

penerapan;lamaran;penggunaan. Secara istilah aplikasi adalah: program siap pakai 

yang direka untuk melaksanakan suatu fungsi bagi pengguna atau aplikasi yang 

lain dan dapat digunakan oleh sasaran 

5.6.1 Aplikasi Mobile 

Aplikasi Mobile adalah sebuah aplikasi yang memungkinkan Anda 

melakukan mobilitas dengan menggunakan perlengkapan seperti PDA, telepon 

seluler atau Handphone.Dengan menggunakan aplikasi mobile, Anda dapat 

dengan mudah melakukan berbagai macam aktifitas mulai dari hiburan, berjualan, 

belajar, mengerjakan pekerjaan kantor, browsing dan lain sebagainya. 

Pemanfaatan aplikasi mobile untuk hiburan paling banyak digemari oleh hampir 

70% pengguna telepon seluler, karena dengan memanfaatkan adanya fitur game, 

music player, sampai video player membuat kita menjadi semakin mudah 

menikmati hiburan kapan saja dan dimanapun. 

Sistem aplikasi mobile merupakan aplikasi yang dapat digunakan walaupun 

pengguna berpindah dengan mudah dari satu tempat ketempat lain lain tanpa 

terjadi pemutusan atau terputusnya komunikasi. Aplikasi ini dapat diakses melalui 


31 

perangkat nirkabel seperti pager, seperti telepon seluler dan PDA. Adapun 

karakteristik perangkat mobile yaitu: 

1. Ukuran yang kecil : Perangkat mobile memiliki ukuran yang kecil. 

Konsumen menginginkan perangkat yang terkecil untuk kenyamanan dan 

mobilitas mereka. 

2. Memory yang terbatas : Perangkat mobile juga memiliki memory yang 

kecil, yaitu primary (RAM) dan secondary (disk). 

3. Daya proses yang terbatas : Sistem mobile tidaklah setangguh rekan mereka 

yaitu desktop. 

5.7 Android 

5.7.1 Versi Android 

Android telah melakukan beberapa update sejak pertama rilis, berikut tabel 

versi Android yang dirilis oleh Google. 

Tabel 5.7 Versi android dan liris 

Versi Nama Tanggal Rilis 

1.5 Cupcake 30 April 2009 

1.6 Donut 15 September 2009 

2.0 Eclair 26 Oktober 2009 

2.2 Froyo 20 Mei 2010 

2.3 Gingerbread 6 Desember 2010 

3.0 Honeycomb 10 Mei 2011 

4.0 Ice Cream 16 Desember 2011 

Sandwich 

4.1 Jelly Bean 9 Juli 2012 

4.4 KitKat 31 Oktober 2013 

5.0 Lollipop 15 Oktober 2014 

6.0 Marshmallow 17 Agustus 2015 

7.0 Nougat 1 Juli 2016 


32 

8.0 Oreo 12 agustus2017 

5.7.2 Android Studio 

Android Studio adalah sebuah IDE untuk Android Development yang 

diperkenalkan google pada acara Google I/O 2013. Android Studio merupakan 

pengembangkan dari Eclipse IDE, dan dibuat berdasarkan IDE Java populer, 

yaitu IntelliJ IDEA. Android Studio merupakan IDE resmi untuk pengembangan 

aplikasi Android. Sebagai pengembangan dari Eclipse, Android Studio 

mempunyai banyak fitur-fitur baru dibandingkan dengan Eclipse IDE. Berbeda 

dengan Eclipse yang menggunakan Ant, Android Studio menggunakan Gradle 

sebagai build environment. Fitur-fitur lainnya adalah sebagai berikut : 

Gambar 5.7 Tampilan Android Studio (sumber : 

https://irmarismay99.wordpress.com) 

4. Mengkonsumsi daya yang rendah : Perangkat mobile menghabiskan 

sedikit daya dibandingkan dengan mesin desktop 

5. Kuat dan dapat diandalkan : Karena perangkat mobile selalu dibawa 

kemana saja, mereka harus cukup kuat untuk menghadapi benturan- benturan, 

gerakan, dan sesekali tetesan-tetesan air. 


33 

6. Konektivitas yang terbatas : Perangkat mobile memiliki bandwith rendah, 

beberapa dari mereka bahkan tidak tersambung. 

7. Masa hidup yang pendek : Perangkat-perangkat konsumen ini menyala 

dalam hitungan detik kebanyakan dari mereka selalu menyala. 

5.8 Java 

Java adalah bahasa pemrograman berorientasi objek yang serbaguna. 

Bahasa ini menyediakan sejumlah perluasan yang mendukung pengembangan 

aplikasi GUI (antarmuka kepada pemakai yang berbentuk grafis). Bahasa 

pemrograman java dapat berjalan pada sembarang platform yang memiliki 

interpreter dan lingkungan runtime. Walaupun java adalah bahasa penerjemah, 

program java harus dikompilasi terlebih dulu. Kompiler java (javac) mengubah 

kode sumber program menjadi bytecode yang dapat dieksekusi dalam lingkungan 

runtime java. (Jackson dan Alan, 1996: 3). 

Dalam penerapan java penulis memberikan sedikit contoh proses halaman 

awal pada aplikasi emergency call. 


34 

Gambar 5.8 Pemograman pada java (sumber : 

http://ibahasapemograman.blogspot.co.id/) 

5.9 GPS Tracking 

Gps tracker atau gps tracking adalah sebuah alat yang fungsi utamanya 

adalah memberikan informasi posisi kendaraan atau benda yang akan dilacak 

dengan memanfaatkan satelit GPS (Global Positioning System) dan GSM 

sehingga data koordinat posisi alat gps tracker bisa dikirim lewat jaringan GSM 

atau GPRS ke ownernya. 


35 

Gambar 5.9 cara kerja GPS (sumber : AKARI GPS) 

5.10 Application Programming Interface (API) 

Application Programming Interface (API) merupakan satu set instruksi 

pemograman untuk mengakses aplikasi berbasis web software atau web tool. 

Sebuah perusahaan perangkat lunak merilis API kepada publik sehingga 

pengembang perangkat lunak lain dapat merancang produk yang didukung oleh 

layanan. 

API pun dapat didefinisikan sebagai sebuah bahasa yang digunakan oleh 

sebuah program aplikasi untuk berkomunikasi dengan sistem operasi atau 

program kontrol lainnya seperti Database Managemnt System (DBMS) atau 

protokol komunikasi. 


36 

Gambar 5.10 Alur Application Programming Interface (API) (sumber : Maruti 

Techlabs di twitter) 

API adalah antar muka software to software, bukan user interface. Dengan 

API, aplikasi berkomunikasi satu sama lain tanpa sepengetahuan. Contohnya 

ketika membeli tiket film secara online dan memasukkan informasi kartu kredit, 

situs tiket film menggunakan API untuk mengirimkan informasi kartu kredit anda 

ke remote aplikasi yang memverifikasi apakah informasi sudah benar. Setelah 

pembayaran dikonfirmasi, remote aplikasi mengirimkan respon balik ke situs tiket 

film dan mengatakan pembayaran telah diterima dan tiket dapat diberikan. 

5.11 Google Maps API 

Google maps API merupakan aplikasi antar muka yang dapat diakses lewat 

javascript Google maps dapat ditampilkan pada halaman web yang sedang 

dibangun. Ada dua cara untuk mengakses data Google maps, tergantung dari data 

yang ingin diambil yang diuraikan dari Google maps. 

1. Menggunakan Google maps tanpa menggunakan API key. 

2. Mengakses data Google maps menggunakan API key. 


37 

Pendaftaran API key dilakukan dengan data pendaftaran berupa nama 

domain web yang kita bangun (Sirenden,2012). 

5.11.1 Manfaat Google Maps API 

adapun manfaat developers menggunakan Google Maps API ketika 

membangun aplikasi sebagai berikut : 

1. Beri aplikasi Anda akses penuh ke basis data Google di seluruh dunia yang 

berisi lebih dari 100 juta cantuman bisnis dan tempat menarik 

menggunakan Google Places API. 

2. Dengan petunjuk arah mengemudi di 199 negara, Directions API 

memungkinkan Anda membantu pengguna menemukan cara mereka 

menuju toko, hotel, dan tujuan Anda lainnya. 

3. Dengan citra visual Street View yang akurat, pengguna Anda dapat melihat 

tempat yang akan mereka kunjungi bahkan sebelum tiba di sana. 

Berikut adalah langkah-langkah untuk menambahkan peta ke aplikasi 

android 

Langkah-langkah dasar untuk menambahkan peta: 

1. (hanya perlu melakukan langkah ini satu kali.) Ikuti langkah dalam 

panduan konfigurasi proyek untuk mendapatkan API, memperoleh kunci 

dan menambahkan atribut yang diperlukan ke manifes Android. 

2. Tambahkan objek Fragment ke Activity yang akan menangani peta. Cara 

paling mudah untuk melakukannya adalah menambahkan elemen 

ke file layout untuk Activity. 

3. Implementasikan antarmuka OnMapReadyCallback dan gunakan metode 

callback onMapReady(GoogleMap) untuk mendapatkan tuas ke objek 

GoogleMap. Objek GoogleMap adalah representasi internal dari peta itu 

sendiri. Untuk menyetel opsi tampilan peta, Anda perlu memodifikasi 

objek GoogleMap. 

4. Panggil getMapAsync() pada fragmen untuk mendaftarkan callback. 


38 

Gambar 5.11 source code Google Maps Android API untuk memasukan peta 

pada android (sumber : developer google.com) 

5.12 JSON (java script object notation) 

JSON adalah JSON (java script object notation) adalah format pertukaran 

data (lightweight data interchange format), mudah dibaca dan ditulis oleh 

manusia, serta mudah diterjemahkan dan mudah dibuat (generate) oleh komputer. 

Format ini dibuat berdasarkan bagian dari bahasa pemrograman java script, 

standard ECMA edisi ke-3 desember 1999. JSON merupakan format teks yang 

tidak bergantung pada bahasa pemrograman apapun karena menggunakan gaya 

bahasa yang umum digunakan oleh pemrogrammer keluarga c termasuk c, c++, 

c#, java, java script, pel, python dll. Oleh karena sifat-sifat tersebut, menjadi 

JSON ideal sebagai bahasa pertukaran data (Nazariddin Safaat, 2011). 


39 

Gambar 5.12 contoh Source code JSON (sumber : 

https://marcelekaputra.wordpress.com) 

5.13 PHP 

Kadir, Abdul (2002:1) mengatakan PHP merupakan Bahasa server side 

HTML-embedded scripting, yaitu segala proses pemograman dilakukan di server 

sebelum dikirim ke komputer client sehingga komputer client hanya menerima 

keluaran dalam bentuk HTML.PHP adalah salah satu bahasa Server-side yang 

didesain khusus unluk aplikasi web. PHP dapat disisipkan diantara bahasa HTML 

dan karena bahasa Server side, maka bahasa PHP akan dieksekusi di server, 

sehingga yang dikirimkan ke browser adalah "hasil jadi" dalam bentuk HTML, 

dan kode PHP tidak akan terlihat. 

PHP dibuat pertama kali oleh seorang yang bernama Rasmus Lerdorf. pada 

awalnya PHP dibuat untuk menghitung jumlah pengunjung pada situsnya. Diawal 

Januari 2001, PHP telah dipakai lebih dari 5 juta domain diseluruh dunia 


40 

. Berikut adalah gambar tampilan lingkungan kerja dari phpMyAdmin yang 

digunakan oleh penulis 

Gambar 5.13 Contoh source code PHP (sumber : https://www.dumetschool.com) 

5.14 XML (extensible Markup Language) 

Menurut Garling dan Lestari (2010:2) XML atau extensible Markup 

Language bukanlah sebuah bahasa pemrograman. XML merupakan kumpulan 

aturan untuk mendesain format teks, sehingga format teks lebih terstruktur dan 

lebih mudah dibaca oleh komputer. 

Pada dasarnya XML merupakan penyusun informasi, sehingga sebuah 

informasi menjadi terstruktur dan dapat dibaca dengan mudah oleh komputer serta 

informasi tersebut mudah diterima oleh pengguna. Adapun fungsi XML adalah 

sebagai media pembawa data/informasi. 

Dalam penerapan XML penulis memberikan sedikit contoh tampilan 

halaman awal pada aplikasi emergency call. 

5.15 Framework CodeIgniter 

Saat ini sudah banyak bermunculan aplikasi yang memudahkan dalam 

mengembangkan website, ada yang mengembangkan website dari dasar, ada 

yang menggunakan CMS dan sekarang yang sedang banyak digunakan oleh para 

pengembang website ialah menggunakan framework. 


41 

Framework adalah kumpulan dari fungsi dan class yang sering digunakan 

oleh pengembang sehingga para pengembang tidak harus membuat fungsi dari 

awal. Konsep suatu framework mengikuti DRY (Dont Repeat Yourself) sehingga 

kode yang pernah dibuat dapat digunakan kembali oleh para pengembang lainnya. 

Keuntungan menggunakan framework seperti yang dijelaskan oleh Bertha Sidik 

(2012: 5) adalah pengunaan library yang ready-to-use sehingga memudahkan 

pengembang dalam pembuatan aplikasi yang tak perlu menulis script berulangulang. 

Selain itu ada beberapa keuntungan menggunakan framework , seperti : 

a. Mempermudah dalam pembuatan aplikasi website 

b. Mudah dalam perawatan atau pencarian bug 

c. Menggunakan konsep DRY sehingga pengembang tidak perlu membuat 

fungsi atau prosedur dari awal 

d. Lebih bebas dalam pengembangan aplikasi dibandingkan bila 

menggunakan CMS. 

Salah satu framework yang kini banyak digunakan ialah CodeIgniter yang 

dikembangkan oleh ElinsLab. CodeIgniter ini berbasis MVC yang 

memudahkan pengembang dalam pembuatan website, dan pelacakan kesalahan 

menggunakan metode dapat dengan mudah ditelusuri. Konsep MVC yakni suatu 

konsep dalam pengembangan aplikasi website, MVC memisahkan pengembangan 

aplikasi website berdasarkan komponen utama seperti pengolahan data, user 

interface, dan bagian yang menjadi kontrol aplikasi. Terdapat tiga bagian dalam 

konsep MVC yakni model, view dan controller. Model digunakan untuk 

pengolahan data sehingga berkaitan erat dengan database, view digunakan untuk 

mengolah bagian tentang tampilan sedangkan controller digunakan untuk 

penghubung antara bagian Model dan View. 

Keuntungan menggunakan framework CodeIgniter dibandingkan 

framework yang lain yakni : 

a. Perfoma lebih cepat 

b. Konfigurasi sangat minim 

c. Banyak komunitas CodeIgniter 

d. Dokumentasi sangat langkah 


42 

5.16 Menentukan Ruang Lingkup Penelitian 

Menurut (Turner, Eisele, Benz, & Holdener, 1998), Ruang lingkup 

penelitian seharusnya bisa menjawab pertanyaan seperti di mana data waktu 

tempuh dikumpulkan (Geographic Areas), dengan fasilitas apa data waktu tempuh 

dikumpulkan (Facility Types), dan kapan data waktu tempuh dikumpulkan (Time 

Elements). 

a. Geographic Areas 

Ruanglingkup geografis mendefinisikan batas-batas penelitian. 

Contoh cakupan geografis meliputi: 

Jalan pendek di sekitar transportasi yang direncanakan atau 

dilaksanakan perbaikan (misalnya sebelum dan sesudah perbaikan); 

Jalan tol atau jalan bebas hambatan dan jalan arteri paralel; 

Beberapa koridor transportasi yang melayani kawasan pusat bisnis 

atau pusat aktivitas masyarakat; dan 

Semua koridor transportasi utama dalam zona yang ditetapkan, subwilayah, 

atau wilayah (misalnya, sistem manajemen kemacetan). 

b. Facility Types 

Langkah berikutnya dalam mendefinisikan ruang lingkup studi 

menentukan jenis sarana transportasi atau kelas/klasifikasi fungsional jalan raya. 

Tabel berikut berisi contoh-contoh dari klasifikasi jalan umum dari berbagai 

sumber yang berbeda. 

Tabel 5.8 Klasifikasi Umum Jalan (sumber : PP 34/2006 tentang Jalan) 

Rencana Tata 

Travel Demand 

Highway Performance Ruang 

Forecasting Model Monitoring System Wilayah Jakarta 

(bervariasi) 

(HPMS), Perkotaan (U.S. 

Selatan Tahun 2011 

– 

2031 (Pemerintah 

Department of 

Jakarta 


43 

selatan,2011) 

Transportation, 2014) 

Jalan raya radial Jalan raya antar negara Jalan tol 

Jalan raya melingkar 

Jalan raya lain dan 

Jalan 

sekunder dan 

arteri 

bebas hambatan (1,6 s.d. 

kolektor sekunder 

4,8 km) 

Arteri utama (terbagi / tak Arteri utama lainnya (0,6 Jalan local 

terbagi) (0,6 s.d. 3,2 km) 

s.d. 3,2 km) 

Arteri kecil (terbagi / tak Arteri kecil (0,8 s.d. 3,2 

Jalan 

sekunder 

lingkungan 

terbagi) (0,8 s.d. 3,2 km) 

km) 

c. Time Elements 

Ada beberapa elemen waktu yang harus diperhatikan dalam membangun 

ruang lingkup kegiatan pengumpulan data waktu perjalanan: 

Periode bulan dalam setahun; 

Periode hari dalam seminggu; dan 

Periode waktu (Time Periods), atau jam dalam sehari. Sedangkan Time 

Periods secara umum diklasifikasikan sebagai berikut: 

1. Morning Peak Period, yaitu jam puncak kemacetan (jam berangkat kerja) 

pada pagi hari antara pukul 06:00 sampai dengan 09:00. 

2. Off-Peak Period, yaitu periode lalu lintas normal lancar pada siang atau 

dini hari. Biasanya antara pukul 10:00 sampai 11:00, 13:00 sampai 15:00 

dan setelah pukul 19:00. 


44 

3. Evening Peak Period, yaitu jam puncak kemacetan (jam pulang kerja) 

pada sore hari antara pukul 16:00 sampai dengan 19:00. 

5.17 Waktu Tempuh 

5.17.1 Definisi Kecepatan dan Waktu Tempuh Perjalanan (Travel Time) 

Waktu tempuh secara luas didefinisikan sebagai “waktu yang diperlukan 

untuk melintasi suatu rute di antara dua titik (titik keberangkatan dan tujuan) suatu 

tempat.” Waktu tempuh tersusun dari waktu jalan (running time), atau total waktu 

pada saat kendaraan bergerak, dan waktu berhenti/macet (stopped delay time), 

atau total waktu pada saat kendaraan berhenti (atau berjalan dengan rentang 

kecepatan kurang dari 8 km/jam) (Turner, Eisele, Benz, & Holdener, 1998). Lihat 

berikut yang mengilustrasikan konsep running time dan stopped delay time. 

Gambar 5.14 Ilustrasi Running Time dan 

Stopped Delay Time (sumber : Turner, Eisele, 

Benz, & Holdener, 1998) 

5.17.2 Rumus Estimasi Waktu Tempuh Perjalanan 

Pada beberapa kasus, waktu tempuh dapat diukur dengan mengasumsikan 

rata-rata kecepatan pada titik tertentu (spot speed) adalah konstan untuk jarak 

yang relatif dekat (biasanya kurang dari 0,8 km) dengan bantuan rumus kecepatan 

rerata-waktu (time-mean speed) pada Rumus 2.2. Kasus ini hanya cocok 


45 

diterapkan pada jalan bebas hambat (jalan tol) dengan pola arus lalu lintas yang 

stabil. Sedangkan untuk kondisi lalu lintas yang tidak stabil (karena ada 

kemacetan/delay), digunakan rumus kecepatan rerata-ruang (space-mean speed) 

pada persamaan Rumus 2.3. Kemudian perkiraan waktu tempuh total dapat 

dihitung menggunakan Rumus 2.1. (Turner, Eisele, Benz, & Holdener, 1998) 

Estimated Travel Time (detik) 

= 

jarak segment (km) 

time − mean speed ( km 

jam ) × (3.600 detik/jam) 

Rumus 2.1 Persamaan Estimasi Waktu Tempuh 

5.17.3 Rumus Time-Mean Speed 

Time-Mean Speed (Kecepatan Rerata-Waktu) adalah kecepatan rerata 

aritmetika semua kendaraan pada periode waktu tertentu, kecepatan ini relatif 

konstan tanpa hambatan 

time − mean speed = ∑v i 

n 

Rumus 2.2 Persamaan Time-Mean Speed 

Di mana: 

v i = kecepatan kendaraan ke − i 

d = jarak ditempuh atau panjang ruas jalan 

t i = waktu tempuh kendaraan ke − i 

n = jumlah observasi 

= ∑ d t i 

n 

5.17.4 Rumus Space-Mean Speed 

Space-Mean Speed (Kecepatan Rerata-Ruang) adalah kecepatan rerata 

kendaraan berjalan pada suatu ruas jalan tertentu selama jangka waktu 

tertentu dan dihitung menggunakan panjangnya ruas jalan 

(distance traveled) dibagi waktu tempuh rata-rata (average travel time) 

space − mean = 

d 

∑t i 

n 

= 

n × d 

∑t i 

Rumus 2.3 Persamaan Space-Mean Speed 


46 

Di mana: 

d = jarak di tempuh 



5.17.5 Rumus Average Running Speed 

Average Running Speed (Kecepatan Rerata Berjalan) adalah kecepatan ratarata 

kendaraan pada saat berjalan tanpa disertai kemacetan/delay time 

Average running speed = 

Rumus 2.4 Persamaan Average Running Speed 

Dimana: 

d = jarak ditempuh atau ruas jalan 

t ri = waktu tempuh 


5.17.6 Rumus Standar Deviasi dan Variansi Data 

d 

∑ t ri 

x 3600 (sec) 

Untuk menghitung Space-Mean Speed, diperlukan variansi sampel dari 

space-mean speed . Maka dari itu, rumus umum untuk menghitung deviasi standar 

sebagai berikut: 

∑(x − x)̈ 

SD = √ 

(n − 1) 

Rumus 2.5 Persamaan Standar Deviasi 

varians = SD 2 

Rumus 2.6 Mencari Variansi dari Standar Deviasi 

Dimana 

x = nilai ke − x 

ẍ = nilai rata − rata x 



47 

5.17.7 Hubungan Time-Mean Speed dengan Space-Mean Speed 

Ketika mengukur waktu tempuh total termasuk kemacetan (delay time), 

setelah menghitung kecepatan rerata-ruang pada Rumus 2.3 Persamaan Space- 

Mean Speed (ῦ), kemudian dihitung kembali kecepatan rerata-waktu dengan 

rumus berikut sebelum dimasukkan ke persamaan Rumus 2.1. Secara sederhana, 

Space-Mean Speed adalah jarak yang ditempuh kendaraan dibagi dengan rata-rata 

waktu tempuh perjalanan dan Time-Mean Speed adalah rata-rata kecepatan 

kendaraan individu 

υ̅TMS ≈ υ̅SMS + 

S 2 

̅̅̅̅̅̅̅̅ υ̅SMS 

Rumus 2.7 Rumus Hubungan ῦTMS dengan ῦSMS (Wardrop, 1952) 

Dimana : 

υ̅TMS = sample time − mean speed 

υ̅SMS = sample space − mean speed 

S 2 = variansi sample dari space − mean speed 

Rumus di atas mengindikasikan bahwa kecepatan rerata-waktu (ῦ) akan 

sama persis dengan kecepatan rerata-ruang (ῦ ) ketika variansi sampel dari 

kecepatan rerata-ruang ( 2 ) sama dengan nol (0). Kasus lainnya, ketika kecepatan 

rerata-ruang (ῦ ) lebih besar dari nol (0),kecepatan rerata-waktu (ῦ ) akan selalu 

lebih besar dari kecepatan rerata-ruang (ῦ ). 

5.17.8 Teknik Uji Kendaraan 

Untuk mengumpulkan data-data tersebut, penulis menggunakan Teknik Uji 

Kendaraan (Test Vehicle Techniques) dari buku Travel Time Data Collection 

Handbook oleh (Turner, Eisele, Benz, & Holdener, 1998) yang akan penulis 

jelaskan berikut ini. 

Penulis menggunakan Teknik Manual Uji Kendaraan “Aktif” (“Active” Test 

Vehicle Techniques), yaitu dengan cara mengendarai kendaraan roda empat 

(mobil) secara langsung pada ruas jalan yang sudah ditentukan dan kemudian 

mencatat secara manual waktu tempuh, waktu macet, dll. pada formulir koleksi 

data dengan bantuan stopwatch dan pulpen. untuk dilakukan analisa estimasi 


48 

waktu tempuh total, kecepatan rata-rata berjalan dan kecepatan rata-rata total 

perjalanan. 

Keunggulan uji ini adalah: 

• Biaya percobaan penelitian murah 

• Tidak memerlukan kemampuan khusus 

• Unggul dalam fleksibilitas rute 

• Ketepatan dan keterwakilan cukup wajar. 

5.18 Pemodelan dan Simulasi 

Pemodelan adalah proses untuk menghasilkan suatu model. Model adalah 

representasi dari konstruksi dan proses kerja dari beberapa sistem. Sebuah model 

adalah mirip tapi lebih sederhana dari sistem yang diwakilinya. Salah satu tujuan 

dari Model adalah memungkinkan analis untuk memprediksi efek perubahan dari 

suatu sistem. (Maria, 1997) 

Simulasi adalah alat untuk mengevaluasi kinerja dari sistem, yang ada atau 

yang diusulkan, di bawah konfigurasi yang berbeda dan jangka waktu lebih lama 

dari waktu nyata. (Maria, 1997) 

5.18.1 Skema Studi Simulasi 


49 

Gambar 2.15 Skema Studi Simulasi (sumber :Maria, 1997) 

Langkah-langkah yang terlibat dalam mengembangkan Model 

Simulasi (Simulation Model), merancang Percobaan Simulasi (Simulation 

Experiment) dan melakukan Analisis Simulasi (Simulation Analysis) sebagai 

berikut (Maria, 1997): 

5.18.2 Simulation Model 

a) Merumuskan masalah 

Pilih batasan dari sistem, masalah atau bagiannya untuk dipelajari. Tentukan 

tujuan keseluruhan dari studi dan beberapa isu-isu spesifik yang harus ditangani. 

Definisikan pengukuran kinerja (performance measure) – kriteria kuantitatif atas 

dasar konfigurasi sistem yang berbeda akan dibandingkan dan dinilai. 

Identifikasi rumusan hipotesis secara singkat tentang kinerja sistem. 

Tentukan jangka waktu penelitian, misalnya, akankah model digunakan sekali saja 

atau dengan periode waktu tertentu. Mengidentifikasi pengguna akhir dari model 

simulasi, misalnya, Manajemen Perusahaan versus Pengawas Produksi. Masalah 

harus dirumuskan setepat mungkin. 

b) Merumuskan dan mengembangkan model 

Mengembangkan skema dan diagram jaringan dari sistem (Bagaimana 

entitas mengalir melalui sistem?). Pastikan model simulasi berjalan sesuai tujuan. 

5.18.3 Simulation Experiment 

a) Penulis akan melakukan 3 (tiga) kali Observasi (Run) pada setiap Periode 

Waktu dengan mencacat Running Time (dalam detik) dan Stopped Delay 

Time (dalam detik), lihat Gambar 2.6 Ilustrasi Running Time dan Stopped 

Delay Time. Hasil dari perjalanan/running yang penulis lakukan bisa 

dilihat pada lampiran 3. Kemudian dari catatan itu akan dihitung Estimasi 

Waktu Tempuh 

b) Melakukan simulasi berdasarkan tahapan sebelumnya 


50 

5.18.4 Simulation Analysis 

a) Menginterpretasikan dan menampilkan hasil 

Tampilkan hasil perhitungan data (travel time, nilai rata-rata, running 

speed, delay time, dll.). Tampilkan kedua data uji 

hipotesis T-test pada percobaan dalam bentuk grafik sebagai data keluaran. 

Dokumentasikan hasil dan ambil kesimpulan. 

b) Rekomendasi untuk tindakan lanjutan 

Tahap ini menjelaskan percobaan tingkat lanjut dengan menggunakan 

peralatan (tools) yang lebih baik untuk memperoleh data. 

5.18.5 Keuntungan Pemodelan dan Analisis Simulasi 

Ketika digunakan dengan bijak, analisis simulasi memungkinkan untuk: 

a) Mendapatkan pemahaman yang lebih baik dari sistem dengan 

mengembangkan model matematika dari suatu sistem dan mengamati 

operasi sistem lebih rinci dalam jangka waktu yang lama. 

b) Uji hipotesis sistem untuk uji kelayakan. 

c) Melakukan percobaan dengan situasi yang tidak diketahui atau baru 

tersedia dengan sedikit informasi 

5.19 Uji Hipotesis T Sampel Independen 

Uji t untuk sampel independen merupakan prosedur uji t untuk sampel bebas 

dengan membandingkan rata-rata dua kelompok kasus. Kasus yang diuji bersifat 

acak. Pengujian hipotesis dengan distribusi t adalah pengujian hipotesis yang 

menggunakan distribusi t sebagai uji statistik. Tabel pengujian disebut tabel t- 

student. 

a. Kriteria data untuk uji t sampel independen : 

Data untuk dua sampel bersifat independen 

Sampel acak dari distribusi normal 

b. Fungsi pengujian uji t : 

Untuk memperkirakan interval rata-rata. 

Untuk menguji hipotesis tentang rata-rata suatu sampel. 

Untuk mengetahui batas penerimaan suatu hipotesis. 


51 

Untuk menguji layak tidaknya sebuah pernyataan dapat dipercaya 

atau tidak 

5.20 Gambaran Umum Instansi pemerintah 

Gambar 5.16 Logo BPBD Jakarta(sumber : https://bpbd.jakarta.go.id) 

Nama Instansi pemerintah : Badan Penanggulangan Bencana Daerah Jakarta 

Alamat 

: Jalan Abdul Muis No. 66, Petojo Selatan, Gambir, 

RT.4/RW.3, Petojo Sel., Gambir, Kota Jakarta 

Pusat, Daerah Khusus Ibukota Jakarta 

Telepon : (021) 3822078 

Fax : (021) 3822078 

Email 

: bpbddki@jakarta.go.id 

Website 

: https://bpbd.jakarta.go.id 

5.20.1 Sejarah Singkat Instansi pemerintah 

Provinsi DKI Jakarta merupakan Ibu Kota Republik Indonesia yang 

memiliki permasalahan kebencanaan yang kompleks. Dengan luas 661,52 km2, 

40% atau 24.000 hektar merupakan dataran rendah dengan ketinggian rata-rata di 

bawah permukaan air laut. DKI Jakarta juga merupakan pertemuan sungai dari 

bagian selatan dengan kemiringan dan curah hujan tinggi. Terdapat 13 sungai 

yang melewati dan bermuara ke Teluk Jakarta. Secara alamiah, kondisi ini 

memosisikan wilayah DKI Jakarta memiliki kerawanan yang tinggi terhadap 

banjir. 

Beberapa wilayah DKI Jakarta, pada musim penghujan menjadi wilayah 

banjir. Dari catatan sejarah kejadian banjir, banjir besar pernah terjadi pada tahun 


52 

1621, 1654 dan 1918. Banjir besar juga terjadi pada tahun 1976, 1996, 2002, 2007 

dan 2013. Banjir tahun 1996 menggenangi hampir seluruh penjuru kota. Kejadian 

ini menjadi tragedi nasional dan mendapat perhatian dunia. Banjir tahun 2007 

juga memiliki cakupan wilayah genangan lebih luas. Berulangnya kejadian banjir 

per lima tahun menyebabkan banyak kalangan memercayai sebagai siklus lima 

tahunan. Kerusakan dan kerugian terhadap aset terkena banjir yang melanda DKI 

Jakarta, Bogor, Depok, tangerang dan Bekasi (Jabodetabek) tahun 2007, baik 

milik pemerintah, aset dunia usaha dan aset masyarakat diperkirakan senilai 

Rp5,16 trilyun. 

Selain ancaman bencana banjir, DKI Jakarta juga memiliki ancaman 

bencana lain berupa cuaca ekstrim, gelombang ekstrim, gempa bumi, tanah 

longsor maupun ancaman bencana non alam dan sosial seperti konflik sosial, 

kegagalan teknologi, epidemi, dan wabah penyakit, kebakaran gedung dan 

pemukiman. 

Resiko bencana di DKI Jakarta dipengaruhi oleh ancaman bencana, 

kerentanan, dan kapasitas dalam menghadapi ancaman yang ada. Curah hujan 

tinggi dalam waktu yang pendek meningkatkan tingkat bahaya banjir akibat 

topografi wilayah, daya dukung lingkungan yang semakin menurun maupun 

kerentanan dan kapasitas warga dalam menghadapi ancaman bencana. Penurunan 

permukaan tanah yang diakibatkan oleh ekspoitasi air yang berlebihan dan 

pembangunan insfrastruktur semakin meningkatkan ancaman banjir dan 

meningkatkan kerentanan wilayah maupun komunitas DKI Jakarta. 

5.20.2 Visi dan Misi Instansi pemerintah 

a. Visi Perushaan 

“Ketangguhan Kota Jakarta dalam Menghadapi Bencana” 

b. Misi Perusahan 

1. Melindungi warga Jakarta melalui pengurangan resiko bencana. 

2. Meningkatkan kesiapsiagaan masyarakat kota Jakarta. 

3. Meningkatkan kapasitas penanggulangan bencana. 


53 

5.20.3 Struktur Organisasi Instansi pemerintah 

Gambar 5.15 Struktur Organisasi BPBD Jakarta (sumber : 

https://bpbd.jakarta.go.id) 

5.20.4 Tugas Pokok dan Fungsi 

Berikut ini tugas dan fungsi BPBD Jakarta yaitu: 

1. Menetapkan pedoman dan pengarahan sesuai dengan kebijakan 

Pemerintah Daerah dan BNPB terhadap usaha Penanggulangan Bencana 

yang mencakup pra Bencana, Tanggap Darurat Bencana dan Pasca 

Bencana secara adil dan setara serta sesuai dengan kebutuhan dan 

perkembangan; 

2. menetapkan standardisasi serta kebutuhan penyelenggaraan 

Penanggulangan Bencana sesuai dengan ketentuan peraturan perundangundangan; 

3. menyusun, menetapkan dan menginformasikan peta rawan bencana; 

4. menyusun dan menetapkan prosedur tetap penanganan bencana; 

5. melaksanakan penyelenggaraan penanganan bencana di daerah; 

6. melaporkan penyelenggaraan penanganan bencana kepada Kepala Daerah 

setiap 1 (satu) bulan sekali dalam kondisi normal dan setiap saat dalam 

keadaan darurat bencana; 


54 

7. mengendalikan pengumpulan dan penyaluran uang dan barang; 

8. mempertanggungjawabkan penggunaan anggaran yang diterima dari 

APBD; dan 

9. melaksanakan kewajiban lain sesuai dengan ketentuan peraturan 

perundang-undangan. Dan memiliki fungsi 

10. Perumusan dan penetapan kebijakan Penanggulangan encana dan 

penanganan Pengungsi dengan bertindak cepat, tepat, efektif dan efisien; 

dan 

11. pengoordinasian pelaksanaan kegiatan Penanggulangan Bencana secara 

terpadu dan menyeluruh. 


BAB III 

METODOLOGI PENELITIAN 

6.1 Metode Pengumpulan Data 

Dalam melakukan pengumpulan data penulis menggunakan tiga cara atau 

teknik untuk mendapatkan bahan-bahan sebagai dasar penelitian yaitu metode 

observasi, metode studi pustaka, metode wawancara. 

6.2 Studi Lapangan 

6.2.1 Observasi 

Pada tahap ini penulis melakukan observasi dengan membandingkan 

beberapa layanan crowdsouce yang menyediakan data kemacetan lalu lintas yang 

di petakan. Beberapa layanan tersebut seperti : Google Maps,Waze,Bing Maps 

Tabel 3.1 perbandingan layanan crowdsouce 

Google Maps Waze Bing 

Maps 

Pemilik Google,Inc Waze 

Microsoft,corp 

mobile(acquired by 

google,Inc) 

Fitur 

Peta,navigasi, Peta dan Peta dan 

street 

navigasi 

navigasi 

view,satelite,custom 

map styling,static 

and interativ 

,google place API 

Keung 

gulan 

Terpilih 

(Google 

Maps) 

Kepem 

ilikan sendiri 

Lebih 

banyak fitur 

55

56 

API Access Unofficial Maps API limited Memili 

access 

ki API 

sendiri 

Kontributor 

crowd 

Durasi 

pembaruan 

Banyak karena Banyak sedikit Google maps 

waze sudah masuk 

banyak 

di dalam 

kontributor 

perusahaan google 

dan waze 

sudah masuk 

di dalam 

perusahaan 

google 

Sinkronus Setiap 30 menit Tidak dikethui Update data 

google maps 

real time 

Platform Mobile web, Mobile web, 

Mobile web Google 

android, ios, android, 

multiplatform 

symbian,blackberry ios,symbian,blackberry 

,and windows ,and windows mobile 

mobile 

6.2.2 Wawancara 

Konsultasi dan tanya jawab langsung dengan staff terkait di Badan 

Penanggulangan Bencana Daerah Jakarta (BPBD Jakarta) peneliti pada pada 

tanggal 10 juli 2017 di kantor BPBD Jakarta (lampiran 1) untuk mendapatkan 

penjelasan mengenai sistem yang sedang berjalan.Proses tanya jawab secara lisan 

dilakukan dengan harapan agar penulis mendapatkan data yang dibutuhkan untuk 

sistem yang dibutuhkan user. Dari hasil wawancara diperoleh sistem yang sedang 

berjalan dan data-data dari hasil wawancara digunakan untuk mengidentifikasi 

kebutuhan-kebutuhan pengguna akan aplikasi emergency call berbasis android. 

Hasil wawancara disajikan pada bagian lampiran . 


57 

6.3 Studi Pustaka 

Penulis melakukan studi pustaka sebagai bahan tambahan untuk 

melengkapi kekurangan-kekurangan data yang diperoleh dari observasi. 

Pengumpulan data dan informasi dengan cara mengambil sumber-sumber media 

cetak maupun elektronik yang dapat dijadikan acuan pada pembahasan masalah 

dan digunakan pada penyusunan landasan teori. 

6.3.1 Studi Literatur 

Studi literatur dalam penelitian ini dilakukan untuk menambah referensi 

teori-teori yang digunakan dalam penelitian serta mempelajari literatur yang dapat 

mendukung penelitian terhadap aplikasi emergency call. Sumber-sumber yang 

dapat dijadikan sumber litartur antara lain tugas akhir atau skripsi sejenis, tesis 

dan jurnal-jurnal yang terkait dengan penelitian yang akan 


58 

No Judul, Tahun Peneliti, 

Sumber 

Kelebihan Kekurangan Perbedaan dengan penulis 

1 Aplikasi 

 

Lutfi 

 

telah 

 

belum 

 

menggunakan 2 aplikasi satu 

Monitoring Armada 

Chrisdiansyah,Anji 

menggunakan 

menggunaka 

buat user aplikasi dan satu 

Bus Menggunakan 

k Sukmaaji,Teguh 

GPS Tracking 

n 

google 

lagi buat petugas 

Gps Tracking Pada 

Sutanto 

untuk 

maps 

API 

menggunakan 

google 

Smartphone Android 

 

Institut Bisnis dan 

memantau 

untuk 

maps API 

-Tahun 2016 

Informatika 

keberadaan bus 

menghitung 

STIKOM Surabaya 

telah berbasis 

berapa jarak 

android 

terdekat dari 

smartphone 

bus lain 

android 

 

hanya 

sebagai 

alat 

berfokus 

monitoring 

untuk 

monitoring 

bus 


59 

2 Aplikasi 

 

Budi Yulianto, Rita 

telah berbasis 

 

belum 

 

menggunakan google maps 

Pencarian Rumah 

Layona 

android untuk 

menggunaka 

API sehingga mudah dalam 

Makan Berbasis Gps 

 

mencari rumah 

n 

google 

mendapatkan lokasi yang 

Pada Perangkat 

makan terdekat 

maps 

API 

ingin di cari dan di tracking 

Mobile Android 

- Tahun 2016 

 

telah 

menggunakan 

sehingga ada 

data rumah 

GPS 

untuk 

makan belum 

mencari rumah 

lengkap 

makan terdekat 

 

belum 

menggunkan 

algoritma 

djikstra 

untuk 

memilih 

rumah makan 

mana 

yang 

terdekat dari 

user 


60 

3 Analisis 

Muhamad rizka 

 

Telah 

 

Masih 

Di aplikasi penulis 

perhitungan 

akbar 

menggunakan 

Menggunaka 

Menggunakan 

crowdsource 

keakuratan waktu 

aplikasi mobile 

n 

matrix distance API 

tempuh data 

dengan 

crowdsource 

 

crowsource pada 

berbasis 

dari waze 

aplikasi perhotelan di 

android 

tanggerang selatan 

 

Menggunakan 

dengan metode 

metode 

Estimed Travel Time 

Estimed Travel 

-Tahun 2015 

Time 

4 Aplikasi 

 

Hidayatullah 

 

telah 

 

penghitungan 

melakukan pada tempat- 

Crowdsourcing 

Suryaputra 

menghitung 

estimasi 

tempat berbeda karena 

Estimasi Waktu 

Crowdsource 

waktu 

menggunakan 

fitur google 

Kedatangan Bus 

dengan waktu 

kedatangan 

maps API 

Transjogja Berbasis 

kedatangan bis 

hanya 

Android 

ke halte 

berlaku buat 

-Tahun 2016 

tempat yang 

telah 

di 


61 

tentukan 

5 Membangun 

 

MahdyArief,NiaA 

 

Telah 

 

Masih 

Di aplikasi penulis telah 

Aplikasi E-Commerce 

mbarsari 

menggunakan 

berbasis web 

menggunkan 

aplikasi 

Jasa Fotografi Pre 

,TaufikNurAdi 

teknik 

berbasis android 

Wedding Berbasis 

crowsource 

Web Crowdsourcing 

dalam 

Modul Fotografer 

pencarian data 

Menggunakan Metode 

Iterative Incremental 

-Tahun 2015 


62 

6.4 Metodologi Pengembangan Sistem 

Metode pengembangan sistem yang akan digunakan dalam penulisan ini 

adalah metorde berorientasi objek dengan model pengembangan Rapid 

Application Development (RAD) dan tools UML untuk pemodelannya. 

Alasan pribadi menggunakan Rapid Application Development (RAD) dan 

tools UML 

1. Dikarenakan pembuatan aplikasi atau sistem sangat lah mudah 

2. Tidak terlalu banyak menggunakan biaya 

3. Bisa dilakukan pengerjaan lebih cepat 

Alasan dari refernsi penulis ambil (Rizal Loa Wanda) menggunakan Rapid 

Application Development (RAD) dan tools UML : 

Alasan yang Buruk 

1. Apabila menggunakan RAD hanya untuk menghemat biaya 

pengembangan suatu sistem. Hal ini disebabkan karena dengan 

menggunakan metode RAD membutuhkan suatu tim yang 

mengerti betul 

2. mengenai manajemen biaya. Sebab bila tidak, maka biaya yang 

dikeluarkan akan menjadi lebih besar. 

3. Apabila menggunakan RAD hanya untuk menghemat waktu 

pengembangan suatu sistem. Hal ini disebabkan karena dengan 

menggunakan metode RAD membutuhkan suatu tim yang 

mengerti betul mengenai manajemen waktu. Sebab bila tidak maka 

waktu yang dibutuhkan akan menjadi lebih lama. 

Alasan yang Baik 

1. Apabila menggunakan RAD untuk mendapatkan suatu desain yang 

dapat diterima oleh konsumen dan dapat dikembangkan dengan 

mudah. 

2. Apabila menggunakan RAD untuk memberikan batasan-batasan 

pada suatu system supaya tidak mengalami perubahan. 


63 

3. Apabila menggunakan RAD untuk menghemat waktu, dan kalau 

memungkinkan bisa menghemat biaya serta menghasilkan produk 

yang berkualitas. 

Tahapan pengembangan sistem dengan RAD ini terdiri dari beberapa tahap 

yaitu: 

6.4.1 Fase Requirement Planning 

Pada fase ini, peneliti mengidentifikasi kebutuhan aplikasi yang terkait 

dengan aplikasi emergency call. Tidak hanya itu, fase ini juga dapat menentukan 

batasan-batasan untuk aplikasi yang dibuat, kendala, serta alternatif masalah. Pada 

fase ini, peneliti melakukan interaksi secara langsung pada pihak yang terkait 

dalam proses pembuatan aplikasi yang berjalan terutama dalam hal proses 

emergency call. Berikut hasil yang diperoleh dari interkasi tersebut: 

1. Data-data mengenai keberadaan posisi dan koordinat : 

a) Rumah sakit 

b) Kantor polisi 

c) Pemadam kebakaran 

d) Ambulance 

2. Analisis 

Analisis dalam menjabarkan permasalahan-permasalahan yang terjadi pada 

pelayanan penanggulangan bencana. Penulis menggunakan rich picture dalam 

memvisualisasi proses cara menggunakan aplikasi. Berikut hal yang dilakukan 

dalamtahap analis yaitu: 

a. Problem Analysis, mempelajari pelayanan penanggulangan 

bencana dan estetika yang telah berjalan dan menganalisa 

masalah-masalah yang terdapat pada pelayanan emergency 

call sebelumnya yang berjalan. Adapun langkah-langkah tahap 

ini adalah sebagai berikut: 

- Membuat gambaran dari hasil analisa sistem yang sedang 

berjalan pada BPBD jakarta (Badan Penanggulangan 

Bencana Daerah Jakarta) 


64 

- Mengidentifikasi masalah-masalah yang ada pada 

pelayanan emergency call yang sedang berjalan. 

b. Requirement Analysis, menganalisis kebutuhan apa saja yang 

diperlukan dalam permasalahan pada pelayanan emergency 

call a .Tahapan dari requirement analysis sebagai berikut: 

- Membuat tabel analisis PIECES, peneliti menganalisis 

persyaratan dengan mengacu pada kerangka kerja PIECES 

yang disajikan pada tabel perbandingan sistem berjalan 

dengan sistem usulan. 

c. Decision Analysis, menentukan solusi yang akan digunakan 

dalam mengatasi masalah pelayanan emergency call: 

- Menentukan aplikasi seperti apa yang sesuai dengan 

persyaratan yang telah ditentukan. 

- Menentukan teknologi yang dipakai pada aplikasi. 

- Menentukan komponen-komponen aplikasi 

6.4.2 Fase Workshop Design 

Pada fase Workshop Design, penulis melakukan perancangan sistem yang 

diusulkan dengan tahapan yang penulis lakukan sebagai berikut: 

a. Mekanisme Pengambilan Data Crowdsource. 

Pada tahap ini, penulis melakukan perancangan proses pengambilan data 

lalu lintas (traffic) terkini dari situs Google Maps API . 

b. Perancangan UML 

Pada tahap ini, penulis melakukan perancangan dengan menggunakan UML 

seperti berikut: 

Use Case Diagram Sistem (Identifikasi Actor) 

Use Case Naratif Desain Sistem 

Activity Diagram 

Sequence Diagram 


65 

c. Perancangan Basis Data (Database) 

Pada tahap ini, penulis melakukan perancangan basis data yang mengacu 

pada class diagram sebagai berikut: 

Perancangan Class Diagram 

Perancangan Antarmuka (User Interface) 

Pada tahap ini, penulis melakukan perancangan tampilan antarmuka untuk 

mengetahui seperti apa bentuk tampilan yang akan digunakan pada aplikasi. 

Selain itu, dilakukan juga pembuatan Struktur Menu yang akan ditampilkan pada 

aplikasi. 

6.4.3 Fase Implementasi 

Pada fase ini dilakukan beberapa tahap penerapan perancangan prototipe 

aplikasi, sebagai berikut: 

a. Implementasi Aplikasi Mobile Emergency Call 

Pada tahap ini dilakukan implementasi aplikasi untuk fitur 

halaman utama,kejadian,dan profil pelapor. 

b. Melakukan Pengodean (coding) Aplikasi. 

Pada tahap ini, penulis melakukan tahap pengodean terhadap hasil 

rancangan yang telah didefinisikan untuk dijadikan suatu program 

aplikasi yang siap digunakan. 

c. Implementasi Aplikasi ke Server 

Pada tahap ini dilakukan pengunggahan (upload) data aplikasi ke 

sisi server (server side hosting) berupa file PHP beserta basis 

datanya. 

d. Pengujian Aplikasi (Blackbox Testing) 

Pada tahap ini penulis melakukan pengujian aplikasi dengan 

menggunakan metode blackbox. Penulis melakukan dua tahap 

pengujian blackbox yaitu: 

Pengujian Fungsionalitas Aplikasi 

Pengujian ini untuk memastikan fungsionalitas aplikasi 

berjalan sebagaimana mestinya tanpa memerhatikan 

pengodean aplikasi. Pengujian ini dititikberatkan pada 


66 

fungsionalitas aplikasi, tidak mengecek benar atau salahnya 

suatu alur algoritma aplikasi di dalamnya. 

Kesimpulan Hasil Pengujian Blackbox. 

Tahap ini menjelaskan tentang kesimpulan dari 2 tahap 

pengujian Blackbox yang telah dilakukan pada tahap 

sebelumnya. 

e. Pengujian Data Estimasi Waktu Tempuh 

Tahapan ini menjelaskan studi kasus pengujian data yang 

dilakukan dengan cara menghitung manual dengan rumus 

Estimasi waktu tempuh yang sudah dibahas pada Bab 2 dan 

dicocokkan dengan data pada aplikasi dengan uji Hipotesis T-test 

dengan menggunakan metode Modeling and Simulation dari 

(Maria, 1997) yang terdiri dari Simulation Model, Simulation 

Experiment dan Simulation Analysis yang kemudian ditarik 

kesimpulan. 

6.5 Kerangka Berpikir Penelitian 

Dalam melakukan penelitian ini, penulis melakukan tahapan-tahapan 

kegiatan yang sesuai dengan rancangan kegiatan sebagaimana yang tertuang pada 

kerangka penelitian. Kerangka berpikikir tersebut meliputi metode pengembangan 

sistem yang terlihat pada gambar berikut: 


67 

Gambar 3.1 Kerangka Berpikir 


BAB IV 

ANALISIS DAN PERANCANGAN SISTEM 

4.1 Requirement Planning 

7.1.1 Analisis Sistem 

4.1.2.1 Problem Analysist 

4.1.2.1.1 Analisa Sistem Berjalan 

Sistem Pelayanan Badan Penanggulangan Bencana 

Daerah Jakarta saat ini masih berjalan secara manual. 

Pemesanan masih menggunakan manual dengan menginput 

nomor telepon gawat darurat dan tidak mengetahui posisi 

kendaraan instansi gawat darurat . Berdasarkan pengamatan dan 

observasi yang telah penulis lakukan maka dapat dijelaskan 

sistem yang sedang berjalan dalam penanganan proses pelayan 

gawat. Berikut proses pelayanan gawat darurat yang 

digambarkan dalam bentuk rich picture: 

68

69 

Gambar 4.7.1 Rich Picture Sistem Berjalan 

Berikut merupakan penjelasan dari rich picture proses 

pelayanan kesehatan estetika yang sedang berjalan saat ini: 

1. Agent Menerima telepon masuk dari masyarakat 

melalui call center 112 

2. Agent Menanyakan dan menginput : 

a. IdentitasPelapor (Nama Pelapor) 

b. Nomor Telepon 

c. JenisKejadian 

d. Lokasi Kejadian (Alamat dan titik kenalkejadian) 

e. Jenis Bencana 

f. Apakah ada korbanjiwa 

g. Hal-hal lain/informasi lain yang akan ditambahkan 


70 

3. Agent Menghubungi polisi,ambulace,divisi KDRT dan 

pemadam kebakaran sesuai laporan dan dibutuhkan pelapor 

melalui Radio Trunking atau Telepon 

4. Menerima laporan kejadian dari agent call center112 

5. Agent Melakukan Koordinasi dengan SKPD lain yaitu, 

Dinas Sosial, Dinas Sumber Daya Air, Dinaskehutanan, 

Dinas Lingkungan Hidup, SARJakarta,DPE/PLN dan Dinas 

Bina Marga. 

6. Menerima laporan kejadian dari agent call center 112 dan 

memonitor status kejadian melalui aplikasi Web Monitoring 

7. Back Office memantau pergerakan mobil AGD 

yangdiluncurkan dengan berkoordinasi dengan DISHUB 

8. Back Office memantau proses penanganan di lokasikejadian 

dengan berkoordinasi DISHUB,SAR,PMI dan AGD 

9. Back Office berkoordinasi dengan AGD, PMI,DISHUB dan 

RS serta memandu Ambulance terkaitpengiriman korban ke 

RS terdekat 

10. Menerima informasi dari Back Office mengenai Menerima 

korban. 

11. Back Office menerima laporan terkait upaya penanganan 

korban dari RS. 


71 

12. Back Office berkoordinasi dengan g polisi,ambulace,divisi 

KDRT dan pemadam kebakaran sesuai laporan tentang 

status kejadian 

13. Back Office Menghubungi SKPD dan PMI terkait bahwa 

kejadian sudah ditutup. 

4.1.2.1.2 Identifikasi Masalah 

Di dalam mengidentifikasi masalah, peneliti 

menganalisis sistem yang berjalan di BPBD Jakarta. Sistem yang 

digunakan untuk melakukan kegiatan pelayanan gawat darurat 

saat ini pada dasarnya sudah memenuhi prosedur yang 

dibutuhkan. Namun sistem tersebut masih terdapat beberapa 

kekurangan, diantaranya adalah sebagai berikut: 

1. Pemesan tidak mengetahui posisi keberadaan kendaraan 

2. Informasi mengenai kejadian yang dilaporkan tentang 

kejadian dengan menggunkan sistem yang masih lama 

belum tentu kebenaran 

3. Pelayanan gawat darurat kurang efisen karna komunikasi 

antar pihak masih menggunakan telepon umum . 

4.1.2.2 Requirement Analysist 

4.1.2.2.1 Analisis PIECES 

Analisis PIECES dilakukan untuk mengetahui 

persyaratan apa saja yang dibutuhkan untuk memperbaiki sistem 

yang berjalan dapat diperoleh berdasarkan analisis dengan 


72 

menggunakan kerangka kerja PIECES dengan memperhatikan 

beberapa aspek yang meliputi kinerja (performance), nilai 

informasi (information), nilai ekonomi (economic), pengendalian 

(control), efisiensi (efficiency), dan pelayanan (service). Analisis 

ini dilakukan pada sistem yang berjalan sehingga hasilnya dapat 

diketahui sistem yang akan diusulkan tersebut layak atau tidak. 

Tabel 7.1 Analisis PIECES 

ator 

Indik 

Performance 

Kelemahan Sistem 

Berjalan 

Masih menggunakan via 

Sistem Usulan 

Proses pelaporan telah 

telepon sehingga proses 

menggunakan 

aplikasi 

penerimaan data dan proses 

berbasis android sehingga 

konfrimasi 

petugas 

pelapor hanya menekan panic 

membutuhkan waktu lama 

button 

Information 

Informasi yang disajikan 

Informasi 

yang 

pada laporan harian, mingguan 

dan bulanan terkadang tidak 

disajikan dapat lebih akurat 

dan rapih karena sistem dapat 

akurat karena belum 

terdapatnya basis data atau 

database untuk menyimpan 

data-data 

mendokumentasikan 

datadata 

dengan baik 

Economic 

Dibutuhkan biaya dalam 

pemberitahuan dari agent ke 

Biaya yang dikeluarkan 

akan berkurang karena 


73 

pada instansi gawat 

dengan adanya aplikasi yang 

hanya menggunakan sedikit 

data seluler 

Control Dalam pengentrolan 

hanya agent center yang 

mengetahui posisi petugas 

Efficiency Waktu penyusunan 

laporan dan relatif lama 

Agent center dan 

palapor sudah mengetahui 

posisi petugas 

Mempersingkat proses 

penyusunan data laporan 

sehingga 

penyampaian 

kejadian dan penyampaian 

informasi kepada pihak 

laporan. 

pimpinan kurang maksimal. 

Service Pihak pelapor tidak 

Pelapor 

dapat 

mengetahui tentang status 

laporan kejadian yang 

mengetahui status laporan 

kejadian 

dilaporkan pelapor 

4.1.2.3 Decission Analysist 

Dari tahapan analisis sebelumnya telah diketahui permasalahan 

dari sistem yang berjalan dan persyaratan apa saja yang dibutuhkan 

dalam sistem yang diusulkan. Sistem usulan ini diharapkan mampu 

memenuhi kebutuhan dalam proses pelayanan gawat darurat dan 

memberikan solusi atas kekurangan sistem yang berjalan. 


74 

4.1.2.3.1. Menentukan Sistem Usulan 

Berdasarkan persyaratan yang telah didapat maka dapat 

disimpulkan bahwa sistem usulan yang paling mendukung proses 

pelayanan gawat darurat tersebut yaitu berbasis android yang 

dapat menyajikan layanan gawat darurat secara realtime karena 

user dapat melaporkan kejadian secara online dengan 

menggunakan fasilitas internet. Selain itu sistem ini juga dapat 

mengintegrasikan data yang terdapat pada satu database, 

sehingga memudahkan dalam pengelolaan data layanan gawat 

darurat 

4.1.2.3.2. Menentukan Teknologi 

Sistem usulan ini dirancang dengan menggunakan tools 

UML (Unified Modelling Language) untuk menggambarkan 

proses sistem. Sedangkan teknologi yang akan digunakan untuk 

pengembangan sistem ini adalah bahasa pemrograman PHP. 

Media penyimpanan data menggunakan MySQL. Peneliti 

menggunakan XAMPP yang merupakan web server apache yang 

di dalamnya sudah menyediakan database server MySQL dan 

mendukung pemrograman PHP. Untuk aplikasi yang digunakan 

pasien menggunakan mobile Android, Bahasa pemprograman 

yang digunakan adalah JAVA dan XML. Sedangkan tools yang 

digunakan untuk membangun aplikasi mobile adalah Android 

Studio. Untuk koneksi antara webservice dengan mobile atau 


75 

Aplication Programing Interface (API) mengunakan notasi JSON. 

Sistem Informasi Pelayanan Gawat Darurat yang akan dibangun 

ini menggunakan teknologi open source, jadi pengembang tidak 

perlu menggunakan banyak biaya untuk mendapatkan lisensi dari 

tools yang digunakan. 

Dengan server yang sudah terkoneksi dengan internet 

maka sistem ini dapat diakses dengan mudah dimana dan kapan 

saja. Sistem ini dapat diakses dengan berbagai macam web 

browser, seperti UC Browser, Chrome (disarankan), Opera, 

Firefox dan lain-lain. Selain itu dalam pengembangan aplikasi 

mobile Android dibangun mengunakan SDK Android versi 

Jellybean sampai SDK terbaru saat ini yaitu Oreo, sehingga dapat 

diakses oleh berbagai macam device Android yang tersedia saat 

ini. 

4.1.2.3.3. Gambaran Sistem Usulan 

Penulis mengusulkan dengan membangun sebuah 

aplikasi berbasis android mobile yang dapat melaporkan kejadian 

darurat secara real time dan mempermudah server untuk mencari 

instasi apa yang dibutuhkan pelapor dalam kejadian gawat darurat 

layanan gawat darurat serta sistem ini diharapkan mampu untuk 

membantu dalam proses layanan gawat darurat 

pendokumentasian data-data kejadian yang telah di laporkan. 

Berikut gambaran sistem yang disusulkan penulis: 


76 

Gambar 4.7.2 Sistem Usulan 

Berikut penjelasan dari sistem yang diusulkan penulis: 

1. Pelapor melaporkan kejadian melalui aplikasi. 

2. Pelapor memilih instansi yang ada di aplikasi. 

3. Sever memberi infomarsi kepada instnasi sesuai 

permintaan pelapor yang di pilih memlalui aplikasi. 

4. Instansi mengkonfrimasi keberangkatan melalui aplikasi 

petugas 

5. Server memberi status instansi yang di pilih pelapor 

6. Kepala pelaksana mendapat laporan dari kejadian 


77 

7.2 Workshop Design 

7.2.1 Desain Proses 

4.2.2.1 Perancangan Use Case Diagram 

Use case diagram di bawah ini menggambarkan interaksi 

antara sistem dan user. Berikut ini adalah langkah-langkah dalam 

membuat use case diagram yaitu: 

a. Identifikasi Actor 

Tabel 7.2 Identifikasi Actor 

Aktor 

Pelapor 

Petugas 

Penjelasan 

Orang yang melaporkan kejadian gawat darurat 

Orang yang akan melakukan penindakan 

kejadian gawat darurat 

Server 

Perantara informasi dari pelapor ke petugas dan 

milih petugas mana yang akan diberangkatkan 

b. Identifikasi Usecase 

Tabel 7.3 Identifikasi Usecase 

Usecase Penejelasan Aktor 

registrasi Use Case ini 

Pelapor 

dan 

menggambarkan 

pengisian biodata 

proses 

petugas 

Login Use case ini merupkan Semua aktor 


78 

pengisian username dan 

password 

Pilih instansi Use Case ini 

Pelapor 

dan 

menggambarkan 

kegiatan 

server 

pemilihan instansi gawat 

darurat 

informasi kejadian Use Case ini 

menggambarkan 

petugas 

Server 

dan 

mendapatkan 

informasi 

kejadian 

list opsi rute Use Case ini 

Server 

dan 

menggambarkan 

kegiatan 

petugas 

melihat rute terpendek 

Tracking maps Use Case ini 

Pelapor 

dan 

menggambarkan 

kegiatan 

server 

untuk melihat posisi petugas 

oleh pelapor di aplikasi 

emergency call 


79 

c. Use Case Diargam 

Gambar 4.7.3 Usecase Diagram 

d. Narasi Use Case 

Narasi use case digunakan untuk mendeskripsikan interaksi 

dan langkah-langkah yang terjadi antara sistem dengan 

penggunanya secara tekstual. Berikut adalah narasi use case yang 

akan menjelaskan use case yang telah dibuat sebelumnya. 


80 

1. Narasi Use case registrasi 

Tabel 7.4 Narasi Use case Mengisi biodata 

Use case name 

Registrasi 

Use case Id 1 

Actor 

Description 

Pelapor 

Use Case ini menggambarkan kegiatan menginput biodata 

pelapoor sebelum menggunakan aplikasi ini 

Pre condition 

Trigger 

Aktor berada pada halaman registrasi akun 

Aktor input biodata kemudian klik register 

Typical course of 

Actor Action 

System Response 

events 

1. Membuka aplikasi 2. Menampilkan halaman 

register 

3. Masukkan biodata 

4.pilih register 

5. Validasi biodata 

6. Menampilkan halaman 

utama pengguna 

Alternate courses 

Alternatif no. 3 jika “biodata” ada yang salah isi maka akan 

diberi pemberitahuan isi no.3 lagi 

Conclusion 

Post condition 

Use case ini dibuat untuk masuk ke dalam sistem. 

Setelah validasi biodata benar sistem akan membuka 

halaman utama sesuai dengan level pengguna. 


81 

2. Narasi Use Case Login 

Tabel 7.5 Narasi Use Case Login 

Use case name 

Login 

Use case Id 2 

Actor 

Description 

Semua aktor 

Use Case ini menggambarkan kegiatan masuk kedalam 

sistem dengan data yang telah diregistrasi oleh Admin. 

Pre condition 

Trigger 

Pengguna sistem harus telah terdaftar di dalam sistem. 

Aktor input username dan password, kemudian klik login 


Actor Action 


events 

1. Membuka sistem 2. Menampilkan halaman 

login 

3. Masukkan “username” 

4. Masukkan “password” 

5. Pilih login 6. Validasi username dan 

password 




Alternatif no. 3 dan 4 jika username dan password tidak 

sesuai maka akan menampilkan pesan data salah dan 

diminta mengisi kembali no. 3 dan 4. 

Conclusion 



82 


Setelah validasi email dan password benar sistem akan 

membuka halaman utama sesuai dengan level pengguna. 

3. Narasi Use Case Pilih instansi 

Tabel 7.6 Narasi Use Case Pilih instansi 

Use case name 

Pilih instansi 

Use case Id 3 

Actor 

Description 

Pelapor 

Use Case ini menggambarkan kegiatan memilih instansi 

yang ingin dipilih oleh pelapor ketika telah masuk ke 

halaman utama 

Pre condition 

Trigger 

Aktor berada di halaman utama aplikasi 

Pengguna membuka halaman utama aplikasi 


events 

Actor Action 

1. Klik menu tab halaman 

utama 

3. Pilih instansi yang di 

inginkan 

5. Mengirim lokasi 



menu utama 

4. Menampilkan peta lokasi 

aktor 

6.mengirim lokasi dan 

berpindah ke layanan telpon 


83 


Alternatif kondisi signal jelek posisi keberadan aktor akan 

susah dikirim ke server,silahkan hubungi instansi lewat 

panggilan seluler 

Conclusion 

Use case ini dibuat untuk memfasilitasi pelapor untuk 

mengirim lokasi kejadian 


Setelah lokasi dikirim maka akan disimpan ke dalam 

Database. 

4. Narasi Use Case Informasi kejadian 

Tabel 7.7 Narasi Use Case Informasi kejadian 

Use case name 

Informasi kejadian 

Use case Id 4 

Actor 

Description 

server 

Use Case ini menggambarkan kegiatan menampilkan 

informasi kejadian 

Pre condition 

Trigger 

Pengguna server harus sudah login ke server 

Pengguna server membuka pemberithuan server 


Actor Action 


events 

1. Klik menu pemberitahuan 2. Menampilkan 


84 

pemberitahuan dari aplikasi 

3. Pilih pemberitahuan yang 

akan di respom 

4. Menampilkan informasi 

kejadian 

5. memilih petugas 

6. Menyimpan data ke dalam 

database 


Alternatif no. 6 pengguna klik tombol delete maka data 

tidak akan tersimpan dalam database. 

Conclusion 

Use case ini dibuat untuk memfasilitasi server mendapatkan 

informasi dari aplikasi 


Setelah informasi disimpan maka akan disimpan ke dalam 

Database. 

5. Narasi Use Case list route 

Tabel 7.8 Narasi Use Case list route 

Use case name 

list route 

Use case Id 5 

Actor 

Description 

petugas 

Use Case ini menggambarkan aktor melakukan kegiatan 

lihat rute terdekat menuju lokasi dengan menampilkan jarak 

dan waktu 


85 

Pre condition 

Trigger 

Petugas harus berada di halaman utama aplikasi petugas 

Pengguna membuka menu tab halaman utama 


Actor Action 


events 

1. Klik menu navigate 2. Mengkoneksikan ke API 

google maps untuk 

mendapatkan lalu lintas dan 

waktu terkini 

3. Mendapatkan data dari 

API google maps dalam 

bentuk JSON 

5. Mendapatkan pilihan 

route 


Alternatif jika API google maps down atau dalam gangguan 

maka pengambilan data akan gagal,silahkan coba lagi nanti 

Conclusion Use case ini dibuat untuk memfasilitasi petugas 

mendapatkan list route terdekat 


Petugas mendapatkan informasi rute menuju lokasi kejadian 


86 

6. Narasi Use Case tracking maps 

Tabel 7.8 Narasi Use Case tracking maps 

Use case name 

posisi petugas 

Use case Id 6 

Actor 

Description 

pelapor 

Use Case ini menggambarkan pelapor untuk melihat posisi 

kendaraan petugas 

Pre condition 

Trigger 

Pelapor harus masuk ke aplikasi 

Pengguna membuka menu tab kejadian 


Actor Action 


events 

1. Klik menu tab kejadian 2. Menampilkan list kejadian 

3. Pilih kejadian 4. Menampilkan posisi 

petugas di dalam tracking 

maps 


Alternatif no. 4 pilih sinyal yang bagus agar pemantauan 

posisi petugas dilihat dengan baik 

Conclusion 

Use case ini dibuat untuk memfasilitasi pelapor agar bisa 

melihat kendaraan petugas 


87 


Pelapor mendapatkann posisi kendaraan petugas 

7. Narasi Use Case registrasi 

Tabel 7.9 Narasi Use Case registrasi 

Use case name 

Mengisi biodata 

Use case Id 7 

Actor 

Description 

petugas 

Use Case ini menggambarkan kegiatan menginput biodata 

petugas sebelum menggunakan aplikasi ini 

Pre condition 

Trigger 

Aktor berada pada halaman registrasi akun 

Aktor input biodata kemudian klik register 


Actor Action 


events 

1. Membuka aplikasi 2. Menampilkan halaman 

register 

3. Masukkan biodata 

4.pilih register 

5. Validasi biodata 




Alternatif no. 3 jika “biodata” ada yang salah isi maka akan 

diberi pemberitahuan isi no.3 lagi 

Conclusion 



88 


Setelah validasi biodata benar sistem akan membuka 

halaman utama sesuai dengan level pengguna. 

8. Narasi Use Case Memilih instansi gawat darurat 

Tabel 7.10 Narasi Use Case Memilih instansi gawat darurat 

Use case name 

Pilih instansi 

Use case Id 8 

Actor 

Description 

server 

Use Case ini menggambarkan kegiatan memilih instansi 

yang ingin dipilih oleh server ketika pelapor memilih 

instansi yang di butuhkan lewat aplikasi pelapor 

Pre condition 

Trigger 

pengguna berada di list menu agency 

Pengguna membuka list menu 


Actor Action 


events 

1. Klik list menu agency 2. Menampilkan instansi 

3. Pilih instansi 4.mengirim lokasi dan 

deskripsi kejadian kepada 

aplikasi petugas yang dipilih 


89 


Alternatif instansi yang dipilih telah di pakai maka akan di 

cari instansi terdekat lagi dari lokasi kejadian 

Conclusion 

Use case ini dibuat untuk memfasilitasi server untuk 

memilih instansi yang dibutuhkan pelapor 


Setelah lokasi kejadian dikirim ke aplikasi petugas maka 

akan disimpan ke dalam Database. 

9. Narasi Use Case Informasi kejadian 

Tabel 7.11 Narasi Use Case Informasi kejadian 

Use case name 

Informasi kejadian 

Use case Id 9 

Actor 

Description 

petugas 

Use Case ini menggambarkan kegiatan menampilkan 

informasi kejadian di aplikasi petugas 

Pre condition 

Trigger 

Pengguna aplikasi petugas harus sudah login 

Pengguna membuka menu tab kejadian 

Typical course 

Actor Action 


of events 

1. Klik menu tab 2. Menampilkan pemberitahuan 


90 

kejadian 

3. Pilih pemberitahuan 

yang akan di respom 

dari server 

4. Menampilkan 

informasi/deskripsikejadian 

5. memilih klik tombol 

berangkat 

Alternate 

courses 

Alternatif no. 5 informasi berangkat tidak terkirim keserver 

maka petugas mengulang klik tombol berangkat lagi 

Conclusion Use case ini dibuat untuk memfasilitasi petugas 

mendapatkan informasi dari server 


Setelah informasi disimpan maka akan disimpan ke dalam 

Database. 


91 

4.2.2.2 Activity Diagram 

1. Activity Diagram registrasi 

Gambar 7.4 Activity Diagram registrasi 

Dalam aktifitas ini Aktor membuka aplikasi emergency call dan 

menginput biodata pelapor sebelum menggunakan aplikasi ini, kemudian server 

akan menyimpan biodata dalam database 


92 

2. Activity Diagram Login 

Gambar 7.5 Activity Diagram Login 

menjelaskan aktifitas dari use case login. Aktor membuka 

aplikasi sistem, kemudian sistem akan menampilkan halaman login, kemudian 

aktor memasukkan username dan password. Jika username dan password yang 

dimasukkan salah, maka sistem akan menampilkan pesan gagal dan jika benar, 

maka akan masuk ke menu utama 


93 

3. Activity Diagram pilih instansi 

Gambar 7.6 Activity Diagram pilih instansi 

Dalam aktifitasini aktor memilih instansi di aplikasi emergency call kemudian 

pelapor mengirim lokasi kejadian kemudian di server akan mencarikan instasi 

terdekat dari lokasi pelapor setalah itu server memilih petugas dan data dikirim ke 

aplikasi petugas sehingga petugas mendapatkan laporan kejadian setalah di 

konfrimasi maka pelapor akan mendapatkan notifikasi keberangkatan petugas 


94 

4. Activity Diagram list opsi route 

Gambar 7.7 Activity Diagram list opsi route 

Dalam aktivitas ini petugas berada pada halaman info kejadian. Setelah 

pelapor memilih keberangkatan, sistem akan memanggil API Google maps dan 

menampilkan pilihan rute perjalanan dengan jarak dan waktu yang berbeda. 


95 

5. Activity Diagram lihat posisi petugas 

Gambar 7.8 Activity Diagram lihat posisi petugas 

Dalam 

aktifitas ini petugas mengkonfrimasi keberangkata dan server 

mendapatkan konfrimasi ,kemudian pelapor mendapatkan notifikasi dari server 

bahwa petugas menuju lokasi kejadia kemudian pelapor membuka aplikasi 

emergency call dan membuka menu tab list kejadian dan mengklik kejadian 

setelah itu pelapor dapat melakukan monitoring keberdaan petugas 


96 

4.2.2.3 Perancangan Sequence Diagram 

Sequence diagram merupakan diagram interaksi yang dinyatakan 

dengan waktu, atau dapat disebut dengan diagram dari atas ke bawah. 

Setiap sequence diagram menyatakan salah satu dari beberapa aliran yang 

memulai sebuah Use Case. 

a. Sequence Diagram registrasi 

Gambar 7.9 Sequence Diagram mengisi biodata 

Alur ini menjelaskan proses pengguna Aplikasi Emergency Call melakukan 

pengisian biodata. Ketika pengguna Aplikasi Emergency Call mengisi biodata 

server akan menyimpan biodata dan menampilkan di menu profil 


97 

b. Sequence Diagram login 

Gambar 7.10 Sequence Diagram login 

Alur ini menjelaskan proses pengguna/aktor untuk mengisi username dan 

password,yang mana pengguna/aktor setelah mengisi username dan password 

dengan benar akan masuk ke menu utama aplikasi 


98 

c. Sequence Diagram pilih instansi 

aplikasi EM 

server 

aplikasi Petugas 

pelapor 

pilih instansi(); 

mengirim pilihan instansi(); 

memilih instansi(); 

mengirim data(); 

mengkonfrimasi (); 

tampil kejadian(); 

Gambar 7.11 Sequence Diagram memilih instansi gawat darurat 

Alur Ini menggambarkan proses untuk memilih instansi gawat darurat 

yang mana pengguna aplikasi Emergency Call akan memilih Instansi gawat 

darurat dan pilihan itu akan dikirim oleh server ke aplikasi petugas kemudian 

aplikasi petugas mengkonfirmasi keberangkatan kepada server dan server akan 

mengirim data konfrimasi keberangkatan petugas 


99 

d. Sequence Diagramt list opsi route 

aplikasi petugas 

Google Maps API 

petugas 

berangkat(); 

GetLocationRoute(); 

ShowOptRoute(); 

Gambar 7.12 Sequence Diagram lihat list opsi route 

Alur ini menggambarkan proses untuk menampilkan opsi jalur petugas 

untuk menuju lokasi kejadian dengan bantuan google maps API memanfaatkan 

Crowdsource nya. Pada saat petugas menekan tombol berangkat pada aplikasi 

petugas maka data lokasi menuju kejadian tampil sesuai dengan kondisi lalin 

terkini dari google maps API. 


100 

e. Sequence Diagram lihat posisi petugas 

aplikasi EM 

Maps Tracking 

pelapor 

ListKejadian(); 

GetRoute(); 

ShowPosition(); 

Gambar 7.13 Sequence Diagram lihat posisi petugas 

Alur ini mengambarkan proses untuk menampilkan keberadaan posisi 

petugas dengan tools maps tracking di mana pelapor dapat melihat keberadaan 

petugas dengan masuk kemenu kejadian. 


101 

4.2.2.4 Perancangan Class Diagram 

Class diagram mendeskripsikan struktur objek pada sistem seperti kelas 

objek dan hubungan antar kelas objek tersebut. Berikut adalah class diagram 

aplikasi: 

Gambar 7.14 Class Diagram 

Gambar di atas adalah gambar diagram kelas yang berada pada aplikasi 

Emergency Call untuk list opsi rute dan detail rute tidak menggunakan database 

karena datanya langsung diambil dari Server API Waze. 


102 

7.2.2 Perancangan User Interface 

Perancangan ini diperlukan untuk mengetahui seperti apa bentuk tampilan 

yang akan dikerjakan pada aplikasi. Penulis menggunakan software Balsamiq 

Mockups dalam melakukan perancangan antarmuka sebagai berikut: 

4.2.3.1 Tampilan Menu login 

Gambar 7.15 Rancangan tampilan menu login 

Gambar ini merupakan rancangan tampilan login aplikasi emergency call 

buat pelapor untuk masuk ke dalam sistem. 

Halaman ini terdapat pengisian email,password,button login, dan button 

daftar berfungsi untuk mengisi biodata pelapor yang belum membuat akun. 


103 

4.2.3.2 Tampilan Menu daftar 

Gambar 7.16 Rancangan tampilan menu daftar 

Gambar ini merupakan rancang tampilan yang menampilkan pengisian 

nama,emai,no telepon,password,ulangi password,alamat dan ktp berfungsi untuk 

data-data pelapor yang akan dikirim dan disimpan di server 


104 

4.2.3.3 Tampilan Menu home 

Gambar 7.17 Rancangan tampilan menu home 

Gambar ini merupakan rancangan tampilan menu home, yang berisi 4 panic 

button diantaranya polisi, kebakaran, ambulance, KDRT, apabila pelapor 

memilih salah satu panic button akan langsung masuk keamanan selanjutnya. 


105 

4.2.3.4 Tampilan Menu kirim lokasi 

Gambar 7.18 Rancangan tampilan menu kirim lokasi 

Gambar ini merupakan Perancang tampilan yang menampilkan icon 

kamera yang berfungsi untuk mengirim gambar kejadian dan button kirim yang 

berfungsi untuk mengirim lokasi kejadian secara langsung akan berpindah ke 

panggilan seluler. 


106 

4.2.3.5 Tampilan Menu kejadian 

Gambar 7.19 Rancangan tampilan menu kejadian 

Gambar ini merupakan rancangan tampilan yang menampilkan daftar 

kejadian yang user laporkan kepada server . 


107 

4.2.3.6 Tampilan Menu tracking 

Gambar 7.20 Rancangan tampilan menu tracking 

Gambar ini merupakan rancangan tampilan yang menampilkan posisi 

keberadaan petugas ketika pelapor telah menerima konfrimasi tentang 

keberangkatan petugas. 


108 

4.2.3.7 Tampilan Menu login aplikasi petugas 

Gambar 7.21 Rancangan tampilan menu login aplikasi petugas 

Gambar ini merupakan rancangan tampilan yang menampilkan halaman 

login buat aplikasi petugas, Di sini terdapat from username, Password, ganti 

Instansi dan kemudian Button log in 


109 

4.2.3.8 Tampilan Menu kejadian aplikasi petugas 

Gambar 7.22 Rancangan tampilan menu kejadian aplikasi petugas 

Gambar ini merupakan rancangan tampilan yang menampilkan kejadian 

yang dikirim oleh server kepada petugas ketika petugas mendapat notifikasi. Di 

halaman ini terdapat posisi petugas,posisi kejadian, deskripsi kejadian dan button 

berangkat untuk mengkonfirmasi keberangkatan petugas ia akan dikirim ke 

server dan server akan mengirim kepada aplikasi pelapor 


110 

4.2.3.8 Tampilan Menu route aplikasi petugas 

Gambar 7.23 Rancangan tampilan menu route aplikasi petugas 

Gambar ini merupakan rancangan tampilan yang menampilkan rute dari 

data google maps API. Halaman ini akan menampil rute rute jalan dengan waktu 

dan jarak tempuh. 


111 


BAB V 

HASIL DAN PEMBAHASAN 

8.1 Implementasi 

Sebelum sistem diimplementasikan, aplikasi harus terbebas dari 

kesalahan-kesalahan program yang mungkin terjadi seperti kesalahan 

penulisan kode, kesalahan proses, logika atau kesalahan sintaks. 

Pada bagian ini penulis akan menjelaskan alur kerja pembuatan 

program yang terdiri dari pengodean (coding) aplikasi dan pengujian 

aplikasi dengan metode Blackbox yang terdiri dari pengujian 

fungsionalitas aplikasi dan pengujian jalannya Fitur Crowdsource. 

Tidak lupa penulis juga meng-input-kan data ke dalam database secara 

manual dan dilanjutkan dengan pengunggahan seluruh source code 

program ke Server hosting agar bisa diakses oleh semua orang. 

8.1.1 Aplikasi Emergency Call 

1. Tampilan Login Pelapor 

Gambar 8.1 Gambar tampilan menu login 

Gambar ini merupakan rancangan tampilan login aplikasi emergency call 

buat pelapor untuk masuk ke dalam sistem. 

Halaman ini terdapat pengisian email,password,button login, dan button 

daftar berfungsi untuk mengisi biodata pelapor yang belum membuat akun. 

112

113 

2. Tampilan Daftar akun Pelapor 

Gambar 8.2 Tampilan menu daftar 

Gambar ini merupakan rancang tampilan yang menampilkan pengisian 

nama,emai,no telepon,password,ulangi password,alamat dan ktp berfungsi untuk 

data-data pelapor yang akan dikirim dan disimpan di server 


114 

3. Tampilan Menu Utama Pelapor 

Gambar 8.3 Tampilan menu home 

Gambar ini merupakan rancangan tampilan menu home, yang berisi 

4 panic button diantaranya polisi, kebakaran, ambulance, KDRT, apabila 

pelapor memilih salah satu panic button akan langsung masuk keamanan 

selanjutnya 


115 

4. Tampilan Menu Kejadian Pelapor 

Gambar 8.4 Tampilan menu kejadian 

Gambar ini merupakan rancangan tampilan yang menampilkan daftar 

kejadian yang user laporkan kepada server . 


116 

5. Tampilan Menu Kirim Lokasi kejadian 

Gambar 8.5 Tampilan menu kirim lokasi 

Gambar ini merupakan Perancang tampilan yang menampilkan icon 

kamera yang berfungsi untuk mengirim gambar kejadian dan button kirim 

yang berfungsi untuk mengirim lokasi kejadian secara langsung akan 

berpindah ke panggilan seluler 


117 

6. Tampilan nomor telepon 

Gambar 8.6 Menu telepon 

Gambar ini merupakan tampilan ketika user telah mengirim lokasi 

dan secara otomatis akan masuk ke menu nomor telepon 


118 

7. Tampilan Menu Profil Pelapor 

Gambar 8.7 Tampilan menu login aplikasi petugas 



Instansi dan kemudian Button log in. 


119 

8. Tampilan Tracking 

Gambar 8.8 Rancangan tampilan menu tracking 

Gambar ini merupakan rancangan tampilan yang menampilkan 

posisi keberadaan petugas ketika pelapor telah menerima konfrimasi 

tentang keberangkatan petugas 


120 

9. Tampilan Login petugas 

Gambar 8.9 Tampilan menu login aplikasi petugas 



Instansi dan kemudian Button log in 


121 

10. TampilanMenu Kejadian petugas 

Gambar 8.10 Tampilan menu kejadian aplikasi petugas 

Gambar ini merupakan rancangan tampilan yang menampilkan kejadian 

yang dikirim oleh server kepada petugas ketika petugas mendapat notifikasi. Di 

halaman ini terdapat posisi petugas,posisi kejadian, deskripsi kejadian dan button 

berangkat untuk mengkonfirmasi keberangkatan petugas ia akan dikirim ke 

server dan server akan mengirim kepada aplikasi pelapor 


122 

11. Tampilan Menu route aplikasi petugas 

Gambar 8.11 tampilan menu route aplikasi petugas 

Gambar ini merupakan rancangan tampilan yang menampilkan rute dari 

data google maps API. Halaman ini akan menampil rute rute jalan dengan waktu 

dan jarak tempuh. 

8.1.2 Pembuatan kode program 

Pada tahap ini penulis melakukan pengodean sistem setelah perancangan 

pada tahap sebelumnya dilaksanakan. Penulis menggunakan bahasa pemrograman 

PHP dengan bantuan framework CodeIgniter untuk sisi Coding internal dan 

java,XML untuk sisi tampilan User Interface, database yang digunakan adalah 

MySQL, dan JSON untuk menarik (retrieve) data dari Google Maps API. Penulis 

menggunakan perangkat lunak Android Studio untuk melakukan pengodean 

aplikasi ini karena aplikasi ini tergolong ringan atau tidak terlalu memberatkan 

sistem komputer penulis. Sebelum sistem diimplementasikan, aplikasi harus 


123 

terbebas dari kesalahan-kesalahan program yang mungkin terjadi seperti 

kesalahan penulisan kode, kesalahan proses, logika atau kesalahan sintaks. 

Pada bagian ini penulis akan menjelaskan alur kerja pembuatan program 

yang terdiri dari pengodean (coding) aplikasi dan pengujian aplikasi dengan 

metode Blackbox yang terdiri dari pengujian fungsionalitas aplikasi dan pengujian 

jalannya Fitur Crowdsource. Tidak lupa penulis juga meng-input-kan data hotel 

ke dalam database secara manual dan dilanjutkan dengan pengunggahan seluruh 

source code program ke Server hosting agar bisa diakses oleh semua orang. 

8.1.3 Server 

Melakukan implementasi aplikasi ke server hosting beserta database yang 

telah dibuat. Semua data di hosting melalui layanan hosting 

www.dapurhosting.com. Untuk mengakses aplikasinya Emergency Call ini, 

pengguna dapat membuka dengan ponsel atau smartphone pengguna yang dapat 

mengakses internet. 

8.2 Pengujian Aplikasi (Blackbox Testing) 

Selanjutnya, penulis melakukan pengujian terhadap aplikasi yang telah 

dibuat dengan pengujian Blackbox. 

8.2.1 Pengujian Fungsionalitas Aplikasi 

Uji coba fungsionalitas dilakukan dengan cara menjalankan aplikasi yang 

telah dibuat, dan melakukan pengujian fungsi- fungsi fitur dari aplikasi untuk 

melihat apakah sudah berjalan sesuai yang diinginkan atau sebaliknya. 

Tabel 8.1 Pengujian Fungsionalitas Aplikasi 

No Item uji Kegiatan Hasil yang 

diharapkan 

1 Halaman Menampilkan Halaman 

login login aplikasi login 

aplikasi emergency call aplikasi 

emergenc 

ditampilkan 

Hasil 

aktual 

Sesuai 

Rujukan 

Gambar 


124 

y call 

2 Halaman 

Menampilkan 

Halaman 

sesuai 

Gambar 

daftar 

list 

kolom 

daftar 

aplikasi 

untuk 

mengisi 

aplikasi 

emergenc 

biodata 

pada 

ditampilkan 

y call 

aplikasi 


3 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

home 

halaman home 

home 

aplikasi 

yang 

berisi 

aplikasi 

emergenc 

panic 

button 

ditampilkan 

y call 

pada 

aplikasi 


4 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

kejadian 

halaman 

kejadian 

aplikasi 

kejadian 

yang 

aplikasi 

emergenc 

berisi 

list 

ditampilkan 

y call 

kejadian 

pada 

aplikasi 


5 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

tracking 

halaman 

tracking 

aplikasi 

tracking 

yang 

aplikasi 

emergenc 

berisi 

tracking 

ditampilkan 

y call 

maps 

pada 

aplikasi 


6 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

kirim 

halaman kirim 

kirim lokasi 

lokasi 

lokasi 

yang 

aplikasi 


125 

aplikasi 

berisi 

share 

ditampilkan 

emergenc 

location 

pada 

y call 

aplikasi 


7 Halaman 

Menamppilkan 

Halaman 

sesuai 

Ga 

profil user 

halaman profil 

profil 

mbar 

aplikasi 

user yang berisi 

aplikasi 

emergenc 

biodata 

pada 

ditampilkan 

y call 

aplikasi 


8 Halaman 

Menamppilkan 

Halaman 

sesuai 

Ga 

login 

halaman 

login 

login 

mbar 

aplikasi 

petugas 

yang 

aplikasi 

petugas 

berisi 

ditampilkan 

username,passw 

ord dan pilih 

instansi 

pada 


9 Halaman 

Menamppilkan 

Halaman 

Sesuai 

Ga 

profil 

halaman profil 

profil 

mbar 

aplikasi 

petugas 

yang 

aplikasi 

petugas 

berisi 

biodata 

ditampilkan 

dan 

foto 

petugas 

pada 


10 Halaman 

Menamppilkan 

Halaman 

Sesuai 

Gambar 

edit profil 

halaman 

edit 

edit 

profil 

aplikasi 

profil 

petugas 

aplikasi 

petugas 

yang 

berisi 

ditampilkan 

biodata dan foto 


126 

petugas 

pada 


11 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

kejadian 

halaman 

kejadian 

aplikasi 

kejadian 

yang 

aplikasi 

petugas 

berisi kejadian 

ditampilkan 

yang dilaporkan 

user 

pada 

aplikasi 


12 Halaman 

Menamppilkan 

Halaman 

sesuai 

Gambar 

list route 

pilihan 

rute 

list 

route 

aplikasi 

menuju 

lokasi 

aplikasi 

petugas 

kejadian dengan 

ditampilkan 

menampilkan 

jarak dan waktu 

tempuh 

8.2.2 Kesimpulan Hasil Pengujian Blackbox 

Berdasarkan hasil pengujian dengan kasus sampel uji yang telah dilakukan, 

dapat disimpulkan bahwa secara fungsional sistem dapat menghasilkan output 

sesuai yang diharapkan. 

8.3 Pengujian Data Estimasi Waktu Tempuh 

Pengujian ini dilakukan untuk membuktikan ketepatan atau keakuratan data 

Crowdsource yang dihasilkan. Pada pengujian ini, Penulis menggunakan metode 

pengujian Modeling dan Simulation dari (Maria, 1997). 


127 

8.4 Simulation Model 

berikut ini adalah gambar alur scenario pengujian pada tahap pengujian data 

Estimasi waktu tempuh. 

mulai 

system under study 

case A: 

(hasil aplikasi/ 

data google maps ) 

case B: 

(perhitungan manual) 

sistem request 

data 

simulation 

model 

data 

tampil 

simulation 

experiment 

data hasil 

simulation analysis 

membandingkan 

data 

Analisis data 

(Uji Hipotesis) 

conclusions 

selesai 

Gambar 8.12 Alur skenario Pengujian Estimasi Waktu Tempuh 


128 

Berikut ini adalah gambar alur pengujian data Estimasi Waktu Tempuh 

pada tahap Simulation Model 

Gambar 8.13 Alur kerangka perhitungan manual tahap Simulation Model 

a) Merumuskan Masalah 

Penulis memakai dua kasus skenario (Case) A untuk data yang didapatkan 

dari aplikasi dan skenario B untuk data hasil perhitungan manual (menggunakan 


129 

Rumus 2.1 Persamaan Estimasi Waktu Tempuh). Lihat alur skenario pengujian 

data pada Gambar 3.2 Alur Skenario Pengujian Estimasi Waktu Tempuh. 

Untuk keperluan simulasi, penulis menggunakan data berikut: 

Tabel 8.2 Informasi Pengujian 

Titik Observasi awal: 

Polsek kebayoran lama ,jalan 

Praja II No.1, RT 05 / RW 01, 

Kebayoran Lama Selatan, 

Kebayoran Lama, RT.5/RW.1, 

Kby. Lama Sel., Kby. Lama, 

Kota Jakarta Selatan, Daerah 

Khusus Ibukota Jakarta 

Titik Observasi tujuan: 

Gandaria city 

Waktu: 

Morning Peak(7.00-9.00), Off- 

Peak (12.00-15.00) 

dan Evening Peak(16.00-21) 

(merujuk ke pembahasan 

pada Sub Time 

Elements) 

Untuk Facility Types (lihat Subbab b Facility Types), Penulis memilih ruas 

Jalan Jln.iskandar muda sebagai area pengujian karena merupakan salah satu jalan 

arteri di Jakarta selatan). Penulis menggunakan kendaraan roda empat (mobil) 

untuk penelitian ini . Penulis menghitung yaitu waktu tempuh dengan kemacetan. 

proporsi kendaraan arah ke Gandaria City untuk ruas jalan iskandar muda lebih 

didominasi oleh mobil (78% dari total kendaraan). 


130 

Untuk arus menuju arah Gandaria City lebih fluktuatif pada jam-jam 

tertentu khususnya pada jam kerja dan jam istirahat. Maka dari itu, Penulis 

menggunakan Periode Time Elements dan mengambil sampel waktu penelitian 

untuk Morning Peak antara 

b) Merumuskan dan Mengembangkan Model 

Kemudian dari alur skenario pengujian data, metode pengujian perhitungan 

data pada tahap ini dikembangkan lebih lanjut. Alur Kerangka Perhitungan 

Manual Tahap Simulation Model. 

8.4.1 Simulation Experiment 

a) Membangun Kondisi Percobaan Untuk Dijalankan 

Penulis akan melakukan 3 (tiga) kali Observasi (Run) pada setiap Periode 

Waktu dengan mencacat Running Time (dalam detik) dan Stopped Delay Time 

(dalam detik. Kemudian dari catatan itu akan dihitung Estimasi Waktu Tempuh 

sesuai dengan Alur pada Gambar 5.2 Alur Kerangka Perhitungan Manual. 

b) Melakukan Simulasi 

Pada tahap ini dilakukan simulasi seperti yang sudah dijelaskan pada tahap 

(Simulation Experiment point) di atas. 

8.4.2 Simulation Analysis 

a) Menginterpretasikan dan Menampilkan Hasil 

1. Perhitungan Case A (Data Aplikasi/Google Maps ) 

Berikut ini adalah hasil pengambilan data pada aplikasi dengan waktu 

Morning Peak, Off-Peak dan Evening Peak. 

Tabel 8.3 Data Waktu Tempuh Aplikasi Emergency Call menggunakan 

Crowdsource google maps API. 

Aplikasi Emergency call 

No Periode 

menggunakan Crowdsource 

google maps API (menit) 

1 Morning Peak 07:00 7 menit 

2 Off-Peak 06:00 6 menit 

3 Evening Peak 09:00 9 menit 


131 

2. Perhitungan Case B (Data Hasil Perhitungan) 

Untuk setiap periode waktu, penulis melakukan 3 kali observasi/jalan/run 

dari titik awal menuju titik tujuan (lihat Tabel 5.2 Informasi Pengujian). 

Informasi tentang tabel : 

Travel Time (sec) (t ri ) = hitungan waktu tempuh perjalan tanpa dikurangin 

stopped delay time 

Running Time (sec) = hitungan waktu tempuh perjalan dengan dikurangin 


stopped delay time (sec) = waktu lama berhenti kendaraan 

Average Travel Speed (km/h) = kecepatan rata-rata kendaraan pada saat 

berjalan disertai kemacetan/delay time 

Dimana: 



t i = waktu tempuh 


d 

∑ t i 

x 3600 (sec) 

Average Running Speed (km/h) = kecepatan rata-rata kendaraan pada saat 

berjalan tanpa disertai kemacetan/delay time 


d 

∑ t ri 

x 3600 (sec) 

Dimana: 




Section Length (in km) (d) = Panjang rute 

Number of Observations (n) = banyak observasi 


132 

a. Perhitungan Data Morning Peak 

Run 

Run 

Run 

Su 

Avera 

Data Items 

Var 

1 

2 

3 

m 

ge 

Travel Time (sec) t i 370 375 381 1126 375,3 

Running Time (sec) t ri 328 342 346 1016 338,7 

Stopped Delay Time 

(sec) 42 33 35 110 36,7 

Average Travel Speed 

(km/h) 

Average Running Speed 

χ 12,6 12,5 12,3 37,4 12,4 

(km/h) 14,2 13,7 12,3 - 13,8 

Section Length (in km) 

(d) 

D 

1,3 

Number of Observations 

(n) 

N 3 


133 

penjelasan tabel morning-peak dengan waktu uji coba dari jam 8.00-10.00 

wib 

 

Hasil dari Travel Time (sec) run 1 : 370 detik , run 2 : 375 detik dan 

run 3 : 381 detik merupakan hasil percobaan perjalanan dari polsek 

kebayoran lama menuju gandaria city di jam 8.00-10.00 

menggunakan stopwatch untuk menghitung waktu dan 

menggunakan mobil sebagai kendaraan 

Running Time (sec) run 1 : 328 detik , run 2 : 342 detik dan run 3 : 

346 detik merupakan hasil percobaan perjalanan dari polsek 



menggunakan mobil sebagai kendaraan dengan tanpa menghitung 


 

Stopped Delay Time (sec) run 1 : 42 detik , run 2 : 33 detik dan run 

3 : 35 detik merupakan hasil percobaan berapa waktu lama berhenti 

di perjalanan dari polsek kebayoran lama menuju gandaria city di 

jam 8.00-10.00 menggunakan stopwatch untuk menghitung waktu 

dan menggunakan mobil sebagai kendaraan 

Average Travel Speed (km/h) ) 





run 1 = 

run 2 = 

run 3 = 

1,3 km 

370 

1,3 km 

375 

1,3 km 

381 

× 3600 = 12,6 km/h 

× 3600 = 12,5 km/h 

× 3600 = 12,3 km/h 

d 

∑ t i 

x 3600 (sec) 


134 




d 

∑ t ri 

x 3600 (sec) 

Dimana: 




run 1 = 

run 2 = 

run 3 = 

1,3 km 

328 

1,3 km 

328 

1,3 km 

346 

× 3600 = 14,2 km/h 

× 3600 = 13,7 km/h 

× 3600 = 12,3 km/h 

Section Length (in km) (d) = Panjang rute dari polsek kebayoran lama menuju 

gandaria city dengan penyesuian dengan rute yang ada di google maps 



135 

Hasil Perhitungan Estimasi Waktu Tempuh pada Morning Peak: 

1. Hitungan Space-Mean dengan tahap berikut : 

nx d 

∑t i 

= ẍ 




= 

3 x 1,3 km/h 

1126 detik 

= 0,0034km/sec 

= 12,5 km 

jam 

2. Hitungan variansi sample dari space-man dengan tahapan sebagi 

berikut : 

∑(x − ẍ )2 

SD = √ 

(n − 1) 


ẍ = hasil space − mean 


√(12,6km/h − 12,5km/h ) 2 + (12,5km/h − 12,5km/h) 2 +(12,3km/h − 12,5km/h) 2 

= 

3 − 1 

√(0,2km/h ) 2 + (0,1km/h ) 2 +(−0,1) 2 

= 

2km/h 

√0,04 + 0,01 + 0,01 

2 

= 


136 

√0,06 

2 

= 

√0,03 = 0,17 

SD 2 = 0,17 

Varians = SD 2 

Varians =0,3 

S 2 sms = 0,3 

3. Hitungan Time-Mean Speed dengan tahapan berikut : 

υ̅TMS = υ̅SMS + 

S 2 

̅̅̅̅̅̅̅̅ υ̅SMS 




12,5km/h + 

0,3 

12,5km/h = 

12,5km/h + 0,024 = 

12,74 km/h 


137 

4. Hitungan Estimated Travel Time dengan tahapan berikut : 

= 




= 1,3 x 3600 detik/jam 

12,74 

= 367,3 detik 

= 6 menit 7 detik 

b. Perhitungan Data Off-Peak 

Run 

Run 

Run 

Su 

Avera 

Data Items 

Var 

1 

2 

3 

m 

ge 




(sec) 35 37 32 104 34,6 


(km/h) 


14,6 14 13,7 42,3 14,1 

(km/h) 16,4 15,7 15,2 - 15,7 


(d) D 1,3 


138 


(n) 

N 3 

penjelasan tabelData off-peak dengan waktu uji coba dari jam 12.00-15.00 

wib 

 












 











run 1 = 

1,3 km 

320 

× 3600 = 14,6 km/h 

d 

∑ t i 

x 3600 (sec) 


139 

run 2 = 

run 3 = 

1,3 km 

335 

1,3 km 

340 

× 3600 = 14 km/h 

× 3600 = 13,7 km/h 




d 

∑ t ri 

x 3600 (sec) 

Dimana: 




run 1 = 

run 2 = 

run 3 = 

1,3 km 

285 

1,3 km 

298 

1,3 km 

308 

× 3600 = 16,4 km/h 

× 3600 = 15,7 km/h 

× 3600 = 15,2 km/h 





140 

Hasil Perhitungan Estimasi Waktu Tempuh pada Data Off-Peak: 


nx d 

= 

∑t i 




= 

3 x 1,3 

995 

= 0,004km/sec 

= 14,4 km/jam 


berikut : 

∑(x − ẍ )2 

SD = √ 

(n − 1) 




√(14,6 − 14,1) 2 + (14 − 14,1) 2 +(13,7 − 14,1) 2 

= 

3 − 1 

√(0,5) 2 + (0,1) 2 +(−0,4) 2 

= 

2 

√0,25 + 0,01 + 0,16 

2 

= 


141 

√0,42 

2 

= 

√0,21 = 0,46 


Varians = 0,46 2 

Varians =0,21 

S 2 sms = 0,21 



S 2 

̅̅̅̅̅̅̅̅ υ̅SMS 




14,4 + 0,21 

14,4 = 

14,4 + 0,014 = 

14,4 km/jam 





= 1,3 

14,4 

x 3600 detik/jam 


142 

= 325detik 


c. Perhitungan Data Evening-Peak 

Run 

Run 

Run 

Su 

Avera 

Data Items 

Var 

1 

2 

3 

m 

ge 




(sec) 81 76 77 234 78 


(km/h) 


8,8 8,85 8,9 26,5 8,85 

(km/h) 10,3 10,33 10,4 - 10,37 


(d) 

D 

1,3 


(n) 

N 3 


143 

penjelasan tabel evening-peak dengan waktu uji coba dari jam 18.00-21.00 

wib 

 












 











run 1 = 

1,3 km 

532 

× 3600 = 8,8 km/h 

d 

∑ t i 

x 3600 (sec) 

run 2 = 

run 3 = 

1,3 km 

529 

1,3 km 

527 

× 3600 = 8,85 km/h 

× 3600 = 8,9 km/h 


144 




d 

∑ t ri 

x 3600 (sec) 

Dimana: 




run 1 = 

run 2 = 

run 3 = 

1,3 km 

451 

1,3 km 

453 

1,3 km 

450 

× 3600 = 10,3 km/h 

× 3600 = 10,33 km/h 

× 3600 = 10,4 km/h 





145 

d. Hasil Perhitungan Estimasi Waktu Tempuh pada Evening-Peak: 



nx d 

= 

∑t i 


t i = waktu tempuh kendaraan ke − i = 

= 8,84km/sec 

= 8,84 km/jam 

3 x 1,3 

1588 


berikut : 

∑(x − ẍ )2 

SD = √ 

(n − 1) 




√(8,8 − 8,85) 2 + (8,85 − 8,85) 2 +(8,9 − 8,85) 2 

= 

3 − 1 

√(−0,005) 2 + (0) 2 +(0,005) 2 

= 

2 

√0,0025 + 0 + 0,0025 

2 

= 

√0,005 

2 

= 


146 

√0,0025 = 0,05 


Varians = 0,05 2 

Varians =0,0025 

S 2 sms = 0,0025 



S 2 

̅̅̅̅̅̅̅̅ υ̅SMS 




8,4 + 0,0025 

8,4 

= 

8,4 + 0,0003 = 

8,843 km/jam 


147 





= 1,3 x 3600 detik/jam 

8,843 

= 529,23detik 


Keterangan: 

Travel Time adalah Running Time ditambah Stopped Delay Time 

untuk setiap Run/Observasi. 

Running Time adalah waktu pada saat kendaraan 

bergerak/berjalan. 

Stopped Delay Time adalah waktu pada saat kendaraan 

berhenti/macet (kecepatan < 8 km/jam). 

Average Travel Speed adalah kecepatan rata-rata kendaraan dalam 

satu kali perjalanan (termasuk Stopped Delay Time). 

Average Running Speed adalah kecepatan rata-rata lajunya 

kendaraan (tanpa Stopped Delay Time). Dihitung dengan Rumus 

2.4. 

Section Length adalah jarak tempuh kendaraan untuk setiap 

observasi (dalam kilometer). 

Number of Observations adalah jumlah observasi total dalam 

setiap periode waktu. 

Run 1 – 3 adalah percobaan observasi/jalan pertama, kedua dan 

ketiga. 

Sum adalah jumlah seluruh observasi (Run 1 – 3). 

Average adalah Total rata-rata tiap observasi. 


148 

 

 

 

 

Variance adalah nilai variansi nilai untuk Average Travel Speed. 

Time-Mean Speed adalah jumlah semua Run pada Average Travel 

Speed dibagi total observasi (lihat Rumus 2.2). 

Space-Mean Speed adalah total observasi dikali panjang ruas jalan 

(section length) dibagi jumlah semua Run pada Travel Time. (lihat 

Rumus 2.3) 

TT (mm:ss) adalah Travel Time dalam format menit:detik. 

Tabel 8.4 Hasil Observasi Semua Time Element 

Average Speed 

Time- Estimated Travel 

Hasil (km/h) 

Space-Mean Mean Time 

Time 

Elements Run Travel Speed (km/h) 

Speed 

(km/h) minutes mm:ss 

Morning 

Peak 13,8 12,4 12,5 12,74 367,3 6:07 

Off-Peak 15,7 14,1 14,4 14,4 325 5:25 

Evening 

Peak 10,37 8,85 8,84 8,843 529,23 8:49 

3. Uji Hipotesis T-Test 

Setelah didapatkan data masing-masing output baik dari Case A maupun 

Case B, kemudian dilakukan perbandingan dengan analisis data menggunakan 

analisis statistik Uji Hipotesis T-test.Berikut ini adalah tabel dari pengujian Case 

A dan Case B. 


149 

Tabel 8.5 Hasil Perhitungan Case A dan Case B 

Aplikasi Emergency call 

No Periode menggunakan 

Manual Tes (menit) 

crowsource (menit) 

1 

Morning 

6 menit 7 

07:00 7 menit 6:07 

Peak 

deti 

2 Off-Peak 06:00 6 menit 5:25 

5 menit 25 

detik 

3 

Evening 

8 menit 49 

09:00 9 menit 8:49 

Peak 

detik 

kasus. 

Berikut adalah gambar grafik hasil perbandingan waktu tempuh kedua 

25 

Chart Title 

20 

15 

10 

5 

0 

App 

Manual 

Run 1 Run 2 Run 3 

Gambar 8.14 Grafik Perbandingan Waktu Tempuh 


150 

Kemudian hasil perhitungan tersebut dilakukan Uji Hipotesis dengan T-test 

sebagai berikut: 

a. Menentukan H0 dan H1 

x H0 = data Case A dan data Case B adalah sama atau hampir mendekati 

sama. 

H1 = data Case A dan data Case B adalah berbeda atau tidak sama. 

b. Menentukan Nilai Level of Significant 

Nilai level signifikan (D) = 5% = 0,05. 

c. Kriteria penerimaan uji hipotesis 

Terima H0, jika t hitung d t tabel atau p-value > D 

Tolak H0, jika t hitung ! t tabel atau p-value d D 

d. Hitung nilai t tabel , t hitung , dan p-value 

Berikut hasil perhitungan Uji-T yang peneliti lakukan menggunakan 

software Microsoft Excel 

(langkah melakukan perhitungan Uji-T menggunakan Excel dapat dilihat 

pada lampiran 3.) 

T hitung = -0,40; t tabel = 2,78; dan P-value = 0,70. 

e. Kesimpulan 

Dari hasil analisis data statistik Uji Hipotesis T-test di atas, peneliti 

menyimpulkan sebagai berikut: 

t hitung (0,20) (tanda minus diabaikan) < t tabel (2,78), berarti H0 

tidak dapat ditolak, artinya Hipotesis diterima. 

p-value (0,85) > α(0,05), berarti H0 tidak dapat ditolak, artinya Hipotesis 

diterima. 

Bahwa dari kedua kasus (case A dan B), terlihat perbandingan datanya 

hampir sama. Artinya, perbedaan nilai antara aplikasi dan perhitungan rumus 

tidak signifikan dan masih dapat diterima. 


151 


BAB VI 

PENUTUP 

9.1 Kesimpulan 

Berdasarkan perumusan masalah yang sudah dijabarkan pada Bab 1, penulis 

dapat mengambil kesimpulan sebagai berikut: 

a. Dengan menerapkan Crowdsource Matrix Distance Google Maps API 

membuat pengambilan data lalu lintas lebih terperinci 

b. Dengan menggunakan Metode E.T.T (Estimed Travel Time) penulis dapat 

membandingkan keakuratan waktu tempuh aplikasi Emergency Call 

menggunakan crowdsource google maps API dengan hitungan manual yang 

dilakukan penulis 

c. Dari hasil perbandingan aplikasi Emergency Call menggunakan 

crowdsource google maps API dengan hitungan manual yang dilakukan 

penulis,perhitungan waktu hampir sama 

9.2 Saran 

Penulis menyadari aplikasi ini masih jauh dari kata sempurna. Berikut 

beberapa saran yang mungkin dapat dilakukan pada pengembangan aplikasi 

selanjutnya: 

a. Menerapkan rumus perhitungan estimasi waktu tempuh pada code aplikasi. 

b. Untuk aplikasi dibuat versi IOS 

c. Untuk Software Aplikasi dapat menampung semua Point of Interest, tidak 

hanya Hotel saja. 

d. Untuk Software Aplikasi, fitur penunjuk arah pada Google Maps Navigation 

dapat dikembangkan menjadi bentuk Visual Augmented Reality. 

e. Pengembangan pada sistem usulan 

f. Penambahan fitur list nomor telepon pada aplikasi 

152

DAFTAR PUSTAKA 

Adi.T.N, Ambarsari, N. & A. M. (2015). Membangun Aplikasi E-commerce Jasa 

Fotografi Pre Wedding Berbasis Web Crowdsourcing Modul Calon 

Pengantin Dan Foto Sesi Menggunakan Metode Iterative Incremental. 

eProceedings of Engineering, 2(2), 5782–5790. Retrieved from 

http://libraryeproceeding.telkomuniversity.ac.id/index.php/engineering/articl 

e/view/2403 

Akbar, muhamad rizka. (2015). analisis perhitungan keakuratan waktu tempuh 

data crowdsource pada aplikasi perhotelan di tanggerang selatan dengan 

metode estimated travel time. In metode estimated travel time (pp. 69–79). 

Jakarta. 

Anisah.R, R, Damayanti.D.D & Santosa, B. (2016). Perancangan Rute 

Pendistribusian Produk Obat Dengan Menggunakan Algoritma Tabu Search 

Pada Vehicle Routing. E-Proceeding of Engineering, 3(2), 2384–2391 

Budianto, A. & E. R. N. (2016). Perancangan Aplikasi Islamic Boarding School 

Finder. Sniptek 2016, 144–150. 

Chrisdianto, I., & Legowo, S. J. (2015). Perbandingan Estimasi Waktu Perjalanan 

Dari Instantaneous Model Dan Time Slice Model Dengan. Jurnal MATRIKS 

TEKNIK SIPIL, (September), 654–662. 

Dwi, S. R. & A. (2016). Penerapan Algoritma Dijkstra pada Aplikasi Pencarian 

Rute Bus Trans Semarang. In Seminar Nasional Ilmu Komputer (pp. 299– 

306). 

Fauziah, Y., Rustamaji, H. C., & Ramadhan, R. P. (2016). Penerapan Mobile 

Crowdsourching Untuk Estimasi Waktu Kedatangan Bis Berdasarkan 

Informasi Masyarakat. Lontar Komputer : Jurnal Ilmiah Teknologi Informasi, 

7(3), 150. https://doi.org/10.24843/LKJITI.2016.v07.i03.p03 

Farizah, Nur, R. & K. (2016). Pemodelan aplikasi mobile reminder berbasis 

android. In Seminar Nasional Teknologi Informasi dan Komunikas (Vol. 

2016, pp. 18–19). 

Fitri, K. K. (2014). PENENTUAN ARAH TUJUAN OBJEK DENGAN TABU 

SEARCH. Jurnal Informatika, 3(70), 1–6. 

Handayani, S. (2016). INOVASI LAYANAN ( Studi Kasus Emergency Call 115 

sebagai Inovasi Layanan pada Kantor Basarnas Kelas A Biak ). Jurnal 

Administrasi Publik, 6(1), 83–87. 

153

154 

Hermawansyah, C. B. & W. J. (2014). Pengembangan Sistem Keamanan Untuk 

Toko Online Pemrograman Php Dan Mysql. Jurnal Media Infotama, 11(1). 

Jalni, Y. M. P., & Yuliansyah, H. (2015). Rancangan Aplikasi Web Monitoring 

Estimasi Kedatangan Bus Trans-Jogja Berdasarkan Lokasi Bus dengan GPS 

Smartphone. Simposium Nasional Teknologi Terapan (SNTT) 3. 

Jehrey Whitten & Lonnie.D.Bentley. (2007). System Analysis and Design 

Methods (Brett Gord). New York. 

Kadir abdul. (2001). dasar-dasar pemograman web dinamis menggunakan PHP. 

Kendall, K. E., & Kendall, J. E. (2006). Systems Analysis and Design. 

https://doi.org/QA76.9.S88K45 2010 

Kosasi, S. (2015). Penerapan Rapid Application Development Dalam Sistem 

Perniagaan Elektronik Furniture. Citec Journal, 2(4), 265–276.. 

Kusumah,Irwan, A. (2011). PENGEMBANGAN SISTEM DALAM SISTEM 

INFORMASI AKUNTANSI. Jurnal Sistem Informasi, 6–15. 

Layona, R. (2016). Aplikasi Pencarian Rumah Makan Berbasis Gps Pada 

Perangkat Mobile Android. Jurnal Sistem Komputer, 6(1), 1–5. 

Lestari & Garling. (2010). bahasa xml. Yogyakarta. 

Luthfi,E.T. (2013). Modul Kuliah Program Aplikasi Mobile. Bandung 

Mahardhika, Budi, W., Hidayat, B., & Atmaja, R. D. (2013). PERANCANGAN 

APLIKASI ANDROID UNTUK SISTEM PANGGILAN DARURAT 

STUDI KASUS KANTOR POLISI DAN RUMAH SAKIT DI KOTA 

BANDUNG MENGGUNAKAN PERINTAH SUARA. Information 

Technology.. 

Maulidis, N., Kristalina, P., & Hadi, M. Z. S. (2013). Pembuatan Aplikasi 

Emergency-Call dengan Pengaksesan J2ME. Jurnal Informatika, 1–10. 

Maria,A (1997) introduction to modelling and simulation.proceeding of the 1997 

winter simulation conference,(hal 7-13).State University Of New York 

Mufti, Y. (2013). RANCANG BANGUN EMERGENCY SECURITY CALLER 

BERBASIS ANDROID UNTUK SITUASI PERAMPOKAN. universitas 

islam negeri sunan kalijaga. 

Noertjahyana, Agustinus. (2002). Studi Analisis Rapid Aplication Development 

Sebagai Salah Satu Alternatif Metode Pengembangan Perangkat Lunak. 


155 

Jurnal Informatika, 3(2), 64–68. 

https://doi.org/10.9744/INFORMATIKA.3.2.PP. 64-68 

Novandya, A., Kartika, A., Wibowo, A., & Libriadiany, Y. (2012). Aplikasi 

Pengenalan Budaya Dari 33 Provinsi Indonesia Berbasis Android. Komputer 

Dan Sistem Intelijen, 7, 508–513. Retrieved from 

http://ejournal.gunadarma.ac.id/index.php/kommit/article/view/576/499 

Nyura, Y. (2010). Pembuatan Aplikasi Pembelajaran Bahasa Inggris Pada 

Handphone dengan J2ME Yusni Nyura. Jurnal Informatika, 5(3), 18–27. 

Oktafiana,Gian, D. (2015). Pengembangan Media Pembelajaran Berbasis Android 

Dalam Bentuk Buku Saku Digital Untuk Mata Pelajaran Akuntansi 

Kompetensi Dasar Membuat Ikhtisar Siklus Akuntansi Perusahaan Jasa Di 

Kelas Xi Man 1 Yogyakarta Tahun Ajaran 2014/2015 Skripsi. Universitas 

Negeri Yogyakarta, 1. https://doi.org/10.1017/CBO9781107415324.004 

Oktoviana, R. S. & M. Y. L. T. (2017). Implementasi Algoritma Dijkstra Dalam 

Pencarian Lintasan Terpendek Lokasi Rumah Sakit, Hotel Dan Terminal 

Kota Malang Berbasis Web. Jurnal Informatika, 4(3), 3993–4000 

Prasetyo, V. Z. (2013). Penerapan Algoritma Dijkstra Untuk Perutean Adaptif 

Pada Jaringan Pendistribusian Air Pdam Di Kabupaten Demak. Universitas 

Negeri Semarang. 

Rosa A.S, & Shalahuddin, M. (2013). Rekayasa Perangkat Lunak (Terstruktur 

dan Berorientasi Objek). Bandung 

Safaat,N,H. (2011). Android Pemrograman Aplikasi Mobile Smartphone dan 

Tablet PC Berbasis Android. Informatika. Bandung. 

Salim, A. & E. A. W. R. (2013). Pembuatan Sistem Pelayanan Taksi dengan 

Menggunakan Android , Google Maps , dan Ruby on Rail. Sistem Informasi, 

17–28. 

Sallaby, A. F., Utami, F. H., & Arliando, Y. (2015). Aplikasi Widget Berbasis 

Java. Jurnal Media Infotama, 11(2), 171–176. 

Setyawan, M. B., Gamayanti, N., & Alkaff, A. (2013). Optimasi Rute Perjalanan 

Ambulance. Teknik Elektro, 1–6. 

Sidik,B. (2012). Pemrograman Web dengan PHP, Informatika, 

Bandung. 

Sirenden. (2012). Buat sendiri aplikasi Petamu menggunakan CodeIgniter dan 

google Maps API. Yogyakarta. 


156 

Sugiarti. (2013). Analisis dan Perancangan UML (Unified Modeling Languege). 

Bandung. 

Supriyanto, A. (2005). Penyajian Dokumen XML dengan Teknik Pengikatan 

Data. Jurnal Teknologi Informasi DINAMIK, X(2), 66–75. 

Suryo Saputro, S. (2013). Perancangan Aplikasi Gis Pencarian Rute Terpendek 

Peta Wisata Di Kota Manado Berbasis Mobile Web Dengan Algoritma 

Dijkstra. Journal of Chemical Information and Modeling, 53(9), 1689–1699. 

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

Suryaputra Hidayahtullah. (2016). Aplikasi Crowdsourcing Estimasi Waktu 

Kedatangan Bus Transjogja Berbasis Android. Jurnal Informatika. Retrieved 

from http://hdl.handle.net/123456789/3749 

Triansyah, A. & F. (2013). Implementasi Algoritma Dijkstra Dalam Aplikasi 

Untuk Menentukan Lintasan Terpendek Jalan Darat Antar Kota Di Sumatera 

Bagian Selatan. Jurnal Sistem Informasi, 5(2), 611–621 

Turner,S.M.,Eisele,W.L.,Benz R. J., & Holderner , D. J. (1998). TRAVEL TIME 

DATA COLLECTION HANDBOOK. Washington, DC : Federal Highway 

Administrator. 

Varita, I., & Setyawati, O. (2013). Pencarian Jalur Tercepat Rute Perjalanan 

Wisata Dengan Algoritma Tabu Search, 7(2), 185–190. 

Wikanta, P., Wijanarko, H., & Palufi, Z. (2014). Pemantauan Posisi Armada Bus 

Pada Busway Berbasis Android E-59 E-60. In Simposium Nasional RAPI 

XIII (pp. 59–64).. 


LAMPIRAN 

Lampiran 1 Wawancara 

1. Kategori seperti apakah yang bisa dikatakan emergency call ? 

Jawaban : Yang bisa di kategorikan emergency call adalah 

ketika masyarakatkan mendapatkan bencana,kejahatan,dan 

membutuhkan apapun yang bersangkutan dengan nyawa seseorang 

2. Bagaimana tindakan BPBD Jakarta ketika mendapatkan emergency 

call ? 

Jawaban : Melakukan tindakan sesuai SOP yang telah dibuat 

3. Apa yang harus dilakukan BPBD ketika mendapatkan emergency call 

dengan data yang kurang akurat? 

Jawaban : Admin akan menanyakan dulu lokasi 

keberadaan,kejadian apa yang terjadi dan akan meminta nomor telpon 

orang yang terdekat dari pelapor 

4. apakah sistem prosedur emergency call banyak di dapat komplent dari 

masyarakat? 

Jawaban : Sejauh ini masih ada feedback positif dan negatif dari 

masyarkat 

5. Permasalahan apa yang sering di dapatkan BPBD ketika mendapatkan 

emergency call dari masyarakat ? 

Jawaban : Permasalahan yang sering di dapatkan BPBD adalah 

sering mendapatkan lokasi kejadian yang kurang akurat,tingkat 

bencana yang di dapatkan pelapor sehingga BPBD tidak perlu 

mengerahkan banyak personilnya 

6. Bagaimana cara masyarakat memberitahukan atau melaporkan 

kejadiaan saat menghubungi emergency call? 

Jawaban : 

1. Nama 

2. Alamat 

3.kejadian apa yang dilaporkan 

157

158 

4. Nomor telpon orang terdekat dari kejadian 

7. Apakah layanan emergency call itu gratis ? 

Jawaban : Emergency call merupakan layanan gratis tanpa 

dikenakan biaya apapun 

8. Kapan saya bisa memanggil nomor darurat? 

Jawaban : Anda bisa menghubungi 112 atau 101 saat Anda sangat 

membutuhkan brigade pemadam kebakaran, ambulans atau polisi. Jika 

tidak ada urgensi, lebih baik Anda memanggil pemadam kebakaran 

setempat, dokter umum Anda (di luar jam buka Anda dapat 

menghubungi perawatan primer setelah jam kerja) atau polisi 

setempat. 

Ada juga nomor darurat lainnya untuk masalah spesifik, seperti garis 

bunuh diri atau Pusat Perawatan untuk Kasus Keracunan. 

9. Bagaimana sebaiknya Anda meminta bantuan saat badai lebat? 

Jawaban : ika BMKG mengumumkan kode oranye atau merah karena 

badai atau banjir, teleponlah emergency call bila Anda memerlukan 

bantuan dari pemadam kebakaran dan bila tidak ada orang yang 

berada dalam bahaya kematian. 

Hubungi saja emergency call saat penyelamatan diperlukan atau bila 

situasi yang mengancam jiwa dilibatkan. 

Bila Anda menelepon emergency call ,sabar menunggu jawaban. 

Jangan meletakkan gagang telepon 

10. Bagaimana menurut anda emergency call dibuatkan dalam bentuk 

aplikasi berbasis android dan IOS ? 

Jawaban : Menurut saya sangat dibutuhkan, guna untuk membantu 

pelayanan emergency call di masyarakat karena dengan ada aplikasi 

kemungkinan data lebih akurat dan layanan lebih cepat 


159 

Lampiran 2 Data dari Kantor Polisi,Pemadam Kebakaran,Rumah Sakit 

Jakarta Selatan 

A. Data Kantor Polisi Jakarta Selatan 

No Nama Kantor Polisi Alamat 

1 

Polres Jakarta Selatan Jl. Wijaya II no.42 Kebayoran Baru, Jakarta Selatan 

2 

Polsek 

Lama 

Kebayoran 

Jl. Kyai Maja No. 62 Kebayoran Lama, Jakarta Selatan 

3 

Polsek Tebet 

Jl Prof Dr Supomo SH No 56 B Tebet, Jakarta Selatan 

12810 

4 

Polsek Pancoran 

Jl. Buncit Raya No.124, Kelurahan Kalibata, 

Kecamatan Pancoran, Jakarta Selatan 

5 

Polsek 

Prapatan 

Mampang 

Jl. Kapten Tendean No. 93 Mampang Prapatan 

6 

7 

8 

9 

Polsek Cilandak 

Polsek Jagakarsa 

Polsek Pasar Minggu 

Polsek Pesanggrahan 

Jl.Caringin Utara No.1 Cilandak 

Jl. Timbul Jagakarsa 

Jl. Raya Ragunan No. 1, Pasar Minggu,Jakarta Selatan 

Jl. Bintaro Utara No. 1 Jakarta Selatan 


160 

B. Data Pemadam Kebakaran Jakarta Selatan 

No Nama Pemadam Kabakaran Alamat 

1 SUDIN Jakarta Selatan 

Jl. Raya Lebak Bulus 

2 

Pos Cipulir 

Jalan Ciledug Raya Kelurahan Cipulir 

Kecamatan Kebayoran Lama 

3 

Pos Walikota 

Jalan Prapanca Raya Kelurahan Petogogan 

Kecamatan Kebayoran Baru 

4 

Kantor Sektor Pesanggrahan 

Jalan Pesanggrahan Indah Kelurahan 

Pesanggrahan Kecamatan Pesanggrahan 

5 

Pos Fatmawati 

Jalan RS.Fatmawati Kelurahan Cipete Barat 

Kecamatan Cilandak 

6 

Pos Casablanka 

Jalan Casablanca Kelurahan Menteng Atas 

Kecamatan Setiabudi 

7 

Sektor Pasar Minggu 

Jalan Salihara Kelurahan Jatipadang 

Kecamatan Pasar minggu 

8 

Pos Pasar Minggu 

Jalan Tanjung Barat Kelurahan Pasar Minggu 

Kecamatan Pasar Minggu 

9 

Pos Grogol Utara 

alan Kebayoran Lama Kelurahan Grogol 

utara Kecamatan Kebayoran Lama 

10 

Pos Mampang Prapatan 

Jalan Kapten Tendean Kelurahan Kuningan 

Barat Kecamatan Mampang Prapatan 


161 

11 

Pos Cipete 

Jalan Melati Kelurahan Cipete Selatan 

Kelurahan Cilandak 

12 

Pos Tebet 

Jalan Prof DR Supomo,SH Kelurahan Tebet 

Barat Kecamatan Tebet 

13 Pos Kalibata 

Jalan Komplek MPR Kalibata Kelurahan 

Rawajati Kecamatan Pancoran 

14 Pos Pejaten 

Jalan Raya Condet Kelurahan Pejaten Barat 

Kecamatan Pasar Minggu 

15 Sektor Jagakarsa 

Jalan M.Khafi Kelurahan Jagakarsa 

Kecamatan Jagakarsa 

16 Pos Srengseng 

Sawah Kampung Betawi Jalan Srengseng 

Sawah Kelurahan Srengseng Sawah 

Kecamatan Jagakarsa 

C. Data Rumah Sakit Jakarta Selatan 

No Nama Rumah Sakit Alamat 

1 

2 

3 

Rumah Sakit Tebet 

Rumah Sakit Pusat Pertamina 

Rumah Sakit Pondok Indah 

Alamat : Jl Let.Jen.MT Haryono kav 13 


Jl. Kyai Maja No.43 Kebayoran 

Baru,Jakarta Selatan 

Jl. Metro Duta Kav. UE Pondok 

Indah,Jakarta Selatan 

4 Rumah Sakit MMC Jl. H R. Rasuna Said No.21,Jakarta Selatan 

5 Rumah Sakit Medistra Jl. Gatot Subroto Kav 59,Jakarta Selatan 


162 

6 

Jalan Lebak Bulus I. Kav. 29, Jakarta 

Rumah Sakit Mayapada 

Selatan 

7 Rumah Sakit Jakarta Jl. Jend.Sudirman Kav.49,Jakarta Selatan 

8 

: Jl. Tebet Raya No. 4-6,Jaksel, Jakarta 

Rumah Sakit Indah Medika 

Selatan 

9 RSUP Fatmawati Jl. RS Fatmawati Cilandak, Jaksel 

10 

Jl. Raya Pasar Minggu No.3A,Jakarta 

RSU Tria Dipa 

Selatan 

11 

Jl. RS Fatmawati Raya No. 74, Pd. Labu- 

RSU Prikasih 

Cilandak, Jakarta Selatan 

12 RSU MRCCC Siloam Semanggi / 

RS Kanker 

Jl. Garnisun Kav. 2-3 karet Semanggi, 

Setiabudi, Jakarta Selatan 

13 

Jl. Gandaria Tengah 11 Kby Baru,Jakarta 

RSU Gandaria 

Selata 

14 RSIA Yadika Kebayoran Lama Jl. Ciputat Raya No. 5, Jakarta Selatan 

15 RSIA Muhammadiyah Taman Jl. Gandaria I/20 Kebayoran Baru,Jakarta 

Puring 

Selatan 

16 RSIA KEMANG MEDICAL 

CARE 

Jl. Ampera Raya No. 34, Jakarta Selatan 

17 RSIA Brawijaya Women and Jl..Taman Brawijaya No.1,Cepete 

Children Hospital 

Utara,Jakarta Selatan 

18 

Jl. Warung Sila 8 RT 004/06, 

RSIA Andhika 

Ciganjur,Jagakarsa, Jakarta Selatan 

19 RSB Panti Nugeraha Jl. Senayan 26 Kby.Baru,Jakarta Selatan 

20 

Jl. Ciledug Raya No.94-96 Cipulir, 

RSB Kartini 

Keabayoran Lama, Jakarta Selatan 

21 

Jl. Duren Tiga Raya No.5 Pancoran,Jakarta 

RSB Durentiga 

Selatan 

22 RSB Budhi Jaya Jl. Dr. Sahardjo 120,Jakarta Selatan 

23 RSB Asri Jl. Duren 3 Raya No. 20 Duren 3, 


163 

Pancoran, Jakarta Selatan 

24 

Jl. Panglima Polim I/34 Melawai – 

RSB Asih 

Kebayorann Baru, Jakarta Selatan 

25 

Jl. Siaga Raya Kav.4-8, Pejaten Barat pasar 

RS Siaga Raya 

minggu,Jakarta Selatan 

26 RS Setia Mitra Jl. Fatmawati No. 80-82,Jakarta Selatan 

27 RS Jiwa Dharmawangsa/ RS Jiwa/ 

RSKO 

Jl. Darmawangsa Raya Blok P/ II No.13, 


28 RS Jakarta Medical Center (JMC) Jl. Buncit Raya No.15, Jakarta Selatan 

29 RS Harapan Kartini Jl. Ampera Raya No.1,Jakarta Selatan 

30 

: JL.Ciputat Raya No 40,Kel.Pondok 

RS Bhayangkara Sespimma Polri Pinang,Kec.Kebayoran Lama, Jakarta 

Selatan 

31 RS AL Cilandak Jl. Raya Cilandak,Jakarta Selatan 

32 RS Agung Jl. Sultan Agung No.67,Jakarta Selatan 

33 

Alamat : Jl Let.Jen.MT Haryono kav 13 

Rumah Sakit Tebet 


34 

Jl. Kyai Maja No.43 Kebayoran 

Rumah Sakit Pusat Pertamina 

Baru,Jakarta Selatan 

35 

Jl. Metro Duta Kav. UE Pondok 

Rumah Sakit Pondok Indah 

Indah,Jakarta Selatan 

36 Rumah Sakit MMC Jl. H R. Rasuna Said No.21,Jakarta Selatan 

37 Rumah Sakit Medistra Jl. Gatot Subroto Kav 59,Jakarta Selatan 

38 

Jalan Lebak Bulus I. Kav. 29, Jakarta 

Rumah Sakit Mayapada 

Selatan 

39 Rumah Sakit Jakarta Jl. Jend.Sudirman Kav.49,Jakarta Selatan 

40 

: Jl. Tebet Raya No. 4-6,Jaksel, Jakarta 

Rumah Sakit Indah Medika 

Selatan 

41 RSUP Fatmawati Jl. RS Fatmawati Cilandak, Jaksel 

42 RSU Tria Dipa Jl. Raya Pasar Minggu No.3A,Jakarta 


164 

Selatan 

43 

Jl. RS Fatmawati Raya No. 74, Pd. Labu- 

RSU Prikasih 

Cilandak, Jakarta Selatan 

44 RSU MRCCC Siloam Semanggi / 

RS Kanker 

Jl. Garnisun Kav. 2-3 karet Semanggi, 

Setiabudi, Jakarta Selatan 

45 

Jl. Gandaria Tengah 11 Kby Baru,Jakarta 

RSU Gandaria 

Selata 

46 RSIA Yadika Kebayoran Lama Jl. Ciputat Raya No. 5, Jakarta Selatan 

47 RSIA Muhammadiyah Taman Jl. Gandaria I/20 Kebayoran Baru,Jakarta 

Puring 

Selatan 

48 RSIA KEMANG MEDICAL 

CARE 

Jl. Ampera Raya No. 34, Jakarta Selatan 

49 RSIA Brawijaya Women and Jl..Taman Brawijaya No.1,Cepete 

Children Hospital 

Utara,Jakarta Selatan 

50 RS Setia Mitra Jl. Fatmawati No. 80-82,Jakarta Selatan 

51 RS Jiwa Dharmawangsa/ RS Jiwa/ 

RSKO 

Jl. Darmawangsa Raya Blok P/ II No.13, 


52 RS Jakarta Medical Center (JMC) Jl. Buncit Raya No.15, Jakarta Selatan 

53 RS Harapan Kartini Jl. Ampera Raya No.1,Jakarta Selatan 

54 

: JL.Ciputat Raya No 40,Kel.Pondok 

RS Bhayangkara Sespimma Polri Pinang,Kec.Kebayoran Lama, Jakarta 

Selatan 

55 RS AL Cilandak Jl. Raya Cilandak,Jakarta Selatan 

56 RS Agung Jl. Sultan Agung No.67,Jakarta Selatan 


165 

Lampiran 3 Perhitungan Uji-T menggunakan Excel 

a. Masukkan data Case A dan B ke dalam Microsoft Excel. 

b. Kemudian klik menu tab toolbar Data>klik Data Analysis pada 

bagian Analysis. 

c. Selanjutnya muncul jendela menu Data Analysist lalu pilih t-Test: 

Two-Sample Assuming Equal Variances dan klik OK. Penulis 

memilih ini karena data kedua sampel Case uji diasumsikan 

variansinya sama. 


166 

d. Selanjutnya akan tampil jendela menu t-Test: Two-Sample Assuming 

Equal Variances. Pada bagian Input Variable 1 Range:, isi dengan 

range kolom Case A dan Input Variable 2 Range:, isi dengan range 

kolom Case B. Isi Hyepothesized Mean Difference: dengan nilai 0 

karena dianggap kedua variabel memiliki mean yang sama. 

Centang Labels untukmenampilkan baris pertama pada tiap kolom 

sebagai nama kolom hasil perhitungan. Isi Alpha 0,05 sebagai level 

signifikan.Pada Output options pilih New Worksheet Ply: agar 

hasilnya dipisahkan ke Sheet (lembar kerja) baru. Klik OK jika 

sudah selesai. 

e. Selanjutnya hasil perhitungan akan ditampilkan sebagai berikut: 


167 

t 

Berikut penjelasan mengenai angka-angka di atas: 

Mean = Nilai rerata. 

Variance = Nilai variasi data. 

Observations = Jumlah pengamatan data. 

Hypothesized Mean difference = perbedaan nilai rerata antara data. 

df = derajat kebebasan. 

t Stat = nilai t hitung. 

P(T

168 

Lampiran 5 Source Code 

5. Tampilan android 

 

 

 

 

169 

class="com.google.android.gms.maps.SupportMapFragment" 

android:layout_width="match_parent" 

android:layout_height="match_parent" 

android:layout_below="@+id/appBar"/> 

 

 

 


170 

 

 

 

 

 

 

 

 


171 

 

 

5. Java Get Maps 

public class DetailActivity extends AppCompatActivity 

implements 

OnMapReadyCallback, 

GoogleApiClient.ConnectionCallbacks, 

GoogleApiClient.OnConnectionFailedListener, 

com.google.android.gms.location.LocationListener { 

private static String TAG = "MAP LOCATION"; 

protected GoogleApiClient mGoogleApiClient; 

Context mContext; 

private GoogleMap mMap; 

Location mLastLocation; 

private Toolbar toolbar; 

private Button btnPesan; 


172 

private AddressResultReceiver mResultReceiver; 

protected String mAddressOutput; 

protected String mAreaOutput; 

protected String mCityOutput; 

protected String mStateOutput; 

private TextView txtsearch; 

private File tempFile; 

public static final int REQUEST_CODE_GALLERY = 0x1; 

public static final int REQUEST_CODE_TAKE_PICTURE = 

0x2; 

public static final int REQUEST_CODE_CROP_IMAGE = 

0x3; 

public static final String TEMP_PHOTO_FILE_NAME = 

"temp_gambar.jpg"; 

String[] PERMISSIONS = {Manifest.permission.CAMERA, 

Manifest.permission.READ_EXTERNAL_STORAGE, 

Manifest.permission.WRITE_EXTERNAL_STORAGE}; 

int PERMISSION_ALL = 1; 

public static boolean hasPermissions(Context context, String... 

permissions) { 

if (android.os.Build.VERSION.SDK_INT >= 

Build.VERSION_CODES.M && context != null && permissions 

!= null) { 

for (String permission : permissions) { 


173 

if (ActivityCompat.checkSelfPermission(context, 

permission) != PackageManager.PERMISSION_GRANTED) { 

return false; 

} 

} 

} 

return true; 

} 

public void checkPermissions() { 

if (!hasPermissions(this, PERMISSIONS)) { 

ActivityCompat.requestPermissions(this, PERMISSIONS, 

PERMISSION_ALL); 

} 

} 

private String type; 

@Override 

protected void onCreate(Bundle savedInstanceState) { 

super.onCreate(savedInstanceState); 

setContentView(R.layout.activity_maps); 

mContext = this; 

Intent i = getIntent(); 

type = i.getStringExtra("type"); 

txtsearch = (TextView) findViewById(R.id.txtsearch); 

btnPesan = (Button) findViewById(R.id.btnPesan); 

btnPesan.setOnClickListener(new View.OnClickListener() { 


174 

@Override 

public void onClick(View v) { 

new Order().execute(); 

} 

}); 

toolbar = (Toolbar) findViewById(R.id.toolbar); 

setSupportActionBar(toolbar); 

getSupportActionBar().setDisplayHomeAsUpEnabled(true); 

getSupportActionBar().setTitle(i.getStringExtra("nama")); 

buildGoogleApiClient(); 

SupportMapFragment mapFragment = 

(SupportMapFragment) getSupportFragmentManager() 

.findFragmentById(R.id.map); 

mapFragment.getMapAsync(this); 

mResultReceiver = new AddressResultReceiver(new 

Handler()); 

String state = Environment.getExternalStorageState(); 

int randomName = (int) (Math.random() * 9000) + 1000; 

if (Environment.MEDIA_MOUNTED.equals(state)) { 

tempFile = new 

File(Environment.getExternalStorageDirectory(), 

String.valueOf(randomName) + "one.jpg"); 

} else { 

tempFile = new File(getFilesDir(), 

String.valueOf(randomName) + "one.jpg"); 

} 


175 

checkPermissions(); 

} 


176 

Lampiran 6 Surat izin penelitian 


177

BAB I-VI_Harsy Tamimi_1113091000075

Create successful ePaper yourself

Delete template?

Save as template?