i

RANCANG BANGUN SISTEM REPOSITORY SURAT KEPUTUSAN (SK) DENGAN MEMANFAATKAN

ZKOSS FRAMEWORK (Studi Kasus : Sub Bagian Organisasi Tata Laksana dan Perundang-

undangan Universitas Islam Negeri Syarif Hidayatullah Jakarta)

Skripsi

Disusun Oleh :

FAUZI RAHMAN 107091000614

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS ISLAM NEGERI

SYARIF HIDAYATULLAH

JAKARTA

2011 M/ 1432 H

i

i

RANCANG BANGUN SISTEM REPOSITORY SURAT KEPUTUSAN (SK) DENGAN MEMANFAATKAN

ZKOSS FRAMEWORK (Studi Kasus : Sub Bagian Organisasi Tata Laksana dan Perundang-

undangan Universitas Islam Negeri Syarif Hidayatullah Jakarta)

Skripsi

Sebagai Salah Satu Syarat Untuk Memperoleh Gelar

Sarjana Komputer

Fakultas Sains dan Teknologi

Universitas Islam Negeri Syarif Hidayatullah Jakarta

Oleh :

FAUZI RAHMAN

107091000614

PROGRAM STUDI TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS ISLAM NEGERI

SYARIF HIDAYATULLAH

JAKARTA

2011 M/ 1432 H

ii

ii

iii

iii

iv

iv

PERNYATAAN

DENGAN INI SAYA MENYATAKAN BAHWA SKRIPSI INI BENAR-BENAR HASIL KARYA SENDIRI YANG BELUM PERNAH DIAJUKAN SEBAGAI SKRIPSI ATAU KARYA ILMIAH PADA PERGURUAN TINGGI ATAU LEMBAGA MANAPUN. SUMBER INFORMASI YANG BERASAL ATAU DIKUTIP DARI KARYA ILMIAH YANG DITERBITKAN MAUPUN TIDAK DITERBITKAN DARI PENULIS LAIN TELAH DISEBUTKAN DALAM TEKS DAN DICANTUMKAN DALAM DAFTAR PUSTAKA DI BAGIAN AKHIR SKRIPSI INI.

Jakarta, 13 Desember 2011

Fauzi Rahman 107091000614

v

v

ABSTRAK

Fauzi Rahman, Rancang Bangun Sistem Repository Surat Keputusan (SK) dengan Memanfaatkan Zkozz Framework (Studi Kasus : Sub Bagian Organisasi Tata Laksana dan Perundang-undangan Universitas Islam Negeri Syarif Hidayatullah Jakarta) dibawah bimbingan HUSNI TEJA SUKMANA, Ph.D dan MUHAMMAD FAUZI MURTADLO, S.Kom, M.IT.

Sistem Repository SK adalah sebuah sistem online berbasis Web yang dapat menangani penyimpanan berkas secara digital dan dapat menampung berkas SK untuk 14 Unit Kerja/Fakultas yang ada di UIN Jakarta dengan pembatasan masalah yaitu untuk 4 kategori SK. Dalam pembuatan aplikasi web ini penulis menggunakan metode pengembangan sistem Rapid Application Development (RAD) dan untuk pembuatan aplikasi menggunakan Zkoss Framewok. Pada akhirnya, sistem ini dapat memberikan keluaran kepada penggunanya berupa berkas digital yang dapat diakses secara real time, penyimpanan dan pencarian berkas menjadi lebih mudah dan cepat. Aplikasi ini dapat dikembangkan lagi dengan penambahan modul-modul kategori SK lainnya mengingat banyaknya kategori SK yang ada di Subbag Ortala. Kata Kunci : Repository, Surat Keputusan (SK), ZKoss, RAD

vi

vi

KATA PENGANTAR

Assalamu’alaikum Warahmatullahi Wabarakatuh

Segala puji kehadirat Allah AWT yang telah memberikan taufiq dan

hidayah-Nya, rahmat dan maghfirah-Nya sehingga penulis dapat menyelesaikan

skripsi ini dengan baik. Shalawat serta salam selalu tersampaikan kepada

Rasulullah SAW yang telah menyampaikan ajaran Islam sehingga menyejukan

hati ini dalam menyelesaikan skripsi ini.

Penulis menyadari bahwa penulisan ini tidak dapat terselesaikan tanpa

bantuan dari pihak lain. Oleh karena itu izinkanlah penulis mengucapkan

terimakasih yang sebesar-besarnya kepada semua pihak yang telah membantu

penulis dalam menyelesaikan skripsi ini, terutama kepada :

1. Bapak DR. Syopiansyah Jaya Putra, M.Sis, Selaku Dekan Fakultas Sains

dan Teknologi.

2. Bapak Yusuf Durrachman, MIT, M.Sc dan Ibu Viva Arifin, M.Si selaku

Ketua dan Sekretaris Program Studi Teknik Informatika yang dengan tulus

membantu kelancaran penyelesaian skripsi ini.

3. Bapak Husni Teja Sukmana, Ph. D selaku dosen pembimbing I yang

dengan ikhlas dan sabar dalam membimbing dan mengarahkan penulis

dalam menyelesaikan skripsi ini.

4. Bapak Muhammad Fauzi Murtadlo, S.Kom, M.TI selaku dosen pembimbing

II yang telah banyak memberikan bimbingan, nasihat, ilmu dan dukungan

baik secaara moril maupun secara teknis kepada penulis dalam

menyelesaikan skripsi ini.

5. Seluruh Dosen, staf karyawan Fakultas Sains dan Teknologi, khususnya

Program Studi Teknik Informatika yang telah membimbing penulis selama

menuntut ilmu, berbagi pengalaman dan pengetahuan dalam menyelesaikan

skripsi ini.

vii

vii

6. Ayahanda Suryono dan Ibunda Ilah Carmillah serta kakak tercinta (Beni

Aprijiani) dan kedua adik tersayang (Fajar Ramdhani dan Fikar Ardiansyah)

yang tidak henti-hentinya mendo’akan, memotivasi, dengan tulus ikhlas

serta curahan perhatian dalam lahir maupun batin sepanjang penulis

mengikuti masa proses kuliah hingga masa proses penyusunan skripsi ini.

7. Untuk kawan saya Hendra Kurniawan dan Sufyan Sidqy yang telah

memberikan dukungan serta ilmu yang dapat membantu saya dalam

penyusunan skripsi ini.

8. Sahabat seperjuangan Uyun, Siti maryam, Dwi Vollina, Miftah Haris,

Muhammad Affandy dan teman-teman CCNA Academy tercinta yang telah

memberikan motivasi bagi penulis dalam proses penyelesaian skripsi ini.

9. Mery Andriyani Putri tercinta yang selalu memberi semangat serta motivasi

kepada penulis dari awal hingga selesainya skripsi ini.

Akhir kata Kesempurnaan hanya milik Allah SWT, begitu juga dengan

skripsi ini dan penulis mengharapkan kritik serta saran yang membangun dari

pembaca untuk penulisan skripsi yang lebih baik lagi. Semoga skripsi ini

bermanfaat bagi semua pembaca. Amin

Wassalamu’alaikum Warahmatullahi Wabarakatuh

Jakarta, 13 Desember 2011

Fauzi Rahman (107091000614)

viii

viii

DAFTAR ISI

Halaman

Halaman Judul .................................................................................................. i

Persetujuan Pembimbing.................................................................................. ii

Halaman Pengesahan ........................................................................................ iii

Halaman Pernyataan......................................................................................... iv

Abstrak ............................................................................................................... v

Kata Pengantar ................................................................................................. vi

Daftar Isi ............................................................................................................ viii

Daftar Gambar .................................................................................................. xii

Daftar Tabel ....................................................................................................... xvii

Daftar Simbol.....................................................................................................xviii

BAB I PENDAHULUAN 1

1.1 Latar Belakang ........................................................................................ 1

1.2 Rumusan Masalah.................................................................................... 4

1.3 Pembatasan Masalah ............................................................................... 4

1.4 Tujuan Penelitian ..................................................................................... 5

1.5 Manfaat Penelitian ................................................................................... 6

1.5.1 Bagi Pengguna Siste....................................................................... 6

1.5.2 Bagi Penulis ................................................................................... 6

1.5.3 Bagi Akademik ............................................................................... 7

1.6 Metodologi Penelitian ............................................................................. 7

1.6.1 Metodologi Pengumpulan Data ..................................................... 7

1.6.2 Metodologi Pengembangan Sistem................................................ 8

1.7 Sistematika Penulisan .............................................................................. 8

BAB II LANDASAN TEORI........................................................................... 10

2.1 Konsep Dasar Sistem............................................................................... 10

2.1.1 Pengertian Sistem........................................................................... 10

2.1.2 Karakteristik Sistem ....................................................................... 10

ix

ix

2.1.3 Klasifikasi Sistem .......................................................................... 12

2.2 Konsep Dasar Informasi .......................................................................... 14

2.2.1 Data Versus Informasi.................................................................... 14

2.2.2 Siklus Informasi.............................................................................. 15

2.2.3 Nilai Informasi ............................................................................... 16

2.3 Konsep Dasar Sistem Informasi .............................................................. 17

2.3.1 Pengertian Sistem Infromasi .......................................................... 17

2.3.2 Komponen Sistem Informasi.......................................................... 18

2.4 Repository................................................................................................ 19

2.5 Surat ........................................................................................................ 20

2.6 Konsep Basis Data dan DBMS (Database Management System) .......... 22

2.6.1 Definisi Basis Data (Database)....................................................... 23

2.6.2 DBMS (Database Management System)......................................... 26

2.7 Object Relational Mapping (ORM) ......................................................... 27

2.7.1 Alasan Memilih ORM.................................................................... 28

2.7.2 Keunggulan ORM .......................................................................... 28

2.8 SQL (Structured Query Language) ......................................................... 29

2.9 PostgreSQL ............................................................................................. 30

2.10 Web ........................................................................................................ 31

2.10.1 Arsitektur Web Tradisional .......................................................... 32

2.10.2 Aplikasi Web ................................................................................ 34

2.11 Unified Modeling Language (UML) ....................................................... 35

2.11.1 Use Case Diagram ........................................................................ 37

2.11.2 Activity Diagram .......................................................................... 38

2.11.3 Sequence Diagram ....................................................................... 38

2.11.4 Class Diagram .............................................................................. 39

2.11.5 Statechart Diagram ...................................................................... 41

2.12 Java ........................................................................................................ 41

2.12.1 Kelebihan Java ............................................................................. 42

2.12.2 Kekurangan Java .......................................................................... 44

2.13 Framework............................................................................................... 44

x

x

2.14 Zkoss Framework .................................................................................... 47

2.14.1 Alasan Memilih Teknologi Zkoss................................................ 48

2.14.2 Karakteristik Utama ZK............................................................... 49

2.15 Perbandingan Framework ZK dengan Struts........................................... 52

2.16 Pengujian Blackbox ................................................................................. 53

2.17 Studi Literatur ......................................................................................... 54

BAB III METODOLOGI PENELITIAN ...................................................... 64

3.1. Metode Pengumpulan Data ..................................................................... 64

3.1.1. Studi Lapangan .............................................................................. 64

3.1.1.1 Observasi ............................................................................ 64

3.1.1.2 Wawancara ......................................................................... 65

3.1.2 Studi Pustaka .................................................................................. 67

3.2 Metode Pengembangan Sistem (RAD) .................................................. 68

3.2.1 Alasan Menggunakan RAD............................................................ 68

3.2.2 Fase-fase RAD ............................................................................... 70

3.2.3 Kelebihan RAD .............................................................................. 76

3.2.4 Kekurangan RAD............................................................................ 77

3.3 Kerangka Berpikir Penelitian .................................................................. 78

BAB IV PEMBAHASAN ............................................................................... 79

4.1 Perencanaan Persyaratan (Requirement Planning).................................. 79

4.1.1 Sekilas Tentang UIN Syarif Hidayatullah Jakarta ......................... 80

4.1.2 Visi, Misi dan Tujuan UIN ............................................................. 80

4.1.3 Subbagian Ortala UIN.................................................................... 82

4.1.4 Struktur Organisasi ........................................................................ 83

4.1.5 Analisa Sistem Yang Sedang Berjalan........................................... 84

4.1.6 Identifikasi Masalah ....................................................................... 85

4.1.7 Analisa Kebutuhan Sistem ............................................................. 86

4.1.7.1 Identifikasi Strategi IT ..................................................... 87

4.1.7.2 Identifikasi Pola Solusi .................................................... 87

xi

xi

4.1.7.3 Kebutuhan Fungsional Sistem ......................................... 88

4.1.7.4 Kebutuhan Non Fungsional Sistem ................................. 88

4.1.8 Tujuan Pengembangan Sistem ....................................................... 89

4.1.9 Analisa Proses Bisnis Sistem yang Diusulkan ............................... 90

4.1.10 Membuat Use Case Diagram ....................................................... 91

4.1.10.1 Use Case Secenario.......................................................... 93

4.2 Workshop Design .................................................................................... 106

4.2.1 Design System ............................................................................... 106

4.2.1.1 Membuat Activity Diagram .............................................. 106

4.2.1.2 Membuat Sequence Diagram ........................................... 138

4.2.1.3 Desain Basis Data ............................................................ 157

4.2.1.4 Perancangan Desain Interface.......................................... 161

4.2.2 Build System .................................................................................. 172

4.2.2.1 Bahasa Pemrograman dan Komponen ............................. 172

4.3 Implmentasi ............................................................................................ 173

4.3.1 Perangkat Keras (Hardware) ......................................................... 173

4.3.2 Perangkat Lunak Sistem ................................................................ 174

4.3.3 Platform Arsitektur Teknologi ....................................................... 175

4.3.4 Topologi Infrastruktur .................................................................... 176

4.3.5 Pengujian Sistem............................................................................ 177

4.3.6 Acceptance Testing (Pengujian Penerimaan) ................................. 188

BAB V KESIMPULAN DAN SARAN ........................................................... 189

5.1 Kesimpulan .................................................................................... 189

5.2 Saran .............................................................................................. 190

DAFTAR PUSTAKA ........................................................................................ 191

LAMPIRAN-LAMPIRAN

xii

xii

DAFTAR GAMBAR

Gambar 2.1. Siklus Informasi ............................................................................ 16

Gambar 2.2. Komponen Sistem Informasi ........................................................ 19

Gambar 2.3 Jenjang dari data ........................................................................... 24

Gambar 2.4 Interaksi antara pengguna dan server Web .................................... 33

Gambar 2.5 Contoh Use Case Diagram ............................................................ 37

Gambar 2.6 Contoh Activity Diagram ............................................................... 38

Gambar 2.7 Contoh Sequence Diagram ............................................................ 39

Gambar 2.8 Contoh Class Diagram .................................................................. 41

Gambar 2.9 Contoh Statechart Diagram ........................................................... 41

Gambar 2.10 Struts Framework Bekerja Dalam Aplikasi Web......................... 46

Gambar 3.1 Fase RAD (Kendall & Kendall) .................................................... 70

Gambar 3.2 Kerangka Berfikir Penlitian .......................................................... 78

Gambar 4.1 Struktur Organisasi Biro AUK UIN Syarif Hidayatullah Jakarta.. 83

Gambar 4.2. Rich Picture Sistem Berjalan ........................................................ 85

Gambar 4.3. Bisnis Sistem Usulan..................................................................... 90

Gambar 4.4. Use Case Diagram yang diusulkan............................................... 92

Gambar 4.5 Activity diagram use case login ..................................................... 107

Gambar 4.6 Activity diagram use case Lihat Struktur Organisasi..................... 108

Gambar 4.7 Activity diagram use case Lihat Kontak ........................................ 109

Gambar 4.8 Activity diagram tambah berkas SK............................................... 110

Gambar 4.9 Activity diagram fungsi Delete Berkas SK..................................... 111

xiii

xiii

Gambar 4.10 Activity diagram fungsi Cari Berkas SK Admin.......................... 112

Gambar 4.11 Activity diagram fungsi Cari Berkas SK User.............................. 113

Gambar 4.12 Activity diagram fungsi Validasi Berkas SK ............................... 114

Gambar 4.13 Activity diagram fungsi Detail Berkas SK................................... 116

Gambar 4.14 Activity diagram fungsi Download Berkas SK ............................ 117

Gambar 4.15 Activity diagram Tambah Kategori.............................................. 118

Gambar 4.16 Activity diagram Edit Kategori .................................................... 120

Gambar 4.17 Activity diagram Delete Kategori................................................. 121

Gambar 4.18 Activity diagram Tambah Indeks ................................................. 123

Gambar 4.19 Activity diagram Edit Indeks........................................................ 125

Gambar 4.20 Activity diagram Delete Kategori ................................................ 126

Gambar 4.21 Activity diagram Tambah User Account...................................... 128

Gambar 4.22 Activity diagram Edit User Account ............................................ 129

Gambar 4.23 Activity diagram Delete User....................................................... 131

Gambar 4.24 Activity diagram Tambah Role..................................................... 133

Gambar 4.25 Activity diagram Edit Role........................................................... 134

Gambar 4.26 Activity diagram Delete Role ....................................................... 136

Gambar 4.27 Activity diagram use case logout ................................................. 137

Gambar 4.28 Sequence diagram use case login User........................................ 138

Gambar 4.29 Sequence diagram use case login Admin .................................... 139

Gambar 4.30 Sequence diagram use case Validasi I Berkas............................. 140

Gambar 4.31 Sequence diagram use case Validasi II Berkas ........................... 141

Gambar 4.32 Sequence diagram use case Input/Upload berkas........................ 142

xiv

xiv

Gambar 4.33 Sequence diagram use case cari/detail/download Berkas ........... 144

Gambar 4.34 Sequence diagram use case cari/detail/download Berkas ........... 146

Gambar 4.35 Sequence diagram use case Input/Edit/Delete Kategori.............. 148

Gambar 4.36 Sequence diagram use case Input/Edit/Delete Indeks ................. 150

Gambar 4.37 Sequence diagram use case Input/Edit/Delete User Account...... 152

Gambar 4.38 Sequence diagram use case Input/Edit/Delete Role..................... 154

Gambar 4.39 Sequence diagram use case logout User...................................... 155

Gambar 4.40 Sequence diagram use case logout Admin .................................. 156

Gambar 4.41 Class Diagram ............................................................................. 157

Gambar 4.42 Desain Interface Login................................................................. 161

Gambar 4.43 Desain Interface Beranda (User) ................................................. 162

Gambar 4.44 Desain Interface Beranda Admin Ortala ..................................... 162

Gambar 4.45 Desain Interface Beranda (Admin TU Rektorat) ........................ 163

Gambar 4.46 Desain Interface Beranda (Super Admin).................................... 163

Gambar 4.47 Desain Interface Struktur Organisasi........................................... 164

Gambar 4.48 Desain Interface Kontak .............................................................. 164

Gambar 4.49 Desain Interface lihat berkas (user) ............................................. 165

Gambar 4.50 Desain Interface lihat berkas (Admin TU Rektorat).................... 165

Gambar 4.51 Desain Interface lihat/hapus berkas ............................................. 166

Gambar 4.52 Desain Interface validasi berkas (Admin Ortala) ........................ 166

Gambar 4.53 Desain Interface validasi berkas (Admin TU Rektorat) .............. 167

Gambar 4.54 Desain Interface Tambah Berkas/ Edit Berkas ............................ 167

Gambar 4.55 Desain Interface Detail Berkas/ Download Berkas (User) ......... 168

xv

xv

Gambar 4.56 Desain Interface Detail Berkas/ Download Berkas (Ortala) ...... 168

Gambar 4.57 Desain Interface Detail Berkas/ Download Berkas (Rektorat) ... 169

Gambar 4.58 Desain Interface Tambah/ Edit / Delete Indeks ........................... 169

Gambar 4.59 Desain Interface Tambah/ Edit / Delete Kategori........................ 170

Gambar 4.60 Desain Interface Tambah/Edit/Hapus User ................................. 170

Gambar 4.61 Desain Interface Pengaturan Hak Akses ..................................... 171

Gambar 4.62 Desain Interface Logout .............................................................. 171

Gambar 4.63 Platform Arsitektur Teknologi .................................................... 175

Gambar 4.64 Topologi Inftastruktur Sistem Repository SK ............................. 176

xvi

xvi

DAFTAR TABEL

Tabel 4.1 Identifikasi Strategi IT........................................................................ 87

Tabel 4.2 Identifikasi Pola Solusi ....................................................................... 87

Tabel 4.3 Identifikasi Actor dengan Deskripsi ................................................... 91

Tabel 4.4 Use Case Secenario Login.................................................................. 93

Tabel 4.5 Use Case Scenario Telusur SK........................................................... 94

Tabel 4.6 Use Case Secenario Lihat Beranda .................................................... 94

Tabel 4.7 Use Case Secenario Lihat Struktur Organisasi................................... 95

Tabel 4.8 Use Case Secenario Lihat Kontak...................................................... 96

Tabel 4.9 Use Case Secenario Lihat koleksi SK (User)..................................... 96

Tabel 4.10 Use Case Secenario Lihat koleksi SK (Admin)................................. 97

Tabel 4.11 Use Case Secenario View Detail....................................................... 98

Tabel 4.12 Use Case Secenario Download SK................................................... 98

Tabel 4.13 Use Case Secenario Delete .............................................................. 99

Tabel 4.14 Use Case Secenario Tambah SK...................................................... 100

Tabel 4.15 Use Case Secenario Validasi SK ..................................................... 101

Tabel 4.16 Use Case Secenario Role ................................................................. 102

Tabel 4.17 Use Case Secenario Tambah / edit / delete Indeks/Unit kerja ......... 103

Tabel 4.18 Use Case Secenario Tambah / edit / delete Kategori ....................... 103

Tabel 4.19 Use Case Secenario Tambah / edit / delete user............................... 104

Tabel 4.20 Use Case Secenario Logout.............................................................. 105

Tabel 4.21 Tabel Kategori .................................................................................. 158

xvii

xvii

Tabel 4.22 Tabel indeks...................................................................................... 158

Tabel 4.23 Tabel berkas...................................................................................... 159

Tabel 4.24 Tabel tbmuser ................................................................................... 159

Tabel 4.25 Tabel tbmaccount.............................................................................. 160

Tabel 4.26 Tabel tbmrole.................................................................................... 160

Tabel 4.27 Tabel refpage .................................................................................... 161

Tabel 4.28 Testing role User .............................................................................. 177

Tabel 4.29 Testing role Admin Ortala ................................................................ 179

Tabel 4.30 Testing role Admin TU Rektorat...................................................... 182

Tabel 4.31 Testing role Super Admin................................................................. 184

Tabel 4.32 Pengujian Penerimaan Sistem.......................................................... 188

xviii

xviii

DAFTAR SIMBOL

(Sholiq:2006:59-77)

Simbol Arti

Actor

Use Case

Association

Extends

Includes

Inheritance

xix

xix

SIMBOL ACTIVITY DIAGRAM

(Sholiq:2006:42:&161)

Simbol Arti

Activity

Initiate Activities

Start of the Process

Termination of the Process

Synchronization Bar

Decision Activity

xx

xx

SIMBOL CLASS DIAGRAM

(Sholiq:2006:103-135)

Simbol Arti

Class Ket :

1. Class name 2. Attributes 3. Behaviors

Association

Agregation

Generalization

xxi

xxi

SIMBOL SEQUENCE DIAGRAM

(Sholiq:2006:94-97)

Simbol Arti

Object

Lifeline

Message

Behaviors (operation)

1

BAB I

PENDAHULUAN

1.1. Latar Belakang

Perkembangan aplikasi web yang semakin pesat sejak munculnya

teknologi internet sangat membantu dalam kemudahan serta kecepatan

pengiriman, penyampaian dan penerimaan informasi. Mulai dari

perusahaan-perusahaan, sekolah-sekolah, perguruan tinggi, dan lembaga

atau organisasi lainnya telah banyak memanfaatkan aplikasi web dalam

kegiatan penjualan, promosi, belajar dan kegiatan lainnya dimana

dibutuhkan pengiriman, penyebaran dan penerimaan informasi sehingga

memberikan kemudahan bagi pengguna (user) yang membutuhkan.

Aplikasi web atau bisa disebut juga dengan perangkat lunak

berbasis web telah berkembang dengan pesat baik dari segi penggunaan,

ukuran, bahasa yang digunakan dan kompleksitasnya. Aplikasi web pada

mulanya hanya berupa situs web yang bersifat statis dan navigated

oriented, serta lebih banyak digunakan sebagai brosur produk atau profil

perusahaan online. Pada saat ini aplikasi web telah banyak yang bersifat

dinamis, interaktif dan task oriented untuk digunakan dalam sistem

informasi, telekomunikasi, perdagangan, perbankan dan lain-lain.

Penggunaan sistem Informasi untuk membantu kinerja organisasi

semakin dibutuhkan. Dengan didukung oleh kecanggihan teknologi

informasi, telah memungkinkan pengembangan sistem informasi yang

2

semakin handal. Informasi merupakan salah satu sumber daya penting

dalam menajemen moderen. Banyak keputusan strategis yang bergantung

kepada informasi.

Repository adalah suatu tempat dimana data disimpan dan

dipelihara. Sebuah Repository juga dapat berupa tempat dimana database

atau file disimpan untuk kemudian didistribusikan dengan menggunakan

jaringan komputer. Repository SK (Surat Keputusan) adalah sebuah

tempat Online untuk mengumpulkan dan menyebarkan suatu data dalam

bentuk digital, yang mana merupakan output dari proses pengajuan atau

usulan pembuatan sebuah SK yang telah terbit atau yang siap untuk

diterbitkan.

UIN Syarif Hidayatullah Jakarta merupakan institusi perguruan

tinggi yang memiliki jumlah pegawai yang cukup besar serta unit kerja

yang cukup banyak. Untuk memudahkan pengolahan kearsipan maka

selain melakukan kegiatan kearsipan secara manual, maka dibutuhkan

suatu aplikasi sistem yang dapat menangani penyimpanan arsip secara

digital, pencarian terhadap suatu arsip yang telah dibuat, dan lain

sebagainya yaitu dengan sebuah sistem yang dinamakan Sistem

Repository SK.

Subbagian Organisasi Tata laksana dan Perundang-undangan UIN

Jakarta mempunyai tugas melakukan administrasi organisasi, tata laksana

dan perundang-undangan sekaligus mengarsipkan berkas-berkas yang

dihasilkan disubbagian tersebut. Berdasarkan hasil observasi dan

3

wawancara penulis dengan Kasubbag Ortala dan staf-stafnya, proses

penyimpanan berkas SK yang sudah disahkan masih dilakukan secara

tradisional yaitu penyimpanan secara fisik pada lemari arsip. Belum

dilakukan penyimpanan secara digital dalam suatu database.

Mengingat pentingnya surat-surat yang diarsipkan tersebut

terutama arsip yang terkait dengan Surat Keputusan (SK) yang akan dan

telah diterbitkan, maka dibutuhkan suatu konsep pengolahan

penyimpanan arsip secara digital di lingkungan UIN Jakarta dalam

bentuk Repository berbasis website agar kelak dapat memudahkan dalam

pencarian kembali, dapat diakses oleh pimpinan dari masing-masing unit

kerja dan pimpinan direktorat pada saat dibutuhkan secara real time serta

mengurangi resiko terjadinya kehilangan file SK yang telah dibuat.

Berdasarkan penjelasan diatas, penulis tertarik untuk melakukan

penelitian dalam rangka skripsi dengan tema “Rancang Bangun Sistem

Repository Surat Keputusan (SK) Dengan Memanfaatkan ZKOSS

Framework Studi Kasus: Subbagian Organisasi Tata Laksana dan

Perundang-undangan Pusat UIN Syarif Hidayatullah Jakarta”.

Harapan dari penelitian ini adalah agar skripsi ini dapat

memberikan solusi sebagai pemecahan masalah pengolahan dan

penyimpanan serta publikasi Surat Keputusan dilingkungan dalam UIN

Jakarta pada Subbagian Ortala UIN Jakarta.

4

1.2. Rumusan Masalah

Berdasarkan latar belakang tersebut, maka penulis merumuskan

masalah yang akan dihadapi dalam penelitian dan pengembangan sistem

sebagai berikut :

1. Bagaimana kegiatan Penyimpanan/Kearsipan dari SK yang telah

diterbitkan ke dalam sebuah database agar dapat diakses kembali

jika sewaktu-waktu dibutuhkan?

2. Bagaimana menjadikan Sistem Repository SK menjadi sebuah

sumber informasi dan diakui legalitas serta keaslian datanya?

3. Bagaimana Sistem Repository SK dapat menampilkan berkas SK

secara utuh?

4. Bagaimana Sistem Repository SK dapat menjadi sebuah media

sentrasilisasi berkas (SK) dilingkungan UIN Jakarta?

1.3. Pembatasan Masalah

Dalam pengembangan Sistem Repository SK ini, penulis membatasi

masalah sebagai berikut :

