1. ANALISIS PEMBANGKITAN JADWAL PERKULIAHAN DENGAN DISCRETE PARTICLE SWARM OPTIMIZATION.

(1)

BAB V KESIMPULAN DAN SARAN

1. Metode DPSO telah berhasil dieksplorasi dengan membuat prototipe yang menciptakan jadwal kuliah, dimana pemenuhan kendala lemah (soft

constraints) dicapai dalan level tertentu. Sedangkan kendala tegas (hard

constraints) dijamin dipenuhi.

2. Metode DPSO telah dapat digunakan dalam pembuatan timetable perkuliahan.

Berdasarkan hasil eksekusi prototipe, jumlah partikel dan epoch

mempengaruhi waktu dan kualitas dari hasil generate jadwal. Dari 44 kendala

dosen tipe satu, 23 kendala dosen tipe dua dan satu kendala mahasiswa,

sejumlah kendala di antaranya terpenuhi. Pemenuhan kendala lemah ini

dipengaruhi oleh jumlah epoch dan partikel. Pada pengujian dengan 100 epoch

dan 100 partikel, 96% kendala dosen tipe satu terpenuhi, 43% kendala dosen

(2)

DAFTAR PUSTAKA

1. Afaq, Hifza., Saini, Sanjay., On the Solutions to the Travelling Salesman Problem using Nature Inspired Computing Techniques, India, IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 4, No 2, July 2011.

2. Altay, Ayca., Kayakutlu, Gulgun., 2011, Animal Food Chain Based Particle Swarm Optimization, London U.K, Proceedings of the World Congress on Engineering 2011 Vol II WCE 2011, July 6 – 8.

3. Chen, Yin-Yann., 2010, A Production Planning Problem Solved by the Particle Swarm Optimization, Hong Kong, Proceedings of the International MultiConference of Engineers and Computer Scientists 2010 Vol III, IMECS 2010.

4. Chu, Shu-Chuan., Chen, Yi-Tin., Ho, Jiun-Huei., 2006, Timetable Scheduling Using Particle Swarm Optimization, Taiwan, First International Conference on Innovative Computing, Information and Control.

5. Devi, Suprava ., Panigrahi, Sunil Kumar., 2011, Intelligent Decision Making Using Particle Swarm Optimization for Optimizing Product-Mix Model, India, International Journal of Computer Science & Informatics, Volume-1, Issue-1.

6. Fan, Huilian., 2010, Discrete Particle Swarm Optimization for TSP based on neightborhood, Journal of Computational Information System 6:10.

7. Gani, Taufiq Abdul ., Khader, Ahamad Tajudin., Budiarto, Rahmat., 2004, Optimizing Examination Timetabling using a Hybrid Evolution Strategies, Malaysia, 2nd International Conference and Autonomous Robots and Agents.

8. Hsieh, Ling-Feng., Huang, Chao-Jung., Huang, Chien-Lin., 2007, Applying Particle Swarm Optimization to Schedule Order Picking Routes, in a Distribution Centre, Taiwan, Asian Journal of Management and Humanity Science, Vol. 1, No. 4, pp. 558-576.

9. Huang, Jui-Ching., Wu, Shan-Ying., Pan, Wen-Tsao., 2011, Using particle swarm optimization (PSO) to perform financial characteristic study for enterprises in Taiwan, China, African Journal of Business Management Vol. 5(30), pp. 12040-12049.

10. Kanthavel, K., Prasad, P.S.S., Vignesh K.P., 2012, A Study of Sweep Algorithm Based Candidate List Performance in Capacitated Vehicle Routing Problem using Nested Particle Swarm Optimization, European Journal of Scientific Research.

11. Kiruthiga G., Senthilkumar M., 2011, A Survey about Dynamic Tasks Scheduling in Heterogeneous Processors Using Hybrid Particle Swarm Optimization, India, IJCSt Vol. 2, ISSue 3.

(3)

62

13. Kumar, Kuldeep., Sikander., Sharma, Ramesh., Mehta, Kaushal., 2012, Genetic Algorithm Approach to Automate University Timetable, International Journal of Technical Research.

14. Montero, Elizabeth ., Riff, Mar´ıa-Cristina., Altamirano, Leopoldo., 2011, A PSO Algorithm to Solve a Real Course+Exam Timetabling Problem, France, International Conference on Swarm Intelligence.

15. Mozafaria, Marzieh., Tafazzolia, Sajedeh., Jolaib, Fariborz., 2011, A new IPSO-SA approach for cardinality constrained portfolio optimization, Iran, International Journal of Industrial Engineering Computations, 2 249–262. 16. Mushi, A.R., 2006, Tabu Search Heutristic_{for University Course Time}

Tabling Problem, African Journal of Science and Technology, Science and Engineering series Vol. 7, No. 1, pp. 34-40.

17. Niasar, N. Salmani., Shanbezade, J., Perdam, M. M., Mohajeri M., 2009, Discrete Fuzzy Particle Swarm Optimization for Solving Traveling Salesman Problem, IEEE, International Conference on Information and Financial Engineering.

18. Norberciak, Maciej., 2006, Universal Method for Timetable based on Evolutionary Approach, Polandia, International Journal of Applied Mathematics and Computer Science Volume 3 Number 3.

19. Pang, W., Wang, Kang-ping, Zhou Chun-guang, Dong, Long-jiang, 2004, Fuzzy Discrete Particle Swarm Optimization for Solving Traveling Salesman Problem, IEEE, Proceedings of the Fourth International Conference on Computer and Information Technology (CIT’04).

20. Park, Jong-Bae ., Lee, Ki-Song., Shin, Joong-Rin., Lee, Kwang Y., 2005, A Particle Swarm Optimization for Economic Dispatch With Nonsmooth Cost Functions, IEEE Transaction on Power Systems, VOL. 20, NO. 1.

