T1__Full text Institutional Repository | Satya Wacana Christian University: Perancangan dan Impementasi Aplikasi Desktop Pengajuan Anggaran Sistem Informasi Keuangan dan Akuntansi Satya Wacana (SIKASA): Studi Kasus Universitas Kristen Satya Wacana, Salati

Perancangan dan Impementasi Aplikasi Desktop Pengajuan
Anggaran Sistem Informasi Keuangan dan Akuntansi Satya
Wacana (SIKASA)
Studi Kasus : Universitas Kristen Satya Wacana, Salatiga

Artikel Ilmiah

Diajukan kepada
Fakultas Teknologi Informasi
Untuk memperoleh Gelar Sarjana Sistem Informasi

Peneliti :
Indra Prasetya
682015603

PROGRAM STUDI SISTEM INFORMASI
FAKULTAS TEKNOLOGI INFORMASI
UNIVERSITAS KRISTEN SATYA WACANA
SALATIGA
2016


Perancangan dan Impementasi Aplikasi Desktop Pengajuan Anggara Sistem
Informasi Keuangan dan Akuntansi Satya Wacana (SIKASA)
Studi Kasus : Universitas Kristen Satya Wacana, Salatiga
1)

Indra Prasetya, 2) Augie David Manuputty

Program Studi Sistem Informasi
Fakultas Teknologi Informasi
Universitas Kristen Satya Wacana
Jl. Diponegoro 52-60 Salatiga
E-mail: 1)682015603@student.uksw.edu , 2)augiemanuputty@gmail.com
Abstrak
Universitas Kristen Satya Wacana (UKSW) sudah menerapkan sistem informasi
keuangan dan akuntansi Satya Wacana untuk membantu dalam proses administrasi
berupa pencatatan semua pemasukan dan pengeluaran yang dilakukan oleh Universitas.
Namun ada beberapa fungsi yang belum ada seperti pengajuan anggaran non-rutin yang
belum dilakukan menggunakan sistem sehingga hanya bisa dilakukan dengan melakukan
inject langsng kedalam database, selain itu pada sistem lama pengguna dapat mengelola
data pada masa periode lampau sehingga hal tersebut memungkinkan untuk terjadinya

perubahan data yang sebenarnya sudah bersifat read-only. Dalam penelitian ini dengan
menggunakan metode prototype akan merancang dan mengimplementasikan sebuah
aplikasi dekstop pengajuan anggaran untuk sistem informasi keuangan dan akuntansi di
UKSW dengan tujuan untuk mempermudah bagian keuangan agar dapat melakukan
pengajuan anggaran non-rutin menggunakan sistem secara real-time. Serta membatasi
pengguna untuk mengelola pengajuan anggaran periode yang sedang berlangsung dan
periode yang akan datang saja.
Kata Kunci: Aplikasi Desktop, Sistem Infomasi Keuangan dan Akuntansi.
Abstract

Satya Wacana Christian University (SWCU) have applied information systems financial
and accounting to assist in the administrative process of recording all entry and
expenditure be undertaken by universities. But there is some function who has not yet
been as the submission of non routine budget that have not done use the system so that
can only be done by implementing inject directly into a database, in addition to the old
system users can manage data during the past period so that it is possible to change the
data that actually can not be changed. In this study by using the prototype method will
design and implement a desktop application budget submissions for financial and
accounting information systems in SWCU to facilitate the finance department in order to
perform non-routine budget submissions using the system in real-time. And limit users to

manage the budget submission period of on going and next periods only.
Keywords: desktop applications, financial and accounting information system.

_______________________________________________________________________
¹Mahasiswa Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
²Staff Pengajar Fakultas Teknologi Informasi Universitas Kristen Satya Wacana
³Staff Pengajar Fakultas Teknologi Informasi Universitas Kristen Satya Wacana

1.

Pendahuluan

Teknologi Informasi (TI) mampu membuat informasi menjadi lebih efisien
dan efektif, dengan hal ini banyak organisasi yang sudah memanfaatkan dan
berinovasi dalam TI untuk diterapkan dalam membantu proses bisnis.
Pemanfaatan TI secara baik dan tepat dapat membuat informasi dalam proses
bisnis menjadi lebih akurat, real time, relevan, ekonomis serta dapat membantu
dalam mengambil keputusan terkait dengan kebijakan manajemen. Dengan
pengambilan kebijakan yang tepat pada manajemen maka akan berdampak pada
kemajuan suatu organisasi sehingga organisasi tersebut akan siap bersaing dengan

organisasi lain. Oleh karena itu tidak dapat dipungkiri bahwa penggunaan IT
dalam suatu organisasi merupakan suatu keharusan terlebih pada organisasi
berskala besar seperti Universitas Kristen Satya Wacana (UKSW).
UKSW merupakan perguruan tinggi swasta yang berdiri sejak tahun 1956.
Pada tahun 2016 UKSW memiliki 15 fakultas dengan 56 Program Studi beserta
14.000 mahasiswa yang aktif registrasi. Dengan besarnya UKSW ini menuntut
adanya pengelolaan sistem administrasi keuangan dan akuntansi yang
professional dan saling terintegrasi untuk mengoptimalkan dalam memberikan
pelayanan pendidikan.
Pada tahun 1998 UKSW mulai menerapkan Sistem Informasi Akademik
Satya Wacana (SIASAT), proses utama pada sistem ini adalah proses registrasi,
pengambilan mata kuliah dan melihat nilai akademik oleh mahasiswa. Siasat juga
digunakan oleh dosen sebagai acuan untuk melakukan perwalian dan memberi
nilai atas matakuliah yang diampu. Pada awalnya SIASAT hanya sebatas sistem
dengan cakupan area intranet, karena kebijakan tertentu pada tahun 2004 SIASAT
sudah menjadi online dan dapat diakses dari mana saja menggunakan internet.
Sistem Manajemen Ruang (SIMANRU) juga dikembangkan dan diterapkan oleh
UKSW pada tahun 2012 untuk mengelola semua ruang yang ada di UKSW. Di
sisi lain pada tahun 2003 UKSW sudah mulai menerapkan Sistem Informasi
Keuangan dan Akuntansi Satya Wacana terkomputerisasi (SIKASA) berbasis

