Rancang Bangun Sistem Pencarian Dokumen Jurnal Menggunakan Metode BM25+.

RANCANG BANGUN SISTEM PENCARIAN DOKUMEN

JURNAL MENGGUNAKAN METODE BM25+

LEMBAR JUDUL SKRIPSI

DENI SUPRIAWAN NIM. 1108605001

PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM UNIVERSITAS UDAYANA

BUKIT JIMBARAN 2016

ii

SURAT PERNYATAAN KEASLIAN KARYA ILMIAH

Yang bertanda tangan di bawah ini menyatakan bahwa naskah Skripsi dengan judul:

“RANCANG BANGUN SISTEM PENCARIAN DOKUMEN JURNAL

MENGGUNAKAN METODE BM25+”

Nama : Deni Supriawan

NIM : 1108605001

Program Studi : Teknik Informatika E-mail : deni.aptx@gmail.com Nomor telp/HP : 082144190930

Alamat : Jl. Bedugul 17 Sidakarya, Denpasar

Belum pernah dipublikasikan dalam dokumen skripsi, jurnal nasional maupun internasional atau dalam prosiding manapun, dan tidak sedang atau akan diajukan untuk publikasi di jurnal atau prosiding manapun. Apabila di kemudian hari terbukti terdapat pelanggaran kaidah – kaidah akademik pada karya ilmiah saya, maka saya bersedia menanggung sanksi-sanksi yang dijatuhkan karena kesalahan tersebut, sebagaimana diatur oleh Peraturan Menteri Pendidikan Nasional Nomor 17 Tahun 2010 tentang Pencegahan dan Penanggulangan Plagiat di Perguruan Tinggi.

Demikian Surat Pernyataan ini saya buat dengan sesungguhnya untuk dapat dipergunakan bilamana diperlukan.

Denpasar, 1 Juli 2016 Yang membuat pernyataan,

Deni Supriawan NIM. 1108605001

iii

LEMBAR PENGESAHAN TUGAS AKHIR

Judul : Rancang Bangun Sistem Pencarian Dokumen Jurnal Menggunakan Metode BM25+

Kompetensi : Rekayasa Perangkat Lunak

Nama : Deni Supriawan

NIM : 1108605001

Tanggal Seminar : 17 Juni 2016

Disetujui oleh: Pembimbing I

I Made Widiartha, S.Si., M.Kom. NIP. 198212202008011008

Penguji I

Drs. I Wayan Santiyasa, M.Si. NIP. 196704141992031002 Pembimbing II

Ida Bagus Gede Dwidasmara, S.Kom., M.Cs. NIP. 198503152010121007

Penguji II

I Putu Gede Hendra Suputra, S.Kom., M.Kom. NIP. 198812282014041001

Penguji III

I Gede Oka Gartria Atitama, S.Kom., M.Kom. NIP. 1991022620160312001

Mengetahui,

Jurusan Ilmu Komputer FMIPA UNUD Ketua,

Agus Muliantara, S.Kom., M.Kom. NIP. 198006162005011001

iv

Judul : Rancang Bangun Sistem Pencarian Dokumen Jurnal Menggunakan Metode BM25+

Nama : Deni Supriawan

NIM : 1108605001

Pembimbing I : I Made Widiartha, S.Si., M.Kom.

Pembimbing II : Ida Bagus Gede Dwidasmara, S.Kom., M.Cs. ABSTRAK

Jurnal penelitian merupakan dokumen yang diperlukan bagi para mahasiswa yang sedang melakukan penelitian tugas akhir untuk dijadikan sebagai referensi. Jumlah dokumen jurnal tentunya akan terus bertambah, sehingga pencarian secara manual belum tentu menghasilkan jurnal yang diinginkan. Dari masalah ini diperlukan suatu sistem pencarian dokumen yang dapat memberikan hasil pencarian yang sesuai dengan keinginan pengguna.

Sistem Temu Kembali Informasi (STKI) merupakan kegiatan untuk menemukan suatu material (dokumen) dari data yang tidak terstruktur (berbentuk teks) yang dapat memenuhi kebutuhan informasi yang dicari dalam koleksi dokumen besar. Sistem bekerja dengan menghitung bobot dokumen pada hasil pencarian untuk mengetahui tingkat relevansinya dengan kata kunci pengguna. Salah satu metode pembobotan dokumen yang digunakan dalam masalah ini adalah Metode BM25+. BM25+ memiliki fungsi yang sesuai dengan prinsip pembobotan yang baik, yaitu memiliki inverse document frequecy (IDF), term frequency (TF), fungsi normalisasi dari panjang dokumen (document length normalization), dan terdapat parameter delta untuk mengatur batas bawah dari normalisasi TF terhadap panjang dokumen. Data dokumen yang digunakan berjumlah 264 jurnal terdiri dari Jurnal SNATIA dan JELIKU.

Dari hasil pengujian static, black box, whitebox, dan performance, sistem telah berhasil dirancang dan diimplementasikan berdasarkan hasil definisi kebutuhan fungsional dan non-fungsional. Dari hasil pengujian tuning parameter delta, nilai Non Interpolated Average Precision (NIAP) yang dihasilkan oleh metode BM25+ lebih besar dari metode BM25 yakni meningkat sekitar 10.53%. Nilai delta 0.7 akan menghasilkan nilai NIAP maksimal (0.84) untuk semua kemungkinan panjang dokumen. Hal ini menunjukkan sistem mampu memberikan bobot besar untuk dokumen yang relevan dengan kata kunci, sehingga dokumen tersebut terdapat pada urutan teratas pada hasil pencarian.

v

Title : Search System Design of Journal Document by Using BM25+ Method

Name : Deni Supriawan

Registration : 1108605001

Main Supervisor : I Made Widiartha, S.Si., M.Kom.

Second Supervisor : Ida Bagus Gede Dwidasmara, S.Kom., M.Cs. ABSTRACT

Journal of research is the necessary documents for the students who are undertaking research thesis to be used as a reference. The number of journal document will certainly continue to grow, so that the manual search is not necessarily obtain the desired journal. Of this problem, it is required a document retrieval system that can provide search results according to the user’s needs.

Information Retrieval System (STKI) is an activity to find a material (documents) from unstructured data (text-based) to meet the needs of the information sought in a large document collection. The system works by calculating the weight of documents on the search results to find the level of relevance to the keywords of the users. One of the document weighting methods used in this problem is the method of BM25+. It has the function according to the principle of good weighting scheme, i.e. it has the inverse document frequecy (IDF), term frequency (TF), the function of the document length normalization, and a parameter of delta to set the lower limit of the normalization of TF to the length of document. Document data used were 264 journals, consisting of Journals of SNATIA and JELIKU.

From the results of static, black box, white box, and performance testing, the system has been successfully designed and implemented based on the definition of functional and non-functional requirements. From the test results of the tuning parameter delta, Non Interpolated Average Precision (NIAP) values produced by the BM25+ method was greater than the BM25 method, which increased by about 10.53%. Delta value of 0.7 would result in a maximum NIAP (0.84) for all the possible length of the document. This indicated that the system was able to give great weight to the relevant documents by keyword, so that these documents were on the top of the search results.

vi

KATA PENGANTAR

Tugas Akhir dengan judul Rancang Bangun Sistem Pencarian Dokumen Jurnal Menggunakan Metode BM25+ ini disusun sebagai salah satu syarat dalam melakukan penelitian Tugas Akhir di Jurusan Ilmu Komputer FMIPA Universitas Udayana.

Sehubungan dengan telah terselesaikannya penelitian ini, maka diucapkan terima kasih dan penghargaan kepada berbagai pihak yang telah membantu penulis, antara lain:

1. Bapak I Made Widiartha, S.Si., M.Kom. sebagai Pembimbing I yang telah membimbing dan membantu menyempurnakan penelitian tugas akhir ini; 2. Bapak Ida Bagus Gede Dwidasmara, S.Kom., M.Cs. sebagai Pembimbing

II yang telah bersedia mengkritisi, memeriksa, dan menyempurnakan penelitian tugas akhir ini;

3. Komisi Tugas Akhir Jurusan Ilmu Komputer FMIPA UNUD, yang telah memberikan petunjuk dalam penyusunan laporan penelitian tugas akhir ini; 4. Bapak-bapak dan Ibu-ibu dosen di Jurusan Ilmu Komputer yang secara

tidak langsung telah memberikan dukungan serta arahan kepada penulis; 5. Seluruh teman-teman mahasiswa Jurusan Ilmu Komputer FMIPA

Universitas Udayana yang telah memberikan bantuan dan dukungan moral dalam penyelesaian penelitian tugas akhir ini.

Disadari pula bahwa sudah tentu penelitian tugas akhir ini masih mengandung kelemahan dan kekurangan. Memperhatikan hal ini, maka masukan dan saran-saran penyempurnaan sangat diharapkan.

Bukit Jimbaran, Juni 2016

vii

DAFTAR ISI

LEMBAR JUDUL ... i

SURAT PERNYATAAN KEASLIAN KARYA ILMIAH ... ii

LEMBAR PENGESAHAN TUGAS AKHIR ... iii

ABSTRAK ... iv

ABSTRACT ... v

KATA PENGANTAR ... vi

DAFTAR ISI ... vii

DAFTAR TABEL ... ix

DAFTAR GAMBAR ... x

DAFTAR LAMPIRAN ... xii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang ... 1

1.2 Rumusan Masalah ... 3

1.3 Tujuan Penelitian ... 3

1.4 Batasan Masalah ... 3

1.5 Manfaat Penelitian ... 3

1.6 Metodelogi Penelitian ... 4

1.6.1 Desain Penelitian ... 4

1.6.2 Pengumpulan Data ... 5

1.6.3 Pengolahan Data Awal ... 5

1.6.4 Metode yang digunakan ... 6

1.6.5 Eksperimen dan Pengujian Metode ... 6

1.6.6 Evaluasi dan Validasi Hasil ... 8

1.6.7 Jadwal Pelaksanaan Kegiatan ... 11

BAB II TINJAUAN PUSTAKA ... 12

2.1. Sistem Temu Kembali Informasi... 12

2.2. Text Preprocessing ... 14

2.2.1. Case Folding ... 14

2.2.2. Tokenizing ... 15

2.2.3. Filtering ... 15

2.2.4. Stemming ... 16

2.3. BM25+ ... 17

2.4. Model Proses Waterfall ... 20

2.5. Unified Modeling Language (UML) ... 21

2.5.1 Use Case Diagram ... 22

2.5.2 Class Diagram ... 24

2.5.3 Activity Diagram ... 27

2.5.4 Sequence Diagram ... 28