21. Rawat, Sandeep Singh., Rajamani, Lakshmi.,., 2005-2010, A Timetable Prediction for Technical Educational System Using Genetic Algorithm, India, Journal of Theoritical and Applied Information Technology.

22. Shahzad, Waseem., Khan, Farrukh Aslam., and Siddiqui, Abdul Basit., 2010, Weighted Clustering using Comprehensive Learning Particle Swarm Optimization for Mobile Ad Hoc Networks, Pakistan, International Journal of Future Generation Communication and Networking Vol. 3, No. 1. 23. Shi, X.H., Liang, Y.C., Lee, H.P., Lu, C., Wang, Q.X., 2007, Particle swarm

optimization-based algorithms for TSP and generalized TSP, Singapore, Elsevier.

24. Sun, Jingjing., Lei, Xiujuan., 2009, Geese-inspired Hybrid Particle Swarm Optimization Algorithm for Traveling Salesman Problem, IEEE, International Conference on Artificial Intelligence and Computational Intelligence.

25. Tariq, M.P., Mirza, M.Waqar, Akbar, R., 2010, Multi-agent Based University Time Table Scheduling System (MUTSS), International Journal of Multidiciplinery Science and Engineering, Vol 1, No 1,

(4)

63

27. Venkatesan, S.R., Logendran, D., Chandramohan, D., 2011, Optimization of Capacitated Vehicle Routing Problem using PSO, India, IJEST International Journal of Engineering Science Issues , Vol 8, Issue 4, No 2.

28. Wahyu Triadi Gunawan, 2010, Optimasi Penjadwalan Mata Kuliah dengan Metode Particle Swam Optimization, Skripsi Mahasiswa UAJY 05-07-04492.

29. Xue-Fei, H., Yun-xia, L., 2008, Optimization of Operational Route in AS/RS Based on Particle Swarm Algorithm, China, Journal of Southwest Jiaolong University.

30. Zhang, Jiang-wei., Xiong, Wei., 2008, An Improved Particle Swarm Optimization Algorithm and its Application for Solving Travelling Salesman Problem, IEEE, World Congress on Computer Science and Information Engineering.

(5)

(6)

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

SISTEM PENGATURAN JADWAL KULIAH

Untuk :

Universitas Atma Jaya Yogyakarta

Dipersiapkan oleh:

Rochim Widaryanto/ 105301536

Program Studi Magister Teknik Informatika

Universitas Atma Jaya Yogyakarta

Nomor Dokumen Halaman

SKPL

-SPJK

1/55

Program Studi Magister Teknik Informatika

Revisi 2013

(7)

DAFTAR PERUBAHAN

Revisi Deskripsi

A

B

C

D

E

F

INDEX TGL

- A B C D E F G

Ditulis oleh

Diperik sa oleh

(8)

Daftar Halaman Perubahan

(9)

Daftar Isi

1 Pendahuluan... 7

1.1 Tujuan... 7

1.2 Lingkup Masalah... 7

1.3 Definisi, Akronim dan Singkatan... 7

1.4 Referensi... 8

1.5 Deskripsi umum (Overview)... 8

2 Deskripsi Kebutuhan... 9

2.1 Perspektif produk... 9

2.2 Kebutuhan Fungsionalitas Produk... 10

2.3 Karakteristik Pengguna... 17

2.4 Batasan-batasan... 17

2.5 Asumsi dan Ketergantungan... 18

3 Kebutuhan khusus... 18

3.1 Kebutuhan antarmuka eksternal... 18

3.1.1 Antarmuka pemakai... 18

3.1.2 Antarmuka perangkat keras... 18

3.1.3 Antarmuka perangkat lunak... 18

3.2 Kebutuhan fungsionalitas Perangkat Lunak... 20

3.2.1 Use Case Diagram... 20

4 Spesifikasi Rinci Kebutuhan... 20

4.1 Spesifikasi Kebutuhan Fungsionalitas... 20

4.1.1 Use case Spesification : login... 20

4.1.2 Use case Spesification : generateJadwal... 20

4.1.3 Use case Spesification : manageDosen... 20

4.1.4 Use case Spesification : manageKendalaDosen... 20

4.1.5 Use case Spesification : manageKelasMataKuliah... 20

4.1.6 Use case Spesification : manageKendalaMahasiswa... 20

4.1.7 Use case Spesification : manageMataKuliah... 20

4.1.8 Use case Spesification : manageRefSesi... 20

4.1.9 Use case Spesification : manageRefRuang... 20

4.1.10Use case Spesification : manageRefHari... 20

4.1.11Use case Spesification : manageRefKelas... 20

(10)

4.1.13Use case Spesification : manageUser... 20

(11)

Daftar Gambar

1. Arsitektur Perangkat Lunak SPJK ………10

2. Use Case Diagram ………20

(12)

1 Pendahuluan

1.1 Tujuan

Dokumen Spesifikasi Kebutuhan Perangkat Lunak

(SKPL) ini merupakan dokumen spesifikasi kebutuhan

perangkat lunak SPJK untuk mendefinisikan kebutuhan

perangkat lunak yang meliputi antarmuka eksternal

(antarmuka antara sistem dengan sistem lain perangkat

lunak dan perangkat keras, dan pengguna) perfomansi

(kemampuan perangkat lunak dari segi kecepatan, tempat

penyimpanan yang dibutuhkan, serta keakuratan), dan

atribut (feature-feature tambahan yang dimiliki

sistem), serta mendefinisikan fungsi perangkat lunak.

SKPL-SPJK ini juga mendefinisikan batasan perancangan

perangkat lunak.

1.2 Lingkup Masalah

Untuk membantu kaprodi dalam menyelesaikan

