TA : Rancang Bangun Sistem Informasi Monitoring dan Evaluasi Pengendalian DBD Pada Dinas Kesehatan Kota Surabaya.

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 masyarakat yang setinggi-tingginya dapat terwujud, serta untuk mencapai

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 dimana daerahnya akan dilakukan penyelidikan dan pemfoggingan, sedangkan

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) = < 1% , dan Angka Bebas Jentik (ABJ) = > 95%

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 proses evaluasi dan tindak lanjut dapat segera di lakukan dan di ketahui jika di

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 selama ini antara puskesmas dan dinas kesehatan.

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 2009,Sehingga diharapkan dapat membantu Dinas Kesehatan dalam melakukan

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 mengenai sistematika penulisan pada penelitian ini.

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 sistem yang dikembangkan.

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 laporan-laporan yang diperlukan (Bocij, 2008).

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 (DBD) mulai dikenal di Indonesia sejak tahun 1968 di Surabaya dan Jakarta, dan

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 penderita termasuk tempat-tempat umum diradius sekurang-kurangnya 100m.

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. d. Untuk meberikan akses topik ke SWEBOK

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 itu sendiri.

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 lengkap.

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 yang tidak sesuai, atau dapat terjadi antara kebutuhan dan sumber daya.

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 yang termasuk didalam kelompok ini antara lain :

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

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 computer

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

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 dari disk atau output disimpan ke disk

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 konseptual.

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. 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

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 pemrograman di dalamnya. (Madcoms, 2011)

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 dalam Maintenance Process.(England, John Wiley & Sons, 2004).

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 yang akan diberikan kepada puskesmas. Permasalahan lainnya yaitu jauhnya jarak

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

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 3.3.

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

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

Dokumen Kasus Harian

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

Dokumen KDBD dan Tindak Lanjut

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, dapat diketahui proses mana yang harus dieliminasi, proses yang diintegrasikan

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 inputan kasus sesuai dengan draft yang diserahkan.

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 yang ada. Dalam menyelesaikan permasalahan, solusi yang diberikan ialah

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. Pada tahapan ini dilakukan penyeleksian data yang diperoleh sehingga dapat

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 dapat diliat dilampiran pada table 4.

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 data yaitu :

1. Data Pengguna sudah tersedia 2. Data Puskesmas sudah tersedia

Untuk membantu peningkatan pemanfaatan informasi pengolahan data kasus, proses yang akan dilakukan yaitu :

a. Seksi DBD puskesmas dapat melakukan penyimpanan secara terpusat untuk pengarsipan data.

b. Persetujuan kepala puskesmas dilakukan secara komputerisasi yang saling terhubung dan memberikan notifikasi.

c. Sistem dapat menerima notifikasi revisi ataupun disetujui oleh pihak kepala puskesmas.

d. Sistem pada Seksi DBD (puskesmas) dapat membantu memberikan laporan tentang kasus DBD secara langsung pada Seksi DBD (Dinas Kesehatan).

Dengan adanya perubahan tersebut, maka proses kedepannya akan mengalami peningkatan pemanfaatan informasi pengelolahan data kasus jika dibandingkan pada saat ini.

B.2 Analisis Kebutuhan Koordinator DBD Dinkes

Setelah dilakukan analisis pada tahap sebelumnya, maka koordinator DBD dinas kesehatan membutuhkan peningkatan informasi. Adapun peningkatan tersebut maka data yang dibutuhkan untuk menunjang proses ini adalah :

1. Data Pengguna tersedia

2. Data rekap kasus harian tersedia 3. Data Puskesmas sudah tersedia

4. Data Rekap bulanan Kasus (K-DBD) sudah tersedia 5. Data rencana tindak pencegahan tersedia

6. Data KLB sudah tersedia

Untuk membantu meningkatkan informasi, Monitoring dan Evaluasi kasus DBD pada setiap puskesmas, maka dilakukan proses sebagai berikut :

a. Koordinator DBD dapat menerima rekapan data kasus harian oleh pihak seksi DBD puskesmas secara langsung dengan menerima notifikasi pada sistem.

b. Bagian koordinator DBD melakukan monitoring berdasarkan kasus perpuskesmas yang diterima secara terkomputerisasi

c. Sistem memberikan notitifikasi jika terjadi KLB pada saat dilakukannya monitoring

