Sistem Informasi Penjadwalan Kereta Rel Listrik (KRL)

SKRIPSI

Diajukan untuk Menempuh Ujian Akhir Sarjana Program Strata Satu Jurusan Teknik Informatika

Fakultas Teknik dan Ilmu Komputer Universitas Komputer Indonesia

HARKAT WIJAYA

10105082

JURUSAN TEKNIK INFORMATIKA

FAKULTAS TEKNIK DAN ILMU KOMPUTER

UNIVERSITAS KOMPUTER INDONESIA

BANDUNG

v

LEMBAR JUDUL

LEMBAR PENGESAHAN

ABSTRAK……… i

ABSTRACT………. ii

KATA PENGANTAR………. iii

DAFTAR ISI……… v

DAFTAR TABEL……… viii

DAFTAR GAMBAR……….. x

DAFTAR SIMBOL………..………... xiii

DAFTAR LAMPIRAN………..………. xvi

BAB I PENDAHULUAN……… 1

1.1 Latar Belakang Masalah……… 1

1.2 Identifikasi Masalah……….. 2

1.3 Maksud dan Tujuan………... 3

1.4 Batasan Masalah……… 3

1.5 Metodologi Penelitian………... 4

1.6 Sistematika Penulisan……… 8

BAB II TINJAUAN PUSTAKA……….. 10

2.1 Tinjaun Perusahaan……….……….. 10

2.1.1 Sejarah Perusahaan... 10

2.1.2 Visi dan Misi Perusahaan... 11

2.1.3 Struktur Organisasi... 11

2.1.4 Tugas dan wewenang... 12

2.2 Landasan Teori.……….. 13

2.2.1 Pengertian Sistem Informasi... 13

2.2.2 Landasan Dasar Algoritma Genetik... 14

vi

2.2.7.1 Pengujian White Box... 29

2.2.7.2 Pengujian Black Box... 29

2.2.8 Software Pendukung... 30

2.2.8.1 Borland C++ Builder 6... 30

2.2.8.2 Borland Interbase 7.1... 31

BAB III ANALISIS DAN PERANCANGAN SISTEM... 37

3.1 Analisis Sistem………... 37

3.1.1 Prosedur Yang Terlibat………... 37

3.1.2 Analisis Kebutuhan Non Fungsional... 44

3.1.3 Analisis Basis Data... 47

3.1.4 Analisis Kebutuhan Fungsional………... 49

3.1.4.1 Diagram Konteks..………... 49

3.1.4.2 DFD….………...……… 50

3.1.4.3 Spesifikasi Proses………... 66

3.1.4.4 Kamus Data…….………... 88

3.2 Perancangan Sistem... 94

3.2.1 Perancangan Data... 94

3.2.1.1 Skema Relasi... 94

3.2.1.2 Struktur Tabel... 96

3.2.2 Perancangan Kode... 101

vii

3.2.3.4 Perancangan Prosedural... 126

BAB IV IMPLEMENTASI DAN PENGUJIAN SISTEM……….. 133

4.1 Implementasi Sistem... 133

4.1.1 Perangkat Lunak……...………... 134

4.1.2 Perangkat Keras…..………... 134

4.1.3 Implementasi Database dan Antarmuka……….. 134

4.1.3.1 Implementasi Database... 135

4.1.3.2 Implementasi Antar Muka... 145

4.2 Pengujian Blackbox... 148

4.2.1 Rencana Pengujian... 148

4.2.2 Kasus dan Hasil PengujianAlpha... 150

4.2.3 Kesimpulan Hasil PengujianAlpha……… 195

4.2.4 Kasus dan PengujianBetha……..…………..……… 195

4.2.5 Kesimpulan Hasil PengujianBetha…..……….. 203

BAB V KESIMPULAN DAN SARAN... 204

5.1 Kesimpulan………... 204

5.2 Saran………. 204

Oleh Harkat Wijaya

10105082

Kereta rel listrik atau lebih sering dikenal dengan KRL adalah salah satu transportasi yang sangat populer dikalangan pengguna kereta api terutama disekitar daerah Jakarta, Bogor, Depok, Tanggerang dan Bekasi yang sering disebut dengan singkatan JABODETABEK dibandingkan dengan transportasi umum darat lainnya, selain hargannya yang ekonomis, kereta rel listrik (KRL) juga merupakan salah satu kendaraan efektif yang dapat membebaskan dari kemacetan lalulintas yang sering menjadi kendala transportasi darat umum lainya didaerah JABODETABEK.

Sistem informasi ini dibuat untuk memudahkan dalam penjadwalan kereta rel listrrik (KRL) di wilayah dipo satu kota depok regional JABODETABEK. Dari sistem informasi ini dapat memberikan informasi mengenai jadwal kereta rel listrik (KRL). Pembangunan sistem informasi ini menggunakan metode algoritma genetik sebagai metode penjadwalannya.

Sistem ini dibangun berbasis stand alone yaitu untuk memberikan kemudahan kepada kepala ruas opeerasional (KROP) untuk menangani penjadwalan kereta rel listrik (KRL) di wilayah dipo satu kota depok regional JABODETABEK. Bahasa pemrograman yang digunakan yaitu Borland C++ Builder 6 dan Interbase 7.1 sebagaidatabasenya.

by Harkat Wijaya

10105082

Rail electric trains or more often known as KRL is one of the transportation be a very popular train users, especially around the Jakarta, Bogor, Depok, Tanggerang and Bekasi are often referred to with abbreviations JABODETABEK compared with other public transportation on land, in addition to the economic hargannya, rail electric train (KRL) is also one of the vehicles that can be effectively exempt from the congestion that often become lalulintas constraints Other public land transportation didaerah JABODETABEK.

Information systems were created to facilitate the scheduling rail train electricity(KRL) in the area of a city dipo depok regional JABODETABEK. From this information the system can provide information on the electric rail train schedule (KRL). Development of information system using this method the genetic algorithm as a method penjadwalannya.

This system is built based on the stand alone to provide facilities to the head segment opeerasional (CROP) to handle the scheduling rail electric train (KRL) in the area of a city dipo depok regional JABODETABEK. Programming language used is Borland C + + Builder 6 and Interbase 7.1 as a database.

1 1.1. Latar Belakang Masalah

Kereta rel listrik atau lebih sering dikenal dengan KRL adalah salah satu transportasi yang sangat populer dikalangan pengguna kereta api terutama disekitar daerah Jakarta, Bogor, Depok, Tanggerang, Bekasi, yang sering disebut dengan singkatan JABODETABEK dibandingkan dengan transportasi umum darat lainnya, selain hargannya yang ekonomis, kereta rel listrik (KRL) juga merupakan salah satu kendaraan efektif yang dapat membebaskan dari kemacetan lalulintas yang sering menjadi kendala transportasi darat umum lainya didaerah JABODETABEK.

Banyaknya peminat pengguna kereta rel listrik (KRL), menjadikan jumlah penumpang KRL lebih banyak terutama dijam-jam sibuk seperti pada jam kerja dan sekolah oleh karena itu operasional KRL juga harus diperbanyak untuk dapat mengangkut para penumpang, sehingga pihak PT.KAI regional JABODETABEK dapat mengalami kesulitan dalam mengatur penjadwalan kereta rel listrik (KRL) dan juga mengalami kesulitan untuk membuat laporan operasional kereta rel listrik (KRL) yang akan di berikan kepada kepala ruas operasinal (KROP) yang masih dibuat secara manual menggunakanMicrosoft Office Exel. Setiap kereta rel listrik yang akan datang maupun berangkat dari suatu stasiun ke satasiun tujuan akan mengalami beberapa kali persinggahan, persinggahan-persinggahan ini sering kali menjadi suatu hal yang sangat membingungkan bagi petugas PT.KAI yang akan mengatur

penjadwalan operasional KRL untuk mengetahui kilometer tempuh serta informasi apa saja yang ada disepanjang lintasan yang akan dilalui setiap kereta rel listrik,

Petugas PT.KAI sering kali dihadapkan oleh permasalahan untuk menentukan jenis KRL apa yang akan dioperasikan, disebabkan terbatasnya jumlah rangkaian kereta yang dimiliki dan layak jalan oleh PT.KAI, setiap rangkaian KRL yang akan dioperasionalkan oleh petugas KRL sering kali menjadi masalah bagi pihak PT.KAI untuk mengetahui informasi data petugas yang mengoperasionalkan KRL tersebut.

Untuk mengatasi hal-hal tersebut dibutuhkan sebuah alat bantu yang dapat mengatasi penjadwalan kereta rel listrik dengan dibangunya sebuah sistem informasi penjadwalan kereta rel listrik (KRL) JABODETABEK untuk membantu pekerjaan karyawan PT. KAI dalam menjalankan pekerjaannya.

1.2. Identifikasi Masalah

Berdasarkan latar belakang dan judul yang telah dijabarkan diatas, maka dapat ditemukan beberapa permasalahan sebagai berikut :

1. Bagaimana mengatur penjadwalan kereta rel listrik (KRL)

2. Bagaimana membuat laporan operasional kereta rel listrik (KRL)

Oleh karena itu PT. Kereta Api Indonesia membutuhkan sebuah sistem informasi sebagai pemecah masalah yang ada didalam permasalahan tersebut, maka dapat dirumuskan :

1.3. Maksud dan Tujuan

Maksud dari penulisan adalah untuk membangun sistem informasi penjadwalan Kereta Rel Listrik (KRL).

Tujuan yang ingin dicapai dari sistem informasi penjadwalan kereta rel listrik ini adalah :

1. Memudahkan dalam menjadwakan Kereta Rel Listrik (KRL).

2. Memudahkan dalam membuat laporan operasional kereta rel listrik (KRL).

1.4. Batasan Masalah

Batasan masalah pada objek penelitian ini akan meliputi beberapa permasalahan yang akan dibatasi sebagai berikut:

1. Komponen data yang menjadi masukan berupa data yang akan dibutuhkan pada saat melakukan penjadwalan seperti data KRL, data stasiun, data kedatangan dan keberangkatan KRL.

2. Data yang akan diproses dalam sistem meliputi data pengolahan user, data KRL, data stasiun, data petugas KRL dan pesan.

3. Infomasi yang akan dihasilkan adalah untuk mengetahui jarak tempuh KRL, informasi KRL, informasi stasiun yang dilalui KRL, laporan penjadwalan serta informasi lainnya yang berhubungan dengan keberangkatan dan kedatangan KRL.

4. Pembangunan Sistem Informasi Penjadwalan KRL menggunakan metode optimasi algoritma genetika untuk menyelesaikan permasalahan penjadwalan. 5. Sistem informasi penjadwalan KRL yang akan dibangun hanya akan meliputi satu

Dipo yaitu Dipo Depok pada divisi JABODETABEK.

6. Pengguna (Braindware) dalam hal ini adalah kepala ruas operasi (KROP) sebagai user yang mengelolah penjadwalan KRL.

7. Pembuatan antar muka sistem menggunakan aplikasi Borland C++ Builder 6

dengan bahasa pemrograman C sedangkan untuk databasenya menggunakan

Interbase 7.1.

8. Sistem operasi yang digunakan adalahWindows XP Service Pack 2. 9. Aplikasi ini bebasisclient-server.

10. Aplikasi ini tidak menangani laporan harian masinis dan pemeliharaan kereta rel listrik (KRL).

1.5. Metodelogi Penelitian

