SURABAYA
TUGAS AKHIR
Nama : ARFIN TRI HASNAWA
NIM : 06.41010.0290 Program : S1 (Strata Satu) Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
vii
bergerak dalam bidang kesehatan. Sebagai instansi pemerintah yang menerapkan
ketepatan waktu dalam melakukan pelaporan disetiap puskesmas, Dinas
Kesehatan Surabaya sering mengalami keterlambatan dalam memonitoring dan
mengevaluasi untuk beberapa periode, sehingga angka kesehatan mengalami
penurunan apalagi dalam program Demam Berdarah Dengue (DBD), juga
mengalami keterlambatan dalam penanganan kasus yang terjadi, yang
dikarenakan keterlambatan pihak puskesmas dalam melakukan pelaporan dan
lokasi puskesmas yang berjauhan dari dinas kesehatan.
Dari hasil analisis, diketahui bahwa keterlambatan pelaporan yang
dilakukan puskesmas berakibat bertambahnya kasus. Dari permasalahan dan
analisis terhadap permasalahan yang ada, maka dibutuhkan aplikasi yang dapat
melakukan monitoring dan evaluasi pengendalian DBD berbasis web yang
dibangun berdasarkan wawancara dan observasi yang telah dilakukan.
Dengan menggunakan web based dapat membantu pihak dinas kesehatan
dan puskesmas di Surabaya dalam menangani masalah effisiensi waktu pelaporan
dan pengendalian dan dapat mempercepat proses evaluasi agar angka kesakitan
dan kematian dapat ditekan serendah mungkin. Berdasarkan hasil uji coba dan
evaluasi, diketahui bahwa aplikasi dapat memberikan hasil evaluasi dalam satu
bulan, sehingga tidak sampai terjadi Kejadian Luar Biasa (KLB), dengan
persentase indikator angka kesakitan (IR) 1,4/100.000 penduduk, angka kematian
(CFR) 0% dan angka bebas jentik (ABJ) 85%.
x DAFTAR ISI
Halaman
ABSTRAK ... vii
KATA PENGANTAR ... ..viii
DAFTAR ISI ... x
DAFTAR TABEL ...xiv
DAFTAR GAMBAR ... xviii
DAFTAR LAMPIRAN ...xxi
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 Pengendalian Demam Berdarah Dengue ... 10
2.2 Sistem Informasi ... 10
2.2.1 Sistem ... 11
2.2.2 Informasi ... 11
2.3 Demam Berdarah Dengue ... 11
2.4 Monitoring ... 12
2.5 Evaluasi ... 13
xi
Halaman
2.5.2 Ukuran Surveilans Nyamuk ... 14
2.6 Software Engineering of Body Knowledge ... 14
2.6.1 Requirements ... 15
2.6.2 Analisis ... 17
2.6.3 Desain ... 19
2.6.4 Construction ... 26
2.6.5 Testing dan Implementasi ... 28
2.6.6 Maintenance ... 28
BAB III ANALISIS DAN PERANCANGAN SISTEM ... 29
3.1 Identifikasi dan Analisis Permasalahan ... 30
3.1.1 Alir Sistem Mencatat Kasus Harian ... 31
3.1.2 Alir Sistem Persetujuan Kasus Harian ... 33
3.1.3 Alir Sistem Monitoring dan Evaluasi ... 34
3.1.4 Alir Sistem Persetujuan K-DBD ... 37
3.2 Permasalahan ... 39
3.2.1 Analisis Pada Pencatatan Kasus Harian ... 39
3.2.2 Analisis Pada Persetujuan Kasus Harian ... 39
3.2.3 Analisis Pada Monitoring dan Evaluasi ... 40
3.2.4 Analisis Pada Persetujuan K-DBD ... 40
3.3 Solusi Permasalahan ... 40
3.3.1 Kebutuhan Perangkat Lunak ... 41
3.3.2 Desain Sistem ... 55
xii
Halaman
3.3.4 Data Flow Diagram ... 65
3.3.5 Entity Relationship Diagram ... 77
3.3.6 Struktur Basis Data ... 79
3.3.7 Perancangan Prosedur dan Program Unit ... 83
3.3.8 Program Unit ... 89
3.3.9 Program Pseudocode ... 90
3.3.10 Desain Arsitektur ... 93
BAB IV IMPLEMENTASI DAN EVALUASI ... 93
4.1 Implementasi ... 95
4.2 Penjelasan Penggunaan Aplikasi ... 95
4.2.1 Pengguna Sebagai Seksi DBD Puskesmas ... 96
4.2.2 Pengguna Sebagai Kepala Puskesmas ...100
4.2.2 Pengguna Sebagai Koordinator DBD ...101
4.2.2 Pengguna Sebagai Kepala Seksi Dinas Kesehatan ...104
4.3 Uji Coba Fungsional dan Non Fungsional ...105
4.3.1 Uji Fungsional dan Non-Fungsional Seksi DBD Puskesmas ...106
4.3.2 Uji Fungsional dan Non-Fungsional Kepala Puskesmas ...107
4.3.2 Uji Fungsional dan Non-Fungsional Koordinator DBD ...108
4.3.2 Uji Fungsional dan Non-Fungsional Kepala Seksi Pengendalian dan Pemeberantasan Penyakit ...110
4.4 Evaluasi ...111
xiii
Halaman
4.4.2Perhitungan Manual Tanpa Aplikasi ...114
4.4.3Perbandingan Hasil Evaluasi ...114
BAB V PENUTUP...115
5.1 Kesimpulan ...115
5.2 Saran ...115
DAFTAR PUSTAKA ...116
xiv
DAFTAR TABEL
Halaman
Tabel 2.1 Flow Direction Symbols ... 18
Tabel 2.3 Processing Symbols ... 19
Tabel 2.4 Input/Output Symbols ... 20
Tabel 3.1 Proses Bisnis Berdasarkan Stakeholder ... 30
Tabel 3.2 Penjelasan Alir Sistem Pencatatan Kasus Harian ... 33
Tabel 3.3 Penjelasan Alir Sistem Persetujuan Kasus Harian ... 35
Tabel 3.4 Penjelasan Alir Sistem Monitoring dan Evaluasi ... 37
Tabel 3.5 Penjelasan Alir Sistem Persetujuan K-DBD ... 40
Tabel 3.6 Detil Kebutuhan Fungsi Pencatatan Kasus Harian ... 48
Tabel 3.7 Detil Kebutuhan Fungsi Persetujuan Kasus Harian ... 50
Tabel 3.8 Detil Kebutuhan Fungsi Monitoring dan Evaluasi ... 52
Tabel 3.9 Detil Kebutuhan Fungsi Persetujuan K-DBD ... 55
Tabel 3.10 Proses Bisnis Berdasarkan Stakeholder Sesuai Sistem Baru ... 59
Tabel 3.11 Alir Sistem Baru Pencatatan Kasus Harian ... 61
Tabel 3.12 Alir Sistem Baru Persetujuan Kasus Harian ... 63
Tabel 3.13 Alir Sistem Baru Monitoring dan Evaluasi ... 65
Tabel 3.14 Alir Sistem Baru Persetujuan K-DBD ... 68
Tabel 3.15 Alir Sistem DFD Level 0 ... 71
Tabel 3.16 Alir Sistem DFD Level 1 Pencatatan Kasus Harian ... 74
Tabel 3.17 Alir Sistem DFD Level 1 Persetujuan Kasus Harian ... 75
Tabel 3.18 Alir Sistem DFD Level 1 Monitoring dan Evaluasi ... 77
xv
Halaman
Tabel 3.20 Struktur Tabel Puskesmas ... 83
Tabel 3.21 Struktur Tabel Kecamatan ... 83
Tabel 3.22 Struktur Tabel Pengguna ... 84
Tabel 3.23 Struktur Tabel K-DBD ... 84
Tabel 3.24 Struktur Tabel Kasus Harian ... 85
Tabel 3.25 Struktur Tabel KLB ... 86
Tabel 3.26 Detil Form Pencatatan Kasus Harian ... 87
Tabel 3.27 Detil Form Persetujuan Kasus Harian ... 88
Tabel 3.28 Detil Form Monitoring dan Evaluasi ... 89
Tabel 3.29 Detil Form Persetujuan K-DBD ... 91
Tabel 3.30 Program Unit Sistem ... 93
Tabel 3.31 Program Pseudocode... 94
Tabel 3.32 Tabel Spesifikasi Kebutuhan Perangkat Keras ... 97
Tabel 4.1 Penjelasan Form Login ... 99
Tabel 4.2 Penjelasan MenuYang Tersedia Seksi DBD Puskesmas ...100
Tabel 4.3 Penjelasan Halaman Master Pengguna ...101
Tabel 4.4 Penjelasan Form Master Kasus Harian ...102
Tabel 4.5 Penjelasan Persetukuan Kasus Harian ...103
Tabel 4.6 Penjelasan Halaman Dashboard Koordinator DBD ...105
Tabel 4.7 Penjelasan Halaman KLB ...106
Tabel 4.8 Penjelasan Halaman KDBD. ...106
xvi
Tabel 4.10 Hasil Uji Fungsional dan Non-Fungsional pada Seksi DBD Puseksmas
...109
Tabel 4.11 Hasil Uji Fungsional Dan Non-Fungsional Pada Kepala Puskesmas ...110
Tabel 4.12 Hasil Uji Fungsional Dan Non-Fungsional Pada Koordinator ...111
Tabel 4.13 Hasil Uji Fungsional Dan Non-Fungsional Pada Kepala Seksi ...113
xvii
DAFTAR GAMBAR
Halaman
Gambar 2.1 Simbol External Entity ... 21
Gambar 2.2 Simbol Data Flow ... 21
Gambar 2.3 Simbol Process ... 21
Gambar 2.4 Simbol Data Store ... 22
Gambar 2.5 Hubungan one-to-one ... 23
Gambar 2.6 Hubugan one-to-many ... 23
Gambar 2.7 Hubungan many-to-one ... 24
Gambar 2.8 Hubungan many-to-many ... 24
Gambar 3.1 Alir Sistem Seksi DBD Puskesmas ... 32
Gambar 3.2 Alir Sistem Kepala Puskesmas... 34
Gambar 3.3 Alir Sistem Koordinator DBD Dinkes ... 36
Gambar 3.4 Alir Sistem Kepala Seksi Approval... 39
Gambar 3.5 Alir Sistem Baru Seksi DBD Puskesmas ... 60
Gambar 3.6 Alir Sistem Baru Kepala Puskesmas ... 62
Gambar 3.7 Alir Sistem Baru Koordinator DBD ... 64
Gambar 3.8 Alir Sistem Baru Kepala Seksi ... 67
Gambar 3.9 Context Diagram ... 69
Gambar 3.10 DFD Level 0 ... 70
Gambar 3.11 DFD Level 1 Pencatatan Kasus Harian ... 73
Gambar 3.12 DFD Level 1 Persetujuan Kasus Harian ... 75
Gambar 3.13 DFD Level 1 Monitoring dan Evaluasi ... 76
xviii
Halaman
Gambar 3.15 Conceptual Data Model(CDM) ... 81
Gambar 3.16 Physical Data Model (PDM) ... 82
Gambar 3.17 Desain Arsitektur Jaringan ... 97
Gambar 4.1 Form Login ... 99
Gambar 4.2 Menu Yang Tersedia Seksi DBD Puskesmas ...100
Gambar 4.3 Halaman Master Pengguna ...101
Gambar 4.4 Halaman Master Kasus Harian...102
Gambar 4.5 Halaman Persetujuan Kasus Harian ...103
Gambar 4.6 Halaman Dashboard Koordinator DBD ...104
Gambar 4.7 Halaman KLB ...105
Gambar 4.8 Halaman KDBD ...106
Gambar 4.9 Halaman Persetujuan KDBD ...107
Gambar 4.10 Form Pilihan Laporan KDBD dan Tindak Lanjut...108
Gambar 4.11 Evaluasi Kasus Menggunakan Aplikasi ...116
xix
DAFTAR LAMPIRAN
Halaman
Lampiran 1 Biodata Penulis ...117
Lampiran 2 Transkip Wawancara 1 ...119
Lampiran 3 Dokumen Profil Perusahaan ...122
Lampiran 4 Dokumen Struktur Organisasi, Role and Responsibilty ...124
Lampiran 5 Proses Identifikasi Permasalahan ...127
Lampiran 6 Data dan Fakta Permasalahan ...130
Lampiran 7 Dokumen Rule and Policy ...131
Lampiran 8 Dokumen Kebutuhan Fungsional dan Non-Fungsional ...133
Lampiran 9 Desain Arsitektur ...136
BAB I PENDAHULUAN
1.1 Latar Belakang Masalah
Deman Berdarah Dengue adalah penyakit menular yang disebabkan oleh
virus dari golongan Arbovirosis group A dan B. Di Indonesia penyakit akibat
gigitan nyamuk yang paling bermasalah adalah Demam Berdarah Dengue (DBD),
Chikungunya dan Japanese Encephalitis (JE). Penyakit DBD mulai dikenal di
Indonesia sejak tahun 1968 di Surabaya dan Jakarta, dan setelah itu jumlah kasus
DBD terus bertambah seiring dengan meluasnya daerah endemis DBD. Pada tiga
tahun terakhir (2008-2010) jumlah rata-rata kasus yang dilaporkan sebanyak
150.822 kasus dengan rata-rata kematian 1.321. Situasi kasus DBD tahun 2011
sampai dengan juni 2011 dilaporkan sebanyak 16.612 orang dengan kematian
sebanyak 142 orang (Depkes, 2011). Dari jumlah kasus tersebut, proporsi
penderita DBD pada perempuan sebesar 50,33% dan laki-laki sebesar 49,67%
(Depkes, 2011). Disisi lain angka kematian akibat DBD pada perempuan lebih
tinggi dibanding laki-laki.
Dinas Kesehatan kota Surabaya adalah salah satu instansi pemerintahan
kota Surabaya yang bertanggung jawab terhadap kesehatan masyarakat kota
Surabaya. Sesuai dengan peraturan walikota nomor 91 tahun 2008, dinas
kesehatan kota surabaya mempunyai tugas menyelenggarakan kewenangan daerah
dalam bidang kesehatan dan tugas pembantuan yang di berikan oleh pemerintah.
Pembangunan kesehatan di arahkan untuk meningkatkan kesadaran, kemauan, dan
kemampuan hidup sehat bagi setiap orang agar peningkatan derajat kesehatan
komitmen internasional, yang di tuangkan dalam millenium development
goals(MDGs) dengan tujuan yang terkait langsung dengan bidang kesehatan yaitu
menurunkan angka kematian anak, meningkatkan kesehatan ibu, memerangi
HIV-AIDS, TB dan Demam Berdarah Dengue (DBD) serta penyakit lainnya dan yang
tidak terkait langsung yaitu menanggulangi kemiskinan dan kelaparan serta
mendorong kesetaraan gender dan pemberdayaan perempuan. Dalam menjalankan
tugasnya agar mencapai tujuan yang sudah di tentukan di atas. Dinas kesehatan
kota surabaya membaginya ke dalam beberapa seksi bagian. Salah satu seksi
bagian tersebut adalah seksi pengendalian dan pemberantasan penyakit. Seksi
pengendalian dan pemberantasan penyakit mempunyai tugas yaitu mencegah dan
menanggulangi penyakit menular skala kota. Dan salah satu penyakit menular
tersebut adalah penyakit DBD.
Pada saat ini pihak dinas kesehatan kota surabaya sudah
menjalankanprogram pengendalian DBD, yang di sesuaikan dengan surat
Keputusan Menteri Kesehatan Republik Indonesia Nomor
581/MENKES/SK/VII/1992. Dalam menjalankan program tersebut dinas
kesehatan kota surabaya di bantu oleh puskesmas dalam hal operasional
pengobatan sehari-hari. Dari proses yang sudah di dapat oleh puskesmas,
puskesmas memberikan form kasus harian yang selanjutnya proses tersebut di
olah, pelaporan oleh pihak dinas kesehatan Kota Surabaya dilakukan dengan
menggunakan media form KLB dan Form K-DBD . Dimana dari form-form
tersebut mempunyai fungsi yang berbeda-beda antara lain, Form Kasus Harian
berfungsi sebagai laporan jumlah penderita yang di duga menderita penyakit DBD
Form Kejadian Luar Biasa (KLB) berfungsi sebagai media pelaporan jika angka
kasus di sebuah daerah tinggi dengan indikator (KLB = Penderita >=3 atau
Meninggal >=1). Yang dimana KLB sendiri sangat mempengaruhi meningkatnya
indikator yang ditetapkan oleh pemerintah dalam mengendalikan (DBD) , Form
K-DBD yang berfungsi sebagai media pelaporan bulanan penderita DBD
berdasarkan kecamatan.
Kemudian pihak dinas melakukan monitoring setiap hari jika terjadi
kasus dengan cara memantau penyelidikan epidemiologi (PE) sesuai standard
pada saat ada laporan terjadinya kasus. Penyelidikan epidemiologi(PE) sendiri
terbagi menjadi 2 yaitu PE(+) dan PE(-). Jika PE(+), ditemukanya kasus demam
tanpa sebab yang jelas atau ditemukannya 1 kasus yang meninggal karena DBD
dalam radius 100m atau 20 rumah disekitarnya. Sedangkan jika PE(-) tidak terjadi
atau tidak adanya kasus. Penyelidikan epidemiologi dilakukan petugas dengan
cara survey kelokasi untuk diambil sampling data. Penyelidikan epidemiologi
(PE) sendiri dilakukan oleh petugas puskesmas untuk mengetahui jumlah kasus
saat menerima laporan dari masyarakat yang hasilnya kemudian direkap dengan
menggunakan form kasus harian.
Kemudian dilakukan evaluasi dari form diatas dengan tujuan menekan
jumlah kesakitan atau incident rate (IR), menekan angka kematian critical factor
rate (CFR) dan angka bebas jentik (ABJ) yang dimana pelaporanya sudah
ditentukan oleh kemenkes dengan nomor 560/MENKES/SK/VIII/1989 dengan
target Incident Rate (IR) = < 55/100.000 penduduk, Critical Factor Rate (CFR) =
Dari hasil evaluasi perhitungan indikator yang telah ditentukan yang
menghasilkan grafik dan laporan yang diperlukan, pihak dinas membuat
keputusan tentang penentuan daerah KLB berdasarkan grafik epidemiologi DBD.
Penentuan daerah KLB tersebut berdasarkan dari target yang ada yaitu, jika (KLB
= Penderita >=3 atau Meninggal >=1)yang menyebabkan PE menjadi (+) maka
daerah tersebut dinyatakan daerah KLB yang kemudian direkap menajadi Laporan
KLB.
Kemudian membuat surat edaran untuk dilakukannya pemberantasan
sarang nyamuk dan melakukan penyuluhan pada daerah yang paling banyak
terdapat kasus DBD jika angka indikator melebihi batas target. Pihak puskesmas
kemudian melakukan survey dan memeriksa kartu jentik rumah/bangunan yang
tersedia di setiap RT. Setelah itu, puskesmas mengisi formulir JPJ-1 untuk didata
agar bisa dilakukan rekapitulasi. Kemudian, hasil rekapitulasi laporan diberikan
ke pihak dinas kesehatan untuk dilakukan evaluasi. Jika hasil positif, pihak dinas
hanya melakukan penyuluhan satu bulan sekali ke puskesmas-puskesmas tentang
pemberantasan sarang nyamuk. Sedangkan jika hasil negatif, pihak dinas
kesehatan dengan dibantu pihak puskesmas melakukan survey langsung ke daerah
yang angka bebas jentiknya dibawah 95% dan melakukan tindakan dan
penyuluhan untuk memberantas sarang nyamuk didaerah yang tidak memenuhi
target.
Dari penjelasan di atas diketahui bahwa permasalahan yang di hadapi
oleh Kepala Seksi Bidang Penanggulangan dan Pemberantasan penyakit adalah
bagaimana cara Monitoring pelaksanaan program DBD dengan cepat. Sehingga
temukan indikator yang masih belum mencapai angka minimal, hal ini disebabkan
kesadaran masyarakat tentang penyakit DBD sangat kurang, padahal sudah
banyak penyuluhan dan himbauan yang telah diberikan.
Namun dalam hal ini dinas kesehatan kota Surabaya menemui kendala.
Kendala tersebut adalah lamanya waktu pelaporan yang dilakukan pihak
puskesmas terhadap dinas kesehatan kota sehingga berdampak pada proses
evaluasi dan proses tindak lanjut atau surveilan yang dapat mengakibatkan
kematian pada penderita.
Dari uraian diatas, diketahui pentingnya kecepatan pelaporan pada dinas
kesehatan dalam rangka mengendalikan DBD dengan Sistem Informasi
Monitoring dan Evaluasi pengendalian DBD.Aplikasi ini di rancang untuk
membantu kepala seksi bidang penanggulangan dan pemberantasan penyakit
dalam hal pemantauan. Aplikasi ini akan di jalankan dengan menggunakan media
website yang akan di implementasikan di seluruh puskesmas perkecamatan,
khususnya di Kota Surabaya. sehingga di harapkan dengan adanya aplikasi ini
dinas kesehatan kota dapat mengetahui laporan yang dikirim dari puskesmas
secara langsung berdasarkan form yang sudah di buat agar dapat menunjukkan
indikator secara langsung.
Pembangunan aplikasi monitoring dan evaluasi ini bertujuan untuk
membantu pihak fungsional Dinas Kesehatan Kota Surabaya sehingga mampu
menyelesaikan masalah yang ada. Aplikasi ini diharapkan dapat membantu
masalah effisiensi waktu dan efektifitas pengendalian yang menjadi masalah
1.2 Perumusan Masalah
Dari uraian latar belakang di atas dapat dirumuskan masalah adalah
bagaimana membangun sistem informasi monitoring dan evaluasi yang membantu
dinas kesehatan menekan angka dari target yang telah ditentukan dalam
pengendalian DBD?
1.3 Pembatasan Masalah
Adapun batasan masalah di dalam pembuatan tugas akhir ini adalah :
1. Menggunakan data contoh pada puskesmas Manukan Kulon dan Jagir
2. Pada penelitian ini hanya bersangkutan dengan seksi pengendalian dan
pemberantasan penyakit khusus penyakit DBD.
3. Acuan kebijakan pada penelitian ini berdasarkan Surat Keputusan Menteri
Kesehatan Republik Indonesia Nomor 561/MENKES/SK/VII/1992.
4. Pada penelitian ini hanya membahas proses pemantauan dan tidak membahas
proses tindak lanjut dari dinas kesehatan kota Surabaya.
5. Pada penelitian hanya membahas proses pelaporan dari puskesmas ke dinas
kesehatan kota Surabaya.
1.4 Tujuan
Sesuai dengan permasalahan yang ada tujuan dibuatnya sistem ini adalah
menghasilkan Rancang Bangun Sistem Informasi Monitoring dan Evaluasi
Pengendalian DBD berdasarkan peraturan kementrian kesehatan tahun
pelaporan dengan cepat dan dapat mengevaluasi untuk menekan jumlah angka
kesakitan, angka kematian, dan memberantas sarang nyamuk.
1.5 Manfaat
Aplikasi Monitoring dan Evaluasi Pengendalian DBD mempunyai manfaat
yang berdampak pada kinerja Dinas Kesehatan dan Puskesmas
a. Seksi Pengendalian dan Pemberantasan Penyakit
Kepala Seksi dapat lebih mudah dalam mengevaluasi laporan kasus DBD
yang akurat dan cepat sehingga dapat terbantu dalam mengambil keputusan
untuk menekan angka kesakitan dan menekan jumlah penyebaran jentik
menjadi minimum.
b. Puskesmas
Mempercepat proses pelaporan dari puskesmas kepada seksi Dinas Kesehatan
sehingga puskesmas dapat cepat melakukan tindakan untuk melakukan
pengendalian di lokasi yang terjadi kasus
1.6 Sistematika Penulisan
Secara garis besar sistematika penulisan pada laporan ini adalah sebagai
berikut :
Bab I : Pendahuluan
Pada bab ini akan dijelaskan mengenai latar belakang permasalahan
yang terjadi, perumusan permasalahan yang didapat dari latar
belakang, pembatasan permasalahan, tujuan dilakukannya penelitian,
manfaat yang akan diberikan kepada stakeholder, serta penjelasan
Bab II : Landasan Teori
Pada bab ini akan dijelaskan mengenai teori-teori yang mendukung
atau digunakan sebagai acuan pada saat atau sebelum melakukan
penelitian.
Bab III : Analisis dan Perancangan Sistem
Pada bab ini akan dijelaskan bagaimana awal proses penelitian ini
dilakukan hingga menghasilkan sebuah perancangan yang diperoleh
melalui beberapa tahapan seperti, pengumpulan data, identifikasi
permasalahan, analisis permasalahan, solusi permasalahan, serta
dilanjutkan sampai dengan perancangan sistem, seperti document
flow, system flow, data flow diagram, desain ERD baik conceptual
data model maupun physical data model, struktur basis data, dan
interface.
Bab IV : Implementasi dan Evaluasi
Pada bab ini akan dijelaskan mengenai implementasi program atau
aplikasi yang sudah dibuat, berdasarkan hasil analisis hingga
perancangan dan akan dilakukan uji coba fungsional maupun non
fungsional terhadap perangkat lunak yang dibangun. Tahap akhir
adalah melakukan evaluasi terhadap uji coba yang sudah dilakukan.
Bab V : Penutup
Pada bab ini akan dijelaskan mengenai kesimpulan yang diperoleh
dari penelitian ini, yaitu hasil dari evaluasi, serta saran terkait dengan
9
2.1 Pengendalian Demam Berdarah Dengue
Penyakit Demam Berdarah Dengue (DBD) disebabkan virus dan ditularkan lewat nyamuk merupakan salah satu masalah kesehatan masyarakat di Indonesia,
yang cenderung semakin luas penyebarannya sejalan dengan meningkatnya
mobilitas dan kepadatan penduduk. Pengendalian penyakit demam berdarah
dengue pada dasarnya dilakukan sesuai peraturan KEMENKES NOMOR
581/MENKES/SK/VII/1992 yang berisi, upaya pengendalian penyakit demam
berdarah dengue (DBD) dilakukan melalui kegiatan pencegahan, penemuan,
pelaporan penderita, pengamatan penyakit, dan penyelidikan epidemiologi,
penanggulangan seperlunya, penanggulangan lain dan penyuluhan masyarakat.
Pelaksanaan kegiatan pengendalian penyakit demam berdarah dengue dilakukan
oleh pemerintah dan masyarakat dibawah koordinasi kepala wilayah/daerah
(Depkes, 2011).
2.2 Sistem Informasi
Sistem informasi adalah suatu sistem di dalam suatu organisasi yang
mempertemukan kebutuhan pengolahan transaksi harian yang mendukung fungsi
operasi organisasi yang bersifat manajerial dengan kegiatan strategi dari suatu
organisasi untuk dapat menyediakan kepada pihak luar tertentu dengan
2.2.1 Sistem
Sistem dapat didefinisikan sebagai kumpulan komponen yang saling terkait
yang bekerjasama untuk mencapai tujuan bersama. Fungsi sistem adalah untuk
menerima masukan dan mengubah ini menjadi output (Bocij, 2008).
2.2.2 Informasi
Seperti konsep data, ada beberapa definisi informasi yang umum
digunakan, yaitu:
a. Data yang telah diolah sehingga mereka bermakna
b. Data yang telah diolah untuk tujuan
c. Data yang telah dipahami dan dimengerti oleh penerima
Tigahal penting dapat ditarik dari definisi ini pertama, ada proses yang jelas dan
logis yang digunakan untuk menghasilkan informasi. Proses ini melibatkan
pengumpulan data untuk sebuah proses transformasi dalam rangka menciptakan
informasi. Kedua, informasi melibatkan dan menempatkan beberapa inisial data
dalam bentuk konteks yang bermakna, sehingga mereka dapat dipahami dan
ditindak lanjuti. Ketiga, informasi yang dihasilkan untuk suatu tujuan, untuk
melayani kebutuhan informasid ari beberapa jenis (Bocij, 2008).
2.3 Demam Berdarah Dengue
Demam Berdarah Dengueadalah penyakit menular yang disebabkan oleh
virus dari golongan Arbovirosis group A dan B. Di Indonesia penyakit akibat
gigitan nyamuk yang paling bermasalah adalah Demam Berdarah Dengue (DBD),
Chikungunya dan Japanese Encephalitis (JE). Penyakit Demam Berdarah Dengue
setelah itu jumlah kasus Demam Berdarah Dengue (DBD) terus bertambah seiring
dengan meluasnya daerah endemis Demam Berdarah Dengue (DBD).Penyakit ini
menimbulkan kejadian luar biasa (KLB) yangberdampak buruk pada segi sosial
dan ekonomi. Kerugian sosial yang terjadi antara lain karena menimbulkan
kepanikan dalam keluarga, kematian anggota keluarga, dan berkurangnya usia
harapan penduduk. Pada tiga tahun terakhir (2008-2010) jumlah rata-rata kasus
yang dilaporkan sebanyak 150.822 kasus dengan rata-rata kematian 1.321. Situasi
kasus Demam Berdarah Dengue (DBD) tahun 2011 sampai dengan juni 2011
dilaporkan sebanyak 16.612 orang dengan kematian sebanyak 142 orang (Depkes,
2011). Dari jumlah kasus tersebut, proporsi penderita Demam Berdarah Dengue
(DBD) pada perempuan sebesar 50,33% dan laki-laki sebesar 49,67%. Disisi lain
angka kematian akibat DBD pada perempuan lebih tinggi dibanding laki-laki
(Depkes, 2011).
2.4 Monitoring
Monitoring adalah kegiatan pemantauan atau pengamatan yang
berlangsung selama kegiatan berjalan untuk memastikan dan mengendalikan
keserasianpelaksanaan program dengan perencanaan yang telah ditetapkan.
(Rinda Hedwig, 2007). Disini penderita DBD di monitoring sesuai dengan
peraturan yang berlaku terdiri dari penyelidikan epidemiologi (PE) yang
dilaporkan melalui dokumen kasus harian dan dilakukan penanggulangan
seperlunya berdasarkan hasil penyelidikan tersebut. Penyelidikan Epidemologi
sendiri adalah kegiatan pencarian penderita DBD disekitar tempat tinggal
2.5 Evaluasi
Evaluasi adalah upaya menilai kualitas program dan hasil-hasilnya secara
berkala dengan menggunakan pendekatan yang tepat. Evaluasi penelitian berarti
upaya menggali informasi terhadap proses dan hasil penelitian untuk menilai
kualitasnya dengan menggunakan pendekatan yang tepat (Hedwig, 2007).
2.5.1 Ukuran Epidemologi
Ukuran (parameter) frekuensi penyakit yang paling sederhana dan
menghitung jumlah individu yang sakit pada suatu populasi. Frekuensi tersebut
bermanfaat bagi petugas kesehatan di daerah untuk mengalokasi dana atau
kegiatan penanggulangan. Ukuran-ukuran epidemiologi yang sering digunakan
dalam kegiatan pengendalian DBD adalah Insidence Rate (IR) dan Case Fatality
Rate (CFR).
a. Angka Kesakitan/Insiden Rate (IR)
IR adalah ukuran yang menunjukan kecepatan kejadian (baru) penyakit
populasi, IR merupakan proporsi antara jumlah orang yang menderita
penyakit DBD dan jumlah orang dalam resiko X lamanya penderita dalam
resiko.
IR = 100%
Beresiko Yang
Orang Jumlah
Penyakit Baru
Kasus Jumlah
X
b. Angka Kematian/Case Fatality Rate (CFR)
CFR adalah angka kematian yang di akibatkan dari suatu penyakit dalam
suatu waktu tertentu dikalikan 100%
CFR= 100%
Kasus Jumlah
Kematian Jumlah
2.5.2 Ukuran Survielans Nyamuk
Surveilans Jentik nyamuk DBD meliputi proses pengumpulan, pencatatan,
pengolahan, analisis dan interpretasi data jentik serta penyebarluasan
informasi secara sistematis dan terus menerus agar dapat memutus rantai
penularan dan penyhebaran nyamuk. Berikut adalah ukuran yang dipakai
untuk mengetahui angka bebas dari jentik Aedes Aegypti :
a. Angka Bebas Jentik (ABJ) :
Jumlah atau bangunan rumah yang tidak ditemukan jentik.
ABJ = 100%
diperiksa yang
unan rumah/bang Jumlah
jentik ditemukan tidak
yang unan rumah/bang Jumlah
X
2.6 Software Engineering Body of Knowledge (SWEBOK)
SWEBOK menggambarkan pengetahuan secara umum tentang rekayasa
perangkat lunak yang dibagi kedalam 10 area pengetahuan (Knowledge Areas)
atau disebut Kas.” Software Engineering Body of Knowledge (SWEBOK) adalah
produk dari komite koordinasi rekayasa perangkat lunak disponsori oleh IEEE
Computer Society. SWEBOK sendiri mempunyai panduan yang disebut Guiede to
the SWEBOK, panduan ini dibuat untuk 5 tunjuan, yaitu :
a. Untuk memperlihatkan kesamaan pandangan tentang rekayasa perangkat
lunak diseluruh dunia.
b. Untuk memperjelas tempat dan menetapkan batas dari rekayasa perangkat
lunak dan hubungannya dengan disiplin ilmu lain seperti ilmu komouter,
manajemen proyek, teknik komputer dan matematika.
c. Untuk memberi karakter isi dari disiplin ilmu rekayasa perangkat lunak.
e. Untuk memberikan pengetahuan dasar bagi pengembangan kurikulum dan
sertifikasi serta perizinan.
Berikut adalah penjabaran tentang ruang lingkup pengetahuan atau yang
disebut juga Knowledge Area (KAs) yang digunakan sebagai panduan dalam
mengembangkan aplikasi (England, 2004).
2.6.1 Requirements
Tahapan awal dalam membangun aplikasi, Software Requirements
merupakan sebuah properti yang disajikan untuk memenuhi kebutuhan dalam
menyelesaikan permasalahan yang ada akan diselesaikan oleh aplikasi tersebut.
Menjabarkan bagaimana mengotomatiskan sebuah permasalahan sebuah tugas
yang dihadapi oleh pengguna, membantu menganalisa proses bisnis perusahaan
yang telah menggunakan aplikasi, menganalisa kekurangan yang ada, dan lainnya.
Berikut penjabaran tentang beberapa tahapan yang ada pada software
requirement:
a. Requirement Elicitation
Tahapan awal dalam pemenuhan software requirements makna dari kebutuhan
mendatang ini berhubungan dengan darimana kebutuhan perangkat lunak itu
sendiri dan bagaiman para pengembangan perangkat lunak dapat
mengumpulkannya. Pada dasarnya, kegiatan yang dijabarkan adalah dari tiap
individu dan tiap pemegang kendali sistem tersebut untuk membangun
ketersinambungan antara pihak pengembang dan pengguna perangkat lunak
b. Requirement Analysis
Tahapan ini mebahas tentang kegiatan menganalisa kegiatan manganalisa
kebutuhan untuk :
1. Mendeteksi dan menyelesaikan ketidakcocokan yang ada pada tiap-tiap
kebutuhan.
2. Menggali batasan yang ada pada perangkat lunak yang dikembangkan dan
bagaimana perangkat lunak tersebut akan berinteraksi dengan sistem.
3. Menguraikan kebutuhan sistem yang akan digunakan sebagai kebutuhan
perangkat lunak
c. Requirements spesification
Secara teknis pada kata “specification” mengacu pada banyaknya jumlah
pekerjaan atau kemampuan perangkat lunak tersebut dalam mencapai
tujuannya. Dalam sebuah istilah pengembangan perangkat lunak. “software
requirements specification” secara khusus mengarah kepada hasil ketepatan,
atau penyamaan elektronik, yang dapat ditinjau, dinilai, dan dibenarkan.
d. Requirement Verification and Validation
Beberapa dokumen requirements di atas menjadi bahan dari tahapan validasi
dan verifikasi. Kebutuhan yang ada di validasi untuk menjamin bahwa
pengembang dari perangkat lunak tersebut dapat memahami kebutuhan yang
akan dicapai. Penyesuaian kebutuhan untuk standar perusahaan sangat penting
untuk diperhatikan bahwa kebutuhan tersebut dimengerti, konsisten, dan
2.6.2 Analisis
Tahap Analisis merupakan tahap identifikasi, seleksi, dan perencanaan
sistem yang bertujuan untuk mendeteksi dan memberikan solusi antar kebutuhan
serta mengetahui ruang lingkup perangkat lunak dan bagaimana perangkat lunak
tersebut berinteraksi dengan lingkungan.
Tahapan analisis kebutuhan, menunjukkan tahapan-tahapan didalam
analisis kebutuhan. Pada dasarnya, aktivitas analisis dibutuhkan dalam setiap
proses dalam daur hidup pengembangan perangkat lunak. Dalam proses rekayasa
kebutuhan, analisis pun dilakukan dalam setiap aktivitas-aktivitasnya. Aktivitas
tersebut antara lain sebagai berikut :
1. Domain Understanding : Dalam tahapan ini, pengembang harus mengetahui
bagaimana organisasi perusahaan beroperasi dan apa yang menjadi
permasalahan pada sistem yang berjalan.
2. Requirements Collection : Tahapan ini merupakan tahapan pengumpulan
kebutuhan akan sistem yang akan dibangun sehingga diperlukan adanya
interaksi secara intensif dengan stakeholder.
3. Classification : Tahapan ini mengelompokkan hasil dari tahap kebutuhan
sehingga menjadi lebih terstruktur untuk selanjutnya diorganisir kedalam
kelompok-kelompok yang koheren.
4. Conflict Resolution : Tahapan ini berguna untuk menemukan dan
menyelesaikan kebutuhan yang didalamnya terdapat konflik. Konflik tersebut
dapat terjadi antara dua stakeholder yang saling terkait tetapi memiliki fasilitas
5. Prioritisation : Tahap ini melakukan interaksi dengan stakeholder untuk
mengidentifikasikan kebutuhan-kebutuhan prioritas dari masing-masing
kebutuhan agar memenuhi sumber daya yang tersedia pada organisasi.
6. Requirements Checking: Menganalisis sekumpulan kebutuhan dari hasil
tahapan sebelumnya untuk menverifikasi dan memvalidasi berdasarkan aspek
kelengkapan, konsistensi, dan kebutuhan nyata.
Semua jenis kebutuhan yang telah diperoleh tersebut kemudian
dituangkan dalam bentuk dokumen yang berisi tentang kebutuhan sistem secara
keseluruhan. Dokumen ini menjelaskan secara rinci tentang kesepakatan antara
pengembang dengan klien, desain perangkat lunak yang akan dibangun, segala
resiko yang akan dihadapi dan jadwal pembuatan perangkat lunak. Dokumen ini
sangat berguna bagi pihak yang ingin mengetahui tentang perangkat lunak yang
akan dibangun namun tidak mengerti secara teknik karena dokumen ini
menggunakan bahasa yang sederhana. Secara umum dokumen ini biasa disebut
dengan Software Requirements Spesification (SRS).
Pada dokumen SRS akan dijelaskan juga mengenai kebutuhan fungsional
dan non-fungsional dimana kebutuhan non-fungsional dibuat berdasarkan
dokumen IEEE standart 803:1993. IEEE 803:1993 mengelompokkan kebutuhan
non-fungsional kedalam sejumlah kategori kualitas dari suatu perangkat lunak.
Kategori-kategori tersebut secara umum dibagi kedalam 2 kelompok, yaitu faktor
kualitas eksternal dari perangkat lunak dan faktor kualitas internal perangkat
lunak. Faktor kualitas eksternal merupakan kategori kualitas yang dapat
diobservasi atau menjadi ketertarikan utama dari pelanggan. Kategori-kategori
a. Ketepatan (correctness),
b. Robustness,
c. Unjuk Kerja (performance),
d. Ketersediaan dan kualitas antar muka (interface),
e. Kehandalan (reliability), dan
f. Ketersediaan (availability)
Sedangkan kualitas faktor internal merupakan kategori kualitas yang
dapat diobservasi atau menjadi ketertarikan utama dari pengembang. Seprerti :
a. Kemudahan membaca/memahami struktur perangkat lunak (readibility),
b. Kemampuan untuk dilakukan pengujian (testability),
c. Ketersediaan dan kualitas dokumentasi (documentation),
d. Kemudahan pemeliharaan (maintainability), dan
e. Adaptasi terhadap lingkungan berbeda (portability)
2.6.3 Desain
Desain adalah penggambaran, perencanaan dan pembuatan sketsa atau
pengaturan dari beberapa elemen yang terpisah ke dalam satu kesatuan yang utuh
dan berfungsi (Burch, 1986).
Analis sistem dapat mendesain model dari sistem informasi yang diusulkan
dalam bentuk physical system dan logical model.Bagan alir sistem (system
flowchart) merupakan alat yang tepat digunakan untuk menggambarkan physical
system.
Logical model dari sistem informasi lebih menjelaskan kepada user
Logical model dapat digambarkan dengan menggunakan diagram arus data (data
flow diagram) (Burch, 1986).
1. Flowchart
[image:31.595.91.519.238.588.2]a. Flow Direction Symbol
Tabel 2.1 Flow Direction Symbols
Simbol arus / flow, yaitu menyatakan
jalannya arus suatu proses
Simbol connector, berfungsi menyatakan
sambungan dari proses ke proses lainnya
dalam halaman yang sama.
Simbol off-page connector, menyatakan
sambungan dari proses ke proses lainnya
dalam halaman yang berbeda.
b. Processing Symbols
Tabel 2.2 Processing Symbols
Simbol process, yaitu menyatakan suatu
tindakan (proses) yang dilakukan oleh
computer
Simbol manual, yaitu menyatakan suatu
tindakan (proses) yang tidak dilakukan oleh
Simbol decision, yaitu menunjukkan suatu
kondisi tertentu yang akan menghasikan dua
kemungkinan jawaban : ya / tidak.
Simbol preparation, yaitu menyatakan
penyediaan tempat penyimpanan suatu
pengolahan untuk memberi harga awal
Simbol terminal, yaitu menyatakan
permulaan atau akhir suatu program.
Simol offline-storage, menunjukkan bahwa
data dalam simbol ini akan disimpan ke
suatu media tertentu
Simbol manual-input, memasukkan data
secara manual dengan menggunakan online
keyboard
[image:32.595.98.515.80.534.2]c. Input / Output Symbol
Tabel 2.3 Input / Output Symbol
Simbol input-output menyatakan proses
input atau output tanpa tergantung jenis
peralatannya
Simbol storage menyatakan input berasal
Simbol document mencetak keluaran dalam
bentuk dokumn (melalui printer)
Simbol display mencetak keluaran dalam
layar monitor.
2. Data Flow Diagram
Data Flow Diagram (DFD) adalah diagram yang menggunakan notasi-notasi ini
untuk menggambarkan arus dari data sistem, sekarang di kenal dengan nama
diagram arus data (data flow diagram). Data Flow Diagram (DFD) sering
digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem baru
yang akan di kembangkan secara logika tanpa mempertibangkan lingkungan fisik
dimana data tersebut mengalir.
a. External entity
External entity merupakan kesatuan di lingkungan luar sistem yang dapat berupa
orang, organisasi, atau sistem lainnya yang berada di lingkungan luarnya yang
akan memberikan input atau menerima output dari sistem.
Gambar 2.1 Simbol Eksternal Entity
b. Data flow
Data flow menunjukkan arus dari data yang berupa masukan untuk sistem atau
Gambar 2.2 Simbol Data flow
c. Process
Process adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau
komputer dari hasil suatu arus data yang masuk kedalam proses untuk dihasilkan
arus data yang akan keluar dari proses.
Gambar 2.3 Simbol Process
d. Data Store
Data store adalah simpanan dari data yang berupa, suatu file database di sistem
komputer, arsip atau catatan manual, dan suatu tabel acuan manual.
Gambar 2.4 Simbol Data source
3. Entity Relationship Diagram
Atribute adalah kolom di sebuah relasi.
a. Simple Atribute
Atribute ini merupakan atribute yang unik dan tidak dimiliki oleh atribute
lainnya, misalnya entity mahasiswa yang atribute-nya NIM.
b. Composite Atribute
Composite Atribute adalah atribute yang memiliki dua nilai harga, misalnya
nama besar (nama keluarga) dan nama kecil (nama asli).
c. Single Value Atribute
Atribute yang hanya memiliki satu nilai harga, misalnya entity mahasiswa
dengan atribute-nya umur (tanggal lahir).
d. Multi Value Atribute
Atribute yang banyak memiliki nilai harga, misalnya entity mahasiswa dengan
atribute-nya pendidikan (SD, SMP, SMA).
e. Null Value Atribute
Atribute yang tidak memiliki nilai harga, misalnya entity tukang becak dengan
atribute-nya pendidikan (tanpa memiliki ijazah).
ERD ini diperlukan agar dapat menggambarkan hubugan antar entity
dengan jelas, dapat menggambarkan batasan jumlah entity dan partisipasi antar
entity, mudah dimengerti pemakai dan mudah disajikan oleh perancang database.
(Kadir, 2008)
Untuk itu ERD dibagi menjadi 2 jenis model, yaitu :
a. Conceptual Data Model (CDM)
Merupakan jenis model data yang menggambarkan hubungan antar tabel secara
b. Physical Data Model (PDM)
Merupakan jenis model data yang menggambarkan hubungan antar tabel secara
fisikal.
ERD mempunyai 4 jenis hubungan antara lain :
a. Hubungan one–to–one ( 1:1 ) menyatakan bahwa setiap entitas pada tipe
entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas B.
[image:36.595.91.512.288.547.2]Begitu pula sebaliknya. Contoh :
Gambar 2.5 Hubungan one-to-one
b. Hubungan one–to–many ( 1:M ) menyatakan bahwa setiap entitas pada tipe
entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B,
sedangkan setiap entitas pada B hanya bisa berpasangan dengan satu entitas
pada tipe entitas B. Contoh :
Gambar 2.6 Hubungan one-to-many
c. Hubungan many–to–one ( M:1 ) menyatakan bahwa setiap entitas pada tipe
entitas A paling banyak berpasangan dengan satu entitas pada tipe entitas B
dan setiap entitas pada tipe entitas B bisa berpasangan dengan banyak entitas
pada tipe entitas A. Contoh :
Relation_3
A B
Relation_3
Gambar 2.7 Hubungan many-to-one
d. Hubungan many–to–many ( M:N ) Menyatakan bahwa setiap entitas pada suatu
tipe entitas A bisa berpasangan dengan banyak entitas pada tipe entitas B dan
begitu pula sebaliknya. Contoh :
Gambar 2.8 Hubungan many-to-many
e. Kardinalitas menggambar hubungan antara dua entitas dengan
mengindentifikasi berapa banyak instance untuk setiap entitas yang nantinya
dapat dihubungkan dengan setiap instance yang spesifik di entitas yang lain.
2.6.4 Construction
Software construction lebih di artikan sebagai pembuatan detail dari suatu
pekerjaan, menciptakan satu software yang penting yang di kombinasikan dengan
code, proses verifikasi, testing unit, dan testing yang terintegrasi, serta proses
debuging. Software construction lebih sering di hubungkan dengan proses desain
dan proses testing. Hal ini dikarenakan proses tersebut saling ketergantungan satu
sama lain, dimana software construction merupakan keluaran dari desain software
dan juga sebagai masukan dari software testing. Software construction bertipikal
memproduksi volume konfigurasi item yang lebih tinggi dan juga di butuhkan
dalam mengelola sebuah software proyek (file sumber, isi, test cases, dll).
(England, 2004)
Relation_3
A B
Relation_3
[image:37.595.95.511.265.504.2]A. Software Contsruction Fundamentals
Pada tahap pertama, dilakukan pendefinisian dasar tetang prinsip-prinsip
yang digunakan dalam proses implementasi seperti minimalisasi kompleksitas,
mengantisipasi perubahan, dan standar yang digunakan.
B. Managing Costruction
Bagian ini mendefeinisikan 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 mplementasi yang dilakukan,
proses pengetesan dan integritas.
Dalam proses pengimplementasia ini, digunakan beberapa aplikasi pendukung
yaitu :
a. Adobe Dreamweaver
Adobe Dreamweaver merupakan aplikasi yang di gunakan sebagai HTML
editor profesional untuk mendesain web secara visual.Yang intinya adalah anda
tidak harus berurusan dengan tag-tag HTML untuk membuat sebuah site dan
dapat melihat hasil desainnya secara langsung.
Kemampuan Dreamweaver untuk berinteraksi dengan beberapa bahasa
pemrograman seperti PHP, ASP, JavaScript, dan yang lainnnya juga memberikan
fasilitas maksimal kepada desainer web dengan menyertakan bahasa
b. Bahasa Pemrograman PHP
Bahasa Pemrograman PHP adalah bahasa pemrograman yang bekerja
dalam sebuah webserver.Script-script PHP harus tersimpan dalam sebuah server
dan dieksekusi atau diproses dalam server tersebut. Dengan menggunakan
program PHP, sebuah website akan lebih interaktif dan dinamis.(Madcoms, 2011)
c. Database MySQL
Database MySQL adalah jenis database yang sangat populer dan
digunakan pada banyak website di internet sebagai bank data, selain itu Database
MySQL juga dapat dijalankan dibeberapa platform, antara lain linux, windows,
dan sebagainya.(Madcoms, 2011).
2.6.5 Testing dan Implementasi
Tahap ini mendemonstrasikan sistem perangkat lunak yang telah selesai
dibuat untuk dijalankan, apakah telah sesuai dengan kebutuhan yang telah di
spesifikasikan dan dapat diadaptasi pada lingkungan sistem yang baru. Thapan ini
tertuang dalam suatu dokumen Test Plan, yang dimulai dari membuat Software
Testing fundamentals yang berisi tentang penjelasan penting mengenai
terminology tetsting, kemudian selanjutnya merancang Test Levels yang terbagi
antara target pengetesan dan objektif dari pengetesan. Pada tahap berikutnya
adalah mendefinisikan Test Techniques, yaitu tentang bagaiman teknik yang
digunakan termasuk dasar-dasar pengetesan berdasarkan intuisi dan pengalaman
serta teknik pengetesan secara teknik coding, teknik kesalahan, teknik
penggunaan, dan teknik terkait lainnya.Tahap selanjutnya adalah mendefinisikan
Test – Related Measures, yaitu ukuran-ukuran pencapaian testing yang telah
mendefinisikan test Process yang berisi tentang aktivitas testing. (England, John
Wiley & sons, 2004)
2.6.6 Maintenance
Pada tahap ini akan dilakukan pendeskripsian pekerjaan untuk
mengoperasikan dan memelihara sistem informasi pada lingkungan pengguna
termasuk implementasi akhir dan proses peninjauan kembali. Pemeliharaan sistem
ini terdiri dari beberapa jenis yaitu:
a.) Corrective, yaitu memperbaiki desain dan error pada program.
b.) Adaptive, yaitu memodifikasi sistem untuk beradaptasi dengan perubahan
lingkungan.
c.) Perfective, yaitu elibatkan sistem untuk menyelesaikan masalah baru atau
mengambil kesempatan untuk penambahan fitur.
d.) Preventive, yaitu menjaga sistem dari kemungkinan masalah di masa yang akan
datang.
Prosedur pemeliharaan tersebut disusun dalam beberapa tahapan.Tahap
awal adlah menyusun software maintenance fundamentals yang berisi tentang
dasar-dasar pemeliharaan, segalayang dibutuhkan untuk melakukan pemeliharaan,
dan ketgori pemeliharaan. Selanjutnya adalah mendefinisikan Key Issues in
Software Maintenance, yang berisi tentang teknik pemeliharaan, manajemen
pemeliharaan dan biaya, serta ukuran pemeliharaan perangkat lunak. Tahap
selanjutnya adalah mendefinisikan proses dan aktivitas pemeliharaan tersebut ke
29
Pada bab ini akan dibahas tentang identifikasi permasalahan, analisis
permasalahan, solusi permasalahan dan perancangan sistem dalam Rancang
Bangun Sistem Informasi Monitoring dan Evaluasi Pengendalian DBD pada
Dinas Kesehatan Kota Surabaya. Sebelum melakukan identifikasi dan analisis
permasalahan, telah dilakukan pengumpulan data yang dilakukan di dinas
kesehatan kota Surabaya.
3.1 Identifikasi dan Analisis Permasalahan
Identifikasi permasalahan dilakukan pada saat setelah proses wawancara
dilakukan, identifikasi dilakukan sampai menemukan titik permasalahan yang
terjadi pada dinas kesehatan kota Surabaya. Analisis dilakukan sesuai data dan
proses yang telah dikumpulkan untuk dapat menciptakan kefektifan dan ke
efisiensian bagi dinas kesehatan kota Surabaya.
Melalui analisis yang dilakukan mulai dari aktivitas pelaporan di
puskesmas sampai pelaporan di dinas kesehatan kota, diperoleh kesimpulan
bahwa permasalahan utama yang terjadi pada Dinas Kesehatan Kota Surabaya
adalah pada bagian seksi dbd puskesmas. Dimana Dinas Kesehatan mengalami
masalah pada pelaporan kasus harian, seperti tidak tepatnya pencatatan yang
dilakukan puskesmas, terkadang tidak tepat waktunya puskesmas dalam
memberikan laporan kasus yang seharusnya ditangani dalam 1X24 jam, yang
menyebabkan dinas kesehatan mengalami masalah dalam pengambilan keputusan
perpuskesmas ke dinas kesehatan dan kurangnya sumber daya manusia yang
melakukan penanganan demam berdarah dengue ( Seksi DBD Puskesmas).
Melalui proses analisis lebih jauh lagi, maka dapat dirangkum hasil identifikasi
tersebut.
Tahapan selanjutnya adalah melakukan analisis permasalahan. Analisis
permasalahan digunakan untuk mendefinisikan suatu permasalahan dan cara
mengatasi permasalahan tersebut. Dari hasil pengumpulan data yang dilakukan,
diketahui beberapa dokumen mengenai peran (role), tanggung jawab
(responsibility), aturan (rule), kebijakan (policy) serta stakeholder atau pengguna
yang terlibat dengan sistem yang sudah ada saat ini, yaitu Seksi DBD Puskesmas,
Kepala Puskesmas, Koordinator DBD, Kepala Seksi Pengendalian dan
Pemberantasan Penyakit. Secara garis besar proses bisnis monitoring dan evaluasi
pada Dinas Kesehatan Surabaya dimulai dari pencatatan dokumen kasus harian,
dengan persetujuan dari kepala puskesmas, yang dilanjutkan dengan monitoring
dan perhitungan evaluasi, dan persetujuan dari kepala seksi.
Sebelum menggambarkan proses bisnis menggunakan desain flowchart,
perlu diketahui terlebih dahulu mengenai peran (role), tanggung jawab
(responsibility), aturan (rule) dan kebijakan (policy) yang ada pada dinas
kesehatan, lebih lengkapnya bisa dilihat pada Tabel 3.1.
Tabel 3.1 Rule and Policy Berdasarkan Stakeholder
Stakeholder Proses Bisnis Phase Rule Policy Puskesmas Pelaporan
Kasus
1 R.1. Dokumen Rekapan Kasus dibuat rangkap (2) :
1. Dokumen Asli untuk arsip Puskesmas.
2. Rangkap 1 dikirim untuk Dinas
Kesehatan Kabupaten/Kota. Koordinator
Pencegahan dan Pemberantasan DBD
Monitoring dan Evaluasi Kasus
2 R.2. Didasarkan
Didasarkan atas Kejadian Luar Biasa (KLB) yang dimana membutuhkan penanganan secara cepat yang dimana perlu diperhatikan hal-hal sebagai berikut :
1. Pengumpulan data pengolahan data 2. Analisa data untuk
informasi dan evaluasi 3. Perhitungan
Indikator 4. Tindakan
pencegahan
-
3.1.1 Alir Sistem Mencatat Kasus Harian
Berikut ini merupakan alir sistem yang lebih detil untuk Alir Mencatat
Kasus Harian.Dimana hasilnya dapat dilihat pada Gambar 3.1.
Mencatat Kasus Harian
Seksi DBD Puskesmas
Start
Input Data Kasus Harian
Pembuatan Dokumen
Kasus Harian
[image:43.595.94.512.77.754.2]Draft Dokumen Kasus Harian 1
Adapun penjelasan dari Alir Sistem Mencatat Kasus Harian yang sesuai
dengan Gambar 3.1 dapat dilihat pada Tabel 3.2.
Tabel 3.2 Penjelasan Alir Sistem Mencatat Kasus Harian Phase No.
Proses
Nama Proses Input Proses Output
1 1 Input data Jumlah Kasus, Meninggal, Puskesmas
Proses ini
menjelaskan tentang Memasukkan data
kasus yang
dilakukan pada setiap hari oleh pihak puskesmas jika terjadi kasus.
-
2 Pembuatan Dokumen Kasus Harian
- Proses ini
menjelaskan tentang pembuatan dokumen yang berdasarkan inputan data kasus yang berbentuk file excel.
Draft Dokumen Kasus Harian
3.1.2 Alir Sistem Persetujuan Kasus Harian
Berikut ini merupakan alir sistem yang lebih detil untuk alir sistem
Persetujuan Kasus Harian, yang bisa dilihat pada Gambar 3.2.
Persetujuan Kasus Harian
Koordinator DBD dinkes Kepala Puskesmas
Draft Dokumen Kasus Harian
Approval Kepala Puskes mas
Acc?
Dokumen Kasus Harian acc
Y T
Dokumen Kasus Harian acc
1
Adapun penjelasan dari Alir Sistem Persetujuan Kasus Harian yang
sesuai dengan Gambar 3.2 dapat dilihat pada Tabel 3.3.
Tabel 3.3 Penjelasan Alir Sistem Persetujuan Kasus Harian Phase No.
Proses
Nama Proses Input Proses Output
1 1 Approval Kepala Puskesmas
Draft Kasus Harian
Proses ini
menjelaskan
tentang proses validasi yang dilakukan oleh kepala puskesmas
Dokumen Kasus Harian (Fix)
Decision Draft kasus harian
Proses ini
menjelaskan
tentang persetujuan yang dilakukan oleh kepala puskesmas. Jika tidak disetujui dokumen
dikembalikan kepada seksi dbd puskesmas untuk direvisi
Dokumen Kasus Harian
2 Menerima Dokumen Kasus Harian
Dokumen Kasus Harian
Proses ini
menjelaskan
tentang bagaimana pihak dinkes menerima dokumen
kasus yang
diberikan oleh pihak puskesmas
Dokumen Kasus harian
3.1.3 Alir Sistem Monitoring dan Evaluasi
Berikut adalah alir sistem lebih detil untuk Koordinator DBD, alir sistem
Monitoring dan Evaluasi dirancang sesuai dengan proses bisnis berdasarkan
proses yang terdapat pada Tabel 3.1. Lebih jelasnya dapat dilihat pada Gambar
Monitoring dan Evaluasi
Koordinator DBD Dinkes
Menerima Dokumen Kasus Harian
Dokumen Kasus Harian
Monitoring Kasus per
Hari
KLB?
Dokumen KLB dan Tindak Pencegahan
T
Y
Pembuatan Dokumen KLB
dan Tindak Pencegahan
Evaluasi Kasus Per
Bulan
Dokumen K-DBD dan Tindak Lanjut Dokumen
Kasus Harian
Pembuatan Dokumen K-DBD dan
[image:46.595.91.502.82.528.2]Tindak Lanjut 2
Gambar 3.3 Alir Sistem Monitoring dan Evaluasi
Tabel 3.4 Penjelasan Alir Sistem Monitoring dan Evaluasi Phase No.
Proses
Nama Proses Input Proses Output
1 1 Menerima
Dokumen Kasus Harian
Dokumen Kasus Harian
Proses ini menjelaskan tentang
bagaimana pihak dinkes menerima dokumen kasus yang diberikan
oleh pihak puskesmas
2 Monitoring Kasus Harian per Hari
Dokumen kasus harian
Proses ini menjelaskan tentang
monitoring yang dilakukan oleh pihak koordinator
dbd untuk
mengetahui puskesmas mana yang terkena kasus
Dokumen Kasus Harian
Decision Dokumen Kasus Harian
Proses ini menjelaskan tentang KLB yang terjadi pada puskesmas yang dimonitoring
Dokumen Kasus harian
3 Pembuatan Dokumen KLB dan Tindak Pencegahan Dokumen Kasus Harian
Proses ini menjelaskan tentang pembuatan
dokumen KLB dan tindak pencegahan yang akan dijadikan acuan pada saat evaluasi
Dokumen KLB dan Tindak Pencegahan
4 Evaluasi kasus per bulan Dokumen Kasus Harian, Dokumen KLB dan Tindak Pencegahan
Proses ini menjelaskan tentang evaluasi yang dilakukan setiap bulan, yang dimana nilai2 indikator dihitung untuk dijadikan acuan pada saat pembuatan
dokumen KDBD dan Tindak Lanjut
Dokumen KDBD dan Tindak Lanjut
5 Pembuatan Dokumen KDBD dan Tindak Lanjut Dokumen Kasus Harian, Dokumen KLB dan Tindak Pencegahan
Proses ini menjelaskan tentang pembuatan
dokumen KDBD dan tindak lanjut untuk diserahkan
kepada pihak puskesmas agar dijadikan acuan dalam
pengendalian DBD
3.1.4 Alir Sistem Persetujuan Laporan K-DBD
Berikut ini merupakan alir sistem detil untuk alir sistem Persetujuan
Laporan K-DBD, sama seperti alir sistem Monitoring dan Evaluasi, alir sistem
Persetujuan Laporan K-DBD juga dirancang sesuai dengan proses bisnis
berdasarkan proses yang terdapat pada Tabel 3.1. Lebih jelasnya dapat dilihat
pada Gambar 3.4.
Persetujuan Laporan K-DBD
Seksi DBD Puskesmas Kepala Seksi Dinkes
Dokumen K-DBD dan Tindak Lanjut
Approval Dokumen K-DBD dan Tindak Lanjut
Acc?
Dokumen K-DBD dan Tindak Lanjut
acc
Melakukan Konfirmasi kepada Seksi DBD Puskesmas
Menerima Konfirmasi K-DBD
dan tindak lanjut
Dokumen K-DBD dan Tindak Lanjut
acc Y
2 T
Adapun penjelasan dari Alir Sistem Persetujuan Laporan K-DBD yang
sesuai dengan Gambar 3.4 dapat dilihat pada Tabel 3.5.
Tabel 3.5 Penjelasan Alir Sistem Persetujuan Laporan K-DBD Phase No.
Proses
Nama Proses Input Proses Output
1 1 Approval Dokumen K-DBD dan Tindak Lanjut Dokumen K-DBD dan Tindak Lanjut
Proses ini
menjelaskan
tentang validasi kepala seksi
-
Decision Dokumen K-DBD dan Tindak Lanjut
Proses ini
menjelaskan
tentang persetujuan yang dilakukan oleh kepala seksi. Jika tidak disetujui dokumen
dikembalikan kepada koordinator dbd dinkes untuk direvisi
Dokumen K-DBD dan Tindak Lanjut Fix
2 Menerima Konfirmasi K-DBD dan Tindak Lanjut Dokumen K-DBD dan Tindak Lanjut Fix
Proses ini
menjelaskan
tentang bagaimana pihak Puskesmas menerima dokumen K-DBD dan Tindak Lanjut yang diberikan oleh pihak Dinkes untuk dijadikan acuan dalam
pengendalian dbd
Dokumen Kasus harian
Pada gambar alir sistem yang sudah dibahas sebelumnya, merupakan
gambaran mengenai alir sistem yang sedang berjalan pada dinas kesehatan saat
ini. Dari alir sistem inilah analisis dilakukan untuk mengetahui kebutuhan dari
masing-masing proses. Selain itu melalui hasil analisis pada setiap alir sistem,
menjadi satu fungsi, atau membangun fungsi baru, hal ini dilakukan agar fungsi
yang akan dibangun sesuai dengan kebutuhan masing-masing pengguna sistem
nantinya.
3.2 Permasalahan
Setelah diketahui proses atau alir sistem yang dilakukan oleh
masing-masing pengguna, maka proses berikutnya adalah melakukan analisis kebutuhan
yang sesuai dengan proses-proses tersebut. Analisis kebutuhan ini diperlukan
untuk merancang perangkat lunak yang memiliki fungsi-fungsi yang sesuai
dengan kebutuhan masing-masing pengguna. Analisis ini dilakukan pada setiap
pengguna yang secara langsung berinteraksi dengan sistem nantinya. Berikut ini
merupakan hasil analisis kebutuhan untuk masing-masing pengguna :
3.2.1 Analisis pada Pencatatan Kasus Harian
Dari identifikasi permasalahan diatas maka dilakukan analisis
permasalahan, sehingga dapat diketahui kenapa dinas kesehatan kota surabaya
mengalami hal tersebut di atas. Hasil analisis, diperoleh bahwa untuk melakukan
pelaporan, puskesmas harus melakukan pelaporan secara manual dan harus
menunggu validasi dari kepala puskesmas.
3.2.2 Analisis pada Alir Sistem Persetujuan Kasus Harian
Dari identifikasi permasalahan diatas maka dilakukan analisis
permasalahan, sehingga dapat diketahui kenapa dinas kesehatan kota surabaya
mengalami hal tersebut di atas. Hasil analisis, diperoleh bahwa kepala puskesmas
sangat lama dalam mevalidasi laporan, dikarenakan harus melakukan pengecekan
3.2.3 Analisis pada Alir Sistem Monitoring dan Evaluasi
Dari identifikasi permasalahan diatas maka dilakukan analisis
permasalahan, sehingga dapat diketahui kenapa dinas kesehatan kota surabaya
mengalami hal tersebut di atas. Hasil analisis, diperoleh bahwa pihak dinas
kesehatan dalam melakukan monitoring selalu terlambat dikarenakan harus
menunggu laporan yang dikirim oleh pihak puskesmas. Sedangkan selama ini
proses pengecekan atau pemantauan hanya sebatas melalui telepon ke pihak
puskesmas. Dan jika terjadi KLB pihak koordinator DBD dinkes hanya
melakukan tindak pencegahan dengan cara menelepon pihak puskesmas untuk
melakukan pengendalian kasus.
3.2.4 Analisis pada Alir Sistem Persetujuan K-DBD
Dari identifikasi permasalahan diatas maka dilakukan analisis
permasalahan, sehingga dapat diketahui kenapa dinas kesehatan kota surabaya
mengalami hal tersebut di atas. Hasil analisis, diperoleh bahwa pihak kepala seksi
dalam melakukan validasi sering terlambat dikarenakan proses yang dilakukan
oleh pihak koordinator juga terlambat, padahal dokumen ini sangat penting untuk
acuan pengendalian DBD disetiap puskesmas
3.3 Solusi Permasalahan
Setelah dilakukan pengumpulan data melalui proses wawancara dan
observasi, pengolahan data dari hasil observasi, dilanjutkan dengan melakukan
identifikasi dan analisis permasalahan, didapatkan suatu permasalahan yang harus
diselesaikan dengan memberikan solusi terbaik yang sesuai dengan permasalahan
dengan membangun aplikasi untuk melakukan monitoring dan evaluasi
pengendalian dbd secara web based agar memudahkan kedua belah pihak dalam
melakukan pengendalian secara real time. Kenapa harus web based? Karena
dibutuhkan kecepatan waktu dalam melakukan pelaporan, jika terlambat dalam
proses pelaporan sangat memberi dampak pada saat proses evaluasi dan
pengambilan keputusan, yang menyebabkan meningkatnya angka penderita dan
angkat orang meninggal karena demam berdarah dengue.
Dalam membangun sebuah aplikasi atau perangkat lunak sebagai solusi
pada permasalahan yang ada di dinas kesehatan kota Surabaya, dikerjakan melalui
beberapa tahapan. Tahapan pengembangan perangkat lunak tersebut terdiri dari :
3.3.1 Kebutuhan Perangkat Lunak (Software Requirement)
Kebutuhan perangkat lunak merupakan langkah awal dalam membangun
sebuah sistem atau aplikasi, hal ini dilakukan agar aplikasi yang dibangun sesuai
dengan kebutuhan pengguna. Dalam melakukan identifikasi kebutuhan perangkat
lunak, ada beberapa tahapan yang harus dilalui, yaitu :
A. Elisitasi Kebutuhan (Requirement Elicitation)
Elisitasi kebutuhan atau pengumpulan kebutuhan adalah aktivitas awal
untuk proses rekayasa kebutuhan (Requirement Engineering). Proses elisitasi
dilakukan yaitu dengan cara wawancara dan observasi awal, namun yang
dilakukan wawancara hanya kepada stakeholder yang terkait saja. Sebelum
kebutuhan dapat dianalisis, kebutuhan harus dikumpulkan melalui proses elisitasi.
diketahui data-data yang digunakan dan yang tidak digunakan terkait dengan
pengembangan perangkat lunak.
Berikut ini data yang dikumpulkan melalui proses wawancara ataupun observasi
pada dinas kesehatan. Data tersebut meliputi :
a. Data Rekap Kasus DBD Harian
Data rekap kasus dbd harian digunakan sebagai pencatatan kasus harian yang
akan dijadikan sebagai laporan kejadian K-DBD. Untuk contoh data dapat
diliat dilampiran pada table 1.
b. Data Laporan K-DBD
Data K-DBD dikumpulkan sebagai acuan dalam melakukan proses monitoring
yang digunakan yaitu data pada tahun 2006 sampai dengan 2011, sebagai data
pendukung untuk proses monitoring, maka dibutuhkan pengolahan data untuk
dapat mengetahui kasus yang ditangani secara cepat. Data jumlah kasus
tersebut juga digunakaan untuk melakukan proses evaluasi untuk menekan
jumlah kasus kedepannya. Untuk contoh data dapat diliat dilampiran pada
table 2. c. Data KLB
Data KLB digunakan sebagai melihat jumlah kasus DBD yang mengalami
KLB yang ada pada puskesmas yang dihasilkan dari data K-DBD. Untuk
contoh data dapat diliat dilampiran pada table 3.
d. Data Pengguna
Data pengguna digunakan untuk pengaturan terhadap hak akses setiap
pengguna yang terlibat dalam sistem untuk kedepannya. Untuk contoh data
e. Data Puskesmas.
Data puskesmas digunakan untuk melihat data puskesmas mana saja yang
akan dimasukkan kedalam sistem yang akan dibuat, didalamnya berupa
informasi puskesmas. Untuk contoh data dapat diliat dilampiran pada table 5.
B. Analisis Kebutuhan (Requirement Analysis)
Sesuai dengan dari hasil elisitasi data-data yang dibutuhkan untuk
membangun perangkat lunak, dibutuhkan sistem yang dibangun secara terhubung
antara puskesmas dengan seksi DBD dinas kesehatan.
B.1 Analisis Kebutuhan Seksi DBD Puskesmas
Setelah dilakukan analisis pada tahap yang sebelumnya, maka Seksi DBD
puskesmas membutuhkan peningkatan pemanfaatan informasi pengelolahan data
kasus untuk dilakukannya proses peningkatan pemanfaatan informasi
pengelolahan data kasus membutuhkan beberapa