timetable perkuliahan, maka dilakukan eksplorasi metode

DPSO yang dapat secara automatis men-generate timetable

dengan mempertimbangkan aturan kampus, preferensi

dosen, dan preferensi mahasiswa.

1.3 Definisi, Akronim dan Singkatan

Daftar definisi akronim dan singkatan :

Keyword/Phrase Definisi

SKPL Merupakan spesifikasi kebutuhan dari

perangkat lunak yang akan dikembangkan.

SKPL-SPJK-XXX Kode yang merepresentasikan kebutuhan pada

SPJK dimana XXX merupakan nomor fungsi

(13)

SPJK Program auto generate Timetable dengan

menggunakan algoritma discrete particle

swarm optimization.

ERD Entity Relationship Diagram merupakan

teknis grafis/diagram yang menggambarkan

objek dan hubungan antar objek.

1.4 Referensi

Referensi yang digunakan pada perangkat lunak

tersebut adalah:

1. Aryo Wibisono, Spesifikasi Kebutuhan Perangkat Lunak Sistem Informasi Akademik Mahasiswa (SIATMA), Universitas Atma Jaya Yogyakarta.

1.5 Deskripsi umum (Overview)

Secara umum dokumen SKPL ini terbagi atas 3 bagian

utama. Bagian utama berisi penjelasan mengenai dokumen

SKPL tersebut yang mencakup tujuan pembuatan SKPL,

ruang lingkup masalah dalam pengembangan perangkat

lunak tersebut, definisi, referensi dan deskripsi umum

tentang dokumen SKPL ini.

Bagian kedua berisi penjelasan umum tentang

perangkat lunak SPJK yang akan dikembangkan, mencakup

perspektif produk yang akan dikembangkan, fungsi produk

perangkat lunak, karakteristik pengguna, batasan dalam

penggunaan perangkat lunak dan asumsi yang dipakai

dalam pengembangan perangkat lunak SPJK tersebut.

Bagian ketiga berisi penjelasan secara lebih rinci

tentang kebutuhan perangkat lunak SPJK yang akan

(14)

2 Deskripsi Kebutuhan

2.1 Perspektif produk

SPJK merupakan perangkat lunak yang dikembangkan

untuk membantu Kaprodi dalam menciptakan suatu

timetable. Sistem ini menangani pengelolaan data dan

generate timetable yang merupakan bagian dari sistem

yang digunakan untuk menyempurnakan pembelajaran.

Perangkat lunak SPJK ini berjalan pada platform

berbasis windows, dan dibuat menggunakan bahasa

pemrograman C#. Sedangkan untuk lingkungan

pemrogramannya menggunakan Microsoft Visual Studio

2005.

Pengguna akan berinteraksi dengan sistem melalui

antarmuka GUI (Graphical User Interface). Pada sistem

ini, seperti terlihat pada gambar 1, arsitektur

perangkat lunak yang digunakan berupa client server, di

mana semua data disimpan di server. User dapat

mengakses data yang ada di server tersebut.

Input data yang dimasukkan akan disimpan dalam

database server, sehingga jika ada pencarian data, maka

data yang diinginkan akan dicari ke database server

yang selanjutnya dikirimkan ke client yang merequest

(15)

Gambar 1. Arsitektur Perangkat lunak SPJK

2.2 Kebutuhan Fungsionalitas Produk

Fungsi produk pengembangan perangkat lunak SPJK

adalah sebagai berikut :

a.User (Kaprodi, Petugas TU, Admin)

1.Fungsi login (SKPL SPJK-001)

Merupakan fungsi yang digunakan untuk masuk ke

dalam sistem utama.

b. User (Kaprodi)

1. Fungsi manageDosen (SKPL SPJK-002)

Merupakan fungsi yang digunakan untuk mengelola

data Dosen.

a) Fungsi add (SKPL SPJK-002-01)

Merupakan fungsi yang digunakan untuk

(16)

b) Fungsi edit (SKPL SPJK-002-02)

Merupakan fungsi yang digunakan untuk mengedit

data dosen.

c) Fungsi delete (SKPL SPJK-002-03)

menghapus data dosen.

2.Fungsi manageKelasMataKuliah (SKPL SPJK-003)

data kelasMataKuliah.

a) add (SKPL SPJK-003-01)

menginput data kelasMataKuliah.

b) edit (SKPL SPJK-003-02)

c) delete (SKPL SPJK-003-03)

menghapus data kelasMataKuliah.

3.Fungsi manageKendalaDosen (SKPL SPJK-004)

data kendalaDosen.

a. add (SKPL SPJK-004-01)

(17)

b. edit (SKPL SPJK-004-02)

data kendalaDosen.

c. delete (SKPL SPJK-004-03)

menghapus data kendalaDosen.

4.Fungsi manageKendalaMahasiswa (SKPL SPJK-005)

data kendalaMahasiswa.

menginput data kendalaMahasiswa.

data kendalaMahasiswa.

menghapus data kendalaMahasiswa.

5.Fungsi generateJadwal (SKPL SPJK-006)

data jadwal.

a. generateJadwal (SKPL SPJK-006-01)

(18)

b. showJadwal (SKPL SPJK-006-02)

menampilkan data jadwal.

c. report (SKPL SPJK-006-03)

Merupakan fungsi yang digunakan untuk report

data jadwal.

c.User(Petugas TU)

1. Fungsi manageMataKuliah (SKPL SPJK-007)

data mataKuliah.

a) add (SKPL SPJK-007-01)

menginput data kelasMataKuliah.

b) edit (SKPL SPJK-007-02)

c) delete (SKPL SPJK-007-03)

menghapus data kelasMataKuliah.

2. Fungsi manageRefSesi (SKPL SPJK-008)

