PARADIGMA VOL. XV. September 2013
APLIKASI SISTEM PAKAR DIAGNOSIS PENYAKIT HEPATITIS PADA RSUD TANGERANG SELATAN Chalid Kabiran Akademi Manajemen Informatika dan Komputer Bina Sarana Informatika Tangerang Bumi Serpong Damai Sektor XIV Blok C1/1, Jl. Letnan Sutopo BSD Serpong, Tangerang Selatan ABSTRAKSI Saat ini, masih banyak perusahaan yang belum memiliki sistem yang dapat digunakan untuk membantu proses kualifikasi dalam pemilihan perekrutan karyawan untuk penugasan, sehingga proses kualifikasi harus dilakukan secara manual dan membutuhkan waktu yang cukup lama. Keadaan tersebut sangat tidak efektif, sehingga dibutuhkan sebuah sistem yang mampu mengatasi permasalahan tersebut. Untuk mencapai tujuan tersebut metode penelitian yang digunakan meliputi desain penelitian menggunakan metode deskriptif, metode pengumpulan data yang digunakan wawancara dan observasi, metode pendekatan yang digunakan adalah metode pendekatan terstruktur, metode pengembangan sistemnya adalah model waterfall, alat bantu analisis dan perancangan meliputi flowmap, diagram kontek, kamus data dan perancangan database. Adapun perangkat lunak pendukung dalam pembuatan sistem informasi penerimaan pegawai ini adalah PHP sebagai interface dan MySQL sebagai databasenya.Sistem ini akan melakukan kualifikasi terhadap pelamar (recruitment) berdasarkan kriteria-kriteria yang telah ditentukan, kemudian kriteria-kriteria tersebut akan diproses dengan data-data lowongan yang tersimpan di dalam database. Output dari proses tersebut adalah beberapa solusi alternatif pelamar yang akan diterima ataupun direkomendasikan pada system recruitment memberikan nilai rekomendasi yang digunakan sebagai urutan prioritas pilihan. Kata kunci : recruitment, kualifikasi, database
1.1.
Latar Belakang Masalah Suatu gejala penyakit dapat merupakan awal dari sebuah penyakit yang akan membahayakan pasien, tetapi pada kenyataannya gejala penyakit tersebut terkadang dianggap remeh oleh pasien, kurangnya waktu dan kesibukan dari seorang dokter bisa menjadi permasalahan untuk cepat menangani gejala penyakit yang di derita oleh pasien. Dengan adanya kemajuan ilmu pengetahuan dan teknologi komunikasi, bahaya yang ditimbulkan oleh suatu penyakit dapat didekteksi gejalanya melalui sistem pakar. Hal ini yang mendasari dibutuhkannya suatu aplikasi mengenai sistem diagnosis penyakit. Sehingga dapat meningkatkan kinerja pelayanan kesehatan. Serta dapat mengurangi timbulnya bahaya yang disebabkan oleh gejala penyakit karena dapat didekteksi dengan cepat terutama
untuk diagnosis penyakit hepatitis yang banyak diderita oleh masyarakat Indonesia. Hepatitis adalah penyakit yang disebabkan oleh beberapa jenis virus yang menyerang dan menyebabkan peradangan serta merusak sel-sel organ hati manusia. Peradangan pada sel hati dapat menyebabkan kerusakan sel-sel, jaringan, bahkan semua bagian dari organ hati (liver). Jika semua bagian organ hati (liver) telah mengalami kerusakan maka akan terjadi gagal hati (liver) yang menyebabkan kematian. Menurut data dari Organisasi Kesehatan Dunia (WHO) tahun 2000, angka kejadian infeksi virus Hepatitis di Indonesia mencapai 7 juta orang, dunia 2.000.000.000 penduduk telah terinfeksi. Diperkirakan 1.000.000 pengidap hepatitis meninggal akibat infeksi kronis aktif, sirosis atau kanker hati.Di dalam jurnal Sulistiowaty (2011)
81
PARADIGMA VOL. XV. September 2013 yang berjudul “implementasi sistem pakar berbasis web untuk mendiagnosa penyakit dalam pada manusia”, menyatakan bahwa perkembangan penyakit dalam semakin berkembang setiapa tahunnya. Baik dari perkembangan jenis penyakit maupun penderita, kurangnya waktu dan tenaga dari seorang dokter spesialis dalam menjadi permasalahan untuk menangani penyakit tersebut untuk itu dibutuhkan sistem pakar untuk mendiagnosis penyakit dalam serta menentukan solusi dari penyakit tersebut. Sistem pakar ini menggunakan metode forward chaining dan backward chaining serta didukung dengan menggunakan kaidah produksi. Untuk itu dibutuhkan informasi berupa sistem pakar agar gejala-gejala penyakit hepatitis dari pasien dapat didiagnosa berdasarkan pengetahuan yang didapat dari seorang pakar. Maka diharapkan aplikasi diagnosis ini dapat membantu dan mempermudah pihak-pihak terkait khususnya dokter dalam diagnosis penyakit pasien. Berdasarkan hasil analisis yang dilakukan ada beberapa permasalahan yang dapat dikemukan pada sistem yang berjalan, permasalahan tersebut diantaranya adalah sebagai berikut: 1. Perancangan konsep sistem pakar sangat sederhana dengan didukung proses yang disajikan secara lengkap dan akurat dalam bentuk tampilan visual serta intruksi-intruksinya untuk mengatasi diagnosis penyakit hepatitis. 2. Konsultasi dalam sistem pakar ini nantinya user interface karena sesuai dengan gejala diagnosis penyakit hepatitis. II. TINJAUAN PUSTAKA 3.1. Teori Pendukung Menurut Istri Sustiowati (2011) didalam jurnalnya yang berjudul “implementasi sistem pakar berbasis web untuk mendiagnosis penyakit dalam pada manusia”, Menyatakan bahwa Penyakit dalam pada manusia semakin berkembang setiap tahunnya akan tetapi terbatasnya
82
jumlah, waktu dan tenaga dari seorang dokter sehingga untuk melakukan konsultasi ketika dokter berhalangan hadir akan menyulitkan pasien sehingga di butuhkannya sistem pakar untuk mendiagnosis penyakit dalam. Sistem pakar yang di buat menggunakan aplikasi website dimana sistem ini bertujuan untuk memudahkan dan membantu user dalam melakukan diagnosis penyakit dalam serta menentukan solusi dari penyakit tersebut. Sistem pakar ini menggunakan metode penelusuran dalam mesin inferensi yaitu pelacak maju (forward chaining) dan pelacak mundur (backward chaining), sedangkan untuk metode representasi menggunakan kaidah produksi untuk mempresentasikan pengetahuan tentang jenis-jenis penyakit dalam beserta gejala dan pengobatannya. Menurut Arji Pujiyanta, dkk (617:2012) didalam jurnalnya yang berjudul “ Sistem Pakar Penentuan Jenis Penyakit Hati Dengan Metode Inferensi Fuzzy Tsukomoto”, menyatakan bahwa penyakit hati akut akan mempengaruhi fungsi hati sehingga seorang pakar penyakit dalam terkadang mengalami kesulitan dalam menentukan jenis penyakit yang diderita oleh pasien karena adanya beberapa gejala-gejala yang mirip pada beberapa penyakit. Maka dari itu penelitian ini dilakukan bertujuan untuk membangun sebuah sistem pakar yang dapat digunakan untuk menentukan jenis penyakit hati. Pada penelitian ini penelusuran faktanya menggunakan forward chaining dan logika yang digunakan adalah sistem inferensi fuzzy metode tsukamoto. Tahapan pengembangan aplikasi diawali dengan analisa data, perancangan sistem, pengkodean (coding) dengan menggunakan Visual Basic 6.0 dan testing (pengujian sistem dengan black boxtest dan alfa test) dari hasil penelitian yang dilakukan menghasilkan sebuah perangkat lunak tentang “Sistem pakar penentuan jenis penyakit hati dengan metode inferensi fuzzy tsukamoto”. Berdasarkan pengujian yang telah dilakukan terhadap responden menghasilkan secara keseluruhan sistem layak untuk digunakan. 3.2. Konsep Dasar Model Pengembangan Sistem 1. Teori Model Water Fall Menurut M. Salahuddin (2011: 26), Model Water Fall adalah model SDLC yang paling
PARADIGMA VOL. XV. September 2013
sederhana. Model ini hanya cocok untuk pengembangan perangkat dengan spesifikasi yang tidak berubah-ubah.
Terdapat dua pendekatan dalam menyusun mekanisme inferensi berbasis aturan, yaitu forward chaining dan backward chaining. a. Forward Chaining
a. Analisis Kebutuhan Perangkat Lunak Proses pengumpulan kebutuhan dilakukan secara intensif untuk mespesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu untuk didokumentasikan. b. Desain Desain perangkat linak adalah proses multilangkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antar muka, dan prosedur pengodean. Tahap ini mentranslasi kebutuhan perangkat lunak dari tahap analisis kebutuhan ke representasi desain agar dapat diimplementasikan menjadi program pada tahap selanjutnya. Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan. c. Pembuatan Kode Program Desain harus ditranslasikan kedalam program perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain. d. Pengujian Pengujian fokus pada perangkat lunak secara dari segi lojik dan fungsional dan memastikan bahwa semua bagian sudah di uji. Hal ini dilakukan untuk meminimalisir kesalahan (error) dan memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan. e. Pendukung Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirim ke user. Perubahan bias terjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptasi dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru. 2. Teori Metode Interface
Yaitu sebuah metode pelacakan kedepan, dimana diawali dari fakta-fakta yang diberikan user kemudian dicari dibasis pengetahuan lalu dicari rule yang sesuai dengan fakta-fakta. Setelah itu diadakan hipotesa untuk memperoleh kesimpulan. Metode inferensi ini yang akan digunakan dalam sistem pakar yang akan dibangun dengan contoh penalaran sebagai berikut: IF Badan Demam AND Mata kuning AND Sendi-sendi kaku AND Air seni berwarna gelap THEN Hepatitis A Pencocokan fakta atau pernyataan dimulai dari bagian sebelah kiri. Dengan kata lain, penalaran dimulai dari fakta terlebih dahulu, lalu dicari rule yang sesuai dengan fakta-fakta yang diberikan untuk menguji kebenaran hipotesa. b. Backward Chaining Adalah suatu teknik pelacakan yang dimulai dari sekumpulan kesimpulan, lalu hipotesa yang diinginkan, kemudian dengan mempergunakan kaidah- kaidah yang ada akan dicari sejumlah besar kondisi awal fakta-fakta yang mendukung kaidah-kaidah tersebut. Pencocokan fakta atau pernyataan dimulai dari bagian sebelah kanan. Dengan kata lain, penalaran dimulai dari kesimpulan, lalu hipotesa terlebih dahulu, dan untuk menguji kebenaran hipotesa tersebut harus dicari rule yang sesuai, lalu fakta yang ada dalam basis pengetahuan. Contoh penalaran Backward Chaining: Lampu 1 rusak, IF Lampu 1 dinyalakan AND Lampu 1 tidak nyala AND Lampu 1 dinyalakan dengan sekering AND Sekering masih utuh 3.3. Konsep Dasar Pemrograman Istilah Pemrograman Terstruktur (Structured Programming) mengacu dari suatu kumpulan tehnik untuk meningkatkan produktifitas programmer, dengan mengurangi waktu yang dibutuhkan dalam penulisan (write), pengujian (test), penelusuran kesalahan (debug) dan pemeliharan (maintenance) suatu program. Pada pembahasan berikut ini kita akan melihat bagaimana tehnik ini yang
83
PARADIGMA VOL. XV. September 2013 pendekatan yang dilakukan secara modular, dapat membantu kita dalam membangun suatu program. Menurut Rosa A.S dan M. Salahuddin (2011:62) Pemerograman terstruktur adalah konsep atau paradigm atau sudut pandang pemograman yang membagi-bagi program berdasarkan fungsifungsi atau prosedur-prosedur yang dibutuhka program komputer. Modulmodul (pembagian program) biasanya dibuat dengan mengelompokan fungsifungsi dari prosedur-prosedur yang diperlukan sebuah proses tertentu. Fungsifungsi dan prosedur-prosedur ditulis secara sekunsial atau terurut dari atas kebawah sesuai dengan kebergantungan antarfungsi atau prosedur (fungsi atau prosedur yang dapat dipakai oleh fungsi atau prosedur dibawahnya harus yang sudah ditulis atau dideklarasikan di atasnya) Pemodulan pada pemograman terstruktur dibagi berdasarkan fungsi – fungsi dan prosedur- prosedur. Oleh karena itu pemodelan pada pemogramaan terstruktur lebih fokus bagai mana memodelkan data dan fungsi-fungsi atau prosedur-prosedur yang harus dibuat. Jenis paradigma pemograman yang digunakan dapat dideteksi dari bahasa pemograman apa yang akan digunakan untuk membuat program, baru setelah itu digunakan paradigm apa yang akan digunakan. Berikut akan diuraikan beberapa teknik pemograman terstruktur. 1. Pemrograman modular Dalam pemerograman modular, program dipecah menjadi modul-modul. Setiap modul menunjukan fungsi dan tugas tunggal. Modul-modul tersebut ditulis dan dicari kesalahannya secara terpisah, karena tujuan dan ukkuran setiap modul dibatasi, maka terjadinya kesalahan dalam program tersebut dapat dikurangi (Tata Sutabri, 2004:6). 2. Pemrograman Top-Down Pendekatan top-down ini sangat berguna dalam perencanaan pemerograman modular. Dalam pemerograman top-down (atas-bawah), yang pertama harus definisikan adalah modul utama. Modul utama yang di maksud adalah modul yang pertama kali dijalankan atau modul yang memanggil modul lainnya atau juga modul
84
yang mengakhiri proses program tersebut (Tata Sutabri, 2004:7). 3.4. Peralatan Pendukung Sistem 3.4.1 UML (unifield modeling language) Menurut Bambang Hariyanto (2004:259) UML adalah bahasa grafis untuk mendokumentasi, menspesifikasikan dan membangun sistem perangkat lunak. UML berorientasi Objek, menerapkan banyak level abstraksi, tidak bergantung proses pengembangan, tidak bergantung bahasa dan teknologi, pemaduan beberap anotasi di beragam metodologi, usaha bersama dari banyak pihak, didukung oleh kakas-kakas yang diintegrasikan lewat XML. 1. Use Case Menurut M. Salahuddin (2011:130) memberikan batasan bahwa “ diagram use case merupakan pemodelan untuk kelakukan (behavior) sistem informasi yang akan dibuat”. Use case mendeskripsikan sebuah interaksi antara satu atau lebih actor dengan sistem informasi yang akan dibuat. Secara kasar, use case digunakan untuk mengetahui fungsi apa saja yang ada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi itu. Syarat penanaman pada use case adalah nama didefinisikan sesimpel mungkin dan dapat dipahami. Ada dua hal utama pada use case yaitu pendefinisian apa yang disebut actor dan use case. Actor merupakan orang,proses, atau sistem lain yang berinteraksi akan dibuat itu sendiri, jadi walaupun symbol dari actor adalah gambar orang, tapi actor blum tentu merupakan orang, sedangkan use case merupakan fungsionalitas yang disediakan sistem sebagai unit-unit yang saling bertukar pesan antarunit atau actor. Berikut adalah simbol-simbol yang ada pada diagram use case: 2. Activity Diagram Menurut M. Salahuddin, (2011:134) memberikan batasan bahwa “Diagram aktifitas atau activity diagram menggambarkan workflow (aliran kerja) atau aktifitas dari sebuah sistem atau proses bisnis”. Perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang
PARADIGMA VOL. XV. September 2013
dilakukan actor, jadi aktivitas yang dapat dilakukan oleh sistem. Diagram aktivitas juga banyak digunakan untuk mendifinisikan hal-hal berikut: a. Rancangan proses bisnis dimana setiap urutan aktivitas yang digambarkan merupakan proses bisnis sistem yang didefinisikan. b. Urutan atau pengelompokan tampilan dari sistem /user interrface dimana setiap. aktivitas dianggap memiliki sebuah rancangan antarmuka tampilan. c. Rancangan pengujian di mana setiap aktivitas dianggap memerlukan sebuah pengujian yang perlu didefinisikan kasus ujiya. 3. Component Diagram Menurut M.Salahuddin (2011:124) memberikan batasan bahwa “component diagram dibuat untuk menunjukan organisasi dan ketergantungan diantara kumpulan komponen dalam sebuah sistem. Diagram komponen fokus pada komponen sistem yang dibutuhkan dan ada didalam sistem”. Diagram komponen juga dapat digunakan untuk memodelkan hal-hal berikut : a. Source code program perangkat lunak b. Komponen executable yang dilepas ke user c. Basis data secara fisik d. Sistem yang harus beradaptasi dengan sistem lain e. Framework sistem, framework pada perangkat lunak merupakan kerangka kerja yang dibuat untuk memudahkan pengembangan dan pemelihatraan aplikasi, contohnya seperti strust dari apache yang menggunakan prinsip desain modelview-controller (MVC) dimana source code program dikelompokan berdasarkan fungsinya
Gambar II.5. Contoh Component Diagram Dimana controller berisi source code yang menangani request dan validasi, model yang berisi source code yang menangani manipulasi data dan business logic, dan view berisi source code yang menangani tampilan.
Komponen dasar yang biasanya ada dalam suatu sistem adalah sebagai berikut : 1. Component user interface yang menangani tampilan 2. Komponen business processing yang menangani fungsi- fungsi proses bisnis 3. Komponen data yang menangani manipulasi data 4. Komponen security yang menangani keamanan sistem Komponen lebih terfokus pada penggolongan secara umum fungsi-fungsi yang di di perlukan. Berikut aadalah simbol-simbol yang ada pada diagram komponen. 4. Diagram Deployment M. Salahuddin (2011:128) member batasan bahwa “Diagram deployment menunjukan konfigurasi komponen dalam proses eksekusi aplikasi. Diagram deployment juga dapat digunakan untuk memodelkan sistem tambahan (embedded system) yang menggambarkan rancangan device, node dan hardware, dan sistem client/server
Sumber : Rossa A.S dan M.Shalahuddin (2011:129) Gambar II.6. Contoh Deployment Diagram 4. ERD (Entity Relationship Diagram) ERD (Entity relationship Diagram) adalah bentuk paling awal dalam melakukan perancangan basis data relasional. Jika menggunakan OODBMS maka perancangan ERD tidak perlu dilakukan. (M. Shalahuddin, 2011:50). Suatu objek disebut entity dan hubungan dimilikinya disebut relationship. Mentalist suatu entity bersifat unik dan memeiliki atribut sebagai pembeda antara entity lainnya. Contoh : entity mahasiswa, mempunyai atribut nama, umur, alamat, dan nim. Diagram E-R terdiri dari kotak persegi panjang menggambarkan hubungan entitas, elips menggambarkan atribut entitas, diamond menggambarkan hubungan antara entitas dan garis yang menghubungkan antar entitas dalam E-R.
85
PARADIGMA VOL. XV. September 2013 Model E-R terdiri dari beberapa komponen dasar yaitu sebagai berikut: 1. Entitas (Entity) dan Himpunan Entitas (Entitas Sets) Entitas merupakan individu yang mewakili sesuatu yang nyata (eksistensinya) dan dapat dibedakan dari sesuatu yang lain. Sebuah kursi yang kita duduki, seseorang yang menjadi pegawai disebuah perusahaan dan sebuah mobil yang melintas di depan kita adalah entitas. Sekelompok entitas yang sejenis dan berada dalam lingkup yang sama membentuk sebuah himpunan entitas (Entity Sets). Sederhananya, entitas menunjukan pada individu suatu objek, sedangkan himpunan entitas mennjuk pada rumpun (family) dari individu tersebut. Seseorang memang dapat menjadi sebuah entitas, tapi dapat berada pada himpunan entitas yang berbeda dengan seseorang yang lain. Seorang pasien, misalnya, akan dimasukan dalam himpunan entitas pasien, sedangkan seorang dokter akan ditempatkan dalam himpunan entitas dokter. Dalam berbagai pembahasan atau literatur, penyebutan himpunan entitas (yang kurang praktis) ini sering kali diganti dengan sebutan entitas saja. Karena itu sering kita temui, penggunaan istilah entitas (Entity) disebuah literature sebenarnya menunjuk pada himpunan entitas. 2. Atribut (Attributes/Properties) Setiap entitas pasti memiliki atribut yang mendeskripsikan karakteristik (properti) dari entitas tersebut. Sebagaimana telah disebutkan sebelumnya, penentuan/pemilihan atribut-atribut yang relevan bagi sebuah entitas merupakan hal penting lainnya dalam pembentukan model data. Penetapan atribut bagi sebuah entitas umumnya memang didasarkan pada fakta yang ada. Tetapi tidak selalu seperti itu. Kelak akan kita lihat, karena proses normalisasi atau pertimbangan-pertimbangan kompromistis, ada sejumlah atribut yang kita ciptakan sendiri dan tidak dikenal di „dunia nyata‟ yang sesungguhnya. Atribut berfungsi sebagai penjelasan pada sebuah entitas dan untuk menggambarkan atribut digunakan aturan sebagai berikut : (sustanta,2011 : 98) a. Atribut dinyatakan dengan simbol elips. b. Nama atribut dituliskan didalam simbol elips
86
c. Nama atribut berupa kata benda, tunggal. d. Nama atribut sedapat mungkin menggunakan nama yang mudah dipahami dan dapat menyatakan maknanya dengan jelas e. Atribut dihubungkan dengan entitas yang bersesuai menggunakan sebuah garis. 3. Relasi (Relationship) dan Himpunan Relasi (Relationship Sets) Relasi menunjukan adanya hubungan diantara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Misalnya, entitas seorang mahasiswa dengan nim=‟980001‟ dan nama_mhs=‟Ali Akbar‟ (yang ada di himpunan entitas mahasiswa) mempunyai relasi dengan entitas sebuah mata kuliah dengan kode_kul=‟IF-110‟ dan nama_kul=‟Struktur Data‟. Relasi di antara kedua entitas tadi mengandung arti bahwa mahasiswa tersebut sedang mengambil atau mempelajari mata kuliah tersebut disebuah perguruan tinggi yang kita tinjau. Kumpulan semua relasi diantara entitasentitas yang terdapat pada himpunan entitas-himpunan entitas tersebut membentuk himpunan relasi (Relationship Sets). Sebagaimana istilah himpunan entitas yang banyak sekali disingkat menjadi entitas (walaupun sebenarnya memiliki perbedaan makna), istilah himpunan relasi jarang sekali digunakan dan lebih sering disingkat dengan istilah relasi saja. 4. Kardinalitas/Derajat Relasi Kardinalitas relasi menunjukan jumlah maksimum entitas yag dapat berelasi dengan entitas pada himpunan entitas yang lain. Pada contoh sebelumnya, dapat kita lihat bahwa entitas-entitas pada himpunan entitas mahasiswa dapat berelasi dengan satu entitas, banyak entitas atau bahkan tidak satupun entitas dari himpunan entitas kuliah. Begitu juga sebaliknya, entitasentitas pada himpunan entitas kuliah ada yang berelasi dengan beberapa entitas pada himpunan entitas mahasiswa dan adapula yang berelasi dengan satu entitas pada himpunan entitas mahasiswa. Dari sejumlah kemungkian banyaknya hubungan antar entitas tersebut, kardinalitas relasi merujuk kepada hubungan maksimun yang terjadi dari himpunan entitas yang satu ke himpunan entitas yang lain dan begitu juga
PARADIGMA VOL. XV. September 2013
sebaliknya. Pada contoh di atas, maka hubungan maksimum dari himpunan entitas mahasiswa ke himpunan entitas kuliah adalah banyak (lebih dari satu). Dan semikian pula hubungan maksismun dari himpunan entitas kuliah ke himpunan entitas mahasiswa adalah banyak (lebih dari satu). Dengan demikian kardinalitas relasi antar kedua himpunan entitas adalah banyak ke banyak. Kardinalitas relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dapat berupa: a. Satu ke Satu (One to One) Yang berarti setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas B dan begitu juga sebaliknya setiap entitas pada himpunan entitas B beruhubungan dengan paling banyak dengan satu entitas paa himpunan entitas A. b. Satu ke Banyak (One to Many) Yang berarti setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada hipunan entitas B, tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas A. c. Banyak ke Satu (Many to One) Yang berarti setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas B, tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas A berhubungan dengan paling banyak satu entitas pada himpunan entitas B. d. Banyak ke banyak (Many to Many) Yang berarti setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, dan demikian juga sebaliknya, dimana setiap entitas pada himpunan entitas B dapat berhubungan dengan banyak entitas pada himpunan entitas A III. METODE PENELITIAN 5.1 Konsep Dasar Pengembangan sistem
Model
1. Teori Model water Fall Menurut M. Salahuddin (2011: 26), Model Water Fall adalah model SDLC yang paling sederhana. Model ini
hanya cocok untuk pengembangan perangkat dengan spesifikasi yang tidak berubah-ubah. Sistem/Rekayasa Informasi Analisis Desain Pengodean Pengujian a. Analisis Kebutuhan Perangkat Lunak Proses pengumpulan kebutuhan dilakukan secara intensif untuk mespesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan perangkat lunak pada tahap ini perlu untuk didokumentasikan. b. Desain Desain perangkat linak adalah proses multilangkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antar muka, dan prosedur pengodean. Tahap ini mentranslasi kebutuhan perangkat lunak dari tahap analisis kebutuhan ke representasi desain agar dapat diimplementasikan menjadi program pada tahap selanjutnya. Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu didokumentasikan. c. Pembuatan Kode Program Desain harus ditranslasikan kedalam program perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain. d. Pengujian Pengujian fokus pada perangkat lunak secara dari segi lojik dan fungsional dan memastikan bahwa semua bagian sudah di uji. Hal ini dilakukan untuk meminimalisir kesalahan (error) dan memastikan keluaran yang dihasilkan sesuai dengan yang diinginkan. e. Pendukung Tidak menutup kemungkinan sebuah perangkat lunak mengalami perubahan ketika sudah dikirim ke user. Perubahan bias terjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau perangkat lunak harus beradaptasi dengan lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan
87
PARADIGMA VOL. XV. September 2013 mulai dari analisis spesifikasi untuk perubahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru. 2. Teori Metode Interface Terdapat dua pendekatan dalam menyusun mekanisme inferensi berbasis aturan, yaitu forward chaining dan backward chaining. a. Forward Chaining Yaitu sebuah metode pelacakan kedepan, dimana diawali dari faktafakta yang diberikan user kemudian dicari dibasis pengetahuan lalu dicari rule yang sesuai dengan fakta-fakta. Setelah itu diadakan hipotesa untuk memperoleh kesimpulan. Metode inferensi ini yang akan digunakan dalam sistem pakar yang akan dibangun dengan contoh penalaran sebagai berikut: IF Badan Demam AND Mata kuning AND Sendi-sendi kaku AND Air seni berwarna gelap THEN Hepatitis A
4.user bisa menghapus data pasien agar tidak terjadi penumpukan saat di cetak Halaman Admin: 1. Admin dapat mengelola data penyakit. 2. Admin dapat mengelola data gejala. 3. Admin dapat mengelola data solusi. 4. Admin dapat mengelola data pasien. 5. Admin dapat mengelola data admin baru B. Use Case Diagram 1. Use Case Admin
Gambar VI.1. Use Case Diagram Dengan Actor Admin 2. Use Case User
Pencocokan fakta atau pernyataan dimulai dari bagian sebelah kiri. Dengan kata lain, penalaran dimulai dari fakta terlebih dahulu, lalu dicari rule yang IV. PEMBAHASAN 4.1. Analisa Kebutuhan Sofware A. Tahapan Analisis Pasien dalam hal melakukan diagnosis tidak harus menunggu dokter atau bertatap langsung dengan dokter, pasien langsung mendiagnosis penyakit yang dideritanya melalui sistem pakar diagnosis khusus mendiagnosis penyakit hepatitis. Berikut ini spesifikasi kebutuhan (system requirement)untuk admin dan user dalam bentuk siatem pakar. Halaman user: 1. user harus mengisi form data pasien terlebih dahulu dengan ketik nama pasien, umur dan jenis kelamin sebelum melakukan diagnosis. 2. user melakukan diagnosis penyakit hepatitis dengan menjawab pertanyaan sesuai dengan gejala yang dialami pasien. 3. user bisa melihat Hasil diagnosis dan solusi dari hasil penyakit tersebut.
88
Gambar VI.2. Use Case Diagram Dengan Actor User A. Spesifikasi File Penjelasan tabel-tabel yang digunakan dalam program yang diusulkan serta field yang terdapat pada file database yang akan dibangun sering disebut dengan spesifikasi file. Tabel-tabel tersebut akan menampung data sistem pakar diagnosis penyakit Hepatitis. B. Component Diagram Komponen yang dipakai didalam sistem pakar diagnosis penyakit hepatitis adalah microscof visual basic 6.0 dan menggunakan data accses ADODC untuk
PARADIGMA VOL. XV. September 2013
menyimpan pengetahuan pada sistem ini menggunakan microscof office access 2007 C. Deployment Diagram Proses deployment pada sistem pakar diagnosis penyakit Hepatitis ini adalah adalah Microsoft Visual Basic 6.0 dan menggunakan data akses ADODC, database Microsoft Access 2007. Untuk lebih memahaminya dapat melihat pemodelan dari proses deployment D Testing Penulis dalam mentesting sistem Pakar diagnosis penyakit hepatitis menggunakan testing whitebox. whitebox testing merupakan metode pengujian perangkat lunak yang tes fungsionalitas dari aplikasi yang bertentangan dengan struktur internal atau kerja. pengetahuan khusus dari kode struktur internal dan pengetahuan pemrograman pada umumnya tidak diperlukan. Uji kasus dibangun di sekitar spesifikasi dan persyaratan, yakni aplikasi apa yang seharusnya dilakukan. Menggunakan deskripsi eksternal perangkat lunak, termasuk spesifikasi, persyaratan, dan desain untuk menurunkan uji kasus. Tes ini dapat menjadi fungsional atau nonfungsional, meskipun biasanya fungsional. Perancang uji memilih input yang valid dan tidak valid dan menentukan output yang benar. Tidak ada pengetahuan tentang struktur internal benda uji itu. Berikut hasil pengujian dari sistem pakar diagnosis penyakit hepatitis. E Support Spesifikasi Hardware Dan Sofware Untuk membuat sebuah system diperlukan beberapa hal yang harus ada, supaya sistem komputer ini bisa berjalan sesuai dengan keinginan, kebutuhan dan kepentingan. Hal – hal yang dibutuhkan dalam sebuah system komputer meliputi hardware dan software yang sesuai dengan kebutuhan, berikut beberapa perangkat yang dibutuhkan dalam sebuah sistem. IV. PENUTUP 4.1 Kesimpulan Berdasarkan dari hasil penelitian yang sudah dilakukan di Rumah Sakit Umum daerah Tasikmalaya, penulis mencoba mengambil kesimpulan dari seluruh pokok pembahasan pada bab-bab sebelumnya yang ada dalam skripsi yang telah dibuat ini. Bahwa kurangnya
waktu dan kesibukan dokter bisa menjadi permasalahan untuk cepat menangani gejala penyakit pada pasien terutama untuk penyakit hepatitis. Hepatitis adalah penyakit yang disebabkan oleh beberapa jenis virus yang menyerang dan menyebabkan peradangan serta merusak sel-sel organ hati manusia jika dibiarkan penyakit tersebut akan cepat menular dan bisa menyebabkan kematian. Untuk itu dibutuhkan informasi berupa sistem pakar agar gejala-gejala penyakit hepatitis dari pasien dapat didiagnosa berdasarkan pengetahuan yang didapat dari seorang pakar. Maka diharapkan aplikasi diagnosis ini dapat membantu dan mempermudah pihak-pihak terkait khususnya dokter dalam diagnosis penyakit pasien. Di dalam skripsi ini, program pendiagnosisan penyakit hepatitis menggunakan metode pencarian forward chaining. Setelah di uji coba, program sistem pakar ini telah berhasil memecahkan masalah pendiagnosisan pada penyakit hepatitis. Sehingga dapat memberikan informasi berupa aplikasi yang dapat menghasilkan diagnosis jenis penyakit hepatitis pada pasien dan dapat membantu (bukan menggantikan) tugastugas paradokter sehingga dapat meringankan beban pakar dalam hal intensistas pekerjaan dokter. Secara umum kesimpulan penulis pada skripsi yang telah dibuat ini adalah sebagai berikut: 1. Untuk memberikan informasi berupa aplikasi yang dapat menghasilkan diagnosis jenis penyakit hepatitis pada pasien sehingga pasien lebih cepat mengetahui hasil diagnosis penyakit sehingga dapat melakukan tindakan selanjutnya untuk tahap tes labotorium. 2. Untuk membantu (bukan menggantikan) tugas-tugas para dokter sehingga dapat meringankan beban pakar dalam hal intensistas pekerjaan dokter. 4.2. Saran - Saran Berdasarkan kesimpulan dari pembahasan dan penjelasan diatas, penulis memberikan beberapa saran sebagai alternatife yang dapat dijadikan sebagai masukan yang berguna dan bermanfaat dan berharap agar dapat meningkatkan kualitas pendiagnosisan penyakit Hepatitis
89
PARADIGMA VOL. XV. September 2013 Untuk itu perlu diperhatikan pada sistem pakar pendiagnosisan penyakit hepatitis yang telah dikomputerisasikan, yaitu sebagai berikut: 1. Bila sistem akan di pakai didalam suatu sistem di klinik atau Rumah sakit, maka perlu penambahan entitas dan data untuk mendukung informasi yang dibutuhkan pada klinik atau Rumah sakit tersebut. 2. Melakukan pembaharuan data apabila ditemukan kasus-kasus terbaru, sehingga masyarakat dapat memperoleh informasi lebih banyak lagi. 3. Ketika Menjawab pertanyaan yang terdapat di form konsultasi, di harapkan sesuai dengan geja yang dialami pasien sehingga meminimalkan adanya kesalahan diagnosis penyakit. 4. Ada baiknya diadakan suatu pelatihan terhadap para petugas yang akan menuntun pengguna untuk menjalankan aplikasi ini sehingga tidak menghambat rangkaian kerja yang akan dilakukan dan untuk menjamin kebenarannya, ketepatan, dan kecepatan pendiagnosaan penyakit. Demikianlah penjelasan mengenai program pada skripsi ini mengenai sistem pakar untuk mendiagnosis penyakit hepatitis menggunkan metode forward chaining.semoga dengan adanya sistem pakar ini, para penderita penyakit hepatitis bisa cepat mendapatkan hasil diagnosis, sehingga dapat di deteksi lebih cepat dan langsung diberikan pengobatan.
90
DAFTAR PUSTAKA Arhami, Muhammad. 2005. Konsep dasar sistem pakar.yogyakarta: andi offse Chandra Pradana, sri kusumadewi. 2007. Aplikasi Diagnosis Penyakit Hepatitis Untuk Mobile Devices Menggunakan J2ME. Vol. 5 number 2, Desember 2007. Pujianta, Pujiantoro. 2012. Sistem Pakar Penentuan Jenis Penyakit Hati Dengan Metode Inferensi Fuzzy Tsukamoto. Vol. 6 number 1, January 2012. Pressman, Roger. 2012.Rekayasa Perangkat Lunak.yogyakarta: Andi Ramadhan, Arief. 2004. Seri penuntun praktis microsoft visual basic 6.0. jakarta: pt elex media komputindo. Rosa A. S, M. Salahuddin. 2011. Rekayasa Perangkat Lunak. Bandung: Modula. Sulisyowati, Isti. 2011. Implementasi Ssistem Pakar Berbasis Web Untuk Mendiagnosis Penyakit Dalam Pada Manusia. ISBN 979-26-0255-0, 2011. Tim Penerbit ANDI. 2003. Pengembangan Sistem Pakar Menggunakan Visual Basic. Yogyakarta: Andi Offset.