Website. Sikasa dirancang untuk mengelola pendapatan yang ditermia Universitas
secara umum dan mengelola pengeluaran UKSW baik aktivitas operasional
Universitas seperti gaji pegawai maupun pengeluaran yang dilakukan atas
kebijakan tertentu (khusus) yang dilakukan oleh UKSW. Sehingga sejak tahun
2003 UKSW melakukan kegiatan berupa pencatatan, pemrosesan dan pelaporan
keuangan dan akuntansi sudah berbasis komputer . Namun pada SIKASA ini
masih memiliki beberapa kelemahan berupa durasi yang dibutuhkan unit/subunit
untuk melakukan kegiatan pencatatan/pelaporan cukup lama, unit/subunit bisa
secara bebas melakukan perubahan terhadap data lama dan belum terpenuhinya
beberapa fungsi seperti pengajuan anggaran yang hanya bisa dilakukan untuk
kelompok pengajuan anggaran rutin dan discretionary saja. Sehingga untuk
pengajuan anggaran kelompok non-ruitn masih dilakukan dengan cara inject
langsung ke dalam database di mana cara seperti ini cukup berbahaya karena jika
perubahan data dilakukan langsung melalui database data tidak akan bisa di-filter
oleh aplikasi, hal ini juga akan mempengaruhi kinerja database serta aplikasi
SIKASA. Oleh sebab itu diperlukan sebuah sistem yang mampu melakukan

1

pengajuan anggaran untuk kelompok rutin, discretionary dan juga non-rutin

secara baik serta bisa melakukan pencatatan dan pelaporan pengajuan anggaran
dengan waktu singkat untuk megelola data pengajuan anggaran dalam periode
buku yang sedang berlangsung dan periode yang akan datang saja.
Dari permasalahan di atas maka penulis akan merancang sekaligus
mengimplementasikan aplikasi desktop sistem informasi keuangan dan akuntansi
Satya Wacana khusus dalam pengajuan anggaran yang mampu melakukan
pengajuan kelompok rutin, discretionary dan non-rutin untuk data pengajuan
anggaran periode yang sedang berlangsung dan periode yang akan datang beserta
pelaporan pengajuan anggaran. Aplikasi desktop ini nantinya akan digunakan oleh
semua unit/subunit kerja yang ada di lingkungan UKSW serta dapat digunakan
oleh universitas pusat (bagian keuangan) untuk mengelola dan memantau semua
pengajuan anggaran yang dilakukan oleh unit/subunit.

2. Kajian Pustaka
2.1

Penelitian terdahulu
Penelitian yang dilakukan oleh Wina Setiawati dengan judul “Aplikasi
Laporan Keuangan Berbasis Web Untuk Kelurahan Dukuh” melakukan
perancangan sistem dengan menggambarkan alur proses bisnis aplikasi dengan

diagram Data Flow Diagram (DFD), perancangan database yang digambarkan
menggunakan Entity Relation Diagram (ERD) serta menggunakan Dreamweaver
sebagai editor, bahasa pemrogaman PHP , MySQL sebagai database serta ajax
untuk menunjang tampilan yang efektif. Hasil dari perancangan ini adalah
membuat proses pelaporan keuangan yang dilakukan secara manual menjadi
terotomatisasi dan mempermudah dalam pengelolaan dan akses bagi warga untuk
mengetahui perihal anggaran kelurahan Dukuh [1].
Penelitian dengan judul “Rancang Bangun Sistem Informasi Pengelolaan
Keuangan Daerah (Studi Kasus pada SKPD dinas Energi dan Sumber Daya
Mineral Kabupaten Kepulauan Sangihe)” Penelitian ini membahas perancangan
dan membangun sebuah aplikasi keuangan berbasis desktop yang sebelumnya
belum ada pada dinas terkait, untuk memudahkan proses penatausahaan
pengeluaran yaitu pengajuan dana dan pembuatan laporan dengan menggunakan
metode FAST (Framework for Application of System Thinking) dengan
microsoft Visual Basic 8.0 dan database MYSQL [2].
Dari penelitian-penelitian terdahulu yang pernah dilakukan terkait
perancangan dan pembangunan aplikasi keuangan, penelitian ini dengan judul
“Perancangan dan Implementasi Aplikasi Desktop Pengajuan Anggaran Sistem
Informasi Keuangan dan Akuntansi Satya Wacana (SIKASA) Studi Kasus:
Universitas Kristen Satya Wacana, Salatiga” membahas mengenai merancang dan

membangun sebuah aplikasi keuangan berbasis desktop tingkatan Universitas
menggunakan visual studio bahasa pemrograman .Net yaitu VB.Net dan C#
dengan menggunakan web service dan Json sebagai penghubung antara front-end
serta back-end . Aplikasi ini ditujukan untuk bagian keuangan Universitas Satya
Wacana yang mengelola anggaran untuk memudahkan dalam menjalankan proses
bisnis sesuai dengan prosedur yang ada.

2

2.2 Landasan Teori
Sistem informasi merupakan seperangkat prosedur yang terorganisasi
dengan sistematik yang jika akan dilaksanakan akan menyediakan informasi yang
dapat dimanfaatkan dalam proses pembuatan keputusan [3]. Pada suatu sistem
informasi juga terdapat perancangan sistem, dimana perancangan sistem adalah
suatu fase dimana diperlukan suatu keahlian perancangan untuk elemen-elemen
komputer yang akan mengunakan sistem yaitu pemilihan peralatan dan program
komputer untuk sistem yang baru. Tujuan dari perancangan sistem informasi
adalah untuk memenuhi kebutuhan pemakaian sistem (user ) dan untuk
memberikan gambaran yang jelas dan menghasilkan rancangan bangun yang
lengkap kepada pemograman komputer dan ahli-ahli teknik lainnya yang terlibat

dalam pengembangan atau pembuatan sistem [4].
Impelentasi adalah suatu tindakan atau pelaksanaan dari sebuah rencana
yang sudah disusun secara matang dan terperinci. Implementasi biasanya
dilakukan setelah perencanaaan sudah dianggap fix. Sedangkan implementasi
sistem adalah prosedur yang dilakukan untuk menyelesaikan desain yang ada
dalam dokumen desain sistem yang disetujui dan menguji, meng instal, memulai
menggunakan sistem yang baru atau sistem yang diperbaiki [5].
Anggaran merupakan suatu rencana yang disusun secara sistematis dalam
bentuk angka dan dinyatakan dalam unit moneter yang meliputi seluruh kegiatan
perusahaan untuk jangka waktu (periode) tertentu di masa yang akan datang. Oleh
karena rencana yang disusun dinyatakan dalam bentuk unit moneter, maka
anggaran seringkali disebut juga dengan rencana keuangan. Dalam anggaran,
satuan kegiatan dan satuan uang menempati posisi penting dalam arti segala
kegiatan akan dikuantifikasikan dalam satuan uang, sehingga dapat diukur
pencapaian efisiensi dan efektivitas dari kegiatan yang dilakukan [6].
Akuntansi merupakan suatu sistem pencatatan seluruh aktivitas keuangan
organisasi dan dapat menghasilkan laporan keuangan yang dapat digunakan para
pemilik kepentingan dalam mengambil keputusan. Proses administrasi akuntansi
saat ini sudah memanfaatkan IT dalam pelaksanaanny. Implementasi IT dalam
proses administrasi akuntansi ini seringkali disebut dengan Sistem Informasi

