TA : Rancang Bangun Aplikasi Pengoptimalan Penjadwalan Praktikum Menggunakan Metode Tabu Search Pada Laboratorium Komputer Institut Bisnis dan Informatika Stikom Surabaya.

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

INSTITUT BISNIS DAN INFORMATIKA STIKOM SURABAYA 2015

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.

Di dalam praktikum ada beberapa faktor yang dapat menyebabkan mahasiswa dapat lulus dengan nilai yang memuaskan. Beberapa faktor tersebut adalah dari sisi pengajar, modul, dan jadwal praktikum itu sendiri. Proses penjadwalan yang terjadi di Labkom Stikom Surabaya saat ini dimulai dari pengumpulan data mata praktikum yang diselenggarakan oleh masing-masing program studi dan pengumpulan data praktikan yang mengikuti mata praktikum. Setelah pengumpulan data tersebut, dilakukan penentuan dan plotting grup dan ruang praktikum pada daftar mata praktikum wajib beserta grup dan ruang per prodi. Apabila grup dan ruang praktikum sudah ada, dilakukan proses penjadwalan dengan kriteria penjadwalan antara lain berdasarkan adanya grup praktikum untuk praktikan, antar grup praktikum tidak ada praktikan yang mengalami crash pada jadwal mata praktikum, adanya jumlah minimal praktikan dalam satu grup praktikum, dan tidak memperhitungkan jumlah mata kuliah dalam sehari dari praktikan itu sendiri. Jika jadwal praktikum sudah terbentuk,

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)

Sedangkan sebanyak 65% praktikan mengharapkan satu hari semaksimalnya tiga jadwal kuliah dan jadwal praktikum (Lampiran I). Dampak dari pembuatan jadwal tersebut juga berpengaruh dalam tingkat kelulusan praktikan. Hal ini dapat terlihat pada Gambar 1.2 yang menunjukkan grafik tingkat kelulusan praktikan yang setiap semesternya terus menurun.

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

adalah salah satu prosedur metaheuristik tingkat tinggi untuk penyelesaian permasalahan optimasi kombinatorial. Implementasi metode tabu search dalam penelitian ada tiga langkah yaitu, (1) pembuatan jadwal inisialisasi, (2) penyesuaian dengan kriteria yang diajukan oleh Labkom Stikom Surabaya, (3) penyesuaian dengan kriteria yang sesuai dengan praktikan dan Kartu Rencana Studi (KRS) praktikan. Dengan adanya solusi ini diharapkan dapat meminimalkan jumlah mahasiswa yang mendapat jadwal kuliah dan jadwal praktikum terlalu

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

Laporan tugas akhir ini dibagi menjadi lima bab, yaitu bab pendahuluan, bab landasan teori, bab analisis dan perancangan sistem, bab implementasi dan evaluasi sistem, dan bab penutup.

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.

Bab penutup berisi tentang kesimpulan dari penelitian yang telah dilakukan. Bab ini juga berisi saran-saran yang dapat menjadi tambahan untuk pengembangan produk hasil penelitian ke depan.

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.

Permasalahan dalam proses penjadwalan dapat diselesaikan dengan menggunakan algoritma optimasi.

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

permasalahan optimasi kombinatorial. Tabu search ini dirancang untuk mengarahkan metode-metode lain (atau komponen proses tabu search itu sendiri) untuk keluar atau menghindari dari masuk ke dalam solusi optimal yang bersifat lokal. Kemampuan tabu search dalam menghasilkan solusi yang mendekati optimal telah dimanfaatkan dalam beragam permasalahan di berbagai bidang mulai penjadwalan hingga bidang telekomunikasi.

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.

Menurut Kusumadewi dan Purnomo (2005), Tabu Search merupakan suatu metode optimasi yang menggunakan short-term memory untuk menjaga

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

Menurut Pressman (2010), model waterfall adalah siklus hidup klasik, menunjukkan secara sistematis, pendekatan sekuensial untuk pengembangan perangkat lunak yang diawali dengan spesifikasi persyaratan pelanggan dan berkembang melalui planning, modeling, construction, dan deployment,