1. Perancangan database yang akan menampung arsip digital berupa Surat

Keputusan (SK) yang akan dan telah diterbitkan didalam lingkungan UIN

Jakarta.

2. Perancangan dan pembangunan aplikasi berbasis web menggunakan

bahasa pemrograman JAVA dan Zkoss Framework.

5

3. Penelitian dibatasi hanya untuk penyimpanan SK Kelembagaan yang

terdiri dari 4 kategori Surat Keputusan (SK) pada 14 Unit Kerja yang ada

dilingkungan UIN Jakarta.

4. Usulan rancangan sistem tidak membahas sistem keamanan yang

digunakan.

5. Dalam melakukan perancangan aplikasi, penulis menggunakan bahasa

pemodelan UML.

6. Pengguna sistem ini nantinya adalah admin Tata Usaha rektorat, Admin

Ortala, pimpinan yang berwenang pada masing-masing unit kerja/fakultas,

pihak PUSKOM sebagai administrator sistem.

1.4. Tujuan Penelitian

Tujuan yang ingin dicapai penulis dari penelitian ini adalah :

a. Menganalisis sistem yang ada (current system) pada Subbagian Ortala

Pusat UIN Jakarta.

b. Merancang dan membangun Aplikasi Sistem Repository SK yang dapat

menunjang aktivitas pada Subbag Ortala dan lingkungan dalam UIN

Jakarta yang berkaitan dengan penyimpanan surat keputusan (SK)

kedalam aplikasi Repository SK.

c. Tersedianya media publikasi SK secara online yang diterbitkan pada

lingkungan UIN Jakarta.

d. Terjadinya sentralisasi penyimpanan SK yang dapat menjaga keaslian dari

berkas yang disimpan tersebut.

6

e. Memudahkan dalam proses pencarian kembali berkas SK.

f. Menguji Aplikasi Sistem Repository SK dengan metode blackbox testing.

1.5. Manfaat Penelitian

1.5.1. Bagi Pengguna Sistem khususnya Subbagian Organisasi Tata

Laksana dan Perundang-undangan UIN Jakarta.

Manfaat yang dapat dipetik oleh Subbagian Ortala UIN

Jakarta dari penelitian ini antara lain :

a. Tersedianya aplikasi sistem Repository SK yang didukung

dengan database sebagai tempat penyimpanan berkas SK

secara digital yang dapat menampilkan konsep SK secara

utuh.

b. Membantu dalam proses penyimpanan berkas SK secara

digital dengan tetap menjaga keaslian dari SK.

c. Memudahkan dalam pencarian dan publikasi SK yang akan

dan telah diterbitkan.

1.5.2. Bagi Penulis

Banyak sekali menfaat yang bisa penulis petik dalam

penelitian skripsi ini, diantaranya adalah sebagai berikut :

a. Menambah wawasan penulis tentang teknologi informasi,

khususnya dalam membangun sistem informasi berbasis web.

b. Dapat mengimplementasikan ilmu yang didapat di bangku

kuliah.

7

1.5.3. Bagi Akademik

a. Mengetahui kemampuan mahasiswa dalam penguasaan materi

dan penerapan ilmu yang telah didapat di bangku kuliah.

b. Memberikan gambaran tentang kesiapan mahasiswa dalam

menghadapi dunia kerja dari hasil yang diperoleh selama

pembelajaran pada masa kuliah.

1.6. Metodologi Penelitian

Metode penelitian yang digunakan dan diterapkan dalam penulisan

tugas akhir ini meliputi :

1.6.1. Metodologi Pengumpulan Data

Dalam proses penulisan skripsi ini, bentuk metodologi

pelaksanaan yang akan dilakukan antara lain :

a. Studi Lapangan, dalam studi lapangan terbagi menjadi dua

bagian diantaranya:

- Observasi, yakni proses pengambilan data dalam penelitian

dimana penelitian atau pengamat melihat langsung keadaan

permasalahan penelitian yaitu sistem yang berjalan saat ini.

- Wawancara, yakni mengumpulkan data melalui tanya jawab

dan diskusi dengan pihak-pihak bagian kepegawaian.

b. Studi Pustaka, yakni mengumpulkan data melalui buku

maupun artikel yang berhubungan dengan penulisan skripsi

ini.

8

1.6.2. Metodologi Pengembangan Sistem

Pengembangan sistem dalam penelitian ini penulis

menggunkan metode RAD(Rapid Application Development). RAD

adalah suatu pendekatan berorientasi objek terhadap

pengembangan sistem yang mencakup metode pengembangan serta

perangkat-perangkat lunak Model RAD ini terdiri atas tiga tahapan

utama, antara lain: requirements planning(perencanaan syarat-

syarat), RAD design workshop (workshop desain RAD) dan

implementation(implementasi). (Kendall & Kendall, 2003:237)

1.7. Sistematika Penulisan

Untuk mendapatkan gambaran umum secara menyeluruh dari

penulisan skripsi ini, maka dapat dijelaskan mengenai penulisan yang ada

pada sub bab ini. Sistematika penulisan skripsi ini terdiri dari lima bab

yang masing-masing memiliki kaitan yang jelas. Berikut ini adalah

ringkasan dari tiap-tiap bab tersebut :

BAB I PENDAHULUAN

Bab ini menjelaskan mengenai masalah yang melatarbelakangi

penulisan skripsi ini. Selain itu bab ini juga membahas ruang

lingkup, pembahasan masalah, tujuan yang ingin dicapai dan

manfaat yang dapat diperoleh dengan adanya sistem yang baru.

Bab ini juga membahas mengenai metodologi pengembangan

9

sistem yang digunakan serta sitematika penulisan.

BAB II LANDASAN TEORI

Bab ini berisi tentang teori-teori yang digunakan sebagai dasar

dalam pengembangan aplikasi sistem ini.

BAB III METODOLOGI PENELITIAN

Penjelasan mengenai metode pengumpulan data dan metode

pengembangan sistem yang digunakan untuk sistem yang dibuat

pada skripsi ini.

BAB IV ANALISIS DAN PERANCANGAN SISTEM

Bab ini berisi tentang analisis terhadap kebutuhan sistem, serta

implementasi pengembangan secara nyata.

BAB V KESIMPULAN DAN SARAN

Bab ini berisi kesimpulan yang dapat dibuat dari hasil

analisis, pengembangan, serta pengujian sistem yang telah

dilakukan. Selain itu juga terdapat saran-saran yang dapat

digunakan untuk pengembangan sistem lebih lanjut di masa

yang akan datang.

10

BAB II

LANDASAN TEORI

2.1 Konsep Dasar Sistem

Sistem merupakan sekumpulan dari subsistem-subsistem yang saling

terintegrasi untuk mencapai tujuan tertentu. Untuk lebih mendalami suatu

konsep dasar dari sistem terdapat beberapa ahli yang berpendapat mengenai

apa itu sistem, karakteristik sistem dan klasifikasi sistem.

2.1.1. Pengertian Sistem

“Sistem adalah kumpulan dari elemen-elemen yang berinteraksi

untuk mencapai suatu tujuan tertentu” (Jogiyanto, 2001). Sedangkan

menurut (Kadir, 2003). “Sistem adalah sekumpulan elemen yang

saling terkait atau terpadu yang dimaksudkan untuk mencapai suatu

tujuan”.

2.1.2. Karakteristik Sistem

Suatu sistem mempunyai karakteristik atau sifat-sifat tertentu,

(Jogiyanto, 2001), yaitu :

1. Komponen Sistem (components)

Suatu sistem terdiri dari sejumlah komponen atau elemen yang

saling berinteraksi, artinya komponen atau elemen yang saling

bekerja sama dalam bentuk satu kesatuan. Komponen atau elemen

sistem dapat berupa subsistem atau bagian dari sistem. Setiap

subsistem mempunyai sifat-sifat dari sistem. Untuk menjalankan

11

suatu fungsi tertentu dan mempengaruhi proses sistem secara

keseluruhan.

2. Batas Sistem (boundary)

Batas sistem merupakan daerah yang membatasi antara suatu sistem

dengan sistem yang lainnya atau dengan lingkungan luar. Batas

suatu sistem menunjukan lingkup (scope) dari sistem tersebut.

3. Lingkungan Luar Sistem (environments)

Lingkungan luar dari suatu sistem adalah apapun diluar batas dari

sistem yang mempengaruhi operasi dari sistem. Lingkungan luar

sistem dapat bersifat menguntungkan dan juga merugikan.

Lingkungan luar yang menguntungkan merupakan energi dari

sistem dan demikian harus dijaga dan dipelihara. Sedangkan

lingkungan yang merugikan harus ditahan dan dikendalikan, jika

tidak maka akan mengganggu kelangsungan hidup sistem.

4. Penghubung Sistem (interface)

Penghubung sistem merupakan media penghubung antara satu

subsistem dengan subsistem yang lain untuk dapat berinteraksi

membentuk suatu kesatuan.

5. Masukan Sistem (input)

Masukan sistem merupakan energi yang dimasukan ke dalam sistem

yang berupa masukan perawatan (maintenance input) dan keluaran

sinya (signal output). Maintenance input adalah energi yang

12

dimasukan supaya sistem tersebut dapat beroperasi. Signal output

adalah energi yang diproses untuk mendapatkan keluaran.

6. Keluaran Sistem (output)

Keluaran sistem adalah hasil dari energi yang diolah dan

diklasifikasikan menjadi keluaran yang berguna dan sisa

pembuangan.

7. Pengolahan Sistem (process)

Suatu sistem dapat mempunyai suatu bagian pengolahan yang akan

merubah masukan menjadi keluaran yang berguna.

8. Sasaran Sistem (objective) atau tujuan sistem (Goal)

Suatu sistem harus mempunyai sasaran, karena sasaran sangat

menentukan sekali masukan yang dibutuhkan oleh sistem dan

keluaran yang akan dihasilkan sistem. Suatu sistem dikatakan

berhasil apabila mengenai sasaran atau tujuan.

2.1.3. Klasifikasi Sistem

Sistem merupakan suatu bentuk integrasi antara suatu

komponen dengan komponen lain, karena sistem memiliki sasaran

yang berbeda untuk setiap kasus yang terjadi ada dalam sistem

tersebut. Suatu sistem dapat diklasifikasikan kedalam beberapa sudut

pandang, diantaranya adalah sebagai berikut (Ladjmudin, 2005).

a. Sistem Abstrak dan Sistem Fisik

Sistem abstrak (abstract system) adalah sistem yang berupa

pemikiran atau ide-ide yang tampak secara fisik. Misalnya sistem

13

teologi, yaitu sistem yang berupa pemikiran-pemikiran hubungan

antara manusia dengan Tuhan. Sistem fisik (physical system)

merupakan sistem yang ada secara fisik. Misalnya sistem

komputer, sistem akuntansi, sistem produksi dan lain sebagainya.

b. Sistem Alamiah dan Sistem Buatan Manusia

Sistem alamiah (natural system) adalah sistem yang terjadi

karena proses alam yang tidak dibuat oleh manusia (ditentukan

dan tunduk kepada kehendak sang pencipta alam). Misalnya

sistem perputaran bumi, sistem pergantian siang dan malam.

Sistem buatan manusia (human made system) adalah sistem yang

dirancang oleh manusia. Sistem buatan manusia yang melibatkan

interaksi manusia dengan mesin yang disebut dengan human-

machine system.

c. Sistem Tertentu dan Sistem Tak Tentu

Sistem tertentu (deterministic system) beroperasi dengan

tingkah laku yang sudah dapat diprediksi. Interaksi diantara

bagian-bagiannya dapat dideteksi dengan pasti, sehingga keluaran

dari sistem dapat diramalkan. Sistem komputer adalah contoh dari

sistem tertentu yang tingkah lakunya dapat dipastikan berdasarkan

program-program yang dijalankan. Sistem tak tentu (probabilistic

system) adalah sistem yang kondisi masa depannya tidak dapat

diprediksi karena mengandung unsur probabilitas.

14

d. Sistem Tertutup dan Sistem Terbuka

Sistem tertutup (closed system) merupakan sistem yang

tidak berhubungan dan tidak terpengaruh dengan lingkungan

luarnya. Sistem ini bekerja secara otomatis tanpa adanya turut

campur tangan dari pihak diluarnya.

Sistem terbuka (open system) adalah sistem yang

berhubungan dan terpegaruh dengan lingkungan luarnya. Sistem

ini menerima masukan dan menghasilkan keluaran untuk

lingkungan luar atau subsistem yang lainnya. Karena sistem

sifatnya terbuka dan terpengaruh oleh lingkungan luarnya, maka

suatu sistem harus mempunyai suatu sistem pengendalian yang

baik.

2.2. Konsep Dasar Informasi

Untuk lebih mengenal apa itu data dan apa itu informasi, terlebih

dahulu harus mengenal definisi dari data dan informasi itu sendiri.

2.2.1. Data Versus Informasi

Data adalah deskripsi dari sesuatu atau kejadian yang kita

hadapi (the description of things and events that we face). Definisi data

yang lain adalah data merupakan kenyataan yang menggambarkan

suatu kejadian-kejadian dan kesatuan nyata. Kesatuan nyata adalah

berupa suatu objek nyata seperti tempat, benda dan orang yang betul-

betul ada dan terjadi. Untuk pengambilan keputusan bagi manajemen,

15

maka faktor-faktor tersebut harus diolah lebih lanjut untuk menjadi

suatu informasi. (Ladjamudin, 2005).

Informasi adalah data yang telah diproses sehingga lebih

bermakna. (McLeod, 2004:12). Definisi lain menyebutkan bahwa

informasi adalah data yang telah diproses atau disusun kedalam suatu

format lebih berarti untuk seseorang. Informasi dibentuk dari data yang

dengan penuh harapan dapat mempunyai arti bagi penerimanya.

(Whitten, 2004:27).

2.2.2. Siklus Informasi

Data merupakan bentuk yang masih mentah, belum dapat

bercerita banyak, sehingga harus diolah lebih lanjut. Data diolah

melalui suatu model untuk menghasilkan suatu informasi. Data dapat

berbentuk simbol-simbol semacam huruf-huruf atau alphabet, angka-

angka, bentuk-bentuk suara, sinyal-sinyal, gambar-gambar, dan

sebagainya (Jogiyanto, 1999). Jadi, pada intinya adalah bahwa hasil

dari pengolahan data adalah berupa informasi yang sangat diperlukan

oleh penerimanya. Ini dapat dilihat pada gambar 2.1 yang

dikemukakam oleh Ladjmudin, berpendapat bahwa untuk memperoleh

informasi yang bermanfaat bagi penerimanya, perlu untuk dijelaskan

bagaimana siklus yang terjadi atau dibutuhkan dalam menghasilkan

informasi (Ladjmudin, 2005). Siklus informasi atau siklus pengolahan

data adalah sebagai berikut :

16

Gambar 2.1. Siklus Informasi (Ladjamudin, 2005)

2.2.3. Nilai Informasi

Nilai dari informasi ditentukan oleh dua hal, yaitu : manfaat dan

biaya mendapatkannya. Suatu informasi dikatakan bernilai bila

manfaatnya lebih efektif dibandingkan dengan biaya untuk

mendapatkannya. Akan tetapi, perlu diperhatikan bahwa informasi

yang digunakan didalam suatu sistem informasi umumnya digunakan

untuk beberapa kegunaan. Sehingga tidak memungkinkan dan sulit

untuk menghubungkan suatu bagian informasi pada suatu masalah

tertentu dengan biaya untuk memperolehnya, karena sebagian besar

informasi dinikmati tidak hanya oleh satu pihak didalam perusahaan

(Jogiyanto, 2005). Tidak jauh beda dengan pendapat (Ladjamudin,

2005), yang berpendapat bahwa suatu informasi dikatakan bernilai bila

manfaatnya lebih efektif dibandingkan dengan biaya untuk

mendapatkannya dan sebagian informasi tidak dapat tepat ditaksir

keuntungannya dengan suatu nilai uang, tetapi dapat ditaksir nilai

efektivitasnya. Pengukurannya dapat menggunakan analisis cost

effectivennes atau cost benefit.

Masukan (Data)

Proses (Model)

Keluaran (Informasi)

17

2.3. Konsep Dasar Sistem Informasi

Informasi merupakan hal yang sangat penting bagi manajemen dalam

menunjang suatu pengambilan keputusan, maka sistem informasi sangat

diperlukan dalam hal mendapatkan informasi.

2.3.1. Pengertian Sistem Informasi

Menurut (Jogiyanto, 1999) sistem informasi didefinisikan

sebagai suatu sistem didalam suatu organisasi yang merupakan

kombinasi dari orang-orang, fasilitas, teknologi, media prosedur-

prosedur dan pengendalian yang ditujukan untuk mendapatkan jalur

komunikasi penting, memproses tipe transaksi rutin tertentu, memberi

sinyal kepada manajemen dan yang lainnya terhadap kejadian-kejadian

internal dan eksternal yang penting dan menyediakan suatu dasar

informasi untuk pengambilan keputusan yang cerdik (Jogiyanto, 1999).

Sedangkan, Ladjamudin menjelaskan suatu sistem informasi dapat

didefinisikan sebagai berikut (Ladjamudin, 2005).

1. Suatu sistem yang dibuat oleh manusia yang terdiri dari komponen-

komponen dalam organisasi untuk mencapai suatu tujuan yaitu

menyajikan informasi.

2. Sekumpulan prosedur organisasi yang pada saat dilaksanakan akan

memberikan informasi bagi pengambil keputusan dan atau untuk

mengendalikan organisasi.

3. Suatu sistem didalam suatu organisasi yang mempertemukan

kebutuhan pengolahan transaksi, mendukung operasi, bersifat

18

manajerial, dan kegiatan strategi dari suatu organisasi dan

menyediakan pihak luar tertentu dengan laporan-laporan yang

diperlukan.

2.3.2. Komponen Sistem Informasi

Dalam suatu sistem informasi terdapat komponen-komponen

yaitu hardware, software, prosedur, brainware, database, jaringan

komputer dan komunikasi data (Kadir, 2003).

a. Perangkat keras (hardware)

Mencakup piranti-piranti fisik seperti komputer, printer, monitor.

b. Perangkat lunak (software)

Sekumpulan intruksi yang memungkinkan perangkat keras untuk

memproses data.

c. Prosedur

Sekumpulan aturan yang dipakai untuk mewujudkan pemrosesan

data dan pembangkitan keluaran yang dikehendaki.

d. Pengguna (brainware)

Semua pihak yang bertanggung jawab dalam pengembangan sistem

informasi, pemrosesan, dan penggunaan keluaran sistem informasi.

e. Basis data (database)

Sekumpulan tabel, hubungan, dan lain-lain yang berkaitan dengan

penyimpanan data.

f. Jaringan komputer komunikasi data

19

Sistem penghubung yang memungkinkan sumber (resources)

dipakai secara bersama atau diakses oleh sejumlah pemakai.

Menurut (Ladjamudin, 2005) keenam komponen diatas

diklasifikasikan menjadi tiga bagian yaitu sebagai berikut :

1. Hardware (perangkat keras) dan Software (perangkat lunak) yang

berfungsi sebagai mesin.

2. People dan Prosedur merupakan manusia dan tatacara

menggunakan mesin.

3. Data merupakan jembatan penghubung antara manusia dan mesin

agar terjadi suatu proses pengolahan data.

Gambar 2.2. Komponen Sistem Informasi (Ladjamudin, 2005)

2.4. Repository

Repository adalah tempat penyimpanan atau gudang (John M. Echols,

2006). Sebuah repository dapat berupa :

1. Tempat dimana data disimpan.

2. Tempat dimana secara khusus data dalam format digital disimpan.

Hardware (Perangkat

Keras)

Software (Perangkat

Lunak)

People

(Manusia)

Procedures

(Prosedur)

DATA

Mesin Manusia

20

3. Tempat dimana eprint diletakkan.

4. Tempat dimana beberapa database atau file diletakaan untuk

didistibusikan secara jaringan komputer.

5. Tempat dimana sesuatu disimpan yang kemungkinan untuk digunakan

lagi.

Sebuah repository SK adalah sebuah tempat online untuk

mengumpulkan dan menyebarkan berkas SK dalam bentuk digital, yang

mana merupakan output dari institusi khusunya hasil dari sebuah keputusan

pimpinan yang harus diakui bersama.

2.5. Surat

Surat adalah sesuatu yang ditulis, yang tertulis atau tulisan. Sedangkan

keputusan memiliki arti prihal yang berkaitan dengan putusan atau segala

putusan yang telah ditetapkan (sudah dipertimbangkan dan dipikirkan) (Dept.

Pendidikan Nasional, 2008).

Dalam kehidupan sehari-hari terdapat bermacam jenis-jenis surat yang

berdar, baik antar organisasi, antar instansi maupun antar perusahaan. Dalam

hal-hal tertentu jelas ada perbedaan-perbedaan, baik asal surat, sifat surat,

tujuan, cara pembuatan ataupun cara pengirimannya.

Jenis-jenis surat dapat ditinjau dari beberapa segi sebagai mana yang

diuraikan berikut ini. Berdasarkan Sifatnya Surat dapat digolongkan menjadi

5 jenis :

21

a. Surat Pribadi

Adalah surat-surat yang bersifat kekeluargaan, surat-surat yang

berisi masalah keluarga, baik tentang kesehatan, keuangan keluarga dan

sebagainya.

Contoh:

- Surat dari orang tua kepada anaknya.

- Surat persahabatan.

- Surat perkenalan dan sebagainya.

b. Surat Dinas Pribadi

Disebut juga surat setengah resmi adalah surat-surat yang

dikirimkan dari seseorang kepada instansi-instansi, perusahaan-

perusahaan ataupun jawatan-jawatan.

Contoh:

- Surat lamaran kerja.

- Surat permohonan tidak masuk kerja dan sebagainya.

c. Surat Dinas Swasta

Disebut juga surat resmi adalah surat-surat yang dibuat oleh

instansi-instansi swasta, yang dikirimkan untuk para karyawannya

ataupun untuk para relasinya atau langganannya atau instansi-instansi

yang terkait.

Contoh:

22

- Surat undangan rapat untuk para karyawan.

- Surat undangan pertemuan untuk para relasi.

- Surat rapat tahunan para pemegang saham dan sebagainya.

d. Surat Niaga

Adalah surat yang berisi soal-soal perdagangan yang dibuat oleh

perusahaan yang dikirimkan kepada para pelanggan.

Contoh:

- Surat perkenalan barang.

- Surat penawaran barang.

- Surat pesanan barang dan sebagainya.

e. Surat Dinas Pemerintah

Adalah surat-surat yang berisi masalah-masalah administrasi

pemerintahan yang dibuat oleh instansi pemerintah.

Contoh:

- Surat keputusan.

- Surat instruksi.

- dll.

2.6. Konsep Basis Data dan DBMS (Database Management System)

Ada dua pendekatan untuk menyimpan data dalam sistem yang

berdasarkan komputer (Kendal dan Kendall, 2003). Metode yang pertama

adalah menyimpan data dengan file individu, masing-masing khusus untuk

aplikasi tertentu. Pendekatan kedua untuk penyimpanan data dalam sistem

23

berdasarkan komputer meliputi membangun basis data. Basis data

didefinisikan secara formal dan mengontrol penyimpanan data terpusat yang

dimaksud untuk penggunaan dalam banyak aplikasi berbeda.

2.6.1. Definisi Basis Data (Database)

Basis data (database) merupakan kumpulan dari data yang

saling berhubungan satu dengan lainnya, tersimpan di perangkat

keras komputer dan digunakan perangkat lunak untuk

memanipulasinya (Jogiyanto, 1999). Penjelasan lain dikemukakan

bahwa basis data tidak hanya kumpulan file, lebih dari itu, basis data

adalah pusat sumber data yang caranya dipakai oleh banyak pemakai

untuk berbagai aplikasi. Inti dari basis data adalah database

management system (DBMS), yang membolehkan pembuatan,

modifikasi, dan pembaharuan basis data (Kendall dan Kendall,

2003). Sedangkan Hariyanto menjelaskan dalam bukunya Sistem

Manajemen Basis data, basis data adalah kumpulan data (elementer)

yang secara logic berkaitan dalam mempresentasikan fenomena /

fakta secara terstruktur dalam domain tertentu untuk mendukung

aplikasi dalam sistem tertentu (Hariyanto, 2004). Jadi, basis data

merupakan suatu komponen utama sistem informasi karena semua

informasi untuk pengambilan keputusan berasal dari data yang ada

pada basis data.

24

Gambar 2.3 Jenjang dari data (Jogiyanto, 1999)

Sampai dengan membentuk suatu database, data mempunyai

jenjang yang dapat dilihat pada gambar 2.3 (Jogiyanto, 1999)

a. Characters

Characters merupakan bagian data yang terkecil, dapat berupa

karakter numerik, huruf ataupun karakter-karakter khusus (special

Characters) yang membentuk suatu item data atau Field.

b. Field

Field menggambarkan suatu atribut dari record yang

menunjukkan suatu item dari data, seperti misalnya nama, alamat,

dan lain sebagainya. Kumpulan dari Field membentuk suatu

record.

Database

File

Record

Data Item atau Field

Characters

25

1. Nama dari Field (Field name)

Field harus diberi nama unruk membedakan Field yang satu

dengan Field yang lainnya.

2. Representasi dari Field (Field representation)

Representasi dari Field menunjukan tipe dari Field (Field

type) dapat berupa tipe numeric, karakter atau huruf, tanggal,

dan memo. Serta lebar dari Field (Field width) menunjukan

ruang maksimum dari Field yang dapat diisi dengan karakter-

karakter data.

3. Nilai dari Field (Field value)

Nilai dari Field menunjukan isi dari Field untuk masing-

masing record.

c. Record

Record merupakan kumpulan dari Field yang membentuk suatu

record. Record menggambarkan suatu unit data individu tertentu.

Kumpulan dari record membentuk suatu file. Misalnya file

mahasiswa, tiap-tiap record dapat mewakili data tiap-tiap

mahasiswa.

d. File

File terdiri dari record-record yang menggambarkan suatu

kesatuan data yang sejenis. Misalnya file mata kuliah berisi data

tentang semua mata kuliah yang ada.

26

e. Database

Database merupakan kumpulan dari file yang membentuk suatu

database. Tujuan basis data yang efektif termuat di bawah ini

(Kendall dan Kendall, 2003).

1. Memastikan bahwa data dapat dipakai diantara pemakai

untuk berbagai aplikasi.

2. Memelihara data baik keakuratan maupun konsistensi.

3. Memastikan bahwa semua data yang diperlukan untuk

aplikasi sekarang dan yang akan datang akan disediakan

secara cepat.

4. Membolehkan basis data untuk berkembang dan kebutuhan

pemakai untuk berkembang.

5. Membolehkan pemakai untuk mengembangkan pandangan

personalnya tentang data tanpa memperhatikan cara data

disimpan secara fisik.

2.6.2. DBMS (Database Management System)

Database Management System (DBMS atau DMS) adalah

paket perangkat lunak yang kompleks digunakan untuk memanipulasi

database (Jogiyanto, 1999). Lebih detail lagi dijelaskan oleh

Hariyanto bahwa DBMS adalah perangkat lunak ntuk mendefinisikan,

menciptakan, mengelola dan mengendalikan pengaksesan basis data

(Hariyanto, 2004).

27

Semua operasi input dan output yang berhubungan dengan

database harus menggunakan DBMS. Bila pemakai akan mengakses

database, DBMS menyediakan penghubung (interface) antara

pemakai dengan database (Jogiyanto, 1999).

Hubungan pemakai dengan database dapat dilakukan dengan

dua cara :

a. Secara interaktif menggunakan bahasa pertanyaan (query

language).

b. Dengan menggunakan program aplikasi.

2.7. Object Relational Mapping (ORM)

ORM (Object Relational Mapping) adalah sebuah teknik

pemrograman yang menghubungkan perbedaan tipe data pada konsep

pemrograman yang berorientasi obyek dengan konsep RDBMS. Dengan

mengimplementasikan ORM, developer bisa lebih berfikir secara obyek

dibanding dengan tabel dan kolom-kolom yang menjadi ciri dari model

relasional. ORM digunakan untuk menjaga kemurnian pola pikir developer

atas pemrograman berorientasi obyek. (Object Relational Mapping (ORM)

Object Oriented Programming, 2010).

Konsep ORM adalah konsep dimana dilakukan mapping dari tabel

menjadi obyek. Kolom-kolom yang ada pada tabel nantinya akan menjadi

attribute atau variabel-variabel dalam obyek. Satu obyek mewakili satu row.

28

Karena merupakan obyek, untuk mengakses beberapa row sekaligus, dapat

disamakan dengan mengakses array dari obyek.

2.7.1. Alasan Memilh ORM

Beberapa alasan mengapa penulis memilih konsep ORM

sebagai konsep dalam memodelkan basis data. Yang pertama karena,

ORM secara otomatis object-to-table dan table-to object conversion,