Akuntansi [7].

Gambar 1. Arsitektur web service.

Web service dapat diartikan juga sebuah metode pertukaran data, tanpa
memperhatikan di mana sebuah database ditanamkan, dibuat dalam bahasa apa
3

sebuah aplikasi yang mengkonsumsi data, dan di platform apa sebuah data itu
dikonsumsi. Web service mampu menunjang interoperabilitas. Sehingga web
service mampu menjadi sebuah jembatan penghubung antara berbagai sistem
yang ada [8].
3.

Metode Penelitian

Dengan menggunakan metode penelitian kualitatif, identifikasi dan
perumusan masalah didapat berdasarkan interaksi wawancara secara langsung
dengan developer SIKASA lama, unit/subunit dan bagian keuangan selaku
pengguna SIKASA. Selanjutnya adalah perancangan sistem menggunakan metode

prototype, setelah sistem berhasil dibuat maka akan dilakukan testing dan akan
diimplementasikan setelah semua fungsi dinyatakan berjalan dan disetujui oleh
tester . Pada tahap akhir akan dilakukan monitoring dan evaluasi.
Tahapan 1: Identifikasi dan perumusan masalah
Hasil yang diharapkan : user-reqirement

Tahapan 2: Perancangan dan pengembangan sistem menggunakan metode
prototype
Hasil yang diharapkan : Aplikasi desktop pengajuan anggaran

Tahapan 3: Testing
Hasil yang diharapkan : Perbaikan aplikasi desktop pengajuan anggaran

Tahapan 4: Implementasi
Hasil yang diharapkan : instalasi untuk mulai digunakan user

Tahapan 5: Monitoring dan evaluasi
Hasil yang diharapkan : Memantau dan mengevaluasi sistem
Gambar 2. Tahapan penelitian.

Dari tahapan identifikasi dan perumusan masalah diketahui bahwa pada
modul pengajuan anggaran SIKASA lama hanya bisa melakukan pengajuan
anggaran untuk kelompok rutin dan discretionary saja, sedangkan untuk
kelompok non-rutin dilakukan dengan cara inject langsung kedalam database. Hal
ini menyebabkan bagian keuangan tidak bisa melakukan pengajuan anggaran
non-rutin secara mandiri dengan menggunakan sistem karena harus meminta
bantuan kepada bagian IT untuk melakukan inject database. Selain itu pengajuan
4

anggaran yang dilakukan dengan cara inject tidak akan ada proses filter data
sehingga besar kemungkinan terjadi kesalahan. Pengajuan anggaran non-rutin
tidak memiliki batasan periode sehingga bisa dilakukan kapan saja. Data yang
dapat dikelola hanya data pengajuan anggaran non rutin untuk periode buku yang
sedang berlangsung dan periode buku yang akan datang saja. Dari permasalahan
pokok yang ditemukan maka perancangan sistem pengajuan anggaran akan fokus
untuk menyelesaikan permasalahan pengajuan anggaran kelompok non-rutin.
Pengajuan anggaran kelompok non-rutin hanya bersifat sebagai pencatatan saja.
Pada pengajuan anggaran kelompok rutin dan discretionary dimana daftar
anggaran yang diajukan oleh setiap unit kerja akan di-review oleh Komite
Anggaran UKSW kemudian akan diputuskan mata anggaran mana saja yang
disetujui, diperbaiki atau dibatalkan secara bersama-sama dengan pimpinan unit
kerja (Perwalian Anggaran). Berbeda dengan anggaran kelompok non-rutin,
berikut adalah diagram alur mengenai pengajuan anggaran non-rutin :
Start

A

Pengajuan
anggaran oleh
jajaran pimpinan

Input data
pengajuan
anggaran non rutin

ke yayasan

Simpan pengajuan
Persetujuan
Rapat pembina
oleh Pimppinan
dan Yayasan
Cetak Laporan
pengajuan
Hasil rapat
persetujuan
anggaran

Penandatang
anan laporan

Disetujui

Realisasi
anggaran

Tidak

Ya
End

A

Gambar 3. Diagram flowchart proses bisnis pengajuan anggaran non rutin.

Alur dari pengajuan anggaran non rutin sedikit berbeda dengan pengajuan
anggaran lainnya. Pengajuan anggaran non rutin tetap memiliki tahap perencanaan
di mana yang melakukan perencanaan adalah jajaran pemimpin di Universitas
yang nantinya akan diajukan pada tingkat Yayasan karena sumber dana anggaran
non rutin adalah dari Yayasan, pada tahap pengajuan ini banyak sekali
pertimbangan yang dilakukan seperti tingkat urgent hingga nominal pengajuan
yang dipengaruhi oleh pengajuan anggaran sebelumnya. Setelah pengajuan
dilakukan pada waktu tertentu akan diadakan rapat pembina oleh pimpinan
Universitas dan Yayasan yang mengulas persetujuan setiap anggaran yang
5

diajukan. Hasil dari tahapan ini adalah menentukan anggaran mana saja yang akan
disetujui, ditunda atau ditolak. Jika terjadi penolakan pengajuan anggaran bisa
dilakukan pengajuan atas kebutuhan yang sama pada periode selanjutnya, jika
anggaran disetujui maka data dari pengajuan anggaran akan dimasukan ke dalam
sistem pengajuan anggaran non-rutin oleh bagian keuangan untuk disimpan
sebagai pencatatan kemudian daftar pengajuan anggaran akan dicetak untuk
dimintakan tanda tangan oleh Bagian Keuangan, Pimpinan Unit Anggaran dan
Unit Anggaran untuk diarsipkan. Tahapan terakhir adalah merealisasikan
anggaran yang telah diajukan untuk digunakan sesuai dengan perencanaan.
Pada tahapan perancangan dan pengembangan sistem ini dilakukan
menggunakan metode prototype.