berpuncak pada dukungan yang berkelanjutan dari perangkat lunak yang telah dibuat. Gambar model waterfall dapat dilihat pada Gambar 2.1.

Communication

Project initiation Requirements gathering

Planning

Estimating Scheduling Tracking

Modeling

Analysis Design

Construction

Code Test

Deployment

Delivery Support Feedback

Gambar 2.1 Model Waterfall (Pressman, 2010)

Kerangka proses generik untuk rekayasa perangkat lunak meliputi lima kegiatan berikut:

a. Communication(Komunikasi)

Sebelum pekerjaan teknis dapat dimulai, sangat penting untuk berkomunikasi dan berkolaborasi dengan pelanggan atau stakeholder. Tujuannya adalah untuk memahami kemauan dari stakeholder untuk proyek ini dan untuk mengumpulkan kebutuhan yang membantu mendefinisikan fitur-fitur dan fungsi-fungsi aplikasi.

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

Aplikasi yang sudah dibuat akan diberikan kepada stakeholder sehingga dapat dievaluasi dan memberikan saran dan kritik berdasarkan evaluasi terhadap aplikasi.

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.

Dokumen KRS mahasiswa akan dijadikan sebagai acuan dalam fungsi penjadwalan praktikum. Adapun dokumen lain yang digunakan untuk proses penjadwalan praktikum adalah, data pemakaian laboratorium dalam satu semester, data kriteria Labkom, data mata praktikum yang diselenggarakan dan data praktikan.

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.2. Aplikasi membuat jadwal praktikum awal berdasarkan kriteria Labkom dan data pemakaian laboratorium

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

Merupakan data dari praktikan yang mengikuti mata praktikum yang diselenggarakan.

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

AAK Labkom

Mulai

Memberikan Data KRS dan Data

Praktikan

Data KRS Data Praktikan

Ja dwal Praktikum yang sudah disetujui

oleh Labkom Ja dwal Praktikum

yang sudah disetujui oleh Labkom

Selesai Menginputkan Da ta

KRS dan Data Praktikan

Data KRS Data Praktikan

Melakukan Pengeceka n Terhadap KRS

Praktikan

Mata Kuliah/ Praktikum ≥ 3 dalam

satu ha ri?

Menyetujui jadwal praktikum yang

sudah dibuat

Ja dwal Praktikum

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.

Pertama-tama, bagian AAK akan menyerahkan data KRS dan data praktikan dan bagian Labkom akan menginputkan data tersebut sehingga data tersebut dapat diolah dalam proses pengecekan jadwal KRS praktikan. Apabila dalam satu hari praktikan memiliki 3 jadwal mata kuliah atau praktikum maka, proses pengecekan akan diulangi untuk hari yang lain. Apabila jadwal praktikum yang dibuat sudah sesuai maka jadwal praktikum akan disetujui dan diserahkan kepada AAK. Gambar 3.2 ini merupakan gambar dari system flow aplikasi penjadwalan praktikum.

18

AAK Labkom

Mulai

Memberikan Data KRS dan Data

Praktikan

Data KRS Data Praktikan

Jadwal Praktikum yang sudah disetujui

oleh Labkom Ja dwal Praktikum

yang sudah disetujui oleh Labkom

Selesai Menginputkan Data

KRS dan Data Praktikan

Data KRS Data Praktikan

Melakukan Pengeceka n Terhadap KRS

Praktikan

Mata Kuliah/ Praktikum ≥ 3 dalam

satu ha ri?

Menyetujui jadwal praktikum yang

sudah dibuat

Jadwal Praktikum

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

Bagian Labkom yang akan menggunakan aplikasi penjadwalan praktikum ini akan memberikan inputan data pemakaian laboratorium dan data kriteria Labkom dan akan menerima output berupa jadwal praktikum. Bagian AAK akan membantu aplikasi penjadwalan praktikum dengan memberikan inputan data KRS mahasiswa, data peserta praktikum(praktikan) dan data mata praktikum yang diselenggarakan.

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]

