RANCANG BANGUN APLIKASI PEMBAYARAN

SUMBANGAN PEMBINAAN PENDIDIKAN (SPP) DI SMA CILEDUG GARUT

MENGGUNAKAN METODOLOGI BERORIENTASI OBJEK UNIFIED APPROACH (UA)

Yana Suryana1, Eri Satria2, Kiki Aisyah3

Jurnal Algoritma
Sekolah Tinggi Teknologi Garut
Jl. Mayor Syamsu No. 1 Jayaraga Garut 44151 Indonesia
Email : jurnal@sttgarut.ac.id
1
0906134@sttgarut.ac.id
2
erisatria@sttgarut.ac.id
3
kikiaisyah@sttgarut.ac.id

Abstrak – Sebuah sistem informasi memiliki peranan yang sangat penting bagi kelangsungan
sebuah organisasi. Oleh karena itu, hal pertama yang harus dilakukan untuk menciptakan sebuah
sistem informasi yang handal dan berkualitas adalah dengan menganalisis setiap aktivitas bisnis dari
sistem sampai didapatkan gambaran dan perilaku sistem secara utuh. Setelah itu dibuatlah suatu
perancangan yang menuangkan hasil analisis yang telah dilakukan. Kegiatan perancangan meliputi
perancangan struktur sistem serta perancangan antarmuka sistem. Pengembangan Sistem Informasi
Perpustakaan di SMA Ciledug Garut dengan fokus utama kepada proses pengajuan Transaksi
Peminjaman dan Pengembalian buku di perpustakaan. Adapun tujuan dari pengembangan sistem
informasi Perpustakaan ini adalah untuk meningkatkan efektifitas dan efisiensi dalam proses
Peminjaman dan Pengembalian buku dan menghasilkan rancangan aplikasi pengolah data buku dan
laporan dari sistem yang dirancang. Sistem dirancang dengan menggunakan metodologi
pengembangan sistem tradisional yaitu waterfall yang terdiri dari tahapan requirement analysis dan
design (Mc O’Docherty, 2005), dimana output setiap tahap merupakan input bagi tahap selanjutnya.

Kata kunci: Aplikasi, Pembayaran Keuangan, Pendidikan, Unified Approach

I. PENDAHULUAN

Pendidikan adalah usaha sadar yang terencana untuk mewujudkan suasana belajar dan
proses pembelajaran agar peserta didik secara aktif mengembangkan potensi dirinya untuk memiliki
kekuatan spiritual keagamaan, pengendalian diri, kepribadian, kecerdasan serta keterampilan.
Sekolah merupakan lembaga atau intansi untuk mewujudkan sarana kegiatan untuk media belajar
siswa didik dan mengajar pendidik yang terbentuk dalam suatu organisasi.
Keuangan sekolah merupakan kegiatan administrasi yang mengurus keluar masuknya uang
dalam suatu lembaga pendidikan, salah satunya keuangan SPP (Sumbangan Pembinaan
Pendidikan). Pengelolaan keuangan Sumbangan Pembinaan Pendidikan (SPP) sangat berpengaruh
terhadap kegiatan belajar mengajar (KBM). Pada saat ini proses Pembayaran keuangan SPP di
SMA masih belum terkomputerisasi, pada proses transaksi keuangan SPP siswa harus mengisi
terlebih dahulu form yang telah disediakan oleh bagian keuangan, kemudian di serahkan ke staff
keuangan untuk direkap kembali pada buku besar, selanjutnya ditulis pada kartu siswa sebagai
tanda bukti pembayaran yang berupa potongan kartu kecil bertuliskan bulan yang dibayar, melihat
proses yang berjalan menjadi masalah apabila tanda bukti pembayaran hilang, proses penyusunan
laporan keuangan SPP dan proses transaksi yang kurang efektip.
Oleh karena itu harus dibangun sebuah sistem untuk Pembayaran keuangan SPP
(Sumbangan Pembinaan Pendidikan) yang diharapkan akan membantu pihak sekolah, terutama staff
 ISSN: 2302-7339 Vol. 10 No. 01 2013