Gambar 4. Tahapan pengembangan sistem dengan metode Prototype [9].

Mulai dari tahapan listen to customer di mana sistem yang akan dibangun
dibagi menjadi 2 halaman utama. Halaman rangkuman untuk menampilkan data
pengajuan anggaran kelompok non-rutin yang telah diajukan oleh unit/subunit
pada periode yang sedang berlangsung dan yang akan datang. Kemudian halaman
pengajuan anggaran non-rutin yang digunakan untuk mengajukan anggaran oleh
unit/subunit dan bagian keuangan di mana jumlah pengajuan untuk setiap
unit/subunit bisa lebih dari 1 rekening sekaligus. Pada halaman rangkuman
terdapat fitur pembatalan pengajuan dengan syarat dana yang dibatalkan tidak
boleh lebih dari sisa anggaran yang tersedia oleh setiap rekening dalam
unit/subunit. Kedua halaman harus memiliki fitur laporan untuk melakukan printout data pengajuan anggaran kelompok non-rutin. Dalam metode prototype
tahapan selanjutnya adalah mulai mengembangkan sistem. Aplikasi ini dibangun
dengan bahasa vb.net sebagai front-end dan C# sebagai back-end dan
dihubungkan dengan web-service dan Json. Database yang digunakan adalah
SQL Server dan pelaporan yang menggunakan crystal report. Setelah aplikasi jadi
maka tahapan selanjutnya adalah uji coba yang dilakukan oleh user dan mendapat
masukan untuk perbaikan aplikasi sampai aplikasi sesuai dengan permintaan dan
bisa berjalan lancar. Use Case dari pengajuan anggaran dapat dilihat pada gambar
5.

6

Ubah
Hapus

Tambah

Cetak daftar
pengajuan anggaran non-rutin








Pengajuan Anggaran
non-rutin
Pembatalan pengajuan
Anggaran non-rutin




Cetak Rangkuman
anggaran non-rutin

Bagian Keuangan

Gambar 5. Diagram Use case pengajuan anggaran non-rutin

Terdapat 1 aktor yaitu begian keuangan di mana bagian keuangan bisa
melihat rangkuman pengajuan anggaran non-rutin. Bagian keuangan juga
memiliki kemampuan untuk membatalkan pengajuan dan mencetak rangkuman
anggaran sebagai pelaporan. Bagian keuangan juga bisa mengelola pengajuan
anggaran non-rutin serta dapat mencetak untuk ditanda tangani bagian keuangan,
pimpinan unit dan unit anggaran. Alur pengajuan anggaran non-rutin dapat dilihat
pada gambar 6.
Bagian Keuangan

Sistem

Pengajuan
anggaran non-rutin

Menampilkan form
pengajuan anggaran

Memilih
unit/sub-unit
Menampilkan form
tambah pengajuan

Tambah
pengajuan
menentukan
rekening

Menampilkan
sisa anggaran

Menentukan jumlah
pengajuan dan keterangan
Simpan
temporary

Simpan

ya

tidak

Simpan
pengajuan

Tambah data
pengajuan ?

Simpan kedalam
database

Gambar 6. Diagram Activity Pengajuan anggaran non-rutin
Dari diagram aktivity dapat dilihat runtutan bagian keuangan ketika
mengajukan anggaran non-rutin. Pengajuan anggaran non-rutin bisa dilakukan
lebih dari 1 rekening dalam sekali pengajuan oleh unit. Pengajuan anggaran hanya
bersifat sebagai pencatatan sehingga data hanya bisa diajukan oleh bagian

7

keuangan dan anggaran yang sudah diajukan tidak perlu diproses untuk ke tahap
perwalian anggaran seperti anggaran kelompok rutin dan discretionarry. Struktur
dan relasi database yang digunakan khusus untuk pengajuan anggaran non-rutin
dapat dilihat pada gambar 7.

Gambar 7. Struktur dan relasi database yang digunakan khusus anggaran non-rutin

Terdapat 8 tabel yang digunakan dalam pengajuan anggaran non-rutin.
Tabel yang bersifat master/ sebagai acuan seperti tabel “Tuser”, “PeriodeBuku”,
“TUnit”, “Rekening”, “MasterKelompok” dan “MasterSatuan” serta memiliki
tabel utama yaitu “AnggaranNR” dan “DetailAnggaranNR”. Setiap pengajuan
anggaran non-rutin akan memiliki 1 baris inti yang disimpan sebagai header
dalam tabel AnggaranNR. Karena setiap pengajuan anggaran non-rutin bisa
memilki lebih dari 1 item rekening pengajuan maka item-item tersebut akan
disimpan pada tabel DetailAnggaranNR. Yang bertugas untuk berhubungan
dengan database adalah back-end. Class utama pada back-end memiliki banyak
fungsi yaitu GetPeriodeAnggaranAktif(), GetPeriode AnggaranSelanjutnya(),
AmbilListComboUnit(),
AmbilListComboUnitAll(),
Ambil
ListComboRekening(), CariListAnggaranNonRutin(), SimpanDaftarPengajuan
AnggaranNonRutin() dan SimpanBatalDaftarPengajuanAnggaranNonRutin().
Fungsi-fungsi ini dihubungkan melalui web-service yang dikemas menggunakan
Json.
Setelah aplikasi berhasil dibuat maka selanjutnya adalah tahapan testing.
Tahapan testing ini dilakukan dengan berbagai macam metode dan banyak tester .
Testing awal dilakukan oleh internal team programmer dengan menggunakan
metode blackbox, jika inputan dan output sesuai maka aplikasi dinyatakan siap
untuk diperlihatkan ke user . Namun jika output tidak sesuai / output sesuai tetapi
membutuhkan waktu lama dan tidak efisien maka akan dilakukan uji
menggunakan metode whitebox di mana aplikasi akan dibedah dan diteliti untuk
setiap baris pengkodean agar aplikasi bekerja lebih maksimal. Testing berikutnya
dilakuklan oleh user secara langsung serta diadakan pelatihan terhadap aplikasi
8

