3.1. Tinjauan Perusahaan
Tinjauan perusahaan ini akan membahas mengenai sejarah berdirinya Rumah Sakit Muhammadiyah Bandung, dan struktur organisasi nya
3.1.1. Sejarah Perusahaan
Pada tahun 1965 sebelum Muktamar Muhammadiyah ke – 36 diselenggarakan, Gubernur Provinsi Jawa Barat Bapak Mayjen Masjhudi meminta kepada Pimpinan Wilayah Muhammadiyah Jawa Barat agar segera memprakarsai berdirinya sebuah Rumah Sakit Islam di Bandung, alasannya karena atas dasar tuntutan masyarakat Jawa Barat dan sudah ada 5 yayasan yang akan mendirikan Rumah Sakit Islam, tetapi tidak terwujud.
Sebagai tindak lanjut dari keinginan tersebut, maka pada Muktamar Muhammadiyah ke – 36 yang dilaksanakan pada bulan Juli 1965 di Bandung, dihasilkan suatu keputusan antara lain agar di setiap provinsi di seluruh Indonesia dibangun sebuah Rumah Sakit Muhammadiyah, Sekolah Perawat dan Sekolah Bidan.
Terdorong atas rasa tanggung jawab dan keprihatinan umat islam di Bandung, khususnya Muhammadiyah dengan melihat kenyataan di Bandung ini hanya ada 5 buah RS Swasta milik non muslim. Niat ini kemudian disampaikan dalam sebuah rapat pleno Pimpinan Wilayah Muhammadiyah dan ‘Aisyiyah tahun 1967 dan Rapat Kerja Majelis Pendidikan dan Kesejahteraan Ummat
30
(PKU), agar di Bandung segera didirikan Rumah Ssakit Muhammadiyah, yang kemudian disetujui untuk segera didirikan.
Langkah awal segera dilakukan dalam menentukan titik lokasi didirikannya Rumah Sakit Islam Muhammadiyah, yaitu dengan meminta saran kepada Walikota Kota Madya Bandung, Bapak E. Sukarna Widjaya dan Kepala Dinas, Bapak Dr. Uton Muchtar Rafe’i, MPH, bahwa RS. Muhammadiyah harus segera dibangun di wilayah Karees, yang setelah dianalisa ternyata sesuai dengan rencana pengembangan kota, karena di wilayah-wilayah lain pelayanan telah terpenuhi.
Pimpinan Wilayah Muhammadiyah saat itu mengadakan musyawarah dengan Pimpinan Muhammadiyah Daerah Priangan, Pimpinan Muhammadiyah Cabang Bandung Lama, Bagian PKU Cabang, Pimpinan ‘Aisyiyah Cabang Bandung Lama dan dari musyawarah tersebut dihasilkan suatu keputusan, bahwa lokasi gedung Panti Asuhan Taman Harapan Muhammadiyah dan Asrama Putri
‘Aisyiyah setuju ditukar amal usahanya dengan RS. Islam Muhammadiyah.
Sesuai dengan berita acara serah terima gedung No. 130-47/13 tertanggal 1 September 1967, maka Panti Asuhan Taman Harapan Muhammadiyah yang semula terletak di Jl. Banteng No. 53 dipindahkan ke Jl. Nilem No. 9 (Bekas Poliklinik Bersalin Muhammadiyah Cabang Lengkong), sedangkan Asrama Putri
‘Aisyiyah dipindah ke Asrama Muslihat Jl. Buahbatu Bandung.
Alasan didirikannya RS. Islam Muhammadiyah di bekas lokasi Panti Asuhan tersebut adalah:
1. Biaya tidak banyak, hanya perbaikan lokal, dan kamar-kamar.
2. Perijinan dari Departemen sosial sudah ada.
3. Dukungan masyarakat dan keluarga Muhammadiyah 4. Fasilitas air dan listrik sudah mencukupi.
5. Pemerintah Kotamadya Bandung akan mudah memberi ijin.
6. Bapak Gubernur dan Walikota sudah diberikan laporannya dan setuju.
7. Usaha dan kerja terbatas untuk pengadaan peralatan dan renovasi kecil saja
Saatnya untuk membuktikan kepada masyarakat dan pemerintah bahwa Muhammadiyah mampu mendirikan rumah sakit dan berusaha membentuksebuah rumah sakit yang disesuaikan dengan kemampuan situasi dan kondisi fisik bangunan. Untuk mewujudkan keinginan mendirikan Rumah Sakit Islam tersebut, maka dibentuklah Panitia Pelaksana Pembangunan yang terdiri dari:
1. Adang Affandi (Ketua dan Usaha Dana)
2. Abu Bakrin (Ketua I, Urusan Pembangunan Fisik dan Logistik) 3. Uton Muchtar Rafe’i, MPH (Ketua II, Urusan Medis dan Perijinan) 4. Asikin Sanhadji (Sekretaris merangkap urusan perijinan dan usaha
dana)
5. M. Mustafa (Bendahara)
6. Sachron Fadjar (Anggota Urusan Medis) 7. Ahmad Wiratmadja (Anggota Urusan Dana) 8. Sulaeman Faruq (Publikasi)
Sedangkan rencana renovasinya dipimpin oleh Ketua II yang diserahkan kepada Sdr. Tengku Z. Abidin dibantu oleh para mahasiswa ITB dan Himpunan
Mahasiswa Islam dan Ikatan Mahasiswa Muhammadiyah yang dilaksanakan pada bulan Juni 1968.
Akhirnya pada hari Sabtu tanggal 17 November 1968 bertepatan dengan tanggal 27 Sya’ban 1338 H Rumah Sakit Islam Muhammadiyah dibuka secara resmi oleh Gubernur Jawa Barat Mayjen Masjhudi dan Pimpinan Pusat Muhammadiyah, Bapak HM. Yunus Anis dan dinyatakan mulai beroperasi pada tanggal 18 November 1968, dibawah langsung Pimpinan Wilayah Muhammadiyah Jawa Barat.
A. Visi
Menjadi Rumah Sakit Islam Unggulan di Jawa Barat Tahun 2018 B. Misi
Adapun misi dari Klinik Dokter Kita dalam menjalankan pelayanannya antara lain:
1. Mewujudkan pelayanan yang prima.
2. Membangun SDM dan operasional yang berkualitas.
3. Ketersediaan saranan dan prasaranan yang memadai.
4. Meningkatkan kualitas kesehatan masyarakat.
C. Tujuan
1. Meningkatkan mutu pelayanan kesehatan.
2. Meningkatkan pelayanan yang berdaya saing dengan berbasis IT.
3. Mewujudkan profesionalisme SDI yang islami untuk meningkatkan mutu pelayanan.
4. Meningkatkan Mutu pelayanan melalui peningkatan sarana dan prasarana.
5. Mengoptimalkan pengelolaan program JKN melalui peningkatan kemitraan dengan pemangku kepentingan.
6. Meningkatkan promosi RS melalui Syi’ar Dakwah Islam.
3.1.2. Struktur Organisasi
Rumah Sakit Islam Muhammadiyah memiliki struktur organisasi yang dibentuk untuk mengkoordinasikan dan membagi tugas dari masing-masing posisi.
Gambar III.1 Struktur Organisasi RS Muhammadiyah Bandung Periode 2014-2019
Sumber : Rumah Sakit Muhammadiyah Bandung
3.2. Analisa Kebutuhan Aplikasi
Analisa kebutuhan aplikasi yang akan dikembangkan yaitu untuk mengetahui bagaimana cara kerja sistem pakar diagnosa penyakit bergejala demam menggunakan metode certainty factor berbasis android. Berikut ini kebutuhan aplikasi untuk diagnose penyakit bergejala demam:
3.2.1. Identifikasi Masalah
Berdasarkan bab yang telah dibahas sebelumnya, maka dapat didefinisikan beberapa permasalahan sebagai berikut :
1. Kurangnya pengetahuan masyarakat sehingga sering menyepelekan penyakit yang diderita sehingga tidak ada penanganan yang tepat.
2. Terdapat kendala dalam identifikasi penyakit bergejala demam.
3.2.2. Analisa Kebutuhan Aplikasi
Aplikasi yang akan dibangun ini memerlukan berbagai macam fungsi- fungsi yang akan menunjang pembuatan dan pengembangannya. Oleh karena itu diperlukan tahap analisa kebutuhan aplikasi yang merupakan proses menganalisis dan mengumpulkan kebutuhan-kebutuhan sistem yang sesuai dengan informasi yang dikumpulkan, guna menentukan solusi aplikasi yang akan dibangun.
A. Tahapan Analisa
Pada tahapan ini perlu dirincikan spesifikasi kebutuhan dari sistem pakar menggunakan metode Certainty Factor.
Halaman Aplikasi Pengguna:
A1. Pengguna dapat melakukan login dengan memasukkan username dan password.
A2. Pengguna dapat melakukan diagnosa dari hasil perhitungan diagnosa.
A3. Pengguna dapat mengakses halaman informasi.
A4. Pengguna dapat mengelola gejala.
A5. Pengguna dapat mengelola penyakit yang memiliki gejala demam.
A6. Pengguna dapat mengelola metode.
B. Kebutuhan Perangkat Keras (Hardware)
Kebutuhan perangkat keras (Hardware) merupakan analisa kebutuhan sistem yang digunakan untuk mengetahui secara jelas perangkat yang dibutuhkan untuk aplikasi sistem pakar diagnosa penyakit bergejala demam. Adapun spesifikasinya adalah sebagai berikut:
1. Spesifikasi Perangkat Keras Komputer a. Processor Intel(R) Celeron(R) CPU N3060 @1.60GHz b. RAM 4GB
c. Harddisk 1 TeraByte d. Screen 14”HD
2. Spesifikasi Perangkat Keras Smartphone
a. CPU Snapdragon 435 Octa-Core 1.4 GHz Cortex-A53, GPU Qualcomm
b. RAM 3 GB
c. Storage 32 GB
d. Layar 5 inches, 720x1280 pixels
C. Kebutuhan Perangkat Lunak (Software)
Kebutuhan perangkat lunak (software) yaitu program yang diperlukan untuk melakukan proses intruksi atau menjalankan perangkat keras. Agar aplikasi dapat dibuat dan diimplementasikan sesuai perancangan, maka diperlukan suatu perangkat lunak. Adapun spesifikasi software yang dibutuhkan adalah:
1. Spesifikasi Perangkat Lunak
Komputer
a. Sistem Operasi Ms.
Windows 10 64-bit
b. Android Studio v3.4.1
for Windows 64-bit
2. Spesifikasi Perangkat Lunak Software
a. Android OS v7.1.2
(Nougat) 3.3. Desain
Aplikasi ini umumnya di desain untuk memberikan kemudahan pengguna dalam mengaksesnya serta memberikan gambaran rancangan dan isi dari aplikasi yang di bangun. Rancangan dibuat dengan mengidentifikasi komponen-komponen dalam sistem yang akan mendukung aplikasi yang dibuat agar lebih efisien, menarik dan bisa dipakai oleh semua pengguna android.
3.3.1. Rancangan Algoritma
Dibawah ini merupakan table gejala dari algoritma certainty factor yang dibuat untuk membangun aplikasi diagnosis penyakit bergejala demam.
A. Algoritma Certainty Factor
Pada bagian ini dijelaskan penerapan algoritma Certainty Factor pada aplikasi yang ditunjukkan pada gambar III.2 menggunakan flow chart.
Gambar III.2. Flow Chart Algoritma Certainty Factor
Pada Gambar III.2 dapat dijelaskan bahwa penerapan algoritma Certainty Factor pada aplikasi dilakukan dengan inferensi dan fungsi perhitungan kepastian dari basis pengetahuan. Perhitungan dilakukan dengan menentukan nilai MB
(Measure of Belief) dan nilai MD (Measure of Disbelief) pada rumus Certainty Factor.
A. Tabel Pakar
Dalam membangun sebuah aplikasi sistem pakar diagnosa penyakit bergejala demam ini peneliti ambil 5 jenis penyakit bergejala demam dan 17 gejala yang berkaitan dengan penyakit bergejala demam. Tabel daftar jenis penyakit bergejala demam dapat dilihat di table berikut:
Tabel III.1. Tabel daftar penyakit bergejala demam
Kode Jenis Penyakit
P01 Malaria
P02 Demam Berdarah
P03 Tipus
P04 Radang Tenggorokan
P05 Hepatitis
Tabel III.2. Tabel daftar gejala
Kode Nama Gejala
G001 Sakit kepala parah
G002 Mual dan muntah
G003 Diare
G004 Nyeri otot dan sendi
G005 Tidak nafsu makan
G006 Panas dingin
G007 Pendarahan
G008 Demam
G009 Tubuh menggigil
G010 Munculnya bintik bintik merah
G011 Nyeri menelan
G012 Kuning pada kulit dan mata
G013 Nyeri perut
G014 Urin gelap
G015 Pusing
G016 Lemah. Letih, lesu
G017 Menurunnya jumlah trombosit
Tabel III.3. Tabel Malaria
Kode Nama Gejala Nilai pakar
G001 Sakit kepala parah 0,9
G002 Mual dan muntah 0,7
G004 Nyeri otot dan sendi 0,6
G008 Demam 0,9
G005 Tidak nafsu makan 0,8
G009 Tubuh menggigil 0,7
G016 Letih, lemah, lesu 0,8
Tabel III.4 Tabel Demam berdarah
Kode Nama Gejala Nilai Pakar
G001 Sakit kepala parah 0,9
G004 Nyeri otot dan sendi 0,7
G010 Munculnya bintik bintik merah 0,9
G005 Tidak nafsu makan 0,7
G017 Menurunnya jumlah trombosit 0,2
G002 Mual dan muntah 0,6
G008 Demam 0.9
Tabel III.5 Tabel tipus
Kode Nama Gejala Nilai pakar
G008 Demam 0,9
G004 Nyeri perut 0,9
G003 Diare 0,8
G001 Sakit kepala parah 0,4
G002 Mual dan muntah 0,6
G006 Panas dingin 0,3
Tabel III.6 Tabel radang tenggorokan
Kode Nama Gejala Nilai pakar
G008 Demam 0,9
G011 Nyeri menelan 0,9
G016 Letih, lemah, lesu 0,7
G005 Tidak nafsu makan 0,8
G004 Nyeri otot 0,3
G012 Pusing 0,2
G013 Nyeri perut 0,4
Tabel III.7 Tabel Hepatitis
Kode Nama Gejala Nilai pakar
G013 Nyeri perut 0,8
G008 Demam 0,9
G001 Sakit kepala parah 0,8
G002 Mual dan muntah 0,7
G016 Letih, lemah. Lesu 0,8
G005 Tidak nafsu makan 0,6
G012 Kuning pada kulit dan mata 0,9
G014 Urin berwarna gelap 0,9
G004 Nyeri otot 0,4
G009 Tubuh menggigil 0,5
B. Perhitungan Algoritma
Berisikan aturan-aturan untuk pengambilan keputusan. Pada kasus baru terdapat seorang pasien yang menderita gejala-gejala sebagai berikut:
1. Demam (G008)
2. Tubuh menggigil (G009) 3. Diare (G003)
4. Mual dan muntah (G002)
Maka langkah-langkah dari metode Certainty Factor terhadap kepastian bahwa pasien terkena penyakit malaria dapat diselesaikan sebagai berikut:
CF G008 = CF(user)*CF(pakar)
= 0.3 * 0.9
= 0.27
CF G009 = CF(user)*CF(pakar)
= 0.3 * 0.7
= 0.21
CF G003 = CF(user)*CF(pakar)
= 0.6 * 0.2
= 0.12
CF G002 = CF(user)*CF(pakar)
= 0.9 * 0.4
= 0.36
CF combain1 (CFg1, CFg2) = CFg1 + CFg2 (1-CFg1) = 0.27 + 0.21* (1-0.27) = 0.48*0.73
= 0.4233
CF combain2 (CFold1, CFg3) = CFold1 + CFg3 (1-CFold1) = 0.4233 + 0.12 * (1- 0.4233) = 0.5433 + 0.5767
=1.12
CF combain3 (CFold2, CFg4) = CFold2 + CFg4 (1-CFold2)
= 1.12 + 0.12 (1-1.12)
= 1.24+0.12
=1 3.3.2. Database
1. Entity Relationship Diagram (ERD)
Menggambarkan hubungan antar tabel yang dibuat beserta relasinya. Dalam penggambaran basis data pada perancangan ini menggunakan Entity Relationship Diagram (ERD).
Gambar III.3. Entity Relationship Diagram Aplikasi Diagnosa Gejala Demam
2. Spesifikasi File
a. Spesifikasi File Tabel Gejala Nama Database : fever_check Nama File : Gejala
Akronim : gejala
Akses File : All Privileges Kunci Field : id
Tabel III.8.
Spesifikasi File Tabel Gejala
No Elemen Data Nama Field Type Size Keterangan
1 ID Gejala id_gejala Varchar 50 Primary Key
2 Nama Gejala nama_gejala Varchar 200
b. Spesifikasi File Tabel Metode Nama Database : fever_check
Nama File : Metode
Akronim : metode
Akses File : All Privileges Kunci Field : id
Tabel III.9.
Spesifikasi File Tabel Metode
No Elemen Data Nama Field Type Size Keterangan
1 ID Metode id_metode Integer AI Primary Key
2 ID Penyakit id_penyakit Varchar 50 Foreign Key
3 ID Gejala id_gejala Varchar 50 Foreign Key
4 Nilai Pakar Mb Double -
5 Nilai User Md Double -
c. Spesifikasi File Tabel Pengguna Nama Database : fever_check Nama File : Pengguna
Akronim : pengguna Akses File : All Privileges Kunci Field : id
Tabel III.10.
Spesifikasi File Tabel Pengguna
No Elemen Data Nama Field Type Size Keterangan
1 ID Pengguna Username Varchar 50 Primary Key
2 Kata Sandi Password Varchar 50
d. Spesifikasi File Tabel Penyakit Nama Database : fever_check Nama File : Penyakit
Akronim : penyakit
Akses File : All Privileges Kunci Field : id
Tabel III.11.
Spesifikasi File Tabel Penyakit
No Elemen Data Nama Field Type Size Keterangan
1 ID Penyakit id_penyakit Varchar 50 Primary Key
3 Nama Penyakit nama_penyakit Varchar 200 4 Solusi Penyakit solusi_penyakit Varchar 200
3.3.3. Software Architecture
Pada tahapan ini, penulis menggambarkan diagram-diagram terkait dengan program yang dibuat. Adapun diagram-diagramnya adalah sebagai berikut:
A.Use Case Diagram
Use case diagram pada aplikasi yang akan dibangun digambarkan hanya yang terkait dengan proses saja ditunjukkan pada Gambar III.4.
Gambar III.4. Use Case Diagram Sistem Pakar 1. Deskripsi Use Case melakukan Login
Kegiatan atau interaksi antara pengguna dengan aplikasi dalam melakukan login dapat dilihat pada Tabel III.12.
Tabel III.12.
Deskripsi Use Case Melakukan Kelola Use Case Name Melakukan Kelola
Requirements A1
Goal Pengguna dapat melakukan login pada aplikasi Fever Check.
Pre-conditions Pengguna telah menjalankan aplikasi.
Post-conditions Aplikasi membuka halaman utama (home page).
Failed end conditions Pranata Kesehatan salah memasukkan username atau password.
Primary Actors Pengguna Main Flow /
Basic Path
1. Pengguna memilih menu ‘Login’.
2. Aplikasi menampilkan halaman login.
3. Pengguna memasukkan username dan password, kemudian menekan tombol ‘Login’.
4. Aplikasi memeriksa apakah username dan/atau password yang dimasukkan benar atau salah. Jika benar maka aplikasi akan menampilkan halaman backend (home page).
2. Deskripsi Use Case Mengelola Gejala:
Kegiatan atau interaksi antara Pranata Kesehatan dengan aplikasi dalam mengelola gejala dapat dilihat pada Tabel III.13.
Tabel III.13.
Deskripsi Use Case Mengelola Gejala Use Case Name Mengelola Gejala
Requirements A2
Goal Pengguna dapat mengelola data gejala.
Pre-conditions Pengguna telah melakukan login.
Post-conditions Aplikasi memproses pengelolaan data gejala.
Failed end conditions
Pengguna tidak lengkap memasukkan data gejala atau tidak sesuai tipe datanya.
Primary Actors Pengguna Main Flow /
Basic Path
1. Pengguna memilih menu ‘Gejala’.
2. Aplikasi menampilkan data gejala yang sudah ada.
3. Pengguna menekan tombol ‘Tambah’.
4. Aplikasi menampilkan formulir tambah gejala.
5. Pengguna mengisi data gejala, kemudian menekan tombol ‘Simpan’.
6. Aplikasi menyimpan data gejala ke dalam database.
Invariant A: A3. Pengguna menentukan data gejala yang akan diubah, kemudian menekan tombol ‘Ubah’.
A4. Aplikasi menampilkan formulir ubah gejala.
A5. Pengguna mengedit data gejala, kemudian menekan tombol ‘Simpan’.
A6. Aplikasi menyimpan perubahan data gejala ke dalam database.
Invariant B: B3. Pengguna menentukan gejala yang akan dihapus, kemudian menekan tombol ‘Hapus’.
B4. Aplikasi menampilkan konfirmasi penghapusan.
B5. Pengguna mengkonfirmasi penghapusan data.
B6. Aplikasi menghapus data gejala dari database.
3. Deskripsi Use Case Mengelola Penyakit
Kegiatan atau interaksi antara Pengguna dengan aplikasi dalam mengelola penyakit bergejala demam dapat dilihat pada Tabel III.14.
Tabel III.14.
Deskripsi Use Case Mengelola Penyakit Use Case Name Mengelola Penyakit
Requirements A3
Goal Pengguna dapat mengelola data penyakit.
Pre-conditions Pengguna telah melakukan login.
Post-conditions Aplikasi memproses pengelolaan data penyakit.
Failed end conditions Pengguna tidak lengkap memasukkan data penyakit atau tidak sesuai tipe datanya.
Primary Actors Pengguna Main Flow /
Basic Path
1. Pengguna memilih menu ‘Penyakit’.
2. Aplikasi menampilkan data penyakit yang tersedia.
3. Pengguna menekan tombol ‘Tambah’.
4. Aplikasi menampilkan formulir tambah penyakit.
5. Pengguna mengisi data penyakit, kemudian menekan tombol ‘Simpan’.
6. Aplikasi menyimpan data penyakit ke database.
Invariant A: A3. Pengguna menentukan data penyakit, kemudian menekan tombol ‘Ubah’.
A4. Aplikasi menampilkan formulir ubah penyakit.
A5. Pengguna mengedit data penyakit, kemudian menekan tombol ‘Simpan’.
A6. Aplikasi menyimpan perubahan data penyakit ke dalam database.
Invariant B: B3. Pengguna menentukan penyakit, kemudian menekan tombol ‘Hapus’.
B4. Aplikasi menampilkan konfirmasi penghapusan.
B5. Pengguna mengkonfirmasi penghapusan data.
B6. Aplikasi menghapus data penyakit dari database.
4. Deskripsi Use Case Mengelola Metode
Kegiatan atau interaksi antara Pengguna dengan aplikasi dalam mengelola metode dari penyakit bergejala demam yang dapat dilihat pada Tabel III.15.
Tabel III.15.
Deskripsi Use Case Mengelola Metode Use Case Name Mengelola Metode
Requirements A4
Goal Pengguna dapat mengelola data metode.
Pre-conditions Pengguna telah melakukan login.
Post-conditions Aplikasi memproses pengelolaan metode.
Failed end conditions Pengguna tidak lengkap memasukkan kombinasi inferensi atau tidak sesuai tipe datanya.
Primary Actors Pengguna Main Flow / Basic
Path
1. Pranata Kesehatan memilih menu ‘Metode’.
2. Aplikasi menampilkan data metode yang tersedia.
3. Pengguna menekan tombol ‘Tambah’.
4. Aplikasi menampilkan formulir tambah metode.
5. Pengguna mengisi data metode, kemudian menekan tombol ‘Simpan’.
6. Aplikasi menyimpan data metode ke database.
Invariant A: A3. Pengguna menentukan data metode yang akan diubah, kemudian menekan tombol ‘Edit’.
A4. Aplikasi menampilkan formulir ubah metode.
A5. Pengguna mengedit data metode, kemudian menekan tombol ‘Simpan’.
A6. Aplikasi menyimpan perubahan data metode ke dalam database.
Invariant B: B3. Pengguna menentukan metode, kemudian menekan tombol ‘Hapus’.
B4. Aplikasi menampilkan konfirmasi penghapusan.
B5. Penggguna mengkonfirmasi penghapusan data.
B6. Aplikasi menghapus data metode dari database.
5. Deskripsi Use Case Melakukan Diagnosa
Kegiatan atau interaksi antara Pengguna dengan aplikasi dalam mengakses menu Diganosa dapat dilihat pada Tabel III.16.
Tabel III.16.
Deskripsi Use Case Melakukan Diagnosa Use Case Name Melakukan Diagnosa
Requirements A5
Goal Pengguna dapat melihat hasil perhitungan nilai kepastian dari penyakit bergejala demam dengan metode Certainty Factor.
Pre-conditions Kombinasi basis pengetahuan pada Metode telah
ditentukan oleh pada halaman backend.
Post-conditions Aplikasi menampilkan hasil perhitungan diagnosa penyakit bergejala demam beserta rincian perhitungan metode Certainty Factor.
Failed end conditions Data penyakit dan gejala masih kosong.
Primary Actors Pengguna Main Flow / Basic
Path
1. Pengguna memilih menu ‘Diagnosa’.
2. Aplikasi menampilkan gejala-gelaja yang bisa dipilih sesuai dengan kondisi tubuh yang dirasakannya.
3. Pengguna menekan tombol ‘Hasil Diagnosa’.
4. Aplikasi menampilkan rincian/detail perhitungan metode Certainty Factor.
6. Deskripsi Use Case Mengakses RSMB
Kegiatan atau interaksi antara Pengguna dengan aplikasi dalam mengakses menu tentang RSMB dapat dilihat pada Tabel III.17
Tabel III.17.
Deskripsi Use Case Mengakses Menu RSMB Use Case Name Mengakses RSMB
Requirements A6
Goal Pengguna dapat melihat ketererangan RSMB atau deskripsi dari aplikasi mobile sistem pakar diagnosa penyakit bergejala demam menggunakan metode Certainty Factor. Serta dapat melakukan pemesanan online ke situs http://regonline.rsmb.co.id/
Pre-conditions Pengguna menjalankan aplikasi.
Post-conditions Aplikasi menampilkan deskripsi mengenai aplikasi diagnosa penyakit bergejala demam menggunakan metode Certainty Factor pada aplikasi fever check.
Failed end conditions -
Primary Actors Pengguna Main Flow / Basic
Path
1. Pengguna memilih menu ‘RSMB’.
2. Aplikasi menampilkan keterangan aplikasi dan informasi pada aplikasi fever check.
3. Pengguna mengakses pemesanan online di http://regonline.rsmb.co.id/
4. Aplikasi me-redirect ke situs RS Muhammadiyah Bandung.
B.Activity Diagram
Penggambaran activity diagram menggunakan partisi berdasarkan actor yang melakukan interaksi dengan aplikasi.
1. Activity Diagram Melakukan Login
Pada aplikasi diagnosa penyakit bergejala demam hanya pengguna yang dapat melakukan login yang dapat dilihat pada Gambar III.5.
Gambar III.5. Activity Diagram Melakukan Login
Pada Gambar III.5 dapat dilihat ketika Pengguna memilih menu login maka aplikasi akan menampilkan halaman login. Pengguna memasukkan username dan password yang divalidasi oleh sistem. Apabila username atau password salah
maka pengguna harus mengulangi kembali untuk memasukkan data login yang benar.
2. Activity Diagram Mengelola Penyakit
Pengelolaan penyakit bergejala demam yang dapat ditambah, diubah, maupun dihapus oleh pengguna yang dapat dilihat pada Gambar III.6.
Gambar III.6. Activity Diagram Mengelola Penyakit
Pada Gambar III.6 dapat dijelaskan mengenai menu penyakit yang dipilih oleh Pengguna akan menampilkan halaman dari data penyakit begejala demam.
Kemudian Pengguna dapat mengelola data penyakit bergejala demam untuk diperbaharui melalui aplikasi ke dalam database.
3. Activity Diagram Mengelola Gejala
Beberapa gejala yang telah ditentukan oleh pakar dapat ditambah, diubah, maupun dihapus oleh Pengguna yang dapat dilihat pada Gambar III.7.
Gambar III.7. Activity Diagram Mengelola Gejala
Pada Gambar III.7 dapat dijelaskan mengenai menu gejala yang dipilih oleh Pengguna yang akan menampilkan halaman gejala pada aplikasi. Kemudian
Pengguna dapat mengelola data gejala seperti id dan nama gejala untuk diperbaharui melalui aplikasi ke dalam database.
4. Activity Diagram Mengelola Metode
Menu Metode yang berisi kombinasi basis pengetahuan yang telah ditentukan oleh pakar dengan activity diagram yang dapat dilihat pada Gambar III.8.
Gambar III.8. Activity Diagram Mengelola Metode
Pada Gambar III.8 merupakan alur menu untuk pengelolaan metode yang dipilih oleh Pengguna pada aplikasi. Kemudian Pengguna dapat mengelola kombinasi basis pengetahuan yang telah ditentukan oleh pakar untuk diperbaharui melalui aplikasi ke dalam database.
5. Activity Diagram Melakukan Diagnosa
Pada menu Diagnosa berisi hasil dari perhitungan metode Certainty Factor yang mengurutkan fase penyakit Filariasis berdasarkan nilai terbesar. Alur dari proses melakukan check-up yang dapat dilihat pada Gambar III.9.
Gambar III.9. Activity Diagram Melakukan Diagnosa
Pada Gambar III.9 dapat dijelaskan bahwa menu Diagnosa dapat diakses oleh Pengguna dalam melakukan pemeriksaan klinis dari penyakit bergejala demam. Ketika menu Diagnosa dipilih atau diakses oleh Pengguna kemudian menekan tombol “Hasil Diagnosa”, maka aplikasi akan menampilkan penyakit bergejala demam dengan nilai terbesar.
6. Activity Diagram Mengakses RSMB
Menu RSMB berisi keterangan mengenai instansi, dan link aktif yang terhubung ke situs RS Muhammadiyah Bandung untuk melakukan pendaftaran online. Activity diagram pada kegiatan mengakses menu RSMB dapat dilihat pada Gambar III.10.
Gambar III.10. Activity Diagram Mengakses RSMB
Pada Gambar III.10 merupakan alur yang dapat dilakukan oleh Pengguna untuk mengakses menu informasi RSMB. Pengguna dapat memilih menu RSMB yang kemudian aplikasi menampilkan halaman informasi.
C. Class Diagram
Gambar III.11. Class Diagram Aplikasi
Pada Gambar III.11 merupakan class diagram aplikasi diagnosa penyakit bergejala demam yang terdiri dari kelas penyakit, gejala, metode, dan pengguna.
Masing-masing kelas mempunyai atribut dan operasinya masing-masing untuk pengolahan datanya.
D. Sequence Diagram
Penggambaran sequence diagram aplikasi diagnosa penyakit bergejala demam digambarkan sebagai berikut:
1. Sequence Diagram Melakukan Kelola
Skenario dari proses login yang dilakukan oleh pengguna dapat dilihat urutannya dengan sequence diagram yang dapat dilihat pada Gambar III.12.
Gambar III.12. Sequence Diagram Melakukan Login
Pada Gambar III.12 menunjukkan interaksi fever check Kesehatan melakukan login dengan memasukkan username dan password. Kemudian controller login memvalidasi data tersebut. Jika username atau password benar maka akan dialihkan ke halaman backend. Namun jika salah maka akan menolak akses.
2. Sequence Diagram Mengelola Penyakit
Skenario mengelola penyakit bergejala demam dapat dilihat urutannya menggunakan sequence diagram yang dapat dilihat pada Gambar III.13.
Gambar III.13. Sequence Diagram Mengelola Penyakit
Pada Gambar III.13 menunjukkan skenario dari sequence diagram dalam mengelola penyakit bergejala demam oleh Pengguna yang dapat menambah, mengubah, dan menghapus data penyakit untuk disimpan ke dalam database.
3. Sequence Diagram Mengelola Gejala
Skenario mengelola data gejala dapat dilihat urutannya menggunakan sequence diagram yang dapat dilihat pada Gambar III.14.
Gambar III.14. Sequence Diagram Mengelola Gejala
Pada Gambar III.14 dapat dijelaskan bahwa Pranata Kesehatan dapat menambah, mengubah, dan menghapus data gejala yang meliputi id dan nama gejala untuk disimpan melalui aplikasi ke dalam database.
4. Sequence Diagram Mengelola metode
Skenario menambah metode dengan urutannya menggunakan sequence diagram yang dapat dilihat pada Gambar III.15.
Gambar III.15. Sequence Diagram Mengelola Metode
5. Sequence Diagram Melakukan Diagnosa
Skenario mengakses meni diagnose oleh Pengguna dengan urutannya menggunakan sequence diagram yang dapat dilihat pada Gambar III.16.
Gambar III.16. Sequence Diagram Melakukan Diagnosa
6. Sequence Diagram Mengakses RSMB
Skenario mengakses menu klinik oleh Pengguna dengan urutannya menggunakan sequence diagram yang dapat dilihat pada Gambar III.17.
Gambar III.17. Sequence Diagram Mengakses RSMB
3.3.3. User Interface
User interface merupakan gambar antarmuka pengguna dari perancangan sistem yang dibuat. Perancangan antarmuka berfungsi untuk memudahkan interaksi antara pengguna dengan sistem.
1. Halaman Menu Utama
Tampilan halaman depan merupakan halaman utama dari aplikasi yang dapat dilihat pada Gambar III.18.
Gambar III.18. Tampilan Halaman Depan
2. Halaman Login
Untuk dapat melakukan pengelolaan data diperlukan otentikasi login pengguna agar tidak terjadi penyalahgunaan penilaian oleh pihak yang tidak mempunyai hak akses. Tampilan dari halaman login pengguna oleh pengguna dapat dilihat pada Gambar III.19.
Gambar III.19. Tampilan Halaman Login
3. Halaman Kelola
Halaman kelola terkadang disebut juga sebagai halaman administrator yang hanya dapat diakses oleh Pengguna setelah login yang dapat dilihat pada Gambar III.20.
Gambar III.20. Tampilan Halaman kelola
4. Halaman Penyakit
Pada halaman ini ditampilkan data penyakit yang tersedia agar dapat digunakan untuk pengolahan data penyakit bergejala demam dengan tampilan antarmuka pengguna pada Gambar III.21.
Gambar III.21. Tampilan Halaman Penyakit
5. Halaman Gejala
Pada halaman gejala terdapat beberapa data gejala yang sudah ditentukan oleh pakar, namun data-data tersebut dapat diperbaharui ketika terjadi perubahan
ilmu pengetahuan. Tampilan dari halaman gejala ditunjukkan pada Gambar III.22.
Gambar III.22. Tampilan Halaman Gejala
6. Halaman Metode
Halaman metode berisi penilaian yang diberikan oleh pengguna terhadap beberapa penyakit bergejala demam yang sudah dimasukkan sebelumnya.
Tampilan dari halaman metode dapat dilihat pada Gambar III.23.
Gambar III.23. Tampilan Halaman metode
7. Halaman Diagnosa
Hasil akhir dari proses perhitungan metode Certainty Factor yaitu menghasilkan kepastian dari penyakit bergejala demam dengan tampilan pada Gambar III.24
Gambar III.24. Tampilan Halaman diagnosa 8. Halaman RSMB
Pada halaman informasi berisi deskripsi dari aplikasi diagnosa penyakit bergejala demam beserta keterangan menganai tempat riset dengan tampilan pada Gambar III.25.
Gambar III.25. Tampilan Halaman RSMB
3.4. Testing
Proses pemeriksaaan atau evaluasi komponen aplikasi untuk memverifikasi kebutuhan pengguna atau mengidentifikasi perbedaan-perbedaan antara hasil yang diharapkan dengan hasil yang terjadi. Aplikasi yang dikembangkan pada penelitian ini akan diujikan menggunakan whitebox testing.
Flowchart dari aplikasi penyakit Filariasis untuk analisa awal dari whitebox testing dapat dilihat pada Gambar III.26.
Gambar III.26. Flow Chart Aplikasi Diagnosa Penyakit Bergejala Demam
Sedangkan kompleksitas siklomatis/cyclomatic complexity atau matrik perangkat lunak yang memberikan pengukuran kuantitatif terhadap kompleksitas logis untuk aplikasi diagnosa penyakit bergejala demam dapat digambarkan pada grafik alir/flow graph pada Gambar III.27.
Gambar III.27. Grafik Alir Aplikasi Diagnosa Penyakit Bergejala Demam
Kompleksitas siklomatis dari grafik alir untuk white box testing dapat diperoleh dengan perhitungan berikut ini:
V(G) = E-N + 2
Dimana:
E = Jumlah Edge yang ditentukan gambar panah.
N = Jumlah simpul grafik alir ditentukan dengan gambar lingkaran.
V(G) = 24 - 16 + 2 = 10
V(G) < 10 berarti memenuhi syarat kekomplesitasi siklomatisnya. Baris set yang dihasilkan dari jalur independent aplikasi diagnosa penyakit bergejala demam yaitu:
1. 1-2-3-4-5-6-7 2. 1-2-3-8-7 3. 1-2-3-8-11-7 4. 1-2-3-4-9-7
5. 1-2-3-4-5-10-12-13-14-7 6. 1-2-3-4-5-10-12-15-7 7. 1-2-3-4-5-10-12-13-16-7 8. 1-2-3-4-5-10-12-13-14-7
9. Ketika aplikasi dijalankan, maka terlihat bahwa satu set baris yang dihasilkan adalah 1-2-3-4-5-6-7-1-2-3-8-7-1-2-3-8-11-7-1-2-3-4-9-7-1-2-3-4-5-10-12-13- 14-7-1-2-3-4-5-10-12-15-7-1-2-3-4-5-10-12-13-16-7-1-2-3-4-5-10-12-13-14-7 dan terlihat bahwa simpul telah dieksekusi satu kali.
3.5. Implementasi
Tahap implementasi sistem adalah tahap penerapan sistem yang telah didesain atau dirancang, sehingga sistem yang telah dibuat dapat dioperasikan dan digunakan secara optimal sesuai dengan kebutuhan.
1. Class Pengguna
package com.cf_android;
import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.Toast;
public class LoginActivity extends AppCompatActivity { EditText edloginusername;
EditText edloginpassword;
Button btnlogin;
protected Cursor cursor;
SQLHelper dbHelper;
} }
2. Class Penyakit
package com.cf_android;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.Window;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.ListView;
public class PenyakitActivity extends AppCompatActivity { String[] array_id_penyakit;
String[] array_nama_penyakit;
String[] array_solusi_penyakit;
String[] array_solusi_penyakit2;
String[] array_solusi_penyakit3;
String[] array_solusi_penyakit4;
String[] array_solusi_penyakit5;
String[] array_penyakit;
ListView listpenyakit;
protected Cursor cursor;
SQLHelper dbHelper;
public static PenyakitActivity obj;
Button btnpenyakitadd;
3. Class Gejala
package com.cf_android;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.view.Window;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.ListView;
public class GejalaActivity extends AppCompatActivity { String[] array_id_gejala;
String[] array_nama_gejala;
String[] array_gejala;
ListView listgejala;
protected Cursor cursor;
SQLHelper dbHelper;
public static GejalaActivity obj;
Button btngejalaadd;
4. Class Metode
package com.cf_android;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.Intent;
import android.database.Cursor;
import android.database.sqlite.SQLiteDatabase;
import android.os.Bundle;
import android.support.v7.app.AppCompatActivity;
import android.view.Menu;
import android.view.MenuItem;
import android.view.View;
import android.widget.AdapterView;
import android.widget.ArrayAdapter;
import android.widget.Button;
import android.widget.ListView;
public class PengetahuanActivity extends AppCompatActivity { String[] array_id_pengetahuan;
String[] array_id_penyakit;
String[] array_id_gejala;
String[] array_mb;
String[] array_md;
String[] array_pengetahuan;
ListView listpengetahuan;
protected Cursor cursor;
SQLHelper dbHelper;
public static PengetahuanActivity obj;
Button btnpengetahuanadd;
}
public void RefreshList() {
SQLiteDatabase db = dbHelper.getReadableDatabase();
//cursor = db.rawQuery("SELECT alternatif_kriteria.id_alternatif_kriteria, alternatif_kriteria.id_alternatif,
alternatif_kriteria.id_kriteriaalternatif_kriteria.nilai, alternatif.nama_alternatif, kriteria.nama_kriteria FROM
alternatif_kriteria LEFT JOIN alternatif ON alternatif.id_alternatif
= alternatif_kriteria.id_alternatif LEFT JOIN kriteria.id_kriteria = alternatif_kriteria.id_kriteria",null);
//cursor = db.rawQuery("SELECT pengetahuan.*,
penyakit.nama_penyakit, gejala.nama_gejala FROM pengetahuan LEFT JOIN penyakit ON penyakit.id_penyakit = pengetahuan.id_penyakit LEFT JOIN gejala ON gejala.id_gejala = pengetahuan.id_gejala",null);
//cursor = db.rawQuery("SELECT pengetahuan.*,
penyakit.nama_penyakit, gejala.nama_gejala FROM (pengetahuan LEFT JOIN penyakit ON penyakit.id_penyakit = pengetahuan.id_penyakit) LEFT JOIN gejala ON gejala.id_gejala = pengetahuan.id_gejala",null);
cursor = db.rawQuery("SELECT pengetahuan.*,
gejala.nama_gejala, penyakit.nama_penyakit FROM pengetahuan LEFT JOIN gejala ON gejala.id_gejala = pengetahuan.id_gejala LEFT JOIN penyakit ON penyakit.id_penyakit = pengetahuan.id_penyakit",null);
//cursor = db.rawQuery("SELECT * FROM alternatif_kriteria ak LEFT JOIN kriteria k ON k.id_kriteria = ak.id_kriteria LEFT JOIN
alternatif a ON a.id_alternatif = ak.id_alternatif",null);
array_id_pengetahuan = new String[cursor.getCount()];
array_id_penyakit = new String[cursor.getCount()];
array_id_gejala = new String[cursor.getCount()];
array_mb = new String[cursor.getCount()];
array_md = new String[cursor.getCount()];
array_pengetahuan = new String[cursor.getCount()];
cursor.moveToFirst();
for (int cc=0; cc < cursor.getCount(); cc++) {
cursor.moveToPosition(cc);
array_id_pengetahuan[cc] = cursor.getString(0).toString();
array_id_penyakit[cc] = cursor.getString(1).toString();
array_id_gejala[cc] = cursor.getString(2).toString();
array_mb[cc] = cursor.getString(3).toString();
array_md[cc] = cursor.getString(4).toString();
array_pengetahuan[cc] = cursor.getString(0).toString() +
". " + cursor.getString(6).toString() + " / " + cursor.getString(5).toString()
+ "\nMB = " + cursor.getString(3).toString() + "
, MD = " + cursor.getString(4).toString();
}
3.6. Support
Perangkat yang digunakan untuk pemasangan aplikasi yang telah berhasil diujikan, serta menjelaskan kebutuhan hardware dan software standar yang akan digunakan untuk dapat menjalankan sistem usulan.
Tabel III.18.
Spesifikasi Smartphone
No. Kebutuhan Smartphone Keterangan
1 Operating System Android OS, v5.1.1 (Lollipop)
2 CPU Exynos 3475 Quad-Core 1.3 GHz
3 RAM 1 GB
4 Storage 8 GB
5 Konektivitas HSPA 42.2/5.76 Mbps, LTE Cat4
6 Layar 4.7 inches, 540x960 pixels.