keuangan dalam mengelola sekaligus menyimpan data keuangan, dimana data tersebut dapat
digunakan dalam proses pembuatan laporan keuangan.
Sebagai bahan perbandingan sebelumnya telah ada penelitian yang dilakukan sebagai
berikut, pertama penelitian dengan judul Analisis dan Perancangan Aplikasi Laporan Keuangan
Daerah Pada Dinas Pendidikan, pemuda dan olahraga Kabupaten Maluku Tenggara (Pataha, 2010),
penelitian ini merupakan bentuk global yaitu mencakup seluruh dokumen laporan keuangan. Kedua
penelitian dengan judul pengembangan sistem Informasi administrasi keuangan sekolah Nopiana
(2010) dengan metodologi Waterfall, penelitian ini membahas secara keseluruhan keuangan
sekolah, dan yang terakhir penelitian dengan judul Aplikasi Pengelolaan Dana dan Belanja
Pemerintah Daerah Berbasis Web Fajriah (2008).
Melihat kepada penelitian yang telah dilakukan tersebut, maka peneliti tertarik untuk
membangun sebuah aplikasi Pembayaran keuangan SPP dengan menggunakan metodologi
pengembangan sistem berbasis objek Unified Approach, pada penelitian yang akan dilakukan hanya
berfokus pada Pembayaran keuangan sekolah SPP (Sumbangan Pembinaan Pendidikan). melihat
latar belakang tersebut diatas peneliti tertarik untuk mengangkat judul :
“ RANCANG BANGUN APLIKASI PEMBAYARAN SUMBANGAN PEMBINAAN
PENDIDIKAN (SPP) DI SMA CILEDUG AL MUSADDADIYAH GARUT
MENGGUNAKAN METODOLOGI BERORIENTASI OBJEK UNIFIED APPROACH (UA)
“.

II. TINJAUAN PUSTAKA

A. Aplikasi
Aplikasi adalah program yang berisikan perintah-perintah untuk melakukan Pembayaran
data. Jadi aplikasi secara umum adalah suatau proses dari cara manual yang ditransformasikan ke
komputer dengan membuat sistem atau program agar data diolah lebih berdaya guna secara optimal.
(Jogiyanto, 2004). Aplikasi (application) adalah software yang dibuat oleh suatu perusahaan
komputer untuk mengerjakan tugas-tugas tertentu, misalnya Microsoft Word, Microsoft Excel.
(Dhanta, 2009)

B. Pembayaran
Pembayaran adalah merupakan suatu proses memberikan uang sebagai imbalan dari proses
kegiatan belajar dan mengajar di sekolah. Dari pengertian tersebut dapat diartikan bahwa
pembayaran dilakukan apabila terjadi timbal balik antara siswa selaku yang menerima pendidikan
dari sekolah dan pengajar selaku yang memberikan pelajaran dan sekolah sebagai fasilitator
terjadinya proses tersebut.

C. Metodologi Unified Aproach

Metodologi Unified Aproach adalah versi berorientasi objek semua fase klasik
pengembangan perangkat lunak. Karena orientasi objek ketika diakses, pengembang dapat terlibat
dalam semua fase, pelanggan dapat terlibat dalam tahap awal, yang membantu pengembang untuk
melakukan pekerjaan mereka, dan manajer pun ikut terlibat, sehingga komunikasi dapat
ditingkatkan. Tahapan yang akan dilakukan hanya mencakup tahapan requirements, analysis,
design, implementation, dan testing. Tahapan ini memiliki kesamaan tahapan sepderti yang ada
pada metodologi pengembangan sistem klasik. Namun artifak yang dihasilkan berbeda dari
metodologi klasik. Artifak yang dihasilkan merupakan diagram-diagram dari UML
Tahap-tahap dalam metodologi Unified Aproach adalah sebagai berikut [7]:
Requirements: Mengumpulkan persyaratan/ requirement adalah tentang menemukan apa yang akan
dicapai dengan perangkat lunak baru kita dan memiliki dua aspek yaitu persyaratan bisnis dan
sistem. Pemodelan persyaratan sistem (atau spesifikasi fungsional) berarti memutuskan kemampuan
apa yang akan dimiliki perangkat lunak baru dan menuliskan kemampuan tersebut. Kita harus jelas
tentang apa yang akan perangkat lunak lakukan dan apa yang tidak akan dilakukan, sehingga