yang menyederhanakan pengembangan aplikasi. Perkembangan

pasar kini lebih disederhanakan menuju ke kecepatan waktu dan

mengurangi biaya pengembangan dan pemeliharaan. Selanjutnya,

ORM membutuhkan sedikit kode dibandingkan dengan

menggunakan perintah SQL. ORM menyediakan caching transparan

obyek pada klien dengan demikian meningkatkan kinerja sistem.

Sebuah ORM yang baik adalah solusi yang sangat optimal yang akan

membuat aplikasi lebih cepat dan lebih mudah.

2.7.2. Keunggulan ORM

ORM memiliki kemampuan untuk menciptakan

obyekdatabase virtual, yaitu suatu model database yang

direpresentasikan kedalam sebuah obyek pada bahasa pemrograman

OOP. Berikut ini adalah beberapa kelebihan yang dimiliki ORM,

antara lain:

1. Mempercepat pengembangan program. Contohnya, mengurangi

perulangan kode query, memudahkan pemakaian karena tabel-

tabel ter-representasikan dalam bentuk obyek.

29

2. Membuat akses data menjadi lebih abstrak dan portable. Hal ini

dikarenakan ORM menanganigenerate (pembangkitan) syntax

SQL berdasarkan vendor database-nya (contoh MySQL,

PostgreSQL, Oracle, DbDerby, dll).

3. Mendukung enkapsulasi business rule pada lapisan Data Access.

4. Dapat melakukan generateboilerplate code (unit kode yang

reusable) untuk fungsi dasar CRUD (create, retrieve, update,

delete).

2.8. SQL (Structured Query Language)

SQL (dibaca “es-que-el” atau “sequel”) singkatan dari Structured

Query Language. SQL adalah bahasa yang digunakan untuk berkomunikasi

dengan database. Menurut ANSI (American National Standards Institute),

bahasa ini merupakan standar untuk relational database management system

(RDBMS) (Sidik, 2004). Menurut (Hariyanto,2004) SQL adalah bahasa yang

menghubungkan fitur-fitur bahasa query formal aljabar relasional dan bahasa

query formal kalkulus relasional. SQL tidak hanya bahasa untuk query

terhadap basis data. SQL juga berisi fasilitas untuk pendefinisian struktur

data, modifikasi struktur data dan data di basis data, serta juga digunakan

untuk menspesifikasi konstrain-konstrain integritas dan keamanan

(Hariyanto, 2004).

Beberapa software RDBMS dapat menggunakan SQL, seperti:

Oracle. Sybase, Microsoft SLQ Server, Microsoft Access, Ingres, MySQL,

30

PostgreSQL. Setiap software database mempunyai bahasa perintah/sintaks

yang berbeda, namun pada prinsipnya mempunyai arti dan fungsi yang sama.

Perintah-perintah tersebut antara lain “Select”, “Insert”, “Update”, “Create”,

dan “Drop”, yang dapat digunakan untuk mengerjakan hampir semua

kebutuhan untuk memanipulasi sebuah database.

2.9. PostgreSQL

PostgreSQL merupakan sebuah Objek Relasional Data Base

Management System (ORDBMS) yang dikembangkan oleh Brekely

Computer Science Departement. Sistem yang ditawarkan PostgreSQL

diharapkan sanggup dan dapat mencukupi untuk kebutuhan proses aplikasi

data masa depan. PostgreSQL juga menawarkan tambahan-tambahan yang

cukup signifikan yaitu class, inheritance, type, dan function. Tambahan

keistimewaan lain yang tidak dimiliki database management system yang lain

berupa constraint, triggers, rule, dan transaction integrity, dengan adanya

feature (keistimewaan) tersebut maka para pemakai dapat dengan mudah

mengimplementasikan dan menyampaikan sistem ini. Sejak tahun 1996

PostgreSQL mengalami kemajuan yang sangat berarti, berbagai keistimewaan

dari PostgreSQL sanggup membuat database ini melebihi database lain dari

berbagai sudut pandang.

Pada awal pembuatannya di University of California Berkeley (1977-

1985) PostgreSQL masih mempunyai banyak kekurangan bila dibandingkan

dengan database lain, namun seiring dengan berjalannya waktu tepatnya pada

31

tahun 1996 PostgreSQL berubah menjadi sebuah database yang menawarkan

standar melebihi standar ANSI-SQL92 dan sanggup memenuhi permintaan

dunia open source akan server database SQL. Standar ANSI-SQL92

merupakan standar yang ditetapkan untuk sebuah database bersekala besar

seperti Oracle, Interbase, DB2 dan yang lainnya.

PostgreSQL adalah object-relational database management system

yang datang begitu banyak fitur, diantaranya multivision concurency control

(MVCC), mendukung hampir semua aturan SQL dan memiliki banyak

dukungan bahasa pemrograman lain seperti C/ C++, TCL, Java, Perl dan

Python. Dengan berbagai fitur tersebut, layaknya PostgreSQL mengklaim

dirinya sebagai most advanced database system. Proyek open source yang

hebat umumnya relatif sulit digunakan. Begitu pun dengan PostgreSQL.

Dibandingkan dengan MySQL, PostgreSQL relatif lebih sulit digunakan

karena kompleksitasnya yang begitu besar. Namu, bagi pengguna yang lebih

peduli untuk merancang database yang bagus dan hanya sekedar

menggunakannya, maka PostgreSQL tetap layak digunakan dan dapat

dipelajari dalam waktu yang singkat, dengan catatan pengguna tersebut telah

memahami konsep database dan SQL secara umum.

2.10. Web

Pada tahun 1991, Tim Berners-Lee mengembangkan visi untuk

Network Information Project pada le Centre Europeen de Recherche

Nucleaire (CERN) di Swiss. Misinya adalah untuk menciptakan sistem

32

informasi global yang mudah, namun kuat berdasarkan pada hiperteks. Dua

bagian utama yang muncul dari proyek ini adalah HyperText Markup

Language (HTML) dan HyperText Transfer Protocol (HTTP).

HTML adalah bahasa markup untuk menyebarkan informasi pada

Web. Ketika merancang HTML, ide ini diambil dari Standard Generalized

Markup Language (SGML). SGML adalah cara yang terstandarisasi dari

pengorganisasian dan informasi yang terstruktur di dalam dokumen atau

sekumpulan dokumen. Walaupun HTML tidak dengan mudah dapat

dipahami kebanyakakn orang, ketika diterbitkan penggunanya menjadi jelas.

HTTP adalah protokol komunikasi stateless yang berbasiskan pada TCP

yang awalnya digunakan untuk mengambil kembali file-file HTML dari

server Web ketika dirancang pada tahun 1991.(Simarmata, 2010)

HTML dan HTTP telah dikembangkan lebih lanjut sejak keduanya

pertama kali diusulkan. World Wide Web Consortion (W3C) pada awal

Oktober 1994 dan temuan Tim Berners-Lee telah menyatu dan memimpin

evolusi teknis dari Web. Sekarang ini, W3C mempunyai lebih dari 500

anggota organisasi. Microsoft, IBM dan Ericsson adalah beberapa

diantaranya yang menjadi anggota W3C.

2.10.1. Arsitektur Web Tradisional

Ada dua komponen dasar di dalam arsitektur Web, yaitu

browser Web dan server Web. Browser Web menawarkan

antarmuka grafis untuk pengguna dan bertanggung jawab untuk

komunikasi dengan server Web. Protokol komunikai antara browser

33

dan server Web mengikuti protokol HTTP yang distandarisasi.

(Lindskog, 2003)

Gambar 2.4 Interaksi antara pengguna dan server Web (Lindskog, 2003)

1. Pengguna meminta suatu layanan dengan mengklik tautan (link)

atau dengan mengetikkan sebuah perintah melalui keyboard.

Browser Web menangkap perintah tersebut dan menerjemahkannya

ke dalam permintaan HTTP.

2. Browser kemudian meneruskan permintaan yang baru saja

diciptakan kepada server Web dari penyedia konten. Ketika server

menerima sebuah permintaan, permintaan tersebut akan diproses.

3. Ketika pemrosesan dilakukan, server Web kemudian mengirimkan

kembali respon tersebut ke browser.

4. Ketika browser menerima respon tersebut, browser

menerjemahkannya ke dalam bentuk yang dapat dibaca oleh

manusia.

Antar muka antara pengguna dan browser adalah bahasa

HTML yang terstandarisasi. Sedangkan komunikasi antara browser

dan server menggunakan protokol HTTP. Sebagai catatan, Gambar

34

2.4 hanya mengilustrasikan bentuk komunikasi yang paling sederhana

antara pengguna dan server Web.

2.10.2. Aplikasi Web

Aplikasi Web adalah sebuah sistem informasi yang

mendukung interaksi pengguna melalui antarmuka berbasis Web.

Fitur-fitur aplikasi Web biasanya berupa data persistence,

mendukung transaksi dan komposisi halaman Web dinamis yang

dapat dipertimbangkan sebagai hibridisasi, antar hipermedia dan

sistem informasi. (Simarmata, 2010)

Aplikasi Web adalah bagian dari client-side yang dapat

dijalankan oleh browser Web. Client-side mempunyai tanggung

jawab untuk pengeksekusian proses bisnis. Interaksi Web dibagi

kedalam tiga langkah, yaitu permintaan, pemrosesan dan jawaban.

1. Permintaan

Penggunaan mengirimkan permintaan ke server Web, biasanya

via halaman Web yang ditampilkan pada browser Web.

2. Pemrosesan

Server Web menerima permintaan yang dikirimkan oleh

pengguna, kemudian memproses permintaan tersebut.

3. Jawaban

Browser menampilkan hasil dari permintaan pada jendela

browser.

35

Halaman Web bisa terdiri dari beberapa jenis informasi grafis

(tekstual dan multimedia). Kebanyakan komponen grafis dihasilkan

dengan perkakas (tools) khusus, menggunakan manipulasi langsung

dan editor WYSIWIG.

Halaman Web juga dapat dibuat dengan menggunakan

berbagai program agar dapat menampilkan suatu informasi di dalam

browser (misalnya, Java atau PHP). Pembangunan aplikasi Web

membutuhkan beberapa kualifikasi yang berbeda. Biasanya, para

developer dalam pembangunan Web akan memegang peranan

berikut:

1. Pemasaran, untuk menetapkan target pengunjung Web dan

konten untuk diserahkan.

2. Perancangan grafis, untuk menetapkan tampilan visual

(meliputi tata letak halaman, huruf, warna, gambar dan film).

3. Integrator HTML, untuk mengembangkan halaman HTML.

4. Pemrogram, untuk menulis program (didalam Java, PHP atau

bahasa pemrograman lainnya, yang dapat dikombinasikan

dengan HTML).

2.11. Unified Modeling Language (UML)

UML (Unified Modeling Language) pertama kali dikenalkan pada

tahun 1990-an ketika Grady Booch dan Ivan Jacobson dan James

Rumbaugh mulai mengadopsi ide-ide serta kemampuan-kemampuan

36

tambahan dari masing-masing metodenya dan berusaha membuat

metodologi terpadu yang kemudian dinamakan UML (Unified Modeling

Language). UML merupakan metode pengembangan perangkat lunak

(sistem informasi) dengan metode grafis yang relatif mudah dipahami.

(Nugroho, 2005:20)

Menurut Fowler, UML adalah keluarga notasi grafis yang didukung

oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem

perangkat lunak, khususnya sistem yang dibangun menggunakan

pemrograman berorientasi objek (OO).

UML merupakan standar yang relatif terbuka yang dikontrol oleh

Object Management Group (OMG), sebuah konsorsium terbuka yang

terdiridari banyak perusahaan. OMG dibentuk untuk membuat standar-

standar yang mendukung interoperabilitas, khususnya interoperabilitas

sistem berorientasi objek.

UML menyediakan beberapa diagram visual yang menunjukan

berbagai aspek dalam sistem. Beberapa diagram yang disediakan pada UML

standard version 2.0 OMG antara lain (Martin Fowler, 2004)

1. Use case diagram

2. Activity diagram

3. Sequence diagram

4. Class diagram

5. Statechart diagram

37

Dengan menggunakan UML maka dapat membuat model untuk

semua jenis aplikasi piranti lunak, selain itu UML memudahkan user untuk

melihat gambaran model konseptual piranti lunak dari suatu bahasa

pemrograman yang tekstual sehingga dapat dimengerti oleh user non-

programmer. Selain itu UML lebih cocok untuk penulisan piranti lunak

berorientasi objek karena pada konsep dasarnya UML menggunakan class

dan operation.

2.11.1. Use Case Diagram

Use case atau use case diagram adalah abstraksi dari interaksi

antar sistem dan aktor. Diagram use case menunjukan 3 aspek dari

sistem yaitu aktor, use case dan sistem/sub sistem boundary. Aktor

mewakili peran orang, sistem yang lain atau alat ketika

berkomunikasi dengan use case. Gambar 2.6 mengilustrasikan aktor,

use case dan boundary.

Gambar 2.5 Contoh Use Case Diagram (Sholiq, 2006:8)

38

2.11.2. Activity Diagram

Activity diagram adalah teknik untuk mendeskripsikan

logika prosedural, proses bisnis dan aliran kerja dalam banyak

kasus. Activity diagram mempunyai peran seperti halnya flowchart,

akan tetapi perbedaannya dengan flowchart adalah diagram bisa

mendukung perilaku pararel sedangkan flowchart tidak

bisa.(Munawar, 2005).

Gambar 2.6 Contoh Activity Diagram (Sholiq, 2006:9)

2.11.3. Sequence Diagram

Sequence diagram atau Diagram Sikuensial digunakan

untuk menggambarkan perilaku pada sebuah secenario. Diagram

ini menunjukan sejumlah contoh objek dan message (pesan) yang

diletakan diantara objek-objek ini di dalam use case. Komponen

utama sequence diagram terdiri atas objek yang dituliskan dengan

kotak segiempat bernama. Message diwakili oleh garis dengan

tanda panah dan waktu yang ditunjukan dengan progres vertical.

Contoh sequence diagram :

39

Gambar 2.7 Contoh Sequence Diagram (Sholiq, 2006:10)

2.11.4. Class Diagram

Class Diagram atau Diagram Kelas menggambarkan

struktur dan deskripsi class, package dan objek beserta interaksi

antar kelas dalam sistem. Class memiliki tiga area pokok :

1. Nama (dan stereotype)

2. Atribut

3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :

Private, tidak dapat dipanggil dari luar class yang

bersangkutan.

40

Protected, hanya dapat dipanggil oleh class yang

bersangkutan dan anak-anak yang mewarisinya

Public, dapat dipanggil oleh siapa saja.

Adapun hubungan antar Class yaitu :

1. Asosiasi, yaitu hubungan statis antar class. Umumnya

menggambarkan class yang memiliki atribut berupa class

lain, atau class yang harus mengetahui eksistensi class lain.

Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu relasi sebuah objek terhadap objek yang

lainnya dimana merupakan bagian dari objek tersebut.

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat

diturunkan dari class lain dan mewarisi semua atribut dan

metoda class asalnya dan menambahkan fungsionalitas baru,

sehingga ia disebut anak dari class yang diwarisinya.

Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di

passing dari satu class kepada class lain. Hubungan dinamis

dapat digambarkan dengan menggunakan sequence diagram

yang akan dijelaskan kemudian.

Contoh class diagram :

41

Gambar 2.8 Contoh Class Diagram (Sholiq, 2006:13)

2.11.5. Statechart Diagram

Statechart diagram menyediakan sebuah cara untuk

memodelkan bermacam-macam keadaan yang mungkin dialami

oleh sebuah objek. Diagram statechart digunakan untuk

memodelkan tingkah laku dinamik sistem.

Gambar 2.9 Contoh Statechart Diagram (Sholiq, 2006:15)

2.12. Java

Java adalah bahasa pemrograman yang dapat dijalankan di berbagai

komputer termasuk telepon genggam. Bahasa ini awalnya dibuat oleh James

42

Gosling saat masih bergabung di Sun Microsystems yang saat ini

merupakan bagian dari Oracle dan dirilis tahun 1995. Bahasa ini banyak

mengadopsi sintaksis yang terdapat pada C dan C++ namun dengan

sintaksis model obyek yang lebih sederhana serta dukungan rutin-rutin atas

bawah yang minimal. Aplikasi-aplikasi berbasis java umumnya dikompilasi

kedalam p-code (bytecode) dan dapat dijalankan pada berbagai Mesin

Virtual Java (JVM). Java merupakan bahasa pemrograman yang bersifat

umum/non-spesifik (general purpose) dan secara khusus didisain untuk

memanfaatkan dependensi implementasi seminimal mungkin. Karena

fungsionalitasnya yang memungkinkan aplikasi Java mampu berjalan di

beberapa platform sistem operasi yang berbeda, Java dikenal pula dengan

slogannya WORA write ones run anywhere "Tulis sekali, jalankan di mana

pun". Saat ini Java merupakan bahasa pemrograman yang paling populer

digunakan dan secara luas dimanfaatkan dalam pengembangan berbagai

jenis perangkat lunak aplikasi ataupun aplikasi berbasis web.

2.12.1. Kelebihan Java

Multiplatform. Kelebihan utama dari Java ialah dapat

dijalankan dibeberapa platform/ sistem operasi komputer.

Dengan kelebihan tersebut, pemrogram cukup menulis sebuah

program Java dan dikompilasi (diubah, dari bahasa yang

dimengerti manusia menjadi bahasa mesin/ bytecode) sekali lalu

hasilnya dapat dijalankan di atas beberapa platform tanpa

perubahan. Kelebihan ini memungkinkan sebuah program

43

berbasis Java dikerjakan diatas sistem operasi Linux tetapi

dijalankan dengan baik diatas Microsoft Windows. Platform

yang didukung sampai saat ini adalah Microsoft Windows,

Linux, Mac OS dan Sun Solaris. Penyebanya adalah setiap

sistem operasi menggunakan programnya sendiri-sendiri (yang

dapat diunduh dari situs Java) untuk meninterpretasikan

bytecode tersebut.

OOP (Object Oriented Programming - Pemrogram

Berorientasi Objek) yang artinya semua aspek yang terdapat di

Java adalah Object. Java merupakan salah satu bahasa

pemrograman yang murni berbasis obyek. Semua tipe data

diturunkan dari kelas dasar yang disebut object. Hal ini sangat

memudahkan pemrogram untuk melakukan desain, membuat,

mengembangkan dan mengalokasi kesalahan sebuah program

dengan basis Java secara cepat, tepat, mudah dan terorganisir.

Kelebihan ini menjadikan Java sebagai salah satu bahasa

pemograman termudah, bahkan untuk fungsi-fungsi yang

advance seperti komunikasi antara komputer sekalipun.

Kepustakaan Kelas Yang Lengkap, Java terkenal dengan

kelengkapan library/ kepustakaan (kumpulan program program

yang disertakan dalam pemrograman Java) yang sangat

memudahkan dalam penggunaan oleh para pemrogram untuk

membangun aplikasinya. Kelengkapan perpustakaan ini

44

ditambah dengan keberadaan komunitas Java yang besar yang

terus menerus membuat berbagai kepustakaan baru untuk

melingkupi seluruh kebutuhan pembangunan aplikasi.

2.12.2. Kekurangan Java

Tulis sekali, jalankan di mana saja - Masih ada beberapa hal

yang tidak kompatibel antara platform satu dengan yang lain.

Untuk J2SE, misalnya SWT-AWT bridge yang sampai sekarang

tidak berfungsi pada Mac OS X.

Penggunaan memori yang banyak. Penggunaan memori untuk

program berbasis Java jauh lebih besar daripada bahasa tingkat

tinggi generasi sebelumnya seperti C/C++ dan Pascal (lebih

spesifik lagi, Delphi dan Object Pascal). Biasanya ini bukan

merupakan masalah bagi pihak yang menggunakan teknologi

terbaru (karena trend memori terpasang makin murah), tetapi

menjadi masalah bagi mereka yang masih harus berkutat dengan

mesin komputer berumur lebih dari 4 tahun.

2.13. Framework

Framework memiliki arti kerangka kerja, dalam pemrograman

framework dapat diartikan sebagai koleksi atau kumpulan potongan-

potongan program yang disusun atau diorganisasikan sedemikian rupa,

sehingga dapat digunakan untuk membantu membuat aplikasi utuh tanpa

harus membuat semua kodenya dari awal.(Basuki, 2010:3).

45

Berikut adalah beberapa jenis framework berbasis Java yang saat ini

masih terus dikembangkan:

1. Hibernate

Hibernate is an open source ORM service implementation. Hibernate is

an ambitious project that aims to be a complete solution to the problem

of managing persistent data in Java. It mediates the application’s

interaction with a relational database, leaving the developer free to

concentrate on the business problem at hand. Hibernate is a

nonintrusive solution. (Bauer & King, 2007)

Dari pengertian di atas dapat disimpulkan, bahwa yang

dimaksud dengan Hibernate ORM adalah sebuah aplikasi yang

mendefinisikan kelas-kelas persistan yang dipetakan (mapping) ke

dalam tabel-tabel tertentu yang ada disistem basis data yang mendasari

aplikasi yang berkaitan.

2. Sruts Framework

Struts adalah web development framework yang berada di

bawah payung Apache Software Foundation. Struts menggunakan pola

kerja Model-View-Controller (MVC) dengan memanfaatkan Java Bean

(Model), Servlet (Controller) dan JSP (View).

46

Gambar 2.10 Struts Framework Bekerja Dalam Aplikasi Web (Arianto, 2008)

Pada saat web container mendeploy aplikasi, Action Servlet akan

membaca file struts-config.xml yang berisi semua konfigurasi yang

diperlukan untuk menjalankan sistem ini. Ketika ada request dari browser,

langkah-langkah berikut akan dijalankan:

a. Request data akan secara otomatis dibungkus ke dalam sebuah obyek

Action Form.

b. Action Servlet akan mencari controller (Action class) yang sesuai

dengan path yang di-request oleh browser.

c. Action class memiliki satu method utama dengan nama execute, yang

akan dijalankan untuk melayani request. Semua pemrosesan yang

dibutuhkan seperti akses database, perhitungan dan lain lain

dijalankan di dalam method ini. Disini objek model dimasukkan

kedalam variable HTTP request atau HTTP session, yang selanjutnya

akan dipanggil dari halaman JSP.

47

d. Setelah pemrosesan selesai, method execute tersebut akan

mengembalikan return value yang akan menunjukkan Status dari

processing.

e. Selanjutnya, status dari Action class tersebut akan digunakan untuk

menentukan halaman JSP mana yang akan ditampilkan.

f. JSP dievaluasi, obyek model di-render ke dalam halaman HTML dan

respon dikirimkan ke browser.

2.14. ZK Framework

ZK is an event-driven, component-based framework to enable rich

user interfaces for web applications. ZK includes an Ajax-based event

driven engine, a rich set of XML User Interface Language (XUL) and

XHTML components, and a markup language called ZK User Interface

Markup Language (ZUML). (Chen & Cheng, 2007)

Dari kutipan di atas, dapat diketahui bahwa ZK adalah framework

berbasis komponen (componen-based) yang menyediakan tampilan antar

muka (interfaces) yang kaya, dinamis dan interaktif bagi pengembangan

web aplikasi. ZK menyertakan sebuah engineevent-driven berbasis AJAX,

yaitu sekumpulan komponen-komponen beraneka ragam (rich) yang terdiri

dari XML User Interface Language (XUL), XHTML dan ZK User Interface

Markup Language disingkat ZUML (markup language milik ZK).

Engineevent-driven sendiri merupakan sebuah engine yang dapat

memungkinkan untuk melakukan model pemrograman desktop ke model

48

pemrograman web programming. Maksudnya, konsep-konsep pemrograman

pada aplikasi desktop yang dilakukan dengan cepat dan mudah atau istilah

tren-nya drag and drop, dapat dilakukan pada lingkungan web. Para

programmer dapat menampilkan aplikasinya dalam fitur komponen rich

XUL dan XHMTL.

2.14.1. Alasan Memilih Teknologi Zkoss

Ada beberapa alasan mengapa penulis memilih teknologi ZK

sebagai teknologi pemrograman untuk penelitian ini. Pertama, ZK

merupakan framework Ajax + Mobile enterprise yang terkemuka

dan merupakan cara termudah dalam membangun aplikasi web

modern berbasis Java yang hebat. (Chen & Cheng, 2007)

Selanjutnya, berikut alasan mengapa ZK dikatakan sebagai

framework enterprise yang terkemuka:

1. Enterprise. Trusted. Established.

ZK telah dipercaya dan diakui oleh berbagai industri sebagai

pilihan framework yang unggul. Hal ini dapat dilihat dari

sudah lebih dari 1.500.000 kali, ZK di-download dan

diberdayakan oleh berbagai macam perusahaan dan institusi

baik industri kecil dan maupun besar. (Potix Corporation,

2011)

2. Transparan Ajax with Java

ZK menyediakan bagi para pengembang suatu fasilitas yang

sederhana dan transparan dari penggunaan Rich Internet

49

Application (RIA) menggunakan Java. Model event-driven

merefleksikan keahlianpemrograman desktop tanpa

pengembang tersebut harus terfokus dengan pemrograman

Java Script, isu-isu penggunaan browser yang berbeda,

komunikasi Ajax yang terkesan kompleks dan faktor-faktor

lain yang dapat menyia-nyiakan waktu serta biaya dalam

pengembangan Aplikasi Web pada level enterprise.

3. Rich Modular UI

ZK menyediakan lebih dari 200 komponen yang unggul yang

dapat menyebarkan fungsi polimorfisme (plymorphic). Para

pengguna dapat dengan mudah melakukan penyusunan

komponen-komponen program seperti halnya permainan

LEGO yaitu dengan membangun blok-blok yg berkelanjutan

dalam membuat disain UI. ZK menyediakan dua metodologi

untuk mengimplementasikan aplikasi UI yaitu dengan

menggunakan kode Java atau XML markup.

Maka, berdasarkan ketiga alasan di ataslah, maka penulis

memilih framework ZK sebagai framework dalam mendukung

pembangunan sistem repository SK.

2.14.2. Karakteristik Utama ZK

ZK memiliki tiga karakteristik utama yang terdapat pada

dirinya. Karakteristik tersebut secara tidak langsung menunjukkan

keunggulan ZK dibanding framework yang mengatur layer view

50

yang lain. Karakteristik yang pertama menjelaskan tentang fokus

ZK dalam tier application. ZK dibangun memang benar-benar untuk

memperkaya tingkatan view dari konsep MVC (model view control).

Karakteristik kedua, menjelaskan tentang bagaimana ZK

dapat menjadi solusi dari permasalahan komunikasi antara

komponen AJAX dengan Server. ZK menampilkan teknologi

framework berbasis komponen yang mudah untuk dijalankan pada

Server apapun.

Dan karakteristik yang ketiga, menjelaskan tentang

bagaimana peranan ZK sebagai framework yang dapat membawa

konsep pemrograman desktop kepada model pemrograman web.

1. A Presentation Layer (Layer Presentasi)

ZK memang dirancang seringan mungkin dan hanya

berfokus pada layer presentation. Lebih jauh, ZK tidak

bergantung pada teknologi back-end dibelakangnya, atau semua

aplikasi middleware yang mungkin banyak disukai seperti Java

Database Connectivity (JDBC), Hibernate, Java Mail,

Enterprise Java Beans (EJBs) dan Java Message Service (JMS).

Pekerjaan middleware tersebut dapat dikerjakan secara tepat

oleh ZK.

2. A Server-Centric Event-Driven Framework (Framework Dengan

Server Terpusat)

51

Diketahui, bahwa sebagian besar framework berbasis

AJAX menyebabkan peran sebuah server menjadi pasif. Hal ini

dikarenakan sebuah server hanya bertanggung jawab sebagai

penyedia respon ketika ada request datang dari sisi klien.

Komunikasi yang terbangun antar komponen-komponennya pun

cukup kompleks dan membutuhkan banyak kode JavaScript,

belum lagi masalah ketidaksesuaian antara JavaScript dan

browser.

Sebaliknya, ZK menjadi solusi dalam menangani

masalah tersebut. Semua komponen ZK dibuat pada sisi Server,

hal ini mengakibatkan komunikasi yang terbangun antar

komponen lebih mudah karena komponen-komponen itu dapat

diakses dengan segera pada Server. Selain itu, cara komunikasi

antar komponen yang satu dengan lainnya juga dilakukan

dengan event-driven. Artinya, interaksi dapat digerakkan oleh

aktifitas user pada sisi klien atau dengan lemparan event dari

komponen lain. Sederhananya, ZK mencerminkan

kesederhanaan untuk membuat aplikasi desktop dalam

pengembangan aplikasi web dan komunikasi yang lebih

interaktif serta responsif bagi para pengguna.

3. A Component-Based GUI Toolkit

ZK merupakan toolkit GUI (graphical user interface)

berbasis komponen. ZK menyediakan lebih dari 70 komponen

52

berbasis XUL dan 80 XHTML dan keduanya menyediakan

