TA : Rancang Bangun Aplikasi Penilaian Bahaya Pada Pusat Pengendalian Operasi Penanggulangan Bencana Jawa Timur Berbasis Web.
RANCANG BANGUN APLIKASI PENILAIAN BAHAYA
PADA PUSAT PENGENDALIAN OPERASI
PENANGGULANGAN BENCANA JAWA TIMUR
BERBASIS WEB
TUGAS AKHIR
Program Studi S1 Sistem Informasi
Oleh:
Dhesky Aris Mas Darwanto 11410100138
FAKULTAS TEKNOLOGI DAN INFORMATIKA
INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2015
(2)
iv
ABSTRAK ... i
KATA PENGANTAR ... ii
DAFTAR ISI ... iv
DAFTAR TABEL ... viii
DAFTAR GAMBAR ... x
DAFTAR LAMPIRAN ... xvii
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang Masalah ... 1
1.2 Perumusan Masalah ... 6
1.3 Pembatasan Masalah ... 6
1.4 Tujuan ... 7
1.5 Manfaat . ... 7
1.6 Sistematika Penulisan ... 7
BAB II LANDASAN TEORI ... 9
2.1 Aplikasi... 9
2.2 Sistem ... 9
2.3 Informan ... 10
2.4 Bencana ... 11
2.5 Pusdalops PB ... 12
2.6 Penilaian Bahaya ... 13
2.7 SMS Gateway ... 23
(3)
v
2.10 Tahapan SDLC ... 25
2.10.1 Kebutuhan Perangkat Lunak... 25
2.10.2 Analisis dan Desain Perangkat Lunak ... 26
2.10.3 Konstruksi Perangkat Lunak... 32
2.10.4 Uji Coba Perangkat Lunak... 33
BAB III ANALISIS DAN PERANCANGAN SISTEM ... 34
3.1 Uraian Permasalahan ... 34
3.2 Analisis Permasalahan ... 35
3.3 Perancangan Sistem ... 37
3.3.1 Document Flow Penilaian Bahaya ... 40
3.3.2 System Flow Penilaian Bahaya ... 41
3.3.3 Diagram Jenjang Proses ... 56
3.3.4 Entity Relationship Diagram ... 63
3.3.5 Struktur Database ... 66
3.3.6 Desain Input Output ... 72
BAB IV IMPLEMENTASI DAN EVALUASI ... 84
4.1 Kebutuhan Sistem ... 84
4.1.1 Kebutuhan Hardware ... 84
4.1.2 Kebutuhan Software... 84
4.2 Implementasi Sistem ... 85
4.2.1 Form Login ... 85
(4)
vi
4.2.4 Form Master Kecamatan... 88
4.2.5 Form Master Informan ... 89
4.2.6 Form Master Jenis Bencana ... 91
4.2.7 Form Master Peristiwa ... 92
4.2.8 Form Master Parameter Dampak ... 93
4.2.9 Form Master Parameter Probabilitas ... 95
4.2.10 Form Transaksi Penilaian ... 96
4.2.11 Form Tampil Informasi Bencana ... 98
4.2.12 Form Tampil Hasil Dampak ... 98
4.2.13 Form Tampil Hasil Probabilitas ... 99
4.2.14 Form Pesan SMS Masuk ... 100
4.2.15 Form Broadcast Pesan ... 101
4.2.16 Form Laporan Informasi ... 101
4.2.17 Form Laporan Peta ... 104
4.2.18 Form Laporan Grafik ... 104
4.2.19 Form Laporan Penilaian Dampak ... 106
4.2.20 Form Laporan Penilaian Probabilitas ... 108
4.2.21 Form Laporan Makro ... 111
4.3 Evaluasi Sistem ... 113
4.3.1 Uji Coba Form ... 113
4.3.2 Uji Coba Penilaian Bahaya dengan SMS ... 119
(5)
vii
4.3.5 Uji Coba Berdasarkan Data Bencana 6 Bulan ... 149
BAB V PENUTUP... 151
5.1 Kesimpulan ... 151
5.2 Saran ... 151
DAFTAR PUSTAKA ... 152
(6)
1 1.1Latar Belakang Masalah
Peraturan Gubernur Jawa Timur No. 113 Tahun 2010 memuat aturan perubahan mengenai tata naskah dinas yang bersifat manual menjadi eletronik. Peraturan ini didasari adanya penghematan waktu dan biaya dalam pembuatan surat-surat dan nota dinas serta kecepatan proses pengirimannya dilakukan secara realtime. Adanya peraturan ini menyebabkan seluruh dinas yang ada di provinsi Jawa Timur merubah tata naskah dinas yang digunakan. Perubahan ini memang tidak bersifat secara langsung dan masif, tetapi lebih pada perubahan yang perlahan-lahan dari manual menjadi elektronik. Salah satu dinas yang mengalami perubahan tersebut adalah Badan Penanggulangan Bencana Daerah (BPBD) Jawa Timur.
BPBD Jawa Timur adalah lembaga khusus yang menangani penanggulangan bencana di provinsi Jawa Timur. Salah satu fungsi dari BPBD Jawa Timur adalah perumusan dan penetapan kebijakan penanggulangan bencana (Permen: no.46 tahun 2008). Dalam tiap BPBD Provinsi terdapat divisi Pusat Pengendalian Operasi Penanggulangan Bencana (Pusdalops PB) yang berfungsi mengelola data dan informasi hingga menyebarluaskan kepada pejabat berwenang maupun masyarakat melalui media. Salah satu tugas pokok Pusdalops PB sebelum bencana adalah memberikan dukungan kegiatan pada saat sebelum bencana (pengumpul, pengolah, penyaji data dan informasi kebencanaan) secara rutin (Perka No.15 Tahun 2012). Salah satu dukungan kegiatan tersebut adalah dengan membuat
(7)
penilaian bahaya sebagai bahan penyusun rencana kontingensi. Rencana kontingensi adalah rencana terintegrasi yang berisi upaya-upaya yang dilakukan oleh pemerintah provinsi, masyarakat serta lembaga usaha dalam menghadapi ancaman bencana (Pedoman Renkon BNPB, 2013).
Menurut pedoman rencana kontingensi tahun 2013, penilaian bahaya merupakan hasil dari mengidentifikasi ancaman bencana yang melanda suatu wilayah. Hasil identifikasi berupa pembobotan atau scoring ancaman bencana dari beberapa jenis ancaman yang ada berdasarkan ancaman kejadian bencana dan dampak dari suatu ancaman bencana. Penilaian bahaya berdasarkan dari data bencana yang ada pada rekap laporan. Rekap laporan adalah kumpulan dari laporan harian yang dibuat oleh Pusdalops PB berdasarkan periode tertentu. Laporan harian adalah laporan yang dibuat oleh Pusdalops PB yang berisi mengenai hal-hal yang berkaitan dengan bencana pada suatu wilayah tertentu setiap hari. Laporan ini berisi mengenai berita kejadian bencana, aktivitas gunung api, pantauan peringatan dini cuaca, prakiraan cuaca, prakiraan tinggi gelombang, dan hasil monitoring komunikasi radio. Proses penilaian bahaya dapat dilihat pada gambar sebagai berikut:
(8)
Penetapan penilaian bahaya juga bergantung dari data yang ada pada laporan harian. Laporan Harian disusun berdasarkan informasi hasil komunikasi dan pantauan dengan pihak terkait bencana. Pihak tersebut antara lain BPBD Kota, BMKG (Badan Meteorologi, Klimatologi dan Geofisika), PVMBG (Pusat Vulkanologi Mitigasi dan Bencana Geologi) dan pihak lain yang terkait dengan bencana. Informasi dari berbagai pihak tersebut akan dimasukkan kedalam log sheet kemudian dimasukkan kedalam laporan harian. Ketika petugas jaga memperoleh informasi dari pihak terkait, petugas jaga biasanya menyalin terlebih dahulu di selembar kertas kemudian mengetiknya di laporan. Laporan tersebut berupa file worksheet. File worksheet ini nantinya akan bertambah banyak karena setiap hari menghasilkan satu file laporan harian. Kemudian setiap minggu, laporan harian tersebut di sortir dan dimasukkan kedalam rekap laporan. Format rekap laporan ini juga berupa file worksheet. Rekap laporan nantinya akan menjadi bahan untuk penetapan penilaian bahaya.
Proses pembuatan dan pengumpulan laporan harian diatas ternyata banyak sekali kelemahan. Pertama, petugas jaga kesulitan dalam memasukkan informasi ke laporan harian. Untuk memasukkan informasi, petugas harus menulis terlebih dahulu di kertas. Hal ini dilakukan karena petugas dalam menerima informasi dapat melalui telepon atau radio sehingga butuh ditulis terlebih dahulu. Setelah ditulis, kemudian diketik ke worksheet. Permasalahan ini menyebabkan waktu memasukkan informasi menjadi lebih lama. Kedua, File rekap laporan menyulitkan petugas untuk dijadikan bahan penetapan penilaian bahaya. File rekap laporan merupakan file kumpulan laporan harian sehingga dapat digunakan sebagai bahan analisis kejadian bencana hingga penetapan penilaian bahaya. Namun ternyata file
(9)
ini hanya dapat digunakan untuk keperluan laporan saja dan tidak dapat digunakan untuk penetapan penilaian bahaya. Hal ini dikarenakan file rekap berbentuk worksheet sehingga tidak dapat diolah menjadi bentuk yang lain, misalnya tidak dapat difilter. Ketiga, File rekap juga tidak dapat menghasilkan penilaian bahaya secara langsung. File rekap yang berupa worksheet tidak dapat menghasilkan penilaian bahaya dikarenakan file tersebut belum berupa database. Penilaian bahaya yang dihasilkan menjadi tidak akurat. Tidak akurat artinya nilai yang dihasilkan tidak sesuai dengan kondisi yang sebenarnya setelah nilai tersebut dimasukkan dalam dokumen rencana kontingensi. Penilaian bahaya juga sering kali tidak valid dikarenakan Pusdalops PB menilai bencana hanya dengan memperkirakan saja tanpa ada perhitungan mengenai bencana tersebut, selain itu perhitungan penilaian bahaya masih bersifat manual. Kesalahan sering kali terjadi pada penentuan range skala penilaian. Bencana yang seharusnya masuk dalam range skala yang besar tetapi keliru dalam menempatkan di range skala yang lebih kecil. Hal ini yang menyebabkan penilaian bahaya masih tidak valid. Ditambah lagi, sistem yang sekarang masih menggunakan aplikasi worksheet yang terikat dengan sistem operasi tertentu. Sistem ini menyebabkan petugas dan pihak - pihak tertentu kesulitan mengakses sistem tersebut jika tidak berada ditempat. Sistem yang sekarang juga masih belum realtime, artinya sistem masih belum menghasilkan respon yang cepat dalam menghitung penilaian bahaya.
Permasalahan pada Pusdalops PB Jawa Timur dapat dirangkum pada tabel berikut:
(10)
Tabel 1.1 Masalah dan dampak
No Masalah Dampak
1 Petugas jaga kesulitan memasukkan informasi ke laporan harian.
Waktu memasukkan informasi lebih lama.
2 File rekap laporan hanya untuk keperluan laporan.
Data tidak dapat diolah lebih lanjut menjadi bahan penetapan penilaian bahaya.
3 File rekap tidak dapat menghasilkan penilaian bahaya secara langsung.
Penilaian bahaya menjadi tidak akurat.
Untuk mengatasi permasalahan yang dihadapi, maka Pusdalops PB perlu membuat sebuah sistem yang dapat melakukan penilaian bahaya terhadap bencana di Jawa Timur. Sistem ini berbasis web karena dapat diakses oleh petugas serta kepala Pusdalops dimanapun dan kapanpun tanpa harus melakukan penginstalan serta dapat dijalankan di berbagai sistem operasi serta bersifat realtime. Dengan adanya sistem yang realtime, maka petugas dapat mengetahui kondisi data secara cepat.
Sistem ini dimulai dari informan memasukkan data mengenai bencana. Data tersebut dapat langsung dimasukkan ke dalam website maupun melalui SMS. Jika menggunakan website, maka informan harus login terlebih dahulu kemudian memasukkan data-data informasi dan nilai parameter bencana. Jika menggunakan SMS, maka informan harus mengirimkan data-data informasi dan nilai parameter bencana sesuai dengan format SMS. Data informasi dan nilai parameter bencana nantinya akan diolah sistem menjadi nilai bahaya. Sistem akan melakukan penilaian bahaya menggunakan metode scoring berdasarkan buku pedoman rencana
(11)
kontingensi. Setelah dinilai, sistem dapat merekap dan menampilkan informasi nilai bencana berupa grafik dan peta daerah di Jawa Timur. Laporan grafik akan memudahkan dalam memantau perkembangan nilai bahaya dari bencana tersebut. Sistem dapat menghasilkan laporan harian untuk kebutuhan pelaporan Pusdalops.
Aplikasi penilaian bahaya pada Pusdalops ini dapat menghasilkan penilaian bahaya terhadap bencana, laporan harian, informasi berupa grafik dan peta. Dengan adanya aplikasi penilaian bahaya maka kendala dalam penilaian bahaya sebagai bahan penyusun rencana kontingensi di Pusdalops PB Jawa Timur dapat diselesaikan dengan baik.
1.2 Perumusan Masalah
Berdasarkan latar belakang permasalahan diatas, maka dapat dirumuskan permasalahan : bagaimana membangun aplikasi penilaian bahaya pada Pusdalops PB Jawa Timur berbasis web yang dapat memberikan penilaian bahaya terhadap bencana di Jawa Timur.
1.3 Pembatasan Masalah
Berdasarkan perumusan masalah diatas, maka dapat dibuat batasan masalah sebagai berikut:
1. Aplikasi tidak menunjukkan tempat kejadian bencana secara detail.
2. Jenis bencana yang dinilai oleh aplikasi hanya berjumlah 13 bencana sesuai dengan prioritas di BPBD Jawa Timur.
3. Aplikasi menggunakan metode scoring berdasarkan dokumen rencana kontingensi 2013.
(12)
1.4 Tujuan
Berdasarkan rumusan masalah diatas, maka tujuan dari penyusunan tugas akhir ini adalah menghasilkan aplikasi penilaian bahaya pada Pusdalops PB Jawa Timur berbasis web yang dapat memberikan penilaian bahaya terhadap bencana di Jawa Timur.
1.5 Manfaat
Dengan adanya penelitian ini, maka diharapkan memiliki beberapa nilai manfaat antara lain:
1. Membantu pihak Pusdalops PB dalam melakukan penilaian bahaya bencana. 2. Membantu pihak Pusdalops PB dalam proses pembuatan laporan harian.
1.6 Sistematika Penulisan
Di dalam penyusunan laporan tugas akhir ini secara sistematis diatur dan disusun dalam lima bab, yang masing-masing terdiri dari beberapa sub bab. Adapun urutan dari bab pertama sampai bab terakhir adalah sebagai berikut:
BAB I PENDAHULUAN
Bab ini membahas tentang latar belakang masalah, perumusan masalah, batasan masalah, tujuan pembuatan sistem, manfaat bagi penggunanya, serta sistematika penulisan laporan.
BAB II LANDASAN TEORI
Bab ini membahas mengenai berbagai macam teori yang mendukung dalam pembuatan rancang bangun aplikasi penilaian bahaya pada Pusdalops PB Jawa Timur berbasis web.
(13)
BAB III ANALISA DAN PERANCANGAN SISTEM
Bab ini membahas analisa dan perancangan sistem. Analisa berisi penjelasan dari timbulnya masalah beserta penyelesaiannya, sedangkan perancangan sistem berisi Document Flow, System Flow, Data Flow Diagram, Entity Relationship Diagram, dan Desain Input / Output.
BAB IV IMPLEMENTASI DAN EVALUASI SISTEM
Bab ini membahas tentang kebutuhan perangkat lunak, perangkat keras, implementasi dan evaluasi sistem. Implementasi ini mengacu pada perancangan desain sistem yang telah dibuat dan berfokus memberikan penilaian bahaya dari bencana di Jawa Timur. Dalam implementasi ini juga berisi penjelasan Graphical User Interface (GUI) sistem yang telah dibuat. Sedangkan evaluasi sistem berisi validasi dan uji coba sistem agar terhindar dari error serta berjalan sesuai yang diharapkan.
BAB V PENUTUP
Bab ini membahas tentang kesimpulan yang diperoleh dari pembuatan sistem ini serta saran yang bertujuan untuk pengembangan sistem dimasa yang akan datang.
(14)
9 BAB II
LANDASAN TEORI
2.1Aplikasi
Menurut Noviansyah (2008), aplikasi adalah penggunaan atau penerapan suatu konsep yang menjadi suatu pokok pembahasan. Aplikasi dapat diartikan juga sebagai program komputer yang dibuat untuk menolong manusia dalam melaksanakan tugas tertentu. Aplikasi software yang dirancang untuk suatu tugas khusus dapat dibedakan menjadi dua jenis, yaitu:
a. Aplikasi software spesialis, program dengan dokumentasi tergabung yang dirancang untuk menjalankan tugas tertentu.
b. Aplikasi software paket, suatu program dengan dokumentasi tergabung yang dirancang untuk jenis masalah tertentu.
2.2Sistem
Menurut Leman (1998), sistem terdiri dari komponen-komponen yang saling berkaitan dan bekerjasama untuk mencapai suatu tujuan. Menurut Herlambang dan Tanuwijaya (2005) definisi sistem dapat dibagi menjadi dua pendekatan, yaitu pendekatan secara prosedur dan pendekatan secara komponen. Berdasarkan pendekatan prosedur, sistem didefinisikan sebagai kumpulan dari beberapa prosedur yang mempunyai tujuan tertentu.
Berdasarkan pendekatan komponen, sistem merupakan kumpulan dari komponen-komponen yang saling berkaitan untuk mencapai tujuan tertentu. Menurut Kristanto (2008), terdapat 2 kelompok pendekatan di dalam
(15)
mendefinisikan sistem, yaitu yang menekankan pada prosedurnya dan yang menekankan pada komponen atau elemennya.
1. Pendekatan sistem yang lebih menekankan pada perosedur, mendefinisikan sistem sebagai berikut: “Sistem adalah suatu jaringan kerja dari prosedur -prosedur yang saling berhubungan, berkumpul, bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran tertentu”. 2. Pendekatan sistem yang merupakan jaringan kerja dari prosedur, lebih
menekankan urutan-urutan operasi didalam sistem. Prosedur didefinisikan sebagai berikut: “Suatu prosedur adalah suatu urutan-urutan operasi klerikal (tulis-menulis), biasanya melibatkan beberapa orang di dalam satu atau lebih departemen, yang diterapkan untuk menjamin penanganan yang seragam dari transaksi-transaksi bisnis yang terjadi”.
3. Pendekatan yang lebih menekankan pada elemen atau komponennya mendefinisikan sistem sebagai berikut: “Sistem adalah kumpulan dari elemen -elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.
2.3Informan
Menurut peraturan kepala BNPB (Badan Nasional Penanggulangan Bencana) no 15 tahun 2012, informan adalah personil yang bertugas melakukan pemantauan dan pelaporan kejadian bencana dalam suatu daerah. Pelaporan kejadian bencana meliputi pelaporan informasi dan indeks ancaman kejadian bencana. Indeks ancaman kejadian bencana meliputi nilai dampak dan probabilitas kejadian bencana. Pelaporan dilakukan ketika terjadi kejadian bencana dan pasca kejadian bencana.
(16)
Informan dalam satu kota berjumlah minimal 1 orang dan maksimal ditentukan oleh BPBD Kota berdasarkan kebutuhan di lapangan. Informan berasal dari pegawai BPBD Kota yang ditempatkan di kota tersebut atau relawan yang berasal dari masyarakat. Relawan yang menjadi informan berasal dari Tagana, Pramuka dan Mapala. Tagana adalah Taruna Siaga Bencana yang merupakan organisasi sosial yang bergerak dalam bidang penanggulangan bencana alam dan bencana sosial yang berbasiskan masyarakat. Pramuka adalah Praja Muda Karana yang merupakan organisasi pendidikan nonformal yang menyelenggarakan pendidikan kepanduan di Indonesia. Tingkatan Pramuka yang diperbolehkan untuk menjadi relawan adalah penegak dan pandega atau setaranya. Mapala adalah Mahasiswa Pecinta Alam yang merupakan organisasi non formal yang terdiri dari mahasiswa yang menyenangi kegiatan di alam.
2.4Bencana
Menurut peraturan kepala BNPB no 15 tahun 2012, bencana adalah peristiwa atau rangkaian yang mengancam dan mengganggu kehidupan dan penghidupan masyarakat yang disebabkan baik oleh faktor alam dan faktor non alam maupun faktor manusia sehingga mengakibatkan timbulnya korban jiwa manusia, kerusakan lingkungan, kerugian harta benda, dan dampak psikologis. Bencana berdasarkan penyebabnya dikategorikan menjadi 3, yaitu:
a. Bencana alam adalah bencana yang diakibatkan oleh peristiwa atau serangkaian peristiwa yang disebabkan oleh alam antara lain berupa gempa bumi, tsunami, gunung meletus, banjir, kekeringan, angin topan dan tanah longsor.
(17)
b. Bencana non alam adalah bencana yang diakibatkan oleh peristiwa atau serangkaian peristiwa non alam yang antara lain berupa gagal teknologi, gagal modernisasi, epidemi dan wabah penyakit.
c. Bencana sosial adalah bencana yang diakibatkan oleh peristiwa atau serangkaian peristiwa yang diakibatkan oleh manusia yang meliputi konflik sosial antar kelompok atau antar komunitas masyarakat dan teror.
Resiko bencana adalah potensi kerugian yang ditimbulkan akibat bencana pada suatu wilayah dan kurun waktu tertentu yang dapat berupa kematian, luka, sakit, jiwa terancam, hilangnya rasa aman, mengungsi, kerusakan atau kehilangan harta dan gangguan kegiatan masyarakat. Menurut pedoman renkon tahun 2013, kejadian bencana adalah peristiwa bencana yang terjadi dan dicatat berdasarkan tanggal kejadian, lokasi, jenis bencana, korban, dan ataupun kerusakan.
2.5Pusdalops PB
Pusat Pengendalian Operasi Penanggulangan Bencana atau Pusdalops PB adalah unsur pelaksana di BNPB atau BPBD yang bertugas menyelenggarakan sistem informasi dan komunikasi penanggulangan bencana (perka no. 15 tahun 2012). Tugas pokok Pusdalops PB adalah sebagai berikut :
1. Sebelum bencana
Memberikan dukungan kegiatan pada saat sebelum bencana (pengumpul, pengolah, penyaji data dan informasi kebencanaan) secara rutin.
2. Saat bencana
Memberikan dukungan pada posko tanggap darurat dan pelaksanaan kegiatan darurat.
(18)
3. Pasca bencana
4. Memberikan dukungan kegiatan pada saat setelah bencana terjadi (penyedia data dan informasi khusunya dalam pelaksanaan rehabilitasi dan rekonstruksi). Fungsi Pusdalops PB adalah sebagai berikut :
1. Fungsi penerima, pengolah dan pendistribusi informasi kebencanaan.
2. Fungsi penerima, pengolah dan penerus peringatan dini kepada instansi terkait dan masyarakat.
3. Fungsi tanggap darurat sebagai fasilitator pengerahan sumber daya untuk penanganan tanggap darurat bencana secara tepat, efisien dan efektif.
4. Fungsi koordinasi, komunikasi dan sinkronisasi pelaksanaan penanggulangan bencana.
BPBD Provinsi akan berkordinasi dengan BPBD Kota sehingga setiap kota akan didirikan BPBD Kota yang berfungsi sebagai kepanjangan tugas dari BPBD Provinsi. Setiap BPBD Kota memiliki informan yang bertugas memantau dan melaporkan kejadian bencana yang terjadi di kota tersebut. Informan dalam satu kota berjumlah minimal 1 orang dan maksimal ditentukan oleh BPBD Kota berdasarkan kebutuhan di lapangan. Informan berasal dari pegawai BPBD Kota yang ditempatkan di kota tersebut atau relawan yang berasal dari masyarakat.
2.6Penilaian Bahaya
Menurut pedoman rencana kontingensi tahun 2013, penilaian bahaya merupakan hasil dari mengidentifikasi ancaman bencana yang melanda suatu wilayah. Hasil identifikasi berupa pembobotan atau scoring ancaman bencana dari beberapa jenis ancaman yang ada berdasarkan ancaman kejadian bencana dan
(19)
dampak dari suatu ancaman bencana. Penilaian bahaya berdasarkan dari data bencana yang ada pada rekap laporan. Rekap laporan adalah kumpulan dari laporan harian yang dibuat oleh Pusdalops PB berdasarkan periode tertentu. Laporan harian adalah laporan yang dibuat oleh Pusdalops PB yang berisi mengenai hal-hal yang berkaitan dengan bencana pada suatu wilayah tertentu setiap hari. Laporan ini berisi mengenai berita kejadian bencana, aktivitas gunung api, pantauan peringatan dini cuaca, prakiraan cuaca, prakiraan tinggi gelombang, dan hasil monitoring komunikasi radio. Data laporan ini diperoleh dari informan seperti BPBD Kota dan beberapa informan yang berada di lapangan.
Penilaian bahaya dilakukan melalui identifikasi profil ancaman yang berpotensi melanda suatu wilayah berdasarkan :
a. Identifikasi profil ancaman yang berpotensi melanda suatu wilayah melalui dokumen Rencana Penanggulangan Bencana atau dari data sejarah kejadian bencana atau dari hasil kajian para pakar tentang potensi bencana di sebuah daerah.
b. Pembobotan atau scoring ancaman bahaya dari beberapa jenis ancaman yang ada dengan memberikan nilai atau bobot berdasarkan probabilitas (P) ancaman kejadian bencana dan dampak (D) dari suatu ancaman. Jenis ancaman tersebut meliputi :
1. Gempa Bumi 2. Tsunami 3. Banjir
4. Tanah Longsor 5. Letusan Gunung Api
(20)
6. Gelombang Ekstrim dan Abrasi 7. Cuaca Ekstrim
8. Kekeringan
9. Kebakaran Hutan dan Lahan
10.Kebakaran Gedung dan Pemukiman 11.Epidemi dan Wabah Penyakit 12.Gagal Teknologi
13.Konflik Sosial
c. Penilaian bahaya dapat ditetapkan langsung oleh kepala negara atau daerah berdasarkan masukan dari para pakar di bidangnya.
Pembobotan penilaian bahaya dibedakan menjadi dua (2) yaitu skala probabilitas dan skala dampak. Penentuan skala probabilitas berdasarkan pada prediksi waktu kemungkinan terjadinya suatu bencana disaat penilaian bahaya dilakukan dengan pembobotan seperti berikut :
1. Skala 4, kemungkinan bencana terjadi dalam rentang waktu sampai dengan 6 bulan ke depan. Skala ini dapat diartikan dengan skala sangat sering.
2. Skala 3, kemungkinan bencana terjadi dalam rentang waktu 6 bulan - 1 tahun ke depan. Skala ini dapat diartikan dengan skala sering.
3. Skala 2, kemungkinan bencana terjadi dalam rentang waktu 1 – 5 tahun ke depan. Skala ini dapat diartikan dengan skala kadang-kadang.
4. Skala 1, kemungkinan bencana terjadi dalam rentang waktu di atas 5 tahun ke depan. Skala ini dapat diartikan dengan skala jarang.
(21)
Untuk skala probabilitas dihitung dengan menghitung jumlah kejadian bencana yang masuk, kemudian dilakukan rata-rata. Dari data rata-rata tersebut akan menjadi skala yang dibagi menjadi 4 skala.
Tabel 2.1 Skala Penilaian Bahaya
Skala Probabilitas 1 2 3 4
Keterangan Jarang Kadang-kadang Sering Sangat sering Periode waktu berdasarkan periode yang dinilai
Berikut parameter kejadian bencana yang digunakan dalam menghitung skala probabilitas:
1. Gempa Bumi
Tabel 2.2 Parameter Probabilitas Gempa Bumi
Parameter A B C D
Nilai pga < 0.2501 0.2501 – 0.475 0.476 - 0.70 > 0.70
2. Tsunami
Tabel 2.3 Parameter Probabilitas Tsunami
Parameter 1 2 3 4
Ketinggian < 1 m 1 m – 2 m 2 m – 3 m > 3 m 3. Banjir
Tabel 2.4 Parameter Probabilitas Banjir
Parameter 1 2 3 4
Zona Banjir < 1 m 1 m – 2 m 2 m – 3 m > 3 m 4. Tanah Longsor
Tabel 2.5 Parameter Probabilitas Tanah Longsor
Parameter 1 2 3 4
(22)
5. Letusan Gunung Api
Tabel 2.6 Parameter Probabilitas Letusan Gunung Api
Parameter 1 2 3 4
Peta KRB KRB I KRB II KRB III KRB IV 6. Gelombang Ekstrim dan Abrasi
Tabel 2.7 Parameter Probabilitas Gelombang Ekstrim dan Abrasi
Parameter 1 2 3 4 Persen
Tinggi Gelombang
< 1 m 1 m – 1.75 m
1.76 m – 2.5 m > 2.5 m 30 % Arus (current) < 0.2 0.2 – 0.3 0.3 - 0.4 > 0.4 30 % Tutupan Lahan /
Vegetasi
<40 % 40 % - 60 %
61 % - 80 % > 80 % 25 % Bentuk garis
pantai
berteluk Lurus - berteluk
Lurus - berteluk lurus 15 %
7. Cuaca Ekstrim
Tabel 2.8 Parameter Probabilitas Cuaca Ekstrim
Parameter 1 2 3 4
Lahan terbuka Skor bahaya = (0.3333 * Lahan Terbuka) + (0.3333 * (1 -Kemiringan Lereng)) + (0.3333*(Curah Hujan Tahunan / 5000))
Kemiringan Lereng Curah Hujan Tahunan
Skor Bahaya < 0.25 0.25 – 0.50 0.51 - 0.75 >0.75 8. Kekeringan
Tabel 2.9 Parameter Probabilitas Kekeringan
Parameter 1 2 3 4
Peta rendah sedang tinggi Sangat tinggi
9. Kebakaran Hutan dan Lahan
Tabel 2.10 Parameter Probabilitas Kebakaran Hutan dan Lahan
Parameter 1 2 3 4
(23)
10.Kebakaran Gedung dan Pemukiman
Tabel 2.11 Parameter Probabilitas Kebakaran Gedung dan Pemukiman
Parameter 1 2 3 4
Durasi Pemadaman <3 jam 3 – 15 jam 15–24 jam >24 jam 11.Epidemi dan Wabah Penyakit
Tabel 2.12 Parameter Probabilitas Epidemi dan Wabah Penyakit
Parameter 1 2 3 4
Kepadatan Timbulnya Malaria (KTM)
Skor bahaya =(0.25*(KTM/10)) +
(0.25*(KTDB/5)) + (0.25*(KTHIV/0.05)) + (0.25*(KTC/5)) Kepadatan Timbulnya Demam Berdarah (KTDB) Kepadatan Timbulnya HIV/AIDS (KTHIV) Kepadatan Timbulnya Campak (KTC)
Skor Bahaya < 0.25 0.25 – 0.50 0.51 - 0.75 >0.75 12.Gagal Teknologi
Tabel 2.13 Parameter Probabilitas Gagal Teknologi
Parameter 1 2 3 4
Kapasitas Industri kecil Industri menengah Industri besar Industri sangat besar
13.Konflik Sosial
Tabel 2.14 Parameter Probabilitas Konflik Sosial
Parameter 1 2 3 4
Dampak kejadian <5 org 5 – 10 org 11–20 org >20 org
Penentuan skala dampak kerugian berpatokan pada luas wilayah terdampak dengan pembobotan seperti berikut :
1. Skala 4, sangat parah (81% - 100% wilayah hancur dan atau lumpuh total). 2. Skala 3, parah (51% - 80% wilayah hancur).
(24)
3. Skala 2, sedang (31% - 50% wilayah rusak). 4. Skala 1, ringan (10% - 30% wilayah rusak).
Berikut parameter kejadian bencana yang digunakan dalam menghitung skala dampak:
1. Gempa Bumi
Tabel 2.15 Parameter Dampak Gempa Bumi
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 30 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
40 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 2. Tsunami
Tabel 2.16 Parameter Dampak Tsunami
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 30 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
40 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 3. Banjir
Tabel 2.17 Parameter Dampak Banjir
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 30 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Rawa 20 < 5 ha 5 – 10 ha 11 – 20 ha > 20 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2
(25)
4. Tanah Longsor
Tabel 2.18 Parameter Dampak Tanah Longsor
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 40 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 40 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 5. Letusan Gunung Api
Tabel 2.19 Parameter Dampak Letusan Gunung Api
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 40 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 40 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 6. Gelombang Ekstrim dan Abrasi
Tabel 2.20 Parameter Dampak Gelombang Ekstrim dan Abrasi
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 10 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
40 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Rawa 10 < 5 ha 5 – 10 ha 11 – 20 ha > 20 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2
(26)
7. Cuaca Ekstrim
Tabel 2.21 Parameter Dampak Cuaca Ekstrim
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 10 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
40 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Rawa 10 < 5 ha 5 – 10 ha 11 – 20 ha > 20 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 8. Kekeringan
Tabel 2.22 Parameter Dampak Kekeringan
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 35 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 35 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 20 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 9. Kebakaran Hutan dan Lahan
Tabel 2.23 Parameter Dampak Kebakaran Hutan dan Lahan
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 40 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 40 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2
(27)
10.Kebakaran Gedung dan Pemukiman
Tabel 2.24 Parameter Dampak Kebakaran Gedung dan Pemukiman
Daerah Bobot
(%)
1 2 3 4
Rumah 40 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Fasilitas Umum 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Fasilitas Kritis 30 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 11.Epidemi dan Wabah Penyakit
Tabel 2.25 Parameter Dampak Epidemi dan Wabah Penyakit
Daerah Bobot
(%)
1 2 3 4
Hutan Bakau / mangrove
50 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Rawa 50 <5 ha 5 – 12 ha 13 – 20 ha > 20 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 12.Gagal Teknologi
Tabel 2.26 Parameter Dampak Gagal Teknologi
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 40 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
30 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 13.Konflik Sosial
Tabel 2.27 Parameter Dampak Konflik Sosial
Daerah Bobot
(%)
1 2 3 4
Hutan Lindung 30 < 20 ha 20 – 30 ha 31 – 50 ha > 50 ha Hutan Alam 30 < 25 ha 25 – 50 ha 51 – 75 ha > 75 ha Hutan Bakau /
mangrove
(28)
Daerah Bobot (%)
1 2 3 4
Semak Belukar 10 < 10 ha 10 – 20 ha 21 – 30 ha > 30 ha Rawa 10 < 5 ha 5 – 10 ha 11 – 20 ha > 20 ha Kepadatan
Penduduk
100 < 500 jiwa/km2
501–750 jiwa/km2
751–1000 jiwa/km2
>1000 jiwa/km2 2.7SMS Gateway
Short Message Service (SMS) (Talukder, 2010), merupakan sebuah layanan yang banyak diaplikasikan pada sistem komunikasi tanpa kabel, memungkinkan dilakukannya pengiriman pesan dalam bentuk teks. SMS didukung oleh GSM (Global System For Mobile Communication), TDMA (Time Division Multiple Access), CDMA (Code Division Multiple Access) yang berbasis pada telepon seluler yang saat ini banyak digunakan.
SMS Gateway merupakan pintu gerbang atau jalur informasi suatu sistem untuk mengirimkan pesan informasi berdasarkan kebutuhan user dimana pintu gerbang tersebut adalah server yang bertugas sebagai media penghubung user dengan nomor ponsel yang dituju. SMS Gateway adalah sebuah perangkat lunak yang menggunakan bantuan komputer dan memanfaatkan teknologi seluler yang digunkaan untuk mendistribusikan maupun menerima pesan melalui sistem informasi dimana SMS tersebut dapat dikirim ke banyak nomor secara otomatis dan praktis. Adapun fungsi dan fitur SMS Gateway antara lain :
1. Komunikasi SMS interaktif dua arah. 2. SMS info on demand.
3. SMS Automatic Registration. 4. Polling SMS
5. Pengiriman SMS Broadcast. 6. Pengiriman SMS ke Call Group.
(29)
7. Pengiriman SMS terjadwal.
2.8PHP
Hypertext Prepocessor atau PHP (Saputra, 2012), merupakan suatu bahasa pemrograman yang difungsikan untuk membangun suatu website dinamis. PHP menyatu dengan kode HTML, maksudnya adalah beda kondisi. HTML digunakan sebagai pembangun atau pondasi dari kerangka layout web, sedangkan PHP difungsikan sebagai prosesnya sehingga dengan adanya PHP tersebut, web akan sangat mudah di-maintenance. PHP berjalan pada sisi server sehingga PHP disebut juga sebagai bahasa Server Side Scripting. Dalam menjalankan PHP, wajib adanya web server. PHP ini bersifat open source sehingga dapat dipakai secara cuma-cuma dan mampu lintas platform, yaitu dapat berjalan pada sistem operasi Windows maupun Linux. PHP juga dibangun sebagai modul pada web server apache dan sebagai binary yang dapat berjalan sebagai CGI.
2.9Siklus Hidup Pengembangan Sistem
Siklus hidup pengembangan sistem adalah nama lain dari System Development Life Cycle (SDLC) ini merupakan suatu proses pengembangan atau perubahan pada suatu perangkat lunak. Pengembangan atau perubahan tersebut dilakukan dengan cara menggunakan model-model dan metodologi yang digunakan oleh banyak orang yang telah mengembangkan sistem-sistem perangkat lunak sebelumnya. Hal itu berdasarkan oleh best practice atau cara-cara yang sudah teruji baik.
(30)
2.10 Tahapan SDLC
2.10.1 Kebutuhan Perangkat Lunak
Kebutuhan perangkat lunak dapat diartikan sebagai properti yang harus dipamerkan dalam rangka memecahkan beberapa masalah di dunia nyata (IEEE Computer Society, 2014). Dalam menentukan kebutuhan perangkat lunak, yang pertama perlu harus diperhatikan setelah definisi dari kebutuhan perangkat lunak adalah jenis dari kebutuhan tersebut seperti apakah produk atau proses, fungsional atau non-fungsional, dan properti yang akan muncul. Keseluruhan proses tersebut dapat menjelaskan perbedaan antara kebutuhan sistem dan perangkat lunak.
Kedua yaitu, proses dari kebutuhan itu sendiri. Didalamnya digambarkan model, aktor, dukungan dan manajemen, kualitas dan pengembangan dari proses itu sendiri. Ketiga yaitu, elisitasi kebutuhan yang menjelaskan darimana kebutuhan perangkat lunak berasal dan bagaimana caranya mendapatkannya. Keempat yaitu, analisis kebutuhan yang membahas konflik antar kebutuhan, interaksi perangkat lunak dengan lingkungan sekitar, dan mengkolaborasikan antara kebutuhan sistem dengan perangkat lunak. Selain itu, termasuk di dalamnya klasifikasi kebutuhan, pemodelan konseptual, desain arsitektur dan alokasi kebutuhan, dan negosiasi kebutuhan.
Kelima yaitu, spesifikasi kebutuhan yang menhasilkan dokumen spesifikasi kebutuhan perangkat lunak. Keenam yaitu, validasi kebutuhan yang memastikan kebutuhan perangkat lunak yang diabarkan benar-benar telah sesuai sebelum digunakan. Yang terakhir, ketujuh yaitu, pertimbangan praktis, yang menggambarkan beberapa topik yang perlu dupahami dalam pelaksanaannya.
(31)
Topik itu seperti sifat berulangnya sebuah proses, manajemen dan pemeliharaan, dan pengukuran kebutuhan
2.10.2 Analisis dan Desain Perangkat Lunak
a. System Flow
System flow atau bagan alir sistem merupakan bagan yang menunjukkan arus pekerjaan secara keseluruhan dari sistem. System flow menunjukkan urutan-urutan dari prosedur yang ada di dalam sistem dan menunjukkan apa yang dikerjakan sistem. Simbol-simbol yang digunakan dalam system flow ditunjukkan pada Gambar 2.1
Mengenai penjelasan dari simbol-simbol yang digunakan dalam system flow adalah sebagai berikut
1. Simbol Dokumen
Menunjukkan dokumen input dan output baik untuk proses manual atau komputer.
2. Simbol Kegiatan Manual
Menunjukkan pekerjaan manual. 3. Simbol Simpanan Offline
Menunjukkan file non-komputer yang diarsip. 4. Simbol Proses
Menunjukkan kegiatan proses dari operasi program komputer. 5. Simbol Database
Menunjukkan tempat untuk menyimpan data hasil operasi komputer. 6. Simbol Garis Alir
(32)
7. Simbol Penghubung
Menunjukkan penghubung ke halaman yang masih sama atau ke halaman lain.
Gambar 2.1 Simbol-simbol pada System Flow
b. Data Flow Diagram (DFD)
DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik di tempat data tersebut mengalir. DFD merupakan alat yang digunakan pada metodologi pengembangan sistem yang terstruktur dan dapat mengembangkan arus data di dalam sistem dengan terstruktur dan jelas.
DFD fokus pada aliran data dari dan ke dalam sistem serta memproses data yang mengalir tersebut (Kendall dan Kendall, 2003). Simbol-simbol dasar dalam DFD yaitu :
1. External Entity
Suatu External entity atau entitas merupakan orang, kelompok, departemen, atau sistem lain di luar sistem yang dibuat dapat menerima atau memberikan
1. Simbol Dokumen
2. Simbol Kegiatan Manual
3. Simbol Simpanan Offline
4. Simbol Proses
5. Simbol Database
6. Simbol Garis Alir
7. Simbol Penghubung ke Halaman yang Sama
(33)
informasi atau data ke dalam sistem yang dibuat. Gambar 2.2 merupakan simbol entitas dalam DFD dalam model Gane. Suatu External entity atau entitas merupakan orang, kelompok, departemen, atau sistem lain di luar sistem yang dibuat dapat menerima atau memberikan informasi atau data ke dalam sistem yang dibuat.
Gambar 2.2 Simbol External Entity
2. Data Flow
Data flow atau aliran data disimbolkan dengan tanda panah. Data flow menunjukkan arus data atau aliran data yang menghubungkan dua proses atau entitas dengan proses. Gambar 2.3 merupakan simbol data flow.
Gambar 2.3 Simbol Data Flow
3. Process
Suatu process meliputi beberapa tindakan atau sekelompok tindakan dari arus data yang masuk untuk dijalankan atau diproses agar menghasilkan arus data yang akan keluar dari proses. Gambar 2.4 merupakan simbol Process.
(34)
Gambar 2.4 Simbol Process
4. Data Store
Data store adalah simbol yang digunakan untuk melambangkan proses penyimpanan data. Suatu nama perlu diberikan pada Data Store untuk menunjukkan nama dari file-nya. Gambar 2.5 merupakan simbol file penyimpanan / data store yang dapat berupa hal-hal sebagai berikut, sebagai gambaran:
1. Suatu file atau Database di sistem komputer. 2. Suatu arsip atau catatan manual.
3. Suatu tabel acuan manual.
Gambar 2.5 Simbol Data Store
Berikut ini adalah urutan langkah bagaimana menggambarkan suatu sistem pada DFD:
1. Context Diagram
Context diagram merupakan langkah pertama dalam pembuatan data flow diagram. Pada context diagram dijelaskan sistem apa yang dibuat dan entity apa saja yang digunakan. Dalam context diagram harus ada arus data yang masuk dan arus data yang keluar.
2. Data Flow Diagram Level 0
0
Proc es s
(35)
DFD level 0 adalah langkah selanjutnya setelah context diagram. Hal yang digambarkan dalam Diagram level 0 ini adalah proses utama dari sistem serta hubungan entity, process, data flow dan data store.
3. Data Flow Diagram Level 1
DFD level 1 merupakan penjelasan dari DFD level 0. Pada proses ini dijelaskan proses apa saja yang dilakukan pada setiap proses yang terdapat di DFD level 0.
c. Entity Relationship Diagram (ERD)
Entity Relationship Diagram (ERD) adalah gambaran pada sistem yang di dalamnya terdapat hubungan antara entity beserta relasinya. Entity merupakan sesuatu yang ada dan terdefinisikan di dalam suatu organisasi, dapat abstrak dan nyata. Untuk setiap entity biasanya mempunyai attribute yang merupakan ciri entity tersebut. Menurut Marlinda (2004), attribute memiliki pengertian kolom di sebuah relasi. Macam-macam attribute yaitu :
1. Simple Attribute
Attribute ini merupakan attribute yang unik dan tidak dimiliki oleh attribute lainnya, misalnya entity mahasiswa yang attribute-nya NIM.
2. Composite Attribute
Composite attribute adalah attribute yang memiliki dua nilai harga, misalnya nama besar (nama keluarga) dan nama kecil (nama asli).
3. Single Value Attribute
Attribute yang hanya memiliki satu nilai harga, misalnya entity mahasiswa dengan attribute-nya umur (tanggal lahir).
(36)
Multi value attribute adalah attribute yang banyak memiliki nilai harga, misalnya entity mahasiswa dengan attribute-nya pendidikan (SD, SMP, SMA). 5. Null Value Attribute
Null value attribute adalah attribute yang tidak memiliki nilai harga, misalnya entity tukang becak dengan attribute-nya pendidikan (tanpa memiliki ijazah).
Relasi adalah hubungan antar entity yang berfungsi sebagai hubungan yang mewujudkan pemetaan antar entity. Macam-macam relasi itu sendiri antara lain :
1. One To One (1:1)
Relasi dari entity satu dengan entity dua adalah satu berbanding satu. Contoh: Pada pelajaran privat, satu guru mengajar satu siswa dan satu siswa hanya diajar oleh satu guru.
2. One To Many (1:m)
Relasi antara entity yang pertama dengan entity yang kedua adalah satu berbanding banyak atau dapat pula dibalik, banyak berbanding satu. Contoh: Pada sekolah, satu guru mengajar banyak siswa dan banyak siswa diajar oleh satu guru.
Entity relationship diagram ini diperlukan agar dapat menggambarkan hubungan antar entity dengan jelas, dapat menggambarkan batasan jumlah entity dan partisipasi antar entity, mudah dimengerti pemakai dan mudah disajikan oleh perancang database. Untuk itu entity relationship diagram dibagi menjadi dua jenis model, yaitu :
(37)
CDM adalah jenis model data yang menggambarkan hubungan antar tabel secara konseptual.
2. Physical Data Model (PDM)
PDM adalah jenis model data yang menggambarkan hubungan antar tabel secara fisikal.
2.10.3 Konstruksi Perangkat Lunak
Pada tahap ini ialah melakukan konversi hasil desain ke sistem informasi yang lengkap melalui tahapan coding atau pengkodean termasuk bagaimana, membuat basis data dan menyiapkan prosedur kasus pengujian, mempersiapkan berkas atau file pengujian, pengodean pengompilasian, memperbaiki dan membersihkan program serta melakukan peminjaman pengujian. Construction ini memiliki beberapa tahapan secara umum. (IEEE Computer Society, 2014).
a. Software Construction Fundamentals
Pada tahap pertama yaitu dilakukan pendefinisian dasar tentang prinsip-prinsip yang digunakan dalam proses implementasi seperti minimalisasi kompleksitas, mengantisipasi perubahan, dan standar yang digunakan.
b. Managing Construction
Bagian ini mendefinisikan tentang model implementasi yang digunakan, rencana implementasi, dan ukuran pencapaian dari implementasi tersebut. c. Practical Considerations
Bagian ini membahas tentang desain implementasi yang digunakan, bahasa pemrograman yang digunakan, kualitas dari implementasi yang dilakukan, proses pengetesan dan integritas.
(38)
2.10.4 Uji Coba Perangkat Lunak
Pengujian program dilakukan untuk mengetahui kesesuaian sistem berjalan sesuai prosedur atau tidak dan memastikan sistem terhindar dari error yang terjadi (IEEE Computer Society, 2014). Testing juga dapat digunakan untuk memastikan kevalidan dalam proses input, sehingga dapat menghasilkan output yang sesuai. Pada tahap ini, uji coba perangkat lunak yang digunakan yaitu metode black-box. Pengujian dengan metode black-box merupakan pengujian yang menekankan pada fungsionalitas dari sebuah perangkat lunak tanpa harus mengetahui bagaimana struktur di dalam perangkat lunak tersebut. Sebuah perangkat lunak yang diuji menggunakan metode black-box dikatakan berhasil jika fungsi-fungsi yang ada telah memenuhi spesifikasi kebutuhan yang telah dibuat sebelumnya. Metode black-box yang digunakan adalah dengan menguji form dan fungsi dari penilaian bahaya.
(39)
34 BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1Uraian Permasalahan
Identifikasi masalah yang ada di Pusdalops-PB Jawa Timur adalah penilaian bahaya terhadap bencana. Penilaian bahaya ini digunakan untuk menyusun dokumen rencana kontingensi. Rencana kontingensi adalah rencana terintegrasi yang berisi upaya-upaya yang dilakukan oleh pemerintah provinsi, masyarakat serta lembaga usaha dalam menghadapi ancaman bencana.
Menurut hasil wawancara dan observasi yang telah dilakukan, selama ini penilaian bahaya sering kali tidak valid dikarenakan Pusdalops PB menilai bencana hanya dengan memperkirakan saja tanpa ada perhitungan mengenai bencana tersebut. Perkiraan penilaian ini dikarenakan rekap laporan yang tidak dapat diolah lebih lanjut menjadi penilaian bahaya. Oleh sebab itu, perhitungan penilaian bahaya masih bersifat manual sehingga sering kali terjadi kesalahan pada penentuan nilai bahaya. Bencana yang seharusnya masuk dalam nilai skala yang besar tetapi keliru dalam menempatkan di nilai skala yang lebih kecil. Hal ini yang menyebabkan penilaian bahaya menjadi tidak valid.
Wawancara dan observasi dilakukan pada bulan Desember 2014 hingga Maret 2015, bertempat di kantor BPBD Jawa Timur. Obyek wawancara yaitu perwira jaga sebanyak 6 orang, informan sebanyak 6 orang dan kepala BPBD Kota sebanyak 6 orang.
(40)
3.2Analisis Permasalahan
Proses penetapan penilaian bahaya dimulai dari pembuatan laporan harian. Proses pembuatan dan pengumpulan laporan harian terdapat beberapa permasalahan.
1. Petugas jaga kesulitan dalam memasukkan informasi ke laporan harian. Untuk memasukkan informasi, petugas harus menulis terlebih dahulu di kertas. Hal ini dilakukan karena petugas dalam menerima informasi dapat melalui telepon atau radio sehingga butuh ditulis terlebih dahulu. Setelah ditulis, kemudian diketik ke worksheet. Permasalahan ini menyebabkan waktu memasukkan informasi menjadi lebih lama.
2. File rekap tidak dapat menghasilkan penilaian bahaya secara langsung.
File rekap yang berupa worksheet tidak dapat menghasilkan penilaian bahaya serta penilaian tersebut masih bersifat manual tanpa perhitungan sehingga penilaian bahaya yang dihasilkan menjadi tidak akurat. Tidak akurat artinya nilai yang dihasilkan tidak sesuai dengan kondisi yang sebenarnya setelah nilai tersebut dimasukkan dalam dokumen rencana kontingensi. Ditambah lagi, sistem yang sekarang masih menggunakan aplikasi worksheet yang terikat dengan sistem operasi tertentu. Sistem ini menyebabkan petugas kesulitan mengakses sistem tersebut jika tidak berada ditempat. Sistem yang sekarang juga masih belum realtime, artinya sistem masih belum menghasilkan respon yang tepat dan cepat dalam menghitung penilaian bahaya.
Untuk mengatasi permasalahan yang dihadapi, maka Pusdalops PB perlu dibuat sebuah sistem yang dapat melakukan penilaian bahaya terhadap bencana yang dapat menilai potensi bahaya dari bencana di Jawa Timur. Sistem ini berbasis
(41)
web karena dapat diakses oleh petugas serta kepala Pusdalops dimanapun dan kapanpun tanpa harus melakukan penginstalan serta dapat dijalankan di berbagai sistem operasi serta bersifat realtime. Dengan adanya sistem yang realtime, maka petugas dapat mengetahui kondisi data secara cepat.
Sistem ini dimulai dari informan memasukkan data mengenai bencana. Data tersebut dapat langsung di masukkan kedalam website maupun melalui SMS. Sistem tersebut akan mengolah data SMS menjadi laporan harian. Kemudian sistem akan melakukan rekap laporan berdasarkan periode tertentu hingga nantinya sistem akan menghasilkan penilaian bahaya dari data rekap laporan. Sistem akan menetapkan penilaian bahaya berdasarkan metode scoring yang tertera dalam buku pedomen rencana kontingensi. Sistem ini berbeda dengan sistem yang sedang digunakan, dimana sistem yang sekarang masih belum bisa secara langsung menilai bahaya. Sistem ini dapat menampilkan informasi berupa grafik dan peta daerah yang berbahaya di Jawa Timur. Peta daerah yang berbahaya akan menampilkan informasi kejadian bencana pada setiap kecamatan. Dengan adanya aplikasi penilaian bahaya maka kendala dalam penilaian bahaya di Pusdalops PB Jawa Timur dapat diselesaikan.
(42)
3.3Perancangan Sistem
Setelah dilakukan analisis terhadap sistem, maka langkah selanjutnya adalah perancangan sistem. Perancangan sistem ini bertujuan untuk mendefinisikan kebutuhan-kebutuhan fungsional, menggambarkan aliran data dan alur sistem, dan sebagai tahap persiapan sebelum implementasi sistem. Perancangan sistem ini diharapkan dapat merancang dan mendesain sistem dengan baik, yang isinya meliputi langkah-langkah operasi dalam proses pengolahan data dan prosedur untuk mendukung operasi sistem.
Arsitektur aplikasi penilaian bahaya dijelaskan pada gambar berikut.
(43)
Gambar 3.1 merupakan desain arsitektur aplikasi penilaian bahaya dimana aplikasi tersebut menerima data dari informan. Data tersebut berupa SMS. SMS ini nantinya akan masuk kedalam server kemudian akan terekam dalam log sheet. Log sheet adalah kumpulan data kejadian bencana di Jawa Timur. Log sheet nantinya akan menjadi bahan petugas Pusdalops PB untuk membuat laporan informasi. Laporan informasi ini nantinya akan direkap kemudian menjadi rekap laporan. Data pada rekap laporan nantinya akan menjadi bahan untuk penilaian bahaya. Data kejadian bencana nantinya akan ditampilkan dengan peta dan grafik. Untuk petanya akan menampilkan informasi kejadian bencana pada setiap kecamatan sedangkan untuk grafik akan menampilkan statistik kejadian dan bencana. Data SMS ini dikirim dengan menggunakan format tertentu. Berikut format SMS yang digunakan: 1. Info
Format SMS Info digunakan ketika informan ingin menyampaikan informasi berkaitan dengan kejadian bencana tersebut. Informasi ini seperti kronologi kejadian bencana, jumlah korban, upaya yang sudah dilakukan, dll.
INFO/<TANGGAL>/<KOTA>/<KECAMATAN>/<NAMA_BENCANA>/< NAMA_PERISTIWA>/<ISI_INFORMASI>/<ISI_INFORMASI2>/<ISI_IN FORMASI3>
2. Lapor
Format SMS Lapor digunakan ketika informan ingin menyampaikan laporan berkaitan dengan kejadian bencana tersebut berdasarkan parameter kejadian bencana. SMS Lapor ini yang nantinya akan dinilai kadar bahayanya.
(44)
LAPOR/<TANGGAL>/<KOTA>/<KECAMATAN>/<KATEGORI>/< NAMA_BENCANA>/<NAMA_PERISTIWA>/<PARAMETER>/<NIL AI_PARAMETER>
b. Banyak parameter
LAPOR/<TANGGAL>/<KOTA>/<KECAMATAN>/<KATEGORI>/< NAMA_BENCANA>/<NAMA_PERISTIWA>/<PARAMETER1>/<NI LAI_PARAMETER1>/<PARAMETER2>/<NILAI_PARAMETER2> 3. Help
Format SMS Help digunakan ketika informan ingin mengetahui format SMS penilaian bahaya dan ID Peristiwa dalam suatu kejadian bencana. Formatnya sebagai berikut:
a. Bantuan format SMS HELP
b. Bantuan ID Peristiwa
HELP/<ID_KEJADIAN_BENCANA>
Jika SMS tidak sesuai dengan format maka sistem akan mengirimkan SMS balasan yang menyatakan ketidaksesuaian dengan format. Batas estimasi ketidaksesuaian format ini sebanyak 5 kali, jika lebih dari itu maka nomor tersebut akan diblokir. Hal ini sebagai upaya mengantisipasi adanya bom SMS. Oleh sebab itu, nomor informan harus terdaftar didalam sistem. Nomor yang terdaftar nantinya akan dijadikan sebagai acuan untuk diolah atau tidaknya SMS yang dikirimkan.
Langkah-langkah operasi dalam perancangan sistem ini adalah sebagai berikut :
(45)
b. System Flow.
c. Diagram Jenjang Proses.
d. Data Flow Diagram (DFD), yang didalamnya terdapat : Context Diagram, DFD Level 0, dan DFD Level 1.
e. Entity Relationship Diagram (ERD), yang didalamnya meliputi : Conceptual Data Model (CDM), dan Physical Data Model (PDM).
f. Desain Input Output.
3.3.1 Document Flow Penilaian Bahaya
Document Flow merupakan bagan yang menunjukkan aliran atau arus dokumen dari satu bagian ke bagian yang lain di dalam sistem secara logika. Document flow juga menggambarkan tiap-tiap bagian organisasi yang terlibat dalam pengolahan dokumen di dalam tiap-tiap proses. Namun, proses yang digambarkan dalam document flow adalah proses manual atau proses yang selama ini dikerjakan Pusdalops tanpa adanya sebuah sistem yang membantu menangani proses tersebut.
Sehubungan dengan itu dibawah ini akan digambarkan aliran dokumen penilaian bahaya yang selama ini terjadi pada Pusdalops-PB Jawa Timur. Secara umum ada tiga bagian atau entitas dalam aliran dokumen ini, yaitu informan, Perwira Jaga dan Kepala Pusdalops.
(46)
Gambar 3.2 Document Flow Penilaian Bahaya
3.3.2 System Flow Penilaian Bahaya
System flow adalah penggambaran aliran dokumen dalam sistem dan merupakan proses kerja dalam sistem. System flow ini juga representasi aliran data lanjutan dari document flow. Jika document flow menggambarkan aliran data secara manual atau yang selam ini terjadi diorganisasi, maka system flow ini menggambarkan aliran data pada sistem yang nantinya akan dibangun untuk membantu proses dalam organisasi. Tentunya, transformasi aliran dokumen ini
(47)
lebih efektif dalam menjalankan proses organisasi, sehingga proses tersebut bisa dikerjakan dengan cepat dan hasilnya akurat.
System Flow pada aplikasi ini dapat dibagi menjadi empat (4) yang akan dijelaskan pada sub bab berikut.
A. Mengelola Data Master
System flow mencatat data master ini terdiri dari tujuh (7) data master, dimana system flow tiap-tiap data master tersebut memiliki kemiripan model yang hampir sama. Data master yang harus dicatat adalah data kota, data kecamatan, data informan, data jenis bencana, data parameter probabilitas dan data parameter dampak.
1. Mengelola data kota
Pada system flow mencatat data kota menjelaskan bahwa untuk dapat mengelola data kota maka terlebih dahulu memasukkan data secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel kota. Sistem juga dapat menampilkan data kota yang diambil dari tabel kota. Desain system flow mencatat data kota dapat dilihat pada Gambar 3.3.
(48)
Gambar 3.3 System Flow Mengelola Data Master Kota
2. Mengelola data kecamatan
Pada system flow mencatat data kecamatan menjelaskan bahwa untuk dapat mengelola data kecamatan maka terlebih dahulu memilih kota kemudian memasukkan data kecamatan secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel kecamatan. Sistem juga dapat menampilkan data kecamatan yang diambil dari tabel kecamatan. Desain system flow mencatat data kecamatan dapat dilihat pada Gambar 3.4
(49)
Gambar 3.4 System Flow Mengelola Data Master Kecamatan
3. Mengelola data informan
Pada system flow mencatat data informan menjelaskan bahwa untuk dapat mengelola data informan maka terlebih dahulu memilih kota kemudian memasukkan data informan secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel informan. Sistem juga dapat menampilkan data informan yang diambil dari tabel informan. Desain system flow mencatat data informan dapat dilihat pada Gambar 3.5.
(50)
Gambar 3.5 System Flow Mengelola Data Master Informan
4. Mengelola data jenis bencana
Pada system flow mencatat data jenis bencana menjelaskan bahwa untuk dapat mengelola data jenis bencana maka terlebih dahulu memasukkan data secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel jenis bencana. Sistem juga dapat menampilkan data jenis bencana yang diambil dari tabel jenis bencana.
(51)
Desain system flow mencatat data jenis bencana dapat dilihat pada Gambar 3.6.
Gambar 3.6 System Flow Mengelola Data Master Jenis Bencana
5. Mengelola data peristiwa
Pada system flow mencatat data peristiwa menjelaskan bahwa untuk dapat mengelola data peristiwa maka terlebih dahulu memasukkan data secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel peristiwa. Sistem juga dapat menampilkan data peristiwa yang diambil dari tabel peristiwa. Desain system flow mencatat data peristiwa dapat dilihat pada Gambar 3.7.
(52)
Gambar 3.7 System Flow Mengelola Data Master Peristiwa
6. Mengelola data parameter probabilitas
Pada system flow mencatat data parameter probabilitas menjelaskan bahwa untuk dapat mengelola data parameter probabilitas maka terlebih dahulu memilih jenis bencana kemudian memasukkan data parameter probabilitas secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel parameter probabilitas. Sistem juga dapat menampilkan data parameter probabilitas yang
(53)
diambil dari tabel parameter probabilitas. Desain system flow mencatat data parameter probabilitas dapat dilihat pada Gambar 3.8.
Gambar 3.8 System Flow Mengelola Data Master Parameter Probabilitas
7. Mengelola data parameter dampak.
Pada system flow mencatat data parameter dampak menjelaskan bahwa untuk dapat mengelola data parameter dampak maka terlebih dahulu memilih jenis bencana kemudian memasukkan data parameter dampak secara manual. Setelah itu, sistem akan melakukan proses penyimpanan ke dalam tabel parameter dampak. Sistem juga dapat
(54)
menampilkan data parameter dampak yang diambil dari tabel parameter dampak. Desain system flow mencatat data parameter dampak dapat dilihat pada Gambar 3.9.
Gambar 3.9 System Flow Mengelola Data Master Parameter Dampak
B. Mencatat Data Informasi
Pada system flow mencatat data informasi melalui SMS, menjelaskan bahwa proses ini dimulai dengan memasukkan data kejadian bencana. Data kejadian bencana diperoleh dari informan yang memberikan data info maupun data lapor. Data info adalah data yang isinya menginformasikan berita yang terkait dengan bencana sedangkan data lapor adalah data yang nantinya akan dinilai bahayanya. Data kejadian bencana ini akan disimpan terlebih dahulu di tabel
(55)
kejadian bencana kemudian dipilah. Jika termasuk data informasi maka akan disimpan di tabel informasi. Namun jika tidak termasuk data informasi maka data tersebut akan diproses pada penilaian bahaya.
Gambar 3.10 System Flow Mencatat Data Informasi melalui SMS
Pada system flow mencatat data informasi melalui Web, menjelaskan bahwa proses ini dimulai dengan memasukkan data kejadian bencana. Data kejadian bencana diperoleh dari informan yang memberikan data info. Data kejadian bencana ini akan langsung disimpan di tabel kejadian bencana. Proses selanjutnya data informasi akan disimpan di tabel informasi.
(56)
Gambar 3.11 System Flow Mencatat Data Informasi melalui Web
C. Menentukan Penilaian Bahaya
Pada system flow menentukan penilaian bahaya melalui SMS, menjelaskan bahwa dalam menentukan penilaian bahaya dimulai dengan mengambil data kejadian bencana, jenis bencana, data parameter dampak dan data parameter probabilitas. Data kejadian bencana, jenis bencana, data parameter dampak dan data parameter probabilitas diperoleh dari informan yang dimasukkan pada proses sebelumnya. Data yang sudah diambil, akan dihitung nilai bahayanya kemudian nilai dari data tersebut akan ditampilkan.
(57)
Gambar 3.12 System Flow Menentukan Penilaian Bahaya melalui SMS
Pada system flow menentukan penilaian bahaya melalui web, menjelaskan bahwa dalam menentukan penilaian bahaya dimulai dengan memasukkan data besaran kejadian bencana kemudian jenis bencana, data parameter dampak dan data parameter probabilitas. Data kejadian bencana, jenis bencana, data parameter dampak dan data parameter probabilitas diperoleh dari informan yang dimasukkan pada proses sebelumnya. Data yang sudah diambil, akan dihitung nilai bahayanya kemudian nilai dari data tersebut akan ditampilkan.
(58)
Gambar 3.13 System Flow Menentukan Penilaian Bahaya melalui Web
D. Membuat Laporan
Pada system flow membuat laporan informasi, menjelaskan salah satu dari beberapa laporan yang harus ditampilkan. Laporan yang disediakan dalam sistem ini adalah laporan informasi, laporan peta dan laporan grafik. Proses membuat laporan informasi dimulai dengan mengambil data informasi. Kemudian menampilkan data tersebut hingga mencetaknya.
(59)
Gambar 3.14 System Flow Membuat Laporan Informasi
Pada system flow membuat laporan peta, menjelaskan salah satu dari beberapa laporan yang harus ditampilkan. Proses membuat laporan peta dimulai dengan mengambil data kejadian bencana, lapor dan jenis bencana. Kemudian menampilkan data tersebut menjadi peta. Sedangkan system flow membuat laporan peta, dimulai dengan mengambil data kejadian bencana, lapor dan jenis bencana.
(60)
Kemudian menampilkan data tersebut menjadi peta. System flow membuat laporan peta dapat dilihat pada Gambar 3.15.
Gambar 3.15 System Flow Membuat Laporan Peta
Pada system flow membuat laporan grafik, menjelaskan salah satu dari beberapa laporan yang harus ditampilkan. Proses membuat laporan grafik dimulai dengan mengambil data kejadian bencana, lapor dan jenis bencana. Kemudian menampilkan data tersebut menjadi grafik. Sedangkan system flow membuat laporan grafik, dimulai dengan mengambil data kejadian bencana, lapor dan jenis bencana. Kemudian menampilkan data tersebut menjadi grafik. System flow membuat laporan grafik dapat dilihat pada Gambar 3.16.
(61)
Gambar 3.16 System Flow Membuat Laporan Grafik
3.3.3 Diagram Jenjang Proses
Diagram Jenjang Proses adalah sarana dalam melakukan desain dan teknik dokumentasi dalam siklus pengembangan sistem yang berbasis pada fungsi. Tujuannya agar Diagram Jenjang Proses tersebut dapat memberikan informasi tentang fungsi-fungsi yang ada didalam sistem tersebut. Gambar Diagram Jenjang Proses dapat dilihat pada Gambar 3.17.
(62)
57 Gambar 3.17 Diagram Jenjang Proses
(63)
A. Context Diagram
Context Diagram adalah gambaran menyeluruh dari DFD. Di dalam Context Diagram terdapat tiga (3) External Entity yaitu Informan, Perwira Jaga dan Kepala BPBD. Proses pembuatan context diagram dimulai dari system flow yang menjelaskan alur sistem. Dalam alur sistem terdapat proses dan tabel yang dibutuhkan untuk menjalankan proses tersebut sehingga dapat diketahui alur data serta entitasnya.
Perwira Jaga memasukkan data informan, data kota, data kecamatan, data parameter probabilitas, data peristiwa dan data parameter dampak. Informan memasukkan data informasi dan data kejadian bencana melalui media SMS dan web. Informan juga menerima data SMS feedback informasi dan kejadian bencana. Kepala BPBD mendapatkan data hasil penilaian, laporan informasi, laporan peta dan laporan grafik. Gambar Context Diagram dapat dilihat pada Gambar 3.18.
(64)
59
Le
ve
l 0
(65)
60
Seperti gambar DFD Level 0 diatas, bahwa Gambar 3.19 ini memiliki lima (5) proses dan sepuluh (10) data store yang fungsinya masing-masing adalah penjabaran lebih lanjut tentang proses dalam sistem dan tabel yang digunakan dalam penyimpanan data. Selanjutnya, empat proses tersebut juga dijelaskan lebih detail kedalam DFD Level 1 berikut :
C. DFD Level 1 Mengelola Data Master
Pada DFD Level 1 mengelola data master terdapat tujuh (7) sub proses yaitu mengelola data kota, mengelola data kecamatan, mengelola data informan, mengelola data jenis bencana, mengelola data parameter probabilitas, mengelola data parameter dampak, dan mengelola data peristiwa. Sub proses mengelola data kota berfungsi untuk mengelola data-data kota. Sub proses mengelola data kecamatan berfungsi untuk mengelola data-data kecamatan. Sub proses mengelola data informan berfungsi untuk mengelola data-data informan. Sub proses mengelola data jenis bencana berfungsi untuk mengelola data-data jenis bencana. Sub proses mengelola data parameter probabilitas berfungsi untuk mengelola data-data parameter probabilitas. Sub proses mengelola data-data parameter dampak berfungsi untuk mengelola data-data parameter dampak. Sub proses mengelola data peristiwa berfungsi untuk mengelola data-data peristiwa.
(66)
Gambar 3.20 DFD Level 1 Mengelola Data Master
D. DFD Level 1 Mencatat Data Informasi
Pada DFD Level 1 mencatat data informasi terdapat dua (2) sub proses yaitu menyimpan data kejadian bencana dan menyimpan data informasi. Sub proses menyimpan data kejadian bencana berfungsi untuk menyimpan data web kejadian bencana dan sms kejadian bencana serta mengirimkan data sms feedback kejadian bencana. Sub proses menyimpan data informasi berfungsi untuk menyimpan data web informasi dan sms informasi serta mengirimkan data sms feedback informasi.
(67)
Gambar 3.21 DFD Level 1 Mencatat Data Informasi
E. DFD Level 1 Menentukan Penilaian Bahaya
Pada DFD Level 1 menentukan penilaian bahaya terdapat tiga (3) sub proses yaitu menghitung penilaian bahaya, menyimpan penilaian bahaya dan menampilkan penilaian bahaya. Sub proses menghitung penilaian bahaya berfungsi untuk menghitung penilaian bahaya. Sub proses menyimpan penilaian bahaya berfungsi untuk menyimpan penilaian bahaya. Sub proses menampilkan penilaian bahaya berfungsi untuk menampilkan penilaian bahaya.
(68)
F. DFD Level 1 Membuat Laporan
Pada DFD Level 1 membuat laporan terdapat tiga (3) sub proses yaitu membuat laporan informasi, membuat laporan peta dan membuat laporan grafik. Sub proses membuat laporan informasi berfungsi untuk membuat laporan informasi. Sub proses membuat laporan peta berfungsi untuk membuat laporan peta. Sub proses membuat laporan grafik berfungsi untuk membuat laporan grafik.
Gambar 3.23 DFD Level 1 Membuat Laporan
3.3.4 Entity Relationship Diagram
Menurut Kendall dan Kendall (2003), sebuah Entity Relationship Diagram (ERD) mendokumentasikan data sebuah perusahaan dengan cara menentukan data yang terdapat dalam tiap entitas dan relasi antara sebuah entitas dengan yang lainnya. Data flow diagram menggambarkan arus data yang ada dalam sistem, dari arus data tersebut maka akan diketahui kebutuhan tabel untuk penyimpanan data. Untuk mengelola data master maka dibutuhkan tabel master seperti kota,
(69)
kecamatan, informan, jenis bencana, peristiwa, parameter probabilitas dan parameter dampak. Untuk mencatat data transaksi maka dibutuhkan tabel kejadian bencana dan informasi. Kemudian untuk menentukan penilaian bahaya maka dibutuhkan tabel lapor. Entity Relationship Diagram dapat dilihat pada Gambar 3.24.
(70)
A. Conceptual Data Model
CDM dari aplikasi penilaian bahaya terdapat 10 tabel yang berasal dari kebutuhan penyimpanan data dari data flow diagram yaitu tabel informan, kota, kecamatan, jenis bencana, kejadian bencana, informasi, lapor, parameter dampak, parameter probabilitas, dan peristiwa. CDM sistem ini dapat dilihat pada Gambar 3.25.
Gambar 3.25 Conceptual Data Model
B. Physical Data Model
PDM dari aplikasi penilaian bahaya terdapat 10 tabel yaitu tabel informan, kota, kecamatan, jenis bencana, kejadian bencana, informasi, lapor, parameter dampak, parameter probabilitas, dan peristiwa. PDM sistem ini dapat dilihat pada Gambar 3.26.
(71)
Gambar 3.26 Physical Data Model
3.3.5 Struktur Database A. Tabel Informan
Nama tabel : Informan Primary key : ID_Informan
Foreign key : ID_Kota, ID_BPBD_Kota Fungsi : Menyimpan data informan
Tabel 3.1 Informan
No Field Name Data Type Length Constraint
1 ID_Informan Integer PK
2 ID_Kota Integer FK
(72)
No Field Name Data Type Length Constraint
4 No_Telp Varchar 15
B. Tabel Kota
Nama tabel : Kota Primary key : ID_Kota Foreign key : -
Fungsi : Menyimpan data kota
Tabel 3.2 Kota
No Field Name Data Type Length Constraint
1 ID_Kota Integer PK
2 Nama_Kota Varchar 100
3 Nama_BPBD_Kota Varchar 100
4 Latitude Varchar 50
5 Longitude Varchar 50
C. Tabel Kecamatan
Nama tabel : Kecamatan Primary key : ID_Kecamatan Foreign key : ID_Kota
Fungsi : Menyimpan data kecamatan
Tabel 3.3 Kecamatan
No Field Name Data Type Length Constraint
1 ID_Kecamatan Integer PK
(73)
No Field Name Data Type Length Constraint 3 Nama_Kecamatan Varchar 100
D. Tabel Kejadian Bencana
Nama tabel : Kejadian Bencana Primary key : ID_Kejadian_Bencana
Foreign key : ID_Peristiwa, ID_Informan, ID_Kecamatan Fungsi : Menyimpan data kejadian bencana
Tabel 3.4 Kejadian Bencana
No Field Name Data Type Length Constraint
1 ID_Kejadian_Bencana Integer PK
2 ID_Peristiwa Integer FK
3 ID_Informan Integer FK
4 ID_Kecamatan Integer FK
5 Tanggal_Kejadian_Bencana Date 6 Jam_Kejadian_Bencana Time
E. Tabel Jenis Bencana
Nama tabel : Jenis Bencana Primary key : ID_Jenis_Bencana Foreign key : -
Fungsi : Menyimpan data kejadian bencana
Tabel 3.5 Jenis Bencana
No Field Name Data Type Length Constraint
(74)
No Field Name Data Type Length Constraint 2 Nama_Jenis_Bencana Varchar 100
F. Tabel Informasi
Nama tabel : Informasi Primary key : ID_Informasi
Foreign key : ID_Kejadian_Bencana Fungsi : Menyimpan data informasi
Tabel 3.6 Informasi
No Field Name Data Type Length Constraint
1 ID_Informasi Integer PK
2 ID_Kejadian_Bencana Integer FK
3 Keterangan Varchar 1000
G. Tabel Lapor
Nama tabel : Lapor Primary key : ID_Lapor
Foreign key : ID_Kejadian_Bencana Fungsi : Menyimpan data lapor
Tabel 3.7 Lapor
No Field Name Data Type Length Constraint
1 ID_Lapor Integer PK
2 ID_Kejadian_Bencana Integer FK
3 Jenis_Lapor Varchar 100
(75)
No Field Name Data Type Length Constraint 5 Keterangan_Lapor Varchar 100
H. Tabel Peristiwa
Nama tabel : Peristiwa Primary key : ID_Peristiwa Foreign key : ID_Jenis_Bencana
Fungsi : Menyimpan data peristiwa Tabel 3.8 Peristiwa
No Field Name Data Type Length Constraint
1 ID_Peristiwa Integer PK
2 ID_Kota Integer FK
3 ID_Jenis_Bencana Integer FK
4 Nama_Peristiwa Varchar 50 5 Tahun_Peristiwa Varchar 15
6 Status Varchar 50
I. Tabel Parameter Dampak
Nama tabel : Parameter Dampak Primary key : ID_Parameter_Dampak Foreign key : ID_Jenis_Bencana
Fungsi : Menyimpan data parameter dampak
Tabel 3.9 Parameter Dampak
No Field Name Data Type Length Constraint
1 ID_Parameter_Dampak Integer PK
(1)
cukup atau informan merasa tampilan website sudah cukup baik. Untuk pertanyaan ketiga memiliki nilai rata-rata 4,17 yang memiliki arti baik atau informan merasa akses aplikasi sudah cepat. Untuk pertanyaan keempat memiliki nilai rata-rata 3,67 yang memiliki arti cukup baik atau informan cukup mudah dalam melakukan login sistem. Untuk pertanyaan kelima memiliki nilai rata-rata 4,17 yang memiliki arti baik atau informan mudah dalam memasukkan nilai parameter bencana. Untuk pertanyaan keenam memiliki nilai rata-rata 3,83 yang memiliki arti cukup baik atau informan mudah dalam menambahkan data peristiwa. Dari keenam pertanyaan tersebut dapat disimpulkan nilai rata-rata untuk angket role informan ini sebesar 3,86 yang memiliki arti cukup baik atau informan cukup nyaman dan mudah dalam menggunakan website.
b. Role kepala
Pada role kepala, ada 6 responden yang mengisi angket. Responden ini memiliki tugas sebagai kepala di BPBD kota dan daerah. Dalam angket ini memiliki 6 pertanyaan. Hasil angket pada pertanyaan pertama memiliki nilai rata-rata 3,67 yang memiliki arti cukup baik atau kepala merasa bahwa aplikasi cukup sesuai dengan kebutuhan. Untuk pertanyaan kedua memiliki nilai rata-rata 4,00 yang memiliki arti baik atau kepala mudah dalam membuat laporan. Untuk pertanyaan ketiga memiliki nilai rata-rata 3,83 yang memiliki arti cukup baik atau kepala merasa dengan adanya aplikasi cukup mempermudah dalam melihat kondisi penilaian bahaya pada bulan berjalan. Untuk pertanyaan
(2)
148
keempat memiliki nilai rata-rata 3,83 yang memiliki arti cukup baik atau kepala merasa laporan peta cukup memudahkan dalan melihat nilai bencana. Untuk pertanyaan kelima memiliki nilai rata-rata 3,50 yang memiliki arti cukup baik atau kepala merasa laporan grafik cukup mudah dalam melihay nilai bencana. Untuk pertanyaan keenam memiliki nilai rata-rata 3,67 yang memiliki arti cukup baik atau kepala merasa laporan dari aplikasi cukup memudahkan untuk melakukan pengambilan keputusan. Dari keenam pertanyaan tersebut dapat disimpulkan nilai rata-rata untuk angket role informan ini sebesar 3,75 yang memiliki arti cukup baik atau kepala merasa aplikasi cukup baik dalam membantu memudahkan dalam pengambilan keputusan. c. Role perwira jaga
Pada role perwira jaga, ada 6 responden yang mengisi angket. Responden ini memiliki tugas sebagai perwira jaga. Dalam angket ini memiliki 5 pertanyaan. Hasil angket pada pertanyaan pertama memiliki nilai rata-rata 3,83 yang memiliki arti cukup baik atau perwira jaga cukup nyaman dalam menggunakan aplikasi. Untuk pertanyaan kedua memiliki nilai rata-rata 4,17 yang memiliki arti cukup atau perwira jaga merasa tampilan website sudah cukup baik. Untuk pertanyaan ketiga memiliki nilai rata-rata 3,67 yang memiliki arti cukup baik atau perwira jaga merasa aplikasi cukup mempermudah dalam pengisian data master. Untuk pertanyaan keempat memiliki nilai rata-rata 3,83 yang memiliki arti cukup baik atau perwira jaga merasa aplikasi cukup mempermudah dalam membuat laporan atau
(3)
menampilkan data bencana. Untuk pertanyaan kelima memiliki nilai rata-rata 4,17 yang memiliki arti baik atau perwira jaga merasa bahwa penilaian yang dilakukan aplikasi sudah benar. Dari kelima pertanyaan tersebut dapat disimpulkan nilai rata-rata untuk angket role informan ini sebesar 3,93 yang memiliki arti cukup baik atau informan cukup nyaman dan mudah dalam menggunakan website.
Hasil penyebaran angket pada masing-masing role menunjukkan bahwa aplikasi yang telah dibuat dapat digunakan sesuai dengan masing-masing role. Untuk detail angket dan hasil angket dapat dilihat pada lampiran 6 dan 7.
4.3.5 Uji Coba Berdasarkan Data Bencana 6 bulan
Berikut adalah pengujian yang dilakukan dengan memasukkan data bencana selama 6 bulan mulai bulan maret hingga agustus 2015. Pengujian menggunakan data bencana dimaksudkan apakah aplikasi yang telah dibuat dapat bekerja dengan baik jika dimasukkan data bencana. Data bencana yang dimasukkan berdasarkan laporan harian yang dibuat oleh Pusdalops. Laporan harian ini biasanya memuat kejadian bencana sehari sebelumnya bahkan beberapa hari sebelumnya. Hal ini membuat laporan harian tidak memiliki sifat update. Oleh sebab itu, pada pengujian ini data kejadian bencana dimasukkan kedalam aplikasi berdasarkan tanggal kejadian bencana bukan berdasarkan tanggal pembuatan laporan harian.
Pengujian berdasarkan data bencana ini memasukkan data informasi yang terdapat pada kronologi kejadian dan data lapor yang terdapat pada nilai indeks ancaman dampak dan probabilitas. Setelah data tersebut dimasukkan maka aplikasi dapat mengeluarkan laporan. Laporan tersebut terdiri dari laporan informasi,
(4)
150
laporan dampak, laporan probabilitas, laporan grafik, laporan peta dan laporan makro. Untuk laporan informasi, laporan dampak dan laporan probabilitas pada sebagian data bencana 6 bulan dapat dilihat pada lampiran 8. Dari pengujian data bencana ini dapat ditarik kesimpulan sebagai berikut:
1. Aplikasi dapat menilai bahaya dari bencana dengan baik.
2. Aplikasi dapat menghasilkan laporan berupa peta dan grafik sehingga memudahkan pengguna dalam mengetahui daerah yang terkena bencana..
(5)
151
BAB V
PENUTUP
5.1Kesimpulan
Kesimpulan yang dapat diambil dari hasil implementasi di Pusdalops PB Jawa Timur yaitu sebagai berikut :
1. Sistem yang dibuat dapat melakukan penilaian bahaya terhadap bencana yang terjadi di Jawa Timur, sehingga bencana dapat diantisipasi.
2. Sistem dapat menghasilkan laporan berupa peta dan grafik sehingga memudahkan pengguna dalam mengetahui daerah yang terkena bencana. Adanya peta yang berwarna memudahkan pengambilan keputusan dalam menangani daerah tersebut.
5.2 Saran
Adapun saran yang dapat diberikan pada penelitian ini adalah :
1. Sistem ini dapat dikembangkan menjadi sistem yang terintegrasi dengan sistem pihak-pihak yang terkait bencana, seperti BMKG dan PVMBG.
2. Sistem ini dapat dikembangkan dalam bentuk aplikasi mobile berbasis android
sehingga informan maupun admin dapat menilai bahaya dari sistem ini dimanapun dan kapanpun melalui smartphonenya. Aplikasi mobile akan memudahkan pengguna dalam menilai bahaya tanpa melalui browser.
(6)
152
DAFTAR PUSTAKA
Herlambang, Soendoro dan Tanuwijaya, Haryanto. 2005. Sistem Informasi : Konsep, Teknologi dan Manajemen. Yogyakarta : Graha Ilmu.
IEEE Computer Society. 2014. Guide to the Software Engineering Body of Knowledge Version 3.0. California: The Institute of Electricaland Electronics Engineers, Inc.
Kendall, K.E. dan Kendall, J.E. 2003. Analisis dan Perancangan Sistem Jilid 1. Jakarta: Prenhallindo.
Kristanto, Andri. 2008. Perancangan Sistem Informasi dan Aplikasinya. Jakarta : Gava Media.
Leman. 1998. Metodologi Pengembangan Sistem Informasi. Jakarta : Elex Media Komputindo.
Marlinda, L. 2004. Sistem Basis Data. Yogyakarta: Penerbit ANDI.
Noviansyah, Eka. 2008. Aplikasi Website Museum Nasional Menggunakan Macromedia Dreamweaver MX. Jakarta : STIK.
Pedoman Penyusunan Rencana Kontingensi Antar Lembaga Menghadapi Ancaman Bencana edisi ketiga tahun 2013 oleh BNPB.
Peraturan Gubernur Jawa Timur nomor 113 tahun 2010 tentang Tata Nasdah Dinas di Lingkungan Pemerintah Provinsi Jawa Timur.
Peraturan Kepala Badan Nasional Penanggulangan Bencana nomor 15 tahun 2012 tentang Pedoman Pusat Pengendalian Bencana (Pusdalops PB).
Peraturan Menteri Dalam Negeri nomor 46 tahun 2008 tentang Pedoman Organisasi dan Tata Kerja Badan Penanggulangan Bencana Daerah.
Saputra, Agus. 2012. Web Trik: PHP, HTML5 dan CSS3. Jakarta : Jasakom. Talukder, Asoke K. 2010. Mobile Computing. New Delhi : Tata McGraw Hill