http://jurnal.sttgarut.ac.id 2
Jurnal Algoritma Sekolah Tinggi Teknologi Garut

pengembangan tidak keluar dari daerah-daerah yang tidak relevan dan kita tahu baik apakah
aplikasi sudah selesai dan sukses
Analysis: Analisis berarti memahami apa yang sedang kita hadapi. Sebelum dapat merancang solusi,
harus dijelaskan tentang entitas apa yang relevan, sifat mereka dan hubungan di antara mereka. Kita
juga perlu untuk memverifikasi pemahaman kita. Hal ini dapat melibatkan pelanggan dan pengguna
akhir, karena mereka cenderung menjadi masalah subjek ahli
Design: Dalam tahap ini akan dibuat keputusan, berdasarkan pengalaman, estimasi dan intuisi,
tentang software yang akan kita tulis dan bagaimana kita akan menyebarkannya. Desain sistem
memecah sistem ke dalam subsistem logis (proses) dan subsistem fisik (komputer dan jaringan),
memutuskan bagaimana mesin akan berkomunikasi, memilih teknologi yang tepat untuk pekerjaan,
dan sebagainya
Implementation: Tahap ini adalah tahap dimana kita melakukan pekerjaan kodifikasi, menulis
potongan kode yang bekerja sama untuk membentuk subsistem, yang pada gilirannya berkolaborasi
untuk membentuk seluruh sistem.
Testing: Ketika perangkat lunak telah selesai dibangun, maka perangkat lunak tersebut harus diuji
terhadap persyaratan sistem untuk melihat apakah perangkat lunak sesuai dengan tujuan awal
ataukah tidak. Pada dasarnya, pengujian akan dilakukan dengan 2 cara, yaitu dengan teknik Black-
Box untuk menguji usage ability dan teknik pengujian langsung oleh pengguna. Pengujian Black-
Box muncul dari filosofi “kita tidak peduli bagaimana kode mencapai ujungnya, asalkan mereka
mencapai tujuan". Hal ini cocok dengan gagasan bahwa persyaratan sistem yang ditulis sebelum
perangkat lunak diproduksi adalah aspek yang paling penting dari pengembangan perangkat lunak

D. Bahasa Pemodelan dan Pengembangan Sistem

Bahasa pemodelan yang umum digunakan dalam orientasi objek adalah UML (Unified
Modeling Language). UML adalah notasi yang akan digunakan untuk dokumentasi tingkat tinggi,
beberapa juga menyatakan bahwa UML menjadi bahasa pemrograman bergambar, menghasilkan
kode atau mensintesis dari kode yang ada. UML memiliki 13 jenis diagram. Spesifikasi UML tidak
menyebutkan di mana diagram ini harus digunakan dalam suatu metodologi tertentu, tetapi bebas
digunakan dimana saja yang dianggap tepat pada setiap tahap oleh pengembang sistem [7].
Dalam pengembangan sistem yang dilakukan, bahasa pemrograman yang akan dipakai
adalah Java. Java merupakan bahasa pemrograman berorientasi obyek yang menggunakan abstraksi,
enkapsulasi, inheritance, dan polimorfisme untuk memberikan fleksibilitas yang besar, modularitas,
dan usabilitas dalam pengembangan software [7].

III. KERANGKA KERJA KONSEPTUAL