ZUML markup language untuk desain antarmuka. Pemrogram

membuat program dengan memanipulasi event striggered

dengan aktivias penggunanya secara langsung.

2.15. Perbandingan Framework ZK dengan Struts

Setelah penulis memberikan alasan mengapa dipilihnya ZK sebagai

framework pembangung sistem ini, maka kemudian penulis juga ingin

membandingkan ZK dengan framework sejenis lainnya. Tujuan

perbandingan tersebut adalah untuk lebih menyakinkan bahwa ZK

memberikan kontribusi yang lebih untuk mendukung pembangunan aplikasi

web enterprise dewasa ini.

Adapun framework sejenis yang ingin penulis bandingkan adalah

framework Struts dari Apache Software Foundation. Seperti yang telah

dijelaskan sebelumnya tentang Framework Strut, Struts menggunakan pola

kerja Model-View-Controller (MVC) dengan memanfaatkan Java Bean

(Model), Servlet (Controller) dan JSP (View). Yang perlu digarisbawahi

disini adalah pada bagian controller dan view, Struts menggunakan Servlet

dan Java Server Page (JSP). Sedangkan pada ZK, bagian controller

menggunakan Java dan view menggunakan komponen ZK.

Selain itu, pada JSP tidak mendukung konsep RIA yang dapat

membuat aplikasi menjadi kaya dan memiliki UI serta interaksi yang cantik

dengan pengguna. Jadi apabila disimpulkan, Struts masih memiliki

53

kekurangan untuk mendukung aplikasi web enterprise yang saat ini sedang

hangat, karena dari sisi visual Struts tidak mendukung komponen RIA.

2.16. Pengujian Black box

Pengujian black-box berfokus pada persyaratan fungsional perangkat

lunak. Dengan mengetahui fungsi yang ditentukan dimana produk dirancang

untuk melakukannya, pengujian dapat dilakukan untuk memperlihatkan

bahwa masing-masing fungsi beroperasi sepenuhnya, pada waktu yang sama

mencari kesalahan pada setiap fungsi. Pengujian black-box berkaitan dengan

pengujian yang dilakukan pada interface perangkat lunak. Pengujian black-

box digunakan untuk memperlihatkan bahwa fungsi-fungsi perangakt lunak

adalah operasional yang memiliki arti bahwa input diterima dengan baik dan

output dihasilkan dengan tepat dan integritas informasi external (seperti file

data) dipelihara. Pengujian black-box menguji beberapa aspek dasar suatu

sistem dengan sedikit memperhatikan struktur logika internal perangkat

lunak tersebut. Dengan demikian, pengujian black-box memungkinkan

perekayasa perangkat lunak mendapatkan serangkaian kondisi input yang

sepenuhnya menggunakan semua persyaratan fungsional untuk suatu

program.

Pengujian black-box berusaha menemukan kesalahan dalam kategori

sebagai berikut:

1. Fungsi-fungsi yang tidak benar atau hilang.

2. Kesalahan interface.

54

3. Kesalahan dalam struktur data atau akses database ekternal.

4. Kesalahan kinerja.

5. Inisialisasi dan kesalahan terminasi.

Pengujian black-box cenderung diaplikasikan selama tahap akhir

pengujian. (Roger S. Pressman,2002).

2.17. Studi Literatur Sejenis

Literatur yang digunakan didalam penulisan skripsi ini adalah

literatur hasil penulisan karya ilmiah yang bertujuan untuk menekankan

kelebihan dan kekurangan yang dilihat dari sisi sistem yang telah dirancang

sebagai sumber referensi dan bahan acuan terhadap sistem yang akan dibuat.

Dari berbagai referensi, terdapat studi literatur yakni sebagai berikut :

Alianto (2011), mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Analisa dan Perancangan Mobile Repository

Network System di BPPT”. Penulis membangun sebuah sistem dengan

menggunakan metode penyimpanan sementara yang praktis sehingga dapat

mempermudah user dalam mengakses dan mengorganisasi data ketika rapat.

Aplikasi dibangun berbasis web, menggunakan bahasa pemrograman PHP.

Hasil penelitiannya yakni dapat mempercepat proses download data dalam

rapat dan memudahkan user dalam mengorganisir data.

Benny (2009) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Pembangunan Knowledge Repository System

Untuk Mengelola dan Mengoptimalkan Knowledge pada PT. Ismaya

55

Group”. Tujuan pembuatan aplikasi adalah sebagai sarana pendukung

penangkapan knowledge dan sharing knowledge antar karyawan pada outlet

Blowfish subdivisi Operasional. Aplikasi dibangun menggunakan bahasa

pemrograman PHP. Kesimpulan yang dapat diambil adalah dengan adanya

knowledge repository system pada outlet Blowfish subdivisi Operasional

PT. Ismaya Group maka akan mengurangi tingkat kesalahan yang dilakukan

karyawan, mengefektifkan sistem pendokumentasian, menghemat waktu

pembelajaran karyawan dan juga agar knowledge perusahaan tidak hilang

begitu saja.

Lie, Chendawan (2008), mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisa dan Perancangan Knowledge

Repository System pada PT.Bimasakti Usindo Persada”. Tujuannya adalah

perancangan suatu aplikasi yang dapat mengelola dan mendokumentasikan

knowledge perusahaan sehingga aplikasi ini dapat membantu pihak

perusahaan dalam menangkap knowledge yang dimiliki oleh karyawannya.

Aplikasi dibangun berbasis web, menggunakan bahasa pemrograman PHP.

Hasil penelitian dan penulisan dari penelitian ini yakni menyadarkan kepada

karyawan akan pentingnya budaya knowledge sharing dan juga

pendistribusian knowledge pada prusahaan yang lebih baik. Kelemahan dari

studi ini ialah tampilan sistem yang tidak user friendly, sehingga membuat

karyawan kesulitan untuk berinteraksi didalam sistem.

Ricky Wilsen, dkk.(2007) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisis dan Perancangan Knowledge

56

Repository System pada Divisi Operasional PT. Bayu Buana tbk”. Tujuan

penulisannya adalah untuk membuat suatu sistem yang mampu

memfasilitasi pertukaran pengetahuan antar karyawan. Sistem yang

dirancang merupakan sistem berbasis WEB. Sistem dibuat dengan

menggunakan bahasa pemrograman PHP dan MySQL. Kelebihan sistem ini

adalah adanya discussion forum untuk memfasilitasi pertukaran

pengetahuan antar karyawan, sehingga terdapat wadah untuk menampung

aspirasi karyawan.

Suryani (2007), mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Pembangunan Knowledge Repoository pada PT.

Medco E&P Indonesia Divisi Petroleum Engineering”. Tujuan penulisannya

adalah membangun knowledge repository dan bagaimana mengelola

knowledge agar tidak terbuang sia-sia. Sistem yang dirancang adalah sistem

berbasis WEB. Sistem dibuat dengan menggunakan bahasa pemrograman

PHP dan MySQL. Hasil dari penelitian ini adalah tersedianya knowledge

repository yang diisi dengan knowledge dan informasi yang akan membantu

para pekerja dalam menyelesaikan setiap tugas mereka dan secara perlahan

membawa mereka menjadi learning organization.

Sutrisno (2007), mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Pembangunan Knowledge Repository pada PT.

Trikomsel Multimedia”. Tujuan dari penelitian ini adalah untuk

menghasilkan sebuah Knowledge Repository System yang dapat

mempermudah dan memperlancar proses pendokumentasian sehinga

57

membantu mencegah terjadinya hilangnya informasi dan pengetahuan.

Aplikasi ini menggunakan bahasa pemrograman PHP. Hasil yang diperoleh

dari pembangunan sistem knowledge repository ini adalah memudahkan

pihak perusahaan dalam membantu proses pembelajaran karyawan dan

membantu proses berbagi pengetahuan yang berdasar pada doumentation,

sharing and distribution knowledge.

Hutama, Singgih (2007) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Pembangunan Knowledge Repository

System Untuk Mengelola dan Mengoptimalkan Knowledge Pada PT. Zero

Celcius Indonesia”. Tujuan penelitian ini adalah untuk mencegah terjadinya

hilangnya knowledge yang dimiliki oleh karyawan yang telah meninggalkan

perusahaan dan sebagai sarana pendukung penangkapan knowledge dan

sharing knowledge antar karyawan didalam perusahaan. Perancangan

menggunakan UML, Pembangunan aplikasi menggunakan bahasa

pemrograman PHP. Hasil yang diperoleh dari pembangunan sistem

knowledge repository ini adalah PT.Zero Celcius Indonesia akan

mengurangi tingkat kesalahan yang dilakukan karyawan, dengan

mengefektifkan sistem pendokumentasian, serta mempersingkat waktu

pembelajaran karyawan.

Fredy, Darsena. dkk (2006), mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisa dan Perancangan Knowledge

Repository Untuk Mendukung Organisasi Pembelajar (Studi Kasus

Programming Division PT.Rajawali Citra Televisi Indonesia)”. Tujuan

58

penulisannya adalah menghasilkan sebuah bagian dari sistem manajemen

pengetahuan yang dapat memfasilitasi kelancaran proses penyimpanan

pengetahuan dalam satu devisi. Sistem yang dirancang adalah sistem

berbasis web yang dijalankan dijaringan (LAN) perusahaan. Hasil yang

dicapai adalah Knowledge yang tersimpan pada knowledge repository

menjadi pembelajaran bagi knowledge worker lain yang ada pada

Programming Devision. Jadi sistem berbasis web ini sangat membantu

Prusahaan terutama Programming Devision dalam mendokumentasikan

hasil pemikiran mereka. Kelemahan dari studi ini yaitu sistem tidak memuat

fungsi schedulling dan status inventory karena tidak terhubung dengan

aplikasi schedulling yang telah dimiliki oleh perusahaan.

Sujono (2006) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Pembangunan Knowledge Repository Pada PT.

Sinar Sosro KPW Banten Bagian Distribusi dan Marketing Dalam

Peningkatan Kualitas Kinerja SDM”. Tujuan penelitian yang dilakukan

adalah untuk membangun fasilitas knowledge repository, dan bagaimana

cara me-maintenance knowledge-knowledge yang ada, agar tidak terbuang

sia-sia. Pembangunan aplikasi menggunakan pemrograman PHP dan Mysql.

Hasil yang diperoleh dari pembangunan sistem knowledge repository ini

adalah membantu perusahaan dalam menjaga informasi perusahaan dan

knowledge perusahaan, seperti penyimpanan knowlede promosi, knowledge

outlet, dan kondisi pasar sehingga informasi dan knowledge tersebut dapat

membantu SDM dalam meningkatkan kualitas kerjanya.

59

Andrian Satrianto, dkk (2011) mahasiswa Universitas Bina

Nusantara dalam penelitiannya berjudul “Analisa dan Perancangan Data

Warehouse pada Rumah Sakit Sumber Waras”. Tujuan penelitiannya adalah

mengusulkan alternatif pemecahan masalah dengan menganalisa database

yang ada pada instansi tersebut sehingga memperoleh informasi yang

dibutuhkan, merancang data warehouse dengan mengintegrasikan data yang

ada. Pembangunan aplikasi menggunakan pemrograman PHP dan Mysql

Sebagai databasenya. Hasil yang dicapai adalah sebuah aplikasi data

warehouse yang dapat merangkum, mengintegrasikan dan menyajikan data

historis secara multi dimensi sehingga dapat membantu pihak eksekutif

dirumah sakit dalam pengambilan keputusan.

Rony Wijaya, dkk (2011) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisa dan Perancangan Data Warehouse

pada PT. Indometal Jayapratama”. Tujuan penelitian ini adalah merancang

aplikasi data warehouse untuk memenuhi kebutuhan pihak eksekutif

perusahaan dalam hal informasi. Pembangunan aplikasi menggunakan

pemrograman PHP. Hasil yang dicapai setelah menggunakan aplikasi data

warehouse adalah pihak eksekutif dapat membaca laporan yang

multidimensional dari berbagai sudut pandang yang sangat berguna sebagai

bahan analisa dalam pengambilan keputusan.

Nurlaelah (2011) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Analisa dan Perancangan Data Warehouse pada PT.

HD Finance”. Tujuan penelitian ini ialah merancang sebuah data

60

warehouse beserta aplikasinya untuk PT. HD Finance agar dapat

menampilkan laporan yang diinginkan dalam bentuk yang dinamis

khususnya pada bagian penjualan angsuran, penagihan dan penarikan.

Pembangunan aplikasi menggunakan pemrograman PHP. Hasil yang

dicapai adalah rancangan data warehouse beserta aplikasinya untuk bagian

penjualan angsuran, penagihan dan penarikan yang diharapkan dapat

membantu pihak PT. HD Finance dalam menghasilkan laporan yang dapat

dilihat dari berbagai dimensi.

Apriliyanti, dkk (2011) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisa dan Perancangan Data Warehouse

pada PT. Saga Machine”. Tujuan penelitian ini adalah menganalisis

kebutuhan data pada perusahaan guna merancang data warehouse

penjualan, pembelian dan persediaan pada PT. Saga Machie serta

merancang aplikasi yang mempermudah dalam menampilkan laporan untuk

analisis bisnis. Pembangunan aplikasi menggunakan pemrograman PHP dan

Mysql. Hasil penelitian yaitu suatu aplikasi data warehouse yang dapat

mengintegrasikan data dan menyajikan informasi secara multidimensi yang

memudahkan pengguna dengan menampilkan laporan yang dapat dilihat

dari berbagai sudut pandang.

Novita Hanafiah, dkk (2011) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisis dan Perancangan Data Warehouse

Produksi, Penjualan, dan Pembayaran Berbasis Web pada PT. Mulia

Knitting Factory, Ltd”. Pembangunan Aplikasi ini berbasis web dengan

61

bahasa pemrograman PHP. Tujuan penelitian ini adalah menganalisis dan

merancang sebuah sistem data warehouse yang dapat ditampilkan dengan

aplikasi web pada PT. Mulia Knitting Factory, Ltd. yang bergerak di bidang

garmen. Hasil yang dicapai adalah sebuah sistem data warehouse berbasis

web yang mempermudah pengolahan data dan laporan-laporan yang

diperlukan oleh pihak eksekutif.

Wildy Wijaya, dkk (2011) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Analisis dan Perancangan Data Warehouse

pada PT. Duta Cendana Adimandiri”. Pembangunan Aplikasi menggunakan

bahasa pemrograman PHP dan database mysql. Tujuan penelitian ini untuk

menghasilkan informasi data warehouse terutama pada bagian sales, service

dan sparepart dengan cepat dan akurat bagi pihak level manager tertinggi

pada PT. Duta Cendana Adimandiri. Hasil yang dicapai adalah dengan

sistem yang baru, diharapkan dapat mengatasi masalah yang dihadapi dan

menghasilkan informasi yang cepat dan akurat dalam pengambilan

keputusan perusahaan.

Hardyman, dkk (2010) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Analisis dan Perancangan Data Warehouse pada PT.

Era Grahareality”. Pembangunan Aplikasi menggunakan bahasa

pemrograman PHP dan database mysql. Tujuan penelitian ini adalah

menganalisa dan menyimpan informasi knowledge perusahaan. Hasil yang

dicapai data warehouse dapat menyediakan informasi yang lengkap dan

sesuai sehingga pengambilan keputusan akan lebih cepat.

62

Ageng Kurniawan, (2011) mahasiswa Universitas Bina Nusantara

dalam penelitiannya berjudul “Data Warehouse pada Rumah Sakit Umum

Daerah Koja”. Pembangunan Aplikasi menggunakan bahasa pemrograman

PHP dan database mysql. Tujuan penelitian ini adalah untuk menganalisis

dan merancang sistem data warehouse yang membantu dan mempermudah

penyimpanan data. Hasil yang dicapai adalah sistem berhasil

mengintegrasikan dua database yang terpisah.

Andreas (2010) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Analisis dan Perancangan Data Warehouse Kredit

Kendaraan Bermotor pada PT. Mandala Multifinance”. Pembangunan

Aplikasi menggunakan bahasa pemrograman PHP dan database mysql.

Tujuan penelitian ini adalah untuk mengusulkan alternatif pemecahan

masalah dengan menganalisa database yang ada pada perusahaan sehingga

memperoleh informasi yang dibutuhkan. Hasil yang dicapai adalah sebuah

rancangan data warehouse dan aplikasi pendukung data warehouse yang

dapat menampilkan informasi mengenai pola perubahan pemesanan kredit,

penagihan kredit dll.

Lisiana, dkk (2010) mahasiswa Universitas Bina Nusantara dalam

penelitiannya berjudul “Analisis dan Perancangan Data Warehouse pada PT.

Antar Mitra Prakarsa”. Pembangunan Aplikasi menggunakan bahasa

pemrograman PHP. Tujuan penelitian ini adalah ialah menganalisis dan

merancang data warehouse untuk mendukung proses pengambilan

keputusan oleh pihak manajemen PT. Antar Mitra Prakarsa berdasarkan

63

data historis yang ada khususnya dalam bidang penjualan dan pembelian.

Hasil yang dicapai adalah rancangan data warehouse dan prototype aplikasi

yang dapat menyajikan data historis secara multidimensi sesuai dengan

keinginan pihak manajemen.

Berdasarkan literatur-literatur diatas maka penulis membandingkan

dengan materi penelitian yang penulis angkat dalam skripsi ini. Adapun

judul dari skripsi penulis adalah “Rancang Bangun Sistem Repository Surat

Keputusan (SK) dengan Memanfaatkan Zkoss Framework studi kasus pada

Subbagian Organisasi Tata Laksana dan Perundang-undangan UIN syarif

Hidayatullah jakarta” Tujuan dari penelitian ini adalah merancang dan

membangun Aplikasi Sistem Repository SK yang dapae menunjang

aktivitas pada Subbagian Ortala dan lingkungan dalam UIN Jakarta yang

berkaitan dengan penyimpanan surat keputusan (SK) kedalam aplikasi

Repository SK, Tersedianya media publikasi SK secara online yang

diterbitkan pada lingkungan UIN Jakarta serta Terjadinya sentralisasi

penyimpanan SK yang dapat menjaga keaslian dari berkas yang disimpan

tersebut. Adapun kelebihan dari aplikasi yang penulis buat adalah

pembangunan aplikasi dengan menggunakan bahasa pemrograman Java dan

pemanfaatan Zkoss framework yang sudah tidak diragukan lagi

kemampuannya serta menggunakan database PostgreSql yang merupakan

freeware dan dapat menampung banyak data dengan tingkat kestabilan yang

tinggi.

64

BAB III

METODOLOGI PENELITIAN

Dalam penelitian skripsi ini penulis menggunakan beberapa kerangka

metodologi. Dalam tahap pengumpulan data, penulis menggunakan metode: studi

lapangan dan studi pustaka. Sedangkan dalam pengembanga sistem, penulis

mengguakan metode rapid application development (RAD) dengan tiga tahapan

utama yaitu: requirements planning, RAD design workshop dan implementation.

Berikut akan dijelaskan masing-masing tahapan dalam pengembangan aplikasi

tersebut.

3.1. Metode Pengumpulan Data

3.1.1. Studi Lapangan

Pada studi lapangan ini penulis membagi kedalam dua bagian

yaitu studi lapangan berupa Observasi dan Wawancara.

3.1.1.1. Observasi

Penulis mengamati langsung proses penyimpanan arsip

SK dan pendistribusian yang sedang berjalan saat ini. Hal ini

perlu dilakukan agar penulis dapat melakukan analisis terhadap

sistem yang berjalan serta menentukan rancangan sistem yang

akan dibangun agar sesuai dengan prosedur penyimpanan

berkas SK saat ini.

65

a. Tempat

Tempat yang menjadi objek penelitian adalah :

Nama Instansi : Subbag ORTALA UIN Syarif

Hidayatullah Jakarta

Alamat : Gedung Rektorat UIN Syarif Hidayatullah

Jakarta Jl. Ir. H. Juanda Lt.3

b. Waktu

Waktu pelaksanaan adalah :

Hari Kerja : Senin s/d Jum’at

Pukul : 08.00 s/d 15.00

Penelitian : Juni s/d Juli 2011 (2 bulan)

3.1.1.2. Wawancara

Penulis melakukan wawancara kepada pihak-pihak

yang nantinya akan berhubungan dengan sistem yang akan

dibangun. Tujuannya untuk mendapatkan informasi struktur

organisasi, sejarah singkat, dan mengetahui prosedur sistem

yang berjalan pada instansi tersebut. Penulis melakukan

wawancara kepada Bapak Bambang, SH selaku Kasubbag

Organisasi Tata Laksana dan Perundang-undangan, Admin-

admin Ortala. Adapun contoh dari pertanyaan yang diajukan

pada saat dilakukan wawancara adalah sebagai berikut:

66

1. Penulis : Seberapa pentingkah penyimpanan arsip

dari suatu berkas SK?

Kasubbag : Penyimpanan arsip berkas SK sangatlah

penting. Sebuah arsip sangat dibutuhkan

ketika terjadi suatu kegiatan atau wewenang

yang menyimpang serta dapat menjadi

sebagai bukti yang memiliki kekuatan

hukum. Sehingga harus dijaga dan

dilestarikan keberadaannya.

2. Penulis : Siapa saja yang boleh melihat SK

Kelembagaan?

Kasubbag : Pihak yang dibolehkan melihat berkas SK

secara utuh adalah pimpinan dari masing-

masing unit kerja / fakultas.

3. Penulis : Bagaimana Proses penyimpanan SK yang

sudah dibuat?

Kasubbag : Saat ini proses penyimpanan terhadap

berkas SK yang telah matang/jadi yaitu

disimpan dengan cara di kelompokan pada

lemari-lemari arsip berupa arsip fisik.

67

3.1.2. Studi Pustaka

Pada tahapan pengumpulan data dengan cara studi pustaka,

penulis mencari referensi-referensi yang relevan dengan objek yang

akan diteliti. Referensi-referensi tersebut berasal dari buku-buku

pegangan, artikel, situs internet dan studi sejenis serta sumber

informasi lain yang berkaitan dengan penelitian ini seperti

kepustakaan di beberapa tempat antara lain di perpustakaan dan toko

buku. Setelah mendapatkan referensi-referensi yang relevan tersebut,

penulis lalu mencari informasi-informasi yang dibutuhkan dalam

penelitian ini dari referensi-referensi tersebut. Informasi yang didapat

digunakan dalam penyusunan landasan teori, metodologi penelitian

serta pengembangan aplikasinya secara langsung. Adapun Pustaka

yang menjadi acuan dari penulis adalah Systems Analysis and Design,

Pengenalan Sistem Informasi, Rekayasa Perangakat Lunak

Pendekatan Praktis (Buku I). Selengkapnya ada pada daftar pustaka.

Pada studi sejenis, penulis mengamati hasil penelitian yang

telah dilakukan sebelumnya, mempelajari bagaimana cara

mengerjakannya, dan melakukan perbandingan seberapa berbedakah

penelitian yang akan penulis lakukan dengan penelitian yang telah

dilakukan sebelumnya.

68

3.2. Metode Pengembangan Sistem Rapid Application Development (RAD)

Menurut (Kendal & Kendal, 2010:237), RAD adalah suatu

pendekatan berorientasi objek terhadap pengembangan sistem yang

mencangkup suatu metode pengembangan serta perangkat-perangkat lunak.

Menurut (Pressman,2002:42), RAD adalah sebuah model proses

perkembangan perangkat lunak sekuensial linier yang menekankan siklus

perkembangan yang sangat pendek. Model RAD ini merupakan sebuah

adaptasi ”kecepatan tinggi” dari model sekuensial linier dimana

perkembangan cepat didapat dengan menggunakan pendekatan konstruksi

berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD

memungkinkan tim pengembangan menciptakan ”sistem fungsional yang

utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90

hari).

Sedangkan menurut James Martin, RAD adalah strategi

penembangan sistem yang menekankan kepada kecepatan pengembangan

melalui lingkungan user didalam kontruksi yang cepat (rapid), iteratif, dan

inkremental dari suatu urutan fungsi prototipe dari sistem yang berangsur-

angsur berubah menjadi sistem final.

3.2.1. Alasan Menggunakan RAD

Dari beberapa macam model-model metode perangkat lunak

yang dikemukakan oleh (Dennis, Wixom, & Tegarden, 2005),

penulis memilih metode RAD sebagai metode pengembangan sistem

untuk kasus yang diteliti dengan alasan sebagai berikut:

69

1. Aplikasi yang dirancang dan dikembangkan merupakan aplikasi

yang sederhana dan tidak memerlukan waktu yang lama. Hal ini

sesuai dengan tujuan dari model RAD yang dikemukakan oleh

Kenneth E. Kendall dan Julie E. Kendall yaitu RAD digunakan

untuk mempersingkat waktu antara perancangan dan penerapan

sistem informasi (Kendall dan Kendall, 2010:237).

2. Dengan menggunakan metode RAD, akan dicapai suatu sistem

fungsional yang utuh dalam periode waktu yang relatif pendek

dengan catatan, investigasi kebutuhan sistem telah diperoleh dan

