LKP : Rancang Bangun Pembuatan Aplikasi Informasi Jadwal Sidang Proposal Tugas Akhir Berbasis Web Pada Stikom Surabaya.

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

ABSTRAK ... ii

KATA PENGANTAR ...iii

DAFTAR ISI ... iv

DAFTAR TABEL ... vii

DAFTAR GAMBAR ...viii

DAFTAR LAMPIRAN ... ii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 2

1.3 Batasan Masalah ... 2

1.4 Tujuan ... 2

1.5 Kontribusi ... 3

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.1 Analisa Sistem ... 22

4.2 Desain Sistem ... 22

4.2.1 Use Case Bisnis ... 22

4.2.2 Activity Diagram ... 24

4.2.3 Use Case Sistem ... 30

4.2.4 Flow Of Event (FOE) ... 32

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 Kutisari 66 yang nantinya menjadi Kampus 1 Stikom. Peresmian gedung tersebut

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. 3. Meningkatkan kualifikasi dan kompetensi Sumber Daya Manusia.

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, hingga pelaksanaan tugas akhir dan sidang 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 end’.

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 “kegiatan” dan modeling berasal dari kata “model” mendapat akhiran “ing”.

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 bisnis. Simbol untuk relasi asosiasi adalah sebagai berikut:

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 adalah contoh entitas bisnis:

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 workflow berakhir, aktivitas apa saja yang terjadi di dalam workflow, dan apa saja

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. Sistematika flow of event terdiri dari:

• 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 adalah cara tepat untuk memodelkan perilaku dinamis sebuah kelas.

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 database yang akan diperlukan.

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 tidak dapat diketahui oleh orang lain yang tidak berhak

• 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 berhak).

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 pada tabel 4.1.

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 menunjukkan langkah-langkah di dalam alur kerja, titik-titik keputusan di dalam alur

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 memberikan ACC berupa tandatangan.

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 PPTA.

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 proposal yang sudah masuk pada PPTA dan sudah di ACC dosen pembimbing,

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 pada web PPTA.

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 kekurangan-kekurangan atau catatan penting mengenai proposal yang telah dipresentasikan oleh

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, diagram aktivitas, dan diagram use case bisnis, demikian juga pada pemodelan use

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 bisnis pada gambar 4.7 akan diberikan pada tabel 4.2.

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 sendiri lakukan.

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.

Kondisi Akhir Gagal Jika salah memasukkan password, maka user tidak dapat masuk ke dalam system

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 entri judul proposal:

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

Diskripsi Singkat Use case entri tanggal, waktu, dan ruang pelaksanaan sidang proposal TA digunakan untuk menetapkan kapan

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 cek jadwal sidang proposal tugas akhir:

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

Diskripsi Singkat Use case mencetak jadwal sidang proposal Tugas Akhir digunakan untuk memberikan informasi kepada dosen

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 login user:

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 entry nim dan nama:

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 entri judul proposal tugas akhir:

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 entri tanggal dan waktu pelaksanaan sidang:

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 entri nama dosen:

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 simpan data jadwal sidang proposal tugas akhir:

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 cetak jadwal sidang proposal tugas akhir:

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 cek jadwal sidang proposal tugas akhir:

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 mendapatkan pola kelas-kelas dalam system, struktur system sebelum menuliskan

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 akhir.

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 revisi untuk proposal yang telah diajukan mahasiswa

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 PPTA dan mahasiswa.

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 tugas akhir.

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 Gambar 4.21.

MEMILI KI MEMPUNYAI MAHASISWA NIM NAMA DOSEN NIK NAMA JADWAL_SIDANG KODE NIM NIK1 NIK2 NIK3 NIK4 JUDUL T GL_D AF T AR T GL_SIDANG T GL_SERAH WAKTU RUANG STAT US

Gambar 4.21 CDM

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.

NIK = NIK KODE = KODE

KODE = KODENIM = NIM MAHASISWA NIM varchar KODE varchar(5) NAMA varchar(100) DOSEN NIK varchar NAMA varchar(100) JADWAL_SIDANG KODE varchar(5) NIM varchar NIK1 varchar NIK2 varchar NIK3 varchar NIK4 varchar JUDUL varchar(1000) TANGGAL date WAKTU time RUANG varchar(20) STATUS varchar(20) PROPOSAL_TA KODE varchar(5) NIK varchar NIM varchar JUDUL varchar TGL_SIDANG date

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

