RANCANG BANGUN PEMBUATAN APLIKASI INFORMASI JADWAL SIDANG PROPOSAL TUGAS AKHIR BERBASIS WEB PADA
STIKOM SURABAYA
Oleh :
Nama : RIZKI MENTARI TIMUR
NIM : 09.41010.0097
Program : S1 (Strata Satu)
Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
RANCANG BANGUN PEMBUATAN APLIKASI INFORMASI JADWAL SIDANG PROPOSAL TUGAS AKHIR BERBASIS WEB PADA
STIKOM SURABAYA
Diajukan sebagai salah satu syarat untuk menyelesaikan
Program S1 Sistem Informasi
Oleh :
Nama : RIZKI MENTARI TIMUR
NIM : 09.41010.0097
Program : S1 (Strata Satu)
Jurusan : Sistem Informasi
SEKOLAH TINGGI
MANAJEMEN INFORMATIKA & TEKNIK KOMPUTER SURABAYA
ABSTRAK
Pengembangan dan Penerapan Teknologi Informasi (PPTI) STIKOM
Surabaya adalah sebuah bagian dari STIKOM Surabaya yang menangani dan
membantu dalam pembuatan aplikasi-aplikasi yang diperlukan dalam
mengembangkan STIKOM Surabaya. Saat ini salah satu kendalan yang dihadapai
oleh STIKOM Surabaya adalah pada bagian Pusat Pelayanan Tugas Akhir (PPTA).
Yaitu permasalahan yang dihadapi oleh mahasiswa adalah kesulitan memperoleh
informasi mengenai kapan jadwal mereka melakukan sidang proposal tugas akhir.
Untuk itu dibutuhkan suatu aplikasi yang dapat membantu PPTA dalam
mengentri jadwal sidang proposal tugas akhir untuk ditampilkan pada web
PPTA.stikom.edu sehingga dapat membantu PPTA dalam memberikan informasi
kepada mahasiswa mengenai kapan waktu mereka melakukan sidang proposal tugas
akhir.
Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web
merupakan aplikasi sangat diperlukan bagi PPTA (Pusat Pelayanan Tugas Akhir)
STIKOM Surabaya, khususnya bagi mahasiswa yang akan mengerjakan tugas akhir.
Jadwal sidang berupa hari dan waktu pelaksaan sidang, dosen pembimbing, dosen
penguji, dan segala informasi mengenai sidang tugas akhir sangat diperlukan bagi
mahasiswa yang akan mengerjakan tugas akhir. Aplikasi tersebut dibuat dan dikelola
dengan harapan dapat membantu mahasiswa STIKOM Surabaya dalam melakukan
pengecekan kapan mereka melaksanakan sidang proposal tugas akhir.
Kata kunci: aplikasi informasi jadwal sidang proposal tugas akhir, pusat pelayanan
tugas akir
DAFTAR ISI
DAFTAR LAMPIRAN ... ii
BAB I PENDAHULUAN ... 1
1.6 Sistematika Penulisan ... 3
BAB II GAMBARAN UMUM PERUSAHAAN ... 5
2.1 Sejarah Singkat STIKOM Surabaya ... 5
2.2 Visi dan Misi STIKOM Surabaya ... 6
2.3 Ruang Lingkup Bagian Pusat Pelayanan Tugas Akhir ... 7
2.4 Tugas dan Fungsi Bagian Peneltian Akademik ... 7
BAB III LANDASAN TEORI ... 9
3.1 Sistem ... 9
3.2 Sistem Informasi ... 9
3.3 Oracle ... 10
3.4 Database ... 11
3.5 Unified Modeling Language (UML) ... 11
3.6 Pemodelan Bisnis ... 11
3.7 Pemodelan Use Case Sistem ... 16
3.8 Entity Relational Diagram ... 19
3.9 Web ... 20
3.10 World Wide Web ... 20
3.11 Keamanan Informasi ... 20
BAB IV ANALISA DAN DESAIN SISTEM ... 22
4.2.5 Diagram Sekuensial ... 40
4.2.6 Diagram Kelas ... 48
4.2.7 Diagram Statechart ... 50
4.2.8 Diagram Komponen ... 51
4.2.9 Diagram Deployment ... 52
4.2.10 Entity Relational Model ... 53
4.2.11 Struktur Tabel ... 55
4.2.12 Desain Input/Output ... 57
BAB V IMPLEMENTASI SISTEM ... 61
5.1 Kebutuhan Sistem ... 61
5.1.1 Kebutuhan Perangkat Keras ... 61
5.1.2 Kebutuhan Perangkat Lunak ... 62
5.2 Pegoperasian Program ... 62
BAB VI PENUTUP ... 70
6.1 Kesimpulan ... 70
6.2 Saran ... 70
Daftar Pustaka ... 71
LAMPIRAN ... 72
DAFTAR TABEL
Tabel 4.1 Keterangan Use Case Bisnis: Penjadwalan Sidang Proposal Tugas Akhir 24
Tabel 4.2 Keterangan Use Case Sistem: Penjadwalan Sidang Proposal Tugas Akhir
... 32
Tabel 4.3 FOE Use Case Login User ... 33
Tabel 4.4 FOE Use Case Entri NIM dan Nama Mahasiswa ... 34
Tabel 4.5 FOE Use Case Entri Judul Proposal ... 35
Tabel 4.6 FOE Use Case Entri Tanggal, Waktu, dan Ruang Pelaksanaan Sidang .... 35
Tabel 4.7 FOE Use Case Entri Nama Dosen Pembimbing dan Penguji ... 36
Tabel 4.8 Use Case Entri Status Sidang Proposal Tugas Akhir ... 37
Tabel 4.9 FOE Use Case Simpan Data Jadwal Sidang Proposal Tugas Akhir ... 38
Tabel 4.10 FOE Use Case Cek Jadwal Sidang ... 39
Tabel 4.11 FOE Use Case Mencetak Jadwal Sidang Proposal Tugas Akhir ... 39
Table 4.12 Tabel Mahasiswa ... 55
Tabel 4.13 Tabel Dosen ... 56
Tabel 4.14 Tabel Jadwal Sidang ... 56
Tabel 4.15 Tabel Detail Jadwal Sidang ... 57
DAFTAR GAMBAR
Gambar 2.1 Struktur Organisasi PPTI ... 8
Gambar 3.1 Aktor Bisnis ... 12
Gambar 3.2 Use Case Bisnis ... 13
Gambar 3.3 Relasi Asosiasi ... 14
Gambar 3.4 Relasi Generalisasi ... 14
Gambar 3.5 Entitas Bisnis ... 15
Gambar 3.6 Aktor Sistem ... 16
Gambar 3.7 Use Case Sistem ... 17
Gambar 4.1 Use Case Bisnis PPTA ... 23
Gambar 4.2 Activity Diagram Pembuatan Proposal ... 25
Gambar 4.3 Activity Diagram Pendaftaran Proposal ... 26
Gambar 4.4 Activity Diagram Penjadwalan Sidang Proposal TA ... 27
Gambar 4.5 Activity Diagram Sidang Proposal Tugas Akhir ... 29
Gambar 4.6 Activity Diagram Penyerahan Revisi Proposal Tugas Akhir ... 30
Gambar 4.7 Use Case Sistem Penjadwalan Sidang Proposal Tugas Akhir ... 31
Gambar 4.8 Diagram Sekuensial Login User ... 41
Gambar 4.9 Diagram Sekuensial Entri NIM dan Nama Mahasiswa ... 42
Gambar 4.10 Digram Sekuensial Entri Judul Proposal ... 43
Gambar 4.11 Diagram Sekuensial Entri Tanggal dan Waktu Pelaksanaan Sidang Proposal ... 44
Gambar 4.12 Diagram Sekuensial Entri Nama Dosen ... 45
Gambar 4.13 Diagram Sekuensial Entri Nama Dosen ... 46
Gambar 4.14 Diagram Sekuensial Cetak Jadwal Sidang Proposal ... 47
Gambar 4.15 Diagram Sekuensial Cek Jadwal Sidang Proposal ... 48
Gambar 4.16 Diagram Kelas Penjadwalan Sidang Proposal Tugas Akhir ... 49
Gambar 4.17 Kelas Form Jadwal Sidang Proposal TA ... 50
Gambar 4.18 Diagram Statechart untuk kelas form jadwal sidang proposal TA ... 51
Gambar 4.19 Diagram Komponen ... 52
Gambar 4.20 Diagram Deployment ... 53
Gambar 4.21 CDM ... 54
Gambar 4.22 PDM ... 54
Gambar 4.231 Desain IO Input Jadwal Sidang Proposal Tugas Akhir ... 58
Gambar 4.24 Desain IO Update Jadwal Sidang Proposal Tugas Akhir ... 59
Gambar 4.25 Cetak Jadwal Sidang Proposal Tugas Akhir ... 60
Gambar 5.1 Halaman Input Jadwal Sidang Proposal Tugas Akhir ... 63
Gambar 5.2 Halaman Pencarian NIM dan Nama Mahasiswa ... 63
Gambar 5.3 Halaman Pencarian NIK dan Nama Dosen ... 64
Gambar 5.4 Halaman Lihat Data Jadwal Sidang Proposal Tugas Akhir ... 65
Gambar 5.5 Halaman Update Jadwal Sidang Proposal Tugas Akhir ... 66
Gambar 5.7 Tampilan Laporan Jadwal Sidang Proposal Tugas Akhir ... 66
Gambar 5.6 Halaman Pencarian Mahasiswa Berdasarkan Status ... 67
Gambar 5.7 Laporan Daftar Proposal TA Berdasarkan Status ... 68
Gambar 5.8 Halaman Pencarian Mahasiswa Berdasarkan Bulan ... 68
Gambar 5.9 Laporan Daftar Proposal TA Berdasarkan Bulan ... 69
BAB I PENDAHULUAN
1.1 Latar Belakang Masalah
Pusat Pelayanan Tugas Akhir (PPTA) STIKOM Surabaya adalah sebuah
bagian dari STIKOM Surabaya yang menangani segala kebutuhan mahasiswa dalam
menyelesaikan tugas akhir. Mulai dari pengajuan proposal tugas akhir, sidang
proposal tugas akhir, penyelesaian TA, hingga sidang tugas akhir. Sidang proposal
tugas akhir merupakan program baru dari STIKOM Surabaya yang mewajibkan
mahasiswa untuk melakukan sidang proposal tugas akhir sebelum akhirnya
mahasiswa dapat mengerjakan tugas akhir. Namun karena merupakan program baru
dari STIKOM Surabaya maka bagian PPTA dan mahasiswa sering kesulitan dalam
menentukan jadwal sidang proposal tugas akhir. Mahasiswa sering kesulitan dalam
mengetahui kapan mereka melakukan sidang proposal tugas akhir.
Dari permasalahan di atas, maka solusi yang dapat diberikan adalah
menciptakan suatu aplikasi web yang dapat membantu mahasiswa dan PPTA dalam
menentukan jadwal sidang proposal tugas akhir. Aplikasi tersebut dapat tergabung
dalam website PPTA.stikom.edu. suatu website yang memberikan informasi
mengenai tugas akhir. Aplikasi tersebut membantu PPTA dalam mengentri jadwal
sidang proposal tugas akhir, dan juga membantu mahasiswa untuk mengetahui kapan
mahasiswa tersebut melakukan sidang proposal tugas akhir.
Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web pada
STIKOM Surabaya ini merupakan aplikasi yang dapat membantu PPTA dan
mahasiswa yang akan melaksanakan tugas akhir. Dalam aplikasi ini PPTA mengentri
Nomor Induk Mahasiswa (NIM) , nama mahasiswa, Nomor Induk Karyawan (NIK)
dosen pembimbing dan penguji, tanggal sidang, waktu sidang, ruang pelaksanaan
sidang, dan judul tugas akhir. Aplikasi ini juga memberikan fasilitas untuk mencetak
informasi jadwal sidang proposal tugas akhir untuk diberikan PPTA pada dosen
pembimbing dan penguji. Manfaat bagi mahasiswa adalah, mempermudah
mahasiswa dalam mengetahui waktu sidang proposal tugas akhir. Karena aplikasi ini
nantinya akan tergabung dalam website PPTA.
1.2 Perumusan Masalah
Dengan melihat latar belakang masalah yang ada, maka dapat disimpulkan
bahwa permasalahan yang ada pada Stikom Surabaya bagian PPTA adalah sebagai
berikut:
Bagaimana merancang bangun aplikasi informasi jadwal sidang proposal TA
berbasis web
1.3 Batasan Masalah
Adapun batasan masalah yang digunakan, yaitu:
1. Sistem ini hanya memproses informasi jadwal sidang proposal Tugas Akhir di STIKOM Surabaya
2. Sistem ini tidak berbasis dekstop melainkan berbasis web dan berdasarkan pada data yang diperoleh dari STIKOM Surabaya.
1.4 Tujuan
Tujuan dari Rancang Bangun Pembuatan Aplikasi Informasi Jadwal Sidang
Proposal TA Berbasis Web ini adalah :
1. Mendesain dan membangun aplikasi yang dapat menampilkan informasi jadwal
pelaksanaan sidang proposal tugas akhir berbasis web
2. Menerapkan aplikasi informasi jadwal sidang proposal berbasis web PHP di
bagian PPTA
1.5 Kontribusi
Beberapa hal yang dapat diperoleh dari kegiatan kerja praktek di PPTI
STIKOM Surabaya antara lain:
1. Membuat dan merancang bangun aplikasi informasi jadwal sidang proposal
tugas akhir STIKOM Surabaya berbasis web
2. Mempermudah menyajikan informasi jadwal pelaksanaan sidang proposal tugas
akhir, sehingga mahasiswa STIKOM Surabaya dengan mudah dan cepat
melakukan pengecekan jadwal sidang proposal tugas akhir
1.6 Sistematika Penulisan BAB I PENDAHULUAN
Pada bab ini akan dibahas tentang latar belakang yang mendasari studi kasus
ini serta perumusan masalah, pembatasan masalah, tujuan dan sistematika penulisan.
BAB II GAMBARAN UMUM PERUSAHAAN
Pada bab ini akan menjelaskan secara singkat tentang bagian PPTI dan
PPTA STIKOM Surabaya. Beberapa hal yang dibahas adalah tentang profil
perusahaan, struktur organisasi perusahaan, arsitektur proses bisnis perusahaan,
proses bisnis perusahaan serta pemodelan dari proses bisnis perusahaan tersebut.
BAB III LANDASAN TEORI
Pada bab ini menjelaskan tentang teori-teori pendukung dalam mengerjakan
Aplikasi Pendataan Penelitian Dosen Berbasis Web PHP.
BAB IV DESKRIPSI PEKERJAAN
Bab ini menjelaskan tentang semua pekerjaan yang dilakukan selama KP
yakni, mendesain UML, ERD, input/output, dan interface.
BAB V PENUTUP
Pada bab ini berisikan kesimpulan pembahasan yang telah dilakukan terkait
dengan tujuan dan permasalahan yang ada, serta saran untuk pengembangannya.
BAB II GAMBARAN UMUM PERUSAHAAN
2.1 Sejarah Singkat STIKOM Surabaya
STIKOM Surabaya pertama kali didirikan pada tanggal 30 April 1983 oleh
Yayasan Putra Bakti, dengan nama Akademi Komputer dan Informatika Surabaya (
AKIS ). Tokoh pendirinya saat itu adalah :
1. Laksda. TNI (purn) Mardiono
2. Ir. Andrian A.T
3. Ir. Handoko Anindoyo
4. Dra. Suzana Surojo
5. Dra. Rosy Merianti, Ak
Kemudian berdasarkan rapat BLKPTS tanggal 2-3 Maret 1984 kepanjangan
AKIS dirubah menjadi Akademi Manajemen Informatika & Komputer Surabaya
yang bertempat di jalan Ketintang Baru XIV no 2. Kemudian pada tanggal 19 Juni
1984 AKIS memperoleh status terdaftar untuk program Diploma III dan kepanjangan
AKIS berubah lagi menjadi Akademi Manajemen & teknik Komputer Surabaya.
Waktu terus berlalu, kebutuhan informasi terus meningkat. Untuk menjawab
kebutuhan tersebut AKIS ditingkatkan menjadi Sekolah Tinggi dengan membuka
program Strata 1 dan Diploma III jurusan Manajemen Informatika. Dan pada tanggal
30 Maret 1986 nama AKIS berubah menjadi STIKOM, singkatan dari Sekolah
Tinggi Manajemen Informatika & Teknik Komputer Surabaya yang selanjutnya
memperoleh status TERDAFTAR pada tanggal 25 Nopember 1986.
Di samping itu juga melakukan pembangunan gedung Kampus Baru di jalan
dilakukan pada tanggal 11 Desember 1987 oleh Bapak Wahono Gubernur Jawa
Timur pada saat itu. Sebelumnya pada bulan Nopember 1987 Stikom juga membuka
pendidikan Diploma (DI) program studi Komputer Akuntansi.
Tahun 1990 : Membuka jurusan DI Program Studi Komputer Keuangan.
1 Januari 1992 : Membuka jurusan Strata 1 jurusan Teknik Komputer.
19 Maret 1992 : DIII Manajemen Informatika memperoleh status “Diakui”
1 Nopember 1994 : Membuka DI Komputer Grafik Multimedia.
28 Oktober 1997 : Dilakukan pemasangan Tiang Pancang pertama.
30 Juni 1998 : Program DI & DIII Stikom status “ Disamakan ”.
2.2 Visi dan Misi STIKOM Surabaya 2.2.1 Visi
Menjadi Perguruan Tinggi yang Berkualitas, Unggul, dan Terkenal.
2.2.2 Misi
1. Mengembangkan ipteks sesuai dengan kompetensi.
2. Membentuk SDM yang profesional, unggul dan berkompetensi.
3. Menciptakan corporate yang sehat dan produktif.
4. Meningkatkan kepedulian sosial terhadap kehidupan bermasyarakat.
5. Menciptakan lingkungan hidup yang sehat dan produktif.
2.2.3 Tujuan
1. Menghasilkan pengembangan dan karya inovatif ipteks sesuai bidang kajian dan
kompetensi.
2. Menghasilkan lulusan yang berdaya saing tinggi,mandiri, dan profesional.
4. Menjadi lembaga pendidikan tinggi yang sehat, bermutu dan produktif.
5. Meningkatkan kerjasama dan pencitraan.
6. Meningkatkan pemberdayaan ipteks bagi masyarakat.
7. Memperluas akses pendidikan bagi masyarakat.
8. Menciptakan lingkungan hidup yang sehat dan produktif.
2.3 Ruang Lingkup Bagian Pusat Pelayanan Tugas Akhir
Pusat pelayanan tugas akhir STIKOM Surabaya adalah sebuah bagian dari
STIKOM Surabaya yang menangani mahasiswa yang akan dan sedang mengerjakan
tugas akhir di STIKOM Surabaya.
2.4 Tugas dan Fungsi Bagian Peneltian Akademik
Pusat Pelayanan Tugas Akhir STIKOM Surabaya memiliki tugas dan fungsi
yaitu membantu mahasiswa dalam melaksanakan tugas akhir. Mulai dari menerima
proposal tugas akhir, menentukan jadwal sidang proposal tugas akhir, menentukan
dosen penguji untuk sidang proposal, pelaksanaan sidang proposal tugas akhir,
2.5 Struktur Organisasi PPTI
CIO / KABAG
IT SERVICES R&D
TEKNOLOGI SI TEKNOLOGI
INFRASTRUKTUR USER SERVICES
SYSTEM ANALYST
DBA
PROGRAMMER
SYSTEM TESTING
SYSTEM INTEGRATOR
NETWORK ADMINISTRATOR
INFRASTRUKTUR SERVICES
APPLICATION SERVICES
HELP DESK
BAB III LANDASAN TEORI
3.1 Sistem
Menurut Soendoro dan Haryanto (2005), definisi dari sistem dapat
dilakukan dengan 2 pendekatan, yaitu pendekatan prosedur dan pendekatan
komponen. Dengan pendekatan prosedur yang mempunyai tujuan tertentu. Dengan
pendekatan komponen, system merupakan kumpulan dari komponen-komponen
yang saling berkaitan untuk mencapai tujuan tertentu.
3.2 Sistem Informasi
Menurut Soendoro dan Haryanto (2005), sistem informasi adalah elemen
dari sistem yang terdiri dari tujuan, masukan, keluaran, proses, mekanisme
pengendali dan umpan lingkungan dan system yang lain.
1. Tujuan
Tujuan merupakan pedoman system untuk melaksanan tugas serta
merupakan pemacu untuk mencapai hasil tertentu. Sesuai dengan keberagaman
system, setiap system tidak mempunyai tujuan yang identik sama persis. Meskipun
berbeda-beda system, namun secara umum tujuan dari sebuah system menurut Hall
(2001) adalah sebagai berikut.
• Untuk mendukung organisasi dari system tersebut
• Untuk menentukan pengambilan keputusan dari system
• Untuk menentukan arah kegiatan dari operasi perusahaan
2. Masukan
Masukan (input) adalah segala sesuatu yang dimasukkan kedalam
karakter-karakter huruf maupun berupa numerik. Data ini diproses dengan metode-metode
tertentu dan akan menghasilkan output yang berupa informasi yang dihasilkan dapat
berupa laporan atau report maupun solusi dari proses yang telah dijalankan.
3. Proses
Semua bahan yang dimasukan kedalam system akan diolah atau diproses
menjadi output, yaitu informasi yang berguna bagi pemakainya. Kegiatan yang ada
dalam proses meliputi, mencatat, mengklasifikasi, menghitung, menganalisis,
membuat hipotesa dan perkiraan-perkiraan, menarik kesimpulan, serta membuat
keputusan. Hasil proses ini akan diberikan pada bagian berikutnya yaitu output.
4. Keluaran
Keluaran (output) diterima dari proses yang dihasilkan. Hasil dari proses
bisa berupa informasi, laporan, gambar, dan grafik.
5. Batas
Batas merupakan pemisah antara system dengan daerah diluar system.
System yang berada diluar system disebut lingkungan. Ada 8 elemen lingkungan
yang mempengaruhhi system yaitu pemasok, pelanggan, serikat pekerja, masyarakat
keuangan, pemegang saham atau pemilik, pesaing, pemerintah, masyarakat global.
3.3 Oracle
Menurut Imam Heryanto dan Budi Raharjo (2009), oracle merupakan
software database yang bisa menampung serta mengelola data dengan kapasitas yang
sangat besar serta dapat mengaksesnya dengan sangat cepat. Sintak SQL nya hamper
seluruhnya telah memenuhi standar ANSI-92, lebih memudahkan para programmer
database dalam membangun aplikasi baik dari sisi ‘back end’ maupun dari sisi ’front
3.4 Database
Menurut Marlinda (2004), database adalah suatu susunan/kumpulan data
operasional lengkap dari suatu organisasi/perusahaan yang diorganisir/dikelola dan
disimpan secara terintegrasi dengan menggunakan metode tertentu menggunakan
komputer sehingga mampu menyediakan informasi optimal yang diperlukan
pemakainya.
3.5 Unified Modeling Language (UML)
Menurut Sholiq (2010), Notasi UML dibuat sebagai kolaborasi dari Grady
Booch, DR. James Rumbaugh, Ivar Jacobson, Rebecca Wirfs-Brock, Peter Yourdon,
dan lainnya. Jacobson telah menulis tentang bagaimana mendapatkan
persyaratan-persyaratan system dalam paket-paket transaksi yang disebut use case. Ia juga
mengembangkan sebuah metode untuk perancangan system yang disebut
Object-Oriented Software Enginnering (OOSE) yang berfokus pada analisis. Booch,
Rumbaugh, dan Jacobson disebut tiga sekawan.
Penggabungan beberapa metode menjadi UML dimulai tahun 1993. Setiap
orang dari tiga sekawan mulai menggabungkan idenya dengan metode-metode lain
yang ada saat itu. Akhir tahun 2005 Unified Method versi 0.8 diperkenalkan. Unified
method diperbaiki dan diubah menjadi UML pada tahun 1996, UML 1.0 disahkan
dan diberikan pada Object Technology Group (OGT) pada tahun 1997. Pada tahun
yang sama UML 1.1 dirilis sebagai standar industri.
3.6 Pemodelan Bisnis
Menurut Sholiq (2010), Kata pemodelan bisnis diterjemahkan dari kata
Business Modeling, kata business berasal dari kata “busy+ness” yang berarti
Modeling berarti pemodelan, sehingga kata pemodelan bisnis secara singkat
diterjemahkan menjadi “pemodelan kegiatan”.
Mencermati makna harfiah pemoelan bisnis yang berarti proses
memodelkan kegiatan-kegiatan, tentu saja, kegiatan pada kontek ini adalah kegiatan
organisasi. Dengan demikian, maka pemodelan bisnis adalah studi tentang organisasi
dan aktivitasnya.
Singkatnya, pemodelan bisnis mencoba memahami apa yang ada di dalam
dan di luar bisnis, bagaimana mereka yang ada di dalam dan di luar organisasi
berkomunikasi satu sama lain untuk menjalankan kegiatan-kegiatan tertentu.
Informasi-informasi ini akan didookumentasikan ke suatu model bisnis.
Elemen-elemen yang digunakan untuk membuat model bisnis adalah :
A. Aktor bisnis
Aktor bisnis adalah seseorang atau sesuatu yang ada di luar organisasi. Ia
berinteraksi dengan organisasi dan terlibat dalam kegiatan bisnis organisasi.contoh
actor bisnis antara lain: pelanggan, kreditor, investor, atau pemasok. Jadi posisi
mereka di luar organisasi yang sedang dimodelkan, tetapi terlibat dalam kegiatan
organisasi. Aktor bisnis dimodelkan dengan menggunakan ikon berikut:
B. Pekerja Bisnis
Pekerja bisnis adalah suatu peran (role) di dalam organisasi, bukan posisi
atau jabatan. Seseorang bisa memainkan banyak peran tetapi memegang hanya satu
posisi.
C. Use case Bisnis
Sebuah use case bisnis adalah model yang digunakan untuk
menggambarkan sebuah proses bisnis organisasi. Dengan kata lain, use case bisnis
menginformasikan tentang aktifitas bisnis utama yang organisasi lakukan. Dengan
UML, digunakan symbol seperti di bawah ini :
Gambar 3.2 Use Case Bisnis
D. Relasi Asosiasi dan Generalisasi
Relasi asosiasi adalah relasi antara actor bisnis atau pekerja bisnis dan use
case bisnis. Relasi asosiasi mengindikasi bahwa actor bisnis atau pekerja bisnis
tertentu berkomunikasi terhadap fungsionalitas yang disediakan dalam use case
Gambar 3.3 Relasi Asosiasi
Relasi generalisasi digunakan ketika ada dua atau lebih actor bisnis, pekerja
bisnis, atau use case bisnis yang serupa. Berikut adalah symbol untuk relasi
generalisasi:
Gambar 3.4 Relasi Generalisasi
E. Entitas Bisnis
Entitas bisnis adalah obyek yang digunakan atau yang dihasilkan oleh
organisasi saat melakukan aktifitas bisnis. Entitas bisnis meliputi sesuatu yang
pekerja bisnis hadapi sehari-hari. Misalnya daftar penjualan, daftar akun. Berikut
Gambar 3.5 Entitas Bisnis
F. Diagram Use Case Bisnis
Diagram Use case bisnis menunjukkan interaksi antar actor bisnis atau
pekerja bisnis dan usecase bisnis dalam sebuah organisasi. Diagram ini
menggambarkan model bisnis lengkap tentang apa yang perusahaan lakukan, siapa
yang ada di dalam organisasi, dan siapa yang ada di luar organisasi. Dengan diagram
bisnis, dapat secara cepat memberikan informasi tingkat tinggi tentang bisnis apa
yang organisasi lakukan tanpa semua rincian dari masing-masing proses bisnis yang
membingungkan pembaca dengan menyajikan terlalu banyak notasi.
G. Digram Aktivitas
diagram aktivitas menggambarkan aliran fungsionalitas system. Ada 2
kegunaan diagram aktivitas dalam pemodelan dengan UML :
1. Pada tahap pemodelan bisnis , diagram aktivitas dapat digunakan untuk
menunjukkan alur kerja bisnis (business workflow).
2. Pada tahap pemodelan system, diagram aktivitas dapat digunakan untuk
menjelaskan aktivitas yang terjadi di dalam sebuah use case.
Diagram aktivitas mendefinisikan dari mana workflow di mulai, di mana
yang dilakukan saat sebuah aktivitas terjadi. Aktivitas adalah tugas yang dilakukan
selama dalam workflow.
Diagram Aktivitas adalah sebuah cara untuk memodelkan alur kerja
(workflow) dari use case bisnis ke dalam bentuk grafik.
H. Unit Organisasi
Unit Organisasi dapat diartikan sebagai kumpulan pekerja bisnis, entitas
bisnis, atau elemen-elemen pemodelan bisnis lainnya.
3.7 Pemodelan Use Case Sistem
Menurut Sholiq (2010), suatu pemodelan use case system berkonsentrasi
pada system perangkat lunak yang sedang dikembangkan. Berikut adalah
elemen-elemen yang terkandung dalam pemodelan use case system:
A. Actor
Pada pemodelan system, actor memiliki arti yang berbeda dengan
pemodelan bisnis, actor bisa berupa seseorang atau apa saja yang berhubungan
dengan system yang sedang dibangun. Berikut adalah notasi actor:
B. Use Case Sistem
Use case system menggambarkan bagaimana seseorang sebagai pengguna
berinteraksi dengan system. Use case system dapat dikatakan sebagai fungsi-fungsi
atau fitur-fitur apa saja yang disediakan oleh system informasi yang akan dibangun
kepada pengguna. Use case juga bisa meliputi fitur apa saja yang yang pengguna
dapat lakukan terhadap system. Berikut adalah notasi use case system:
Gambar 3.7 Use Case Sistem
C. Diagram Use Case Sistem
Menurut Sholiq (2010), diagram use case menyajikan interaksi antara use
case dan actor dalam system yang dikembangkan. Use case sendiri adalah
fungsionalitas atau persyaratan-persyaratan system yang harus dipenuhi oleh system
yang akan dikembangkan tersebut menurut pandangan pemakai system.
D. Flow Of Event
Detail spesifik use case ditulis dalam flow of event. Tujuan flow of events
adalah untuk mendokumentasikan aliran logika dalam use case, yang menjelaskan
secara rinci apa yang pemakai akan lakukan dan apa yang system itu sendiri lakukan.
• Diskripsi singkat
Menjelaskan apa yang akan system lakukan. Deskripsi singkat harus
singkat dan langsung ke focus persoalan. • Prasyarat
Prasyarat adalah kondisi yang harus dipenuhi sebelum sebuah use case
dijalankan. • Alur utama
Alur utama adalah jalur utama dalam use case yang membawa tercapainya
tujuan utama sebuah use case. • Alur alternative
Alur alternative adalah penyimpangan dari alur utama dan bukan sebagai
kondisi yang salah. • Alur Salah
Alur salah adalah alur yang menyatakan penyimpangan dari alur utama atau
alur alternative yang menyatakan kondisi error dari system.
E. Diagram Kelas
Menurut Sholiq (2010), Diagram Kelas menunjukkan interaksi antar
kelas-kelas dalam system. Kelas juga dapat dianggap sebagai cetak biru dari obyek-obyek
di dalam system.
F. Diagram StateChart
Menurut Sholiq (2010), Diagram statechart menunjukkan siklus hidup
sebuah obyek tunggal, dari saat dibuat sampai obyek tersebut dihapus. Diagram ini
G. Diagram Komponen
Menurut Sholiq (2010), Diagram komponen adalah diagram UML yang
menampilkan komponen dalam system dan hubungan antara mereka. Dengan
diagram komponen, seseorang yang bertanggung jawab untuk mengkompilasi dan
men-deploy system akan tahu, kode pustaka mana saja yang dikompilasi lebih dulu
sebelum yang lainnya dikompilasi. Jadi diagram komponen salah satunya berguna
untuk mengetahui urutan kompilasi terhadap komponen-komponen yang akan
dibuat.
H. Diagram Deployment
Menurut Sholiq (2010), Diagram deployment segala hal yang berkaitan
dengan penyebaran fisik aplikasi. Hal ini termasuk persoalan layout jaringan dan
lokasi komponen-komponen dalam jaringan.
Diagram deployment berisikan prosesor-prosesor, peralatan-peralatan,
proses-proses, dan hubungan antar prosesor atau antar peralatan. Hanya ada satu
diagram deployment dalam setiap system, sehingga hanya ada satu diagram
deployment dalam setiap model.
3.8 Entity Relational Diagram
Menurut Marlinda (2004), Entity Relational Diagram (ERD) merupakan
penggambaran hubungan antara beberapa entity yang digunakan untuk merancang
3.9 Web
Menurut Jill dan Matthew (1997), web merupakan system yang
menyebabkan pertukakaran data di Internet menjadi mudah dan efisien. Web terdiri
atas dua komponen dasar yaitu :
• Server Web : sebuah computer dan software yang menyimpan dan
mendistribusikan data ke computer lainnya (yang meminta informasi) melalui
internet.
• Browser Web : software yang dijalankan pada computer pemakai (client) yang
meminta informasi dari server Web dan menampilkannya sesuai dengan file data
itu sendiri.
3.10 World Wide Web
Menurut Jill dan Matthew (1997), World Wide Web merupakan jaringan
dokumen yang sangat besar yang saling dihubungkan satu sama lain; satu set
protocol yang mendefinisikan bagaimana system bekerja dan mentransfer data; dan
sebuah software yang membuatnya bekerja dengan mulus. Web menggunakan teknik
hypertext dan multimedia yang membuat internet mudah digunakan, dijelajahi, dan
dikontribusikan.
3.11 Keamanan Informasi
Menurut Purbo (2001), Sistem keamanan informasi memilki empat macam
tujuan yang sangat mendasar yaitu : • Confidentiality
Menjamin apakah informasi yang dikirim tersebut tidak dapat dibuka atau
• Integrity
Menjamin konsistensi data tersebut apakah dia itu masih utuh sesuai aslinya
atau tidak (palsu/tidak), sehingga upaya orang-orang yang tidak bertanggung jawab
untukn melakukan penduplikatan dan perusakan data bisa dihindari. • Availability
Menjamin pengguna yang sah agar bisa mengakses informasi dan sumber
miliknya sendiri. Tujuannya adalah untuk memastikan bahwa orang-orang yang
memang berhak, tidak ditolak untuk mengakses informasi yang menjadi haknya. • Legitimate Use
Menjamin kepastian bahwa sumber tidak digunakan (informasi tidak
diakses) oleh orang-orang yang tidak bertanggung jawab (orang-orang yang tidak
BAB IV ANALISA DAN DESAIN SISTEM
4.1 Analisa Sistem
Sebelum melakukan desain sistem yang akan dibuat, maka langkah yang
pertama kali dilakukan yaitu menganalisis kebutuhan sistem. Di dalam tahapan
analisis ini berisikan identifikasi proses-proses yang terjadi saat ini di Pusat
Pelayanan Tugas Akhir STIKOM Surabaya. Proses identifikasi ini meliputi data-data
yang akan diolah, kebutuhan dari solusi permasalahan, dan output yang akan
dihasilkan.
Dari data-data yang diperoleh dari PPTA STIKOM Surabaya, selanjutnya
mengidentifikasi data-data tersebut agar dapat dirumuskan solusi-solusi yang
ditawarkan untuk mengatasi permasalahan yang ada. Dari perumusan tersebut,
kemudian menggambarkan terlebih dahulu output yang akan dihasilkan dari solusi.
Setelah gambaran singkat solusi diberikan kepada PPTA dan penyelia PPTI
Stikom Surabaya. Maka langkah selanjutnya yaitu dengan mendesain sistem dari
usecase bisnis, usecase system, activity diagram, flow of event, diagram sekuensial,
ERD, struktur tabel desain I/O (input-output), desain Interface.
4.2 Desain Sistem
Berdasarkan analisa yang telah dilakukan, maka dibuatlah system yang
baru. Sistem yang baru tersebut dapat digambarkan pada Use case Bisnis berikut ini :
4.2.1 Use Case Bisnis
Diagram use case bisnis menunjukkan interaksi antara actor bisnis atau pekerja
bisnis dan use case bisnis dalam sebuah organisasi. Diagram ini menggambarkan
model bisnis lengkap tentang apa yang perushaaan lakukan, siapa yang ada dalam
organisasi, dan siapa yang ada di luar organisasi. Hal ini menggambarkan ruang
lingkup organisasi, sehingga dapat apa/siapa saja yang ada di luar organisasi dan
sampai di mana batasannya.
4.2.1.1 Use Case Bisnis Penjadwalan Sidang Proposal Tugas Akhir
Berikut ini adalah gambar use case bisnis untuk penjadwalan sidang
proposal tugas akhir.
Gambar 4.1 Use Case Bisnis PPTA
Diagram use case bisnis untuk penjadwalan sidang proposal tugas akhir
diberikan pada gambar 4.1. Ada 5 proses bisnis yang dilakukan pada penjadwalan
sidang proposal tugas akhir, yaitu : pembuatan proposal tugas akhir, pendaftaran
proposal tugas akhir, penentuan dosen penguji, penjadwalan sidang proposal tugas
akhir, sidang proposal tugas akhir, dan penyerahan proposal revisi (ACC).
Keterangan tentang masing-masing use case bisnis pada gambar 4.1 akan diberikan
Tabel 4.1 Keterangan Use Case Bisnis: Penjadwalan Sidang Proposal Tugas Akhir
No Use Case Bisnis Aktor/pekerja
bisnis yang terlibat Keterangan
1. Pembuatan proposal
tugas akhir
Mahasiswa dan
dosen pembimbing
Proposal tugas akhir yang telah dibuat
oleh mahasiswa, kemudian diperiksa dan
di ACC oleh dosen pembimbing
2. Pemdaftaran
proposal tugas akhir
Mahasiswa dan
PPTA
Proposal tugas akhir yang telah dibuat
dan di ACC oleh dosen pembimbing
kemudian didaftar pada bagian PPTA
3. Penentuan dosen
penguji
PPTA dan kaprodi Data mengenai mahasiswa yang akan
melaksanakan sidang proposal tugas
akhir akan diberikan kepada kaprodi
untuk dicarikan dosen pembimbing yang
tepat.
4. Penjadwalan sidang
proposal tugas akhir
PPTA dan
mahasiswa
Data lengkap mengenai adanya sidang
proposal tugas akhir kemudian
dijadwalkan oleh bagian PPTA. Dan
mahasiswa dapat melihat hasil
penjadwalan sidang proposal tugas akhir.
5. Sidang proposal
tugas akhir
Mahasiswa, dosen
pembimbing, dosen
penguji
Sesuai dengan jadwal sidang proposal
tugas akhir, kemudian mahasiswa
melakukan sidang proposal tugas akhir
bersama dosen pembimbing dan penguji
6. Penyerahan proposal
revisi (ACC)
Mahasiswa dan
PPTA
Jika hasil sidang adalah ACC revisi,
maka mahasiswa harus merevisi ulang
proposal tugas akhir dan myerahkan
kembali pada bagian PPTA.
4.2.2 Activity Diagram
Diagram aktifitas (activity diagram) adalah sebuah cara untuk memodelkan
alur kerja (workflow) dari use case bisnis dalam bentuk grafik. Digram ini
kerja, siapa yang bertanggung jawab menyelesaikan masing-masing aktifitas, dan
obyek-obyek yang digunakan dalam alur kerja.
4.2.2.1 Activity Diagram Pembuatan Proposal
Berikut adalah diagram aktivitas untuk pembuatan proposal :
Gambar 4.2 Activity Diagram Pembuatan Proposal
Proses pembuatan proposal adalah mahasiswa membuat proposal tugas
akhir, kemudian meminta dosen pembimbing untuk melakukan ACC proposal tugas
akhir. Sebelum langsung di ACC, dosen pembimbing harus mengecek dan menelliti
proposal terlebih dahulu. Jika masih salah, maka mahasiswa harus melakukan revisi
terlebih dahulu. Jika sudah benar, maka dosen pembimbing dapat langsung
4.2.2.2 Activity Diagram Pendaftaran Proposal
Gambar 4.3 Activity Diagram Pendaftaran Proposal
Pada gambar 4.3 yaitu activity diagram pendaftaran proposal, mahasiswa
yang telah mendapatkan ACC dari dosen pembimbing dapat menyerahkan ke bagian
4.2.2.3 Activity Diagram Penjadwalan Sidang Proposal Tugas Akhir
Gambar 4.4 Activity Diagram Penjadwalan Sidang Proposal TA
Proses yang terjadi pada penjadwalan sidang proposal tugas akhir yaitu
dijadwalkan oleh bagian PPTA untuk melakukan sidang proposal tugas akhir.
Namun, yang berhak menentukan siapa yang akan menjadi dosen penguji adalah
kaprodi atau coordinator PPTA. Jadi, PPTA hanya mengentrikan nim, nik dosen
pembimbing, judul proposal tugas akhir, tanggal, dan ruang tempat sidang
berlangsung.
Setelah itu, PPTA mencetak jadwal sidang proposal TA sementara, yang
belum berisikan nama dosen penguji untuk diberikan kepada kaprodi atau
coordinator PPTA untuk ditentukan siapa yang akan menjadi dosen penguji.
Kemudian tugas bagian PPTA adalah menghubungi dosen penguji yang telah
ditentukan oleh kaprodi. Apakah dosen tersebut bersedia untuk menjadi penguji
ataukah tidak. Jika tidak bersedia, maka PPTA akan menghubungi kaprodi untuk
dicarikan pengganti dosen penguji. Jika dosen penguji telah setuju, maka PPTA akan
konfirmasi dengan dosen penguji dan pembimbing untuk mencarikan waktu yang
tepat untuk melaksanakan sidang proposal tugas akhir.
Dan jika dosen penguji dan waktu pelaksanaan sidang telah ditentukan, maka
PPTA akan meng-update jadwal sidang proposal tugas akhir. Maka setelah itu
mahasiswa dapat melihat jadwal kapan dilaksanakannya sidang proposal tugas akhir
4.2.2.4 Activity Diagram Sidang Proposal Tugas Akhir
Gambar 4.5 Activity Diagram Sidang Proposal Tugas Akhir
Untuk melakukan sidang proposal tugas akhir, mahasiswa menyiapkan
bahan-bahan untuk dipresentasikan. Setelah presentasi, berupa sesi tanya jawab
dengan dosen penguji dan pembimbing. Tugas dari dosen pembimbing adalah
mencatat berita acara presentasi proposal tugas akhir. Yang berisi
mahasiswa. Hasil akhirnya adalah keputusan mengenai proposal tugas akhir apakah
langsung di setujui (ACC), perlu revisi (ACC bersyarat), atau mungkin ditolak.
4.2.2.5 Activity Diagram Penyerahan Revisi Proposal Tugas Akhir
Gambar 4.6 Activity Diagram Penyerahan Revisi Proposal Tugas Akhir
Mahasiswa yang mendapatkan ACC bersyarat akan merevisi proposal tugas
akhirnya sesuai dengan yang telah disidangkan. Hasil dari revisi tersebut diberikan
kepada dosen pembimbing dan penguji untuk dikoreksi dan di ACC. Jika maswih
belum benar, maka mahasiswa harus melakukan revisi ulang. Jika telah sesuai, maka
dosen pembimbing dan penguji akan memberikan ACC. Proposal dengan ACC dari
dosen pembimbing dan penguji, akan diberikan kepada PPTA.
4.2.3 Use Case Sistem
Pada pemodelan bisnis ada istilah: actor bisnis, use case bisnis, relasi,
case system. Perbedaan utama adalah jika pada pemodelan bisnis berfokus pada
organisasi, sedangkan pada pemodelan system berkonsentrasi pada system perangkat
lunak yang sedang dikembangkan.
4.2.3.1 Penjadwalan Sidang Proposal Tugas Akhir
Gambar 4.7 Use Case Sistem Penjadwalan Sidang Proposal Tugas Akhir
Diagram use case sistem untuk penjadwalan sidang proposal tugas akhir
diberikan pada gambar 4.7. Ada 9 proses bisnis yang dilakukan pada penjadwalan
sidang proposal tugas akhir, yaitu : login admin, entri nim dan nama mahasiswa,
entri judul proposal, entri tanggal, waktu, dan ruang pelaksanaan sidang proposal,
entri nama dosen pembimbing dan penguji, entri status proposal tugas akhir, simpan
data sidang proposal tugas akhir, mencetak jadwal sidang proposal tugas akhir, dan
cek jadwal sidang proposal tugas akhir. Keterangan tentang masing-masing use case
Tabel 4.2 Keterangan Use Case Sistem: Penjadwalan Sidang Proposal Tugas Akhir
No Use Case Bisnis Aktor/pekerja
bisnis yang terlibat Keterangan
1. Login admin PPTA Sebelum masuk kedalam system, bagian
PPTA harus login terlebih dahulu.
Fungsinya sebagai pengaman dari
pengguna asing.
2. Entri nim dan nama
mahasiswa
PPTA Memasukkan data mahasiswa yang akan
melaksanakan sidang proposal TA
3. Entri judul proposal PPTA Memasukkan judul proposal tugas akhir
sesuai yang diajukan
4. Entri tanggal, waktu,
dan ruang
pelaksanaan sidang
PPTA Memasukkan data tanggal, waktu, dan
ruang untuk pelaksanaan sidang proposal
tugas akhir
5. Entri nama dosen
pembimbing dan
penguji
PPTA Memasukan nama dosen yang menjadi
pembimbing dan yang akan menjadi
penguji
6. Entri status PPTA Memasukkan status proposal tugas akhir.
Apakah belum sidang, ACC, ACC
bersyarat, ataukah di tolak
7. Simpan data jadwal
sidang proposal
tugas akhir
PPTA Menyimpan seluruh data-data mengenai
sidang proposal tugas akhir yang telah di
entrikan.
8. Mencetak jadwal
sidang proposal
tugas akhir
PPTA, dosen
pembimbing, dan
dosen penguji
Mencetak jadwal sidang yang telah
disimpan untuk diberikan kepada dosen
pembimbing dan penguji sebagai
pemberitahuan.
9. Cek jadwal sidang mahasiswa Mengecek jadwal yang telah disimpan
oleh PPTA
4.2.4 Flow Of Event (FOE)
Detail spesifikasi use case ditulis dalam flow of event. Tujuan utama flow of
events adalah untuk mendokumentasikan aliran logika dalam use case yang, yang
menjelaskan secara rinci apa yang pemakai akan lakukan dan apa yang system itu
Sistematika flow of events terdiri dari beberapa elemen berikut :
1. Diskripsi singkat
2. Prasyarat
3. Alur utama
4. Alur alternative dan alur salah
5. Kondisi akhir
4.2.4.1 FOE Use Case Login User
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
login user:
Tabel 4.3 FOE Use Case Login User Deskripsi Use Case
Nama Use Case Login User
Diskripsi Singkat Use case login user digunakan untuk keamanan system. Agar tidak sembarang user bisa masuk ke dalam system
dan mengendalikan system
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Memasukkan username dan password 2. Verifikasi password
Alur Alternatif Tidak ada
Kondisi Akhir Sukses Proses login user berhasil dilakukan. Maka PPTA diberikan hak akses sesuai kebijakan.
4.2.4.2 FOE Use Case Entri Nim dan Nama Mahasiswa
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
entri nim dan nama mahasiswa:
Tabel 4.4 FOE Use Case Entri NIM dan Nama Mahasiswa Deskripsi Use Case
Nama Use Case Entri Nim dan Nama Mahasiswa
Diskripsi Singkat Use case entri nim dan nama mahasiswa digunakan untuk menetapkan nim dan nama mahasiswa yang akan
melakukan sidang proposal TA pada waktu yang
ditentukan
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Memasukkan nim mahasiswa
2. Tampil nama mahasiswa sesuai nim yang
diinputkan
Alur Alternatif 2.1Display mahasiswa tidak ada, maka muncul peringatan dan actor kembali ke langkah 1
Kondisi Akhir Sukses Nama mahasiswa berhasil tampil beserta nim yang tadi dientrikan
Kondisi Akhir Gagal Jika salah memasukkan nim, maka nama mahasiswa tidak akan tampil dan terdapat pesan error
4.2.4.3 FOE Use Case Entri Judul Proposal
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
Tabel 4.5 FOE Use Case Entri Judul Proposal Deskripsi Use Case
Nama Use Case Entri Judul Proposal
Diskripsi Singkat Use case entri judul proposal digunakan untuk memasukkan judul proposal TA yang sudah diajukan
oleh mahasiswa dan akan ditetapkan jadwal untuk
melakukan sidang.
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Memasukkan judul proposal TA
2. Tampil judul proposal yang telah dientrikan
Alur Alternatif Tidak ada
Kondisi Akhir Sukses Judul proposal berhasil tampil Kondisi Akhir Gagal -
4.2.4.4 FOE Use Case Entri Tanggal, Waktu, dan Ruang Pelaksanaan Sidang Proposal
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
entri tanggal, waktu, dan ruang pelaksanaan sidang proposal:
Tabel 4.6 FOE Use Case Entri Tanggal, Waktu, dan Ruang Pelaksanaan Sidang
Deskripsi Use Case
Nama Use Case Entri Tanggal, Waktu, dan Ruang Pelaksanaan Sidang Proposal
dan di mana mahasiswa akan melakukan sidang proposal
TA
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Menginputkan tanggal, waktu, dan ruang 2. Tampil tanggal, waktu, dan ruang yang telah
ditetapkan
Alur Alternatif -
Kondisi Akhir Sukses Tanggal , waktu, dan ruang berhasil tampil Kondisi Akhir Gagal -
4.2.4.5 FOE Use Case Entri Nama Dosen Pembimbing dan Penguji
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
entri nama dosen pembimbing dan penguji:
Tabel 4.7 FOE Use Case Entri Nama Dosen Pembimbing dan Penguji
Deskripsi Use Case
Nama Use Case Entri Nama Dosen Pembimbing dan Penguji
Diskripsi Singkat Use case entri nama dosen pembimbing dan penguji digunakan untuk memasukkan nama dosen yang akan
menjadi pembimbing sesuai dengan proposal yang telah
diajukan ke bagian PPTA
Aktor PPTA
Prasyarat (kondisi) Tidak ada
2. Tampil nama dosen pembimbing beserta NIK
dosen
Alur Alternatif 2.1 Display NIK tidak tampil, actor mengkonfirmasi dan kembali ke langkah 1
Kondisi Akhir Sukses Nama dan NIK dari dosen pembimbing berhasil tampil Kondisi Akhir Gagal Jika nama tidak terdaftar / salah, maka muncul pesan
peringakatan dan NIK tidak akan muncul
4.2.4.6 FOE Use Case Entri Status Sidang Proposal Tugas Akhir
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
entri status sidang proposal tugas akhir:
Tabel 4.8 Use Case Entri Status Sidang Proposal Tugas Akhir
Deskripsi Use Case
Nama Use Case Entri Status Sidang Proposal Tugas Akhir
Diskripsi Singkat Use case entri status sidang proposal tugas akhir digunakan untuk member tanda mengenai sidang
proposal tugas akhir tersebut. Apakah telah
melaksanakan sidang, proposal ditolak, ataukah
membutuhkan revisi.
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Mengentrikan status sidang proposal tugas akhir 2. Tampil status sidang proposal TA
Kondisi Akhir Sukses Status berhasil dientrikan Kondisi Akhir Gagal -
4.2.4.7 FOE Use Case Simpan Data Jadwal Sidang Proposal Tugas Akhir Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
simpan data jadwal sidang proposal tugas akhir:
Tabel 4.9 FOE Use Case Simpan Data Jadwal Sidang Proposal Tugas Akhir
Deskripsi Use Case
Nama Use Case Simpan Data Jadwal Sidang Proposal Tugas Akhir Diskripsi Singkat Use case simpan data jadwal sidang proposal tugas akhir
digunakan untuk menyimpan data-data mengenai sidang
proposal TA yang sebelumnya telah dientrikan.
Aktor PPTA
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Menyimpan data-data jadwal sidang proposal tugas akhir yang telah dientrikan
2. Tampil data mengenai jadwak sidang proposal TA
Alur Alternatif -
Kondisi Akhir Sukses Jadwal sidang proposal TA berhasil disimpan dan ditampilkan
Kondisi Akhir Gagal -
4.2.4.8 FOE Use Case Cek Jadwal Sidang Proposal
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
Tabel 4.10 FOE Use Case Cek Jadwal Sidang
Deskripsi Use Case
Nama Use Case Cek Jadwal Sidang Proposal TA
Diskripsi Singkat Use case cek jadwal sidang proposal digunakan untuk mengecek jadwal kapan sidang proposal dilaksanakan
oleh mahasiswa
Aktor Mahasiswa
Prasyarat (kondisi) Tidak ada
Alur Utama 1. Membuka web PPTA
2. Membuka menu jadwal sidang proposal TA
3. Tampil NIM, nama mahasiswa, judul proposal,
nama dosen pembimbing, tanggal, dan waktu
pelaksanaan sidang proposal TA
Alur Alternatif Tidak ada
Kondisi Akhir Sukses Jadwal sidang proposal berhasil tampil Kondisi Akhir Gagal -
4.2.4.9 FOE Use Case Mencetak Jadwal Sidang Proposal Tugas Akhir
Berikut ini adalah tabel flow of event yang menjelaskan mengenai use case
mencetak jadwal sidang proposal tugas akhir:
Tabel 4.11 FOE Use Case Mencetak Jadwal Sidang Proposal Tugas Akhir
Deskripsi Use Case
Nama Use Case Mencetak Jadwal Sidang Proposal Tugas Akhir
pembimbing dan penguji mengenai jadwal sidang
proposal tugas akhir
Aktor PPTA, Dosen Pembimbing, Dosen Penguji Prasyarat (kondisi) Tidak ada
Alur Utama 1. Cek jadwal sidang proposal TA 2. Cetak data jadwal sidang proposal TA
Alur Alternatif Tidak ada
Kondisi Akhir Sukses Informasi jadwal sidang proposal TA berhasil dicetak Kondisi Akhir Gagal -
4.2.5 Diagram Sekuensial
Diagram Sekuensial adalah diagram interaksi yang disusun berdasarkan
urutan waktu. Digram sekuensial dibaca dari atas ke bawah. Setiap use case memiliki
sejumlah flow (utama dan alternative). Setiap diagram sekuensial merepresentasikan
satu flow dari beberapa flow di dalam use case.
4.2.5.1 Diagram Sekuensial Login User
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.8 Diagram Sekuensial Login User
Ketika login user, pertama PPTA membuka form untuk login, maka form
login memberi balasan berupa display form login. PPTA kemudian mengentrikan
username dan password, dan form login memverifikasi username dan password
kepada database. Setelah berhasil login, maka akan muncul halaman utama.
4.2.5.2 Diagram Sekuensial entri nim dan nama mahasiswa
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.9 Diagram Sekuensial Entri NIM dan Nama Mahasiswa
Untuk mengentri nim dan nama mahasiswa, pertama yang dilakukan adalah
membuka form entri jadwal sidang proposal tugas akhir. Dari form entri tersebut,
maka akan tampil display form entry. Kemudian PPTA mengentrikan nim
mahasiswa. Dari form entry kemudian di verifikasi dengan database, dan tampil nim
dan nama mahasiswa sesuai dengan nim yang telah dientrikan tadi.
4.2.5.3 Digram Sekuensial Entri Judul Proposal Tugas Akhir
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.10 Digram Sekuensial Entri Judul Proposal
Untuk mengentri judul proposal tugas akhir, pertama yang dilakukan adalah
membuka form entri jadwal sidang proposal tugas akhir. Dari form entri tersebut,
maka akan tampil display form entry. Kemudian PPTA mengentrikan nim judul
proposal tugas akhir. Dari form entry kemudian tampil judul proposal yang
dientrikan.
4.2.5.4 Diagram Sekuensial entri tanggal dan waktu pelaksanaan sidang proposal
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.11 Diagram Sekuensial Entri Tanggal dan Waktu Pelaksanaan Sidang Proposal
Untuk mengentri tanggal dan waktu pelaksanaan sidang proposal, pertama
yang dilakukan adalah membuka form entri jadwal sidang proposal tugas akhir. Dari
form entri tersebut, maka akan tampil display form entry. Kemudian PPTA
mengentrikan tanggal dan waktu pelaksanaan sidang proposal. Dari form entry
kemudian tampil tanggal dan waktu pelaksanaan sidang proposal.
4.2.5.5 Diagram Sekuensial entri nama dosen
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.12 Diagram Sekuensial Entri Nama Dosen
Untuk mengentri nik dan nama dosen, pertama yang dilakukan adalah
membuka form entri jadwal sidang proposal tugas akhir. Dari form entri tersebut,
maka akan tampil display form entry. Kemudian PPTA mengentrikan nik atau nama
dosen. Dari form entry kemudian di verifikasi dengan database, dan tampil nik dan
nama dosen sesuai dengan nik atau nama yang telah dientrikan tadi.
4.2.5.6 Diagram Sekuensial Simpan Data Jadwal Sidang Proposal Tugas Akhir Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.13 Diagram Sekuensial Entri Nama Dosen
Untuk menyimpan data jadwal sidang proposal tugas akhir, pertama yang
dilakukan adalah membuka form entri jadwal sidang proposal tugas akhir. Dari form
entri tersebut, maka akan tampil display form entry. Kemudian PPTA mengentrikan
seluruh data-data jadwal sidang proposal tugas akhir. Dari form entry kemudian
disimpan ke dalam database, dan tampil seluruh data jadwal sidang proposal tugas
akhir yang telah dientrikan tadi.
4.2.5.7 Diagram Sekuensial Cetak Jadwal Sidang Proposal Tugas Akhir
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.14 Diagram Sekuensial Cetak Jadwal Sidang Proposal
Untuk mencetak jadwal sidang proposal tugas akhir , pertama yang dilakukan
adalah membuka menu utama. Dari menu utama tersebut akan tampil seluruh
data-data jadwal sidang proposal tugas akhir. Kemudian pilih pilihan cetak untuk data-data
yang akan dicetak. Maka data akan diambil dari database dan ditampilkan dalam
bentuk pdf. Jika sudah dalam bentuk pdf, maka dapat dengan mudah dicetak.
4.2.5.8 Diagram Sekuensial Cek jadwal sidang proposal
Berikut ini adalah diagram sekuensial yang menjelaskan mengenai use case
Gambar 4.15 Diagram Sekuensial Cek Jadwal Sidang Proposal
Untuk mengecek jadwal sidang proposal tugas akhir, mahasiswa membuka
web PPTA, kemudian web PPTA akan memeberikan display halaman utama. Maka
mahasiswa akan memilih menu jadwal sidang proposal tugas akhir, maka web PPTA
akan mendisplay jadwal sidang proposal tugas akhir.
4.2.6 Diagram Kelas
Diagram kelas digunakan untuk menampilkan kelas-kelas atau paket-paket
dalam system dan relasi antara mereka. Satu diagram kelas menampilkan subset dari
kelas-kelas dan relasinya.
Digram kelas adalah alat perancangan terbaik untuk tim pengembang
kode program dan membantu untuk memastikan bahwa system adalah rancangan
terbaik dari beberapa alternative rancangan
4.2.6.1 Penjadwalan Sidang Proposal Tugas Akhir
Gambar 4.16 Diagram Kelas Penjadwalan Sidang Proposal Tugas Akhir
Pada gambar 17 di atas adalah gambar diagram kelas penjadwalan sidang
proposal tugas akhir. Proses yang terjadi adalah PPTA sebagai actor yang bertindak
untuk menjadwalkan sidang proposal tugas akhir. PPTA mengentrikan NIM, NIK,
judul, ruang sidang, tanggal, dan waktu pelaksanaan sidang pada form entry jadwal
sidang. Form entry jadwal sidang, juga mengambil data dari entitas mahasiswa dan
dosen. Setelah PPTA menjadwalkan, maka data-data jadwal sidang disimpan dalam
database dan ditampil pada jadwal sidang berupa informasi nim, nama mahasiswa,
nik, nama dosen, judul, ruang, tanggal, dan waktu pelaksanaan sidang proposal tugas
4.2.7 Diagram Statechart
Perhatikan gambar 4.17, pada kelas form jadwal sidang proposal TA
mempunyai atribut status yang digunakan untuk menyimpan keadaan atau state yang dialami obyek-obyek kelas form jadwal sidang proposal TA.
Gambar 4.17 Kelas Form Jadwal Sidang Proposal TA
Keadaan yang mungkin dialami oleh obyek-obyek kelas form jadwal sidang proposal
tugas akhir adalah sebagai berikut:
1. Belum Sidang (Baru) : bahwa jadwal sidang baru saja dijadwalkan dan
mahasiswa belum melakukan sidang.
2. ACC : bahwa mahasiswa telah melakukan sidang dan telah disetujui oleh dosen
pembimbing dan penguji.
3. ACC Bersyarat : bahwa mahasiswa telah melakukan sidang namun perlu adanya
4. Tolak : bahwa mahasiswa telah melakukan sidang namun proposal yang
diajukan tidak mendapat persetujuan oleh dosen penguji. Dan proposal tugas
akhir yang telah diajukan ditolak.
Gambar 4.18 Diagram Statechart untuk kelas form jadwal sidang proposal TA
Memperhatikan beberapa keadaan yang mungkin dialami, maka kelas form
jadwal sidang proposal TA perlu membuat diagram statechart. Seperti pada gambar
4.18, untuk state ACC bersyarat ada aksi state: do / revisi proposal TA adalah yang
perlu dilakukan oleh mahasiswa untuk merevisi proposal TA sesuai hasil sidang.
4.2.8 Diagram Komponen
Diagram komponen adalah diagram UML yang menampilkan komponen
dalam system dan hubungan antara mereka. Berikut ini adalah diagram komponen
yang menunjukkan model secara fisik komponen perangkat lunak pada system.
Penjadwalan sidang proposal tugas akhir direncanakan berbasis web untuk actor
Gambar 4.19 Diagram Komponen
Gambar 4.19 di atas menunjukkan model secara fisik komponen perangkat
lunak pada system yang akan digunakan oleh bagian PPTA dan mahasiswa
4.2.9 Diagram Deployment
Diagram Deployment menampilkan layout fisik jaringan. Diagram ini
membantu tim pengembang untuk merencanakan deployment yang akan ditawarkan.
Gambar 4.20 menyajikan diagram deployment untuk penjadwalan sidang proposal
Gambar 4.20 Diagram Deployment
Actor PPTA berkomunikasi dengan system penjadwalan sidang proposal
tugas akhir dengan menggunakan jaringan internet. Begitu juga dengan mahasiswa
melihat info mengenai jadwal sidang proposal tugas akhir melalui internet pada web
PPTA.
4.2.10 Entity Relational Model
Entity Relationship Diagram (ERD) adalah suatu desain sistem yang
digunakan untuk merepresentasikan, menentukan dan mendokumentasikan
kebutuhan-kebutuhan untuk sistem pemrosesan database. Pada gambar berikut akan
dijelaskan relasi-relasi atau hubungan antar tabel dalam aplikasi penjadwalan sidang
proposal tugas akhir STIKOM dalam bentuk conceptual data model (CDM) dan
physical data model (PDM).
4.2.10.1 Conceptual Data Model
Sebuah Conceptual Data Model (CDM) menggambarkan secara keseluruhan
konsep struktur basis data yang dirancang untuk suatu aplikasi seperti terlihat pada
MEMILI KI
4.2.10.2 Phisical Data Model
Sebuah Physical Data Model (PDM) menggambarkan secara detail konsep
rancangan struktur basis data yang dircancang untuk suatu program aplikasi. PDM
merupakan hasil generate dari CDM. Pada PDM tergambar jelas tabel-tabel
penyusun basis data beserta kolom-kolom yang terdapat pada setiap tabel
sebagaimana terlihat pada gambar 4.22.
4.2.11 Struktur Tabel
Struktur tabel akan menjelaskan tentang fungsi tabel, relasi antar tabel,
constraint, dan item-item yang terdapat dalam sebuah tabel yang dapat digunakan
sebagai gambaran dari database yang terbentuk.
A. Tabel Master
Untuk mempermudah pengelolaan data-data maka di kelompokan data-data
tersebeut sesuai dengan fungsinya. Dibawah ini akan dijelaskan kelompok tabel
yang berfungsi sebagai tabel master.
A1. Tabel Mahasiswa
Primary Key : NIM
Foreign Key : -
Fungsi : Melihat data mahasiswa
Table 4.12 Tabel Mahasiswa
Kolom Tipe Data Panjang Keterangan
Tabel 4.13 Tabel Dosen
Kolom Tipe Data Panjang Keterangan
PK FK Tabel Asal
NIK Varchar2 11
Nama Varchar2 100
B. Tabel Transaksi
Untuk mempermudah pengelolaan data maka dikelompokan data-data
tersebut sesuai dengan fungsinya. Dibawah ini akan dijelaskan kelompok tabel yang
berfungsi sebagai tabel transaksi.
B1. Tabel Jadwal Sidang
Primary Key : Kode
Foreign Key : NIK
Fungsi : Untuk menyimpan data jadwal sidang proposal tugas akhir
Tabel 4.14 Tabel Jadwal Sidang
Kolom Tipe Data Panjang Keterangan
B2. Tabel Detail Jadwal Sidang
Primary Key : Kode, NIK
Foreign Key : Kode, NIK
Fungsi : Untuk menyimpan detail data jadwal sidang proposal tugas akhir
Tabel 4.15 Tabel Detail Jadwal Sidang
Kolom Tipe Data Panjang Keterangan
PK FK Tabel Asal
Kode Varchar2 5 Jadwal sidang
NIK Varchar2 6 dosen
4.2.12 Desain Input/Output
Desain input output digunakan untuk memberikan gambaran terhadap
desain aplikasi yang akan dibangun. Berikut ini adalah desain input output dari
Aplikasi Penjadwalan Sidang Proposal Tugas Akhir STIKOM Surabaya.
4.2.12.1 Input Jadwal Sidang Proposal Tugas Akhir
Halaman input jadwal proposal tugas akhir ini digunakan untuk
memasukkan data-data mengenai mahasiswa yang mengajukan proposal tugas akhir.
Yaitu nim dan nama mahasiswa, judul tugas akhir yang diambil, dosen pembimbing,
dosen penguji, tanggal, waktu, ruang pelaksanaan sidang, dan status proposal tugas
JADWAL SIDANG PROPOSAL TA
DOSEN PEMBIMBING 2 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>
DOSEN PENGUJI 1 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>
DOSEN PENGUJI 2 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>
Gambar 4.231 Desain IO Input Jadwal Sidang Proposal Tugas Akhir
4.2.12.2 Update Jadwal Sidang Proposal Tugas Akhir
Halaman update jadwal proposal tugas akhir ini digunakan untuk
meng-update data-data mengenai mahasiswa yang mengajukan proposal tugas akhir. Yaitu
nim dan nama mahasiswa, judul tugas akhir yang diambil, dosen pembimbing, dosen
penguji, tanggal, waktu, ruang pelaksanaan sidang, dan status proposal tugas akhir
JADWAL SIDANG PROPOSAL TA
DOSEN PEMBIMBING 2 : <<NIK>> <<NAMA.. SEARCH>><<BUTTON
DOSEN PENGUJI 1 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>
DOSEN PENGUJI 2 : <<NIK>> <<NAMA.. SEARCH>><<BUTTON
TANGGAL : <<TANGGAL>>
Gambar 4.24 Desain IO Update Jadwal Sidang Proposal Tugas Akhir
4.2.12.3 Jadwal Sidang Proposal Tugas Akhir
Halaman jadwal sidang proposal tugas akhir ini digunakan sebagai laporan
mengenai data mahasiswa yang akan sidang proposal tugas akhir, untuk diberikan
JADWAL SIDANG PROPOSAL
BAB V IMPLEMENTASI SISTEM
5.1 Kebutuhan Sistem
Untuk implementasi system ini ada beberapa spesifikasi perangkat lunak
dan perangkat keras yang dibutuhkan.
5.1.1 Kebutuhan Perangkat Keras
Perangkat keras adalah komponen fisik peralatan yang membentuk system
komputer, serta peralatan lain yang mendukung komputer dalam menjalankan
tugasnya.
A. Kebutuhan Minimum Client
Untuk menjalankan aplikasi ini sebagai client membutuhkan komputer dengan spesifikasi minimum sebagai berikut:
1. Processor Pentium IV 1,8 Ghz
2. Memory dengan RAM 128 MB DDR 1
3. VGA on Board
4. Monitor Super VGA (800x600) dengan minimum 256 warna 5. Keyboard + Mouse
B. Kebutuhan Minimum Server
Untuk menjalankan aplikasi ini sebagai server membutuhkan computer
dengan spesifikasi minimum sebagai berikut:
1. Processor Pentium IV 1,8 Ghz
2. Memory dengan RAM 512 MB DDR 1
3. VGA on Board
4. Monitor Super VGA (800x600) dengan minimum 256 warna
5. Keyboard + Mouse
5.1.2 Kebutuhan Perangkat Lunak
Perangkat lunak adalah komponen non fisik yang digunakan untuk membuat
system computer dapat berjalan dan melakukan tugasnya.
A. Kebutuhan Minimum Client
Adapun perangkat lunak yang dibutuhkan dan telah diujicobakan pada
komputer client yaitu:
1. Operating Sistem: Windows XP , Linux (Ubuntu)
2. Browser: Google Chrome versi 23.0.1271.64 m dan Mozilla Firefox versi 4.0
B. Kebutuhan Minimum Server
Adapun perangkat lunak yang dibutuhkan dan telah diujicobakan pada
computer server yaitu:
1. Operating System: Linux Ubuntu 7.04
2. Web Server: Apache 2.2
3. Programming Language: PHP
4. Database: Oracle 10g
5.2 Implementasi Program
Pada sub bab ini akan dijelaskan langkah-langkah implementasi program aplikasi
A. Halaman Input Jadwal Sidang Proposal Tugas Akhir
Halaman ini digunakan untuk meng-entry kan data mengenai sidang
proposal tugas akhir. Seperti gambar 5.1 berikut ini :
Gambar 5.1 Halaman Input Jadwal Sidang Proposal Tugas Akhir
B. Halaman Pencarian Nim dan Nama Mahasiswa
Halaman ini digunakan untuk mencari nim dan nama mahasiswa, sehingga
PPTA tidak perlu meng-entry secara lengkap. Seperti gambar 5.2 berikut ini :
C. Halaman Pencarian NIK dan Nama Dosen
Halaman ini digunakan untuk mencari NIK dan nama dosen, sehingga
PPTA tidak perlu meng-entry secara lengkap. Seperti gambar 5.3 berikut ini :
Gambar 5.3 Halaman Pencarian NIK dan Nama Dosen
D. Halaman Lihat Data Jadwal Sidang Proposal Tugas Akhir
Halaman ini berisi data seluruh jadwal sidang proposal tugas akhir. Seperti
Gambar 5.4 Halaman Lihat Data Jadwal Sidang Proposal Tugas Akhir
E. Halaman Update Jadwal Sidang Proposal Tugas Akhir
Halaman ini digunakan meng-update data jadwal sidang proposal tugas
Gambar 5.5 Halaman Update Jadwal Sidang Proposal Tugas Akhir
F. Tampilan Laporan Jadwal Sidang Proposal Tugas Akhir
Halaman ini digunakan untuk mencetak laporan jadwal sidang proposal
tugas akhir untuk diberikan kepada dosen pembimbing dan penguji sebagai
pemberitahuan. Seperti gambar 5.7 berikut ini :
G. Halaman Pencarian Mahasiswa Berdasarkan Status Sidang Proposal TA Halaman ini digunakan untuk mencari data sidang proposal tugas akhir
mahasiswa berdasarkan status. Yaitu apakah berstatus ACC, ACC Revisi, Belum
Sidang, ataukah Tolak. Seperti gambar 5.6 berikut ini :
Gambar 5.6 Halaman Pencarian Mahasiswa Berdasarkan Status
H. Tampilan Laporan Daftar Sidang Proposal TA Berdasarkan Status
Halaman ini digunakan untuk melaporkan data jadwal sidang berdasarkan
status proposal TA. Yaitu apakah berstatus ACC, ACC Revisi, Belum Sidang,