difahami dengan baik (Pressman, Software Engineering: A

Practitioner's Approach Sixth Edition, 2010).

3. RAD dapat mendukung untuk penggunaan teknik dan

kemampuan tools komputer yang spesial untuk mempercepat

fase analisis, desain dan implementasi. Kemampuan spesial itu

antara lain seperti fourth generation/ visual programming

language yang membuat proses pemrograman menjadi mudah

dan sederhana, penggunaan code generators yang mengotomasi

pembuatan program berdasarkan spesifikasi disain dan RAD

mendukung pengembangan sistem yang membutuhkan

lingkungan pustaka (library) yang cukup besar, yaitu

menggunakan teknologi Java Enterprise Edition (JEE). Hal ini

sesuai dengan penjelasan tujuan dan spesifikasi RAD oleh

(Dennis, Wixom, & Tegarden, 2005, p. 9).

70

4. RAD dapat mengatasi permasalahan ketidakjelasan tentang

kebutuhan pengguna (user requirement), terhadap apa yang

harus sistem lakukan nantinya. Ketidakjelasan ini biasanya

disebabkan karena sulitnya bagi pengguna untuk

mengemukakan apa yang diinginkan kepada pengembangdan

lebih mudah jikalangsung berinteraksi dengan teknologi. Hal ini

sesuai dengan penjelasan maksud dan tujuan RAD yang

dikemukakan oleh (Dennis, Wixom, & Tegarden, 2005, p. 15),

bahwa RAD menyediakan konsep prototyping, dimana seorang

pengguna dapat langsung berinteraksi dengan sistem di awal.

3.2.2. Fase-fase RAD

Menurut (Kendall & Kendall, 2010), fase-fase RAD terdiri

dari tigabagian utama yaitu: fase perencanaan kebutuhan

(requirement planning), pemodelan (workshop design) dan

implementasi (implementation).Gambar 2.3 menunjukkan siklus

metodologi RAD dengan model (Kendall & Kendall, 2010).

Gambar 3.1 Fase RAD (Kendall & Kendall, 2010:237)

71

1. Perencanaan Kebutuhan (requirement planning)

Pada fase ini para pengguna dan penganalis bertemu

untuk mengidentifikasi tujuan dari aplikasi atau sistem yang

ingin dibangun. Fase ini memerlukan keterlibatan yang intens

dari kedua belah pihak, tidak hanya melakukan tanda-tangan

proposal atau dokumen saja, sebagaimana diutarakan oleh

(Kendall & Kendall, 2010),

“In the requirements planning phase, users and

analysts meet to identify objectives of the application or system

and to identify information requirements arising from those

objectives. This phase requires intense involvement from both

groups; it is not just signing off on a proposal or document.”

Dalam tahap ini dilakukan beberapa tahap identifikasi

diantaranya adalah

Input :

a. Penjabaran sekilas tentang objek studi kasus, Visi Misi

dan tujuan, Struktur Organisasi.

b. Wawancara dan observasi pada pihak-pihak yang

terkait alur dokumen. (Terlampir)

Proses :

a. Menganalisa sistem berjalan yang ada di Subbag Ortala

terkait alur dokumen SK (Rich Picture).

b. Melakukan identifikasi masalah.

72

c. Menganalisa kebutuhan sistem.

d. Melakukan identifikasi kebutuhan sistem.

Output :

a. Menentukan tujuan pengembangan sistem.

b. Membuat use case diagram sistem usulan.

2. Workshop Desain RAD (RAD design workshop)

Faseworkshop desain RAD adalah fase mendesain dan

memperbaiki aplikasi atau sistem, Kendall & Kendall

mencirikan fase ini seperti workshop. Mengapa fase ini

dicirikan dengan workshop, karena layaknya sebuah workshop

yang terdapat para partisipan yang berpartisipasi kuat dalam

kelompok dan tidak terdapat aktifitas yang pasif. Partisipan

tersebut dianalogikan sebagai kelompok-kelompok kecil

(group decision support systems) yang dibentuk untuk

membantu user dalam menyetujui desain. Selama workshop

desain RAD ini, pengguna merespon working prototype yang

ada, menganalisa dan memperbaiki modul-modul yang

dirancang menggunakan perangkat lunak berdasarkan respon

pengguna Hal ini sebagaimana yang diutarakan oleh (Kendall

& Kendall, 2010).

“The RAD design workshop phase is a design-and-

refine phase that can best be characterized as a workshop.

73

When you imagine a workshop, you know that participation is

intense, not passive, and that it is typically hands on. During

the RAD design workshop, users respond to actual working

prototypes and analysts refine designed modules (using some

of the software tools mentioned later) based on user re-

sponses.”

Sesuai dengan pernyataan Kendall & Kendall maka

Pada tahap ini akan dibagi menjadi dua bagian yaitu Design

System dan Build System. Untuk penjabaran masing-masing

bagian adalah sebagai berikut:

a. Design System

Pada Design System ini akan dilakukan antara lain

Perancangan proses-proses dan yang akan terjadi didalam

sistem akan direpresentasikan dengan Diagram UML agar user

dan developer dapat lebih memahami langkah awal

membangun sistem secara fisik.

Input :

- Use Case

Proses :

- Pembuatan Pemodelan Proses dengan Activity

Diagram dan Sequence Diagram.

- Perancangan basis data dilakukan dengan Class

Diagram yang menggambarkan hubungan antar

74

entitiy yang ada pada Use Case Diagram dan

spesifikasi Tabel.

- Perancangan User Interface atau perancangan layar

tampilan.

b. Build System

Pada Tahap Build System ini merupakan output dari

design system yaitu pengembangan aplikasi yang telah

dirancang sebelumnya menggunakan Eclipse Helios versi 1.8.1

yang sebelumnya telah dilakukan penginstalan plugin ZK

Studio sebagai framework yang dipakai untuk membuat user

interfece dan source code. Sedangkan pengembangan pada sisi

database penulis menggunakan PosgreSQL versi 1.12.2

sebagai toolnya.

3. Implementasi (implementation)

Berdasarkan fase sebelumnya, diketahui bahawa

selama workshop desain, seorang penganalisis dan penguna

bekerja bersama secara intensif untuk membuat desain bisnis

proses atau aspek-aspek non-teknis dari aplikasi. Segera

setelah aspek-aspek tersebut disepakati dan sistem telah

dibangun dan diperbaiki, aplikasi yang baru tersebut

diujicobakan (testing) dan ditampilkan kepada organisasi

untuk mendapatkan respon. Hal ini sebagaimana yang

diutarakan oleh (Kendall & Kendall, 2010).

75

“… analysts are working with users intensely during

the workshop to design the business or nontechnical aspects of

the system. As soon as these aspects are agreed on and the

systems are built and refined, the new systems or part of

systems are tested and then introduced to the organization.”

Pada fase ini dilakukan beberapa tahapan, anatara lain :

a. Spesifikasi Hardware yang digunakan

Menjelaskan spesifikasi minimal yang harus dimiliki oleh

hardware (PC) yang akan menerapkan aplikasi ini.

b. Perangakat lunak pendukung.

Menjelaskan perangkat lunak untuk mendukung

berjalannya sistem repository SK.

c. Platform Arsitektur Teknologi

d. Penentuan topologi jaringan sistem.

e. Pengujian Sistem

Menjelaskan proses pengujian sistem yang bertujuan

untuk melihat jalannya aplikasi. Pada tahap pengujian

sistem ini dilakukan dengan dua tahap pengujian, yaitu :

1. Pengujian dengan cara Black box Mandiri, yaitu

dengan melakukan pengujian langsung pada

beberapa hardware (PC/Laptop). Dalam pengujian

ini penulis menggunakan laptop/notebook Lenovo

Y430 guna mendapatkan validitas aplikasi ini.

76

2. Respon oleh user (pengguna) tentang aplikasi, berisi

pertanyaan yang meminta tanggapan user setelah

menggunakan aplikasi ini yang diberikan kepada

user yang diambil dari kantor tempat penulis

melakukan studi kasus. Pengujian ini bertujuan untuk

mendapatkan tingkat validitas apabila digunakan

langsung oleh pengguna. Angket berupa pertanyaan

yang berhubungan dengan aplikasi. Form dan hasil

angket dapat dilihat secara lengkap pada lampiran.

3.2.3. Kelebihan RAD

Menurut (Pressman, 2010) beberapa kelebihan yang dimiliki

metode RAD antara lain:

1. Siklus dan fase pengembangan sistem yang cepat.

2. Aplikasi dapat terlihat lebih cepat di awal, karena digunakan

prototyping dengan perancangannya menggunakan Graphic

User Interface (GUI).

3. Memiliki fleksibilitas tinggi karena karena dibangun atas

dasar modularisasi dimana pengembang dapat mendesain

ulang atau me-reuse modul dan bersifat life cycles.

4. Mengurangi biaya dan waktu pengembangan karena

didasarkan pada timeboxing.

77

3.2.4. Kekurangan RAD

Adapun kekurangan dari metode RAD menurut (Kendall &

Kendall 2010: 241) diantaranya:

1. Penganalisis biasanya selalu terburu-buru.

2. Detail analisis dan dokumentasi kurang sehingga menyebabkan

programmer sulit untuk memahami maksud dan arah

pemrograman modul yang dikerjakannya.

3. Terjadi beban tugas yang cukup berat karena para programmer

beserta system analyst dituntut untuk menguasai kemampuan-

kemampuan baru sementara pada saat yang bersamaan diminta

untuk mengembangkan sistem.

78

3.3. Kerangka Berfikir Penelitian

Gambar 3.2. Kerangka Berfikir Penlitian

79

BAB IV

PEMBAHASAN

Pada bab ini, akan dibahas secara detail dan terperinci mengenai sistem

yang akan diimplementasikan dengan menerapkan metodologi penelitian yang

telah diuraikan pada bab sebelumnya. Bahwa model pengembangan sistem yang

akan digunakan penulis dalam pembuatan aplikasi ini adalah Rapid Application

Development (RAD) versi Kendal & kendal yang terdiri dari tiga fase yaitu Fase

Requirements Planning, Workshop Design dan Fase Implementation.

4.1. Perencanaan Persyaratan (Requirements Planning)

Sebelum membahas pembuatan sistem, akan dijelaskan terlebih

dahulu secara umum profil Subbagian Organisasi Tata Laksana dan

Perundang-undangan UIN Syarif Hidayatullah Jakarta sebagai tempat

penelitian yang mengolah data terkait dengan SK Kelembagaan. Dan dalam

rangka mengetahui proses kerja yang ada di Subbagian Ortala, yaitu dengan

menelaah dokumen-dokumen terkait untuk mendapatkan informasi mulai dari

proses pengajuan sampai dengan diterbitkannya SK. Akan tetapi dalam

penelitian ini secara khusus hanya membahas proses penyimpanan Surat

Keputusan (SK) serta proses publikasi terhadap penerima SK secara online

pada subbagian Ortala UIN Syarif Hidayatullah Jakarta. Sesuai dengan yang

telah di bahas pada bab sebelumnya bahwa pada fase ini akan dilakukan

sejumlah kegiatan yaitu :

80

4.1.1. Sekilas Tentang UIN Syarif Hidayatullah Jakarta

UIN Syarif Hidayatullah Jakarta merupakan institusi

pembelajaran dan transmisi ilmu pengetahuan, institusi riset yang

mendukung proses pembangunan bangsa, dan sebagai institusi

pengabdian masyarakat yang menyumbangkan program-program

peningkatan kesejahteraan sosial. Selama setengah abad UIN Syarif

Hidayatulla Jakarta telah melewati beberapa periode sejarah sehingga

sekarang ini telah menjadi salah satu universitas Islam terkemuka di

Indonesia.

4.1.2. Visi dan Misi serta Tujuan UIN Syarif Hidayatullah Jakarta

a. Visi

Visi Universitas adalah menjadi lembaga pendidika tinggi

terkemuka dalam mengembangkan dan mengintegrasikan aspek

keislaman, keilmuan, kemanusiaan, dan keindonesiaan

(UIN,2003:4).

b. Misi

1. Melakukan reintegrasi keilmuan pada tingkat epistimologi,

ontologi, dan aksiologi, sehingga tidak ada lagi dikhotomi

antara ilmu-ilmu umum dan ilmu-ilmu agama.

2. Memberikan landasan moral terhadap pengembangan ilmu

pengetahuan dan teknologi (iptek) dan melakukan pencerahan

dalam pembinaan iman dan takwa (imtak) sehingga iptek dan

imtak dapat sejalan.

81

3. Mengartikulasikan ajaran Islam secara ilmiah-akademis ke

dalam kontek kehidupan masyarakat, sehingga tidak ada lagi

jarak antara nilai dan perspektif agama dan sofistifikasi

masyarakat.

4. Mempertahankan nilai-nilai lama yang positif dan mengambil

dan/atau mengembangkan nilai-nilai baru yang lebih positif.

5. Memberikan kontribusi kepada peningkatan kualitas hidup

masyarakat melalui pola pengabdian masyarakat yang lebih

profesional.

6. Memberikan landasan moral dan spiritual terhadap

pembangunan nasional, sehingga konsep pembangunan

manusia seutuhnya dapat tercapai.

7. Menjadi faktor yang menentukan dalam memelihara hubungan

harmonis antar agama, negara dan masyarakat.

8. Memberikan kontribusi dalam mewujudkan perdamaian dunia

dan kesejahteraan umat manusia. (UIN,2003:4).

c. Tujuan

1. Menyiapkan peserta didik agar menjadi anggota masyarakat

yang memiliki kemampuan akademik dan/atau profesional

yang dapat menerapkan, mengembangkan dan/atau

menciptakan ilmu pengetahuan agama Islam, iptek dan seni

yang dijiwai oleh nilai-nilai keislaman.

82

2. Mengembangkan dan menyebarluaskan ilmu agama Islam,

iptek dan seni yang dijiwai oleh nilai-nilai keislaman, serta

mengupayakan penggunannya untuk meningkatkan taraf

kehidupan masyarakat dan memperkaya kebudayaan nasional.

(UIN, 2003:5).

4.1.3. Subbagian Organisasi Tata Laksana dan Perundang-undangan

UIN Syarif Hidayatullah Jakarta

Subbagian Ortala mempunyai tugas melakukan administrasi

organisasi, tata laksana dan perundang-undangan dilingkungan UIN

Syarif Hidayatullah Jakarta. Dalam menjalankan fungsinya,

Subbagian Ortala berada dibawah Bagian Umum pada Biro

Administrasi Umum dan Kepegawaian UIN Syarif Hidayatullah

Jakarta.

83

4.1.4. Struktur Organisasi

Adapun Struktur Organisasi Biro Administrasi Umum dan

Kepegawaian UIN Syarif Hidayatullah Jakarta adalah sebagai beriku:

Gambar 4.1 Struktur Organisasi Biro Administrasi Umum dan

Kepegawaian UIN Syarif Hidayatullah Jakarta. (UIN, 2002)

BIRO ADMINISTRASI UMUM DAN

Bagian Umum

Bagian Ortala dan Kepegawaian

Subbagian Tata Usaha

Subbagian Rumah Tangga

Subbagian Administrasi Pusat

Bahasa

Subbagian Ortala dan

Perundang-undangan

Subbagian Administrasi Kepegawaian

Subbagian Kesejahteraan

Pegawai

84

4.1.5. Analisa Sistem Yang Sedang Berjalan

Berdasarkan wawancara dan observasi yang telah dilakukan

oleh penulis, ditemukan bahwa untuk kegiatan penyimpanan berkas

SK masih dilakukan secara tradisional yaitu hanya dilakukan

penyimpanan dalam bentuk fisik pada lemari penyimpanan. Sebelum

dilakukan proses penyimpanan, dilakukan klasifikasi terlebih dahulu

untuk mempermudah proses penyimpanan oleh admin yang bertugas

menangani kegiatan penyimpanan tersebut.

Klasifikasi dilakukan sesuai dengan unit kerja masing-masing

dan kategori SK yang diterbitkan. Setelah diklasifikasikan kemudian

indeks dan isi ringkas dari SK tersebut dicatat pada komputer admin.

Namun pada pencatatan dikomputer admin tidak disertai lokasi

penyimpanan berkas yang tepat, sehingga hanya admin saja yang

mengetahui tempat dimana berkas tersebut disimpan. Setelah

dilakukan pencatatan, kemudian arsip tersebut disimpan sesuai folder

yang sudah diberi label. Apabila ingin mengakses kembali file arsip

yang telah disimpan, maka proses pencariannya akan memakan waktu

yang cukup lama dan hanya admin yang menyimpanlah yang

mengetahui keberadaan berkas tersebut. Karena tidak ada buku

petunjuk dimana file tersebut disimpan.

Saat ini, untuk penyimpanan berkas-berkas SK pun belum

dapat disentralisasikan, makan dikhawatirkan akan adanya SK liar

yang tidak terpantau dan tidak sah statusnya. Masih banyak berkas-

85

berkas SK lainnya yang terpencar pada unit-unit kerja lain yang

seharusnya terorganisir pada subbagian Ortala/Kepegawaian UIN

Syarif Hidayatullah Jakarta.

Gambar 4.2. Rich Picture Sistem Berjalan

4.1.6. Identifikasi Masalah

Dari hasil analisa diketahui bahwa sistem yang sedang berjalan

masih terdapat banyak kekurangan. Proses penyimpanan berkas SK

masih dilakukan dengan cara tradisonal, yaitu berkas SK yang sudah

disahkan disimpan dilemari penyimpanan dalam bentuk fisik serta

media penyimpanan yang kurang memadai seperti sempitnya ruangan,

lemari arsip yang sedikit dan lain sebagainya sehingga dikhawatirkan

akan terjadi hilangnya berkas yang mungkin dikemudian hari menjadi

86

berkas yang sangat penting. Penyimpanan seperti ini mengakibatkan

apabila dikemudian hari pimpinan masing-masing unit membutuhkan

SK-SK yang dibutuhkan, maka pimpinan harus mengutus stafnya

untuk mengcopy SK yang dibutuhkan di bagian tata usaha pusat,

sehingga akan memakan waktu yang cukup banyak untuk melihat

konsep SK secara utuh.

Dalam merumuskan solusi bagi permasalahan tersebut diatas,

peneliti mengusulkan sebuah sistem yang nantinya mampu

menyimpan berkas SK secara digital serta dapat menampilkan konsep

SK tersebut secara utuh agar dapat diakses sesuai dengan kebutuhan.

4.1.7. Analisa Kebutuhan Sistem

Sistem penyimpanan berkas SK yang terdapat di UIN masih

memiliki kelemahan. Sistem belum bisa menyimpan arsip SK secara

digital dan belum bisa menampilkan konsep SK secara utuh secara

realtime. Penyimpanan dan pencarian kembali berkas SK masih

dilakukan secara manual yaitu penyimpanan dan pencarian secara

fisik pada lemari penyimpanan.

Melihat permasalahan diatas, maka diperlukan strategi untuk

menentukan solusi-solusi dari permasalahan diatas dengan cara:

87

4.1.7.1. Identifikasi Strategi IT

Tabel 4.1 Identifikasi Strategi IT

No Judul Tolak Ukur Sasaran Perbaikan 1. Sulit untuk pengecekan

ulang. Pengecekan pada saat terjadi kekeliruan atau pengecekan apabila diperlukan.

Minimalisasi birokrasi.

2. Pencarian ulang berkas sulit.

Pencarian terhadap arsip SK yang akan dilihat ulang.

Penyederhanaan proses pencarian.

3. Penyimpanan berkas manual.

Kemungkinan Berkas Rusak, hilang.

Penyimpanan dalam bentuk digital dalam database.

4. Data terpencar Berkas berada dimana-mana dan tidak terorganisir.

Sentralisasi berkas SK.

5. Pengiriman lambat Birokrasi dan ekpedisi yang lambat.

Penyederhanaan proses pengiriman.

4.1.7.2. Identifikasi Pola Solusi

Tabel 4.2 Identifikasi Pola Solusi

No Sasaran Perbaikan Pola Solusi 1. Minimalisasi birokrasi. Pembuatan sebuah media online untuk

seua aktifitas yang berhubungan dengan birokrasi.

2. Penyederhanaan proses pencarian. Pencarian kedalam database melalui sistem.

3. Penyimpanan dalam bentuk digital dalam database.

Mengubah berkas fisik menjadi berkas digital kemudian menyimpannya kedalam database sistem.

4. Sentralisasi berkas SK. Mengumpulkan dan mengelompokan sesuai dengan indeks yang ada dalam database.

5. Penyederhanaan proses pengiriman.

Pengiriman / publikasi dapat dilakukan melalui media online.

88

Berdasarkan Identifikasi Strategi IT dan Identifikasi pola solusi

maka, sangat memungkinkan untuk pembuatan sistem berbasis web

yaitu aplikasi Repository SK yang dapat menyimpan berkas SK secara

digital serta dapat menampilkan konsep SK secara utuh dan realtime.

4.1.7.3. Kebutuhan Fungsional Sistem

Sistem yang dikembangkan harus mempunyai

functional requirements sebagai berikut:

1. Sistem repository SK dapat melakukan Penginputan

berkas SK kedaalm sistem.

2. Sistem Repository SK dapat melakukan Pengklasifikasian

berkas SK.

3. Dapat melakukan Validasi terhadap berkas SK.

4. Mempermudah dan mempercepat dalam proses

pengaksesan kembali.

5. Dapat melakukan download berkas SK.

6. Aplikasi dapat langsung digunakan.

4.1.7.4. Kebutuhan Non Fungsional Sistem

Selain kebutuhan fungsional sistem maka ada pula

kebutuhan non fungsional sistem diantaranya yaitu :

1. Sistem hanya dapat diakses oleh masing-masing user

yang telah ditentukan oleh seorang super admin.

2. Sistem repository SK akan dapat berjalan pada sistem

operasi Windows atau Linux Ubuntu.

89

3. Sistem akan bekerja maksimal jika diakses dengan

menggunakan browser Mozilla Firefox karena

membutuhkan linkungan AJAX yang memadai. Pada

Internet Explorer dan Google Chrome kurang

mendukung antarmuka sistem ini.

4. Terdapat pihak-pihak yang bertanggung jawab dalam

memasukkan informasi data master untuk kebutuhan

pada repository.

4.1.8. Tujuan Pengembangan Sistem

Pengembangan sistem bertujuan untuk membantu pihak ortala

dalam melakukan tugas pendokumentasian dan publikasi. Selain itu

dengan adanya sistem ini juga dapat mempermudah para pimpinan

tiap unit kerja untuk mengakses langsung kedalam repository SK

untuk mencari SK-SK yang telah diterbitkan secara realtime dan

proses pencarian dapat dilakukan dimanasaja jika suatu saat

dibutuhkan.

90

4.1.9. Analisa Proses Bisnis Sistem yang Diusulkan

Gambar 4.3. Bisnis Sistem Usulan

Keterangan Gambar: Dalam proses bisnis yang diusulkan, setelah

pihak admin Ortala membuat konsep SK, bila perlu kosep tersebut

diberi label watermark untuk menjaga keaslian hak cipta dan disimpan

dalam bentuk pdf file. Setelah file disimpan kemudian dilakukan

klasifikasi berkas SK sesuai dengan kategorinya untuk kemudian

dilakukan proses upload berkas ke dalam sistem repository SK

dengan status draft. Setelah file tersebut berhasil di upload kedalam

sistem repository SK maka berkas akan masuk pada list validasi

dimenu admin TU rektorat dan admin Ortala. Jika berkas fisik sudah

disahkan oleh rektor, maka selanjutnya pihak admin TU rektorat akan

melakukan validasi terhadap draft SK tersebut. Dengan adanya

validasi ini maka menandakan bahwa SK sudah di sahkan sehingga

91

selanjutnya berkas tersebut dapat diakses oleh pimpinan dari unit-unit

kerja. Kemudian dalam kondisi lain Apabila berkas SK yang sudah

disahkan oleh rektor telah sampai kepada pembuat yaitu pihak Ortala,

maka dapat dilakukan penggantian berkas dengan yang sudah

disahkan rektor. Untuk proses penggantian berkas dapat dilakukan

proses delete berkas yang lama kemudian melakukan scanning

terhadap berkas asli, kemudian disimpan dengan output file scanning

berupa file PDF dan diupload kembali.

Dari segi user, dapat mengakses sistem repository SK dan

mencari file SK sesuai dengan kategori dan ketersediaan didalam

database repository SK masing-masing. Apabila ditemukan maka

user dapat langsung melihat, mencetak ataupun mendownload hasil

copy dari SK tersebut. Sedangkan untuk manajemen hak akses akan

ditangani oleh super admin.

4.1.10. Membuat Use Case Diagram

Use Case mendeskripsikan interaksi antar actor di dalam

sistem informasi eksekutif pada Organisasi. Seperti dijelaskan pada

tabel 4.1 berikut :

Tabel 4.3 Identifikasi Actor dengan Deskripsi

No. Actor Description

1. Pimpinan Unit

Kerja/ Fakultas

Actor yang melakukan pencarian informasi

SK ke sistem.

2. Admin Ortala Actor yang membuat konsep SK dan

melakukan scanning, input, update, validasi

92

dan delete serta menyimpan berkas SK yang

sudah jadi.

3. Admin TU

Rektorat

Actor yang melakukan pencarian dan

validasi berkas SK.

4. Super Admin Actor yang melakukan manajemen hak

akses dan mengurusi keseluruhan sistem.

Berikut adalah Use Case diagram usulan yang menggambarkan

kegiatan-kegiatan dalam sistem repository SK :

Gambar 4.4. Use Case Diagram yang diusulkan

93

4.1.10.1. Use Case Secenario

Tabel 4.4 Use Case Secenario Login

Use Case Name Login

Use Case ID 1

Actor Pimpinan unit, Admin Ortala, Admin TU

Rektorat, Super Admin.

Description Use case menggambarkan kegiatan

memasukan username dan password

untuk mengakses sistem.

Precondition Pimpinan unit, Admin Ortala, Admin TU

Rektorat, Super Admin membuka sistem.

Typical Course of Events Actor Action System Response

1. Input username

dan password.

2. Cek username dan

password.

3. Menampilkan

halaman sesuai

authentifikasi.

Alternate Courses Jika no.2 salah input atau tidak

ditemukan maka akan menampilkan

pesan kesalahan.

Conclusion Pimpinan unit, Admin Ortala, Admin TU

Rektorat, Super Admin login ke sistem.

Post Condition Pimpinan unit, Admin Ortala, Admin TU

Rektorat, Super Admin dapat mengakses

sistem.

94

Tabel 4.5 Use Case Scenario Telusur SK

Use Case Name Telusur SK

Use Case ID 2

Actor Pimpinan Unit kerja/fakultas, Admin

Ortala.

Description Use case menggambarkan kegiatan

pencarian SK.

Precondition Pimpinan Unit kerja/fakultas, Admin

Ortala login ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

koleksi SK.

2. Menampilkan list

SK.

3. Memilih untuk

penelusuran SK

3. Menampilkan

hasil penelusuran.

Alternate Courses Jika no.3 tidak ditemukan maka akan

menampilkan pesan data tidak

ditemukan.

Conclusion Pimpinan Unit kerja/fakultas, Admin

Ortala menemukan SK yang dicari.

Post Condition Pimpinan Unit kerja/fakultas, Admin

Ortala dapat melihat berkas SK secara

utuh.

Tabel 4.6 Use Case Secenario Lihat Beranda

Use Case Name Lihat Beranda

Use Case ID 3

Actor Pimpinan Unit kerja/fakultas, admin

Ortala.

Description Use case menggambarkan kegiatan untuk

95

melihat beranda.

Precondition Pimpinan Unit kerja/fakultas, Admin

Ortala login ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

beranda.

2.Menampilkan

menu beranda.

Alternate Courses -

Conclusion Pimpinan Unit kerja/fakultas, Admin

Ortala melihat menu beranda.

Post Condition Menu beranda berhasil ditampilkan.

Tabel 4.7 Use Case Secenario Lihat Struktur Organisasi

Use Case Name Lihat Struktur Organisasi

Use Case ID 4

Actor Pimpinan Unit kerja/fakultas, Admin

Ortala

Description Use case menggambarkan kegiatan untuk

melihat struktur organisasi.

Precondition Pimpinan Unit kerja/fakultas, Admin

Ortala login ke dalam sistem.

Typical Course of Events Actor Action System Response

1.Memilih menu

Struktur

organisasi.

2.Menampilkan

menu struktur

organisasi.

Alternate Courses -

Conclusion Pimpinan Unit kerja/fakultas, Admin

Ortala melihat menu struktur organisasi.

Post Condition Menu struktur organisasi berhasil

ditampilkan.

96

Tabel 4.8 Use Case Secenario Lihat Kontak

Use Case Name Lihat Kontak

Use Case ID 5

Actor Pimpinan Unit kerja/fakultas, Admin

Ortala

Description Use case menggambarkan kegiatan

untuk melihat kontak.

Precondition Pimpinan Unit kerja/fakultas, Admin

Ortala login ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

kontak.

2. Menampilkan

menu kontak

Alternate Courses -

Conclusion Pimpinan Unit kerja/fakultas, Admin

Ortala melihat menu kontak.

Post Condition Menu kontak berhasil ditampilkan

Tabel 4.9 Use Case Secenario Lihat koleksi SK (User)

Use Case Name Lihat koleksi SK

Use Case ID 6

Actor Pimpinan Unit kerja/fakultas

Description Use case menggambarkan kegiatan

untuk melihat koleksi SK

Precondition Pimpinan Unit kerja/fakultas login ke

dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

pada koleksi SK.

2. Menampilkan list

SK.

3. Memilih detail 4. Menampilkan

97

detail keterangan SK

Alternate Courses -

Conclusion Pimpinan Unit kerja/fakultas melihat

koleksi SK Sesuai dengan akunnya.

Post Condition Menu Koleksi SK berhasil ditampilkan.

Tabel 4.10 Use Case Secenario Lihat koleksi SK (Admin)

Use Case Name Lihat koleksi SK

Use Case ID 7

Actor Admin Ortala dan Admi TU Rektorat

Description Use case menggambarkan kegiatan untuk

melihat keseluruhan koleksi SK.

Precondition Admin Ortala dan Admi TU Rektorat

login ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

pada koleksi SK.

2. Menampilkan

menu koleksi SK

3. Memilih

Fakultas/ Unit

kerja.

4. Menampilkan SK

sesuai dengan

Fakultas/Unit Kerja

yang dipilih.

3. Memilih detail 4. Menampilkan

detail keterangan SK

Alternate Courses -

Conclusion Admin Ortala dan Admi TU Rektorat

melihat koleksi SK Sesuai dengan

Fakultas/unit kerja yang dipilih.

Post Condition Menu Koleksi SK berhasil ditampilkan.

98

Tabel 4.11 Use Case Secenario View Detail

Use Case Name View detail

Use Case ID 8

Actor Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala.

Description Use case menggambarkan kegiatan untuk

melihat detail rincian SK.

Precondition Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala masuk ke dalam

sistem.

Typical Course of Events Actor Action System Response

1. mengklik

detail link

2. menampilkan

detail dari berkas SK

Alternate Courses -

Conclusion Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala melihat detail

dari berkas SK.

Post Condition Menu View detail berhasil ditampilkan.

Tabel 4.12 Use Case Secenario Download SK

Use Case Name Download SK

Use Case ID 9

Actor Pimpinan unit/fakultas, Admin Ortala,

Admin TU Rektorat.

Description Use case menggambarkan kegiatan

untuk download berkas SK secara utuh.

Precondition Pimpinan unit/fakultas, Admin Ortala,

Admin TU Rektorat masuk ke dalam

sistem.

99

Typical Course of Events Actor Action System Response

1. Memilih menu

koleksi berkas

SK

2. Menampilkan

koleksi berkas SK

3. Memilih

berkas yang akan

di download.

4. Menghubungkan

dengan database dan

menampilkannya.

Alternate Courses -

Conclusion Pimpinan unit/fakultas, Admin Ortala,

Admin TU Rektorat Berhasil

mendownload berkas SK dari sistem.

Post Condition Sistem kembali melist berkas.

Tabel 4.13 Use Case Secenario Delete

Use Case Name Delete Berkas SK

Use Case ID 10

Actor Admin Ortala

Description Use case menggambarkan kegiatan untuk

menghapus berkas dari database.

Precondition Admin Ortala masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. mencari berkas

SK yang akan

dihapus.

2. menampilkan

berkas SK

3. mengklik

tombol delete

4. menampilkan

pesan bahawa berkas

berhasil dihapus.

Alternate Courses -

Conclusion Admin Ortala berhasil menghapus data

100

berkas SK dari sistem.

Post Condition Berkas tidak dapat diakses kembali.

Tabel 4.14 Use Case Secenario Tambah SK

Use Case Name Tambah/Upload SK

Use Case ID 11

Actor Admin Ortala

Description Use Case menggambarkan kegiatan

untuk menambah / mengupload berkas

SK.

Precondition Admin Ortala masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

Tambah berkas

SK

2. Menampilkan

form tambah SK

3. Mengisi Form

tambah SK

4. Menghubungkan

dengan database.

5. memilih data

upload

6. Menghubungkan

dengan database.

7. klik “simpan”

sebagai tanda

informasi telah

disimpan.

8. Menyimpan hasil

input kedalam

database sistem.

Alternate Courses Jika data yang dimasukan tidak lengkap,

maka sistem akan menampilkan pesan

kesalahan.

Conclusion Admin Ortala Berhasil menambah berkas

SK kedalam sistem.

Post Condition Database SK telah bertambah.

101

Tabel 4.15 Use Case Secenario Validasi SK

Use Case Name Validasi SK

Use Case ID 12

Actor Admin TU Rektorat, Admin Ortala

Description Use Case menggambarkan kegiatan

untuk melakukan validasi berkas SK

yang di Upload oleh Admin ortala.

Precondition Admin TU Rektorat, Admin Ortala

masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. melihat detail

berkas pada menu

berkas masuk

2. menampilkan

detail berkas SK

3. validasi berkas

“YA”

4. menghubungkan

database dan

memberi status

validasi pada berkas.

5. Validasi berkas

“Tidak”

6. Berkas tidak jadi

di validasi dan status

validasi kosong.

7. Klik “simpan” 7. menghubungkan

dengan database

validasi.

Alternate Courses -

Conclusion Admin TU Rektorat, Admin Ortala

berhasil melakukan validasi berkas.

Post Condition Berkas SK telah divalidasi dan tidak

terdaftar lagi pada menu validasi

102

Tabel 4.16 Use Case Secenario Role

Use Case Name Tambah / edit / hapus Role

Use Case ID 13

Actor Super Admin

Description Use Case menggambarkan kegiatan

untuk menambah/ mengedit/ menghapus

role pengguna sistem.

Precondition Super Admin masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

pengaturan

2. Menampilkan

menu pengaturan

role.

3. Mengisi Form

tambah SK

4. Menghubungkan

dengan database.

5. menentukan

hak akses

6. Menghubungkan

dengan database.

7. klik “simpan”

sebagai tanda

informasi telah

disimpan.

8. Menyimpan hasil

input kedalam

database sistem.

Alternate Courses -

Conclusion Super Admin Berhasil menambah/

mengedit/ menghapus role kedalam

sistem.

Post Condition Data role telah tersimpan dalam

database.

103

Tabel 4.17 Use Case Secenario Tambah / edit / delete Indeks/Unit

kerja

Use Case Name Tambah / edit / delete Indeks/Unit kerja

Use Case ID 14

Actor Admin Ortala

Description Use Case menggambarkan kegiatan

untuk menambah/ mengedit/ menghapus

indeks/unit kerja.

Precondition Admin Ortala masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

indeks

2. Menampilkan

menu indeks.

3. Mengisi Form

indeks

4. Menghubungkan

dengan database.

5. klik “simpan”

sebagai tanda

informasi telah

disimpan.

6. Menyimpan hasil

input kedalam

database sistem.

Alternate Courses -

Conclusion Admin Ortala Berhasil menambah/

mengedit/ menghapus indeks kedalam

sistem.

Post Condition Data Indeks telah tersimpan dalam

database.

Tabel 4.18 Use Case Secenario Tambah / edit / delete Kategori

Use Case Name Tambah / edit / delete Kategori

Use Case ID 15

Actor Admin Ortala

104

Description Use Case menggambarkan kegiatan

untuk menambah/ mengedit/ menghapus

kategori SK.

Precondition Admin Ortala masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

1. Memilih menu

kategori

2. Menampilkan

menu kategori.

3. Mengisi Form

kategori

4. Menghubungkan

dengan database.

5. klik “simpan”

sebagai tanda

informasi telah

disimpan.

6. Menyimpan hasil

input kedalam

database sistem.

Alternate Courses -

Conclusion Admin Ortala Berhasil menambah/

mengedit/ menghapus kategori kedalam

sistem.

Post Condition Data Indeks telah tersimpan dalam

database.

Tabel 4.19 Use Case Secenario Tambah / edit / delete user

Use Case Name Tambah / edit / delete user

Use Case ID 16

Actor Super Admin

Description Use Case menggambarkan kegiatan

untuk menambah/ mengedit/ menghapus

user.

Precondition Super Admin masuk ke dalam sistem.

Typical Course of Events Actor Action System Response

105

1. Memilih menu

User Account

2. Menampilkan

menu user.

3. Mengisi Form

user.

4. Menghubungkan

dengan database.

5. klik “simpan”

sebagai tanda

informasi telah

disimpan.

6. Menyimpan hasil

input kedalam

database sistem.

Alternate Courses -

Conclusion Super Admin Berhasil menambah/

mengedit/ menghapus kategori kedalam

sistem.

Post Condition Data User telah tersimpan dalam

database.

Tabel 4.20 Use Case Secenario Logout

Use Case Name Logout

Use Case ID 17

Actor Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala.

Description Use case menggambarkan kegiatan

keluar dari sistem.

Precondition Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala login ke dalam

sistem.

Typical Course of Events Actor Action System Response

1. memilih menu

logout

2. menghubungkan

dengan database

3. Menampilkan

halaman login

106

Alternate Courses

Conclusion Pimpinan Unit kerja/fakultas, Admin TU

Rektorat, Admin Ortala keluar dari

sistem.

Post Condition Logout

4.2. Workshop Design

Sesuai dengan yang telah dijabarkan pada bab sebelumnya, pada fase

ini akan dilakukan design system dan Build the system. Keduanya akan

dijabarkan sebagai berikut :

4.2.1. Design System

4.2.1.1. Membuat Activity Diagram

Activity Diagram memodelkan alur kerja (work

flow) sebuah urutan aktivitas pada suatu proses. Diagram ini

sangat mirip dengan flow chart karena kita dapat

memodelkan proses logika, proses bisnis dan alur kerja.

Perbedaan utamanya adalah flow chart dibuat untuk

menggambarkan alur kerja dari sebuah sistem, sedangkan

activity diagram dibuat untuk menggambarkan aktivitas

aktor.

Berikut ini adalah activity diagram yang

menggambarkan aktifitas-aktifitas yang dapat terjadi dalam

sistem repository SK.

107

1. Activity diagram fungsi login (Admin Ortala, Admin TU

Rektorat, User dan Super Admin)

Gambar 4.5 Activity diagram use case login Admin Ortala,

Admin TU Rektorat, User dan Super Admin

Keterangan Gambar : Yang harus dilakuakan Admin Ortala,

Admin TU Rektorat, Super Admin dan User dalam activity

diagram use case login adalah memasukan User Id dan

password, kemudian sistem akan menampilkan pesan kesalahan

dan kembali ke menu login untuk memasukan User Id dan

Password yang benar. Jika User Id dan Password yang

dimasukan benar, maka system akan menampilkan menu utama

system.

108

2. Activity Digram fungsi Lihat Struktur Organisasi (Admin

Ortala, Admin TU Rektorat, dan User)

Gambar 4.6 Activity diagram use case Lihat Struktur

Organisasi (Admin Ortala, Admin TU Rektorat dan User)

Keterangan Gambar : Pada activity diagram ini Admin Ortala,

Admin TU Rektorat dan User melakukan login, kemudian sistem

memvalidasi username dan password yang dimasukan. Jika

username dan password sesuai dengan data yang terdapat

didatabase, user mengklik menu Struktur Organisasi dan sistem

akan menampilkan struktur organisasi Subbagian Ortala UIN

Jakarta.

109

3. Activity Diagram fungsi Lihat Kontak (Admin Ortala, Admin

TU Rektorat, Super Admin dan User)

Gambar 4.7 Activity diagram use case Lihat Kontak

(Admin Ortala, Admin TU Rektorat, Super Admin dan

User)

Keterangan Gambar : Didalam activity diagram use case lihat

kontak yang harus dilakukan oleh Admin Ortala, Admin TU

Rektorat, Super Admin dan User adalah membuka aplikasi

sistem, sistem akan menampilkan menu login. Admin Ortala,

Admin TU Rektorat, Super Admin dan User login ke dalam

system. Jika benar maka Admin Ortala, Admin TU Rektorat,

110

Super Admin dan User dapat mengakses system. Kemudian

memilih menu kontak, sistem akan menampilkan kontak.

4. Activity Berkas

a. Activity diagram fungsi Tambah Berkas (Admin Ortala)

Gambar 4.8 Activity diagram tambah berkas SK

Keterangan Gambar : Pada activity diagram ini Admin

Ortala melakukan login, kemudian sistem memvalidasi

username dan password yang dimasukan. Jika username dan

password sesuai dengan data yang terdapat didatabase, Admin

111

Ortala mengklik menu Tambah Berkas dan sistem akan

menampilkan Form Tambah Berkas serta Upload File.

b. Activity diagram fungsi Delete Berkas SK (Admin

Ortala)

Gambar 4.9 Activity diagram fungsi Delete Berkas SK

Keterangan Gambar : Pada activity diagram ini Admin

Ortala melakukan login, kemudian sistem memvalidasi

username dan password yang dimasukan. Jika username

dan password sesuai dengan data yang terdapat didatabase,

Admin Ortala mengklik menu Koleksi dan sistem akan

menampilkan List koleksi Berkas SK dan dapat langsung

melakukan delete terhadap berkas SK.

112

c. Activity diagram fungsi Cari Berkas SK (Admin Ortala

dan Admin TU Rektorat)

Gambar 4.10 Activity diagram fungsi Cari Berkas SK Admin

Ortala dan Admin TU Rektorat

Keterangan Gambar : Pada activity diagram ini Admin

Ortala dan Admin TU Rektorat melakukan login, kemudian

sistem memvalidasi username dan password yang

dimasukan. Jika username dan password sesuai dengan data

yang terdapat didatabase, Admin Ortala dan Admin TU

Rektorat mengklik menu Koleksi dan sistem akan

menampilkan List koleksi Berkas SK. Kemudian Admin

113

Ortala dan Admin TU Rektorat melakukan pencarian SK

dengan memasukan key pencarian atau kategori kemudian

mengklik button telusur pada koleksi ini. Kemudian sistem

akan menampilkan hasil pencarian.

d. Activity diagram fungsi Cari Berkas SK (User)

Gambar 4.11 Activity diagram fungsi Cari Berkas SK User

Keterangan Gambar : Pada activity diagram ini User

melakukan login, kemudian sistem memvalidasi username

dan password yang dimasukan. Jika username dan

password sesuai dengan data yang terdapat didatabase,

User mengklik menu Berkas SK dan sistem akan

114

menampilkan List koleksi Berkas SK. Kemudian User

melakukan pencarian SK dengan memasukan key pencarian

atau kategori kemudian mengklik button telusur pada

koleksi ini. Kemudian sistem akan menampilkan hasil

pencarian.

e. Activity diagram fungsi Validasi Berkas SK (Admin

Ortala dan Admin TU Rektorat)

Gambar 4.12 Activity diagram fungsi Validasi Berkas SK

Keterangan Gambar : Pada activity diagram ini Admin

Ortala dan Admin TU Rektorat melakukan login, kemudian

sistem memvalidasi username dan password yang

dimasukan. Jika username dan password sesuai dengan data

115

yang terdapat didatabase, Admin Ortala dan Admin TU

Rektorat mengklik menu Validasi dan sistem akan

menampilkan List koleksi Berkas SK yang belum

tervalidasi. Kemudian Admin Ortala dan Admin TU

Rektorat melakukan validasi berkas dengan cara mengklik

tombol validasi, kemudian sistem akan memberi masukan

pada berkas tersebut bahwa berkas telah divalidasi dan

berkas tersebut tidak masuk lagi dalam daftar berkas yang

belum tervalidasi.

f. Activity diagram fungsi Detail Berkas SK (Admin Ortala,

Admin TU Rektorat dan User)

116

Gambar 4.13 Activity diagram fungsi Detail Berkas SK

Keterangan Gambar : Pada activity diagram ini Admin

Ortala dan Admin TU Rektorat melakukan login, kemudian

sistem memvalidasi username dan password yang

dimasukan. Jika username dan password sesuai dengan data

yang terdapat didatabase, Admin Ortala, Admin TU

Rektorat dan User mengklik menu Koleksi dan sistem akan

menampilkan List Berkas SK . Admin Ortala, Admin TU

Rektorat dan User mengklik detail button dan sistem akan

memberi pop up berupa detail riwayat dari berkas SK.

g. Activity diagram fungsi Download Berkas SK (Admin

Ortala, Admin TU Rektorat dan User)

117

Gambar 4.14 Activity diagram fungsi Download Berkas SK

Keterangan Gambar : Pada activity diagram ini Admin

Ortala, Admin TU Rektorat dan User melakukan login,

kemudian sistem memvalidasi username dan password

yang dimasukan. Jika username dan password sesuai

dengan data yang terdapat didatabase, Admin Ortala,

Admin TU Rektorat dan User mengklik menu Koleksi dan

sistem akan menampilkan List Berkas SK. Admin Ortala,

Admin TU Rektorat dan User mengklik Download button

dan sistem akan mengeluarkan output yang didownload

dari database.

5. Activity diagram fungsi Kategori

118

a. Activity diagram fungsi Tambah Kategori (Super

Admin dan Admin Ortala)

Gambar 4.15 Activity diagram Tambah Kategori (Super

Admin dan Admin Ortala)

Keterangan Gambar : Didalam activity diagram use

case Tambah Kategori yang harus dilakukan oleh Super

Admin dan Admin Ortala adalah membuka aplikasi

system, system akan menampilkan menu login. Super

Admin dan Admin Ortala login ke dalam sistem. Jika

119

benar maka Super Admin dan Admin Ortala dapat

mengakses sistem. Kemudian memilih menu Kategori,

sistem akan menampilkan List Kategori. Kemudian

Super Admin dan Admin Ortala mengklik button add

dan mengisi form tambah kategori kemudian Super

Admin dan Admin Ortala mengklik button submit.

Dengan demikian proses penambahan kategori telah

selesai dilakukkan dan sistem melakukan list kembali

daftar kategori.

b. Activity diagram fungsi Edit Kategori (Super Admin

dan Admin Ortala)

120

User Sistem

Membuka sistem repository SK

Input User ID & Password

Menampilkan Form Login

Validasi UsernameDan password

Menampilkan Pesan Kesalahan

Menampilkan Halaman UtamaMemilih Menu Kategori

Menampilkan Menu Kategori

Klik Edit Memanggil data dari database Dan Menampilkan Form Edit Kategori

Input Edit

Klik Update Simpan ke database

Mulai

Selesai

Gambar 4.16 Activity diagram Edit Kategori (Super Admin

dan Admin Ortala)

Keterangan Gambar : Didalam activity diagram Edit

Kategori yang harus dilakukan oleh Super Admin dan

Admin Ortala adalah membuka aplikasi system, system

akan menampilkan menu login. Super Admin dan Admin

Ortala login ke dalam sistem. Jika benar maka Super

Admin dan Admin Ortala dapat mengakses sistem.

Kemudian memilih menu Kategori, sistem akan

menampilkan List Kategori. Kemudian Super Admin dan

Admin Ortala mengklik button Edit dan mengisi atau

121

memperbaiki form tambah kategori kemudian Super

Admin dan Admin Ortala mengklik button Update.

Dengan demikian proses edit kategori telah selesai

dilakukkan dan sistem melakukan list kembali daftar

kategori.

c. Activity diagram fungsi Delete Kategori (Super

Admin dan Admin Ortala)

Gambar 4.17 Activity diagram Delete Kategori

(Super Admin dan Admin Ortala)

Keterangan Gambar : Didalam activity diagram Delete

Kategori yang harus dilakukan oleh Super Admin dan

Admin Ortala adalah membuka aplikasi system, system

akan menampilkan menu login. Super Admin dan Admin

122

Ortala login ke dalam sistem. Jika benar maka Super

Admin dan Admin Ortala dapat mengakses sistem.

Kemudian memilih menu Kategori, sistem akan

menampilkan List Kategori. Kemudian Super Admin dan

Admin Ortala mengklik button delete dan sistem akan

merespon dengan menampilkan pop up window yang

berisi pertanyaan. Kemudian Super Admin dan Admin

Ortala mengklik yes. Dengan demikian proses delete

kategori telah selesai dilakukkan dan sistem melakukan

list kembali daftar kategori.

6. Activity diagram fungsi Indeks

123

a. Activity diagram fungsi Tambah Indeks (Super

Admin dan Admin Ortala)

Gambar 4.18 Activity diagram Tambah Indeks (Super Admin

dan Admin Ortala)

Keterangan Gambar : Didalam activity diagram use

case Tambah Indeks yang harus dilakukan oleh Super

Admin dan Admin Ortala adalah membuka aplikasi

system, system akan menampilkan menu login. Super

Admin dan Admin Ortala login ke dalam sistem. Jika

124

benar maka Super Admin dan Admin Ortala dapat

mengakses sistem. Kemudian memilih menu Indeks,

sistem akan menampilkan List Indeks. Kemudian Super

Admin dan Admin Ortala mengklik button add dan

mengisi form tambah indeks kemudian Super Admin dan

Admin Ortala mengklik button submit. Dengan demikian

proses penambahan indeks telah selesai dilakukkan dan

sistem melakukan list kembali daftar indeks.

125

b. Activity diagram fungsi Edit Indeks (Super Admin

dan Admin Ortala)

Gambar 4.19 Activity diagram Edit Indeks (Super Admin

dan Admin Ortala)

Keterangan Gambar : Didalam activity diagram Edit

Indeks yang harus dilakukan oleh Super Admin dan

Admin Ortala adalah membuka aplikasi system, system

akan menampilkan menu login. Super Admin dan

Admin Ortala login ke dalam sistem. Jika benar maka

Super Admin dan Admin Ortala dapat mengakses

sistem. Kemudian memilih menu Indeks, sistem akan

126

menampilkan List Indeks. Kemudian Super Admin dan

Admin Ortala mengklik button Edit dan mengisi atau

memperbaiki form Indeks kemudian Super Admin dan

Admin Ortala mengklik button Update. Dengan

demikian proses edit kategori telah selesai dilakukkan

dan sistem melakukan list kembali daftar Indeks.

c. Activity diagram fungsi Delete Indeks (Super Admin

dan Admin Ortala)

Gambar 4.20 Activity diagram Delete Kategori (Super

Admin dan Admin Ortala)

127

Keterangan Gambar : Didalam activity diagram

Delete Indeks yang harus dilakukan oleh Super Admin

dan Admin Ortala adalah membuka aplikasi system,

system akan menampilkan menu login. Super Admin

dan Admin Ortala login ke dalam sistem. Jika benar

maka Super Admin dan Admin Ortala dapat mengakses

sistem. Kemudian memilih menu Indeks, sistem akan

menampilkan List Indeks. Kemudian Super Admin dan

Admin Ortala mengklik button delete dan sistem akan

merespon dengan menampilkan pop up window yang

berisi pertanyaan. Kemudian Super Admin dan Admin

Ortala mengklik yes. Dengan demikian proses delete

Indeks telah selesai dilakukkan dan sistem melakukan

list kembali daftar Indeks.

128

7. Activity diagram fungsi User Account

a. Activity diagram fungsi Tambah User Account (Super

Admin)

Gambar 4.21 Activity diagram Tambah User Account (Super

Admin)

Keterangan Gambar : Didalam activity diagram use

case Tambah Indeks yang harus dilakukan oleh Super

Admin adalah membuka aplikasi system, system akan

menampilkan menu login. Super Admin login ke dalam

129

sistem. Jika benar maka Super Admin dapat mengakses

sistem. Kemudian memilih menu User, sistem akan

menampilkan List User. Kemudian Super Admin

mengklik button tambah user dan mengisi form tambah

user, kemudian Super Admin mengklik button submit.

Dengan demikian proses penambahan indeks telah selesai

dilakukkan dan sistem melakukan list kembali daftar user.

b. Activity diagram fungsi Edit User Account (Super

Admin)

Gambar 4.22 Activity diagram Edit User Account (Super

Admin)

130

Keterangan Gambar : Didalam activity diagram Edit

User yang harus dilakukan oleh Super Admin adalah

membuka aplikasi system, system akan menampilkan

menu login. Super Admin login ke dalam sistem. Jika

benar maka Super Admin dapat mengakses sistem.

Kemudian memilih menu User, sistem akan menampilkan

List User. Kemudian Super Admin dan Admin Ortala

mengklik button Edit dan mengisi atau memperbaiki form

User kemudian Super Admin mengklik button Update.

Dengan demikian proses edit user telah selesai dilakukkan

dan sistem melakukan list kembali daftar user.

131

c. Activity diagram fungsi Delete User (Super Admin)

Gambar 4.23 Activity diagram Delete User (Super

Admin)

Keterangan Gambar : Didalam activity diagram Delete

User yang harus dilakukan oleh Super Admin adalah

membuka aplikasi system, system akan menampilkan

menu login. Super Admin login ke dalam sistem. Jika

benar maka Super Admin dapat mengakses sistem.

Kemudian memilih menu User, sistem akan menampilkan

List User. Kemudian Super Admin mengklik button delete

132

dan sistem akan merespon dengan menampilkan pop up

window yang berisi pertanyaan. Kemudian Super Admin

mengklik yes. Dengan demikian proses delete user telah

selesai dilakukkan dan sistem melakukan list kembali

daftar user.

133

8. Activity diagram fungsi Pengaturan

a. Activity diagram fungsi Tambah Role (Super Admin)

Gambar 4.24 Activity diagram Tambah Role (Super Admin)

Keterangan Gambar : Didalam activity diagram use

case Tambah Role yang harus dilakukan oleh Super

Admin adalah membuka aplikasi sistem, sistem akan

menampilkan menu login. Super Admin login ke dalam

sistem. Jika benar maka Super Admin dapat mengakses

134

sistem. Kemudian memilih menu Pengaturan, sistem

akan menampilkan List Role yang ada. Kemudian Super

Admin mengklik button tambah Role dan mengisi form

tambah Role, kemudian Super Admin mengklik button

submit. Dengan demikian proses penambahan Role telah

selesai dilakukkan dan sistem melakukan list kembali

daftar Role.

b. Activity diagram fungsi Edit Role (Super Admin)

Gambar 4.25 Activity diagram Edit Role (Super Admin)

Keterangan Gambar : Didalam activity diagram Edit

Role yang harus dilakukan oleh Super Admin adalah

135

membuka aplikasi sistem, sistem akan menampilkan

menu login. Super Admin login ke dalam sistem. Jika

benar maka Super Admin dapat mengakses sistem.

Kemudian memilih menu Pengaturan, sistem akan

menampilkan List Role. Kemudian Super Admin dan

Admin Ortala mengklik button Edit dan mengisi atau

memperbaiki form Role kemudian Super Admin

mengklik button Update. Dengan demikian proses edit

Role telah selesai dilakukkan dan sistem melakukan list

kembali daftar Role.

136

c. Activity diagram fungsi Delete Role (Super Admin)

Gambar 4.26 Activity diagram Delete Role (Super Admin)

Keterangan Gambar : Didalam activity diagram Delete

Role yang harus dilakukan oleh Super Admin adalah

membuka aplikasi system, system akan menampilkan

menu login. Super Admin login ke dalam sistem. Jika

benar maka Super Admin dapat mengakses sistem.

Kemudian memilih menu pengaturan, sistem akan

menampilkan List Role. Kemudian Super Admin

137

mengklik button delete dan sistem akan merespon

dengan menampilkan pop up window yang berisi

pertanyaan. Kemudian Super Admin mengklik yes.

Dengan demikian proses delete Role telah selesai

dilakukkan dan sistem melakukan list kembali daftar

Role.

9. Activity diagram fungsi logout (Admin Ortala, Admin

TU Rektorat, Super Admin & User)

Gambar 4.27 Activity diagram use case logout

Keterangan Gambar : Didalam Activity diagram fungsi

logout yang pertama harus dilakukan oleh Admin Ortala,

Admin TU Rektorat, Super Admin dan User yaitu

membuka aplikasi serta login terlebih dahulu, jika benar

maka sistem akan menampilkan halaman beranda sistem

138

repository SK, namun jika login salah maka sistem akan

menampilkan pesan kesalanan dan kembali ke menu form

login. Kemudia Admin Ortala, Admin TU Rektorat, Super

Admin dan User memilih menu logout, maka Admin

Ortala, Admin TU Rektorat, Super Admin dan User keluar

dari sistem.

4.2.1.2. Membuat Sequence Diagram

Sequence diagram menggambarkan interaksi antar

objek didalam dan di sekitar sistem (termasuk pengguna,

display, dan sebagainya) berupa message yang digambarkan

terhadap waktu. Dibawah ini adalah sequence diagram untuk

masing-masing modul.

1. Sequence Diagram Login

a. Sequence Diagram Login User

Gambar 4.28 Sequence diagram use case login User

139

Keteranga Gambar : pada saat user melakukan login,

sistem akan meminta username dan password terlebih

dahulu. Pada saat username dan password dibaca oleh sistem,

sistem akan memeriksa username dan password yang

diinputkan dengan username dan password yang sudah ada

didalam database (user). Jika sudah benar maka user akan

masuk ke tampilan menu utama sistem. Jika terdapat

kesalahan maka, sistem akan menampilkan pesan kesalahan

untuk memasukan username dan password kembali.

b. Sequence Diagram Login Admin

Gambar 4.29 Sequence diagram use case login Admin

Keteranga Gambar : pada saat Admin Ortala, Admin TU

Rektorat dan Super admin melakukan login, sistem akan

meminta username dan password terlebih dahulu. Pada saat

username dan password dibaca oleh sistem, sistem akan

memeriksa username dan password yang diinputkan dengan

140

username dan password yang sudah ada didalam database.

Jika sudah benar maka Admin Ortala/ Admin TU Rektorat/

Super admin akan masuk ke tampilan menu utama sistem.

Jika terdapat kesalahan maka, sistem akan menampilkan

pesan kesalahan untuk memasukan username dan password

kembali.

2. Sequence Diagram Berkas

a. Sequence Diagram fungsi Validasi I Berkas Admin

Ortala

Gambar 4.30 Sequence diagram use case Validasi I Berkas

141

Keterangan Gambar : Pada Saat Admin Ortala ingin

memvalidasi berkas maka Admin Ortala masuk kedalam

menu utama, kemudian memilih menu validasi. Di menu

validasi kemudian Admin Ortala melakukan validasi terhadap

berkas SK. Apabila berkas telah divalidasi maka data berkas

SK disimpan didatabase berkas kemudian sistem tidak akan

menampilkannya kembali pada menu validasi dan sistem

kembali menampilkan list berkas yang belum divalidasi.

b. Sequence Diagram fungsi Validasi II Berkas Admin TU

Rektorat

Gambar 4.31 Sequence diagram use case Validasi II Berkas

142

Keterangan Gambar : Pada Saat Admin TU Rektorat ingin

memvalidasi berkas maka Admin TU Rektorat masuk

kedalam menu utama, kemudian memilih menu validasi. Di

menu validasi kemudian Admin TU Rektorat melakukan

validasi terhadap berkas SK. Apabila berkas telah divalidasi

maka data berkas SK disimpan didatabase berkas kemudian

sistem tidak akan menampilkannya kembali pada menu

validasi dan sistem kembali menampilkan list berkas yang

belum divalidasi.

c. Sequence Diagram fungsi Input/Upload Berkas Admin

Ortala

Gambar 4.32 Sequence diagram use case Input/Upload berkas

Keterangan Gambar : Pada Saat Admin Ortala ingin

menginput berkas maka Admin Ortala masuk kedalam menu

143

utama, kemudian memilih menu Berkas. Di menu berkas

terdapat menu tambah berkas, kemudian Admin Ortala

memilih menu tersebut, setelah dipilih maka sistem akan

menampilkan menu tambah berkas. Apabila data berkas telah

dimasukan maka data Role disimpan didatabase Role

kemudian sistem akan menampilkan data berkas yang telah

dimasukan.

Apabila Super Admin ingin melakukan upload file

berkas, Admin Ortala dapat memilih menu browse, setelah

dipilih maka sistem akan menampilkan menu browse, bila

data telah dipilih maka file berkas akan disimpan ke dalam

database berkas file dan kemudian sistem akan menampilkan

pesan berhasil.

144

d. Sequence Diagram fungsi Cari/Detail/Download Berkas

User

Gambar 4.33 Sequence diagram use case cari/detail/download Berkas

Keterangan Gambar : Pada Saat user ingin mencari berkas

SK maka user masuk kedalam menu utama, kemudian

memilih menu koleksi berkas. Di menu koleksi berkas

terdapat menu pencarian berkas, kemudian user memilih

menu tersebut, setelah diinput key pencarian maka sistem

145

akan melakukan pencarian pada database berkas. Apabila

data pencarian telah ditemukan maka sistem akan

menampilkan berkas/list hasil pencarian.

Apabila user ingin melihat detail berkas file, user dapat

memilih menu koleksi berkas, setelah dipilih maka sistem

akan menampilkan list berkas, kemudian user memilih menu

detail. Selanjutnya sistem akan menampilkan detail

keterangan dari berkas. Dan apabila user ingin

mendownload file tersebut, user dapat memilih menu

download, setelah dipilih maka sistem akan memanggil data

dari database berkas sistem akan menampilkan file hasil

download.

146

e. Sequence Diagram fungsi Cari/Detail/Download/Delete Berkas Admin

Gambar 4.34 Sequence diagram use case cari/detail/download Berkas

Keterangan Gambar : Pada Saat Admin Ortala dan Admin

TU Rektorat ingin mencari berkas SK maka Admin Ortala

dan Admin TU Rektorat masuk kedalam menu utama,

kemudian memilih menu koleksi berkas. Di menu koleksi

berkas terdapat menu pencarian berkas, kemudian Admin

Ortala dan Admin TU Rektorat memilih menu tersebut,

setelah diinput key pencarian maka sistem akan melakukan

pencarian pada database berkas. Apabila data pencarian telah

147

ditemukan maka sistem akan menampilkan berkas/list hasil

pencarian.

Apabila Admin Ortala dan Admin TU Rektorat ingin

melihat detail berkas file, Admin Ortala dan Admin TU

Rektorat dapat memilih menu koleksi berkas, setelah dipilih

maka sistem akan menampilkan list berkas, kemudian Admin

Ortala memilih menu detail. Selanjutnya sistem akan

menampilkan detail keterangan dari berkas. Dan apabila

Admin Ortala dan Admin TU Rektorat ingin mendownload

file tersebut, Admin Ortala dan Admin TU Rektorat dapat

memilih menu download, setelah dipilih maka sistem akan

memanggil data dari database berkas sistem akan

menampilkan file hasil download. Dan apabila Admin Ortala

dan Admin TU Rektorat ingin menghapus data berkas,

Admin Ortala dan Admin TU Rektorat dapat memilih menu

delete, setelah dipilih maka sistem akan menghapus data

berkas dari database berkas, kemudian sistem akan

menampilkan kembali seluruh list data berkas.

148

3. Sequence Diagram fungsi Input/Edit/Delete Kategori

Admin Ortala

Gambar 4.35 Sequence diagram use case Input/Edit/Delete Kategori

Keterangan Gambar : Pada Saat Admin Ortala ingin

menginput kategori maka Admin Ortala masuk kedalam

menu utama, kemudian memilih menu kategori. Di menu

kategori terdapat menu tambah kategori, kemudian Admin

Ortala memilih menu tersebut, setelah dipilih maka sistem

akan menampilkan menu tambah kategori. Apabila data

kategori telah dimasukan maka data kategori disimpan di

149

database kategori kemudian sistem akan menampilkan

seluruh data kategori.

Apabila Admin Ortala ingin mengupdate data

kategori, Admin Ortala dapat memilih menu edit, setelah

dipilih maka sistem akan menampilkan menu edit, bila data

kategori telah diubah maka data kategori akan disimpan

kembali ke dalam database kategori dan kemudian sistem

akan menampilkan seluruh data kategori. Dan apabila Admin

Ortala ingin menghapus data kategori, Admin Ortala dapat

memilih menu delete, setelah dipilih maka sistem akan

menghapus data kategori dari database kategori, kemudian

sistem akan menampilkan list seluruh data kategori.

150

4. Sequence Diagram fungsi Input/Edit/Delete Indeks Admin

Ortala

Gambar 4.36 Sequence diagram use case Input/Edit/Delete Indeks

Keterangan Gambar : Pada Saat Admin Ortala ingin

menginput indeks maka Admin Ortala masuk kedalam menu

utama, kemudian memilih menu indeks. Di menu indeks

terdapat menu tambah indeks, kemudian Admin Ortala

memilih menu tersebut, setelah dipilih maka sistem akan

menampilkan menu tambah indeks. Apabila data indeks telah

dimasukan maka data indeks disimpan di database indeks

kemudian sistem akan menampilkan list seluruh data indeks.

151

Apabila Admin Ortala ingin mengupdate data indeks,

Admin Ortala dapat memilih menu edit, setelah dipilih maka

sistem akan menampilkan menu edit, bila data indeks telah

diubah maka data indeks akan disimpan kembali ke dalam

database indeks dan kemudian sistem akan menampilkan

seluruh data indeks. Dan apabila Admin Ortala ingin

menghapus data indeks, Admin Ortala dapat memilih menu

delete, setelah dipilih maka sistem akan menghapus data

indeks dari database indeks, kemudian sistem akan

menampilkan list seluruh data indeks.

152

5. Sequence Diagram fungsi Input/Edit/Delete User Account

Super Admin

Gambar 4.37 Sequence diagram use case Input/Edit/Delete User Account

Keterangan Gambar : Pada Saat Super Admin ingin

menginput User Account maka Super Admin masuk kedalam

menu utama, kemudian memilih menu User Account. Di

menu User Account terdapat menu tambah Account,

kemudian Super Admin memilih menu tersebut, setelah

dipilih maka sistem akan menampilkan menu tambah User

Account. Apabila data Account telah dimasukan maka data

153

User Account disimpan didatabase tbmuser kemudian sistem

akan menampilkan list seluruh data User Account.

Apabila Super Admin ingin mengupdate data User

Account, Super Admin dapat memilih menu edit, setelah

dipilih maka sistem akan menampilkan menu edit, bila data

User Account telah diubah maka data User Account akan

disimpan kembali ke dalam database User Account dan

kemudian sistem akan menampilkan seluruh data User

Account. Dan apabila Super Admin ingin menghapus data

User Account, Super Admin dapat memilih menu delete,

setelah dipilih maka sistem akan menghapus data User

Account dari database tbmuser, kemudian sistem akan

menampilkan list seluruh data User Account.

154

6. Sequence Diagram fungsi Input/Edit/Delete Pengaturan

Role Super Admin

Gambar 4.38 Sequence diagram use case Input/Edit/Delete Role

Keterangan Gambar : Pada Saat Super Admin ingin

menginput Role maka Super Admin masuk kedalam menu

utama, kemudian memilih menu pengaturan. Di menu

pengaturan terdapat menu tambah Role, kemudian Super

Admin memilih menu tersebut, setelah dipilih maka sistem

akan menampilkan menu tambah Role. Apabila data Role

telah dimasukan maka data Role disimpan didatabase Role

kemudian sistem akan menampilkan list seluruh data Role.

155

Apabila Super Admin ingin mengupdate data Role,

Super Admin dapat memilih menu edit, setelah dipilih maka

sistem akan menampilkan menu edit, bila data Role telah

diubah maka data Role akan disimpan kembali ke dalam

database Role dan kemudian sistem akan menampilkan

seluruh data Role. Dan apabila Super Admin ingin

menghapus data Role, Super Admin dapat memilih menu

delete, setelah dipilih maka sistem akan menghapus data Role

dari database Role, kemudian sistem akan menampilkan list

seluruh data Role.

7. Sequence Diagram fungsi Logout

a. Sequence Diagram fungsi logout User

Gambar 4.39 Sequence diagram use case logout User

156

Keterangan gambar : Pada saat user ingin logout (keluar

dari sistem) maka user memilih menu logout. User keluar

dari sistem.

b. Sequence Diagram fungsi logout Admin

Gambar 4.40 Sequence diagram use case logout Admin

Keterangan gambar : Pada saat Admin Ortala/ admin TU Rektorat/

Super admin ingin logout (keluar dari sistem) maka admin memilih

menu logout. Kemudian keluar dari sistem.

157

4.2.1.3 Desain Basis Data

a. Perancangan Class Diagram

Pada class diagram dibawah ini, dapat kita lihat bahwa

class dibawah ini adalah class yang digunakan pada aplikasi

Sistem Repository SK UIN Jakarta.

Gambar 4.41 Class Diagram

b. Penerjemahan Entity ke dalam Basis Data

Pada class diagram terdapat entity yang dapat

diterjemahkan ke dalam bentuk tabel-tabel beserta field-

field dan relation nya ke dalam basis data.

158

1. Kategori

Nama Tabel : ketegori

Primary Key : id

Foreign Key : -

Tabel 4.21 Tabel Kategori

Nama Field Tipe Data Ukuran Keterangan

id Integer Id kategori

nama varchar 20 Nama kategori

deskripsi varchar 65535 Deskripsi kategori

2. Indeks

Nama Tabel : indeks

Primary Key : id

Foreign Key : -

Tabel 4.22 Tabel indeks

Nama Field Tipe Data Ukuran Keterangan

id Integer Id indeks

kode varchar 20 Kode indeks

deskripsi varchar 65535 Deskripsi indeks

3. Berkas

Nama Tabel : berkas

Primary Key : id

Foreign Key : id_index, id_kategori.

159

Tabel 4.23 Tabel berkas

Nama Field Tipe Data Ukuran Keterangan

id Integer Id berkas

Id_index Integer Id indeks

Id_kategori Integer Id kategori

keyPencarian varchar 50 Key pencarian

ringkasan varchar Isi ringkas sk

asal varchar 50 Asal surat

kepada varchar 50 Alamat tertuju

thnTerbit date Tahun terbit sk

status varchar 20 Status sk

berkasSk varchar 255 Keterangan berkas

Validasi1 varchar 255 Validasi Ortala

Validasi2 varchar 255 Validasi TU Rektorat

filecontent Blob Penyimpanan file

filename varchar 255 Nama file

mimetype varchar 255 Tipe file simpanan

uploaddate date Waktu upload

4. User

Nama Tabel : tbmuser

160

Primary Key : id

Foreign Key : id_index, id_tbmaccount

Tabel 4.24 Tabel tbmuser

Nama Field Tipe Data Ukuran Keterangan

id Integer Id tbmuser

Alamat varchar 65535 Alamat user

email varchar 50 Alamat email

jabatan varchar 50 jabatan

nama varchar 50 Nama user

Nip varchar 50 NIP

telp varchar 50 telepon

Id_index Integer Id indeks

Id_tbmaccount integer Id tabel account

5. Account

Nama Tabel : tbmaccount

Primary Key : id

Foreign Key : id_tbmrole

Tabel 4.25 Tabel tbmaccount

Nama Field Tipe Data Ukuran Keterangan

id Integer Id tbmaccount

username varchar 50 Username login

password varchar 50 Password login

Session_id integer Session login

161

lastLogin date Waktu login

Id_tbmrole Integer Id tbmrole

6. Role

Nama Tabel : tbmrole

Primary Key : id

Foreign Key : -

Tabel 4.26 Tabel tbmrole

Nama Field Tipe Data Ukuran Keterangan

id Integer Id role

nama varchar 20 Nama role

7. Referensi page

Nama Tabel : refpage

Primary Key : id

Foreign Key : id_tbmrole, id_parent

Tabel 4.27 Tabel refpage

Nama Field Tipe Data Ukuran Keterangan

id Integer Id refpage

depth Integer depth

Hak_akses Integer 50 Hak akses

kategori varchar 30 kategori

162

nama varchar 255 Nama label

No_order Integer Nomor order

Urlpage varchar 255 Nama url

Id_parent Integer Id parent

Id_tbmrole Integer Id tbmrole

4.2.1.4 Perancangan Desain Interface

1. Desain Interface Login

Gambar 4.42 Desain Interface Login (user, admin ortala, admin

TU rektorat, super admin)

2. Desain Interface Beranda

163

Gambar 4.43 Desain Interface Beranda (User)

Logo UINRepository SKDokumentasi Repository Surat Keputusan UIN

Beranda LogoutKontakValidasiStruktur Organisasi

Selamat datang di Sistem Repository SK Syarif Hidayatullah Jakatra

Kategori IndeksTambah Berkas Koleksi SK

Gambar 4.44 Desain Interface Beranda (Admin Ortala)

164

Gambar 4.45 Desain Interface Beranda (Admin TU Rektorat)

Gambar 4.46 Desain Interface Beranda (Super Admin)

165

3. Desain Interface Struktur Organisasi

Gambar 4.47 Desain Interface Struktur Organisasi (user, admin

ortala, admin TU rektorat, super admin)

4. Desain Interface Kontak

Gambar 4.48 Desain Interface Kontak (user, admin ortala, admin

TU rektorat, super admin)

166

5. Desain interface berkas

a. Desain interface lihat berkas

Gambar 4.49 Desain Interface lihat berkas (user)

Gambar 4.50 Desain Interface lihat berkas (Admin TU Rektorat)

167

Gambar 4.51 Desain Interface lihat/hapus berkas (Admin Ortala,

Super Admin)

b. Validasi berkas

Gambar 4.52 Desain Interface validasi berkas (Admin

Ortala)

168

Gambar 4.53 Desain Interface validasi berkas (Admin TU

Rektorat)

c. Tambah Berkas

Gambar 4.54 Desain Interface Tambah Berkas/ Edit Berkas

(Admin Ortala)

169

d. Detail Berkas

Gambar 4.55 Desain Interface Detail Berkas/ Download

Berkas (User)

Gambar 4.56 Desain Interface Detail Berkas/ Download

Berkas (Admin Ortala)

170

Gambar 4.57 Desain Interface Detail Berkas/ Download

Berkas (Admin TU Rektorat)

6. Indeks

Gambar 4.58 Desain Interface Tambah/ Edit / Delete Indeks

(Admin Ortala)

171

7. Kategori

Gambar 4.59 Desain Interface Tambah/ Edit / Delete

Kategori (Admin Ortala)

8. User

Gambar 4.60 Desain Interface Tambah/Edit/Hapus User (Super

Admin)

172

9. Pengaturan

Gambar 4.61 Desain Interface Pengaturan Hak Akses (Super

Admin)

Gambar 4.62 Desain Interface Logout

173

4.2.2. Build System

Pada tahap ini dilaksanakan implementasi dari rancangan-

rancangan, baik rancangan basis data, rancangan aplikasi, maupun

rancangan tampilan.

4.2.2.1 Bahasa Pemrograman dan Komponen

Bahasa pemrograman yang digunakan pada

pengembangan aplikasi ini adalah menggunakan java 1.6, yang

diantaranya terdiri dari java development kit dan java runtime

environment. PostgreSQL 8.2 digunakan sebagai database

untuk menyimpan data dengan menggunakan tool pgAdmin III.

Framework yang digunakan adalah ZK framework. Untuk

menjalankan codingan diperlukan application server, pada

pengembangan sistem ini digunakan apache tomcat. Untuk

editor dan unit test digunakan eclipse editor.

Pada proses pembangunan sistem terdapat beberapa

package yang dibuat diantaranya adalah:

a. Package Action

Package action ini digunakan untuk menerima request dari

user. Package action ini juga berfungsi sebagai pengontrol

proses logic, kecuali pada package action helper yang

berfungsi sebagai pembantu dari master. Untuk source code

lengkap pada package action terdapat di lampiran.

174

b. Package Common

Package ini digunakan untuk method–method cara

pehitungan misalnya pada perhitungan tanggal, hari dan

lainnya. Untuk source code lengkap pada package common

terdapat di lampiran.

c. Package Model

Package model adalah package yang digunakan

sebagai representasi dari database. Untuk source code

lengkap pada package model terdapat di lampiran.

d. Package UI

Package UI adalah package yang digunakan sebagai

tampilan dari aplikasi. Untuk source code lengkap pada

package UI terdapat di lampiran.

4.3. Implementasi

Setelah tahap desain dan codding selesai, maka untuk tahap

berikutnya adalah mengimplementasikan hasil rancangan tersebut kedalam

sebuah sistem serta melakukan testing terhadap sistem yang telah dibuat.

4.3.1. Perangkat Keras (Hardware)

Perangkat keras minimum yang mendukung sistem ini adalah

sebuah unit komputer dengan spesifikasi minimal sebagai berikut:

1. Server

a. Processor : Intel Core2Duo keatas.

b. Memory : 1GB atau lebih.

175

c. Hardisk : 250 GB atau lebih.

d. VGA Card : 32 MB.

2. Client

a. Processor : Setara dengan pentium III keatas.

b. Memory : 256 MB atau lebih.

c. Hardisk : 40 GB.

d. VGA Card : 32 MB.

4.3.2. Perangkat Lunak Sistem

Spesifikasi minimum perangkat lunak yang mendukung adalah

sebagai berikut:

1. Server

a. Microsoft Windows XP Profesional Service Pack 2 atau

windows server 2003.

b. Apache Tomcat.

c. PostgreSql.

d. Browser (Mozilla Firefox versi 3.0.6).

2. Client

a. Microsoft Windows XP Profesional Service Pack 1.

b. Browser (Mozilla Firefox versi 3.0.6)

176

4.3.3. Platform Arsitektur Teknologi

Untuk dapat mendukung aplikasi / sistem yang dihasilkan, maka

diperlukan arsitektur teknologi seperti pada gambar berikut ini:

Gambar 4.63 Platform Arsitektur Teknologi Sistem Repository SK

Pada gambar 4.63 diatas dapat dilihat bahwa untuk interface yang akan

digunakan klient adalah web, mengingat selluruh aplikasi / sistem yang

dirancang menggunakan konsep web-based. Kemudian infrastruktur

jaringan yang digunakan adalah Internet, dimana detail gambarnya akan

digambarkan pada subbab selanjutnya. Pada layer aplikasi, akan

digunakan Zkoss framework dan Java sebagai bahasa pemrograman

untuk mengembangkan aplikasi / sistem yang dirancang serta apache

Client Interface

Network

Application

Presentation

Application Integration

Database

Mozilla Firefox

Internet

Apache, Java, Zkoss

PostgreSql

Database SK

Hibernate

177

sebagai web server. Sebagai media penyimpanan data, dirancang satu

buah database dengan menggunakan PostgreSql.

4.3.4. Topologi Infrastruktur

Pemenuhan Topologi Infrastruktur dari sistem ini nantinya akan

seperti gambar dibawah ini.

Gambar 4.64 Topologi Inftastruktur Sistem Repository SK

Pada gambar 4.64 diatas dapat dilihat bahwa arsitektur jaringan

komputer dan komunikasi yang dirancang menggunakan internet.

Web Server Sistem Repository SK

178

Slanjutnya paket data yang masuk akan dikirim melalui internet

gateway dan langsung menuju web server Sistem Repository SK.

4.3.5. Pengujian Sistem

Pada tahap pengujian dilakukan dengancara Blackbox Testing.

Cara pengujian dilakukan dengan menjalankan sistem repository SK

kemudian melihat output-nya apakah telah sesuai dengan hasil

yang diharapkan. Hasil pengujian blackbox testing disajikan dalam

beberapa tabel berikut ini:

1. Role User

Tabel 4.28 Testing role User

No Test Case Prasyarat Hasil yang diharapkan Hasil uji coba

1 Login User mengakses

sistem

Masuk ke dalam sistem

repository SK.

OK

2 Melihat menu

beranda

Login sebagai

sebagai User.

User dapat melihat menu

beranda.

OK

3 Melihat

Struktur

Organisasi

Login sebagai

sebagai User

kemudian

memilih menu

Struktur

Organisasi.

User dapat melihat menu

Struktur Organisasi.

OK

4 Melihat

Koleksi SK

Login sebagai

sebagai User

User dapat melihat

Koleksi SK sesuai

OK

179

kemudian

memilih menu

Koleksi SK.

dengan unit kerja

masing-masing.

5 Download

Berkas SK.

Login sebagai

sebagai User

kemudian

memilih menu

Koleksi SK.

User dapat melakukan

download terhadap SK

yang telah di pilih.

OK

6 Pencarian SK Login sebagai

sebagai User

kemudian

memilih menu

Koleksi SK.

User dapat melakukan

pencarian terhadap SK

yang diinginkan dan

sistem dapat

menampilkan hasil

pencarian.

OK

7 Melihat

Kontak

Login sebagai

sebagai User

kemudian

memilih menu

kontak.

User dapat melihat

menu kontak.

OK

8 Logout Login sebagai

sebagai User.

User dapat keluar dari

sistem repository SK.

OK

2. Role Admin Ortala

Tabel 4.29 Testing role Admin Ortala

180

No Test Case Prasyarat Hasil yang diharapkan Hasil uji

coba

1 Login Admin Ortala

mengakses

sistem

Masuk ke dalam sistem

repository SK.

OK

2 Melihat menu

beranda

Login sebagai

sebagai Admin

Ortala.

Admin Ortala dapat

melihat menu beranda.

OK

3 Melihat

Struktur

Organisasi

Login sebagai

sebagai Admin

Ortala dan

memilih menu

Struktur

organisasi.

Admin Ortala dapat

melihat menu Struktur

Organisasi.

OK

4 Melihat

Koleksi SK

Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

koleksi SK.

Admin Ortala dapat

melihat semua Koleksi

SK yang ada pada sistem

repository SK.

OK

5 Download

Berkas SK

Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Admin Ortala dapat

melakukan download

terhadap semua SK yang

ada pada sistem

OK

181

koleksi SK. repository sk.

6 Pencarian SK Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

koleksi SK.

Admin Ortala dapat

melakukan pencarian

terhadap SK yang

diinginkan dan sistem

dapat menampilkan hasil

pencarian.

OK

7 Validasi Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

validasi.

Berkas SK yang telah di

input dapat di validasi

oleh Admin Ortala.

OK

8 Tambah

Berkas SK

Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Tambah Berkas

SK.

Berkas SK dalam

database akan bertambah

sesuai dengan jumlah

penambahan.

OK

9 Delete

Berkas SK

Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

koleksi SK.

Berkas SK akan Dihapus

dari database dan tidak

akan muncul kembali

pada layar.

OK

10 Tambah

Indeks

Login sebagai

sebagai Admin

Indeks SK dalam

database akan bertambah

OK

182

Ortala kemudian

memilih menu

Indeks.

sesuai dengan jumlah

penambahan.

11 Edit Indeks Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Indeks.

Menampilkan halaman

edit indeks.

OK

12 Delete indeks Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Indeks.

Indeks akan Dihapus dari

database dan tidak akan

muncul kembali pada

layar.

OK

13 Tambah

Kategori

Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Kategori.

Menampilkan Form

tambah Kategori dan

Kategori SK dalam

database akan bertambah

sesuai dengan jumlah

penambahan.

OK

14 Edit Kategori Login sebagai

sebagai Admin

Ortala kemudian

memilih menu

Kategori.

Menampilkan halaman

edit kategori.

OK

15 Delete Login sebagai Kategori akan Dihapus OK

183

3. Role Admin TU Rektorat

Tabel 4.30 Testing role Admin TU Rektorat

Kategori sebagai Admin

Ortala kemudian

memilih menu

Kategori.

dari database dan tidak

akan muncul kembali

pada layar.

16 Melihat

Kontak

Login sebagai

sebagai Admin

Ortala dan

memilih menu

kontak.

Admin Ortala dapat

melihat menu kontak.

OK

17 Logout Login sebagai

sebagai Admin

Ortala.

Admin Ortala dapat

keluar dari sistem

repository SK.

OK

No Test Case Prasyarat Hasil yang diharapkan Hasil uji

coba

1 Login Admin TU

Rektorat

mengakses

sistem.

Masuk ke dalam sistem

repository SK.

OK

2 Melihat menu

beranda.

Login sebagai

sebagai Admin

TU Rektorat.

Admin TU Rektorat

dapat melihat menu

beranda.

OK

184

3 Melihat

Struktur

Organisasi.

Login sebagai

sebagai Admin

TU Rektorat dan

memilih menu

Struktur

organisasi.

Admin TU Rektorat

dapat melihat menu

Struktur Organisasi.

OK

4 Melihat

Koleksi SK.

Login sebagai

sebagai Admin

TU Rektorat

kemudian

memilih menu

koleksi SK.

Admin TU Rektorat

dapat melihat semua

Koleksi SK yang ada

pada sistem repository

SK.

OK

5 Download

Berkas SK.

Login sebagai

sebagai Admin

TU Rektorat

kemudian

memilih menu

koleksi SK.

Admin TU Rektorat

dapat melakukan

download terhadap

semua SK yang ada pada

sistem repository sk.

OK

6. Pencarian SK Login sebagai

sebagai Admin

TU Rektorat

kemudian

memilih menu

koleksi SK.

Admin TU Rektorat

dapat melakukan

pencarian terhadap SK

yang diinginkan dan

sistem dapat

menampilkan hasil

pencarian.

OK

185

4. Role Super Admin

Tabel 4.31 Testing role Super Admin

7. Validasi Login sebagai

sebagai Admin

TU Rektorat

kemudian

memilih menu

validasi.

Berkas SK yang telah di

input dapat divalidasi

oleh Admin TU

Rektorat.

OK

8. Melihat

Kontak

Login sebagai

sebagai Admin

TU Rektorat dan

memilih menu

kontak.

Admin TU Rektorat

dapat melihat menu

kontak.

OK

9. Logout Login sebagai

sebagai Admin

TU Rektorat.

Admin TU Rektorat

dapat keluar dari sistem

repository SK.

OK

No Test Case Prasyarat Hasil yang diharapkan Hasil uji

coba

1 Login Super Admin

mengakses

sistem.

Super Admin Masuk ke

dalam sistem repository

SK.

OK

2 Tambah User Login sebagai

sebagai Super

Sistem menampilkan

form tambah user dan

OK

186

Admin

kemudian

memilih menu

User.

jika dilakukan input pada

form maka user dalam

database akan bertambah

sesuai dengan jumlah

penambahan.

3 Edit User Login sebagai

sebagai Super

Admin

kemudian

memilih menu

User.

Menampilkan halaman

edit User.

OK

4 Delete User Login sebagai

sebagai Super

Admin

kemudian

memilih menu

User.

User akan Dihapus dari

database dan tidak akan

muncul kembali pada

tampilan list user.

OK

5 Tambah Role Login sebagai

sebagai Super

Admin

kemudian

memilih menu

Pengaturan.

Super Admin dapat

melakukan tambah role

sebagai hak akses.

OK

6. Edit Role Login sebagai

sebagai Super

Admin

Menampilkan halaman

edit Role.

OK

187

kemudian

memilih menu

Pengaturan.

7. Delete Role Login sebagai

sebagai Super

Admin

kemudian

memilih menu

Pengaturan.

Role akan Dihapus dari

database dan tidak akan

muncul kembali pada

tampilan list role.

OK

8. Tambah Page

Role

Login sebagai

sebagai Super

Admin

kemudian

memilih menu

Pengaturan.

Super Admin dapat

melakukan penambahan

page role sebagai menu

yang nantinya dapat

diakses oleh masing-

masing role yang telah

dibuat.

OK

9. Edit Page

Role

Login sebagai

sebagai Super

Admin

kemudian

memilih menu

Pengaturan.

Menampilkan halaman

edit Page Role dan dapat

melakukan perubahan

terhadap page yang

sebelumnya sudah ada.

OK

10. Delete Role Login sebagai

sebagai Super

Admin

kemudian

Page Role dapat Dihapus

dari database dan tidak

akan muncul kembali

pada tampilan list page

OK

188

memilih menu

Pengaturan.

role.

11. Logout Login sebagai

sebagai Super

Admin.

Super Admin dapat

keluar dari sistem

repository SK.

OK

189

4.3.6. Acceptance Testing (Pengujian Penerimaan)

Pengujian penerimaan sistem dilakukan oleh Kepala Subbag

Ortala yaitu Bapak Bambang Prihono S.H yang diwakili oleh Bapak

Eddyarsya Alan Alfiqri selaku Adminstrasi Pegawai. Pengujian

dilakukan dengan menggunakan motode blackbox testing. Bukti

terlampir uji coba yang dilakukan dapat dilihat pada bagian lampiran.

Secara ringkas, hasil pengujian yang dapat penulis simpulkan adalah

sebagai berikut :

Tabel 4.32 Pengujian Penerimaan Sistem

No Pengujian Penilaian

1. Fitur aplikasi secara keseluruhan Baik

2. Fitur untuk Admin Ortala Baik

3. Fitur untuk Admin TU Rektorat Baik

4. Fitur untuk User Baik

5. Tampilan Aplikasi Baik

6. Kestabilan Aplikasi Baik

7. Kesesuaian dengan Kebutuhan Baik

190

BAB V

KESIMPULAN DAN SARAN

Perancangan dan pembangunan sistem repository SK UIN Syarif

Hidayatullah Jakarta ini setidaknya dapat mengurangi permasalahan-

permasalahan yang berhubungan dengan birokrasi, penyimpanan dan pengaksesan

data kembali.

Setelah melakukan serangkaian penelitian, maka pada bab ini penulis

akan menguraikan kesimpulan yang dapat ditarik dari rangkaian penelitian

tersebut. Selain kesimpulan, penulis juga memberikan saran yang akan

bermanfaat bagi pihak-pihak yang akan melanjutkan pengembangan penelitian

ini.

5.1 Kesimpulan

Dari penelitian dan tulisan yang telah penulis uraikan, maka dapat

ditarik kesimpulan sebagai berikut.

1. Dengan tersimpannya Berkas SK pada Sistem Repositori SK, maka dapat

memudahkan para pimpinan unit bagian dalam mengakses kembali

berkas SK apabila suatu saat dibutuhkan.

2. Sistem Repository SK dapat membantu sebagai wadah untuk

mendokumentasikan hasil Keputusan Pimpinan yang ada dilingkungan

UIN Jakarta yang dapat diakses langsung dan diakui legalitas serta

keaslian datanya.

191

3. Sistem Repository SK dapat menampilkan berkas SK secara utuh sesuai

dengan berkas fisik/aslinya.

4. Tersedianya media sentralisasi berkas SK di lingkungan UIN Jakarta.

5.2 Saran

Sistem Repository ini masih dapat dikembangkan lebih jauh. Ada

beberapa hal yang dapat dijadikan pertimbangan untuk pengembangan

selanjutnya yaitu sebagai berikut:

1. Fitur dari aplikasi yang dirancang harus terus disesuaikan dengan

perkembangan terbaru di Subbagian ORTALA UIN Jakarta, agar dapat

terus up to date.

2. Penggunaan security sistem untuk keamanan dari berkas SK yang

diupload.

3. Sistem aplikasi ini belum memiliki sistem report dari data-data yang telah

disimpan. Kiranya kedepannya dapat dibuat sebuah fitur yang dapat

menghsilkan output berupa report yang dapat dijadikan sebagai bahan

laporan kepada atasan/pimpinan.

192

DAFTAR PUSTAKA

Arianto, S. (2008, Oktober 5). Pengenalan Web Framework: Apache Struts.

Retrieved November 3, 2011, from Suhe arie's Pages: Programer Juga

Manusia: http://suhearie.wordpress.com/2008/10/05/pengenalan-web-

framework-apache-struts/

Basuki, Awan Pribadi. 2010. Membangun Web Berbasis PHP dengan Framework

Codeigniter. Penerbit Lokomedia : Yogyakarta.

Bauer, C., & King, G. (2007). Java Persistance with Hibernate (Vol. Revised

Edition of Hibernate in Action). Greenwich: Manning.

Chen, H., & Cheng, R. (2007). ZK Ajax Without Javascript Framework. (S. Anglin, Ed.) United State of America: Apress.

Chendawan, Lie. 2008. Analisa dan Perancangan Knowledge Repository System

pada PT. Bimasakti Usindo Persada ( Studi Kasus: SubDivisi Korwil

Departemen Penjualan). Skripsi Tidak Diterbitkan.

Darsena, Fredy. Ariasari, Fany dan Kurniawati, Dian. 2005. Analisis dan

Perancangan Knowledge Repository Untuk Mendukung Organisasi

Pembelajaran (Studi Kasus: Programming Division PT. Rajawali Citra

Televisi indonesia). Skripsi Tidak Diterbitkan.

Dept. Pendidikan Nasional, 2008. Kamus Besar Bahasa Indonesia Pusat Bahasa

Edisi Keempat. Penerbit PT. Gramedia Pustaka Utama : Jakarta.

193

Dennis, A., Wixom, B. H., & Tegarden, D. (2005). System Analysis and Design

with UML: An Object Oriented Approach (2nd ed., Vol. version 2.0).

United States of America: John Wiley and Sons, Inc.

Echols, M.John and Shadily, Hassan. 2006. Kamus Inggris Indonesia. Penerbit

PT. Gramedia Pustaka Utama: Jakarta.

Fikri Rijalul, Adam Ipam Fuadin dan Prakoso Imam. 2004. Pemrograman Java.

Penerbit Andi. Yogyakarta.

Fowler, M. 2005. UML Distilled edisi 3 Panduan Singkat Bahasa Pemodelan

Objek Standar. Andi : Jogjakarta.

Hariyanto, Bambang. 2004. Sistem Manajemen Basis Data. Penerbit Informatika:

Bandung.

Jogiyanto, H.M. 1999. Pengenalan Komputer: Dasar Ilmu Komputer

Pemrograman Sistem Informasi dan Intelegensi Buatan Edisi 3. Penerbit

Andi: Jogjakarta.

Jogiyanto, H.M. 2001. Analisis Dan Desain Sistem Informasi Pendekatan

Terstruktur Teori dan Praktek Aplikasi Bisnis. Penerbit Andi: Yogyakarta.

Jogiyanto, H.M. 2005. Sistem Teknologi Informasi : Pendekatan Terintegrasi

Konsep Dasar, Teknologi, Aplikasi, Pengembangan dan Pengelolaan

Edisi 2. Penerbit Andi: Yogyakarta.

Kadir, Abdul. 2003. Pengenalan Sistem Informasi. Penerbit Andi: Yogyakarta.

194

Kendal, Kenneth E. Dan Kendal, Julie E. 2010. Analisis dan Perancangan Sistem

Edisi Kelima. Penerbit PT INDEKS: Jakarta.

Kendal, Kenneth E. Dan Kendal, Julie E. 2003. System Analysis and Design Edisi

5. Penerbit PRENHALLINDO: Jakarta.

Ladjmudin, Al-Bahra, Bin. 2005. Analisa dan Desain Sistem Informasi, Penerbit

Graha Ilmu: Yogyakarta.

Mcleod, Raymond dan Schell, George. 2004, Sistem Informasi Manajemen.

Penerbit PT INDEKS: Jakarta.

Munawar, 2005. Pemodelan Visual dengan UML. Penerbit Graha Ilmu:

Yogyakarta.

Nugroho, Adi. 2005. Analisis dan Perancangan Sistem Informasi dengan

Metodologi Berorientasi Objek. Penerbit Informatika: Bandung.

Nurbaity, Siti. 2010. Pengembangan Sistem Informasi Kepegawaian (SIMPEG)

Berbasis Web Studi Kasus Subbag Administrasi Kepegawaian Pusat UIN

Syarif Hidayatullah Jakarta. Skripsi Tidak Diterbitkan.

Object Relational Mapping (ORM) Object Oriented Programming. (2010, Desember 11).

Potix Corporation. (2007). Simply Rich ZK The Developer's Guide (Revisiton 158 ed., Vol. 2.4.0). Potix Corporation.

Pressman, Roger, S. 2002. Rekayasa Perangakat Lunak Pendekatan Praktis

(Buku I). Penerbit Andi, Yogyakarta.

195

Raymond mcLeod, Jr dan Deorce Schell. 2004. Sistem Informasi Manajemen.

Jakarta : PT Index

Sidik, Ir, Betha. 2004. MYSQL untuk Pengguna, Administrator, dan

Pengembangan Aplikasi Web. Penerbit Informatika: Bandung.

Sholiq. 2006. Pemodelan Sistem Informasi Berorientasi Objek dengan UML.

Penerbit Graha Ilmu: Jogjakarta.

Simarmata, J. (2010). Rekayasa Web: Analisis dan Desain Sistem, Rekayasa

Informasi, Rekayasa Hypermedia, Interaksi Manusia dan Komputer,

Rekayasa Kebutuhan, Data Mining, Manajemen Proyek. Penerbit Andi :

Yogyakarta.

UIN Jakarta. 2002. STATUTA Universitas Islam Negeri (UIN) Syarif

Hidayatullah Jakarta.

Whitten, Jeffery L., Lonnie D. Bentley, Kevin C.Dittman.2004. Metode Desain

dan Analisis Sistem. Edisi 6. Alih bahasa. Penerbit Andi: Yogyakarta.

Wilsen, Ricky.Yenata, Ricky dan Wahyuni. 2007. Analisis dan Perancangan

Knowledge Repository pada Divisi Operasional P. Bayu Buana Tbk.

Skripsi Tidak Diterbitkan.

Yuliardi, Rafiq. Panduan Administrasi Database PostgreSQL Versi 1.4. Yuliardi

192

LAMPIRAN - LAMPIRAN

Lampiran I. Wawancara

Lampiran II. User Interface

Lampiran III. Testing

Lampiran IV. Codding

193

Lampiran I. Wawancara

Dalam pengumpulan data, penulis melakukan wawancara dengan Bapak

Bambang Prihono, SH pada Subbag Ortala dibawah naungan Bagian Ortala dan

Kepegawaian Biro AUK Universitas Islam Negeri Syarif Hidayatullah Jakarta.

Berikut beberapa petikan hasil wawancara yang dilakukan oleh penulis.

1. Apa saja tugas dan fungsi pada subbag Ortala?

Subbag Organisasi Tata Laksana dan perundang-undangan memiliki tugas

dan fungsi menangani masalah perundang-undangan, menghasilkan

peraturan-peraturan dan hukum yang ada di UIN juga mengurusi

pengelolaan tenaga honorer.

2. Kategori Sk apa saja yang ditangani di subbag Ortala?

SK yang ditangani Oleh subbag ortala adalah Sk-SK yang terkait dengan

kelembagaan diantaranya adalah SK kerjasama, SK Kepanitiaan, SK

Kegiatan, dan SK Pendirian Lembaga, Dll.

3. Seberapa pentingkah penyimpanan arsip dari suatu berkas SK?

Penyimpanan arsip berkas SK sangatlah penting. Sebuah arsip sangat

dibutuhkan ketika terjadi suatu kegiatan atau wewenang yang

menyimpang serta dapat menjadi sebagai bukti yang memiliki kekuatan

hukum. Sehingga harus dijaga dan dilestarikan keberadaannya.

4. Siapa saja yang boleh melihat SK Kelembagaan?

Pihak yang dibolehkan melihat berkas SK secara utuh adalah pimpinan

dari masing-masing unit kerja / fakultas.

194

5. Bagaimana Proses penyimpanan SK yang sudah dibuat?

Saat ini proses penyimpanan terhadap berkas SK yang telah matang/jadi

yaitu disimpan dengan cara di kelompokan pada lemari-lemari arsip

berupa arsip fisik.

6. Siapa yang mengatur proses penyimpanan berkas SK?

Petugas yang menyimpan berkas arsip SK ke dalam lemari arsip adalah

semua petugas admin yang ada di subbag ortala.

7. Siapa yang mendistribusikan Prodak SK yang sudah jadi?

Apabila berkas SK sudah jadi atau siap dipublikasikan kepada yang tertuju

dalam sk tersebut, maka akan diserahkan kepada pihak expedisi pengantar

surat yang ada dilingkungan UIN jakarta untuk kemudian disampaikan

kepada alamat tertuju/ pimpinan unit.

8. Bagaimanakah penyimpanan secara digital? Apakah sudah dilakukan?

Penyimpanan berkas secara digital belum dilakukan, yang ada ialah

penyimpanan berkas master dari masing-masing SK.

9. Kendala apa saja yang timbul dalam proses pengaksesan kembali terhadap

berkas SK yang sudah jadi?

Kendala yang terjadi pada proses pengaksesan kembali adalah pencarian

data yang lambat karena belum dilakukan secara sistemik. Kemudian dari

masing-masing pimpinan unit apabila SK yang dipegangnya sudah hilang

atau rusak. Maka akan memakan waktu yang cukup lama apabila ingin

melihatnya/ jika diperlukan sebagai bukti. Lama disini karena lama dalam

birokrasi. Karena harus sesuai dengan etika birokrasi.

195

Lampiran II. (User Interface)

Halaman Login (User, Admin TU Rektorat, Admin Ortala dan Super Admin)

Halaman Beranda (User, Admin TU Rektorat, Admin Ortala dan Super Admin)

196

Halaman Struktur Organisasi (User, Admin TU Rektorat, dan Admin Ortala)

Halaman Koleksi SK (User)

197

Halaman Koleksi SK (Admin TU Rektorat, dan Admin Ortala)

Halaman Detail SK (User, Admin TU Rektorat, dan Admin Ortala)

198

Halaman Kontak (User, Admin TU Rektorat, dan Admin Ortala)

Halaman Tambah Berkas SK (Admin Ortala)

199

Halaman Validasi (Admin Ortala dan Admin TU Rektorat)

Halaman Kategori SK (Admin Ortala)

200

Halaman Indeks SK (Admin Ortala)

Halaman Pengaturan User (Super Admin)

201

Halaman Pengaturan Role User (Super Admin)

Halaman Logout (User, Admin TU Rektorat, Admin Ortala dan Super Admin)

202

Lampiran III (Testing)

203

204

Lampiran IV. Codding)