Metodologi penelitian yang digunakan dalam penulisan proposal ini adalah metode deskriptif, metode ini merupakan sebuah metode yang menggambarkan fakta-fakta dan informasi dalam situasi atau kejadian dimasa sekarang secara sistematis, faktual dan akurat. Metode penelitian ini memiliki dua tahapan, yaitu :

1.5.1 Tahap pengumpulan data

Tahap pengumpulan data yang digunakan dalam penelitian ini di peroleh secara langsung dari objek penelitian. Cara-cara yang mendukung untuk mendapatkan data primer adalah sebagai berikut :

a. Studi Literatur.

Studi ini dilakukan dengan cara mempelajari, meneliti dan menelaah berbagai literatur-literatur dari perpustakaan yang bersumber dari buku-buku teks, jurnal ilmiah, situs-situs di internet, dan bacaan-bacaan yang ada kaitannya dengan topik penelitian.

b. Studi lapangan

Studi ini dilakukan dengan cara mengunjungi tempat yang akan diteliti dan pengumpulan data dilakukan dengan karyawan PT.KAI, hal ini meliputi :

1. Observasi

Observasi adalah salah satu teknik pengumpulan data dengan cara meninjau langsung di PT.KAI bagian Pusrenbang.

Interview adalah teknik pengumpulan data dengan cara mengadakan wawancara dan tanya jawab lansung kepada karyawan PT.KAI bagian sistem analis mengenai topik yang sedang diteliti .

1.5.2 Tahap Pengembangan Perangkat Lunak

Tahap pengembangan sistem menggunakan metode incremental yang sudah dikembangkan dari waterfall model (gambar 1.1), karena metode incremental terdiri dari tahap-tahap yang memberikan kemudahan yaitu mampu mengakomodisi perubahan secara fleksibel dan produk yang dihasilkan pada increment pertama bukanlah prototipe, tapi produk yang bisa berfukngsi dengan spesifikasi dasar.

Tahap-tahap pengembangan perangkat lunak metode waterfall sebagai berikut [2]:

a. System engineering (Rekayasa perangkat lunak).

Merupakan tahapan yang pertama kali dilakukan yaitu merupakan sistem yang akan kita bangun. Hal ini bertujuan agar pengembang benar-benar memahami sistem yang akan kita bagun dan langkah-langkah serta kebijakan apa saja yang berkaitan dengan pengembangan sistem tersebut.

b. Requirements analysis

Melakukan analisis terhadap permasalahan yang dihadapi dan menetapkan kebutuhan perangkat lunak.

Menghasilkan rancangan yang memenuhi kebutuhan yang ditentukan selama tahapan requirements analisis. Hasil akhirnya berupa spesifikasi rancangan yang sangat rinci sehingga mudah diwujudkan pada saat pemrograman.

d. Coding (Implementasi)

Pengkodean yang mengimplementasikan hasil desain kedalam kode atau bahasa yang dimengerti oleh mesin komputer dengan menggunakan bahasa pemrograman tertentu.

e. Testing(Pengujian)

Melakukan pengujian yang menghasilkan kebenaran program. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua peryataan sudah diuji dan memastikan apakah hasil yang diinginkan sudah tercapai atau belum.

f. Maintenance (Perawatan)

Menangani perangkat lunak yang sudah selesai agar dapat berjalan lancar dan terhindar dari gangguan-gangguan yang dapat menyebabkan kerusakan.

Gambar 1.1 Modelwaterfall [4]

1.6 Sistematika Penulisan BAB I PENDAHULUAN

Bab ini menguraikan tentang latar belakang permasalahan, mencoba merumuskan inti permasalahan yang dihadapi, menentukan tujuan dan kegunaan penelitian, yang kemudian diikuti dengan pembatasan masalah, asumsi, serta sistematika penulisan.

BAB II TINJAUAN PUSTAKA

Bab ini menguraikan tentang penelitian perusahaan dan uraian teori-teori yang berkaitan tentang sistem informasi penjadwalan kereta rel listrik, penggunaan bahasa pemrograman yang akan digunakan serta teori lain yang berasal dari sumber-sumber hasil penelitian.

BAB III ANALISIS DAN PERANCANGAN SISTEM

Bab ini menjelaskan tentang anlisis masalah dan pemecahan masalah rancangan sistem informasi yang diusulkan, pemodelan sistem yang dibuat, seperti Konteks Diagram, DataFlow Diagram, rancangan struktur database dan rancangan tampilan.

BAB IV IMPLEMENTASI DAN PENGUJIAN SISTEM

Bab ini menjelaskan tentang implementasi dan pengujian sistem informasi penjadwalan KRL kepada karyawan PT.KAI

BAB V KESIMPULAN DAN SARAN

Bab ini berisi menguraikan tentang kesimpulan dari bahasa yang telah dilakukan dan saran untuk pengembangan selanjutnya.

10 2.1 Tinjauan Perusahaan

Pada sub bab ini akan menjelaskan mengenai profil perusahaan yang menjelaskan tentang sejarah berdirinnya perusahaan, Visi maupun misi perusahaan serta sturktur organisasi perusahaan.

2.1.1 Sejarah Perusahaan [1]

Kehadiran kereta api di Indonesia ditandai dengan pencangkulan pertama pembangunan jalan KA didesa Kemijen Jumat tanggal 17 Juni 1864 oleh Gubernur Jenderal Hindia Belanda, Mr. L.A.J Baron Sloet Van Den Beele. Pembangunan diprakarsai oleh Naamlooze Venootschap Nederlandsch Indische Spoorweg Maatschappij (NV. NISM) yang dipimpin oleh Ir. J.P De Bordes dari Kemijen menuju Desa Tanggung sepanjang 26 Km dengan lebar sepur 1435 mm. Ruas jalan ini dibuka untuk angkutan umum pada hari sabtu, 10 agustus 1867.

Keberhasilan swasta, NV. NISM membangun jalan KA antara Kemijen sampai Tanggung, yang kemudian pada tanggal 10 februari 1870 dapat menghubungkan kota Semarang dan Surakarta sepanjang 110 Km, akhirnya mendorong minat investor untuk membangun jalan KA didaerah lainnya.

Setelah kemerdekaan Indonesia diproklamasikan pada tanggal 17 Agustus 1945, karyawan KA yang tergabung dalam Angkatan Moeda Kereta Api (AMKA)

mengambil alih kekuasaan perkeretaapian dari pihak Jepang. Peristiwa bersejarah yang terjadi pada tanggal 28 September 1945, pembacaan pernyataan sikap oleh Ismangil dan sejumlah anggota AMKA lainnya, menegaskan bahwa mulai tanggal 28 September 1945 kekuasaan perkeretaapian berada ditangan bangsa Indonesia. Orang Jepang tidak diperkenankan lagi campur tangan dengan urusan perkeretaapian di Indonesia. Inilah yang melandasi ditetapkannya 28 September 1945 sebagai Hari Kereta Api di Indonesia, serta dibentuknya Djawatan Kereta Api Republik Indonesia (DKARI).

2.1.2 Visi dan Misi Perusahaan

Visi dari perusahaan PT.KAI adalah terwujudnya kereta api sebagai pilihan utama jasa transportasi dengan fokus keselamatan dan pelayanan yang terbaik kepada masyarakat sedangkan misi dari perusahaan yaitu menyelenggarakan jasa transportasi sesuai keinginan masyarakat dengan meningkatkan keselamatan dan pelayanan serta penyelenggaraan yang semakin efisien [1] .

2.1.3 Struktur Organisasi

Struktur organisasi merupakan susunan seluruh organisasi dari PT Kereta Api Indonesia, mulai dari yang tertinggi yaitu dewan komisaris sampai ke daerah operasi dan divisi regional. Organisasi tertinggi dalam struktur organisasi PT.KAI adalah dewan komisaris yang menjabat sebagai dewan tertinggi diatas direktur utama yang memiliki kemampuan dan keputusan menganai arah susunan organisasi PT.KAI

sesuai dengan keputusan mentri transportasi indonesia, semua susunan organisasi didalam PT.KAI mulai dari dewan komisaris sampai ke daerah operasi dan divisi regional memiliki fungsi dan perannnya masing-masing untuk menuju satu tujuan yang sama yaitu memiliki visi yang sama memberikan kenyamanan bertransportasi berkereta api kepada masyarakat. Untuk lebih jelasnya dapat dilihat pada gambar dibawah ini [1]:

Gambar 2.1 Struktur Organisasi 2.1.4 Tugas Dan Wewenang

Tugas dan wewenang dilakukan pada bagian pusrenbang sebagai pusat pengembangan IT dan implementasi yang berada dikantor pusat milik PT.KAI dijalan perintis kemerdekaan nomor 1 Bandung, sedangkan tugas yang ditiliti berada pada

daerah operasional jawa dan divisi JABOTABEK dengan studi kasus menjadwalkan KRL pada bagaian dipo Depok divisi dari JABODETABEK milik PT.KAI.

2.2 Landasan Teori

Pada subab landasan teori ini akan menjelaskan beberapa teori yang akan berhubungan dengan permasalahan yang akan dibahas sebagai dasar pemahaman dalam sebuah sistem serta metode yang dipakai untuk kegiatan pengembangan terhadap sistem.

2.2.1 Pengertian Sisitem Informasi

Terdapat beberapa istilah pengertian sistem informasi diantarannya pengertian sistem informasi menurut Henry C. Lucas, John F. Nash dan Martin B. Robert:

1. Menurut Henry C. Lucas

“Sistem Informasi adalah kegiatan dari suatu prosedur-prosedur yang

diorganisasikan bilamana dieksekusi akan menyediakan informasi untuk mendukukung pengambilan keputusan dan pengendalian di dalam organisasi”.

2. Menurut John F. Nash dan Martin B. Robert

Sistem Informasi adalah suatu kombinasi dari orang-orang, fasilitas teknologi, media, prosedur-prosedur dan pengendalian ditujukan untuk mendapatkan jalur komunikasi penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada manajemen dan yang lainnya terhadap

kejadian-kejadian internal dan eksternal yang penting dan menyediakan

suatu dasar untuk pengambilan keputusannya yang cerdik .

Berdasarkan pengertian sistem informasi yang telah disebutkan oleh Henry C. Lucas, John F. Nash dan Martin B. Robert tersebut sistem informasi memiliki suatu kelebihan diantarannya untuk mengambil sebuah keputusan berdasarkan ketentuan-ketentuan yang telah ada untuk mendukung sistem informasi tersebut.

2.2.2 Landasan Dasar Algoritma Genetik

Algoritma genetik ditemukan di Universitas Michigan, Amerika Serikat oleh John Holland (1975) melalui sebuah penelitian dan dipopulerkan oleh salah satu muridnya, David Goldberg. Algoritma genetik adalah algoritma yang berusaha menerapkan pemahaman mengenai evolusi alamiah pada tugas-tugas pemecahan masalah (problem solving). Pendekatan yang diambil oleh algoritma ini adalah dengan menggabungkan secara acak berbagai pilihan solusi terbaik didalam suatu kumpulan untuk mendapatkan generasi solusi terbaik berikutnya yaitu pada suatu kondisi yang memaksimalkan kecocokannya atau lazim disebut fitness. Generasi ini akan merepresentasikan perbaikan-perbaikan pada populasi awalnya, dengan melakukan proses ini secara berulang, algoritma ini diharapkan dapat mensimulasikan proses evolusioner. Pada akhirnya, akan didapatkan solusi-solusi yang paling tepat bagi permasalahan yang dihadapi. Untuk menggunakan algoritma genetik, solusi permasalahan direpresentasikan sebagai kromosom. Tiga aspek yang penting untuk penggunaan algoritma genetik:

1 Definisifitness function

2. Definisi dan implementasi representasi genetik 3. Definisi dan implementasi operasi genetik

Jika ketiga aspek diatas telah didefinisikan, algoritma genetik genetik akan bekerja dengan baik. Tentu saja, algoritma genetik bukanlah solusi terbaik untuk memecahkan segala masalah. Sebagai contoh, metode tradisional telah diatur untuk untuk mencari penyelesaian dari fungsi analitis convex yang variabelnya sedikit.

Pada kasus-kasus ini, metode berbasis kalkulus lebih unggul dari algoritma genetik karena metode ini dengan cepat menemukan solusi minimum ketika algoritma genetik masih menganalisa bobot dari populasi awal. Untuk problem-problem ini pengguna harus mengakui fakta dari pengalaman ini dan memakai metode tradisional yang lebih cepat tersebut. Akan tetapi, banyak persoalan realistis yang berada diluar golongan ini. Selain itu, untuk persoalan yang tidak terlalu rumit, banyak cara yang lebih cepat dari algoritma genetik. Jumlah besar dari populasi solusi, yang merupakan keunggulan dari algoritma genetik, juga harus mengakui kekurangannya dalam dalam kecepatan pada sekumpulan komputer yang dipasang secara seri fitness function dari tiap solusi harus dievaluasi. Namun, bila tersedia komputer-komputer yang paralel, tiap prosesor dapat mengevaluasi fungsi yang terpisah pada saat yang bersamaan. Karena itulah, algoritma genetik sangat cocok untuk perhitungan yang parallel [6].

2.2.3 Penggunaan Algoritma Genetika

Algoritma genetik dimulai dengan sekumpulan set status yang dipilih secara random, yang disebut populasi. Algoritma ini mengkombinasikan dua populasi induk. Setiap status atau individual direpresentasikan sebagai sebuah string. Setiap individual dievaluasi denganfitness function. Sebuah fitness function

mengembalikan nilai tertinggi untuk individual yang terbaik. Individu akan diurutkan berdasarkan nilai atau disebut denganselection.

Untuk setiap pasang induk, sebuah titik crossover akan dipilih secara acak dari posisi dalam string. Pada gambar titik crossover terletak pada indeks ketiga dalam pasangan pertama dan setelah indeks kelima pada pasangan kedua.

Pada mutasi, tiap lokasi menjadi sasaran mutasi acak, dengan probabilitas independen yang kecil. Sebuah digit dimutasikan pada anak pertama, ketiga, dan keempat. Algoritma genetik mengkombinasikan suatu kecenderungan menaik dengan pengeksplorasian acak diantara thread pencarian paralel. Keuntungan utamanya,bila ada, datang dari operasi crossover. Namun, secara matematis dapat tunjukkan bahwa bila posisi dari kode genetik dipermutasikan diawal dengan urutan acak,crossovertidak memberikan keunggulan. Secara intuisi, keuntungannya didapat dari kemampuan crossover untuk menggabungkan blok-blok huruf berukuran besar yang telah berevolusi secara independen untuk melakukan fungsi yang bermanfaat sehingga dapat menaikkan tingkat granularity dimana pencarian dilakukan.

Teori dari algoritma genetik menjelaskan cara kerjanya menggunakan ide dari suatu sekema, suatu sub-string dimana beberapa posisi tidak disebutkan. Dapat ditunjukkan bahwa, bila fitness rata-rata dari schema berada dibawah

mean maka jumlah instansiasi dari sekema didalam populasi akan bertambah seiring bertambaahnya waktu. Jelas sekali bahwa efek ini tidak akan signifikan bila bit-bit yang bersebelahan sama sekali tidak berhubungan satu sama sekali, karena akan ada beberapa blok yang memberikan keuntungan yang konsisten. Algoritma genetik paling efektif dipakai bila skema-skema berkorespondensi menjadi komponen berati dari sebuah solusi. Sebagai contoh, bila string adalah representasi dari sebuah antena, maka schema merepresentasikan komponen-komponen dari antena, seperti reflector dan deflector. Sebuah komponen yang baik cenderung akan berkerja baik pada rancangan yang berbeda. Ini menunjukkan bahwa penggunaan algoritma genetik yang benar memerlukan rekayasa yang baik.

2.2.3.1 Skema Pengkodean

Misalkan kita ingin memecahkan masalah optimasi fungsi produksi Cobb-Dauglas yaitu y = 1L 2K 3 dengan sample yang ada untuk L dan K berapa nilai 1, 2, 3 dengan fungsi tujuan meminimumkan least square atau memaksimumkan fungsi likelihood. Dengkian pula untuk persoalan yang sama pada fungsi produksi CES. Persoalan tersebut dapat diselesaikan dengan AG, yaitu: ketiga parameter 1, 2, 3 dikodekan dalam kromosom. Masing- masing kromosom berisi sejumlah gen, yang mengkodekan informasi yang disimpan di dalam kromosom. Misalkan untuk memudahkan digunakan binary encoding dengan panjang kromosom 12 gen (12 bits), masing-masing parameter 1, 2, 3 dikodekan dengan 4 gen, sehingga dapat iilustrasikan skema pengkodean pada Gambar 2.3 bawah ini:

Gambar 2.3 Skema Binary Encoding

Bilamana nilai parameter yang akan kita cari mempunyai konstraint. yaitu a < < b maka berdasarkan binary encoding, nilai parameter dapat dieroleh dengan formula :