2.6. Teknik Pengujian Perangkat Lunak ... 31

2.6.1. Static Testing ... 31

2.6.2. White Box Testing ... 31

viii

2.6.4. Performance Testing ... 33

2.7. Precision, Recall, dan NIAP ... 33

2.8. Tinjauan Studi ... 35

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 37

3.1. Definisi Kebutuhan ... 37

3.1.1. Kebutuhan Fungsional ... 37

3.1.2. Kebutuhan Non-Fungsional ... 38

3.2. Perancangan Sistem ... 38

3.2.1 Use Case Diagram ... 38

3.2.2 Activity Diagram ... 41

3.2.3 Class Diagram ... 57

3.2.4 Sequence Diagram ... 59

3.2.5 Entity Relationship Diagram... 70

3.3. Perancangan Antarmuka ... 71

BAB IV HASIL DAN PEMBAHASAN ... 78

4.1. Lingkungan Perancangan dan Implementasi Sistem ... 78

4.2. Implementasi Database ... 78

4.3. Implementasi Antarmuka ... 80

4.3.1 Antarmuka User ... 80

4.3.2 Antarmuka Admin ... 84

4.4. Implementasi Sistem ... 85

4.5. Pengujian Sistem ... 90

4.5.1. Static Testing ... 90

4.5.2. Black Box Testing ... 91

4.5.3. White Box Testing ... 95

4.5.4. Performance Testing ... 99

4.5.5. Precision dan Recall ... 104

4.5.6. Tuning Parameter BM25+ ... 106

BAB V KESIMPULAN DAN SARAN ... 109

5.1. Kesimpulan ... 109

5.2. Saran ... 110

ix

DAFTAR TABEL

Tabel 1.1. Rancangan Tabel Kebutuhan Fungsional ... 6

Tabel 1.2. Rancangan Tabel Kebutuhan Non-Fungsional ... 7

Tabel 1.3. Rancangan Tabel Static Testing ... 9

Tabel 1.4. Rancangan Tabel Black Box Testing ... 9

Tabel 1.5. Rancangan Tabel Performance Testing ... 10

Tabel 1.6. Rancangan Tabel Precision dan Recall ... 10

Tabel 1.7. Jadwal Kegiatan ... 11

Tabel 2.1. Simbol Use Case Diagram ... 22

Tabel 2.2. Simbol ClassDiagram ... 25

Tabel 2.3. Simbol ActivityDiagram ... 27

Tabel 2.4. Simbol SequenceDiagram... 29

Tabel 2.5. Hubungan Cyclomatic Complexity dan Resiko ... 32

Tabel 3.1. Kebutuhan fungsional ... 37

Tabel 3.2. Kebutuhan Non-fungsional ... 38

Tabel 3.3. Definisi Aktor ... 39

Tabel 3.4. Definisi Use Case... 39

Tabel 3.5. Hubungan Class dan UseCase ... 58

Tabel 4.1. Kode Preprocessing Teks ... 86

Tabel 4.2. Kode Indexing ... 87

Tabel 4.3. Kode Hitung Bobot Dokumen ... 88

Tabel 4.4. Hasil Static Testing ... 90

Tabel 4.5. Skenario Black Box Testing ... 91

Tabel 4.6. Hasil Black Box Testing ... 92

Tabel 4.7. Flowgraph Indexing ... 96

Tabel 4.8. Kasus Uji Proses Indexing ... 97

Tabel 4.9. Flowgraph Hitung Bobot Dokumen ... 98

Tabel 4.10. Kasus Uji ProsesHitung Bobot Dokumen ... 99

Tabel 4.11. Hasil Performance Testing Query 1 Term ... 100

Tabel 4.12. Hasil Performance Testing Query 2 Term ... 100

Tabel 4.13. Hasil Performance Testing Query 3 Term ... 101

Tabel 4.14. Hasil Performance Testing Query 4 Term ... 101

Tabel 4.15. Hasil Performance Testing Query 5 Term ... 102

Tabel 4.16. Rata-rata Waktu Berdasarkan Penambahan Term ... 102

Tabel 4.17. Rata-rata Waktu Berdasarkan Penambahan Dokumen ... 103

x

DAFTAR GAMBAR

Gambar 2.1. Bagian-bagian Sistem Temu Kembali Informasi ... 13

Gambar 2.2. Contoh Case Folding ... 15

Gambar 2.3. Contoh Tokenisasi ... 15

Gambar 2.4. Contoh Filtering ... 16

Gambar 2.5. Contoh Stemming ... 17

Gambar 2.6. Model Proses Waterfall ... 20

Gambar 3.1. Use Case Diagram Sistem Pencarian Jurnal ... 39

Gambar 3.2. Activity Diagram Autentikasi ... 41

Gambar 3.3. Activity Diagram Tambah Data Jurnal ... 42

Gambar 3.4. Activity Diagram Edit Data Jurnal ... 43

Gambar 3.5. Activity Diagram Hapus Data Jurnal ... 44

Gambar 3.6. Activity Diagram Lihat Master Data Jurnal ... 45

Gambar 3.7. Activity Diagram Tambah Data Publikasi ... 46

Gambar 3.8. Activity Diagram Edit Data Publikasi ... 47

Gambar 3.9. Activity Diagram Hapus Data Publikasi ... 48

Gambar 3.10. Activity Diagram Lihat Master Data Publikasi ... 49

Gambar 3.11. Activity Diagram Pencarian Publikasi ... 50

Gambar 3.12. Activity Diagram Lihat Detail Publikasi ... 51

Gambar 3.13. Activity Diagram Melihat List Jurnal ... 51

Gambar 3.14. Activity Diagram Melihat List Publikasi ... 52

Gambar 3.15. Activity DiagramPreprocessing Teks ... 53

Gambar 3.16. Activity DiagramIndexing ... 54

Gambar 3.17. Activity Diagram Hitung Bobot Dokumen ... 56

Gambar 3.18. Class Diagram Sistem Pencarian Jurnal ... 57

Gambar 3.19. Sequence Diagram Autentikasi ... 60

Gambar 3.20. Sequence Diagram Tambah Data Jurnal ... 61

Gambar 3.21. Sequence Diagram Edit Data Jurnal ... 62

Gambar 3.22. Sequence Diagram Hapus Data Jurnal ... 63

Gambar 3.23. Sequence Diagram Lihat Master Data Jurnal ... 63

Gambar 3.24. Sequence Diagram Tambah Data Publikasi ... 64

Gambar 3.25. Sequence Diagram Edit Data Publikasi ... 65

Gambar 3.26. Sequence Diagram Hapus Data Publikasi ... 66

Gambar 3.27. Sequence Diagram Lihat Master Data Publikasi ... 66

Gambar 3.28. Sequence Diagram Pencarian Publikasi ... 67

Gambar 3.29. Sequence Diagram Lihat Detail Publikasi ... 68

Gambar 3.30. Sequence Diagram Lihat List Jurnal ... 69

Gambar 3.31. Sequence Diagram Lihat List Publikasi ... 69

Gambar 3.32. Entity Relationship Diagram Sistem Pencarian Jurnal ... 70

Gambar 3.33. Rancangan Antarmuka Home... 71

Gambar 3.34. Rancangan Antarmuka Detail Publikasi ... 72

Gambar 3.35. Rancangan Antarmuka List Jurnal ... 73

xi

Gambar 3.37. Rancangan Antarmuka Login ... 75

Gambar 3.38. Rancangan Antarmuka Dashboard Admin ... 75

Gambar 3.39. Rancangan Antarmuka Master Data ... 76

Gambar 3.40. Rancangan Antarmuka Tambah Data ... 77

Gambar 4.1. Skema Database Sistem Pencarian Jurnal ... 79

Gambar 4.2. Antarmuka Home ... 80

Gambar 4.3. Antarmuka Hasil Pencarian ... 81

Gambar 4.4. Antarmuka Detail Publikasi ... 81

Gambar 4.5. Antarmuka List Jurnal ... 82

Gambar 4.6. Antarmuka List Publikasi ... 83

Gambar 4.7. Antarmuka Login... 83

Gambar 4.8. Antarmuka Dashboard ... 84

Gambar 4.9. Antarmuka Master Data ... 84

Gambar 4.10. Antarmuka Tambah Data ... 85

Gambar 4.11. Grafik Waktu berdasarkan Penambahan Dokumen ... 103

Gambar 4.12. Grafik Waktu berdasarkan Penambahan Term... 104

Gambar 4.13. Grafik Hasil Uji Precision dan Recall ... 105

Gambar 4.14. Grafik Hasil Uji NIAP Tuning Parameter Delta ... 107

Gambar 4.15. Grafik Hasil Uji Precision Tuning Parameter Delta ... 107

xii

DAFTAR LAMPIRAN

LAMPIRAN

1. Hasil Uji Precisiondan Recall 2. Hasil Uji Tuning Parameter BM25+

1

BAB I

PENDAHULUAN

1.1 Latar Belakang

Sumber informasi atau referensi sudah merupakan hal yang tidak asing lagi bagi seorang peneliti, terutamanya bagi para mahasiswa yang sedang melakukan penelitian untuk tugas akhir. Dalam penelitian, mahasiswa pastinya melakukan pencarian terhadap jurnal-jurnal terkait penelitian yang sedang dilakukan sebagai referensi. Selain itu, jurnal tersebut juga dapat memperkuat argumen mahasiswa dalam laporan tugas akhirnya. Namun, alangkah baiknya jika jurnal-jurnal yang dijadikan referensi tersebut adalah jurnal penelitian dari mahasiswa, alumni maupun dosen yang sudah pernah melakukan penelitian sebelumnya sehingga dapat dikembangkan pada penelitian selanjutnya.

Seiring dengan berkembangnya jumlah penelitian yang dilakukan, dokumen jurnal yang dipublikasikan dari penelitian tersebut tentunya akan semakin bertambah dalam koleksi dokumen. Pencarian secara manual terhadap tumpukan dokumen tentunya menghabiskan banyak tenaga. Selain menghabiskan banyak waktu, dokumen yang kita dapatkan belum tentu relevan dengan apa yang kita inginkan. Meninjau dari permasalah tersebut, terlihat pentingnya suatu sistem pencarian dokumen jurnal yang dapat mempermudah mahasiswa maupun dosen untuk mencari referensi atau untuk kegiatan perkuliahan. Sehingga keberadaan sistem pencarian dokumen jurnal ini sangat di perlukan di lingkungan Jurusan Ilmu Komputer Universitas Udayana.