SIKASA baru oleh setiap unit/subunit secara berkala. Pada tahapan ini user
berhak melakukan uji coba semua fitur/fungsi yang ada pada aplikasi SIKASA
baru.
Ketika aplikasi dinyatakan siap untuk digunakan dan user sudah melakukan
persetujuan maka tahapan selanjutnya adalah implementasi. Implementasi
dilakukan dengan cara menaruh aplikasi inti dan database di ruang server .
Kemudian shortcut dari aplikasi SIKASA akan didistribusikan ke seluruh
unit/subunit untuk digunakan dalam mengakses aplikasi. Pada gambar 8 dapat
dilihat diagram deployment dari modul pengajuan anggaran berbasis desktop.
PC Bagian
Keuangan (Client)
+Distribusi Shortcut
Aplikasi

App Server

Web Service
+ Back-end
(.Net, Json)

+ Front-end
(.Net, Json)

Database
+Sql Server

Gambar 8. diagram deployment dari modul pengajuan anggaran berbasis desktop.

Diagram deployment dapat menggambarkan tahap implementasi, pada
personal computer (PC) yang digunakan bagian keuangan hanya memiliki
shortcut yang sudah didistribusikan dan bersumber dari AppServer di mana pada
AppServer merupakan pusat aplikasi SIKASA secara utuh (front-end) dan
memiliki business layer yang berasal dari web-services di mana web-service
adalah bagian yang mampu berhubungan dengan database SIKASA.
Setelah aplikasi terpasang tahap selanjutnya adalah monitoring dan evalusei.
Monitoring dan evaluasi sangat dibutuhkan karena pengembangan SIKASA lama
ke SIKASA baru dilakukan menggunakan cara migrasi sistem cut-off. Dimana
SIKASA lama dihentikan seketika dan digantikan langsung dengan SIKASA yang
baru. Sehingga sangat memungkinkan suatu waktu terjadi error dan memerlukan
penanganan secara cepat oleh team programmer . Kemudian dari error yang
didapat dari hasil monitoring akan dilakukan evaluasi untuk perbaikan sistem.

4.

Hasil dan Pembahasan

Hasil dari pengembangan sistem Prototype tahap awal adalah halaman
rangkuman anggaran non-rutin dan juga halaman pengajuan anggaran non-rutin.
Pada pengajuan anggaran non-rutin hanya memiliki fungsi tambah pengajuan,
ubah pengajuan dan hapus pengajuan yang disimpan secara temporary
menggunakan data table. Setelah penambahan pengajuan selesai dilakukan maka
bisa menekan tombol simpan yang sudah disediakan untuk menyimpan kedalam
database. Proses simpan kedalam database dilakukan dengan memberikan daftar
anggaran yang diajukan dari data table dari front-end ke back-end melalui web
service yang dikemas ke dalam Json. Sedangkan pada halaman rangkuman hanya
memiliki fungsi mengambil data pengajuan anggaran saja yang didapat dari backend melalui web service. Pada prototype tahap awal pelaporan berupa daftar
9

pengajuan anggaran secara keseluruhan atau berdasarkan unit/subunit tertentu.
Setelah prototype tahap awal selesai dilakukan testing oleh team programmer dan
mendapatkan beberapa hasil evaluasi yaitu : Ketika melakukan penambahan
pengajuan anggaran, setelah memilih rekening yang akan diajukan nominal sisa
anggaran tetap 0. Setalah melakukan pengajuan anggaran, pada halaman
rangkuman tidak bisa melihat detail dari setiap transaski yang telah diajukan.
Dikarenakan aplikasi belum memenuhi semua kebutuhan user , maka dilakukan
prototype tahap kedua.
Prototype tahap kedua merupakan perbaikan dari hasil evaluasi prototype
tahap pertama. Dimulai dengan penyempurnaan fungsi untuk mendapatkan
nominal sisa anggaran setelah user memilih rekening yang diajukan. Kemudian
penambahan fitur untuk melihat detail dari transaksi yang sudah dilakukan dengan
menekan kolom nomor bukti transaksi pada halaman rangkuman anggaran.
Setelah perbaikan aplikasi dilakukan, testing dilakukan kembali dan mendapatkan
beberapa point evaluasi yaitu: sisa anggaran sudah secara otomatis muncul sesuai
dengan rekening yang dipilih oleh user. Detail anggaran non-rutin yang sudah
diajukan bisa tampil sesuai dengan apa yang diinputkan oleh user. Penambahan
fungsi untuk membatalkan pengajuan anggaran non-rutin pada halaman
rangkuman anggaran dengan syarat nominal anggaran yang dibatalkan tidak boleh
meliebihi sisa anggaran yang ada sesuai dengan permintaan user .
Prototype tahap tiga dilakukan untuk perbaikan berdasarkan hasil evaluasi
prototype tahap dua. Dilakukan penambahan fungsi pembatalan pengajuan
anggaran non-rutin dari back-end yang diakses melalui web-service serta dipicu
oleh tombol batal yang diletakkan pada halaman rangkuman anggaran. Hasil
evaluasi dari prototype tahap tiga ini adalah fitur pembatalan pengajuan anggaran
sudah berjalan dengan baik dilengkapi dengan form untuk menampung
keterangan/alasan user melakukan pembatalan. Pada bagian pelaporan user
meminta untuk merubah format di mana terdapat tambahan keterangan perihal
pengajuan anggaran dan disertakan kolom untuk tanda tangan bagian keuangan,
pimpinan unit anggaran dan unit anggaran untuk persetujuan atas pengajuan
anggaran non-rutin yang telah diajukan.
Prototype tahap akhir adalah perbaikan dari prototype tahap tiga di mana
dilakukan perubahan pada format pelaporan. Hasil dari evaluasi prototype tahap
akhir ini adalah pelaporan yang sesuai dengan permintaan user. Pada prototype
tahap akhir ini juga dilakukan penambahan validasi untuk melakukan checking
pada setiap inputan yang dilakukan oleh user .
Setelah prototype sudah dalam tahap akhir dan telah dilakukan test akhir
secara keseluruhan maka aplikasi bisa digunakan oleh user untuk menjalankan
proses bisnis pangajuan anggaran non-rutin. Bagian keuangan Universitas bisa
melakukan pengajuan anggaran ke dalam sistem berdasarkan hasil rapat
persetujuan pimpinan Universitas dengan Yayasan yang telah melakukan
persetujuan anggaran non-rutin. Ketika pengajuan telah dilakukan, bagian
keuangan wajib mencetak laporan untuk ditanda tangani oleh pihak terkait perihal
persetujuan sebelum dilakukan pengambilan dana anggaran yang diajukan.
Nominal dari pengajuan anggaran tidak bisa diubah karena bersifat pasti, bagian

