PERANCANGAN SISTEM PAKAR ALARM GANGGUAN BASE TRANSCEIVER STATION BERBASIS WEB

TUGAS AKHIR Diajukan untuk Memenuhi Salah Satu Syarat Kelulusan Program Sarjana Strata 1 (S1) Teknik Informatika

Oleh: Oky Yogaswara 0406035

JURUSAN TEKNIK INFORMATIKA SEKOLAH TINGGI TEKNOLOGI GARUT 2011

LEMBAR PENGESAHAN
PERANCANGAN SISTEM PAKAR ALARM GANGGUAN BASE TRANSCEIVER STATION BERBASIS WEB

Disusun Oleh: Oky Yogaswara NRP. 0406035

Menyetujui: Pembimbing I Pembimbing II

Dini Destiani SF., MT. NIDN. 0017126401

Nurdiyanto., MT. NIP. 132135913

Mengetahui, Ketua Jurusan Teknik Informatika

Eri Satria., M.Si. NIDN. 0029127501

Ya Allah.. Pada-Mu kutitip secuil asa, Kau berikan selaksa bahagia Pada-Mu kuharap setetes cinta, Kau limpahkan samudera cinta. Sebuah harapan berakar keyakinan dari perpaduan hati yang memiliki keteguhan. Walaupun didera oleh cobaan dan membutuhkan perjuangan panjang demi cita-cita yang tak mengenal kata usai. Setitik harapan itu telah kuraih, namun sejuta harapan masih kuimpikan dan ingin kugapai. Karya ini ku persembahkan untuk mama Nenden Dimyati dan almarhum bapa Warsan Goenara tercinta yang tak kenal lelah dalam memperjuangkan anak-anaknya. Yang selalu memberiku harapan, kebahagiaan, cinta dan kasih sayangnya yang diberikan dengan ikhlas tanpa pamrih. Terimakasih juga untuk kakak ku tersayang Deden Daniswara dan Telly Kania Iswara, motivasi dan kritikannya membuatku semakin semangat untuk berjuang. Serta buat Gina Gustina yang tak pernah berhenti memberikan motivasi. Dan kepada keluarga besarku,saudara serta para sahabatku yang telah memberi semangat dan dukungan, Terima kasih atas doa, dorongan dan bantuan yang tak pernah henti.. Semoga Allah SWT selalu memberikan yang terbaik dan Ridho-Nya kepada kita semua.. Amin..

OKY YOGASWARA, 0406035 PERANCANGAN SISTEM PAKAR ALARM TRANSCEIVER STATION BERBASIS WEB

GANGGUAN

BASE

Di bawah bimbingan Dini Destiani S.F., MT., selaku Dosen Pembimbing I dan Nurdiyanto., MT., selaku Dosen Pembimbing II 148 halaman, 55 tabel, 79 gambar, 16 daftar pustaka ABSTRAK
Gangguan yang dialami oleh pelanggan seluler disebabkan oleh banyak faktor salah satunya yakni gangguan pada mesin BTS. Gangguan yang terjadi ditandai dengan adanya alarm yang terdapat pada modul-modul dari mesin BTS itu sendiri. Alarm ini memudahkan user dalam hal ini team engineer dan field engineer untuk menganalisa masalah dan melakukan trouble shoot untuk memperbaiki masalah yang terjadi. Namun tidak semua jenis alarm bisa dianalisa secara langsung dikarenakan banyaknya jenis alarm yang terdapat di mesin BTS. Oleh karena hal tersebut, maka sistem pakar alarm gangguan base transceiver diharapkan menjadi sebuah alternatif bantuan bagi user dalam memperoleh informasi mengenai jenis-jenis alarm dan penanganan kerusakannya. .Bahasa pemrograman yang digunakan sebagai pembangun sistem adalah PHP dan MySQL untuk pengolahan database-nya. Dalam pengembangannya, sistem pakar yang dirancang menggunakan metodologi ESDLC (Expert System Development Life Cycle). Pada bagian analisis, dimulai dengan tahap penilaian permasalahan gangguan pada mesin BTS yang terjadi dengan kompleksitasnya sehingga dapat ditentukan tujuan perancangan sistem pakar untuk dapat membantu team engineer dalam mengetahui jenis-jenis alarm dan penanganan kerusakannya. Dari penilaian tersebut kemudian dibangun basis pengetahuan yang didapat dengan proses akuisisi pengetahuan dari sumber pengetahuan untuk kemudian diorganisir dan dipelajari secara terperinci sehingga diperoleh pengetahuan yang dijadikan sebagai basis data dalam basis pengetahuan sistem pakar yang dibangun. Pada tahap perancangan sistem pakar, basis pengetahuan yang didapat dari proses akusisi pengetahuan kemudian direpresentasikan dengan menggunakan model kaidah produksi, sementara itu dalam mengembangkan mesin inferensi teknik yang digunakan yaitu backward chaining. Dalam mendeskripsikan alur program digunakan dua pendekatan, yaitu flowmap untuk mendeskripsikan mekanisme kerja aplikasi sistem pakar yang dirancang dan diagram aliran data (DFD) untuk mendeskripsikan proses aliran data yang ada dalam aplikasi sistem pakar yang dirancang. Untuk menggambarkan pemodelan data atau desain basis data digunakan model Entity Relationship Diagram yang selanjutnya ditransformasikan ke dalam bentuk database relasional, yaitu dalam bentuk hubungan antar atribut dalam suatu tabel yang kemudian diuji tingkat akurasi datanya menggunakan teknik normalisasi dan diteruskan dengan penjelasan objek data pada setiap tabel dengan menggunakan kamus data. Dengan fasilitas yang diberikan untuk pemakai dan pakar, memungkinkan baik pemakai maupun pakar untuk menggunakan sistem ini sesuai kebutuhannya masing-masing. Pemakai diberi kemudahan untuk mendapatkan solusi atas kerusakan mesin BTS yang terjadi berdasarkan gejala-gejala yang telah dipilih pada proses penelusuran, yang terdiri dari pemilihan tipe dari alarm, dilanjutkan dengan pemilihan data gejala kerusakan yang dialami. Sedangkan pakar diberi kemudahan dalam memanajemen sistem, baik proses tambah, hapus maupun update data terkait.

Kata kunci : sistem pakar, alarm BTS, backward chaining.

KATA PENGANTAR Puji dan syukur penulis panjatkan ke hadirat Illahi Rabbi karena atas berkat dan rahmatnya penulis dapat menyelesaikan Laporan Tugas Akhir ini. Tak lupa shalawat beserta salam semoga tercurah limpah kepada Nabi Besar Muhammad SAW, kepada para keluarganya, sahabatnya dan selanjutnya kepada umatnya hingga akhir zaman. Laporan Tugas Akhir berjudul : Perancangan Sistem Pakar Alarm Gangguan Base Transceiver Station Berbasis Web diajukan untuk memenuhi syarat kelulusan mata kuliah Tugas Akhir sebagai akhir dari program pembelajaran program studi Strata-1 di Sekolah Tinggi Teknologi Garut. Penulis menyadari sepenuhnya bahwa Laporan Tugas Akhir ini kurang sempurna baik penyusunan maupun materi yang disajikan di dalamnya. Hal ini dikarenakan keterbatasan kemampuan dan pemahaman penulis dalam meninterpretasikan suatu masalah. Oleh karena itu penulis mengharapkan saran dan kritik yang sekiranya dapat menjadi perbaikan dan pembangun bagi pembuatan Laporan selanjutnya. Pada kesempatan ini penulis mengucapkan terima kasih dan penghargaan kepada: 1. Ibu dan Almarhum Ayah yang senantiasa memberi penulis semangat, doa, dan materil. 2. Bapak Eri Satria, MT., selaku Ketua Jurusan Teknik Informatika STTGarut dan sekaligus sebagai dosen Penguji yang telah banyak memberikan masukan dalam laporan Tugas Akhir ini. 3. Bapak Rinda Cahyana, ST., selaku Sekretaris Jurusan Teknik Informatika STT-Garut. 4. Ibu Dini Destiani S.F., MT., selaku dosen pembimbing I yang telah banyak membantu penulis dalam menyelesaikan laporan Tugas Akhir ini. 5. Bapak Nurdiyanto., MT., selaku dosen pembimbing II yang telah banyak membantu penulis dalam menyelesaikan laporan Tugas Akhir ini

6. Kang Dian dan Kang Yosep selaku Staf Jurusan Informatika yang telah banyak membantu penulis dalam administrasi Tugas Akhir. 7. Bapak Iwan Ridwan., ST., dan seleruh Staff Operational and Maintenance Network di PT. Bakrie Telecom Tbk Tasikmalaya yang telah membantu dan memberikan informasi mengenai alarm gangguan BTS. 8. Taopik Ridwan., ST., yang telah membantu dan membimbing penulis dalam pengerjaan aplikasi. 9. Bagi seorang perempuan spesial bagi penulis yang selalu memberi semangat, dorongan dan motivasi bagi penulis selama ini. 10. Teman-teman seperjuangan di Teknik Informatika 2004, Dandan, Peri, Farid dan seluruh rekan-rekan di Teknik Informatika 2004 yang selalu hadir selama penulis kuliah di STTG, kenangan yang takkan terlupakan. 11. Rekan-rekan kerja di PT. Bakrie Telecom Tbk Garut yang selalu membantu penulis dengan masukan-masukan yang berarti bagi penyusunan Laporan Tugas Akhir ini. 12. Dan semua pihak yang telah membantu penulis yang tidak bisa disebutkan satu persatu. Penulis mengucapkan terima kasih dan semoga apa yang telah diberikan kepada penulis selama ini mendapat balasan yang setimpal dari Allah SWT. Amin. Terlepas dari segala keterbatasan Laporan Tugas Akhir ini, penulis berharap semoga Laporan ini dapat bermanfaat khususnya bagi penulis demi peningkatan pengetahuan penulis dan umumnya kepada semua pihak yang akan dan terus membaca Laporan ini.

Garut,

Oktober 2010

Penulis

DAFTAR ISI Halaman ABSTRAK KATA PENGANTAR ....................................................................................... i DAFTAR ISI ...................................................................................................... iii DAFTAR GAMBAR ......................................................................................... ix DAFTAR TABEL ............................................................................................. xiii BAB I 1.1 1.2 1.3 1.4 1.5 1.6 1.7 BAB II 2.1 2.2 PENDAHULUAN Latar Belakang Masalah ..................................................................... Identifikasi Masalah ........................................................................... Tujuan ................................................................................................. Batasan Masalah ................................................................................. Metodologi Penelitian ........................................................................ Kerangka Pemikiran ........................................................................... Sistematika Penulisan ......................................................................... LANDASAN TEORI Kecerdasan Buatan ............................................................................. 10 Sistem Pakar ....................................................................................... 11 1 3 3 3 4 7 9

2.2.1 Pengertian Sistem ............................................................................. 11 2.2.2 Karakteristik Sistem ......................................................................... 12 2.2.3 Definisi Pakar .................................................................................. 13 2.2.4 Pengenalan Sistem Pakar ................................................................. 14 2.2.5 Tujuan Sistem Pakar......................................................................... 16 2.2.6 Ciri dan Karakteristik Sistem Pakar ................................................. 17 2.2.6.1 Ciri Sistem Pakar ............................................................................. 17 2.2.6.2 Karakteristik Sistem Pakar ............................................................... 18 2.2.7 Perbandingan Sistem Konvensional dan Sistem Pakar .................... 19

Halaman 2.2.8 Pengelompokan Sistem Pakar .......................................................... 20 2.2.9 Sistem Pakar Berbasis Aturan .......................................................... 21 2.2.10 Arsitektur Sistem Pakar Berbasis Aturan ......................................... 22 2.3 Representasi Pengetahuan .................................................................. 26 2.3.1 Definisi Representasi Pengetahuan .................................................. 26 2.3.2 Model Representasi pengetahuan ..................................................... 26 2.3.2.1 Object-Attribute-Value (OAV) ......................................................... 26 2.3.2.2 Kaidah Produksi ............................................................................... 26 2.3.2.3 Frame (Bingkai) ............................................................................... 28 2.3.2.4 Logika .............................................................................................. 29 2.4 Inferensi .............................................................................................. 30 2.4.1 Forward Chaining ............................................................................ 31 2.4.2 Backward Chaining .......................................................................... 32 2.4.3 Karakteristik Forward Chaining dan Backward Chaining .............. 32 2.5 Basis Data ........................................................................................... 33 2.5.1 Definisi Basis Data ........................................................................... 33 2.5.2 Fungsi dan Perancangan Basis Data ................................................ 34 2.5.3 Identifikasi Bussiness Activity .......................................................... 35 2.5.4 Pemodelan Data................................................................................ 37 2.5.4.1 Data Flow Diagram (DFD) ............................................................. 37 2.5.4.2 Pengembangan Data Flow Diagram (DFD) .................................... 38 2.5.4.3 Kamus Data ...................................................................................... 39 2.5.5 Normalisasi....................................................................................... 41 2.5.6 Model Entity Relationship (E-R) ...................................................... 42 2.5.7 Entity Relationship Diagram (ERD) ................................................ 42 2.5.8 Kardinalitas ...................................................................................... 43 2.5.9 Structure Query Language (SQL) .................................................... 44 2.6 2.7 Server Web .......................................................................................... 46 PHP .................................................................................................... 47

Halaman 2.7.1 Kegunaan PHP ................................................................................. 49 2.7.2 Editor PHP ....................................................................................... 50 2.8 2.9 MySQL ................................................................................................ 50 Aplikasi PHP-MySQL ........................................................................ 51

2.9.1 Fungsi-fungsi MySQL ...................................................................... 51 2.9.2 Interaksi Database MySQL dan PHP ............................................... 53 2.9.3 Koneksi Server ................................................................................. 53 2.10 Editor Dreamweaver MX ................................................................... 54 2.11 Komponen Dreamweaver ................................................................... 55 2.11.1 Tool Bar Common ............................................................................ 55 2.11.2 Tool Bar Layout ............................................................................... 56 2.11.3 Tool Bar Frame ................................................................................ 56 2.11.4 Tool Bar Form.................................................................................. 56 2.11.5 Tool Bar Text.................................................................................... 57 2.11.6 Tool Bar PHP ................................................................................... 57 2.11.7 Menu Properties ............................................................................... 57 2.12 Mobile Station (MS) ........................................................................... 58 2.13 Base Tranceiver Station (BTS) ........................................................... 58 2.14 Base Station Controller (BSC) ........................................................... 59 2.15 Teori Alarm BTS ................................................................................ 60 2.15.1 Overview Alarm BTS ........................................................................ 60 2.15.2 Report Monitoring Alarm ................................................................. 62 2.15.3 Layout Frame BTS ............................................................................ 63 2.15.4 Level Alarm ....................................................................................... 63 2.15.5 Format Alarm .................................................................................... 64 2.15.6 Template Alarm ................................................................................ 64 BAB III ANALISIS SISTEM 3.1 Penilaian (Assessment) ....................................................................... 68

Halaman 3.1.1 Kelayakan dan Justifikasi Masalah .................................................. 68 3.1.2 Analisis Kebutuhan .......................................................................... 69 3.1.3 Tujuan Pengembangan Sistem ......................................................... 69 3.1.4 Perumusan Masalah.......................................................................... 69 3.1.4.1 Analisis Spesifikasi Kebutuhan Pemakai ......................................... 69 3.1.4.2 Analisis Spesifikasi Paket Program ................................................. 70 3.1.5 3.1.6 3.2 Identifikasi Sistem ............................................................................ 72 Sumber Pengetahuan ........................................................................ 73 Akuisisi Pengetahuan (Knowledge Acquistion) .................................. 74

BAB IV DESAIN SISTEM 4.1 Representasi Pengetahuan .................................................................. 77 4.1.1 Tabel Keputusan ............................................................................... 77 4.1.2 Pohon Keputusan.............................................................................. 83 4.1.3 Kaidah-kaidah dalam Bentuk Kaidah Produksi ............................... 85 4.2 Pengembangan Mesin Inferensi.......................................................... 89 4.2.1 Pemilihan Teknik Inferensi .............................................................. 89 4.2.2 Teknik Penelusuran Data ................................................................. 90 4.3 Perancangan Basis Data...................................................................... 90 4.3.1 Identifikasi Bussiness Activity .......................................................... 91 4.3.1.1 Batasan Sistem ................................................................................. 91 4.3.1.2 Bagan Organisasi ............................................................................. 91 4.3.1.3 Deskripsi Proses ............................................................................... 91 4.3.1.4 Flow Map (Bagan Alir) .................................................................... 92 4.3.2 Diagram Konteks.............................................................................. 94 4.3.2.1 DFD Level 0 .................................................................................... 95 4.3.2.2 DFD Level 1 Subproses Login......................................................... 96 4.3.2.3 DFD Level 1 Suproses Pengelolaan Basis Pengetahuan ................. 97 4.3.2.4 DFD Level 2 Subproses Kelola Data Gangguan ............................. 99

Halaman 4.3.2.5 DFD Level 2 Subproses Kelola Data Gejala ................................... 101 4.3.2.6 DFD Level 2 Subproses Kelola Data Solusi .................................... 103 4.3.2.7 DFD Level 1 Subproses Pengelolaan Basis Aturan ......................... 105 4.3.2.8 DFD Level 1 Subproses Konsultasi ................................................. 107 4.3.3 4.3.4 4.3.5 4.3.6 4.3.7 Kamus Data ...................................................................................... 108 Struktur Menu Sistem Pakar ............................................................ 111 Entity Relationship Diagram (ERD) ................................................ 113 Transformasi ERD ke Database Relasional ..................................... 113 Normalisasi dengan Ketergantugan Fungsional ............................... 114

4.3.7.1 Tabel Gangguan ............................................................................... 114 4.3.7.2 Tabel Pertanyaan .............................................................................. 115 4.3.7.3 Tabel Aturan ..................................................................................... 116 4.3.7.4 Tabel Solusi ...................................................................................... 117 4.3.7.5 Tabel User ........................................................................................ 119 4.4 Implementasi ...................................................................................... 120 4.4.1 Antarmuka Utama ............................................................................ 120 4.4.2 Antarmuka Login ............................................................................. 121 4.4.3 Antarmuka Konsultasi ...................................................................... 122 4.4.4 Antarmuka Hasil Hipotesis .............................................................. 124 4.4.5 Antarmuka Menu Pakar ................................................................... 125 4.4.6 Antarmuka Tambah Data Gangguan ................................................ 126 4.4.7 Antarmuka Tambah Data Gejala ...................................................... 127 4.4.8 Antarmuka Tambah Data Solusi ...................................................... 128 4.4.9 Antarmuka Tambah Data Rule ......................................................... 129 4.4.10 Antarmuka Tampil Data User .......................................................... 130 4.5 Simulasi Aplikasi................................................................................ 131 4.5.1 Lingkungan Pemakai ....................................................................... 131 4.5.2 Lingkungan Pakar ............................................................................ 134 4.5.2.1 Tambah Data Gangguan................................................................... 135

Halaman 4.5.2.2 Tambah Data Gejala ........................................................................ 137 4.5.2.3 Tambah Data Solusi ......................................................................... 139 4.5.2.4 Tambah Data Aturan ........................................................................ 141 4.5.2.5 Tambah Data User ........................................................................... 143 BAB V PENUTUP

5.1 Kesimpulan ............................................................................................ 146 5.2 Saran ...................................................................................................... 146 DAFTAR PUSTAKA ........................................................................................ 147

DAFTAR GAMBAR Halaman Gambar 1.1 Gambar 1.2 Gambar 2.1 Gambar 2.2 Gambar 2.3 Gambar 2.4 Gambar 2.5 Gambar 2.6 Gambar 2.7 Gambar 2.8 Gambar 2.9 Tahap Pengembangan Sistem Pakar ............................................ 5 Proses Perancangan Aplikasi Sistem Pakar ................................. 8 Model Umum Suatu Sistem Secara Sederhana ........................... 11 Karakteristik Suatu Sistem .......................................................... 12 Blok Diagram Sistem Pakar ........................................................ 15 Arsitektur Sistem Pakar ............................................................... 19 Model Sistem Produksi................................................................ 22 Arsitektur sistem pakar berbasis aturan ....................................... 23 Contoh Jaringan Semantik ........................................................... 28 Proses Inferensi dalam Sebuah Sistem Pakar .............................. 30 Proses Forward Chaining............................................................ 31

Gambar 2.10 Algoritma forward chaining ........................................................ 31 Gambar 2.11 Proses Backward Chaining.......................................................... 32 Gambar 2.12 Contoh Relasi Satu ke Satu ......................................................... 43 Gambar 2.13 Contoh Relasi Satu ke Banyak .................................................... 44 Gambar 2.14 Contoh Relasi Banyak ke Banyak ............................................... 44 Gambar 2.15 Diagram Eksekusi Halaman PHP ................................................ 48 Gambar 2.16 Halaman Design .......................................................................... 55 Gambar 2.17 Halaman Coder ............................................................................ 55 Gambar 2.18 Toolbar Common......................................................................... 55 Gambar 2.19 Toolbar Layout ............................................................................ 56 Gambar 2.20 Toolbar Frame ............................................................................. 56 Gambar 2.21 Toolbar Form ............................................................................... 57 Gambar 2.22 Toolbar Text ................................................................................ 57 Gambar 2.23 Toolbar PHP ................................................................................ 57 Gambar 2.24 Menu Properties........................................................................... 58 Gambar 2.25 Diagram Blok Base Transceiver Station ..................................... 61

Halaman Gambar 2.26 Layout Frame Base Transceiver Station ..................................... 63 Gambar 3.1 Gambar 4.1 Gambar 4.2 Gambar 4.3 Gambar 4.4 Gambar 4.5 Gambar 4.6 Gambar 4.7 Gambar 4.8 Gambar 4.9 Struktur dan Proses Sistem Pakar Alarm Gangguan Base Transceiver Station ...................................................................... 72 Pohon Keputusan Diagnosa Alarm Gangguan ............................ 84 Penerapan Inferensi Runut Balik (Backward Chaining) ............. 89 Teknik Penelusuran Data ............................................................. 90 Hubungan Tiga Aktor pada Perancangan Sistem Pakar Alarm Gangguan Base Transceiver Station ........................................... 91 Skema Sistem Pakar .................................................................... 91 Skema Diagnosis Alarm Gangguan Base Transceiver Station ... 92 Flowmap Aplikasi Sistem Pakar Alarm Gangguan Base Transceiver Station ...................................................................... 93 Diagram Konteks Sistem Pakar Alarm Gangguan Base Transceiver Station ...................................................................... 94 DFD Level 0 Aplikasi Sistem Pakar Alarm Gangguan Base Transceiver Station ...................................................................... 95 Gambar 4.10 DFD Level 1 Subproses Login .................................................... 96 Gambar 4.11 DFD Level 1 Pengelolaan Basis Pengetahuan ............................ 97 Gambar 4.12 DFD Level 2 Subproses Kelola Data Gangguan ......................... 99 Gambar 4.13 DFD Level 2 Subproses Kelola Data Gejala ...............................101 Gambar 4.14 DFD Level 2 Subproses Kelola Data Solusi ...............................103 Gambar 4.15 DFD Level 2 Subproses Pengelolaan Basis Aturan ....................105 Gambar 4.16 DFD Level 1 Subproses Konsultasi ............................................107 Gambar 4.17 Struktur Menu Aplikasi Sistem Pakar Alarm Gangguan Base Transceiver Station Pada Lingkungan User ...............................111 Gambar 4.18 Struktur Menu Aplikasi Sistem Pakar Alarm Gangguan Base Transceiver Station Pada Lingkungan Admin/Pakar ..................112 Gambar 4.19 ERD Untuk Sistem Pakar Diagnosis Alarm Gangguan Base Transceiver Station ......................................................................113

Halaman Gambar 4.20 Antarmuka Utama .......................................................................120 Gambar 4.21 Antarmuka Login.........................................................................121 Gambar 4.22 Antarmuka Konsultasi .................................................................122 Gambar 4.23 Antarmuka Konfirmasi Jawaban Hipotesis .................................123 Gambar 4.24 Antarmuka Hasil Hipotesis..........................................................124 Gambar 4.25 Antarmuka Menu Pakar ...............................................................125 Gambar 4.26 Antarmuka Tambah Data Gangguan ...........................................126 Gambar 4.27 Antarmuka Tambah Data Gejala .................................................127 Gambar 4.28 Antarmuka Tambah Data Solusi .................................................128 Gambar 4.29 Antarmuka Tambah Data Rule ....................................................129 Gambar 4.30 Antarmuka Tampil Data User .....................................................130 Gambar 4.31 Form Login untuk User ...............................................................131 Gambar 4.32 Form Konsultasi ..........................................................................132 Gambar 4.33 Form Konfirmasi Jawaban ..........................................................133 Gambar 4.34 Hasil Hipotesis.............................................................................134 Gambar 4.35 Form Login untuk Pakar ..............................................................135 Gambar 4.36 Akses ke Sub-Menu Tambah Data Alarm ...................................135 Gambar 4.37 From Tambah Data Alarm...........................................................136 Gambar 4.38 Data Alarm ..................................................................................137 Gambar 4.39 Akses ke Sub-Menu Tambah Data Gejala...................................137 Gambar 4.40 Form Tambah Data Gejala ..........................................................138 Gambar 4.41 Data Gejala ..................................................................................139 Gambar 4.42 Akses ke Sub-Menu Tambah Data Solusi ...................................140 Gambar 4.43 Form Tambah Data Solusi ...........................................................140 Gambar 4.44 Data Solusi...................................................................................141 Gambar 4.45 Akses ke Sub-Menu Tambah Data Rule .....................................142 Gambar 4.46 Form Tambah Data Rule .............................................................142 Gambar 4.47 Data Rule .....................................................................................143 Gambar 4.48 Akses ke Sub-Menu Tambah Data User .....................................144