Sistem pencarian yang dimaksud lebih dikenal dengan Sistem Temu Kembali Informasi (STKI). STKI merupakan kegiatan untuk menemukan suatu material (dokumen) dari data yang tidak terstruktur (berbentuk teks) yang dapat memenuhi kebutuhan informasi yang dicari dalam koleksi dokumen yang besar. Informasi yang dikembalikan oleh STKI berupa tumpukan dokumen yang relevan terhadap query yang dimasukkan oleh pengguna (Manning et al, 2008). STKI diperlukan ketika koleksi dokumen yang besar dimana teknik katalog tradisional tidak dapat mengatasinya (Sanderson & Croft, 2012).

2

Sampai saat ini terdapat beberapa model-model untuk melakukan pembobotan dokumen dalam STKI, salah satunya adalah model peluang. Model peluang merupakan salah satu model retrieval terbaik (Zhang et al, 2013). Salah satu framework pada model peluang ini adalah BM25 yang dikembangkan oleh (Robertson & Jones, 1976). BM25 memiliki fungsi yang sesuai dengan 3 prinsip pembobotan yang baik, yaitu memiliki inverse document frequecy (IDF), term frequency (TF), dan memiliki fungsi normalisasi dari panjang dokumen (document length normalization). Sampai saat ini, BM25 merupakan fungsi yang memiliki tingkat keberhasilan terbaik (Saputra, 2013). Oleh karenanya fungsi ini masih terus dikembangkan oleh beberapa peneliti. Salah satu pengembangan dari BM25 adalah BM25+ yang dikembangkan oleh (Lv & Zhai, 2011) dimana dalam penelitian tersebut dikatakan bahwa normalisasi TF berdasarkan panjang dokumen tidak dibatasi (lower-bounded) dengan benar. Oleh karena itu dikembangkan fungsi BM25+ yang dapat mengatasi kekurangan dari fungsi aslinya. Dari hasil penelitian didapat bahwa fungsi BM25+ memiliki performa yang lebih baik daripada fungsi BM25.

Berdasarkan pemaparan di atas, maka peneliti menggunakan BM25+ sebagai model perangkingan untuk pengembangan sistem pencarian dokumen jurnal di Jurusan Ilmu Komputer Universitas Udayana. Pada tahap pengembangan sistem ini digunakan model proses Waterfall yang merupakan suatu metode pengembangan perangkat lunak yang bersifat berurutan dalam tiap pengerjaan tahapnya (Sommerville, 2011). Tahap dalam model proses ini terdiri dari analisis dan definisi kebutuhan, desain, implementasi, pengujian, dan pemeliharaan sistem. Sesuai dengan pengertiannya, model proses ini dikerjakan secara berurutan, jadi jika pengerjaan pada suatu tahap belum terselesaikan, maka pengerjaan untuk tahap selanjutnya tidak diperbolehkan. Sehingga dapat dihasilkan suatu perangkat lunak dengan kualitas yang baik dan sesuai dengan kebutuhan pengguna.

3

1.2 Rumusan Masalah

Berdasarkan latar belakang di atas, maka permasalahan yang akan dibahas dalam penelitian ini yaitu:

1. Bagaimana perancangan dan implementasi sistem pencarian dokumen jurnal menggunakan Metode BM25+.

2. Bagaimana pengaruh modifikasi nilai tuning parameter dari metode BM25+ terhadap tingkat precision, recall dan non interpolated average precision (NIAP) dari sistem pencarian dokumen jurnal.

1.3 Tujuan Penelitian

Tujuan dari penelitian ini adalah:

1. Merancang dan mengimplementasikan sistem pencarian dokumen jurnal yang mampu memberikan informasi yang relevan dengan query pengguna menggunakan metode BM25+.

2. Mengetahui pengaruh modifikasi nilai tuning parameter dari metode BM25+ terhadap tingkat precision, recall, dan NIAP dari hasil temu balik informasi pada sistem pencarian dokumen jurnal.

1.4 Batasan Masalah

Batasan-batasan masalah yang akan dijadikan acuan dalam penelitian ini adalah:

1. Dokumen jurnal yang digunakan dalam penelitian ini terdiri dari dokumen Jurnal Seminar Nasional Teknologi Informasi dan Aplikasinya (SNATIA) dan dokumen Jurnal Elektronik Ilmu Komputer Universitas Udayana (JELIKU). 2. Dokumen yang dijadikan dataset adalah dokumen berbahasa Indonesia.

1.5 Manfaat Penelitian

Adapun manfaat yang diharapkan penulis dari penelitian ini adalah: 1. Menghasilkan sistem pencarian dokumen dengan menggunakan metode

4

lingkungan jurusan Ilmu Komputer Universitas Udayana yang sesuai dengan query pengguna.

2. Memberikan kemudahan bagi para pengguna terutama mahasiswa yang sedang melakukan penelitian dalam mencari referensi dokumen jurnal penelitian Jurusan Ilmu Komputer Universitas Udayana.

1.6 Metodelogi Penelitian 1.6.1 Desain Penelitian

Desain penelitian yang digunakan pada penelitian ini adalah studi kasus. Studi kasus merupakan penelitian yang memusatkan perhatian pada suatu kasus tertentu dengan menggunakan individu atau kelompok sebagai bahan studinya (Hasibuan Z. A., 2007). Penggunaan penelitian studi kasus ini biasanya difokuskan untuk menggali dan mengumpulkan data yang lebih dalam terhadap obyek yang diteliti untuk dapat menjawab permasalahan yang sedang terjadi. Sehingga bisa dikatakan bahwa penelitian bersifat deskriptif dan eksploratif.

Permasalahan yang ingin diselesaikan dalam penelitian ini yaitu bagaimana merancang dan membangun sistem pencarian dokumen jurnal yang dapat digunakan oleh pengguna khususnya bagi para peneliti yang ingin mencari referensi untuk penelitian yang sedang dilakukan. Data dokumen yang digunakan pada penelitian ini adalah jurnal penelitian yang terdapat di lingkungan Jurusan Ilmu Komputer Universitas Udayana.

Metode yang digunakan dalam pengembangan sistem adalah model proses waterfall dimana dalam implementasinya model proses ini bersifat sistematis, yaitu tahap pengembangannya dilakukan secara berurutan dan dilakukan evaluasi pada masing-masing tahap untuk memastikan pengembangan sistem berjalan dengan baik. Pada tahap awal, akan dilakukan pendifinisian kebutuhan sistem baik itu kebutuhan fungsional dan non-fungsional. Definisi kebutuhan sistem ini selanjutnya akan dianalisis dan dijadikan sebagai acuan dalam pengembangan sistem.

5

1.6.2 Pengumpulan Data

Data yang digunakan pada penelitian ini dibagi menjadi 2 yaitu Data Primer dan Data Sekunder. Data primer adalah data yang diambil langsung dari obyek penelitian atau merupakan data yang berasal dari sumber asli atau pertama. Data Sekunder adalah data yang tidak didapatkan secara langsung dari objek penelitian, melainkan data yang berasal dari sumber yang telah dikumpulkan oleh pihak lain (Hasibuan Z. A., 2007).

Data primer pada penelitian ini diperoleh dengan melakukan wawancara yang ditujukan pada pengguna sistem, yaitu mahasiswa dan dosen. Hal ini dilakukan untuk dapat mendefinisikan kebutuhan pada pengembangan sistem yang terdiri dari kebutuhan fungsional dan non-fungsional. Kebutuhan ini nantinya akan dijadikan acuan dalam pengembangan sistem.

Data Sekunder pada penelitian ini menggunakan data dokumen jurnal yang berada di lingkungan Jurusan Ilmu Komputer Universitas Udayana. Dokumen jurnal yang dimaksud dibagi menjadi 2 yaitu dokumen Jurnal Elektronik Ilmu Komputer Universitas Udayana (JELIKU) yang diperoleh dari ketua redaksi jurnal dan dokumen jurnal Seminar Nasional Teknologi Informasi dan Aplikasinya (SNATIA) yang diperoleh dari ketua pelaksana kegiatan seminar.

1.6.3 Pengolahan Data Awal

Setelah mendapatkan data primer dan data sekunder terkait penelitian yang dilakukan, proses selanjutnya yaitu pengolahan data awal. Pengolahan data atau analisa data merupakan proses pra-analisa yang mempunyai tahapan-tahapan sebagai berikut: editing data, pengembangan variable, pengkodean data, cek kesalahan, membuat struktur data, cek preanalisa komputer, dan tabulasi (Hasibuan Z. A., 2007). Pengolahan data ini dilakukan agar data tersebut mudah digunakan dalam pengembangan sistem.

Dari data primer yang didapatkan yaitu definisi kebutuhan sistem selanjutnya akan dilakukan analisis lebih lanjut dan mengidentifikasi ke dalam kebutuhan fungsional dan non-fungsional. Sedangkan pada data sekunder yaitu data

6

dokumen jurnal, akan dilakukan text preprocessing yang terdiri dari Case Folding, Tokenizing, Filtering, dan Stemming.

1.6.4 Metode yang digunakan

Dalam merancang dan membangun “Sistem Pencarian Dokumen Jurnal Menggunakan Metode BM25+” akan digunakan model proses Waterfall. Model proses ini terdiri dari 5 fase, yaitu analisis dan definisi kebutuhan, desain, implementasi, pengujian, dan pemeliharaan. Pada tiap fasenya akan dilakukan evaluasi dan dokumentasi apakah fase tersebut sudah dilakukan dengan benar sebelum melanjutkan ke fase berikutnya.

Pada fase pengujian sistem akan dilakukan teknik pengujian sistem yaitu Static Testing, White Box Testing, Black Box Testing, dan Performance Testing. Hal ini bertujuan agar perangkat lunak yang dihasilkan sesuai dengan kebutuhan pengguna dan dapat berjalan sebagaimana mesitnya.

1.6.5 Eksperimen dan Pengujian Metode

Dalam penelitian ini sistem akan dikembangkan dengan menggunakan model proses Waterfall yang terdiri dari 5 fase tahapan yaitu:

1. Requirement analysis and definition

Fase ini merupakan pencarian informasi yang akan digunakan sebagai acuan dalam pembuatan sistem nantinya. Pengumpulan informasi ini dilakukan dengan metode wawancara dengan pengguna baik itu mahasiswa maupun dosen. Definisi kebutuhan ini dapat memberikan gambaran umum sistem yang akan dibangun. Kegiatan selanjutnya yaitu mengidentifikasi definisi kebutuhan tersebut ke dalam kebutuhan fungsional dan non-fungsional yang ditunjukkan pada tabel 1.1. dan 1.2. Tabel 1.1. Rancangan Tabel Kebutuhan Fungsional