10

keuangan bisa melakukan pembatalan pengajuan anggaran sebelum dana
terealisasikan dengan menyertakan alasan tertentu.
Aplikasi desktop pengajuan anggaran non-rutin pada sistem informasi
keuangan dan akuntansi ini memiliki dua halaman utama sesuai dengan hasil
wawancara dengan user . Halaman rangkuman anggaran non-rutin dan juga
halaman pengajuan. Pada halaman rangkuman user dapat melihat anggaran nonrutin yang sudah diajukan untuk periode buku yang akan datang.

Gambar 9. Tampilan rangkuman anggaran non-rutin

Tampilan rangkuman anggaran non-rutin memiliki pilihan filter berupa
tanggal transaski dan juga unit yang sifatnya optional. Filter ini digunakan ketika
user ingin melihat data anggaran non-rutin yang sudah diajukan berdasarkan
tanggal atau unit tertentu. Ketika user tidak melakukan filter maka seluruh data
pengajuan anggaran non-rutin periode buku yang akan datang akan tampil secara
keseluruhan dengan menekan tombol “Cari”. Pada bagian bawah terdapat tombol
“Batalkan Pengajuan Anggaran Non-Rutin” yang digunakan untuk membatalkan
pengajuan anggaran non-rutin secara permanen dengan cara memilih item pada
data rangkuman kemudian menekan tombol pembatalan, maka secara otomatis
data yang dipilih akan hilang dengan syarat pembatalan hanya bisa dilakukan
ketika sisa anggaran melebihi dari nominal anggaran yang dibatalkan. Ketika
syarat tidak terpenuhi maka akan muncul pesan notifikasi bahwa anggaran gagal
untuk dibatalkan. Pada halaman rangkuman user juga bisa mencetak data. Data
pada laporan akan sama serperti data yang tampil pada halaman rangkuman.

11

Gambar 10. Tampilan laporan rangkuman anggaran non-rutin

Pada gambar 10 merupakan tampilan format dari pelaporan dari data
rangkuman anggaran non-rutin. User juga bisa melihat setiap detail pengajuan
anggaran non-rutin. Data yang tampil pada rangkuman merupakan header nya
saja. Sedangkan dalam 1 data header bisa memiliki lebih dari 1 item rekening
pengajuan anggaran non-rutin.

Gambar 11. Tampilan Detail rangkuman anggaran non-rutin

Pada gambar 11 merupakan tampilan ketika user menekan kolom nomor
bukti transaksi pada halaman rangkuman. Fitur ini ditujukan untuk melihat
kembali data yang sudah diajukan secara detail. Pada fitur ini data tidak bisa
ditambah, diubah atau dihapus. Halaman berikutnya adalah halaman pengajuan
anggaran, pengajuan anggaran dapat diakses dengan cara menekan tombol
“Pengajuan anggaran non-rutiin” pada halaman rangkuman. Halaman pengajuan
digunakan oleh bagian keuangan untuk mengajukan anggaran.

12

Gambar 12. Tampilan halaman pengajuan anggaran non-rutin

Pada halaman pengajuan terdapat filter di mana user dapat memilih
unit/subunit mana yang akan melakukan pengajuan anggaran non-rutin.
Kemudian user bisa menekan tombol “Tambah” untuk menambah item
pengajuan.

Gambar 13. Tampilan pop-up tambah anggaran non-rutin

Pada menu tambah maka akan ada kolom yang bersifat read only seperti
tanggal transaksi yang diambil tanggal real time pada waktu melakukan
pengajuan anggaran, periode anggaran yang diambil secara otomatis dari periode
buku anggaran yang akan datang/selanjutnya dan unit/subunit yang secara
otomatis terisi berdasarkan unit/subunit yang dipilih dari halaman pengajuan
anggaran. Selanjutnya user bisa memilih rekening mana yang akan diajukan
sebagai anggaran non-rutin, kemudian secara otomatis data sisa anggaran untuk
rekening yang dipilih oleh user akan muncul. Data sisa anggaran digunakan
sebagai acuan untuk mengisikan jumlah pengajuan dan yang terakhir user bisa
13

memberi keterangan tertentu bila diperlukan yang bersifat optional. Setelah semua
terisi maka tekan tombol simpan pada menu pop-up tambah anggaran. Maka item
yang sudah ditambahkan tadi akan masuk kedalam list pengajuan di mana masih
bersifat simpan sementara/temporary. Data yang masih berada dalam list
memungkinkan untuk diolah seperti diubah / dihapus dari list. Setelah proses
pengelolaan data selesai tekan tombol simpan yang berada pada halaman
pengajuan anggaran. Sehingga data yang sudah diajukan akan tersimpan kedalam
database. User juga bisa melakukan pelaporan pengajuan anggaran. Format
pelaporan dari pengajuan anggaran non-rutin bisa dilihat pada gambar 14.

Gambar 14. Tampilan pelaporan pengajuan anggaran non-rutin

Pada tampilan pelaporan pengajuan bagian atas kiri terdapat keterangan
yang menyertakan nomor transasksi, unit yang mengajukan dan keterangan. Pada
bagian kanan atas terdapat judul laporan, tahun anggaran, tanggal cetak, tanggal
pengajuan dan nomor bukti. Nominal jumlah total akan secara otomatis dihitung
oleh sistem. Laporan pengajuan ini dicetak juga untuk ditanda tangani bagian
keuangan, Pimpinan Unit Anggaran dan Unit anggaran.
Untuk memastikan semua fungsi berjalan dengan baik pada aplikasi desktop
pengajuan Anggaran non-rutin Sistem Informasi Keuangan dan Akuntansi Satya
Wacana dilakukan testing tahap akhir. Dalam pengujian ini menggunakan metode
pengujian black-box testing. Black-box testing adalah pengujian aspek
fundamental sistem tanpa memperhatikan struktur logika internal perangkat lunak
yang diuji. Pengujian black box merupakan metode perancangan data uji yang
didasarkan pada spesifikasi perangkat lunak. Data diuji (input), dieksekusi
(proses) pada perangkat lunak kemudian keluaran (output), dari perangkat lunak
dicek apakah telah sesuai dengan yang diharapkan atau masih perlu pebaikan [10].
Berikut adalah tabel pengujian black-box pada aplikasi desktop pengajuan
anggaran non-rutin:
No
1