Halaman Gambar 4.49 Form Tambah Data User .............................................................144 Gambar 4.50 Data Pengguna atau Pakar ...........................................................145

DAFTAR TABEL Halaman Tabel 2.1 Perbandingan Kepakaran Manusia dan Sistem Pakar ...................... 16 Tabel 2.2 Perbandingan Sistem Konvensional dan Sistem Pakar .................... 19 Tabel 2.3 Representasi pengetahuan dengan OAV .......................................... 26 Tabel 2.4 Karakteristik Forward Chaining dan Backward Chaining .............. 32 Tabel 2.5 Simbol Flow Map ............................................................................. 36 Tabel 2.6 Simbol-simbol pada DFD................................................................. 37 Tabel 2.7 Notasi dalam ERD ............................................................................ 42 Tabel 2.8 Tujuh Perintah SQL ......................................................................... 46 Tabel 2.9 Fungsi-fungsi MySQL ..................................................................... 51 Tabel 3.1 Hasil Akuisisi Pengetahuan .............................................................. 75 Tabel 3.2 Hasil Akuisisi Pengetahuan (Lanjutan) ............................................ 76 Tabel 4.1 Keputusan Berdasarkan Gangguan Alarm ....................................... 78 Tabel 4.2 Keputusan Berdasarkan Gejala ........................................................ 80 Tabel 4.3 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS .................... 85 Tabel 4.4 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) .. 86 Tabel 4.5 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) .. 87 Tabel 4.6 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) .. 88 Tabel 4.7 Spesifikasi Proses DFD Level 1 Subproses Login ........................... 96 Tabel 4.8 Arus Data DFD Level 1 Subproses Login........................................ 97 Tabel 4.9 Spesifikasi Proses DFD Level 1 Subproses Pengelolaan Basis Pengetahuan ..................................................................................... 98 Tabel 4.10 Arus Data DFD Level 1 Subproses Pengelolaan Basis Pengetahuan ..................................................................................... 98 Tabel 4.11 Spesifikasi Proses DFD Level 2 Subproses Kelola Data Gangguan ......................................................................................... 99 Tabel 4.12 Arus Data DFD Level 2 Subproses Kelola Data Gangguan ............100

Halaman Tabel 4.13 Spesifikasi Proses DFD Level 2 Subproses Kelola Data Gejala ......102 Tabel 4.14 Arus Data DFD Level 2 Subproses Kelola Data Gejala ..................102 Tabel 4.15 Spesifikasi Proses DFD Level 2 Subproses Kelola Data Solusi ......103 Tabel 4.16 Arus Data DFD Level 2 Subproses Kelola Data Solusi ...................104 Tabel 4.17 Spesifikasi Proses DFD Level 1 Pengelolaan Basis Aturan ............105 Tabel 4.18 Arus Data DFD Level 1 Pengelolaan Basis Aturan .........................106 Tabel 4.19 Spesifikasi Proses DFD Level 1 Subproses Konsultasi ...................107 Tabel 4.20 Arus Data DFD Level 1 Subproses Konsultasi ................................108 Tabel 4.21 Kamus Data Tabel Gangguan ..........................................................109 Tabel 4.22 Kamus Data Tabel Pertanyaan .........................................................109 Tabel 4.23 Kamus Data Tabel Solusi .................................................................109 Tabel 4.24 Kamus Data Tabel Keterangan ........................................................110 Tabel 4.25 Kamus Data Tabel GoalSolusi .........................................................110 Tabel 4.26 Kamus Data Tabel Aturan ................................................................110 Tabel 4.27 Kamus Data Tabel Teporary ............................................................110 Tabel 4.28 Kamus Data Tabel User ...................................................................111 Tabel 4.29 Normalisasi Tabel Gangguan ...........................................................114 Tabel 4.30 Normalisasi Tabel Pertanyaan ..........................................................116 Tabel 4.31 Normalisasi Tabel Aturan ................................................................117 Tabel 4.32 Normalisasi Tabel Solusi .................................................................118 Tabel 4.33 Normalisasi Tabel User ....................................................................119 Tabel 4.34 Tabel Keterangan Antarmuka Utama ...............................................120 Tabel 4.35 Tabel Keterangan Antarmuka Login ................................................121 Tabel 4.36 Tabel Keterangan Antarmuka Konsultasi ........................................122 Tabel 4.37 Tabel Keterangan Antarmuka Konfirmasi Jawaban Hipotesis ........123 Tabel 4.38 Tabel Keterangan Antarmuka Hasil Hipotesis .................................124 Tabel 4.39 Tabel Keterangan Antarmuka Menu Pakar ......................................125 Tabel 4.40 Tabel Keterangan Antarmuka Tambah Data Gangguan ..................126 Tabel 4.41 Tabel Keterangan Antarmuka Tambah Data Gejala ........................127

Halaman Tabel 4.42 Tabel Keterangan Antarmuka Tambah Data Solusi .........................128 Tabel 4.43 Tabel Keterangan Antarmuka Tambah Data Rule ...........................129 Tabel 4.44 Tabel Keterangan Antarmuka Tampil Data User ............................130

BAB I PENDAHULUAN

1.1

Latar Belakang Masalah Perkembangan teknologi di bidang Informasi dan Telekomunikasi yang pesat mendorong berkembangnya berbagai metode dalam merancang jaringan telekomunikasi khususnya komunikasi nirkabel yang bersifat mobile. Pilihan-pilihan teknologi Telekomunikasi yang dapat dimanfaatkan oleh masyarakat masing-masing memiliki kelebihan dan kekurangan. Perusahaan-perusahaan yang bergerak di bidang telekomunikasi mulai berlomba-lomba mengeluarkan kartu Sim Card dengan jenis CDMA atau GSM demi memuaskan konsumen. Di antara penunjang keberhasilan suatu operator adalah jaringan yang bagus meliputi cakupan wilayah yang luas, tingkat keberhasilan pelanggan membuat panggilan yang tinggi, jumlah drop call yang kecil, dan kapasitas kanal yang disediakan memadai. Untuk menjaga kehandalan jaringan, maka bagian yang berhubungan langsung dengan telepon genggam harus dijaga kestabilan kerjanya. Bagian tersebut adalah Base Transceiver Station (BTS). BTS tersebut jumlahnya banyak tersebar ke daerah-daerah. Base Transceiver Station (BTS) merupakan perangkat transceiver yang berhubungan dari/ke pelanggan atau dari MSC ke MS dalam sistem komunikasi seluler. Perangkat tersebut terdiri dari modul-modul yang masing-masing memiliki indikator alarm untuk mengindikasikan kerusakan atau error, misalnya error device, error fan, error rectifier. Gangguan yang dialami oleh pelanggan seluler disebabkan oleh banyak faktor salah satunya yakni gangguan pada mesin BTS. Gangguan yang terjadi ditandai dengan adanya alarm yang terdapat pada modul-modul dari mesin BTS itu sendiri. Alarm ini memudahkan user dalam hal ini teknisi ahli untuk menganalisa masalah dan melakukan troubleshooting untuk memperbaiki masalah yang terjadi.

Saat ini sistem yang ada pada salah satu perusahaan penyedia layanan jaringan telekomunikasi untuk menginformasikan alarm yang terjadi pada mesin BTS adalah dengan cara teknisi yang melakukan shift kerja dengan kurun waktu 24 jam untuk memonitoring alarm pada Span Line Interface yang terjadi dalam sebuah aplikasi Alarm Management System kemudian apabila alarm yang muncul masuk kategori critical alarm maka harus menginformasikan alarm tersebut ke teknisi ahli untuk melakukan troubleshooting. Sistem yang dijalankan saat ini sangat manual dan tergantung pada kemampuan teknisi yang berbeda-beda, juga resiko kesalahan yang dilakukan teknisi. Karena keterbatasan itulah yang menyebabkan para teknisi cukup kesulitan untuk melakukan troubleshooting dengan cepat karena harus melakukan proses pelaporan dulu ke teknisi ahli. Untuk menangani masalah ini, dibutuhkan suatu sistem yang merangkum seluruh jenis alarm, dapat membantu proses diagnosis menentukan jenis alarm yang terjadi, serta dapat memberikan solusi troubleshooting yang tepat dan efektif bagi tiap-tiap jenis alarm. Sistem Pakar merupakan salah satu cabang kecerdasan buatan yang mengalihkan keahlian seorang pakar/ahli ke dalam suatu program komputer untuk dialihkan kembali ke pengguna. Kajian pokok dalam sistem pakar adalah bagaimana mentransfer pengetahuan yang dimiliki oleh seorang pakar ke dalam komputer, dan bagaimana membuat keputusan atau mengambil kesimpulan berdasarkan pengetahuan itu. Dengan menyimpan informasi dan digabungkan dengan himpunan aturan penalaran yang memadai memungkinkan komputer memberikan kesimpulan atau mengambil keputusan seperti seorang pakar. Dengan adanya hal tersebut maka dapat dimungkinkan diterapkannya sebuah aplikasi sistem pakar berbasis web untuk alarm gangguan BTS, sehingga dapat digunakan oleh teknisi. Maka sebagai bahan penelitian untuk tugas akhir ini, penulis mengangkat judul: PERANCANGAN SISTEM PAKAR ALARM GANGGUAN BASE TRANSCEIVER STATION BERBASIS WEB.

1.2

Identifikasi Masalah Sebagaimana telah dibahas dalam latar belakang diatas, maka diidentifikasi sejumlah masalah yang ditemui dalam Tugas Akhir ini antara lain: 1. 2. Adanya kesulitan dalam menemukan informasi mengenai penyebab munculnya alarm pada Span Line Interface oleh teknisi. Teknisi cukup membutuhkan waktu dan proses untuk penanganan gangguan yang terjadi pada mesin BTS setelah alarm muncul, karena alarm yang muncul pada Span Line Interface yang di kategorikan Critical Alarm biasanya harus ada penanganan khusus terlebih dahulu oleh teknisi ahli yang berada di Centralized Base Station Controller (CBSC) Jakarta.

1.3

Tujuan Tujuan penelitian tugas akhir ini adalah merancang suatu sistem pakar yang

memiliki kemampuan untuk merangkum jenis-jenis alarm BTS, dan mampu memberikan solusi terhadap alarm gangguan, yang harus dilakukan oleh teknisi. 1.4 Batasan Masalah Batasan masalah pada Tugas Akhir ini antara lain : 1. Jumlah sampel jenis alarm yang digunakan pada tugas akhir ini sebanyak 15 jenis, yang terdiri dari 5 jenis minor alarm, 5 jenis major alarm dan 5 jenis critical alarm . 2. 3. Teknologi yang dibahas pada tugas akhir ini, hanya mengenai alarm pada mesin BTS. Pada pembahasan masalah tidak diikutsertakan tentang analisis perkiraan 4. biaya yang diperlukan untuk perancangan dan pengembangan sistem. Perangkat lunak tidak dirancang untuk memiliki kemampuan belajar sendiri, artinya sistem pakar ini tidak dapat menambah sendiri pengetahuannya selama interaksinya dengan pemakai.

5.

Bahasa pemrograman yang digunakan sebagai pembangun sistem adalah PHP dan untuk pengolahan basis datanya digunakan software Microsoft MySQL.

6.

Pengembangan sistem pakar hanya dilakukan sampai pada tahap simulasi implementasi sistem pakar.

1.5

Metodologi Penelitian Metodologi penelitian yang dilakukan terdiri dari tahap pengumpulan data dan tahap pengembangan sistem. Untuk tahap pengembangan sistem, metodologi yang digunakan adalah ESDLC (Expert System Development Life Cycle), suatu metode siklus pengembangan untuk sistem pakar. a. Tahap Pengumpulan Data Tahap pengumpulan data terdiri dari pengumpulan data primer dan pengumpulan data sekunder. 1. Pengumpulan data primer, yakni pengumpulan data dilakukan dengan mewawancarai para teknisi network. Selain wawancara, pengumpulan data primer juga dilakukan dengan studi pustaka dari beberapa literatur yang mendukung. 2. Pengumpulan data sekunder, dilakukan dengan penelusuran kepustakaan melalui internet dan informasi-informasi lain yang menunjang.

b. Tahap Pengembangan Sistem Tahap 1 Penilaian Kebutuhan Tahap 2 Akuisisi Pengetahuan Pengetahuan Tahap 3 Perancangan Struktur Tahap 4 Pengujian Evaluasi Tahap 5 Dokumentasi Produk Tahap 6 Pemeliharaan Gambar 1.1 Tahap Pengembangan Sistem Pakar (Durkin, 1994) 1. Penilaian (Assessment) Merupakan proses untuk menentukan kelayakan dan jastifikasi atas permasalahan yang akan diambil. Setelah itu masalah diperiksa lebih lanjut untuk menentukan tujuan keseluruhan dari proyek. Upaya ini dilakukan untuk menentukan fitur-fitur penting dan ruang lingkup dari proyek, dan juga untuk menetapkan sumber daya yang diperlukan termasuk proyek personal. Sumber pengetahuan yang diperlukan, termasuk diantaranya para pakar dan juga berbagai laporan harus diidentifikasi. Setelah tahap inisialisasi dilakukan persyaratan-persyaratan proyek harus ditetapkan. Eksplorasi Formulasi ulang

Perbaikan

2.

Akuisisi Pengetahuan (knowledge acquisition) Proses ini meliputi bagaimana suatu pengetahuan didapatkan, kemudian diorganisisir dan dipelajari. Pada tahap ini pula melibatkan pertemuan dengan pakar dimana beberapa aspek dibahas. Pada tahap awal meliputi materi yang dibahas secara umum. Tujuannya adalah untuk mengungkap konsep-konsep kunci dan metode pemecahan masalah umum yang digunakan oleh pakar. Sesi selanjutnya mengambil keuntungan dari informasi yang diperoleh dari pengujian sistem untuk mengeksplorasi untuk informasi lebih lanjut.

3.

Perancangan (Design) Setelah tahap akuisisi pengetahuan, wawasan diperoleh pada pendekatan yang terbaik untuk merepresentasikan pengetahuan ahli dan strategi pemecahan masalah dalam sistem pakar. Selama fase perancangan, struktur dan organisasi pengetahuan sistem secara keseluruhan didefinisikan. Metode juga didefinisikan untuk memproses pengetahuan. Sebuah perangkat lunak dipilih yang dapat mewakili dan alasan dengan sistem pengetahuan dalam cara yang mirip dengan pendekatan yang diambil oleh ahli manusia. Selama fase perancangan, sistem prototype awal dibangun. Tujuan dari prototype ini adalah untuk menyediakan kendaraan untuk mendapatkan pemahaman yang lebih baik dari masalah. Dengan bangunan pertama sistem kecil, dan meninjau hasil tes dengan ahli domain, wawasan diperoleh ke dalam persyaratan sistem tambahan. Prototype ini juga berfungsi sebagai titik fokus untuk wawancara lebih lanjut dengan ahli.

4.

Pengujian (Testing) Merupakan tahap uji coba kesesuaian perancangan sistem pakar dengan kebutuhan yang telah diinisialisasi pada tahap penilaian.

5.

Dokumentasi (Documentation) Fase dokumentasi memenuhi kebutuhan untuk mengkompilasi semua proyek informasi ke dalam dokumen yang dapat memenuhi persyaratan baik pengguna dan pengembang mensyaratkan sistem bahwa pakar. Mengakomodasi pengguna

dokumentasi yang memenuhi persyaratan ditemukan di sebagian besar proyek perangkat lunak. 6. Pemeliharaan (Maintenance) Setelah sistem ditempatkan di lingkungan kerja, itu perlu dirawat secara berkala. Seperti anak kecil, sistem pakar terus tumbuh dan belajar. Pengetahuan tidak statis, itu tumbuh, berkembang, dan sifat. sistem pengetahuan yang mungkin perlu diperbaiki atau diperbaharui untuk memenuhi kebutuhan saat ini. Perubahan kebutuhan sistem utama juga dapat terjadi yang akan membutuhkan reformulasi spesifikasi sistem.

1.6

Kerangka Pemikiran Dalam penyusunan tugas akhir ini, jenis solusi yang ditawarkan adalah pembangunan aplikasi sistem pakar alarm gangguan BTS melalui media internet sehingga memudahkan teknisi dan teknisi ahli dalam menggunakan aplikasi ini. Dalam proses pengembangannya penulis memberikan beberapa tahapan dalam pengembangan sistem ini, seperti berikut ini:

Penilaian (Assessment) Kegiatan penelitian

Observasi lapangan (Konsultasi dgn pakar)

Studi pustaka Kegiatan analisis

Penelitian mengenai alarm gangguan BTS

Akuisisi Pengetahuan Analisis kebutuhan sistem pakar alarm gangguan BTS Desain

Representasi pengetahuan

Pengembangan mesin inferensi

Desain kebutuhan sistem pakar alarm gangguan BTS

Compile

Implementasi

Di compile ke dalam bahasa yang dimengerti oleh komputer

Sistem pakar alarm gangguan BTS

Gambar 1.2 Proses Perancangan Aplikasi Sistem Pakar

1.7

Sistematika Penulisan BAB I PENDAHULUAN Pada Bab ini penulis menyajikan alasan bagaimana perancangan sistem pakar untuk Alarm Gangguan BTS. Dimana perancangan ini dibuat untuk memberikan kemudahan teknisi agar dapat melakukan troubleshooting sendiri tanpa harus melakukan laporan terlebih dahulu ke teknisi ahli dalam sebuah kerangka pemikiran yang disajikan dengan metodologi penelitian BAB II LANDASAN TEORI Bab ini membahas tentang pengertian konsep sistem pakar, keuntungan sistem pakar dan tahapan pengembangan sistem pakar. Selain itu pula pada bab ini penulis memaparkan tentang BTS dan alarm-alarm kesalahan pada modul BTS. BAB III ANALISIS SISTEM Bab ini membahas tentang analisis terhadap permasalahan BTS . BAB IV DESAIN SISTEM Bab ini berisi perancangan sistem pakar dan implementasi sistem pakar untuk Alarm Gangguan BTS. BAB V KESIMPULAN DAN SARAN Bab ini mendeskripsikan kesimpulan yang didapat dari pembahasan permasalahan dan disajikan pula saran-saran yang untuk dijadikan referensi bagi semua pihak dalam pengembangan selanjutnya.

BAB II LANDASAN TEORI 1. 2. 2.1 D Kecerdasan Buatan Kecerdasan buatan adalah cabang ilmu komputer yang bertujuan untuk membuat sebuah komputer dapat berfikir dan bernalar seperti manusia (Durkin, 1994). Tujuan dari kecerdasan buatan ini adalah membuat komputer semakin berguna bagi manusia. Kecerdasan buatan dapat membantu meringankan beban kerja manusia, misalnya dalam membuat keputusan, mencari informasi secara lebih akurat, atau membuat komputer lebih mudah digunakan dengan tampilan yang mudah dipahami. Cara kerja artificial intelegence adalah menerima input untuk kemudian diproses dan mengeluarkan output yang berupa suatu keputusan. Adapun ruang lingkup dari kecerdasan buatan ini terdiri dari : 1. 2. 3. 4. 5. 6. Robotika Pengenalan suara (speech recognition) Sistem syaraf tiruan Sistem pakar Pengenalan pola Pengolahan bahasa alami Dari beberapa ruang lingkup kecerdasan buatan, bidang sistem pakar merupakan penyelesaian pendakatan yang sangat berhasil/bagus untuk permasalahan kecerdasan buatan dari pemrograman intelegent (cerdas) Professor Edward Feigenbaum (1982) dari Universitas Stanford yang meurpakan seorang pelopor awal dari teknologi sistem pakar, yang mendefinisikan sistem pakar sebagai suatu program komputer cerdas yang menggunakan knowledge (pengetahuan) yang prosedur inferensi untuk menyelesaikan masalah yang cukup sulit sehingga membutuhkan seorang yang ahli untuk menyelesaikannya (Arhami, 2005).

68

2.2 2.2.1

Sistem Pakar Pengertian Sistem Suatu system adalah suatu jaringan kerja dari prosedur-prosuder yang saling berhubungan, berkumpul bersama-sama untuk melakukan suatu kegiatan atau untuk menyelesaikan suatu sasaran tertentu. (Hartono, 1999) Sistem adalah kumpulan dari elemen-elemen yang saling berinteraksi untuk mencapai suatu tujuan tertentu. (Hartono, 1999) Pengertian system yang pertama lebih menekankan pada prosedur,

sedangkan pengertian system yang kedua lebih menekankan pada komponen atau elemennya. Tetapi kedua pengertian atau definisi dari system ini adalah benar dan tidak bertentangan, yang berbeda adalah cara pendekatannya. Karena pada hakekatnya setiap komponen system, untuk dapat saling berinterkasi dan untuk dapat mencapai tujuan tertentu harus melakukan sejumlah prosedur, metode, dan cara kerja yang juga saling berinteraksi. Suatu system dapat tersiri atas satu atau lebih input, yang kemudian di proses mengahasilkan satu atau lebih output. Input yang dimasukan berupa data dan data output yang dihasilkan berupa informasi. Secara umum model suatu system dapat digunakan sebagai berikut:

INPUT

PROSES

OUTPUT

STORAGE

Gambar 2.1 Model Umum Suatu Sistem Secara Sederhana (Amsyah, 2000)

2.2.2

Karakteristik Sistem Interface

Lingkungan Luar

Sub Siste m Boundary Sub Siste m

Sub Siste m

Sub Siste m

Boundary

Input

Process

Output

Boundary

Gambar 2.2 Karakteristik Suatu Sistem (Hartono, 1999) Suatu sistem mempunyai karakteristik atau sifat-sifat tertentu yaitu (Hartono, 1999): a. Komponen Sistem (Component) Suatu sistem terrdiri dari sejumlah sistem yang saling berinteraksi, yang artinya saling kerjasama membentuk satu kesatuan.

b. Batas Sistem (Boundary) Merupakan daerah yang membatasi antara satu sistem dengan sistem yang lainnya dengan lingkungan luarnya. c. Lingkungan Luar Sistem (Environments) Apapun diluar dari batas sistem yang mempengaruhi operasi. d. Penghubung (Interface) Merupakan media penghubung antara sub sistem dengan sistem lainnya. e. Masukan Sistem (Input) Adalah energy yang dimasukan ke dalam sistem. Masukan dapat berupa masukan perawatan (maintenance input) yaitu energi yang dimasukan supaya sistem dapat beropasi, dan dapat berupa masukan sinyal (signal input) yaitu energy yang diproses untuk mendapatkan keluaran. f. Keluaran Sistem (Output) Adalah hasil dari energy yang diolah dan diklasifikasikan menjadi keluaran yang berguna dari sistem pembuangan. g. Pengolahan Sistem (Process) Suatu sistem dapat mempunyai bagian pengolah yang akan mengubah masukan menjadi keluaran. h. Sasaran Sistem (Objective) Suatu sistem mempunyai tujuan (goal) atau sasaran (objective). 2.2.3 Definisi Pakar Pakar adalah seorang individu yang memiliki pengetahuan khusus, pemahaman, pengalaman, dan metode-metode yang digunakan untuk memecahkan masalah persoalan dalam bidang tertentu. Seorang pakar memiliki kemampuan kepakaran, yaitu (Kusrini, 2006): a. Dapat mengenali dan merumuskan suatu masalah. b. Menyelesaikan masalah dengan cepat dan tepat. c. Menjelaskan suatu solusi dari suatu masalah.

d. Restrukturisasi pengetahuan. e. Belajar dan pengalaman. f. Memahami batas kemampuan. Selain itu, pakar juga memiliki kemampuan untuk mengaplikasikan pengetahuannya dan memberikan saran serta pemecahan masalah pada domain tertentu. Ini merupakan pekerjaan pakar, memberikan pengetahuan tentang bagaimana seseorang melaksanakan tugas untuk menyelesaikan masalah. Penyelesaian masalah ini didukung atau bahkan secara ekstrim akan dilaksanakan oleh system berbasis pengetahuan/system pakar. Seorang pakar mengetahui faktafakta mana yang penting, sebab dan akaibat, fenomena-fenomena yang terkait serta mampu menginterprestasikan akibat-akibat yang terjadi karena sesuatu sebab terjadi. Pada kasus diagnosis masalah system elektronik mobil misalnya, pakar mekanik mengetahui tali kipas dapat rusak dan sebab kekosongan baterai. Seseorang akan langsung mengecek tali kipas dan menginterpretasikan arti dari lepas atau hilangnya tali dengan akibat-akibat yang ditimbulkannya. Ini adalah sebuah contoh keahlian. Jika digunakan lebih dari satu pakar, situasi akan menjadi sulit jika para pakar saling tidak setuju. Perlu ada kesepakatan antar pakar dalam menyelesaikan permasalahan (Kusrini, 2006). 2.2.4 Pengenalan Sistem Pakar Sebagaimana disebutkan sebelumnya bahwa sistem pakar adalah sebuah program komputer yang di desain untuk menggantikan seorang pakar di bidang tertentu. Ada dua hal penting yang perlu diadopsi dari seorang pakar dalam membangun sebuah sistem pakar, yaitu : pengetahuan (knowledge) seorang pakar dan konsep berfikir (reasoning) seorang pakar. Untuk menghasikan kedua hal tersebut, sebuah sistem pakar harus memiliki dua modul diantaranya : sebuah basis pengetahuan (knowledge base) dan sebuah mesin inferensi (inference engine). (Durkin, 1994).

