RANCANG BANGUN APLIKASI PENGOPTIMALAN
PENJADWALAN
PRAKTIKUM
MENGGUNAKAN
METODE TABU SEARCH PADA LABORATORIUM
KOMPUTER INSTITUT BISNIS DAN INFORMATIKA
STIKOM SURABAYA
TUGAS AKHIR
Program Studi S1 Sistem Informasi
Oleh:
JOSHUA GABRIELL S. 07410100002
FAKULTAS TEKNOLOGI DAN INFORMATIKA
vi DAFTAR ISI
Halaman
ABSTRAK ... iii
KATA PENGANTAR ... iv
DAFTAR ISI ... vi
DAFTAR GAMBAR ... viii
DAFTAR TABEL ... ix
DAFTAR LAMPIRAN ... x
BAB I PENDAHULUAN ... 1
1.1 Latar Belakang ... 1
1.2 Perumusan Masalah ... 4
1.3 Pembatasan Masalah ... 4
1.4 Tujuan ... 4
1.5 Sistematika Penulisan ... 4
BAB IILANDASAN TEORI ... 6
2.1 Penjadwalan ... 6
2.2 Algoritma Optimasi ... 7
2.3 Tabu Search ... 7
2.4 Aplikasi ... 9
2.5 Siklus Hidup Pengembangan Sistem ... 10
2.6 Model Waterfall ... 10
BAB III ANALISIS DAN PERANCANGAN APLIKASI ... 13
3.1 Analisis ... 13
3.1.1 User Requirements ... 14
vii
3.2Perancangan Aplikasi ... 16
3.2.1Desain Proses ... 16
3.2.2Desain Data ... 21
3.2.3 Desain Antarmuka ... 25
3.2.4 Desain Fisik ... 29
3.2.5 Perancangan Algoritma Tabu Search ... 30
3.3 Desain Uji Coba ... 35
3.3.1 Desain Uji Fungsional ... 35
3.3.2 Desain Uji Data ... 36
BAB IVIMPLEMENTASI DAN EVALUASI ... 37
4.1. ImplementasiAplikasi ... 37
4.2. EvaluasiAplikasi ... 39
4.2.1.Uji Fungsional ... 39
4.2.2. Uji Data ... 41
BAB VPENUTUP ... 42
5.1.Kesimpulan ... 42
5.2.Saran ... 42
DAFTAR PUSTAKA ... 43
viii
DAFTAR GAMBAR
Halaman
Gambar 1.1 Jadwal Kuliah Dan Jadwal Praktikum Berlebih (Sumber : PPTI) ... 2
Gambar 1.2 Grafik Tingkat Kelulusan Mulai Semester 121 (Sumber : Labkom) ... 3
Gambar 2.1 Model Waterfall (Pressman, 2010) ... 11
Gambar 3.1 Document Flow Penjadwalan Praktikum ... 16
Gambar 3.2 System Flow Aplikasi Penjadwalan Praktikum ... 18
Gambar 3.3 Context Diagram ... 19
Gambar 3.4 DFD Level 0 Aplikasi Penjadwalan Praktikum ... 20
Gambar 3.5 Desain Model ER ... 22
Gambar 3.6 CDM(Conceptual Data Model) ... 25
Gambar 3.7 Gambar Antarmuka Perangkat Lunak ... 25
Gambar 3.8 Desain Form Penjadwalan ... 26
Gambar 3.9 Desain Form Tampil Jadwal Praktikum ... 28
Gambar 3.10 Desain Form Tampil KRS Praktikan ... 28
Gambar 3.11 PDM(Physical Data Model)... 29
Gambar 3.12 Algoritma Penjadwalan Inisialisasi ... 32
Gambar 3.13 Algoritma Pengecekan Jadwal Inisialisasi ... 33
Gambar 3.14 Algoritma Pengecekan Tabu List ... 34
Gambar 4.1 Tampilan Form Penjadwalan ... 37
Gambar 4.2 Form Tampil Peserta Praktikum ... 38
ix
Tabel 3.1 User Requirement Penjadwalan ... 14
Tabel 3.2 Software Requirement Penjadwalan ... 14
Tabel 3.3 Tabel JDW_PRK_AWAL... 23
Tabel 3.4 Tabel TABU_LIST ... 23
Tabel 3.5 Struktur Tabel JDW_PRK_AWAL ... 29
Tabel 3.6 Struktur Tabel TABU_LIST ... 30
Tabel 3.7 Data KRS Semester 142 ... 35
Tabel 3.8 Hasil Tabu Search Secara Manual ... 36
Tabel 4.1 Data KRS Semester 142 ... 40
Tabel 4.2 Hasil Uji Tabu Search Dengan Aplikasi ... 40
x
DAFTAR LAMPIRAN
Halaman Lampiran 1. Hasil Survey Keinginan Mahasiswa Tentang Jumlah Maksimal
Mata Kuliah dan Mata Praktikum Dalam Satu Hari ... 44 Lampiran 2. Hasil Survey Tentang Mahasiswa Yang Jadwal Kuliahnya Lebih
1 1.1. Latar Belakang
Laboratorium komputer (Labkom) adalah salah satu unit kerja di Stikom Surabaya yang bertindak sebagai penyedia layanan praktikum. Praktikum digunakan untuk mendukung mahasiswa dalam sebuah perkuliahan yang mengharuskan adanya praktik agar mahasiswa mendapat kesempatan untuk menguji dan melaksanakan secara nyata apa yang diperoleh dalam pengajaran teori di kelas.
2
jadwal tersebut akan diserahkan pada bagian Administrasi Akademik dan Kemahasiswaan (Bagian AAK) agar dapat diinformasikan kepada praktikan.
Dampak yang dihasilkan dari pembuatan jadwal tersebut adalah sebanyak 55% praktikan mendapat jadwal kuliah dan jadwal praktikum yang terlalu banyak dalam satu hari seperti pada Gambar 1.1.
Gambar 1.1 Jadwal Kuliah Dan Jadwal Praktikum Berlebih (Sumber : PPTI)
Gambar 1.2 Grafik Tingkat Kelulusan Mulai Semester 121 (Sumber : Labkom)
Untuk mengatasi permasalahan di atas, diperlukan sebuah aplikasi yang dapat menyusun jadwal mata praktikum sesuai dengan kriteria yang diajukan oleh Labkom Stikom Surabaya dan praktikan itu sendiri, sehingga praktikan tidak terbebani dengan jadwal praktikum yang ada. Salah satu metode yang dapat digunakan adalah tabu search. Menurut Glover dan Laguna (1998), tabu search
4
banyak dalam satu hari, dan mahasiswa memiliki tidak lebih dari tiga jadwal kuliah dalam satu hari.
1.2. Perumusan Masalah
Dari latar belakang masalah di atas, maka dapat dirumuskan masalah yaitu bagaimana merancang bangun aplikasi optimasi penjadwalan praktikum menggunakan metode tabu search pada Labkom Stikom Surabaya.
1.3. Pembatasan Masalah
Batasan masalah dalam penelitian ini adalah sebagai berikut : 1. Proses penjadwalan dilakukan setelah proses perwalian.
2. Tidak dibahas mengenai perubahan mata praktikum diselenggarakan 3. Data praktikan yang digunakan tidak ada penambahan atau pengurangan
secara mendadak.
1.4. Tujuan
Berdasarkan rumusan masalah, maka tujuan dari tugas akhir ini adalah merancang dan membangun aplikasi optimasi penjadwalan praktikum menggunakan metode tabu search pada Labkom Stikom Surabaya.
1.5. Sistematika Penulisan
Bab pendahuluan berisi tentang latar belakang topik tugas akhir, rumusan permasalahan dari latar belakang penelitian, batasan dalam penelitian, tujuan penelitian, dan manfaat dari penelitian.
Bab landasan teori berisi penjelasan tentang proses rekrutmen dan seleksi yang menjadi domain penelitian dari tugas akhir. Bab ini juga menjelaskan tentang algoritma optimasi dan metode tabu search yang menjadi dasar pembentukan solusi dari permasalahan yang diangkat dalam tugas akhir. Selain domain dan solusi, bab ini juga menjelaskan tentang model inkremental yang digunakan sebagai metode dalam membangun solusi permasalahan.
Bab analisis dan perancangan sistem berisi penjelasan tentang hasil identifikasi dan analisis permasalahan yang diangkat pada penelitian. Bab ini juga menjelaskan perancangan sistem, yang terdiri dari diagram konteks, diagram jenjang, diagram alir data (DFD), diagram hubungan entitas (ERD), struktur tabel, desain antarmuka produk, dan desain uji coba produk.
Bab empat adalah bab implementasi dan evaluasi. Bab ini berisi tentang penjelasan implementasi desain sistem. Bab ini juga berisi hasil uji coba yang sudah dilakukan pada produk berdasarkan desain uji coba yang sudah dibuat sebelumnya.
6 BAB II
LANDASAN TEORI
2.1. Penjadwalan
Menurut Pinedo (2002), penjadwalan adalah proses pengambilan keputusan yang mempunyai peran penting dala proses manufaktur dan sistem produksi begitu juga dalam lingkungan pemrosesan informasi. Penjadwalan juga terdapat dalam transportasi dan distribusi serta dalam industri.
Menurut Farida (2008), Penjadwalan merupakan kumpulan kebijaksanaan dan mekanisme dalam sistem operasi yang berhubungan dengan urutan kerja yang dilakukan sistem komputer. Penjadwalan digunakan untuk memutuskan proses yang harus berjalan serta kapan dan selama berapa lama proses tersebut berjalan.
Sasaran utama proses penjadwalan:
1. Adil, tidak ada proses yang tidak kebagian layanan.
2. Efisien, pemroses dijaga tetap bekerja agar tidak ada waktu yang terbuang sia-sia.
3. Waktu tanggap, termasuk di dalamnya sistem waktu interaktif dan sistem waktu nyata.
4. Turn around time, waktu yang diperlukan untuk serangkaian satu proses.
5. Throughput, jumlah kerja yang dapat dilakukan dalam satu satuan waktu.
2.2. Algoritma Optimasi
Menurut Suyanto (2010), algoritma optimasi dapat didefinisikan sebagai algoritma atau metode numerik untuk menemukan nilai x sedemikian hingga menghasilkan f(x) yang bernilai sekecil (atau sebesar) mungkin untuk suatu fungsi f yang diberikan, yang mungkin disertai dengan beberapa batasan pada x. Di sini, x bisa berupa skalar atau vektor dari nilai-nilai kontinu maupun diskrit.
Algoritma optimasi didefinisikan juga sebagai suatu cabang dari matematika terapan dan analisis numerik yang membahas optimasi dengan kriteria yang bersifat tunggal, ganda atau bahkan mungkin konflik. Hasil dari suatu proses optimasi adalah suatu himpunan masukan yang membuat fungsi-fungsi objektif menghasilkan nilai-nilai optimal (yang bisa berupa maksimal atau minimal). Dari beberapa algoritma optimasi yang ada, algoritma Tabu Search dapat digunakan untuk menyelesaikan masalah optimasi yang sulit.
2.3. Tabu Search
Menurut Glover dan Laguna (1998), Tabu Search pertama kali diperkenalkan oleh Glover sekitar tahun 1986. Glover menyatakan bahwa tabu
search adalah salah satu prosedur metaheuristik tingkat tinggi untuk penyelesaian
8
Menurut Suyanto (2010), Tabu Search adalah suatu metode optimasi matematis yang termasuk ke dalam local search. Tabu search memperbaiki perfomansi local search dengan memanfaatkan penggunaan struktur memori. Sebagian solusi yang pernah diberikan ditandai sebagai “tabu” (dalam ejaan lain
adalah “taboo” yang berarti sesuatu yang terlarang), sehingga algoritma tabu
search tidak akan mengangkat solusi tersebut secara berulang-ulang. Hal ini yang
membuat Tabu Search menjadi lebih efisien dalam hal usaha dan waktu.
Tabu Search menggunakan struktur memori yang disebut Tabu List untuk
menyimpan atribut dari sebagian move (langkah transisi dari satu solusi ke solusi yang lain) yang telah diterapkan pada iterasi-iterasi sebelumnya. Tabu List
digunakan untuk menolak solusi-solusi yang memenuhi atribut tertentu agar proses pencarian tidak berulang-ulang pada daerah solusi yang sama dan untuk menuntun proses pencarian menelusuri solusi-solusi yang belum pernah dikunjungi.
Untuk efisiensi memori dan waktu proses, Tabu List hanya menyimpan langkah transisi (move) yang merupakan kebalikan dari langkah yang telah digunakan pada iterasi-iterasi sebelumnya. Dengan kata lain, Tabu List hanya berisi langkah-langkah yang mengembalikan solusi yang baru ke solusi yang lama. Dengan menggunakan Tabu List, Tabu Search dapat menerima solusi yang tidak memberikan peningkatan kualitas, sehingga Tabu Search dapat keluar dari optimum lokal. Nilai optimum lokal sendiri adalah nilai solusi optimal dalam beberapa kriteria solusi.
agar proses pencarian tidak terjebak pada nilai optimum lokal. Metode ini menggunakan Tabu List untuk menyimpan sekumpulan solusi yang baru saja dievaluasi. Selama proses optimasi, pada setiap iterasi, solusi yang akan dievaluasi akan dicocokkan terlebih dahulu dengan isi Tabu List untuk melihat apakah solusi tersebut sudah ada pada Tabu List. Apabila solusi tersebut sudah ada pada Tabu List, maka solusi tersebut tidak akan dievaluasi lagi pada iterasi berikutnya. Apabila sudah tidak ada lagi solusi yang tidak menjadi anggota Tabu List, maka nilai terbaik yang baru saja diperoleh merupakan solusi yang sebenarnya.
Algoritma tabu search secara garis besar dapat ditulis sebagai berikut :
Menurut Hertz dkk (1995), algoritma di atas berisikan langkah-langkah dalam membangun proses iterasi dari solusi awal(i), solusi berikutnya(j) dan memeriksa apakah proses iterasi harus dihentikan atau mengulangi proses iterasi(k) kembali. Setiap prosedur iterasi akan menghasilkan solusi yang layak dari solusi awal(i) dan solusi berikutnya(j).
2.4. Aplikasi
Menurut Pressman (2010), aplikasi adalah elemen sistem logis daripada fisik. Karena itu, aplikasi memiliki karakteristik yang jauh berbeda dibandingkan dengan perangkat keras:
Langkah 1. Tentukan solusi awal i di dalam S.
Langkah 2. Cari j terbaik dalam N(i)(seperti f(j) f(k) untuk k di dalam N(i)). Langkah 3. Jika f(j) ≥f(i) maka berhenti. Jika tidak maka i=j dan pergi ke
10
a. Aplikasi dikembangkan atau direkayasa b. Aplikasi tidak habis pakai
c. Meskipun industri sekarang ini terus bergerak menuju pengembangan berbasis komponen, sebagian besar aplikasi terus diperbaharui sesuai dengan kebutuhan.
2.5. Siklus Hidup Pengembangan Sistem
Menurut Laudon dan Laudon (2007), siklus hidup pengembangan sistem adalah metode pengembangan sistem informasi yang paling tua. Metodologi siklus hidup adalah pendekatan bertahap untuk membangun sistem, membagi pengembangan sistem menjadi tahapan-tahapan yang formal.
Sedangkan menurut Hoffer dkk (2011), siklus hidup pengembangan sistem adalah metodologi umumuntuk pengembangan sistem di banyak organisasi. Di dalam siklus ini terdapat beberapa fase yang digunakan untuk menandai kemajuan analisa sistem dan desain. Siklus hidup dapat dianggap sebagai proses yang melingkar di mana akhir dari sebuah sistem dapat mengarah kepada proyek lain yang akan mengembangkan versi baru atau mengganti sistem yang ada.
2.6. Model Waterfall
berpuncak pada dukungan yang berkelanjutan dari perangkat lunak yang telah dibuat. Gambar model waterfall dapat dilihat pada Gambar 2.1.
Communication
Gambar 2.1 Model Waterfall (Pressman, 2010)
Kerangka proses generik untuk rekayasa perangkat lunak meliputi lima kegiatan berikut:
a. Communication(Komunikasi)
12
b. Planning(Perencanaan)
Proyek pembuatan aplikasi adalah perjalanan yang rumit, dan perencanaan adalah kegiatan yang membuat “peta” yang membantu dalam pengerjaan
proyek. Peta ini disebut juga software project plan berisikan rencana kerja rekayasa aplikasi dengan menggambarkan tugas-tugas teknis yang akan dikerjakan, resiko apa saja yang bisa terjadi, sumber daya apa yang dibutuhkan, hasil yang diharapkan dan jadwal kerja.
c. Modelling(Pemodelan)
Proses yang dilakukan untuk menggambarkan fitur-fitur dan fungsi-fungsi dari aplikasi yang akan dibuat. Sehingga dapat memahami dan memenuhi kebutuhan dari stakeholder.
d. Construction(Konstruksi)
Proses yang menggabungkan pembuatan aplikasi baik menggunakan pembuatan secara manual maupun secara otomatis. Proses ini juga mencakup proses uji coba terhadap aplikasi yang sudah dibuat untuk mengetahui apakah masih ada kesalahan dalam pembuatan aplikasi.
e. Deployment
13 3.1 Analisis
Dalam proses analisis, terdapat dua cara yang ditempuh, diantaranya : a. Wawancara/Interview
Langkah ini dilakukan untuk mengetahui permasalahan-permasalahan yang terjadi di Labkom, dimana permasalahan tersebut berkaitan dengan masalah penjadwalan praktikum. Selain itu, langkah ini dilakukan untuk mengetahui kebutuhan-kebutuhan aplikasi dan keinginan pihak Labkom yang nantinya akan menggunakan aplikasi ini nantinya. Wawancara ini dikoordinasikan oleh pihak Labkom, dimana pihak Labkom ini akan mendatangkan beberapa narasumber yang akan menggunakan aplikasi ini. Narasumber tersebut diantaranya adalah Ibu Ayuningtyas selaku kepala bagian Labkom.
b. Analisis Dokumen
Analisis dokumen ini adalah langkah untuk mengamati dan menganalisis dokumen apa saja yang berkaitan tentang penjadwalan. Dokumen yang diamati diantaranya adalah adalah dokumen KRS mahasiswa.
14
3.1.1 User Requirements
Berdasarkan hasil wawancara dengan bagian laboratorium komputer maka user requirements yang dibutuhkan adalah sebagai berikut.
Tabel 3.1 User Requirement Penjadwalan
Deskripsi : Fungsi ini digunakan oleh Labkom. Untuk melakukan proses penjadwalan praktikum
Aktor : Labkom, AAK Input
:
Data KRS mahasiswa, data pemakaian laboratorium dalam satu semester, data kriteria Labkom, data mata praktikum yang diselenggarakan, data praktikan
Proses : 1.Mencocokan data praktikan dengan KRS dan kriteria yang telah dibuat oleh Labkom
Output : Data Jadwal Praktikum Tersimpan Peraturan
1.Tidak boleh ada jadwal yang crash (dalam hal jam matapraktikum dan jam mata kuliah reguler)
2.Laboratorium yang digunakan tidak lebih dari kapasitas.
3.1.2 Software Requirements
Berdasarkan hasil analisis dari user requirements diatas, maka dibutuhkan software requirements yang dapat menunjang fungsi penjadwalan. Terdapat 1 fungsi dalam software requirements yang dibutuhkan, yaitu :
Tabel 3.2 Software Requirement Penjadwalan
Deskripsi : Fungsi ini digunakan oleh Labkom. Untuk melakukan proses penjadwalan praktikum
Awal : Masukkan Data Praktikan dan Data KRS Mahasiswa Alur
komputerisasi
(computerized-system-flow)
:
1. Aktor mengklik tombol proses jadwal
1.1. Aplikasi mengambil data KRS mahasiswa dan data praktikan
1.3. Aplikasi menampung data praktikan ke dalam array praktikan, data KRS ke dalam array KRS dan data jadwal praktikum awal ke dalam array jadwal awal 1.4. Proses Tabu array KRS, array praktikan dan array
jadwal awal
1.5. Aplikasi akan meng-update data jadwal 1.6. Aplikasi akan Menyimpan data jadwal Akhir : Jadwal Praktikum
Non
Fungsional :
3.1.3 Data Requirements
Dari beberapa software requirements yang sudah dijabarkan sebelumnya, maka diperlukan beberapa data untuk mendukung software requirements tersebut, beberapa data yang dibutuhkan diantaranya adalah.
a. Data Kriteria Labkom
Merupakan data kriteria dari pihak Labkom yang berisi tentang ketentuan penggunaan dan jumlah peserta dalam satu laboratorium.
b. Data Mata Praktikum Yang Diselenggarakan
Merupakan data mata praktikum yang diselenggarakan dalam satu semester.
c. Data Kartu Rencana Studi(KRS) Mahasiswa Terakhir
Merupakan data kartu rencana studi sebagai acuan dalam pembuatan jadwal mata praktikum.
d. Data Praktikan
16
3.2 Perancangan Aplikasi 3.2.1 Desain Proses
Dari hasil analisis software requirements di atas terdapat 1 fungsi yang digunakan agar aplikasi penjadwalan praktikum dapat berjalan. Fungsi yang telah dihasilkan dari analisa kebutuhan aplikasi tersebut akan digambarkan dalam
system flow, context diagram dan data flow diagram.
A. Document Flow
Document flow ini akan menjelaskan tentang proses penjadwalan yang lama. Proses dimulai oleh bagian AAK yang menyerahkan data praktikan. Labkom akan melakukan proses penjadwalan dengan tidak memperhatikan jumlah mata kuliah atau praktikum dalam satu hari. Apabila jadwal praktikum yang dibuat sudah sesuai maka jadwal praktikum akan disetujui dan diserahkan kepada AAK. Gambar 3.1 berikut ini merupakan document flow dari proses penjadwalan praktikum.
B. System Flow
System flow ini akan menjelaskan tentang aplikasi yang akan dibuat.
18
Gambar 3.2 System Flow Aplikasi Penjadwalan Praktikum
C. Context Diagram
Context diagram dibuat untuk menampilkan entitas apa saja yang akan
berinteraksi dengan aplikasi penjadwalan ini. Context diagram ini dibuat berdasarkan hasil analisis software requirements. Terdapat satu software
requirements yang dihasilkan yaitu penjadwalan. Dimana dari software
sehingga dalam hal ini bagian Labkom dan AAK otomatis menjadi entitas yang ikut membangun aplikasi tersebut. Gambar 3.3 ini merupakan gambar dari
Context Diagram aplikasi penjadwalan praktikum.
KRS Fix
Jadwal Praktikum
Data MK Praktikum Yang Diseleng g arakan Data Kriteria Labkom
Data Praktikan
Data KRS
0
Aplikasi Penjadwalan Praktikum
+
Sistem Administrasi AAK
Sistem Administrasi Labkom
Gambar 3.3 Context Diagram
20
D. DFD Level 0 Aplikasi Penjadwalan Praktikum
Sama halnya dengan context diagram, DFD level 0 aplikasi penjadwalan praktikum ini dibuat berdasarkan software requirements. Gambar 3.4 ini merupakan DFD level 0 aplikasi penjadwalan praktikum.
[Jadwal Praktikum]
[Data MK Praktikum Yang Diseleng g arakan] [Data Praktikan]
Proses Peng ecekan Tabu List
4
Pembuatan Jadwal Praktikum dan KRS
Gambar 3.4 DFD Level 0 Aplikasi Penjadwalan Praktikum
Proses pertama dari DFD level 0 adalah proses membuat jadwal inisialisasi. Pada proses ini, sistem administrasi AAK akan memasukkan data praktikan. Sistem administrasi Labkom akan memasukkan data MK praktikum yang diselenggarakan, data hari, dan data shift praktikum. Hasil dari proses ini akan dimasukkan ke dalam tabel JDW_PRK_AWAL.
data yang ada pada tabel JDW_PRK_AWAL. Sedangkan, data jadwal belum fix akan dimasukkan ke dalam tabel TABU_LIST.
Proses yang ketiga adalah proses pengecekan tabu list. Proses ini akan mengecek data dalam tabel TABU_LIST terhadap KRS praktikan sehingga dapat dicari data jadwal praktikum yang cocok dengan KRS praktikan. Proses ini akan menghasilkan data jadwal fix yang akan kembali dimasukkan ke dalam tabel JDW_PRK_AWAL. Proses terakhir adalah proses menampilkan data jadwal praktikum dan KRS praktikan. Hasil dari proses ini adalah hasil dari proses penjadwalan yaitu, jadwal praktikum beserta praktikan dan KRS praktikan.
3.2.2 Desain Data
Setelah selesai menggambarkan desain proses diatas, maka dapat diketahui desain data yang dibutuhkan dalam menunjang berjalannya aplikasi penjadwalan praktikum. Dari Gambar 3.4 DFD level 0 aplikasi penjadwalan praktikum di atas, dibutuhkan dua buah desain data yang diperlukan dalam pembuatan aplikasi penjadwalan praktikum ini. Kedua data tersebut diantaranya adalah JDW_PRK_AWAL dan TABU_LIST. Kedua desain data tersebut akan digambarkan dalam bentuk ER-Model dan normalisasi
A. Desain Konseptual
Desain konseptual kali ini diawali dengan pembuatan desain entity
relationship model (model ER). Model ER ini nantinya digunakan untuk
22
harus disimpan atau dibutuhkan pada sebuah entitas atau pada sebuah hubungan antar entitas. Dari desain data konseptual tersebut maka dapat dihasilkan model data fisikal, yaitu daftar tabel yang akan digunakan pada aplikasi. Desain model ER tersebut dapat dilihat pada Gambar 3.5.
JDW_PRK_AWAL
Gambar 3.5 Desain Model ER
B. Normalisasi
1. Tabel JDW_PRK_AWAL
Tabel 3.3 Tabel JDW_PRK_AWAL
a. 1NF/ First Normal Form (Bentuk Normal Prima)
Kriteria Pass
Semua nilai atribut harus simple/atomic yang tidak bisa dibagi-bagi lagi (tidak boleh ada atribut yang komposit/ multivalue)
b. 2NF/ First Normal Form (Bentuk Normal Kedua)
Kriteria Pass
Memenuhi Kriteria 1NF
Setiap attribute bergantung penuh pada
primary key
c. 3NF/ First Normal Form (Bentuk Normal Ketiga)
Kriteria Pass
Memenuhi Kriteria 2NF
Tidak ada ketergantungan transitif, yaitu atribut bukan key tidak tergantung secara transitif terhadap atribut key
2. Tabel Jadwal
Tabel 3.4 Tabel TABU_LIST
a. 1NF/ First Normal Form (Bentuk Normal Prima)
Kriteria Pass
24
Kriteria Pass
yang tidak bisa dibagi-bagi lagi (tidak boleh ada atribut yang komposit/ multivalue)
b. 2NF/ First Normal Form (Bentuk Normal Kedua)
Kriteria Pass
Memenuhi Kriteria 1NF
Setiap attribute bergantung penuh pada
primary key
c. 3NF/ First Normal Form (Bentuk Normal Ketiga)
Kriteria Pass
Memenuhi Kriteria 2NF
Tidak ada ketergantungan transitif, yaitu atribut bukan key tidak tergantung secara transitif terhadap atribut key
Dari hasil pengecekkan diatas, dapat diketahui bahwa tabel jdw_prk_awal dan tabu_list telah memenuhi bentuk 3NF, dimana atrribut bukan key yang ada di dalam kedua tabel tersebut tidak tergantung secara transitif terhadap attribut key.
C. CDM (Conceptual Data Model)
Pada conceptual data model (CDM) ini terdapat 2 entitas (tabel) antara entitas jdw_prk_awal dan tabu_list, dimana entitas jdw_prk_awal dan tabu_list bergantung pada entitas mahasiswa dengan hubungan relasi (one to one). Kedua tabel ini merupakan tabel asli yang telah dibuat oleh peneliti guna melengkapi tabel yang sudah disediakan oleh perusahaan untuk kepentingan penelitian ini. Desain CDM bisa dilihat pada Gambar 3.11.
Mempunyai
Gambar 3.6 CDM(Conceptual Data Model)
3.2.3 Desain Antarmuka
A Antarmuka Perangkat Lunak
Aplikasi penjadwalan praktikum yang akan dibuat ini membutuhkan data excel untuk dapat menghasilkan jadwal praktikum. Selain itu, dibutuhkan sebuah driver oracle yang bernama Oracle.DataAccess.dll, driver ini berfungsi untuk menghubungkan antara aplikasi dengan database oracle. Gambar 3.6 ini merupakan gambar desain antarmuka perangkat lunak.
Database
Gambar 3.7 Gambar Antarmuka Perangkat Lunak
B Antarmuka Pengguna
26
GUI secara keseluruhan. Missal, dari form login lalu ke form utama, dan seterusnya
1. Desain Form Penjadwalan
Form penjadwalan digunakan oleh pengguna untuk melakukan proses penjadwalan praktikum. Pada form penjadwalan ini terdapat dua buah textbox
yang berfungsi untuk menampung alamat dari data KRS dan data praktikan, dalam hal ini berupa data excel. Di dalam form ini juga terdapat empat buah
button. Untuk button pilih digunakan untuk memilih data KRS dan data
praktikan yang akan digunakan untuk proses penjadwalan praktikum. Sedangkan untuk button proses digunakan untuk memproses data KRS dan data Praktikan tersebut menjadi jadwal praktikum. Button batal digunakan untuk keluar dari aplikasi. Desain form penjadwalan dapat dilihat pada Gambar 3.8.
Gambar 3.8 Desain Form Penjadwalan
Alur fungsional utama untuk halaman penjadwalan adalah sebagai berikut function proses()
{
membuat jadwal inisialisasi
mengambil data KRS dan data praktikan;
melakukan perulangan sebanyak data praktikan yang mengambil mata praktikum
foreach($datapraktikan) {
mencari jadwal yang tidak berbenturan dengan jadwal kuliah reguler;
mencari hari di mana praktikan memiliki jadwal kuliah reguler di bawah 3 mata kuliah;
if (KRS praktikan < 3) {
if (kriteria Labkom terpenuhi) {
simpan data jadwal ke dalam tabel jadwal; }
else {
mencari jadwal lain yang cocok dengan kriteria Labkom
} } else {
mencari jadwal lain yang tidak melebihi jadwal mata kuliah praktikan
} }
}
2. Desain Form Tampil Jadwal Praktikum
28
Gambar 3.9 Desain Form Tampil Jadwal Praktikum
3. Desain Form Tampil KRS Praktikan
Form tampil KRS praktikan ini digunakan untuk menampilkan KRS praktikan. Form ini berfungsi untuk membuktikan penggunaan metode tabu search sehingga, satu praktikan tidak memiliki jadwal mata kuliah atau praktikum yang melebihi tiga jadwal. Gambar 3.10 menunjukkan desain form tampil KRS praktikan.
Tampil KRS Praktikan
Kode MK HARI Jam Mulai
Text
3.2.4 Desain Fisik
Setelah mengetahui desain data yang dibutuhkan, maka langkah selanjutnya adalah menggambarkan desain fisik. Dalam aplikasi penjadwalan tambat kapal ini, Database management systems (DBMS) yang digunakan adalah
oracle database. Terdapat 3 tabel baru yang dibutuhkan dalam aplikasi ini, yaitu
tabel KRS, mahasiswa dan jadwal. Ketiga tabel tersebut akan digambarkan dalam
Physical Data Model (PDM).
a. PDM (Physical Data Model)
Gambar 3.11 PDM(Physical Data Model)
b. Struktur Tabel
1. Nama Tabel : JDW_PRK_AWAL
Keterangan : Untuk menyimpan data jadwal praktikum. Tabel 3.5 Struktur Tabel JDW_PRK_AWAL
Nama Kolom Tipe Data Constraint Keterangan
NIM Char(11) FK NIM Mahasiswa
KODE_MK Char(9) FK Kode Mata Kuliah
30
Nama Kolom Tipe Data Constraint Keterangan
SHIFT_MF_ID Char(1) FK Shift Praktikum RUANG_MF_ID Char(4) FK Ruang Praktikum
FIX Char(1) NN
2. Nama Tabel : TABU_LIST
Keterangan : Untuk menyimpan data tabu.
Tabel 3.6 Struktur Tabel TABU_LIST
Nama Kolom Tipe Data Constraint Keterangan
NIM Char(11) FK NIM Mahasiswa
KODE_MK Char(9) FK Kode Mata Kuliah
HARI_MF_ID Char(1) FK Hari Praktikum
SHIFT_MF_ID Char(1) FK Shift Praktikum RUANG_MF_ID Char(4) FK Ruang Praktikum
3.2.5 Perancangan Algoritma Tabu Search
Algoritma tabu search pada penjadwalan praktikum ini dibagi menjadi empat bagian di mana terdiri dari satu bagian utama dan tiga bagian pendukung yaitu pembuatan jadwal inisialisasi, pengecekan jadwal inisialisasi dan pengecekan tabu list. Keempat algoritma tersebut dihubungkan dengan connector off page antara satu dengan lainnya. Tujuan dari pembagian tersebut tidak lain adalah memudahkan dalam pembacaan algoritma tabu search tersebut. Di bawah ini merupakan penjelasan dari keempat algoritma tabu search penjadwalan praktikum.
tiap mata praktikum. Dilanjutkan dengan proses perulangan untuk mencari ruang laboratorium yang cocok untuk praktikan tersebut. Apabila sudah menemukan kecocokan antara ruangan dan praktikan, maka proses akan dilanjutkan ke bagian ketiga.
Pada algoritma bagian ketiga ini, proses di mulai dengan mengambil data dari hasil penjadwalan inisialisasi, data tersebut akan dibandingkan dengan data KRS masing-masing praktikan. Apabila KRS praktikan pada hari dan shift tersebut cocok maka, proses dilanjutkan dengan memperbaharui data pada tabel JDW_PRK_AWAL. Jika tidak menemui kecocokan maka, data praktikan yang tidak cocok tersebut akan dimasukkan ke dalam tabel TABU_LIST.
Pada algoritma bagian keempat ini, proses di mulai dengan mengambil data dari tabel TABU_LIST. Pada proses ini data pada tabel TABU_LIST akan dibandingkan dengan KRS praktikan. Apabila ada kecocokan antara KRS dan data pada tabel TABU_LIST, maka data pada TABU_LIST akan dihapus dan dipindah ke dalam tabel JDW_PRK_AWAL. Apabila tidak ada kecocokan antara KRS dan data pada tabel TABU_LIST, maka akan dilakukan perulangan untuk hari dan shift berikutnya.
32
Start
Mengambil Data KRS dan Data
Praktikan
Foreach,…, (jumlah praktikan tiap MK), do
Kapasistas_Ruang > 0 For Ruang = 1,…,(7),do
MK_Ruang = MK
Insert to jdw_prk_awal
Ya
Ya
Tidak Tidak
1
1
Mengambil data dari JDW_PRK_AWAL
Foreach,…, (jumlah data dalam JDW_PRK_AWAL), do
Foreach,…, (jumlah KRS Tiap Praktikan), do
Jml_KRS >= 3
Jam_KRS = Shift_Praktikum
3 Update fix = 1
Insert to Tabu_List
2 Tidak
Tidak Ya
Ya
34
2
Foreach,…, (jumlah data dalam TABU_LIST), do
For hari=2,…,6, do
KRS_Hari >= 3
For shift=1,…,6,do
Jam_KRS = Jam_shift
Insert into JDW_PRK_AWAL
and FIX=1 Mengambil data
dari TABU_LIST
Tidak
Tidak Ya
Ya
3
Tampilkan Jadwal FIX
Selesai
3.3 Desain Uji Coba 3.3.1 Desain Uji Fungsional
Desain uji fungsional ini digunakan sebagai dasar melakukan pengujian terhadap aplikasi dan untuk membuktikan bahwa fungsi dari metode Tabu Search pada aplikasi sudah berjalan sesuai dengan semestinya. Pengujian fungsional ini akan dilakukan dengan membandingkan antara hasil dari penjadwalan praktikum menggunakan metode tabu search secara manual dan hasil dari penjadwalan praktikum menggunakan metode tabu search secara aplikasi. Diharapkan setelah pengujian akan ada kesamaan hasil dari penjadwalan secara manual dan aplikasi.
Pada pengujian fungsional ini akan menggunakan data KRS semester 142. Data yang digunakan dalam penjadwalan manual dapat dilihat pada Tabel 3.7.
Tabel 3.7 Data KRS Semester 142
MHS_NIM kode MK Hari Mulai selesai
08410100071 410104015 1 07:32 07:33
08410100071 410103092 2 13:30 16:00 08410100071 410102053 3 10:30 13:00 08410100071 410102055 3 13:30 15:10 08410100071 410102054 4 15:45 17:25
08410100071 410103083 5 10:30 13:00 08410100071 410103086 5 15:15 17:45 08410100071 410103078 6 07:30 10:00
08410100071 410109041 7 07:42 07:43
08410100071 410109042 7 07:58 07:59
08410100071 410109044 7 07:50 07:51
Terdapat beberapa langkah yang harus dilalui dalam perhitungan tabu
search sercara manual ini. Langkah-langkah tersebut diantaranya sebagai berikut.
36
2. Memasukkan semua praktikan yang memiliki mata praktikum yang sama dalam satu laboratorium dengan kapasitas 18 peserta.
3. Melakukan pengecekan jumlah KRS dalam satu hari apabila dalam satu hari sudah ada tiga jadwal mata kuliah, maka praktikan tersebut akan dipindah di hari yang tidak memiliki tiga jadwal mata kuliah .
4. Melakukan pengecekan KRS dengan jadwal praktikum apabila ada jadwal mata kuliah dan jadwal mata praktikum yang berbenturan maka, praktikan tersebut akan dipindah di mana tidak ada jadwal yang tidak berbenturan. 5. Hasil akhir dari pemrosesan manual ini dapat dilihat pada Tabel 3.8.
Tabel 3.8 Hasil Tabu Search Secara Manual NIM KODE_MK HARI SHIFT RUANG
08410100071 410109041 2 1 B606 08410100071 410109042 2 2 B609 08410100071 410109044 3 1 B610
3.3.2 Desain Uji Data
37 BAB IV
IMPLEMENTASI DAN EVALUASI
4.1 Implementasi Aplikasi
Aplikasi penjadwalan praktikum ini digunakan oleh bagian Labkom. Pada sub-bab ini akan dijelaskan form apa saja yang dapat digunakan oleh bagian Labkom.
A Form Penjadwalan
Form penjadwalan ini digunakan untuk memproses data KRS dan praktiakn yang diinputkan melalui data excel. Untuk melakukan proses penjadwalan menggunakan form ini, pengguna tinggal menekan tombol yang bertuliskan “proses” yang ada di sisi kanan bawah form penjadwalan ini. Setelah pengguna menekan tombol tersebut, aplikasi akan memproses data KRS dan praktikan yang ada di database.
38
B Form Tampil Peserta Praktikum
Form tampil peserta praktikum digunakan untuk menampilkan peserta praktikum dalam satu grup praktikum. Form tampil peserta praktikum dapat dilihat pada Gambar 4.3.
Gambar 4.2 Form Tampil Peserta Praktikum
C Form Tampil KRS Praktikan
Gambar 4.3 Form Tampil KRS Praktikan
4.2 Evaluasi Aplikasi
Setelah proses perencanaan dan implementasi aplikasi penjadwalan praktikum ini selesai, maka langkah terakhir yang harus dilakukan dalam penelitian ini adalah tahapan evaluasi. Tahapan evaluasi ini berupa uji data antara data penjadwalan manual dan data penjadwalan oleh aplikasi penjadwalan praktikum.
4.2.1 Uji Fungsional
40
Tabel 4.1 Data KRS Semester 142
MHS_NIM kode MK Hari Mulai selesai
Setelah pada tahapan sebelumnya penjadwalan praktikum menggunakan metode tabu search dilakukan secara manual, maka pada tahapan ini penjadwalan praktikum akan diproses menggunakan aplikasi. Data yang digunakan pada tahapan ini masih sama seperti yang digunakan pada tahapan sebelumnya. Hasil dari pemrosesan menggunakan aplikasi diperlihatkan pada Tabel 4.3.
Tabel 4.2 Hasil Uji Tabu Search Dengan Aplikasi
4.2.2 Uji Data
Uji data yang akan dilakukan adalah dengan membandingkan antara jadwal praktikum yang dihasilkan melalui proses penjadwalan manual yang sudah dilakukan sebelumnya oleh bagian Labkom dengan jadwal praktikum yang dihasilkan oleh aplikasi. Uji coba data dilakukan sebanyak satu kali dengan data praktikan yang akan diambil adalah data praktikan semester 142. Berikut ini adalah hasil uji coba tersebut.
Tabel 4.3 Hasil Uji Data Dari Aplikasi
MHS_NIM kode MK Hari Mulai selesai
08410100071 410104015 1 07:32 07:33 08410100071 410103092 2 13:30 16:00
08410100071 410109041 2 07:30 09:15
08410100071 410109042 2 09:30 11:15
08410100071 410102053 3 10:30 13:00 08410100071 410102055 3 13:30 15:10
08410100071 410109044 3 07:30 09:15
42 BAB V PENUTUP
5.1. Kesimpulan
Setelah dilakukan uji coba dan evaluasi terhadap aplikasi penjadwalan praktikum yang telah dibuat, maka dapat ditarik kesimpulan sebagai berikut: 1. Aplikasi yang dibuat dapat menangani proses penjadwalan praktikum
berdasarkan data KRS praktikan dan kriteria yang disediakan oleh Labkom, serta proses-proses yang berhubungan dengan maintenance kriteria Labkom dengan menggunakan metode Tabu Search.
2. Aplikasi yang dibuat dapat menghasilkan output berupa jadwal praktikum setelah proses penjadwalan menggunakan metode Tabu Search.
5.2. Saran
Adapun beberapa saran yang dapat diberikan kepada peneliti berikutnya apabila ingin mengembangkan aplikasi yang telah dibuat ini agar menjadi lebih baik adalah sebagai berikut:
1. Perlu adanya sistem reminder untuk praktikum kepada praktikan sesuai dengan jadwal praktikumnya masing-masing.
2. Akan lebih baik jika sistem ini dapat digunakan dalam proses maintenance
Farida, N. I. 2008. Sistem Pendukung Keputusan Penjadwalan Pengajar Praktikum Laboratorium Komputer STIKOM Menggunakan Agoritma Genetika.
Surabaya: STIKOM Surabaya.
Glover, F., dan Laguna, M. 1998. Tabu Search. Massachussets: Kluwer Academic Publishers.
Hertz, A., Taillard, E., dan Werra, D. d. 1995. A Tutorial On Tabu Search. 1.
Hoffer, J. A., George, J. F., dan Valacich, J. S. 2011. Modern System Analysis and
Design. New Jersey: Pearson Education, Inc.
Idris, M. R. 2013. Rancang Bangun Aplikasi Penjadwalan Pengajar Menggunakan
Tabu Search Pada Labkom STIKOM Surabaya. Surabaya: STIKOM
Surabaya.
Kendall, K. E., dan Kendall, J. E. 2008. System Analysis and Design. New Jersey: Pearson Prentice Hall.
Kusumadewi, S., dan Purnomo, H. 2005. Penyelesaian Masalah Optimasi Dengan
Teknik-Teknik Heuristik. Yogyakarta: Graha Ilmu.
Laudon, K. C., dan Laudon, J. P. 2007. Sistem Informasi Manajemen Mengelola
Perusahaan Digital. New Jersey: Pearson Education, Inc.
Pinedo, M. 2002. Scheduling: Theory, Algorithms, and Systems. New Jersey: Prentice-Hall, Inc.
Pressman, R. S. 2010. Software Engineering, A Practitioner's Approach. New York: The McGraw-Hill Companies, Inc.