Skenario Pengujian
Testing fungsi
GetPeriodeAnggaranA

Test Case
Memanggil
fungsi ketika

14

Hasil yang diharapkan
Dapat mengambil periode
angaran aktif dari tabel

Hasil
Uji
Valid

ktif()
Testing fungsi
GetPeriodeAnggaranS
elanjutnya()
Testing fungsi
AmbilListComboUnit
All()
Testing fungsi
CariListAnggaranNon
Rutin()
Testing fungsi
CariListAnggaranNon
Rutin()

form load
Memanggil
fungsi ketika
form load
Memanggil
fungsi ketika
form load
Tanpa
menggunakan
filter
Menggunakan
filter unit

6

Testing fungsi
CariListAnggaranNon
Rutin()

Menggunakan
filter tanggal
transaksi

7

Testing fungsi
CariListAnggaranNon
Rutin()

Menggunakan
filter unit dan
tanggal
transaksi

8

Menekan tombol print

9

Menekan tombol print

Data
rangkuman
kosong
Tersedia data
rangkuman

10

Menekan kolom link
No.Bukti Transaksi

11

Menekan tombol Batal
Valid
Pengajuan Anggaran
Non Rutin
Menekan tombol
Akan berpindah ke halaman
Valid
Pengajuan anggaran
pengajuan
Non Rutin
Menekan tombol
Akan keluar dari modul
Valid
Selesai
pengajuan anggaran non-rutin
Tabel 1. Tabel pengujian black box pada semua fungsi halaman rangkuman.

2

3

4

5

12

13

No
1
2

Skenario Pengujian
Menekan tombol
Tambah
Testing fungsi simpan
tambah pengajuan

Test Case

Tanpa
mengisikan
kolom
rekening
15

periode buku
Dapat mengambil periode
angaran aktif dari tabel
periode buku
Dapat menampilkan daftar
semua unit kerja kedalam
combo box unit
Dapat menampilkan semua
data pengajuan anggaran

Valid

Valid

Valid

Dapat menampilkan data
pengajuan anggaran yang
diajukan oleh unit terpilih
saja
Dapat menampilkan data
pengajuan anggaran yang
diajukan pada tanggal
transaski terpilih saja
Dapat menampilkan data
pengajuan anggaran yang
diajukan oleh unit terpilih
dan pada tanggal transaski
terpilih saja
Muncul pesan “Tidak ada
data untuk dicetak”

Valid

Muncul halaman print
priview dengan data sesuai
pada halaman rangkuman
Muncul halaman yang
menampilkan detail dari
transasksi terpilih
Transaksi terpilih akan
terhapus

Valid

Hasil yang diharapkan
Akan muncul halaman
tambah pengajuan
Muncul pesan peringatan
“Rekening belum diisi” dan
proses tambah pengajuan
gagal

Valid

Valid

Valid

Valid

Hasil
Uji
Valid
Valid

3

Testing fungsi simpan
tambah pengajuan

4

Testing fungsi simpan
tambah pengajuan

5

Mengisi kolom jumlah
pengajuan
Testing fungsi
GetSisaAnggaran()

6

7

8

Menekan tombol Reset
pada halaman tambah
pengajuan
Menekan tambal batal
pada halaman tambah
pengajuan

9

Menekan kolom ubah
pada transaksi
pengajuan anggaran

10

Menekan tombol
simpan dengan status
mengubah data

11

Menekan kolom hapus
pada transaksi
pengajuan anggaran
Testing total pengajuan

12

13

14

Tanpa
mengisikan
kolom Jumlah
pengajuan
Tanpa
mengisikan
kolom
keterangan
Isi dengan
huruf
setelah
memilih
rekening

Perubahan
data pada
rekening dan
atau jumlah
pengajuan dan
atau
keterangan

Muncul pesan peringatan
“Jumlah pengajuan belum
diisi” dan proses tambah
pengajuan gagal
Tambah pengajuan anggaran
berhasil dilakukan, data
disimpan kedalam datatable

Valid

Tidak akan terjadi perubahan
pada kolom jumlah pengajuan
Secara otomatis sisa anggaran
akan tampil pada kolom sisa
anggaran
Kolom rekening,sisa
anggaran, jumlah pengajuan
dan keterangan akan kosong
Akan kembali ke halaman
pengajuan tanpa
menambahkan/ merubah data
data
Menampilkan halaman
tambah pengajuan anggaran
dengan kelengkapan data
terpilih
Data akan disimpan ke dalam
data table, akan kembali ke
halaman pengajuan dengan
daftar data yang terbaru/
setelah perubahan dilakukan

Valid

Valid

Valid

Valid

Valid

Valid

Valid

Data pengajuan yang terpilih
Valid
akan dihapus dari datatable
dan daftar pengajuan
Setaip ada penambahan,
Valid
perubahan dan penghapusan
data, pada kolom total akan
secara terisi dari akumulasi
kolom jumlah pengajun.
Testing fungsi
Daftar pengajuan yang telah
Valid
SimpanDaftarPengajua
ditambahkan akan tersimpan
n AnggaranNonRutin()
ke dalam database, dan akan
dengan menekan
kembali pada halaman
tombol simpan
rangkuman
Menekan tombol batal
Akan kembali pada halaman
Valid
rangkuman tanpa melakukan
penambahan data apapun
Tabel 2. Tabel pengujian black box pada semua fungsi halaman Pengajuan.

16

5.

Simpulan

Berdasarkan penelitian yang telah dilakukan serta hasil pembahasan yang
dilakukan dengan judul Perancangan dan Implementai Aplikasi Desktop
Pengajuan Anggaran Sistem Informasi Keuangan dan Akuntansni Satya Wacana
(SIKASA) studi kasus: Universitas Kristen Satya Wacana Salatiga, dapat
disimpulkan sebagai berikut :
Aplikasi desktop pengajuan anggaran non-rutin SIKASA memudahkan
bagian Keuangan UKSW untuk mencatat pengajuan anggaran non-rutin ke dalam
sistem yang disimpan menggunakan database dan juga telah menggantikan cara
lama yaitu memasukan pengajuan anggaran melalui inject database secara
langsung. Dengan cara memasukan data pengajuan anggaran non-rutin melalui
sistem, maka kecil kemungkinan terjadi kesalahan input, karena sistem dilengkapi
dengan validasi dan bagian Keuangan hanya bisa mengelola pengajuan anggaran
pada periode buku yang sedang berlangsung dan periode buku yang akan datang
saja.
Setelah memasukan data pengajuan anggaran, bagian keuangan bisa dengan
mudah mencetak laporan pengajuan anggaran non-rutin untuk dimintakan tanda
tangan Bagian Keuangan, Pimpinan Unit Anggaran dan Unit Anggaran untuk
disimpan sebagai arsip anggaran non-rutin. Saat terjadi pembatalan pengajuan
anggaran oleh Pimpinan Universitas maupun Yayasan, bagian Keuangan bisa
melakukan pembatalan pada sistem pengajuan anggaran non-rutin dengan
menyertakan alasan dilakukan pembatalan.
Aplikasi SIKASA dapat dikembangkan lagi terutama pada bagian
pemanfaatan database yang perlu memanfaatkan stored procedure dan juga
trigger yang mampu memaksimalkan kecepatan dalam pengambilan data dan
eksekusi perintah sekaligus mampu dijalakan ke dalam banyak platform karena
SIKASA dirancang menggunakan platform yang berbeda-beda seperti PHP dan
.Net,
.