= a + dec ( (b a)

banyaknya gen (bits) yaitu 4 untuk setiap parameter dan kontraint 0 < <1 , Setetelah skema pengkodean ditentukan, AG diinisialisasi untuk sebuahpopulasi dengan N kromosom. Gen-gen yang mengisi masing- masing kromosom dibangkitkan secara random. Masing- masing kromosom akan dikodekan menjadi individu dengan nilai fitness tertentu. Kemudian sebuah populasi baru akan dibentuk dengan menggunakan mekanisme seleksi alamiah, yaitu memilih individu- individu secara proporsional terhadap nilai fitnessnya, dan genetika alamiah, yakni pindah silang (crossover) dan mutasi.Pada algoritma getika yang akan digunakan adalah dengan skema pergantian populasi yang disebut generational replacement, artinya, N kromosom dari suatu generasi digantikan sekaligus oleh N kromosom baru hasil pindah silang dan mutasi.

2.2.3.2 Nilai Fitness

Suatu individu dievaluasi berdasarkan suatu fungsi tertentu sebagai ukuran performansinya. Di dalam evolusi alam, individu yang bernilai fitnes tinggi yang akan bertahan hidup. Sedangkan individu yang bernilai fitness rendah akan mati. Pada masalah optimasi, solusi yang akan dicari adalah memaksimumkan sebuah fungsi likelihood dan meminimumkan least square baik untuk fungsi produksi Cobb-Dauglas maupun fungsi produksi CES.

2.2.3.3 Seleksi Orang Tua

Pemilihan dua buah kromosom sebagai orang tua, yang akan dipindahsilangkan, biasanya dilakukan secara proporsional sesuai dengan dengan nilai fitness-nya. Suatu meetoda seleksi yang umumnya digunakan adalah roulette wheel (roda raoulette). Sesuai dengan namanya, metoda ini menirukan permainan roulette wheel di mana masing-masing kromosom menempati potongan lingkaran pada roda raulette secara proporsional sesuai dengan nilai fitnessnya. Kromosom yang memiliki nilai fitness lebih besar menempati potongan lingkaran yang lebih besar dibandingkan dengan kromosom bernilai fitness rendah.

Gambar 2.4 Contoh penggunaan metoda roulette wheel selection.

Metoda raulette-wheel selection sangat mudah diimplementasikan dalam pemprograman. Pertama, dibuat interval nilai kumulatif dari nilai fitness masing-masing kromosom. Sebuah kromosom akan terpilih jika bilangan random yang dibangkitkan berada dalam interval kumulatifnya. Pada Gambar 2.4 di atas, K1 menempati interval kumulatif [0;0,25], K2 berada dalam interval (0,25;0,74], K3

dalam interval (0,75;0,875] dan K4 berada dalam interval (0,875;1]. Misalkan, jika bilangan random yang dibangkitkan adalah 0,6 maka kromosom K2 terpilih sebagai orang tua. Tetapi jika bilangan random yang dibangkitkan adalah 0,9 maka kromosom K4 yang terpilih.

2.2.3.4 Pindah Silang (Cross-over )

Salah satu komponen yang paling penting dalam algoritma genetik adalah crossover atau pindah silang. Sebuah kromosom yang mengarah pada solusi yang baik dapat diperoleh dari proses memindah-silangkan dua buah kromosom.

Gambar 2.5 Contoh Proses Pindah Silang

Pindah silang juga dapat berakibat buruk jika ukuran populasinya sangat kecil. Dalam suatu populasi yang sangat kecil, suatu kromosom dengan gen-gen yang mengarah ke solusi akan sangat cepat menyebar ke kromosomkromosom lainnya. Untuk mengatasi masalah ini digunakan suatu aturan bahwa pindah silang hanya bisa dilakukan dengan suatu probabilitas tertentu, artinya pindah silang bisa dilakukan hanya jika suatu bilangan random yang dibangkitkan kurang dari probabilitas yang ditentukan

tersebut. Pada umumnya probabilita tersebut diset mendekati 1. Pindah silang yang paling sederhana adalah pindah silang satu titik potong (one-point crossover). Suatu titik potong dipilih secara random, kemudian bagian pertama dari orang tua 1 digabungkan dengan bagian kedua dari orang tua 2 (terlihat pada gambar 2.5). Crossover adalah operator Algoritma Genetika yang utama karena beroperasi pada dua kromosom pada suatu waktu dan membentuk offspring dengan mengkombinasikan dua bentuk kromosom. Cara sederhana untuk memperoleh crossover adalah dengan memilih suatu titik yang dipisahkan secara random dan kemudian membentuk offspring dengan cara mengkombinasikan segmen dari satu induk ke sebelah kiri dari titik yang dipisahkan dengan segmen dari induk yang lain ke sebelah kanan dari titik yang dipisahkan. Metode ini akan berjalan normal dengan representasi bit string. Performa dari Algoritma Genetika bergantung pada performa dari operator crossover yang digunakan. Crossover rate merupakan rasio antara jumlah offspring yang dihasilkan pada setiap generasi terhadap luas populasinya. Semakin tinggi crossover rate akan memungkinkan eksplorasi ruang solusi yang lebih luas dan mereduksi kemungkinan jatuh pada kondisi optimum yang salah. Namun memberikan rate yang memberikan konsekuensi makin lamanya waktu perhitungan yang diperlukan sebagai akibat eksplorasi pada luas populasi yang ada.

2.2.3.5 Mutasi

Mutasi dapat dilakukan dari semua gen yang ada dengan probabilitas mutasi tertentu. Jika bilangan random yang dibangkitkan kurang dari probabilitas mutasi

yang ditentukan maka ubah gen tersebut menjadi nilai kebalikan yang dalam hal ini, binary encoding, 0 diubah 1, dan 1 diubah 0. Bila mana probabilitas mutasi adalah ( 1 12 ) maka sebanyak 1 gen akan dimutasi dari kromosom yang terdiri dari 12 gen (bits). Pada algoritma genetika yang sederhana, nilai probabilitas mutasi adalah tetap selama evolusi. Gambar 2.6 menunjukan proses mutasi yang terjadi pada gen5.

Gambar 2.6 Contoh Proses Mutasi

Mutasi dapat dikatakan sebagai operasi pendukung yang menghasilkan perubahan secara acak dan seketika pada berbagai jenis kromosom. Cara mudah untuk mendapatkan mutasi dengan mengubah satu atau lebih genes. Pada Algoritma Genetika, mutasi memainkan peran penting, yaitu pertama, menggantikan genes yang hilang dari populasi selama proses seleksi, sehingga dapat diujikan pada suatu kondisi yang baru. Kedua, menyediakan genes yang tidak ditampilkan pada populasi awal. utation rate menyatakan presentase dari total jumlah genes dalam opulasi. Mutation rate ini melakukan kontrol dimana genes baru dalam populasi dapat diuji seleksi. Jika rate terlalu kecil akan banyak genes yangsebenarnya bermanfaat tetapi tidak pernah diuji seleksi. Namun jika rate terlalu tinggi akan terjadi random pertubation, yang berakibat offspring mulai kehilangan kemiripan dengan induknya dan Algoritma Genetika akan kehilangan kemampuan untuk melihat urutan langkah observasinya.

2.2.3.6 Elitisme

Proses seleksi dilakukan secara random sehingga tidak ada jaminan bahwa suatu indvidu yang bernilai fitness tertinggi akan selalu terpilih. Walaupun individu bernilai fitness tertinggi terpilih, mungkin saja individu tersebut akan rusak (nilai fitnessnya menurun) karena proses pindah silang. Oleh karena itu, untuk menjaga agar individu bernilai fitness tertinggi tersebut tidak hilang selama evolusi, maka perlu dibuat satu atau beberapa kopinya. Prosedure ini dikenal sebagai elitisme.

2.2.4 Entity Relationship Diagram (ERD)

Entity Relationship Diagram (ERD) adalah model konseptual yang mendeskripsikan hubungan antara penympanan (dalam DFD). ERD digunakan untuk memodelkan struktur data dan hubungan antar data. Dengan ERD model dapat diuji dengan mengabaikan proses yang dilakukan.

ERD pertama kali dideskripsikan oleh Peter Chen yang dibuat sebagai bagian dari perangkat lunakCASE.

Didalam atribut ada yang berfungsi sebagaikey. Key adalah suatu atribut yang sifatnya unik. Key dapat dibangun dari satu atribut atau gabungan dari beberapa atribut.Key terbagi menjadi beberapa jenis, diantarnya [3] :

1. Super key, seluruh atribut dalam suatu entitas dijadikankey. 2. Primary key, 1 atribut dalam suatu entitas dijadikankey. 3. Candidat key, beberapa atribut dijadikankey.

Di dalam ERD, relasi, dapat terdiri dari sejumlah entitas yang disebut dengan derajat relasi. Derajat relasi maksimum disebut dengan kardinalitas sedangkan derajat minimum disebut dengan modalitas. Jadi, kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas lain. Kardinalitas relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dapat berupa:

1. Satu ke satu (one to one / 1-1)

Setiap entitas pada himpunan entitas A dapat berelasi dengan paling banyak satu entitas pada himpunan entitas B, demikian juga sebaliknya.

2. Satu ke banyak (one to many / 1-N)

Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada himpunan B, tetapi tidak sebaliknya.

3. Banyak ke banyak (many to many / N-N)

Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada himpunan entitas B, demikian juga sebaliknya. Relasi akan dipetakan menjadi tabel beserta atributnya.

2.2.5 Data Flow Diagram (DFD)

DFD adalah suatu model logika data atau proses yang dibuat untuk menggambarkan dari mana asal data dan kemana tujuan data keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data dan interaksi antara data yang tersimpan dan proses yang dikenakan pada data tersebut.

DFD sering digukan untuk menggambarkan suatu sistem yang telah ada atau sistem baru yang akan dikembangkan secara logika tanpa mempertimbangkan lingkungan fisik dimana data tersebut mengalir atau simana data tersebut akan disimpan.

DFD merupakan alat yang digunakan pada metodologi pengembangan sistem yang terstruktur. Kelebihan utama DFD yaitu:

1 Kebebasan dalam menjalankan implementasi teknik sistem.

2 Pemahaman lebih jauh mengenai keterkaitan satu sama lain dalam sistem dan subsistem.

3 Mengkomunikasikan pengetahuan sistem yang ada dengan pengguna melalui diagram aliran data.

4 Menganalisa system yang diajukan untuk mementukan apakah data-data dan proses yang diperlukan sudah ditetapkan.

5 Dapat digunakan sebagai latihan yang bermanfaat bagi penganalisis, sehingga bisa memahami dengan lebih baik keterkaitan satu sama lain dalam sistem dan subsistem.

6 Membedakan sistem dari lingkungannya dengan menempatkan batas-batasnya.

7 Dapat digunakan sebagai suatu perangkat untuk berinteraksi dengan pengguna.

8 Memungkinkan penganalisis menggambarkan setiap komponen yang digunakan dalam diagram.

DFD terdiri dari context diagram dan diagram rinci (DFD Levelled). Context diagram berfungsi memetakan model lingkungan (menggambarkan hubungan antara entitas luar, masukan dan keluaran sistem), yang direpresentasikan dengan lingkaran tunggal yang mewakili keseluruhan sistem. DFD levelled menggambarkan sistem sebagai jaringan kerja antara fungsi yang berhubungan satu sama lain dengan aliran dan penyimpanan data, model ini hanya memodelkan system dari sudut pandang fungsi.

Dalam DFD levelled akan terjadi penurunan level dimana dalam penurunan level yang lebih rendah harus mampu merepresentasikan proses tersebut ke dalam spesifikasi proses yang jelas. Setiap penurunan hanya dilakukan bila perlu. Aliran data yang masuk dan keluar pada suatu proses dilevel x harus berhubungan dengan aliran data yang masuk dan keluar pada level x+1 yang mendefinisikan proses pada level x tersebut.

Dalam penggambaran DFD, ada beberapa peraturan yang harus diperhatikan sehingga dalam penggambarannya tidak terjadi kesalahan, aturan tersebut yaitu:

1 Antar entitas tidak diijinkan terjadi hubungan atau relasi.

2 Tidak boleh ada aliran data antara entitas eksternal dengan data store.

3 Untuk alasan kerapian, entitas eksternal atau data store boleh digambar beberapa kali dengan tanda khusus, misalnya diberi nomor atau garis miring. 4 Data aliran data boleh mengalirkan beberapa paket data.

5 Bentuk anak panah aliran data boleh bervariasi. 6 Semua objek harus mempunyai nama.

7 Aliran data selalu diawali atau diakhiri dengan proses. 8 Semua aliran data harus mempunya tanda arah.

9 Jumlah proses tidak lebih dari sembilan proses dalam sistem, jika melebihi maka sebaiknya dikelompokan menjadi beberapa proses yang bekerja bersama-sama didalam suatu subsistem.

2.2.6 Flow Chart

Flow Chart adalah suatu bagan yang menggambarkan arus logika dari data yang akan diproses dalam suatu program dari awal sampai akhir. Flow chart merupakan alat yang berguna bagi programmer untuk mempersiapkan program yang rumit.Flow chart terdiri dari simbol-simbol yang mewakili fungsi-fungsi langkah program dari garis alir (flow lines) yang menunjukan urutan dari simbol-simbol yang akan dikerjakan.

2.2.7 Pengujian

Pengujian adalah elemen kritis dari jaminan kualitas perangkat lunak dan merepresentasikan kajian pokok dari spesifikasi, desain, dan pengkodean. Pentingnya pengujian perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak tidak dapat terlalu ditekan karena melibatkan sederetan aktivitas produksi dimana peluang terjadinya kesalahan manusia sangat besar dan arena ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna

maka pengembangan perangkat lunak diiringi dengan aktivitas jaminan kualitas. Pendekatan DesainTest Case terbagi menjadi :

2.2.7.1 Pengujian White Box

Pengujian White Box merupakan pendekatan terhadap pengujian yang diturunkan dari pengetahuan struktur dan implementasi perangkat lunak.Pengujian

White Box biasanya diterapkan untuk unit program yang relatif kecil seperti subrutin atau operasi yang terkait dengan suatu objek. Penguji dapat menganalisis kode dan menggunakan pengetahuan mengenai struktur komponen untuk menurunkan data uji [2]. Analisis kode dapat digunakan untuk menemukan berapa kasus uji yang dibutuhkan untuk menjamin bahwa semua statement pada program atau komponen dieksekusi paling tidak satu kali pada proses pengujian. Pengetahuan mengenai algoritma yang digunakan untuk implementasi beberapa fungsi dapat dipakai untuk mengidentifikasi partisi ekuivalensi lebih lanjut.

2.2.7.2 Pengujian Black Box

Pengujian Black Box merupakan pendekatan pengujian yang ujinya diturunkan dari spesifikasi program atau komponen. Sistem merupakan kotak hitam yang perilakunya hanya dapat ditentukan dengan mempelajari input dan output yang berkaitan. Nama lain untuk cara ini adalah pengujian fungsional karena penguji hanya berkepentingan dengna fungsionalitas dan bukan implementasi perangkat

lunak.PengujianBlack Box dapat diterapkan pada sistem yang disusun sebagai sistem maupun sebagai objek [2]. Penguji memberikan input kepada komponen atau sistem dan meneliti output yang dihasilkan. Jika output bukan merupakan yang dikehendaki, berarati pengujian tersebut telah mendeteksi masalah dengan perangkat lunak tersebut.

2.2.8 Software Pendukung

Untuk membangun sebuah Sistem Informasi Penjadwalan KRL dibutuhkan perangkat lunak yang menunjang yaitu berupa program aplikasi Borland C++ Builder 6 dengan Database Management System (DBMS) menggunakan Interbase 7.1.

2.2.8.1 Borland C++ Builder 6 [4]

C++ Builder adalah suatu alat pengembang aplikasi (development tool) berbasis

Microsoft Windows yang menerapkan konsep visualisasi. Dengan adanya dukungan visualisasi ini C++ Builder menjadi mudah digunakan untuk membuat aplikasi-aplikasi secara cepat. Dengan C++ Builder, dapat melakukan desain, testing, debugging, maupun prosesdeployment aplikasi secara mudah.

Bahasa dasar yang digunakan dalam pemrograman C++ Builder adalah bahasa C++, yang telah terkenal dalam keampuhannya dalam pembuatan program. Memang harus diakui bahwa tingkat keteraturan dan kemudahan dari bahasa C++ relatif lebih rendah dibandingkan bahasa Objek Pascal, namun dengan mempelajari

konsep-konsep yang ada didalamnya, tentu C++ akan menjadi bahasa yang mudah dipahami dan digunakan.

Lingkungan yang terdapat pada C++ Builder menawarkan kemudahan dan kenyamanan dalam proses pengembangan aplikasi, sehingga mudah digunakan oleh siapapun, termasuk bagi para programmer pemula sekalipun. Namun bila digunakan oleh programmer yang telah berpengalaman, C++ Builder tentu akan dapat menghasilkan aplikasi yang berkemampuan tinggi.

Untuk memulai pemrograman dengan C++ Builder tentu harus mengenal dengan baik lingkungan yang ada didalamnya. Lingkungan semacam ini sering disebut dengan IDE(Integrated Development Environtment).

2.2.8.2 Borland Interbase 7.1

Borland Interbase 7.1 adalah database transaksional yang ekonomis dan memiliki performa yang tinggi, dan banyak digunakan oleh jutaan pengguna diseluruh dunia. Dengan mengkombinasi instalasi yang mudah,crash-recovery secara

otomatis, dan perawatan yang sangat minim, Interbase menjadi sangat sesuai untuk

embedding dalam aplikasi terdistribusi. Dukungan terhadap multiprosesor dan arsitektur yang canggih menjadikannya sebuah pilihan yang tepat untuk aplikasi bisnis dengan kekuatan tinggi yang memiliki banyak pengguna yang terkoneksi. Kekuatannya, yaitu kemudahan penggunaan, dukungan terhadap platform Windows, Linux, dan Solaris (termasuk pengembangan dalam lingkungan seperti Borland

Delphi, C++ Builder, dan Kylix), membuat Interbase menjadi favorit bagi para pengembang.

Fitur-fitur dan keunggulan yang dimiliki olehinterbase adalah sebagai berikut: a. Database terintegrasi

b. Cepat c. Fleksibel

d. Dapat dipercaya e. Kebebasan platform

f. Dukungan untuk standar industri

Adapula arsitekturinterbase sebagai berikut: a. Super Server

Super Server merupakan multi klien, implementasi multi-thread dari proses

server InterBase. Implementasi ini menggantikan jenis implementasi model Classic

yang telah digunakan pada versiInterBasesebelumnya.

Super Server melayani banyak klien dalam waktu yang sama menggunakan urutan daripada proses server yang terpisah untuk setiap klien. Multiple thread

membagi akses kepada prosessingle server. Keuntungan dariSuper Serveradalah: 1. Memiliki sebuah proses server mengeliminasi kemacetan hasil dari arbitrasi

untuk membagi halaman-halaman database dan mengurangi kenaikan yang diperlukan untukmultiple proses memulai dan permintaandatabase.

2. Super Server meningkatkan kinerja interaksi pesan karena pemanggilan sharing library selalu lebih cepat daripada interproses permintaan komunikasi pada proses server.

3. Super Server meningkatkan integritas database karena hanya satu proses server yang telah ditulis mengakses database, daripada satu proses untuk setiap klien. 4. Super Servermengijinkan dalam mengoleksistatistic database dan informasi user

yang dapat digunakan oleh tool InterBase untuk kinerja pengawasan dan tugas administratif.

5. Super Server bernilai lebih efektif ketimbang arsitektur Classic. Semua sistem operasi memiliki batas nilai dari operasi sistem operasi yang dapat berjalan secara bersama-sama. Super Server mengijinkan untuk angka dari database yang telah ditetapkan meneruskan menjadi digandakan angka yang besar secara potensial dari koneksi database berbarengan.

b. Classic

Jenis arsitektur lainnya yaitu Classic, merupakan design dari InterBase versi 4.0 dan sebelumnya, adalah didasarkan pada proses. Untuk setiap koneksi klien, proses server yang terpisah dimulai dengan mengeksekusiengine database dan setiap proses server memiliki suatu cache database yang didedikasikan. Proses server ditentang untuk mengakses database, sehingga subsistem Lock Manager diperlukan untuk mengarbitrasi dan mengsinkronisasi akses database berbarengan diantara proses-proses.

Server InterBase Classic berjalan berdasar permintaan multiple proses. Sewaktu klien berusaha mengkoneksi ke suatu database Interbase, suatu executable

darigds_inet_serverberjalan dan sisanya didedikasikan kepada koneksi klien tersebut selama durasi koneksi. Inisiator dari gdnet_inet_server adalah inetd, merupakan proses pelayanan pengalihan kunci dari UNIX. Ia memiliki sebuah konfigurasi file

(/etc/inetd.conf) yang mengasosiasikan pelayanan dengan executable yang dipakai untuk menerima koneksi. Ketika inetd menerima sebuah koneksi yang diminta untuk sebuah servis, ia akan mencari program yang tepat pada /etc/inetd.conf, kemudian mengeksekusinya dan mentransfer koneksi jaringan ke program servis. Ketika klien memutuskan untuk disconnect, gds_inet_server menutup koneksi ke database dan file-file lainnya tersebut. Sewaktu tidak ada klien yang terkoneksi ke database, seharusnya tidak terdapat invokasi darigds_inet_serveryang sedang berjalan.

Lock Management, diambil alih oleh proses lainnya yaitu gds_lock_mgr. Program ini akan memulai ketika klien kedua masuk untuk diberikan database. Pekerjaan dari lock manager adalah untuk pelayanan, sebagai traffic cop. Ia memberikan kunci sumber database kepada klien. Ia juga meminta klien melepaskan kunci pada suatu sumber sewakturesourcetersebut sedang diminta oleh klien lain. Ia masih berjalan meskipun klien terakhir disconnect. Untuk waktu berikutnya suatu klien melakukan koneksi, akan terhindar dari kelebihan kelalaian dari proses lock manager.

Gds_lock_mgr memproses komunikasi kepada setiap proses klien dengan penggunaan area share memory dan sebuah mekanisme sinyal menggunakan sinyal

Posix, yaitu SIGUSR1 dan SIGUSR2. Sinyal-sinyal tersebut ditangkap dalam rutin sinyal handling pada libgdslib,a, dan untuk alasan ini aplikasi pengguna seharusnya tidak menampilkan sinyal handling atau memodifikasi signal mask. Seluruh aplikasi klien decompile dengan menggunakanligds,a.Tidak ada perubahan yang diperlukan, hanyaoption hubungan yang berbeda.

Setiap instance dari gdnet_inet_server menyimpan cache dari halaman-halaman database pada setiap ruang memorinya, digunakan untuk menghasilkan beberapa duplikasi dari datacache melalui sistem. Selama penggunaanresource per klien lebih besar pada Super Server, model Classic secara keseluruhan lebih sedikit menggunakan resource ketika angka dari koneksi yang dilakukan berbarengan jumlahnya sedikit.

ArsitekturClassicmengijinkan pemrosesan dari aplikasi untuk melakukanI/O

pada file-file database secara langsung, mengingat arsitektur Super Server

membutuhkan aplikasi untuk meminta operasiI/O ibserverdariproxy, menggunakan metode jaringan. Metode akses local lebih cepat daripada metode akses jaringan, tetapi hanya berguna dengan aplikasi-aplikasi yang berjalan pada host yang sama sebagai database.

Dalam memonitor database, pada model Classic, informasi panggilan dari koneksi database selalu melaporkan tepatnya satu koneksi, tidak terpengaruh terhadap berapa banyaknya klien yang melakukan koneksi kepada server tersebut. Hal ini terjadi karena setiap koneksi klien memiliki proses gds_inet_server masing-masing. Hanya pad model Super Server saja yang memiliki kemampuan untuk melaporkan seluruh koneksi klien pada server.

Mengenai sekuritas, dalam hal model Classic bekerja percampuran antara local dan remote klien yang berjalan sebagai userID yang berbeda, server yang dapat diesekusi gdnet_inet_server dan gds_lock_mgr harus berjalan sebagai root. Prosesnya harus berjalan denganuserIDsebenarnya dari root untuk mengeset userID

efektif mereka, yaitu userID klien tersebut. Dalam hal ini Lock Manager harus memiliki hak sebagaisuper useruntuk mengirim sinyal kepada proses tersebut.

37 3.1 Analisis Sistem

Analisis sistem dapat didefinisikan sebagai penguraian dari suatu sistem informasi yang utuh ke dalam bagian-bagian komponennya untuk mengidentifikasikan masalah-masalah, dan hambatan-hambatan sehingga dapat diusulkan kebutuhan-kebutuhan untuk perbaikannya. Tahap analisis merupakan suatu tahap yang sangat penting dari sistem informasi yang akan dibangun, karena didalam tahapan ini akan terdapat bagian-bagian yang akan menjelaskan bagaimana sistem informasi penjadwalan kereta rel listrik ini dapat dibangun sesuai dengan kebutuhan yang ada, kebutuhan tersebut diperoleh melalui wawancara dan observasi yang dilakukan untuk mendapatkan beberapa data dan fakta yang akan dijadikan sebagai bahan penelitian. Bahan penelitian yang didapat akan dianalisis terlebih dahulu untuk pengembangan sebuah aplikasi penjadwalan KRL.

3.1.1 Prosedur Yang Terlibat

Prosedur dapat didefinisikan sebagai proses-proses didalam suatu sistem yang berkaitan satu dengan yang lainnya untuk mencapai suatu tujuan. Prosedur yang terlibat saat ini di PT.KA untuk melakukan penjadwalan dibagi menjadi 2 bagian prosedur yaitu prosedur penggunaan KRL dan prosedur penjadwalan KRL.

Kedua prosedut tersebut akan dijelaskan sebagai berikut : a. Prosedur Penggunaan KRL

Prosedur Penggunaan KRL adalah prosedur yang didalamnya terdapat proses untuk melakukan pemesanan pengadaan KRL hingga untuk melakukan pemesanan penggunaan KRL dengan melakukan pengisian formulir untuk pemesanan maupun formulir penggunaan KRL, prosedur penggunaan KRL dapat dilihat padaflowmap penggunaan KRL gambar 3.1. Proses-proses yang dilakukan pada prosedur penggunaan KRL sebagai berikut :

1. Bagian pemeliharaan akan mengisi terlebih dahulu formulir pengadaan KRL yang akan diberikan kepada bagian logistik.

2. Formulir pengadaan yang telah ada pada bagian logistik akan diperiksa terlebih dahulu secara manual apakah barang dari isi formulir pengadaan KRL tersedia digudang milik PT.KAI atau tidak jika formulir pengadaan KRL sesuai dengan barang yang ada digudang maka bagian logistik akan mengesahkan formulir pengadaan KRL jika tidak formulir pengadaan KRL akan dikembalikan kepada pemeliharaan.

3. Formulir pengadaan KRL yang telah disahkan akan diinputkan kedalam komputer menggunakan alat bantu aplikasi Microsoft Exel dengan diberi nama file siloka.exe setelah isi didalam formulir dimasukan, formulir akan dikembalikan kepada pemeliharaan.

4. Formulir pengadaan KRL yang telah disahkan akan dicatat terlebih dahulu oleh pemeliharaan kedalam buku pengadaan KRL, setelah dicatat formulir akan diberikan kepada KROP.

5. Formulir pengadaan KRL yang telah ada akan dicatat bersama daftar kebutuhaan penggunaan KRL Yang akan dibentuk menjadi dokumen penggunaan KRL

6. Formulir pengadaan KRL dan daftar kebutuhan penggunaan KRL yang telah dicatat akan dijadikan arsip dengan nama arsip pengadaan KRL dan arsip daftar kebutuhan penggunaan KRL

7. Dokumen penggunaan KRL yang telah tersusun akan diberikan kembali kepada bagian pemeliharaan untuk dilakukan pengecekan apakah isi dari dokumen sesuai atau tidak jika isi dokumen tidak sesuai dengan buku pengadaan KRL maka dokumen akan dikembalikan kepda KROP untuk dilakukan pengoreksiaan setelah dokumen dikoreksi maka dokumen akan didirim kembali kepada pemeliharaan untuk dilakukan pengecekan kembali 8. Dokumen yang sesuia datanya akan diinputkan dulu kedalam komputer dengan menggunakan aplikasi Microsoft Exel dengan nama file Siper-KRL.exe setelah itu dokumen dikembalikan kepda KROP lalu diarsipkan dengan nama arsip penggunaan KRL.

. .

Pemeliharaan Kepala Ruas Operasional (KROP)

Keterangan : A1 = Arsip Penggadaan KRL A2 = Arsip Daftar Kebutuhaan Penggunaan KRL A3 = Arsip Penggunaan KRL

Ya Formulir Pengadaan KRL Tidak Logistik Formulir Pengadaan KRL Pemeriksaan Formulir Pengadaan KRL Formulir Pengadaan KRL Yang Tersedia Tersedia? Formulir Pengadaan KRL Yang Tidak

Tersedia

Formulir Pengadaan KRL Yang Tidak

Tersedia

Input Data Penggadaan KRL Simpan Data Penggadaan KRL Yang Tersedia Dan

Telah Disahkan

Siloka.Xls

Formulir Pengadaan KRL Yang Tersedia Dan Telah Disahkan

Pencatatan Formulir Pengadaan KRL Yang Tersedia

Dan Telah Disahkan Buku Pengadaan

KRL

Pencatatan Data Pengadaan Dan Kebutuhan Penggunaan KRL

Dokumen Penggunaan KRL Yang Telah

Tersusun Pengecekan Dokumen

Penggunaan KRL Yang Telah Tersusun Sesuai? Dokumen Penggunaan KRL Yang Telah Tersusun Dan Sesuai Input Data Penggunaan KRL Simpan Data Penggunaan KRL Siper-KRL.Xls Dokumen Penggunaan KRL Yang Telah Tersusun Dan Sesuai Ya Tidak Kepala Stasiun Pengesahan Formulir Pengadaan KRL Yang

Tersedia

Formulir Pengadaan KRL Yang Tersedia Dan

Telah Disahkan

Formulir Pengadaan KRL Yang Tersedia Dan

Telah Disahkan

Formulir Pengadaan KRL Yang Tersedia Dan

Telah Disahkan Daftar Kebutuhan Penggunaan KRL Daftar Kebutuhan Penggunaan KRL Formulir Pengadaan KRL Yang Tersedia Dan

Telah Disahkan

Daftar Kebutuhan Penggunaan KRL

A1 A2 Dokumen Penggunaan

KRL Yang Telah Tersusun

Dokumen Penggunaan KRL

Yang Telah Tersusun Dan Tidak

Sesuai

Dokumen Penggunaan KRL Yang Telah Tersusun Dan Tidak Sesuai

Pengoreksian Dokumen Penggunaan KRL Yang Telah

Tersusun Dan Tidak Sesuai Dokumen Penggunaan KRL Yang

Telah Tersusun Dan Telah Dikoreksi Dokumen Penggunaan

KRL Yang Telah Tersusun Dan Sesuai

A3

b. Prosedur Penjadwalan KRL

Prosedur Penjadwalan KRL adalah prosedur yang akan dilakukan KROP untuk melakukan penjadwalan KRL dengan melakukan pembuatan penjadwalan dari daftar penggunaan KRL dan daftar petugas KRL yang diberikan oleh bagian administrasi, yang dapat dilihat pada flowmap

penjadwalan KRL gambar 3.2. Proses-proses yang dilakukan pada prosedur penjadwalan KRL sebagai berikut :

1. Arsip dokumen penggunaan KRL yang telah tersusun dan sesuai yang ada di KROP akan dicatat terlebih dahulu untuk mendapatkan daftar penggunaan KRL yang telah tersusun dan sesuai kemudian dokumen diarsipkan kembali menjadi arsip dokumen penggunaan KRL.

2. Daftar penggunaan KRL yang telah tersusun dan sesuai akan dibangun terlebih dahulu bersama daftar petugas KRL yang diberikan oleh bagian administrasi lalu akan diarsipkan kembali menjadi arsip penggunaan KRL dan arsip daftar petugas KRL

3. Dari pembangunan daftar penggunaan KRL dan daftar petugas KRL akan dilakukan pembentukan penjadwalan KRL jika pembentukan tidak sesuai maka akan dilakukan pembentukan penjadwalan KRL kembali, apabila pembentukan penjadwalan sesuai maka akan dilakukan penginputan data penjadwalan kedalam komputer dengan aplikasi bantuan Microsoft Exel

4. Setelah data berhasil dimasukan maka akan dilakukan pencetakan penjadwalan KRL.

5. Hasil print out penjadwlan KRL akan diduplikasikan terlebih dahulu dan dijadikan arsip oleh KROP dengan nama arsip print out penjadwalan KRL dan hasi dari penduplikasian print out tersebut akan dibagikan kepada bagian pemeliharaan dan bagian pegawai (Petugas KRL).

3.1.2 Analisis Kebutuhan Non Fungsional

Analisis kebutuhan non fungsional dilakukan untuk mengetahui spesifikasi kebutuhan untuk sistem yang akan dibangun. Spesifikasi kebutuhan melibatkan analisis perangkat keras/hardware, analisis perangkat lunak/software, analisis pengguna/user analisis jaringan dan analisis pengkodean.

3.1.2.1 Analisis Perangkat Keras/Hardware.

Pada bagian gedung admin regional JABODETABEK di ruangan KROP milik PT KAI saat ini terdapat komputer yang digunakan oleh KROP untuk melakukan penjadwalan KRL dengan spesifikasi sebagai berikut:

a. Processor : 2.4 Ghz b. Hardisk : 60 GB c. Memory : 512 MB d. VGA : 64 MB e. Monitor : 15’’ f. Mouse dan keyboard g. printer

Perangkat keras (Hardware) yang telah ada pada gedung admin regional JABODETABEK di ruangan KROP milik PT KAI saat ini, sudah cukup memenuhi standar kebutuhan minimum spesifikasi perangkat keras yang dibutuhkan untuk membangun sistem informasi penjadwalan KRL di PT KAI.

3.1.2.2 Analisis Perangkat Lunak/Software.

Perangkat lunak (software) yang digunakan di PT.KAI saat ini adalah sebagai berikut:

1. Sistem operasi :Microsoft Windows XP 2. Software lainnya :Microsoft Office 2003

3. Borland C++ Builder 6 sebagai implementasi perancangan sistem 4. Interbase 7.1 sebagai media penyimpanan (database).

Perangkat lunak yang akan dibangun akan mengikuti perangkat lunak yang dimiliki perusahaan PT KAI saat ini, sehingga untuk mengimplementasikan aplikasi penjadwalan KRL yang akan dibangun tidak akan terlalu mengalami kesulitan untuk menjalankannya.

3.1.2.3 Analisis Pengguna/User.

Karakteristik dari user yang ada saat ini yaitu berumur antara 35 sampai 45 tahun.User yang menggunakan aplikasi adalah kepala ruas operasional (KROP) yang memiliki jenjang pendidikan program diploma III.User sudah memiliki pengalaman dan mengenal dalam mengoperasikan komputer kecuali memahami program-program aplikasi, tetapi sudah cukup berpengalaman dalam mengoperasikan Sistem Operasi Windows, bekerja menggunakan Microsoft Office seperti Microsoft Office Word danMicrosoft Office Excel.

Perangkat lunak yang akan dibangun akan digunakan oleh kepala ruas operasional (KROP). Untuk lebih jelasnya tentang pengguna dapat dilihat pada tabel dibawah ini.

Tabel 3.1 Karakteristik Pengguna

Pengguna Tanggung

Jawab Hak Akses

Tingkat Pendidikan Tingkat Keterampilan Pengalaman Kepala Ruas Operasional (KROP) Mengatur penjadwalan dan membuat laporan operasional KRL Menambah, menghapus dan mengubah data Min. Diploma III Bisa mengikuti petunjuk yang ada pada sistem Min. mampu mengoperasikan komputer, menggunakan Microsoft word, Microsoft Excel

Dari penjelasan pada tabel 3.1, dapat diambil kesimpulan bahwa karakteristik

user yang telah ada saat ini sudah memenuhi kriteria untuk dapat menggunakan program aplikasi yang akan dibangun dan dapat disimpulkan bahwa kepala ruas operasional (KROP) dapat dijadikan sebagai seorang user dengan akses penuh. Hanya saja, dibutuhkan pengenalan dan pelatihan kepada kepala ruas operasional (KROP) untuk dapat mengoperasikan sistem penjadwalan KRL yang baru.

3.1.2.4 Analisis Jaringan

Jaringan yang ada pada saat ini pada gedung admin regional KROP JABODETABEK diruangan KROP milik PT KAI jaringan bersifat stand alone,

jaringan stand alone ini akan digunakan untuk membangun sisitem informasi penjadwalan kereta rel listrik (KRL) diruangan KROP

3.1.2.5 Analisis Pengkodean

Analisis pengkodean merupakan analisis dari kode-kode yang digunakan untuk mengklasifikasikan suatu data yang berhubungan dengan pengolahan sistem informasi penjadawalan kereta rel listrik (KRL) di PT.KAI, setelah dilakukan analisis terhadap prosedur pengkodean yang terdapat pada pengolahan pegawai di PT.KAI, yaitu:

1. Kode NIP pegawai 99999

Menerangkan nomor urut masuk pegawai Contoh : 46969

46969 : Menerangkan bahwa nomor urut pegawai yang masuk dengan nomor urut 46969

3.1.3 Analisis Basis Data

Dari hasil analisis, didapat data yang akan dipakai dalam proses pembangunan program aplikasi sistem informasi penjadwalan Kereta Rel Listrik (KRL). Kemudian dari data yang telah diperoleh, dibangun sebuah desain basis data dengan menggunakantools Entity Relational Diagram (ERD) pada gambar 3.3.

Terdapat istilah-istilah yang digunakan dalam penganalisisan basis data pada gambar 3.3 dibawah ini diantarannya terdapat entitas dengan pemberian nama stand formasi, fungsi dari entitas tersebut adalah untuk memudahkan membentuk formasi dari sebuah kereta rel listrik sesuai yang akan dibutuhkan dan istilah kedua yang akan digunakan dalam pembentukan Entity Relational Diagram (ERD) pada gambar 3.3 dibawah ini adalah istilah dinasan yang terdapat pada entitas dinasan yang memiliki fungsi untuk membentuk suatu keberangkatan kereta rel listrik yang akan dibutuhkan dalam penjadwalan.

3.1.4 Analisis Kebutuhan Fungsional

Analisis kebutuhan fungsional dilakukan untuk memberikan gambaran aliran data yang ada pada program aplikasi yang akan dibangun. Kebutuhan fungsional pada aplikasi sistem informasi penjadwalan Kereta Rel Listrik di PT KAI Bandung meliputi diagram konteks, data flow diagram, kamus data dan spesifikasi proses.

3.1.4.1 Diagram Konteks

Diagram konteks merupakan gambaran sistem secara umum yaitu hubungan sistem dengan lingkungan sistem. Terdapat entitas yang terhubung langsung dengan sistem yaitu entitas KROP. Gambar diagram konteks dapat dilihat pada gambar 3.4

3.1.4.2 Data Flow Diagram (DFD)

Data Flow Diagram (DFD) adalah diagram alir yang dipresentasikan dalam bentuk lambang-lambang tertentu yang menunjukan aliran data, proses, tempat penyimpanan data, dan entitas eksternal.

3.1.4.2.1`DFD Level 0

DFD Level 0 dilakukan untuk lebih memperinci diagram konteks yang telah dibuat pada gambar 3.5.

3.1.4.2.2 DFD Level 1

DFD Level 1 menggambarkan tiap-tiap proses level 0 secara lebih rinci. 3.1.4.2.2.1 DFD Level 1 Untuk Proses 2.0

Terdapat 3 proses untuk level 2 pada proses 2.0 pengolahan data pegawai yaitu proses 2.1 tambahan data pegawai, proses 2.2 cari data pegawai, proses 2.3 ubah data pegawai, proses 2.4 hapus data pegawai yang dapat dilihat pada gambar 3.6

3.1.4.2.2.2 DFD Level 1 Untuk Proses 3.0

Terdapat 6 proses untuk level 2 pada proses 3.0 pengolahan data user yaitu proses 3.1 Tambah data user, proses 3.2 Cari data user, proses 3.3 Ubah data user, yang dapat dilihat pada gambar 3.7

3.1.4.2.2.3 DFD Level 1 Untuk Proses 4.0

Terdapat 8 proses untuk level 1 pada proses 4.0 pengolahan data master yaitu 4.1 Pengolahan data stand_formasi, 4.2 Pengolahan data sarana, 4.3 Pengolahan data KRL, 4.4 Pengolahan data petugas KRL, 4.5 Pengolahan data stasiun, 4.6 Pengolahan data tujuan, 4.7 Pengolahan data tujuan, 4.8 Pengolahan data dinasan yang dapat dilihat pada gambar 3.8

3.1.4.2.2.4 DFD Level 1 Untuk Proses 5.0

Terdapat 5 proses untuk level 1 pada proses 5.0 Pengolahan penjadwalan yaitu 5.1 Pemasukan data Dinasan, 5.2 Pemasukan data tujuan, 5.3 Pemasukan data tujuan, 5.4 Pemasukan Data Waktu, 5.5 Penetapan Jadwal, yang dapat dilihat pada gambar 3.9

3.1.4.2.3 DFD Level 2

DFD Level 2 menggambarkan tiap-tiap proses level 1 secara lebih rinci. 3.1.4.2.3.1 DFD Level 2 Untuk Proses 4.1.

Terdapat 4 proses untuk level 2 pada proses 4.1. pengolahan data jenis yaitu proses 4.1.1 tambah data jenis, proses 4.1.2 cari data jenis, proses 4.1.3 ubah data jenis, 4.1.4 hapus data jenis yang dapat dilihat pada gambar 3.10

3.1.4.2.3.2 DFD Level 2 Untuk Proses 4.2.

Terdapat 4 proses untuk level 2 pada proses 4.2. pengolahan data stand formasi yaitu proses 4.2.1 tambah data stand formasi, proses 4.2.2 cari data stand formasi, proses 4.2.3 ubah data stand formasi, 4.2.4 hapus data stand formasi yang dapat dilihat pada gambar 3.11

3.1.4.2.3.3 DFD Level 2 Untuk Proses 4.3

Terdapat 4 proses untuk level 2 pada proses 4.3. pengolahan data sarana yaitu proses 4.3.1 tambah data sarana , proses 4.3.2 cari data sarana, proses 4.3.3 ubah data sarana, 4.3.4 hapus data sarana yang dapat dilihat pada gambar 3.12

3.1.4.2.3.4 DFD Level 2 Untuk Proses 4.4

Terdapat 4 proses untuk level 2 pada proses 4.4. pengolahan data KRL yaitu proses 4.4.1 tambah data KRL , proses 4.4.2 cari data KRL, proses 4.4.3 ubah data KRL, 4.4.4 hapus data KRL yang dapat dilihat pada gambar 3.13

3.1.4.2.3.5 DFD Level 2 Untuk Proses 4.5

Terdapat 4 proses untuk level 2 pada proses 4.5. pengolahan data Petugas KRL yaitu proses 4.5.1 tambah data petugas_KRL, proses 4.5.2 cari data petugas_KRL, proses 4.5.3 ubah data petugas_ KRL, 4.5.4 hapus data petugas_KRL yang dapat dilihat pada gambar 3.14

3.1.4.2.3.6 DFD Level 2 Untuk Proses 4.6

Terdapat 4 proses untuk level 2 pada proses 4.6. pengolahan data stasiun yaitu proses 4.6.1 tambah data stasiun, proses 4.6.2 cari stasiun, proses 4.6.3 ubah data stasiun, 4.6.4 hapus data stasiun yang dapat dilihat pada gambar 3.15

3.1.4.2.3.7 DFD Level 2 Untuk Proses 4.7

Terdapat 4 proses untuk level 2 pada proses 4.7. pengolahan data tujuan yaitu proses 4.7.1 tambah data tujuan , proses 4.7.2 cari tujuan, proses 4.7.3 ubah data tujuan, 4.7.4 hapus data tujuan yang dapat dilihat pada gambar 3.16

KROP 4.7.1. Tambah Data Tujuan 4.7.2. Cari Data Tujuan 4.7.3. Ubah Data Tujuan T_Tujuan Data Tujuan Stasiun Yang

Akan Ditambah

Data Tujuan Yang Akan Diubah

Data Tujuan Yang Akan Dihapus

Informasi Tujuan Yang Dihapus

Informasi Tujuan Yang Sudah Ditambah

DataTujuan Yang Akan Ditambah

Data Tujuan Yang Akan Diubah

Informasi Tujuan Yang Sudah Diubah

Data Tujuan Yang Akan Dihapus

Informasi TujuanYang Sudah Dihapus Validasi Login Berhasil

Validasi Login Berhasil

Validasi Login Berhasil

4.7.4. Hapus Data

Tujuan

Validasi Login Berhasil Data Tujuan Yang akan

Dicari Informasi Tujuan Yang

Dicari tidak ada

Data Tujuan Yang Akan Dicari

Informasi TujuanYang Sudah Dicari Informasi Tujuan gagal disimpan

Data TujuanYang Dicari Data Tujuan

Data Tujuan Yang Dicari

DataTujuan Informasi Tujuan gagal disimpan

T_Stasiun Data Stasiun

Data Stasiun

3.1.4.2.3.8 DFD Level 2 Untuk Proses 4.8

Terdapat 4 proses untuk level 2 pada proses 4.8. pengolahan data type yaitu proses 4.8.1 tambah data type, proses 4.8.2 cari type, proses 4.8.3 ubah data type 4.8.4 hapus data type yang dapat dilihat pada gambar 3.17

3.1.4.2.3.9 DFD Level 2 Untuk Proses 4.9

Terdapat 4 proses untuk level 2 pada proses 4.9. pengolahan data dinasan yaitu proses 4.9.1 tambah data dinasan, proses 4.9.2 cari dinasan, proses 4.9.3 ubah data dinasan 4.9.4 hapus data dinasan yang dapat dilihat pada gambar 3.18

3.1.4.2.3.10 DFD Level 3 Untuk Proses 5.5

Terdapat 3 proses untuk level 3 pada proses penetapan penjadwalan yaitu proses 5.5.1. proses pembuatan populasi awal, proses 5.5.2 proses menghitung nilai fitness yang dapat dilihat pada gambar 3.19

Gambar 3.19 DFD level 3 untuk proses 5.5 Penetapan penjadwalan

3.1.4.3 Spesifikasi Proses

Spesifikasi proses digunakan untuk menggambarkan semua proses model aliran data yang disajikan pada diagram aliran data. Spesifikasi proses yang terdapat pada Data Flow Diagram dapat dilihat pada tabel 3.2.

Tabel 3.2 Spesifikasi Proses

No. Proses Keterangan

1 No. Proses 1.0

Nama Proses Login

Source (Sumber) User

Input Data Login User

Data Master KRL Destination (Tujuan) User

Logika Proses Begin

{User Memasukkan Nama Dan Password pengun} IF nama_user ada

and password ada

then tampil menu aplikasi

else tampil pesan ‘nama_user dan password salah’

End IF End

2 No. Proses 2.0

Nama Proses Pengolahan Data Pegawai

Source(Sumber) User

Input Data Pegawai yang ditambah, dicari, diubah,

dihapus

Output Informasi data pegawai gagal disimpan, data dicaro tidak ada

Destination(Tujuan) User Logika Proses Begin

{User Melakukan Pengolahan Data User } End

3 No. Proses 2.1.

Nama Proses Tambah Data Pegawai

Source(Sumber) User

Input Data Pegawai Yang Akan Ditambah

Output Informasi Pegawai Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Pegawai Yang Akan Ditambah}

IF Data Pegawai Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data Pegawai Yang Disimpan End IF

End

4 No. Proses 2.2.

Nama Proses Cari Data Pegawai

Source(Sumber) User

Input Data PegawaiYang akan Dicari

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Pegawai Yang Akan Dicari}

IF Data Pegawai yang dicari tidak ditemukan Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data Pegawai yang dicari

End IF End

5 No. Proses 2.3

Nama Proses Ubah Data Pegawai

Source(Sumber) User

Input Data Pegawai yang Akan Diubah

Output Informasi Pegawai Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Pegawai Yang Akan Diubah}

IF Data Pegawai Yang Dicari Untuk Diubah Then Tampil Data Pegawai Yang Akan Diubah Else IF Data Pegawai Diubah

Then Tampil Data Pegawai Yang disimpan Else Tampil Pesan ‘Data Gagal Disimpan’ End IF

End IF End

6 No. Proses 2.4

Nama Proses Hapus Petugas Pegawai

Source(Sumber) User

Input Data Pegawai Yang Akan Dihapus

Output Informasi Pegawai Yang Dihapus

Destination(Tujuan) User Logika Proses Begin

{User memasukkan data Pegawai yang dihapus } IF data Pegawai yang dicari untuk dihapus Then tampil data Pegawai yang akan dihapus IF data Pegawai dihapus

Then tampil pesan ‘Data Pegawai berhasil dihapus dan data Pegawai dihapus’

Else data tidak terhapus End IF

End

7 No. Proses 3.0

Nama Proses Pengolahan Data User

Source(Sumber) User

Input Data User Yang Akan Ditambah, Dicari Dan

Diubah

Output Informasi User yang gagal disimpan, dicari tidak ada

Destination(Tujuan) User Logika Proses Begin

{User Melakukan Pengolahan Data User } End

8 No. Proses 3.1.

Nama Proses Tambah Data User

Source(Sumber) User

Input Data User Yang Akan Ditambah

Output Informasi User Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data User Yang Akan Ditambah}

IF Data User Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else

Tampil Data User Yang Disimpan End IF

End

9 No. Proses 3.2

Nama Proses Cari Data User

Source(Sumber) User

Input Data User Yang Akan Dicari

Output Informasi UserYang Dicari Tidak Ada

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data User Yang Akan Dicari} IF Data User yang dicari tidak ditemukan

Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data User yang dicari

End IF End

Nama Proses Ubah Data User

Source(Sumber) User

Input Data User Yang Akan Diubah

Output Informasi User Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data User Yang Akan Diubah} IF Data User Yang Dicari Untuk Diubah

Then Tampil Data User Yang Akan Diubah Else if Data User Diubah

Then Tampil Data User Yang disimpan Else Tampil Pesan ‘Data Gagal Disimpan’ End IF

End IF End

11 No. Proses 4.0

Nama Proses Pengolahan Data Master

Source(Sumber) User

Input Data Jenis Yang Akan Ditambah, Diubah, Dihapus

Dan Dicari

Data Stand Formasi Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Sarana Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data KRL Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Petugas KRL Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Stasiun Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Tujuan Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Type Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Data Dinasan Yang Akan Ditambah, Diubah, Dihapus Dan Dicari

Output Informasi Jenis yang gagal disimpan, dicari tidak ada, dihapus

Informasi Stand formasi yang gagal disimpan, dicari tidak ada, dihapus

12 No. Proses 4.1

Nama Proses Pengolahan Data Jenis

Source(Sumber) User

Input Data Jenis Yang Akan Ditambah, Diubah, Dihapus

Dan Dicari

Output Informasi Jenis Gagal Disimpan

Informasi Jenis Yang Dicari Tidak Ada Informasi Jenis Dihapus

Destination(Tujuan) User

Logika Proses Begin

{User Mengolah Data Jenis } End

ada, dihapus

informasi KRL gagal disimpan, dicari tidak ada, dihapus

informasi Petugas KRLgagal disimpan, dicari tidak ada, dihapus

Informasi Stasiun gagal disimpan, dicari tidak ada, dihapus

Informasi Tujuan gagal disimpan, dicari tidak ada, dihapus

Informasi Type gagal disimpan, dicari tidak ada, dihapus

Informasi Type gagal disimpan, dicari tidak ada, dihapus

Destination(Tujuan) User Logika Proses Begin

{User Mengolah Data Master} End

13 No. Proses 4.1.1.

Nama Proses Tambah Data Jenis

Source(Sumber) User

Input Data Jenis Yang Akan Ditambah

Output Informasi Jenis Gagal Disimpan

14 No. Proses 4.1.2.

Nama Proses Cari Data Jenis

Source(Sumber) User

Input Data Jenis Yang akan Dicari

Output Informasi Jenis Yang Dicari Tidak Ada

Destination(Tujuan) User

Logika Proses Begin

{User Memasukan Data Jenis Yang Akan Dicari} IF Data Jenis yang dicari tidak ditemukan

Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data Jenis yang dicari

End IF End

15 No. Proses 4.1.3

Nama Proses Ubah Jenis

Source(Sumber) User

Input Data Jenis yang Akan Diubah

Output Informasi Jenis Gagal Disimpan

Destination(Tujuan) User

Logika Proses Begin

{User Memasukan Data Jenis Yang Akan Diubah} IF Data Jenis Yang Dicari Untuk Diubah

Then Tampil Data Jenis Yang Akan Diubah Else IF Data Jenis Diubah

Then Tampil Data Jenis Yang disimpan Else Tampil Pesan ‘Data Gagal Disimpan’ End IF

End IF End

16 No. Proses 4.1.4

Nama Proses Hapus Data Jenis

Source(Sumber) User

Input Data Jenis Yang Akan Dihapus

Logika Proses Begin

{User Memasukan Data Jenis Yang Akan Ditambah}

IF Data Jenis Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data Jenis Yang Disimpan End IF

Output Informasi Jenis Yang Dihapus

Destination(Tujuan) User

Logika Proses Begin

{User memasukkan data Jenis yang dihapus } IF data Jenis yang dicari untuk dihapus then tampil data Jenis yang akan dihapus IF data Jenis dihapus

then tampil pesan ‘Data Jenis berhasil dihapus dan data Jenis dihapus’

else data tidak terhapus End IF

End IF End

17 No. Proses 4.2.

Nama Proses Pengolahan Data Stand Formasi

Source(Sumber) User

Input Data Stand Formasi Yang Akan Ditambah, Diubah,

Dihapus Dan Dicari

Output Informasi Stand Formasi Gagal Disimpan

Informasi Stand Formasi Yang Dicari Tidak Ada Informasi Stand Formasi Dihapus

Destination(Tujuan) User

Logika Proses Begin

{User Mengolah Data Stand Formasi } End

18 No. Proses 4.2.1.

Nama Proses Tambah Data Stand Formasi

Source(Sumber) User

Input Data Stand Formasi Yang Akan Ditambah

Output Informasi Stand Formasi Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Stand Formasi Yang Akan Ditambah}

IF Data Sarana Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data Stand Formasi Yang Disimpan End IF

End

Nama Proses Cari Data Stand Formasi

Source(Sumber) User

Input Data Stand Formasi Yang akan Dicari

Output Informasi Stand Formasi Yang Dicari Tidak Ada

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Stand Formasi Yang Akan Dicari}

IF Data Stand Formasi yang dicari tidak ditemukan

Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data Stand Formasi yang dicari End IF

End

20 No. Proses 4.2.3

Nama Proses Ubah Stand Formasi

Source(Sumber) User

Input Data Stand Formasi yang Akan Diubah

Output Informasi Stand Formasi Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Stand Formasi Yang Akan Diubah}

IF Data Stand Formasi Yang Dicari Untuk Diubah

Then Tampil Data Stand Formasi Yang Akan Diubah

Else IF Data Stand Formasi Diubah

Then Tampil Data Stand Formasi Yang disimpan

Else Tampil Pesan ‘Data Gagal Disimpan’ End IF

End IF End

21 No. Proses 4.2.4

Nama Proses Hapus Data Stand Formasi

Source(Sumber) User

Input Data Stand Formasi Yang Akan Dihapus

Output Informasi Stand Formasi Yang Dihapus

Destination(Tujuan) User Logika Proses Begin

{User memasukkan data sarana yang dihapus } IF data Stand Formasi yang dicari untuk dihapus

then tampil data Stand Formasi yang akan dihapus

IF data Stand Formasi dihapus

then tampil pesan ‘Data Stand Formasi berhasil dihapus dan data Stand Formasi dihapus’ else data tidak terhapus

End IF End IF End

22 No. Proses 4.3.

Nama Proses Pengolahan Data Sarana

Source(Sumber) User

Input Data Sarana Yang Akan Ditambah, Diubah,

Dihapus Dan Dicari

Output Informasi Sarana Gagal Disimpan

Informasi Sarana Yang Dicari Tidak Ada Informasi Sarana Dihapus

Destination(Tujuan) User Logika Proses Begin

{User Mengolah Data Sarana } End

23 No. Proses 4.3.1.

Nama Proses Tambah Data Sarana

Source(Sumber) User

Input Data Sarana Yang Akan Ditambah

Output Informasi Sarana Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Sarana Yang Akan Ditambah}

IF Data Sarana Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data Sarana Yang Disimpan End IF

End

24 No. Proses 4.3.2.

Nama Proses Cari Data Sarana

Input Data Sarana Yang akan Dicari

Output Informasi Sarana Yang Dicari Tidak Ada

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data sarana Yang Akan Dicari} IF Data Sarana yang dicari tidak ditemukan

Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data sarana yang dicari

End IF End

25 No. Proses 4.3.3

Nama Proses Ubah Data Sarana

Source(Sumber) User

Input Data Sarana yang Akan Diubah

Output Informasi Sarana Gagal Disimpan

Destination(Tujuan) User Logika Proses Begin

{User Memasukan Data Sarana Yang Akan Diubah}

IF Data Sarana Yang Dicari Untuk Diubah Then Tampil Data Sarana Yang Akan Diubah Else IF Data Sarana Diubah

Then Tampil Data Sarana Yang disimpan Else Tampil Pesan ‘Data Gagal Disimpan’ End IF

End IF End

26 No. Proses 4.3.4

Nama Proses Hapus Data Sarana

Source(Sumber) User

Input Data Sarana Yang Akan Dihapus

Output Informasi Sarana Yang Dihapus

Destination(Tujuan) User Logika Proses Begin

{User memasukkan data sarana yang dihapus } IF data sarana yang dicari untuk dihapus then tampil data sarana yang akan dihapus IF data sarana dihapus

then tampil pesan ‘Data sarana berhasil dihapus dan data sarana dihapus’

else data tidak terhapus End IF

203

5. Kurang Menyenangkan -

-6. Tidak Menyenangkan -

-7. Sangat tidak Menyenangkan

-

-Berdasarkan hasil prosentase dapat disimpulkan bahwa pengguna menyatakan bahwa tampilan aplikasi ini cukup menyenangkan

4.2.5 Kesimpulan Hasil Pengujian Betha

Berdasarkan hasil prosentase diatas yang didapat dari pengujian betha, maka dapat disimpulkan sistem informasi yang dibangun sudah sesuai dengan tujuannya yaitu antarmuka menjadi lebih Sesuai, lebih Mudah digunakan dan lebih terstruktur.

204

BAB V

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Berdasarkan penelitian yang dilakukan oleh penyusun mengenai perancangan dan implementasi sistem informasi penjadwalan KRL, maka dapat ditarik beberapa kesimpulan sebagai berikut :

1. Sistem Iinformasi Penjadwalan KRL dapat Memudahkan dalam menjadwakan Kereta Rel Listrik (KRL).

2. Memudahkan dalam membuat laporan operasional kereta rel listrik (KRL).

5.2 Saran

Untuk lebih meningkatkan kinerja dari sistem informasi penjadwalan KRL ini penulis mengusulkan beberapa saran yang dapat dijadikan pertimbangan, yaitu:

1. sistem informasi Penjadwalan KRL ini dapat dikembangkan lebeih lanjut, sehingga informasi yang disajikan dapat lebih jelas, lebih lengkap, serta lebih banyak, agar menjadi satu sistem informasi yang dapat menyajikan informasi secara lengkap..

DAFTAR RIWAYAT HIDUP

Nama : Harkat Wijaya

Tempat Tanggal Lahir : Cilegon, 21 April 1987 Jenis Kelamin : Laki-laki

Kewarganegaraan : Indonesia

Agama : Islam

Nama Orangtua

Ayah : Taryana Kina

Ibu : Diah Lestari

Tinggi Badan : 174 cm Berat Badan : 58 kg

Alamat : Desa Karang malang Blok Puhun dusun 3 kec. Karangsembung Cirebon

Pendidikan :

1. Tahun 1993, Lulus Taman Kanak-kanak (TK) 1Cilegon. 2. Tahun 1999, Lulus SD 4 KS Cilegon.

3. Tahun 2002, Lulus SLTP KS cilegon. 4. Tahun 2005, Lulus SMA Negeri 2 Cilegon.

5. Tahun 2005, Terdaftar sebagai mahasiswa S1 Fakultas Teknik dan Ilmu Komputer Jurusan Teknik Informatika Universitas Komputer Indonesia Bandung.

LEMBAR PENGESAHAN

SISTEM INFORMASI PENJADWALAN KERETA REL LISTRIK (KRL)

HARKAT WIJAYA 10105082

Pembimbing

Tati Harihayati M., S.T.M.T. NIP. 41277006006

Menyetujui,

Ketua Jurusan Teknik Informatika

Mira Kania Sabariah, S.T., M.T. NIP. 4127700608

LEMBAR PENGESAHAN

SISTEM INFORMASI PENJADWALAN KERETA REL LISTRIK (KRL)

HARKAT WIJAYA 10105082

Penguji I

Dian Dharmayanti, S.T. NIP. 41277006005

Penguji II

Tati Harihayati M.,S.T.M.T. NIP. 41277006006

Penguji III

Andri Heryandi, S.T. NIP. 41277006007

Bandung, Agustus 2009

Perihal: Plagiat Tugas Akhir

Saya yang bertanda tangan di bawah ini:

Nama : Harkat Wijaya Nim : 10105082

Judul Tugas Akhir : Sistem Informasi Penjadwalan Kereta Rel Listrik (KRL).

Menyatakan bahwa saya tidak melakukan tindakan meniru, menyalin atau menjiplak tugas akhir/karya ilmiah yang telah ada secara keseluruhan. Apabila saya terbukti melakukan kegiatan tersebut, maka saya bersedia untuk menerima sanksi yang diberikan sesuai dengan ketentuan yang ditetapkan dan berlaku di Jurusan Teknik Informatika Universitas Komputer Indonesia.

Mengetahui, Yang memberi pernyataan