PK FK Tabel Asal

NIM Varchar2 11 

Nama Varchar2 100

A2. Tabel Dosen

Primary Key : NIK Foreign Key : -

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

PK FK Tabel Asal

Kode Varchar2 5 

NIM Varchar2 11  Mahasiswa

NIK1 Varchar2 6  Dosen

NIK2 Varchar2 6  Dosen

NIK3 Varchar2 6  Dosen

NIK4 Varchar2 6  Dosen

Judul Varchar2 1000

Tanggal Date

Waktu Varchar2 10

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 akhir tersebut. Seperti pada gambar 4.23 betikut ini :

JADWAL SIDANG PROPOSAL TA

MAHASISWA :

DOSEN PEMBIMBING 1 :

<<NIM>> <<NIK>> SAVE <<NAMA.. <<BUTTON SEARCH>> <<NAMA.. <<BUTTON SEARCH>>

DOSEN PEMBIMBING 2 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>

DOSEN PENGUJI 1 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>

DOSEN PENGUJI 2 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>> TANGGAL : <<TANGGAL>>

WAKTU : <<WAKTU>> RUANG : <<RUANG>>

JUDUL :

<<JUDUL>>

STATUS : _<<STATUS>>

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 tersebut. Seperti pada gambar 4.24 betikut ini :

JADWAL SIDANG PROPOSAL TA

MAHASISWA :

DOSEN PEMBIMBING 1 :

<<NIM>>

<<NIK>>

UPDATE

<<NAMA.. <<BUTTON SEARCH>>

<<NAMA.. <<BUTTON SEARCH>>

DOSEN PEMBIMBING 2 : <<NIK>> <<NAMA.. _SEARCH>><<BUTTON DOSEN PENGUJI 1 : <<NIK>> <<NAMA.. <<BUTTON SEARCH>>

DOSEN PENGUJI 2 : <<NIK>> <<NAMA.. _SEARCH>><<BUTTON TANGGAL : <<TANGGAL>>

WAKTU : <<WAKTU>> RUANG : <<RUANG>>

JUDUL :

<<JUDUL>>

STATUS : <<STATUS>>

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 pada dosen pembimbing dan penguji. Seperti pada gambar 4.25 betikut ini :

JADWAL SIDANG PROPOSAL

TUGAS AKHIR

JUDUL PROPOSAL :

MAHASISWA :

DOSEN PEMBIMBING 1 : DOSEN PEMBIMBING 2 : DOSEN PENGUJI 1 : DOSEN PENGUJI 2 :

TANGGAL :

WAKTU :

RUANG :

………..

……….. (<<NIM>>) ……….. (<<NIK>>) ……….. (<<NIK>>) ……….. (<<NIK>>) ……….. (<<NIK>>)

……….. ……….. ………..

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 informasi jadwal sidang proposal tugas akhir.

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 berikut ini :

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 akhir. Seperti gambar 5.5 berikut ini :

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, ataukah Tolak. Seperti gambar 5.7 berikut ini :

Gambar 5.7 Laporan Daftar Proposal TA Berdasarkan Status

I. Halaman Pencarian Mahasiswa Berdasarkan Bulan Sidang Proposal TA Halaman ini digunakan untuk mencari data sidang proposal tugas akhir mahasiswa berdasarkan bulan pelaksanaan sidang proposal TA. Seperti gambar 5.8 berikut ini :

J. Tampilan Laporan Daftar Sidang Proposal TA Berdasarkan Bulan

Halaman ini digunakan untuk melaporkan data jadwal sidang berdasarkan bulan pelaksanaan sidang proposal TA. Seperti gambar 5.9 berikut ini :

BAB VI PENUTUP

6.1 Kesimpulan

Kesimpulan yang dapat diambil dari pembuatan aplikasi informasi jadwal sidang proposal tugas akhir STIKOM Surabaya adalah sebagai berikut :

1. Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web pada bagian PPTA STIKOM Surabaya ini merupakan aplikasi yang dapat membantu mahasiswa STIKOM Surabaya dalam hal pemberitahuan jadwal sidang proposal tugas akhir.