data refSesi.

(19)

data refSesi.

menghapus data refSesi.

3. Fungsi manageRefRuang (SKPL SPJK-009)

data refRuang.

menginput data refRuang.

data refRuang.

menghapus data refRuang.

4. Fungsi manageRefHari(SKPL SPJK-010)

data refHari.

(20)

data refHari.

menghapus data refHari.

5. Fungsi manageRefKelas(SKPL SPJK-011)

data refHari.

menginput data refKelas.

data refKelas.

menghapus data refKelas.

6. Fungsi manageRefSemester(SKPL SPJK-012)

data refHari.

(21)

data refSemester.

menghapus data refSemester.

d.User(Administrator)

1. Fungsi manageUser (SKPL SPJK-013)

data user.

menginput data user.

data user.

menghapus data user

2. Fungsi manageRefRole (SKPL SPJK-014)

data refRole.

menginput data refRole.

(22)

data refRole.

menghapus data refRole

2.3 Karakteristik Pengguna

Karakteristik dari pengguna perangkat lunak SPJK

adalah sebagai berikut :

1.Administrator

a. Mengerti pengoperasian komputer dan internet.

b. Mengerti proses pengelolaan sistem yang

digunakan.

2.Kaprodi

a. Mengerti pengoperasian komputer.

digunakan

3.Petugas TU

a. Mengerti pengoperasian komputer.

digunakan.

2.4 Batasan-batasan

Batasan-batasan dalam pengembangan perangkat lunak

SPJK tersebut adalah :

1.Semua user mengakses SPJK dalam satu lingkungan

(23)

2.5 Asumsi dan Ketergantungan

Sistem ini dapat dijalankan pada perangkat PC dan

Notebook.

3 Kebutuhan khusus

3.1 Kebutuhan antarmuka eksternal

Kebutuhan antar muka eksternal pada perangkat lunak

SPJK meliputi kebutuhan antarmuka pemakai, antarmuka

perangkat keras dan antarmuka perangkat lunak.

3.1.1 Antarmuka pemakai

Pengguna berinteraksi dengan antarmuka yang

ditampilkan dalam layar komputer.

3.1.2 Antarmuka perangkat keras

Antarmuka perangkat keras yang digunakan dalam

perangkat lunak SPJK adalah:

1. PC/Notebook

2. Keyboard

3. Mouse

3.1.3 Antarmuka perangkat lunak

Perangkat lunak yang dibutuhkan dalam

mengoperasikan perangkat lunak SPJK adalah sebagai

berikut:

a. Nama : SQL Server 2005

Sumber : Microsoft

Sebagai database yang dibutuhkan dalam

(24)

b. Nama : C#

Sebagai bahasa pemrograman yang digunakan untuk

membangun sistem SPJK0.

e. Nama : Visual Studio 2005

Sumber : Microsoft

Sebagai program yang digunakan untuk membangun

(25)

3.2 Kebutuhan fungsionalitas Perangkat Lunak

3.2.1 Use Case Diagram

Admin

(from Actor)

manageDosen

(from Use Case)

manageKelasMataKuliah

(from Use Case)

manageUser

(from Use Case)

manageKendalaDosen

(from Use Case)

manageRefRole

(from Use Case)

manageRefRuang

(from Use Case)

manageRefSesi

(from Use Case)

manageRefHari

(from Use Case)

manageMataKuliah

(from Use Case)

generateJadwal

(from Use Case)

manageRefKelas

(from Use Case)

Petugas TU

(from Actor)

manageRefSemester

(from Use Case)

Kaprodi

(from Actor)

manageKendalaMahasiswa

(from Use Case)

login

(from Use Case)

<<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>> <<include>>

(26)

4 Spesifikasi Rinci Kebutuhan

4.1 Spesifikasi Kebutuhan Fungsionalitas

4.1.1 Use case Spesification : login

1. Brief Description

Use Case ini digunakan oleh aktor untuk masuk ke dalam aplikasi SPJK.

2. Primary Actor

1. Kaprodi, Petugas TU, Admin.

3. Supporting Actor

None.

4. Basic Flow

1. Aktor mengisi nama dan password. 2. Aktor menekan login.

3. Sistem memeriksa nama dan password. 4. Sistem masuk ke dalam aplikasi utama. 5. Use Case ini selesai.

5. Alternative Flow

None.

6. Error Flow

E-1. Setelah Basic Flow path 3.

1. Sistem menampilkan pesan bahwa nama belum dimasukkan. 2. Kembali ke Basic Flow path 1.

E-2. Setelah Basic Flow path 3.

1. Sistem menampilkan pesan bahwa password belum dimasukkan.

2. Kembali ke Basic Flow path 1. E-3. Setelah Basic Flow path 3.

1. Sistem menampilkan pesan bahwa data tidak ditemukan. 2. Kembali ke Basic Flow path 1.

(27)

8. PostConditions

(28)

4.1.2 Use case Spesification : generateJadwal

1. Brief Description

Use Case ini digunakan oleh aktor untuk menciptakan jadwal.

1. Kaprodi.

None.

4. Basic Flow

1. Sistem melakukan show untuk menampilkan data. 2. Aktor menekan generate.

3. Sistem melakukan show untuk menampilkan data 4. Use Case ini selesai.

5. Alternative Flow

A-1 Setelah Basic Flow path 1.

1. Aktor menekan report.

2. Sistem menampilkan report data. 3. kembali ke Basic Flow path 4.

6. Error Flow

None.

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki generate jadwal dari aplikasi.

8. PostConditions

(29)

4.1.3 Use case Spesification : manageDosen

1. Brief Description

Use Case ini digunakan untuk melakukan manage terhadap dosen.

1. Kaprodi.

None.

4. Basic Flow