No Kebutuhan Fungsional 1 Kebutuhan A

2 Kebutuhan B 3 Kebutuhan C

7

Tabel 1.2. Rancangan Tabel Kebutuhan Non-Fungsional No Kebutuhan Non-Fungsional Deskripsi

1 Kebutuhan A Deskripsi A

2 Kebutuhan B Deskripsi B

3 Kebutuhan C Deskripsi C

2. System and software design

Pada tahap ini akan dilakukan perancangan sistem sesuai dengan kebutuhan fungsional dan non-fungsional yang sudah didefinisikan pada fase sebelumnya. Berikut adalah hal-hal yang dilakukan pada fase ini.

1. Memodelkan sistem dengan menggunakan Unified Modeling Language (Use Case Diagram, Class Diagram, Activity Diagram, Sequence Diagram).

2. Perancangan database dengan menggunakan Entity Relationship Diagram (ERD).

3. Perancangan antarmuka.

3. Implementation and unit testing

Pada fase ini, peneliti akan mengimplementasikan rancangan perangkat lunak yang telah dibuat pada fase sebelumnya ke dalam bahasa pemrograman. Implementasi sistem ini meliputi pembuatan database, antarmuka, hingga persiapan testcase yang akan digunakan pada fase pengujian sistem.

Dalam fase ini akan digunakan beberapa komponen yaitu: 1. Database server menggunakan MySQL

2. Sistem ini akan dibangun dan diimplementasikan dengan menggunakan framework Codeigniter, PHP, HTML, JQuery, JavaScript, dan AJAX 3. Sublime Text 2 sebagai text editor

8

4. Integration and system testing

Pada fase ini, akan dilakukan pengujian terhadap sistem pencarian dokumen jurnal menggunakan BM25+, apakah sistem sudah sesuai dengan definisi kebutuhan yang ditentukan sebelumnya dan memberikan dokumen yang relevan dengan query pengguna. Teknik pengujian sistem yang akan digunakan pada fase ini yaitu Static Testing, White Box Testing, Black Box Testing, dan Performance Testing (Everett & McLeod Jr., 2007). Sedangkan untuk pengujian tingkat akurasi metode BM25+ akan dilakukan perhitungan Precision dan Recall (Manning et al, 2008).

5. Operation and maintenance

Setelah sistem dinyatakan selesai, maka sistem akan dirilis. Para pengguna sistem akan memberikan feedback setelah menggunakan sistem seperti ditemukan bug pada sistem, maka sistem akan segera di analisis dan diperbaiki. Jika tidak ditemukan permasalahan yang signifikan maka sistem akan dinyatakan selesai dan dirilis sebagai versi 1.0.

1.6.6 Evaluasi dan Validasi Hasil

Pada penelitan ini akan dilakukan pengujian dari sisi sistem dan sisi metode yang digunakan. Untuk pengujian sistem dilakukan 5 pengujian yang berupa Static Testing, Black Box Testing, White Box Testing, dan Performance Testing. Untuk pengujian metode digunakan perhitungan Precision dan Recall.

1. Static Testing

Pada pengembangan sistem ini akan dilakukan static testing dengan menggunakan metode desk checking. Metode desk checking dilakukan dengan menguji apakah hasil dokumentasi perancangan sistem pada fase System and software design dapat diimplementasikan dengan benar, dan definisi kebutuhan mampu dipenuhi berdasarkan rancangan sistem.

9

Tabel 1.3. Rancangan Tabel Static Testing

No Kebutuhan Sistem Implementasi Sistem Keterangan

1 Kebutuhan A Implementasi A Sesuai

2 Kebutuhan B Implementasi B Tidak Sesuai 3 Kebutuhan C Implementasi C Kurang Sesuai

2. BlackBoxTesting

Black Box Testing bertujuan untuk mengetahui tingkah laku sistem apakah sistem sudah berjalan sesuai yang diinginkan. Pengujian dituangkan dalam bentuk tabel uji (Tabel 1.4) dengan melakukan berbagai macam skenario terdapat sistem dilihat hasilnya dan disimpulkan validasinya.

Tabel 1.4. Rancangan Tabel Black Box Testing No Butir Uji Skenario

pengujian

Keluaran pengujian

Hasil yang Diharapkan

Kesimpulan

1 Pengujian 1 Skenario 1 Output 1 Hasil 1 Valid 2 Pengujian 2 Skenario 2 Output 2 Hasil 2 Valid 3 Pengujian 3 Skenario 3 Output 3 Hasil 3 Valid

3. White Box Testing

Pengujian white box pada penelitian ini, akan dilakukan dengan pengujian basis path atau dikenal dengan Cyclomatic Complexity yang tahapannya terdiri dari (Pressman, 2010):

1. Menggambar flowgraph yang ditransfer oleh flowchart.

2. Menghitung Cylomatic Complexity V(G) untuk flowgraph yang telah dibuat. 3. Menentukan jalur pengujian dari flowgraph yang berjumlah sesuai dengan

Cyclomatic Complexity yang telah ditentukan.

Cyclomatic Complexity yang tinggi menunjukkan prosedur kompleks yang sulit untuk dipahami, diuji dan dipelihara.

10

4. Performance Testing

Pengujian akan dilakukan dengan mencatat waktu yang digunakan untuk memproses sebuah query hingga pengembalian dokumen yang didapat oleh sistem. Pada setiap tahap percobaan query dilakukan penambahan dokumen pada koleksi dokumen untuk mengetahui kinerja sistem apabila koleksi dokumen terus bertambah. Berikut adalah rancangan tabel Performance Testing.

Tabel 1.5. Rancangan Tabel Performance Testing

Query Jumlah dokumen

10 20 30 40

Query 1 0,1 detik 0,2 detik 0,3 detik 0,4 detik

Query 2 0,1 detik 0,2 detik 0,3 detik 0,4 detik

Query 3 0,1 detik 0,2 detik 0,3 detik 0,4 detik

5. Precision dan Recall

Precision dan Recall digunakan untuk menguji tingkat relevansi informasi hasil pencarian dokumen dengan query pengguna (Manning et al, 2008). Precision dapat dianggap sebagai ukuran ketepatan atau ketelitian, sedangkan recall dapat diartikan sebagai kesempurnaan. Nilai precision adalah proporsi dokumen yang terambil oleh sistem adalah relevan. Nilai recall adalah proporsi dokumen relevan yang terambil oleh sistem. Berikut adalah rancangan tabel pengujian precision dan recall.

Tabel 1.6. Rancangan Tabel Precision dan Recall

Query Dokumen Relevan

Tidak Relevan

Dokumen Terambil

Tidak Ditemukan

Total Dokumen

Relevan

Recall Precision

11

1.6.7 Jadwal Pelaksanaan Kegiatan Tabel 1.7. Jadwal Kegiatan

No Nama Kegiatan

Minggu ke-

1 2 3 4 5 6 7 8 9 10 11 12 1 Pengumpulan Data

2 Studi Literatur 3 Pengolahan Data 4 Perancangan Sistem 5 Implementasi Sistem 6 Pengujian Sistem 7 Penulisan Laporan

12

BAB II

TINJAUAN PUSTAKA

2.1.Sistem Temu Kembali Informasi

Sistem Temu Kembali Informasi atau Information Retrieval (IR) adalah kegiatan untuk menemukan suatu material (dokumen) dari data yang tidak terstruktur (berbentuk teks) yang dapat memenuhi kebutuhan informasi yang dicari dalam koleksi dokumen yang besar. Informasi yang dikembalikan oleh IR berupa tumpukan dokumen yang relevan terhadap query yang dimasukkan oleh pengguna (Manning et al, 2008). Banyak pihak menggunakan IR untuk menyediakan informasi ke organisasinya sendiri atau publik, informasi tersebut bisa berupa buku, jurnal ataupun dokumen lain.

Salah satu aplikasi umum dari sistem IR adalah search engine atau mesin pencarian yang terdapat pada jaringan internet. Pengguna dapat mencari halaman-halaman web yang dibutuhkannya melalui search engine. Sistem IR terutama berhubungan dengan pencarian informasi yang isinya tidak memiliki struktur. Demikian pula ekspresi kebutuhan pengguna yang disebut query, juga tidak memiliki struktur. Hal ini yang membedakan sistem temu kembali informasi dengan sistem basis data. Dokumen adalah contoh informasi yang tidak terstruktur. Isi dari suatu dokumen sangat tergantung pada pembuat dokumen tersebut.

Sebagai suatu sistem, sistem temu kembali informasi memiliki beberapa bagian yang membangun sistem secara keseluruhan. Gambaran bagian-bagian yang terdapat pada suatu sistem temu kembali informasi digambarkan pada Gambar 2.1.

13

Text Operations Text Operations

Ranking

Indexing Query formulation

Collection Index

Terms Index

Document Collection

1. Dok1 2. Dok2 3. Dok3

. .

Ranked Documents

Query

Gambar 2.1. Bagian-bagian Sistem Temu Kembali Informasi (Mandala & Setiawan, 2009)

Dari ilustrasi pada gambar 2.1, terlihat bahwa secara umum cara kerja dari sistem IR terbagi menjadi 2 alur kerja yaitu dari sisi query dan koleksi dokumen dimana alur koleksi dokumen dijalankan terlebih dahulu. Alur pertama yaitu pemrosesan terhadap koleksi dokumen menjadi basis data indeks tidak tergantung pada alur kedua. Sedangkan alur kedua tergantung dari keberadaan basis data indeks yang dihasilkan pada alur pertama.

Bagian-bagian dari Sistem Temu Kembali Informasi menurut gambar 2.1. meliputi:

1. Text Operations (operasi terhadap teks) yang meliputi pemilihan kata-kata dalam query maupun dokumen (term selection) dalam pentransformasian dokumen atau query menjadi termsindex (indeks dari kata-kata).

2. Query formulation (formulasi terhadap query) yaitu memberi bobot pada indeks kata-kata query.

3. Ranking (perangkingan), mencari dokumen-dokumen yang relevan terhadap query dan mengurukan dokumen tersebut berdasarkan kesesuaiannya dengan query.

14

4. Indexing (pengindeksan), membangun basis data indeks dari koleksi dokumen. Dilakukan terlebih dahulu sebelum pencarian dokumen dilakukan.

Sistem temu kembali informasi menerima query dari pengguna, kemudian melakukan perangkingan terhadap dokumen pada koleksi berdasarkan kesesuaiannya dengan query. Hasil perangkingan yang diberikan kepada pengguna merupakan dokumen yang menurut sistem relevan dengan query. Namun relevansi dokumen terhadap suatu query merupakan penilaian pengguna yang subjektif dan dipengaruhi banyak faktor seperti topik, pewaktuan, sumber informasi mapun tujuan pengguna.

