disusun oleh: jamaluddin 1112093000032 program studi...
TRANSCRIPT
SKRIPSI
RANCANG BANGUN REVOLVING FUND DOCUMENT
MANAGEMENT SYSTEM
Sebagai Salah Satu Syarat untuk Memperoleh Gelar
Sarjana Komputer
Disusun Oleh:
Jamaluddin
1112093000032
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
2019 M / 1440
A-PDF PageMaster Demo. Purchase from www.A-PDF.com to remove the watermark
SKRIPSI
RANCANG BANGUN REVOLVING FUND DOCUMENT
MANAGEMENT SYSTEM
Sebagai Salah Satu Syarat untuk Memperoleh Gelar
Sarjana Komputer
Disusun Oleh:
Jamaluddin
1112093000032
PROGRAM STUDI SISTEM INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
2019 M / 1440 H
iii
LEMBAR PENGESAHAN SKRIPSI
RANCANG BANGUN REVOLVING FUND DOCUMENT
MANAGEMENT SYSTEM
Disusun Oleh:
Jamaluddin
1112093000032
Menyetujui,
Pembimbing I
Nur Aeni Hidayah, MMSI
NIP. 19750818 200501 2 008
Pembimbing II
Nidaul Hasanati, MMSI
NIP. 19790718 201411 2 002
Mengetahui,
Ketua Program Studi Sistem Informasi Fakultas Sains dan Teknologi
Universitas Islam Negeri Syarif Hidayatullah Jakarta
A’ang Subiyakto, Ph.D
NIP. 19760219 200710 1 002
iv
PENGESAHAN UJIAN
Skripsi yang berjudul “Rancang Bangun Revolving Fund Document
Management System” yang ditulis oleh Jamaluddin, NIM 1112093000032 telah
diuji dan dinyatakan lulus dalam siding Munaqosah Fakultas Sains dan Teknologi,
Universitas Islam Negeri Syarif Hidayatullah Jakarta pada hari Senin, 24 Juni
2019. Skripsi ini telah diterima sebagai salah satu syarat memperoleh gelar Sarjana
Satu (S1) Program Studi Sistem Informasi.
Menyetujui,
Penguji I
Dr. Qurrotul Aini, M.T.
Penguji II
Meinarini Catur Utami, M.T.
NIP. 1973032 5200901 2 001
Pembimbing I
Nur Aeni Hidayah, MMSI
NIP. 19750818 200501 2 008
NIP. 19780505 201101 2 009
Pembimbing II
Nidaul Hasanati, MMSI
NIP. 19790718 201411 2 002
Mengetahui,
Dekan
Fakultas Sains dan Teknologi
Prof. Dr. Lily Surraya Eka Putri, M.
Env.Stud.
NIP. 19690404 200501 2 005
Ketua
Program Studi Sistem Informasi
A’ang Subiyakto, Ph.D
NIP. 19760219 200710 1 002
v
LEMBAR PERNYATAAN
DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-
BENAR-BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH
DIAJUKAN SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA
PERGURUAN TINGGI DAN LEMBAGA MANAPUN.
Jakarta, 12 Juni 2019
Jamaluddin
1112093000032
vii
ABSTRAK
Jamaluddin 1112093000032, Rancang Bangun Revolving Fund Document
Management System. Di bawah bimbingan NUR AENI HIDAYAH, MMSI dan
NIDAUL HASANATI, MMSI.
Document Management System (DMS) adalah sistem berbasis komputer
yang menyediakan penyimpanan berbasis web yang dapat diakses di berbagai
tempat. DMS dapat mengurangi resiko kehilangan dokumen, memangkas biaya
pengarsipan dokumen fisik dan dapat dicetak kembali. Universitas Islam Negeri
(UIN) Syarif Hidayatullah Jakarta memiliki proses Ganti Uang Persediaan (GUP)
yaitu mekanisme penggantian Uang Persediaan (UP) yang diberikan pada awal
tahun anggaran, proses ini melibatkan banyak berkas penting dan seluruh fakultas.
Oleh karena itu DMS mencoba mendukung proses bisnis GUP ini dengan
menyediakan media koordinasi antar unit dalam mengelola berkas maupun
dokumen elektronik secara online untuk meminimalisir kecelakaan ataupun
hilangnya berkas. Metode pengembangan sistem yang digunakan adalah SCRUM
dengan Unified Modelling Language (UML) sebagai tools perancangan sistem.
Sistem dibangun menggunakan PHP dan MySQL. Mengacu dari hasil wawancara
kepada Bapak Ady Cahyadi selaku Sekretaris SPI dan Bapak Rezky Mehta Setiadi
sebagai Koor Divisi Kepatuhan dan Keuangan SPI, output berupa Revolving Fund
Document Management System berbasis web ini mendukung pengelolaan
dokumen, pengecekan proses dokumen dan koordinasi secara online pada proses
GUP tingkat fakultas di UIN Jakarta.
Kata kunci: Manajemen Dokumen, Monitoring, Electronic Document, Uang
Persediaan, Scrum, Unified Modelling Language.
V Bab + 150 Halaman + xxvii Halaman Romawi + 61 Gambar + 56 Tabel + 3
Daftar Simbol
Pustaka Acuan (32, 2007-2019)
ix
KATA PENGANTAR
Puji dan syukur penulis panjatkan kepada Allah SWT yang telah
memberikan rahmat dan hidayah-Nya, sehingga penulis dapat menyelesaikan
skripsi dengan judul “RANCANG BANGUN REVOLVING FUND
DOCUMENT MANAGEMENT SYSTEM.” Skripsi ini disusun sebagai
persyaratan guna memperoleh gelar sarjana (S-1) dalam bidang Sistem Informasi
dari Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta.
Peneliti sangat menyadari skripsi ini masih jauh dari sempurna. Selama
penyusunan skripsi ini tentunya ada banyak kesulitan dan hambatan yang penulis
hadapi, baik dalam pengumpulan bahan dan lain sebagainya. Namun berkat
kesungguhan hati dan bantuan dari berbagai pihak, sehingga kesulitan tersebut
dapat diatasi.
Pada kesempatan ini penulis hendak mengucapkan terima kasih kepada
pihak-pihak yang telah membantu memberikan dukungan, bimbingan, bantuan
kepada saya selama melakukan riset skripsi dan proses penyelesaian skripsi ini.
Tanpa bantuan dari berbagai pihak, tentunya proses penyusunan skripsi ini akan
sangat sulit untuk diselesaikan. Oleh karena itu, penulis ingin menyampaikan
terima kasih kepada:
1. Ibu Prof. Dr. Hj. Amany Burhanuddin Umar Lubis, M. A. selaku Rektor
UIN Syarif Hidayatullah Jakarta.
2. Ibu Prof. Dr. Lily Surraya Eka Putri, M. Env.Stud. selaku Dekan Fakultas
Sains dan Teknologi, Universitas Islam Negeri Syarif Hidayatullah.
x
3. Bapak A’ang Subiyakto, Ph.D selaku Ketua Program Studi Sistem
Informasi, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif
Hidayatullah.
4. Ibu Nidaul Hasanati, MMSI selaku Sekretaris Program Studi Sistem
Informasi, Fakultas Sains dan Teknologi, Universitas Islam Negeri Syarif
Hidayatullah.
5. Ibu Nur Aeni Hidayah, MMSI dan Ibu Nidaul Hasanati, MMSI selaku dosen
pembimbing yang secara sabar membimbimbing penulis dan telah
memberikan kesempatan untuk menyelesaikan penelitian ini.
6. Ibu Dr. Qurrotul Aini, MT dan Ibu Meinarini Catur Utami, MT selaku dosen
penguji yang telah memberikan waktu dan arahan dalam penyelesaian
skripsi ini.
7. Dosen-dosen Program Studi Sistem Informasi yang telah memberikan ilmu
selama perkuliahan.
8. Orang tua saya, bapak dan mama yang telah bersabar menghadapi anaknya
dan terus mendukung anaknya untuk mendapatkan pendidikan yang lebih
baik.
9. Ayub, Dhimas, Bedul, Imam, Ocol, Galih, Galang, Tasa, Je serta teman-
teman yang tidak bisa disebutkan satu persatu yang telah mengingatkan dan
membantu penulis dalam menyelesaikan laporan penelitian ini.
10. Teman-teman seperjuangan di Grup Mari Kita Bersabar SI A 2012 dan
Grup Menuju Wisuda yang saling memberikan semangat dan informasi.
xi
11. Diriku sendiri, terima kasih telah berjuang walaupun motivasi sempat surut,
kamu telah menunjukkan jika dirimu mampu menyelesaikan laporan ini dan
kamu pantas mengapresiasi dirimu sendiri.
12. Semua pihak yang tidak disebutkan satu persatu, namun tidak mengurangi
sedikitpun rasa terima kasih penulis, yang telah membantu hingga
terselesaikannya skripsi ini.
Terima kasih atas segala bantuan dari semua pihak. Akhir kata penulis berharap
semoga skripsi ini dapat bermanfaat bagi penulis khususnya dan bagi para pembaca
pada umumnya.
Jakarta, 24 Juni 2019
Jamaluddin
1112093000032
xiii
DAFTAR ISI
ABSTRAK……. .................................................................................................. vii
KATA PENGANTAR .......................................................................................... ix
DAFTAR ISI….. ................................................................................................. xiii
DAFTAR GAMBAR ........................................................................................ xviii
DAFTAR TABEL .............................................................................................. xxi
DAFTAR SIMBOL .......................................................................................... xxiv
BAB 1 PENDAHULUAN ..................................................................................... 1
1.1 Latar Belakang ............................................................................................... 1
1.2 Identifikasi Masalah....................................................................................... 3
1.3 Rumusan Masalah .......................................................................................... 4
1.4 Batasan Masalah ............................................................................................ 4
1.5 Tujuan Penelitian ........................................................................................... 5
1.6 Manfaat Analisis ............................................................................................ 6
1.7 Metode Penelitian .......................................................................................... 6
1.7.1 Metode Pengumpulan Data ................................................................ 7
1.7.1.1 Observasi ............................................................................... 7
1.7.1.2 Wawancara ............................................................................. 7
1.7.1.3 Studi Pustaka .......................................................................... 7
1.7.2 Metode Pengembangan Sistem .......................................................... 8
1.8 Sistematika Penulisan .................................................................................... 9
BAB 2 LANDASAN TEORI .............................................................................. 12
2.1 Konsep Dasar Rancang Bangun Sistem ...................................................... 12
2.2 Konsep Document Management System ..................................................... 13
xiv
2.2.1 Pengertian Manajemen .................................................................... 13
2.2.2 Pengertian Dokumen ........................................................................ 13
2.2.3 Pengertian Dokumen Elektronik ...................................................... 13
2.2.4 Pengertian Document Management System ..................................... 14
2.2.5 Nilai Tambah Document Management System ............................... 14
2.2.6 Keuntungan Dokumen Elektronik ................................................... 15
2.2.7 Kerugian Dokumen Elektronik ........................................................ 16
2.2.8 ISO 15489 ........................................................................................ 17
2.3 Konsep Uang Persediaan ............................................................................. 18
2.3.1 Pengertian Uang Persediaan (Revolving Fund) Menurut Peraturan
Menteri Keuangan Nomor 190/PMK.05/2012 ................................ 18
2.4 Konsep Ganti Uang Persediaan ................................................................... 18
2.4.1 Pengertian Ganti Uang Persediaan dalam Peraturan Rektor UIN
Syarif Hidayatullah Jakarta Un.01/R/HK.00.5/02/2014 .................. 18
2.4.2 Mekanisme Ganti Uang Persediaan ................................................. 19
2.5 Konsep Tambah Uang Persediaan ............................................................... 20
2.5.1 Pengertian Tambah Uang Persediaan dalam Peraturan Rektor UIN
Syarif Hidayatullah Jakarta Un.01/R/HK.00.5/02/2014 .................. 20
2.5.2 Mekanisme Tambah Uang Persediaan ............................................. 21
2.6 Metodologi Pengembangan Sistem ............................................................. 24
2.6.1 Pengertian Metodologi Pengembangan Sistem ............................... 24
2.6.2 System Development Life Cycle (SDLC) ......................................... 24
2.6.3 Extreme Programming ..................................................................... 26
2.6.4 Scrum……….. ................................................................................... 27
2.6.4.1 Scrum Events ........................................................................ 28
2.6.4.2 Scrum Artifacts .................................................................... 31
xv
2.7 Konsep Analisis dan Desain Sistem Informasi ............................................ 32
2.7.1 Pengertian Analisis Sistem .............................................................. 32
2.7.2 Pengertian Desain Sistem ................................................................ 32
2.7.3 Pendekatan Analisis Sistem ............................................................. 33
2.8 Object Oriented Analysis and Design.......................................................... 35
2.8.1 Object Oriented Analysis ................................................................. 35
2.8.2 Object Oriented Design ................................................................... 35
2.8.3 Konsep Sistem untuk Pemodelan Obyek ......................................... 35
2.9 Konsep Basis Data ....................................................................................... 36
2.10 Tools Perancangan Sistem ........................................................................... 36
2.10.1 Flowchart ......................................................................................... 36
2.10.2 Rich Picture ..................................................................................... 36
2.10.3 Unified Modelling Language ........................................................ 37
2.10.3.1 Pengertian UML ............................................................... 37
2.10.3.2 Diagram-Diagram UML ................................................... 37
2.11 Konsep Pemrograman Web ......................................................................... 40
2.11.1 Pengertian PHP ................................................................................ 40
2.11.2 Pengertian Laravel ........................................................................... 41
2.11.3 Pengertian MySQL .......................................................................... 46
2.11.4 HTML .............................................................................................. 48
2.11.5 CSS….. ............................................................................................ 48
2.11.6 JavaScript ........................................................................................ 48
2.12 Testing…… .................................................................................................. 49
2.12.1 The Test Case Design Inmplication of OO Concept ........................ 51
2.12.2 Application of Conventional Test Case Design Methods ................ 51
xvi
2.12.3 Fault Based Testing ......................................................................... 52
2.12.4 Scenario Based Testing .................................................................... 52
2.13 Perangkat Lunak Pendukung ....................................................................... 53
2.13.1 XAMPP ............................................................................................ 53
2.13.2 Visual Studio Code .......................................................................... 53
2.13.3 Astah Professional ........................................................................... 54
2.13.4 Microsoft Visio 2016 ....................................................................... 54
BAB 3 METODE PENGEMBANGAN SISTEM ............................................. 56
3.1 Metode Pengumpulan Data.......................................................................... 56
3.1.1 Metode Observasi ............................................................................ 56
3.1.2 Studi Pustaka .................................................................................... 56
3.2 Metode Pengembangan Sistem .................................................................... 60
3.2.1 Sprint Planning ................................................................................ 60
3.2.2 Daily Scrum ..................................................................................... 60
3.2.3 Sprint Review ................................................................................... 61
3.2.4 Sprint Retrospective ......................................................................... 61
3.3 Alasan Menggunakan Scrum ....................................................................... 61
3.4 Tahapan-Tahapan Penelitian ....................................................................... 62
BAB 4 HASIL DAN PEMBAHASAN ............................................................... 64
4.1 Gambaran Umum Universitas Islam Negeri (UIN) Syarif Hidayatullah
Jakarta ………… ......................................................................................... 64
4.1.1 Sekilas Profil UIN Syarif Hidayatullah Jakarta ............................... 64
4.1.2 Visi dan Misi UIN Syarif Hidayatullah Jakarta ............................... 64
4.2 Struktur Organisasi UIN Syarif Hidayatullah Jakarta ................................. 65
4.3 Sprint Planning ............................................................................................ 67
xvii
4.3.1 Menentukan User Stories ................................................................. 67
4.3.2 Menentukan Acceptance Criteria .................................................... 69
4.3.3 Menyusun Product Backlog ............................................................. 71
4.4 Daily Scrum ................................................................................................. 75
4.4.1 Rancangan UML .............................................................................. 75
4.4.1.1 Use Case Diagram ............................................................... 75
4.4.1.2 Use Case Narrative .............................................................. 80
4.4.1.3 Activity Diagram .................................................................. 94
4.4.1.4 Class Diagram ................................................................... 108
4.4.1.5 Sequence Diagram ............................................................. 111
4.4.1.6 Component Diagram .......................................................... 120
4.4.1.7 Deployment Diagram ......................................................... 122
4.4.2 Desain Database ............................................................................ 122
4.4.2.1 Skema Database ................................................................ 123
4.4.2.2 Spesifikasi Database .......................................................... 124
4.6 Desain Interface......................................................................................... 134
4.7 Sprint Review ............................................................................................. 140
BAB 5 PENUTUP .............................................................................................. 146
5.1 Kesimpulan ................................................................................................ 146
5.2 Saran……. ................................................................................................. 147
DAFTAR PUSTAKA ........................................................................................ 149
LAMPIRAN
xviii
DAFTAR GAMBAR
Gambar 2.1 Mekanisme GUP ............................................................................... 19
Gambar 2.2 Mekanisme TUP ................................................................................ 21
Gambar 2.3 System Development Life Cycle (Dennis et al, 2012) ........................ 25
Gambar 2.4 Extreme Programming (Dennis et al, 2012) ..................................... 26
Gambar 2.5 Alur Kerja Scrum (Stellman & Greene, 2015) .................................. 27
Gambar 2.6 Komponen yang ada pada Use Case Diagram……. ........................ 38
Gambar 2.7 Contoh Activity Diagram (Kendall & Kendall, 2014) ...................... 38
Gambar 2.8 Contoh Class Diagram (Kendall & Kendall, 2014) .......................... 39
Gambar 2.9 Contoh Sequence Diagram (Kendall & Kendall, 2014) ................... 39
Gambar 2.10 Contoh Menetapkan One to One Relationship ................................ 42
Gambar 2.11 Menuliskan Foreign Key Secara Eksplisit ...................................... 43
Gambar 2.12 One to One Relationship ................................................................. 43
Gambar 2.13 One to Many Relationship ............................................................... 44
Gambar 2.14 Many to Many Relationship ............................................................ 44
Gambar 2.15 One to Many Polymorphic Relationship ......................................... 45
Gambar 2.16 Many to Many Polymorphic Relationship ....................................... 46
Gambar 3.1 Tahapan-Tahapan Penelitian ............................................................. 62
Gambar 4.1 Struktur Organisasi UIN Syarif Hidayatullah Jakarta ....................... 66
Gambar 4.2 Use Case Revolving Fund Document Management System .............. 79
Gambar 4.3 Activity Diagram Sign Up ................................................................. 95
Gambar 4.4 Activity Diagram Manage Users ....................................................... 96
Gambar 4.5 Activity Diagram Login ..................................................................... 97
Gambar 4.6 Activity Diagram Manage Roles ....................................................... 98
xix
Gambar 4.7 Activity Diagram Manage Permissions ............................................ 99
Gambar 4.8 Activity Diagram Manage Departemen........................................... 100
Gambar 4.9 Activity Login Input Data Dokumen................................................ 101
Gambar 4.10 Activity Diagram Submit Pengajuan ............................................. 102
Gambar 4.11 Activity Diagram Verifikasi Dokumen ......................................... 103
Gambar 4.12 Activity Diagram Revisi Dokumen ............................................... 104
Gambar 4.13 Activity Diagram Disposisi Hasil .................................................. 105
Gambar 4.14 Activity Diagram Input Data Pencairan ........................................ 106
Gambar 4.15 Activity Diagram Logout ............................................................... 107
Gambar 4.16 Class Diagram Revolving Fund Document Management System . 110
Gambar 4.17 Sequence Diagram Signup ............................................................ 111
Gambar 4.18 Sequence Diagram Login .............................................................. 112
Gambar 4.19 Sequence Diagram Forgot Password ........................................... 112
Gambar 4.20 Sequence Diagram Users, Roles dan Permissions ........................ 113
Gambar 4.21 Sequence Diagram User dan Mediafile ........................................ 114
Gambar 4.22 Sequence Diagram User dan Dokumen ........................................ 115
Gambar 4.23 Sequence Diagram User, Pengajuan dan Dokumen ..................... 115
Gambar 4.24 Sequence Diagram User, Verifikasi, Pengajuan dan Mediafile .... 116
Gambar 4.25 Sequence Diagram User, Revisi, Verifikasi dan Mediafile .......... 117
Gambar 4.26 Sequence Diagram User, Disposisi, Verifikasi dan Mediafile ..... 118
Gambar 4.27 Sequence Diagram User, Pencairan, Disposisi dan Mediafile ...... 118
Gambar 4.28 Sequence Diagram User, Thread, Participants dan Message ...... 119
Gambar 4.28 Component Diagram ..................................................................... 120
Gambar 4.29 Deployment Diagram .................................................................... 122
Gambar 4.30 Skema Database ............................................................................ 123
xx
Gambar 4.31 Tampilan Login ............................................................................. 134
Gambar 4.32 Reset Password ............................................................................. 134
Gambar 4.33 Tampilan Dashboard..................................................................... 135
Gambar 4.34 Tampilan Manage Users ............................................................... 135
Gambar 4.35 Tampilan Manage Roles................................................................ 136
Gambar 4.36 Tampilan Manage Permissions ..................................................... 136
Gambar 4.37 Tampilan Manage Departemen ..................................................... 137
Gambar 4.38 Pengajuan Dokumen ..................................................................... 137
Gambar 4.39 Verifikasi Dokumen ...................................................................... 138
Gambar 4.40 Revisi Dokumen ............................................................................ 138
Gambar 4.41 Disposisi ........................................................................................ 139
Gambar 4.42 Pencairan ....................................................................................... 139
Gambar 4.43 Lembar Laporan ............................................................................ 140
xxi
DAFTAR TABEL
Tabel 2.1 Kriteria Pemilihan Metodologi Pengembangan Sistem ....................... 24
Tabel 2.1 Kriteria Pemilihan Sebuah Teknik Pengujian ....................................... 51
Tabel 3.1 Tabel Perbandingan Literatur Sejenis ................................................... 57
Tabel 4.1 User Stories ........................................................................................... 67
Tabel 4.2 Rincian User Stories ............................................................................. 68
Tabel 4.3 Acceptance Criteria Pendaftaran User ................................................. 69
Tabel 4.4 Acceptance Criteria Melakukan Pendataan Proses Pengajuan GUP .... 69
Tabel 4.5 Acceptance Criteria Mengelola File Dokumen .................................. 70
Tabel 4.6 Acceptance Criteria Mencari Informasi Dokumen ............................... 70
Tabel 4.7 Acceptance Criteria Mendapatkan Kontrol Waktu Proses Dokumen .. 70
Tabel 4.8 Acceptance Criteria Berinteraksi dengan User Lain ............................ 70
Tabel 4.9 Acceptance Criteria Melihat Laporan Hasil Pengajuan ....................... 70
Tabel 4.10 Product Backlog .................................................................................. 71
Tabel 4.11 Identifikasi Aktor ................................................................................ 75
Tabel 4.12 Identifikasi Use Case .......................................................................... 76
Tabel 4.13 Narasi Use Case Sign Up .................................................................... 80
Tabel 4.14 Narasi Use Case Login ........................................................................ 81
Tabel 4.15 Narasi Use Case Forgot Password ..................................................... 82
Tabel 4.16 Narasi Use Case Manage Users.......................................................... 82
Tabel 4.17 Narasi Use Case Manage Roles .......................................................... 84
Tabel 4.18 Narasi Use Case Manage Permissions ............................................... 85
Tabel 4.19 Narasi Use Case Manage Departemen ............................................... 87
Tabel 4.20 Narasi Use Case Input Data Dokumen ............................................... 88
xxii
Tabel 4.21 Narasi Use Case Submit Pengajuan .................................................... 89
Tabel 4.22 Narasi Use Case Verifikasi Dokumen ................................................ 90
Tabel 4.23 Narasi Use Case Submit Data Revisi .................................................. 90
Tabel 4.24 Narasi Use Case Disposisi Hasil ......................................................... 91
Tabel 4.25 Narasi Use Case Proses Pencairan ...................................................... 92
Tabel 4.26 Narasi Use Case Submit Data Pencairan............................................. 93
Tabel 4.27 Narasi Use Case Melihat Laporan Hasil ............................................. 93
Tabel 4.28 Narasi Use Case Log Out .................................................................... 94
Tabel 4.29 Daftar Obyek Potensial ..................................................................... 108
Tabel 4.30 Daftar Obyek Potensial yang Diusulkan ........................................... 109
Tabel 4.31 Basis Data Users ............................................................................... 124
Tabel 4.32 Basis Data Password Resets ............................................................. 125
Tabel 4.33 Basis Data Permissions ..................................................................... 126
Tabel 4.34 Basis Data Roles................................................................................ 126
Tabel 4.35 Basis Data Role Has Permissions ..................................................... 127
Tabel 4.36 Basis Data Jenis Dokumen ................................................................ 127
Tabel 4.37 Basis Data Dokumen ......................................................................... 127
Tabel 4.38 Basis Data Pengajuan ........................................................................ 128
Tabel 4.39 Basis Data Verifikasi ........................................................................ 129
Tabel 4.40 Basis Data Revisi .............................................................................. 129
Tabel 4.41 Basis Data Disposisi.......................................................................... 130
Tabel 4.42 Basis Data Pencairan ......................................................................... 131
Tabel 4.43 Basis Data Threads ........................................................................... 132
Tabel 4.44 Basis Data Messages ......................................................................... 132
Tabel 4.45 Basis Data Participants ..................................................................... 133
xxiii
Tabel 4.48 Skenario Pengujian ........................................................................... 141
Tabel 4.49 Pengujian Input Data Dokumen ........................................................ 142
Tabel 4.50 Pengujian Pengajuan Dokumen ........................................................ 142
Tabel 4.51 Pengujian Verifikasi Dokumen ......................................................... 143
Tabel 4.52 Pengujian Revisi Dokumen ............................................................... 144
Tabel 4.53 Pengujian Disposisi Dokumen .......................................................... 144
Tabel 4.54 Pengujian Pencairan Dokumen ......................................................... 145
xxiv
DAFTAR SIMBOL
1. Use Case (Object Management Group, 2011)
Nama Simbol Deskripsi
Aktor
Sebuah aktor merepresentasikan sebuah
peranan dari luar sistem yang
berinteraksi dengan sistem bisnis.
Sebuah aktor bisa berupa customer,
partner bisnis, dll.
Business Use case
Mendeskripsikan interaksi antara aktor
dan sistem bisnis. Yang berarti
mengambarkan fungsi dari sistem bisnis
yang aktor gunakan.
Asosiasi
Asosiasi adalah penghubung antara
aktor dan business use case,
menggambarkan bahwa aktor dapat
menggunakan business use case yang
ada dalam sistem.
Include
Menghubungkan antara sesama
business usecase yang berarti sebuah
business usecase menyediakan business
usecase lainnya yang bisa diakses.
Extend
Menghubungkan antara sesama
business usecase yang berarti sebuah
business usecase menyediakan business
usecase lainnya yang bisa diakses.
Subject Subyek diartikan sebagai lingkup dari
sistem bisnis yang di dalamnya terdapat
beberapa Business Use case.
use case
actor
<<include>>
<<extend>>
xxv
2. Activity Diagram (Object Management Group, 2011)
Nama Simbol Deskripsi
Activity
Partition
Menujukkan siapa yang bertanggung
jawab melakukan aktivitas dalam
suatu diagram.
Intial node
Menujukkan dimana aliran kerja itu
dimulai.
Final node
Menujukkan dimana aliran kerja itu
berakhir.
Action
Action adalah langkah-langkah
dalam sebuah activity. Action bisa
memproses input dan output
informasi.
Join Join menunjukkan penggabungkan
dalam aliran kerja berjalan secara
serentak.
Fork Fork menunjukkan percabangan
dalam aliran kerja berjalan secara
serentak.
Edge Mengkoneksikan antar komponen
dari activity diagram, dan
diilustrasikan sebagai alur aktifitas.
Decision node
Merupakan percabangan kondisional
atau keputusan.
3. Sequence Diagram (Object Management Group, 2011)
Nama Simbol Deskripsi
Object
Merepresentasikan entitas tunggal dalam
sequence diagram, digambarkan dengan kotak.
Swimlane1
Object1
Activity1
xxvi
Lifeline Kurun waktu sebuah obyek selama sequence.
Message Menyampaikan sebuah informasi dari satu obyek
ke obyek lain. Dibagi menjadi dua yaitu
mengirim dan balasan.
1
BAB 1
PENDAHULUAN
1.1 Latar Belakang
Satuan Pemeriksa Intern (SPI) Universitas Islam Negeri Syarif Hidayatullah
yang dibentuk berdasarkan SK Rektor Nomor 161 Tahun 2008, merupakan
organisasi pengawasan yang mempunyai tugas melaksanakan pengawasan,
pengendalian, evaluasi dan audit dalam rangka mewujudkan sistem pengelolaan
keuangan negara yang transparan, akuntabel dan terukur yang terkandung pada
Peraturan Pemerintah Nomor 60 Tahun 2008 mengenai Sistem Pengendalian Intern
Pemerintah.
Berdasarkan tugas Satuan Pemeriksa Intern yang telah diuraikan, Satuan
Pemeriksa Intern memiliki kebutuhan informasi mengenai penelusuran keberadaan,
rekam data, dan status dari dokumen proses pencairan dan penerimaan keuangan,
khususnya dokumen terkait dengan Uang Persediaan di Universitas Islam Negeri
Syarif Hidayatullah.
Revolving Fund (Uang Persediaan) seperti yang tercantum pada Pasal 1
Peraturan Menteri Keuangan Nomor 190/PMK.05/2012 adalah uang muka kerja
dalam jumlah tertentu yang diberikan kepada bendahara pengeluaran untuk
membiayai operasional sehari-hari satuan kerja atau pengeluaran yang tidak
mungkin dilakukan mekanisme pembayaran langsung. Uang Persediaan ini terkait
dengan prosedur Ganti Uang Persediaan (GUP) dan Tambah Uang Persediaan
(TUP). Ganti Uang Persediaan adalah mekanisme pengajuan penggantian atas
2
Uang Persediaan yang telah diberikan pada awal tahun anggaran, sedangkan
Tambah Uang Persediaan adalah uang yang diberikan kepada Bendahara
Pengeluaran untuk kebutuhan mendesak dan akan habis digunakan dalam 1 bulan
terhitung sejak tanggal dikeluarkannya cek. Satuan Pemeriksa Intern sebagai organ
pengawasan kampus, ikut serta dalam pengelolaan, pemeriksaan dokumen-
dokumen uang persediaan yang dijelaskan sebelumnya, dokumen-dokumen
tersebut berasal dari berbagai fakultas dan program studi hingga ke bendahara
pengeluaran universitas, oleh karena itu manajemen dan kontrol terhadap dokumen-
dokumen tersebut sangatlah penting.
Proses ganti uang persediaan melibatkan staf keuangan tingkat fakultas
menyiapkan dokumen pengajuan ganti uang persediaan yang diserahkan kepada
Kuasa Pengguna Anggaran (KPA) berikut dengan berbagai dokumen yang perlu
diproses dan dikelola seperti surat permintaan pembayaran, surat permohonan
pencairan, surat pertanggungjawaban, surat pernyataan, laporan dana operasional,
serta bukti-bukti pembayaran belanja. Kuasa pengguna anggaran menerima
dokumen tersebut, kemudian meneruskan kepada SPI untuk proses verifikasi. SPI
menerima dan melakukan verifikasi dengan waktu dua hari dan memberikan
tanggapan yang jika disetujui akan ditindaklanjuti Kasubbag Verifikasi dalam
waktu satu hari dan jika tidak disetujui akan kembali ke staf keuangan fakultas.
Kasubbag Verifikasi memberikan disposisi hasil tindak lanjut kepada Bendahara
Pengeluaran Pembantu (BPP) untuk proses pencairan. BPP nantinya akan
menyerahkan dana tersebut dan menyatakan proses telah selesai.
3
Namun pada pelaksanaan proses tersebut, sering kali SPI maupun unit
lainnya yang terlibat tidak mengetahui keberadaan maupun status dokumen karena
belum adanya sistem khusus yang membantu SPI untuk merekam data, menelusuri
keberadaan, memberikan informasi realtime terkait waktu yang ditetapkan standar
operasional,serta mengelola dokumen uang persediaan tersebut secara digital.
Padahal masalah manajemen dokumen seperti ini memiliki ruang lingkup yang luas
karena meliputi banyak data dokumen, surat-surat dan bukti penting dari berbagai
fakultas dan unit-unit yang terkait dalam prosedur ini, terlebih lagi resiko hilangnya
dokumen karena kelalaian maupun musibah.
Di dalam SPI, rekam data dan penelusuran dokumen ini sangatlah
dibutuhkan karena hal-hal tersebut adalah salah satu bentuk dari pengawasan,
pengendalian yang merupakan tugas dari SPI. Informasi tersebut juga dapat
menjadi bahan tindak lanjut dari unit-unit yang terlibat di dalamnya.
Berdasarkan uraian sebelumnya, penulis bermaksud untuk mewujudkan
rancangan Revolving Fund Document Management System berbasis web yang dapat
mengakomodir serta mendukung proses pengelolaan, penelusuran serta kontrol
terhadap dokumen uang persediaan yang ada di lingkungan Universitas Islam
Negeri Syarif Hidayatullah. Oleh karena itu, penelitian ini berjudul “Rancang
Bangun Revolving Fund Document Management System (Studi Kasus: SPI
Universitas Islam Negeri Syarif Hidayatullah)”.
1.2 Identifikasi Masalah
4
Berdasarkan analisis yang telah dijelaskan, maka dapat diidentifikasi empat
permasalahan yang dihadapi SPI UIN Syarif Hidayatullah yaitu:
1. SPI dan aktor lain tidak dapat memantau dan mengontrol aliran dokumen
secara realtime sehingga aktor yang terlibat kesulitan untuk mengetahui
status dan posisi dokumen;
2. Misinformasi yang dikarenakan kurangnya koordinasi mengenai
keterlambatan proses pengelolaan uang persediaan;
3. Waktu pemrosesan dokumen seperti proses verifikasi dan revisi yang tidak
sesuai SOP, proses sering kali lebih dari 2 hari untuk proses verifikasi dan
lebih dari 1 hari untuk proses revisi.
1.3 Rumusan Masalah
Berdasarkan identifikasi masalah yang telah diuraikan sebelumnya, maka
dapat dirumuskan permasalahan yaitu, “Bagaimana membangun sebuah Revolving
Fund Document Management System berbasis web di Universitas Islam Negeri
Syarif Hidayatullah Jakarta?”.
1.4 Batasan Masalah
Berdasarkan identifikasi masalah, maka batasan masalah penelitian skripsi
ini yaitu:
a. Platform yang digunakan adalah berbasis web.
b. Penelitian ini dilakukan di Universitas Islam Negeri Syarif Hidayatullah Jakarta
dan hanya pada proses manajemen dokumen dari proses ganti uang persediaan
5
tingkat fakultas yang melibatkan Staf Keuangan Fakultas, Kuasa Pengguna
Anggaran, SPI, Kasubbag Verifikasi dan Bendahara Pengeluaran Pembantu.
c. Penelitian ini terfokus pada pengelolaan file dokumen, koordinasi antar unit dan
laporan dari informasi waktu pengelolaan dokumen.
d. Metode Pengembangan Sistem yang digunakan adalah SCRUM.
e. Tools yang digunakan alat bantu analisis dan perancangan sistem adalah Unified
Modelling Language versi 2.4 yang meliputi use case, narasi use case, activity
diagram, class diagram, sequence diagram dan skema database.
f. Proses pengembangan sistem dilakukan dengan menggunakan HTML, CSS, dan
JQuery 3.4.1 sebagai frontend sistem. Pada backend sistem, penulis
menggunakan bahasa pemrograman PHP versi 7.2 dengan Laravel 5.7 sebagai
framework dan MariaDB sebagai sistem database.
g. Tidak membahas keamanan jaringan dan sistem secara mendalam.
1.5 Tujuan Penelitian
Penelitian ini tentu memiliki tujuan-tujuan yang ingin dicapai. Tujuan dari
penelitian ini adalah:
a. Mendukung proses koordinasi antar unit dan pengelolaan dokumen ganti uang
persediaan.
b. Memberikan informasi waktu proses pada tiap unit berdasarkan SOP yang sudah
ditetapkan untuk pengelolaan ganti uang persediaan.
c. Memberikan kontribusi kepada UIN Syarif Hidayatullah Jakarta dengan
menghasilkan rancang bangun Revolving Fund Document Management System
6
sebagai langkah awal menuju pengelolaan dokumen uang persediaan secara
online.
1.6 Manfaat Analisis
Adapun manfaat yang didapat dari penelitian skripsi ini adalah sebagai
berikut:
1. Manfaat Bagi Mahasiswa
a. Meningkatkan pengetahuan penulis terhadap proses pengelolaan uang
persediaan yang ada di Universitas Islam Negeri Syarif Hidayatullah Jakarta.
b. Menambah kemampuan penulis dalam ilmu pemrograman PHP terutama
dalam penggunaan Framework Laravel yang umum digunakan sebagai tools
yang umum digunakan dalam pengembangan aplikasi web di dunia kerja dan
segala hal yang berkaitan dengan metodologi penulisan skripsi.
2. Manfaat Bagi Instansi
a. Memudahkan dalam koordinasi dan mengelola dokumen uang persediaan.
b. Mendukung proses bisnis ganti uang persediaan.
3. Manfaat Bagi Universitas
a. Mengetahui kemampuan siswa dalam mengaplikasikan ilmu yang telah
dipelajari selama masa perkuliahan;
b. Dapat menambah referensi penelitian mengenai sistem manajemen dokumen
1.7 Metode Penelitian
Pada penelitian ini, penulis menggunakan beberapa metode yang digunakan
dalam merancang sistem ini, yaitu sebagai berikut.
7
1.7.1 Metode Pengumpulan Data
Untuk melakukan berbagai analisis dalam penelitian ini, penulis
menggunakan beberapa metode dalam pengumpulan data sebagai materi yang
mendukung pada uraian dan pembahasan selanjutnya. Pengumpulan data adalah
prosedur standar dalam memperoleh data yang diperlukan dalam penelitian.
Metode yang penulis gunakan antara lain:
1.7.1.1 Observasi
Pada metode observasi, penulis mengumpulkan data dan informasi dengan
meninjau dan mengamati secara langsung ke lapangan, bagaimana sistem berjalan
dan kebutuhan SPI berdasarkan permasalahan yang ada, lalu mengumpulkan semua
data yang dibutuhkan dalam penelitian ini.
Observasi dibantu langsung oleh staf dari SPI dengan menjelaskan sistem
berjalan serta kebutuhan organisasi dalam mengelola data dari mekanisme Uang
Persediaan.
1.7.1.2 Wawancara
Wawancara dilakukan dengan adanya interaksi tanya jawab dengan staf SPI
UIN Syarif Hidayatullah untuk menggali informasi yang dibutuhkan mengenai
prosedur Ganti Uang Persediaan dan Tambah Uang Persediaan.
1.7.1.3 Studi Pustaka
Data dan informasi yang dihimpun dari sumber-sumber media cetak
ataupun elektronik serta buku pedoman yang terkait dengan proses pencairan dan
penerimaan dana di SPI. Sumber literatur yang digunakan dalam penelitian yang
8
diperoleh dari penelitian serupa dan sistem yang berkaitan dengan pengawasan,
pengelolaan, dan pengendalian dokumen.
1.7.2 Metode Pengembangan Sistem
Metode pengembangan sistem yang digunakan dalam penelitian ini adalah
Scrum. Tahapan-tahapan metode pengembangan dijelaskan sebagai berikut:
1. Sprint Planning
Pada tahap ini peneliti menyusun product backlog yang merupakan fitur-fitur
atau komponen yang ditentukan bersama tim pengembang sistem dan product
owner. Product backlog disusun berdasarkan user stories yang didiskusikan
oleh product owner ataupun stakeholder sebagai guideline dalam
mengambangkan fitur-fitur yang akan dibangun pada sistem.
2. Daily Scrum
Pada tahap ini peneliti merancang sistem yang nantinya akan memecah
product backlog menjadi sprint backlog yang berisikan tugas-tugas yang
harus diselesaikan agar dapat memenuhi tujuan Sprint. Pada tahap ini penulis
melakukan perancangan sistem dengan menggunakan UML sebelum
melakukan proses pengembangan sistem. Pada tahap ini, peneliti menentukan
apa yang harus dilakukan pada sprint backlog yang berisikan tugas-tugas
yang lebih spesifik untuk menyelesaikan item dari product backlog. Pada
tahap ini proses pemrograman beserta perancangan antar muka dilakukan.
3. Sprint Review
Pada tahap ini masa Sprint telah berakhir dan peneliti melakukan review
bersama tim dengan melakukan demonstrasi terhadap Product Backlog yang
9
telah diselesaikan selama masa Sprint. Item dari Product Backlog yang telah
diselesaikan diuji dengan anggota tim dengan menggunakan metode black
box testing dengan teknik Scenario Based Testing agar user yang awam
secara ilmu pemrograman dapat memahami fitur yang sedang diuji.
4. Sprint Retrospective
Pada tahap ini keseluruhan fase Sprint telah berakhir, peneliti melakukan
peninjauan ulang terhadap kinerja pengembangan sistem dan melakukan
perbaikan terhadap hal-hal yang menjadi masalah dalam pengembangan
product backlog di Sprint selanjutnya.
1.8 Sistematika Penulisan
Penyusunan Laporan Penelitian Skripsi ini penulis bagi dalam beberapa bab
yang secara singkat dapat dijelaskan sebagai berikut:
BAB 1 PENDAHULUAN
Bab ini menerangkan tentang latar belakang masalah, identifikasi
masalah, perumusan masalah, batasan masalah, tujuan penelitian,
manfaat penelitian, metode penelitian serta sistematika penulisan.
BAB 2 LANDASAN TEORI
Bab ini menguraikan konsep ataupun teori yang mendukung dan
berhubungan dengan rancang bangun Revolving Fund Document
Management System atau Sistem Manajemen Dokumen Uang
Persediaan berbasis web.
BAB 3 METODOLOGI PENELITIAN
10
Bab ini menguraikan penjelasan metode penelitian yang
digunakan, mulai dari metode pengumpulan data yang digunakan
dan juga menjelaskan metode pengembangan sistem yang
digunakan untuk rancang bangun Revolving Fund Document
Management System berbasis web ini.
BAB 4 HASIL DAN PEMBAHASAN
Bab ini berisi penjelasan dan pembahasan mengenai proses
pengembangan sistem Revolving Fund Document Management
System berbasis web berdasarkan tahapan-tahapan yang ada pada
metodologi pengembangan sistem Scrum, mulai dari sprint
planning, daily scrum, hingga sprint review yang berisi pengujian
sistem dengan teknik scenario based testing.
BAB 5 PENUTUP
Bab ini merupakan bab terakhir yang berisi simpulan dari apa
yang telah diuraikan pada bab sebelumnya, serta saran perbaikan
dan pengembangan sistem ini untuk penelitian di masa
mendatang.
12
BAB 2
LANDASAN TEORI
2.1 Konsep Dasar Rancang Bangun Sistem
Menurut Pressman (2015) perancangan atau rancang merupakan
serangkaian prosedur untuk menerjemahkan hasil analisis dari suatu sistem ke
dalam bahasa pemrograman untuk mendeskripsikan dengan detail bagaimana
komponen-komponen sistem diimplementasikan.
Menurut Pressman (2015) pengertian pembangunan atau bangun sistem
adalah kegiatan menciptakan sistem baru maupun mengganti atau memperbaiki
sistem yang ada secara keseluruhan.
Menurut Stair and Reynolds (2010) perancangan sistem adalah fase
pengembangan sistem yang mendefinisikan bagaimana sistem informasi akan
melakukan perancangan untuk mendapatkan solusi pemecahan masalah.
“Proses software development berisikan aktifitas, aksi, dan tugas yang harus
dilakukan ketika ingin membangun sebuah software. Sebuah aktifitas bertujuan
untuk mendapatkan hasil yang diinginkan dan dengan menentukan kebutuhan
proyek seperti ruang lingkup, ukuran, dan kompleksitas. Selain itu sebuah aksi
untuk menentukan tugas-tugas yang harus dilakukan, dan yang terakhir tugas
harus focus pada sesuatu yang simpel, tapi terjabarkan dan dapat menghasilkan
sesuatu yang nyata dan bernilai.” (Pressman dan Maxim, 2015)
Dari semua uraian di atas, maka dapat disimpulkan bahwa rancang bangun
adalah serangkaian prosedur untuk menerjemahkan hasil analisa ke dalam bahasa
13
pemrograman dan cara implementasinya untuk menciptakan sistem yang baru
maupun memperbaiki suatu sistem yang sebelumnya.
2.2 Konsep Document Management System
2.2.1 Pengertian Manajemen
Menurut Faisal (dalam Wulandari, 2014), bahwa inti dari manajemen
adalah manage yang berarti mengelola, secara harfiah mengelola juga identik
dengan memelihara, merawat dan membuat segala sesuatu menjadi berarti karena
ada yang mengontrol.
2.2.2 Pengertian Dokumen
Menurut Kamus Besar Bahasa Indonesia, dokumen yaitu surat yang tertulis
atau tercetak yang dapat dipakai sebagai bukti keterangan ,sedangkan menurut
Sukoco (2007), ia menjelaskan bahwa dokumen juga dapat didefinisikan sebagai
informasi yang diciptakan, diterima, dan dikelola sebagai bukti maupun informasi
yang oleh organisasi atau perorangan digunakan untuk memenuhi kewajiban
hukum atau transaksi bisnis.
2.2.3 Pengertian Dokumen Elektronik
Menurut Undang-Undang nomor 11 tahun 2008 tentang informasi dan
transaksi elektronik (ITE) menjelaskan bahwa Dokumen Elektronik adalah setiap
informasi elektronik yang dibuat, diteruskan, dikirimkan, diterima, atau disimpan
dalam bentuk analog, digital, elektromagnetik, optikal, atau sejenisnya, yang dapat
dilihat ditampilkan dan/atau didengar melalui komputer atau sistem elektronik
tetapi tidak terbatas pada tulisan, suara, gambar, peta rancangan, foto atau
14
sejenisnya, huruf, tanda, angka, kode akses, simbol atau perforasi yang memiliki
makna atau arti atau dapat dipahami oleh orang yang mampu memahaminya.
2.2.4 Pengertian Document Management System
. Menurut Wiggins et al (2007), Sistem Manajemen Dokumen atau Document
Management System adalah suatu aplikasi yang digunakan untuk melacak dan
menyimpan gambar dari kertas atau dokumen elektronik. Sedangkan menurut
Panduwinata (dalam Gunardi, 2014), Sistem Manajemen Dokumen merupakan
sistem berbasis komputer yang menyediakan tempat penyimpanan berbasis web
yang dapat diakses dari berbagai tempat. Inti pada sistem manajemen dokumen
adalah tempat penyimpanan terpusat (centralized repository), sebuah medium
elektronik tempat penyimpanan (storage) dengan sebuah lokasi storage utama yang
mampu menyediakan banyak akses ke dalamnya.
2.2.5 Nilai Tambah Document Management System
Menurut Panduwinata (dalam Gunardi, 2014), sistem manajemen dokumen
dapat diterapkan secara ‘cheap and cheerful’, beroperasi pada sejumlah fungsi yang
terbatas atau dapat juga yang berkembang sepenuhnya, sistem yang mahal dengan
sejumlah fungsi yang besar dan berpotensi menakutkan dalam istilah dampak
mereka terhadap proses-proses organisatoris dan pelaksana kegiatan-kegiatan
administrasi.
Fasilitas-fasilitas nilai tambah pada sistem manajemen dokumen meliputi:
a. Mengontrol untuk menjamin hanya satu user saja yang memodifikasi
sebuah dokumen pada satu waktu
15
b. Memeriksa jejak untuk mengawasi perubahan-perubahan yang terjadi pada
sebuah dokumen setiap waktu.
c. Menyiapkan keamanan untuk mengontrol akses user kepada dokumen-
dokumen.
d. Pengaturan dokumen-dokumen ke dalam groups yang berhubungan dan
folders.
e. Pengenalan dan mendapatkan kembali dari dokumen-dokumen sesuai
dengan teks yang ada pada dokumen-dokumen tersebut (freetext searching).
f. Mencatat informasi yang berhubungan dengan dokumen sebagai metadata,
seperti pengarang, tanggal pembuatan dan judul.
g. Kemampuan untuk mengirimkan dokumen-dokumen dari satu user kepada
user lainnya dalam kebiasaan yang terkontrol berdasarkan workflow.
h. Merubah dokumen-dokumen kertas ke dalam format elektronik dengan
melakukan scanning.
i. Mengatur dokumen-dokumen ke dalam grup-grup untuk memungkinkan
dokumen-dokumen tersebut untuk didistribusikan kepada target pencari
atau pembaca.
Pilihan sistem manajemen dokumen adalah mungkin untuk memberikan
pengaruh kepada budaya organisasi atau, tergantung pada skalanya, mungkin juga
hanya mencerminkan budaya yang dominan.
2.2.6 Keuntungan Dokumen Elektronik
Penggunaan Document Management System pada suatu organisasi tentu
memiliki keuntungan dan kerugian tersendiri. Seperti yang dijelaskan oleh
16
Komalasari (dalam Gunardi, 2014), keuntungan atau kelebihan dokumen elektronik
atau digital dibandingkan dengan dokumen konvensional di antaranya:
1. Sistem digital lebih mudah dirancang
2. Informasi lebih mudah disimpan
3. Lebih menghemat ruangan
4. Dapat diakses oleh banyak orang dalam waktu bersamaan
5. Tidak dibatasi ruang dan waktu
6. Dokumen yang tersimpan dapat diakses dengan cepat, tepat dan akurat
7. Dokumen dapat berbentuk multimedia (kombinasi antara teks, gambar dan
suara).
2.2.7 Kerugian Dokumen Elektronik
Selain memiliki keuntungan, penggunaan dokumen elektronik juga
memiliki kekurangan di antaranya (Saleh, 2009):
1. Kesulitan membaca layar komputer. Kesulitan ini muncul karena pada saat
mengakses online journal secara bersamaan user membuka windows
lainnya cara ini berpengaruh juga pada proses download dari hasil akhirnya.
2. Sering tidak memasukkan indeks dan abstrak. Pada umumnya artikel yang
terdapat pada online journals menyediakan keduanya, tetapi ada juga yang
tidak melengkapi salah satunya.
3. Sitasi yang mudah rusak, perubahan url menjadikan akses ke online
journals menjadi terganggu bahkan hilang semuanya.
17
4. Keaslian, sumber dan otoritas material secara umum menjadi perhatian pada
akses online journals . Kredibilitas pembacanya selalu harus diperhatikan
oleh online journals .
5. Mesin pencari mengabaikan file PDF, perlu memperhatikan format dari
artikel online journals . Format yang tersedia merupakan copy dari versi
jurnal tercetaknya.
2.2.8 ISO 15489
ISO 15489 adalah standar internasional yang mendefinisikan best practice
untuk manajemen dari kertas dan dokumen elektronik serta record. Standar ISO
15489 didefinisikan dan dikelola oleh International Organization for
Standarization (ISO). Hal ini didasarkan pada Australia standar AS 4390-1996:
Records Management, yang telah dipromosikan standar terbaik untuk praktek
Record Keeping. Setelah ISO 15489 terbit, Pemerintah Australia mencabut standar
Australia AS 4390-1996, menggantinya dengan AS ISO 15489.
Standar ISO 15489 ditunjukan untuk semua organisasi yang perlu
memastikan bahwa dokumen dan catatan mereka dipelihara dengan baik, dapat
diproses, dikategorikan, dan diindeks dari awal pembuatan dokumen sampai akhir
penggunaan dokumen tersebut, yang bisa berupa pembuangan, pengarsipan, atau
memindahkan dokumen atau catatan untuk penyimpanan.
18
2.3 Konsep Uang Persediaan
2.3.1 Pengertian Uang Persediaan (Revolving Fund) Menurut Peraturan
Menteri Keuangan Nomor 190/PMK.05/2012
Menurut Peraturan Menteri Keuangan Nomor 190/PMK.05/2012, uang
persediaan (UP) adalah uang muka kerja dalam jumlah tertentu yang diberikan
kepada Bendahara Pengeluaran untuk membiayai kegiatan operasional sehari-hari
Satker atau membiayai pengeluaran yang menurut sifat dan tujuannya tidak
mungkin dilakukan melalu mekanisme pembayaran langsung.
Menurut Peraturan Rektor UIN Syarif Hidayatullah Jakarta Un.01
/R/HK.00.5/02/2014, Uang Persediaan yang selanjutnya disebut UP adalah uang
muka kerja dengan jumlah tertentu yang bersifat daur ulang (revolving).
2.4 Konsep Ganti Uang Persediaan
2.4.1 Pengertian Ganti Uang Persediaan dalam Peraturan Rektor UIN Syarif
Hidayatullah Jakarta Un.01/R/HK.00.5/02/2014
Ganti Uang Persediaan (GUP) adalah mekanisme pengajuan penggantian
(revolving) atas UP yang telah diberikan pada awal tahun anggaran. Berikut adalah
penjelasan dari proses ganti uang persediaan berdasarkan nomor yang tertera pada
gambar sebelumnya:
1. Menyiapkan dokumen
Pengelola keuangan fakultas menyiapkan dokumen pengajuan pencairan
Ganti Uang Pesediaan (GUP) kemudian diserahkan kepada Kuasa Pengguna
Anggaran.
19
2.4.2 Mekanisme Ganti Uang Persediaan
Gambar 2.1 Mekanisme GUP
(KPA)
(SPI)
20
2. Pengajuan Dokumen
Kuasa Pengguna Anggaran menerima dokumen pengajuan permohonan
Ganti Uang Persediaan kemudian (GUP) kemudian diteruskan kepada SPI (SPI)
untuk proses verifikasi.
3. Verifikasi Dokumen
SPI menerima dan melakukan verifikasi atas dokumen permohonan
pencairan GUP paling lambat 2 hari setelah pemasukan dokumen permohonan.
4. Disposisi kepada Kasubag Verifikasi
SPI menyerahkan disposisi dan dokumen pengajuan pencairan GUP
paling lambat 1 hari setelah tanggal pemasukan dokumen perbaikan kepada
kepala subbagian verifikasi untuk ditindaklanjuti.
5. Disposisi kepada Bendahara Pengeluaran Pembantu
Kepala subbagian verifikasi mendisposisi dokumen pengajuan pencairan
gup paling lambat 1 hari setelah tanggal disposisi kepada bendahara pengeluaran
pembantu untuk diproses.
6. Proses Pencairan
Bendahara Pengeluaran Pembantu (BPP) enyelesaikan proses
administrasi dan pengarsipan.
2.5 Konsep Tambah Uang Persediaan
2.5.1 Pengertian Tambah Uang Persediaan dalam Peraturan Rektor UIN
Syarif Hidayatullah Jakarta Un.01/R/HK.00.5/02/2014
21
Tambahan Uang Persediaan (TUP) adalah uang muka yang diberikan
kepada Bendahara Pengeluaran untuk kebutuhan yang sangat mendesak dalam 1
(satu) bulan terhitung sejak tanggal dikeluarkannya cek.
2.5.2 Mekanisme Tambah Uang Persediaan
Gambar 2.2 Mekanisme TUP
Pejabat Penandatangan Surat Perintah Membayar
Pengelola Keuangan Fakultas/Rektorat/Unit
Kuasa Pengguna Anggaran
Satuan Pemeriksa Intern Bendahara Pengeluaran Pembantu
KPPN Jakarta
22
Berikut adalah penjelasan dari proses tambah uang persediaan berdasarkan
nomor yang tertera pada Gambar 2.2.
1. Menyiapkan Dokumen:
Bendahara Pengeluaran Pembantu dan Pejabat Pembuat Komitmen menyiapkan
dokumen pengajuan pencairan Tambahan Uang Persediaan kemudian
diserahkan kepada Pejabat Penandatangan Surat Perintah Membayar (PPSPM)
untuk diotorisasi.
2. Otorisasi Dokumen:
PPSPM mengotorisasi Surat Permintaan Pembayaran Tambah Uang Persediaan
(SPP TUP) dengan menandatangani Surat Perintah Membayar Tambah Uang
Persediaan (SPM TUP), kemudian menyerahkan dokumen pengajuan TUP
tersebut kepada Kuasa Pengguna Anggaran (KPA).
3. Pengajuan Dokumen:
KPA menerima dokumen pengajuan permohonan Tambahan Uang Persediaan
kemudian diteruskan kepada SPI untuk proses verifikasi.
4. Verifikasi dan Disposisi Dokumen:
SPI menerima dan melakukan verifikasi atas dokumen permohonan pencairan
TUP paling lambat 2 hari kerja setelah pemasukan dokumen. SPI menyerahkan
disposisi dan dokumen pengajuan pencairan TUP paling lambat 1 hari setelah
tanggal pemasukan dokumen perbaikan kepada Kepala Subbagian Verifikasi
untuk ditindaklanjuti.
23
5. Disposisi ke Bendahara Pengeluaran:
Kepala Subbagian Verifikasi mendisposisi dokumen pengajuan pencairan TUP
paling lambat 1 hari setelah tanggal disposisi kepada atasan langsung BP untuk
diproses pencairan TUP.
6. Disposisi ke Bendahara Pengeluaran Pembantu:
Bendahara Pengeluaran menyetujui dan menyerahkan dokumen pengajuan
pencairan TUP paling lambat 1 hari setelah tanggal disposisi kepada Bendahara
Pengeluaran Pembantu untuk diproses.
7. Mengajukan Pencairan:
Bendahara Pengeluaran Pembantu (BPP) mengajukan pencairan kepada KPPN
Jakarta IV.
8. Pengarsipan Surat
Bendahara Pengeluaran Pembantu (BPP) mengarsip rangkap 2 copy Surat
Permintaan Pembayaran Tambahan Uang Persediaan (SPP TUP) dan Surat
Perintah Membayar Tambahan Uang Persediaan (SPM TUP).
9. Pencairan Selesai
KPPN Jakarta IV melakukan proses transfer dengan menerbitkan surat perintah
pencairan dana dan menyerahkan ke bendahara pengeluaran.
24
2.6 Metodologi Pengembangan Sistem
2.6.1 Pengertian Metodologi Pengembangan Sistem
Menurut Jogiyanto (2010) metodologi adalah metode-metode, prosedur-
prosedur, konsep-konsep pekerjaan, aturan-aturan dan postulat-postulat yang akan
digunakan untuk mengembangkan suatu sistem informasi.
Tidak ada metodologi yang bisa digunakan untuk semua perangkat lunak,
semua metodologi memiliki keunikan cara kerja yang berbeda (Sommerville,
2011).
Tabel 2.1 Kriteria Pemilihan Metodologi Pengembangan Sistem (Dennis et al,
2012)
Setiap pengembangan sebuah aplikasi pasti memiliki lingkungan, masalah, dan
pendekatan yang berbeda.
2.6.2 System Development Life Cycle (SDLC)
SDLC adalah proses menentukan bagaimana sistem informasi dapat
membantu kebutuhan bisnis, merancang sistem, membangun, dan menyerahkannya
kepada pengguna (Dennis, et al, 2012).
25
Gambar 2.3 System Development Life Cycle (Dennis et al, 2012)
Menurut Kendall dan Kendall (2014) SDLC adalah fase pendekatan dalam
menganalisis dan merancang sebuah sistem yang dikembangkan dengan baik,
dengan menggunakan siklus spesifik. Tahapan-tahapan pada SDLC diantaranya
(Dennis et al, 2012):
1. Perencanaan: tahap perencanaan merupakan proses yang mendasar untuk
memahami kenapa sebuah sistem informasi dibutuhkan dan menentukan
bagaimana cara untuk membangunnya.
2. Analisis: pada tahap ini, tim pengembang menganalisis beberapa faktor-
faktor pengembangan, seperti pertanyaan siapa pemakai sistem tersebut, apa
yang dilakukan sistem, dll. Tim pengembang juga mengidentifikasi apa saja
kebutuhan sistem yang akan dibangun.
3. Perancangan: pada tahap perancangan, ditentukan bagaimana sistem akan
beroperasi, dalam hal ini yaitu hardware, software, jaringan, tampilan antar
muka, formulir, fitur, database dan file yang dibutuhkan.
4. Implementasi: merupakan tahap akhir dalam SDLC yang merupakan proses
penerapan dari hasil perencanaan, analisis dan desain untuk membangun
sebuah sistem.
26
2.6.3 Extreme Programming
Extreme Programming (XP) merupakan salah satu metodologi agile yang
menekankan kepuasan pelanggan dan kerja sama tim. Komunikasi, sederhana,
umpan balik, dan keberanian adalah hal yang utama (Dennis et al, 2012).
Gambar 2.4 Extreme Programming (Dennis et al, 2012)
XP juga merupakan pendekatan yang menekankan pada praktik yang baik, seperti
pengembangan yang berulang hinggal level extreme (Sommerville, 2011).
Adapun 5 inti nilai dari Extreme Programming (Stellman & Greene, 2015):
1. Communication: setiap anggota dari tim mengetahui pekerjaan yang
dilakukan oleh rekan tim lainnya.
2. Simplicity: pengembang hanya fokus pada solusi yang paling sederhana dan
memungkinkan.
3. Feedback: pengujian terus menerus untuk menghasilkan umpan balik yang
dapat menjaga kualitas produk yang dikembangkan.
27
4. Courage: setiap anggota tim difokuskan pada membuat pilihan terbaik
untuk proyek tersebut. Walaupun harus membuang solusi yang gagal atau
menghadirkan pendekatan yang berbeda.
2.6.4 Scrum
Scrum adalah sebuah metode pengembangan sistem Agile yang digagas oleh
Jeff Sutherland dan tim pengembangnya pada awal tahun 1990-an. Dalam beberapa
tahun terakhir, pengembangan lebih jauh pada metode Scrum telah dilakukan oleh
Schwaber dan Beedle (Pressman, 2015).
Gambar 2.5 Alur Kerja Scrum (Stellman & Greene, 2015)
Prinsip-prinsip Scrum konsisten dengan Agile Manifesto dan digunakan
untuk pedoman aktivitas pengembangan dalam proses yang menggabungkan
28
beberapa aktivitas kerangka kerja yaitu requirements, analysis, design, evolution
dan delivery. Di dalam tiap aktivitas kerangka kerja, tugas pekerjaan terjadi di
dalam sebuah proses berpola yang disebut sebagai Sprint. Pekerjaan dilakukan di
dalam sebuah Sprint, banyaknya jumlah Sprint yang dibutuhkan untuk setiap
aktivitas kerangka kerja tergantung pada tingkat kerumitan dan besarnya produk
yang nantinya akan disesuaikan dengan masalah yang dihadapi lalu diperjelas dan
diubah secara real time oleh tim Scrum.
2.6.4.1 Scrum Events
Scrum memiliki beberapa event yang digunakan dalam membuat regulasi
meminimalisir kebutuhan dalam bertemu. Berikut adalah event yang ada pada
metode pengambangan sistem scrum:
1. Sprint
Menurut Sutherland & Schwabber (2017), Sprint merupakan jantung dari
scrum, satu waktu dalam satu bulan atau kurang yang mana task terdefinisi “Done”,
dapat digunakan, dan secara potensi, perkembangan produk yang dapat dirilis telah
dibuat. Sprint menjadi wadah dari event lain yang merupakan tahap-tahapan dalam
menyelesaikan satu fase Sprint. Events tersebut yakni Sprint Planning, Daily
Scrum, Sprint Review, dan Sprint Retrospective.
2. Sprint Planning
Sprint Planning adalah tahap dimana pekerjaan yang akan dilakukan dalam
satu fase Sprint direncanakan. perencanaan ini dibuat dengan kolaborasi oleh
seluruh anggota tim (Sutherland & Schwabber, 2017).
29
Pada fase ini kebutuhan user dikumpulkan dan disusun sebagai product backlog.
Tim pengembang juga mengestimasi berapa banyak product backlog yang dapat
diselesaikan dalam satu waktu sprint.
3. Daily Scrum
Daily Scrum adalah event dengan batas waktu 15 menit. Pada waktu
tersebut, tim pengembang merencanakan apa saja yang harus dikerjakan untuk 24
jam ke depan (Sutherland & Schwabber, 2017).
Tim pengembang menggunakan Daily Scrum untuk meninjau proses dalam
menyelesaikan pekerjaan yang ada dalam Sprint Backlog.
4. Sprint Review
Menurut Sutherland dan Schwabber (2017), Sprint Review diadakan pada
akhir Sprint untuk meninjau perkembangan dan mengadaptasi dari Product
Backlog. Pada tahap ini, Scrum Team berkolaborasi dengan stakeholder pada hal-
hal yang dapat diselesaikan untuk meningkatkan value. Pertemuan ini bersifat
informal dan perkembangan produk dapat ditampilkan dan diuji coba untuk
mendapatkan feedback dan output yang sesuai.
Sprint Review memiliki beberapa elemen sebagai berikut (Sutherland &
Schwabber, 2017):
1. Anggota yang hadir adalah tim scrum dan stakeholder yang diundang oleh
product owner;
2. Product owner menjelaskan item Product Backlog mana yang telah selesai
dan mana yang belum selesai;
30
3. Tim pengembangan mendiskusikan apa yang berjalan dengan baik selama
masa Sprint, masalah apa yang dihadapi, dan bagaimana masalah tersebut
terselesaikan;
4. Tim pengembang mendemostrasikan Product Backlog yang telah selesai dan
menjawab pertanyaan dari bagian produk yang ditambahkan;
5. Product owner mendiskusikan Product Backlog seperti yang sudah
ditentukan. Product owner akan menargetkan prakiraan tanggal untuk
produk dapat selesai jika diperlukan.
6. Seluruh anggota berkolaborasi pada apa yang akan dilakukan selanjutnya,
dengan demikian Sprint Review menyediakan input yang bermanfaat untuk
melanjutkan tahap Sprint Planning selanjutnya.
7. Meninjau bagaimana user atau marketplace dan potensi penggunaan dari
produk yang telah berubah dan hal apa yang paling penting untuk dilakukan
selanjutnya;
8. Meninjau timeline, budget, potensi kemampuan, dan marketplace untuk
mengantisipasi rilis selanjutnya.
5. Sprint Retrospective
Retrospective, proses terakhir dari masa Sprint setelah Sprint Review
dimana setelah ini proses pengembangan akan kembali ke proses penentuan produk
Backlog (Stellman & Greene, 2015).
Menurut Schwaber & Sutherland (2013) Sprint Retrospective adalah sebuah
kesempatan bagi tim Scrum untuk meninjau dirinya sendiri dan membuat
perencanaan mengenai peningkatan yang akan dilakukan pada Sprint berikutnya.
31
Bedanya dengan Daily Scrum, proses ini terjadi setelah Sprint Review karena
bersifat peningkatan kinerja untuk keseluruhan masa Sprint berikutnya.
Tujuan dari Sprint Retrospective adalah (Schwaber & Sutherland, 2013):
1. Meninjau bagaimana Sprint yang telah selesai berlangsung, termasuk hal-
hal yang berkaitan dengan orang-orangnya, hubungan antara orang-orang,
proses, dan perangkat kerja.
2. Mengidentifikasi dan mengurutkan hal-hal utama yang berjalan baik, dan
hal-hal yang berpotensi untuk ditingkatkan.
3. Membuat rencana implementasi, dengan tujuan peningkatan cara-cara kerja
Tim Scrum.
2.6.4.2 Scrum Artifacts
Scrum artifacts merepresentasikan pekerjaan atau nilai untuk menyediakan
transparansi dan peluang untuk ditinjau dan diadaptasi (Sutherland & Schwabber,
2017).
1. Product Backlog
Menurut Sutherland dan Schwabber (2017), Product Backlog adalah sebuah
daftar berurutan dari setiap hal yang diketahui dibutuhkan di dalam suatu produk.
Product Backlog tidak pernah selesai seutuhnya. Product Backlog berubah seiring
produk dan lingkungan dimana produk dipakai juga berubah. Product Backlog itu
dinamis, dan secara konstan berubah untuk mengidentifikasi apa yang dibutuhkan
produk agar sesuai, kompetitif dan berguna. Jika suatu produk ada, maka Product
Backlog juga ada.
32
Product Backlog terdiri atas daftar seluruh fitur, fungsi, kebutuhan,
pengembangan dan perbaikan yang menjadi dasar perubahan untuk dilakukan
terhadap produk pada waktu rilis selanjutnya.
2. Sprint Backlog
Menurut Sutherland dan Schwabber (2017), Sprint Backlog adalah
sekumpulan dari Product Backlog yang telah dipilih untuk fase Sprint, ditambah
suatu rencana untuk menyampaikan perkembangan produk dan menyadari tujuan
Sprint. Sprint Backlog merupakan prakiraan dari tim pengembang mengenai
fungsionalitas apa yang ada dalam perkembangan produk selanjutnya dan pekerjaan
yang dibutuhkan untuk menyampaikan fungsionalitas tersebut ke dalam
perkembangan produk yang telah diselesaikan.
2.7 Konsep Analisis dan Desain Sistem Informasi
2.7.1 Pengertian Analisis Sistem
Analisis sistem adalah suatu teknik pemecahan masalah yang mengurai
sebuah sistem menjadi bagian-bagian komponennya dengan maksud mempelajari
seberapa baiknya bagian-bagian komponen bekerja dan berinteraksi untuk
mencapai tujuannya (Whitten & Bentley, 2007).
2.7.2 Pengertian Desain Sistem
Desain sistem adalah suatu teknik pemecahan masalah yang melengkapi
analisis sistem yang menyusun kembali potong-potongan komponen dari sebuah
sistem kembali menjadi sebuah sistem utuh dengan harapan sistem menjadi lebih
33
baik. Hal ini dapat dengan menambah, menghapus, dan mengganti potongan-
potongan yang berhubungan pada sistem yang asli (Whitten & Bentley, 2007).
2.7.3 Pendekatan Analisis Sistem
Menurut Whitten dan Bentley (2007), secara mendasar, analisis sistem
adalah tentang pemecahan masalah. Ada banyak pendekatan untuk pemecahan
masalah, oleh karena itu tidak mengherankan jika banyak pendekatan yang ada
untuk analisis sistem. Berikut adalah penjelasan pendekatan analisis yang dapat
menjadi pilihan:
a. Model Driven Analysis Approach
Suatu pendekatan pemecahan masalah yang menekankan pembuatan
gambar dari model-model sistem ke dalam dokumen dan memvalidasi sistem
yang berjalan dan/atau sistem yang diajukan.
i) Structured Analysis adalah suatu teknik yang berfokus pada pemodelan
proses.
ii) Information Engineering adalah suatu teknik yang berfokus pada
pemodelan data.
iii) Object Oriented Analysis adalah teknik yang fokus pada pemodelan obyek
yang membungkus data dan proses yang berlangsung pada data tersebut.
b. Accelerated Systems Analysis Approach
Accelerated Analysis Approach menitikberatkan pada prototipe, yaitu
komunikasi antar blok bangunan di dalam suatu sistem informasi dengan
membangun sampel dari form dan laporan.
34
i) Discovery Prototyping adalah suatu teknik yang berfokus pada
pembangunan skala kecil, sub sistem yang fungsional untuk menyesuaikan
atau menemukan kebutuhan yang tepat.
ii) Rapid Architected mencoba untuk mengotomatisasikan hasil model sistem
dari prototipe ataupun sistem yang berjalan. Penghasilan model secara
otomatis memerlukan teknologi reverse engineering.
c. Requirements Discovery Methods
Suatu proses yang digunakan analis sistem dalam mengidentifikasi atau
menggali masalah-masalah sistem dan kebutuhan-kebutuhan solusi dari
kelompok user.
i) Fact Finding adalah proses formal dalam menggunakan penelitian,
wawancara, kuesioner, sampel, dan teknik untuk mengumpulkan data.
ii) Joint Requirements Planning yaitu teknik yang menggunakan ruang kerja
yang terfasilitasi untuk membawa semua pihak dan mempercepat proses
penemuan fakta.
d. Business Process Redesign Methods
Suatu metode analisis sistem yang bertujuan untuk secara dramatis
mengubah dan meningkatkan dasar atau fundamental proses bisnis dalam
suatu organisasi, independen dari teknologi informasi.
35
2.8 Object Oriented Analysis and Design
2.8.1 Object Oriented Analysis
Object Oriented Analysis adalah sebuah pendekatan yang digunakan untuk
mempelajari obyek-obyek yang ada untuk melihat apakah mereka dapat digunakan
atau disesuaikan untuk kegunaan yang baru dan menetapkan obyek yang baru atau
termodifikasi ke dalam sebuah aplikasi komputasi bisnis yang berguna (Whitten &
Bentley, 2007).
2.8.2 Object Oriented Design
Object Oriented Design adalah pendekatan yang digunakan untuk
menspesifikasikan solusi perangkat lunak dalam hal obyek-obyek yang
berkolaborasi, beserta atribut-atributnya dan method-methodnya (Whitten &
Bentley, 2007).
2.8.3 Konsep Sistem untuk Pemodelan Obyek
Analisis sistem berorientasi obyek didasarkan pada beberapa konsep.
Beberapa dari konsep-konsep ini membutuhkan cara baru dalam berpikir mengenai
sistem dan proses pengembangan (Whitten & Bentley, 2007). Konsep-konsep yang
dimaksud yaitu:
a. Object adalah sesuatu yang mampu terlihat, disentuh, atau dengan kata lain
dapat dirasakan dan di mana user menyimpan data dan perilaku terkait.
b. Attribute adalah data yang merepresentasikan karakteristik yang menarik
tentang suatu obyek.
c. Object Instance adalah setiap orang, tempat, sesuatu atau kejadian dan juga
nilai-nilai untuk atribut-atribut pada obyek itu.
36
d. Behavior adalah kumpulan dari sesuatu yang sebuah obyek dapat lakukan dan
yang berhubungan dengan fungsi yang bertindak pada data suatu obyek (atau
atribut). Di dalam lingkaran atau siklus berorientasi obyek, suatu perilaku
obyek umumnya dikaitkan sebagai sebuah metode, operasi, atau layanan.
e. Encapsulation adalah pembungkusan dari beberapa item bersama ke dalam
satu unit.
2.9 Konsep Basis Data
Database bukan hanya suatu kumpulan atau koleksi dari file. Lebih
tepatnya, sebuah database adalah sumber pusat data yang dimaksudkan untuk
digunakan bersama oleh banyak user untuk berbagai aplikasi (Kendall & Kendall,
2014). Database Management System adalah sistem perangkat lunak yang
mengelola, dan khususnya menangani semua akses ke beberapa database atau
koleksi database (Date, 2015).
2.10 Tools Perancangan Sistem
2.10.1 Flowchart
Menurut Levitin (2012), flowchart adalah sebuah metode dan sarana dalam
mengekspresikan sebuah algoritma dengan suatu kumpulan bidang geometris yang
terhubung dan berisi deskripsi dari langkah-langkah algoritma.
2.10.2 Rich Picture
Menurut Riel (2010), Rich Picture adalah sebuah metodologi untuk
merepresentasikan ide, permasalahan atau suatu konsep. Rich Picture menyediakan
pandangan umum terhadap suatu topik dan juga menunjukkan relasi dan antar
37
keterkaitan di antara elemen-elemen, secara jelas mengidentifikasikan aktivitas
utama dan aktor-aktor pada suatu aktivitas.
2.10.3 Unified Modelling Language
2.10.3.1 Pengertian UML
Unified Modelling Language (UML) adalah bahasa standar untuk menulis
cetak biru dari perangkat lunak. UML dapat digunakan untuk memvisualisasikan,
menentukan, membangun, dan mendokumentasikan artefak dari sistem perangkat
lunak (Pressman & Maxim, 2014). Dengan kata lain, arsitek bangunan membuat
cetak biru untuk digunakan oleh perusahaan konstruktor, sedangkan arsitek
perangkat lunak membuat diagram UML untuk membantu pengembang perangkat
lunak membangun perangkat lunak.
2.10.3.2 Diagram-Diagram UML
Berikut adalah penjelasan diagram-diagram UML yang digunakan di
dalam laporan penelitian ini:
a. Use Case Diagram
Use case diagram menggambarkan interaksi antara sistem dan sistem
eksternal dan user. Dengan kata lain, use case secara grafis
menggambarkan siapa yang akan menggunakan sistem dan dengan cara
apa user akan berinteraksi dengan sistem (Whitten & Bentley, 2007).
38
Gambar 2.6 Komponen yang ada pada Use Case Diagram (Kendall & Kendall,
2014)
b. Activity Diagram
Menggambarkan alur sekuensial dari aktivitas-aktivitas dalam sebuah use
case atau proses bisnis. Activity diagram dapat juga digunakan untuk memodelkan
logika dengan sistem (Whitten & Bentley, 2007).
Gambar 2.7 Contoh Activity Diagram (Kendall & Kendall, 2014)
39
c. Class Diagram
Gambar 2.8 Contoh Class Diagram (Kendall & Kendall, 2014)
Menggambarkan struktur obyek sistem. Class diagram menunjukkan kelas-
kelas obyek yang menyusun sistem serta hubungan antara kelas-kelas tersebut
(Whitten & Bentley, 2007).
d. Sequence Diagram
Gambar 2.9 Contoh Sequence Diagram (Kendall & Kendall, 2014)
40
Secara grafis menggambarkan bagaimana obyek berinteraksi dengan satu
sama lain melalui pesan-pesan di dalam eksekusi dari sebuah use case atau operasi.
Sequence diagram mengilustrasikan bagaimana pesan-pesan terkirim dan diterima
di antara obyek-obyek dan di dalam rangkaian apa (Whitten & Bentley, 2007).
2.11 Konsep Pemrograman Web
2.11.1 Pengertian PHP
PHP dahulunya merupakan singkatan dari Personal Home Page dan dirilis
sebagai gratis, open-source project. Dari waktu ke waktu, bahasa PHP terus
diperbaiki untuk memenuhi kebutuhan usernya. Di tahun 1997, PHP diubah
namanya menjadi PHP: Hypertext Preprocessor, hingga sekarang yang kita kenal.
PHP secara umum digunakan sebagai bahasa pemrograman dari sisi server yang
secara khusus sangat cocok untuk membangun halaman web dinamis (Hansen dan
Lengstorf, 2014).
David Sklar (2016) menjelaskan apa kehebatan atau kelebihan dari PHP,
berikut adalah kelebihan-kelebihan bahasa pemrograman PHP:
a. Gratis
PHP dapat diunduh gratis tanpa membayar lisensi, dukungan, biaya
maintenance, biaya upgrade, atau segala jenis biaya.
b. Open Source
Semua orang dapat melihat langsung engine dari bahasa pemrograman
PHP secara langsung yang tertulis dalam bahasa pemrograman C, dengan
41
begitu mereka dapat melihat bagaimana cara kerja ataupun membantu
memperbaiki permasalahan yang ada.
c. Cross Platform
PHP dapat digunakan dengan web server yang menjalankan Windows,
Mac OS X, Linux dan banyak versi dari sistem operasi Unix.
d. Banyak Digunakan
PHP digunakan pada lebih dari 200 juta website berbeda, dari halaman
pribadi kecil yang tidak terhitung hingga raksasa seperti Facebook,
Wikipedia, Tumblr, Slack, dan Yahoo. Banyak buku dan sumber-sumber
yang mengajarkan PHP dan mengeksplorasi apa yang dapat digunakan
dengan PHP.
e. Menyembunyikan Kerumitan
PHP menyediakan banyak fitur tingkat lanjut yang dapat digunakan, tetapi
tidak perlu cemas, karena hanya dengan mempelajari dasar-dasarnya, sudah
cukup untuk project yang sederhana agar bisa berjalan.
f. Dibuat untuk Web Programming
Berbeda dengan banyak bahasa pemrograman lain, PHP dibuat dari dasar
untuk menghasilkan halaman web. Hal ini berarti, pekerjaan-pekerjaan umum
dalam web seperti mengakses form, berinteraksi dengan database, sering kali
lebih sederhana dalam bahasa PHP.
2.11.2 Pengertian Laravel
Laravel adalah sebuah rapid application development framework . Hal ini
berarti Laravel terfokus pada sebuah kurva pembelajaran yang mudah dan
42
meminimalisir langkah-langkah antara membuat suatu aplikasi baru dan
menerbitkannya (Matt Stauffer, 2019).
Tujuan Laravel adalah menyediakan code yang jelas, sederhana dan indah
dan fitur-fitur yang membantu developer secara cepat belajar, memulai dan
mengembangkan, dan menulis code yang sederhana, jelas dan tahan lama (Matt
Stauffer, 2019).
Laravel memiliki fungsi bawaan dalam mengelola relationship antar model
yang bernama Eloquent Relationship. Eloquent dapat mengatur dan bekerja dengan
relationship secara mudah dan mendukung beberapa jenis dari relationship.
Eloquent terdapat di dalam Laravel menyediakan implementasi yang
memungkinkan setiap table database terkait dengan kelas model agar
mempermudah berinteraksi dengan tabel database tersebut. Lalu model tersebut
memungkinkan pengguna untuk melakukan query untuk data yang ada pada tabel,
dan juga memasukkan data baru ke dalam tabel.
Gambar 2.10 Contoh Menetapkan One to One Relationship
43
Pada Gambar 2.10 adalah relationship yang menunjukan hubungan one to
one, dimana satu user hanya memiliki satu phone . Eloquent menentukan foreign
key dari sebuah relationship berdasarkan nama model. Dimana nama model yang
digunakan adalah Phone. Model Phone ini secara otomatis diasumsikan
mempunyai sebuah user_id sebagai foreign key. Sebagai tambahannya, Eloquent
juga mengasumsikan bahwa foreign key harusnya memiliki nilai yang sama dengan
kolom id dari parent table. Jika menginginkan foreign key selain user_id,
programmer dapat menuliskannya pada parameter kedua di relationship yang ada
pada model. Seperti contoh berikut:
Gambar 2.11 Menuliskan Foreign Key Secara Eksplisit
Dengan kata lain, Eloquent akan mencari id dari user dalam kolom user_id
yang ada pada Phone. Berikut adalah relationship yang akan diaplikasikan pada
penelitian ini:
1. One to One Relationship
Gambar 2.12 One to One Relationship
44
One to One Relationship adalah relationship yang sangat dasar. Pada
hubungan ini, satu record hanya dapat terhubung pada satu record pada tabel lain.
2. One to Many Relationship
Gambar 2.13 One to Many Relationship
One to Many Relationship adalah hubungan dimana satu record dapat
terasosiasi dengan banyak record dari satu tabel lain.
3. Many to Many Relationship
Gambar 2.14 Many to Many Relationship
45
Many to Many Relationship adalah tiap record pada satu tabel A dapat
terasosiasi dengan banyak record dari satu tabel B, begitu juga sebaliknya, tiap
record pada tabel B dapat terasosiasi dengan banyak record pada tabel A.
4. One to Many Polymorphic Relationship
Gambar 2.15 One to Many Polymorphic Relationship
One to Many Polymorphic Relationship adalah relationship yang mirip
dengan hubungan one to many, akan tetapi polymorphic relationship
memungkinkan 1 record pada suatu tabel dapat terasosiasi dengan banyak record
pada tabel lain.
46
5. Many to Many Polymorphic Relationship
Gambar 2.16 Many to Many Polymorphic Relationship
Many to Many Polymorphic Relationship adalah hubungan yang mirip
dengan many to many, akan tetapi hubungan ini memungkinkan suatu tiap record
pada tabel A terasosiasi dengan banyak record pada lebih dari satu tabel lainnya,
begitu juga tiap record tabel-tabel lainnya dapat berinteraksi dengan banyak record
yang ada pada tabel A.
2.11.3 Pengertian MySQL
MySQL adalah sistem database yang mudah digunakan namun cepat dan
kuat, yang menawarkan apa saja situs web akan butuhkan untuk mencari dan
melayani hingga data ke browser (Nixon, 2015).
Saied dan Williams (2007), menjelaskan kenapa MySQL populer dan
menjadi pilihan oleh orang banyak, berikut adalah kelebihan MySQL:
47
a. Ukuran dan Kecepatan
MySQL dapat berjalan pada perangkat keras yang sangat sederhana dan
memberikan tekanan yang sangat kecil terhadap sumber daya atau resources
dari komputer.
b. Kemudahan Instalasi
MySQL dapat diinstal tanpa banyak kesulitan dan konfigurasi yang rumit.
c. Perhatian Terhadap Standar
MySQL melakukan pekerjaan yang baik dalam hal menyediakan sebuah
lingkungan standar, dan semakin membaik sebagaimana MySQL
mengembangkan fitur-fitur yang lebih banyak.
d. Responsif Terhadap Komunitas
Organisasi pengembang MySQL secara konstan menyediakan tempat
untuk kebutuhan usernya. Mengingat MySQL gratis dan open source,
programmer mana pun yang memiliki keahlian dapat melihat kode secara
langsung atau mungkin mencari dan membantu memperbaiki masalah-
masalah.
e. Antarmuka yang Mudah untuk Perangkat Lunak Lain
Mudah untuk menggunakan MySQL sebagai sebuah perangkat lunak yang
lebih besar. Kita dapat menulis program yang dapat berinteraksi langsung
dengan database MySQL dan banyak bahasa-bahasa pemrograman yang
memiliki library untuk digunakan dengan MySQL.
48
2.11.4 HTML
Menurut Duckett (2011), Hypertext Markup Language atau biasa disebut
HTML adalah bahasa yang memungkinkan anda membuat link yang
memungkinkan pengunjung untuk berpindah dari satu halaman ke halaman lain
dengan cepat dan mudah. Suatu bahasa markup memungkinkan anda untuk
menganotasikan teks dan anotasi ini memberikan makna tambahan terhadap konten
dokumen. Jika diberikan kode tambahan di sekitar teks asli maka browser akan
menggunakannya untuk menampilkannya secara benar. Jadi, markup.adalah tags
atau kode tambahan yang disisipkan.
2.11.5 CSS
CSS atau Cascading Stylesheets memungkinkan anda untuk membuat
aturan-aturan bagaimana konten dari sebuah elemen harusnya ditampilkan
(Duckett, 2011). Dengan CSS, tampilan seperti jenis font, ukuran, warna pada
paragraf, background, atau elemen lainnya dapat diubah dengan menggunakan
kode CSS.
2.11.6 JavaScript
Menurut Nixon (2011), JavaScript diciptakan untuk memungkinkan akses
scripting ke semua elemen pada suatu dokumen HTML. Dengan kata lain,
JavaScript menyediakan sarana untuk interaksi user yang dinamis misalnya seperti
menampilkan petunjuk atau validasi suatu form. Dengan kombinasi HTML dan
CSS, programmer dapat menciptakan interaksi-interaksi yang lebih menarik.
49
2.12 Testing
Testing atau pengujian merupakan fokus utama sistem analis, pengujian
langusng dilakukan setelah sistem berhasil dibangun (Dennis et al., 2012). Menurut
Kendall dan Kendall (2014) keseluruhan sebuah sistem harus diuji, mulai dari
antarmuka, kebenaran output yang dihasilkan, kegunaan sistem, dan keselarasan
terhadap dokumentasi dan output sistem.
Pada suatu pengembangan aplikasi dibutuhkan pengujian terhadap aplikasi
yang telah dibangun. Metode pengujian yang digunakan dalam penelitian ini adalah
Black Box. Pressman (2015) menjelaskan bahwa black box testing adalah pengujian
yang terfokus pada fungsional sebuah sistem. Yaitu mencoba untuk menemukan
kesalahan pada kategori berikut: (1) fungsi-fungsi yang salah atau hilang, (2)
kesalahan antar muka, (3) kesalahan dari struktur data atau akses database
eksternal, (4) kesalahan kinerja atau tingkah laku dan (5) inisialisasi dan kesalahan
terminasi.
Menurut James Bach yang disadur oleh Pressman dan Maxim (2015)
terdapat tujuh karakteristik sebuah perangkat lunak yang diuji, diantaranya :
1. Operability, jika sebuah sistem didesain dan diimplementasikan dengan
kualitas, sedikit bugs akan lebih efisien untuk diuji.
2. Observability, input merupakan bagian penting dari pengujian
ketimbang output. Ditentukan apakah sistem dan variabel mudah dilihat
selama eksekusi. Sedangkan output yang salah mudah untuk ditelusuri.
50
3. Controllability, pengujian dapat lebih nyaman, otomatis, dan dapat
ditelusuri jika perangkat lunak, perangkat keras, dan variabel bisa
dikontrol langsung oleh penguji.
4. Decomposability, dengan mengendalikan menjadi beberapa ruang
lingkup pengujian akan lebih cepat untuk mengisolasi masalah dan
pengujian menjadi lebih baik.
5. Simplicity, sebuah fungsionalitas dapat dibuat sederhana agar pengujian
dapat dilakukan dengan cepat, tanpa perlu menunggu lama untuk
memenuhi kebutuhan suatu fungsionalitas sistem.
6. Stability, semakin sedikit perubahan sistem, maka semakin sedikit
gangguan dalam pengujian.
7. Understandability, pemahaman terhadap desain arsitektur sistem
diperlukan agar pengujian dapat berlangsung dengan benar.
Terdapat beberapa jenis teknik pengujian sistem yang biasa digunakan
untuk aplikasi berbasis Object Oriented, seperti The Test Case Design Inmplication
of OO Concept, Application of Conventional Test Case Design Methods, Fault
Based Testing, Scenario Based Test Design, dan lainnya.
51
Tabel 2.1 Kriteria Pemilihan Sebuah Teknik Pengujian
(Pressman dan Maxim, 2015)
Kriteria The Test
Case Design
Inmplication
of OO
Concept
Application of
Conventional
Test Case
Design
Methods
Fault
Based
Testing
Scenario
Based
Test
Design
Kompleksitas
sistem
Baik Baik Kurang Kurang
Presisi
pengujian
Baik Baik Baik Cukup
Kesederhanaan
proses
pengujian
Kurang Kurang Baik Baik
Waktu Cukup Kurang Cukup Baik
2.12.1 The Test Case Design Inmplication of OO Concept
Menurut Pressman dan Maxim (2015) Sebuah kelas yang berhubungan saat
analisis dan perancangan model akan menjadi target pengujian, sedangkan atribut
dan operasi diluar dari kelas yang ditentukan tidak diuji karena dirasa akan tidak
produktif.
Setiap obyek kelas pada rancangan diuji sesuai dengan rancangan yang
dibuat. Namun sebuah kelas yang merupakan warisan dari kelas lainnya akan
menjadi tantangan saat pengujian, karena membutuhkan beberapa testing tambahan
sesuai dengan konteks yang diperlukan (Pressman dan Maxim, 2015).
2.12.2 Application of Conventional Test Case Design Methods
Metode ini merupakan metode lama white box testing yang bisa diterapkan
seperti basis path, loop testing, atau data flow techniques untuk membantu
memastikan setiap statement yang beroperasi sudah diuji (Pressman dan Maxim,
52
2015). Penggunaan metode konvensional diatas digunakan untuk membantu
pengujian berbasis obyek ini. Pengujian konvensional diatas digunakan untuk untuk
pengujian level class (Pressman dan Maxim, 2015).
2.12.3 Fault Based Testing
Mendesain sebuah pengujian untuk mencari tahu kemungkinan kerusakan
atau kesalahan sistem yang tidak terjangkau. Karena sebuah produk atau sistem
harus sesuai dengan kebutuhan user, perencanaan awal dibutuhkan untuk memulai
menganalisis model pengujian (Pressman dan Maxim, 2015).
Efektifitas dari teknik ini bergantung pada bagaimana penguji bisa
mendapatkan kemungkinan kerusakan atau kesalahan sistem (Pressman dan
Maxim, 2015). Setiap kemungkinan kesalahan interaksi yang dilakukan user harus
dapat dijangkau dalam pengujian ini, sehingga dapat menambah antisipasi terhadap
kemungkinan-kemungkinan kesalahan sistem.
2.12.4 Scenario Based Testing
Berbeda dengan Fault Based Testing dimana kesalahan sistem yang tidak
dapat dijangkau menggunakan metode itu adalah kesalahan pada spesifikasi dan
interaksi antar subsistem, ketika sebuah sistem tidak sesuai dengan spesifikasi yang
diinginkan, produk tersebut tidak sesuai dengan keinginan pelanggan (Pressman
dan Maxim, 2015).
Metode pengujian ini bertujuan untuk menguji alur sistem atau perangkat
lunak sesuai dengan skenario yang dibuat berdasarkan interaksi user dengan sistem
tersebut. Ini berarti menjabarkan tugas tugas pengujian berdasarkan alur melalui
use case yang mengharuskan user untuk melakukan sesuatu lalu menaruh itu semua
53
kedalam varian pengujian (Pressman dan Maxim, 2015). Metode ini tidak
menjangkau kesahalan interaksi, tapi untuk mencapainya dibutuhkan pengujian
yang lebih kompleks dan realistis dibanding Fault Based Testing (Pressman dan
Maxim, 2015).
Pada penelitian ini teknik pengujian yang digunakan adalah Scenario Based
Testing. Teknik ini digunakan karena sederhana dan user tidak perlu memahami
sistem dalam konteks kelas ataupun fungsi pada kode sistem, melainkan hanya dari
perspektif user dalam skenario penggunaan sistem sehari-hari.
2.13 Perangkat Lunak Pendukung
2.13.1 XAMPP
XAMPP adalah program yang memuat salinan dari apache, PHP, dan
MySQL (Kevin Yank, 2012). Dengan kata lain program ini memudahkan user
untuk menginstall PHP, apache, dan MySQL sekaligus dengan web server yang
berjalan secara lokal.
2.13.2 Visual Studio Code
Menurut (Alessandro, 2019) Visual Studio Code sudah menjadi
development tool di keluarga Microsoft Visual Studio yang dapat berjalan pada
Windows, Linux dan MacOS. Editor ini gratis dan open source dan editor ini benar-
benar terpusatkan sebagai tools untuk menulis kode program, yang mempermudah
untuk mengubah file kode dan proyek berbasis folder dan juga menulis aplikasi web
cross platform dan aplikasi mobile dari platform terpopuler yang ada.
54
2.13.3 Astah Professional
Astah atau dikenal juga sebagai JUDE, adalah alat UML Modeling yang
diciptakan oleh perusahaan Jepang Change Vision. Pengembangan JUDE pertama
kali dilakukan oleh Kenji Hiranabe CEO dari Change Vision Inc pada tahun 1996.
JUDE dijadikan freeware pada tahun 1999, dan lima tahun kemudian mulai dijual
di pasar Jepang. Software ini berperan penting buat seorang perancang
program/software.
2.13.4 Microsoft Visio 2016
Microsoft Visio adalah aplikasi untuk membuat diagram bisnis dari semua
jenis (Helmers, 2016). Microsoft Visio menyediakan berbagai fitur dan elemen
yang memudahkan pembuatan flowchart, rich picture dan diagram-diagram bisnis
lainnya.
56
BAB 3
METODE PENGEMBANGAN SISTEM
3.1 Metode Pengumpulan Data
Pada suatu penelitian diperlukan data dan informasi yang lengkap untuk
mendukung kebenaran dari materi uraian dan pembahasan. Oleh karena itu
pengumpulan data dilakukan. Pengumpulan data adalah prosedur yang dilakukan
dengan tujuan memperoleh data yang dibutuhkan di dalam penelitian. Penulis
menggunakan beberapa metode pengumpulan data pada laporan penelitian ini,
yaitu:
3.1.1 Metode Observasi
Pada metode observasi ini, penulis mengumpulkan data dan informasi yang
dibutuhkan dengan cara melakukan pengamatan secara langsung ke lapangan.
Observasi ini dilakukan untuk memperoleh gambaran umum organisasi serta proses
bisnis yang berlangsung saat ini. Observasi ini dilakukan di SPI UIN Jakarta yang
berlokasi di Gedung Rektorat Lantai 3 UIN Syarif Hidayatullah Jakarta, Jl. Ir. H.
Juanda No.95, Ciputat, Tangerang Selatan 15412. Kegiatan observasi dibantu oleh
Kepala SPI beserta staf dan kegiatan ini berlangsung selama 2 bulan, sejak bulan
Desember 2016 hingga bulan Januari 2016.
3.1.2 Studi Pustaka
Studi pustaka digunakan sebagai materi pembelajaran penulis serta sebagai
landasan teori dari laporan ini. Materi-materi yang dikumpulkan adalah materi yang
berkaitan dengan teori-teori sistem informasi, metodologi penelitian,
57
pengembangan sistem, serta pedoman yang membahas proses bisnis dari SPI UIN.
Pengumpulan materi ini diperoleh dari media cetak maupun media elektronik.
Tabel 3.1 Tabel Perbandingan Literatur Sejenis
No Penulis dan Judul Metode Kelebihan Kekurangan
1 Wulandari, 2014,
Rancang Bangun E-
Document
Management System
pada BMT Al-
Munawarah Pusat,
UIN Syarif
Hidayatullah Jakarta
Metode
pengumpulan data
yang digunakan
adalah observasi,
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
Menghasilkan
sistem
manajemen e-
document yang
mengacu pada
ISO 9001:2008
di BMT Al-
Munawarah
Pusat
Tidak terdapat
penyajian laporan
dari aktivitas
manajemen
dokumen hanya
sebatas proses
penyimpanan,
pengelolaan serta
pencarian kembali
dokumen
2 Hakim, 2014,
Rancang Bangun
Sistem Informasi
Persuratan
Pelanggaran Kode
Etik Penyelenggara
Pemilu (Studi Kasus:
DKPP). UIN Syarif
Hidayatullah Jakarta
Metode
pengumpulan data
yang digunakan
adalah observasi,
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
Menghasilkan
sistem yang
memberikan
kemudahan
dalam
pengolahan
dokumen dan
laporan
persuratan
pelanggaran
kode etik.
Tidak ada fitur
forgot password,
sehingga dapat
menyulitkan user
untuk
mendapatkan
kembali hak akses
jika password
terlupakan
3 Tarina, 2016, Rancang
Bangun Sistem
Informasi Pendapat
Badan Pemeriksa
Metode
pengumpulan data
yang digunakan
adalah observasi,
Menghasilkan
sistem yang
dapat memantau
proses
Sistem ini tidak
memiliki fitur
export tabel dari
data pendapat
58
Keuangan Berbasis
Web. UIN Syarif
Hidayatullah Jakarta
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
perkembangan
tindak lanjut
pendapat dan
mempersingkat
pencarian
pendapat di
BPK
yang telah di
input ke dalam
sistem
4 Gunardi, 2014,
Rancang Bangun
Sistem Informasi E-
Document
Management System
pada Pusat Layanan
Pengadaan Secara
Elektronik Sekretariat
Jenderal Kementerian
Keuangan. UIN Syarif
Hidayatullah Jakarta
Metode
pengumpulan data
yang digunakan
adalah observasi,
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
Menghasilkan
Document
Management
System yang
mendukung
proses revisi
dokumen dan
menjamin
validitas data
pada Pusat
Layanan
Pengadaan di
Sekretariat
Jendral
Kementerian
Keuangan
Sistem ini tidak
memberikan
informasi waktu
proses yang
dibutuhkan secara
realtime kepada
user
5 Raharjo, 2014. Sistem
Informasi Persuratan
Kepala Sub Bagian
BKD DKI Jakarta.
UIN Syarif
Hidayatullah Jakarta
Metode
pengumpulan data
yang digunakan
adalah observasi,
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
Menghasilkan
sistem yang
menyimpan
surat sebagai
pdf, pelaporan
surat serta,
agenda dan
dokumentasi
persuratan
Sistem ini hanya
mendukung
penyimpanan file
dokumen
elektronik pdf
59
6 Sari, 2013. Sistem
Informasi Persuratan
Kepegawaian. UIN
Syarif Hidayatullah
Jakarta.
Metode
pengumpulan data
yang digunakan
adalah observasi,
wawancara, dan
literatur sejenis.
Metode
pengembangan
sistem yang
digunakan adalah
RAD (Rapid
Application
Development).
Menghasilkan
sistem yang
memudahkan
kasubbag untuk
mengelola surat
masuk dan surat
keluar
Tidak terdapat
penyajian laporan
aktivitas
persuratan dan
sistem hanya
sebatas
pencatatan surat
masuk dan keluar
Peneliti membuat perbandingan dengan penelitian lain dan ada beberapa
kelebihan berupa fitur-fitur yang dimiliki oleh Revolving Fund Document
Management System (RDMS) di antaranya:
1. RDMS mengacu pada ISO 15489.
2. RDMS tidak hanya menampilkan tanggal proses selesai tetapi juga
menampilkan sisa waktu yang dibutuhkan untuk menyelesaikan proses.
3. RDMS tidak hanya menerima file dengan format PDF, tetapi juga file
dengan format png, jpg, jpeg, doc, docx, xls dan xlsx.
4. RDMS tidak hanya memiliki fitur ubah password, tetapi juga memiliki fitur
forgot password untuk mempermudah user mendapatkan kembali hak akses
akun.
5. RDMS dapat menyortir tanggal pada tabel data dan dapat difilter untuk
mempermudah pencarian data.
6. RDMS memiliki fitur export data dari tabel yang telah diinput menjadi file
worksheet dengan format xlsx untuk mempermudah rekap data.
60
7. RDMS memiliki fitur pesan untuk mempermudah komunikasi antar unit
yang terlibat di dalam sistem.
3.2 Metode Pengembangan Sistem
Metodologi pengembangan sistem yang digunakan untuk mengembangkan
sistem ini adalah metodologi pengembangan sistem scrum. Sebelum melakukan
pengembangan sistem, penulis melakukan analisis dan perancangan dengan
membuat pemodelan menggunakan Unified Modelling Language. Perancangan
diagram-diagram menggunakan aplikasi Astah Professional 8.1 dan Microsoft
Visio 2016.
3.2.1 Sprint Planning
Peneliti akan mencatat kebutuhan dari sistem berdasarkan user stories. Pada
sprint planning ini peneliti menentukan apa saja yang dapat dikerjakan dan tujuan
sprint dalam satu waktu periode sprint. Input dari sprint planning adalah product
backlog yang telah disusun berdasarkan user stories atau pengembangan produk
terbaru.
3.2.2 Daily Scrum
Dalam tahap ini peneliti sebagai developer mengerjakan proses
pengembangan sistem berdasarkan pekerjaan yang telah ditentukan pada sprint
planning, seperti desain sistem, desain interface , proses coding, maupun testing.
Peneliti melakukan perencangan model sistem dengan menggunakan UML
sebelum memulai proses pemrograman. Proses pemrograman menggunakan Visual
Studio Code dengan bahasa pemrograman PHP versi 7.2.
61
Proses pengembangan sistem akan berjalan selama 24 jam ke depan dengan
jangka waktu pengerjaan tiap item sprint backlog yang telah ditentukan. Output
dari pemrograman ini adalah aplikasi yang berjalan secara fungsional berdasarkan
product backlog yang telah ditetapkan.
3.2.3 Sprint Review
Peneliti menyerahkan output dari proses pemrograman untuk pengujian
fitur. Pengujian ini dilakukan dengan metode black box testing yang hanya
mencakup kemampuan aplikasi untuk berjalan secara fungsional.
Pada tahap ini peneliti menjelaskan product backlog mana saja yang telah
selesai dan belum selesai. Peneliti menyampaikan produk dan mengadaptasi
masukan dari hasil pengujian sebagai item yang harus dilakukan dalam fase sprint
selanjutnya.
Output dari fase ini adalah item dari product backlog yang telah diperbaiki
dan disesuaikan sebagai item baru atau tambahan pada sprint selanjutnya. Apabila
product backlog telah sesuai, peneliti akan menentukan product backlog untuk
sprint selanjutnya.
3.2.4 Sprint Retrospective
Pada tahap ini peneliti meninjau ulang kembali apa yang perlu ditingkatkan
untuk masa sprint berikutnya agar kineja tim dapat meningkat. Dari tahap ini akan
didapatkan saran-saran untuk pengembangan selanjutnya.
3.3 Alasan Menggunakan Scrum
Berikut ini adalah alasan penulis menggunakan metodologi pengembangan
SCRUM dalam merancang sistem informasi ini:
62
1. Berorientasi pada narasi dan kebutuhan user dalam menggunakan sistem
2. Fleksibel dan mudah diadaptasi pada proyek skala kecil hingga menengah
3. Tidak rumit dan mudah dipahami
4. Memungkinkan untuk menciptakan sistem dengan fungsional yang utuh
dalam jangka waktu yang pendek
3.4 Tahapan-Tahapan Penelitian
Dalam melakukan penelitian ini, penulis merencanakan kegiatan-kegiatan
penelitian dan menggambarkannya dalam kerangka berpikir. Berikut ini adalah
kerangka berpikir penulis gunakan dalam l mjaporan penelitian ini:
Gambar 3.1 Tahapan-Tahapan Penelitian
64
BAB 4
HASIL DAN PEMBAHASAN
4.1 Gambaran Umum Universitas Islam Negeri (UIN) Syarif Hidayatullah
Jakarta
4.1.1 Sekilas Profil UIN Syarif Hidayatullah Jakarta
UIN Syarif Hidayatullah Jakarta sebelumnya adalah Akademi Dinas Ilmu
Agama yang dibangun pada tahun 1957. Nama UIN Syarif Hidayatullah sendiri
terbentuk dengan terbitnya Keputusan Presiden RI No. 031 Tanggal 20 Mei 2002.
Keppres itu menjadi landasan legalitas formal perubahan yang sebelumnya adalah
IAIN Syarif Hidayatullah Jakarta, lalu menjadi Universitas Islam Negeri Syarif
Hidayatullah Jakarta. UIN Syarif Hidayatullah kini memiliki 11 fakultas dan 54
program studi pada program sarjana.
4.1.2 Visi dan Misi UIN Syarif Hidayatullah Jakarta
Visi dari UIN Syarif Hidayatullah Jakarta adalah sebagai berikut:
“UIN Syarif Hidayatullah Jakarta menjadi universitas kelas dunia dengan
keunggulan integrasi keilmuan, keislaman, dan keindonesiaan”.
Misi dari UIN Syarif Hidayatullah Jakarta adalah sebagai berikut:
1. Menyelenggarakan pendidikan tinggi yang bermutu dan relevan untuk
pengembangan keilmuan, transformasi sosial, dan peningkatan daya saing
bangsa;
2. Menyelenggarakan pendidikan tinggi dalam kerangka struktur dan kultur
organisasi yang kokoh, berintegritas, dan akuntabel.
65
Tujuan:
1. Meningkatkan kinerja pendidikan dan pengajaran yang berdampak terhadap
peningkatan mutu dan kompetensi kelulusan;
2. Meningkatkan kinerja penilitian, publikasi ilmiah, dan pengabdian kepada
masyarakat secara sinergis dalam rangka peningkatan mutu, relevansi, dan
daya saing pendidikan;
3. Meningkatkan koordinasi dan membangun sinergi antar-unit untuk
penguatan struktur dan kultur organisasi;
4. Meningkatkan penegakan prinsip-prinsip tatakelola universitas yang baik
pada semua area manajerial.
4.2 Struktur Organisasi UIN Syarif Hidayatullah Jakarta
Gambar 4.1 merupakan gambaran umum dari struktur organisasi yang ada
pada Universitas Islam Negeri Syarif Hidayatullah Jakarta. Pada sistem yang
penulis kembangkan ini, unit-unit yang terlibat ialah unit yang ikut serta atau
menjadi aktor dalam proses pengelolaan uang persediaan. Diantaranya ialah seluruh
fakultas khususnya staf keuangan dari setiap fakultas, SPI dan Bendahara
Pengeluaran Pembantu yang menjabat UIN Syarif Hidayatullah Jakarta.
66
Gambar 4.1 Struktur Organisasi UIN Syarif Hidayatullah Jakarta
67
4.3 Sprint Planning
Pada metodologi pengembangan sistem Scrum, dibutuhkan Sprint Planning
sebelum melakukan yang diperoleh dari Product Owner agar hasil akhir dari sistem
sesuai dengan kebutuhan. Oleh karena itu Scrum Meeting dibutuhkan untuk
memetakan dan menganalisis kebutuhan dari Product Owner agar bisa
mengembangkan sistem yang ada atau yang sedang berjalan saat ini dan sebagai
pedoman pengembang sistem dalam membangun sistem tersebut.
Sebelum melakukan pengembangan sistem penulis melakukan identifikasi
terhadap sistem yang diinginkan, institusi dan para aktor yang berkaitan dengan
sistem dengan menyusun Product Backlog berdasarkan User Stories yang
dikumpulkan. Setelah Product Backlog tersusun, lalu dipecah lagi menjadi Sprint
yang menjelaskan unit-unit terkecil apa saja yang akan dikerjakan
4.3.1 Menentukan User Stories
Pada tahap ini penulis akan menentukan User Stories. User Stories
ditentukan berdasarkan keinginan dan kebutuhan dalam perspektif user terhadap
sistem.
Tabel 4.1 User Stories
User Stories – Revolving Fund Document Management System
Pendaftaran user
Melakukan pendataan proses pengajuan GUP
Mengelola file dokumen pengelolaan uang persediaan
Mencari informasi suatu dokumen
Mendapatkan kontrol waktu proses dokumen sesuai SOP
Dapat berinteraksi dengan user lain
Mendapatkan laporan hasil pemrosesan dokumen
68
Pada tabel di atas terdapat poin-poin yang secara umum menjelaskan
bagaimana sistem akan berjalan dalam perspektif user.
Tabel 4.2 Rincian User Stories
1. Pendaftaran User
a. Sebagai user saya dapat mendaftarkan diri ke dalam sistem
b. Sebagai user saya dapat memulihkan password saya jika lupa
c. Sebagai admin saya dapat menyetujui pendaftaran user
Sebagai admin saya dapat mengatur user yang ada di dalam system
2. Melakukan pendataan proses pengajuan GUP
a. Sebagai staf keuangan fakultas saya dapat memberikan data dokumen
yang telah disiapkan
b. Sebagai kuasa pengguna anggaran saya dapat melihat dan
memberikan data dokumen yang diajukan ke satuan pemeriksa intern
c. Sebagai satuan pemeriksa intern saya dapat melihat surat pengajuan,
memberikan data verifikasi dan memberikan data disposisi ke
kasubbag verifikasi
d. Sebagai staf keuangan fakultas saya dapat memberikan data revisi
dari hasil verifikasi
e. Sebagai kasubbag verifikasi saya dapat meninjau hasil verifikasi dan
melakukan disposisi ke bendahara pengeluaran pembantu
f. Sebagai bendahara pengeluaran pembantu saya dapat memberikan
data pencairan dan menyatakan proses selesai
3. Mengelola file dokumen pengelolaan uang persediaan
a. Sebagai user saya dapat mengunggah salinan fisik dari suatu dokumen
atau surat
b. Sebagai user saya dapat mengunduh salinan fisik dari suatu dokumen atau
surat
4. Mencari informasi suatu dokumen
a. Sebagai user saya dapat mencari informasi dari suatu dokumen
b. Sebagai user saya dapat melihat status dari suatu dokumen
5. Mendapatkan kontrol waktu proses dokumen sesuai SOP
a. Admin dapat memberikan batasan waktu dari setiap proses sesuai dengan
SOP
b. Sistem akan memberikan batasan waktu dari setiap proses pengajuan
GUP.
6. Dapat berinteraksi dengan user lain
a. Sebagai user saya ingin dapat melakukan komunikasi dengan user lain
7. Mendapatkan laporan hasil pemrosesan dokumen
69
a. Sebagai bendahara pengeluaran pembantu saya ingin membuat laporan
bila proses pengajuan telah selesai
b. Sebagai staf keuangan fakultas saya ingin melihat laporan jika proses
pengajuan telah selesai
c. Sebagai user saya ingin melihat stastik dari semua dokumen yang ada
4.3.2 Menentukan Acceptance Criteria
Tabel 4.3 Acceptance Criteria Pendaftaran User
1. Pendaftaran user
Acceptance Criteria:
a. User dapat mendaftarkan diri hanya dengan email
b. User dapat melakukan reset password jika lupa password
c. Admin dapat menyetujui pendaftaran user
Tabel 4.4 Acceptance Criteria Melakukan Pendataan Proses Pengajuan GUP
2. Melakukan pendataan proses pengajuan GUP
Acceptance Criteria:
a. User (staf keuangan fakultas) dapat memberikan data
dokumen
b. User (kuasa pengguna anggaran) dapat melihat dokumen
yang telah diajukan user (staf keuangan fakultas)
c. User (kuasa pengguna anggaran) dapat memberikan data
pengajuan kepada user (satuan pemeriksa intern)
d. User (satuan pemeriksa intern) dapat melihat pengajuan
yang telah diajukan user (kuasa user anggran)
e. User (satuan pemeriksa intern) dapat menolak pengajuan
pengajuan user (staf keuangan fakultas)
f. User (staf keuangan fakultas) dapat memberikan data revisi
g. User (satuan pemeriksa intern) dapat menerima pengajuan
dan memberikan data hasil verifikasi
h. User (satuan pemeriksa intern) dapat memberikan data
disposisi beserta data hasil verifikasi ke user (kasubbag
verifikasi)
i. User (kasubbag verifikasi) dapat melihat dan memberikan
data disposisi untuk pencairan kepada user (bendahara
pengeluaran pembantu)
j. User (bendahara pengeluaran pembantu) dapat
memberikan data tindak lanjut pengajuan pencairan
70
Tabel 4.5 Acceptance Criteria Mengelola File Dokumen Pengelolaan Uang
Persediaan
3. Mengelola file dokumen pengelolaan uang persediaan
Acceptance Criteria:
a. User dapat mengunggah softcopy dari dokumen ataupun surat.
b. User dapat mengganti dokumen yang diunggah.
c. User dapat menghapus dokumen yang diunggah.
Tabel 4.6 Acceptance Criteria Mencari Informasi Dokumen
4. Mencari informasi suatu dokumen
Acceptance Criteria:
a. User dapat melakukan pencarian dokumen
b. User dapat melihat informasi dokumen
Tabel 4.7 Acceptance Criteria Mendapatkan Kontrol Waktu Proses Dokumen
Sesuai SOP
5. Mendapatkan kontrol waktu proses dokumen sesuai SOP
Acceptance Criteria:
a. User dapat menggunakan sistem untuk mengontrol batas waktu
pemrosesan dokumen
b. Dokumen akan expired secara otomatis, ketika pemrosesan
dokumen melewati batas waktu yang tertera pada SOP.
Tabel 4.8 Acceptance Criteria Berinteraksi dengan User Lain
6. Berinteraksi dengan user lain
Acceptance Criteria:
a. User dapat menggunakan sistem untuk berkirim pesan secara
pribadi
b. User dapat menggunakan sistem untuk berkirim pesan secara
berkelompok
Tabel 4.9 Acceptance Criteria Melihat Laporan Hasil Pengajuan
7. Melihat laporan hasil pengajuan
Acceptance Criteria:
71
a. User (staf keuangan fakultas) dapat melihat laporan hasil akhir
pengajuan dari user (bendahara pengeluaran pembantu)
b. Dengan memilih menu daftar pencairan
c. Sistem akan menampilkan hasil data pencairan yang dilakukan
oleh user (bendahara pengeluaran pembantu)
4.3.3 Menyusun Product Backlog
Pada tahap ini kita menyusun Product Backlog setelah mengumpulkan User
Stories. Product Backlog menjelaskan daftar semua yang perlu dilakukan dalam
pengembangan sistem. Berikut adalah
Tabel 4.10 Product Backlog
Todo In Progress Done
Pendaftaran user
Membuat fitur register
user dengan
menggunakan alamat
Membuat fitur login
agar user dapat
berinteraksi dengan
sistem
Membuat fitur forgot
password agar user
dapat mengubah
password jika lupa
72
Melakukan pendataan proses pengajuan GUP
Membuat fitur
pendataan dokumen
untuk staf keuangan
fakultas
Membuat fitur
pendataan pengajuan
dokumen untuk staf
keuangan fakultas dan
kuasa pengguna
anggaran
Membuat fitur
pendataan verifikasi
pengajuan dokumen
untuk satuan
pemeriksa intern
Membuat fitur
disposisi hasil
verifikasi kepada
kasubbag verifikasi
Membuat fitur
disposisi kepada
bendahara
pengeluaran pembantu
untuk melakukan
pencairan
73
Membuat fitur
pendataan pencairan
agar pengajuan
dinyatakan selesai dan
diketahui staf
keuangan fakultas dan
kuasa pengguna
anggaran
Mengelola file dokumen pengelolaan uang persediaan
Membuat fitur upload
pada pendataan
dokumen
Membuat fitur upload
pada pendataan
pengajuan
Membuat fitur upload
pada pendataan
verifikasi
Membuat fitur upload
pada pendataan
disposisi
Membuat fitur upload
pada pendataan
pencairan
74
Mencari informasi suatu dokumen
Membuat fitur
pencarian untuk data
dokumen
Membuat fitur
pencarian untuk data
pengajuan
Membuat fitur
pencarian untuk data
verifikasi
Membuat fitur
pencarian untuk data
disposisi
Membuat fitur
pencarian untuk data
pencairan
Mendapatkan kontrol waktu proses dokumen sesuai SOP
Membuat fitur batas
tenggang waktu
pemrosesan dokumen
Dapat berinteraksi dengan user lain
Membuat fitur pesan
Mendapatkan laporan hasil pemrosesan dokumen
75
Menampilkan output
dari hasil pemrosesan
dokumen
4.4 Daily Scrum
Pada tahap ini peneliti akan mengerjakan apa yang telah direncanakan
sebelumnya pada tabel Product Backlog. Sebelum melakukan pengembangan
sistem pada Sprint, peneliti perlu membuat model-model dari sistem yang akan
dikembangkan.
4.4.1 Rancangan UML
Pada Sprint 1 telah dilakukan perancangan UML sebagai kerangka dari
RDMS UIN Jakarta ini. Perancangan UML dibagi menjadi 6 bagian yaitu use case,
use case narrative, activity diagram, class diagram dan sequence diagram. Berikut
adalah dokumentasi dari perancangan UML pada tahap Sprint 1:
4.4.1.1 Use Case Diagram
Use case digunakan sebagai konsep dasar sebuah sistem, bagaimana aktor-
aktor atau stakeholder terkait saling berinteraksi dengan sistem. Sebelum itu
penulis membuat dahulu identifikasi aktor dan identifikasi use case.
Tabel 4.11 Identifikasi Aktor
No Aktor Description
1 Admin Menggunakan sistem ini untuk mengelola data user,
departemen, roles dan permission.
76
Tabel 4.12 Identifikasi Use Case
2 Staf Keuangan
Fakultas
Menggunakan sistem ini untuk menginput data dokumen
GUP, melakukan revisi apabila dokumen ditolak dalam
tahap verifikasi serta mencetak laporan hasil pengajuan
dokumen GUP.
3 Kuasa Pengguna
Anggaran
Menggunakan sistem ini untuk melakukan pengajuan
dokumen GUP.
4 Satuan Pemeriksa
Inter
Menggunakan sistem untuk melakukan verifikasi
dokumen GUP dan memberikan disposisi hasil verifikasi
kepada Kasubbag Verifikasi.
5 Kasubbag Verifi-
kasi
Menggunakan sistem untuk melihat hasil verifikasi dan
membuat disposisi untuk pencairan dari pengajuan
dokumen GUP.
6 Bendahara
Pengeluaran
Pembantu
Menggunakan sistem untuk memberi input berita
pencairan dari pengajuan dokumen GUP dan
menghasilkan laporan hasil pengajuan.
No Nama use case Description Actor
1 Sign Up Use case ini menjelaskan mengenai
kegiatan calon pengguna terdaftar di
dalam sistem.
Pengguna
sistem
2 Login Use case ini menjelaskan mengenai
kegiatan login untuk dapat masuk ke
halaman dashboard dan berinteraksi
dengan sistem.
Semua user
3 Forgot
Password
Use case ini menjelaskan mengenai
kegiatan memulihkan password yang
terlupa oleh user.
Semua user
77
4 Manage Roles Use case ini menjelaskan mengenai
kegiatan mengelola data roles dari setiap
user.
Admin
5 Manage
Permissions
Use case ini menjelaskan mengenai
kegiatan mengelola data permissions dari
setiap role.
Admin
6 Manage
Departemens
Use case ini menjelaskan mengenai
kegiatan mengelola data departemen dari
setiap user.
Admin
7 Manage Users Use case ini menjelaskan mengenai
kegiatan mengelola data user yang telah
terdaftar di dalam sistem dan pendaftaran
user baru ke dalam sistem.
Admin
8 Pesan Use case ini menjelaskan mengenai
kegiatan user dalam berinteraksi dan
berkoordinasi di dalam sistem.
Semua user
9 Input data do-
kumen
Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah disiapkan.
Staf Keuangan
Fakultas,
Bendahara
Pengeluaran
Pembantu
10 Pengajuan Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah diajukan kepada SPI.
Staf Keuangan
Fakultas,
Kuasa
Pengguna
Anggaran, SPI
11 Verifikasi Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah diverifikasi oleh SPI
Staf Keuangan
Fakultas,
Satuan
Pemeriksa
78
Inter,
Kasubbag
Verifikasi
12 Revisi Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah direvisi setelah ditolak oleh SPI.
Staf Keuangan
Fakultas, SPI
13 Disposisi Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah diverifikasi SPI dan ditindaklanjuti
oleh Kasubag Verifikasi
SPI, Kasubbag
Verifikasi,
Bendahara
Pengeluaran
Pembantu
14 Pencairan Use case ini menjelaskan mengenai
kegiatan menginput data dokumen yang
telah diproses oleh Bendahara
Pengeluaran Pembantu untuk dilakukan
proses pencairan.
Staf Keuangan
Fakultas,
Bendahara
Pengeluaran
Pembantu
15 Laporan Use case ini menjelaskan mengenai
kegiatan user melihat hasil proses dari
pengolahan dokumen uang persediaan.
Staf Keuangan
Fakultas,
Bendahara
Pengeluaran
Pembantu
16 Cetak Use case ini menjelaskan mengenai
kegiatan mencetak tabel, laporan ataupun
file yang ada di dalam sistem.
Semua user
17 Search Use case ini menjelaskan mengenai
kegiatan user dalam mencari data dari
proses yang telah dilakukan.
Semua user
18 Logout Use case ini menjelaskan mengenai
kegiatan untuk keluar dari sistem dan
menghapus sesi pengguna.
Semua user
79
Berdasarkan identifikasi yang telah dilakukan. Berikut adalah use case dari
sistem yang dikembangkan:
Gambar 4.2 Use Case Revolving Fund Document Management System
80
4.4.1.2 Use Case Narrative
Use case narrative digunakan sebagai dokumentasi dan penjelasan rinci dari
suatu use case. Berikut adalah use case narrative dari sistem yang dikembangkan:
Tabel 4.13 Narasi Use Case Sign Up
Use Case Name Sign Up
Use Case Id 1
Actor Semua aktor terkecuali admin
Description Use case ini mendeskripsikan proses registrasi data user
yang nantinya akan digunakan untuk proses login
Pre Condition -
Typical Course
of Event
Actor Action System Response
1. Memilih menu register
pada halaman login.
2. Menampilkan halaman
registrasi.
3. Memasukkan data yang
diperlukan pada form
4. Memilih tombol submit
5. Sistem melakukan vali-
dasi terhadap data
6. Validasi berhasil, sistem
akan menyimpan data
user
7. Sistem akan menampil-
kan halaman beranda
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Conclusion Aktor mendaftarkan diri dengan memasukkan data pada
form registrasi
Post Condition - Manage Users
81
Tabel 4.14 Narasi Use Case Login
Use Case Name Log In
Use Case Id 2
Actor Semua aktor
Description Use case ini mendeskripsikan proses autentikasi user dengan
memasukan data registrasi untuk masuk ke dalam dan
menggunakan sistem
Pre Condition - Sign Up
- Manage Users
Typical Course
of Event
Actor Action System Response
1. Memasukan email dan
password
2. Mengklik tombol log in. 3. Sistem akan melakukan
autentikasi terhadap data
user
4. Jika data terautentikasi,
maka user akan masuk ke
dalam beranda.
Alternate
Course
Alt Langkah 4: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Conclusion Aktor dapat masuk ke dalam sistem dengan memasukkan
data pada form login
Post Condition - Manage Users
- Manage Roles
- Manage Permissions
- Manage Departemen
- Dashboard
- Input Data Dokumen
- Submit Pengajuan
- Verifikasi Dokumen
- Revisi
- Disposisi
- Input Data Pencairan
- Laporan
- Logout
82
Tabel 4.15 Narasi Use Case Forgot Password
Use Case Name Forgot Password
Use Case Id 3
Actor Semua aktor
Description Use case ini mendeskripsikan proses memulihkan password
milik user yang terlupa dengan mereset dan mengirimkan
link pemulihan melalui email
Pre Condition -
Typical Course
of Event
Actor Action System Response
1. Mengklik link forgot
password
2. Menampilkan halaman
forgot password.
3. Memasukan email.
4. Mengklik tombol submit
5. Melakukan validasi
terhadap data user
6. Validasi sukses, sistem
akan mengirimkan link
untuk memulihkan
password
7. Mengklik link pemulihan
pada email
8. Menampilkan halaman
pemulihan password
9. Mengisi password baru
10. Klik OK 11. Menyimpan password
terbaru
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Conclusion Aktor dapat memulihkan password dengan memasukkan
alamat email yang terdaftar pada sistem
Post Condition - Login
Tabel 4.16 Narasi Use Case Manage Users
Use Case Name Manage Users
Use Case Id 4
Actor Admin
83
Description Use case ini mendeskripsikan proses mengelola user meliputi
tambah user baru, ubah data user, menghapus data user dan
mencari data user
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu “Tambah
User”
2. Menampilkan form
kosong untuk data user
3. Mengisi data user baru
4. Mengklik tombol simpan
5. Melakukan validasi data
6. Menyimpan data ke
dalam database dan
menampilkan pesan
“User telah
ditambahkan”
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Alt Langkah 1a: Klik data user yang ingin diubah
Alt Langkah 2a: Sistem menampilkan form input data user
Alt Langkah 3a: Menginput data user yang baru
Alt Langkah 4a1: Mengklik tombol “simpan”
Alt Langkah 4a2: Mengklik tombol “batal”
Alt Langkah 5a1: Sistem menyimpan data user terbaru ke
dalam basis data
Alt Langkah 5a2: Sistem batal menyimpan data user dan
menutup form data
Alt Langkah 6a1: Sistem menampilkan pesan “data user
telah diperbaharui”
Alt Langkah 1b: Klik tombol hapus pada data user yang
ingin dihapus
Alt Langkah 2b: Sistem menampilkan dialog konfirmasi
Alt Langkah 3b1: Pilih “ya”
Alt Langkah 3b2: Pilih “batal”
Alt Langkah 4b1: Sistem menghapus data user yang ada di
dalam database
84
Alt Langkah 4b2: Sistem batal menghapus data dan menutup
dialog konfirmasi
Alt Langkah 1c: Klik kolom pencarian
Alt Langkah 2c: Masukkan kata kunci pencarian
Alt Langkah 3c: Sistem menampilkan hasil pencarian
Alt Langkah 4c: Selesai
Conclusion Admin dapat mengelola data user
Post Condition -
Tabel 4.17 Narasi Use Case Manage Roles
Use Case Name Manage Roles
Use Case Id 5
Actor Admin
Description Use case ini mendeskripsikan proses mengelola role
meliputi tambah role baru, ubah role, menghapus role dan
mencari role
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu “Tambah
Role”
2. Menampilkan form
kosong untuk data role
3. Mengisi data role baru
4. Mengklik tombol simpan
5. Melakukan validasi data
6. Menyimpan data ke
dalam database dan
menampilkan pesan
“Role telah ditambah-
kan”
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Alt Langkah 1a: Klik role yang ingin diubah
Alt Langkah 2a: Sistem menampilkan form input role
Alt Langkah 3a: Menginput role yang baru
Alt Langkah 4a1: Mengklik tombol “simpan”
Alt Langkah 4a2: Mengklik tombol “batal”
85
Alt Langkah 5a1: Sistem menyimpan role terbaru ke dalam
basis data
Alt Langkah 5a2: Sistem batal menyimpan role dan
menutup form data
Alt Langkah 6a1: Sistem menampilkan pesan “data user
telah diperbaharui”
Alt Langkah 1b: Klik tombol hapus pada role yang ingin
dihapus
Alt Langkah 2b: Sistem menampilkan dialog konfirmasi
Alt Langkah 3b1: Pilih “ya”
Alt Langkah 3b2: Pilih “batal”
Alt Langkah 4b1: Sistem menghapus role yang ada di dalam
database
Alt Langkah 4b2: Sistem batal menghapus data dan menutup
dialog konfirmasi
Alt Langkah 1c: Klik kolom pencarian
Alt Langkah 2c: Masukkan kata kunci pencarian
Alt Langkah 3c: Sistem menampilkan hasil pencarian
Alt Langkah 4c: Selesai
Conclusion Admin dapat mengelola data role
Post Condition -
Tabel 4.18 Narasi Use Case Manage Permissions
Use Case Name Manage Permissions
Use Case Id 6
Actor Admin
Description Use case ini mendeskripsikan proses mengelola permission
meliputi tambah permission baru, ubah permission,
menghapus permission dan mencari permission
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu “Tambah
Permission”
2. Menampilkan form
kosong untuk data
permission
3. Mengisi data permission
baru
86
4. Mengklik tombol simpan
5. Melakukan validasi data
6. Menyimpan data ke
dalam database dan
menampilkan pesan
“Permission telah
ditambah-kan”
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Alt Langkah 1a: Klik permission yang ingin diubah
Alt Langkah 2a: Sistem menampilkan form input permission
Alt Langkah 3a: Menginput permission yang baru
Alt Langkah 4a1: Mengklik tombol “simpan”
Alt Langkah 4a2: Mengklik tombol “batal”
Alt Langkah 5a1: Sistem menyimpan permission terbaru ke
dalam basis data
Alt Langkah 5a2: Sistem batal menyimpan permission dan
menutup form data
Alt Langkah 6a1: Sistem menampilkan pesan “data user
telah diperbaharui”
Alt Langkah 1b: Klik tombol hapus pada permission yang
ingin dihapus
Alt Langkah 2b: Sistem menampilkan dialog konfirmasi
Alt Langkah 3b1: Pilih “ya”
Alt Langkah 3b2: Pilih “batal”
Alt Langkah 4b1: Sistem menghapus permission yang ada di
dalam database
Alt Langkah 4b2: Sistem batal menghapus data dan menutup
dialog konfirmasi
Alt Langkah 1c: Klik kolom pencarian
Alt Langkah 2c: Masukkan kata kunci pencarian
Alt Langkah 3c: Sistem menampilkan hasil pencarian
Alt Langkah 4c: Selesai
Conclusion Admin dapat mengelola data permission
Post Condition -
87
Tabel 4.19 Narasi Use Case Manage Departemen
Use Case Name Manage Departemen
Use Case Id 7
Actor Admin
Description Use case ini mendeskripsikan proses mengelola departemen
meliputi tambah departemen baru, ubah departemen,
menghapus departemen dan mencari departemen
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu “Tambah
Departemen”
2. Menampilkan form
kosong untuk data
departemen
3. Mengisi data departemen
baru
4. Mengklik tombol simpan
5. Melakukan validasi data
6. Menyimpan data ke
dalam database dan
menampilkan pesan
“Departemen telah
ditambah-kan”
Alternate
Course
Alt Langkah 6: Validasi gagal, sistem menampilkan pesan
error penyebab validasi gagal. Ulangi kembali dari langkah
pertama
Alt Langkah 1a: Klik departemen yang ingin diubah
Alt Langkah 2a: Sistem menampilkan form input
departemen
Alt Langkah 3a: Menginput departemen yang baru
Alt Langkah 4a1: Mengklik tombol “simpan”
Alt Langkah 4a2: Mengklik tombol “batal”
Alt Langkah 5a1: Sistem menyimpan departemen terbaru ke
dalam basis data
Alt Langkah 5a2: Sistem batal menyimpan departemen dan
menutup form data
Alt Langkah 6a1: Sistem menampilkan pesan “data user
telah diperbaharui”
88
Alt Langkah 1b: Klik tombol hapus pada departemen yang
ingin dihapus
Alt Langkah 2b: Sistem menampilkan dialog konfirmasi
Alt Langkah 3b1: Pilih “ya”
Alt Langkah 3b2: Pilih “batal”
Alt Langkah 4b1: Sistem menghapus departemen yang ada
di dalam database
Alt Langkah 4b2: Sistem batal menghapus data dan menutup
dialog konfirmasi
Alt Langkah 1c: Klik kolom pencarian
Alt Langkah 2c: Masukkan kata kunci pencarian
Alt Langkah 3c: Sistem menampilkan hasil pencarian
Alt Langkah 4c: Selesai
Conclusion Admin dapat mengelola data departemen
Post Condition -
Tabel 4.20 Narasi Use Case Input Data Dokumen
Use Case Name Input Data Dokumen
Use Case Id 8
Actor Staf Keuangan Fakultas
Description Use case ini mendeskripsikan proses mengisi data dokumen
berkas pengajuan
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu dokumen 2. Menampilkan halaman
dari dokumen
3. Memasukkan data berkas
dokumen
4. Memilih tombol create
5. Melakukan validasi
terhadap data dokumen
6. Jika data valid, sistem
akan menyimpan data
dokumen.
89
7. Melakukan redirect ke
halaman dokumen
dengan pesan sukses
Alternate
Course
Alt Langkah 6: Jika data yang dimasukkan tidak valid atau
kurang, sistem akan memberikan peringatan untuk mengisi
data dokumen ulang secara benar lalu menekan tombol submit
Conclusion Staf keuangan fakultas dapat mengisi data berkas dokumen
Post Condition - Submit Data Pengajuan
Tabel 4.21 Narasi Use Case Submit Pengajuan
Use Case Name Submit Pengajuan
Use Case Id 9
Actor Kuasa Pengguna Anggaran
Description Use case ini mendeskripsikan proses user mengisi data
pengajuan dokumen pencairan
Pre Condition - Login
- Input Data Dokumen
Typical Course
of Event
Actor Action System Response
1. Memilih menu pengajuan 2. Menampilkan halaman
dan data pengajuan
3. Memasukkan data
pengajuan
4. Memilih tombol create.
5. Melakukan validasi
terhadap data pengajuan
6. Jika berhasil, sistem
redirect kembali ke
penerimaan dokumen
dengan pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Kuasa pengguna anggaran dapat mengisi data pengajuan
dokumen
Post Condition - Verifikasi Dokumen
90
Tabel 4.22 Narasi Use Case Verifikasi Dokumen
Use Case Name Verifikasi Dokumen
Use Case Id 10
Actor SPI
Description Use case ini mendeskripsikan proses satuan pemeriksa intern
mengisi data hasil verifikasi dokumen pencairan
Pre Condition - Login
- Input Data Dokumen
- Submit Pengajuan
Typical Course
of Event
Actor Action System Response
1. Memilih menu verifikasi 2. Menampilkan halaman
dan data verifikasi
3. Memasukkan data hasil
verifikasi
4. Memilih tombol create.
5. Melakukan validasi
terhadap data verifikasi
6. Jika berhasil, sistem
redirect kembali ke
penerimaan dokumen
dengan pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Satuan pemeriksa intern dapat memberikan data hasil
verifikasi dokumen
Post Condition - Revisi Dokumen
- Disposisi
Tabel 4.23 Narasi Use Case Submit Data Revisi
Use Case Name Submit Revisi
Use Case Id 11
Actor Staf Keuangan Fakultas
Description Use case ini mendeskripsikan proses satuan pemeriksa intern
mengisi data hasil verifikasi dokumen pencairan
Pre Condition - Login
- Input Data Dokumen
- Submit Pengajuan
- Verifikasi Dokumen
91
Typical Course
of Event
Actor Action System Response
1. Memilih menu verifikasi 2. Menampilkan halaman
dan data verifikasi
3. Memasukkan data hasil
verifikasi
4. Memilih tombol create.
5. Melakukan validasi
terhadap data verifikasi
6. Jika berhasil, sistem
redirect kembali ke
penerimaan dokumen
dengan pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Staf keuangan fakultas dapat memberikan data revisi
dokumen apabila verifikasi gagal
Post Condition - Disposisi Hasil
Tabel 4.24 Narasi Use Case Disposisi Hasil
Use Case Name Disposisi Hasil
Use Case Id 12
Actor SPI, Kasubbag Verifikasi
Description Use case ini mendeskripsikan proses mengisi data disposisi
dari hasil verifikasi
Pre Condition - Login
- Input Data Dokumen
- Submit Pengajuan
- Verifikasi Dokumen
Typical Course
of Event
Actor Action System Response
1. Memilih menu disposisi 2. Menampilkan
halaman dan data
disposisi
3. Memasukkan data isi disposisi
4. Memilih tombol create
5. Melakukan
validasi terhadap
data disposisi
6. Jika berhasil,
sistem akan
92
menampilkan
pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Aktor dapat membuat disposisi untuk menyerahkan hasil
verifikasi
Post Condition - Input Data
Tabel 4.25 Narasi Use Case Proses Pencairan
Use Case Name Proses Pencairan
Use Case Id 13
Actor Bendahara Pengeluaran Pembantu
Description Use case ini mendeskripsikan proses mengisi data dari hasil
pengajuan pencairan
Pre Condition - Login
- Input Data Dokumen
- Submit Pengajuan
- Verifikasi Dokumen
- Disposisi
Typical Course
of Event
Actor Action System Response
1. User memilih menu pencairan 2. Sistem
menampilkan
halaman dan data
pencairan
3. User memasukkan data isi
disposisi
4. User memilih tombol create
5. Sistem akan
melakukan validasi
terhadap data
disposisi
6. Jika berhasil,
sistem akan
menampilkan
pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Bendahara pengeluaran pembantu dapat memberikan data
dari proses pencairan yang telah dilakukan
93
Post Condition - Laporan
Tabel 4.26 Narasi Use Case Submit Data Pencairan
Use Case Name Submit Data Pencairan
Use Case Id 14
Actor Bendahara Pengeluaran Pembantu
Description Use case ini mendeskripsikan proses mengisi data dari hasil
pengajuan pencairan
Pre Condition User menggunakan sistem, mempunyai akun, dan sudah log
in ke dalam sistem.
Typical Course
of Event
Actor Action System Response
1. Memilih menu pencairan 2. Menampilkan
halaman dan data
pencairan
3. Memasukkan data isi disposisi
4. Memilih tombol create
5. Melakukan
validasi terhadap
data disposisi
6. Jika berhasil,
sistem akan
menampilkan
pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Kuasa pengguna anggaran dapat mengisi data pengajuan
dokumen
Post Condition User sukses menerima dokumen baru
Tabel 4.27 Narasi Use Case Melihat Laporan Hasil
Use Case Name Melihat Laporan Hasil
Use Case Id 15
Actor Bendahara Pengeluaran Pembantu
Description Use case ini mendeskripsikan proses mengisi data dari hasil
pengajuan pencairan
Pre Condition User menggunakan sistem, mempunyai akun, dan sudah log
in ke dalam sistem.
Actor Action System Response
94
Typical Course
of Event
1. Memilih menu pencairan 2. Menampilkan
halaman dan data
pencairan
3. Memasukkan data isi disposisi
4. Memilih tombol create
5. Melakukan validasi
terhadap data
disposisi
6. Jika berhasil,
sistem akan
menampilkan
pesan sukses.
Alternate
Course
Alt Langkah 6: Jika data tidak valid akan muncul pesan error
Conclusion Kuasa pengguna anggaran dapat mengisi data pengajuan
dokumen
Post Condition User sukses menerima dokumen baru
Tabel 4.28 Narasi Use Case Log Out
Use Case Name Log Out
Use Case Id 16
Actor Semua user
Description Use case ini mendeskripsikan proses user keluar dari sistem.
Pre Condition - Login
Typical Course
of Event
Actor Action System Response
1. Memilih menu log out 2. Memproses dan
melakukan
redirect ke
halaman log in.
Alternate
Course
Conclusion
Post Condition -
4.4.1.3 Activity Diagram
Activity Diagram menjelaskan proses dari aktivitas user terhadap sistem.
Berikut adalah activity diagram pada RDMS UIN Jakarta.
95
1. Activity Diagram Sign Up
Gambar 4.3 Activity Diagram Sign Up
Gambar 4.3 adalah activity diagram yang digunakan oleh aktor yang teribat
untuk mendaftarkan diri sebagai user. Aktor dapat melakukan kegiatan sign up
untuk mendaftarkan akun agar dapat mengakses sistem.
96
2. Activity Diagram Manage Users
Gambar 4.4 Activity Diagram Manage Users
97
Gambar 4.4 adalah activity diagram yang digunakan oleh admin untuk
memoderasi ataupun mendaftarkan aktor sebagai user. Admin dapat merubah data
user seperti mengubah role dan mendaftarkan user baru secara langsung.
3. Activity Diagram Login
Gambar 4.5 Activity Diagram Login
Gambar 4.5 adalah activity diagram yang digunakan oleh user untuk
melakukan kegiatan login. User dapat mengakses sistem dengan memberikan data
user yang telah terdaftar pada form login.
98
4. Activity Diagram Manage Roles
Gambar 4.6 Activity Diagram Manage Roles
Gambar 4.6 adalah activity diagram yang digunakan oleh admin untuk
mengelola role. Admin dapat melakukan aktivitas seperti menambah role,
mengubah role, menghapus role serta mengatur permissions untuk suatu role.
99
5. Activity Diagram Manage Permissions
Gambar 4.7 Activity Diagram Manage Permissions
Gambar 4.7 adalah activity diagram yang digunakan oleh admin untuk
mengelola permissions. Admin dapat melakukan kegiatan mengelola seperti
tambah permissions, ubah permission dan permissions.
100
6. Activity Diagram Manage Departemen
Gambar 4.8 Activity Diagram Manage Departemen
Gambar 4.8 adalah activity diagram yang digunakan oleh admin untuk
mengelola departemen. Admin dapat melakukan kegiatan mengelola seperti tambah
departemen, ubah departemen dan hapus departemen.
101
7. Activity Diagram Input Data Dokumen
Gambar 4.9 Activity Login Input Data Dokumen
Gambar 4.9 adalah activity diagram yang digunakan oleh staf keuangan
fakultas untuk menginput data dokumen. Staf keuangan fakultas dapat melakukan
kegiatan menginput data pengajuan dokumen yang telah disiapkan ke dalam sistem.
102
8. \Activity Diagram Submit Pengajuan
Gambar 4.10 Activity Diagram Submit Pengajuan
Gambar 4.10 adalah activity diagram yang digunakan oleh staf keuangan
fakultas atau kuasa pengguna anggaran untuk mengajukan dokumen yang telah
terdaftar pada data dokumen. Kuasa pengguna anggaran dapat melakukan input
data pengajuan dokumen.
103
9. Activity Diagram Verifikasi Dokumen
Gambar 4.11 Activity Diagram Verifikasi Dokumen
Gambar 4.11 adalah activity diagram yang digunakan oleh satuan
pemeriksa intern untuk melakukan verifikasi dokumen. Satuan pemeriksa intern
dapat melakukan kegiatan seperti hasil verifikasi berupa penolakan pengajuan
ataupun menerima pengajuan.
104
10. Activity Diagram Revisi Dokumen
Gambar 4.12 Activity Diagram Revisi Dokumen
Gambar 4.12 adalah activity diagram yang digunakan oleh staf keuangan
fakultas untuk merevisi dokumen yang belum berhasil terverifikasi. Staf keuangan
fakultas dapat melakukan menginput data revisi untuk diverifikasi kembali.
105
11. Activity Diagram Disposisi Hasil
Gambar 4.13 Activity Diagram Disposisi Hasil
Gambar 4.13 adalah activity diagram yang digunakan oleh Kasubbag
Verifikasi untuk memberikan meninjau hasil verifikasi dan menginput data
disposisi untuk pencairan kepada bendahara pengeluaran pembantu.
106
12. Activity Diagram Input Data Pencairan
Gambar 4.14 Activity Diagram Input Data Pencairan
Gambar 4.14 adalah activity diagram yang digunakan oleh badan
pengeluaran pembantu untuk menginput data pencairan yang sedang diproses.
107
13. Activity Diagram Logout
Gambar 4.15 Activity Diagram Logout
Gambar 4.15 adalah activity diagram yang digunakan oleh user untuk
keluar dari sistem. Seluruh user dapat melakukan kegiatan logout dengan meng-
klik menu logout.
108
4.4.1.4 Class Diagram
Pada perancangan class diagram, hal yang perlu dilakukan adalah
merancang daftar obyek potensial terlebih dahulu. Obyek potensial selanjutnya kan
dipetakan ke dalam class diagram. Berikut adalah daftar obyek potensial dari
RDMS UIN Jakarta.
Tabel 4.29 Daftar Obyek Potensial
No. Nama Obyek Potensial Berpotensi Alasan
1 login Ya Operasi
2 users Ya Obyek users
3 name Tidak
4 roles Ya Obyek roles
5 name Tidak
6 permissions Ya Obyek permissions
7 name Tidak
8 departemen Ya Obyek departemen
9 name Tidak
10 jenis_dokumen Ya Obyek jenis dokumen
11 name Tidak
12 admin Ya Aktor turunan users
13 keuangan_fakultas Ya Aktor turunan users
14 kpa Ya Aktor turunan users
15 spi Ya Aktor turunan users
16 kasubbag_verifikasi Ya Aktor turunan users
17 bpp Ya Aktor turunan users
18 nip Tidak Atribut users
19 name Tidak Atribut users
20 email Tidak Atribut users
21 password Tidak Atribut users
22 dokumen Ya Obyek dokumen
23 no Tidak Atribut dokumen
24 name Tidak Atribut dokumen
25 pengajuan Ya Obyek pengajuan
26 no Tidak Atribut pengajuan
27 deskripsi Tidak Atribut pengajuan
28 created_at Tidak Atribut pengajuan
29 verifikasi Ya Obyek verifikasi
30 no Tidak Atribut verifikasi
31 verified Tidak Atribut verifikasi
32 reason Tidak Atribut verifikasi
109
33 created_at Tidak Atribut verifikasi
34 expired_at Tidak Atribut verifikasi
35 revisi Ya Obyek revisi
36 approved Tidak Atribut revisi
37 Info Tidak Atribut revisi
38 created_at Tidak Atribut revisi
39 disposisi Ya Obyek disposisi
40 response Tidak Atribut disposisi
41 created_at Tidak Atribut disposisi
42 expired_at Tidak Atribut disposisi
43 pencairan Ya Obyek pencairan
44 finished Tidak Atribut pencairan
45 info Tidak Atribut pencairan
46 created_at Tidak Atribut pencairan
47 expired_at Tidak Atribut pencairan
48 thread Ya Obyek thread
49 subject Tidak Atribut pencairan
50 created_at Tidak Atribut pencairan
51 message Ya Obyek message
52 body Tidak Atribut message
53 created_at Tidak Atribut message
54 participant Ya Obyek participant
55 last_read Tidak Atribut participant
56 created_at Tidak Atribut participant
Setelah menganalisis daftar identifikasi obyek potensial seperti dalam tabel
di atas, maka selanjutnya didapatkan daftar obyek yang diusulkan. Daftar obyek
potensial yang telah ditentukan tertulis pada tabel berikut:
Tabel 4.30 Daftar Obyek Potensial yang Diusulkan
No Daftar obyek potensial yang diusulkan
1 users
2 roles
3 permissions
4 departemen
5 jenis_dokumen
6 dokumen
7 pengajuan
110
8 verifikasi
9 disposisi
10 pencairan
11 media
12 thread
13 message
14 participant
Setelah mendapatkan daftar obyek yang diusulkan, obyek-obyek ini
dijadikan acuan untuk pemodelan terstruktur class diagram dan merancang
database. Class Diagram Gambar 4.16 ini menggambarkan keadaan struktural dari
sistem ini:
Gambar 4.16 Class Diagram Revolving Fund Document Management System
111
4.4.1.5 Sequence Diagram
1. Sequence Diagram Sign Up
Gambar 4.17 Sequence Diagram Signup
Pada Gambar 4.17 adalah sequence diagram hubungan antara user obyek
class user dengan sign up. Pada hubungan ini obyek user akan menginput data user
yang berupa credentials ke obyek sign up, lalu obyek sign up akan melakukan
registrasi dan mengembalikan data sebagai user yang baru teregistrasi.
2. Sequence Diagram Login
Pada Gambar 4.18 adalah sequence diagram hubungan antara user obyek
class user dengan log in. Pada hubungan ini obyek user akan menginput data user
yang berupa credentials yang sudah terdaftar pada sistem ke obyek log in, lalu
obyek log in akan melakukan proses autentikasi dan mengembalikan data sebagai
user yang telah terautentikasi.
112
Gambar 4.18 Sequence Diagram Login
3. Sequence Diagram Forgot Password
Gambar 4.19 Sequence Diagram Forgot Password
113
Pada Gambar 4.19 adalah sequence diagram hubungan antara user obyek
class user dengan forgot password. Pada hubungan ini obyek user akan menginput
data user berupa email ke obyek forgot password, lalu obyek password akan
melakukan melakukan pengecekan alamat email dan mengirimkan link pemulihan
password ke email user.
4. Sequence Diagram User, Role dan Permission
Gambar 4.20 Sequence Diagram Users, Roles dan Permissions
Pada Gambar 4.20 ini adalah sequence diagram hubungan antara user obyek
class user, role dan permission. Pada hubungan ini obyek user akan menginput data
user berupa id user ke obyek role, lalu obyek role akan mendapatkan dan
mengembalikan data permission berdasarkan id role yang dimiliki user. User hanya
114
dapat menjalankan aksi apabila memiliki permission yang sesuai dengan request
yang akan dilakukan.
5. Sequence Diagram User dan Mediafile
Gambar 4.21 Sequence Diagram User dan Mediafile
Pada Gambar 4.21 adalah sequence diagram hubungan antara user obyek
class mediafile. Pada hubungan ini obyek user akan menginput data user yang
berupa id user ke obyek class mediafile, lalu obyek mediafile akan mendapatkan
dan mengembalikan data berupa file kepada obyek class user.
6. Sequence Diagram User, Dokumen dan Mediafile
Pada Gambar 4.22 adalah sequence diagram hubungan antara user obyek
class user, dokumen dan mediafile. Pada hubungan ini obyek user akan menginput
data id user ke obyek dokumen, lalu obyek dokumen akan memberikan id dokumen
kepada obyek mediafile untuk menyimpan data file lalu akan dikembalikan dalam
bentuk data dokumen.
115
Gambar 4.22 Sequence Diagram User dan Dokumen
7. Sequence Diagram User, Pengajuan, Dokumen, dan Mediafile
Gambar 4.23 Sequence Diagram User, Pengajuan dan Dokumen
Pada Gambar 4.23 adalah sequence diagram hubungan antara user obyek
class user, pengajuan, dokumen dan mediafile. Pada hubungan ini obyek user akan
menginput data user id ke obyek class pengajuan, lalu obyek pengajuan akan
116
memperoleh data dokumen dari id dokumen yang ada pada obyek class pengajuan.
Obyek class pengajuan menyimpan data file dengan memberikan id pengajuan
kepada obyek class mediafile. Obyek class user dapat memanggil data yang ada
pada obyek class pengajuan.
8. Sequence Diagram User, Verifikasi, Pengajuan dan Mediafile
Gambar 4.24 Sequence Diagram User, Verifikasi, Pengajuan dan Mediafile
Pada Gambar 4.24 adalah sequence diagram hubungan antara user obyek
class user, verifikasi, pengajuan dan mediafile. Pada hubungan ini obyek user akan
menginput data user id ke obyek class verifikasi, lalu obyek verifikasi akan
memperoleh data pengajuan dari id pengajuan yang ada pada obyek class verifikasi.
Obyek class verifikasi menyimpan data file dengan memberikan id verifikasi
kepada obyek class mediafile. Obyek class user dapat memanggil data yang ada
pada obyek class verifikasi.
117
9. Sequence Diagram User, Revisi, Verifikasi dan Mediafile
Gambar 4.25 Sequence Diagram User, Revisi, Verifikasi dan Mediafile
Pada Gambar 4.25 ini adalah sequence diagram hubungan antara user obyek
class user, revisi, verifikasi dan mediafile. Pada hubungan ini obyek user akan
menginput data user id ke obyek class revisi, lalu obyek revisi akan memperoleh
data verifikasi dari id verifikasi yang ada pada obyek class revisi. Obyek class revisi
menyimpan data file dengan memberikan id revisi kepada obyek class mediafile.
Obyek class user dapat memanggil data yang ada pada obyek class revisi.
10. Sequence Diagram User, Disposisi, Verifikasi dan Mediafile
Pada Gambar 4.26 adalah sequence diagram hubungan antara user obyek
class user, disposisi, verifikasi dan mediafile. Pada hubungan ini obyek user akan
menginput data user id ke obyek class disposisi, lalu obyek disposisi akan
memperoleh data verifikasi dari id pengajuan yang ada pada obyek class disposisi.
Obyek class disposisi menyimpan data file dengan memberikan id disposisi kepada
118
obyek class mediafile. Obyek class user dapat memanggil data yang ada pada obyek
class disposisi.
Gambar 4.26 Sequence Diagram User, Disposisi, Verifikasi dan Mediafile
11. Sequence Diagram User, Pencairan, Disposisi dan Mediafile
Gambar 4.27 Sequence Diagram User, Pencairan, Disposisi dan Mediafile
119
Pada Gambar 4.27 adalah sequence diagram hubungan antara user obyek
class user, pencairan, disposisi dan mediafile. Pada hubungan ini obyek user akan
menginput data user id ke obyek class pencairan, lalu obyek pencairan akan
memperoleh data disposisi dari id disposisi yang ada pada obyek class pencairan.
Obyek class pencairan menyimpan data file dengan memberikan id pencairan
kepada obyek class mediafile. Obyek class user dapat memanggil data yang ada
pada obyek class pencairan.
12. Sequence Diagram User, Thread, Participant, Message
Gambar 4.28 Sequence Diagram User, Thread, Participants dan Message
Pada Gambar 4.28 adalah sequence diagram hubungan antara user obyek
class user, thread, participant, dan message. Pada hubungan ini obyek user akan
membuat thread yang berisikan data user id pembuat thread. Lalu obyek user
mengirimkan user_id dan thread_id kepada obyek participant yang menandakan
user mana saja yang akan berpartisipasi di dalam thread, lalu obyek user akan
120
mengirim kan user_id dan thread_id kepada obyek message sebagai tanda user
mengirimkan pesan pada thread dengan id yang telah dikirim.
4.4.1.6 Component Diagram
Diagram pada Gambar 4.28 menggambarkan hubungan antar komponen-
komponen yang berasal dari obyek potensial sebelumnya:
Keterangan Gambar 4.28:
1. Revolving Fund Document Management System adalah komponen utama
yang dapat diakses melalui web browser.
2. User adalah komponen yang menyimpan data pribadi seperti nama, email
dan password. Di dalamnya juga terdapat komponen role.
Gambar 4.28 Component Diagram Revolving Fund Document Management
System
3. Roles adalah komponen yang menyimpan data-data yang terdiri atas nama-
nama roles. Di dalamnya juga terdapat komponen permission.
121
4. Permissions adalah komponen yang menyimpan data-data yang berisi detail
permissions yang berhubungan dengan hak akses setiap roles.
5. Dokumen adalah komponen yang menyimpan data-data yang berisi detail
dokumen, seperti no dokumen dan nama dokumen.
6. Pengajuan adalah komponen yang menyimpan data-data yang berisi detail
pengajuan, seperti deskripsi. Di dalamnya juga terdapat komponen
dokumen dan komponen user.
7. Verifikasi adalah komponen yang menyimpan data yang berisi verifikasi
seperti status verifikasi dan keterangan tambahan verifikasi. Di dalamnya
juga terdapat komponen pengajuan dan komponen user.
8. Revisi adalah komponen yang menyimpan data yang berisi detail revisi
seperti status revisi dan deskripsi. Di dalamnya juga terdapat komponen
verifikasi dan komponen user.
9. Disposisi adalah komponen yang menyimpan data yang berisi detail
disposisi seperti perihal disposisi, status penerimaan, dan balasan terkait
disposisi. Di dalamnya juga terdapat komponen verifikasi, komponen
disposisi, dan komponen user.
10. Pencairan adalah komponen yang menyimpan data yang berisi detail
pencairan dokumen, seperti keterangan pencairan dan status pencairan. Di
dalamnya juga terdapat komponen disposisi dan komponen user.
11. Mediafile adalah komponen yang menyimpan data yang berisi path dari file
yang di-upload.
122
4.4.1.7 Deployment Diagram
Diagram ini menggambarkan perangkat fisik yang terdiri dari beberapa
komponen. Terdapat 6 perangkat utama, yaitu aplikasi RDMS sebagai penyedia
layanan, sebuah host PC yang akan bertindak sebagai server, MySQL server yang
berperan sebagai database server, network, client yang dapat melalui perangkat
mobile phone dan pc desktop, serta web browser yang menjadi client app.
Gambar 4.29 Deployment Diagram
4.4.2 Desain Database
Pada tahap desain database, skema dirancang untuk basis data Revolving
Fund Document Management System. Tahap ini terdiri atas mapping obyek hingga
membentuk skema basis data.
123
4.4.2.1 Skema Database
Gambar 4.30 adalah skema database yang ada pada sistem ini:
Gambar 4.30 Skema Database
124
4.4.2.2 Spesifikasi Database
Dari skema database yang dibuat sebelumnya, lalu dijabarkan spesifikasi
database dalam bentuk tabel-tabel. Spesifikasi database yang digunakan
merupakan adaptasi dari ketetapan Laravel dalam mengelola primary key dan
foreign key dari suatu table. Berikut adalah tabel spesifikasi database yang
digunakan pada sistem ini:
1. User
Nama Tabel : users
Primary Key : user_id
Foreign Key : departemen_id
Tipe Tabel : master
Tabel 4.31 Basis Data Users
No. Field Tipe Size Keterangan
1. user_id unsigned` integer 10 kode user
2. name varchar 50 nama user
3. departemen_id unsigned` integer 5 kode departemen
4. email varchar 50 email user
5. password varchar 50 password user
6. created_at datetime - tanggal user dibuat
7. updated_at datetime - tanggal user
diperbaharui
2. Departemen
Nama Tabel : departemens
Primary Key : departemen_id
Tipe Tabel : master
125
Tabel 4.31 Basis Data Departemen
No. Field Tipe Size Keterangan
1. departemen_id unsigned`
integer
10 kode departemen
2. name varchar 50 nama departemen
3. display_name varchar
5 kode departemen
4. budget decimal 50 anggaran uang
persediaan departemen
5. start_date datetime - tanggal anggaran berlaku
6. created_at datetime - tanggal anggaran
berakhir
7. updated_at datetime - tanggal user diperbaharui
3. Password Resets
Nama Tabel : password_resets
Primary Key : email
Foreign Key : -
Tipe Tabel : master
Tabel 4.32 Basis Data Password Resets
No. Field Tipe Size Keterangan
1. email varchar 50 email user
2. token varchar 100 token reset password user
3. created_at datetime - tanggal user dibuat
4. Permissions
Nama Tabel : permissions
Primary Key : permission_id
Foreign Key : -
Tipe Tabel : master
126
Tabel 4.33 Basis Data Permissions
No. Field Tipe Size Keterangan
1. permission_id unsigned integer 10 kode permission
2. name varchar 40 nama permission
3. description varchar 50 deskripsi permission
4. guard_name varchar 50 nama guard permission
5. created_at datetime - tanggal permission dibuat
6. updated_at datetime - tanggal permission
diperbaharui
5. Role
Nama Tabel : roles
Primary Key : role_id
Foreign Key : -
Tipe Tabel : master
Tabel 4.34 Basis Data Roles
No. Field Tipe Size Keterangan
1. role_id unsigned integer 10 kode role
2. name varchar 30 nama role
3. description varchar 50 deskripsi role
4. guard_name varchar 50 nama guard role
5. created_at datetime - tanggal role dibuat
6. updated_at datetime - tanggal role diperbaharui
6. Role Has Permissions
Nama Tabel : role_has_permissions
Primary Key : role_has_permission_id
Foreign Key : role_id, permission_id
Tipe Tabel : transaksi
127
Tabel 4.35 Basis Data Role Has Permissions
No. Field Tipe Size Keterangan
1. permission_id unsigned integer 10 kode permission
2. role_id unsigned integer 10 nama model pemilik
permission
7. Jenis Dokumen
Nama Tabel : jenis_dokumens
Primary Key : jenis_dokumen_id
Foreign Key : -
Tipe Tabel : master
Tabel 4.36 Basis Data Jenis Dokumen
No. Field Tipe Size Keterangan
1. jenis_dokumen_id unsigned
integer
2 kode jenis dokumen
2. name varchar 50 nama jenis dokumen
3. created_at datetime - tanggal jenis dokumen
dibuat
4. updated_at datetime - tanggal jenis dokumen
diperbaharui
8. Dokumen
Nama Tabel : dokumens
Primary Key : dokumen_id
Foreign Key : departemen_id, jenis_dokumen_id, user_id
Tipe Tabel : transaksi
Tabel 4.37 Basis Data Dokumen
No. Field Tipe Size Keterangan
1. dokumen_id unsigned
integer
12 kode dokumen
2. no varchar 30 nomor dokumen
128
3. name varchar 30 nama dokumen
4. departemen_id unsigned
integer
5 kode departemen
5. jenis_dokumen_id unsigned`
integer
5 kode jenis dokumen
6. user_id unsigned
integer
5 kode user
7. created_at datetime - tanggal dokumen
dibuat
8. updated_at datetime - tanggal dokumen
diperbaharui
9. Pengajuan
Nama Tabel : pengajuans
Primary Key : pengajuan_id
Foreign Key : dokumen_id, user_id
Tipe Tabel : transaksi
Tabel 4.38 Basis Data Pengajuan
No. Field Tipe Size Keterangan
1. pengajuan_id unsigned
integer
12 kode pengajuan
2. dokumen_id unsigned
integer
12 kode dokumen
3. user_id unsigned
integer
5 kode user
4. description text - deskripsi pengajuan
5. created_at datetime - tanggal pengajuan dibuat
6. updated_at datetime - tanggal pengajuan
diperbaharui
10. Verifikasi
Nama Tabel : verifikasis
Primary Key : verifikasi_id
129
Foreign Key : pengajuan_id, user_id
Tipe Tabel : transaksi
Tabel 4.39 Basis Data Verifikasi
No. Field Tipe Size Keterangan
1. verifikasi_id unsigned
integer
12 kode verifikasi
2. pengajuan_id unsigned
integer
12 kode pengajuan
3. verified boolean - status verifikasi
4. user_id unsigned
integer
5 kode user
5. reason text - keterangan tambahan
verifikasi
6. expired_at datetime - tanggal kadaluarsa
verifikasi
7. created_at datetime - tanggal verifikasi
dibuat
8. updated_at datetime - tanggal verifikasi
diperbaharui
11. Revisis
Nama Tabel : revisis
Primary Key : revisi_id
Foreign Key : verifikasi_id, user_id
Tipe Tabel : transaksi
Tabel 4.40 Basis Data Revisi
No. Field Tipe Size Keterangan
1. revisi_id unsigned
integer
12 kode revisi
2. user_id unsigned
integer
5 kode user
3. verifikasi_id unsigned
integer
12 kode verifikasi
4. approved boolean - status approval
130
5. description text - keterangan
tambahan revisi
6. expired_at datetime - tanggal kadaluarsa
revisi
7. created_at datetime - tanggal revisi
dibuat
8. updated_at datetime - tanggal revisi
diperbaharui
12. Disposisi
Nama Tabel : disposisis
Primary Key : id
Foreign Key : verifikasi_id, user_id
Tipe Tabel : transaksi
Tabel 4.41 Basis Data Disposisi
No. Field Tipe Size Keterangan
1. id unsigned
integer
12 kode disposisi
2. about varchar 50 perihal disposisi
3. verifikasi_id unsigned
integer
12 kode verifikasi
4. user_id unsigned
integer
5 kode user
5. user_id unsigned
integer
5 kode user
6. response text - balasan terkait
disposisi
7. accepted boolean - status penerimaan
disposisi
8. expired_at datetime - tanggal
kadaluarsa
disposisi
9. created_at datetime - tanggal disposisi
dibuat
131
10. updated_at datetime - tanggal disposisi
diperbaharui
13. Pencairan
Nama Tabel : pencairans
Primary Key : id
Foreign Key : disposisi_id, user_id
Tipe Tabel : transaksi
Tabel 4.42 Basis Data Pencairan
No. Field Tipe Size Keterangan
1. id unsigned
integer
12 kode pencairan
2. disposisi_id unsigned
integer
12 kode disposisi
3. finished boolean - status selesainya
pencairan
4. description text - keterangan pencairan
5. user_id unsigned
integer
5 kode user
6. created_at datetime - tanggal pencairan
dibuat
7. updated_at datetime - tanggal pencairan
diperbaharui
14. Threads
Nama Tabel : threads
Primary Key : id
Foreign Key : user_id
Tipe Tabel : transaksi
132
Tabel 4.43 Basis Data Threads
No. Field Tipe Size Keterangan
1. id unsigned
integer
12 kode message
2. subject varchar 12 subject dari
thread
3. user_id unsigned
integer
12 kode dari user
4. created_at datetime - tanggal thread
dibuat
5. updated_at datetime - tanggal thread
diperbaharui
6. deleted_at datetime - tanggal thread
dihapus
15. Messages
Nama Tabel : messages
Primary Key : message_id
Foreign Key : thread_id, user_id
Tipe Tabel : transaksi
Tabel 4.44 Basis Data Messages
No. Field Tipe Size Keterangan
1. message_id unsigned
integer
10 kode message
2. thread_id unsigned
integer
10 kode thread
3. user_id unsigned
integer
10 kode user
4. body varchar 191 isi message
5. created_at datetime tanggal
message dibuat
133
6. updated_at datetime - tanggal
message
diperbaharui
7. deleted_at datetime - tanggal
message
dihapus
16. Participants
Nama Tabel : participants
Primary Key : participant_id
Foreign Key : thread_id, user_id
Tipe Tabel : transaksi
Tabel 4.45 Basis Data Participants
No. Field Tipe Size Keterangan
1. participant_id unsigned
integer
10 kode
participants
2. thread_id unsigned
integer
10 kode thread
3. user_id unsigned
integer
10 kode user
4. last_read datetime - tanggal terakhir
user membaca
5. created_at datetime - tanggal thread
dibuat
6. updated_at datetime - tanggal thread
diperbaharui
7. deleted_at datetime - tanggal thread
dihapus
134
4.6 Desain Interface
Setelah membuat struktur menu pada desain struktur antarmuka, lalu akan
dibuat interface prototype yang menyerupai tampilan yang akan dilihat user.
Gambar 4.31 Tampilan Login
Gambar 4.32 Reset Password
135
Gambar 4.33 Tampilan Dashboard
Gambar 4.34 Tampilan Manage Users
136
Gambar 4.35 Tampilan Manage Roles
Gambar 4.36 Tampilan Manage Permissions
137
Gambar 4.37 Tampilan Manage Departemen
Gambar 4.38 Pengajuan Dokumen
138
Gambar 4.39 Verifikasi Dokumen
Gambar 4.40 Revisi Dokumen
139
Gambar 4.41 Disposisi
Gambar 4.42 Pencairan
140
Gambar 4.43 Lembar Laporan
4.7 Sprint Review
Pada tahap ini peneliti melakukan pengujian terhadap hasil pengembangan
sistem selama masa Sprint. Pengujian dilakukan untuk meminimalisir kesalahan
fatal ataupun mencegah sistem malfungsi sebelum diimplementasikan. Sistem diuji
coba oleh peneliti maupun salah satu orang yang tidak memiliki keahlian
pemrograman. Pengujian dilakukan dengan metode black box testing,
menggunakan teknik scenario testing.
141
Tabel 4.48 Skenario Pengujian
Skenario 1 Skenario 2 Skenario 3 Skenario 4 Skenario 5 Skenario 6
Aksi : Input Data
Dokumen
Aksi : Pengajuan
Dokumen
Aksi : Verifikasi
Dokumen
Aksi : Revisi
Dokumen
Aksi : Disposisi
Dokumen
Aksi : Pencairan
Aksi dimana user
menginput data
dokumen
Aksi dimana user
mengajukan
dokumen yang sudah
terdata
Aksi dimana user
melakukan verifikasi
dokumen yang telah
diajukan
Aksi dimana user
melakukan revisi
dokumen bila
dokumen ditolak
Aksi dimana user
melakukan disposisi
hasil verifikasi
dokumen
Aksi dimana user
memproses
pencairan dokumen
142
1. Pengujian Input Data Dokumen
Tabel 4.49 Pengujian Input Data Dokumen
Pengujian Input Data Dokumen
Aktor Staf Keuangan Fakultas
Menu Dokumen
Aktivitas Rancangan Proses 1. Klik create
2. Isi form data
dokumen
3. Klik tombol simpan
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil meng-
input data dokumen
2. Pengujian Pengajuan Dokumen
Tabel 4.50 Pengujian Pengajuan Dokumen
Pengujian Pengajuan Dokumen
Aktor Kuasa Pengguna
Anggaran
Menu Dokumen
Aktivitas Rancangan Proses 1. Klik tombol
pengajuan pada
dokumen yang ingin
diajukan di menu
dokumen
2. Isi form data
pengajuan
3. Klik simpan
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
143
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil me-
ngajukan dokumen
3. Pengujian Verifikasi Dokumen
Tabel 4.51 Pengujian Verifikasi Dokumen
Pengujian verifikasi dokumen
Aktor SPI
Menu Pengajuan
Aktivitas Rancangan Proses 1. Klik tombol
verifikasi pada list
pengajuan yang ada
pada menu
pengajuan
2. Isi form data
verifikasi
3. Klik simpan
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil me-
lakukan verifikasi
pengajuan dokumen
144
4. Pengujian Revisi Dokumen
Tabel 4.52 Pengujian Revisi Dokumen
Pengujian Revisi Dokumen
Aktor Staf Keuangan Fakultas
Menu Verifikasi
Aktivitas Rancangan Proses 1. Klik tombol revisi
pada list hasil
verifikasi yang ada
pada menu verifikasi
2. Isi form data revisi
3. Klik simpan
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil me-
lakukan revisi pengajuan
dokumen
5. Pengujian Disposisi Dokumen
Tabel 4.53 Pengujian Disposisi Dokumen
Pengujian Disposisi Dokumen
Aktor SPI, Kasubbag
Verifikasi
Menu - Verifikasi
- Revisi (bila
dokumen belum
terverifikasi)
Aktivitas Rancangan Proses 1. Klik tombol
disposisi pada list
hasil verifikasi atau
revisi yang ada pada
menu verifikasi atau
revisi
2. Isi form data
disposisi
3. Klik simpan
145
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil
menginput data disposisi
hasil verifikasi
6. Pengujian Pencairan Dokumen
Tabel 4.54 Pengujian Pencairan Dokumen
Pengujian Pencairan Dokumen
Aktor BPP
Menu Disposisi
Aktivitas Rancangan Proses 1. Klik tombol
pencairan pada list
disposisi yang ada
pada menu disposisi
2. Isi form data
pencairan
3. Klik simpan
Tanda Peringatan Kesalahan - Sistem gagal
menyimpan data
- Sistem menampilkan
pesan pada field yang
error “field harus
diisi”
Kesesuaian Sistem -
Hasil Warning -
Accept Sesuai
Keterangan Aktor berhasil me-
lakukan menginput data
pencairan
146
BAB 5
PENUTUP
Pada bab ini penulis menjabarkan hasil dari kesimpulan penelitian dan saran
yang dapat bermanfaat bagi pengembangan sistem ini maupun sistem lainnya.
Berikut adalah kesimpulan dan saran yang dapat penulis jelaskan:
5.1 Kesimpulan
Dari perumusan masalah yang diangkat dalam penelitian ini, maka dapat
disimpulkan bahwa:
1. Mengacu dari hasil wawancara dengan Bapak Ady Cahyadi sebagai
Sekretaris SPI dan Bapak Rezky Mehta sebagai Koor Divisi Kepatuhan dan
Keuangan SPI bahwa Revolving Fund Document Management System
mampu mendukung unit yang terlibat dalam pemrosesan dokumen untuk
memantau dokumen secara realtime dengan menghadirkan dialog informasi
posisi dan status dokumen.
2. Sistem ini menawarkan opsi kemudahan backup file dokumen berdasarkan
proses yang telah dilakukan sebagai alternatif dari pengarsipan dokumen
fisik yang memiliki kemungkinan tercecer dan mengalami kerusakan akibat
kelalaian ataupun kecelakaan.
3. Sistem ini mampu menyediakan sarana bertukar informasi dengan fitur
pesan dan menampilkan waktu proses dari hasil pengajuan serta kinerja
pemrosesan dokumen selama satu bulan terakhir.
147
4. Sistem dapat menampilkan waktu yang diperlukan dan waktu yang tersisa
untuk memproses suatu dokumen. Sistem ini juga menampilkan dokumen
yang membutuhkan respon segera pada halaman utama sebagai upaya untuk
mengurangi waktu pemrosesan dokumen yang terlambat.
5.2 Saran
Dari hasil kesimpulan yang diuraikan sebelumnya, sistem ini masih
memiliki banyak keterbatasan dan kekurangan. Oleh karena itu ada beberapa hal
yang penulis sampaikan untuk membantu sistem ini menjadi lebih baik di masa
mendatang.
1. Melakukan migrasi seluruhnya ke proses yang paperless dengan cara
mendigitalisasikan dokumen-dokumen yang ada.
2. Menambahkan fitur pengelolaan dokumen untuk proses Tambah Uang
Persediaan dan mengintegrasikan sistem ini dengan Academic Information
System (AIS).
3. Melakukan pengujian keamanan dan memperbaiki celah keamanan sistem
dengan melakukan penetration testing.
149
DAFTAR PUSTAKA
Del Sole, Alessandro. 2019. Visual Studio Code Distilled: Evolved Code Editing
for Windows, macOS, and Linux. New York: Apress
Chaudhary, Mukund. 2014. PhpStorm Cookbook. Birmingham: Packt Publishing
Date, C.J. 2016. The New Relational Database Dictionary. California: O’Reilly
Media
Dennis, A. et al. (2012). Systems Analysis and Design. New Jersey : John Wiley &
sons.
Duckett, Jon. 2011. HTML & CSS: Design and Build Websites. Indianapolis: John
Wiley & Sons
Gunardi, Adam. 2014. Rancang Bangun Sistem Informasi E-Document
Management System. Fakultas Sains dan Teknologi, UIN Syarif
Hidayatullah. Jakarta
Hansen, T.B. dan Lengstorf, J. 2014. PHP for Absolute Beginners. New York:
APRESS
Helmers, S.A. 2015. Microsoft Visio 2016: Step by Step. Washington: Microsoft
Press
H.M, Jogiyanto, 2010. Analisis dan Desain Sistem Informasi. Andi Offset.
Yogyakarta
Kendall, E.K. dan Kendall, J.E. 2014. Systems Analysis and Design. New Jersey:
Pearson
Levitin, Anany. 2012. Introduction to Design and Analysis of Algorithm. New
Jersey: Pearson
Mulyanto, Agus. 2009. Sistem Informasi Konsep & Aplikasi. Yogyakarta: Pustaka
Pelajar
Nixon, Robin. 2014. Learning PHP, MySQL & JavaScript: With Jquery, CSS &
HTML5. California: O’Reilly Media
Object Management Group. (2011). OMG Unified Modelling Language (OMG
UML) Infrastructure, version 2.4. Massachusetts : OMG.
150
Pressman, R.S. dan Maxim, B.R. 2015. Software Engineering: A Practitioner’s
Approach. New York: McGraw-Hill
Republik Indonesia. 2008. Undang-Undang No. 11 Tahun 2008 Tentang Informasi
dan Transaksi Elektronik. Jakarta: Arsip Nasional Republik Indonesia
Riel, Andreas., et al. 2010. Systems, Software and Services Process Improvement.
New York: Springer
Tahaghoghi, S. dan Williams, E.H. 2007. Learning MySQL. California: O’Reilly
Media
Saleh, Abdul Rahman. 2009. Peran Pustakawan Dalam Disseminasi Informasi
Kepada Peneliti Via Jurnal Elektronik Lokal. Bogor: Visi Pustaka
Sklar, David. 2016. Learning PHP. California: O’Reilly Media
Sommerville, I. 2011. Software Engineering. Boston: Addison Wesley
Stair, R.M. dan Reynolds, G.W. 2010. Principles of Information Systems. Boston:
Cengage
Stair, R.M. dan Reynolds, G.W. 2016. Fundamentals of Information Systems.
Boston: Cengage
Stauffer, Matt. 2019. Laravel Up & Running: A Framework for Building Modern
PHP Apps. California: O’Reilly Media, Inc.
Sutherland, J., & Schwaber, K. (2013). The Scrum Guide-The Definitive Guide to
Scrum: The Rules of the Game. Scrum.org.
Sukoco, Badri Munir. 2007. Manajemen Administrasi Perkantoran Modern.
Jakarta: Erlangga
Stellman, A., dan Greene, J. (2014). Learning agile: Understanding scrum, XP,
Lean, and Kanban. California : O’Reilly Media, Inc.
UIN Syarif Hidayatullah Jakarta. 2014. Peraturan Rektor UIN Syarif Hidayatullah
Jakarta. Jakarta: Kementerian Agama
Whitten, J.L. dan Bentley, L.D. 2007. Systems Analysis & Design Methods. New
York: McGraw-Hill
Wiggins, J.M., Wiggins, D.E., dan Botha, S.J. 2007. System and Method of Web
Browser-Based Document and Content Management. U.S. Patent
20070250531, October 25, 2007.
151
Wulandari, Arini. Rancang Bangun E-Document Management System pada BMT
Al Munawarah Pusat. Fakultas Sains dan Teknologi, UIN Syarif
Hidayatullah. Jakarta.
Yank, Kevin. 2012. PHP & MySQL: Novice to Ninja. Victoria: SitePoint
LAMPIRAN
Source Code Aplikasi
//web.php
// Home Redirecting
Route::get('dashboard',
function () {
return redirect()-
>route('dashboard.' .
Auth::user()->getRoleNames()-
>first());
})->name('dashboard');
// Register, Login, Reset
Password
Route::group(['namespace' =>
'Auth'], function () {
Route::get('/register',
'RegisterController@showRegist
rationForm')
->name('register');
Route::post('/register',
'RegisterController@register')
-
>name('register.submit');
Route::get('/login',
'LoginController@showLoginForm
')
->name('login');
Route::post('/login',
'LoginController@login')
-
>name('login.submit');
Route::post('/logout',
'LoginController@logout')
->name('logout');
Route::get('/password/email',
'ForgotPasswordController@show
LinkRequestForm')
-
>name('password.request');
Route::post('/password/email',
'ForgotPasswordController@send
ResetLinkEmail')
-
>name('password.email');
Route::get('/password/reset/{t
oken?}',
'ResetPasswordController@showR
esetForm')
-
>name('password.reset');
Route::post('/password/reset',
'ResetPasswordController@reset
')
-
>name('password.reset.submit')
;
});
//Administrations
Route::group(['prefix' =>
'manage', 'middleware' =>
['auth', 'web']], function ()
{
//users
Route::resource('users',
'UserController')
->except(['create',
'show', 'edit', 'destroy']);
Route::delete('users/{id}',
'UserController@destroy');
//roles
Route::resource('roles',
'RoleController')
->except(['create',
'show', 'edit', 'destroy']);
Route::delete('roles/{id}',
'RoleController@destroy');
//permissions
Route::resource('permissions',
'PermissionController')
->except(['create',
'show', 'edit', 'destroy']);
Route::delete('permissions/{id
}',
'PermissionController@destroy'
);
//departemens
Route::resource('departemens',
'DepartemenController')
->except(['create',
'show', 'edit', 'destroy']);
Route::delete('departemens/{id
}',
'DepartemenController@destroy'
);
});
//Dashboards
Route::group(['prefix' =>
'dashboard'], function () {
Route::get('/admin',
'DashboardController@adminDash
board')
-
>name('dashboard.admin')
-
>middleware(['role:admin']);
Route::get('/keuangan-
fakultas',
'DashboardController@keuanganF
akultasDashboard')
-
>name('dashboard.keuangan_faku
ltas')
-
>middleware(['role:keuangan_fa
kultas']);
Route::get('/kpa',
'DashboardController@kpaDashbo
ard')
-
>name('dashboard.kpa')
-
>middleware(['role:kpa']);
Route::get('/spi',
'DashboardController@spiDashbo
ard')
-
>name('dashboard.spi')
-
>middleware(['role:spi']);
Route::get('/verifikasi',
'DashboardController@verifikas
iDashboard')
-
>name('dashboard.verifikasi')
-
>middleware(['role:verifikasi'
]);
Route::get('/bpp',
'DashboardController@bppDashbo
ard')
-
>name('dashboard.bpp')
-
>middleware(['role:bpp']);
});
//Dokumen routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/dokumen',
'DokumenController@index')
-
>name('dokumen.index')
-
>middleware(['role:admin|keuan
gan_fakultas|kpa']);
Route::post('/dokumen',
'DokumenController@store')
-
>name('dokumen.store')
-
>middleware(['permission:creat
e dokumen']);
});
//Pengajuan routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/pengajuan',
'PengajuanController@index')
-
>name('pengajuan.index')
-
>middleware(['role:admin|keuan
gan_fakultas|kpa|spi']);
Route::post('/pengajuan',
'PengajuanController@store')
-
>name('pengajuan.store')
-
>middleware(['permission:creat
e pengajuan']);
});
//Verifikasi routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/verifikasi',
'VerifikasiController@index')
-
>name('verifikasi.index')
-
>middleware(['role:admin|keuan
gan_fakultas|spi|kpa|verifikas
i']);
Route::post('/verifikasi',
'VerifikasiController@store')
-
>name('verifikasi.store')
-
>middleware(['permission:creat
e verifikasi']);
});
//Revisi routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/revisi',
'RevisiController@index')
->name('revisi.index')
-
>middleware(['role:admin|keuan
gan_fakultas|spi']);
Route::post('/revisi',
'RevisiController@store')
->name('revisi.store')
-
>middleware(['permission:creat
e revisi']);
Route::patch('/revisi/approve/
{id}',
'RevisiController@approve')
-
>name('revisi.approve');
});
//Disposisi routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/disposisi',
'DisposisiController@index')
-
>name('disposisi.index')
-
>middleware(['role:admin|verif
ikasi|spi|bpp']);
Route::post('/disposisi',
'DisposisiController@store')
-
>name('disposisi.store')
-
>middleware(['permission:creat
e disposisi']);
});
//Pencairan routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/pencairan',
'PencairanController@index')
-
>name('pencairan.index')
-
>middleware(['role:admin|keuan
gan_fakultas|bpp']);
Route::post('/pencairan',
'PencairanController@store')
-
>name('pencairan.store')
-
>middleware(['permission:creat
e pencairan']);
});
//Laporan routes
Route::group(['middleware' =>
['auth', 'web']], function ()
{
Route::get('/laporan',
'LaporanController@index')
-
>name('laporan.index')
-
>middleware(['role:admin|keuan
gan_fakultas|bpp']);
Route::post('/laporan',
'LaporanController@store')
-
>name('laporan.store')
-
>middleware(['permission:creat
e laporan']);
//
Route::get('laporan/generate',
function () {
// return
view('laporan.laporan');
// });
Route::get('laporan/{dokumen}/
generate',
'LaporanController@generateLap
oran')
-
>name('generateLaporan');
});
Route::get('/about',
'DashboardController@about')-
>name('about');
//Administrations
Route::group(['namespace' =>
'Tables', 'prefix' =>
'datatable'], function () {
Route::get('/users',
'UserTableController@getUsers'
);
Route::get('/roles',
'RoleTableController@getRoles'
);
Route::get('/permissions',
'PermissionTableController@get
Permissions');
Route::get('/departemens',
'DepartemenTableController@get
Departemens');
});
//login.blade.php
@extends('layouts.master')
@section('styles')
<link rel="stylesheet"
href="https://maxcdn.bootstrap
cdn.com/font-
awesome/4.7.0/css/font-
awesome.min.css">
<link rel="stylesheet"
href="https://cdnjs.cloudflare
.com/ajax/libs/bulma/0.5.1/css
/bulma.min.css" />
<link rel="stylesheet"
type="text/css" href="{{
asset('css/login.css') }}">
@endsection
@section('contents')
<body>
<section class="hero is-
fullheight">
<div class="hero-
body">
<div
class="container has-text-
centered">
<div
class="column is-4 is-offset-
4">
<h3
class="title has-text-
grey">Login</h3>
<p
class="subtitle has-text-
grey">Please login to
proceed.</p>
<div
class="box">
<figure class="avatar">
<img
src="http://style.anu.edu.au/_
anu/4/images/placeholders/pers
on.png">
</figure>
<form
method="POST" action="{{
route('login.submit') }}">
{{
csrf_field() }}
<div class="field">
<div class="control">
<input class="input"
id="email" type="email"
name="email"
value="{{ old('email') }}"
required autofocus>
@if ($errors->has('email'))
<p class="help is-danger">
{{ $errors->first('email') }}
</p>
@endif
</div>
</div>
<div class="field">
<div class="control">
<input class="input"
id="password" type="password"
name="password" required>
@if ($errors->has('password'))
<p class="help is-danger">
{{ $errors->first('password')
}}
</p>
@endif
</div>
</div>
<div class="field">
<label class="checkbox">
<input type="checkbox"
name="remember" {{
old('remember') ? 'checked' :
'' }}> Remember Me
</label>
</div>
<button class="button is-block
is-info is-large is-
fullwidth">Login</button>
</form>
</div>
<p
class="has-text-grey">
{{--
<a href="../">Sign Up</a>
· --}}
<a
href="{{
route('password.request') }}">
Forgot Your Password?
</a>
·
{{--
<a href="../">Need Help?</a> -
-}}
</p>
</div>
</div>
</div>
</section>
@endsection