1. Sistem melakukan melakukan show untuk menampilkan data.

2. Aktor memilih add. 3. Sistem mengisi Id.

4. Aktor mengisi Nama, Nip, dan Status aktif. 5. Aktor menekan Execute.

6. Sistem melakukan add. 7. Use Case ini selesai.

5. Alternative Flow

1. Aktor memilih edit. 2. Aktor mengisi Id. 3. Aktor menekan cek id.

4. Sistem mengisi Nama, Nip, dan Status aktif sesuai data yang ada.

5. Aktor mengubah Nama, Nip, dan Status aktif. 6. Aktor menekan Execute.

7. Sistem melakukan edit.

8. Kembali ke Basic Flow path 7. A-2 Setelah Basic Flow path 1.

(30)

4. Sistem mengisi Nama, Nip, dan Status aktif sesuai data yang ada.

5. Aktor menekan Execute. 6. Sistem melakukan delete. 7. Kembali ke Basic Flow path 7.

6. Error Flow

E-1 Setelah Basic Flow path 5.

1. Sistem menampilkan pesan bahwa Nama belum diisi. 2. Kembali ke Basic Flow A-1 path 4.

1. Sistem menampilkan pesan bahwa Nip belum diisi. 2. Kembali ke Basic Flow A-1 path 4.

E-3 Setelah Alternative Flow A-1 path 3.

1. Sistem menampilkan pesan bahwa Id belum diisi. 2. Kembali ke Alternative Flow A-1 path 2.

1. Sistem menampilkan pesan bahwa data tidak ditemukan. 2. Kembali ke Alternative Flow A-1 path 2.

1. Sistem menampilkan pesan bahwa Nama belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Nip belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Id belum dimasukkan. 2. Kembali ke Alternative Flow A-2 path 2.

(31)

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki manage dosen dari aplikasi.

(32)

4.1.4 Use case Spesification : manageKendalaDosen

Use Case ini digunakan untuk melakukan manage terhadap kendalaDosen.

1. Kaprodi.

None.

4. Basic Flow

4. Aktor mengisi Dosen, Hari, Sesi, dan Nilai kendala. 5. Aktor menekan execute.

6. Sistem melakukan add.

7. Use Case ini selesai.

5. Alternative Flow

4. Sistem mengisi Dosen, Hari, Sesi, dan Nilai kendala sesuai data yang ada.

5. Aktor mengubah Dosen, Hari, Sesi, dan Nilai kendala. 6. Aktor menekan execute.

(33)

4. Sistem mengisi Dosen, Hari, Sesi, dan Nilai kendala sesuai data yang ada.

5. Aktor menekan execute. 6. Sistem melakukan delete. 7. Kembali ke Basic Flow path 7.

6. Error Flow

E-1 Setelah Basic Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Nilai kendala belum diisi.

2. Kembali ke Basic Flow path 4. E-2 Setelah Basic Flow path 5.

1. Sistem menampilkan pesan bahwa Dosen belum diisi. 2. Kembali ke Basic Flow path 4.

Setelah Basic Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Hari belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Sesi belum diisi. 2. Kembali ke Basic Flow path 7.

2. Kembali ke Alternative Flow A-1 path 5. E-9 Setelah Alternative Flow A-1 path 6.

(34)

1. Sistem menampilkan pesan bahwa Hari belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Sesi belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki manage kendalaDosen dari aplikasi.

(35)

4.1.5 Use case Spesification : manageKelasMataKuliah

Use Case ini digunakan untuk melakukan manage terhadap kelasMataKuliah.

1. Kaprodi.

None.

4. Basic Flow

4. Aktor mengisi MK, Dosen dan Kelas. 5. Aktor menekan execute.

4. Sistem mengisi MK, Dosen, dan Kelas sesuai data yang ada.

5. Aktor mengubah MK, Dosen, dan Kelas. 6. Aktor menekan execute.

(36)

4. Sistem mengisi MK, Dosen, dan Kelas sesuai data yang ada.

6. Error Flow

1. Sistem menampilkan pesan bahwa MK belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Dosen belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Kelas belum diisi. 2. Kembali ke Basic Flow path 4.

E-7 Setelah alternative Flow A-1 path 6.

1. Sistem menampilkan pesan bahwa MK belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Dosen belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

E-9 Setelah alternative flow A-1 path 6.

(37)

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki manage mataKuliah dari aplikasi.

(38)

4.1.6 Use case Spesification : manageKendalaMahasiswa

Use Case ini digunakan untuk melakukan manage terhadap kendalaMahasiswa.

1. Kaprodi.

None.

4. Basic Flow

4. Aktor mengisi Nilai kendala, Hari, dan Sesi. 5. Aktor menekan execute.

6. Sistem melakukan add.

7. Use Case ini selesai.

1. Aktor memilih edit. 2. Aktor mengisi Id. 3. Aktor menekan cek id.

4. Sistem mengisi Nilai kendala, Hari, dan Sesi sesuai data yang ada.

5. Aktor mengubah Nilai kendala, Hari, dan Sesi. 6. Aktor menekan execute.

8. Kembali ke Basic Flow path 7. A-2 Setelah basic flow path 1.

(39)

4. Sistem mengisi Nilai kendala, Hari, dan Sesi sesuai data yang ada.

5. Aktor menekan execute.

6. Sistem melakukan delete. 7. Kembali ke Basic Flow path 7.

6. Error Flow

2. Kembali ke Basic Flow path 4. E-2 Setelah Basic Flow path 5.

1. Sistem menampilkan pesan bahwa Hari belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Sesi belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Nilai Kendala belum diisi.

1. Sistem menampilkan pesan bahwa Hari belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

(40)

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki manage kendalaMahasiswa dari aplikasi.