Model sistem temu kembali informasi menentukan detail sistem temu kembali informasi yaitu meliputi representasi dokumen maupun query, fungsi pencarian (retrieval function) dan notasi kesesuaian (relevance notation) dokumen terhadap query.

2.2.Text Preprocessing

Dalam sistem IR sebelum dokumen siap digunakan perlu dilakukan tahap text preprocessing yang terdiri dari case folding, tokenizing, filtering, stemming yang dilakukan secara berurutan.

2.2.1. Case Folding

Case folding adalah proses pertama kali yang dilakukan dalam rangkaian perancangan klasifikasi dokumen teks. Proses ini merupakan proses dimana kata - kata di dalam dokumen atau kalimat akan di ubah menjadi huruf kecil (a sampai z) dan menghilangkan tanda baca. Karakter lain selain huruf akan dianggap delimiter sehingga karakter tersebut akan dihilangkan atau dihapus. Hal ini dilakukan untuk mencegah terjadinya noise pada saat pengambilan informasi. Untuk selanjutnya, hasil dari case folding nantinya akan digunakan pada proses tokenisasi.

15

Gambar 2.2. Contoh Case Folding

2.2.2.Tokenizing

Proses tokenisasi adalah proses pemotongan string input berdasarkan tiap kata yang menyusunnya. Hasil pemrosesan akan berupa kata yang disebut dengan token/term. Term ini nantinya akan disimpan ke dalam database untuk dilakukan indexing saat melakukan pencarian.

Gambar 2.3. Contoh Tokenisasi 2.2.3.Filtering

Filtering merupakan proses mengambilan kata-kata penting dari hasil tokenisasi. Tahap filtering dapat dilakukan menggunakan algoritma stoplist / stopword. Stopword adalah kata-kata yang sering muncul pada teks dalam jumlah besar dan dianggap tidak memiliki makna dan akan dihilangkan. Stopword ini dapat berupa kata penghubung, kata depan, dan kata pengganti, contohnya seperti “yang”,

16

“di”, “dan”, “ke”, “dari” dan lain sebagainya. Tujuan dari proses ini adalah untuk mengurangi jumlah term sehingga hanya kata-kata penting saja yang terdapat pada dictionary. Kumpulan kata yang termasuk stopwords diambil dari penelitian (Asian, 2007).

Gambar 2.4. Contoh Filtering

2.2.4.Stemming

Proses stemming merupakan proses untuk kata dasar dari kata yang sudah mengalami proses stopword. Pencarian kata dasar dapat memperkecil hasil indeks tanpa harus menghilangkan makna. Proses stemming dilakukan dengan menghilangkan semua imbuhan baik yang terdiri dari awalan (prefix), akhiran (surfix), sisipan (infix), bentuk perulangan dan kombinasi antara awalan dan akhiran (confix). Tujuan dari proses ini adalah untuk mengurangi variasi kata yang mempunyai kata dasar yang sama.

Algoritma Stemming yang akan digunakan pada penelitian ini adalah Stemming Nazief & Adriani karena algoritma ini memiliki tingkat keakuratan (presisi) yang baik (Agusta, 2009).

17

Gambar 2.5. Contoh Stemming

2.3.BM25+

Pada model peluang, banyak terdapat fungsi-fungsi kesamaan yang digunakan, yaitu fungsi Best Match (BM). BM25 adalah metode yang dikembangkan oleh (Robertson & Jones, 1976) dan merupakan hasil dari percobaan beberapa variasi fungsi Best Match pada model peluang.

BM25 memiliki fungsi yang sesuai dengan 3 prinsip pembobotan yang baik, yaitu memiliki inverse document frequecy (IDF), term frequency (TF), dan memiliki fungsi normalisasi dari panjang dokumen (document length normalization). TF merupakan jumlah kemunculan suatu term pada suatu dokumen. IDF dapat diartikan sebagai nilai keinformatifan dari sebuah term. Semakin jarang sebuah term muncul dalam koleksi dokumen atau dengan kata lain jumlah dokumen (document frequency) yang mengandung term tersebut sedikit, maka term tersebut akan semakin informatif, begitu pula sebaliknya. Sehingga nilai DF akan di-inverse untuk memberikan bobot yang besar pada term langka dan memberikan bobot yang lebih kecil untuk term yang sering muncul dalam koleksi, dimana hal ini disebut dengan bobot IDF. IDF dihitung dengan membagi jumlah koleksi dokumen dengan DF dari sebuah term. Jadi semakin kecil nilai DF dari suatu term, bobot IDF term tersebut akan semakin besar. Nilai IDF ini akan di-logaritma-kan (log) untuk memperkecil efek dari IDF (Manning et al, 2008).

Fungsi BM25 sampai saat ini masih terus dikembangkan oleh beberapa peneliti. Salah satu pengembangan dari BM25 adalah BM25+ yang dikembangkan oleh (Lv & Zhai, 2011) dimana dalam penelitian tersebut dikatakan bahwa normalisasi TF berdasarkan panjang dokumen tidak dibatasi (lower-bounded)

18

