Fakultas Ilmu Komputer
Universitas Brawijaya
1003
Pengembangan Sistem Informasi Keuangan Operasional Masjid Ibnu Sina
Malang menggunakan Metode Iteratif
Aldiransyah Rizky Putra1, Ismiarta Aknuranda2, Kariyoto3
Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya Email: 1aldirarizkyp@student.ub.ac.id, 2i.aknuranda@ub.ac.id, 3kariyoto@ub.ac.id
Abstrak
Masjid Ibnu Sina merupakan salah satu masjid yang berlokasi di kota Malang. Sama seperti masjid pada umumnya, Masjid Ibnu Sina memiliki fungsi sebagai tempat ibadah, dakwah, kegiatan sosial, pendidikan dan lain-lain. Masjid Ibnu Sina juga merupakan salah satu bentuk organisasi nirlaba yang di dalamnya perlu adanya manajemen keuangan dalam menerapkan fungsi operasional organisasi. Namun, terdapat permasalahan yang terjadi pada saat melakukan manajemen keuangan operasional di dalam Masjid Ibnu Sina. Pendataan laporan keuangan yang masih dilakukan secara manual membuat proses pembuatan laporan memerlukan waktu yang cukup lama, lalu pendataan belanja kebutuhan Masjid yang kurang tercatat dan kurang efisien, dan laporan keuangan yang tercatat kurang mendetail sehingga berisiko menyebabkan penyalahgunaan dana. Berdasarkan permasalahan yang dipaparkan sebelumnya, dilakukan proyek skripsi yang bertujuan untuk mengembangkan sistem informasi keuangan berbasis
web yang membantu dalam melakukan manajemen keuangan operasional Masjid Ibnu Sina. Metode yang digunakan dalam pengembangan ini yaitu metode iteratif yang menghasilkan dua iterasi. Terdapat iterasi luar yang terfokus pada analisis permasalahan dan analisis kebutuhan serta iterasi dalam yang terfokus pada perancangan dan implementasi sistem. Pengembangan ini dilakukan dengan menggunakan bahasa pemrograman PHP serta kerangka kerja Laravel dengan menerapkan pendekatan berorientasi objek. Kemudian pengujian sistem dilakukan dengan menggunakan metode pengujian validasi dan evaluasi usability. Pengujian validasi menghasilkan semua fungsi di kedua iterasi bersifat valid dan evaluasi usability menghasilkan nilai completion rate sebesar 95,45 % pada iterasi ke-1 dan 100 % pada iterasi ke-2, overall relative efficiency menghasilkan nilai 94,1% pada iterasi ke-1 dan 100 % pada iterasi ke-2, dan menghasilkan nilai SUSsebesar 70 pada kedua iterasi.
Kata kunci: masjid, keuangan, operasional, sistem informasi keuangan, iteratif.
Abstract
Ibnu Sina Mosque is one of the mosques located in the city of Malang. Just like mosques in general, the Ibnu Sina Mosque has a function as a place of worship, preaching, social activities, education and others. The Ibnu Sina Mosque is also a form of non-profit organization in which financial management is needed in implementing the operational functions of the organization. However, there are problems that occur when carrying out operational financial management in the Ibnu Sina Mosque. The data collection of financial reports that is still done manually means that the process of making reports takes quite a long time, then the data collection for spending on mosque needs is less recorded and inefficient, and the financial reports that are recorded are less detailed so that it risks causing misuse of funds. Based on the problems described earlier, a thesis project was carried out which aims to develop a web-based financial management information system that helps in conducting the operational finances of the Ibnu Sina Mosque. The method used in this development is the iterative method which produces two iterations. There is an outer iteration that focuses on problem analysis and needs analysis and an inner iteration that focuses on system design and implementation. This development is carried out using PHP programming language and the Laravel framework by applying an object-oriented approach. Then the system testing is carried out using validation testing methods and usability evaluation. The validation test results in all functions in both iterations being valid and usability evaluation results in a completion rate of 95.45% in the first iteration and 100% in the second iteration, the overall relative efficiency yields a value of 94,1% in the first iteration and 100% in the second iteration, and result in a SUS value of 70 in both iterations.
Keywords: mosque, financial, operational, financial information system, iterative.
1. PENDAHULUAN
Masjid merupakan suatu tempat ibadah bagi umat muslim dalam melaksanakan ibadah shalat terutama shalat berjemaah. Menurut Ensiklopedi Hukum Islam (2000), masjid tidak hanya berfungsi untuk menjalankan ibadah shalat, namun masjid juga memiliki fungsi sosial seperti pendidikan, pengajian, dan kegiatan sosial lainnya dan masjid memiliki fungsi politis sebagai pusat pemerintahan, administrasi, dan tempat berlangsungnya permusyawaratan bidang politik. Dalam menjalankan kegiatan operasional di dalam masjid, tentunya masjid memerlukan pendanaan dalam menjalankan kegiatan-kegiatan tersebut. Pendanaan ini berfungsi sebagai alat pendukung kegiatan masjid apabila kegiatan masjid memerlukan suatu kebutuhan yang membutuhkan dana dalam penerapannya. Maka dari itu, manajemen keuangan masjid perlu diperhatikan untuk menunjang segala aspek yang dibutuhkan oleh masjid.
Setiap organisasi pasti memerlukan manajemen keuangan dalam menerapkan fungsi organisasi. Tujuan dari adanya manajemen keuangan yaitu untuk memaksimalkan keuntungan dan meminimalkan pengeluaran untuk mendapatkan pengambilan keputusan yang maksimal dalam menjalankan visi, misi dan tujuan dari organisasi (Irawati, 2006). Begitu juga halnya dengan manajemen keuangan dalam organisasi masjid. Pada penelitian ini yang menjadi objek penelitian yaitu Masjid Ibnu Sina yang terletak di Kota Malang.
Berdasarkan hasil wawancara yang dilakukan kepada bendahara operasional dalam menerapkan manajemen keuangan, Masjid Ibnu Sina memiliki tiga dompet utama yaitu dompet untuk operasional, pembangunan, dan fuqara. Ketiga dompet tersebut memiliki tujuan penggunaan yang berbeda dan cara pelaporan yang berbeda pula. Dompet operasional masjid digunakan untuk mendukung pendanaan berbagai kegiatan-kegiatan di dalam masjid dari kegiatan yang berskala besar hingga skala kecil atau untuk pendanaan renovasi. Dalam pembuatan pelaporan keuangannya, dompet operasional Masjid Ibnu Sina menggunakan MS Excel sebagai alat untuk membuat laporan keuangan yang kemudian laporan tersebut
dilaporkan setiap minggu pada hari Jumat kepada jemaah maupun pihak internal Masjid Ibnu Sina. Masalah yang dialami oleh pihak bendahara masjid yaitu mereka merasa kesulitan dalam pembuatan laporan keuangan apabila laporan tersebut akan diakumulasikan menjadi laporan bulanan atau tahunan. Maka dari itu, pihak bendahara operasional masjid merasa perlu adanya suatu sistem yang dapat mengatur keuangan Masjid Ibnu Sina yang dapat mempermudah bagian keuangan dalam pembuatan laporan keuangan dan meningkatkan akurasi pelaporan keuangan yang dimiliki oleh masjid.
Salah satu cara untuk mengatasi masalah keuangan tersebut adalah dengan membangun suatu sistem informasi keuangan. Baridwan (1996) mengatakan bahwa sistem informasi manajemen keuangan merupakan gabungan subsistem keuangan yang saling terkait untuk menghasilkan informasi. Dengan adanya sistem informasi keuangan, diharapkan dapat memudahkan pihak masjid dalam menjalankan kegiatan operasional, pengambilan keputusan, dan memenuhi pertanggungjawaban. Manajemen keuangan yang jelas dapat memberikan kemudahan bagi pihak yang mengelola keuangan suatu organisasi.
Berdasarkan pemaparan masalah yang diuraikan di atas, penulis akan mengembangkan suatu sistem informasi keuangan operasional pada Masjid Ibnu Sina Malang dengan memanfaatkan metode iterative development
dalam proses pengembangannya. Metode
iterative development merupakan salah satu pendekatan dari Software Development Life Cycle (SDLC). Metode ini menggunakan konsep perulangan yang bertujuan untuk mendapatkan umpan balik agar sistem dapat berkembang sesuai dengan tujuan yang sudah ditentukan dari waktu ke waktu. Maka dari itu, peneliti bertujuan untuk melakukan penelitian pada Masjid Ibnu Sina Malang dengan mengangkat judul
“Pengembangan Sistem Informasi Keuangan Operasional Masjid Ibnu Sina Malang Menggunakan Metode Iteratif”.
2. Tinjauan Pustaka
2.1 Sistem Informasi Manajemen Keuangan
Fakultas Ilmu Komputer, Universitas Brawijaya bagian dari sistem informasi manajemen yang merupakan gabungan antara subsistem-subsistem keuangan yang saling terkait dan terhubung dalam suatu jaringan dengan tujuan untuk menghasilkan informasi terkait keuangan organisasi atau perusahaan. Baridwan (1996) mengatakan bahwa tujuan sistem informasi keuangan yaitu:
1. Mendukung kegiatan operasi sehari-hari dalam organisasi/perusahaan (to support the day to day operations).
2. Mendukung pengambilan keputusan pada tingkat manajerial atau manajemen (to support decision making by internal decision makers). 3. Memenuhi kewajiban dengan pertanggung jawaban (to fulfill obligations relating to stewardship).
2.2 BPMN
Menurut Weske (2007), BPMN merupakan kumpulan notasi grafis yang berfungsi untuk memodelkan suatu proses bisnis dengan tujuan untuk dapat memberikan gambaran proses bisnis kepada pelaku bisnis agar lebih mudah dipahami. Terdapat 4 kategori elemen dasar pada BPMN, yaitu:
1. Flow Object: Elemen utama yang
menggambarkan perilaku proses bisnis, terdiri dari events, activity, gateways.
2. Artefacts: Berfungsi untuk memberi
gambaran mengenai informasi tambahan dalam proses bisnis yang terdiri dari data object, groups, dan text annotations.
3. Connecting Object: Berfungsi
sebagai penghubung di antara aktivitas proses bisnis. Terdiri dari
sequence flows, message flows, association, dan data associations.
4.
Swimlanes: Swimlanes dibagimenjadi dua yaitu pools dan lanes.
Pools menggambarkan organisasi yang berinteraksi terhadap proses bisnis sedangkan lanes
menggambarkan entitas terkait dalam suatu organisasi.
2.3 Iterative Model
Iterative Model merupakan salah satu pendekatan dari System Software Development Life Cycle (SDLC) dimana pengembangan disusun dalam serangkaian singkat, waktu yang ditentukan secara pasti atau yang biasa disebut iterasi. Setiap iterasi memiliki kebutuhan, perancangan, implementasi, dan aktivitas pengujian masing-masing. Siklus hidup iteratif dilakukan dengan melakukan iterasi secara berulang-ulang untuk mendapatkan suatu umpan balik agar mendapatkan sistem yang sesuai sehingga sistem tumbuh secara bertahap dari waktu ke waktu dan iterasi ke iterasi.
Gambar 1. Iterative Development
2.4 Validation Testing
Validation testing difokuskan untuk aksi yang dapat dilihat oleh pengguna serta keluaran hasil yang bisa dikenali oleh pengguna. Dalam pengujian ini, penguji harus menyesuaikan
validation testing dengan use case yang sudah dibuat. Dengan serangkaian percobaan dilakukan, diharapkan sistem dapat memenuhi kesesuaian fungsi yang dibutuhkan oleh pengguna (Pressman, 2010).
2.5 Usability Testing
Usability digunakan untuk mengukur sejauh mana suatu produk dapat digunakan oleh pengguna tertentu untuk mencapai tiga tujuan utama yaitu effectiveness, efficiency, dan
satisfaction. Tujuan dari effectiveness yaitu untuk mengukur akurasi dan kelengkapan pengguna dalam menggunakan sistem, lalu
efficiency digunakan untuk mengukur sumber daya yang digunakan oleh pengguna dalam menggunakan suatu sistem, sedangkan
satisfaction digunakan untuk mengukur kepuasan pengguna dalam menggunakan suatu sistem (ISO 9241-11, 1998). Dalam studi kasus tertentu, penggunaan responden dalam menjalankan usability testing aplikasi berskala
kecil dapat dilakukan hanya dengan 2 responden untuk mendapatkan hasil yang cukup optimal (Nielsen, 2012).
3. METODOLOGI PENELITIAN
Penelitian dilakukan dengan menerapkan metode model iteratif. Pendekatan model iteratif diterapkan untuk implementasi berorientasi objek. Alur dari penelitian ini meliputi pemodelan proses bisnis, proses iterasi yang terbagi menjadi luar dan dalam. Iterasi luar meliputi analisis permasalahan dan analisis kebutuhan, lalu pada iterasi dalam meliputi perancangan sistem dan implementasi sistem. Lalu dilakukan pengujian dan evaluasi sistem dan terakhir penarikan kesimpulan dan saran.
3.1. Pemodelan Proses Bisnis
Pemodelan proses bisnis dilakukan untuk mendapatkan gambaran alur keuangan dompet operasional pada Masjid Ibnu Sina. Proses bisnis dimodelkan ke dalam dua bentuk yaitu proses bisnis as-is dan proses bisnis to-be. Proses bisnis
as-is memberikan gambaran mengenai alur keuangan saat ini sedangkan proses bisnis to-be
merupakan proses bisnis usulan atau pengembangan dari proses bisnis as-is.
3.2 Proses Iterasi
Proses iterasi dibagi menjadi dua bagian yaitu iterasi luar dan iterasi dalam. Proses iterasi luar meliputi analisis permasalahan dan analisis kebutuhan yang dilakukan untuk mengetahui permasalahan yang ada pada masjid dan menentukan kebutuhan sistem. Setelah diketahui gambaran dari kebutuhan sistem, proses iterasi dalam dijalankan. Proses perancangan sistem dilakukan dengan pendekatan Object Oriented Analysis Design (OOAD) yang digambarkan dengan diagram UML. Sedangkan implementasi dilakukan dengan pendekatan Object Oriented Programming (OOP) dengan menggunakan bahasa pemrograman PHP serta kerangka kerja
Laravel. Selanjutnya dilakukan pengujian dan evaluasi sistem dengan menggunakan pendekatan black-box validation testing untuk menguji fungsi dan evaluasi usability untuk menilai kepuasan pengguna. Proses iterasi akan terus berulang sampai kebutuhan sistem terpenuhi.
3.3 Kesimpulan dan Saran
K
esimpulan dan saran merupakan tahapakhir dari penelitian ini. Pada tahap ini dilakukan penarikan kesimpulan dari rumusan masalah yang sudah ditentukan sebelumnya dan memberikan saran sebagai bentuk rekomendasi untuk penelitian selanjutnya.
Gambar 2. Metodologi Penelitian 4. HASIL PENELITIAN
4.1 Deskripsi Proses Bisnis
Pemodelan proses bisnis dibuat berdasarkan kegiatan yang dijalan di Masjid Ibnu Sina terutama dalam dompet operasional keuangan. Proses bisnis ini menjelaskan bagaimana alur yang dijalankan oleh Masjid Ibnu Sina dalam mengelola keuangan dari uang masuk hingga uang keluar. Model proses bisnis yang diteliti terdapat dua macam yaitu proses bisnis saat ini (as-is) dan proses bisnis usulan (to-be) dengan menggunakan sistem informasi.
Proses bisnis as-is menghasilkan 4 model proses bisnis yaitu proses bisnis as-is uang masuk dompet operasional yang tertera pada Gambar 3. Lalu proses bisnis as-is uang keluar kegiatan keagamaan dompet operasional yang tertera pada Gambar 4. Lalu proses bisnis as-is
uang keluar kegiatan sehari-hari dompet operasional yang tertera pada Gambar 5. Dan
Fakultas Ilmu Komputer, Universitas Brawijaya terakhir proses bisnis as-is pelaporan keuangan dompet operasional yang tertera pada Gambar 6. Setelah mendapatkan model proses bisnis as-is,
model proses bisnis tersebut dikembangkan menjadi proses bisnis to-be. Proses bisnis to-be
terdapat penambahan sistem informasi manajemen keuangan untuk mendukung alur proses keuangan yang ada pada Masjid Ibnu Sina. Proses bisnis to-be terdiri dari proses bisnis
to-be uang masuk dompet operasional yang tertera pada Gambar 7, lalu proses bisnis to-be
uang keluar kegiatan keagamaan dompet operasional yang tertera pada Gambar 8, lalu proses bisnis to-be uang keluar kegiatan sehari-hari dompet operasional yang tertera pada Gambar 9, dan terakhir proses bisnis to-be
pelaporan keuangan dompet operasional yang tertera pada Gambar 10.
Gambar 3. Proses Bisnis As-is Uang Masuk Dompet Operasional
Gambar 4. Proses Bisnis As-is Uang Keluar Kegiatan Keagamaan Dompet Operasional
Gambar 5. Proses Bisnis As-is Uang Keluar Kegiatan Sehari-hari Dompet Operasional
Gambar 6. Proses Bisnis As-is Pelaporan Keuangan Dompet Operasional
Gambar 7. Proses Bisnis To-be Uang Masuk Dompet Operasional
Gambar 8. Proses Bisnis To-be Uang Keluar Kegiatan Keagamaan Dompet Operasional
Gambar 9. Proses Bisnis To-be Uang Keluar Kegiatan Sehari-hari Dompet Operasional
Gambar 10. Proses Bisnis To-be Pelaporan Keuangan Dompet Operasional
4.2 Iterasi Luar ke-1
Iterasi luar ke-1 dimulai dari melakukan analisis permasalahan dan kebutuhan. Analisis permasalahan dilakukan pertama kali untuk mendapatkan masalah apa yang dialami oleh pihak masjid. Masalah tersebut diidentifikasi dari sisi mempengaruhi, dampak, dan solusi yang diberikan. Analisis kebutuhan mengidentifikasi pemangku kepentingan, fitur, persyaratan fungsional dan persyaratan nonfungsional. Identifikasi pemangku kepentingan menghasilkan 3 pemangku kepentingan yang terdiri dari bendahara operasional, remas, dan takmir. Identifikasi fitur dilakukan sesuai dengan kebutuhan Masjid dalam menjalankan alur keuangan. Fitur teridentifikasi sebanyak 5 fitur yang akan diuraikan lagi ke dalam bentuk kebutuhan fungsional yang menghasilkan 13 kebutuhan fungsional dan 1 kebutuhan nonfungsional.
Tabel 1. Persyaratan Garis Besar Iterasi luar- ke-1
Kode Fitur Fungsi Aktor
FR-SIMK-01 Login Bendahara
Remas/Takmir FR-SIMK-02 Logout Bendahara, Remas/Takmir FR-SIMK-03 Mengelola data kategori Bendahara Remas/Takmir FR-SIMK-04 Mengelola
data transaksi Bendahara FR-SIMK-05
Mengelola laporan keuangan
Bendahara
Setelah itu dilakukan pemodelan use case
untuk memvisualisasikan hubungan antara
pengguna dengan sistem.
Pemodelan use casetersebut diimplementasikan ke dalam use case diagram yang menghasilkan 5 use case. Use case diagram dapat dilihat pada Gambar 11. Setiap use case dijelaskan secara rinci terkait hubungan pengguna dengan sistem dengan membuat spesifikasi use case yang dapat dilihat pada Tabel 2.
Gambar 11. Use Case Diagram Tabel 2. Spesifiksi Use Case Mengelola Data
Kategori
Kode Use Case UC-SIMK-03
Kode persyaratan fungsional
PF-SIMK-04 PF-SIMK-05 PF-SIMK-06
Deskripsi singkat Use case mengelola data kategori menjelaskan tentang bagaimana aktor melakukan penambahan, perubahan, dan penghapusan data kategori.
Aktor Bendahara Operasional,
Remas/Takmir.
Kondisi sebelumnya 1. Aktor terhubung dengan internet. 2. Aktor telah masuk
Fakultas Ilmu Komputer, Universitas Brawijaya
Alur utama 1. Use case dimulai
ketika aktor menginginkan menambah data kategori 2. Sistem akan menampilkan halaman kategori. 3. Aktor memilih untuk
tambah kategori. 4. Sistem akan mengarahkan aktor ke halaman tambah kategori dan menyediakan form untuk menambah data kategori. 5. Aktor memasukkan
nama kategori dan memilih untuk simpan
6. Sistem akan
menyimpan hasil masukkan aktor ke dalam database dan akan mengembalikan aktor ke halaman kategori. 7. Sistem menampilkan notifikasi bahwa kategori berhasil tersimpan dan menampilkan baris tabel yang berisi data kategori baru hasil masukkan dari aktor. 8. Use Case selesai. Alur alternatif A1. Data kategori tidak diisi
Jika pada alur utama nomor 4 aktor tidak mengisikan form yang disediakan oleh sistem, maka sistem akan memberikan peringatan bahwa form harus diisi. A2. Data kategori tidak diisi
pada saat aktor melakukan edit.
Jika pada subflow nomor 3 (S1. Mengubah data kategori) aktor tidak mengisi form nama kategori, maka sistem akan menampilkan peringatan bahwa form
harus diisi.
Subflow S1. Mengubah data kategori
1. Aktor memilih untuk melakukan edit.
2. Sistem akan
mengalihkan dari halaman kategori ke halaman kategori edit yang akan
menampilkan form edit kategori beserta
kolom untuk
memasukkan nama kategori.
3. Aktor memasukkan nama kategori dan memilih untuk simpan.
4. Sistem akan
menyimpan hasil masukkan aktor ke dalam database dan akan mengembalikan aktor ke halaman kategori. 5. Sistem menampilkan notifikasi bahwa kategori berhasil diubah dan menampilkan tabel yang berisi data kategori hasil perubahan aktor. S2. Menghapus data kategori
1. Aktor memilih untuk melakukan hapus 2. Sistem akan menghapus data kategori dari tampilan dan database berdasarkan data kategori yang dipilih
aktor serta
menghapus data transaksi yang memiliki kategori yang dihapus. Kondisi akhir Kondisi akhir dari use case ini
yaitu: 1. Aktor berhasil menambahkan data kategori. 2. Aktor berhasil mengubah data kategori yang sudah tersimpan.
3. Aktor berhasil menghapus data kategori yang sudah tersimpan.
4.3 Iterasi Dalam ke-1
Iterasi dalam ke-1 merupakan kelanjutan dari iterasi luar ke-1. Setelah diketahui analisis persyaratan, maka akan dilakukan perancangan sistem. Perancangan sistem meliputi perancangan sequence diagram, class diagram,
pemodelan data, dan perancangan antarmuka pengguna. Sequence diagram membahas mengenai hubungan antar objek-objek yang ada pada sistem. Iterasi dalam ke-1 menghasilkan 3
sequence diagram yaitu mengelola data kategori, mengelola data transaksi, dan mengelola laporan keuangan. Selanjutnya dilakukan perancangan class diagram untuk mengetahui hubungan antar kelas pada sistem.
Class diagram terdiri dari class diagram controller dan class diagram model. Class diagram controller menghasilkan 3 controller yaitu kategoriController, transaksiController, dan laporanKeuanganController. Ketiga
controller tersebut mengekstend controller
utama sebagai pusat logika sistem yang sudah disediakan oleh Laravel. Class diagram model menghasilkan 4 kelas yang terdiri dari Kategori, Transaksi, Dompet, dan User. Class tersebut akan mengekstend model utama yang sudah disediakan oleh Laravel. Class diagram controller dan modeldapat dilihat pada Gambar 12 dan 13.
Gambar 12. Class Diagram Controller
Gambar 13. Class Diagram Model Pemodelan data dapat digambarkan dengan menggunakan PDM (Physical Data Modelling).
PDM digunakan untuk memberikan gambaran bagaimana hubungan antara tabel satu dengan tabel lainnya. Physical data model juga mempertimbangkan penggunaan DBMS yang digunakan pada saat memodelkan data fisik, sehingga diperlukan tipe data yang akurat untuk
kolom entitas (Visual Paradigm, n.d.). PDM dapat dilihat pada Gambar 14.
Gambar 14. Physical Data Modelling Proses perancangan berikutnya yaitu perancangan antarmuka pengguna. Perancangan antarmuka pengguna memberikan gambaran antarmuka sistem dengan membuat wireframe
dari setiap antarmuka yang ada pada sistem. Perancangan antarmuka dapat dilihat pada Gambar 15.
Gambar 15. Wireframe Mengelola Data Kategori
Selanjutnya dilakukan proses implementasi sistem yang terdiri dari implementasi antarmuka pengguna, implementasi basis data, dan implementasi fungsi. Implementasi antarmuka pengguna adalah antarmuka dari sistem yang sudah melalui proses kode. Antarmuka diimplementasikan dengan menggunakan
framework dari Bootstrap. Implementasi antarmuka dapat dilihat pada Gambar 16. Implementasi basis data menjelaskan bagaimana rancangan basis data dalam sistem. Pada iterasi ke-1 terdapat 4 tabel basis data yang berperan dalam penyimpanan data, yaitu tabel transaksi, dompet, kategori, dan users. Tabel transaksi mereferensikan ke tabel kategori dan tabel dompet sedangkan tabel users tidak mereferensikan ke tabel lainnya. DBMS yang digunakan adalah mysql. Implementasi fungsi merupakan jabaran dari kode fungsi controller
yang ada pada sistem. Pada iterasi pertama, fungsi controller mencakup kategoriController,
Fakultas Ilmu Komputer, Universitas Brawijaya transaksiController, dan laporanController. Setiap controller memiliki fungsi yang berbeda-beda sesuai dengan kebutuhan dari fitur masing-masing.
Implementasi fungsi menggunakan
bahasa pemrograman PHP dengan kerangka
kerja
Laravel
.
Gambar 16. Implementasi Antarmuka Pengguna Mengelola Data Kategori
Setelah itu dilakukan proses integrasi sistem pada iterasi ke-1. Proses integrasi sistem menjelaskan mengenai proses penggabungan fungsi dalam mengembangkan sistem. Proses pengembangan pertama yaitu membuat fungsi
login dan logout yang disediakan oleh Laravel. Selanjutnya pengembangan fungsi mengelola data kategori dan data dompet. Setelah fungsi data kategori dan dompet dikembangkan, dilanjutkan dengan mengembangkan fungsi mengelola transaksi yang di dalamnya terdapat pengambilan data kategori dan data dompet. Kemudian, fungsi terakhir yang dikembangkan pada iterasi-ke 1 yaitu mengelola laporan keuangan. Pada fungsi mengelola laporan keuangan diperlukan informasi data transaksi yang sudah diinput oleh bendahara.
Proses pengujian dan evaluasi sistem dilakukan dengan menggunakan metode black box validation testing dan usability
menggunakan task scenario dan System Usability Scale (SUS). Pengujian validasi menyatakan bahwa fungsi sistem pada iterasi ke-1 bersifat valid, lalu pengujian usability yang diujikan kepada 2 responden menghasilkan nilai
completion rate sebesar 95,45%, overall relative efficiency sebesar 94,1%, dan nilai SUS sebesar 70.
4.4 Iterasi Luar ke-2
Iterasi luar ke-2 dimulai dari melakukan analisis permasalahan dan kebutuhan. Analisis permasalahan dilakukan untuk mendapatkan masalah apa yang belum teridentifikasi pada iterasi ke-1. Masalah tersebut diidentifikasi dari
sisi mempengaruhi, dampak, dan solusi yang diberikan. Analisis kebutuhan mengidentifikasi pemangku kepentingan, fitur, persyaratan fungsional dan persyaratan nonfungsional yang belum teridentifikasi pada iterasi ke-1. Identifikasi pemangku kepentingan menghasilkan 4 pemangku kepentingan yang terdiri dari ketua takmir, bendahara operasional, remas, dan takmir. Identifikasi fitur dilakukan sesuai dengan kebutuhan Masjid dalam menjalankan alur keuangan. Fitur teridentifikasi sebanyak 6 fitur yang akan diuraikan lagi ke dalam bentuk kebutuhan fungsional yang menghasilkan 14 kebutuhan fungsional dan 1 kebutuhan nonfungsional. Setelah itu dilakukan pemodelan use case untuk memvisualisasikan hubungan antara pengguna dengan sistem. Pemodelan use case tersebut diimplementasikan ke dalam use case diagram yang menghasilkan 5 use case. Setiap use case dijelaskan secara rinci terkait hubungan pengguna dengan sistem dengan membuat spesifikasi use case. Analisis persyaratan pada iterasi ke-2 dapat dilihat pada Tabel 3 dan spesifikasi use case pada iterasi ke-2 dapat dilihat pada Tabel 4.
Tabel 3. Persyaratan Garis Besar Iterasi luar- ke-2
Kode Fitur Fungsi Aktor FR-SIMK-06 Mengelola
pengguna Ketua takmir
FR-SIMK-07 Hak akses setiap pengguna Bendahara Ketua takmir Remas Takmir FR-SIMK-08 Melihat informasi saldo Bendahara Ketua takmir FR-SIMK-09 Melihat dashboard Bendahara Ketua takmir Remas Takmir FR-SIMK-10 Mengelola formulir work order Bendahara Remas FR-SIMK-11 Mengganti password Bendahara Ketua takmir Remas Takmir
Tabel 4. Spesifikasi Use Case Mengelola Formulir Work Order
Kode use case UC-SIMK-09
Kode persyaratan fungsional terkait PF-SIMK-20 PF-SIMK-21 PF-SIMK-22 PF-SIMK-23 PF-SIMK-24 PF-SIMK-25
PF-SIMK-26
Deskripsi singkat Use case mengelola formulir
work order menjelaskan tentang bagaimana remas dan takmir dapat mengajukan formulir work order untuk belanja dan dapat divalidasi oleh bendahara operasional.
Aktor Bendahara Operasional
Remas Takmir
Kondisi sebelumnya 1. Aktor terhubung dengan internet.
2. Aktor telah masuk kedalam sistem.
Alur utama 1. Use case dimulai ketika
aktor remas/takmir menginginkan untuk mengajukan formulir work order
2. Sistem akan menampilkan halaman formulir
work order.
3. Aktor memilih untuk mengajukan formulir work order
4. Sistem akan menampilkan halaman pengajuan formulir work order
dan menyediakan
form yang terdiri dari tanggal, nama barang, keterangan, dan nominal. 5. Aktor mengisi seluruh
data form yang disediakan sistem dimulai dari tanggal transaksi sampai dengan nominal lalu memilih simpan. 6. Sistem menyimpan data
pengajuan formulir
work order aktor ke dalam database dan mengembalikan aktor ke halaman
work order.
7. Sistem menampilkan baris baru pada tabel transaksi hasil masukkan dari aktor beserta notifikasi bahwa formulir work order berhasil disimpan. 8. Use case selesai. Alur alternatif A1. Salah satu data form
tidak diisi pada saat melakukan pengajuan formulir work order. Jika pada alur utama nomor 5 aktor tidak mengisikan salah satu data yang ada pada form,
maka sistem akan memberikan peringatan bahwa form harus diisi. A2. Salah satu data form
tidak diisi pada saat melakukan perubahan data work order. Jika pada subflow nomor 3 (S1. Mengubah data work order) aktor mengosongkan salah satu data form, maka sistem akan memberikan peringatan bahwa data
form harus diisi.
Subflow S1. Mengubah data work
order
1. Aktor berniat untuk melakukan perubahan data work order
2. Sistem akan mengalihkan dari halaman work order
ke halaman perubahan
work order yang akan menampilkan form edit data work order
3. Aktor merubah satu atau lebih data work order dan memilih simpan.
4. Sistem akan memperbarui data
work order pada
database dan mengembalikan ke halaman work order.
5. Sistem menampilkan notifikasi bahwa data
work order berhasil diubah dan menampilkan data yang baru sesuai dengan perubahan yang dilakukan oleh aktor.
S2. Menghapus data work order
1. Aktor berniat untuk menghapus data
work order
2. Sistem akan menghapus data
work order dari tampilan dan
database
berdasarkan data
work order yang dipilih aktor. S3. Upload bukti belanja
1. Aktor memilih untuk melakukan upload
Fakultas Ilmu Komputer, Universitas Brawijaya
2. Sistem akan
menampilkan pop up
pencarian file dari laptop/komputer 3. Aktor memilih bukti
belanja berupa gambar.
4. Sistem meng upload
gambar S4. Menampilkan bukti belanja
1. Aktor memilih untuk menampilkan bukti pada dokumen hasil
upload di salah satu data work order
2. Sistem akan
membuka tab pada
browser dan
memperlihatkan gambar yang di
upload
S5. Validasi formulir work order
1. Aktor memilih untuk melakukan validasi formulir work order
yang sudah diajukan 2. Sistem akan
merubah status formulir work order
dari belum disetujui menjadi sudah disetujui.
Kondisi akhir Kondisi akhir dari use case ini yaitu : 1. Aktor berhasil mengajukan formulir work order 2. Aktor berhasil mengubah formulir work order 3. Aktor berhasil menghapus formulir work order.
4. Aktor berhasil mencari data work order
dengan menuliskan kata kunci
5. Aktor berhasil meng
upload bukti belanja berupa gambar. 6. Aktor berhasil
memvalidasi formulir work order.
4.5 Iterasi Dalam ke-2
Iterasi dalam ke-2 merupakan kelanjutan dari iterasi luar ke-2. Setelah diketahui analisis persyaratan, maka akan dilakukan perancangan sistem. Perancangan sistem meliputi perancangan sequence diagram, class diagram,
pemodelan data, dan perancangan antarmuka pengguna. Sequence diagram membahas mengenai hubungan antar objek-objek yang ada pada sistem. Iterasi dalam ke-2 menghasilkan 6
sequence diagram yaitu mengelola pengguna, melihat informasi saldo, melihat dashboard, mengelola work order (remas), mengelola work order (bendahara), dan mengganti password. Selanjutnya dilakukan perancangan class diagram untuk mengetahui hubungan antar kelas pada sistem. Class diagram terdiri dari class diagram controller dan class diagram model.
Class diagram controller menghasilkan 5
controller yaitu workorderController, pengelolaanController,
gantiPasswordController,
operasionalController, dan dashboardController. Ketiga controller tersebut mengekstend
controller utama sebagai pusat logika sistem yang sudah disediakan oleh Laravel. Class diagram model menghasilkan penambahan class model dari iterasi ke-1 yaitu model Work Order.
Class tersebut akan mengekstend model utama yang sudah disediakan oleh Laravel. Class diagram controller danmodelpada iterasi ke-2 dapat dilihat pada Gambar 17 dan 18.
Gambar 17. Class Diagram Controller
Gambar 18. Class Diagram Model
Pemodelan data dapat digambarkan dengan menggunakan PDM (Physical Data Modelling).
PDM digunakan untuk memberikan gambaran bagaimana hubungan antara tabel satu dengan tabel lainnya. Pada iterasi ke-2 terdapat penambahan tabel yaitu tabel Work Order yang berfungsi untuk mengelola data work order
dalam melakukan pengajuan, validasi, upload
bukti, dan proses lainnya. PDM pada iterasi ke-2 dapat dilihat pada Gambar 19.
Gambar 19. Physical Data Modelling Proses perancangan berikutnya yaitu perancangan antarmuka pengguna. Perancangan antarmuka pengguna memberikan gambaran antarmuka sistem dengan membuat wireframe
dari setiap antarmuka yang ada pada sistem. Perancangan antarmuka dapat dilihat pada Gambar 20.
Gambar 20. Wireframe Mengelola Work Order (Remas)
Selanjutnya dilakukan proses implementasi yang terdiri dari implementasi antarmuka pengguna, implementasi basis data, dan implementasi fungsi. Implementasi antarmuka pengguna adalah antarmuka dari sistem yang sudah melalui proses kode. Antarmuka diimplementasikan dengan menggunakan
framework dari Bootstrap. Implementasi antarmuka dapat dilihat pada Gambar 21. Implementasi basis data pada iterasi ke-2
terdapat penambahan tabel yaitu tabel work order yang berfungsi dalam pengelolaan data yang berhubungan dengan fungsi dari work order dan tabel users pada iterasi ke-2 memiliki peran dalam fitur mengelola pengguna dan ganti
password. Selanjutnya implementasi sistem pada iterasi ke-2
,
fungsi controller mencakup pengelolaanController, operasionalController, dashboardController, workorderController, dan gantiPasswordController. Setiap controllermemiliki fungsi yang berbeda-beda sesuai dengan kebutuhan dari fitur masing-masing.
Gambar 21. Implementasi Antarmuka Pengguna Mengelola Work Order (Remas)
Proses integrasi sistem pada iterasi ke-2 pertama dilakukan dengan mengembangkan fungsi mengelola pengguna. Pengelolaan pengguna dilakukan pertama agar dapat memberikan pendaftaran kepada pengguna dan pemberian hak akses dalam mengakses sistem. Selanjutnya dilakukan pengembangan melihat informasi saldo, lalu dilanjutkan dengan pengembangan melihat dashboard yang mengambil dari data transaksi pada iterasi ke-1. Kemudian dilakukan pengembangan mengelola
work order untuk pihak bendahara dan remas. Dan terakhir dilakukan pengembangan mengganti password.
Proses evaluasi sistem pada iterasi ke-2 dilakukan dengan menggunakan metode black-box validation testing dan usability
menggunakan task scenario dan System Usability Scale (SUS). Pengujian validasi menyatakan bahwa fungsi sistem pada iterasi ke-2 bersifat valid, lalu pengujian usability yang diujikan kepada 2 responden menghasilkan nilai
completion rate sebesar 100%, overall relative efficiency sebesar 100%, dan nilai SUS sebesar 70.
Fakultas Ilmu Komputer, Universitas Brawijaya Berdasarkan penelitian yang dilakukan dalam mengembangkan sistem informasi manajemen keuangan pada Masjid Ibnu Sina, didapatkan kesimpulan sebagai berikut:
1. Terdapat proses bisnis as-is utama yang menggambarkan alur proses jalannya keuangan dompet operasional dari saat pemasukan uang sampai pengeluaran uang. Proses tersebut terdiri dari pemasukan uang dompet operasional, pengeluaran uang kegiatan keagamaan dompet operasional, pengeluaran uang kegiatan sehari-hari dompet operasional, dan pelaporan keuangan dompet operasional. Lalu proses bisnis as-is
tersebut dimodelkan ke dalam proses bisnis
to-be yang di dalamnya terdapat sistem informasi keuangan yang berperan dalam mendukung proses keuangan masjid. Selanjutnya dilakukan proses iterasi luar pada iterasi ke-1 dan ke-2 yang di dalamnya terdapat analisis permasalahan dan analisis kebutuhan. Iterasi ke-1 menghasilkan 3 pemangku kepentingan, 5 fitur, 13 persyaratan fungsional, dan 1 persyaratan nonfungsional. Selanjutnya dilakukan pemodelan use case yang menghasilkan 5 use case diantaranya adalah melakukan log in, melakukan log out, mengelola data kategori, mengelola data transaksi, dan mengelola laporan keuangan. Lalu pada iterasi ke-2 menghasilkan 4 pemangku kepentingan, 6 fitur, 14 persyaratan fungsional, dan 1 persyaratan nonfungsional. Pemodelan use case menghasilkan 5 use case diantaranya adalah mengelola pengguna, melihat informasi saldo, melihat dashboard, mengelola formulir work order, dan mengganti password.
2. Hasil perancangan pada iterasi ke-1 dan ke-2 menghasilkan sequence diagram untuk menggambarkan interaksi antar objek, class diagram yang terdiri dari class diagram controller dan class diagram model, pemodelan data berupa PDM, dan perancangan antarmuka pengguna. Pada iterasi ke-1 menghasilkan 3 sequence diagram, 3 class controller dan 4 class model, 3 tabel yang divisualisasikan ke dalam PDM, dan 10 perancangan antarmuka pengguna. Pada iterasi ke-2 menghasilkan 6
sequence diagram, 5 class controller, dan 5
class model, penambahan tabel work order
pada pemodelan data PDM, dan 16 perancangan antarmuka pengguna.
3. Hasil implementasi pada iterasi 1 dan ke-2 menghasilkan implementasi antarmuka pengguna, implementasi basis data, dan implementasi fungsi. Implementasi antarmuka pengguna memanfaatkan kerangka kerja antarmuka Bootstrap dalam proses pengembangan antarmuka, implementasi basis data menggunakan mysql
sebagai DBMS, dan implementasi fungsi menggunakan bahasa pemrograman PHP dengan memanfaatkan kerangka kerja
Laravel.
4. Hasil pengujian dan evaluasi sistem pada iterasi ke-1 dan ke-2 menggunakan pendekatan black-box validation testing
untuk pengujian validasi dan evaluasi
usability dari 3 aspek yaitu effectiveness, efficiency, dan satisfaction yang diuji kepada 2 responden. Iterasi ke-1 dan ke-2 menghasilkan nilai valid pada setiap kasus uji pengujian validasi dan menghasilkan nilai
completion rate untuk mengukur
effectiveness sebesar 95,45% pada iterasi ke-1 dan ke-100% pada iterasi ke-2, overall relative efficiency untuk mengukur efficiency sebesar 94,1% pada iterasi ke-1 dan 100% pada iterasi ke-2, dan nilai SUS untuk mengukur aspek satisfaction menghasilkan nilai sebesar 70 untuk kedua iterasi.
Berdasarkan penelitian yang dilakukan dalam mengembangkan sistem informasi manajemen keuangan pada Masjid Ibnu Sina, saran yang didapat untuk penelitian selanjutnya adalah sebagai berikut:
1. Perbaikan antarmuka pengguna sistem informasi manajemen keuangan Masjid Ibnu Sina.
2. Menambahkan ilmu akuntansi pada sistem, sehingga mendapatkan informasi keuangan yang lebih mendetail.
6. DAFTAR PUSTAKA
Baridwan, Z., 1996. Sistem Informasi Akuntansi.
ed.2. Yogyakarta: BPFE
Dahlan, A.A. et. al. 2000. Ensiklopedi Hukum Islam. Jilid 1. Jakarta: PT Ichtiar Baru Van Hoeve.
Irawati, S., 2006. Manajemen Keuangan. Bandung: PUSTAKA
International Organization of Standardization, 1998. ISO 9241-11 Ergonomic
requirements for office work with visual display terminals (VDTS): Guidance on usability. Geneva: ISO.
Larman, C., 2004. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3nd ed. Boston: Addison Wesley Professional.
Nielsen, J. (2012). How Many Test Users in a Usability Study? Nielsen Norman Group. [online] Tersedia di: <https://www.nngroup.com/articles/how-many-test-users/> [Diakses 10 Desember 2020]
Pressman, R.S., 2010. Software Engineering A Practitioner’s Approach. 7th ed. New York: McGraw-Hill.
Visual Paradigm. n.d. What is Sequence Diagram? [online] Available at:
<https://www.visual- paradigm.com/guide/uml-unified-modelinglanguage/what-is-sequence -diagram/> [Accessed 14 Januari 2021] Weske, M., 2007. Business Process
Management Concept, Languages, Architectures. New York: Springer-Verlag Berlin Heidelberg.