Sistem pakar (expert system) adalah sistem yang berusaha mengadopsi pengetahuan manusia ke komputer, agar komputer dapat menyelesaikan masalah seperit yang biasa dilakukan oleh para ahli. (Kusumadewi, 2003). Basis pengetahuan berisi pengetahuan yang sangat spesifik dalam sebuah permasalahan tertentu seperti yang dimiliki seorang pakar. Meliputi permasalahan fakta-fakta, aturan-aturan, konsep dan hubungan. Sebagai contoh, mungkin ini berisi pengetahuan yang dimiliki seorang dokter untuk mendiagnosa penyakit. Mesin inferensi adalah sebuah mesin pemroses pengetahuan yang dimodelkan atas konsep berfikir dan bernalar seoarang pakar. Mesin inferensi beserta informasi yang didapat dari sebuah masalah, berpasangan dengan pengetahuan yang disimpan pada basis pengetahuan, untuk mendapatkan kesimpulan atau saran. (Durkin, 1994). Keterhubungan antara basis pengertahuan dan mesin inferensi pada suatu sistem pakar digambarkan pada Gambar 2.3. Sistem Pakar Basis pengetahuan Mesin inferensi

Gambar 2.3 Blok Diagram Sistem Pakar Kehadiran ahli adalah sebuah sumber daya yang berharga bagi suatu organissi. Mereka dapat memberikan ide yang kreatif, solusi untuk solusi yang sulit, atau melakukan tugas rutin secara efisien. Kontribusi mereka dapat meningkatkan produksi suatu organisasi, dimana peningkatan ini dapat meningkatkan posisi kompetisi organisasi dalam pasar. Keahlian manusia tidak bersifat kekal. Melalui kematian, pensiun, atau peralihan kerja sebuah organisasi dapat menghilangkan kemampuan seorang ahli. Sebuah sistem pakar menghasilkan banyak hasil yang tetap dibandingkan kepakaran seorang manusia. Keputusan seorang manusia dipengaruhi banyak faktor yang mungkin berpengaruh buruk pada hasil keputusan. (Durkin, 1994).

Oleh karena keterbatasan kepakaran manusia, maka adanya sistem pakar di bidang tertentu akan sangat berguna. Ada dua tujuan utama pengembangan sebuah sistem pakar, yaitu untuk menggantikan kerja seorang pakar atau membantu kerja seorang pakar. Tabel 2.1 memperlihatkan perbandingan antara kepakaran seorang manusia dan sistem pakar. Tabel 2.1 Perbandingan Kepakaran Manusia dan Sistem Pakar Faktor Ketersediaan waktu Geografis Keamanan Kemungkinan hilang Kinerja Kecepatan Biaya Kepakaran Manusia Setiap hari Lokal Tidak bisa digantikan Ya Berubah-ubah Berubah-ubah Mahal Sumber : (Durkin, 1994) 2.2.5 Tujuan Sistem Pakar Tujuan dari sebuah sistem pakar adalah untuk mentransfer kepakaran yang dimiliki seorang pakar ke dalam komputer, dan kemudian kepada orang lain (nonexpert). Aktivitas yang dilakukan untuk memindahkan kepakaran adalah: 1. Knowledge acquisition (dari pakar atau sumber lainnya) 2. Knowledge representation (ke dalam komputer) 3. Knowledge inferencing 4. Knowledge tranferring (Arhami, 2005) Sistem Pakar Setiap saat Biasa dimana saja Bisa digantikan Tidak Tetap Tetap (selalu tercepat) Lebih murah

2.2.6

Ciri dan Karakteristik Sistem Pakar Menurut Jogiyanto (2003) ada berbagai ciri yang membedakan sistem

2.2.6.1 Ciri Sistem Pakar pakar dengan sistem lain yang dapat dijadikan sebagai pedoman utama dalam pengembangan sistem pakar, diantaranya : 1. Pengetahuan sistem pakar merupakan suatu konsep, bukan berbentuk numeris. Hal ini dikarenakan komputer melakukan proses pengolahan data secara numerik sedangkan keahlian dari seorang pakar adalah fakta dan aturan-aturan, bukan numerik. 2. Informasi dalam sistem pakar tidak selalu lengkap, suyektif, tidak konsisten, subyek terus berubah dan tergantung pada kondisi lingkungan sehingga keputusan yang diambil bersifat tidak pasti dan tidak mutlak ya atau tidak akan tetapi menurut ukuran kebenaran tertentu. Oleh karena itu dibutuhkan kemampuan sistem untuk belajar secara mandiri dalam menyelesaikan masalah-masalah dengan pertimbangan-pertimbangan khusus. 3. Kemungkinan solusi sistem pakar terhadap suatu permasalahan adalah bervariasi dan mempunyai banyak pilihan jawaban yang dapat diterima, semua faktor yang ditelusuri memiliki ruang masalah yang luas dan tidak pasti. Oleh karena itu diperlukan fleksibilitas sistem dalam menangani kemungkinan solusi dari berbagai permasalahan. 4. Perubahan atau pengembangan pengetahuan dalam sistem pakar dapat terjadi setiap saat bahkan sepanjang waktu sehingga diperlukan kemudahan dalam modifikasi sistem untuk menampung jumlah pengetahuan yang semakin besar dan semakin bervariasi. 5. Pandangan dan pendapat setiap pakar tidaklah selalu sama, yang oleh karena itu tidak ada jawaban bahwa solusi sistem pakar merupakan jawaban yang pasti benar. Setiap pakar akan memberikan pertimbangan-pertimbangan berdasarkan faktor subyektif. 6. Keputusan merupakan bagian terpenting dari sistem pakar. Sistem pakar harus memberikan solusi yang akurat berdasarkan masukan pengetahuan

meskipun solusinya sulit sehingga fasilitas informasi sistem harus selalu diperlukan. 2.2.6.2 Karakteristik Sistem Pakar Salah satu fitur yang harus dimiliki oleh sistem pakar adalah kemampuan untuk menalar (reasoing). Jika keahlian-keahlian sudah tersimpan sebagai basis pengetahuan dan sudah tersedia program yang mampu mengakses basis data, maka komputer harus dapat diprogram untuk membuat inferensi. Proses ini dibuat dalam bentuk motor inferensi (inference engine). Menurut Turban (1995), terdapat tiga orang yang terlibat dalam lingkungan sistem pakar, yaitu: 1. Pakar Pakar adalah orang yang memiliki pengetahuan khususnya pendapat, pengalaman dan metode, serta kemampuan untuk mengaplikasikan keahliannya tersebut guna menyelesaikan masalah. 2. Knowledge engineer (Perekayasa Sistem) Knowledge engineer adalah orang yang membantu pakar dalam menyusun area permasalahan dengan menginterpretasikan dan mengintegrasikan jawaban-jawaban pakar atas pertanyaan yang diajukan, menggambarkan analogi, mengajukan kesulitan konseptual. 3. Pemakai Sistem pakar memiliki beberapa pemakai, yaitu: pemakai bukan pakar, pelajara, pembangun sistem pakar yang ingin meningkatkan dan menambah basis pengetahuan, dan pakar. Menurut (Turban, 1995) sistem pakar disusun oleh dua bagian utama, yaitu lingkungan pengembangan (development environment) dan lingkungan konsultasi (consultation environment). Lingkungan pengembangan digunakan untuk memasukkan pengetahuan pakar ke dalam lingkungan sistem pakar, sedangkan lingkungan konsultasi digunakan utnuk pengguna yang bukan pakar counter example dan menerangkan kesulitan-

untuk memperoleh pengethauan pakar. Komponen-komponen sistem pakar dalam kedua bagian tersebut dapat terlihat pada Gambar 2.4 berikut ini:

Gambar 2.4 Arsitektur Sistem Pakar (Sumber : Turban, 1995) Komponen-komponen yang terdapat dalam sistem pakar adalah seperti yang terdapat pada Gambar 2.4 diatas yaitu, user interface (antarmuka pengguna), basis pengetahuan, akuisisi pengetahuan, mesin inferensi, workplace, fasilitas penjelasan, perbaikan pengetahuan. (Arhami, 2005). 2.2.7 Perbandingan Sistem Konvensional dan Sistem Pakar Berikut ini merupakan perbandingan antara sistem konvensional dan sistem pakar (Durkin, 1994) : Tabel 2.2 Perbandingan sistem konvensional dan sistem pakar Sistem konvensional Fokus pada solusi Programer bekerja sendiri Pengembangan sequential Sistem pakar Fokus pada masalah Dikerjakan secara tim Pengembangan iterative

2.2.8

Pengelompokkan Sistem Pakar Selain berdasarkan area permasalahan, sistem pakar juga dapat

dikelompokkan berdasarkan paradigma pemecahan masalah. Kemampuan pakar sebagai kumpulan umum sebuah tugas ketika memecahkan beberapa jenis permasalahan seperti diagnosis atau perencanaan. Pengelompokkan tersebut antara lain: 1. Kontrol (Control) Dengan tujuan untuk mengatur perilaku kerja sistem dalam suatu lingkungan yang kompleks, termasuk didalamnya adalah penafsiran, perkiraan, pengawasan dan perbaikan perilaku kerja sistem tersebut. Contoh : kontrol terhadap proses manufacturing lengkap. 2. Desain (Design) Dengas tujuan untuk menentukan konfigurasi yang cocok dari komponenkomponen yang ada pada sebuah sistem sehingga diperoleh kemampuan kerja yang memuaskan walaupun terdapat keterbatasan didalamnya. Contoh : layout circuit. 3. Diagnosa (Diagnosis) Dengan tujuan untuk melakukan diagnosa yeng menentukan sebab-sebab gagalnya suatu sistem dalam situasi kompleks yang didasarkan pada pengamatan terhadap gejala-gejala yang diamati. Prinsipnya adalah untuk menemukan apa masalah atau kerusakan yang terjadi. Contoh : computer troubleshooting. 4. Instruksi (Instruction) Dengan tujuan untuk mendeteksi dan memperbaiki kekurangan perilaku siswa dalam memahami bidang informasi tertentu. Contoh : program tutorial. 5. Interpretasi (Interpretation) Dengan tujuan menganalisa data yang tidak lengkap, tidak teratur dan data yang kontradiktif yang biasanya diperoleh melalui sensor. Contoh : analisis citra.

6.

Pengamatan (Monitoring) Dengan tujuan membandingkan perilaku yang diamati dalam suatu sistem dengan perilaku yang diharapkan untuk mengenal variasi perilaku yang terdapat didalamnya. Contoh : kontrol instalasi nuklir.

7.

Perencanaan (Planning) Dengan tujuan untuk mendapatkan tahapan secara urut dari tindakan yang harus dilakukan untuk mencapai sasaran yang ditetapkan sebelumnya dari suatu kondisi awal tertentu. Contoh : lengan robot yang dapat memindahkan lima balok dengan susunan tertentu dari susunan asal yang acak.

8.

Prediksi (Prediction) Dengan tujuan untuk memberikan kesimpulan mengenai akibat atau efek yang mungkin terjadi dari sejumlah alternatif situasi yang diberikan. Contoh: financial forecasting.

9.

Prekripsi Dengan tujuan untuk memberikan rekomendasi solusi untuk suatu kondisi malfungsi sistem yang diberikan.

10. Seleksi (Selection) Dengan tujuan untuk mengidentifikasi pilihan yang terbaik atau yang paling cocok dari sebuah daftar kemungkinan dengan memberikan kriteria-kriteria tertentu. 11. Simulasi (Simulation) Dengan tujuan untuk membuat suatu model atas sebuah sistem atau proses yang memiliki banyak kemungkinan solusi. (Durkin, 1994). 2.2.9 Sistem Pakar Berbasis Aturan Pengertian dari sistem pakar berbasis aturan adalah suatu program komputer yang dapat menganalisis informasi tertentu pada memori dengan menggunakan kumpulan aturan pada basis pengetahuan dan menggunakan mesin inferensi sebagai pencarian informasi dengan tujuan memperoleh informasi baru (Durkin, 1994). Sistem pakar berbasis aturan merupakan pilihan utama dalam membangun sebuah sistem pakar.

Konsep dari sistem pakar berbasis aturan adalah mengkombinasikan suatu situasi permasalahan baru di short-term memory dengan produksi dari long-term memory sehingga menghasilkan suatu informasi baru yang disimpan di short-term memory.
Long-term memory (Produksi) Short-term memory (Situasi) aksi situasi

Penalaran

Gambar 2.5 Model Sistem Produksi Sebuah sistem pakar berbasis aturan meniru cara penalaran manusia ini dengan cara sebagai berikut: 1. 2. 3. Meniru long-term memory manusia dengan basis pengetahuan yang berisi seperangkat aturan. Meniru short-term memory manusia dengan memori kerja yang berisi faktafakta baik yang diinputkan maupun hasil inferensi dari aturan. Meniru cara penalaran manusia dengan mesin inferensi yang akan memproses fakta-fakta dari memori kerja dengan menggunakan aturan-aturan yang ada di basis pengetahuan. (Durkin, 1994) 2.2.10 Arsitektur Sistem Pakar Berbasis Aturan Sebuah sistem pakar berbasis aturan terdiri dari tiga modul utama, yaitu : basis pengetahuan, memori kerja dan mesin inferensi yang merupakan jantung dari sebuah sistem pakar dan bagian lainnya diluar ketiga komponen utama yang juga sangat penting diantaranya : antarmuka pemakai, pengembang antarmuka, fasilitas penjelasan dan program eksternal (Durkin, 1994). Arsitektur sistem pakar berbasis aturan dapat dilihat pada Gambar 2.6.

Mesin inferensi

Memori kerja

Fasilitas penjelasan

Basis pengetahuan

Program eksternal

Antarmuka pemakai

Pengembangan antarmuka

Pemakai

Pengembang sistem

Gambar 2.6 Arsitektur sistem pakar berbasis aturan (Durkin, 1994). Keterangan Gambar 2.6 : 1. Basis pengetahuan adalah suatu struktur data yang menyimpan informasi data, aturan, relasi antara data dengan aturan dalam pengambilan kesimpulan. Basis pengetahuan dapat dikatakan sebagai kumpulan informasi dan pengalaman seorang ahli pada suatu bidang tertentu. Basis pengetahuan ini terdiri dari dua elemen dasar, yaitu fakta dan aturan. Setiap kasus yang ditemui, diproses berdasarkan pengalaman yang pernah tercatat, baru dapat diambil kesimpulan. Apabila terjadi suatu kasus yang belum pernah dialami, maka sistem pakar tidak mampu mengambil kesimpulan dari kasus tersebut. Untuk itu diperlukan penambahan data baru yang dapat dijadikan acuan yang melengkapi basis pengetahuan. Jadi, suatu basis pengetahuan dapat dikatakan baik apabila memiliki sejumlah aturan yang bisa digunakan dalam setiap kemungkinan kasus dalam ruang lingkup tertentu. Dalam perancangannya, perancang harus mampu menggali sebanyak mungkin informasi dari narasumbernya dan memindahkannya ke dalam basis pengetahuan.

Berdasarkan dari basis pengetahuan yang dimilikinya, sistem pakar dapat digolongkan menjadi 5 tingkatan, yaitu : a. Tingkat 1 : b. Menggunakan basis pengetahuan internal. Dapat melakukan penambahan data dan membuat laporan data yang ada pada basis pengetahuan. Menggunakan metode backward chaining atau metode forward chaining untuk menyelesaikan suatu kasus. Mampu menampilkan hasil kerja dari mesin inferensi melalui antarmuka pemakai. Tingkat 2 : c. d. e. Menggunakan basis pengetahuan eksternal. Mampu memilih metode backward chaining atau forward chaining yang akan digunakan untuk menyelesaikan suatu kasus. Mampu melakukan perhitungan matematis. Mampu melakukan ekspor atau impor suatu basis pengetahuan. Mampu melakukan perhitungan matematis secara dinamis. Dapat dioperasikan pada berbagai sistem operasi. Mampu merubah atau menambah isi basis pengetahuan secara otomatis dan mempelajari suatu pola baru dari beberapa kasus yang pernah dialaminya. 2. Mesin inferensi merupakan otak dari sistem pakar yang mengandung mekanisme fungsi berpikir dan pola-pola penalaran sistem yang digunakan oleh seorang pakar. Mesin inferensi bertindak sebagai pengambil kesimpulan dan mengkontrol mekanisme dari sistem pakar. Karena itu mesin inferensi merupakan bagian terpenting dari sistem pakar, karena sangat berperan Tingkat 3 :

Tingkat 4 : Tingkat 5 :

penting dalam menentukan efektivitas dan efisiensi sistem pakar. Mesin inferensi melakukan proses pengambilan kesimpulan atau solusi yang terbaik (baik keputusan intermediate maupun keputusan final) berdasarkan suatu kumpulan aturan tertentu, untuk sekumpulan fakta-fakta yang spesifik, pada suatu situasi tertentu. Seperti halnya basis pengetahuan, mesin inferensi juga terdiri dari aturanaturan dan fakta-fakta, bedanya apabila di dalam basis pengetahuan, aturanaturan dan fakta-fakta yang ada berisi sebuah domain yang spesifik dari sifatsifat seorang pakar. Sedangkan aturan-aturan dan fakta-fakta pada mesin inferensi, berisi tentang kontrol secara umum dan strategi pencarian kesimpulan yang dilakukan oleh sistem pakar. Kedua jenis aturan-aturan dan fakta-fakta ini disimpan secara terpisah dalam sistem pakar. Pemisahan kedua jenis aturan-aturan dan fakta-fakta tersebut memiliki beberapa keuntungan, yaitu pertama, memudahkan untuk melakukan perubahan dalam basis pengetahuan tanpa berimbas banyak pada mesin inferensi dan sebaliknya. Kedua, berguna untuk pengembangan dan komponen-komponen lainnya yang terdapat pada sistem pakar (terkecuali basis pengetahuan). 3. 4. Memori kerja merupakan tempat penyimpanan fakta-fakta yang diketahui dari hasil menjawab pertanyaan. Pemakai (user)/antarmuka pemakai (user interface) merupakan apa yang ditampilkan di hadapan user, jadi melalui user interface-lah, user dapat melakukan interaksi dengan sistem, yaitu dengan memasukkan input dan menerima output. Karena itu, perancangan user interface haruslah memenuhi prinsip user friendly, yaitu mudah digunakan oleh user dan sejelas mungkin agar tidak terjadi adanya salah interpretasi. Pengembang akan berhadapan dengan editor dan source code waktu mengembangkan program. 5. 6. Fasilitas penjelasan memberikan penjelasan kepada user mengenai alasan yang diberikan dari solusi. Program eksternal. Berbagai program seperti database, spreadsheets, algoritma dan lainnya yang berfungsi untuk mendukung sistem.

2.3 2.3.1

Representasi Pengetahuan Definisi Representasi Pengetahuan Sebuah metode yang digunakan untuk meng-kodekan basis pengetahuan

dalam sebuah sistem pakar. (Durkin, 1994). Representasi dimaksudkan untuk menangkap sifat-sifat penting dan membuat informasi itu dapat diakses oleh prosedur pemecahan masalah. (Kusrini, 2008). Representasi pengetahuan merupakan kombinasi sistem berdasarkan dua elemen, yaitu struktur data dan penafsiran prosedur untuk digunakan pengetahuan dalam menyimpan struktur data. (Arhami, 2005). 2.3.2 Model Representasi Pengetahuan Object dapat berupa bentuk fisik atau konsep dan attribute adalah karakteristik atau sifat dari object tersebut, sedangkan value (Nilai) besaran/nilai/takaran spesifik dari attribute tersebut pada situasi tertentu, dapat berupa numerik, string atau Boolean. Sebuah object bisa memiliki beberapa attribute, biasa disebut OAV multi-attribute (Kusrini, 2006). Contoh representasi pengetahuan dengan OAV ditunjukkan pada Tabel 2.3. Tabel 2.3 Representasi pengetahuan dengan OAV Object Mobil Motor 2.3.2.2 Kaidah Produksi Kaidah menyediakan cara formal untuk merepresentasikan rekomendasi, arahan atau strategi. Kaidah produksi dituliskan dalam bentuk jika-maka (if-then). Kaidan if-then menghubungkan antesenden dengan konsekuensi yang Attribute Roda Roda 4 2 Value

2.3.2.1 Object-Attribute-Value (OAV)

diakibatkannya. Menurut (Adedji, 1992) berbagai struktur kaidah if-the yang menghubungkan obyek atau atribut sebagai berikut: IF premis THEN konklusi IF masukan THEN keluaran IF kondisi THEN tindakan IF antesenden THEN konsekuen IF data THEN hasil IF tindakan THEN tujuan IF aksi THEN reaksi IF sebab THEN akibat IF gejala THEN diagnosa Premis mengacu pada fakta yang harus benar sebelum konklusi tertentu dapat diperoleh. Masukan mengacu pada data yang harus tersedia sebelum keluaran dapat diperoleh. Kondisi mengacu kepada keadaan yang harus berlaku sebelum tindakan dapat diambil. Antesenden mengacu situasi yang terjadi sebelum konsekuen dapat diamati. Data mengacu pada informasi yang harus terjadi sehingga sebuah hasil dapat diperoleh. Tindakan mengacu pada kegiatan yang harus dilakukan sebelum hasil dapat diharapkan. Aksi mengacu pada kegiatan yang menyebabakan munculnya efek dari tindakan tersebut. Sebab mengacu pada keadaan tertentu yang menimbulkan akibat tertentu. Gejala mengacu pada keadaan yang menyebabkan adanya kerusakan atau keadaan tertentu yang mendorong adanya pemeriksaan. (Hartati & Iswanti, 2008). Menurut (Stilling : 1987), Jaringan semantik atau jaringan merupakan teknik representasi AI yang digunakan untuk informasi yang proporsional. Jaringan semantik kadang disebut juga sebagai jaringan proporsitional. Proposition, adalah suatu pernyataan yang dapat bernilai benar atau salah, spesrti pernyataan semua anjing adalah mamalia dan sebuah segitiga mempunyai tiga sisi. Proposisi merupakan bentuk pengetahuan deklaratif karena menyatakan fakta. Dalam matematika, istilah jaringan semantik merupakan suatu label atau graph berarahan.

Struktur dari jaringan semantik ditunjukkan secara grafik yang terdiri dari simpul (node) dan busur (arc) yang menghubungkannya. Simpul menyatakan objek dan busur sebagai link atau edge. Links dari jaringan semantik digunakan untuk menunjukkan hubungan (relationship). Simpul digunakan untuk menggambarkan objek, konsep dan situasi. Salah satu contoh jaringan semantik dapat terlihat pada Gambar 2.7.

Gambar 2.7 Contoh Jaringan Semantik Penjelasan Gambar 2.5 Mother of Father of Wife of Husband of Sister of = ibu dari = ayah dari = istri dari = suami dari = saudara perempuan dari

(Arhami, 2005) 2.3.2.3 Frame (Bingkai) Menurut (Minsky, 1975), Salah satu skema yang telah digunakan dalam banyak aplikasi AI adalah frame. Menurut (Minsky, 1975), frame dapat dipandang sebagai struktur data statistik yang digunakan untuk merepresentasikan situasi-situasi yang telah

dipahami dan stereotipe. Struktur serupa frame seolah-olah mengatur pengetahuan kita tentang dunia sekitar. Kita berpindah ke situasi baru dengan cara memanggil informasi yang dibentuk oleh pengalaman masa lalu kita. Detail pengalaman masa lalu ini kemudian dibentuk atau diubah dengan merepresentasikan pengalaman masa lalu itu dengan merepresentasikan perbedaan-perbedaan individual untuk situasi yang baru ini. Frame berupa kumpulan-kumpulan slot-slot yang merupakan atribut untuk mendeskripsikan pengetahuan. Pengetahuan yang termuat dalam slot dapat berupa kejadian, lokasi, situasi ataupun elemen-elemen lain. Bingkai digunakan untuk representasi pengetahuan deklaratif dengan proses penalaran secara esensial adalah mengkonfirmasikan berbagia harapan (ekspektasi). Sebagai contoh, bingkai berikut ini adalah untuk pohon: Fram Pohon Spesiliasasi dari Jumlah batang Jenis kulit Model daun Bentuk daun (Arhami, 2005). 2.3.2.4 Logika Bagian yang paling penting dari penalaran logika ini adalah mengambil kesimpulan dari model ini adalah untuk mengambil kesimpulan dari premis. Aplikasi komputer untuk melakukan penalaran telah dihasilkan dalam logika pemrograman dan pengembangan bahasa dasar logika seperti PROLOG. Logika juga sangat penting dalam sistgem pakar sebagai mesin penarik kesimpulan dari fakta ke kesimpulan, pada kenyataannya gambaran untuk istilah logika pemrograman dan sistem pakar merupakan sistem penalaran yang otomatis. Pada mulanya logika dikembangkan oleh filosof Yunani Aristoteles pada abad ke 4 sebelum Masehi. Logika Aristoteles didasarkan pada silogisme. Dia : Tumbuhan : Integer (default 1) : Halus : Jenis pohon jarum, berganti daun : Sederhana, berlekuk, campuran