Pekerjaan-pekerjaan yang akan dilakukan dalam penelitian ini didasarkan kepada tahap-
tahap yang ada pada metodologi Unified Aproach. Secara singkat langkah-langkah kerja dalam
metodologi Unified Aproach ini akan dijgambarkan pada gambar 1.1 di bawah. Gambar tersebut
memuat tahap-tahap yang harus dilakukan beserta artifak-artifak apa saja yang harus dihasilkan
dalam setiap tahapnya.
Tahap-tahap yang ada dalam metodologi Unified Aproach tidak semua akan digunakan
dalam penelitian ini karena ada beberapa tahap yang memang tidak diperlukan. Seperti Genesis,
Deployment dan Maintenance tidak akan digunakan dalam penelitian ini karena tahap-tahap ini
biasanya digunakan dalam proyek besar yang memerlukan tim dalam pengerjaanya. Jadi hanya
tahap Requirements, Analysis, Design, Class Spesification, Implementation dan Testing yang akan
digunakan. Tahap-tahap yang ini merupakan tahap seperti yang terdapat dalam metodologi klasik

3 © 2013 Jurnal STT-Garut All Right Reserved

 ISSN: 2302-7339 Vol. 10 No. 01 2013

Inisialisasi analisis
kebutuhan

Area Kerja
1.2
1.3
Pengembangan 1.4 identifikasi
1.1 Identifikasi Pengembanga 1.5
diagram kelas, relasi,
Aktor n Diagram Pemeriksaan
aktivitas dan atribut dan metode
Interaksi
use case

2.1 Perancangan
2.2 Menyaring 2.3 Perancangan
Kelas, asosiasi,
UML Diagram Layer akses dan
metode dan
Kelas layer antarmuka
atribut

3.1 Pengujian

Gambar 1 Struktur Rincian Kerja

Tahap Berikut ini di jelaskan secara detail mengenai rincian perencanaan Aplikasi
Pembayaran Keuangan SPP di SMA Ciledug Garut.

1. Analisis Kebutuhan
Proses Masukan Keluaran
Mengungkapkan masalah - Wawancara Pokok permasalahan
yang dihadapi staff
- observasi lapangan yang dihadapi
keuangan SMA dalam - studi kepustakaan
Pembayaran keuangan
SPP
2. Analisis Sistem Masa Depan
2.1 Identifikasi Aktor
Proses Masukan Keluaran
Mengidentifikasi - Analisis Kebutuhasn Daftar Aktor yang
users/actors yang terlibat Sistem terdapat pada sistem
pada sistem yang sedang - Alur Sistem yang berdasarkan jenis actor
berjalan (current system). sedang berjalan

2.2 Pengembangan Aktifity Diagram dan Use case Diagram

Proses Masukan Keluaran
Mengembangkan - Daftar Aktor Aktifity Diagram dan
diagram aktifitas dan use - Alur Sistem Usecase diagram Aplikasi
case berdasarkan hasil Pembayaran keuangan
pada tahap sebelumnya (SPP)
(identifikasi aktor)
2.3 Pengembangan Diagram Interaksi
Proses Masukan Keluaran
Mengembangkan Use - Diagram Aktifitas - Sequence diagrams
Case yang telah - Diagram Use Case - Collaboration
teridentifikasi dengan diagrams
Interaction diagrams.

http://jurnal.sttgarut.ac.id 4
Jurnal Algoritma Sekolah Tinggi Teknologi Garut

2.4 Identifikasi Kelas