(41)

4.1.7 Use case Spesification : manageMataKuliah

Use Case ini digunakan untuk melakukan manage terhadap mataKuliah.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih Add. 3. Sistem mengisi id.

4. Aktor mengisi kodeMK, namaMK, semester dan jumlahSKS. 5. Aktor menekan execute.

1. Aktor memilih edit. 2. Aktor mengisi id. 3. Aktor menekan cek id.

4. Sistem mengisi kodeMK, namaMK, semester dan jumlahSKS sesuai data yang ada.

5. Aktor mengubah kodeMK, namaMK, semester dan jumlahSKS. 6. Aktor menekan execute.

(42)

4. Sistem mengisi kodeMK, namaMK, semester dan jumlahSKS sesuai data yang ada.

6. Error Flow

1. Sistem menampilkan pesan bahwa KodeMK belum diisi. 2. Kembali ke Basic Flow Flow path 4.

1. Sistem menampilkan pesan bahwa NamaMK belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Semester belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa JumlahSKS belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa KodeMK belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

(43)

1. Sistem menampilkan pesan bahwa Semester belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa JumlahSKS belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

7. PreConditions

1. Use case ini dimulai setelah kaprodi memasuki manage mataKuliah dari aplikasi.

(44)

4.1.8 Use case Spesification : manageRefSesi

Use Case ini digunakan untuk melakukan manage terhadap refSesi.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih add. 3. Sistem mengisi id.

4. Aktor mengisi Jam Mulai dan Jam Selesai. 5. Aktor menekan execute.

4. Sistem mengisi Jam Mulai, Jam Selesai dan isDeleted sesuai data yang ada.

5. Aktor mengubah Jam Mulai, Jam Selesai, dan isDeleted. 6. Aktor menekan execute.

(45)

4. Sistem mengisi Jam Mulai dan jam Selesai sesuai data yang ada.

6. Error Flow

1. Sistem menampilkan pesan bahwa jamMulai belum diisi. 2. Kembali ke Basic Flow path 4.

E-2 Setelah Basic flow path 5.

1. Sistem menampilkan pesan bahwa jamSelesai belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa jamMulai belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa jamSelesai belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

(46)

7. PreConditions

1. Use case ini dimulai setelah petugas TU memasuki manage refSesi dari aplikasi.

(47)

4.1.9 Use case Spesification : manageRefRuang

Use Case ini digunakan untuk melakukan manage terhadap refRuang.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih add. 3. Sistem mengisi id. 4. Aktor mengisi Ruang. 5. Aktor menekan execute. 6. Sistem melakukan add. 7. Use Case ini selesai.

1. Aktor memilih edit. 2. Aktor mengisi id. 3. Aktor menekan cek id.

4. Sistem mengisi Ruang dan isDeleted. 5. Aktor mengisi Ruang dan isDeleted. 6. Aktor menekan execute.

(48)

6. Error Flow

1. Sistem menampilkan pesan bahwa Ruang belum diisi. 2. Kembali ke path 4.

1. Sistem menampilkan pesan bahwa Ruang belum diisi. 2. Kembali ke alternative flow A-1 path 5.

7. PreConditions

1. Use case ini dimulai setelah petugas TU memasuki manage refRuang dari aplikasi.

(49)

4.1.10 Use case Spesification : manageRefHari

Use Case ini digunakan untuk melakukan manage terhadap refHari.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih add. 3. Sistem mengisi id. 4. Aktor mengisi hari. 5. Aktor menekan execute. 6. Sistem melakukan add. 7. Use Case ini selesai.

A-1 Setelah basic flow path 1.

1. Aktor memilih edit. 2. Aktor mengisi id. 3. Aktor menekan cek id.

4. Sistem mengisi hari dan isDeleted. 5. Aktor mengubah hari dan isDeleted. 6. Aktor menekan execute.

1. Aktor memilih delete. 2. Aktor mengisi id. 3. Aktor menekan cek id.

(50)

6. Sistem melakukan delete. 7. Kembali ke path 7.

6. Error Flow

1. Sistem menampilkan pesan bahwa namaHari belum diisi. 2. Kembali ke Alternative Flow path 4.

7. PreConditions

1. Use case ini dimulai setelah petugas TU memasuki manage refHari dari aplikasi.

(51)

4.1.11 Use case Spesification : manageRefKelas

Use Case ini digunakan untuk melakukan manage terhadap refKelas.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih add. 3. Aktor mengisi kelas. 4. Aktor menekan execute. 5. Sistem melakukan add. 6. Use Case ini selesai.

1. Aktor memilih edit.

2. Aktor mengisi kelas untuk input. 3. Aktor menekan cek id.

4. Sistem mengisi kelas. 5. Aktor mengubah kelas. 6. Aktor menekan execute. 7. Sistem melakukan edit.

1. Aktor memilih delete.

(52)

7. Kembali ke path 7.

6. Error Flow

2. PreConditions

1. Use case ini dimulai setelah petugas TU memasuki manage refKelas dari aplikasi.

(53)

4.1.12 Use case Spesification : manageRefSemester

Use Case ini digunakan untuk melakukan manage terhadap refSemester.

1. Petugas TU.

None.

4. Basic Flow

2. Aktor memilih add. 3. Aktor mengisi semester. 4. Aktor menekan execute. 5. Sistem melakukan add. 6. Use Case ini selesai.

1. Aktor memilih edit.

4. Sistem mengisi semester dan isDeleted. 5. Aktor mengubah semester dan isDeleted. 6. Aktor menekan execute.

1. Aktor memilih delete.

(54)

7. Kembali ke path 7.

6. Error Flow

2. PreConditions

1. Use case ini dimulai setelah petugas TU memasuki manage refKelas dari aplikasi.

