Disusun oleh:
PERUSAHAAN / INDUSTRI
Disusun Oleh :
Menyetujui,
Dosen Pembimbing PKL
Penulis 2
Penulis 3
Puji syukur kehadirat Allah SWT yang telah melimpahkan rahmat, taufik, dan
hidayah-Nya sehingga laporan PKL yang berjudul PENGEMBANGAN SISTEM
INFORMASI MANAJEMEN INTERNSHIP PROGRAM BERBASIS WEBSITE DI PT
CMLABS INDONESIA DIGITAL DENGAN METODE EXTREME PROGRAMMING bisa
selesai dengan baik dan lancar.
Penulis menyadari bahwa laporan PKL ini tidak akan berhasil tanpa bantuan
dari beberapa pihak yang membantu dari awal hingga akhir. Untuk itu penulis
ingin menyampaikan terima kasih kepada:
1. Allah SWT atas berkah, hidayah, dan bimbingan-Nya dalam pelaksanaan
praktik kerja lapangan.
2. Bapak Tri Afirianto, S.T., M.T. selaku dosen pembimbing PKL yang telah
menyediakan waktu serta sabar membimbing dan mengarahkan penulis
sehingga dapat menyelesaikan laporan ini.
3. Bapak Admaja Dwi Herlambang, S.Pd., M.Pd. selaku Ketua Program Studi
Pendidikan Teknologi Informasi.
4. Bapak Issa Arwani, S.Kom., M.Sc. selaku Ketua Jurusan Sistem Informasi.
5. Bapak Dwiyana Dini Kurniawan selaku Manajer Operasional PT CMLABS
Indonesia Digital.
6. Saudara/i Ruli Wahyuni, Nifan Fatahillah, Elmanu, dan Nuril Huda selaku
Pembimbing Lapangan.
7. Seluruh teman-teman PKL dari Program Studi Pendidikan Teknologi
Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya dan pegawai
internal PT CMLABS Indonesia Digital yang telah memberikan bantuan
dan dukungan selama menjalani PKL.
8. Seluruh civitas akademika Pendidikan Teknologi Informasi Universitas
Brawijaya yang telah memberi bantuan dan dukungan selama
penyelesaian laporan PKL ini.
Penulis
lazuardidania@student.ub.ac.id
ABSTRAK
1.3 Tujuan
Penelitian ini bertujuan untuk membangun sistem informasi manajemen
internship program berbasis website yang akan digunakan oleh PT CMLABS
INDONESIA DIGITAL dalam rangka memudahkan Manajer Operasional
CMLABS dalam mengelola data pemagang.
1.4 Manfaat
Membantu dalam kemudahan proses pengelolaan data pemagang dalam
internship program agar tercapainya peningkatan kinerja perusahaan
terhadap tata kelola data pemagang yang lebih baik.
1.5 Batasan Masalah
Dalam penulisan laporan PKL ini terdapat batasan masalah adalah sebagai
berikut.
1. Pembuatan sistem informasi manajemen internship program menggunakan
bahasa pemrograman HTML, JavaScript, dan PHP.
2. Pengelolaan manajemen basis data menggunakan MySQL.
3. Sistem informasi hanya digunakan untuk internal perusahaan.
3.6 HTML
3.6.1 Pengertian HTML
HTML atau Hyper Text Markup Language adalah sebuah bahasa markup
yang digunakan untuk membuat sebuah halaman website, menampilkan
berbagai informasi di dalam sebuah pencarian website di internet. HTML
dijadikan standar yang digunakan secara luas untuk menampilkan halaman
website [CITATION Har16 \l 1033 ]. HTML berperan sebagai pembentuk struktur
halaman website yang menempatkan setiap elemen website sesuai layout yang
diinginkan [CITATION Abd18 \l 1033 ].
3.7 PHP
3.7.1 Pengertian PHP
PHP atau PHP Hypertext Preprocessor adalah bahasa pemrograman yang
dapat disisipkan dalam skrip HTML dan bekerja di sisi server. Tujuan penggunaan
PHP adalah membantu pengembang website (web developer) untuk membuat
website dinamis dengan cepat dan tepat. Umumnya penggunaan bahasa
pemrograman PHP dibantu oleh perangkat lunak web server (Apache, IIS,
Personal Web Server atau PWS), PHP Server, dan database server seperti MySQL,
Interbase, dan MS SQL [CITATION Abd18 \l 1033 ].
3.8 JavaScript
JavaScript adalah jenis bahasa pemrograman yang paling populer dalam
dunia pemrograman website. JavaScript bisa dimasukkan atau disisipkan ke
halaman HTML. Sesuai namanya, JavaScript adalah jenis bahasa scripting
sehingga pengetikan kodenya bisa langsung dari sintaks kodenya, tidak perlu
dikompilasi terlebih dahulu untuk dijadikan file executable [CITATION Win14 \l
1033 ].
JavaScript cocok diletakkan di dokumen website yang ditransfer via jaringan
internet. Kode ini sangat powerful karena tidak perlu browser khusus atau
gadget khusus untuk menjalankannya. Itulah yang menyebabkan kode JavaScript
bisa dieksekusi oleh semua browser modern [CITATION Win14 \l 1033 ].
3.9 MySQL
Database atau basis data merupakan sekumpulan catatan atau data
terstruktur yang disimpan dalam sistem komputer dan diatur sedemikian rupa
sehingga dapat dicari dengan mudah dan informasi dapat diambil dengan cepat.
Basis data yang sering digunakan adalah MySQL dengan bahasa menggunakan
SQL. SQL atau Structured Query Language juga digunakan oleh database lainnya
seperti Oracle dan Microsoft SQL Server [ CITATION Nix18 \l 1033 ].
MySQL adalah salah satu sistem manajemen database open-source yang
populer di kalangan developer, terlebih web developer. MySQL dapat mengirim
dan menerima data dengan sangat cepat dan multiuser. MySQL mampu
menyediakan berbagai fasilitas atau fitur yang dapat digunakan oleh bermacam
pengguna. MySQL merekam semua data pengguna di dalam sistemnya dalam
bentuk tabel [ CITATION Wah10 \l 1033 ]. Database MySQL berisi satu atau lebih
tabel dimana masing-masing berisi catatan atau baris. Baris tersebut memuat
berbagai kolom yang berisi data [ CITATION Nix18 \l 1033 ].
Supaya lebih jelas, berikut contoh pemodelan use case diagram pada studi
kasus sistem infomasi manajemen perpustakan yang dapat dilihat pada .
Gambar 3. Contoh Use Case Diagram Perpustakaan
Sumber: Sukamto & Shalahuddin (2018)
Supaya lebih jelas, berikut contoh pemodelan activity diagram pada studi
kasus sistem informasi manajemen perpustakaan yang dapat dilihat pada .
Gambar 3. Contoh Activity Diagram Perpustakaan
Sumber: Sukamto & Shalahuddin (2018)
Supaya lebih jelas, berikut contoh pemodelan sequence diagram pada studi
kasus sistem informasi manajemen perpustakaan yang dapat dilihat pada .
Gambar 3. Contoh Sequence Diagram Tambah Barang Belanjaan
Sumber: Rahadiyan, et al. (2018)
Supaya lebih jelas, berikut contoh pemodelan class diagram pada studi kasus
sistem informasi manajemen perpustakaan yang dapat dilihat pada .
Gambar 3. Contoh Class Diagram Perpustakaan
Sumber: Sukamto & Shalahuddin (2018)
Bab ini akan membahas metodologi dari penelitian yang akan digunakan
dalam proses perancangan sistem informasi manajemen internship program
berbasis website dengan metode Extreme Programming. Sifat penelitian yang
berfokus pada perancangan dan pengembangan membuat tipe penelitian yang
digunakan adalah tipe implementatif. Tahapan metodologi penelitian yang
digunakan pada laporan PKL ini adalah diagram alir metode yang digunakan,
spesifikasi hardware dan software yang digunakan, studi literatur, perencanaan,
perancangan, pengkodean, pengujian, dan penarikan kesimpulan.
Bab ini akan menjelaskan hasil dan pembahasan dari pengembangan sistem
informasi manajemen internship program berbasis website dengan metode
Extreme Programming. Proses pengembangan sistem informasi diawali dengan
tahap Perencanaan (Planning) yang mana mengumpulkan daftar kebutuhan
sistem sesuai permintaan stakeholder. Kemudian ke tahap Perancangan (Design)
yang fokus pada perancangan pemodelan kebutuhan stakeholder dengan sistem
yang akan dibuat. Tahap selanjutnya adalah Pengkodean (Coding) yang
merupakan proses pembangunan sistem informasi dari segi tampilan antar
muka, fungsi, dan basis data. Tahap terakhir adalah Pengujian (Testing) yang
dimaksudkan untuk memastikan kondisi dan fungsi sistem informasi yang
dibangun telah berjalan dan sesuai keinginan stakeholder.
Hasil dari pemodelan use case scenario untuk fitur login dijelaskan pada .
Tabel 5. Use Case Scenario Login
Use Case Login Admin
Tujuan Memberikan akses masuk ke sistem informasi manajemen
Aktor Admin
Pre-condition Form login berhasil ditampilkan
Main Flow 1. Sistem menampilkan form login yang terdiri dari ID
admin dan password.
2. Admin memasukkan ID admin dan password
3. Sistem memeriksa valid tidaknya data masukan dengan
memeriksa ke basis data.
Alternative Flow 1. Sistem menampilkan form login yang terdiri dari ID
admin dan password.
2. Admin memasukkan ID admin dan password.
3. Sistem memeriksa valid tidaknya data masukan dengan
memeriksa ke basis data.
4. Sistem menampilkan pesan bahwa ID admin atau
password salah.
5. Admin memasukkan kembali ID admin dan password
dengan benar.
6. Sistem memeriksa valid tidaknya data masukan dengan
memeriksa ke basis data.
Post-condition Admin berhasil masuk ke dashboard sistem informasi
manajemen.
Hasil dari pemodelan use case scenario untuk fungsi menampilkan data
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Tampil Data Pemagang
Use Case Mengelola Data Pemagang (Tampil Data Pemagang)
Tujuan Menampilkan data lengkap pemagang dari basis data
Aktor Admin
Pre-condition Masuk ke menu “Data Pemagang”
Main Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
Tabel 5.10 (lanjutan)
Main Flow 2. Admin mencari data pemagang yang ingin dilihat
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem menampilkan kolom data yang dicari.
4. Admin memilih tombol Preview.
Alternative Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin mencari data pemagang yang ingin dilihat
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem tidak menampilkan data apapun karena nama
tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
pemagang dengan benar.
5. Sistem menampilkan kolom data yang dicari.
6. Admin memilih tombol Preview.
Post-condition Sistem berhasil menampilkan data pemagang dengan
lengkap.
Hasil dari pemodelan use case scenario untuk fungsi menambah data
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Tambah Data Pemagang
Use Case Mengelola Data Pemagang (Tambah Data Pemagang)
Tujuan Menambah data pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu Data Pemagang
Main Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin memilih tombol “Tambah Data Pemagang”.
3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nama pemagang, jenis kelamin,
tempat dan tanggal lahir, asal instansi, e-mail, nomor
telepon, posisi magang, status pemagang, tanggal
mulai dan
Tabel 5.11 (lanjutan)
Main Flow dan akhir magang, dan berkas pendukung, seperti CV,
portofolio, dan surat keterangan magang dari instansi
asal yang menaungi calon pemagang, lalu menekan
tombol “Simpan”.
4. Sistem memeriksa valid tidaknya data masukan
pemagang.
5. Sistem menyimpan data pemagang ke basis data.
Alternative Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin memilih tombol “Tambah Data Pemagang”.
3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nama pemagang, jenis kelamin,
tempat dan tanggal lahir, asal instansi, e-mail, posisi
magang, status pemagang, tanggal mulai dan akhir
magang, dan berkas pendukung, seperti CV, portofolio,
dan surat keterangan magang dari instansi asal yang
menaungi calon pemagang, lalu menekan tombol
“Simpan”.
4. Sistem memeriksa valid tidaknya data masukan
pemagang.
5. Menampilkan pesan bahwa penambahan data tidak
lengkap.
6. Admin memasukkan kembali data dengan lengkap
pada form penambahan data pemagang.
7. Sistem memeriksa valid tidaknya data masukan
pemagang.
8. Sistem menyimpan data pemagang ke basis data.
Post-condition Data pemagang berhasil tersimpan.
Hasil dari pemodelan use case scenario untuk fungsi mengubah data
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Ubah Data Pemagang
Use Case Mengelola Data Pemagang (Ubah Data Pemagang)
Tujuan Mengubah data pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Data Pemagang”
Tabel 5.12 (lanjutan)
Main Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin mencari data pemagang yang ingin diubah
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem menampilkan kolom data yang dicari.
4. Admin memilih tombol “Ubah”.
5. Sistem menampilkan form pengubahan data
pemagang.
6. Admin mengubah data pemagang sesuai kebutuhan.
7. Sistem memeriksa valid tidaknya data masukan hasil
mengubah data.
8. Sistem menyimpan data pemagang ke basis data.
Alternative Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin mencari data pemagang yang ingin diubah
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem tidak menampilkan data apapun karena nama
tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
pemagang dengan benar.
5. Sistem menampilkan kolom data yang dicari.
6. Admin memilih tombol “Ubah”.
7. Sistem menampilkan form pengubahan data
pemagang.
8. Admin mengubah data pemagang sesuai kebutuhan.
9. Sistem memeriksa valid tidaknya data masukan hasil
mengubah data.
10. Sistem menampilkan pesan bahwa data masukan tidak
valid (tidak lengkap).
11. Admin mengubah kembali data pemagang dengan
benar.
12. Sistem memeriksa valid tidaknya data masukan hasil
mengubah data.
Tabel 5.12 (lanjutan)
Alternative Flow 13. Sistem menyimpan data pemagang ke basis data.
Post-condition Data pemagang berhasil diubah.
Hasil dari pemodelan use case scenario untuk fungsi menghapus data
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Hapus Data Pemagang
Use Case Mengelola Data Pemagang (Hapus Data Pemagang)
Tujuan Menghapus data pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Data Pemagang”
Main Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari: ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin mencari data pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem menampilkan kolom data yang dicari.
4. Admin memilih tombol “Hapus”.
5. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus data?”.
6. Admin menekan tombol pilihan “Iya”.
Alternative Flow 1. Admin dapat melihat tabel data pemagang yang terdiri
dari ID pemagang, nama pemagang, jenis kelamin, asal
instansi, e-mail, status pemagang, dan posisi magang.
2. Admin mencari data pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem tidak menampilkan data apapun karena nama
tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
pemagang dengan benar.
5. Sistem menampilkan kolom data yang dicari.
6. Admin memilih tombol “Hapus”.
7. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus data?”.
Tabel 5.13 (lanjutan)
Alternative Flow 8. Admin menekan tombol pilihan “Iya”.
Post-condition Data pemagang berhasil dihapus.
Hasil dari pemodelan use case scenario untuk fungsi menambah nilai
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Tambah Nilai Pemagang
Use Case Mengelola Nilai Pemagang (Tambah Nilai Pemagang)
Tujuan Menambah nilai pemagang sesuai kategori penilaian
Aktor Admin
Pre-condition Masuk ke menu “Nilai Pemagang”
Main Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin memilih tombol “Tambah Nilai”.
3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nilai presensi, nilai keterampilan,
nilai sikap, nilai pengetahuan, dan nilai kinerja.
4. Sistem memeriksa valid tidaknya data masukan nilai
pemagang.
5. Sistem menyimpan data nilai pemagang ke basis data.
Alternative Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin memilih tombol “Tambah Nilai”.
3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nilai presensi, nilai keterampilan,
nilai sikap, nilai pengetahuan, dan nilai kinerja.
4. Sistem memeriksa valid tidaknya data masukan nilai
pemagang.
5. Menampilkan pesan bahwa penambahan nilai tidak
lengkap.
6. Admin memasukkan kembali nilai dengan lengkap pada
form penambahan nilai.
Tabel 5.14 (lanjutan)
Alternative Flow 7. Sistem memeriksa valid tidaknya data masukan nilai
pemagang.
8. Sistem menyimpan data nilai pemagang ke basis data.
Post-condition Nilai pemagang berhasil ditambah
Hasil dari pemodelan use case scenario untuk fungsi mengubah nilai
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Ubah Nilai Pemagang
Use Case Mengelola Nilai Pemagang (Ubah Nilai Pemagang)
Tujuan Mengubah nilai pemagang sesuai kebutuhan penilaian
Aktor Admin
Pre-condition Masuk ke menu “Nilai Pemagang”
Main Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin mencari data nilai pemagang yang ingin diubah
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem menampilkan kolom data nilai yang dicari.
4. Admin memilih tombol “Ubah”.
5. Sistem menampilkan form pengubahan nilai
pemagang.
6. Admin mengubah nilai pemagang sesuai kebutuhan.
7. Sistem memeriksa valid tidaknya data masukan hasil
mengubah nilai.
8. Sistem menyimpan data nilai pemagang ke basis data.
Alternative Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari ID pemagang, nama pemagang, nilai presensi, nilai
keterampilan, nilai sikap, nilai pengetahuan, dan nilai
kinerja.
2. Sistem menampilkan kolom data nilai yang dicari.
3. Admin mencari data nilai pemagang yang ingin diubah
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
Hasil dari pemodelan use case scenario untuk fungsi menghapus nilai
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Hapus Nilai Pemagang
Use Case Mengelola Nilai Pemagang (Hapus Nilai Pemagang)
Tujuan Menghapus nilai pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Nilai Pemagang”
Main Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin mencari data nilai pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem menampilkan kolom data nilai yang dicari.
4. Admin memilih tombol “Hapus”.
Tabel 5.16 (lanjutan)
Main Flow 5. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus nilai?”.
6. Admin menekan tombol pilihan “Iya”.
Alternative Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin mencari data nilai pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem tidak menampilkan data apapun karena nama
tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
pemagang dengan benar.
5. Sistem menampilkan kolom data nilai yang dicari.
6. Admin memilih tombol “Hapus”.
7. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus nilai?”.
8. Admin menekan tombol pilihan “Iya”.
Post-condition Nilai pemagang berhasil dihapus.
Hasil dari pemodelan use case scenario untuk fungsi mencetak nilai
pemagang dijelaskan pada .
Tabel 5. Use Case Scenario Cetak Nilai Pemagang
Use Case Mengelola Nilai Pemagang (Cetak Nilai Pemagang)
Tujuan Mencetak nilai pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Nilai Pemagang”
Main Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin mencari data nilai pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
Tabel 5.17 (lanjutan)
Main Flow 3. Sistem menampilkan kolom data nilai yang dicari.
4. Admin memilih tombol “Cetak”.
5. Sistem akan memproses pencetakan atau mengunduh
berkas penilaian dalam format PDF.
Alternative Flow 1. Admin dapat melihat tabel nilai pemagang yang terdiri
dari: ID pemagang, nama pemagang, nilai presensi,
nilai keterampilan, nilai sikap, nilai pengetahuan, dan
nilai kinerja.
2. Admin mencari data nilai pemagang yang ingin dihapus
dengan memasukkan kata kunci berupa nama
pemagang pada kolom pencarian yang telah
disediakan.
3. Sistem tidak menampilkan data apapun karena nama
tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
pemagang dengan benar.
5. Sistem menampilkan kolom data nilai yang dicari.
6. Admin memilih tombol “Cetak”.
7. Sistem akan memproses pencetakan atau mengunduh
berkas penilaian dalam format PDF.
Post-condition Nilai pemagang berhasil dicetak.
Hasil dari pemodelan use case scenario untuk fungsi menambah data master
dijelaskan pada .
Tabel 5. Use Case Scenario Tambah Data Master
Use Case Mengelola Data Master (Tambah Data Master)
Tujuan Menambah data master berupa data instansi yang
menaungi pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Master Data”
Main Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin memilih tombol “Tambah Data Master”.
Tabel 5.18 (lanjutan)
Main Flow 3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nama instansi, alamat instansi,
nomor telepon instansi, dan e-mail instansi.
4. Sistem memeriksa valid tidaknya data-data instansi.
5. Sistem menyimpan data instansi ke basis data.
Alternative Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin memilih tombol “Tambah Data Master”.
3. Sistem menampilkan form berisikan kolom-kolom
untuk memasukkan nama instansi, alamat instansi,
nomor telepon instansi, dan e-mail instansi.
4. Sistem memeriksa valid tidaknya data-data instansi.
5. Menampilkan pesan bahwa penambahan data tidak
lengkap.
6. Admin memasukkan kembali data dengan lengkap
pada formulir penambahan data instansi.
7. Sistem memeriksa valid tidaknya data-data instansi.
8. Sistem menyimpan data instansi ke basis data.
Post-condition Data master berupa data instansi berhasil tersimpan.
Hasil dari pemodelan use case scenario untuk fungsi mengubah data master
dijelaskan pada .
Tabel 5. Use Case Scenario Ubah Data Master
Use Case Mengelola Data Master (Ubah Data Master)
Tujuan Mengubah data master berupa data instansi yang menaungi
pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Master Data”
Main Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin mencari data instansi yang ingin diubah dengan
memasukkan kata kunci berupa nama instansi pada
kolom pencarian yang telah disediakan.
Tabel 5.19 (lanjutan)
Main Flow 3. Sistem menampilkan kolom data yang dicari.
4. Admin memilih tombol “Ubah”.
5. Sistem menampilkan form pengubahan data instansi.
6. Admin mengubah data instansi sesuai kebutuhan.
7. Sistem memeriksa valid tidaknya data instansi hasil
mengubah data.
8. Sistem menyimpan data instansi ke basis data.
Alternative Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin mencari data instansi yang ingin diubah dengan
memasukkan kata kunci berupa nama instansi pada
kolom pencarian yang telah disediakan.
3. Sistem tidak menampilkan data apapun karena nama
instansi tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
instansi dengan benar.
5. Sistem menampilkan kolom data yang dicari.
6. Admin memilih tombol “Ubah”.
7. Sistem menampilkan form pengubahan data instansi.
8. Admin mengubah data instansi sesuai kebutuhan.
9. Sistem memeriksa valid tidaknya data instansi hasil
mengubah data.
10. Sistem menampilkan pesan bahwa data instansi tidak
valid (tidak lengkap).
11. Admin mengubah kembali data instansi dengan benar.
12. Sistem memeriksa valid tidaknya data instansi hasil
mengubah data.
13. Sistem menyimpan data instansi ke basis data.
Tabel 5.19 (lanjutan)
Post-condition Data master berupa data instansi berhasil diubah.
Hasil dari pemodelan use case scenario untuk fungsi menghapus data
master dijelaskan pada .
Tabel 5. Use Case Scenario Hapus Data Master
Use Case Mengelola Data Master (Hapus Data Master)
Tujuan Menghapus data master berupa data instansi yang
menaungi pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Master Data”
Main Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin mencari data instansi yang ingin diubah dengan
memasukkan kata kunci berupa nama instansi pada
kolom pencarian yang telah disediakan.
3. Sistem menampilkan kolom data yang dicari.
4. Admin memilih tombol “Hapus”.
5. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus data?”.
6. Admin menekan tombol pilihan “Iya”.
Alternative Flow 1. Admin dapat melihat tabel data master yang terdiri
dari: ID instansi, nama instansi, alamat instansi, nomor
telepon instansi, dan e-mail instansi.
2. Admin melakukan pencarian data instansi yang ingin
diubah dengan memasukkan kata kunci berupa nama
instansi pada kolom pencarian yang telah disediakan.
3. Sistem tidak menampilkan data apapun karena nama
instansi tidak ditemukan.
4. Admin memasukkan kembali kata kunci berupa nama
instansi dengan benar.
5. Sistem menampilkan kolom data yang dicari.
6. Admin memilih tombol “Hapus”.
7. Sistem menampilkan pesan konfirmasi “Apakah yakin
menghapus data?”.
8. Admin menekan tombol pilihan “Iya”.
Post-condition Data master berupa data instansi berhasil dihapus.
Hasil dari pemodelan use case scenario untuk fungsi mencetak sertifikat
dijelaskan pada .
Tabel 5. Use Case Scenario Cetak Sertifikat
Use Case Cetak Sertifikat
Tujuan Mencetak sertifikat pemagang sesuai kebutuhan
Aktor Admin
Pre-condition Masuk ke menu “Cetak Sertifikat”
Main Flow 1. Sistem menampilkan template sertifikat pemagang.
2. Admin memilih tombol “Cetak”.
3. Sistem akan memproses pencetakan atau mengunduh
sertifikat dalam format PDF.
Alternative Flow 1. Sistem menampilkan template sertifikat pemagang.
2. Admin memilih tombol “Cetak”.
3. Jika admin mengurungkan niat untuk mencetak
sertifikat, maka dapat membatalkan proses mencetak
dengan memilih tombol “Cancel”.
4. Jika admin yakin akan mencetak sertifikat, maka dapat
memilih tombol “Print”.
5. Sistem akan memproses pencetakan atau mengunduh
berkas penilaian dalam format PDF.
Post-condition Nilai pemagang berhasil dicetak.
Hasil dari pemodelan use case scenario untuk fitur logout dijelaskan pada .
Tabel 5. Use Case Scenario Logout
Use Case Logout
Tujuan Keluar dari sistem setelah mengakses sistem informasi
manajemen
Aktor Admin
Pre-condition Masuk ke dalam sistem informasi (bisa dari dashboard,
menu Data Pemagang, Nilai Pemagang, atau Cetak
Sertifikat)
Main Flow 1. Admin memilih tombol logout.
Sistem melakukan proses keluar dari sistem.
Alternative Flow -
Post-condition Admin berhasil keluar dari sistem informasi manajemen.
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menampilkan data pemagang dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menambah data pemagang dijelaskan pada .
Gambar 5. Activity Diagram Tambah Data Pemagang
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi mengubah data pemagang dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menghapus data pemagang dijelaskan pada .
Gambar 5. Activity Diagram Hapus Data Pemagang
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menambah nilai pemagang dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi mengubah nilai pemagang dijelaskan pada .
Gambar 5. Activity Diagram Ubah Nilai Pemagang
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menghapus nilai pemagang dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menambah data master dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi mengubah data master dijelaskan pada .
Gambar 5. Activity Diagram Ubah Data Master
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fungsi menghapus data master dijelaskan pada .
Hasil dari pemodelan activity diagram berdasarkan use case scenario pada
untuk fitur logout dijelaskan pada .
Hasil dari perancangan antar muka sistem informasi untuk dashboard dalam
bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk menu fitur-fitur
sistem informas dalam bentuk wireframe digambarkan pada .
Gambar 5. Wireframe Antar Muka Menu Pada Dashboard
Hasil dari perancangan antar muka sistem informasi untuk laman data
pemagang dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur menambah
data pemagang dalam bentuk wireframe digambarkan pada .
Gambar 5. Wireframe Antar Muka Tambah Data Pemagang
Hasil dari perancangan antar muka sistem informasi untuk fitur mengubah
data pemagang dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi fitur menampilkan data
pemagang dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi fitur menambah nilai
pemagang dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur mengubah
nilai pemagang dalam bentuk wireframe digambarkan pada .
Gambar 5. Wireframe Antar Muka Ubah Nilai Pemagang
Hasil dari perancangan antar muka sistem informasi untuk fitur menghapus
nilai pemagang dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur mencetak
nilai pemagang dalam bentuk wireframe digambarkan pada .
Gambar 5. Wireframe Antar Muka Cetak Nilai Pemagang
Hasil dari perancangan antar muka sistem informasi untuk laman master
data dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur menambah
data master dalam bentuk wireframe digambarkan pada .
Gambar 5. Wireframe Antar Muka Tambah Data Master
Hasil dari perancangan antar muka sistem informasi untuk fitur mengubah
data master dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur menghapus
data master dalam bentuk wireframe digambarkan pada .
Hasil dari perancangan antar muka sistem informasi untuk fitur konfirmasi
mencetak sertifikat dalam bentuk wireframe digambarkan pada .
6.1 Kesimpulan
Berdasarkan hasil penelitian dalam Pengembangan Sistem Informasi
Manajemen Internship Program Berbasis Website yang dilakukan peneliti maka
menghasilkan beberapa kesimpulan sebagai berikut.
1. Proses pengembangan sistem informasi manajemen internship program
berbasis website menghasilkan tampilan dan fungsi sistem ang dibutuhkan,
terdiri dari fungsi pendaftaran calon pemagang, fungsi login dan logout,
fungsi kelola data pemagang, fungsi kelola nilai pemagang, fungsi kelola data
master, dan fungsi cetak sertifikat.
2. Hasil tahap pengujian (testing) sistem menggunakan dua metode yaitu
whitebox dan blackbox testing. Berdasarkan pengujian dengan metode
whitebox, sistem informasi memiliki tingkat kompleksitas sistem sebesar
100% berdasarkan teknik Basis Path dengan perhitungan Cyclomatic
Complexity terhadap flow graph yang menandakan sistem dapat digunakan
oleh admin dan calon pemagang. Namun, tidak memungkiri bahwa sistem
masih dapat dikembangkan kembali sesuai kebutuhan di waktu mendatang.
Sedangkan berdasarkan pengujian dengan metode blackbox, sistem
informasi memiliki tingkat validitas sistem sebesar 100% berdasarkan hasil
valid pada tiap kasus yang diujikan.
6.2 Saran
Terlepas dari selesainya pembangunan sistem informasi manajemen
internship program, sistem tersebut masih belum sempurna. Masih ada
beberapa hal yang dapat dilakukan untuk mengembangkan sistem agar lebih
baik. Salah satunya adalah penggunaan framework pada sistem agar
pembangunan sistem dapat lebih efektif, efisien, dan tertata rapi. Hal ini
dikarenakan pada penelitian ini masih tidak menggunakan framework.
DAFTAR PUSTAKA
Abdulloh, R., 2016. Easy & Simple Web Programming. 1st ed. Jakarta: PT Elex
Media Komputindo.
Abdulloh, R., 2018. 7 in 1 Pemrograman Web Untuk Pemula. 1st ed. Jakarta: PT
Elex Media Komputindo.
Anggraeni, E. Y. & Irviani, R., 2017. Pengantar Sistem Informasi. 1st ed.
Yogyakarta: ANDI.
Azdy, R. A. & Rini, A., 2018. Penerapan Extreme Programming Dalam
Membangun Aplikasi Pengaduan Layanan Pelanggan Pada Perguruan
Tinggi. Jurnal Teknologi Informasi dan Ilmu Komputer, 5(2), pp. 197-206.
Basu, A., 2015. Software Quality Assurance, Testing and Metrics. 1st ed. India:
PHI Learning Private Limited.
Djaelangkara, R. T., Sengkey, R. & Lantang, O. A., 2015. Perancangan Sistem
Informasi Akademik Sekolah Berbasis Web Studi Kasus Sekolah
Menengah Atas Kristen 1 Tomohon. e-Jurnal Teknik Elektro dan
Komputer, 4(3), pp. 86-94.
Harison & Syarif, A., 2016. Sistem Informasi Geografis Sarana Pada Kabupaten
Pasaman Barat. Jurnal TEKNOIF, 4(2), pp. 40-50.
Hutahaean, J., 2014. Konsep Sistem Informasi. 1st ed. Yogyakarta: Deepublish.
Khurana, R., 2010. Software Engineering: Principles and Practices. 2nd ed. New
Delhi: Vikas Publishing House.
Komputer, W., 2010. Panduan Belajar MySQL Database Server. 1st ed. Jakarta:
mediakita.
Kurniawan, T. A., 2018. Pemodelan Use Case (UML): Evaluasi Terhadap Beberapa
Kesalahan Dalam Praktik. Jurnal Teknologi Informasi dan Ilmu Komputer
(JTIIK), 5(1), pp. 77-86.
Lubis, A., 2016. Basis Data Dasar. 1st ed. Yogyakarta: Deepublish.
Mathur, A. P., 2011. Foundations of Software Testing. 1st ed. New Delhi: Darling
Kindersley.
Maturidi, A. D., 2014. Metode Penelitian Teknik Informatika. 1st ed. Yogyakarta:
Deepublish.
Nixon, R., 2018. Learning PHP, MySQL & JavaScript : with jQuery, CSS & HTML5.
4th ed. United States of America: O'Reilly Media, Inc.
PKL, T. P. P., 2018. Panduan Penyelesaian dan Evaluasi Praktik Kerja Lapangan
(PKL). Malang: s.n.
Putra, R. E., Wicaksono, S. A. & Arwani, I., 2019. Pengembangan Sistem Informasi
Perpustakaan menggunakan Metode Extreme Programming (Studi pada:
SMK 1 Muhammadiyah Malang). Jurnal Pengembangan Teknologi
Informasi dan Ilmu Komputer, 3(7), pp. 6330-6340.
Rahadiyan, A., Wardani, N. H. & Rokhmawati, R. I., 2018. Analisis dan
Perancangan Sistem Informasi Penjualan dan Persediaan Barang Pada
Gudang Pada CV. KAJEYEFOOD. Jurnal Pengembangan Teknologi
Informasi Ilmu Komputer, 2(6), pp. 2334-2342.
Silalahi, M. & Saragih, S. P., 2019. Sistem Informasi Manajemen Lembaga
Pendidikan dan Pelatihan Madani (LP2M) dengan Metode Extreme
Programming. Applied Informatics and Computing (JAIC), 3(2), pp. 107-
113.
Sukamto, R. A. & Shalahuddin, M., 2018. Rekayasa Perangkat Lunak: Terstruktur
dan Berorientasi Objek. 1st ed. Bandung: INFORMATIKA.
Suryana, D., 2012. Sistem Teknologi Informasi : Sistem Informasi Penggajian
Karyawan. 3rd ed. Jakarta: Gramedia.
Suryantara, I. G. N., 2017. Merancang Aplikasi dengan Metodologi Extreme
Programming. 1st ed. Jakarta: PT Elex Media Komputindo.
Susanti, M., 2016. Perancangan Sistem Informasi Akademik Berbasis Web Pada
SMK Pasar Minggu Jakarta. Jurnal Informatika, 3(1), pp. 91-99.
Sutabri, T., 2012a. Analisis Sistem Informasi. 1st ed. Yogyakarta: Andi.
Sutabri, T., 2012b. Konsep Sistem Informasi. 1st ed. Yogyakarta: ANDI.
Utami, F. H. & Asnawati, 2015. Rekayasa Perangkat Lunak. 1st ed. Yogyakarta:
Deepublish.
Winarno, E., Zaki, A. & Community, S., 2014. 3 in 1 : JavaScript, jQuery dan
jQuery Mobile. 1st ed. Jakarta: PT Elex Media Komputindo.
LAMPIRAN