dengan benar yang dapat menyebabkan dokumen yang memiliki jumlah kata yang banyak atau document length yang panjang bisa terabaikan. Oleh karena itu dikembangkan fungsi BM25+ dengan penambahan parameter  yang digunakan sebagai TF semu untuk mengatur nilai batas bawah dari normalisasi TF terhadap panjang dokumen. Untuk lebih jelasnya persamaan BM25+ ditunjukkan pada persamaan 2.1 (Lv & Zhai, 2011):









) ( 1 log ) ( | | 1 ) ( 1 ) ( ) ( 1 ) , ( 25 1 1 3 3 t df N t tf avdl D b b k t tf k t qtf k t qtf k D Q BM Q t                       _{ }        





 (2.1)

Dimana:

1. tf(t) adalah frekuensi kemunculan term t pada dokumen D 2. qtf(t) adalah frekuensi kemunculan term t pada query Q 3. N adalah jumlah total dokumen pada koleksi

4. df(t) adalah jumlah dokumen yang mengandung term t 5.

avdl D| |

adalah panjang dokumen D, dinormalisasi oleh panjang rata-rata dari seluruh dokumen di koleksi atau average document length (avdl)

6. b, k₁ dan k₃ adalah parameter bebas dari BM25, dimanabdiberikan nilai antara 0 – 0,8 , k₁ antara 1,0 – 2,0 dan k₃ = 1000 (Zhang et al, 2013). Pada penelitian (Robertson & Walker, 1999) disebutkan nilai standar masing-masing parameter tersebut adalah b= 0,75, k₁ = 1,2 dan k₃= 1000 untuk query panjang dan k₃= 1 untuk query pendek. Namun dalam penelitian ini, nilai yang akan digunakan untuk k₃ adalah 1 karena jenis query yang akan digunakan pada pengujian adalah query pendek

7. Parameter  digunakan untuk mengatur nilai batas bawah dari normalisasi TF terhadap panjang dokumen dimana pada hasil penelitian (Lv & Zhai, 2011) nilai yang direkomendasikan adalah  1.

19

Pada persamaan 2.1 terdapat beberapa tuning parameter BM25+ yaitu b, k₁ dan k₃. Parameter k₁ digunakan untuk mengkalibrasi skala term frequencytf(t) atau dengan kata lain mengatur seberapa efektif nilai tf(t) pada hasil dari BM25+. Parameter k₃ digunakan untuk mengkalibrasi skala term frequency pada query 

) (t

qtf atau dengan kata lain mengatur seberapa efektif nilai qtf(t) pada hasil dari BM25+. Parameter buntuk mengkalibrasi normalisasi term frequency terhadap document length atau dengan kata lain mengatur seberapa efektif nilai dari document length untuk menormalisasi term frequency (Manning et al, 2008). Nilai parameter ini sewaktu-waktu dapat diubah pada rentang nilai yang ditentukan sesuai kebutuhan untuk mendapatkan hasil akurasi yang lebih baik.

Algoritma dari fungsi BM25+ secara garis besar adalah sebagai berikut (Saputra, 2013).

1. Input query q.

2. Lakukan proses tokenisasi query q menjadi q1… qn.

3. Proses q1 dengan mencari nilai IDF, TF dokumen, dan TF query sesuai dengan

fungsi BM25+.

4. Kalikan IDF, TF query, dan TF yang didapatkan pada q1 tersebut sehingga

didapatkan skor kesamaan untuk satu kata query. 5. Ulangi langkah 3 sampai 4 untuk q yang lain.

6. Jumlahkan setiap hasil yang didapatkan dari q1…qn tergantung banyaknya

jumlah kata pada query, sehingga didapatkan skor keseluruhan untuk 1 query pencarian.

7. Didapatkan skor kesamaan untuk suatu query, sehingga dapat ditentukan dokumen hasil pencarian yang dianggap relevan dengan query tersebut. 8. Urutkan dokumen hasil pencarian berdasarkan skor tertinggi ke skor terendah. 9. Dokumen yang telah diurutkan dapat ditampilkan pada sistem.

20

2.4.Model Proses Waterfall

Model proses perangkat lunak merupakan deskripsi sederhana dari proses perangkat lunak yang menyajikan suatu pandangan dari proses tersebut. Model proses mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat dalam rekayasa perangkat lunak.

Model waterfall merupakan model proses klasik yang bersifat sistematis, berurutan dari satu tahap ke tahap lain dalam membangun software (Sommerville, 2011). Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematik dan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, implementasi, pengujian dan pemeliharaan.

Model waterfall memiliki tahapan-tahapan dalam prosesnya, setiap tahapan tersebut harus diselesaikan sebelum berlanjut ke tahap berikutnya. Tahapan yang terdapat pada model proses waterfall ditunjukkan pada gambar 2.6.

Gambar 2.6. Model Proses Waterfall (Sommerville, 2011)

Berikut merupakan penjelasan dari masing-masing tahapan di atas (Sommerville, 2011).

21

1. Requirements analysis and definition

Layanan sistem, kendala, dan tujuan yang ditetapkan dengan berkonsultasi dengan pengguna sistem. Kemudian didefinisikan secara rinci dan dijadikan sebagai spesifikasi sistem.

2. System and software design

Software desain meliputi mengidentifikasi dan merancang abstraksi sistem perangkat lunak yang mendasar.

3. Implementation and unit testing

Pada tahap ini, perancangan perangkat lunak diimplementasikan ke dalam bentuk kode program. Unit pengujian melibatkan verifikasi bahwa setiap unit memenuhi spesifikasinya.

4. Integration and system testing

Tahapan dimana unit program individu atau program yang terintegrasi diuji sebagai sistem yang lengkap untuk memastikan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah pengujian, sistem perangkat lunak disampaikan kepada pengguna.

5. Operation and maintenance

Tahap ini merupakan tahapan dengan masa waktu paling lama. Pemeliharaan meliputi kesalahan mengoreksi yang tidak ditemukan pada awal tahap siklus hidup, meningkatkan implementasi unit sistem dan meningkatkan pelayanan sistem sebagai kebutuhan baru ditemukan.

2.5.Unified Modeling Language (UML)

Unified Modeling Language (UML) merupakan sebuah standarisasi bahasa pemodelan untuk pembangunan perangkat lunak yang dibangun dengan menggunakan teknik pemrograman berorientasi objek (Yulianto dkk, 2009). Berikut adalah penjelasan diagram UML yang digunakan sebagai model perancangan untuk sistem yang akan dibuat.

22

2.5.1 Use Case Diagram

Use Case merupakan pemodelan untuk merepresentasikan kelakuan (behavior) dari suatu sistem yang akan dibuat (Yulianto dkk, 2009). Dengan kata lain use case tersebut mendeskripsikan sebuah interaksi antara satu atau lebih actor dengan sistem informasi yang akan dibuat. Kegunaan dari diagram ini untuk mengetahui fungsi apa saja yang aka nada di dalam sebuah sistem informasi dan siapa saja yang berhak menggunakan fungsi – fungsi tersebut.

Syarat penamaan pada use case adalah nama yang didefinisikan sesimpel mungkin dan dapat dipahami. Terdapat dua hal utama pada use case yaitu pendefinisian apa yang disebut actor dan use case, yaitu:

1. Aktor merupakan orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri. Oleh karena itu walaupun simbol dari aktor ada adalah gambar orang, tetapi belum tentu hal tersebut merupakan orang.

2. Use Case merupakan fungsionalitas yang disediakan sistem sebagai unit – unit yang saling bertukar pesan antar unit atau aktor.

Simbol-simbol pada Use Case ditunjukkan pada tabel 2.1. Tabel 2.1. Simbol Use Case Diagram

No. Simbol Deskripsi

1. Use Case Fungsionalitas yang disediakan sistem

sebagai unit – unit yang saling bertukar pesan antar unit atau aktor; biasanya dinyatakan dengan menggunakan kata kerja di awal di awal frase nama use case

2. Aktor / actor Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang, tapi aktor belum tentu merupakan orang; biasanya

23

dinyatakan menggunakan kata benda di awal frase nama aktor

3. Asosiasi / association Komunikasi antara aktor dan use case yang berpartisipasi pada use case atau use case memiliki interaksi dengan actor

4. Ekstensi / extend Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use case tambahan itu; mirip dengan prinsip inheritance pada pemrograman berorientasi objek; biasanya use case tambahan memiliki nama depan yang sama dengan use case yang ditambahkan, misalnya :

Arah panah mengarah pada use case yang ditambahkan

5. Generalisasi / generalization

Hubungan generalisasi dan spesialisasi (umum - khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya, misalnya :

24

Arah panah mengarah pada use case yang menjadi generalisasinya (umum)

6. Menggunakan / include Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan memerlukan use case ini untuk menjalankan fungsinya atau sebagai syarat dijalankan use case ini. Include berarti use case yang tambahan akan selalu melakukan pengecekan apakah use case yang ditambahkan telah dijalankan sebelum use case tambahan dijalankan, misal pada kasus berikut :

Arah panah include mengarah pada use case yang dipakai

2.5.2 Class Diagram

Diagram kelas atau class diagram menggambarkan struktur sistem dari segi pendefinisian kelas – kelas yang akan dibuat untuk membangun sistem (Yulianto

25

dkk, 2009). Kelas memiliki apa yang disebut atribut dan metode atau operasi. Berikut ialah penjelasannya yaitu:

1. Atribut merupakan variabel – variabel yang dimiliki oleh suatu kelas. 2. Operasi atau metode adalah fungsi – fungsi yang dimiliki oleh suatu kelas.

Simbol-simbol pada Class Diagram ditunjukkan pada tabel 2.2. Tabel 2.2. Simbol ClassDiagram

No. Simbol Deskripsi

1. Package Package merupakan sebuah bungkusan dari satu atau lebih kelas

2. Kelas Kelas pada struktur sistem

3. Antarmuka / interface Sama dengan konsep interface dalam pemrograman berorientasi objek

4. Asosiasi / association Relasi antar kelas dengan makna umum, asosiasi biasanya juga disertai dengan multiplicity

5. Asosiasi berarah / directed association

Relasi antar kelas dengan makna kelas yang satu digunakan oleh kelas yang lain, asosiasi biasanya juga disertai dengan multiplicity

26

6. Generalisasi Relasi antar kelas dengan makna generalisasi-spesialisasi (umum khusus)

7. Kebergantungan / dependency

Relasi antar kelas dengan makna kebergantungan antar kelas

8. Agregasi / aggregation Relasi antar kelas dengan makna semua bagian (whole-part)

Kelas-kelas yang ada pada struktur sistem harus dapat melakukan fungsi-fungsi sesuai dengan kebutuhan sistem. Susunan struktur kelas yang baik pada diagram kelas sebaiknya memiliki jenis-jenis kelas berikut yaitu:

1. Kelas main

Kelas yang memiliki fungsi awal dieksekusi ketika sistem dijalankan. 2. Kelas yang menangani tampilan sistem

Kelas yang mendefinisikan dan mengatur tampilan ke pemakai 3. Kelas yang diambil dari pendefinisian use case

Kelas yang menangani fungsi-fungsi yang harus ada diambil dari pendefinisian use case

4. Kelas yang diambil dari pendefinisian data

Kelas yang digunakan untuk memegang atau membungkus data menjadi sebuah kesatuan yang diambil maupun akan disimpan ke basis data.

Jenis-jenis kelas di atas juga dapat digabungkan satu sama lain sesuai dengan pertimbangan yang dianggap baik asalkan fungsi – fungsi yang sebaiknya ada pada struktur kelas tetap ada. Susunan kelas juga dapat ditambahkan kelas utilitas seperti koneksi ke basis data, membaca file teks, dan lain sebagainya sesuai kebutuhan.

27

2.5.3 Activity Diagram

Diagram aktivitas atau activity diagram menggambarkan workflow (aliran kerja) atau aktivitas dari sebuah sistem atau proses bisnis (Yulianto dkk, 2009). Yang perlu diperhatikan disini adalah bahwa diagram aktivitas menggambarkan aktivitas sistem bukan apa yang dilakukan aktor, jadi aktivitas yang dapat dilakukan oleh sistem.

Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal-hal berikut yaitu:

1. Rancangan proses bisnis dimana setiap urutan aktivitas yang digambarkan merupakan proses bisnis sistem yang didefinisikan

2. Urutan atau pengelompokan tampilan dari sistem atau user interface dimana setiap aktivitas dianggap memiliki sebuah rancangan antarmuka tampilan 3. Rancangan pengujian dimana setiap aktivitas dianggap memerlukan sebuah

pengujian yang perlu didefinisikan kasus ujinya

Simbol-simbol pada Activity Diagram ditunjukkan pada tabel 2.3. Tabel 2.3. Simbol ActivityDiagram

No. Simbol Deskripsi

1. Status awal Status awal aktivitas sistem, sebuah diagram aktivitas memiliki sebuah status awal

2. Aktivitas Aktivitas yang dilakukan sistem, aktivitas biasanya diawali dengan kata kerja

3. Percabangan / decision Asosiasi percabangan dimana jika ada pilihan aktivitas lebih dari satu

28

4. Penggabungan / join Asosiasi penggabungan dimana lebih dari satu aktivitas digabungkan menjadi satu

5. Status akhir Status akhir yang dilakukan sistem, sebuah diagram aktivitas memiliki sebuah status akhir

6. Swimlane

Atau

Memisahkan organisasi bisnis yang bertanggung jawab terhadap aktivitas yang terjadi

2.5.4 Sequence Diagram

Sequence Diagram menggambarkan kelakuan/perilaku objek pada usecase dengan mendeskripsikan waktu hidup objek dan message yang dikirimkan dan diterima antar objek (Yulianto dkk, 2009). Oleh karena itu untuk menggambar diagram sekuen maka harus diketahui objek-objek yang terlibat dalam sebuah use case beserta metode-metode yang dimiliki kelas yang diinstansiasi menjadi objek itu.

29

Banyaknya diagram sekuen yang harus digambar adalah sebanyak pendefinisian use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan sudah dicakup pada diagram sekuen sehingga semakin banyak usecase yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak.

Simbol-simbol pada Sequence Diagram ditunjukkan pada tabel 2.4. Tabel 2.4. Simbol SequenceDiagram

No. Simbol Deskripsi

1. Aktor

Atau

Orang, proses, atau sistem lain yang berinteraksi dengan sistem informasi yang akan dibuat di luar system informasi yang akan dibuat itu sendiri, jadi walaupun simbol dari aktor adalah gambar orang, tapi aktor belum tentu merupakan orang; biasanya dinyatakan menggunakan kata benda di awal frase nama aktor

2. Garis hidup/ Lifeline Menyatakan kehidupan suatu objek

3. Objek Menyatakan objek yang berinteraksi pesan

4. Waktu aktif Menyatakan objek dalam keadaan aktif dan berinteraksi pesan

30

5. Pesan tipe create Menyatakan suatu objek membuat objek yang lain, arah panah mengarah pada objek yang dibuat

6. Pesan tipe call Menyatakan suatu objek memanggil operasi/metode yang ada pada objek lain atau dirinya sendiri,

arah panah mengarah pada objek yang memiliki operasi/metode, karena ini memanggil operasi/metode maka operasi/metode yang dipanggil harus ada pada diagram kelas sesuai dengan kelas objek yang berinteraksi

7. Pesan tipe send Menyatakan bahwa suatu objek mengirimkan data/ masukan/ informasi ke objek lainnya, arah panah mengarah pada objek yang dikirimi

8. Pesan tipe return Menyatakan bahwa suatu objek yang telah menjalankan suatu operasi atau metode menghasilkan suatu kembalian ke objek tertentu, arah panah mengarah pada objek yang menerima kembalian

9. Pesan tipe destroy Menyatakan suatu objek mengakhiri hidup objek yang lain, arah panah mengarah pada objek yang diakhiri, sebaiknya jika ada create maka ada destroy

31

2.6.Teknik Pengujian Perangkat Lunak

Pengujian perangkat lunak dilakukan pada tiap fase pengembangan perangkat lunak mulai dari fase definisi kebutuhan sampai implementasi. Terdapat 4 teknik pengujian, yaitu Static Testing, White Box Testing, Black Box Testing, dan Performance Testing (Everett & McLeod Jr., 2007).

2.6.1. Static Testing

Static Testing merupakan pengujian yang dilakukan terhadap dokumentasi yang dilakukan pada tahap pengembangan sistem. Dokumentasi ini berasal dari tiap fase pengembangan sistem yaitu definisi kebutuhan, desain, implementasi, pengujian, dan pemeliharaan. Pengujian terhadap dokumentasi tersebut dilakukan dengan 3 cara yaitu

1. Desk checking merupakan pengujian dokumentasi yang dilakukan oleh pembuat dokumen itu sendiri.

2. Inspections merupakan pengujian dokumentasi yang dilakukan oleh 2 orang dalam 1 tim pengembangan sistem, yaitu penulis dokumen sendiri dan misalnya anggota senior dari tim pengembang.

3. Walk-throughs merupakan pengujian dokumentasi yang dilakukan oleh beberapa tim pengembang, misalnya fasilitator, penulis dokumen, staf bisnis, atau technical staf senior.

2.6.2.White Box Testing

White Box Testing merupakan sebuah pengujian yang dilakukan terhadap source code dari program. White Box Testing dilakukan oleh tester dengan cara melakukan pengujian terhadap setiap fungsi code.

Salah satu metode yang digunakan dalam White Box Testing adalah pengujian basis path testing atau disebut dengan Cylomatic Complexity. Dalam pelaksanaan White Box Testing, berikut langkah yang dilakukan (Pressman, 2010):

a. Menggambar flowgraph yang ditransfer oleh flowchart.

b. Menghitung Cylomatic Complexity V (G) untuk flowgraph yang telah dibuat. V(G) untuk flowgraph dapat dihitung dengan rumus:

32

V(G) = E – N + 2 Keterangan:

E = Jumlah edge pada flowrgaph N = Jumlah node pada flowrgaph

c. Menentukan jalur pengujian dari flowgraph yang berjumlah sesuai dengan Cyclomatic Complexity yang telah ditentukan.

Cyclomatic complexity yang tinggi menunjukkan prosedur kompleks yang sulit untuk dipahami, diuji dan dipelihara. Ada hubungan antara cyclomatic complexity dan resiko dalam suatu prosedur. Berikut hubungan antara cyclomatic complexity dan resiko dalam suatu prosedur.

Tabel 2.5. Hubungan Cyclomatic Complexity dan Resiko

Cyclomatic Complexity Evaluasi Resiko

1-10 Sebuah program sederhana, tanpa banyak resiko

11-20 Agak kompleks, resiko sedang

21-50 Kompleks, program resiko tinggi

Lebih dari 50 Program belum diuji (resiko sangat tinggi)

2.6.3.Black Box Testing

Black Box Testing adalah pengujian yang dilakukan saat tester tidak memiliki source code, hanya code yang bisa dieksekusi. Black Box Testing dilakukan dengan menjalankan aplikasi dan melakukan apa yang bisa dikerjakan oleh aplikasi untuk menguji tingkah laku dari sistem.

Black Box Testing berfokus pada kebutuhan fungsional perangkat lunak. Dengan demikian, Black Box Testing memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu untuk program. Black Box Testing berusaha menemukan kesalahan dalam beberapa kategori diantaranya fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan dalam struktur data atau akses database eksternal, dan kesalahan kinerja.

33

2.6.4.Performance Testing

Performance Testing merupakan teknik pengujian yang dilakukan apabila perangkat lunak telah berjalan dengan benar. Pengujian ini dilakukan bukan untuk menguji kebenaran dari sistem melainkan hasil dan waktu respon dari perangkat lunak. Tester menguji perangkat lunak mulai dari saat tidak bekerja (idle) hingga saat puncak performa dari perangkat lunak tersebut. Performance Testing ini berbeda dengan White Box Testing dan Black Box Testing, apabila kecacatan ditemukan pada White Box Testing atau Black Box Testing maka akan dilakukan koreksi program, namun Performance Testing akan lebih memeriksa kemampuannya perangkat lunak terhadap hardware, dimana kecacacatan dalam Performance Testing akan membuat tim pengembang menyarankan pembelian hardware yang lebih memadai untuk aplikasinya.

2.7.Precision, Recall, dan NIAP

Pada ilmu IR, keakuratan menjadi hal yang penting karena pengguna mengharapkan informasi yang didapat sesuai dengan yang diinginkan. Salah satunya menggunakan parameter precision dan recall (Manning et al, 2008).

Precision merupakan salah satu parameter pengukuran hasil retrieval terhadap dokumen. Precision dapat diartikan sebagai kecocokan antara permintaaan informasi dengan respon dari permintaan tersebut. Precision dapat dihitung dengan:

� = ℎ _{ℎ ℎ} � � _{� �}

Sedangkan recall merupakan parameter yang didapat dari jumlah dokumen terambil yang relevan dibagi dengan keseluruhan jumlah dokumen yang relevan. Recall digunakan untuk melakukan pengukuran terhadap tingkat keberhasilan sistem dalam mengenali suatu dokumen yang relevan terhadap query.

� = _ℎ ℎ _ℎ � �

Selain menggunakan parameter precision dan recall, performa sistem IR juga dapat dievaluasi menggunakan NonInterpolatedAveragePrecision atau yang

34

selanjutnya disebut NIAP. NIAP merupakan penggabungan dari precision dan recall yang digunakan untuk mengukur tingkat keberhasilan dari sistem IR dalam meranking dokumen hasil pencarian. NIAP menghitung kinerja sistem berdasarkan rata-rata presisinya saat suatu dokumen relevan ditemukan. Jadi saat suatu dokumen relevan ditemukan, nilai presisi dokumen tersebut akan dihitung. Kemudian seluruh nilai presisi tersebut akan dijumlahkan dan dibagi dengan jumlah dokumen relevan dalam koleksi dokumen (Mandala, 2006).

���� = ∑ _ℎ

� �=

Dimana n menunjukkan jumlah dokumen yang dicari hingga seluruh dokumen relevan ditemukan. Nilai NIAP tertinggi adalah 1, yang berarti seluruh dokumen relevan berhasil ditemukan dengan seluruh dokumen relevan tersebut ditempatkan pada urutan teratas pada hasil pencarian.

Contoh:

Misalkan terdapat 2 sistem IR yang hendak diukur performansinya. Diketahui juga sebuah query dan keseluruhan dokumen yang relevan terhadap query dalam koleksi adalah dokumen 1 (D1), dokumen 5 (D5), dokumen 8 (D8), dokumen ke-10 (Dke-10). Kedua sistem IR memberikan hasil berupa ranking dokumen relevan sebagai berikut.

Hasil Ranking Sistem IR ke 1 Hasil Ranking Sistem IR ke 2 1. Dokumen ke 99

2. Dokumen ke 95 3. Dokumen ke 88 4. Dokumen ke 71

…

997. Dokumen ke 1 998. Dokumen ke 5 999. Dokumen ke 8 1000. Dokumen ke 10

1. Dokumen ke 1 2. Dokumen ke 5 3. Dokumen ke 8 4. Dokumen ke 10

…

997. Dokumen ke 99 998. Dokumen ke 95 999. Dokumen ke 34 1000. Dokumen ke 43

35

Sistem IR ke 1 memberikan nilai =4

4 = , =

4 = , Sistem IR ke 2 memberikan nilai =4

4 = , =

4 = ,

Namun Jika dilihat dari hasil ranking menunjukkan bahwa sistem IR ke 2 lebih baik dari sistem IR ke 1 karena dokumen relevan terdapat pada urutan ke 1, ke 2, ke 3, dan ke 4. Apabila nilai NIAP dihitung untuk kedua sistem IR di atas, diperoleh: Sistem IR ke 2 memberikan nilai ���� = + + +

4 =

Sistem IR ke 1 memberikan nilai ���� = + + +

4 = ,

Jadi NIAP sistem IR ke 2 jauh lebih besar daripada NIAP sistem IR ke 1 dengan kata lain performansi sistem IR ke 2 lebih baik daripada sistem IR ke 1.

2.8.Tinjauan Studi

a. Lower-Bounding Term Frequency Normalization (Lv & Zhai, 2011) Pada penelitian ini, peneliti mengemukakan pendapat bahwa dari model retrieval yang ada saat ini masih memiliki beberapa kekurangan dimana metode yang dibahas pada penelitian ini adalah BM25, PL2 Method, Dirichlet Prior Method (Dir), dan Pivoted Normalization Method (Piv). Kekurangan tersebut adalah komponen dari normalisasi Term Frequency (TF) berdasarkan panjang dokumen tidak dibatasi (lower-bounded) dengan benar. Hal ini dapat menyebabkan dokumen yang memiliki document length panjang cenderung diabaikan. Untuk mengatasi masalah ini peneliti mengusulkan metode yang efisien untuk memberikan batas bawah yang cukup besar untuk normalisasi TF. Dari hasil penelitian, metode yang diusulkan tidak menyebabkan perubahan perhitungan komputasi yang signifikan. Hasil metode baru tersebut salah satunya adalah BM25+.

36

b. TUNING PARAMETER DALAM FUNGSI OKAPI BM25 PADA MESIN PENCARI TEKS BAHASA INDONESIA (Saputra, 2013)

Pada penelitian ini, peneliti melakukan analisis tuning parameter terhadap parameter bebas dari metode BM25 yaitu b, k₁ dan k₃. Tuningparameter sendiri merupakan suatu variabel yang dapat diubah-ubah nilainya sesuai dengan kebutuhan dengan tujuan untuk mendapatkan hasil pencarian yang lebih baik. Tujuan dari penelitian ini adalah seberapa besar pengaruh modifikasi nilai dari tuning parameter yang ada dalam fungsi kesamaan OKAPI BM25 terhadap evaluasi dari hasil pencarian. Selain itu juga akan dibandingkan kinerja antara model peluang dengan model lain yaitu model ruang vektor dalam pencarian dokumen yang menggunakan Bahasa Indonesia. Kesimpulan dari peneletian ini bahwa nilai Average Precision (AVP) pada metode BM25 sebelum dilakukan tuning dan sesudah dilakukan tuning mengalami peningkatan yaitu dari 0,5885 menjadi 0,5901 yang dicapai pada nilai k₁ 1,0 dan b0,45.

2.6.Teknik Pengujian Perangkat Lunak

Pengujian perangkat lunak dilakukan pada tiap fase pengembangan perangkat lunak mulai dari fase definisi kebutuhan sampai implementasi. Terdapat 4 teknik pengujian, yaitu Static Testing, White Box Testing, Black Box Testing, dan Performance Testing (Everett & McLeod Jr., 2007).

2.6.1. Static Testing

Static Testing merupakan pengujian yang dilakukan terhadap dokumentasi yang dilakukan pada tahap pengembangan sistem. Dokumentasi ini berasal dari tiap fase pengembangan sistem yaitu definisi kebutuhan, desain, implementasi, pengujian, dan pemeliharaan. Pengujian terhadap dokumentasi tersebut dilakukan dengan 3 cara yaitu

1. Desk checking merupakan pengujian dokumentasi yang dilakukan oleh pembuat dokumen itu sendiri.

2. Inspections merupakan pengujian dokumentasi yang dilakukan oleh 2 orang dalam 1 tim pengembangan sistem, yaitu penulis dokumen sendiri dan misalnya anggota senior dari tim pengembang.

3. Walk-throughs merupakan pengujian dokumentasi yang dilakukan oleh beberapa tim pengembang, misalnya fasilitator, penulis dokumen, staf bisnis, atau technical staf senior.

2.6.2.White Box Testing

White Box Testing merupakan sebuah pengujian yang dilakukan terhadap source code dari program. White Box Testing dilakukan oleh tester dengan cara melakukan pengujian terhadap setiap fungsi code.

Salah satu metode yang digunakan dalam White Box Testing adalah pengujian basis path testing atau disebut dengan Cylomatic Complexity. Dalam pelaksanaan White Box Testing, berikut langkah yang dilakukan (Pressman, 2010):

a. Menggambar flowgraph yang ditransfer oleh flowchart.

b. Menghitung Cylomatic Complexity V (G) untuk flowgraph yang telah dibuat. V(G) untuk flowgraph dapat dihitung dengan rumus:

V(G) = E – N + 2 Keterangan:

E = Jumlah edge pada flowrgaph N = Jumlah node pada flowrgaph

c. Menentukan jalur pengujian dari flowgraph yang berjumlah sesuai dengan Cyclomatic Complexity yang telah ditentukan.

Cyclomatic complexity yang tinggi menunjukkan prosedur kompleks yang sulit untuk dipahami, diuji dan dipelihara. Ada hubungan antara cyclomatic complexity dan resiko dalam suatu prosedur. Berikut hubungan antara cyclomatic complexity dan resiko dalam suatu prosedur.

Tabel 2.5. Hubungan Cyclomatic Complexity dan Resiko

Cyclomatic Complexity Evaluasi Resiko

1-10 Sebuah program sederhana, tanpa banyak resiko

11-20 Agak kompleks, resiko sedang

21-50 Kompleks, program resiko tinggi

Lebih dari 50 Program belum diuji (resiko sangat tinggi)

2.6.3.Black Box Testing

Black Box Testing adalah pengujian yang dilakukan saat tester tidak memiliki source code, hanya code yang bisa dieksekusi. Black Box Testing dilakukan dengan menjalankan aplikasi dan melakukan apa yang bisa dikerjakan oleh aplikasi untuk menguji tingkah laku dari sistem.

Black Box Testing berfokus pada kebutuhan fungsional perangkat lunak. Dengan demikian, Black Box Testing memungkinkan perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang sepenuhnya menggunakan semua persyaratan fungsional untuk suatu untuk program. Black Box Testing berusaha menemukan kesalahan dalam beberapa kategori diantaranya fungsi-fungsi yang tidak benar atau hilang, kesalahan interface, kesalahan dalam struktur data atau akses database eksternal, dan kesalahan kinerja.

2.6.4.Performance Testing

Performance Testing merupakan teknik pengujian yang dilakukan apabila perangkat lunak telah berjalan dengan benar. Pengujian ini dilakukan bukan untuk menguji kebenaran dari sistem melainkan hasil dan waktu respon dari perangkat lunak. Tester menguji perangkat lunak mulai dari saat tidak bekerja (idle) hingga saat puncak performa dari perangkat lunak tersebut. Performance Testing ini berbeda dengan White Box Testing dan Black Box Testing, apabila kecacatan ditemukan pada White Box Testing atau Black Box Testing maka akan dilakukan koreksi program, namun Performance Testing akan lebih memeriksa kemampuannya perangkat lunak terhadap hardware, dimana kecacacatan dalam Performance Testing akan membuat tim pengembang menyarankan pembelian hardware yang lebih memadai untuk aplikasinya.

2.7.Precision, Recall, dan NIAP

Pada ilmu IR, keakuratan menjadi hal yang penting karena pengguna mengharapkan informasi yang didapat sesuai dengan yang diinginkan. Salah satunya menggunakan parameter precision dan recall (Manning et al, 2008).

Precision merupakan salah satu parameter pengukuran hasil retrieval terhadap dokumen. Precision dapat diartikan sebagai kecocokan antara permintaaan informasi dengan respon dari permintaan tersebut. Precision dapat dihitung dengan:

� = ℎ _{ℎ ℎ} � � _{� �}

Sedangkan recall merupakan parameter yang didapat dari jumlah dokumen terambil yang relevan dibagi dengan keseluruhan jumlah dokumen yang relevan. Recall digunakan untuk melakukan pengukuran terhadap tingkat keberhasilan sistem dalam mengenali suatu dokumen yang relevan terhadap query.

� = _ℎ ℎ _ℎ � �

Selain menggunakan parameter precision dan recall, performa sistem IR juga dapat dievaluasi menggunakan Non Interpolated Average Precision atau yang

selanjutnya disebut NIAP. NIAP merupakan penggabungan dari precision dan recall yang digunakan untuk mengukur tingkat keberhasilan dari sistem IR dalam meranking dokumen hasil pencarian. NIAP menghitung kinerja sistem berdasarkan rata-rata presisinya saat suatu dokumen relevan ditemukan. Jadi saat suatu dokumen relevan ditemukan, nilai presisi dokumen tersebut akan dihitung. Kemudian seluruh nilai presisi tersebut akan dijumlahkan dan dibagi dengan jumlah dokumen relevan dalam koleksi dokumen (Mandala, 2006).

���� = ∑ _ℎ

� �=

Dimana n menunjukkan jumlah dokumen yang dicari hingga seluruh dokumen relevan ditemukan. Nilai NIAP tertinggi adalah 1, yang berarti seluruh dokumen relevan berhasil ditemukan dengan seluruh dokumen relevan tersebut ditempatkan pada urutan teratas pada hasil pencarian.

Contoh:

Misalkan terdapat 2 sistem IR yang hendak diukur performansinya. Diketahui juga sebuah query dan keseluruhan dokumen yang relevan terhadap query dalam koleksi adalah dokumen 1 (D1), dokumen 5 (D5), dokumen 8 (D8), dokumen ke-10 (Dke-10). Kedua sistem IR memberikan hasil berupa ranking dokumen relevan sebagai berikut.

Hasil Ranking Sistem IR ke 1 Hasil Ranking Sistem IR ke 2 1. Dokumen ke 99

2. Dokumen ke 95 3. Dokumen ke 88 4. Dokumen ke 71

…

997. Dokumen ke 1 998. Dokumen ke 5 999. Dokumen ke 8 1000. Dokumen ke 10

1. Dokumen ke 1 2. Dokumen ke 5 3. Dokumen ke 8 4. Dokumen ke 10

…

997. Dokumen ke 99 998. Dokumen ke 95 999. Dokumen ke 34 1000. Dokumen ke 43

Sistem IR ke 1 memberikan nilai =4

4 = , =

4 = , Sistem IR ke 2 memberikan nilai =4

4 = , =

4 = ,

Namun Jika dilihat dari hasil ranking menunjukkan bahwa sistem IR ke 2 lebih baik dari sistem IR ke 1 karena dokumen relevan terdapat pada urutan ke 1, ke 2, ke 3, dan ke 4. Apabila nilai NIAP dihitung untuk kedua sistem IR di atas, diperoleh: Sistem IR ke 2 memberikan nilai ���� = + + +

4 =

Sistem IR ke 1 memberikan nilai ���� = + + +

4 = ,

Jadi NIAP sistem IR ke 2 jauh lebih besar daripada NIAP sistem IR ke 1 dengan kata lain performansi sistem IR ke 2 lebih baik daripada sistem IR ke 1.

2.8.Tinjauan Studi

a. Lower-Bounding Term Frequency Normalization (Lv & Zhai, 2011) Pada penelitian ini, peneliti mengemukakan pendapat bahwa dari model retrieval yang ada saat ini masih memiliki beberapa kekurangan dimana metode yang dibahas pada penelitian ini adalah BM25, PL2 Method, Dirichlet Prior Method (Dir), dan Pivoted Normalization Method (Piv). Kekurangan tersebut adalah komponen dari normalisasi Term Frequency (TF) berdasarkan panjang dokumen tidak dibatasi (lower-bounded) dengan benar. Hal ini dapat menyebabkan dokumen yang memiliki document length panjang cenderung diabaikan. Untuk mengatasi masalah ini peneliti mengusulkan metode yang efisien untuk memberikan batas bawah yang cukup besar untuk normalisasi TF. Dari hasil penelitian, metode yang diusulkan tidak menyebabkan perubahan perhitungan komputasi yang signifikan. Hasil metode baru tersebut salah satunya adalah BM25+.

b. TUNING PARAMETER DALAM FUNGSI OKAPI BM25 PADA MESIN PENCARI TEKS BAHASA INDONESIA (Saputra, 2013)

Pada penelitian ini, peneliti melakukan analisis tuning parameter terhadap parameter bebas dari metode BM25 yaitu b, k₁ dan k₃. Tuning parameter sendiri merupakan suatu variabel yang dapat diubah-ubah nilainya sesuai dengan kebutuhan dengan tujuan untuk mendapatkan hasil pencarian yang lebih baik. Tujuan dari penelitian ini adalah seberapa besar pengaruh modifikasi nilai dari tuning parameter yang ada dalam fungsi kesamaan OKAPI BM25 terhadap evaluasi dari hasil pencarian. Selain itu juga akan dibandingkan kinerja antara model peluang dengan model lain yaitu model ruang vektor dalam pencarian dokumen yang menggunakan Bahasa Indonesia. Kesimpulan dari peneletian ini bahwa nilai Average Precision (AVP) pada metode BM25 sebelum dilakukan tuning dan sesudah dilakukan tuning mengalami peningkatan yaitu dari 0,5885 menjadi 0,5901 yang dicapai pada nilai k₁ 1,0 dan b0,45.