d. Bagian koordinator DBD memberikan notifikasi kepada puskesmas untuk dilakukan tindak lanjut pencegahan

e. Bagian koordinator melakukan perhitungan evaluasi secara terkomputerisasi berdasarkan hasil monitoring

f. Bagian koordinator DBD tidak melakukan rekap data kasus harian secara manual untuk dijadikan grafik data dan laporan bulanan (K-DBD), dengan adanya sistem yang terpusat tersebut maka akan dapat secara langsung dilakukan grafik data dan rekap kasus bulanan (K-DBD).

g. Koordinator DBD dapat melakukan penyimpanan secara terpusat untuk pengarsipan data.

Dengan adanya perubahan tersebut, maka proses kedepannya akan mengalami peningkatan pemanfaatan informasi yang lebih cepat dan proses monitoring dan evaluasi kasus dapat memberikan hasil yang tepat dan lebih baik.

C. Spesifikasi kebutuhan perangkat lunak.

Dalam membangun dan mengembangkan perangkat lunak, diperlukan perancangan spesifikasi perangkat lunak yang tepat dan detil, dengan tujuan agar perangkat lunak yang akan dikembangkan tersebut memiliki deskripsi fungsi yang sesuai dengan apa yang dibutuhkan oleh masing-masing pengguna. Kebutuhan fungsi tersebut meliputi kebutuhan fungsional dan non-fungsional.

C.1 Staf Operasional

Kebutuhan fungsional beserta penjelasannya untuk Seksi DBD Puskesmas dapat dilihat pada Tabel 3.6.

Tabel 3.6 Detil Kebutuhan Fungsi Pencatatan Kasus Harian NamaFungsi Mencatat Data Harian Kasus DBD

Stakeholder Seksi DBD (Puskesmas)

Deskripsi Fungsi ini digunakan untuk pencatatan data kasus harian yang akan diberikan kepada seksi DBD dinas kesehatan.

KondisiAwal 1. Data Pengguna sudah tersedia 2. Data Puskesmas sudah tersedia 3. Data Kasus Harian Sudah Tersedia

Alur Normal AksiPengguna ResponSistem

Otentifikasi

1. Pengguna memasukkan

Username dan

Password.

1.A) Sistem akan melakukan verifikasi

pengguna yang

melakukan login.

B) Sistem

menampilkan

Hala a Me u

Uta a da

memberikan Hak

akses penguna.

Input Data Kasus Harian

1. Pengguna memilih

sub e u I put

Kasus Harian pada menu master.

1. A) Sistem

menampilkan menu

I put Kasus Harian

B) Sistem

menampilkan tanggal, Kecamatan, jumlah

Kasus, Kasus

Meninggal dan Total per hari.

2. Pengguna

memasukan jumlah kasus

2.A) Sistem menyimpan ke database.

B) Sistem megupdate data kasus harian.

Pembuatan Dokumen Kasus Harian

1. Pengguna memilih

Dokumen Kasus

Harian

3. A) Sistem

menampilkan menu

Doku e Kasus

Haria

B) Sistem

menampilkan

Dokumen Kasus

C) Sistem memberikan alert dan memberikan

informasi untuk

meminta persetujuan

kepada kepala

Puskesmas. 2. Pengguna memilih

range tanggal yang diinginkan

4.Sistem menampilkan dokumen kasus harian yang telah dipilih pengguna

3. Pengguna memilih cetak

5.Sistem Melakukan cetak

AlurAlternatif AksiPengguna ResponSistem

- -

AlurEksepsi AksiPengguna ResponSistem

Otentifikasi Login

1. Pengguna salah

memasukkan

username ataupun password ataupun keduanya.

1. Sistem

menampilkan pesan terjadinya salah memasukkan

username maupun password

KondisiAkhir 1. Menghasilkan Draft Laporan Rekapan Harian Kasus DBD

Kebutuhan Non-Fungsional

Security

Fungsi mencatat data Kasus Harian ini hanya dapat digunakan oleh yang memiliki hak akses saja

Correctness

Sistem memberikan Peringatan jika terjadi salah input.

Interface

1. Menu yang tersedia dalam bahasa indonesia. 2. Menu dan warna mudah dipahami dan tidak mencolok.

Performance Operability

C.2 Kepala Puskesmas

Kebutuhan fungsional dan beserta penjelasannya untuk Kepala Puskesmas dapat dilihat pada Tabel 3.7.