Modul Berkas

View

<?page title="All Berkas" contentType="text/html;charset=UTF-8"?> <zk> <?init class="org.zkoss.zkplus.databind.AnnotateDataBinderInit"?> <window id="window" title="" border="none" closable="false" sizable="false" position="left,top" apply="sk.action.BerkasAllAction"> <div align="center"> <label value="Koleksi Surat Keputusan UIN Syarif Hidayatullah Jakarta" style="font-size: 14px; color:#008BB6; font-weight:bold; font-family: Verdana;" /> <separator /> </div> <grid> <rows> <row> <groupbox mold="3d" id="gbxForm"> <label value="Indeks" /> <combobox id="cbxIndeks" width="300px"/> <label value="Key Pencarian" /> <textbox id="txbPencarian" /> <label value="Kategori" /> <combobox id="cbxKategori"/> <button label="Telusur Pada Koleksi Ini" onClick="" id="btnSearch" /> </groupbox> </row> </rows> </grid> <listbox id="listboxMain" visible="true" style="z" mold="paging" pageSize="10"> <listhead visible="true"> <listheader label="Key Pencarian" sort="auto" align="center" width="200px" /> <listheader label="Kategori" align="center" width="150px" /> <listheader label="Isi Ringkas" align="center" />

205

<listheader label="Unit Keja" align="center" width="250px" /> <listheader label="Action" align="center" width="120px" /> </listhead> <listitem label="" /> </listbox> <window id="showWindow" width="50%" height="33%" visible="false" mode="popup"> </window> <zscript><![CDATA[ showWindow.setVisible(false); ]]></zscript> </window> </zk>