(55)

4.1.13 Use case Spesification : manageUser

Use Case ini digunakan untuk melakukan manage terhadap user.

1. Admin.

None.

4. Basic Flow

2. Aktor memilih add. 3. Sistem mengisi id.

4. Aktor mengisi Role, Nama, Password, Alamat, Telephone, Email.

5. Aktor menekan execute. 6. Sistem melakukan add. 7. Use Case ini selesai.

4. Sistem mengisi Role, Nama, Password, Alamat, Telephone, Email.

5. Aktor mengubah Role, Nama, Password, Alamat, Telephone, Email.

6. Aktor menekan execute. 7. Sistem melakukan edit.

(56)

3. Aktor menekan cek id.

4. Sistem mengisi Role, Nama, Password, Alamat, Telephone, Email.

6. Error Flow

1. Sistem menampilkan pesan bahwa Role belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Nama belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Password belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Alamat belum diisi. 2. Kembali ke Basic Flow path 4.

1. Sistem menampilkan pesan bahwa Telephone belum diisi. 2. Kembali ke Basic Flow path 4.

E-6 Setelah Basic Glow path 5.

1. Sistem menampilkan pesan bahwa Email belum diisi. 2. Kembali ke Basic Flow path 4.

(57)

1. Sistem menampilkan pesan bahwa Role belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Nama belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Password belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Alamat belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Telephone belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Email belum diisi. 2. Kembali ke Alternative Flow A-1 path 5.

2. PreConditions

1. Use case ini dimulai setelah admin memasuki manage manageUser dari aplikasi.

(58)

4.1.14 Use case Spesification : manageRefRole

Use Case ini digunakan untuk melakukan manage terhadap refRole.

1. Admin.

None.

4. Basic Flow

2. Aktor memilih add. 3. Sistem mengisi id. 4. Aktor mengisi role. 5. Aktor menekan execute. 6. Sistem melakukan add. 7. Use Case ini selesai.

1. Aktor memilih edit. 2. Aktor memilih id. 3. Aktor menekan cek id.

4. Sistem mengisi role dan isDeleted. 5. Aktor mengubah role dan isDeleted. 6. Aktor menekan execute.

(59)

6. Error Flow

E-1 Setelah Basic Flow A-1 path 5.

1. Sistem menampilkan pesan bahwa Role belum diisi. 2. Kembali ke path 4.

1. Sistem menampilkan pesan bahwa Role belum diisi. 2. Kembali ke Alternative Flow A-1 path 3.

3. Sistem menampilkan pesan bahwa data tidak ditemukan.

7. PreConditions

1. Use case ini dimulai setelah admin memasuki manage refRole dari aplikasi.

(60)

ERD (Entity Relationship Diagram)

Diagram alir data digambarkan dalam bentuk entity relationship diagram berikut.

[image:60.612.95.524.152.710.2]

Relationship_2 Relationship_2 Relationship_3 Relationship_5 Relationship_6 Relationship_7 Relationship_9 Relationship_9 Relationship_10 Relationship_11 Relationship_11 Relationship_12 kelasMataKuliah idKelasMataKuliah kelas <pi> I VA2 <M> Identifier_1 <pi> dosen idDosen namaDosen nip aktif <pi> I VA64 VA16 BIN2 <M> Identifier_1 <pi> jadwal idJadwal <pi> I <M> Identifier_1 <pi> refRuang idRefRuang namaRuang isDeleted <pi> I VA32 I <M> Identifier_1 <pi> userLogin idUser namaUser password alamat telephone email <pi> I VA64 VA32 VA128 VA16 VA128 <M> Identifier_1 <pi> KendalaMahasiswa idKendalaMahasiswa nilaiKendala <pi> I I <M> Identifier_1 <pi> refSesi idRefSesi jamMulai jamSelesai isDeleted <pi> I VA16 VA16 I <M> Identifier_1 <pi> refHari idRefHari hari isDeleted <pi> I VA16 I <M> Identifier_1 <pi> kendalaDosen idKendalaDosen nilaiKendala <pi> I I <M> Identifier_1 <pi> refRole idRefRole role isDeleted <pi> I VA16 I <M> Identifier_1 <pi> mataKuliah idMataKuliah kodeMataKuliah namaMataKuliah semester jumlahSKS <pi> I VA16 VA32 I I <M> Identifier_1 <pi> refSemester semester isDeleted I I refKelas kelas isDeleted VA2 I

(61)

(62)

DESKRIPSI PERANCANGAN PERANGKAT LUNAK

SISTEM PENGATURAN JADWAL KULIAH

Untuk :

Universitas Atma Jaya Yogyakarta

Dipersiapkan oleh:

Rochim Widaryanto / 4362

Program Studi Teknik Informatika – Fakultas Teknologi Industri

Universitas Atma Jaya Yogyakarta

Nomor Dokumen Halaman

DPPL-_SPJK _1/102

Program Studi Magister Teknik Informatika

Revisi 2013

(63)

DAFTAR PERUBAHAN

Revisi Deskripsi

A

B

C

D

E

F

G

INDEX TGL

- A B C D E F G

Ditulis oleh

Diperiksa oleh

(64)

Daftar Halaman Perubahan

(65)

DAFTAR ISI

1. Pendahuluan... 7

1.1 Tujuan... 7

1.2 Ruang Lingkup... 7

1.3 Definisi dan Akronim... 7

1.4 Referensi... 8

2. Perancangan Sistem (System Design)... 9

2.1 Perancangan Arsitektur (Architectural Design)... 9

2.2 Perancangan Rinci (Detail Design)... 10

3. Perancangan Data (Data Design)... 87

3.1 Pyhsical Data Model... 87