Proses Masukan Keluaran
Membuat klasifikasi - Sequence diagrams - Clasess
menggunakan Class - Collaboration - relationships
diagrams berdasarkan diagrams - attributes
Use-case diagrams dan - methods
Interaction diagrams
2.5 Pemeriksaan
Proses Masukan Keluaran
Memeriksa kembali - Daftar Aktor - Daftar Aktor yang
setiap tahapan agar dapat - Diagram Aktifitas telah diperiksa
meminimalisasi - Use Case - Diagram Aktifitas
kesalahan. Jika terdapat - Diagram Interaksi yang telah diperiksa
kesalahan maka proses (Sequence diagrams - Use Case yang telah
kembali ke tahap awal, Collaboration diperiksa
namun jika sudah benar, diagrams) - Diagram Interaksi
maka akan dijadikan yang telah diperiksa
input pada tahap
selanjutnya
(Bahrami, 1999)
3. Desain
3.1 Perancangan Kelas, Atribut, Method, dan Asosiasi
Proses Masukan Keluaran
Menerapkan desain - Daftar Aktor yang Hasil Perancangan Kelas,
Axiom pada design telah diperiksa Asosiasi dan atribut
Class, beserta atribut- - Diagram Aktifitas untuk Aplikasi
atributnya, method, yang telah diperiksa Pembayaran keuangan
asosiasi, struktur dan - Use Case yang telah (SPP)
protokolnya diperiksa
- Diagram Interaksi
yang telah diperiksa
3.2 Menyaring Class Diagram
Proses Masukan Keluaran
Mealkukan Iterasi dan Hasil dari perancangan Diagram Kelas
perbaikan ulang Class, atribut-atributnya,
method, asosiasi, struktur
dan protokolnya
3.3 Perancangan Layer akses dan Layer Antar Muka
Proses Masukan Keluaran
Melakukan perancangan Diagram Kelas Hasil perancangan layer
layer akses dan layer akses dan layer
antarmuka antarmuka untuk Aplikasi
Pembayaran keuangan
SPP
4. Pengujian/Testing
Proses Masukan Keluaran
Melakukan Iterasi dan Menerapkan kembali Keseluruhan Desain yang
perbaikan keseluruhan desain axiom (jika telah diperiksa
desain diperlukan) dan tahapan-
tahapan sebelumnya
(Bahrami, 1999)

5 © 2013 Jurnal STT-Garut All Right Reserved

 ISSN: 2302-7339 Vol. 10 No. 01 2013

IV. HASIL DAN PEMBAHASAN

Tahap pertama yang dilakukan adalah requirement, dalam tahap ini ada dua jenis requirement
yang dibuat, yaitu requirement untuk proses bisnis dan requirement untuk sistem. Ada beberapa
langkah dalam menentukan requirement untuk proses bisnis di antaranya actor list, communication
diagram dan activity diagram sedangkan untuk sistem yaitu actor list, use dan use case diagram
serta user interface sketches.
Untuk menggambarkan kegiatan yang dilakukan oleh masing-masing aktor dalam kegiatan
bisnis maupun sistem akan digambarkan dalam sebuah communication dan activity diagram untuk
proses bisnis dan sebuah use case diagram untuk sistem. Berikut adalah gambaran diagram-diagram
tersebut:
siswa

mulai
Petugas TU

Mendatangi Pencarian
tempat informasi data
pembayaran siswa

Pencarian data
transaksi
ya Siswa melakukan
pembayaran Mempunyai
tunggakan

Melakukan
tidak
pembayaran dan
menyertakan form
pengecekan
rincian
Siswa pembayaran
menanyakan
tunggakan

Petugas
menerima uang
pembayaran
Tidak ada
tunggakan

Pencatatan data
pada buku
transaksi

Pencatatan
taqnda buikti pada
selesai kartu iuran

Gambar 2 Communication Diagram untuk Proses Bisnis Pembayaran SPP

Berikut adalah activity diagram yang menggambarkan bagaimana proses bisnis Pembayaran
SPP

Gambar 3 Activity Diagram untuk Proses Bisnis Pembayaran SPP

http://jurnal.sttgarut.ac.id 6
Jurnal Algoritma Sekolah Tinggi Teknologi Garut

Di bawah ini adalah use case diagram dari sistem Pembayaran SPP

Gambar IV Use case Diagram Pembayaran SPP

Untuk menerapkan proses-proses tadi maka diperlukan sebuah antarmuka program yang akan
menjalankan dan mengeksekusi setiap perintah yang diberikan, berikut adalah sketsa dari antar
muka tersebut:

Gambar 6 Form Login

Gambar 7 Tampilan Menu Utama untuk Aplikasi Pembayaran SPP

7 © 2013 Jurnal STT-Garut All Right Reserved

 ISSN: 2302-7339 Vol. 10 No. 01 2013