Control

package sk.action;

import java.io.File;

import java.io.FileInputStream;

import java.io.FileOutputStream;

import java.io.InputStream;

import java.sql.Blob;

import java.util.Date;

import java.util.List;

import org.hibernate.Session;

import org.hibernate.criterion.MatchMode;

import org.hibernate.criterion.Order;

import org.hibernate.criterion.Projections;

import org.hibernate.criterion.Restrictions;

import org.zkoss.zk.ui.Component;

import org.zkoss.zk.ui.event.Event;

import org.zkoss.zk.ui.event.EventListener;

206

import org.zkoss.zk.ui.util.GenericAutowireComposer;

import org.zkoss.zkplus.databind.AnnotateDataBinder;

import org.zkoss.zkplus.hibernate.HibernateUtil;

import org.zkoss.zul.Borderlayout;

import org.zkoss.zul.Button;

import org.zkoss.zul.Center;

import org.zkoss.zul.Combobox;

import org.zkoss.zul.Filedownload;

import org.zkoss.zul.Grid;

import org.zkoss.zul.Hbox;

import org.zkoss.zul.Label;

import org.zkoss.zul.Listbox;

import org.zkoss.zul.Listcell;

import org.zkoss.zul.Listitem;

import org.zkoss.zul.ListitemRenderer;