menemukan 14 tipe dan 5 lagi ditemukan pada pertengahan waktu. Silogisme mempunyai dua premis dan satu konklusi yang disimpulkan dari premis. Berikut ini adalaah contoh klasik dari silogisme: Premis Premis Konklusi : Semua laki-laki adalah mahluk hidup : Socrates adalah laki-laki : Socrates adalah mahluk hidup

Dalam silogisme, premis merupakan fakta dari kesimpulan yang harus diikuti. Silogisme adalah salah satu cara merepresentasikan pengetahuan. (Arhami, 2005). 2.4 Inferensi Proses yang digunakan untuk memperoleh informasi baru dari pengetahuan yang telah diketahui dalam sebuah sistem pakar. Inferensi sebuah sistem pakar menggunakan sebuah modul yang dinamakan mesin inferensi. Mesin inferensi merupakan sebuah pemroses yang bekerja dengann informasi yang berjalan untuk memperoleh kesimpulan lebih lanjut. (Durkin, 1994). Gambar 2.8 menunjukkan proses inferensi pada sebuah sistem pakar. Basis pengetahuan -----------------------Aturan Bingkai Mesin inferensi Memory kerja -----------------------Fakta-faktar Gambar 2.8 Proses Inferensi dalam Sebuah Sistem Pakar (Durkin, 1994).

Terdapat dua metode inferensi yang digunakan dalam sistem pakar, yaitu forward chaining dan backward chaining. 2.4.1 Forward Chaining Strategi inferensi yang dimulai dengan sekumpulan fakta-fakta

pengetahuan, memperoleh fakta-fakta baru menggunakan aturan-aturan dimana premis-premis sesuai dengan fakta-fakta pengetahuan, dan meneruskan prosesnya sampai sebuah tujuan yang ditetapkan telah tercapai. (Durkin, 1994). Algoritma forward chaining menurut (Durkin, 1994) digambarkan pada Gambar 2.9.

Gambar 2.9 Proses Forward Chaining

Informasi

Cek dalam basis aturan Cek aturan berikutnya

Benar

Simpan aturan tersebut

Benar

Cek apakah ada aturan yang sesuai

Salah

Cari aturan berikutnya

Salah

Selesai

Gambar 2.10 Algoritma forward chaining (Durkin, 1994). Secara garis besar proses penalaran dengan forward chaining adalah sebagai berikut : 1. Strategi inferensi dimulai dengan diketahui adanya fakta-fakta.

2. 3.

Mendapatkan fakta baru menggunakan aturan-aturan yang premisnya sesuai dengan fakta yang diketahui. Proses tersebut di lanjutkan hingga tujuannya tercapai atau sampai tidak ada lagi aturan yang premisnya sesuai dengan fakta yang ada. Forward chaining adalah penalaran dari fakta menuju konklusi yang

terdapat dari fakta. Pendekatan dimotori data (data-driven). Dalam pendekatan ini pelacakan dimulai dari informasi masukan, dan selanjutnya mencoba menggambarkan kesimpulan. Pelacakan ke depan mencari fakta yang sesuai dengan bagian IF dari aturan IF-THEN. (Arhami, 2005). Dalam penganalisisan masalah, komputer mencari fakta atau nilai yang sesuai dengan syarat pada posisi JIKA dari rule JIKA-MAKA. 2.4.2 Backward Chaining Backward chaining adalah suatu rantai yang dilintasi dari suatu hipotesa kembali ke fakta yang mendukung hipotesa tersebut. Pendekatan dimotori tujuan (goal-driven). Dalam pendekatan ini pelacanan dimulai dari tujuan, selanjutnya dicari aturan yang memiliki tujuan tersebut untuk kesimpulannya. Selanjutnya proses pelacakan menggunakan premis untuk aturan tersebut sebagai tujuan baru dan mencari aturan lain dengan tujuan baru sebagai kesimpulannya. Proses berlanjut sampai semua kemungkinan ditemukan. Gambar 2.11 menunjukkan proses backward chaining.

Gambar 2.11 Proses Backward Chaining (Arhami, 2005) 2.4.3 Karakteristik Forward Chaining dan Backward Chaining Dari kedua penelusuran terdapat karakteristik masing-masing yang membeda satu sama lain. Karakteristik tersebut adalah tersaji dalam Tabel 2.4.

Tabel 2.4 Karakteristik Forward Chaining dan Backward Chaining Forward Chaining Perencanaan, monitoring, kontrol Disajikan untuk masa depan Antecedent ke konsekuen bawah ke atas Bekerja ke depan Backward Chaining Diagnosis Disajikan untuk masa lalu Konsekuen ke antecedent ke bawah untuk Bekerja hipotesis Depth first search dimudahkan Penjelasan difasilitasi ke belakang untuk

Data memandu, penalaran dari Tujuan memandu, penalaran dari atas

mendapatkan solusi apa yang mendapatkan fakta yang mendukung mengikuti fakta Breadth first search dimudahkan Penjelasan tidak difasilitasi (Sumber : Arhami, 2005). 2.5 2.5.1 Basis Data Definisi Basis Data Basis Data terdiri dari 2 kata, yaitu Basis dan Data. Basis kurang lebih dapat diartikan sebagai markas atau gudang, tempat bersarang atau berkumpul. Sedangkan data adalah representasi fakta dunia nyata yang mewakili suatu objek, yang direkam dalam bentuk angka, huruf, symbol, teks, gambar, bunyi atau kombinasinya. Basis data sendiri dapat didefinisikan dalam sejumlah sudut pandang seperti: - Himpunan kelompok data (arsip) yang saling berhubungan yang diorganisasi sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan mudah. - Kumpulan data yang saling berhubungan yang disimpan secara bersama sedemikian rupa dan tanpa pengulangan (redundansi) yang tidak perlu, untuk memenuhi berbagai kebutuhan.

Antecedent menentukan pencarian Consequent menentukan pencarian

- Kumpulan file/tabel/arsip yang saling berhubungan yang disimpan dalam media penyimpanan elektronik. (Kroenke, 2005). 2.5.2 Fungsi dan Perancangan Basis Data Hampir di semua aspek pemanfaatan perangkat komputer dalam sebuah organisasi/perusahaan senantiasa berhubungan dengan basis data. Perangkat komputer adalam suatu organisasi/perusahaan biasanya digunakan untuk menjalankan fungsi Pengelolaan Sistem Informasi, yang sudah menjadi suatu keharusan, demi untuk meningkatkan efisiensi, daya saing, keakuratan, kecepatan operasional organisasi/perusahaan. Dan basis data merupakan salah satu komponen utama dalam setiap sistem informasi. Tidak ada sistem informasi yang bisa dibuat/dijalankan tanpa adanya basis data. Dalam merancang basis data (konvensional), hal-hal yang perlu dilakukan adalah sebagai berikut: Mengidentifikasi bussiness activity Melakukan pemodelan data Melakukan normalisasi Memanipulasi data dengan structured query language (SQL) Melakukan translasi pada perangkat lunak pendukung basis data Sedangkan dalam perancangannya, basis data memerlukan beberapa alat dan pemodelan, diantaranya: Batasan sistem Organization chart Job Description Flow map Block diagram Data flow diagram Kamus data Entity relationship diagram Arsitektur basis data (Tim Pelaksana Praktikum Basis Data, 2010)

2.5.3

Identifikasi Bussiness Activity Pada langkah ini perancang harus mengidentifikasi berbagai aktivitas

yang terjadi pada suatu basis data. Dalam identifikasi ini diperlukan beberapa alat dan pemodelan yang meliputi: a. Batasan sistem Batasan sistem menjelaskan tentang sistem yang akan dirancang. b. Bagan organisasi Bagan organisasi (organization chart) menunjukkan bagaimana departemen-departemen di dalam organisasi di koordinasikan bersamasama melalui suatu jalur wewenang dan tanggung jawab. Bagan organisasi adalah penggambaran secara grafik yang menggambarkan struktur kerja dari suatu struktur organisasi. Bagan organisasi hanya dapat menunjukkan hubungan wewenang yang formal saja dan tidak dapat menggambarkan seberapa besar wewenang, tanggung jawab dan deskripsi pekerjaan yang terinci. c. Deskripsi tugas Deskripsi tugas (job description) merupakan suatu rincian yang menunjukkan posisi, tanggung jawab, wewenang, fungsi dan tugas-tugas yang harus dikerjakan oleh seorang personil di dalam suatu organisasi. Deskripsi tugas perlu dibuat supaya masing-masing personil mengerti kedudukannya di dalam organisasi. d. Deskripsi proses Deskripsi proses merupakan rincian proses yang terjadi di dalam suatu organisasi. Untuk mendeskripsikan proses ini dapat digambarkan dalam grafik dan dapat berupa deskripsi naratif. e. Flow map (bagan alir) Flowmap atau bagan alir adalah bagan yang menunjukkan aliran di dalam program atau prosedur sistem secara logika. Flowmap ini berfungsi untuk memodelkan masukan, keluaran, proses maupun transaksi dengan menggunakan simbol-simbol tertentu. Pembuatan flowmap ini harus dapat memudahkan bagi pemakai dalam memahami alur dari sistem atau

transaksi. Adapun pedoman-pedoman dalam pembuatan flowmap adalah sebagai berikut : o Flowmap sebaiknya digambarkan dari atas ke bawah dan mulai dari bagian kiri dari suatu halaman. o Kegiatan di dalam flowmap harus ditunjukkan dengan jelas. o Harus ditunjukkan darimana kegiatan akan dimulai dan dimana akan berakhir. o Masing-masing kegiatan di dalam flowmap sebaiknya digunakan suatu kata yang mewakili suatu pekerjaan. o Masing-masing kegiatan di dalam flowmap harus di dalam urutan yang semestinya. o Kegiatan yang terpotong dan akan disambung di tempat lain harus ditunjukkan dengan jelas menggunakan simbol penghubung. o Gunakan simbol-simbol flowmap yang standar. Adapun simbol-simbol yang sering digunakan dalam flowmap dapat dilihat pada Tabel 2.5 berikut ini : Tabel 2.5 Simbol Flow Map Simbol Simbol Keterangan yang digunakan untuk menunjukkan awal atau akhir dari suatu proses Menunjukkan dokumen input dan output baik untuk proses manual mekanik atau komputer

Menunjukkan pekerjaan manual

Menunjukkan multi dokumen

Pengarsipan Data

Menunjukkan Proses

2.5.4

Pemodelan Data Pemodelan data merupakan kumpulan perangkat konseptual untuk

menggambarkan data, hubungan data, semantik (makna) dan batasan data. 2.5.4.1 Data Flow Diagram (DFD) Data flow diagram (DFD) merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yg mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program (Kroenke, 2005). Adapun simbol-simbol yang sering digunakan dalam data flow diagram (DFD) dapat dilihat pada Tabel 2.6 (Kroenke, 2005): Tabel 2.6 Simbol-simbol pada DFD Simbol dengan sistem Entitas Eksternal Definisi Menunjukkan entitas yang berhubungan

Menggambarkan proses yang dilakukan oleh sistem Proses Menunjukkan arah aliran data Objek Data Menunjukkan tempat penyimpanan data Penyimpanan Data 2.5.4.2 Pengembangan Data Flow Diagram (DFD) Untuk memulai suatu diagram aliran data, diperlukan suatu rangkuman narasi sistem organisasi yang telah dibuat dalam bentuk sebuah daftar dengan empat kategori yang terdiri dari entitas eksternal, aliran data, proses, dan penyimpanan data. Daftar ini digunakan untuk membantu menentukan batas-batas sistem yang akan digambarkan. Tingkatan-tingkatan yang terdapat pada DFD adalah (Kroenke, 2005) : 1. Diagram konteks Diagram konteks adalah tingkatan tertinggi dalam diagram aliran data dan hanya memuat satu proses, menunjukkan sistem secara keseluruhan. Proses tersebut diberi nomor nol. Semua entitas eksternal yang ditunjukkan pada diagram konteks berikut aliran data aliran data utama menuju dan dari sistem. Diagram tersebut tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan, begitu entitas-entitas eksternal serta aliran data aliran data menuju dan dari sistem diketahui penganalisis dari wawancara dengan pengguna dan sebagai hasil analisis dokumen. 2. Diagram zero (diagram 0) Diagram 0 adalah pengembangan diagram konteks dan bisa mencakup sampai sembilan proses. Memasukkan lebih banyak proses pada level ini akan terjadi dalam suatu diagram yang kacau yang sulit dipahami. Setiap proses diberi nomor bilangan bulat, umumnya dimulai dari sudut sebelah kiri

atas diagram dan mengarah ke sudut sebelah kanan bawah. Penyimpanan datapenyimpanan data utama dari sistem dan semua entitas eksternal dimasukkan kedalam diagram 0. 3. Diagram level n Diagram level n adalah hasil dekomposisi dari diagram zero. Diagram level n menjelaskan proses secara lebih terperinci. Diagram level 1 merupakan turunan langsung dari diagram zero, artinya diagram level 1 berada satu tingkat lebih rendah dari diagram zero. Apabila diagram level 1 ini diuraikan lagi, maka akan terbentuk diagram level 2, dan seterusnya. 2.5.4.3 Kamus Data Kamus data adalah katalog fakta tentang data dan kebutuhan-kebutuhan informasi dari suatu sistem informasi (Jogiyanto : 2005). Kamus data dibuat berdasarkan arus data yang ada pada data flow diagram. Arus data pada data flow diagram sifatnya adalah global, hanya ditunjukkan nama arus datanya saja. Keterangan lebih lanjut tentang struktur dari suatu arus data pada data flow diagram secara lebih terinci dapat dilihat pada kamus data. Kamus data harus dapat mencerminkan keterangan yang jelas tentang data yang dicatatnya. Untuk maksud keperluan ini, maka kamus data harus memuat hal-hal berikut ini. a. Nama arus data Karena kamus data dibuat berdasarkan arus data yang mengalir pada data flow diagram, maka nama dari arus data juga harus dicatat pada kamus data, sehingga mereka yang membaca data flow diagram dan memerlukan keterangan lebih lanjut tentang suatu arus data tertentu di data flow diagram dapat langsung mencarinya dengan mudah di kamus data. b. Alias Alias atau nama lain dari data dapat dituliskan bila nama lain ini ada. Alias perlu ditulis karena data yang sama mempunyai nama yang berbeda untuk orang atau departemen satu dengan yang lainnya.

c. Bentuk data Bentuk data yang mengalir pada data flow diagram dapat berupa : Dokumen dasar atau formulir. Dokumen hasil cetakan komputer. Tampilan di layar monitor. Variabel. Parameter. Field.

Bentuk dari data ini perlu dicatat di kamus data, karena dapat digunakan untuk mengelompokkan kamus data ke dalam kegunaannya sewaktu perancangan sistem. d. Arus data Arus data menunjukkan dari mana data mengalir dan ke mana data akan menuju. Keterangan arus data ini perlu dicatat pada kamus data supaya memudahkan mencari arus data ini pada data flow diagram. e. Penjelasan Untuk lebih memperjelas lagi tentang makna dari arus data yang dicatat di kamus data, maka bagian penjelasan dapat diisi dengan keterangan-keterangan tentang arus data tersebut. f. Periode Periode ini menunjukkan kapan terjadinya arus data ini. Periode perlu dicatat di kamus data karena dapat digunakan untuk mengidentifikasi kapan input data harus dimasukkan ke sistem, kapan proses dari program harus dilakukan dan kapan laporan-laporan harus dihasilkan. g. Volume Volume yang perlu dicatat pada kamus data adalah tentang volume rata-rata dan volume puncak dari arus data. Volume rata-rata menunjukkan banyaknya rata-rata arus data yang mengalir dalam satu periode tertentu dan volume puncak menunjukkan volume yang terbanyak. Volume ini digunakan untuk mengidentifikasikan besarnya simpanan luar yang akan digunakan, kapasitas dan jumlah dari alat input, alat pemroses dan alat output.

