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.
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.
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
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)
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 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
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.
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
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
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
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
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.
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.
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
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.
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
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
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
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 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.
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.
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
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
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.
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
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
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
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.
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.
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.
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
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.
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 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 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 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
4. Setelah data berhasil dimasukan maka akan dilakukan pencetakan penjadwalan 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
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.
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 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 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
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
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
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 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
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
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
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
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
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
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
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}
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
{User memasukkan data sarana yang dihapus } 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.
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
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’
End IF End
27 No. Proses 4.4.
Nama Proses Pengolahan Data KRL Source(Sumber) User
Input Data KRL Yang Akan Ditambah, Diubah, Dihapus Dan Dicari
Output Informasi KRL Gagal Disimpan
Informasi KRL Yang Dicari Tidak Ada Informasi KRL Dihapus
Destination(Tujuan) User Logika Proses Begin
{User Mengolah Data KRL } End
28 No. Proses 4.4.1.
Nama Proses Tambah Data KRL Source(Sumber) User
Input Data KRL Yang Akan Ditambah Output Informasi KRL Gagal Disimpan Destination(Tujuan) User
Logika Proses Begin
{User Memasukan Data KRL Yang Akan Ditambah}
IF Data KRL Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data KRL Yang Disimpan End IF
End IF 29 No. Proses 4.4.2.
Nama Proses Cari Data KRL Source(Sumber) User
Input Data KRL Yang akan Dicari
Output Informasi KRL Yang Dicari Tidak Ada Destination(Tujuan) User
Logika Proses Begin
{User Memasukan Data KRL Yang Akan Dicari} IF Data KRL yang dicari tidak ditemukan
Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data KRL yang dicari
30 No. Proses 4.4.3
Nama Proses Ubah Data KRL Source(Sumber) User
Input Data KRL yang Akan Diubah Output Informasi KRL Gagal Disimpan Destination(Tujuan) User
Logika Proses Begin
{User Memasukan Data KRL Yang Akan Diubah} IF Data KRL Yang Dicari Untuk Diubah
Nama Proses Hapus Data KRL Source(Sumber) User
Input Data KRL Yang Akan Dihapus Output Informasi KRL Yang Dihapus Destination(Tujuan) User
Logika Proses Begin
{User memasukkan data KRL yang dihapus } IF data KRL yang dicari untuk dihapus then tampil data KRL yang akan dihapus IF data KRL dihapus
Then tampil pesan ‘Data KRL berhasil dihapus dan data KRL dihapus’
Else data tidak terhapus End IF
End IF End
32 No. Proses 4.5
Nama Proses Pengolahan Data Petugas KRL Source(Sumber) User
Input Data Petugas KRL Yang Akan Ditambah, Diubah, Dihapus Dan Dicari
Output Informasi Petugas KRL Gagal Disimpan
Destination(Tujuan) User Logika Proses Begin
{User Mengolah Data Petugas KRL } End
33 No. Proses 4.5.1.
Nama Proses Tambah Data Petugas KRL Source(Sumber) User
Input Data Petugas KRL Yang Akan Ditambah Output Informasi Petugas KRL Gagal Disimpan Destination(Tujuan) User
Logika Proses Begin
{User Memasukan Data Petugas KRL Yang Akan Ditambah}
IF Data Petugas KRL Ditambah gagal disimpan Then Tampilan Pesan ‘Data Gagal Disimpan’ Else Tampil Data Petugas KRL Yang Disimpan End IF
End 34 No. Proses 4.5.2.
Nama Proses Cari Data Petugas KRL Source(Sumber) User
Input Data Petugas KRL Yang akan Dicari
Output Informasi Petugas KRL Yang Dicari Tidak Ada Destination(Tujuan) User
Logika Proses Begin
{User Memasukan Data Petugas KRL Yang Akan Dicari}
IF Data Petugas KRL yang dicari tidak ditemukan Then Tampil Pesan ‘Data yang dicari tidak ada’ Else tampil data Petugas KRL yang dicari End IF
End 35 No. Proses 4.5.3
Nama Proses Ubah Data Petugas KRL Source(Sumber) User
Input Data Petugas KRL yang Akan Diubah Output Informasi Petugas KRL Gagal Disimpan Destination(Tujuan) User
Logika Proses Begin