6.

Daftar Pustaka
[1] Setiawati, Wina, 2008, “Aplikasi Laporan Keuangan Berbasis Web
Untuk Kelurahan Dukuh”, Jurusan Teknologi Informasi Universitas
Guna Darma.
[2] Ella Helmi, Israel. 2012. “Rancang Bangun Sistem Informasi
Pengelolaan Keuangan Daerah (Studi Kasus pada SKPD dinas Energi
dan Sumber Daya Mineral Kabupaten Kepulauan Sangihe)”. Tesis.
Pascasarjana Universitas Diponegoro Semarang.
[3] Hidayat. A., Sugiarto. (2012). Penerapan system informasi akuntansi
berbasis
computer pada kopinspek PT. Sucofindo cabang medan.
Jurnal wira ekonomi mikroskil. Vol.2
[4] Santika Ilerning, 2016, Konsep
Dasar
Analisis
Sistem.
http://santika.ilearning.me/2-1-teori-umum/2-1-4-konsep-dasar-analisissistem/. diakses tanggal 20 oktober 2016.

17

[5] Kumpulan Artikel Serba Guna, 2013, Pengertian Implementasi Menurut
Para
Ahli.
http://el-kawaqi.blogspot.co.id/2012/12/pengertianimplementasi-menurut-para.html.diakses tanggal 3 November 2016.
[6] Adisaputro, Gunawan dan Yunita Anggraini. 2007. Anggaran Bisnis,
Cetakan Pertama, Yogyakarta: UPP STIM YKPN
[7] Klinik Akuntansi, 2016, Definisi Akuntansi Menurut Para Ahli.
http://www.kompasiana.com/klinikakuntansi/definisi-akuntansi-menurutpara-ahli_54f79be6a33311207e8b46fe. diakses tanggal 3 November
2016.
[8] Fina Pandu Winata Dunia Info, 2013, Pengertian Web Service.
http://saptafina13.blogspot.co.id/2013/04/pengertian-web-service.html.
diakses tanggal 8 November 2016.
[9] Rekayasa Perangkat Lunak, 2014, Prototyping Model. https://
julimkirom. wordpress.com/2014/02/20/3-prototyping-model/. diakses
tanggal 11 November 2016.
[10] Suryani, Erni. 2013. ”Aplikasi Pembelajaran Bahasa Korea Dasar
Berbasis Sistem Operasi Android”. Skripsi. Fakultas Teknik dan Ilmu
Komputer, Universitas Komputer Indonesia.

18

Dokumen yang terkait

ANALISIS KOMPARATIF PENDAPATAN DAN EFISIENSI ANTARA BERAS POLES MEDIUM DENGAN BERAS POLES SUPER DI UD. PUTRA TEMU REJEKI (Studi Kasus di Desa Belung Kecamatan Poncokusumo Kabupaten Malang)

23 307 16

FREKUENSI KEMUNCULAN TOKOH KARAKTER ANTAGONIS DAN PROTAGONIS PADA SINETRON (Analisis Isi Pada Sinetron Munajah Cinta di RCTI dan Sinetron Cinta Fitri di SCTV)

27 310 2

PENILAIAN MASYARAKAT TENTANG FILM LASKAR PELANGI Studi Pada Penonton Film Laskar Pelangi Di Studio 21 Malang Town Squere

17 165 2

Analisis Sistem Pengendalian Mutu dan Perencanaan Penugasan Audit pada Kantor Akuntan Publik. (Suatu Studi Kasus pada Kantor Akuntan Publik Jamaludin, Aria, Sukimto dan Rekan)

136 695 18

DOMESTIFIKASI PEREMPUAN DALAM IKLAN Studi Semiotika pada Iklan "Mama Suka", "Mama Lemon", dan "BuKrim"

133 700 21

PEMAKNAAN MAHASISWA TENTANG DAKWAH USTADZ FELIX SIAUW MELALUI TWITTER ( Studi Resepsi Pada Mahasiswa Jurusan Tarbiyah Universitas Muhammadiyah Malang Angkatan 2011)

59 326 21

KONSTRUKSI MEDIA TENTANG KETERLIBATAN POLITISI PARTAI DEMOKRAT ANAS URBANINGRUM PADA KASUS KORUPSI PROYEK PEMBANGUNAN KOMPLEK OLAHRAGA DI BUKIT HAMBALANG (Analisis Wacana Koran Harian Pagi Surya edisi 9-12, 16, 18 dan 23 Februari 2013 )

64 565 20

PENGARUH PENGGUNAAN BLACKBERRY MESSENGER TERHADAP PERUBAHAN PERILAKU MAHASISWA DALAM INTERAKSI SOSIAL (Studi Pada Mahasiswa Jurusan Ilmu Komunikasi Angkatan 2008 Universitas Muhammadiyah Malang)

127 505 26

PENERAPAN MEDIA LITERASI DI KALANGAN JURNALIS KAMPUS (Studi pada Jurnalis Unit Aktivitas Pers Kampus Mahasiswa (UKPM) Kavling 10, Koran Bestari, dan Unit Kegitan Pers Mahasiswa (UKPM) Civitas)

105 442 24

STRATEGI KOMUNIKASI POLITIK PARTAI POLITIK PADA PEMILIHAN KEPALA DAERAH TAHUN 2012 DI KOTA BATU (Studi Kasus Tim Pemenangan Pemilu Eddy Rumpoko-Punjul Santoso)

119 459 25