Gambar 9 Desain Form Transaksi SPP

Gambar 10 Laporan Pembayaran SPP

Berikut adalah tampilan dari implementasi kode sumber yang diterapkan. Ada beberapa
tampilan yang akan dibahas, mulai dari tampilan pilih pengguna, login menu utama, kelola data,
transaksi dan laporan. Di mana pada bagian kelola data, transaksi dan laporan hanya akan
ditampilkan satu untuk setiap kategori dan sisanya akan disimpan pada lampiran.
Proses pertama ketika petugas mengakses program pembayaran SPP adalah petugas TU (user)
diharuskan login sebelum melakukan penggunaan apliksi pembayaran SPP.

Gambar 24 Form Login

1. Form Halaman Utama SPP

Ketika proses login berhasil, ini merupakan tampilan Menu Aplikasi Pembayaran Keuangan
SPP

http://jurnal.sttgarut.ac.id 8
Jurnal Algoritma Sekolah Tinggi Teknologi Garut

Gambar 25 Form Halaman utama

2. From Transaksi Pembayaran SPP

Pada form ini tampilan menu transaksi pembayaran pada menu pembayaran SPP

Gambar. 26 Form Transaksi SPP

3. Tampilan Laporan Keuangan SPP

Form ini menampilkan laporan keuangan sesuai yang di inginkan apakah harian, bulanan atau
tahunan dan dicetak sesuai skala kebutuhan.

Gambar. 27 Laporan Keuangan

V. KESIMPULAN/RINGKASAN

Kesimpulan yang didapat dari hasil penelitian yang sudah dilakukan diantaranya:
1. Aplikasi menggunakan sumber daya basis data dari aplikasi RKA, sehingga dokumen hasil
keluaran RKA yang menjadi acuan dari pembuatan Surat Pertanggungjawaban dapat digunakan
secara maksimal;

9 © 2013 Jurnal STT-Garut All Right Reserved

 ISSN: 2302-7339 Vol. 10 No. 01 2013

2. Dengan penggunaan basis data dari aplikasi RKA yang telah ada, proses input data dapat
dikurangi sehingga tidak ada redundansi pekerjaan input data;
3. Dengan berkurangnya proses input data, kesalahan data akibat input data pun bisa dikurangi;
4. Dengan berkurangnya proses input data serta sedikitnya kesalahan yang mungkin timbul, maka
waktu pengerjaan pembuatan surat pertanggungjawaban pun pada akhirnya bisa dipersingkat.

UCAPAN TERIMA KASIH

Penulis Y. S. mengucapkan terima kasih kepada kedua orang tua yang selalu membantu
secara moril maupun materil. Penulis juga perkenankan untuk menyampaikan ucapan terima kasih
kepada Bapak Eri Satria, M.Si. selaku pembimbing I dan ibu Kiki Aisyah, MT. selaku pembimbing
II yang telah memberikan arahan serta bimbingan selama penyelesaian penelitian ini.

DAFTAR PUSTAKA

[1] Jogiyanto, Hartono, 2005. Analisis & Desain Aplikasi, Andi. Yogyakarta.
[2] Al-Bahra Bin Ladjamudin, Analisis dan Disain Aplikasi, Graha Ilmu, Yogyakarta, 2005.
[3] Kristanto, Andri,” Perancangan Sistem Informasi dan Aplikasinya
Gaya Media :Yogyakarta, 2008.
[4] http://www.siue.edu/-dbock/cmis450/6-relationalmodel.htm
[5] Kamus Besar Bahasa Indonesia. (1998). Jakarta : Pustaka Amani.
[6] Liang, Y. D. (2011). Introduction to Java Programming, 8th Edition. New Jersey: Prentice
Hall.
[7] O’Docherty, M. (2005). Object Oriented Analysis and Design Understanding System
Development with UML. England: John Wiley & Sons Ltd.
[8] Bunafit Nugroho,2004. Database Relasional Dengan MySQL

http://jurnal.sttgarut.ac.id 10