[KRS Fix]

Data Jadwal Fix

Data Tabu Lis t

Data Jadwal

Data Jadwal Belum Fix

Data Jadwal Fix [Data KRS]

Data Jadwal Inisialisas i Data Jadwal Inisialisas i

[Data Ruang] [Data Shift]

[Data MK Praktikum Yang Diseleng g arakan] [Data Praktikan] Sis tem Administra si AAK Sis tem Administrasi Labkom 1 Membuat Jadwal Inisialis asi 1 JDW_PRK_AWAL 2

Proses Peng ecekan Terhadap KRS

Praktikan

2 TABU_LIST

3

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.

Proses yang kedua adalah proses pengecekan terhadap KRS praktikan, proses ini dimulai dari sistem administrasi AAK memberikan data KRS. Proses pengecekan terhadap KRS praktikan ini akan menghasilkan dua data jadwal, yaitu data jadwal fix dan data jadwal belum fix. Data jadwal fix akan memperbaharui

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

memetakan hubungan antara entitas dalam proses yang akan ditangani oleh aplikasi, yang kemudian digunakan untuk mendesain model data konseptual. Desain model data konseptual digunakan untuk menentukan data apa saja yang

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

NIM KODE_MK

FIX

HARI SHIFT

TABU_LIST MEMPUNYAI

1.1 0.1

RUANG

NIM KODE_MK

HARI

SHIFT

RUANG

Gambar 3.5 Desain Model ER

B. Normalisasi

Dari Model ER yang telah dibuat perlu dinormalisasikan. Di sini dilakukan tiga tahap normalisasi yaitu normalisasi pertama untuk mengecek apakah setiap nilai atribut dalam tabel ada yang memiliki dua nilai yang berbeda. Normalisasi kedua adalah pengecekan apakah tabel yang ada bergantung penuh pada primary key setiap tabel. Normalisasi ketiga adalah tidak adanya ketergantungan transitif, yaitu atribut bukan key tidak tergantung secara transitif terhadap atribut key.

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 JDW_PRK_AWAL NIM KODE_MK SHIFT_MF_ID RUANG_MF_ID HARI_MF_ID FIX ... <M> <M> <M> <M> <M> <M> TABU_LIST NIM KODE_MK SHIFT_MF_ID RUANG_MF_ID HARI_MF_ID <M> <M> <M> <M> <M>

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 Oracle ORACLE.DATA ACCESS.dll Aplikasi APLIKASI EXCEL USER

Gambar 3.7 Gambar Antarmuka Perangkat Lunak B Antarmuka Pengguna

Antar muka pengguna adalah sebuah titik dimana aplikasi dan user saling berinteraksi. Interaksi ini dapat melalui layar dan keyboard (interaksi langsung) atau melalui laporan yang dicetak dan form-form yang didesain untuk menangkap data (interaksi tidak langsung). Fokus desain antar muka pengguna adalah pada interaksi tidak langsung. Pada bagian ini, digambarkan terlebih dahulu alur kerja

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.

Aplikasi Penjadwalan

Enter Text

Enter Text

Pilih Data KRS :

Pilih Data Praktikan :

Batal Proses

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

Form tampil jadwal ini digunakan untuk menampilkan jadwal yang sudah dibuat oleh aplikasi. Jadwal yang ditampilkan jadwal untuk satu mata praktikum. Pada form ini terdapat satu buah data grid view yang berguna untuk menampilkan jadwal praktikum harian. Gambar 3.8 menunjukkan desain dari form tampil jadwal praktikum.

28

Tampil Jadwal Praktikum

NIM Nama

Nama Lab

Text Text Text

Text Text Text

Shift

Nama Praktikum

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 Text Text

Text Text Text

Text Text Text

Nama : xxxxxx NIM : xxxxxx

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)

Pada Physical Data Model (PDM) ini, terdapat 3 tabel sama halnya degan

Conceptual Data Model yang telah dibuat sebelumnya. PDM ini dihasilkan dari