Tabel 3.7 Detil Kebutuhan Fungsi Persetujuan Kasus Harian NamaFungsi Persetujuan Dokumen Kasus Harian

Stakeholder Kepala Puskesmas

Deskripsi Fungsi ini digunakan untuk persetujuan laporan kasus harian pada seksi DBD (Puskesmas)

KondisiAwal 1. Data Pengguna tersedia. 2. Data Kasus tersedia

3. Data Rekapan kasus harian tersedia.

Alur Normal AksiPengguna ResponSistem

Otentifikasi

1. Pengguna Memasukkan

Username &

Password.

1. A) Sistem akan

melakukan verifikasi

pengguna yang

melakukan login.

B) Sistem

menampilkan Alert

dan meminta

permintaan persetujuan.

B) Sistem

menampilkan

Hala a Me u

Uta a da

memberikan Hak

akses penguna.

Approval Kepala Puskesmas

1. Pengguna memilih

sub menu

Persetujua Draft Kasus Harian

1. A) Sistem

menampilkan menu persetujuan Draft Kasus Harian.

B) Sistem

menampilkan tanggal, Kecamatan, jumlah

Kasus, Kasus

Meninggal dan Total per hari.

2. Pengguna melakukan persetujuan

2.A) Sistem menyimpan data yang telah disetujui.

B) Sistem melakukan laporan peringatan kepada seksi DBD (Puskesmas).

AlurAlternatif AksiPengguna ResponSistem

- -

AlurEksepsi AksiPengguna ResponSistem

Otentifikasi Login

1. Pengguna salah

memasukkan

username ataupun password ataupun keduanya.

1. Sistem

menampilkan pesan terjadinya salah memasukkan

username maupun password

Approval Kepala Puskesmas

2. Pengguna mendapatkan

informasi untuk permintaan

persetujuan usulan.

2. Sistem

menampilkan

notifikasi adanya permintaan

persetujuan

KondisiAkhir 1. Menghasilkan Dokumen Kasus Harian (KepPus)

Kebutuhan Non-Fungsional

Security

Fungsi persetujuan dokumen ini hanya dapat digunakan oleh yang memiliki hak akses saja

Correctness

Sistem memberikan peringatan jika terjadi salah input

Interface

1. Menu yang tersedia dalam bahasa indonesia. 2. Menu dan warna mudah dipahami dan tidak mencolok.

Performance Operability

C.3 Koordinator DBD Dinkes

Kebutuhan fungsional dan beserta penjelasannya untuk Koordinator DBD Dinkes dapat dilihat pada Tabel 3.8.

Tabel 3.8 Detil Kebutuhan Fungsi Monitoring dan Evaluasi NamaFungsi Monitoring dan Evaluasi Kasus

Stakeholder Koordinator DBD Dinas Kesehatan

Deskripsi Fungsi ini digunakan untuk penyusunan jumlah kasus yang diberikan dari setiap puskesmas.

KondisiAwal 1. Data Pengguna Tersedia

2. Data Rekap Kasus Harian Tersedia

3. Data Rekap Kasus Bulanan (K-DBD) Tersedia 4. Data KLB tersedia

5. Data Puskesmas Tersedia

Alur Normal AksiPengguna ResponSistem Otentifikasi

1. Pengguna memasukkan Username dan Password

1. A)Sistem akan melakukan verifikasi pengguna yang melakukan login.

B) Sistem menampilkan

Hala a Me u Uta a da

memberikan Hak akses

penguna.

C) Sistem menampilkan Alert telah dilakukan pencatatan kasus harian Puskesmas. D) Sistem menampilkan daftar

puskesmas yang telah

melakukan pencatatan.

Menerima Dokumen Kasus Harian 1. Pengguna

membuka halaman utama.

1. A) Sistem menampilkan

Hala a Uta a

B) Sistem menampilkan notifikasi telah dilakukannya penyusunan Dokumen kasus harian.

C) Sistem menampilkan list puskesmas yang sudah melakukan penyusunan

Monitoring setiap hari jika terjadi kasus

1. Pengguna memilih menu monitoring.

1. Sistem menampilkan

o itori g . 2. Pengguna

melakukan monitoring.

2. A) Sistem menampilkan

dashboard monitoring kasus dengan tanggal dan puskesmas yang dipilih.

B) Sistem menampilkan jumlah kasus perpuskesmas.