4. Perancangan Antarmuka (UI Design)... 88

4.1 Antarmuka Login... 88

4.2 Antarmuka Generate Jadwal... 89

4.3 Antarmuka Report... 90

4.4 Antarmuka Manage Dosen... 91

4.5 Antarmuka Manage Kelas Mata Kuliah... 92

4.6 Antarmuka Manage Kendala Mahasiswa... 93

4.7 Antarmuka Manage Kendala Dosen... 94

4.8 Antarmuka Manage Ref Hari... 96

4.9 Antarmuka Manage Ref Sesi... 97

4.10 Antarmuka Manage Ref Ruang... 98

4.11 Antarmuka Manage Ref Kelas... 99

4.12 Antarmuka Manage Ref Semester... 100

4.13 Antarmuka Manage User... 101

(66)

DAFTAR GAMBAR

(67)

[image:67.612.98.516.106.675.2]

(68)

1.

Pendahuluan

1.1 Tujuan

Dokumen Deskripsi Perancangan Perangkat Lunak

(DPPL) SPJK bertujuan untuk mendefinisikan perancangan

perangkat lunak yang akan dikembangkan. Dokumen DPPL

tersebut digunakan oleh pengembang perangkat lunak

sebagai acuan untuk implementasi pada tahap

selanjutnya.

1.2 Ruang Lingkup

Perangkat Lunak SPJK dibangun dengan tujuan untuk

Untuk membantu kaprodi dalam menyelesaikan timetable

perkuliahan. Permasalahan timetable akan diselesaikan

dengan mengeksplorasi algoritma DPSO agar komputasi

menjadi lebih optimal. SPJK berjalan pada platform

berbasis windows. Dengan SPJK ini diharapkan kaprodi

dapat menyelesaikan timetable dengan optimal.

[image:68.612.100.541.145.676.2]

1.3 Definisi dan Akronim

Tabel 1.1 Daftar definisi akronim dan singkatan

Keyword/Phrase Definisi

DPPL Deskripsi Perancangan Perangkat Lunak

disebut juga Software Design Description

(SDD) merupakan deskripsi dari perancangan

produk/perangkat lunak yang akan

dikembangkan.

SPJK Program auto generate Timetable dengan

menggunakan algoritma discrete particle

(69)

1.4 Referensi

Referensi yang digunakan pada perangkat lunak tersebut

adalah:

(70)

2.

Perancangan Sistem (System Design)

2.1 Perancangan Arsitektur (Architectural Design)

User Services Business Services Data Services

dosen

kelasM ataKuliah

kendalaDosen

kendalaM ahasisw a

refS esi

refR ole refRuang

user refKelas

refSem ester refH ari partikel

generateJadw al

[image:70.612.100.519.146.724.2]

(71)

2.2 Perancangan Rinci (Detail Design) a. Sequence Diagram

1. login

: User

: User : SPJKUI : SPJKUI : SPJK : SPJK : manageUser : manageUser

SPJKUI( )

Login( )

[image:71.612.98.519.97.677.2]

getUserLogin( )

(72)

2. manageDosen

: Kaprodi

: Kaprodi : SPJKUI : SPJKUI : SPJK : SPJK : manageDosen : manageDosen

Menu

cmbMenu_SelectedIndexChanged( )

getAllDataDosen

getNewId

(73)

2.1. add

: Kaprodi

Add

rbtnAdd_CheckedChanged( )

getNewId( )

Execute

btnExecute_Click( )

add(idDosen, namaDosen, nip, aktif)

getAllDataDosen( )

(74)

2.2. edit

: Kaprodi

Cek Id

btnCekId_Click( )

getDataById(id) Edit

rbtnEdit_CheckedChanged( )

Execute

btnExecute_Click( )

update(idDosen, namaDosen, nip, aktif)

(75)

2.3. delete

: Kaprodi

Delete

rBtnDelete_CheckedChanged

Cek Id

btnCekId_Click

getDataById(id)

getAllDataDosen( ) Execute

btnExecute_Click( )

delete(id)

(76)

3. generateJadwal

: Kaprodi

: Kaprodi : SPJKUI : SPJKUI : SPJK : SPJK : generateJadwal : generateJadwal

Menu

cmbMenu_SelectedIndexChanged

getAllDataJadwalJoin( )

(77)

[image:77.1191.162.1102.152.592.2]

3.1. generate

(78)

3.2. Report

: Kaprodi

: Kaprodi : SPJKUI : SPJKUI : SPJK : SPJK : generateJadwal : generateJadwal

Report

chkBoxReport_CheckedChanged( )

getAllDataJadwalJoin2( )

(79)

4. manageKelasMataKuliah

: Kaprodi

: Kaprodi : SPJKUI : SPJKUI : SPJK : SPJK : manageKelasMataKuliah

: manageKelasMataKuliah

: manageRefKelas

: manageRefKelas : manageDosen : manageDosen : manageMataKuliah : manageMataKuliah Menu

cmbMenu_SelectedIndexChanged( )

getAllDataKelasMataKuliahJoin( )

getNewId( )

getAllDataRefKelas( )

getAllDataDosen( )

getAllDataMataKuliah( )

(80)

4.1. add

: Kaprodi

: manageKelasMataKuliah Add

rbtnAdd_CheckedChanged( )

getNewId( )

Execute

btnExecute_Click( )

add(idKelasMataKuliah, kodeMataKuliah, idMataKuliah,idDosen,kelas)

(81)

4.2. edit

: Kaprodi

: manageKelasMataKuliah Edit

rbtnEdit_CheckedChanged( )

Cek Id

btnCekId_Click( )

getDataById(id)

Execute

btnExecute_Click( )

edit(idKelasMataKuliah, kodeMataKuliah, idMataKuliah,idDosen,kelas)