import org.zkoss.zul.Messagebox;

import org.zkoss.zul.Row;

import org.zkoss.zul.Rows;

import org.zkoss.zul.SimpleListModel;

import org.zkoss.zul.South;

import org.zkoss.zul.Textbox;

import org.zkoss.zul.Toolbarbutton;

import org.zkoss.zul.Window;

import common.Common;

import sk.database.model.Berkas;

import sk.database.model.BerkasFile;

import sk.database.model.Index;

import sk.database.model.Kategori;

import sk.database.model.Tbmaccount;

import sk.database.model.Tbmuser;

207

public class BerkasAllAction extends GenericAutowireComposer {

private static int increments;

Berkas selectedBerkas;

Berkas selectedFormBerkas;

BerkasFile berkasFile;

Textbox txbPencarian;

public Combobox cbxKategori, cbxIndeks;

Listbox listboxMain;

AnnotateDataBinder binder;

Button btnSearch;

Object kode;

public Label lblKodeIndeks, lblIsi, lblFakultas, lblAsal, lblKepada,

lblThnTerbit, lbladmUpload, lbladmValidasi, lblStatusBerkas;

private Textbox kodeindex;

public Window showWindow;

@Override

public void doAfterCompose(Component comp) throws Exception {

// TODO Auto-generated method stub

super.doAfterCompose(comp);

binder = new AnnotateDataBinder(comp);

//System.out.print("masuk action");

Common.insertCombo(cbxKategori, "deskripsi", Kategori.class);

Common.insertCombo(cbxIndeks, "deskripsi", Index.class);

onSearch();

btnSearch.addEventListener("onClick", new EventListener() {

208

public void onEvent(Event arg0) throws Exception {

// TODO Auto-generated method stub

onSearch();

}

});

}

public void onSearch() {

Session em = HibernateUtil.currentSession();

Tbmaccount acc = Common.getAccountSession();

List<Tbmuser> user = em.createCriteria(Tbmuser.class)

.createAlias("tbmaccount", "a")

.add(Restrictions.eq("a.id", acc.getId()))

.list();

System.out.println("user : " + user);

@SuppressWarnings("unchecked")

List<Berkas> berkas = em.createCriteria(Berkas.class)

.createAlias("index", "i")

.createAlias("kategori", "k")

.add(Restrictions.eq("i.deskripsi", cbxIndeks.getSelectedItem()==null?"0":((Index)cbxIndeks.getSelectedItem().getValue()).getDeskripsi()))

.addOrder(Order.asc("keyPencarian"))

.add(Restrictions.ilike("keyPencarian",

txbPencarian.getValue(), MatchMode.ANYWHERE))

.add(cbxKategori.getSelectedItem() == null ?

Restrictions.sqlRestriction("1=1") :

Restrictions.eq("kategori",cbxKategori.getSelectedItem().getValue())).list();

209

//System.out.println("berkas onSearch: " + berkas);

SimpleListModel model = new SimpleListModel(berkas);

renderListMain(model);

}

private void renderListMain(SimpleListModel model) {

// TODO Auto-generated method stub

listboxMain.setModel(model);

listboxMain.setItemRenderer(new ListitemRenderer() {

public void render(final Listitem item, Object data)

throws Exception {

// TODO Auto-generated method stub

final Berkas dataBerkas = (Berkas) data;

System.out.println("Id berkas di akhir: " +dataBerkas.getId());

new Listcell("" + dataBerkas.getKeyPencarian()).setParent(item);

new Listcell("" + dataBerkas.getKategori().getDeskripsi())

.setParent(item);

new Listcell("" + dataBerkas.getRingkasan()).setParent(item);

new Listcell("" + dataBerkas.getIndex().getDeskripsi())

.setParent(item);

// System.out.println(dataBerkas.getKategori());

Listcell cellAction = new Listcell();

Button tombol = new Button();

tombol.setLabel("Detail");

tombol.addEventListener("onClick", new EventListener() {

public void onEvent(Event event) throws Exception {

210

TODO Auto-generated method stub

selectedBerkas = dataBerkas;

showWindow.setVisible(true);

showWindow.setTitle("Detail Berkas SK");

showWindow.onModal();

Borderlayout borderlayout = new Borderlayout();

borderlayout.setParent(showWindow);

Center center = new Center();

center.setParent(borderlayout);

Grid grid = new Grid();

grid.setParent(center);

Rows rows = new Rows();

rows.setParent(grid);

Row row = new Row();

row.setParent(rows);

row.appendChild(new Label("Kode Indeks"));

row.appendChild(new Label(selectedBerkas.getIndex()

.getKode())); row = new Row();

row.setParent(rows);

row.appendChild(new Label("Isi Ringkas"));

row.appendChild(new Label(selectedBerkas.getRingkasan()));

row = new Row();

row.setParent(rows);

row.appendChild(new Label("Asal"));

row.appendChild(new Label(selectedBerkas.getAsal()));

row = new Row();

211

row.setParent(rows);

row.appendChild(new Label("Kepada"));

row.appendChild(new Label(selectedBerkas.getKepada()));

row = new Row();

row.setParent(rows);

row.appendChild(new Label("Tahun Terbit"));

row.appendChild(new Label(selectedBerkas.getThnTerbit().toString()));

row = new Row();

row.setParent(rows);

row.appendChild(new Label("Validasi 1"));

row.appendChild(new Label(selectedBerkas.getValidasi1()));

row = new Row();

row.setParent(rows);

row.appendChild(new Label("Validasi 2"));

row.appendChild(new Label(selectedBerkas.getValidasi2())); row = new Row(); row.setParent(rows);

row.appendChild(new Label("Status Berkas")); row.appendChild(new Label(selectedBerkas.getStatus()));

South south = new South();

south.setParent(borderlayout);

Hbox hbox = new Hbox();

hbox.setParent(south);

Toolbarbutton back = new Toolbarbutton("back");

back.setParent(hbox);

back.addEventListener("onClick", new EventListener() {

public void onEvent(Event arg0) throws Exception {

212

// TODO Auto-generated method stub

showWindow.setVisible(false);

}

});

Toolbarbutton download = new Toolbarbutton("download");

download.setParent(hbox);

download.addEventListener("onClick",

new EventListener() {

public void onEvent(Event arg0)

throws Exception {

// TODO Auto-generated method stub

// Berkas berkasFile = (Berkas) HibernateUtil

// .currentSession()

// .createCriteria(

// Berkas.class)

// .add(Restrictions.eq("id",

// selectedBerkas.getId()))

// .setMaxResults(1)

// .uniqueResult();

Blob content = (Blob) HibernateUtil

.currentSession()

.createCriteria( Berkas.class)

.setProjection(

Projections

.property("fileContent"))

.add(Restrictions.eq("id",

213

selectedBerkas.getId()))

.setMaxResults(1)

.uniqueResult();

Filedownload

.save(createInputStreamFromFile(content),

selectedBerkas.getMimeType(),

selectedBerkas.getFileName());

}

});

}

});

tombol.setParent(cellAction);

cellAction.setParent(item);

tombol = new Button();

tombol.setLabel("Delete");

tombol.addEventListener("onClick", new EventListener() {

public void onEvent(Event e) throws Exception {

// TODO Auto-generated method stub

Messagebox.show("Apakah anda yakin menghapus data ini?",

"Question", Messagebox.OK | Messagebox.CANCEL,

Messagebox.QUESTION, new EventListener() {

public void onEvent(Event e)

throws Exception {

// TODO Auto-generated method stub

214

Integer i = new Integer(e.getData()

.toString());

if (i == Messagebox.CANCEL)

return;

else {

Session em = HibernateUtil.currentSession();

//selectedBerkas = dataBerkas;

System.out.println("Id berkas di Delete: " +dataBerkas.getId());

em.delete(dataBerkas); Messagebox.show("Data berhasil dihapus");

onSearch();

clearForm();

}

}

});

}

});

tombol.setParent(cellAction);

cellAction.setParent(item);

}

});

}

public List<BerkasFile> getBerkas(){

Session em = HibernateUtil.currentSession();

List<BerkasFile> berkas = em.createCriteria(BerkasFile.class)

.add(Restrictions.eq("berkas", selectedBerkas)).list();

return berkas;

215

}

public static FileInputStream createInputStreamFromFile(Blob blob) {

InputStream inputStream = null;

FileInputStream fileInputStream = null;

try {

inputStream = blob.getBinaryStream();

File file = getCreateRandomFile();

FileOutputStream outputStream = new FileOutputStream(file);

int c;

while ((c = inputStream.read()) != -1) {

outputStream.write(c);

}

outputStream.close();

inputStream.close();

fileInputStream = new FileInputStream(file);

} catch (Exception e) {

e.printStackTrace();

}

return fileInputStream;

}

public static File getCreateRandomFile() {

File myFile = new File(("/opt/file_siri/" + (new Date().getTime())

+ "_" + (++increments)));

myFile.getParentFile().mkdirs();

return myFile;

}

public void clearForm(){

binder.loadAll();

216

}

}

Model

package sk.database.model;

// Generated 19 Agu 11 15:20:12 by Hibernate Tools 3.2.2.GA

import java.sql.Blob;

import java.util.Date;

import javax.persistence.CascadeType;

import javax.persistence.Column;

import javax.persistence.Entity;

import javax.persistence.FetchType;

import javax.persistence.GeneratedValue;

import javax.persistence.OneToOne;

import javax.persistence.Temporal;

import javax.persistence.TemporalType;

import static javax.persistence.GenerationType.IDENTITY;

import javax.persistence.Id;

import javax.persistence.JoinColumn;

import javax.persistence.ManyToOne;

import javax.persistence.Table;

/**

* Berkas generated by hbm2java

*/

@Entity

@Table(name = "berkas")

217

public class Berkas implements java.io.Serializable {

private Integer id;

private Index index;

private Kategori kategori;

private String keyPencarian;

private String ringkasan;

private String asal;

private String kepada;

private Date thnTerbit;

private String status;

//private String berkasSk;

private String validasi1;

private String validasi2;

private Blob fileContent;

private String mimeType;

private String fileName;

//public static final String tarbiyah = "F1";

public Berkas() {

}

public Berkas(String keyPencarian, String ringkasan, String asal,

String kepada, Date thnTerbit, String status, String berkasSk,String validasi1, String validasi2) {

this.keyPencarian = keyPencarian;

this.ringkasan = ringkasan;

this.asal = asal;

this.kepada = kepada;

this.thnTerbit = thnTerbit;

218

this.status = status;

//this.berkasSk = berkasSk;

this.validasi1 = validasi1;

this.validasi2 = validasi2;

}

public Berkas(Index index, Kategori kategori, String keyPencarian,

String ringkasan, String asal, String kepada, Date thnTerbit,

String status, String berkasSk, String validasi1, String validasi2) {

this.index = index;

this.kategori = kategori;

this.keyPencarian = keyPencarian;

this.ringkasan = ringkasan;

this.asal = asal;

this.kepada = kepada;

this.thnTerbit = thnTerbit;

this.status = status;

//this.berkasSk = berkasSk;

this.validasi1 = validasi1;

this.validasi2 = validasi2;

}

@Id

@GeneratedValue(strategy = IDENTITY)

@Column(name = "id", unique = true, nullable = false)

public Integer getId() {

return this.id;

}

public void setId(Integer id) {

219

this.id = id;

}

@ManyToOne(cascade = CascadeType.REMOVE)

@JoinColumn(name = "id_index", nullable=true)

public Index getIndex() {

return this.index;

}

public void setIndex(Index index) {

this.index = index;

}

@ManyToOne(cascade=CascadeType.REMOVE)

@JoinColumn(name = "id_kategori", nullable=true)

public Kategori getKategori() {

return this.kategori;

}

public void setKategori(Kategori kategori) {

this.kategori = kategori;

}

@Column(name = "key_pencarian", nullable = false, length = 50)

public String getKeyPencarian() {

return this.keyPencarian;

}

public void setKeyPencarian(String keyPencarian) {

this.keyPencarian = keyPencarian;

}

220

@Column(name = "ringkasan", nullable = false, length = 65535)

public String getRingkasan() {

return this.ringkasan;

}

public void setRingkasan(String ringkasan) {

this.ringkasan = ringkasan;

}

@Column(name = "asal", nullable = false, length = 50)

public String getAsal() {

return this.asal;

}

public void setAsal(String asal) {

this.asal = asal;

}

@Column(name = "kepada", nullable = false, length = 50)

public String getKepada() {

return this.kepada;

}

public void setKepada(String kepada) {

this.kepada = kepada;

}

@Column(name = "thnTerbit", nullable = true)

221

@Temporal (TemporalType.DATE)

public Date getThnTerbit() {

return thnTerbit;

}

public void setThnTerbit(Date thnTerbit) {

this.thnTerbit = thnTerbit;

}

@Column(name = "status", nullable = true, length = 20)

public String getStatus() {

return this.status;

}

public void setStatus(String status) {

this.status = status;

}

/*@Column(name = "berkas_sk", nullable = true)

public String getBerkasSk() {

return this.berkasSk;

}

public void setBerkasSk(String berkasSk) {

this.berkasSk = berkasSk;

}*/

@Column(name = "validasi1", nullable = true)

public String getValidasi1() {

return validasi1;

222

}

public void setValidasi1(String validasi1) {

this.validasi1 = validasi1;

}

@Column(name = "validasi2", nullable = true)

public String getValidasi2() {

return validasi2;

}

public void setValidasi2(String validasi2) {

this.validasi2 = validasi2;

}

@Column(name = "filecontent", nullable = true)

public Blob getFileContent() {

return fileContent;

}

public void setFileContent(Blob fileContent) {

this.fileContent = fileContent;

}

@Column(name = "mimetype", nullable = true)

public String getMimeType() {

return mimeType;

}

public void setMimeType(String mimeType) {

223

this.mimeType = mimeType;

}

@Column(name = "filename", nullable = true)

public String getFileName() {

return fileName;

}

public void setFileName(String fileName) {

this.fileName = fileName;

}

}