C) Sistem memberikan

notifikasi jika terjadi KLB pada

waktu dilakukannya

Membuat Dokumen KLB

1. Pengguna membuat dokumen KLB

1. A) Siste e a pilka KLB

B) Sistem melakukan

perhitungan KLB yang dimana

i dikator ya jika kasus=

penderita >=3 atau meninggal >=1 maka daerah tersebut

terke a KLB

C) Sistem menampilkan

notifikasi puskesmas yang terkena KLB

D) Pengguna melakukan input rencana tindak pencegahan E) Sistem menyimpan rencana tindak pencegahan

F) Sistem memberikan

notifikasi kepada puskesmas

2. Pengguna memilih puskesmas

yang akan

dicetak.

2. A) Sistem menampilkan

dokumen rencana tindak

pencegahan

B) Sistem mencetak dokumen tindak pencegahan

Evaluasi setiap 1 bulan

1. Pengguna memilih menu Evaluasi

1. Sistem menampilkan

evaluasi . 2. Pengguna

melakukan Evaluasi

2. A) Sistem memberi pilihan tanggal untuk menampilkan pola data

B) Sistem Menampilkan

perhitungan evaluasi dengan

perhitu ga

(IR=(kasus/penduduk)x100%), (CFR=(meninggal/kasus)x100%), (ABJ=(bebas

jentik/penduduk)x100%)

C) Sistem menampilkan Data Kasus bulanan (k-dbd) dan grafik perpuskesmas

D) Sistem Menyimpan dan

Mengupdate data kasus

bulanan (K-DBD)

Tabel 4.14 Data Kasus yang terjadi diseluruh Puskesmas

Puskesmas

Jumlah

Penderita Meninggal

Tanjungsari 7 0

Simomulyo 12 0

Manukan Kulon 53 0

Balongsari 18 1

Asemrowo 14 0

Sememi 40 0

Benowo 22 0

Jeruk 9 0

Lidah Kulon 12 0

Bangkingan 1 0

Lontar 23 1

Made 7 0

Peneleh 15 0

Ketabang 1 0

Kedung Doro 10 0

dr. Soetomo 15 0

Tembok Dukuh 27 0

Gundih 17 0

Tambak Rejo 26 1

Simolawang 5 0

Perak Timur 31 0

Pegirian 9 1

Sidotopo 15 0

Wonokusumo 13 0

Krembangan

Selatan 23 0

Dupak 25 0

Tnh. KL.

Kedinding 21 0

Kenjeran 9 0

Sidotopo Wetan 40 0

Rangkah 15 0

Pacar Keling 24 0

Gading 32 0

Pucang Sewu 15 0

Mojo 14 0

Kali Rungkut 6 0

Medokan Ayu 11 0

Tenggilis 34 0

112

Menur 8 0

Kalmpisngasem 1 0

Keputih 20 0

Mulyorejo 24 0

Sawahan 21 0

Putat Jaya 41 0

Pakis 12 0

Banyu Urip 26 0

Jagir 13 1

Wonokromo 12 0

Ngagel Rejo 8 0

Kedurus 21 0

Dukuh Kupang 17 1

Wiyung 19 0

Balas Klumprik 7 0

Gayungan 13 1

Jemur Sari 13 0

Siwalankerto 8 0

Sidosermo 12 0

Kebon Sari 16 0

4.4.1 Perhitungan Dengan Aplikasi

Perhitungan evaluasi kasus secara terkomputerisasi yang diimplementasikan kedalam sebuah aplikasi ini dilakukan dengan cara indicator-indikator yang telah dinputkan yang direkap setiap bulannya Dari hasil evaluasi pada bulan Januari, nantinya akan dibandingkan dengan kondisi yang ada di dinkes pada saat itu, sehingga dapat diketahui perbedaan antara evaluasi yang dilakukan dinkes secara manual dengan evaluasi yang dilakukan menggunakan sistem. Berdasarkan hasil perhitungan secara terkomputerisasi, hasil evaluasi kasus pada bulan januari tampak pada Gambar 4.11

Gambar 4.11 Evaluasi Kasus Menggunakan Aplikasi

Dari Gambar 4.11 dapat disimpulkan bahwa evaluasi kasus yang dilakukan menghasilkan alert yang digunakan untuk rencana tindak lanjut, yaitu alert berupa warna merah yang berarti hasi evaluasi tidak sesuai dengan target yang diharapkan yaitu ABJ >95%, dan alert berwarna hijau sesuai target yang diharpkan dengan IR <55/100.000 penduduk, dan CFR < 1%.

