Perancangan Aplikasi Sistem Informasi Surat Masuk dan ...
20
Perancangan Aplikasi Sistem Informasi Surat Masuk dan Surat Keluar (Studi Kasus : Dinas Pangan Kota Salatiga) DI SUSUN OLEH: Ravensca Matatula Augie David Manuputty, S.Kom., M.Cs. Program Studi Sistem Informasi Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
Transcript of Perancangan Aplikasi Sistem Informasi Surat Masuk dan ...
Perancangan Aplikasi Sistem Informasi Surat Masuk dan Surat Keluar
(Studi Kasus : Dinas Pangan Kota Salatiga)
DI SUSUN OLEH:
Ravensca Matatula
Augie David Manuputty, S.Kom., M.Cs.
Program Studi Sistem Informasi
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
1. PENDAHULUAN
Dengan perkembangan zaman sekarang,
teknologi komunikasi berkembang begitu pesat,
banyak bermunculannya alat komunikasi. Namun
bagi organisasi, terdapat alat komunikasi yang
tidak dapat ditinggalkan yaitu komunikasi tertulis
berbentuk surat. Hal ini karena banyak persoalan
yang hanya dapat diselesaikan secara efektif dan
efisien melalui komunikasi surat menyurat. Surat
juga menjadi penting karena surat dapat menjadi
tanda bukti yang otentik, menjadi pedoman
dalam melaksanakan suatu tugas atau pekerjaan,
menjadi alat pengingat atau berfikir,
menjadi duta atau wakil pengirim surat, dan
sebagai bukti historis. Surat membantu
memperlancar tercapainya tujuan organisasi [1].
Penanganan surat tidak hanya sebatas mencatat
surat masuk dan surat keluar, tetapi juga terdapat
proses mendistribusikan surat, dan mengarsip
surat. Dibutuhkan sistem yang baik dalam hal
penanganan surat agar surat dapat
diorganisasikan dengan baik, terawat dengan
baik, dan mudah ditemukan kembali pada saat
dibutuhkan. Bagi lembaga negara, tujuan
kearsipan ialah untuk menjamin keselamatan
bahan pertanggungjawaban nasional tentang
perencanaan, pelaksanaan dan penyelenggaraan
kehidupan kebangsaan serta untuk menyediakan
bahan pertanggungjawaban tersebut bagi
kegiatan Pemerintah [1].
Instansi atau organisasi tidak boleh melakukan
kesalahan dalam proses pengelolaan data-data
surat yang ada, misalnya terdapat surat yang
tercecer atau rusak, terdapat surat yang hilang,
dan lain sebagainya. Hal ini dapat menyebabkan
kerugian bagi organisasi tersebut.
Dalam pengolahan surat-surat pada Dinas
Pangan Kota Salatiga hingga kini terdapat
permasalan yang terjadi, seperti: (1) tidak semua
surat terarsipkan dengan baik; (2) kesalahan
pencatatan nomor surat; (3) kesalahan pembuatan
alamat tujuan disposisi; dan (4) hilangnya surat.
Kendala-kendala tersebut disebabkan oleh
beberapa hal, yaitu: (1) banyaknya jumlah surat
masuk dan keluar; (2) tidak semua surat
diserahkan pada petugas pengelola surat tetapi
masih disimpan dimasing-masing bidang yang
berkepentingan atau tujuan dari surat tersebut;
(3) pegawai yang meminjam surat tidak
mengembalikan pada petugas pengelola surat;
dan (4) ada banyak tujuan disposisi surat.
Dinas Pangan Kota Salatiga membutuhkan
sistem informasi berbasis komputer yang dapat
membantu dalam proses penanganan surat dan
dapat mengatasi permasalahan yang terjadi.
Diharapkan dengan adanya sistem ini dapat
mengurangi penggunaan waktu yang cukup lama
dalam pengarsipan surat, memperkecil terjadinya
kesalahan dalam pencatatan surat, mempercepat
proses pencarian surat, memperkecil terjadinya
kehilangan surat, serta memudahkan mengontrol
disposisi surat.
2. TINJAUAN PUSTAKA
Penelitian terkait pengelolaan surat masuk dan
surat keluar telah dilakukan oleh Joko Agus
Prawono dan Anton Respati Pamungkas (2015)
dengan judul Sistem Informasi Pengolahan Surat
Masuk Dan Surat Keluar Di STMK AUB
Surkarta. Pencatatan surat masuk dan disposisi
dibuat dengan desain dan tata letak serta urutan
memasukan data yang sudah diatur sedemikian
rupa sehingga operator dapat menggunakan
sistem ini dengan mudah. Nomor surat keluar
otomatis dibuat oleh sistem sesuai format yang
berlaku di STMIK AUB setelah pengguna
memilih klasifikasi surat sehingga pengguna
tidak perlu lagi melihat buku panduan surat dan
nomor agenda [2].
Penelitian lain dilakukan oleh Andi Darlianto
dan Inggih Permana (2016) dengan judul Sistem
Informasi Pencatatan Surat Masuk (Studi Kasus:
Kantor Camat Kampar Kiri Kabupaten Kampar
Provinsi Riau). Sistem dibangun dengan
menggunakan teknik Object Oriented Analysis
and Design (OOAD). Tools yang digunakan
adalah empat buah diagram Unified Modeling
Language (UML), yaitu: usecase diagram,
sequence diagram, activity diagram dan class
diagram [3].
Iven Suriatno dan Dewi Handayani (2017)
melakukan penelitian yang berjudul Sistem
Manajemen Pengarsipan Surat Menyurat Pada
Setda Kabupaten Sarmi-Papua. Menurut mereka
pengelolaan surat di instansi yang menggunakan
sistem manual sering menimbulkan berbagi
polemik dalam implementasinya. Aplikasi sistem
manajemen pengarsipan surat menyurat
bertujuan untuk meningkatkan pengelolaan data
dan arsip surat menyurat agar lebih efektif dan
efisien. Sistem Manajemen Pengarsipan Surat
menyurat meliputi aktivitas pendataan surat dan
pengarsipan surat, kemampuan melakukan
pencarian surat, view arip, dan pelaporan surat.
Sistem Manajemen pengarsipan surat menyurat
dan database terintegrasi diharapkan dapat
meminilimasir human error yang terjadi pada
registrasi dan pengarsipan surat menyurat serta
memudahkan pelaporan dan pertanggungjawaban
bagi pihak yang membutuhkan. Kerahasiaan
surat menyurat lebih terproteksi, efisiensi dalam
pengaksesan dan keterlacakan status surat lebih
meningkat [4].
Arsip dan Manajemen Kearsipan
Menurut Barthos (2016), arsip atau warkat
adalah setiap catatan tertulis baik dalam bentuk
gambar ataupun bagan yang memuat keterangan-
keterangan mengenai sesuatu subyek (pokok
persoalan) ataupun peristiwa yang dibuat orang
untuk membantu daya ingatan. [1] Yang
termasuk dalam pengertian arsip misalnya :
surat-surat, kwitansi, faktur, pembukuan, daftar
gaji, daftar harga, kartu penduduk, bagan
organisasi, foto-foto dan lain sebagainya.
Kearsipan mempunyai peranan sebagai “pusat
ingatan”, sebagai “sumber informasi”, dan
sebagai “alat pengawasan” yang sangat
diperlukan bagi setiap organisasi dalam rangka
kegiatan perencanaan, penganalisaan,
pengembangan, perumusan kebijakan,
pengambilan keputusan, pembuatan laporan,
pertanggungjawaban, penilaian dan pengendalian
setepat-tepatnya.
Surat adalah alat komunikasi tertulis yang
berasal dari satu pihak dan akan ditujukan
kepada pihak lain untuk menyampaikan warta.
[1] Macam atau jenis surat dapat ditinjau dari
berbagai segi, misalnya :
a. Menurut wujudnya : kartu pos, warkat pos,
surat bersampul, memorandum dan nota,
telegram, surat pengantar.
b. Menurut tujuannya: surat pemberitahuan,
surat perintah, surat peringatan, surat
panggilan, surat susulan, surat keputusan,
surat laporan, surat perjanjian, surat
penawaran, pesanan dan lain-lain.
c. Menurut sifat dan asalnya: surat dinas, surat
niaga, surat pribadi, surat yang isinya
masalah sosial.
d. Menurut jumlah penerima: surat biasa, surat
edaran, surat pengumuman
e. Menurut keamanan isinya: surat sangat
rahasia, surat rahasia, surat biasa.
f. Menurut urgensi penyelesaiannya : surat
sangat segera, surat segera, surat biasa.
g. Menurut prosedur pengurusannya: surat
masuk, surat keluar.
h. Menurut jangkauannya: surat intern, surat
ekstern.
Tata Cara Mengarsip Surat (Filing)
Filing adalah proses pengaturan dan
penyimpanan bahan-bahan secara sistimatis,
sehingga bahan-bahan tersebut dengan mudah
dan cepat dapat ditemukan kembali setiap kali
diperlukan. Oleh karena suatu filing yang tepat
merupakan suatu tempat penyimpanan bahan-
bahan yang aman, maka filing dapat dianggap
sebagai “ingatan” dari suatu organisasi.
Penanganan Dan Cara Mengarsip Surat
Setelah surat-surat diterima maka sekretaris
harus segera mulai pengurusan surat agar segera
dapat diserahkan kepada pimpinan secepatnya.
Proses Pengembangan Perangkat Lunak
Perangkat lunak adalah: (1) instruksi (program
komputer) yang ketika dijalankan memberikan
fitur, fungsi, dan kinerja yang diinginkan; (2)
struktur data yang memungkinkan program
untuk memanipulasi informasi, dan (3) informasi
deskriptif di hard copy dan bentuk virtual yang
menggambarkan operasi dan penggunaan
program. [5]
Menurut Sommerville terdapat 4 kegiatan
mendasar dan umum untuk semua proses
perangkat lunak. [6]
1. Spesifikasi perangkat lunak, di mana
pelanggan dan insinyur menentukan fungsi
perangkat lunak yang akan diproduksi dan
batasan pada operasinya.
2. Pengembangan perangkat lunak, di mana
perangkat lunak dirancang dan diprogram.
3. Validasi perangkat lunak, di mana perangkat
lunak diperiksa untuk memastikan bahwa itu
adalah apa yang pelanggan membutuhkan.
4. Evolusi perangkat lunak, di mana perangkat
lunak dimodifikasi untuk mencerminkan
perubahan pelanggan dan persyaratan pasar.
Object Oriented
Pemrograman Berorientasi Objek berawal dari
pemahaman bahwa setiap program adalah
simulasi dunia nyata atau virtual. Object
Oriented mempertimbangkan orang, hewan dan
benda-benda sebagai obyek dalam kehidupan ini.
Berorientasi objek pada pemrograman
menggeneralisasi pemahaman objek semacam itu
[7].
Analisis dan Design Berorientasi Objek
Dalam proses pembangunan sistem, proses
analisis dibedakan dengan proses perancangan.
Analisis untuk menjawab tentang apa dari sistem,
sedangkan perancangan untuk menjawab
bagaimana dari sistem.
Aktifitas pada saat analisis sistem ditandai
dengan pertanyaan tentang apa yang terjadi
dengan sistem yang ada saat ini dan apa yang
dibutuhkan dari sistem yang baru. Hasil akhir
dari aktifitas analisis ini adalah spesifikasi usulan
tentang apa yang akan dilakukan sistem atas
dasar kebutuhan.
Dalam perspektif OO, tahap analisis
menghasilkan model abstrak tentang apa yang
harus dilakukan(what-to do), sementara pada
fase perancangan menghasilkan dokumen
tentang bagaimanai melakukannya (exactly how
to do it). Hasil akhir perancangan ini disamping
class diagram juga termasuk interaction diagram,
state machine diagram dan juga deployment
diagram.
Secara umum perancangan sistem terbagi
menjadi dua bagian yaitu perancangan sistem
dan perancangan detil. Perancangan sistem
terkait dengan keseluruhan arsitektur sistem dan
penetapan standard yang akan dipakai saat
implementasi. Sementara perancangan detil
terkait dengan perancangan masing-masing
komponen agar sesuai dengan arsitektur sistem
dan standard yang digunakan. Dalam perspektif
OO, perancangan detil terkait dengan
perancangan class dan obyek serta interaksi
diantara mereka.
Unified Modeling Language
UML (Unfied Modelling Language) adalah salah
satu alat bantu yang sangat handal di dunia
pengembangan sistem yang berorientasi obyek.
Hal ini disebabkan karena UML menyediakan
bahasa pemodelan visual yang memungkinkan
bagi pengembang sistem untuk membuat cetak
biru atas visi mereka dalam bentuk yang baku,
mudah dimengerti serta dilengkapi dengan
mekanisme yang efektif untuk berbagi (sharing)
dan mengkomunikasikan rancangan mereka
dengan yang lain [8].
Tabel 1. Tabel Aktifitas Proses Pengembangan
Perangkat Lunak dengan UML Aktifitas Alat bantu Hasil Utama
Analisis
Kebutuhan
- Pemodelan use
case
- Prototyping
- Communication
diagram
- Pemodelan
Class & object
- Activity
diagram
- State machine
diagram
- Use case
diagram
- Daftar
kebutuhan
- Prototyping
Perancangan
Sistem
- Class diagram
- Sequence
diagram untuk
skenario umum
- Arsitektur
sistem
- Deployment
diagram
- Package
diagram
- Component
diagram
Perancangan
user
interface
- Class dan
Object diagram
Interaction
diagram
- State machine
diagram
- Package
diagram
- Prototyping
- Model
rancangan
dengan
spesifikasi
interface
Perancangan
manajemen
data
- Class dan
Object diagram
- Interaction
diagram
- State machine
diagram
- Package
diagram
- Spesifikasi
database
Konstruksi
- Bahasa
pemrograman
- Component
yang bisa
dipakai ulang
- DDL database
- Pembuatan
manual
- Sistem
- Dokumen-
tasi
Pengujian
- Bahasa
pemrograman
- Pengujian atas
rancangan
- Rencana
pengujian
- Pengujian
dengan
kasus
- Pengujian
sistem
Implemen-
tasi
- Perencanaan
- Training
- Migrasi data
- Sistem
terinstall
Sumber : Munawar (2018)
Codeigniter dan MVC (Model View Controller)
Codeigniter dapat disebut sebagai framework
pengembangan aplikasi dengan menggunakan
PHP. Dalam hal ini programmer tidak lagi
membuat sebuah website dari awal (from
scratch), karena Codeigniter telah menyediakan
library yang dapat dimanfaatkan untuk
menyelesaikan pekerjaan yang umum, dengan
menggunakan antarmuka dan struktur logika
yang lebih sederhana untuk mengakses
librarynya. Programmer dalam hal ini cukup
memfokuskan diri pada script atau kode-kode
yang dibuatnya sesuai dengan fungsi yang
diinginkan. [11]
MVC merupakan sebuah pola (pattern) atau
teknik pernrograman yang memisahkan
pengembangan aplikasi menjadi bagian user
interface, bagian kontrol aplikasi, dan bagian
manipulasi data. Secara sederhana dapat
dikatakan bahwa antara file kode program untuk
menghasilkan tampilan, file untuk memproses
data, file untuk logika, berada pada tempat yang
terpisah. [11]
Gambar 1. Urutan proses Model View Controller
[11]
Berikut ini dijelaskan secara singkat urutan dari
request sampai dengan memeroleh respon jika
menggunakan model MVC :
User berhubungan dengan view, dimana di view
inilah informasi atau formulir ditampilkan. Saat
user melakukan permintaan atau request,
misalkan melakukan permintaan update data
dengan cara mengklik tombol update make
request tersebut akan diproses oleh Controller.
Controller akan meminta Model untuk
menyelesaikan request tersebut. Selanjutnya dari
Model, hasil proses update akan dikirim kembali
ke controller untuk diproses lebih lanjut, dan dari
Controller akan memberikan respon ke pengguna
berupa View.
Pengujian
Prinsip utama pengujian adalah memastikan
bahwa semua kebutuhan sudah terpenuhi oleh
sistem yang baru.
Ada 2 tekmik pengujian yang biasanya
digunakan yaitu black box testing dan white box
testing.
Black box testing dilakukan dengan cara
memasukkan input ke sistem dan melihat hasil
keluarannya apakah sesuai dengan yang
diharapkan atau tidak. Bagaimana proses untuk
menghasilkan keluaran tidak dilakukan dalam
pengetesan black box testing.
Sedangkan dalam white box testing, pengujian
justru dilakukan untuk mengetahui bagaimana
proses menghasilkan keluaran (yang justru tidak
dilakukan dengan black box testing).
Tahap akhir pengujian adalah pengujian
penerimaan pengguna (user acceptance testing).,
yaitu eveluasi oleh pengguna terhadap kebutuhan
yang disepakati di awal. Hasil penerimaan
(dibuktikan dengan tanda tangan pengguna) akan
mengakhiri jalannya proyek. Biasanya
dokumentasi dari hasil analisis (khususnya yang
jadi perhatian adalah skenario use case dan
kebutuhan non fungsional) akan digunakan untuk
pengecekan produk akhir. [8]
3. METODOLOGI PENELITIAN
Metode yang digunakan yaitu metode kualitatif
yang merupakan jenis data yang tidak dapat
dihitung tetapi berupa penjelasan, catatan
observasi, dokumen, dan juga wawancara atau
angket. Metode ini digunakan karena
berdasarkan kebutuhan dan pengumpulan data
pada kantor Dinas Pangan Kota Salatiga perlu
dilakukan observasi serta wawancara untuk
memperoleh informasi yang kemudian akan
dianalisis. Metode pengumpulan data yang
dilakukan peneliti berupa hasil wawancara
dengan pihak kantor yang melibatkan kepala
dinas,sekertaris serta peneliti juga melakukan
observasi pada bagian IT Dinas Pangan kota
Salatiga. Penelitian mengikuti metode
pengembangan research and development
(R&D). Metode pengembangan R&D adalah
metode yang digunakan untuk menghasilkan
produk dan menguji keefektifan produk tersebut.
Pada penelitian ini produk yang dihasilkan
adalah perangkat lunak Sistem Informasi Surat
Masuk dan surat keluar Dinas Pangan Kota
Salatiga.
Model pengembangan R&D Borg dan Gall
(1983) terdiri atas 10 langkah. Penelitian hanya
menggunakan 6 langkah karena produk akhir
yang dihasilkan dari penelitian ini adalah bentuk
prototype dimana produk tidak sampai digunakan
atau diuji pada sistem nyata. Berikut ini 6
langkah model pengembangan R&D yang
digunakan yaitu :
1. Research and Information Collecting
(melakukan penelitian dan pengumpulan
informasi)
2. Planning (melakukan perencanaan)
3. Develop Premilnary Form of Product
(melakukan pengembangan produk
pendahuluan)
4. Premilnary Field Testing (melakukan uji coba
pendahuluan)
5. Main Product Revision (melakukan perbaikan
produk utama)
6. Main Field Testing (melakukan uji coba
utama)
Model proses R&D ditunjukkan gambar 2
sebagai berikut :
Gambar 2. Model Pengembangan R&D Borg dan
Gall yang telah dimodifikasi
Prosedur pengembangan perangkat lunak Sistem
Informasi Surat Masuk dan surat keluar Dinas
Pangan Kota Salatiga digambarkan sebagai
berikut :
Gambar 3. Prosedur Pengembangan
Desain Pengujian
Pengujian dilakukan melalui tahapan pengujian
validasi analisis dan validasi desain yang
dilakukan oleh pakar (dosen pembimbing), dan
pengujian validasi prototype oleh pemilik
proyek.
Instrument penelitian berupa formulir validasi.
Formulir validasi berisi pertanyaan yang ditinjau
dari beberapa aspek indikator, dijawab dengan
mencentang sesuai dengan kriteria nilai
1=belum/kurang, 2=antara ya dan tidak, 3=
cukup baik, 4=baik/sesuai. Jumlah pertanyaan
sebanyak 10 buah soal. Keterangan skor yang
diberikan terdapat dalam tabel 2. Skor pada form
lembar validasi.
Tabel 2. Skor pada form lembar validasi Skor Nilai
1≤ n ≤ 10 Tidak baik
11≤ n ≤ 20 Cukup
21≤ n ≤ 30 Baik
31≤ n ≤ 40 Sangat baik (valid)
Hasil penilaian dapat diketahui melalui jumlah
skor yang didapat, apakah hasil analisis dan
desain produk sudah memenuhi harapan atau
belum sesuai yang diharapkan. Kesimpulan dapat
dilihat pada tabel 3. simpulan pada formulir
validasi.
Tabel 3. Simpulan pada form lembar
validasi No Simpulan
1 Belum dapat digunakan dan harus diganti
2 Dapat digunakan dengan banyak revisi
3 Dapat digunakan dengan sedikit revisi
4 Dapat digunakan tanpa revisi
Selain simpulan pengujian, di formulir validasi
juga terdapat isian komentar dan saran perbaikan,
sehingga validator dapat memberikan masukan
untuk pengembangan atau perbaikan berikutnya.
4. HASIL DAN PEMBAHASAN
Tahapan pengembangan perangkat lunak yang
akan dilakukan mengikuti tahapan
pengembangan perangkat lunak model klasik
waterfall atau system development live circle
yang terdiri atas tahapan analisis, perancangan,
implementasi atau coding, dan pengujian.
4.1 Analisis
4.1.1 Analisis Sistem
Selama ini Dinas Pangan Kota Salatiga mencatat
dan mengalirkan dokumen secara konvensional
atau berbasis kertas. Surat yang masuk dan surat
keluar dicatat pada buku agenda surat. Distribusi
dan disposisi surat dilakukan menggunakan
Lembar Pengantar dan Lembar Disposisi. Sistem
dapat berjalan dengan baik, walapun kadang
terjadi kesulitan mencari letak surat. Dan proses
menghasilkan laporan yang relatif membutuhkan
usaha dan waktu lebih lama.
Berikut ini adalah aliran surat masuk di Dinas
Pangan Kota Salatiga saat ini:
1. Surat masuk diterima oleh Sekretaris.
Surat dibuka dan dibaca oleh sekretaris. Data
surat masuk ditulis di buku agenda surat. Data
tersebut adalah tanggal surat diterima, jenis
surat, sifat surat, tanggal surat, pengirim surat,
tujuan atau penerima surat, perihal surat.
2. Surat dibuatkan Lembar Disposisi (LD) dan
diberikan kepada kepala dinas untuk dibaca
dan didisposisikan. Lembar disposisi memuat
informasi tanggal surat, perihal surat,
pengirim surat, tujuan disposisi, perintah
disposisi, dan catatan.
3. Surat dan lembar disposisi diberikan kepada
kepala bidang atau kepala seksi yang
menerima disposisi disertai Lembar Pengantar
(LP). Apabila dibutuhkan, kepala bidang atau
kepala seksi dapat meneruskan disposisi ke
jajaran atau staf dibawahnya.
4. Surat yang telah dibaca dan ditindak lanjuti
oleh kepala bidang atau kepala seksi dan
dianggap selesai, dikembalikan ke sekretaris.
5. Surat disimpan atau diarsip oleh sekretaris
berdasarkan urutan tanggal surat masuk
sehingga memudahkan pencarian.
6. Apabila dibutuhkan informasi tentang surat
masuk, dapat dicari dan ditelusuri melalui
buku agenda surat.
Aliran surat keluar di Dinas Pangan Kota
Salatiga saat ini:
1. Daft surat dibuat oleh kepala dinas, kepala
bidang, kepala seksi, atau pimpinan lainnya.
Daft surat diperiksa oleh sekretaris dan
diparaf, kemudian diperiksa kepala dinas dan
diparaf.
2. Apabila sudah disetujui kepala dinas, surat
dicatat di buku agenda surat dan diberi nomor
surat.
3. Surat dikirim ke tujuan menggunakan jasa
pengiriman yang merupakan standar instansi.
Sistem yang baru diharapkan dapat
memanfaatkan teknologi informasi (komputer)
untuk mencatat surat masuk, mendistribusikan
surat (disposisi surat masuk) secara elektronik,
mencatat surat keluar, mencari surat, dan
menghasilkan laporan surat masuk dan laporan
surat keluar dengan cepat.
Keputusan mengembangkan perangkat lunak
diambil setelah melakukan analisis visibilitas
terhadap kebutuhan teknologi, sumberdaya
manusia, dan anggaran. Secara kemampuan
penerapan teknologi, kemampuan sumber daya
manusia, dan kemampuan pembiayaan Dinas
Pangan Kota Salatiga dianggap mampu dan tidak
akan menemui kendala yang berarti jika ingin
menerapkan sistem informasi pengelolaan surat
masuk dan surat keluar terkomputerisasi.
Menggunakan analisis berorientasi objek, maka
pada tahapan analisis kita harus mengidentifikasi
objek yang ada di sistem. Objek tersebut akan
menjadi kandidat class di perancangan sistem
informasi.
Object yang ditemukan di sistem berdasarkan
deskripsi sistem, yang dapat dijadikan sebagai
kandidat class yaitu :
(1) Instansi, (2) fungsi atau bidang, (3)
pengguna, (3) surat masuk, (4) surat keluar, (5)
jenis surat, (6) derajat surat, (7) disposisi, (8)
perintah disposisi, (9) lembar disposisi, (10)
lembar pengantar, (11) pengirim.
Class diagram hasil analisis ditunjukkan oleh
gambar 4. problem domain class hasil analisis.
Gambar 4. Problem domain class hasil analisis
4.1.2 Analisis Kebutuhan
Usecase diagram
Beberapa Skenario penggunaan sistem informasi
yang dapat diidentifikasi yaitu :
1. Sekretaris mengelola master data
Master data yang harus dikelola sekretaris
adalah data instansi, data pengguna, data
fungsi atau bagian, data jenis surat, data
derajat surat, data pengirim, dan data instruksi
disposisi.
Mengelola berarti sekretaris dapat
menampilkan, menambah, mengubah, dan
menghapus data.
Diagram usecase ditunjukkan pada gambar 5
usecase diagram mengelola master data.
Gambar 5. Usecase diagram mengelola master
data
2. Sekretaris, kepala dinas, dan kepala bidang
mengelola surat masuk
Mengelola surat masuk berarti penanganan
ketika ada surat masuk atau diterima instansi.
Sekretaris harus memasukkan data surat ke
sistem. Selanjutnya kepala dinas membuat
disposisi. Sekretaris mencetak lembar
disposisi dan lembar pengantar untuk di
sampaikan ke penerima disposisi beserta surat
asli. Surat dan disposisi dibaca oleh penerima.
Penerima disposisi mengubah status disposisi
di sistem. Setelah penanganan surat selesai,
surat, lembar pengantar, lembar disposisi, dan
surat asli diserahkan kembali ke sekretaris
untuk disimpan atau diarsip.
Diagram usecase ditunjukkan pada gambar 6
usecase diagram mengelola surat masuk.
Ganbar 6. Usecase diagram mengelola surat
masuk
3. Sekretaris mengelola surat keluar
Setelah surat keluar melalui tahapan secara
konvensional yaitu dicetak, diparaf sekretaris,
diparaf kepala dinas, dan diberi nomor surat,
sekretaris memasukkan data surat keluar ke
sistem.
Diagram usecase ditunjukkan pada gambar 7
usecase diagram mengelola surat keluar.
Gambar 7. Usecase diagram mengelola surat
keluar
4. Sekretaris membuat laporan surat masuk atau
laporan surat keluar
Apabila dibutuhkan, kepala dinas atau
sekretaris dapat membuat laporan surat masuk
dan laporan surat keluar yang tercetak.
Diagram usecase ditunjukkan pada gambar 8
usecase diagram mencetak laporan.
Gambar 8. Usecase diagram mencetak laporan
5. Pengguna mencari arsip surat
Sekteratis dan kepala dinas dapat
menampilkan seluruh data surat. Sedangkan
kepala bidang atau kepala seksi hanya dapat
menampilkan surat yang menjadi haknya
sebagai penerima surat.
Diagram usecase ditunjukkan pada gambar 9
usecase diagram mencari arsip surat.
uc kelola master data
Sekretaris
Kelola Data
Pengguna Kelola Data
Instansi
Kelola Master
Data Fungsi
Kelola Master
Data Jenis
Dokumen
Kelola Master
Data Derajat
Dokumen
Kelola Master
Instruksi
DisposisiKelola Data
Pengirim
uc kelola surat masuk
Kepala DinasSekretaris
Kepala Bidang dan
Kepala Seksi
Tambah Surat
Masuk
Menampilkan List
Surat Masuk
Tambah Data
Pengirim
Menampilkan
Notifikasi Surat
Masuk
Menampilkan
Notifikasi
Disposisi
Mengelola
Disposisi
Menampilkan
Detail Surat
Masuk
Membuat
Korespondensi
Mencetak
Lembar
Disposisi
Mencetak
Lembar
Pengantar
«extend»
«extend»
«extend»
«extend»
{hanya yang
menjadi
haknya}
«extend»
«extend»
«extend»
«extend»
uc mencetak laporan
Kepala Dinas
Sekretaris
Menampilkan
Lap. Surat Masuk
Menampilkan
Lap. Surat Keluar
Mencetak
Laporan«extend»
«extend»
Gambar 9. Usecase diagram mencari arsip surat
Secara lengkap kebutuhan fungsionalitas sistem
dapat digambarkan menggunakan usecase
diagram seperti ditunjukkan pada gambar 10.
usecase diagram sistem informasi pengelolaan
surat masuk dan surat keluar.
Gambar 10. Usecase diagram sistem informasi
pengelolaan surat masuk dan surat keluar
Berdasarkan usecase diagram diketahui
pengguna sistem yaitu :
1. Sekretaris
Yaitu pegawai dengan jawabatan sebagai
sekretaris atau kepala bagian kesekretariatan.
2. Kepala dinas
Yaitu pegawai dengan jawabatan sebagai
kepala dinas. Dalam hal ini dinas pangan
kota Salatiga.
3. Kepala bidang atau kepala seksi
Yaitu pegawai dengan jawabatan sebagai
kepala bidan atau kepala seksi yang
membawahi ssuatu bagian di dinas pangan
kota Salatiga.
Usecase sistem akan menjadi software
requirement specification yang harus dipenuhi
oleh perancang dan programmer, dan akan
diperiksa dalam pengujian perangkat lunak.
Secara lengkap usecase yang harus disediakan
sistem yaitu :
Tabel 4 Software Requirement Specification No / Usecase Aktor Keterangan
01. Kelola data
instansi
Sekretaris Edit data
instansi
02. Kelola data
pengguna
Sekretaris Tambah, edit,
hapus data
pengguna
03. Kelola master
data fungsi
Sekretaris Tambah, edit,
hapus data
fungsi/bidang
04. Kelola master
data jenis
dokumen
Sekretaris Tambah, edit,
hapus data jenis
dokumen
05. Kelola master
data derajat
dokumen
Sekretaris Tambah, edit,
hapus data
derajat dokumen
06. Kelola master
data pengirim
Sekretaris Tambah, edit,
hapus data
pengirim
07. Kelola master
data perintah
disposisi
Sekretaris Tambah, edit,
hapus data
perintah
disposisi
08. Autentifikasi /
Login
Sekretaris,
Kadinas,
Ka Bidang
Login,
memberikan
menu sesuai hak
akses, logout
09. Menampilkan
list surat
masuk
Sekretaris,
Kadinas,
Ka Bidang
Menampilkan
list surat masuk
10. Kelola surat
masuk
Sekretaris Tambah, edit
surat masuk
11. Menampilkan
notifikasi
surat masuk
Sekretaris,
Kadinas,
Ka Bidang
Menampilkan
notifikasi surat
masuk
12. Menampilkan
notifikasi
disposisi
Sekretaris,
Kadinas,
Ka Bidang
Menampilkan
notifikasi
disposisi
13. Menampilkan
detail surat
masuk
Sekretaris,
Kadinas,
Ka Bidang
Edit surat
masuk
14. Mengelola
disposisi
Kadinas Edit surat
masuk + data
disposisi
15. Membuat
korespondensi
Kadinas,
Ka Bidang
Edit surat
masuk + data
disposisi + data
korespondensi
16. Mencetak
Lembar
disposisi
Sekretaris Mencetak
Lembar
disposisi
17. Mencetak
Lembar
Pengantar
Sekretaris Mencetak
Lembar
Pengantar
18. Kelola surat
keluar
Sekretaris Tambah, Edit,
Hapus data surat
keluar
19. Menampilkan Sekretaris, Menampilkan
uc Use Case Model
Sistem Informasi Surat Masuk dan Surat Keluar - Dinas Pangan Kota Salatiga
Kepala Dinas
Sekretaris
Kelola Data
Instansi
Kelola Data
Pengguna
Kelola Surat
Masuk
Kelola Surat
Keluar
Mencetak
Lembar
Pengantar
Menampilkan
Notifikasi
Disposisi
Autentifikasi /
Login
Kelola Master
Dara Jenis
Dokumen
Menampilkan
Lap. Surat
Masuk
Kelola Master
Data Derajat
Dokumen
Menampilkan
Lap. Surat
Keluar
Kelola Master
Data Instruksi
Disposisi
Kepala Bidang dan
Kepala Seksi
Kelola Master
Data Fungsi/
Bidang
Kelola Data
Pengirim
Mencari
Arsip Surat
Menampilkan
Notifikasi Surat
Masuk
Menampilkan
Detail Surat
Masuk
Membuat
Korespondensi
Menampilkan
List Surat
Masuk
Mencetak
Laporan
«extend»
«extend»
«extend»
«include»
«extend»
«extend»
«extend»
«extend»
lap. surat
masuk
Kadinas lap. surat masuk
20. Menampilkan
lap. surat
keluar
Sekretaris,
Kadinas Menampilkan
lap. surat keluar
21. Mencetak
laporan
Sekretaris,
Kadinas Mencetak
laporan
22. Mencari arsip
surat
Sekretaris,
Kadinas,
Ka Bidang
Mencari arsip
surat sesuai hak
aksesnya
Usecase diagram harus disertai penjelasan
usecase (usecase descriptions).
Salah satu contoh penjelasan usecase ditunjukkan
pada tabel 4. penjelasan usecase kelola data surat
masuk.
Tabel 4. Contoh penjelasan usecase untuk
usecase kelola data surat masuk
Usecase Name Kelola data surat masuk
Actors Sekretaris, kepala dinas,
kepala bidang atau kepala
seksi
Summary
Description
Usecase ini mempermudah
pengguna menampilkan list
data surat masuk, menambah,
dan mengubah data surat
masuk.
Priority Harus ada
Pre-condition Pengguna telah login ke
sistem. Pengguna memiliki
data surat masuk.
Post-
condition
List data surat masuk
ditampilkan. Data surat
masuk telah bertambah atau
berubah.
Basic path 1. Pengguna memilih menu
kelola surat masuk.
2. Sistem menampilkan
halaman list data surat
masuk.
3. Pengguna memilih
tombol tambah/edit.
4. Sistem menampilkan
halaman yang sesuai.
5. Pengguna memasukan/
mengubah data, klik
tombol simpan.
6. Sistem memproses
inputan pengguna dan
menampilkan informasi
hasil proses.
Alternatif
path
- Input data bisa valid atau
tidak valid. Sistem harus
dapat menampilkan pesan
kesalahan jika input tidak
valid.
- Proses simpan data bisa
berhasil atau gagal. Sistem
harus dapat menampilkan
informasi hasil proses.
- Jika pengguna adalah
sekretaris, dia dapat
menambah surat masuk,
mencetak lembat disposisi
dan lembar pengantar.
Pengguna lainnya tidak.
- Jika pengguna adalah
kepala dinas, dia bisa
menambahkan disposisi.
Pengguna lainnya tidak.
- Jika pengguna kepala dinas
atau kepala bidang, dia bisa
menambahkan
korespondensi.
Busines rule Usecase dapat dilakukan oleh
sekretaris, kepala dinas, dan
kepala bagian / kepala seksi.
Non-
functional
requirement
Tampilan dirancang dengan
baik, mudah dipahami dan
mudah digunakan.
Untuk mempermudah tahap perancangan dan
sebagai dokumentasi, penjelasan usecase ini
harus dibuat lengkap sebanyak usecase sistem.
4.2 Perancangan
4.2.1 Perancangan Proses
Perancangan proses dilakukan menggunakan
activity diagram dan sequence diagram. Activity
diagram menggambarkan aliran proses dari sudut
pandang pengguna (user), dan sequence diagram
menggambarkan aliran proses di dalam sistem
perangkat lunak.
Berikut ini diberikan contoh activity diagram
proses menambah data surat masuk, dan
sequence diagram proses menambah surat
masuk:
Gambar 11. Activity diagram proses menambah
data surat masuk
Urutan aktivitas pengguna (sekretaris) dalam
menambah surat masuk berdasarkan diagram
yaitu :
1. Pengguna memilih menu atau klik tombol
tambah data surat masuk
2. Sistem menampilkan formulir tambah surat
masuk
3. Jika pengguna memutuskan menambah data,
dia harus memasukkan data surat masuk, klik
tombol simpan.
4. Sistem memeriksa input (validasi input). Jika
input lengkap sesuai syarat validasi, sistem
akan menyimpan data dan menampilkan
informasi hasil proses. Jika input tidak
lengkap, sistem akan menampilkan kembali
formulir tambah surat masuk disertai pesan
kesalahan.
Gambar 12. Sequence diagram proses menambah
surat masuk
Rancangan urutan perintah didalam program
ketika pengguna menambah data surat masuk
yaitu :
1. Pengguna memberikan perintah
tambah_surat masuk ke controller melalui
klik menu atau klik tombol tambah surat
masuk.
2. Controller akan memerintahkan sistem
menampilkan file view yaitu
suratmasuk_tambah_view.
3. Pengguna memasukkan data surat masuk
klik tombol simpan.
4. View akan meneruskan perintah ke controller
untuk menyimpan data surat masuk.
5. Controller melakukan validasi input atau
validasi input dapat ditangani oleh file view
sendiri.
6. Jika input tidak valid, tampilan akan tetap di
form tambah data surat masuk, ditambah
pesan kesalahan.
7. Jika input valid, Controller memerintahkan
file model suratmasuk_model untuk
menyimpan data ke basisdata (tabel surat
masuk). Hasil proses simpan dikembalikan
ke controller.
8. Controller membuatkan pesan informasi
hasil proses dan menampilkan di
suratmasuk_tambah_view.
Pembuatan activity dan sequence diagram akan
memberikan hasil berupa kebutuhan tampilan
(view) dan kebutuhan file controller dan model.
4.2.2 Perancangan Basisdata
Perancangan basisdata dilakukan
menggunakan class diagram. Berbeda dengan
class diagram yang dibuat untuk
menggambarkan static view sistem pada bagian
analisis, class diagram untuk merancang
basisdata ditambahkan stereotype <<table>>
diatas nama class atau icon “tabel” dibagian
kanan atas class. Hal ini memberikan informasi
bahwa class tersebut mewakili sebuah tabel.
Bagian property diberikan stereotype
<<column>> yang memberikan informasi
bahwa bagian tersebut mewakili nama field tabel.
Bagian method digunakan untuk memberikan
informasi field yang menjadi primary key dan
foreign key dengan diberi stereotype <<pk>>
dan <<fk>>. Field yang unik diberi stereotype
<<unique>>.
Hubungan antar tabel diwakili garis
asosiasi, dan ditambahkan informasi atau nama
asosiasi. Nama asosiasi yang digunakan adalah
“memiliki”. Misal surat_masuk memiliki
act Menambah surat masuk
Sistem Informasi Pengelolaan Surat Masuk dan Surat KeluarSekretaris
Mulai
Pilih menu atau klik
tombol tambah surat
masuk
Menampilkan
form tambah data
surat masuk
Tambah data
surat masuk ?
Melihat form tambah
surat masuk
Input data
surat masuk
Klik tombol
simpan
Validasi
input
Valid?
Simpan ke tabel
surat masuk
Tampilkan
pesan
kesalahan
Selesai
Tampilkan
informasi hasil
proses
[Tidak]
[Ya]
[Ya]
[Tidak]
sd Menambah surat masuk
Sekretaris
«view»
suratmasuk_tambah_view
«Controller»
suratmasuk
«Model»
suratmasuk_model
alt Validasi Input
[Tidak Valid]
[Valid]
seq Tambah Data Surat Masuk
tampilkan form
tambah()
insert data surat masuk()
menampilkan informasi
hasil proses insert()
mengembalikan
hasil proses insert()
menampilkan form
tambah data surat
masuk()
tambah_suratmasuk()
inputkan data, klik
tombol simpan ()
menampilkan pesan
kesalahan()
insert data surat
masuk()
tampilkan pesan
kesalahan()
validasi input()
tampilkan
informasi hasil
proses insert()
pengirim, surat_masuk memiliki fungsi
(disposisi).
Class diagram perancangan basisdata
juga dilengkapi informasi multiplicity seperti
kardinalitas pada perancangan basisdata
relasional menggunakan entity relational diagram
(ERD). Multiplicity dituliskan :
1 : satu (one)
0..* : nol atau banyak (zero or many)
1..* : satu atau banyak (one or many)
Class diagram perancangan basisdata sistem
informasi pengelolaan surat masuk dan surat
keluar ditunjukkan dengan gambar 13 class
diagram perancangan basisdata.
Gambar 13. class diagram perancangan basisdata
4.2.3 Perancangan Userinterface
Perancangan userinterface dilakukan dengan
merancang struktur menu dan merancang tata
letak komponen halaman sesuai kebutuhan
tampilan. Informasi kebutuhan tampilan berasal
dari sequence diagram yaitu kebutuhan “view”
untuk semua usecase.
Berikut ini adalah contoh struktur menu, dan
salah satu contoh perancangan tata letak,
halaman tambah surat masuk.
Gambar 13. Strukur menu kepala dinas
Gambar 14. Strukur menu kepala bidang
Gambar 15. Strukur menu sekretaris
class Class Basisdata
cetak_sp
«column»
*PK sp_id: INT
* sp_number: VARCHAR(100)
print_date: DATETIME
printed_by: VARCHAR(100)
«PK»
+ PK_cetak_sp(INT)
«unique»
+ sp_number_UNIQUE(VARCHAR)
derajat
«column»
*PK derajat_kd: CHAR(3)
* derajat_nama: CHAR(20)
«PK»
+ PK_derajat(CHAR)
detail_surat
«column»
*PK detail_surat_id: INT
halaman: INT
pwk_code: VARCHAR(5)
FK arsip_kd: CHAR(20)
FK sp_id: INT
«PK»
+ PK_detail_surat(INT)
«index»
+ fk_table1_tbl_surat1_idx(CHAR)
+ fk_tbl_detail_surat_cetak_sp1_idx(INT)
«FK»
+ detail_surat_ibfk_1(CHAR)
+ detail_surat_ibfk_2(INT)
disposisi
«column»
*PK disposisi_kd: INT
*FK arsip_kd: CHAR(20)
* tgl_disposisi: DATE
* disposisi_oleh: INT
* catatan: TEXT
* disposisi_lanjutan: CHAR(1) = 'T'
«PK»
+ PK_disposisi(INT)
«index»
+ fk_tbl_disposisi_tbl_surat_idx(CHAR)
«FK»
+ disposisi_ibfk_1(CHAR)
disposisi_detail
«column»
*PK disposisi_detail_kd: INT
*FK disposisi_kd: INT
* detail_fungsi_kd: INT
* detail_terima: CHAR(1) = 'T'
* detail_korespondensi: TEXT
detail_waktu: DATETIME
surat_status_pengerjaan: CHAR(1)
detail_perhatian: CHAR(1)
«PK»
+ PK_disposisi_detail(INT)
«index»
+ fk_tbl_disposisi_detail_tbl_disposisi1_idx(INT)
«FK»
+ disposisi_detail_ibfk_1(INT)
disposisi_instruksi
«column»
*PK disposisi_instruksi_kd: INT
* arsip_kd: CHAR(20)
* instruksi_kd: INT
instruksi_perhatian: CHAR(1)
«PK»
+ PK_disposisi_instruksi(INT)
«index»
+ fk_tbl_disposisi_instruksi_tbl_surat1_idx(CHAR)
fungsi
«column»
*PK fungsi_kd: INT
* nama_fungsi: VARCHAR(150)
* status_fungsi: CHAR(1) = 'Y'
* disposisi_fungsi: CHAR(1) = 'T'
* fungsi_input: CHAR(1) = 'T'
* fungsi_urut: INT
«PK»
+ PK_fungsi(INT)
instansi
«column»
*PK id: INT
nama_instansi: VARCHAR(100)
nama_singkat_instansi: VARCHAR(100)
nama_jabatan_kepala_instansi: VARCHAR(100)
alamat_instansi: VARCHAR(255)
email_administrator: VARCHAR(50)
* email_administrator_password: VARCHAR(50)
* user_notifikasi_email: CHAR(1)
status_config: INT = 0
«PK»
+ PK_instansi(INT)
instruksi
«column»
*PK instruksi_kd: INT
* instruksi_nama: VARCHAR(100)
* instruksi_status: VARCHAR(20) = 'Aktif'
instruksi_order: INT
«PK»
+ PK_instruksi(INT)
jenis_surat
«column»
*PK jenis_kd: INT
* jenis_nama: CHAR(35)
«PK»
+ PK_jenis_surat(INT)
korespondensi
«column»
*PK korespondensi_id: INT
*FK arsip_kd: VARCHAR(20)
* user_nama: VARCHAR(255)
* korespondensi_komentar: VARCHAR(255)
* korespondensi_datetime: DATETIME
«PK»
+ PK_korespondensi(INT)
«index»
+ fk_tbl_korespondensi_tbl_surat1_idx(VARCHAR)
«FK»
+ korespondensi_ibfk_1(VARCHAR)
pengirim
«column»
*PK pengirim_kd: INT
* pengirim_nama: CHAR(100)
«PK»
+ PK_pengirim(INT)
sifat
«column»
*PK sifat_kd: INT
* sifat_nama: VARCHAR(100)
«PK»
+ PK_sifat(INT)
surat_keluar
«column»
*PK arsip_kd: VARCHAR(20)
sifat_kd: INT
surat_kd: VARCHAR(50)
FK fungsi_kd: INT
tgl_surat: DATE
perihal_surat: VARCHAR(255)
surat_file: VARCHAR(100)
no_agenda: VARCHAR(10)
jml_hal: INT
«PK»
+ PK_surat_keluar(VARCHAR)
«index»
+ fk_tbl_surat_keluar_tbl_fungsi1_idx(INT)
«FK»
+ surat_keluar_ibfk_1(INT)
surat_masuk
«column»
*PK arsip_kd: CHAR(20)
* surat_kd: CHAR(50)
*FK jenis_kd: INT
* sifat_kd: INT
*FK pengirim_kd: INT
* jabatan_pengirim: VARCHAR(50)
*FK derajat_kd: CHAR(3)
* tgl_surat: DATE
* tgl_diarsipkan: DATE
* perihal_surat: VARCHAR(255)
surat_file: VARCHAR(100)
* keterangan: VARCHAR(255)
* status_disposisi: CHAR(1) = 'T'
tgl_disposisi: DATETIME
* surat_disposisikan: CHAR(1) = 'T'
* surat_fungsi_disposisi: INT
* surat_input_fungsi: INT
surat_berkas_disposisi: VARCHAR(255)
«FK»
+ FK_surat_masuk_derajat(CHAR)
+ surat_masuk_ibfk_1(INT)
+ surat_masuk_ibfk_2(INT)
+ surat_masuk_ibfk_3(CHAR)
«PK»
+ PK_surat_masuk(CHAR)
«index»
+ fk_tbl_surat_tbl_derajat1_idx(CHAR)
+ fk_tbl_surat_tbl_jenis_surat1_idx(INT)
+ fk_tbl_surat_tbl_pengirim1_idx(INT)
user
«column»
*PK user_kd: INT
* user_nama: CHAR(25)
* user_password: CHAR(50)
* user_namalengkap: CHAR(40)
* fungsi_kd: INT
* user_status: CHAR(1)
* user_menerima_disposisi: CHAR(1) = 'Y'
* user_foto: VARCHAR(100) = 'avatar.jpg'
* user_email: VARCHAR(50)
* user_notifikasi_email: VARCHAR(50)
* koordinator_fungsi: CHAR(1) = 'T'
* home_staff: CHAR(1) = 'Y'
«PK»
+ PK_user(INT)
«index»
+ fk_tbl_user_tbl_fungsi1_idx(INT)
0..*
memiliki
1
0..*
memiliki1
0..*
memiliki
1
1
memiliki
0..*
0..*
memiliki
1
0..*
memiliki
1
0..*
memiliki
1
0..*
memiliki
1
0..*
memiliki1
1
memiliki
0..*
1memiliki
0..*
0..*
memiliki
1
Gambar 16. Rancangan tata letak halaman
tambah surat masuk
4.3 Implementasi atau coding
Implementasi basisdata dilakukan menggunakan
basisdata MySQL yang dikelola secara visual
menggunakan PHPMyadmin.
Implementasi pemrograman dilakukan
menggunakan script pemrograman web PHP
mengikuti framework codeigniter. Codeigniter
dapat mewujudkan rancangan dengan baik
karena mendukung pemrograman berorientasi
objek dan konsep MVC (Model View
Controller).
4.4 Pengujian
Pengujian perangkat lunak dilakukan
menggunakan pengujian blackbox. Sistem analis
merencanakan pengujian dan melakukan
pengujian bersama-sama dengan pemilik proyek.
Berikut ini adalah salah satu contoh pengujian
blackbox yang dilakukan :
Tabel 5. Format tabel pengujian blackbox Kode
Uji /
Des-
kripsi
Prosedur
Pengujian
Keluaran
yang
diharapkan
Hasil
Kesi
mpul
an
Uji-01
Me-
nguji
proses
login
Memasuk
kan data
tidak
lengkap
Sistem
penampilkan
pesan
kesalahan
Pesan
kesalahan
di
tampilkan
Dite-
rima
Memasuk
kan data
akun yang
Sistem
penampilkan
pesan
Pesan
kesalahan
di
Dite-
rima
tidak ada
di
basisdata
kesalahan tampilkan
Memasuk
kan data
akun yang
ada di
basisdata
Sistem
menampilka
n dashboard
pengguna
Sistem
menampil
kan
dashboard
pengguna
Dite-
rima
Pengujian dilakukan untuk seluruh usecase atau
software requirement specification yang telah
ditentukan diawal pengembangan.
Pengujian penerimaan (acceptance testing)
dilakukan dengan meminta calon pengguna
menguji perangkat lunak, dan meminta pendapat
mereka perihal perangkat lunak melalui
kuesioner yang disediakan.
Berikut ini bentuk pertanyaan yang diberikan
kepada responden atau pengguna penguji :
1. Kesesuaian solusi yang ditawarkan
dengan permasalahan
2. Kelengkapan kebutuhan fungsional dan
nonfungsional yang ditawarkan
3. Kesesuaian hasil pemrograman dengan
kebutuhan sistem
4. Pemilihan warna dan tata letak
5. Menu navigasi mudah dipahami dan
digunakan
6. Ketersediaan validasi input, dialog, dan
informasi/notifikasi hasil proses
7. Semua fitur dapat berfungsi dengan baik
8. Perangkat lunak membantu kegiatan
perusahaan
9. Perangkat lunak memberikan
kemudahan/kecepatan membuat laporan
10. Laporan yang disediakan sesuai dengan
kebutuhan
Rangkuman penilaian responden diberikan pada
tabel 7. rekapitulasi nilai hasil pengujian
penerimaan.
Tabel 7. Rekapitulasi nilai hasil pengujian
penerimaan Nomor
Pertanyaan
Nilai
User 1
Nilai
User 2
Nilai
User 3
Nilai
User 4
1 4 4 4 4
2 4 4 4 4
3 4 4 4 4
4 4 4 4 4
5 4 3 4 4
6 3 4 3 3
7 3 3 3 3
8 3 3 4 3
9 3 4 4 4
10 4 3 4 3
Total Nilai 36 36 38 36
Rata-rata nilai hasil
pengujian
36+36+38 +36 = 36,5
4
Keterangan :
1. Pengguna 1 : Sekretaris/Kepala Sekretariat
2. Pengguna 2 : Staf Bagian Umum
3. Pengguna 3 : Ka. Bidang ketersediaan dan
distribusi pangan
4. Pengguna 4 : Ka. Bidang konsumsi,
penganekaragaman dan
keamanan pangan
Hasil pengujian penerimaan oleh pengguna
memberikan skor nilai 36,5. Nilai ini didapat
dari penjumlahan total skor yang diberikan
keempat pengguna kemudian di bagi empat
sehingga menghasilkan nilai 36,5 poin. Nilai
36,4 point masuk dalam kategori indikator
4031 n . Predikat yang diberikan adalah
“Sangat Baik” sehingga dapat disimpulkan
prototype dapat digunakan tanpa revisi.
5. KESIMPULAN
Penelitian berhasil menghasilkan perangkat
lunak sistem informasi surat masuk dan surat
keluar untuk dinas pangan kota Salatiga.
Menggunakan analisis dan perancangan
berorientasi objek dengan UML sebagai bahasa
pemodelan, diagram yang dihasilkan di tahap
analisis yaitu usecase diagram untuk
menunjukkan kebutuhan pengguna, dan class
diagram untuk mengenali atau menunjukkan
objek-objek dalam sistem. Di tahap perancangan
digunakan activity diagram untuk merencanakan
langkah penggunaan aplikasi oleh pengguna, dan
sequence diagram untuk merencanakan perintah
di dalam program. Perancangan basisdata
menggunakan class diagram.
Fitur atau menu perangkat lunak yang berhasil
dibuat yaitu kelola data instansi, kelola data
pengguna, kelola master data fungsi, kelola
master data jenis dokumen, kelola master data
derajat dokumen, kelola master data pengirim,
kelola master data perintah disposisi,
autentifikasi / login, menampilkan list surat
masuk, kelola surat masuk, menampilkan
notifikasi surat masuk, menampilkan notifikasi
disposisi, menampilkan detail surat masuk,
mengelola disposisi, membuat korespondensi,
mencetak lembar disposisi, mencetak lembar
pengantar, kelola surat keluar, menampilkan lap.
surat masuk, menampilkan lap. surat keluar,
mencetak laporan, dan mencari arsip surat.
Perangkat lunak telah divalidasi melalui dua
tahap validasi yaitu validasi oleh pakar dan
validasi oleh pengguna. Validasi pakar dilakukan
pada tahap analisis dan perancangan. Validasi
oleh pengguna dilakukan pada tahap pengujian
melalui pengujian blackbox dan pengujian
penerimaan. Hasil pengujian blackbox
menunjukkan bahwa setiap usecase atau
spesifikasi kebutuhan sistem (system requirement
specification) hasil analisis kebutuhan telah
selesai dibuat, lengkap, dan dapat berjalan
dengan baik. Hasil pengujian penerimaan
menyimpulkan bahwa perangkat lunak dapat
digunakan tanpa revisi. Jadi dapat dikatakan
perangkat lunak berupa prototype dapat diterima
dan diharapkan dapat memenuhi kebutuhan
pengguna dengan baik. Walaupun demikian,
apabila ingin menerapkan sistem perangkat
lunak, instansi harus tetap didampingi analis
sistem dan programmer untuk memperbaiki bug
yang mungkin ada dan menambahkan fitur yang
mungkin diperlukan yang belum teridentifikasi
saat tahap pengembangan awal.
DAFTAR PUSTAKA
[1] Barthos, Basir. 2016. Manajemen Kearsipan
– Untuk Lembaga Negara, Swasta, Dan
Perguruan Tinggi. Jakarta : Sinar Grafika
Offset.
[2] Prawono, Joko Agus dan Anton Respati
Pamungkas. 2015. Sistem Informasi
Pengolahan Surat Masuk Dan Surat Keluar
Di STMK AUB Surkarta. INFORMATIKA
vol 2 No.1 edisi Maret 2015 ISSN 2337 –
5213.
[3] Darlianto dan Inggih Permana. 2016. Sistem
Informasi Surat Masuk (Studi Kasus: Kantor
Camat Kampar Kiri Kabupaten Kampar
Provinsi Riau). Jurnal Rekayasa dan
Manajemen Sistem Informasi, Vol. 2, No. 1,
Februari 2016 e-ISSN 2502-8995 p-ISSN
2460-8181.
[4] Suriatno, Iven dan Dewi Handayani. 2017.
Sistem Manajemen Pengarsipan Surat
Menyurat Pada Setda Kabupaten Sarmi-
Papua. Prosiding SINTAK 2017 ISBN: 978-
602-8557-20-7.
[5] Pressman, Roger S. 2010. Software
Engineering : A Practitioner’s Approach.
New York : McGraw-Hill.
[6] Sommerville, Ian. 2016. Software Enginee
ring 10th Edition. United States Of America
: Addison-Wesley Publishing Company
Inc.
[7] Pecinovský, Rudolf. 2013. OOP – Learn
Object Oriented Thinking and
Programming. Czech Republic : Tomáš
Bruckner, Řepín – Živonín.
[8] Munawar. 2018. Analisis perancangan
sistem berorientasi objek dengan UML.
Bandung : Penerbit Informatika.
