Jurnal Algoritma Sekolah Tinggi Teknologi Garut Jl. Mayor Syamsu No. 1 Jayaraga Garut Indonesia

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 : [email protected] 1

[email protected] [email protected] 3 [email protected] 2

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 BlackBox untuk menguji usage ability dan teknik pengujian langsung oleh pengguna. Pengujian BlackBox 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 tahaptahap 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.1 Identifikasi Aktor

1.2 Pengembangan diagram aktivitas dan use case

1.3 Pengembanga n Diagram Interaksi

2.1 Perancangan Kelas, asosiasi, metode dan atribut

1.4 identifikasi kelas, relasi, atribut dan metode

2.2 Menyaring UML Diagram Kelas

1.5 Pemeriksaan

2.3 Perancangan Layer akses dan layer antarmuka

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 Mengungkapkan masalah - Wawancara yang dihadapi staff - observasi lapangan keuangan SMA dalam - studi kepustakaan Pembayaran keuangan SPP 2. Analisis Sistem Masa Depan 2.1 Identifikasi Aktor Proses Masukan Mengidentifikasi - Analisis Kebutuhasn users/actors yang terlibat Sistem pada sistem yang sedang - Alur Sistem yang berjalan (current system). sedang berjalan

Keluaran Pokok permasalahan yang dihadapi

Keluaran Daftar Aktor yang terdapat pada sistem berdasarkan jenis actor

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


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 tahapantahapan sebelumnya (Bahrami, 1999)

5


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 tempat pembayaran

Pencarian informasi data siswa

Pencarian data transaksi ya

Siswa melakukan pembayaran

Mempunyai tunggakan

tidak

pengecekan Siswa menanyakan tunggakan

Melakukan pembayaran dan menyertakan form rincian pembayaran

Petugas menerima uang pembayaran Tidak ada tunggakan

Pencatatan data pada buku transaksi

selesai

Pencatatan taqnda buikti pada 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


6


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


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


8


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


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


10

Jurnal Algoritma Sekolah Tinggi Teknologi Garut Jl. Mayor Syamsu No. 1 Jayaraga Garut Indonesia

Recommend Documents