proses generate CDM diatas. Desain PDM tersebut dapat dilihat pada Gambar 3.12. JDW_PRK_AWAL NIM KODE_MK SHIFT_MF_ID RUANG_MF_ID HARI_MF_ID FIX CHAR(11) CHAR(9) CHAR(1) CHAR(4) CHAR(1) CHAR(1) TABU_LIST NIM KODE_MK SHIFT_MF_ID RUANG_MF_ID HARI_MF_ID CHAR(11) CHAR(9) CHAR(1) CHAR(4) CHAR(1)

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.

Algoritma tabu search ini dimulai dari bagian pertama, di mana algoritma akan mengambil data KRS dan data praktikan. Data tersebut akan langsung diolah pada algoritma bagian kedua untuk proses pembuatan jadwal inisialisasi. Proses pembuatan jadwal inisialisasi ini dimulai dengan perulangan data praktikan untuk

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.

Gambar flowchart dari proses penjadwalan inisialisasi dapat dilihat pada Gambar 3.12. Gambar flowchart dari proses pengecekan jadwal inisialisasi dapat dilihat pada Gambar 3.13. Gambar flowchart dari proses pengecekan tabu list dapat dilihat pada Gambar 3.14.

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

Desain uji data ini digunakan sebagai dasar melakukan pengujian terhadap aplikasi dan membuktikan bahwa hasil penjadwalan menggunakan metode tabu search dari aplikasi sudah menjawab rumusan masalah di atas. Pengujian data ini akan dilakukan dengan membandingkan antara hasil dari penjadwalan secara manual yang lakukan oleh Labkom dan hasil dari penjadwalan secara aplikasi. Diharapkan setelah pengujian hasil dari aplikasi dapat menjawab rumusan masalah di atas.

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

Form tampil KRS praktikan digunakan untuk menampilkan KRS praktikan yang sudah mengalami proses penjadwalan praktikum. Sehingga, dalam satu hari tidak aka nada jadwal mata kuliah atau praktikum yang lebih dari tiga mata kuliah atau praktikum. Form tampil KRS praktikum dapat dilihat pada Gambar 4.4.

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

Sub tahapan ini akan membandingkan metode tabu search penjadwalan praktikum yang diproses secara manual daengan metode tabu search yang telah diterapkan pada aplikasi. Pengujian ini dilakukan untuk mengetahui apakah metode tabu search pada aplikasi penjadwalan praktikum yang telah dibuat sudah sesuai dengan metode tabu search secara umum. Uji fungsional ini akan memakai data KRS semester 142. Berikut data yang digunakan untuk penjadwalan.

40

Tabel 4.1 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

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

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

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

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

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

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.

Suyanto. 2010. Algoritma Optimasi: Deterministik atau Probabilitik. Yogyakarta: Graha Ilmu.

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

Form tampil KRS praktikan digunakan untuk menampilkan KRS praktikan yang sudah mengalami proses penjadwalan praktikum. Sehingga, dalam satu hari tidak aka nada jadwal mata kuliah atau praktikum yang lebih dari tiga mata kuliah atau praktikum. Form tampil KRS praktikum dapat dilihat pada Gambar 4.4.

39

Gambar 4.3 Form Tampil KRS Praktikan

4.2Evaluasi 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

Sub tahapan ini akan membandingkan metode tabu search penjadwalan praktikum yang diproses secara manual daengan metode tabu search yang telah diterapkan pada aplikasi. Pengujian ini dilakukan untuk mengetahui apakah metode tabu search pada aplikasi penjadwalan praktikum yang telah dibuat sudah sesuai dengan metode tabu search secara umum. Uji fungsional ini akan memakai data KRS semester 142. Berikut data yang digunakan untuk penjadwalan.

Tabel 4.1 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

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

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

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

41

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

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

42

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 jadwal saat praktikum sudah berlangsung.

DAFTAR PUSTAKA

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.

Suyanto. 2010. Algoritma Optimasi: Deterministik atau Probabilitik. Yogyakarta: Graha Ilmu.