h. Struktur data Struktur data menunjukkan arus data yang dicatat pada kamus data yang terdiri dari item-item data. (Tim Pelaksana Praktikum Basis Data, 2010) 2.5.5 Normalisasi Normalisasi adalah teknik yang digunakan untuk mengatur data dengan cara tertentu untuk mengurangi dan mencegah timbulnya masalah-masalah yang berhubungan dengan pengelolaan data dalam basis data (database) (Kroenke, 2005). Dalam penerapannya, bentuk normalisasi proses perancangan basis data (database) dapat dimulai dari dokumen dasar yang dipakai dalam sistem (Kroenke, 2005). Adapun bentukbentuk normal pada database adalah sebagai berikut (Kroenke, 2005) : 1. Bentuk tidak normal (un-normally form) Bentuk ini merupakan kumpulan data mula-mula yang akan direkam dan tidak harus memenuhi kaidah normalisasi secara umum. 2. Bentuk normal kesatu (1NF atau normal form) Bentuk ini dapat terpenuhi apabila tabel yang akan dibuat tidak memiliki atribut bernilai banyak (multivaluated attribute) atau lebih dari satu atribut dengan domain nilai yang sama. 3. Bentuk normal kedua (2NF atau second normal form) Bentuk ini dapat terpenuhi apabila pada sebuah tabel, semua atribut yang tidak termasuk dalam primary key memiliki ketergantungan fungsional (KF) pada primary key secara utuh. Sebuah tabel dikatakan tidak memenuhi 2 NF jika ketergantungannya hanya bersifat parsial (hanya tergantung sebagian dari primary key). 4. Bentuk normal ketiga (3NF atau third normal form) Bentuk ini merupakan criteria alternative, jika kriteria BCNF yang ketat tidak dapat dipenuhi. Sebuah tabel dikatakan memenuhi 3 NF jika setiap ketergantungan fungsional dengan notasi X dalam tabel yang tidak ada dalam X). A (A mewakili atribut tunggal

5.

Boyce-code normal form (BCNF) Sebuah tabel dikatakan berada dalam BCNF jika untuk semua KF dengan notasi X Y, maka X harus merupakan superkey pada tabel tersebut. Jika tidak demikian, maka tabel tersebut harus didekomposisi berdasarkan KF yang ada, hingga X menjadi superkey dari tabel-tabel hasil dekomposisi.

2.5.6

Model Entity Relationship (E-R) Model entity relationship merupakan suatu penyajian data dengan

menggunakan entity dan relationship (Kroenke, 2005). Entity adalah obyek yang dapat dibedakan dalam dunia nyata, sedangkan entity set adalah kumpulan dari entity yang sejenis (Kroenke, 2005). Relationship adalah hubungan yang terjadi antara satu atau lebih entity, sedangkan relationship set adalah kumpulan relationship yang sejenis (Kroenke, 2005). 2.5.7 Entity Relationship Diagram (ERD) Diagram entity relationship merupakan suatu bentuk diagram yang menggambarkan model entity-relationship yang berisi komponen-komponen himpunan entitas atau himpunan relasi yang masing-masing dilengkapi dengan atribut-atribut yang mempresentasikan seluruh fakta dari dunia nyata yang dicermati (Kroenke, 2005). Tabel 2.7 menunjukkan notasi atau simbol yang digunakan dalam diagram E-R (Kroenke, 2005): Tabel 2.7 Notasi dalam ERD
Simbol Menunjukkan dengan sistem Entitas Menunjukkan atribut yang dimiliki oleh Atribut entitas Definisi entitas yang berhubungan

Menunjukkan link Link Menunjukkan relasi antar entitas Relasi

2.5.8

Kardinalitas Kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat

berelasi dengan entitas pada himpunan entitas yang lain. Dari sejumlah kemungkinan banyaknya hubungan antar entitas tersebut, Kardinalitas Relasi merujuk kepada hubungan maksimum yang terjadi dari himpunan entitas yang satu ke himpunan entitas yang lain dan begitu juga sebaliknya. Berikut penggambaran relasi antar himpunan entitas, serta relasi itu sendiri digunakan untuk menjelaskan batasan-batasan pada jumlah entitas yang dihubungkan dengan melalui suatu relationship. Ada tiga derajat relasi, yaitu (Kroenke, 2005) : 1. One to one (satu ke satu) Dalam relasi satu ke satu, setiap record dalam tabel A berhubungan paling banyak dengan satu record pada tabel B, dan begitu juga sebaliknya. Jenis relasi ini tidak umum, karena sebenarnya tabel A dan tabel B dapat digabungkan menjadi satu tabel. Contoh: Setiap pengirim mempunyai satu kode barcode.
Pengirim 1 Mempunyai 1 Kode Barcode

Gambar 2.12 Contoh relasi satu ke satu 2. One to many (satu ke banyak) Relasi satu ke banyak adalah bentuk relasi yang paling umum. Dalam relasi satu ke banyak , sebuah record dari tabel A berhubungan dengan banyak record pada tabel B,. Namun sebuah record dalam tabel B berhubungan

dengan paling banyak dengan satu record pada tabel A. Contoh: Setiap pengirim dapat mengirim satu atau lebih barang.
1 N

Pengirim

Mengirim

Barang

Gambar 2.13 Contoh relasi satu ke banyak 3. Many to many (banyak ke banyak) Dalam relasi banyak ke banyak, sebuah record dalam tabel Adapat berhubungan dengan banyak record pada tabel B dan sebaliknya. Jenis relasi ini hanya dimungkinkan jika kita mendefinisikan tabel baru sebagai perantara. Contoh: setiap mahasiswa dapat mengambil mata kuliah lebih dari satu dan setiap mata kuliah dapat diambil oleh lebih dari satu mahasiswa.

Mahasiswa

Mengambil

Mata kuliah

Gambar 2.14 Contoh relasi banyak ke banyak 2.5.9 Structure Query Language (SQL) SQL (Structured Query Language) adalah serangkaian pertanyaan pada engine database (termasuk engine Jet) yang berisi informasi apa yang ingin ditampilkan oleh pemakai. Kemudian engine memproses pernyataan tersebut dan menyediakan informasi yang diperlukan. SQL bukanlah bahasa pemrograman terapi sub-language (subbahasa) yang berisi sekitar 30 pernyataan khusus dengan tugas mengelola database. Pernyatan SQL dikelempokkan menjadi dua yaitu DDL (data definition Language) dan DML (data manipulation language). Pernyataan DDL merujuk pada kumpulan perintah yang dapat digunakan untuk mendefinisikan objek-objek basis data, seperti membuat sebuah tabel basis data atau indeks primer/sekunder. Sedang pernyataan DML mengacu pada kumpulan perintah yang dapat digunakan

untuk melakukan manipulasi data, seperti penyimpanan data ke sebuah tabel lalu kemudian mengubahnya atau menghapusnya atau hanya sekedar menampilkan kembali. Sebuah ekspresi SQL dasar sebenarnya hanya terdiri atas 3 klausa, yaitu: select, from dan where: a. Klausa select digunakan untuk menetapkan daftar atribut (field) yang diinginkan sebagai hasil query. b. Klausa from digunakan untuk menetapkan tabel (atau gabungan tabel) yang akan ditelusuri selama query data dilakukan. c. Klausa where, yang sifatnya opsional digunakan sebagai predikat (kriteria) yang harus dipenuhi dalam memperoleh hasil query. Sintaks (cara penulisan) dari ekspresi SQL dasar dengan 3 klausa tersebut adalah: select A1,A2,,An from T1,T2,,Tn where P dimana: A1,A2,,An merupakan daftar atribut T1,T2,,Tn merupakan daftar tabel P merupakan predikat query Aturan dalam penulisan pernyataan SQL adalah sebagai berikut : Semua keywords (kata kunci) dari pernyataan SQL diketik menggunakan huruf besar. Informasi bertipe string yang terletak di antara pernyataan SQL dapat diapit dengan kutip ganda () atau kutip tunggal (). Pada waktu menampilkan data (recordset), SQL mendukung penggunaan wildcards (memilih semua kolom/field) dengan lambang asterik (*).

 Jika nama field atau tabel memiliki spasi ditengahnya, maka nama tersebut harus diapit dengan lambang bracket ({}). Contoh field dengan nama Data Pegawai dalam pernyataan SQL : [Data Pegawai] Untuk menunjuk field khusus pada tabel khusus dalam pernyataan SQL digunakan notasi dot(.). Tabel 2.8 berikut menunjukkan tujuh buah perintah (command) SQL. Tabel 2.8 Tujuh Perintah SQL Perintah CREATE ALTER DROP SELECT INSERT UPDATE DELETE Keterangan Membuat tabel, field atau indeks. Mengubah tabel dengan menambah field atau mengubah definisi field. Men-drop tabel atau indeks Mendefiniskkan data apa yang akan diambil dari database Dengan sekali operasi menyisipkan banyak record Mengubah informasi seluruh range dengan memberi parameter. Menghapus record pada suatu tabel (Sumber: Tim Pelaksana Praktikum Basis Data, 2010) 2.6 Server Web Server web adalah sebuah perangkat lunak server yang berfungsi menerima permintaan HTTP atau HTTPS dari klien yang dikenal dengan browser web dan mengirimkan kembali hasilnya dalam bentuk halaman-halaman web yang umumnya berbentuk dokumen HTML. (http://wikipedia/id/server_web.htm diakses tgl 17 Mei 2010). Web server adalah sebuah bentuk server yang khusus digunakan untk menyimpan halaman web site atau home page. Komputer dapat dikatakan sebagai web server jika komputer tersebut memiliki suatu program server yang disebut Personal Web Server (PWS). PWS ini difungsikan agar halaman web yang ada di dalam sebuah komputer server dapat dipanggil oleh komputer klien.

Macam-macam web server: Apache (open source) Xitami IIS PWS (Nugroho, 2004) 2.7 PHP PHP (akronim dari PHP Hypertext Preprocessor) yang merupakan bahasa pemrogramman berbasis web yang memiliki kemampuan untuk memproses data dinamis. PHP dikatakan sebagai sebuah server-side embedded script language artinya sintaks-sintaks dan perintah yang kita berikan akan sepenuhnya dijalankan oleh server tetapi disertakan pada halaman HTML biasa. Aplikasi-aplikasi yang dibangun oleh PHP pada umumnya akan memberikan hasil pada web browser, tetapi prosesnya secara keseluruhan dijalankan di server. Pada prinsipnya server akan bekerja apabila ada permintaan dari client. Dalam hal ini client menggunakan kode-kode PHP untuk mengirimkan permintaan ke server (sumber: http://www.deptan.go.id/pusdatin/admin/RB/ Programming/Materi%20PHP.pdf. Diakses tanggal 17 Mei 2010). Interpreter PHP dalam mengeksekusi kode PHP pada sisi server (disebut server-side) berbeda dengan mesin maya Java yang mengeksekusi program pada sisi klien (client-side). Proses eksekusi kode PHP yang disisipkan pada halaman HTML secara diagram dapat digambarkan pada Gambar 2.15 sebagai berikut:

Gambar 2.15 Diagram Eksekusi Halaman PHP PHP merupakan bahasa standar yang digunakan dalam dunia website. PHP adalah bahasa program yang berbentuk script yang diletakkan di dalam server web. Jika kita lihat dari sejarah, mulanya PHP diciptakan dari ide Rasmus Lerdof yang membuat sebuah script perl. Script tersebut sebenarnya dimaksudkan sebagai program untuk dirinya sendiri. Akan tetapi, kemudian dikembangkan lagi sehingga menjadi sebuah bahasa yang disebut Personal Home Page. Inilah awal mulanya PHP sampai saat ini. PHP telah diciptakan terutama untuk kegunaan web dan boleh menghubungkan query database dan mengugnakan simple task yang boleh diluruskan dengan 3 atau 4 baris kod saja. PHP adalah bahasa programin yang baru dibangun sekitar tahun 1994/1995. PHP sebenarnya merupakan program yang berjalan pada platform LINUX sehingga membuat program ini menjadi freeware. Selanjutnya PHP mengalami perkembangan yakni dibuat dalam versi Windows. (Nugroho, 2004).

2.7.1

Kegunaan PHP Hampir seluruh aplikasi berbasis web dapat dibuat dengan PHP ini,

namun fungsi PHP yang paling utama adalah untuk menghubungkan database dengan web. Dengan PHP, membuat aplikasi web yang terkoneksi kt database menjadi sangat mudah. Sistem database yang telah didukung oleh PHP adalah: Oracle Sybase mSQl MySQL Solid Generic ODBC PostgresSQL PHP juga mendukung komunikasi dengan layanan lain melalui protokol IMAP, SNMP, NNTP, dan POP3 atau HTTP. Contoh script PHP: <html> <head> </head> <body> <?php echo Contoh script PHP ?> </body> </html> Script PHP merupakan program yang fleksibel, artinya script-script PHP dapat dituliskan di sela-sela tag HTML karena PHP memiliki sifat yang dapat berkonteraksi dengan program lain. (Nugroho, 2004).

2.7.2

Editor PHP PHP merupakan bahasa programing yang berbentuk script, oleh

karenanya PHP tidak memiliki editor bawaannya, tidak seperti Pascal, Clipper. PHP juga dapat dikatakan bukah sebuah program, karena salah satu persyaratan sebuah program yang tidak dimiliki oleh PHP yaitu compiler, sehingga script yang dihasilkan tidak akan menjadi program yang berdiri sendiri, tetapi tetap memerlukan program pendukunganya, yaitu PHP. Untuk menuliskan script-script PHP harus digunakan aplikasi editor seperti Notepad, Frontpage, PHP editor, Quanta (LINUX), maupun editor Dreamweaver. (Nugroho, 2004). 2.8 MySQL MySQL (My Structure Query Language) atau yang biasa disebut maise-kuel adalah sebuah program pembuat basis data yang bersifat open source, artinya siapa saja boleh menggunakannya dan tidak dicekal. MySQL sebenarnya produk yang berjalan pada platform Linux. Karena sifatnya yang open source, MySQL dapat dijalankan pada semua platform. MySQL juga merupakan program pengakses basis data yang bersifat jaringan sehingga dapat digunakan aplikasi multi user (banyak pengguna). Kelebihan MySQL adalah menggunakan bahasa query standar yang dimiliki SQL (Structure Query Language). SQL adalah suatu bahasa permintaan yang terstruktur yang telah distandarkan untuk semua program pengakses basis data seperti Oracle, Posgres SQL, SQL server, dan lain-lain. Sebagai sebuah program penghasil basis data, MySQL tidak dapat berjalan sendiri tanpa adanya sebuah aplikasi lain (interface). MySQL dapat didukung oleh hampir semua program aplikasi baik yang open source seperti PHP maupun yang tidak, yang ada pada platform Windows seperti Visual Basic, Delphi, dan lainnya. Program-program yang menggunakan bahasa SQL, antara lain: MySQL Posgres SQL

Oracle SQL server 97, 2000 Interbase Program-program aplikasi pendukung MySQL, antara lain: PHP Visual Delphi Visual Basic Cold fusion, dan lain-lain (Nugroho, 2004)

2.9

Aplikasi PHP-MySQL Ada beberapa fungsi yang digunakan dalam aplikasi antar PHP dan

MySQL. Fungsi-fungsi tersebut sangat erat kaitannya dengan Query SQL. Akan tetapi perintah SQL tidak dapat langsung digunakan pada PHP. Di sini, fungsi SQL digunakan sebagai penghubung antara SQL sehingga Query tersebut dapat dijalankan pada server dan dapat dilihat hasilnya oleh klien. Fungsi MySQL dapat juga dikatakan sebagai interpreter Query karena setiap menggunakan Query SQL harus diletakkan di dalam fungsi ini. Dengan kata lain, Query SQL tidak dapat dijalankan tanpa adanya fungsi MySQL. 2.9.1 Fungsi-fungsi MySQL Untuk dapat menggunakan semua perintah SQL pada PHP, diperlukan suatu fungsi MySQL. Fungsi ini berguna untuk mengantarkan perintah SQL pada PHP menuju ke server sehingga perintah tersebut dapat dieksekusi oleh server MySQL. Fungsi-fungsi tersebut dapat dilihat pada Tabel 2.9. Tabel 2.9 Fungsi-fungsi MySQL Fungsi MySQL mysql_change_user() mysql_close() Penggunaan Mengganti user pada koneksi aktif Digunakan untuk menutup koneksi dengan

MySQL mysql_affected_rows() mysql_connect() mysql_create_db() mysql_data_seek() mysql_db_name() mysql_db_query() mysql_drop_db() mysql_errno() mysql_error() mysql_fetch_array() mysql_fetch_assoc() mysql_fetch_field() mysql_fetch_lengths() mysql_fetch_object() mysql_fetch_row() mysql_field_name() mysql_field_len() mysql_field_seek() mysql_field_table() Untuk menghasilkan hasil data Untuk mengantarkan Query MySQL Untuk menghapus database Untuk menampilkan pesan kesalahan dalam bentuk no dari server MySQL Untuk menampilkan pesan kesalahan dalam bentuk teks dari server MySQL Menghasilkan data berupa array dalam bentuk angka dari isi tabel MySQL Menghasilkan data berupa array dalam bentuk field dari isi tabel MySQL Menghasilkan informasi kolom dari hasil yang kemudian dikembalikan sebagai suatu objek Menghasilkan besar file dari hasil tabel MySQL Menghasilkan sebuah baris sebagai suatu objek Menghasilkan array/baris dengan keluaran nama field pada tabel MySQL Menghasilkan nama field khusus pada database MySQL Returns the length of the specified field Set result pointer to a specified field offset Get name of the table the specified field is in Get number of affected rows in previous MySQL operation Utnuk membuka koneksi dengan database MySQL server Untuk membuat databse

mysql_field_type() mysql_free_result() mysql_insert_id() mysql_list_dbs() mysql_list_fields() mysql_num_fields() mysql_num_rows() mysql_pconnect() mysql_query mysql_result() mysql_select_db() mysql_tablename()

Get the type of the specified field in a result Free result memory Get the id generated from the previous INSERT operation List databases available on a MySQL server Listg MySQL result fields List tables in a MySQL database Get number of fields in result Membuka koneksi langsung dengan MySQL Digunakan untuk mengirimkan perintah SQL Untuk menghasilkan data Digunakan untuk masuk pada database MySQL Get table name of field

(Sumber : Nugroho, 2004) 2.9.2 Interaksi Database MySQL dan PHP Untuk dapat menghubungkan database dengan program aplikasi PHP, diperlukan beberapa fungsi API yang dimiliki oleh database itu sendiri. MySQL adalah sebuah database yang mampu berinteraksi dengan aplikasi apa saja. Umumnya semua database menggunakan ODBC sebagai komponen penghubung database dengan aplikasi program. Akan tetapi, MySQL telah menyiapkan beberapa API selain ODBC untuk dapat berinteraksi dengan PHP. Fungsi-fungsi itu diantarany adalah mysq_connect(), mysql_select_db(), dan sebagainya. 2.9.3 Koneksi Server Karena MySQL merupakan suatu server database yang bersifat multiuser dan salah satu sifat program multiuser hanya dapat berjalan di sisi server, maka database tidak dapat diakses tanpa seijin dari server tersebut. Selain itu juga karena saat ini program yang sedang berjalan adalah PHP yang juga berjalan pada sisi server, maka harus diperkenalkan server yang digunakan. Dalam MySQL,

fungsi yang digunakan untuk menghubungkan ke server adalah mysql_connect() atau dapat juga digunakan mysql_pcconnect(). Rumus fungsinya adalah: mysql_connect(server_host, password) 2.10 Editor Dreamweaver MX Dreamweaver MX adalah suatu bentuk bentuk program editor web yang dibuat oleh Macromedia. Dengan program ini seorang programer web dapat dengan mudah membuat dan mendesain webnya. Dreamweaver MX adalah editor yang komplit yang dapat digunakan utnuk membuat animas sederhana yang berbentuk layer. Sebagai editor Dreamweaver MX mempunyai sifat yang WYSIWYG dibaca (Waysiwig), artinya apa yang kami lihat akan kamu peroleh (What You See Is Will What You Get). Dengan kelebihan ini, seorang programer dapat langsung melihat hasil buatannya tanpa harus dibuka di browser. Seperti program editor-editor web lain, Dreamweaver MX juga memiliki dua buah layar, yaitu bentuk halaman Design dan halaman Code. Hal ini dapat mempermudah dalam menambahkan script yang berbasis PHP maupun Javascript. Dreamweaver MX selain mendukung pembuatan web yang berbasis HTML, juga dapat mendukung program-program web yang lain diantaranya PHP, ASP, Perl, Javascript, dan lainnya. Halaman pada Dreamweaver dapat dilihat pada Gambar 2.16. , user,

Gambar 2.16 Halaman Design

Gambar 2.17 Halaman Code 2.11 Komponen Dreamweaver 2.11.1 Tool Bar Common Pada menu ini terdapat ikon-ikon dasar yang digunakan untuk membangun sebuah website, ini merupakan bentuk standar yang ditampilkan pada saat halaman web dibuka. Gambar 2.18 menunjukkan tampilan toolbar common.

Gambar 2.18 Toolbar Common

2.11.2 Tool Bar Layout Toolbar layout merupakan bentuk pengembangna dari komponen sebelumnya atau common. Pada toolbar ini, semua dukungan dikembangkan menjadi beberapa bentuk ikon. Dengan adanya kelengkapan tersebut maka dapat semakin mempermudah dalam melakukan pembuatan aplikasi maupun desain. Gambar 2.19 menunjukkan toolbar layout.

Gambar 2.19 Toolbar Layout 2.11.3 Tool Bar Frame Frame digunakan untuk membuat halaman web yang terlihat menjadi beberapa bagian, dalam pembuatannya Dreamweaver MX versi terbaru dan Dreamweaver 8 ini telah memberikan pengelompokkan yang menjadi satu dalam toolbar Layout, seperti terlihat pada Gambar 2.20.

Gambar 2.20 Toolbar Frame 2.11.4 Tool Bar Form Toolbar form digunakan untuk membuat formulir secara manual menjadi bentuk formulir yang berupa website aplikasi, seperti terlihat pada Gambar 2.21.

Gambar 2.21 Toolbar Form 2.11.5 Tool Bar Text Toolbar text digunakan untuk memformat teks yang ada di dalam halaman desain serta untuk membuat heading dan karakter khusus. Adapun cara lain selain menggunakan ikon pada menu ini adalah dengan memilih menu Text pada Menubar. Toolbar text terlihat seperti pada Gambar 2.22.

Gambar 2.22 Toolbar Text 2.11.6 Toolbar PHP Dalam membangun program atau aplikasi dinamis dengan PHP, sangat dimungkinkan toolbar ini sering digunakan pada halaman kode saat membuat skrip program. Fungsi dari toolbar PHP ini adalah untuk membantu dalam menuliskan beberapa kode PHP. Toolbar PHP terlihat seperti pada Gambar 2.23.

Gambar 2.23 Toolbar PHP 2.11.7 Menu Properties Menu properties adalah sekumpulan menu yang berfungsi sebagai tool dalam pemformatan objek yang ada pada halaman web yang dibuat. Menu ini akan selalu berubah tergantung menu Insert yang sedang diaktifkan tipe apa. Adapun cara mengaktifkannya adalah : Klik menu Window pada menu bar Pilih dan klik properties

Menu properties dapat terlihat pada Gambar 2.24.

Gambar 2.24 Menu Properties 2.12 Mobile Station (MS) Mobile Station merupakan bagian peralatan yang dapat bergerak untuk memberikan pelayanan atau mendukung suatu hubungan bagi terminal luar. Informasi yang berhubungan dengan pelanggan tersimpan dalam suatu kartu chip yang disebut Subscriber Identity Module (SIM). SIM merupakan suatu kartu pintar yang telah distandarisasi oleh ISO. Kartu ini juga memuat Internasional Mobile Station Identity (IMSI). Identitas ini digunakan oleh operator jaringan untuk identifikasi pelanggan dalam jaringan. Bagian lain di dalam Mobile Station adalah Mobile Equipment (ME), yang di dalamnya terdapat kode Internasional Mobile Station Equipment Identity (IMEI). Ketika kartu SIM dimasukkan ke dalam ME, maka MS akan mempunyai identitas pelanggan, sehingga panggilan dapat dikirimkan atau diterima MS tersebut. 2.13 Base Transceiver Station (BTS) BTS merupakan elemen dasar dari suatu sistem radio selular, yang dapat menyediakan kanal bagi pelanggan, dan sebagai elemen jaringan yang melayani fungsi-fungsi penting pada antena. Sebuah BTS dapat dipandang sebagai sebuah sel yang dapat membawa 1 sampai 8 pembawa, dimana 1 pembawa terdiri dari 8 slot waktu. BTS dapat dihubungkan secara lokal bersama dengan BSC atau dihubungkan dari tempat terpisah melalui Base Station Interface Equipment (BIE).

2.14 Base Station Controller (BSC) BSC merupakan bagian inti dari subsistem BSS. Suatu BSC dapat dihubungkan ke beberapa BTS, dan dapat mengendalikan sampai dengan 60 kanal pembawa. BSC mempunyai fungsi utama sebagai berikut : Pengaturan pengukuran radio dan parameternya. Pemrosesan informasi pensinyalan. Penanganan perawatan dan perbaikan. Pengawasan alarm. Penyambungan kanal trafik. Ada tiga buah Network Interface Element (NIE) di dalam BSC, yaitu : a. Terminal Controller Unit (TCU), yang menyediakan antar muka dengan BTS. Banyaknya TCU tergantung dari jumlah frekuensi pembawa di BTS yang dikendalikannya. b. Digital Trunk Controller (DTC), merupakan terminal dari link 2 MBps ke MSC, bertugas sebagai trafik dan pensinyalan dari dan ke MSC. Banyaknya DTC tergantung pada besarnya trafik di dalam BSC tersebut. c. Central Processor (CPR), merupakan tempat menyimpan program dan data, mengerjakan berbagai tugas yang menyangkut sistem, menyediakan fasilitas pemindahan data ke BTS, dan mendukung antar muka X25 dan RS 232. Komunikasi antara NIE dengan NIE lainnya dikerjakan melalui switching matrix, yang mempunyai keistimewaan antara lain pemilihan jalur secara individu dan pembuatan jalur singkat.

2.15 Teori Alarm BTS 2.15.1 Overview Alarm BTS Komponen dari Base Transceiver Station (BTS) memiliki fungsi sebagai berikut : Menyediakan udara yang suatu interface transmiter antara dan receiver di menghubungkan persona communication

subscriber dan span line interface ke (Centralized Base Station Controller) CBSC. Mensupport jaringan interface yang menghubungkan dengan CBSC untuk mengirim dan menerima trafik serta control information. Melaporkan setiap hasil dari alarm dan self-diagnostic secara kontinyu kepada fault system management.

Gambar 2.25 Diagram Blok BTS BTS terdiri dari indoor BTS (SC4812T) dan outdoor BTS

(SC4812ET), masing-masing memiliki modul-modul yang jumlahnya cukup banyak. Sistem tersebut akan memberikan report berupa informasi untuk setiap event pada operator, report dapat berisi command, device state changes, upload information, dan lain-lain. Hal tersebut meliputi alarm function yang mengindikasikan respon jika terjadi error pada sistem.

Alarm tersebut meliputi alarm yang dihasilkan oleh : Base Transceiver Station (BTS) Transcoder (XC) Centralized Base Station Controller (CBSC) Mobility Manager (MM) Operations & Maintenance Center - Radio (OMC-R) Mobile Wireless Fault Mediator (MWFM)

2.15.2 Report Monitoring Alarm BTS mengirim beberapa jenis alarm ke CBSC melalui span line interface, Alarm- alarm ini dapat dikelompokkan kedalam beberapa kategori: Span Alarms. Alarm yang berkaitan dengan performa dan kualitas dari sinyal yang berada didalam TI/IE span line antara BTS dan CBSC. Customer Alarms. Output alarm dari BTS ke CBSC. Timing Alarms. Alarm yang berkaitan dengan kerusakan yang terjadi pada Global Positioning System (GPS), dimana diperolehnya informasi waktu. Power Amplifier (PA) Alarms. Alarm yang berkaitan dengan status dari modul PA. Link Alarms. Alarm yang berkaitan dengan status dan kualitas sinyal dari BTS ke mobile link. BTS Hardware Alarms. Alarm yang berkaitan dengan kerusakan berbagai modul.

2.15.3 Layout Frame BTS

Gambar 2.26 Layout Frame BTS

2.15.4 Level Alarm

Alarm pada BTS dapat dikategori berdasarkan 3 level yaitu: Warning Alarm Warning Alarm yaitu suatu kondisi dimana alarm mendeteksi adanya potensi suatu sistem akan mengalami error, status warning tidak membutuhkan tindak lanjut operator yang signifikan. Minor Alarm Minor Alarm yaitu kondisi alarm pada level satu dimana menunjukkan bahwa telah terjadi kesalahan temporer pada suatu sistem dan telah terjadi. Major Alarm Major Alarm yaitu suatu kondisi dimana alarm berada pada level status kedua, yang memerlukan tindakan korektif secepatnya sebelum terjadi error system lain yang lebih serius. Contoh: kerusakan pada MGLI, GLI, LCI, FEPR, BTSLINK, XCLINK, FEPR, Power Supply. Critical Alarm Critical Alarm yaitu suatu kondisi alarm berada pada level ketiga, dikoreksi. Tindakan lain yang korektif diperlukan segera sebelum kegagalan dapat menyebabkan suatu kesalahan serius

hal ini menunjukkan bahwa telah terjadi kerusakan fatal pada suatu subsistem yang dapat merusakkan sistem lain.

2.15.5 Format Alarm

Format dari alarm pada mesin BTS terdiri dari dua header yakni: Baris pertama menunjukkan background informasi dari event. Baris kedua menjelaskan lebih detail informasi dari event tersebut (template alarm). Contoh format alarm :
MGLI-200-1 93-08-08 13:15:42 ARLINGTN CBSC-1 A000439.00000 127665 *** ALARM:1 -1428 "GLI SPAN A - Framed AIS Alarm: OOS Threshold Exceeded" DEVICE_SUBUNIT=1 REASON="None" ADDITIONAL_DATA=00 00

Keterangan: Format Alarm

MGLI-200-1 93-08-08

Penjelasan Device ID (mengidentifikasikan jenis device ) Date (menunjukkan tanggal, bulan, dan tahun report dari suatu event) diterimanya

13:15:42

Time (menunjukkan waktu diterimanya report dari suatu event dengan format waktu jam, menit, detik) OMCR Name (menunjukkan nama dari OMCR dari suatu event dalam format 8 bit ASCII) Equipment ID (menunjukkan jumlah dari peralatan yang dihasilkan oleh suatu event atau dari pengontrolan BTS) Job ID (mengidentifikasi efek dari suatu event yang terjadi) Ada 2 karakter Job ID : M - Manually invoked event A - Automatically invoked event Master Sequence Number Severity (tingkat level alarm). Terbagi menjadi 3 tipe : * = level minor ** = level mayor *** = Level kritis Tipe dan kode dari event

ARLINGTN

CBSC-1

A000439.00000

127665 ***

ALARM:1-1428

"GLI Framed OOS

SPAN AIS

Alarm:

Deskripsi dari alarm

Threshold

Exceeded"

2.15.6 Template Alarm

Template alarm menjelaskan informasi tambahan dari suatu alarm yang terjadi. Informasi tersebut meliputi: Kondisi-kondisi yang memicu terjadinya error termasuk aspekaspek diluar format alarm. Tipe level error. Bagian informasi dari template alarm yaitu: Template Alarm severity level pengoperasian sistem. Device sub_unit Reason Additional Data Event Time Daftar sub unit identifiers. Pertimbangan-pertimbangan yang dapat digunakan untuk mengidentifikasikan suatu alarm. Bagian ini menjelaskan data tambahan yang terkait dengan jenis alarm. Menunjukkan waktu terjadinya alarm yang dilakukan oleh elemen-elemen jaringan (BTS, SDU, dan lain-lain). Waktu yang tertera pada baris pertama di header alarm menunjukkan waktu saat OMCR menerima dan memproses error. Penjelasan Tingkat kegentingan dari alarm, yang berdampak pada

Correlation Tag

Bagin ini adalah suatu tag atau numeric Id yang digunakan untuk mengkorelasikan alarm event pada seluruh event system lainnya. Sebagai contoh, jika user akan melakukan lock suatu perangkat maka correlation tag akan mengubah status event dan out of service alarm event akan mendapatkan id yang sama.

Event_type

Event-event alarm dibagi dalam lima kategori besar yaitu : Communication, Environmental, Equipment, Processing Error, dan Quality of Service (QoS).

Probable_cause Additional_tex t

Event-event dibagi lagi dalam kategori tambahan untuk membantu menemukan kemungkinan penyebab alarm. Memberikan informasi pada sebuah form ASCII text string untuk dapat mengisolate problem selanjutnya.

Informasi Dasar System Impact Bagian ini menjelaskan bahwa alarm memiliki kemungkinan untuk dapat memproses pangilan. Dalam beberapa kasus dampak dari single alarm tidak akan menyebabkan loss capacity dalam hal penggunaan komponen yang berlebihan pada keseluruhan sistem. System Action Bagian ini menjelaskan tentang apa yang sistem lakukan sebagai respon dari event yang terjadi secara internal. Operator Action Bagian ini menyediakan petunjuk kepada operator yang menerima pesan alarm tentang bagaimana melakukan troubleshooting dari suatu alarm. Device List Daftar dari perangkat-perangkat yag dapat menjadi sumber dari kesalahan. Related Events Daftar dari event-event yang terkait saat suatu event terjadi.

BAB III ANALISIS SISTEM

3.1 3.1.1

Penilaian (Assessment) Kelayakan dan Justifikasi Masalah Di antara penunjang keberhasilan suatu operator adalah jaringan yang

bagus meliputi cakupan wilayah yang luas, tingkat keberhasilan pelanggan membuat panggilan yang tinggi, jumlah drop call yang kecil, dan kapasitas kanal yang disediakan memadai. Untuk menjaga kehandalan jaringan, maka bagian yang berhubungan langsung dengan telepon genggam harus dijaga kestabilan kerjanya. Bagian tersebut adalah Base Transceiver Station (BTS). Gangguan yang dialami oleh pelanggan seluler contohnya drop call disebabkan oleh banyak faktor salah satunya yakni Voice Call Overload berupa gangguan pada pada mesin BTS. Gangguan yang terjadi tersebut ditandai dengan adanya alarm yang terdapat pada modul-modul dari mesin BTS itu sendiri. Alarm ini memudahkan user dalam hal ini teknisi ahli untuk menganalisa masalah dan melakukan troubleshooting untuk memperbaiki masalah yang terjadi. Saat ini sistem yang ada pada salah satu perusahaan penyedia layanan jaringan telekomunikasi untuk menginformasikan alarm yang terjadi pada mesin BTS adalah dengan cara teknisi yang melakukan kerj shif dengan kurun waktu 24 jam untuk memonitoring alarm pada Span Line Interface yang terjadi dalam sebuah aplikasi Alarm Management System kemudian apabila alarm yang muncul masuk kategori critical alarm maka harus menginformasikan alarm tersebut ke teknisi ahli untuk melakukan troubleshooting. Karena keterbatasan itulah yang menyebabkan para teknisi cukup kesulitan untuk melakukan troubleshooting dengan cepat karena harus melakukan proses pelaporan dulu ke teknisi ahli. Untuk menangani masalah ini, dibutuhkan suatu sistem yang merangkum seluruh jenis alarm, dapat membantu proses diagnosis menentukan tiap-tiap jenis alarm. jenis alarm yang terjadi, serta dapat memberikan solusi troubleshooting yang tepat dan efektif bagi

Berdasarkan kasus tersebut, maka perlu dibuat sebuah sistem penunjang yang mendayagunakan komputer agar bisa berpikir dan bertindak seperti manusia, dimana sistem penunjang tersebut merupakan sistem pakar untuk mendiagnosis alarm gangguan BTS yang dirancang untuk memodelkan/mengemulasi kemampuan seorang pakar dalam memecahkan suatu masalah yang berbasiskan pada pengetahuan pakar. 3.1.2 Analisis Kebutuhan Aplikasi sistem pakar untuk diagnosis alarm gangguan BTS ini melibatkan tiga aktor dalam pengembangan maupun implementasinya. Tiga aktor tersebut meliputi knowledge engineer, pakar dalam bidang troubleshooting BTS, dan teknisi sebagai pengguna akhir. Peran knowledge engineer dalam proses pengembangan aplikasi ini mengarah pada proses transformasi pengetahuan dan mengambil keputusan dan pemecahan masalah ke dalam lingkungan aplikasi komputer, rancang bangun aplikasi berbasis komputer yang memiliki pola pikir seorang pakar. Aplikasi ini penulis rancang untuk diakses dalam lingkungan aplikasi berbasis web (internet), dikarenakan dengan penggunaan jaringan internet, aplikasi dapat diakses secara luas. 3.1.3 Tujuan Pengembangan Sistem Tujuan dari proses perancangan ini adalah untuk menghasilkan sebuah model atau representasi dari entitas (perangkat, proses, atau sistem) yang hendak dibangun. Perancangan ini diharapkan mampu menggambarkan logika sistem, aliran data dalam sistem, deskripsi proses, serta kontrol yang terjadi dalam sistem. 3.1.4 Perumusan Masalah Ruang lingkup kepakaran aplikasi ini adalah bidang alarm gangguan BTS, dari segi pemakai secara umum aplikasi dapat digunakan oleh pakar sebagai

3.1.4.1 Analisis spesifikasi kebutuhan pemakai (termasuk sistem)

sumber pengetahuan dari aplikasi ini, dan user yang melakukan penelusuran kerusakan dengan bantuan aplikasi. Sedangkan untuk kebutuhan sistem, perangkat yang digunakan untuk mengakses aplikasi ini adalah komputer dan sistem operasi sebagai lingkungan untuk menjalankan aplikasi. 3.1.4.2 Analisis spesifikasi paket program a. Analisis spesifikasi fungsional Kebutuhan fungsional sistem mendefinisikan hal-hal yang dibutuhkan oleh sistem yang akan dibangun, antara lain: Kemampuan mendiagnosis jenis gangguan/alarm. Kemampuan untuk memberikan troubleshooting yang tepat untuk diberikan kepada pengguna dengan memperhatikan keefektifan solusi tersebut. Kemampuan memberikan penjelasan mengenai troubleshooting yang diambil dalam proses pengambilan keputusan untuk menangani alarm yang terjadi. Kemampuan yang mendukung pengubahan basis pengetahuan, yang meliputi kemampuan untuk menambah, meng-update, menampilkan kembali rule yang telah dibuat, dan menghapus data pada basis pengetahuan. b. Analisis spesifikasi kinerja Mengolah data hasil penelusuran user. Memberikan jawaban berdasarkan pilihan data (hasil penelusuran) dari user. c. Analisis spesifikasi interface Tab menu, berisikan menu-menu untuk navigasi. Dalam aplikasi system pakar yang penulis rancang, system terbagi menjadi dua lingkungan yaitu: lingkungan admin/pakar

dan lingkungan user/teknisi. Form informasi, berisikan informasi troubleshooting BTS. Form penelusuran, berisikan pilihan-pilihan data (berkaitan dengan kerusakan) yang harus dipilih oleh user. Form solusi, berisikan solusi atas kerusakan.

d. Analisis spesifikasi interaksi manusia dan mesin Dalam implementasinya aplikasi ini dapat dengan mudah digunakan oleh user karena dalam pengoperasiannya sistem akan memberikan keterangan langkah-langkah penggunaan, seperti keterangan input, output, selain itu penyajian menu secara grafis untuk memperindah aplikasi. Dalam fasilitas utamanya yaitu penelusuran kerusakan, user hanya diminta untuk memberikan jawaban berdasarkan pilihan data yang diberikan oleh sistem sehingga mudah dimengerti oleh user. e. Analisis spesifikasi sumber daya Dalam pembangunan sistem pakar yang dibuat, dibutuhkan beberapa sumber daya, diantaranya: Hardware Perangkat keras komputer sebagai media dalam komunikasi teknisi dengan sistem. Software Operating system, sistem operasi sebagai lingkungan untuk menjalankan aplikasi. Developer, aplikasi pembangun sistem yang meliputi bahasa pemrograman dan aplikasi pengolahan basis data Web server, sebagai penyimpan halaman web dan untuk menjalankan aplikasi sistem pakar diagnosis yang berbasis web.

f.

Analisis spesifikasi pemeliharaan 1. Update data-data terkait untuk pengembangan basis pengetahuan. 2. Debugging untuk memperbaiki kesalahan pengolahan data.

3.1.5

Identifikasi Sistem Struktur dan proses pada sistem pakar alarm gangguan BTS dapat terlihat

pada Gambar 3.1. Keluhan (gejala) (input)

Memori long-term Memori short-term Diagnosa

Basis Pengetahuan dan Aturan

Proses pengelompokkan keluhan/gejala berdasarkan Alarm BTS

Mekanisme Inferensi

Pengurutan data-data hasil pengelompokkan

Informasi (output)

Gambar 3.1 Struktur dan Proses Sistem Pakar Alarm Gangguan BTS Dilihat dari Gambar 3.1, memori long-term merupakan memori utama yang bersifat permanen yang berisikan data-data utama, seperti basis pengetahuan dan aturan serta mekanisme inferensi yang dipakai untuk penalaran dan penelusuran data. Sedangkan memori short-term yaitu memori yang digunakan pada saat berinteraksi langsung dengan sistem, memori ini akan hilang bila aplikasi ditutup. Memori short-term berisikan data-data yang dimasukkan oleh pengguna.

Dari struktur dan proses sistem yang ditunjukkan pada Gambar 3.1, dimulai saat pengguna memasukkan jenis alarm, selanjutnya sistem akan melakukan diagnosa dengan mengelompokkan data-data yang dimasukkan oleh pengguna kemudian membandingkan gejala-gejala yang ada dengan basis pengetahuan dan diolah sesuai dengan aturan/kaidah yang berlaku. Pada proses pengelompokkan gejala-gejala yang muncul dari BTS, sistem juga melakukan penghitungan nilai-nilai kemungkinan (probabilitas) gejala terhadap suatu alarm sehingga pada akhirnya didapat hasil diagnosa berupa informasi yang dibutuhkan. 3.1.6 Sumber Pengetahuan Untuk mendukung keakuratan system pakar yang penulis rancang dalam penarikan kesimpulan diperlukan sumber pengetahuan berupa data-data terkait bidang kepakarannya. Sumber pengetahuan dalam perancangan aplikasi system pakar untuk alarm gangguan BTS berbasis web ini diantaranya adalah sumber pengetahuan yang berasal dari dokumentasi para pakar dibidangnya, seperti buku, artikel, database, dan hasil konsultasi dengan pakar. Sumber pengetahuan yang berasal dari dokumentasi para pakar dibidang penanganan BTS seperti buku, artikel, database untuk mendukung dalam perancangan aplikasi system pakar ini memiliki beberapa criteria diantaranya: 1. berasal dari sumber yang jelas. 2. Berisikan tulisan-tulisan mengenai informasi seputar BTS, seperti informasi gangguan BTS, informasi gejala gangguan BTS, tata cara indentifikasi gangguan BTS, dan tata cara troubleshooting BTS. 3. Jika data berupa file database berisikan data-data alarm dan gejalanya serta keterkaitan antara keduanya.

3.2

Akuisisi Pengetahuan (Knowledge Acquisition) Akuisisi pengetahuan dilakukan untuk memperoleh pengetahuan dari

sumbernya, yang meliputi proses pengumpulan, pemindahan, dan pengubahan dari kemampuan seorang pakar dalam memecahkan masalah ke dalam bentuk program komputer untuk memperbaiki atau mengembangkan basis pengetahuan system. Yang selanjutnya disusun berdasarkan: 1. 2. 3. 4. Kode Alarm Tipe alarm Gejala Kerusakan Solusi / Troubleshooting Selanjutnya akan dijelaskan hasil dari akuisisi pengetahuan yang disajikan dalam bentuk tabel.

Tabel 3.1 Hasil Akuisisi Pengetahuan

Kode Alarm G-001 G-002 G-003 G-004 Tipe Alarm Alarm: 1-9181 Alarm: 28-1251 Alarm: 1-1974 Alarm: 1-1745 Gejala kerusakan INS_SBY BDC tidak merespon BBXR Perangkat tidak bekerja saat temperature turun Terjadi kesalahan pada konfigurasi system - Performansi kerja BTS menurun - Suhu Ruangan dibawah 5 derajat celcius - Muncul sinyal pada Thermal Management System G-005 G-006 G-007 G-008 G-009 Alarm: 17-1312 Alarm: 35-17320 Alarm: 35-1711 Alarm: 28-24440 Alarm: 28-1754 - Terdapat Alarm pada clock 19 MHz - Hanya mesin BBX yanga mengirim alarm - Pada report alarm tertulis pada kolom oper disabled - MSIP berhenti menerima clock - GCLK tidak berfungsi - Muncul Report berulang-ulang Ada masalah pada battery Loss pada relay contact alarms - Cek Performance Battery - Segera ganti battery jika battery rusak, voltase lemah Re-insert AMR Replace GCLK Solusi/Troubleshooting Cek diindikator perangkat lunak pada modul mesin BTS Tambahkan perangkat weather untuk mengantisipasi penurunan temperature Konfigurasi ulang system BTS dengan melakukan search fault - Periksa pendingin mesin BTS, jika ada kerusakan segera di ganti - Periksa Thermal Management System - Periksa CCD kemungkinan terjadi kesalahan setting - Apabila mesin BBX rusak, harus segera di ganti Ganti board MSIP device

Tabel 3.2 Hasil Akuisisi Pengetahuan (lanjutan)

Kode Alarm G-010 G-011 G-012 G-013 Tipe Alarm Alarm: 1-1851 Alarm: 1-1750 Alarm: 1-1428 Alarm: 34-6790 Gejala kerusakan Kapasitas backhauld overload Alarm pintu menyala Ada masalah pada system - GLI tidak dapat berkomunikasi dengan router yang aktif - Router BTS rusak G-014 Alarm: 23-2276 - Control Card tidak terkonek dengan baik - MGLIs, GLIs, atau MAWIs tidak terkonek dengan baik G-015 Alarm: 22-1973 - Tertulis sector ke-n pada additional text di report alarm - Terjadi penurunan sensitivitas pada salah satu sector - Cek sector yang terdeteksi failure - Reset ulang sector - Cek MGLIs, GLIs, atau MAWIs harus terkoneksi - Jika sudah terkoneksi, Repairs Network Connection Solusi/Troubleshooting Kosongkan Temp pada mesin backhauld Periksa pintu mesin BTS Periksa system kontroling - Coba selidiki Jaringan LAN - Ganti Router BTS

BAB IV DESAIN SISTEM

4.1

Representasi Pengetahuan Dalam perancangan aplikasi sistem pakar alarm gangguan BTS, penulis

memilih model kaidah produksi untuk merepresentasi pengetahuan yang di dapat. Kaidah produksi digunakan karena menghubungkan langsung antara sebab dan akibat. Sesuai dengan teknik diagnosis, dimana menghubungkan secara langsung kondisi objek dan konsekuensi tindakan yang harus dilakukan terhadap objek. Kondisinya berupa data gangguan alarm, data gejala, serta data solusi/troubleshooting sedangkan konsekuensinya berupa hasil diagnosa berdasarkan ciri kerusakan yang di dapat. Sebelum sampai pada bentuk kaidah produksi, terdapat langkah-langkah yang harus ditempuh, yaitu menyajikan pengetahuan yang berhasil didapatkan dalam bentuk tabel keputusan (decision table) kemudian dari tabel keputusan dibuat pohon keputusan (decision tree) (Hartati dan Iswanti, 2008). 4.1.1 Tabel Keputusan Berikut disajikan tabel-tabel keputusan yang dikelompokkan berdasarkan hubungan setiap atribut yang dimilikinya. 1. Keputusan berdasarkan gangguan alarm. Untuk lebih jelasnya dapat dilihat pada Tabel 4.1

78

Tabel 4.1 Keputusan Berdasarkan Gangguan Alarm Level Alarm Tipe Alarm G001 G002 G003 G004 G005 G006 G007 G008 G009 G010 G011 G012 G013 G014 G015 Keterangan: Level Alarm (dikodekan dengan inisial angka 1, 2, dan 3) 1 2 3 : Level Minor : Level Mayor : Level Kritis 1 2 3

Tipe Alarm (dikodekan dengan inisial huruf G) G001 G002 G003 G004 G005 G006 G007 G008 G009 : Alarm: 1-9181 : : : : : : : : Alarm: 28-1221 Alarm: 1-1974 Alarm: 1-1745 Alarm: 17-1312 Alarm: 35-17320 Alarm: 35-1711 Alarm: 28-24440 Alarm: 28-1754

79

G010 G011 G012 G013 G014 G015

: : : : : :

Alarm: 1-1851 Alarm: 1-1750 Alarm: 1-1428 Alarm: 34-6790 Alarm: 23-2276 Alarm: 22-1973

2. Keputusan berdasarkan Gejala. Untuk lebih jelasnya dapat dilihat pada Tabel 4.2

80 Tabel 4.2 Keputusan Berdasarkan Gejala

Jenis Alarm Gejala C001 C002 C003 C004 C005 C006 C007 C008 C009 C010 C011 C012 C013 C014 C015 C016 C017 C018 C019 C020 C021 C022 G001 G002 G003 G004 G005 G006 G007 G008 G009 G010 G011 G012 G013 G014 G-015

80

81

Keterangan : Jenis Gangguan (dikodekan dengan inisial huruf G) Mengacu pada keterangan Tabel 4.1 Gejala (dikodekan dengan Inisial C) C001 C002 C003 C004 C005 C006 C007 C008 C009 C010 C011 C012 C013 C014 C015 C016 C017 C018 C019 C020 C021 C022 : INS_SBY BDC tidak merespon BBXR : Perangkat tidak bekerja saat temperature turun : Terjadi kesalahan pada konfigurasi system : Performansi kerja BTS menurun : Suhu Ruangan dibawah 5 derajat celcius : Muncul sinyal pada Thermal Management System : Terdapat Alarm pada clock 19 MHz : Hanya mesin BBX yanga mengirim alarm : Pada report alarm tertulis pada kolom oper disabled : MSIP berhenti menerima clock : GCLK tidak berfungsi : Ada masalah pada battery : Loss pada relay contact alarms : Kapasitas backhauld overload : Alarm pintu menyala : Ada masalah pada system : GLI tidak dapat berkomunikasi dengan router yang aktif : Router BTS rusak : Control Card tidak terkonek dengan baik : MGLIs, GLIs, atau MAWIs tidak terkonek dengan baik : Tertulis sector ke-n pada additional text di report alarm : Terjadi penurunan sensitivitas pada salah satu sector

82

3. Keputusan berdasarkan gangguan dan solusi. Solusi dari setiap ciri kerusakan disini memiliki nilai yang konstan, dalam artian setiap ciri kerusakan memiliki solusinya masing-masing. Berikut penjelasan dari setiap solusi : Solusi C001 Solusi C002 Solusi C003 Solusi C004 : : : : Cek diindikator perangkat lunak pada modul mesin BTS Tambahkan perangkat weather untuk mengantisipasi penurunan temperature Konfigurasi ulang system BTS dengan melakukan search fault - Periksa pendingin mesin BTS, jika ada kerusakan segera di ganti - Periksa Thermal Management System Solusi C005 : : : : : : : : : : : - Periksa CCD kemungkinan terjadi kesalahan setting - Apabila mesin BBX rusak, harus segera di ganti Solusi C006 Solusi C007 Solusi C008 Solusi C009 Solusi C010 Solusi C011 Solusi C012 Solusi C013 Solusi C014 Solusi C015 Ganti board MSIP device Replace GCLK - Cek Performance Battery - Segera ganti battery jika battery rusak, voltase lemah Re-insert AMR Kosongkan Temporary pada mesin backhauld Periksa pintu mesin BTS Periksa system kontroling - Coba selidiki Jaringan LAN - Ganti Router BTS - Cek MGLIs, GLIs, atau MAWIs harus terkoneksi - Jika sudah terkoneksi, Repairs Network Connection - Cek sector yang terdeteksi failure - Reset ulang sector

83

4.1.2

Pohon Keputusan Pohon keputusan dirancang dengan maksud untuk mengetahui atribut

(kondisi) yang dapat direduksi sehingga menghasilkan kaidah yang efisien dan optimal sebagaimana terlihat pada Gambar 4.1.

84

Gambar 4.1 Pohon Keputusan Diagnosis Alarm Gangguan

84

85

Keterangan Gambar 4.1 : G C Solusi y t * : Tipe Alarm (mengacu pada keterangan tabel 4.2) : Gejala (mengacu pada keterangan tabel 4.2) : Mengacu pada penjelasan solusi yang ada pada point 3 sub bab 4.1.1 : Ya : Tidak : Gejala dari tipe alarm tidak ditemukan

4.1.3

Kaidah-kaidah dalam Bentuk Kaidah Produksi Pohon keputusan yang dihasilkan pada pembahasan sebelumnya

digunakan sebagai acuan dalam menyusun kaidah/aturan, sedangkan atribut di dalam tabel keputusan menjadi premis di dalam kaidah/aturan yang direpresentasikan. Berikut ini adalah daftar kaidah/aturan diagnosis alarm gangguan BTS berdasarkan tipe alarm dan gejalanya yang dapat dilihat pada Tabel 4.3. Tabel 4.3 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS Kaidah / Aturan IF Tipe Alarm = Alarm:1-9181 IF ELSE IF Tipe Alarm = Alarm:28-1251 IF Gejala Perangkat tidak bekerja saat temperature turun THEN Pilih Gejala Kerusakan THEN Solusi Tambahkan perangkat weather untuk mengantisipasi penurunan temperature Gejala INS_SBY BDC tidak merespon BBXR THEN Pilih Gejala Kerusakan THEN Solusi Cek diindikator perangkat lunak pada modul mesin BTS

86

Tabel 4.4 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) Kaidah / Aturan ELSE IF Tipe Alarm = Alarm: 1-1974 IF fault ELSE IF Tipe Alarm = Alarm: 1-1745 IF OR OR ganti AND Konfigurasi ulang system BTS dengan melakukan search fault ELSE IF Tipe Alarm = Alarm: 17-1312 IF OR Gejala Terdapat Alarm pada clock 19 MHz Gejala Hanya mesin BBX yanga mengirim alarm THEN Pilih Gejala Kerusakan Gejala Performansi kerja BTS menurun Gejala Suhu Ruangan dibawah 5 derajat celcius Gejala Muncul sinyal pada Thermal Management System THEN Pilih Gejala Kerusakan Gejala Terjadi kesalahan pada konfigurasi system THEN Pilih Gejala Kerusakan THEN Solusi Konfigurasi ulang system BTS dengan melakukan search

THEN Solusi Periksa pendingin mesin BTS, jika ada kerusakan segera di

THEN Solusi Periksa CCD kemungkinan terjadi kesalahan setting AND Apabila mesin BBX rusak, harus segera di ganti ELSE IF Tipe Alarm = Alarm: 35-17320 IF OR Gejala Pada report alarm tertulis pada kolom oper disabled Gejala MSIP berhenti menerima clock THEN Pilih Gejala Kerusakan

87

Tabel 4.5 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) Kaidah / Aturan THEN Solusi Ganti board MSIP device ELSE IF Tipe Alarm = Alarm: 35-1711 IF OR ELSE IF Tipe Alarm = Alarm: 28-24440 IF Gejala Ada masalah pada battery THEN Pilih Gejala Kerusakan THEN Solusi Cek Performance Battery AND Segera ganti battery jika battery rusak, voltase lemah ELSE IF Tipe Alarm = Alarm: 28-1754 IF ELSE IF Tipe Alarm = Alarm: 1-1851 IF ELSE IF Tipe Alarm = Alarm: 1-1750 THEN Pilih Gejala Kerusakan Gejala Kapasitas backhauld overload THEN Pilih Gejala Kerusakan THEN Solusi Kosongkan Temp pada mesin backhauld Gejala Loss pada relay contact alarms THEN Pilih Gejala Kerusakan THEN Solusi Re-insert AMR Gejala GCLK tidak berfungsi Gejala Muncul Report berulang-ulang THEN Pilih Gejala Kerusakan

THEN Solusi Replace GCLK

88

Tabel 4.6 Kaidah Produksi Sistem Pakar Alarm Gangguan BTS (Lanjutan) Kaidah / Aturan IF ELSE IF Tipe Alarm = Alarm:1-1428 IF ELSE IF Tipe Alarm = Alarm: 34-6790 IF OR Gejala GLI tidak dapat berkomunikasi dengan router yang aktif Gejala Router BTS rusak THEN Pilih Gejala Kerusakan Gejala Ada masalah pada system THEN Pilih Gejala Kerusakan THEN Solusi Periksa system kontroling Gejala Alarm pintu menyala THEN Solusi Periksa pintu mesin BTS

THEN Solusi Coba selidiki Jaringan LAN AND Ganti Router BTS ELSE IF Tipe Alarm = Alarm: 23-2276 THEN Pilih Gejala Kerusakan IF OR Gejala Control Card tidak terkonek dengan baik Gejala MGLIs, GLIs, atau MAWIs tidak terkonek dengan baik

THEN Solusi Cek MGLIs, GLIs, atau MAWIs harus terkoneksi AND Jika sudah terkoneksi, Repairs Network Connection ELSE IF Tipe Alarm = Alarm: 22-1973 IF OR Gejala Tertulis sector ke-n pada additional text di report alarm Gejala Terjadi penurunan sensitivitas pada salah satu sector THEN Pilih Gejala Kerusakan

THEN Solusi Cek sector yang terdeteksi failure AND Reset ulang sector

90

4.2 Pengembangan Mesin Inferensi Mesin inferensi merupakan komponen sistem pakar yang memanipulasi dan mengarahkan pengetahuan dari basis pengetahuan, sehingga tercapai kesimpulan. Berikut ini tahapan pengembangan mesin inferensi dalam perancangan aplikasi sistem pakar untuk alarm gangguan BTS dimulai dengan pemilihan teknik inferensi dan teknik penelusuran data. 4.2.1 Pemilihan Teknik Inferensi Mekanisme inferensi yang dilakukan dalam proses diagnosis dan penentuan alarm gangguan BTS ini adalah backward chaining (penalaran dimulai dari hipotesis kemudian dicari fakta-fakta yang ada dalam basis pengetahuan). Alasan utama penggunaan mekanisme inferensi ini adalah agar proses penemuan solusi dapat berlangsung lebih cepat. Sehingga bila pengguna sudah memiliki hipotesis mengenai trouble yang dialami, sistem akan menggunakan inferensi backward chaining, untuk membuktikan dugaan tersebut. Jika hipotesis tidak terbukti, maka sistem akan menanyakan kemungkinan adanya hipotesis lain, untuk dibuktikan kembali kebenarannya. Setiap informasi yang diperoleh dari pengguna akan disimpan oleh sistem, sehingga sistem tidak akan mengajukan pertanyaan yang sama lebih dari sekali.
Hipotesa

Ciri Kerusakan

Kesimpulan

Data Gejala

Penentuan Diagnosa

Gambar 4.2 Penerapan Inferensi Runut Balik (Backward Chaining)

90

4.2.2

Teknik Penelusuran Data Dalam pengembangan mesin inferensi setelahnya dilakukan teknik

inferensi dengan runut balik (backward chaining), maka dalam implementasinya teknik tersebut memerlukan suatu teknik penelusuran data pencarian fakta-fakta yang dimasukkan oleh pengguna yang sesuai dengan basis pengetahuan untuk mendapatkan solusi yang sesuai. Teknik ini digambarkan melalui node-node dimulai dari level atas sampai bawah. Seperti yang terlihat pada Gambar 4.3.

Diagnosa alarm gangguan BTS

Tipe alarm 2

Gejala Kerusakan ke1

Gejala Kerusakan ken

3 4 Hasil

Gambar 4.3 Teknik Penelusuran Data. 4.3 Perancangan Basis Data Basis data merupakan tahapan yang penting dalam perancangan suatu aplikasi berbasis komputer. Dalam aplikasi sistem pakar yang penulis rancang, basis data dapat berperan sebagai basis pengetahuan, yaitu tempat penyimpanan dan pengolahan data-data kepakaran dan aturan yang berhubungan dengan diagnosis alarm gangguan BTS.

91

4.3.1

Identifikasi Bussiness Activity Dalam implementasi sistem pakar yang dirancang diperuntukkan bagi

4.3.1.1 Batasan Sistem seorang teknisi untuk melakukan pencarian solusi troubleshooting terhadap alarm yang muncul. 4.3.1.2 Bagan Organisasi Perancangan dan implementasi sistem pakar alarm gangguan BTS yang dibangun melibatkan tiga aktor penting, yaitu pakar, knowledge engineering, dan pemakai (teknisi) itu sendiri. Secara jelas keterhubungan ketiganya dapat dilihat pada Gambar 4.4. Pakar

Knowledge Engineering

Pemakai (Teknisi) Gambar 4.4 Hubungan Tiga Aktor pada Perancangan Sistem Pakar Alarm Gangguan Base Transceiver Station 4.3.1.3 Deskripsi Proses Pada perancangan sistem pakar alarm ganggauan BTS yang dibuat terdiri atas tiga bagian input-proses-output. Untuk lebih jelasnya dapat digambarkan pada Gambar 4.5 sebagai berikut.

Input

Sistem Pakar Gambar 4.5 Skema Sistem Pakar

Output

92

Pada gambar tersebut terdapat 3 komponen yang sangat menentukan dalam perancangan sistem pakar tersebut. 1. Input : Input dalam sistem pakar ini dapat berupa gangguan yang ada dari mesin BTS. 2. Sistem pakar : Oleh karena masukan berupa gangguan dari mesin BTS, maka sistem pakar harus mampu mengolah, menelusuri dan mendiagnosa gejala-gejala tersebut dengan berbagai metode representasi digunakan. 3. Output : Dari hasil penelusuran data yang dilakukan oleh sistem pakar, maka keluaran hasil dapat berupa solusi dalam bentuk saran untuk tindakan dari seorang pakar Pada bagian sistem pakar, perancangan dilakukan setelah menggunakan akuisisi pengetahuan dari pakar, maka dilanjutkan dengan representasi pengetahuan dan mengembangkannya dengan mesin inferensi yang sesuai dengan kebutuhan sistem. Sesuai dengan keadaan diatas, maka rancangan sistem pakar dapat digambarkan pula seperti pada Gambar 4.6 Gejala Solusi pengetahuan dan mesin inferensi yang

Diagnosa

Gambar 4.6 Skema Diagnosis Alarm Gangguan Base Transceiver Station 4.3.1.4 Flow Map (Bagan Alir) Berikut ini dekripsi aplikasi sistem pakar yang penulis rancang dalam mendiagnosis alarm gangguan BTS, dapat dilihat pada Gambar 4.7.

93

Gambar 4.7 Flowmap Aplikasi Sistem Pakar Alarm Gangguan Base Transceiver Station

94

4.3.2

Diagram Konteks
Informasi Hasil Diagnosa Daftar Basis Pengetahuan dan Daftar Basis Aturan

Pemakai

Sistem Pakar Alarm Gangguan BTS

Pakar

Penelusuran

Gejala

Data Basis Pengetahuan dan Data Aturan

Gambar 4.8 Diagram Konteks Sistem Pakar Alarm Gangguan Base Transceiver Station

95

4.3.2.1 DFD Level 0

Gambar 4.9 DFD Level 0 Aplikasi Sistem Pakar Alarm Gangguan BTS

96

4.3.2.2

DFD Level 1 Subproses Login

Data Pakar

1.1 Input data Login

Nama dan Password 1.2 Validasi Login

Pakar

User

Info user

Info Validasi user

Gambar 4.10 DFD Level 1 Subproses login Dari gambar 4.10 dapat diketahui proses dan arus data yang terjadi pada DFD level 1 subproses login yang selanjutnya disajikan dalam bentuk tabel yaitu pada Tabel 4.7 dan Tabel 4.8. Tabel 4.7 Spesifikasi Proses DFD level 1 subproses login

No
1

Proses
Proses 1.1 Input data login

Data Masuk
Data user

Data Keluar
Nama dan password

Keterangan
Pakar mempunyai hak mengelola aplikasi dan manipulasi kepakaran

Sumber
Database (User)

Proses 1.2 Nama dan Validasi login password

Info validasi user

Validasi dengan membandingkan data input-an dan data pakar yang ada dalam database

Database (User)

97

Tabel 4.8 Arus Data DFD level 1 sub proses login No Nama Aliran Data 1 Data Pakar Item Data = {Nama+Password}

4.3.2.3

DFD level 1 Subproses Pengelolaan Basis Pengetahuan

Gambar 4.11 DFD Level 1 Subproses Pengelolaan Basis Pengetahuan Dari Gambar 4.11 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 1 subproses pengelolaan basis pengetahuan dan aturan yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.9 dan Tabel 4.10.

98

Tabel 4.9 Spesifikasi Proses DFD Level 1 Subproses Pengelolaan Basis Pengetahuan.

No
1

Proses
Proses 2.1 Kelola macam gangguan

Data Masuk
Data macam gangguan Daftar macam gangguan

Data Keluar
Daftar macam gangguan Data macam gangguan

Keterangan
Data macam gangguan dari gangguan mesin BTS yang didiagnosa oleh sistem Data jenis gejala dari gejala mesin BTS yang didiagnosa oleh sistem

Sumber
Database (gangguan)

Proses 2.2 Kelola jenis gejala

Data jenis gejala Daftar jenis gejala Data nama solusi Daftar nama solusi

Daftar jenis gejala Data jenis gejala Daftar nama solusi Data nama solusi

Database (gejala)

Proses 2.3 Kelola nama solusi

Data nama solusi Database dari struktur solusi yang didiagnosa oleh sistem (solusi)

Tabel 4.10 Arus Data DFD Level 1 Subproses Pengelolaan Basis Pengetahuan No Nama Aliran Data 1 2 3 Data macam gangguan Data jenis gejala Data nama solusi = = = Item Data {kode+tipe_alarm+deskripsi+level} {tipe_alarm+gejala+pertanyaan} {tipe_alarm+system_action+operator_action}

99

4.3.2.4

DFD Level 2 Subproses Kelola Data Gangguan

Gambar 4.12 DFD Level 2 Subproses Kelola Data Gangguan Dari Gambar 4.14 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 2 subproses kelola data gangguan yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.11 dan Tabel 4.12. Tabel 4.11 Spesifikasi Proses DFD Level 2 Subproses Kelola Data Gangguan No 1 Proses Proses 3.1 Tambahkan data gangguan Data Masuk Data macam gangguan Data Keluar Data macam gangguan Keterangan Data macam gangguan yang ditambahkan oleh pakar ke basis pengetahuan Sumber Database (gangguan)

100

Proses 3.2 Tampilkan data macam gangguan

Daftar macam gangguan

Daftar macam gangguan

Data macam gejala yang terdaftar dalam basis pengetahuan

Database (gangguan)

Proses 3.3 Edit data macam gangguan

Data macam gangguan

Data macam gangguan yang diedit

Data macam gejala yang akan diedit dari basis pengetahuan Data macam gangguan yang akan dihapus dari basis pengetahuan

Database (gangguan)

Proses 3.4 Hapus data macam gangguan

Data macam gangguan

Data macam gangguan terhapus

Database (gangguan)

Tabel 4.12 Arus Data DFD Level 2 Subproses Kelola Macam Gejala No Nama Aliran Data 1 Data macam gangguan = Item Data {kode+tipe_alarm+deskripsi+level}

101

4.3.2.5

DFD Level 2 Subproses Kelola Data Gejala

Gambar 4.13 DFD Level 2 Subproses Kelola Data Gejala Dari Gambar 4.13 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 2 subproses kelola data gejala yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.13 dan Tabel 4.14.

102

Tabel 4.13 Spesifikasi Arus DFD Level 2 Subproses Kelola Data Gejala No 1 Proses Proses 4.1 Tambahkan data jenis gejala Data Masuk Data jenis gejala Data Keluar Data jenis gejala Keterangan Data jenis gejala yang ditambahkan oleh pakar ke basis pengetahuan 2 Proses 4.2 Tampilkan data jenis gejala 3 Proses 4.3 Edit data jenis gejala Data jenis gejala Data jenis gejala yang diedit Daftar jenis gejala Daftar jenis gejala Data jenis gejala yang terdaftar dalam basis pengetahuan Data jenis gejala yang akan diedit dari basis pengetahuan 4 Proses 4.4 Hapus data jenis gejala Data jenis gejala Data jenis gejala Terhapus Data jenis gejala yang akan dihapus dari basis pengetahuan Tabel 4.14 Arus Data DFD Level 2 Subproses Kelola Data Gejala No Nama Aliran Data 1 Data jenis gejala = Item Data {tipe_alarm+gejala+pertanyaan} Database (gejala) Database (gejala) Database (gejala) Sumber Database (gejala)

103

4.3.2.6

DFD Level 2 Subproses Kelola Data Solusi

Gambar 4.14 DFD Level 2 Subproses Kelola Data Solusi Dari gambar 4.14 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 2 subproses kelola data jaringan yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.15 dan Tabel 4.16. Tabel 4.15 Spesifikasi Proses DFD Level 2 Subproses Kelola Data Solusi No 1 Proses Proses 5.1 Tambahkan data nama solusi Data Masuk solusi Data Keluar solusi Keterangan Data nama solusi yang ditambahkan oleh pakar ke basis pengetahuan Sumber Database (solusi, jaringan) Data nama Data nama

104

Proses 5.2 Tampilkan data nama solusi

Daftar nama solusi

Daftar

Data nama terdaftar dalam basis pengetahuan

Database (solusi, jaringan)

nama solusi solusi yang

Proses 5.3 Edit data nama solusi

Data nama Data nama solusi solusi yang diedit

Data nama solusiyang akan diedit dari basis pengetahuan

Database (solusi, jaringan)

Proses 5.4 Hapus data nama solusi

Data nama Data nama solusi solusi Terhapus

Data nama solusiyang akan dihapus dari basis pengetahuan

Database (solusi, jaringan)

Tabel 4.16 Arus Data DFD Level 2 Subproses Kelola Data Solusi No Nama Aliran Data Item Data 1 Data nama solusi = {tipe_alarm+system_action+operator_action}

105

4.3.2.7

DFD Level 1 Subproses Pengelolaan Basis Aturan

Gambar 4.15 DFD Level 1 Subproses Pengelolaan Basis Aturan Dari Gambar 4.16 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 1 subproses pengelolaan basis aturan yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.17 dan Tabel 4.28. Tabel 4.17 Spesifikasi Proses DFD Level 1 Subproses Pengelolaan Basis Aturan No 1 Proses Proses 6.1 Tambahkan data nama aturan Data Masuk aturan Data Keluar aturan Keterangan Data nama solusi yang ditambahkan oleh pakar ke Sumber Database (aturan) Data nama Data nama

106

basis pengetahuan 2 Proses 6.2 Tampilkan data nama aturan 3 Proses 6.3 Edit data nama aturan Data nama Data nama aturan aturan yang diedit Daftar nama aturan Daftar nama aturan Data nama aturan yang terdaftar dalam basis pengetahuan Data nama aturanyang akan diedit dari basis pengetahuan 4 Proses 6.4 Hapus data nama aturan Data nama Data nama aturan aturan Terhapus Data nama aturanyang akan dihapus dari basis pengetahuan Tabel 4.18 Arus DataDFD Level 1 Subproses Pengelolaan Basis Aturan No 1 Nama Aliran Data Data Aturan = {pertanyaan} Item Data Database (aturan) Database (aturan) Database (aturan)

107

4.3.2.8

DFD Level 1 Subproses Konsultasi

Gambar 4.16 DFD Level 1 Subproses Konsultasi Dari Gambar 4.19 dapat diketahui spesifikasi proses dan arus data yang terjadi pada DFD level 1subproses konsultasi yang selanjutnya disajikan dalam bentuk tabel yaitu Tabel 4.19 dan Tabel 4.20. Tabel 4.19 Spesifikasi Proses DFD Level 1 Subproses Konsultasi No 1 Proses Data Masuk Data Keluar Keterangan User memilih jawaban atas pertanyaan gejala yang diajukan sistem Sumber Database (aturan)

Proses 7.1 Data macam Data Menjawab gejala + kode_gejal pertanyaan jawaban user a sistem (Pilihan ya dan tidak terhadap pertanyaan

108

gejala yang diajukan sistem) kode_ganggu Info hasil an+ kode_gejala+ info gangguan+in fo gejala diagnosa

Proses 7.2 Mencari Kemungkina n Diagnosis

Sistem menentukan hasil diagnosa

Database (gangguan+ge jala+solusi)

Tabel 4.20 Arus DataDFD Level 1 Subproses Konsultasi No 1 2 3 Nama Aliran Data Data Gejala Data aturan Data Solusi 4.3.3 Kamus Data Kamus data atau data dictionary adalah suatu tempat penyimpanan yang berisi penjelasan atas objek data yang digunakan atau dihasilkan oleh sistem. Di bawah ini akan dijelaskan kamus data yang menyusun aplikasi sistem pakar alarm gangguan BTS yang disajikan dalam bentuk tabel. = = = Item Data {kd_pertanyaan+kd_gangguan+gejala+pertanyaan} {kd_aturan+kd_pertanyaan+jawaban+next+tipenext } {kd_solusi+kd_aturan+kd_pertanyaan+system+operator}

109

1. Tabel Gangguan Tabel 4.21 Kamus Data Tabel Gangguan NO FIELD 1 kd_gangguan 2 3 4 5 6 tipe penjelasan level example jenis TIPE Varchar Text Text Varchar Text Varchar PANJANG 10 255 255 30 255 30 KETERANGAN Kode Gangguan (Primary Key) Tipe alarm Penjelasan tentang alarm Tingkat level alarm Contoh format alarm Jenis alarm

2. Tabel Pertanyaan Tabel 4.22 Kamus Data Tabel Pertanyaan NO FIELD 1 kd_pertanyaan 2 3 4 kd_gangguan gejala pertanyaan TIPE Int Varchar Varchar Varchar PANJANG KETERANGAN 11 Kode pertanyaan (Primary Key) 10 255 255 Mengirim tipe alarm Gejala atau ciri-ciri dari suatu tipe alarm Pertanyaan untuk mengetahui adanya gejala tersebut

3. Tabel Solusi Tabel 4.23 Kamus Data Tabel Solusi NO FIELD 1 kd_solusi 2 kd_pertanyaan 3 kd_gangguan 4 sistem TIPE Int Int Varchar Varchar PANJANG 11 11 10 255 KETERANGAN Kode solusi (Primary Key) Kode pertanyaan Kode gangguan untuk menampilkan tipe alarm Menerangkan kondisi atau aksi yang dilakukan sistem/perangkat BTS saat terjadi alarm Operator action guna melakukan troubleshooting

operator

Varchar

255

110

4. Tabel Keterangan Tabel 4.24 Kamus Data Tabel Keterangan NO FIELD 1 id_keterangan 2 kd_solusi 3 foto TIPE Int Varchar Varchar PANJANG 11 10 255 KETERANGAN Id (Primary Key) Kode solusi Keterangan tambahan untuk operator action yang berbentuk picture

5. Tabel GoalSolusi Tabel 4.25 Kamus Data Tabel GoalSolusi NO FIELD 1 kd_goal 2 kd_pertanyaan 3 jawaban 4 goal TIPE Varchar Varchar Varchar Text PANJANG 20 20 20 255 KETERANGAN Kode goal (Primary Key) Kode pertanyaan Jawaban yang akan dipilih oleh user Output dari sistem

6. Tabel Aturan Tabel 4.26 Kamus Data Tabel Aturan NO 1 1 2 3 4 FIELD kd_aturan kd_pertanyaan jawaban next tipenext TIPE Int Varchar Varchar Varchar Varchar PANJANG 11 6 255 6 10 KETERANGAN Kode Aturan (Primary Key) Kode pertanyaan Alternatif jawaban Link ke pertanyaan berikut/solusi goal Tipe Link ke pertanyaan berikut/solusi goal

7. Tabel Teporary Tabel 4.27 Kamus Data Tabel Teporary NO 1 2 3 4 FIELD kode kd_pertanyaan jawaban id_user TIPE Int Varchar Varchar Int PANJANG 11 20 20 11 KETERANGAN Kode (Primary Key) Kode pertanyaan Jawaban ID User

111

8. Tabel User Tabel 4.28 Kamus Data Tabel User NO 1 2 3 4 5 4.3.4 FIELD kd_user nama_lengkap username password admin TIPE Int Varchar Varchar Varchar tinyint PANJANG 11 100 50 50 11 KETERANGAN Kode User (Primary Key) Kode pertanyaan Jawaban Kata sandi Tipe user

Struktur Menu Sistem Pakar Struktur menu digambarkan dalam dua lingkungan, yaitu : lingkungan

teknisi dan lingkungan pakar. Berikut gambaran struktur menu aplikasi sistem pakar alarm gangguan BTS yang dapat dilihat pada Gambar 4.17 dan Gambar 4.18. Struktur Menu di lingkungan Admin/Pakar
Sistem Pakar Alarm Gangguan BTS

Login

Home

Konsultasi

Penjelasan Aplikasi Lihat Hasil Konsultasi Cetak Hasil Konsultasi

Gambar 4.17 Struktur Menu Aplikasi Sistem Pakar Alarm Gangguan BTS Pada Lingkungan User

Struktur Menu di lingkungan Admin/Pakar

Sistem Pakar Alarm Gangguan BTS Login

Home

Basis Pengetahuan

Basis Aturan

Konsulltasi

User Account

Lihat Data Rule

Gangguan

Tambah Data Rule Lihat Data Gangguan Tambah Data Gangguan Ubah Data Gangguan Hapus Data Gangguan Cetak Data Gangguan Gejala Lihat Data Gejala Tambah Data Gejala Ubah Data Gejala Hapus Data Gejala Cetak Data Gejala Solusi Ubah Data Rule Hapus Data Rule Cetak Data Rule

Lihat Data Solusi Tambah Data Solusi Ubah Data Solusi Hapus Data Solusi Cetak Data Solusi

Gambar 4.18 Struktur Menu Aplikasi Sistem Pakar Alarm Gangguan BTS Pada Lingkungan Admin/Pakar

4.3.5

Entity relationship diagram (ERD) Entity relationship diagram sistem pakar untuk diagnosis alarm

gangguan BTS dapat dilihat pada Gambar 4.19.

Gambar 4.19 ERD Untuk Sistem Pakar Diagnosis Alarm Gangguan BTS 4.3.6 Transformasi ERD ke Basis Data Fisik Berikut ini akan disajikan transformasi ERD ke dalam basis data fisik. Setiap himpunan entitas akan diimplementasikan sebagai sebuah tabel (file data). a. Tabel-tabel utama Tabel-tabel utama yang dimaksud merupakan tabel-tabel yang saling berelasi secara langsung antara satu dan yang lainnya di dalam implementasi perancangan basis data, tabel-tabel tersebut diantaranya : 1. Tabel Aturan 2. Tabel Gangguan 3. Tabel Pertanyaan 4. Tabel Solusi 5. Tabel GoalSolusi

b. Tabel tambahan Tabel tambahan yang dimaksud merupakan tabel yang berdiri sendiri dan tidak berelasi dengan tabel lainnya di dalam implementasi perancangan basis data, tabel tersebut yaitu : 1. Tabel User 4.3.7 Normalisasi dengan Ketergantungan Fungsional Dalam persfektif normalisasi sebuah basis data dapat dikatakan baik jika setiap tabel yang menjadi unsur pembentuk basis data tersebut juga telah berada dalam keadaan normal. Selanjutnya sebuah tabel dapat diketegorikan baik atau efisien jika telah memenuhi tiga kriteria lossless join decompotion, terpeliharanya ketergantungan fungsional dan BCNF. Ketergantungan fungsional biasanya dinyatakan dalam aljabar logika dengan menerapkan sejumlah aksioma atau teorema matematis. Akan tetapi penulis akan menyatakan dalam bentuk diagram supaya lebih mudah dimengerti hasil normalisasinya. 4.3.7.1 Tabel Gangguan Tabel 4.29 Normalisasi Tabel Gangguan
Kode Alarm G001 G002 G003 G004 G005 G006 G007 G008 Tipe Alarm Alarm: 19181 Alarm: 281221 Alarm: 11974 Alarm: 11745 Alarm: 171312 Alarm: 3517320 Alarm: 351711 Alarm: 2824440 Deskripsi BDCI Not to BBXR Excessive Errors Responding LAN Bit Level Minor Minor Minor Minor Minor Mayor Mayor Mayor Contoh Kerusakan Muncul Report berulang-ulang Perangkat tidak bekerja saat temperature turun Terjadi kesalahan pada konfigurasi system Performansi kerja BTS menurun Hanya mesin BBX yanga mengirim alarm Pada report alarm tertulis pada kolom oper disabled GCLK tidak berfungsi Ada masalah pada batery Jenis Alarm BTS Hardware BTS Hardware Power Amplifier BTS Hardware BTS Hardware Timing Timing BTS Hardware

Thermal management subsystem equipage mismatch Low BTS Temperature BBX 19 Failure Mhx Clock

MSIP Out-of-ServiceClock A signal Lost (GCLK to MSIP GCLK Out-of-serviceClock Output Failure Environment Fault, Bus Under Voltage Threshold Exceeded

G009 G010 G011 G012

Alarm: 1754 Alarm: 1851 Alarm: 1750 Alarm: 1428

28111-

AMR Communications Fault Voice Call Overload Door Open GLI SPAN A - Framed AIS Alarm: OOS Threshold Exceeded RAN Unreachable-No Default Route to Backbone BTSLINK Terminates on a Segmented Device SIF Multicoupler Soft Failure Alarm

Mayor Mayor Kritis Kritis

Loss pada relay contact alarms Kapasitas backhauld overload Alarm pintu menyala Ada masalah pada system Router BTS rusak Control Card tidak terkonek dengan baik Terjadi penurunan sensitivitas pada salah satu sector

Link Customer BTS Hardware Span

G013 G014 G015

Alarm: 346790 Alarm: 232276 Alarm: 221973

Kritis Kritis Kritis

BTS Hardware BTS Hardware Span

1. Normalisasi 1 (1NF) Berdasarkan atribut yang ada di Tabel 4.29, tidak terdapat atribut komposit atau atribut bernilai jamak. Syarat dari normalisasi tahap 1 (1NF) adalah menghilangkan atribut bernilai ganda (multivalue). Maka syarat normalisasi 1 (1NF) terpenuhi pada tabel gangguan. 2. Normalisasi 2 (2NF) Syarat dari normalisasi tahap 2 (2NF) adalah terpenuhinya tahap 1 (1NF) serta semua atribut bukan kunci harus bergantung fungsional penuh terhadap kunci field. Dari Tabel 4.29 terlihat bahwa atribut bukan utama (Tipe, deskripsi, level, example, jenis) bergantung fungsional terhadap atribut Kode Alarm. Maka normalisasi tahap 2 terpenuhi. 3. Normalisasi 3 (3NF) Suatu tabel berada dalam bentuk normal ketiga adalah jika berada dalam bentuk normal kedua dan tidak dijumpai ketergantungan transitif. Ketergantungan transitif dalam suatu tabel adalah ketergantungan fungsional antara 2 (atau lebih) atribut bukan kunci. Dari Tabel 4.29 selain sudah terpenuhi normalisasi tahap 2 juga tidak ada ketergantungan fungsional antara atribut-atribut bukan kunci, maka normalisasi tahap 3 sudah terpenuhi.

4.3.7.2 Tabel Pertanyaan Tabel 4.30 Normalisasi Tabel Pertanyaan

Kd_perta nyaan
18 19 20 21 23

Kd_Gangguan
G-001 G-002 G-003 G-004 G-005

Gejala
INS_SBY BDC tidak merespon BBXR Perangkat tidak bekerja saat temperature turun Terjadi kesalahan pada konfigurasi system Performansi kerja BTS menurun Suhu Ruangan dibawah 5 derajat celcius

Pertanyaan
Apakah INS_SBY BDC tidak merespon BBXR? Apakah Perangkat tidak bekerja saat temperature turun? Apakah Terjadi kesalahan pada konfigurasi system? Apakah Performansi kerja BTS menurun? Apakah Suhu Ruangan dibawah 5 derajat celcius?

1. Normalisasi 1 (1NF) Berdasarkan atribut yang ada di Tabel 4.30, tidak terdapat atribut komposit atau atribut bernilai jamak. Syarat dari normalisasi tahap 1 (1NF) adalah menghilangkan atribut bernilai ganda (multivalue). Maka syarat normalisasi 1 (1NF) terpenuhi pada tabel pertanyaan. 2. Normalisasi 2 (2NF) Syarat dari normalisasi tahap 2 (2NF) adalah terpenuhinya tahap 1 (1NF) serta semua atribut bukan kunci harus bergantung fungsional penuh terhadap kunci field. Dari Tabel 4.30 terlihat bahwa atribut bukan utama (kd_gangguan, gejala, pertanyaan) bergantung fungsional terhadap atribut kd_pertanyaan. Maka normalisasi tahap 2 terpenuhi. 3. Normalisasi 3 (3NF) Suatu tabel berada dalam bentuk normal ketiga adalah jika berada dalam bentuk normal kedua dan tidak dijumpai ketergantungan transitif. Ketergantungan transitif dalam suatu tabel adalah ketergantungan fungsional antara 2 (atau lebih) atribut bukan kunci. Dari Tabel 4.30 selain sudah terpenuhi normalisasi tahap 2 juga tidak ada ketergantungan fungsional antara atribut-atribut bukan kunci, maka normalisasi tahap 3 sudah terpenuhi.

4.3.7.1

Tabel Aturan Tabel 4.31 Normalisasi Tabel Aturan

Kd_aturan
25 26 27 29 30

Kd_pertanyaan
18 19 20 21 23

jawaban
Ya Ya Ya Ya Ya

next
10 11 12 17 18

tipenext
S S S S S

1. Normalisasi 1 (1NF) Berdasarkan atribut yang ada di Tabel 4.31, tidak terdapat atribut komposit atau atribut bernilai jamak. Syarat dari normalisasi tahap 1 (1NF) adalah menghilangkan atribut bernilai ganda (multivalue). Maka syarat normalisasi 1 (1NF) terpenuhi pada tabel aturan. 2. Normalisasi 2 (2NF) Syarat dari normalisasi tahap 2 (2NF) adalah terpenuhinya tahap 1 (1NF) serta semua atribut bukan kunci harus bergantung fungsional penuh terhadap kunci field. Dari Tabel 4.31 terlihat bahwa atribut bukan kunci (kd_pertanyaan, jawaban, next, tipenext) bergantung fungsional terhadap atribut kd_aturan. Maka normalisasi tahap 2 terpenuhi. 3. Normalisasi 3 (3NF) Suatu tabel berada dalam bentuk normal ketiga adalah jika berada dalam bentuk normal kedua dan tidak dijumpai ketergantungan transitif. Ketergantungan transitif dalam suatu tabel adalah ketergantungan fungsional antara 2 (atau lebih) atribut bukan kunci. Dari Tabel 4.31 selain sudah terpenuhi normalisasi tahap 2 juga tidak ada ketergantungan fungsional antara atribut-atribut bukan kunci, maka normalisasi tahap 3 sudah terpenuhi.

4.3.7.2

Tabel Solusi Tabel 4.32 Normalisasi Tabel Solusi Kd_gangguan

G-001 19 12 17 21 G-004 G-002 -

Kd_solusi Kd_pertanyaan
10 11 18

system

operator
Cek diindikator perangkat lunak pada modul mesin BTS Tambahkan perangkat weather untuk mengantisipasi penurunan temperature Konfigurasi ulang system BTS dengan melakukan search fault Periksa pendingin mesin BTS, jika ada kerusakan segera di ganti dan Periksa Thermal Management System

20

G-003

18 23 G-004

Periksa pendingin mesin BTS, jika ada kerusakan segera di ganti dan Periksa Thermal Management Sys

1. Normalisasi 1 (1NF) Berdasarkan atribut yang ada di Tabel 4.32, tidak terdapat atribut komposit atau atribut bernilai jamak. Syarat dari normalisasi tahap 1 (1NF) adalah menghilangkan atribut bernilai ganda (multivalue). Maka syarat normalisasi 1 (1NF) terpenuhi pada tabel jaringan. 2. Normalisasi 2 (2NF) Syarat dari normalisasi tahap 2 (2NF) adalah terpenuhinya tahap 1 (1NF) serta semua atribut bukan kunci harus bergantung fungsional penuh terhadap kunci field. Dari Tabel 4.32 terlihat bahwa atribut bukan kunci (kd_pertanyaan, kd_gangguan, system, operator) bergantung fungsional terhadap atribut kd_solusi. Maka normalisasi tahap 2 terpenuhi. 3. Normalisasi 3 (3NF) Suatu tabel berada dalam bentuk normal ketiga adalah jika berada dalam bentuk normal kedua dan tidak dijumpai ketergantungan transitif. Ketergantungan transitif dalam suatu tabel adalah ketergantungan fungsional antara 2 (atau lebih) atribut bukan kunci. Dari Tabel 4.32 selain sudah

terpenuhi normalisasi tahap 2 juga tidak ada ketergantungan fungsional antara atribut-atribut bukan kunci, maka normalisasi tahap 3 sudah terpenuhi. 4.3.7.3 Tabel User Tabel 4.33 Tabel User Kd_user Nama_lengkap 1 2 1. Team CBSC Jakarta OM Priangan Timur Normalisasi 1 (1NF) Berdasarkan atribut yang ada di Tabel 4.33, tidak terdapat atribut komposit atau atribut bernilai jamak. Syarat dari normalisasi tahap 1 (1NF) adalah menghilangkan atribut bernilai ganda (multivalue). Maka syarat normalisasi 1 (1NF) terpenuhi pada tabel analisa hasil. 2. Normalisasi 2 (2NF) Syarat dari normalisasi tahap 2 (2NF) adalah terpenuhinya tahap 1 (1NF) serta semua atribut bukan kunci harus bergantung fungsional penuh terhadap kunci field. Dari Tabel 4.33 terlihat bahwa semua atribut bukan kunci (nama_lengkap, username, password, admin) bergantung fungsional terhadap atribut kd_user. Maka normalisasi tahap 2 terpenuhi. 3. Normalisasi 3 (3NF) Suatu tabel berada dalam bentuk normal ketiga adalah jika berada dalam bentuk normal kedua dan tidak dijumpai ketergantungan transitif. Ketergantungan transitif dalam suatu tabel adalah ketergantungan fungsional antara 2 (atau lebih) atribut bukan kunci. Dari Tabel 4.33 selain sudah terpenuhi normalisasi tahap 2 juga tidak ada ketergantungan fungsional antara atribut-atribut bukan kunci, maka normalisasi tahap 3 sudah terpenuhi. username CBSC Priatim001 password 123 123 admin 1 0

4.4 Implementasi Antarmuka (user interface) berfungsi sebagai jembatan penghubung antara user dan sistem untuk berinteraksi. Dalam perancangan antarmuka perancang antarmuka dituntut untuk membuat antarmuka yang mudah dimengerti oleh pengguna sehingga penggunaan aplikasi akan lebih interaktif. 4.4.1 Antarmuka Utama

Home Konsultasi

3 4 5

Gambar 4.20 Antarmuka Utama Dari Gambar 4.20 dapat diketahui properti antarmuka utama yang selanjutnya dapat dilihat pada Tabel 4.34. Tabel 4.34 Tabel Keterangan Antarmuka Utama No 1 2 3 4 5 6 Type Header Name header Value Keterangan Menampilkan judul aplikasi sistem pakar Menampilkan antarmuka utama Menampilkan antarmuka konsultasi Menampilkan antarmuka utama Masuk ke antar muka login Menampilkan copyright sistem pakar

Hyperlink Home Hyperlink Home Hyperlink Login Footer footerpan

Hyperlink Konsultasi -

4.4.2

Antarmuka Login

LOGIN
Username Password : :

1 2 Batal 3 4

Login

Gambar 4.21 Antarmuka Login Dari Gambar 4.21 dapat diketahui dapat diketahui properti antarmuka login yang selanjutnya dapat dilihat pada Tabel 4.35. Tabel 4.35 Tabel Keterangan Antarmuka Login No 1 2 3 4 Type TextBox TextBox Submit Reset Name username password submit submit2 Login Batal Value Keterangan Input nama pemakai Input kata kunci Untuk masuk ke menu pakar Untuk membatalkan

4.4.3

Antarmuka Konsultasi

KONSULTASI
Hipotesis
>>> Pilih Hipotesis <<<

Lanjut

Gambar 4.22 Antarmuka Konsultasi Dari Gambar 4.22 dapat diketahui property antarmuka konsultasi yang selanjutnya dapat dilihat pada Tabel 4.36. Tabel 4.36 Tabel Keterangan Antarmuka Konsultasi No 1 2 Type Submit Name Value Keterangan Untuk melanjutkan ke pertanyaan menyangkut gejalagejala dari tipe alarm yang di pilih SelectBox alarm Pilih Hipotesis Menampilkan tipe alarm

submit_gejala Lanjut

KONSULTASI
Pertanyaan ke n dari n

1
Jawaban

Lanjut

Gambar 4.23 Antarmuka Konfirmasi Jawaban Hipotesis Dari Gambar 4.23 dapat diketahui property antarmuka konfirmasi jawaban hipotesis yang selanjutnya dapat dilihat pada Tabel 4.37. Tabel 4.37 Tabel Keterangan Antarmuka Konfirmasi Jawaban Hipotesis No 1 2 3 Type Form Name gejala Value Keterangan Pertanyaan untuk hipotesis yang di pilih merujuk ke table gejala SelectBox Jawab Submit Pilihan atas pertanyaan dari gejala yang muncul Submit Lanjut Untuk meneruskan pada konfirmasi gejala berikutnya atau untuk melihat hasil hipotesis

4.4.4

Antarmuka Hasil Hipotesis

Hasil Hipotesis
Pertanyaan ke n dari n
Hipotesa Sementara

History Konsultasi

Hasil Konsultasi

Selesai

Gambar 4.24 Antarmuka Hasil Hipotesis Dari Gambar 4.24 dapat diketahui property antarmuka hasil hipotesis yang selanjutnya dapat dilihat pada Tabel 4.38. Tabel 4.38 Tabel Keterangan Antarmuka Hasil Hipotesis No 1 2 Type FormData Submit Name gangguanedit Submit Selesai Value hipotesis Untuk mengakhiri hasil hipotesis dan kembali ke menu hipotesis Keterangan Menampilkan hasil dari

4.4.5

Antarmuka Menu Pakar

Home Pengetahuan Aturan User Account Konsultasi

2 3 4 5 6

9 10
User Account

Logout

11

Gambar 4.25 Antarmuka Menu Pakar Dari Gambar 4.25 dapat diketahui properti antarmuka menu pakar yang selanjutnya dapat dilihat pada Tabel 4.39. Tabel 4.39 Tabel Keterangan Antarmuka Menu Pakar No 1 2 3 4 5 6 7 8 Type Header Hyperlink Hyperlink Hyperlink Hyperlink Hyperlink Form Hyperlink home basispengetahuan aturan useraccount konsultasi logout Name Header Home Pengetahuan Aturan Value Keterangan Menampilkan judul halaman Menampilkan antarmuka utama Menampilkan antarmuka Basis Pengetahuan Menampilkan antarmuka aturan

User Account Menampilkan antarmuka data user Konsultasi Menampilkan antarmuka konsultasi Menampilkan antarmuka id user Keluar dari menu pakar dan kembali menampilkan halaman utama

9 10 12

Hyperlink Hyperlink footer 4.4.6

home login -

Menampilkan antarmuka utama Menampilkan antarmuka data user Menampilkan copyright pakar

Antarmuka Tambah Data Gangguan

Gambar 4.26 Antarmuka Tambah Data Gangguan Dari Gambar 4.26 dapat diketahui properti gangguan yang selanjutnya dapat dilihat pada Tabel 4.40. Tabel 4.40 Tabel Keterangan Antarmuka Tambah Data Gangguan No 1 2 3 4 5 6 7 Type TextBox TextBox TextArea TextBox TextArea TextBox Submit Name kode tipe deskripsi level contoh jenis submit Simpan Data Value Keterangan Input kode alarm Input tipe alarm Input deskripsi dari alarm Input level alarm Input contoh kerusakan alarm Input jenis alarm Untuk menyimpan data gangguan antarmuka tambah data

4.4.7

Antarmuka Tambah Data Gejala

Tambah Data Gejala
Tipe Alarm Gejala

1 2

Pertanyaan

Simpan

Gambar 4.27 Antarmuka Tambah Data Gejala Dari Gambar 4.27 dapat diketahui properti antarmuka tambah data gejala yang selanjutnya dapat dilihat pada Tabel 4.41. Tabel 4.41 Tabel Keterangan Antarmuka Tambah Data Gejala No 1 2 3 4 Type SelectBox TextArea TextArea Submit Name tipe_alarm gejala pertanyaan submit Simpan Value Keterangan Pilih tipe alarm Input Gejala dari alarm yang di pilih Input Pertanyaan dari alarm Untuk menyimpan data gejala

4.4.8

Antarmuka Tambah Data Solusi

Buat Solusi
Tipe Alarm Pilih Pertanyaan System Action

1 2

3
Operator Action

4
Simpan

Gambar 4.28 Antarmuka Tambah Data Solusi Dari Gambar 4.28 dapat diketahui properti antarmuka tambah data solusi yang selanjutnya dapat dilihat pada Tabel 4.42. Tabel 4.42 Tabel Keterangan Antarmuka Tambah Data Solusi No 1 2 3 4 5 Type Name Simpan Value Keterangan Untuk milih tipe alarm Untuk memilih pertanyaan Input aksi yang harus dilakukan sistem Input aksi yang harus dilakukan operator Untuk menyimpan data solusi SelectBox tipe_alarm SelectBox pertanyaan TextArea TextArea Submit sistem operator submit

4.4.9

Antarmuka Tambah Data Rule

Gambar 4.29 Antarmuka Tambah Data Rule Dari Gambar 4.29 dapat diketahui properti antarmuka tambah data rule yang selanjutnya dapat dilihat pada Tabel 4.43. Tabel 4.43 Tabel Keterangan Antarmuka Tambah Data Rule No 1 2 3 4 5 6 7 8 Type SelectBox SelectBox SelectBox Radio SelectBox Radio SelectBox Submit Name gejala pertanyaan jawaban alarm solusi submit Value Pilih Gejala Keterangan Untuk memilih gejala Untuk memilih pertanyaan Untuk memilih jawaban Untuk memilih link selanjutnya Untuk memilih link selanjutnya Untuk menyimpan data solusi

radiobutton gangguan radiobutton solusi Simpan Data

>Tidak Ada< Untuk memilih link selanjutnya >Tidak Ada< Untuk memilih link selanjutnya

4.4.10 Antarmuka Tampil Data User

Tambah Data User

Nama Lengkap : Username Password Tipe : : :

1 2 3 4 5

Simpan Data

Gambar 4.30 Antarmuka Tampil Data User Dari Gambar 4.30 dapat diketahui properti antarmuka tampil data user yang selanjutnya dapat dilihat pada Tabel 4.44. Tabel 4.44 Tabel Keterangan Antarmuka Tampil Data User No 1 2 3 4 5 Type TextBox TextBox TextBox SelectBox Submit Name nama_lengkap userename password tipe submit Pakar/User Simpan Data Value Keterangan Input nama lengkap Input username Input password Memilih tipe user Untuk menyimpan data User

4.5

Simulasi Aplikasi Dalam pengujian aplikasi sistem pakar alarm gangguan BTS ini penulis

mencoba beberapa fasilitas yang terdapat dalam sistem pakar yang dibangun dengan membagi ke dalam 2 bagian, yaitu: 1. Lingkungan pemakai (Teknisi) Pada lingkungan pemakai ini fasilitas yang diuji coba adalah menu konsultasi. 2. Lingkungan pakar (Teknisi Ahli) Pada lingkungan pakar fasilitas yang dicoba adalah beberapa fasilitas sebagai berikut: 4.5.1 Tambah data gangguan Tambah data gejala Tambah data solusi Tambah data aturan Tambah Data user

Lingkungan Pemakai

Gambar 4.31 Form Login untuk User

Pada lingkungan ini team engineer sebagai pemakai (User) diharuskan untuk melakukan Login terlebih dahulu sebelum masuk ke menu utama untuk melakukan konsultasi, hal ini dilakukan karena aplikasi ini di buat hanya untuk kalangan engineer yang khusus bertugas di lingkungan operational and maintenance network. Setelah masuk ke menu utama maka user tinggal memilih menu konsultasi yang telah disediakan pada form, seperti yang terlihat pada Gambar 4.32.

Gambar 4.32 Form Konsultasi Pada form ini team engineer diharuskan memilih hipotesis berupa tipe alarm kemudian jika di klik tombol Lanjut maka system akan menampilkan form selanjutnya yaitu konfirmasi jawaban gejala, seperti yang terlihat pada gambar 4.33.

Gambar 4.33 Form Konfirmasi Jawaban Pada form ini user diharuskan melakukan konfirmasi terhadap pertanyaan yang diajukan sistem dengan memilih salah satu pilihan. Pilihan Benar (Ya) untuk jawaban gejala yang muncul, dan Salah (Tidak) untuk jawaban gejala yang tidak muncul. Setelah menekan tombol Lanjut maka sistem akan mengelompokkan jawaban jika jawaban Ya, maka jawaban tersebut akan disimpan dalam basis data untuk selanjutnya diseleksi kemungkinan semua gangguan yang ber-relasi dengan gejala yang muncul.. Konfirmasi akan berhenti sampai ada hanya satu kemungkinan gangguan yang ada dari gejala-gejala yang dijawab Ya dan selanjutnya akan ditampilkan hasil analisa seperti yang terdapat pada Gambar 4.34.

Gambar 4.34 Hasil Hipotesis Pada hasil hipotesis ini akan ditampilkan berbagai data termasuk di dalamnya tipe alarm, deskripsi, level, gejala dan hasil konsultasi berupa system action dan operator action. Jika ditekan tombol Selesai maka sistem akan kembali menampilkan form konsultasi dan mengulang kembali penelusuran gejala. 4.5.2 Lingkungan Pakar Sama hal nya di lingkungan pemakai, di lungkungan pakar juga disediakan form Login yang harus dilalui oleh pakar sebelum masuk ke menu utama pakar, seperti terlihat pada Gambar 4.35.

Gambar 4.35 Form Login untuk Pakar 4.5.2.1. Tambah Data Gangguan

Gambar 4.36 Akses ke Sub-Menu Tambah Data Alarm

Seperti yang terlihat pada Gambar 4.36 fasilitas tambah data alarm dapat diakses pada Sub-Menu Tambah Data Alarm pada Menu Pengetahuan > Gangguan. Selanjutnya sistem akan menampilkan form Tambah Data Alarm seperti yang terdapat pada Gambar 4.37.

Gambar 4.37 Form Tambah Data Alarm Setelah pengisian data selesai, dapat dilanjutkan menekan tombol Simpan Data, maka data yang di-inputkan akan masuk ke dalam tabel gangguan dan di tampilkan ke menu data alarm secara otomatis, seperti yang terlihat pada Gambar 4.38.

Gambar 4.38 Data Alarm 4.5.2.2. Tambah Data Gejala

Gambar 4.39 Akses ke Sub-Menu Tambah Data Gejala Seperti yang terlihat pada Gambar 4.39 fasilitas tambah data gejala dapat diakses pada Sub-Menu Tambah Data Gejala pada Menu Pengetahuan > Gejala.

Selanjutnya sistem akan menampilkan form Tambah Data Gejala seperti yang terdapat pada Gambar 4.40.

Gambar 4.40 Form Tambah Data Gejala Setelah pengisian data selesai, dapat dilanjutkan menekan tombol Simpan, maka data yang di-inputkan akan masuk ke dalam tabel pertanyaan dan di tampilkan ke menu data gejala secara otomatis, seperti yang terlihat pada Gambar 4.41.

Gambar 4.41 Data Gejala 4.5.2.3. Tambah Data Solusi Fasilitas tambah data solusi dapat diakses pada Sub-Menu Tambah Data Solusi pada Menu Pengetahuan > Solusi seperti yang terlihat pada Gambar 4.42.

Gambar 4.42 Akses ke Sub-Menu Tambah Data Solusi Selanjutnya sistem akan menampilkan form Tambah Data Jaringan seperti yang terdapat pada Gambar 4.43.

Gambar 4.43 Form Tambah Data Solusi

Setelah pengisian data selesai, dapat dilanjutkan menekan tombol Simpan, maka data yang di-inputkan akan masuk ke dalam tabel solusi dan di tampilkan ke menu data solusi secara otomatis, seperti yang terlihat pada, seperti yang terlihat pada Gambar 4.44.

Gambar 4.44 Data Solusi 4.5.2.4. Tambah Data Aturan Fasilitas tambah data aturan dapat diakses pada Sub-Menu Tambah Data Rule pada Menu Aturan seperti yang terlihat pada Gambar 4.45.

Gambar 4.45 Akses ke Sub-Menu Tambah Data Rule Selanjutnya sistem akan menampilkan form Tambah Data Rule seperti yang terdapat pada Gambar 4.46.

Gambar 4.46 Form Tambah Data Rule

Setelah pengisian data selesai, dapat dilanjutkan menekan tombol Simpan Data, maka data yang di-inputkan akan masuk ke dalam tabel aturan dan di tampilkan ke menu data rule secara otomatis, seperti yang terlihat pada, seperti yang terlihat pada Gambar 4.47.

Gambar 4.47 Data Rule 4.5.2.5. Tambah Data User Fasilitas tambah data user dapat diakses pada Sub-Menu Tambah Data User/Pakar pada Menu User Account seperti yang terlihat pada Gambar 4.48.

Gambar 4.48 Akses ke Sub-Menu Tambah Data User Selanjutnya sistem akan menampilkan form Tambah Data User seperti yang terdapat pada Gambar 4.49.

Gambar 4.49 Form Tambah Data User

Setelah pengisian data selesai, dapat dilanjutkan menekan tombol Simpan Data, maka data yang di-inputkan akan masuk ke dalam tabel user dan di tampilkan ke menu data pengguna/pakar secara otomatis, seperti yang terlihat pada, seperti yang terlihat pada Gambar 4.50.

Gambar 4.50 Data Pengguna atau Pakar

BAB V KESIMPULAN DAN SARAN

5.1

Kesimpulan Berdasarkan hasil analisis dan simulasi yang dilakukan pada Aplikasi

Sistem Pakar untuk Alarm Gangguan Base Transceiver Station ini dapat ditarik kesimpulan, yaitu: 1. Sistem Pakar ini dapat merangkum jenis-jenis alarm yang ada pada modulmodul di mesin Base Transceiver Station (BTS). 2. Pada proses konsultasi, pemakai (Teknisi) diminta konfirmasi jawaban atas gejala-gejala yang diajukan oleh sistem selanjutnya gejala-gejala tersebut akan menjadi masukan untuk menentukan hasil analisa. 3. Pada hasil konsultasi, pemakai (Teknisi) akan mendapatkan informasi tentang tipe alarm yang dipilih berikut dengan hasil konsultasi berupa tindakan yang harus di lakukan oleh Teknisi terhadap gangguan kerusakan pada mesin BTS tersebut. 5.2 Saran Ada beberapa hal yang dapat dilakukan untuk mengembangkan program aplikasi sistem pakar ini, antara lain: 1. Perlu adanya penambahan data untuk jenis alarm dan gejalanya sehingga informasi yang dimiliki akan semakin luas dan banyak. 2. Perlu adanya langkah-langkah pemutakhiran data, agar selalu menyajikan informasi terkini seiring dengan perkembangan teknologi mesin BTS yang di pakai.

DAFTAR PUSTAKA

Admin.

2010.

Programming

Materi

PHP.

Pusdatin.

(online).

(http://www.deptan.go.id/pusdatin/admin/RB/Programming/Materi%20PH P.pdf. Diakses tanggal 17 Mei 2010 Anonim. 2010. Server Web. Wikipedia. (Online). (http://id.wikipedia.org/wiki/Server_web diakses 17 Mei 2010). Amsyah, Zulkifli. 2000., Manajemen Sistem Informasi, Gramedia Pustaka Utama: Jakarta. Arhami, Muhammad. 2005. Konsep Dasar Sistem Pakar. Yogyakarta : Andi Offset. Durkin, J. 1994. Expert Systems Design and Development. Prentice Hall International Inc. New Jersey. Hartati, S. dan Iswanti, S. 2008. Sistem Pakar dan Pengembangannya. Jakarta: Graha Ilmu. Hartono, Jogiyanto. 1999., Analisis dan Desain Sistem Informasi : Pendekatan Terstruktur Teori dan Praktek Aplikasi Bisnis, Edisi 2. Cetakan1. Andi Offset: Yogyakarta. Jogiyanto, H.M. 2003. Pengembangan Sistem Pakar Menggunakan Visual Basic. Yogyakarta : Andi Offset. Kroenke, D.M. 2005. Database Processing: Dasar-Dasar, Desain dan Implementasi. Erlangga. Jakarta. Kusrini. 2006., Sistem Pakar Teori dan Aplikasi, Andi Offsett: Yogyakarta. Kusumadewi, Sri. 2003. Artificial Intelegence (Teknik dan Aplikasinya). Yogyakarta: Graha Ilmu Nugroho, Bunafit. 2004. PHP dan MySQL dengan Editor Dreamweaver MX. Yogyakarta : Andi Offset

Nugroho, Bunafit. 2008. Latihan Membuat Aplikasi Web PHP dan MySQL dengan Dreamweaver MX (6, 7, 2004) dan 8. Yogyakarta : Andi Offset OM Network, Hardware Instalation BTS CDMA. Tidak diterbitkan. Jakarta. Tim Pelaksana. 2010. Modul Praktikum Basis Data. Tidak diterbitkan. Sekolah Tinggi Teknologi Garut Turban, E. 1995., Decision Support System and Expert Systems, Prentice Hall International Inc., USA.

DAFTAR RIWAYAT HIDUP

A. IDENTITAS Nama Jenis Kelamin Status Marital Agama Alamat : Oky Yogaswara : Laki-laki : Belum menikah : Islam : Jl. Gunung Satria No. 1057 RT 03 RW 12 Kelurahan Kotakulon Kecamatan Garut Kota Garut Jawa Barat. B. RIWAYAT PENDIDIKAN 1. TK Pasundan Istri 2. SDN Tanjung Kemuning 2 3. SLTPN 1 Garut 4. SMAN 15 Garut 5. STT-Garut Tahun 1991 Tahun 1997 Tahun 2000 Tahun 2003 Tahun 2011

Tempat, Tanggal Lahir : Garut, 10 Oktober 1985