BAB V IMPLEMENTASI DAN PENGUJIAN Pada bab ini akan dijelaskan mengenai implementasi dan pengujian perangkat lunak Kimspoor Scheduler. Implementasi dilakukan berdasarkan analisis dan perancangan perangkat lunak dan pengujian dilakukan berdasarkan kebutuhankebutuhan perangkat lunak dan use-case yang telah dibuat sebelumnya.
5.1 Lingkungan Implementasi dan Pengujian Perangkat lunak Kimspoor Scheduler ini diimplementasikan dan diujikan dengan menggunakan perangkat keras dengan spesifikasi: 1. Prosesor AMD Athlon 64 Processor 3500+ dengan core speed 2475,2 MHz. 2. Memori dengan tipe DDR2, ukuran 768MB dan frekuensi 275 MHz.
Sistem operasi yang digunakan adalah Microsoft Windows XP Professional Service Pack 3 Build (2600). Perangkat lunak dan kakas pendukung lain yang digunakan adalah: 1. NetBeans IDE 6.1 (Build 200804211638) untuk pembuatan kode sumber perangkat lunak. 2. Compiler Java versi 1.6.0_03-b05 untuk melakukan kompilasi kode sumber dan pemaketan menjadi sebuah file jar yang dapat dieksekusi. 3. XAMPP versi 1.5.5 yang sudah mengandung Apache 2.2.3, MySQL 5.0.27, PHP 5.2.0 dan phpMyAdmin 2.9.1.1. XAMPP dan semua isinya digunakan untuk pengaturan basis data yang digunakan oleh perangkat lunak ini. 4. Pustaka mysql-connector-5.0.5 untuk melakukan koneksi dengan basis data MySQL dan pustaka GapekaChart, JCommon dan JFreeChart untuk pembuatan grafik diagram ruang-waktu.
5.2 Implementasi Pada upabab ini akan dijelaskan mengenai implementasi perangkat lunak secara rinci. Hal ini meliputi batasan implementasi, proses dan dan implementasi.
V-1
V-2
5.2.1 Batasan Implementasi Pada perangkat lunak ini, sebuah petak jalan selalu diasumsikan hanya terdiri dari satu petak blok saja. Asumsi ini digunakan karena pada prakteknya, sebuah kereta api tidak pernah bisa berhenti di sebuah sinyal. Kereta api hanya bisa berhenti di stasiun. Akibatnya, dua kereta api yang berlawanan arah, tidak boleh menggunakan satu petak jalan dalam waktu yang bersamaan (dalam hal ini, berapapun banyaknya petak blok pada petak jalan tersebut, satu petak jalan seakan-akan hanya terdiri dari satu petak blok saja). Dua kereta api yang searah masih boleh menggunakan satu petak jalan yang sama dalam waktu yang bersamaan, asalkan tidak berada dalam satu petak blok yang sama. Agar aturan ini tetap berlaku dengan tetap mempertahankan asumsi bahwa satu petak jalan hanya mengandung satu petak blok, digunakan aturan headway. Aturan ini menyebutkan bahwa dua kereta api yang searah boleh menggunakan petak jalan yang sama asalkan kedua kereta api tersebut terpisah selama suatu selang waktu minimum tertentu. Dalam implementasi perangkat lunak ini, waktu minimum tersebut ditetapkan 10 menit. Walaupun pada prakteknya waktu minimum tersebut tergantung oleh petak jalan, dalam implementasi ini, waktu minimum dianggap konstan. Jika kecepatan rata-rata sebuah kereta api adalah 45 km/jam, maka dalam 10 menit, jarak yang bisa ditempuh adalah 7500m. Dengan kata lain, dua buah kereta api yang searah dan menggunakan petak jalan yang sama, harus terpisah minimal sejauh 7500 m. Hal ini sama dengan mengasumsikan bahwa petak jalan tersebut terdiri atas beberapa petak blok dengan jarak 7500 m tiap petak blok. Aturan headway ini cukup banyak digunakan oleh peneliti sebagai pendekatan untuk mengganti banyaknya petak blok dalam satu petak jalan [OLI01].
Kelas-kelas yang diimplementasikan pada perangkat lunak ini hanyalah kelaskelas antarmuka data masukan, penjadwalan dan hubungan dengan basis data. Untuk
penggambaran
diagram
ruang-waktu,
akan
digunakan
pustaka
GapekaChart yang dibuat oleh Nugroho Herucahyono. Pustaka GapekaChart sendiri dibuat dengan menggunakan pustaka JCommon dan JFreeChart. Penggunaan pustaka ini dikarenakan sangat rumitnya diagram ruang-waktu jika perjalanan yang dijadwalkan sangat banyak. Dengan menggunakan pustaka
V-3
tersebut, grafik pada diagram yang terlihat sangat kecil dapat diperbesar tanpa mengurangi kualitas grafik. Selain menangani pembuatan grafik dalam diagram ruang-waktu, pustaka tersebut juga menangani penyimpanan diagram ruangwaktu dalam sebuah file gambar. Format file gambar yang digunakan dalam perangkat lunak ini adalah PNG (Portable Network Graphics).
Batasan implementasi yang terakhir adalah batasan mengenai basis data yang digunakan. Perangkat lunak ini juga tidak menangani pembuatan basis data. Jadi penggunaan perangkat lunak ini mengasumsikan bahwa basis data dan skemanya sudah dibuat sebelumnya. Basis data yang dapat digunakan oleh perangkat lunak ini hanyalah basis data MySQL. Perangkat lunak ini tidak dapat mengenali kesalahan pada integritas basis data jika basis data diubah dengan menggunakan aplikasi atau perangkat lunak lain. Jadi integritas basis data hanya bisa dijaga oleh perangkat lunak ini jika data perjalanan kereta api dimasukkan dengan menggunakan perangkat lunak ini, tidak oleh aplikasi atau perangkat lunak lainnya.
5.2.2 Proses dan Hasil Implementasi Proses implementasi terdiri atas dua tahap utama. Tahap yang pertama adalah implementasi kelas-kelas pada paket antarmuka dan basis data, dan tahap yang kedua adalah kelas-kelas pada paket penjadwalan. Hal ini karena proses penjadwalan sangat tergantung pada data perjalanan kereta api.
5.2.2.1 Implementasi Kelas-Kelas dan Paket-Paketnya Paket antarmuka perangkat lunak ini bernama paket kimspoor.ui. Implementasi kelas pada paket tersebut menghasilkan kelas-kelas seperti pada tahap perancangan dengan sedikit perubahan nama kelas menyesuaikan kakas yang digunakan. Selain itu juga dihasilkan satu kelas tambahan yang digunakan untuk menampilkan log penjadwalan yang telah dilakukan. Secara rinci, kelas-kelas antarmuka yang telah diimplementasikan disajikan pada Tabel V-1 berikut.
V-4
Tabel V-1 Kelas-Kelas Implementasi pada Paket kimspoor.ui
No
Nama Kelas
Nama File
1
FrameUtama
FrameUtama.java
2
PanelStasiun
PanelStasiun.java
3
PanelPetakJalan
PanelPetakJalan.java
4
PanelRute
PanelRute.java
5
PanelPerjalanan
PanelPerjalanan.java
6
FrameKoneksiBasisData
FrameKoneksiBasisData.java
7
RuteChooser
RuteChooser.java
8
FrameLogPenjadwalan
FrameLogPenjadwalan.java
Untuk melakukan penggambaran grafik dalam diagram ruang-waktu, digunakan pustaka GapekaChart. Kelas-kelas dan nama file pada pustaka tersebut disajikan pada Tabel V-2 berikut. Kelas-kelas tersebut juga sebagai ganti dari kelas PenggambarDiagramSW dan PenyimpanFileDiagramSW yang dibuat pada tahap perancangan.
Tabel V-2 Kelas-Kelas pada Pustaka GapekaChart
No
Nama Kelas
Nama File
1
ChartGenerator
ChartGenerator.java
2
GapekaDataset
GapekaDataset.java
3
GapekaPlot
GapekaPlot.java
4
GapekaRenderer
GapekaRenderer.java
5
JamAxis
JamAxis.java
6
JamTickUnit
JamTickUnit.java
7
PetakJalanChart
PetakJalanChart.java
8
RuteChart
RuteChart.java
9
ShowChart
ShowChart.java
10
StasiunChart
StasiunChart.java
11
VerticalAxisChart
VerticalAxisChart.java
12
VerticalTickUnit
VerticalTickUnit.java
V-5
Selanjutnya, kelas-kelas pada paket basis data diimplementasikan sama seperti tahap perancangan. Nama paket basis data dalam perangkat lunak ini adalah kimspoor.db. Kelas-kelas pada paket tersebut disajikan pada Tabel V-3.
Tabel V-3 Kelas-Kelas pada Paket kimspoor.db
No
Nama Kelas
Nama File
1
DBManager
DBManager.java
2
ObjectGenerator
ObjectGenerator.java
Tahap kedua implementasi perangkat lunak menghasilkan kelas-kelas yang digunakan untuk penjadwalan perjalanan kereta api. Pada tahap ini, paket penjadwalan yang dibuat pada tahap perancangan akhirnya dibagi menjadi dua, yaitu paket untuk penjadwalan dan paket graf disjungtif. Paket penjadwalan diberi nama
kimspoor.scheduler
dan
paket
graf
disjungtif
diberi
nama
kimspoor.disjunctive. Kelas-kelas pada paket tersebut disajikan pada Tabel
V-4 dan Tabel V-5.
Tabel V-4 Kelas-Kelas pada Paket kimspoor.scheduler
No
Nama Kelas
Nama File
1
Stasiun
Stasiun.java
2
StasiunPemberhentian
StasiunPemberhentian.java
3
PetakJalan
PetakJalan.java
4
Perjalanan
Perjalanan.java
5
Operasi
Operasi.java
6
Penjadwalan
Penjadwalan.java
7
Penjadwal
Penjadwal.java
8
Konflik
Konflik.java
Tabel V-5 Kelas-Kelas pada Paket kimspoor.disjunctive
No
Nama Kelas
Nama File
1
GrafDisjungtif
GrafDisjungtif.java
2
Simpul
Simpul.java
V-6
No
Nama Kelas
Nama File
3
SisiKritis
SisiKritis.java
4
AntrianSimpul
AntrianSimpul.java
5
AnggotaAntrianSimpul
AnggotaAntrianSimpul.java
5.2.2.2 Implementasi Algoritma Algoritma Hill Climbing yang digunakan untuk pencarian jadwal perjalanan kereta api diimplementasikan pada kelas-kelas di dalam paket penjadwalan, yaitu kimspoor.scheduler dan kimspoor.ui.
Algoritma pencarian jadwal ini terdiri atas beberapa tahap, yaitu pencarian jadwal awal, pembangunan graf disjungtif dari jadwal awal dan pencarian solusi-solusi lain yang lebih baik berdasarkan graf disjungtif yang telah dibangun dan sisi-sisi kritis pada graf disjungtif tersebut. Pada tahap implementasi, proses pembangunan graf disjungtif dan pencarian jadwal awal dilakukan secara bersamaan. Prosedur untuk
melakukan
kedua
cariJadwalAwal(ArrayList
hal
tersebut
adalah
listPerjalanan,
prosedur
GrafDisjungtif
grafDisjungtif) yang terdapat pada kelas Penjadwal. Pseudo-code dari
prosedur tersebut disajikan pada kode di bawah ini.
public void cariJadwalAwal(List listPerjalanan, GrafDisjungtif grafDisjungtif){ // pertama, jadwalkan perjalanan tanpa penundaan for each perjalanan in listPerjalanan{ waktu = perjalanan.getWaktuBerangkat() for each operasi in perjalanan{ // pertama, jadwalkan operasi tanpa penundaan operasi.setWaktuPelepasan(waktu)
waktu = waktu + operasi.getLamaWaktuOperasi()
// lalu simpan simpul yang merepresentasikan operasi // ke dalam graf disjungtif
V-7
SimpulIni = new Simpul(operasi) grafDisjungtif.addSimpul(simpulIni)
// lalu tambahkan sisi konjungtif pada graf disjungtif grafDisjungtif.addSisiKonjungtif(simpulSebelumnya, simpulIni); } }
// Sekarang cari konflik yang terjadi karena penjadwalan pertama for each perjalanan1 in listPerjalanan { for each perjalanan2 in listPerjalanan { // periksa konflik yg terjadi antara perjalanan1 dan 2. konflik = getFirstKonflikDuaPerjalanan(perjalanan1, perjalanan2); // jika terjadi konflik, simpan di listKonflik // berdasarkan urutan waktu terjadi konflik if (konflik != null){ listKonflik.addAndSort(konflik); } } }
// selanjutnya, selesaikan semua konflik yang ditemukan dengan // strategi kronologis
while (!listKonflik.isEmpty()){ // selesaikan konflik pertama yang terjadi konflik = listKonflik.getFirstKonflik(); selesaikanKonflikBerdasarkanSPT(konflik);
// lalu tambahkan sisi disjungtif ke dalam graf disjungtif // yang menyatakan urutan operasi yang mengalami konflik // penggunaan petak jalan yang sama grafDisjungtif.addSisiDisjungtif(operasiYangDitunda, operasiYangTidakDitunda)
// karena kedua operasi pasti dijalankan secara beruturan // tambahkan sebagai sisi kritis juga grafDisjungtif.addSisiKritis (operasiYangDitunda, operasiYangTidakDitunda)
V-8
// lalu hapus konflik dari list konflik listKonflik.hapus(konflik)
// karena terjadi perubahan waktu pelepasan pada perjalanan // yg ditunda, ada konflik yang tadinya terjadi menjadi // tidak terjadi, dan juga sebaliknya. // lakukan update konflik menyangkut perjalanan yang ditunda updateKonflik(listKonflik, perjalananYangDitunda) } }
Setelah jadwal pertama didapatkan, langkah berikutnya adalah mencari jadwal baru berdasarkan graf disjungtif yang telah dibangun sebelumnya. Dengan adanya informasi graf disjungtif ini, jadwal baru bisa didapatkan dalam waktu yang lebih cepat dibandingkan waktu pencarian jadwal pertama. Pencarian jadwal baru berdasarkan graf disjungtif ini menggunakan strategi variable and value ordering dan constrint propagation. Strategi variable and value ordering dilakukan dengan menelusuri simpul-simpul graf disjungtif secara BFS (urutan simpul yang ditelusuri secara otomatis menjadi urutan operasi yang akan dijadwalkan). Penelusuran graf dengan skema BFS dilakukan dengan menggunakan antrian. Strategi constraint propagation dilakukan dengan menggunakan sisi-sisi konjungtif dan sisi-sisi disjungtif. Jika terdapat sisi konjungtif atau sisi disjungtif dengan arah dari simpul a ke simpul b, dan operasi pada simpul a sudah dijadwalkan, maka strategi ini akan memberitahu operasi pada simpul b bahwa operasi pada simpul b boleh dijadwalkan setelah operasi a selesai. Dengan kata lain, domain waktu pelepasan operasi yang direpresentasikan oleh simpul b menjadi lebih kecil, yaitu setelah operasi a selesai. Pseudo-code dari pencarian jadwal berdasarkan graf disjungtif ini disajikan dalam kode berikut.
public void cariJadwalBerdasarkanGrafDisjungtif(List listPerjalanan, Graf Disjungtif grafDisjungtif){
// pertama, simpan simpul sumber grafDisjungtif ke dalam antrian antrianSimpul.push(grafDisjungtif.getSimpulSumber());
V-9
// lalu lakukan iterasi sampai antrian kosong while (antrianSimpul.isNotEmpty()){ // ambil simpul yang pertama simpul = antrianSimpul.pull(); // lalu jadwalkan operasi yang direpresentasikan oleh simpul // dengan waktu pelepasan earliestReleaseTime // jika penjadwalan berhasil karena semua simpul // predecessornya sudah dijadwalkan, // maka tambahkan simpul-simpul successor ke dalam antrian if (simpul.jadwalkanOperasiSimpul()){ for each simpulSuccessor in simpul.getListSimpulSuccessor(){ antrianSimpul.push(simpulSuccessor);
// dan lakukan strategi constraint propagation dengan // memberitahu bahwa waktu pelepasan simpul successor // harus setelah simpul sampai
simpulSuccessor.setEarliestReleaseTime( simpul.getWaktuSampai()) } } }
// sekarang selesaikan semua konflik baru yang terjadi // dengan cara yang sama persis seperti pencarian jadwal pertama
// cari semua konflik yang terjadi karena penjadwalan // berdasarkan urutan simpul pada graf disjungtif for each perjalanan1 in listPerjalanan { for each perjalanan2 in listPerjalanan { // periksa konflik antara perjalanan1 dan 2. konflik = getFirstKonflikDuaPerjalanan(perjalanan1, perjalanan2); // jika terjadi konflik, simpan di listKonflik // berdasarkan urutan waktu terjadi konflik
if (konflik != null){ listKonflik.addAndSort(konflik); } } }
V-10
// selanjutnya, selesaikan semua konflik yang ditemukan dengan // strategi kronologis
while (!listKonflik.isEmpty()){ // selesaikan konflik pertama yang terjadi konflik = listKonflik.getFirstKonflik(); selesaikanKonflikBerdasarkanSPT(konflik);
// lalu tambahkan sisi disjungtif ke dalam graf disjungtif // yang menyatakan urutan operasi yang mengalami konflik // penggunaan petak jalan yang sama grafDisjungtif.addSisiDisjungtif(operasiYangDitunda, operasiYangTidakDitunda)
// karena kedua operasi pasti dijalankan secara beruturan // tambahkan sebagai sisi kritis juga grafDisjungtif.addSisiKritis (operasiYangDitunda, operasiYangTidakDitunda)
// lalu hapus konflik dari list konflik listKonflik.hapus(konflik)
// karena terjadi perubahan waktu pelepasan pada perjalanan // yang ditunda, mungkin ada konflik yang tadinya terjadi // menjadi tidak terjadi, dan mungkin juga sebaliknya. // lakukan update konflik menyangkut perjalanan yang ditunda updateKonflik(listKonflik, perjalananYangDitunda) } }
5.2.2.3 Struktur Data yang Digunakan Dalam Implementasi Struktur data yang digunakan dalam implementasi perangkat lunak Kimspoor Scheduler ini tidak sama persis dengan struktur data pada dasar teori. Pada dasar teori, himpunan sisi berarah disjungtif dan konjungtif dianggap berbeda. Namun pada implementasi, kedua himpunan tersebut dianggap sama karena sisi disjungtif dan konjungtif memiliki fungsi yang sama, yaitu merepresentasikan urutan dua buah operasi.
V-11
Secara umum, sembarang graf dapat direpresentasikan dengan menggunakan senarai (list) ketetangganan [MUN2004]. Dalam implementasi perangkat lunak ini, struktur data tersebut juga digunakan untuk merepresentasikan graf disjungtif. Dan karena graf disjungtif merupakan graf berarah, maka senarai simpul yang harus disimpan oleh setiap simpul pada graf ada dua buah, yaitu senarai simpul sebelum (predecessor list) dan (successor list) senarai simpul sesudah. Predecessor list digunakan untuk menyimpan simpul-simpul yang menyatakan operasi yang harus dikerjakan sebelumnya dan successor list digunakan untuk menyimpan simpul-simpul yang menyatakan operasi-operasi yang harus dikerjakan sesudahnya. Representasi ini sangat cocok digunakan karena sesuai dengan strategi penelusuran graf disjungtif dengan skema BFS.
Struktur data lain yang digunakan pada tahap implementasi ini adalah struktur data antrian. Struktur data yang digunakan sama seperti antrian pada umumnya. Anggota antrian terdiri atas sebuah simpul dan sebuah pointer yang menunjuk ke simpul berikutnya. Fungsi-fungsi pada antrian tersebut juga merupakan fungsifungsi umum pada antrian, yaitu push dan pop. Fungsi push digunakan untuk menambahkan anggota antrian di belakang dan fungsi pop digunakan untuk mengambil dan menghapus anggota antrian pertama.
5.2.2.4 Antarmuka Perangkat Lunak Antarmuka perangkat lunak ini diimplementasikan sama seperti tahap perancangan. Gambar V-1 sampai dengan Gambar V-8 menyajikan tampilan antarmuka ini.
V-12
Gambar V-1 Antarmuka Utama Perangkat Lunak
Gambar V-2 Antarmuka Koneksi Basis Data
V-13
Gambar V-3 Antarmuka Panel Masukan dan Penampilan Data Stasiun
Gambar V-4 Antarmuka Panel Masukan dan Penampilan Data Petak Jalan
V-14
Gambar V-5 Antarmuka Panel Masukan dan Penampilan Rute
Gambar V-6 Antarmuka Panel Masukan dan Penampilan Data Perjalanan
V-15
Gambar V-7 Antarmuka Penampilan Diagram Ruang Waktu
5.3 Pengujian Pada upabab ini akan dijelaskan pengujian perangkat lunak yang dilakukan secara rinci. Hal ini meliputi tujuan pengujian, rencana dan kriteria keberhasilan pengujian, perancangan kasus-kasus uji (test case), pelaksanaan pengujian dan hasil pengujian serta analisis hasil pengujian.
5.3.1 Tujuan Pengujian Pengujian perangkat lunak yang dilakukan memiliki beberapa tujuan, yaitu: 1. Mengetahui apakah perangkat lunak yang diimplementasikan telah sesuai dengan kebutuhan-kebutuhan utama perangkat lunak yang dispesifikasikan pada tahap analisis, yaitu kebutuhan fungsional dan kebutuhan nonfungsional. 2. Mengetahui apakah keluaran perangkat lunak yang berupa jadwal perjalanan kereta api telah sesuai dengan aturan-aturan yang ada. 3. Mengetahui
kualitas
jadwal
yang
dihasilkan
(total
keterlambatan,
keterlambatan rata-rata, keterlambatan maksimum, keterlambatan minimum dan banyaknya perjalanan yang terlambat).
V-16
5.3.2 Rencana dan Kriteria Keberhasilan Pengujian Berdasarkan tujuan pengujian yang telah dijelaskan sebelumnya, rencana pengujian ini terdiri atas beberapa bagian. Yang pertama adalah pengujian fungsional dan yang kedua adalah pengujian penjadwalan.
Pengujian fungsional mengacu pada kebutuhan-kebutuhan utama perangkat lunak yang telah dispesifikasikan di bagian analisis. Jadi, pengujian ini akan dilakukan dengan cara menguji setiap kebutuhan yang ada. Pengujian fungsional ini dikatakan berhasil jika semua kebutuhan utama perangkat lunak telah terpenuhi. Hal-hal yang harus diuji pada pengujian ini disajikan dalam Tabel V-6 berikut.
Tabel V-6 Rencana Pengujian Fungsional
No
Kebutuhan Perangkat Lunak
1
Memasukkan data perjalanan.
Rencana Pengujian
1. Melakukan koneksi basis data. 2. Melakukan
validasi
data
yang
dimasukkan. 3. Menyimpan data di basis data. 2
Melihat data masukan
1. Mengambil data dari basis data 2. Menampilkan data dalam bentuk tabel di panel-panel antarmuka.
3
Mengubah
atau
menghapus 1. Melakukan
data masukan
validasi
data
yang
diubah. 2. Mengubah data di basis data. 3. Menghapus data di basis data. 4. Menghapus data lain di basis data yang berkaitan dengan data yang telah
dihapus
untuk
menjaga
integritas basis data. 4
Melakukan penjadwalan
1. Mengambil semua data perjalanan di basis data. 2. Melakukan penjadwalan terhadap data perjalanan yang telah diambil.
V-17
No
Kebutuhan Perangkat Lunak
4
Melakukan penjadwalan
Rencana Pengujian
3. Menyimpan hasil penjadwalan di basis data.
5
Menampilkan jadwal
1. Mengambil
jadwal
yang
telah
disimpan di dalam basis data. 2. Menampilkan
jadwal-jadwal
tersebut sebagai diagram ruangwaktu 6
Menyimpan
diagram
ruang- 1. Menyimpan diagram ruang-waktu
waktu sebagai file gambar
sebagai file gambar.
Secara umum, penjadwalan fungsional ini dapat dibagi menjadi dua skenario. Skenario yang pertama adalah skenario normal, yaitu skenario dimana tidak terjadi kesalahan penggunaan perangkat lunak. Skenario yang kedua adalah skenario alternatif, yaitu skenario dimana terjadi kesalahan dalam penggunaan perangkat lunak, misalnya pengguna memasukkan data yang salah. Dalam hal ini, pengujian dilakuan untuk mengetahui apakah perangkat lunak dapat menangkap kesalahan yang terjadi dan menotifikasi pengguna tentang kesalahan yang telah dilakukan.
Pengujian yang kedua adalah pengujian penjadwalan. Rencana pengujian ini dapat dibagi menjadi dua, yaitu pengujian keluaran perangkat lunak berdasarkan aturanaturan perjalanan yang ada dan pengujian optimasi jadwal perjalanan
Pengujian keluaran perangkat lunak dilakukan dengan menggunakan data masukan perjalanan kereta api. Perangkat lunak akan mengambil data tersebut dari basis data, melakukan penjadwalan dan menghasilkan keluaran yang berupa diagram ruang-waktu. Pengujian ini dikatakan berhasil jika diagram ruang-waktu yang dihasilkan tidak melanggar aturan-aturan perjalanan kereta api yang diajukan pada tahap pemodelan.
V-18
Pengujian optimasi jadwal perjalanan dilakukan dengan menguji apakah perangkat lunak dapat mencari jadwal tetangga yang lebih baik dibandingkan jadwal yang telah diperoleh sebelumnya. Pengujian ini dikatakan berhasil jika perangkat lunak dapat melakukan hal tersebut, asalkan memang ada jadwal tetangga yang lebih baik. Pengujian ini tidak bisa dikatakan gagal jika perangkat lunak tidak dapat mencari jadwal lain yang lebih baik karena jadwal tersebut bukan merupakan tetangga dari jadwal sebelumnya.
Secara rinci, rencana pengujian penjadwalan dapat dilihat pada Tabel V-7 berikut.
Tabel V-7 Rencana Pengujian Penjadwalan
No
1
Pengujian Penjadwalan
Rencana Pengujian
Pengujian keluaran perangkat 1.
Pengujian aturan persilangan pada
lunak berdasarkan aturan-aturan
dua perjalanan dengan arah yang
perjalanan yang ada.
berbeda di jalur tunggal. 2.
Pengujian aturan persilangan pada dua perjalanan dengan arah yang berbeda di jalur kembar (aturan persilangan
tidak
boleh
diberlakukan). 3.
Pengujian aturan penyusulan dan headway pada dua perjalanan dengan arah yang sama di jalur tunggal maupun jalur ganda.
4.
Pengujian
waktu
minimum
penundaan perjalanan di stasiun (kereta harus berhenti di suatu stasiun selama suatu selang waktu tertentu) 5.
Pengujian
aturan
maksimal petak jalan.
kecepatan
V-19
No
2
Pengujian Penjadwalan
Pengujian
optimasi
Rencana Pengujian
jadwal 1.
perjalanan
Pencarian jadwal-jadwal tetangga dari jadwal yang telah ditemukan sebelumnya.
2.
Melakukan
perhitungan
total
keterlambatan pada jadwal-jadwal tetangga dan membandingkannya dengan total keterlambatan jadwal yang
telah
ditemukan
sebelumnya. 3.
Menyimpan jadwal dengan total keterlambatan lebih kecil.
5.3.3 Kasus-Kasus Uji Terdapat dua kasus uji yang digunakan dalam pengujian perangkat lunak ini. Yang pertama adalah kasus uji dimana basis data yang digunakan masih kosong. Semua rencana pengujian yang telah dibuat sebelumnya baik pengujian fungsional maupun pengujian penjadwalan akan diujikan dengan menggunakan kasus uji ini.
Kasus uji yang kedua adalah kasus uji dimana basis data sudah terisi dengan data perjalanan kereta api di Indonesia. Data perjalanan kereta api tersebut didapatkan dari PT Kereta Api (Persero). Dalam kasus ini, akan digunakan beberapa basis data berbeda. Setiap basis data memiliki banyak perjalanan dan banyak rute yang berbeda-beda. Sebuah penjadwalan perjalanan kereta api hanya dapat dilakukan dengan menggunakan satu basis data saja. Sebagai contoh, penjadwalan dilakukan dengan 1 perjalanan, 10 perjalanan, 50 perjalanan atau 100 perjalanan. Contoh lain misalnya, semua perjalanan yang dijadwalkan harus memiliki rute yang berbeda, semua perjalanan memiliki satu rute yang sama, atau kombinasi keduanya.
V-20
Secara umum, kasus uji yang kedua ini dapat dibagi menjadi dua, yaitu kasus uji penjadwalan sederhana dan penjadwalan rumit. Kasus uji penjadwalan sederhana dilakukan dengan menggunakan perjalanan-perjalanan dengan stasiun asal dan stasiun tujuan yang sama atau dengan rute-rute yang jarang dilalui perjalanan kereta api (seperti di sumatra). Kasus uji penjadwalan rumit dilakukan dengan menggunakan banyak perjalanan dengan satu rute dimana stasiun asal dan stasiun tujuan perjalanan berbeda-beda. Selain itu, dapat juga menggunakan banyak perjalanan dan banyak rute, dimana antara rute satu dengan yang lain memiliki petak jalan persekutuan.
Utamanya, kasus uji yang kedua ini digunakan pada pengujian penjadwalan dan pengujian fungsional bagian penampilan hasil penjadwalan.
5.3.4 Pelaksanaan Pengujian Ada beberapa hal yang harus dilakukan sebelum pengujian dilaksanakan. Hal pertama yang harus dilakukan adalah mempersiapkan basis data yang digunakan untuk menyimpan data perjalanan. Karena perangkat lunak ini tidak menangani pembuatan basis data, maka basis data dan skemanya harus dibuat dengan menggunakan aplikasi atau perangkat lunak lain. Dalam pengujian yang dilaksanakan, pembuatan basis data dan skemanya dibuat dengan menggunakan phpMyAdmin. Setelah basis data dan skemanya tersedia, pengujian dilakukan sama seperti rencana pengujian.
Secara umum, pelaksanaan pengujian sesuai dengan rencana pengujian terdiri atas empat tahap, yaitu adalah memasukkan data, melihat data yang dimasukkan, melakukan penjadwalan dan melihat hasil penjadwalan. Pengecekan kebenaran data yang dimasukkan dilakukan dengan melihat data yang dimasukkan dengan menggunakan perangkat lunak dan dengan menggunakan phpMyAdmin. Jika data yang dimasukkan dengan menggunakan perangkat lunak benar-benar sama dengan data yang ditampilkan dengan menggunakan phpMyAdmin, maka pengujian data masukkan dapat dikatakan berhasil. Pengujian berikutnya adalah melakukan penjadwalan. Pengecekan hasil penjadwalan dilakukan dengan
V-21
menampilkan hasil penjadwalan dalam diagram ruang-waktu. Dari diagram yang ditampilkan, semua aturan yang diimplementasikan dalam perangkat lunak dapat diperiksa kebenarannya.
5.3.5 Hasil dan Analisis Pengujian
5.3.5.1 Hasil Pengujian Fungsional Pengujian perangkat lunak yang dilaksanakan berdasarkan rencana dan kriteria keberhasilan pengujian fungsional dengan menggunakan kasus-kasus uji yang berbeda-beda menunjukkan keberhasilan di semua rencana pengujian. Upabab ini akan menjelaskan keberhasilan tersebut lebih rinci.
Keberhasilan yang pertama pada pengujian fungsional ditunjukkan dengan kemampuan perangkat lunak untuk melakukan koneksi basis data, validasi data yang dimasukkan, penyimpanan data, penghapusan data dan pengubahan data di basis data. Jika perangkat lunak tidak bisa melakukan koneksi basis data karena server basis data mati atau konfigurasi server di perangkat lunak salah, maka perangkat lunak akan memberikan informasi bahwa koneksi basis data tidak bisa dilakukan. Validasi data yang dimasukkan diperlukan untuk menjamin integritas basis data, misalnya tidak boleh ada dua stasiun dengan singkatan yang sama, tidak boleh ada dua rute yang menggunakan nama yang sama, singkatan nama stasiun paling sedikit dua karakter, kecepatan kereta api tidak boleh lebih dari 200, dan sebagainya. Dengan demikian, validasi diperlukan untuk mencegah duplikasi data atau mencegah pemasukan data yang salah. Dalam pengujian yang telah dilaksanakan, fungsi validasi ini dapat bekerja dengan baik. Perangkat lunak ini juga berhasil dalam pengujian pemasukan data, penghapusan data dan pengubahan data. Kebenaran basis data diperiksa dengan menggunakan phpMyAdmin.
Integritas basis data setelah proses penghapusan atau pengubahan data perjalanan juga selalu dapat dijaga. Sebagai contoh, jika stasiun A dihapus, maka semua petak jalan di basis data yang menggunakan stasiun A juga harus dihapus. Semua rute yang melewati stasiun A juga harus dihapus dan semua perjalanan yang
V-22
menggunakan rute tersebut juga harus dihapus. Contoh lain yang berhubungan dengan pengubahan data misalnya singkatan stasiun diubah. Hal ini akan berakibat semua singkatan stasiun di petak jalan, rute maupun perjalanan juga berubah. Demikian juga dengan singkatan stasiun pada diagram ruang-waktu yang ditampilkan.
Keberhasilan berikutnya adalah keberhasilan dalam pengujian penampilan data perjalanan yang ada di basis data, penampilan hasil penjadwalan dan penyimpanan jadwal sebagai file gambar. Perangkat lunak ini dapat mengambil data dari basis data kemudian menampilkan data tersebut dalam bentuk tabel di dalam panel-panel yang ada. Data yang ditampilkan ini benar-benar sesuai dengan data yang ada di basis data. Setelah proses penjadwalan selesai, perangkat lunak ini mampu menampilkan hasil penjadwalan dalam diagram ruang-waktu. Diagram ruang-waktu tersebut kemudian dapat disimpan sebagai sebuah file gambar dengan format PNG.
Keberhasilan yang terakhir dalam pengujian fungsional adalah keberhasilan dalam proses penjadwalan. Perangkat lunak ini dapat mengambil semua data perjalanan yang telah dimasukkan, melakukan penjadwalan dan menyimpan hasil penjadwalan di basis data. Keberhasilan pengujian ini akan dijelaskan lebih rinci pada upabab berikutnya.
5.3.5.2 Hasil dan Analisis Pengujian Penjadwalan Sama seperti pengujian fungsional, pengujian penjadwalan ini juga berhasil di semua rencana pengujian. Keberhasilan pengujian ini ada dua, yaitu keberhasilan membuat jadwal yang sesuai dengan aturan-aturan perjalanan yang ada dan keberhasilan dalam pencarian jadwal yang lebih baik daripada jadwal yang telah ditemukan sebelumnya.
Keberhasilan pembuatan jadwal yang sesuai dengan aturan-aturan perjalanan yang ada ditunjukkan dengan diagram ruang-waktu hasil penjadwalan. Pertama adalah aturan persilangan. Semua jadwal yang dihasilkan oleh perangkat lunak ini selalu
V-23
mematuhi aturan persilangan. Hal ini ditunjukkan dengan tidak adanya dua kereta api yang berlawanan arah dan menggunakan satu petak jalan yang sama, dimana petak jalan tersebut adalah petak jalan dengan jalur tunggal. Salah satu contohnya ditunjukkan pada Gambar V-8.
Gambar V-8 Hasil Penjadwalan yang Mematuhi Aturan Persilangan
Penjadwalan yang diimplementasikan tidak hanya berlaku untuk perjalanan kereta api dengan menggunakan jalur tunggal saja, tetapi juga perjalanan dengan jalur kembar. Pada jalur kembar, aturan persilangan tidak berlaku karena dua kereta api yang berlawanan arah dapat menggunakan petak jalan tersebut secara bersamaan. Satu kereta menggunakan jalur yang satu dan kereta lain menggunakan jalur yang satunya lagi. Keberhasilan implementasi aturan ini ditunjukkan dengan adanya dua perjalanan kereta api yang berlawanan arah dan menggunakan petak jalan yang sama, asalkan petak jalan tersebut merupakan petak jalan dengan jalur kembar. Salah satu contohnya adalah jadwal yang ditunjukkan dengan diagram ruang waktu pada Gambar V-9.
V-24
Gambar V-9 Hasil Penjadwalan dengan Jalur Kembar
Berikutnya adalah keberhasilan jadwal dalam mematuhi aturan penyusulan dan aturan headway. Keberhasilan implementasi aturan ini ditunjukkan dengan penggunaan satu petak jalan oleh beberapa kereta api dengan arah yang sama, asalkan antara satu kereta api dengan kereta api yang lain terpisah selama suatu selang waktu tertentu. Salah satu contohnya adalah diagram ruang waktu pada Gambar V-10.
Keberhasilan yang terakhir adalah keberhasilan dalam mematuhi aturan waktu minimum penundaan di stasiun dan aturan kecepatan maksimal petak jalan. Sebuah jadwal memenuhi aturan waktu minimum penundaan di stasiun jika kereta api yang dijadwalkan untuk berhenti di stasiun benar-benar berhenti di stasiun paling sedikit selama suatu selang waktu minimum tertentu. Salah satu contoh jadwal yang memenuhi aturan ini ditunjukkan oleh Gambar V-11.
V-25
Gambar V-10 Hasil Penjadwalan yang Mematuhi Aturan Penyusulan dan Headway
Gambar V-11 Hasil Penjadwalan yang Mematuhi Aturan Waktu Minimum Penundaan di Stasiun
Selanjutnya, sebuah jadwal memenuhi aturan kecepatan maksimal petak jalan jika kereta api yang menggunakan petak jalan tersebut tidak berjalan dengan
V-26
kecepatan yang melebihi batas kecepatan masimal petak jalan. Dengan diagram ruang-waktu, hal ini ditunjukkan dengan grafik perjalanan yang lurus atau tidak lurus. Grafik perjalanan lurus terjadi pada kereta api dengan kecepatan yang kurang dari atau sama dengan kecepatan maksimal petak jalan. Sedangkan grafik perjalanan yang tidak lurus terjadi pada kereta api dengan kecepatan yang lebih besar daripada kecepatan maksimal petak jalan. Dalam hal ini, grafik akan melandai di bagian petak jalan yang memiliki kecepatan maksimal lebih kecil dibandingkan kecepatan kereta api. Salah satu jadwal yang memenuhi aturan ini ditunjukkan oleh Gambar V-12.
Gambar V-12 Hasil Penjadwalan yang Mematuhi Aturan Kecepatan Maksimal Petak Jalan
Perangkat lunak ini juga berhasil dalam pengujian optimasi jadwal perjalanan. Setelah sebuah jadwal yang memenuhi semua aturan perjalanan ditemukan, perangkat lunak ini mampu menemukan jadwal-jadwal lain yang merupakan tetangga dari jadwal yang telah ditemukan. Setiap kali sebuah jadwal tetangga ditemukan,
total
keterlambatan
jadwal
tetangga
tersebut
dihitung
dan
dibandingkan dengan total keterlambatan jadwal sebelumnya. Jika total keterlambatan jadwal tetangga lebih kecil, maka jadwal tetangga akan disimpan di
V-27
basis data. Pada akhir iterasi, jadwal yang disimpan di basis data adalah jadwal dengan total keterlambatan paling kecil. Tabel V-8 menunjukkan hasil penjadwalan dengan menggunakan 100 perjalanan dan 3 rute. Ketiga rute yang digunakan memiliki titik ujung Jakarta dan Surabaya. Sebagian besar perjalanan adalah perjalanan dari atau ke Jakarta dan Bekasi, Jakarta dan Bandung, Bandung dan Solo, Bandung dan Surabaya, dan juga Solo dan Yogyakarta.
Hasil penjadwalan yang ditampilkan pada Tabel V-8 tersebut hanyalah jadwal awal dan jadwal-jadwal tetangga yang memiliki total keterlambatan lebih kecil. Jadwal yang memiliki total keterlambatan lebih besar tidak ditampilkan. Selanjutnya, diagram ruang-waktu salah satu rute hasil penjadwalan tersebut ditampilkan pada Gambar V-13. Walaupun grafik yang ditampilkan pada gambar tersebut sangat kecil dan rumit, perangkat lunak ini memiliki fungsi zoom untuk memperbesar grafik yang ditampilkan sebesar apapun.
Tabel V-8 Hasil Penjadwalan dengan 100 Perjalanan dan 3 Rute Jadwal ke-
1
Banyak perjalanan terlambat
Keterlambatan Total
Keterlambatan Rata-rata
Keterlambatan Minimum
Keterlambatan maksimum
49
10 jam 14
6,14 menit
0 menit
1 jam 4 menit
6,10 menit
0 menit
1 jam 4 menit
menit 2
47
10 jam 10 menit
3
46
10 jam 9 menit
6,09 menit
0 menit
1 jam 4 menit
4
46
10 jam 1 menit
6,01 menit
0 menit
1 jam 4 menit
5
48
9 jam 52 menit
5,92 menit
0 menit
1 jam 4 menit
6
48
9 jam 43 menit
5,83 menit
0 menit
1 jam 4 menit
7
47
9 jam 41 menit
5,81 menit
0 menit
1 jam 4 menit
8
48
9 jam 36 menit
5,76 menit
0 menit
1 jam 4 menit
9
46
9 jam 19 menit
5,59 menit
0 menit
1 jam 4 menit
Pada Tabel V-8 di atas, terdapat lima kualitas jadwal yang digunakan, yaitu banyak perjalanan terlambat, keterlambatan total, keterlambatan rata-rata, keterlambatan minimum, dan keterlambatan maksimum. Setiap kualitas jadwal
V-28
tersebut dihitung per banyaknya perjalanan yang dijadwalkan (dalam Tabel V-8, terdapat 100 perjalanan yang dijadwalkan). Sebagai contoh, pada jadwal pertama yang ditemukan, terdapat 49 perjalanan terlambat diantara 100 perjalanan. Selanjutnya, total keterlambatan 100 perjalanan tersebut adalah 10 jam 14 menit atau 614 menit, sehingga keterlambatan rata-rata satu perjalanan adalah 614/100 menit = 6,14 menit. Keterlambatan minimum 0 menit berarti diantara 100 perjalanan yang dijadwalkan, terdapat perjalanan yang tidak terlambat dan keterlambatan maksimum 1 jam 4 menit merupakan keterlambatan terbesar diantara 100 perjalanan yang dijadwalkan.
Gambar V-13 Diagram Ruang-Waktu Salah Satu Rute yang Diujikan
Walaupun keterlambatan rata-rata dan keterlambatan minimum yang pada jadwal yang ditemukan relatif kecil, namun keterlambatan maksimum pada hasil penjadwalan relatif sangat besar dibandingkan dengan keterlambatan rata-rata
V-29
(jadi terjadi penyimpangan (deviation) yang cukup besar). Hal tersebut terjadi karena
aturan
penundaan
maksimum
perjalanan
di
stasiun
tidak
diimplementasikan. Satu-satunya kriteria optimasi yang digunakan oleh perangkat lunak ini hanyalah total keterlambatan minimum saja, tanpa mempedulikan adanya satu perjalanan yang memiliki keterlambatan yang besar.
Jadwal kedua sampai jadwal terakhir yang ditemukan menunjukkan adanya peningkatan kualitas jadwal, yaitu total keterlambatan yang semakin kecil, walaupun banyaknya perjalanan yang terlambat mengalami fluktuasi (naik dan turun). Hal ini berarti pengujian optimasi penjadwalan dengan kriteria optimasi total keterlambatan minimum telah berhasil. Jadwal akhir yang ditemukan bahkan menunjukkan peningkatan kualitas yang cukup signifkan dibandingkan jadwal pertama yang ditemukan, yaitu penurunan total keterlambatan sebesar 55 menit. Dengan demikian, persentase peningkatan kualitas jadwal adalah 55/614 = 8,95%.
Selain pengujian dengan 100 perjalanan dan 3 rute di atas, pengujian juga dilakukan dengan menggunakan beberapa variasi data perjalanan. Tabel V-9 menunjukkan hasil beberapa penjadwalan yang telah dilakukan
Tabel V-9 Hasil Beberapa Penjadwalan
No
1 2 3 4 5
Banyak Perjalanan 26 72 51 70 100
Banyak Rute 1 4 51 1 3
Keterlambatan Total Jadwal Awal 30 menit 5 jam 4 menit 2 jam 30 menit 8 jam 33 menit 10 jam 14 menit
Keterlambatan Total Jadwal Akhir 30 menit 4 jam 59 menit 2 jam 30 menit 7 jam 37 menit 9 jam 19 menit
Data nomor 1 dan 2 pada Tabel V-9 di atas menggunakan data perjalanan kereta api sederhana dan ketiga data terakhir menggunakan data perjalanan kereta api yang rumit. Data nomor 1 adalah data perjalanan kereta api dengan satu rute dan semua perjalanan pada data tersebut berasal dari atau ke Bandung dan Jakarta (Gambir) saja. Data nomor 2 adalah data perjalanan kereta api di Sumatra. Data nomor 3 adalah data 51 perjalanan kereta api dengan menggunakan 51 rute yang
V-30
berbeda, dengan kata lain, satu rute digunakan untuk satu perjalanan. Tapi walaupun berbeda, rute-rute tersebut memiliki petak-petak jalan persekutuan. Data nomor 4 dan 5 adalah data perjalanan kereta api di Jawa yang cukup rumit (banyak perjalanan dengan sedikit rute).
Pada data perjalanan kereta api sederhana, total keterlambatan jadwal akhir yang diperoleh cukup kecil (dengan rata-rata keterlambatan 1-3 menit). Hal ini dikarenakan sedikitnya konflik yang harus diselesaikan antara satu perjalanan dengan perjalanan lain. Untuk data nomor 1, konflik sedikit terjadi karena antara satu perjalanan dengan perjalanan yang lain terdapat suatu perbedaan waktu yang cukup besar, misalnya perjalanan-perjalanan kereta api dari Bandung ke Gambir dengan kereta api Parahyangan dan Argo Gede memiliki selisih waktu keberangkatan 1 sampai 3 jam. Demikian halnya dengan data nomor 2.
Karena alasan yang sama juga, selisih antara total keterlambatan akhir dan total keterlambatan awal juga cukup kecil. Dengan kata lain, optimasi yang dilakukan tidak terlalu signifikan. Hal ini berarti strategi kronologis dan aturan SPT saja dapat menemukan jadwal dengan total keterlambatan yang dekat dengan nilai minimal (karena proses pencarian jadwal pertama hanyalah menggunakan strategi kronologis dan aturan SPT).
Pada data nomor 3, rute yang digunakan sangat banyak. Dalam hal ini kerumitan terjadi karena banyaknya petak jalan persekutuan antara satu rute dengan rute yang lain. Namun dengan menggunakan model penjadwalan Job-Shop hal tersebut tidak menjadi masalah. Yang menjadi masalah dalam model penjadwalan Job-Shop hanyalah banyaknya konflik yang harus diselesaikan dalam penjadwalan. Dalam kasus uji ini, konflik yang harus diselesaikan ternyata sangat sedikit karena petak jalan persekutuan antara satu perjalanan dengan perjalanan yang lain tidak terlalu banyak (hal ini karena perjalanan menggunakan rute yang berbeda-beda). Jadi dengan alasan yang sama, keterlambatan rata-rata penjadwalan ini juga cukup kecil yaitu 3 menit. Selisih total keterlambatan akhir dan total keterlambatan awal juga tidak ada, yang berarti bahwa jadwal yang
V-31
ditemukan pertama kali lebih baik daripada jadwal-jadwal tetangga yang ditemukan.
Data perjalanan nomor 4 jauh lebih rumit dibandingkan ketiga data sebelumnya. Data nomor 4 ini menggunakan 70 perjalanan dan hanya 1 rute. Rute perjalanan yang digunakan memiliki titik ujung Jakarta dan Surabaya. Stasiun asal dan tujuan tiap perjalanan kereta api cukup bervariasi. Pada penjadwalan dengan menggunakan data ini, jadwal awal yang diperoleh memiliki total keterlambatan 8 jam 33 menit atau 513 menit. Dengan demikian, keterlambatan rata-rata tiap perjalanan adalah 7,329 menit. Keterlambatan rata-rata yang lebih besar daripada hasil penjadwalan dengan data sebelumnya tersebut terjadi karena konflik yang harus diselesaikan pada penjadwalan ini lebih banyak.
Setelah jadwal pertama ditemukan, iterasi dilakukan untuk mendapatkan jadwal tetangga yang memiliki total keterlambatan lebih baik. Jadwal akhir yang diperoleh memiliki total keterlambatan 7 jam 37 menit atau sama dengan 457 menit, sehingga keterlambatan rata-rata yang diperoleh tiap perjalanan adalah 6,529 menit. Dalam hal ini, terjadi penurunan total keterlambatan yang cukup signifikan, yaitu 10,92%.
Data yang terakhir pada Tabel V-9 merupakan data yang sama dengan hasil penjadwalan pada Tabel V-8, yaitu menggunakan 100 perjalanan dan 3 rute. Hasil penjadwalan ini secara rinci juga sudah ada pada Tabel V-8 tersebut.