2. Dengan adanya Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web pada bagian PPTA STIKOM Surabaya, dapat membantu bagian PPTA STIKOM Surabaya dalam hal penjadwalan sidang proposal tugas akhir dan mencetak laporan jadwal sidang untuk diberikan kepada dosen pembimbing dan penguji sebagai pemberitahuan

6.2 Saran

Berdasarkan analisis dan perancangan sistem yang sudah dilakukan, saran yang dapat disampaikan oleh penulis untuk pembuatan aplikasi informasi jadwal sidang proposal tugas akhir yaitu:

1. Hasil analisis dan pembuatan aplikasi informasi jadwal sidang proposal tugas akhir ini dapat dikembangkan dengan membangun aplikasi sistem informasi penjadwalan sidang proposal tugas akhir

Daftar Pustaka

Soendoro Herlambang, Haryanto Tanuwijaya.2005.Sistem Informasi: Konsep Teknologi dan Manajemen.Graha Ilmu. Jogjakarta

Marlinda, Linda, S.Kom, 2004, Sistem Basis Data, Andi Offset, Yogyakarta Wulandari, Lily. 2005. Web Service. Depok : Gunadarma

Kurniawan, Budi, 2008, Desain Web dengan HTML + CSS, Andi, Yokyakarta Tamimuddin, 2006, Pemrograman Web Database menggunakan Adodb PHP,

Andi, Yogyakarta.

Sholiq, 2010, Analisis dan Perancangan Berorientasi Obyek, Muara Indah, Bandung

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 :

67

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, ataukah Tolak. Seperti gambar 5.7 berikut ini :

Gambar 5.7 Laporan Daftar Proposal TA Berdasarkan Status

I. Halaman Pencarian Mahasiswa Berdasarkan Bulan Sidang Proposal TA

Halaman ini digunakan untuk mencari data sidang proposal tugas akhir mahasiswa berdasarkan bulan pelaksanaan sidang proposal TA. Seperti gambar 5.8 berikut ini :

69

J. Tampilan Laporan Daftar Sidang Proposal TA Berdasarkan Bulan

Halaman ini digunakan untuk melaporkan data jadwal sidang berdasarkan bulan pelaksanaan sidang proposal TA. Seperti gambar 5.9 berikut ini :

BAB VI PENUTUP

6.1 Kesimpulan

Kesimpulan yang dapat diambil dari pembuatan aplikasi informasi jadwal sidang proposal tugas akhir STIKOM Surabaya adalah sebagai berikut :

1. Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web pada bagian PPTA STIKOM Surabaya ini merupakan aplikasi yang dapat membantu mahasiswa STIKOM Surabaya dalam hal pemberitahuan jadwal sidang proposal tugas akhir.

2. Dengan adanya Aplikasi informasi jadwal sidang proposal tugas akhir berbasis web pada bagian PPTA STIKOM Surabaya, dapat membantu bagian PPTA STIKOM Surabaya dalam hal penjadwalan sidang proposal tugas akhir dan mencetak laporan jadwal sidang untuk diberikan kepada dosen pembimbing dan penguji sebagai pemberitahuan

6.2 Saran

Berdasarkan analisis dan perancangan sistem yang sudah dilakukan, saran yang dapat disampaikan oleh penulis untuk pembuatan aplikasi informasi jadwal sidang proposal tugas akhir yaitu:

1. Hasil analisis dan pembuatan aplikasi informasi jadwal sidang proposal tugas akhir ini dapat dikembangkan dengan membangun aplikasi sistem informasi penjadwalan sidang proposal tugas akhir

Daftar Pustaka

Soendoro Herlambang, Haryanto Tanuwijaya.2005.Sistem Informasi: Konsep Teknologi dan Manajemen.Graha Ilmu. Jogjakarta

Marlinda, Linda, S.Kom, 2004, Sistem Basis Data, Andi Offset, Yogyakarta Wulandari, Lily. 2005. Web Service. Depok : Gunadarma

Kurniawan, Budi, 2008, Desain Web dengan HTML + CSS, Andi, Yokyakarta Tamimuddin, 2006, Pemrograman Web Database menggunakan Adodb PHP,

Andi, Yogyakarta.

Sholiq, 2010, Analisis dan Perancangan Berorientasi Obyek, Muara Indah, Bandung