4.4.2 Perhitungan Manual Tanpa Aplikasi

Perhitungan manual yang dimaksud adalah evalusai untuk 3 indikator yang dilakukan dinkes pada bulan Januari. Lebih jelas mengenai evaluasi yang dilakukan dapat dilihat pada Gambar 4.12.

114

Pada evaluasi perhitungan manual, penggunaan variabel-variabel disamakan dengan perhitungan memakai aplikasi yang meliputi banyaknya periode, data perndertia, meninggal, jumlah penduduk dan rumah bebas jentik sehingga diperoleh perhitungan dengan output yang sama agar dapat dilakukan perbandingan dengan hasil dari penggunaan aplikasi.

4.4.3Perbandingan Hasil Evaluasi

Dari hasil uji coba melalui aplikasi dan melalui perhitungan secara manual, tidak terdapat perbedaan perhitungan. Yang membedakan hanyalah informasi yang terdapat pada aplikasi yang dimana aplikasi memberikan alert berupa warna jika pada perhitungan indicator salah satunya tidak mencapai target. Serta dalam satu laporan evaluasi terdapat keterangan untuk menindak lanjuti hasil dari alert tersebut.

Dengan adanya alert yang diberikan secara real time dapat mempermudah pihak koordinator dalam menajalankan tugasnya, dimana dengan adanya alert tidak terjadi lagi keterlambatan dalam melakukan pelaporan dan tidak ada lagi kekeliruan dalam melakukan pencatatan.

115 5.1 Kesimpulan

Berdasarkan hasil uji coba dan evaluasi yang dilakukan pada bab 4 maka dapat diperoleh kesimpulan sebagai berikut :

1. Aplikasi dapat memberikan hasil monitoring setiap hari dan evaluasi setiap bulannya, sehingga pada saat terjadi KLB, koordinator sudah mengetahui dan memberikan dokumen tindak pencegahan, dan tidak sampai menimbulkan permasalahan angka penderita dan meninggal meningkat. 2. Aplikasi dapat memberikan hasil monitoring dan evaluasi lebih cepat dan

akurat, sehingga pencatatan dan pemberian dokumen kasus harian tidak lagi mengalami keterlambatan.

5.2 Saran

Adapun saran yang dapat diberikan pada penelitian ini adalah sebagai berikut:

1. Penelitian dapat dikembangkan dengan menambahkan fasilitas mapping untuk mengetahui daerah yang terjadi KLB.

2. Penelitian dapat dikembangkan dengan menambahkan fasilitas mapping perpuskesmas agar pihak dinas kesehatan mengetahui daerah mana yang rawan terhadap penyebaran DBD.

116

DAFTAR PUSTAKA

Bojic, Paul, 2008, Business Information System. Pearson Education Ltd., England Burch, John dan Grudnitski, Gary, 1986, Information Systems Theory and

Practice, John Wiley and Sons, New York.

Depkes RI, 2011, Modul Pencegahan dan Pengendalian Penyakit DBD, Jakarta England, John Willey & Sons.IEEE.“Guide to the Software Egineering Body of

Knowledge 2004 version :”SWEBOK A Project of the IEEE Computer Society

Hedwig, Rinda, 2007, Sistem Penjaminan Mutu di Perguruan Tinggi Monitoring dan Evaluasi Internal, Graha Ilmu, Yogyakarta

Kadir, Abdul, 2009, Dasar Aplikasi Mysql-Delphi, Andi Publisher, Yogyakarta MADCOMS, 2007, Dreamweaver CS3 dan PHP-Mysql untuk pemula, Andi

Publisher, Yogyakarta

Moleong, Lexy, 2005, Metodologi Penelitian Kualitatif, PT. Remaja Rosdakarya, Bandung

Nugroho, Benafit, 2008, Latihan Membuat Aplikasi Web PHP dan Mysql dengan Dreamweaver, Gava Media, Yogyakarta

Rahayu, Iin Tri.dan Ardani, Tristiadi Ardi, 2004, Observasi dan Wawancara, Bayu Media Publishing, Malang

Sugiyono, 2007, Metodologi Penelitian Kuantitatif, Kualitatif, R&D, Alfabeta, Bandung