BAB III ANALISA PERANCANGAN SISTEM

BAB III ANALISA PERANCANGAN SISTEM

3.1

Sejarah Perusahaan LaSalle College merupakan salah satu perguruan tinggi desain internasional yang

berpusat di Kanada. LaSalle College memberikan perspektif yang holistik dalam pembelajaran kreatif, sebagai pengalaman belajar internasional, dengan hands-on praktis pendekatan, dengan kurikulum teoritis perspektif first-hand yang solid dari Kanada, mengembangkan keterampilan yang diperlukan untuk mahasiswa di setiap bidang masing-masing. Didirikan di Jakarta pada tahun 1997, LaSalle College Jakarta selalu menjaga standar kualitas dan terus memperluas di pasar Asia, terutama di Indonesia. Pada 2005 LaSalle College membuka sekolah lain di Surabaya-Indonesia. Sampai saat ini kedua sekolah difokuskan pada penyediaan pendidikan berkualitas top di bidang desain. LaSalle College memiliki program-program diploma tingkat lanjutan dan programprogram bersertifikat internasional. Program Diploma dapat diselesaikan dalam waktu 2 tahun untuk studi penuh atau 2 tahun untuk studi parttime. LaSalle College Jakarta memiliki beberapa program yang dapat dipilih mahasiswa baru sebelum mendaftar, yaitu : Digital Media Design (DMD), Fotografi, Interior Design, Artistic Make Up, Fashion Design, Fashion Business. LaSalle College Jakarta berkomitmen untuk tidak hanya memberi para lulusannya dengan ketrampilanketrampilan yang diperlukan tetapi juga menyiapkan dunia kerja bagi semua mahasiswa yang nantinya lulus dari kampus ini. Berbagai program dirancang untuk memberikan kesempatan bagi para mahasiswa untuk menjadi profesional setelah lulus. Sementara itu selama program studi, mahasiswa akan terkenal dengan industri melalui berbagai kegiatan yang menarik seperti kunjungan lapangan, magang, kuliah tamu, pertukaran mahasiswa dan mobilitas, proyek industri riil dilaksanakan sebagai bangku untuk mencapai studi mahasiswa.

27

http://digilib.mercubuana.ac.id/

28

3.2

Visi dan Misi Visi : Menjadi jaringan terkemuka di dunia lembaga pendidikan swasta terpilih, diakui

untuk itu inovasi, efisiensi dan hasil.

Misi : Menghubungkan orang-orang untuk memberikan peluang melalui pendidikan yang berkualitas.

3.3

Struktur Organisasi dan Tugasnya

Ketua Yayasan LaSalle Indonesia Kepala Sekolah / Head Principal Finance & Acc. Manager /Adm. Keuangan

Academic Manager/Adm. Akademik

Unit Pelaksana Teknis/IT Manager

Unit Penelitian dan Pengabdian Masyarakat

Perpustakaan Laboratorium

HRD Manager /Kepegawaian

Account Receivable Admin Finance

GA Supervisor GA Officer

General Affair Manager

Penelitian Pengabdian & Kerjasama

Account Payable

Marketing & Promotion Manager

Mahasiswa dan BEM

Gambar 3.1 Struktur Organisasi LaSalle College Jakarta


29

Dalam melakukan tugasnya LaSalle College Jakarta di kelola oleh bagian-bagianbagian yang terkait sebagai berikut :

1.

Ketua Yayasan a. Bersama-sama pengurus lain dan anggota menyusun rencana program kerja komite sekolah. b. Mengesahkan rencana program kerja komite sekolah. c. Melaksanakan keputusan hasil musyawarah yang ditetapkan oleh anggota melalui rapat-rapat. d. Mengundang rapat-rapat harian komite sekolah kepada kepala sekolah. e. Mengkomunikasikan hasil rapat komite sekolah kepada kepala sekolah. f.

Mengundang rapat pihak sekolah atas undangan kepala sekolah.

g. Menghadiri rapat dinas sekolah atas undangan kepala sekolah.

2.

Head Principal / Kepala Sekolah Kepala Sekolah bertugas sebagai : a. Mengorganisasikan semua kegiatan dan sumber daya yang ada di perusahaan. b. Menetapkan tujuan dan sasaran yang hendak di capai oleh perusahaan. c. Mengambil keputusan dan kebijakan yang berkaitan dengan kegiatan perusahaan.

3. Manager Manager bertugas sebagai : a. Mengontrol setiap hari kegiatan perusahaan yang dilakukan oleh staff-staff yang berkaitan. b. Menghadapi dan mendengarkan keluhan karyawan yang bermasalah. c. Memberi motivasi kepada staff-staff setiap hari. d. Mengevaluasi laporan selama satu bulan.

4. Staff Keuangan Staff keuangan bertugas sebagai : a. Mencatat setiap transaksi keuangan. b. Membuat laporan keuangan setiap bulannya c. Menerima pembayaran dari mahasiswa. d. Mengontrol pemasukan dan pengeluaran keuangan


30

5. Staff Akademik a. Mengatur pemrograman mata kuliah, pencetakkan absensi kuliah mahasiswa, pembagian KHS (Kartu Hasil Studi), dan pengecekkan nilai hasil ujian ketika ada komplain dari mahasiswa. b. Mengarsipkan semua dokumen yang berhubungan dengan akademik, seperti Buku Laporan Registrasi, Buku Laporan Wisuda, dan semua KHS dari berbagai Fakultas maupun Jurusan di tiap-tiap semester. c. Menerima, mendokumentasikan, dan mengarsipkan nilai mata kuliah dosen pengampu mata kuliah dari semua fakultas dan jurusan. d. Mengarsipkan dokumen-dokumen berupa fotocopy nilai (transkrip alumni beserta ijazahnya) serta memberikan ijazah dan transkrip asli kepada alumni yang bersangkutan. e. Melaksanakan tugas pengetikan surat-surat keterangan seperti keterangan masih studi, keterangan beasiswa, keterangan perpustakaan, keterangan lulus, keterangan cuti studi, keterangan mutasi studi, pemrosesan Kartu Tanda Mahasiswa (KTM). f.

Pengetikkan surat keputusan mengenai susunan kepanitiaan kegiatan yang berhubungan dengan bagian administrasi akademik.

6. Staff GA (General Affair) / Facilites a. Melakukan pengurusan seluruh perijinan yg dibutuhkan oleh perusahaan. b. Menjaga hubungan baik dengan lingkungan sekitar perusahaan c. Melakukan pencatatan dan pelaporan Asset Perusahaan, melakukan pemeliharaan dan perbaikan sarana kantor d. Memastikan ketersediaan kebutuhan kantor, serta pengamanan Fasilitas kantor dan asset perusahaan.


31

3.4

Analisa Sistem Berjalan Dalam pengelolaan sistem keuangan yang meliputi penerimaan dan pengeluaran

keuangan memerlukan proses yang harus dilalui. Berikut ini merupakan gambaran dari proses pengelolaan sistem keuangan pada LaSalle College Jakarta:

Gambar 3.2 Flowchart Sistem Berjalan Bagian Penerimaan Keuangan

Berdasarkan gambar diatas, dapat diuraikan proses penerimaan pembayaran kuliah adalah sebagai berikut : 1. Mahasiswa membayarkan uang sekolah kepada bagian penerimaan pembayaran berdasarkan invoice 2. Staff penerimaan pembayaran tersebut menerima dan menghitung uang yang di terima, 3. Staff penerimaan pembayaran membuat receipt form yang di tanda tangan dan di stempel sebagai tanda bukti pembayaran dan diberikan kepada mahasiswa untuk disimpan. 4. Staff penerimaan pembayaran mencatat semua pembayaran yang diterimanya dari mahasiswa. Semua perihal penerimaan keuangan di buatkan laporan setiap bulannya. Dan laporan tersebut dilaporkan kepada manager finance.


32

Gambar 3.3 Flowchart Sistem Berjalan Bagian Pengeluaran Keuangan

Berdasarkan gambar diatas, dapat diuraikan proses pengeluaran pembayaran kuliah adalah sebagai berikut : 1. Pegawai yang ingin melakukan permintaan pembayaran (budget request) pertama-tama harus melakukan pengisian form yaitu Budget Request Form. 2. Setelah diisi, form tersebut diserahkan kepada admin finance untuk diinput di excel. 3. Admin finance memberikan form tersebut kepada manager divisi untuk di approval. 4. Setelah bagian manager divisi sudah approval, form itu dikembalikan ke admin finance. 5. Admin finance meneruskan form tersebut ke manager finance untuk di approval. 6. Manager finance mengecek semua data dan mengapproval form tersebut.


33

7. Setelah manager finance selesai approval, form tersebut diteruskan ke bagian head principal. 8. Sebelum form tersebut di approval, bagian head principal juga mengecek kembali isi dari form yang diajukannya itu lalu baru bisa di approval. 9. Setelah semua approval sudah menyetujuinya, bagian purchasing membuatkan PO (Purchase Order) yang nantinya PO tersebut di teruskan ke bagian admin finance. 10. PO yang sudah di terima oleh bagian admin finance, lalu diberikan estimasi 1 minggu untuk divisi yang melakukan permintaan pembayaran untuk mengambil uangnya. 11. Setelah 1 minggu, divisi tersebut dapat mengambil uang di bagian pengeluaran pembayaran. 12. Pegawai mengisi form Cash Payment untuk mengambil uangnya. Semua pengeluaran atau transaksi dicatat dan dibuatkan laporan secara bulanan.

3.4.1

Identifikasi Masalah Berdasarkan prosedur sistem berjalan yang telah dibahas sebelumnya, maka

ditemukan beberapa permasalahan yaitu: 1. Proses permintaan budget yang kurang efektif dan efisien, jika ada pegawai yang

ingin

mengajukan

permintaan

budget,

admin

finance

harus

menyerahkan form budget request secara berkala kepada bagian-bagiannya. 2. Form budget request yang di kembalikan kepada admin finance tidak termonitor dan terkontrol. 3. Dokumen mudah hilang karena belum ter-record dan tersimpan dalam satu penyimpanan. 4. Lamanya waktu pengembalian dokumen kepada admin finance. 5. Proses persetujuan permintaan budget terkadang terhambat, dikarenakan lamanya pengembalian dokumen kepada admin finance.

Penyebab dari masalah yang timbul dalam proses pemasukan dan pengeluaran yang saat ini sedang berjalan yaitu: 1. Proses permintaan budget yang kurang efektif dan efisien. Penyebab : Admin finance harus mencari dan membuka satu per satu folder. 2. Form budget request yang di kembalikan kepada admin finance tidak termonitor dan terkontrol.


34

Penyebab : Manager yang mengembalikan form BR, tidak membuat data form BR yang sudah dikembalikan. 3. Dokumen mudah hilang karena belum ter-record dan tersimpan dalam satu penyimpanan. Penyebab : Belum terintegrasinya proses pengarsipan, dan pengembalian sehingga penyimpanan data belum terpusat dan belum memiliki back up data. 4. Lamanya waktu pengembalian dokumen kepada admin finance. Penyebab : Pada form BR tidak tercantum tanggal pengembalian dan admin finance tidak memberikan batas waktu form BR. 5. Proses persetujuan permintaan budget terkadang terhambat, dikarenakan lamanya pengembalian dokumen kepada admin finance. Penyebab : Admin finance tidak mengecek kembali form BR yang dikembalikan apakah ada catatan atau tidak.

3.5

Analisa PIECES Informasi sistem berjalan yang telah dijabarkan sebelumnya akan dianalisa

melalui metode analysis PIECES yang terdiri dari 6 variabel yaitu, performance, information, economics, control, efficiency dan services. Berikut merupakan hasil analysis berdasarkan masing-masing variabel:

Tabel 3.1 Analisa PIECES No 1.

Aspek Performance

Kendala

Solusi

Belum terintegrasinya proses Dibuatkan

data

yang

sistem

agar

lebih

pemasukan

pengeluaran

dan terintegrasi

keuangan.

informatif

dalam

penyajian

Respon time yang dibutuhkan mengenai data keuangan dan untuk menulis dan memproses memiliki back up data. data

lebih

daripada

lama

menulis

menggunakan

sistem. 2.

Information

Pencatatan pemasukan dan Dibuatkan penginputan secara pengeluaran uang yang ditulis otomatis

dan

ke dalam buku kurang akurat,

sehingga

karena

terkadang

terupdate

data

akan laporan

datanya yang dihasilkan lebih akurat.

tidak update.


35

3.

Economic

Biaya

operasional

pencetakan seperti

terkait Dibuatkan

semua

:

Budget

form

secara

form otomatis yang tersimpan ke Request dalam

database.

Sehingga

Form, Cash Payment Form, biaya operasional lebih hemat Receipt Form, Invoice Form,

dan dapat menghindari kertas

dan Purchase order form,

yang sia-sia tidak terpakai.

membuktikan

bahwa

penggunaan kertas membuat pengeluaran

biaya

pada

LaSalle College lebih besar. 4.

Control

Kontrol

hak

akses

dalam

Dibuatkan pengontrolan pada

pemasukkan dan pengeluaran setiap data

masih

tidak

form

yang

terdapat

efektif, approval dari beberapa user,

karena form yang diajukan dan juga dibuatkan batasan dapat dipalsukan atau hilang. Sering

terjadi menghindari kehilangan atau

tidak

pengontrolan

terhadap kode hak akses untuk

pada

data pemalsuan data.

keuangan, 5.

Efficiency

Proses

pencarian

penemuan

arsip

dan Pencarian data otomatis dapat kembali ditemukan dari database, dan

kurang efektif dan efisien.

tidak perlu mengecek langsung pada satu per satu folder yang terdapat pada rak arsip.

6.

Services

3.6

-

-

Analisa Kebutuhan Sistem yang Diusulkan Analisa kebutuhan sistem berfungsi untuk menggambarkan fungsi dan kinerja

sistem berbasis komputer yang akan dikembangkan. Dalam analisa kebutuhan sistem yang akan diusulkan ini akan dijelaskan mengenai data masukan yang akan diproses oleh sistem sehingga akan menghasilkan dokumen keluaran. Berikut adalah kebutuhan sistem yang diusulkan :

1.

Bentuk Data Masukkan

a.

Nama Data

: Data Mahasiswa

Fungsi

: Untuk menyimpan data mahasiswa

Sumber

: Admin Finance

Tujuan

: Manajemen


36

Media

: Website

Frekuensi

: Setiap ada data mahasiswa baru

b. Nama Data

c.

Fungsi

: Untuk menyimpan data user aplikasi

Sumber

: Admin Finance

Tujuan

: Manajemen

Media

: Website

Frekuensi

: Setiap ada pengguna baru yang menggunakan aplikasi.

Nama Data

: Data Purchase Order

Fungsi

: Untuk menyimpan transaksi purchase order

Sumber

: Purchasing

Tujuan

: Manager Finance

Frekuensi

: Setiap ada transaksi purchase order

d. Nama Data

g.

2.

: Data transaksi Cash Payment Form

Fungsi

: Menyimpan transaksi pembayaran Cash Payment

Sumber

: Account Payable Staff

Tujuan

: Manager Finance

Frekuensi

: Setiap adanya transaksi cash payment

e. Nama Data

f.

: Data User

: Data Receipt

Fungsi

: Menyimpan transaksi pemasukkan / receipt

Sumber

: Account Receivable Staff

Tujuan

: Manager Finance

Frekuensi

: Setiap adanya penerimaan / receipt

Nama Data

: Data Invoice

Fungsi

: Menyimpan transaksi invoice

Sumber

: Account Receivable Staff

Tujuan

: Manager Finance

Frekuensi

: Setiap adanya invoice yang dikeluarkan.

Nama Data

: Data Budget Request

Fungsi

: Menyimpan transaksi budget request

Sumber

: Admin Finance

Tujuan

: Manager Finance

Frekuensi

: Setiap adanya budget request yang dibuat.

Proses Data yang telah diinput diproses secara terstruktur oleh sistem dengan media

database dan algoritma program yang disusun pada sistem.


37

3.

3.7

Spesifikasi Bentuk Data Keluaran a.

Laporan Bulanan Pengeluaran dan Penerimaan Keuangan

b.

Approval Form

Rancangan Sistem Usulan Perancangan sistem perangkat lunak dideskripsikan dengan model analisis

menggunakan diagram use case, diagram activity, diagram sequence, dan class diagram, serta dilanjutkan dengan model desain. Analisis yang digunakan untuk pemetaan awal mengenai perilaku yang diisyaratkan sistem

aplikasi kedalam elemen-elemen

permodelan. Untuk membantu perancangan dan melengkapi dokumentasi perancangan, digunakan star UML yang mendukung perancangan dengan basis UML.


38

3.7.1

Use Case Diagram Sistem Usulan

Gambar 3.4 Use Case Diagram Sistem Usulan

Diagram use case pada sistem pemasukan dan pengeluaran Lasalle College yaitu terdapat 12 use case dan 6 aktor. Aktor admin finance mempunyai 2 use case yaitu mengelola data master dan membuat form budget request. Aktor Account Receivable Staff mempunyai 3 use case yaitu membuat receipt form, membuat invoice dan membuat laporan bulanan penerimaan keuangan. Manager Finance mempunyai 2 use case yaitu Approval Budget request form, Cash payment form, dan purchase order form. Account Payable staff Memiliki 3 use case yaitu Membuat cash payment form, Laporan bulanan


39

pengeluaran keuangan dan membuat PO form. Sedangkan aktor manager divisi dan head principle mempunyai 1 use case yaitu approval Budget request form.

Tabel 3.2 Skenario Use Case Login Nama Use Case

Use Case Login Admin Finance, Account Receivable Staff, Account Payable Staff,

Actor

Purchasing, Head Principal, Manager Finance, Manager Divisi.

Deskripsi

Login ke dalam aplikasi

Pra Kondisi

Admin Finance, Account Receivable Staff, Account Payable Staff, Purchasing, Head Principal, Manager Finance, Manager Divisi

Skenario

memasukkan username dan passworrd kemudian pilh login. Admin Finance, Account Receivable Staff, Account Payable Staff, Purchasing, Head Principal, Manager Finance, Manager Divisi

Post Kondisi

masuk ke menu utama.

Login adalah salah satu cara untuk mengamankan data dari user yang tidak mempunyai wewenang untuk mengolah data dalam sistem. Caranya dengan memasukkan username dan passwod sesuai user.

Tabel 3.3 Skenario Use Case mengelola data master Nama Use Case

Use Case mengelola data master

Actor

Admin Finance Data Master adalah data utama sebagai dasar dari semua transaksi

Deskripsi

seperti data user dan data mahasiswa.

Pra Kondisi

Login Admin memilih data master pada menu utama, kemudian pilih salah satu sub menu data master untuk mengelolanya. Misal data user atau

Skenario

data mahasiswa.pilih add, save delete dan edit untuk mengelolanya

Post Kondisi

Jika benar Data master tersimpan, jika salah terdapat pesan error.

Data Master adalah data utama atau data dasar yang digunakan untuk mengelola data transaksi contoh, data mahasiswa, dibutuhkan untuk transaksi pembayaran mahasiswa.


40

Tabel 3.4 Skenario Use Case Membuat Budget Request Form Nama Use Case

Use Case membuat budget request form

Actor

Admin Finance

Deskripsi

Admin Finance membat Budget Request Form

Pra Kondisi

Login Admin finance yang membuat menu form kemudian pilih budget request form, pada saat ada pegawai yang ingin mengajukan permintaan budget. pilih add, save delete dan edit untuk

Skenario

mengelolanya Budget Request Form tersimpan dan ada pesan error jika tidak

Post Kondisi

lengkap

Budget Form Request dapat diakses oleh admin finance ketika pegawai ada yang melakukan permintaan budget dan admin finance mengisi di form budget request

Tabel 3.5 Skenario Use Case Membuat Receipt Form Nama Use Case

Use Case membuat receipt form

Actor

Account Receivable Staff Account Receivable Staff membuat receipt form sebagai bukti

Deskripsi

penerimaan keuangan

Pra Kondisi

Login Pilih menu form kemudian pilih menu Receipt Form. pilih add, save

Skenario

delete dan edit untuk mengelolanya

Post Kondisi

Receipt form tersimpan dan ada pesan error jika tidak lengkap

Receipt Form dapat diakses oleh account receivable staff ketika ada mahasiswa yang membayarkan uang kuliah dan staff mengisi form receipt untuk diberikan kepada mahasiswa sebagai tanda bukti pembayaran


41

Tabel 3.6 Skenario Use Case Membuat Invoice Mahasiswa Nama Use Case

Use Case membuat Invoice Mahasiswa

Actor

Account Receivable Staff Account Receivable Staff

Membuat Invoice Mahasiswa untuk

Deskripsi

melihat tagihan kuliah setiap semesternya.

Pra Kondisi

Login Pilih menu Form kemudian pilih sub menu Invoice. pilih add, save

Skenario

delete dan edit untuk mengelolanya

Post Kondisi

Invoice tersimpan dan error jika data tidak lengkap

Invoice dapat diakses oleh account receivable staff ketika ada mahasiswa yang meminta tagihan semesternya kepada staff account receivable.

Tabel 3.7 Skenario Use Case Membuat Laporan Bulanan Penerimaan Keuangan Nama Use Case

Use Case Membuat Laporan Bulanan Penerimaan Keuangan

Actor

Account Receivable Staff

Deskripsi

Membuat Laporan Bulanan Penerimaan Keuangan setiap bulan

Pra Kondisi

Login

Skenario

Pilih Menu Laporan, Pilih print

Post Kondisi

Laporan bulanan penerimaan keuangan tercetak

Laporan penerimaan keuangan adalah keseluruhan data transaksi penerimaan keuangan selama satu bulan.

Tabel 3.8 Skenario Use Case Membuat Cash Payment Form Nama Use Case

Use Case Membuat Cash Payment Form

Actor

Account Payable Staff

Deskripsi

Membuat Cash Payment Form untuk mengajukan pembayaran

Pra Kondisi

Login Pilih Menu Form kemudian pilih sub menu cash payment form. pilih

Skenario

add, save delete dan edit untuk mengelolanya Cash Payment Form tersimpan dan ada pesan error jika tidak

Post Kondisi

lengkap


42

Cash Payment Form dapat diakses oleh account payable staff ketika seorang pegawai yang ingin mengambil uang budget dan purchase order sudah selesai di approval.

Tabel 3.9 Skenario Use Case Membuat Laporan Bulanan Pengeluaran Keuangan Nama Use Case

Use Case Membuat Laporan Bulanan Pengeluaran Keuangan

Actor

Account Payable Staff

Deskripsi

Membuat Laporan Bulanan Pengeluaran Keuangan setiap bulan

Pra Kondisi

Login

Skenario

Pilih Menu Laporan, Pilih print

Post Kondisi

Laporan bulanan pengeluaran keuangan tercetak

Laporan pengeluaran keuangan adalah keseluruhan data transaksi pengeluaran keuangan selama satu bulan.

Tabel 3.10 Skenario Use Case Membuat Purchase Order Form Nama Use Case

Use Case Membuat Purchase Order Form

Actor

Purchasing

Deskripsi

Membuat Purchase Order Form

Pra Kondisi

Login Pilih menu form, kemudian pilih sub menu purchase order form.

Skenario

Pilih add, save delete dan edit untuk mengelolanya Purchase Order Form tersimpan dan pesan error jika data tidak

Post Kondisi

lengkap

Purchasing bertugas untuk membuat purchase order form ketika budget request form sudah di approval oleh head principal dan manager.


43

Tabel 3.11 Skenario Use Case Approval Budget Request Form, Cash Payment Form dan Purchase Order Form Use Case Approval Budget Request Form, Cash Payment Form dan Nama Use Case

Purchase Order Form

Actor

Manager Finance Approval Budget Request Form, Cash Payment Form dan Purchase

Deskripsi

Order Form

Pra Kondisi

Login Pilih Approval Budget Request Form, Cash Payment Form dan

Skenario

Purchase Order Form kemudian pilih approval. Approval Budget Request Form, Cash Payment Form dan Purchase

Post Kondisi

Order Form sudah di approval dan mengirim notifikasi.

Approval Budget Request Form, Cash Payment Form dan Purchase Order Form dilakukan agar dapat segera memproses langkah selanjutnya yang artinya data tersebut telash disetujui oleh yang berwenang.

Tabel 3.12 Skenario Use Case Mengecek Laporan Bulanan Penerimaan dan Pengeluaran Keuangan Use Case Mengecek Laporan Bulanan Penerimaan dan Pengeluaran Nama Use Case

Keuangan

Actor

Manager Finance Mengecek

Deskripsi

Keuangan

Pra Kondisi

Login

Laporan

Bulanan

Penerimaan

dan

Pengeluaran

Manager Finance Pilih laporan penerimaan dan pengeluaran Skenario

keuangan kemudian mengeceknya satu per satu. Laporan bulanan penerimaan dan pengeluaran keuangan sudah di

Post Kondisi

cek.

Mengecek Laporan Bulanan Penerimaan dan Pengeluaran Keuangan dilakukan agar laporan bulanan benar-benar memiliki data yang akurat setelah dilakukan pengecekan oleh pihak yang berwenang.


44

Tabel 3.13 Skenario Use Case Approval Budget Request Form Nama Use Case

Use Case Approval Budget Request Form

Actor

Head Principal dan Manager Divisi Head Principal dan Manager Divisi mengapproval Budget Request

Deskripsi

Form

Pra Kondisi

Login Head Principal dan Manager Divisi memilih menu approval, kemudian pilih form Budget Request Form setelah itu pilih

Skenario

approval.

Post Kondisi

Budget Request Form sudah di approval.

Approval Budget Request Form,dilakukan oleh Head Principal dan Manager Divisi agar dapat segera memproses langkah selanjutnya yang artinya data tersebut telash disetujui oleh yang berwenang.


45

3.7.2

Activity Diagram

A. Activity Diagram Login

Gambar 3.5 Activity Diagram Login Aplikasi

Login dimulai dari memasukkan username dan password. Jika username dan password benar maka sistem akan menampilkan menu utama. Jika tidak maka akan menampilkan pesan error. Login dilakukan oleh Staff Keuangan, Head Principal, Manager Divisi, dan Purchasing yang akan menggunakan aplikasi. Apabila data yang dimasukkan valid maka masuk ke menu utama. Menu utama untuk masing-masing actor berbeda. Dimana Admin Finance dapat mengakses data master sedangkan aktor yang lain tidak dapat mengakses data master tersebut.


46

B. Activity Diagram Data Master

Gambar 3.6 Activity Diagram Data Master

Admin Finance memilih sub master data. Ada 2 master data yaitu data mahasiswa, dan data user. Admin Finance dapat menambah, mengsubmit menghapus,


47

mengedit data yang ada pada data mahasiswa, dan data user. Jika yes maka data tersimpan, dan jika false maka kembali ke tampilan menu data master yang sedang aktif.

C. Activity Diagram Budget Request Form

Gambar 3.7 Activity Diagram Budget Request Form

Budget Form Request dapat diakses oleh admin finance ketika pegawai ada yang melakukan permintaan budget dan admin finance mengisi di form budget request. Pada form ini pilih tombol add maka akan tampil form BR, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


48

D. Activity Diagram Receipt Form

Gambar 3.8 Activity Diagram Receipt Form

Receipt Form dapat diakses oleh account receivable staff ketika ada mahasiswa yang membayarkan uang kuliah dan staff mengisi form receipt untuk diberikan kepada mahasiswa sebagai tanda bukti pembayaran. Pada form ini pilih tombol add maka akan tampil form Receipt, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


49

E. Activity Diagram Invoice Mahasiswa

Gambar 3.9 Activity Diagram Invoice Mahasiswa

Invoice dapat diakses oleh account receivable staff ketika ada mahasiswa yang meminta tagihan semesternya kepada staff account receivable. Pada form ini pilih tombol add maka akan tampil form Invoice, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


50

F. Activity Diagram Cash Payment

Gambar 3.10 Activity Diagram Cash Payment

Cash Payment Form dapat diakses oleh account payable staff ketika seorang pegawai yang ingin mengambil uang budget dan purchase order sudah selesai di approval . Pada form ini pilih tombol add maka akan tampil form Cash Payment, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


51

G. Activity Diagram Laporan Penerimaan dan Pengeluaran Keuangan

Gambar 3.11 Activity Diagram Laporan Penerimaan dan Pengeluaran Keuangan

Laporan diakses oleh staff penerimaan dan pengeluaran keuangan memilih menu laporan kemudian pilih menu laporan yang akan dicetak. Setelah itu masukkan tanggal awal dan tanggal akhir laporan yang akan dicetak. Ketika pilih tombol print maka laporan akan tercetak.


52

H. Activity Diagram Purchase Order Form

Gambar 3.12 Activity Diagram Purchase Order Form

Purchase Order Form dapat diakses oleh purchasing ketika budget request form sudah selesai di approval oleh semua manager dan head principal , kemudian bagian purchasing membuat purchase order. Pada form ini pilih tombol add maka akan tampil form Purchase Order, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


53

I.

Activity Diagram Approval Budget Request Form, Cash Payment Form, dan Purchasing Order Form (Manager Finance)

Gambar 3.13 Activity Diagram Approval Form (Manager Finance)

Pada saat manager finance ingin mengapproval form seperti : Budget Request Form, Cash Payment Form dan Receipt Form, manager finance memilih dahulu form mana yang ingin di approval. Ketika dipilih simpan maka data akan tersimpan.


54

J. Activity Diagram Mengecek Laporan Bulanan Penerimaan dan Pengeluaran Keuangan

Gambar 3.14 Activity Diagram Mengecek Laporan Bulanan

Manager Finance mengecek laporan dengan cara mengakses menu laporan untuk menampilkan laporan penerimaan dan pengeluaran keuangan. Setelah itu masukkan tanggal awal dan tanggal akhir laporan yang akan dicetak. Ketika pilih tombol print maka laporan akan tercetak.


55

K. Activity Diagram Approval Budget Request (Head Principal dan Manager Divisi)

Gambar 3.15 Activity Diagram Approval BR Form (Head Principal & Manager Divisi)

Pada saat head principal ingin mengapproval form Budget Request Form, head principal memilih dahulu form tersebut untuk di approval. Ketika dipilih simpan maka data akan tersimpan. Pada saat manager divisi ingin mengapproval form Budget Request Form, manager divisi memilih dahulu form tersebut untuk di approval. Ketika dipilih simpan maka data akan tersimpan.


56

3.7.3

Sequence Diagram

A. Sequence Diagram Login

Gambar 3.16 Sequence Diagram Login

Gambar diatas merupakan gambar sequence diagram login aplikasi dimana semua aktor memasukkan username dan password jika sukses maka masuk ke Home.


57

B. Sequence Diagram Data Master

Gambar 3.17 Sequence Diagram Data Master Admin Finance memilih sub master data. Ada 2 master data yaitu data mahasiswa, dan data user. Admin Finance dapat menambah, mengsubmit menghapus, mengedit data yang ada pada data mahasiswa, dan data user. Jika yes maka data tersimpan, dan jika false maka kembali ke tampilan menu data master yang sedang aktif.


58

C. Sequence Diagram Budget Request Form

Gambar 3.18 Sequence Diagram Budget Request Form Budget Form Request dapat diakses oleh admin finance ketika pegawai ada yang melakukan permintaan budget dan admin finance mengisi di form budget request. Pada form ini pilih tombol add maka akan tampil form BR, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


59

D. Sequence Diagram Receipt Form

Gambar 3.19 Sequence Diagram Receipt Form

Receipt Form dapat diakses oleh account receivable staff ketika ada mahasiswa yang membayarkan uang kuliah dan staff mengisi form receipt untuk diberikan kepada mahasiswa sebagai tanda bukti pembayaran. Pada form ini pilih tombol add maka akan tampil form Receipt, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


60

E. Sequence Diagram Invoice Mahasiswa

Gambar 3.20 Sequence Diagram Invoice Mahasiswa

Invoice dapat diakses oleh account receivable staff ketika ada mahasiswa yang meminta tagihan semesternya kepada staff account receivable. Pada form ini pilih tombol add maka akan tampil form Invoice, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


61

F. Sequence Diagram Cash Payment

Gambar 3.21 Sequence Diagram Cash Payment

Cash Payment Form dapat diakses oleh account payable staff ketika seorang pegawai yang ingin mengambil uang budget dan purchase order sudah selesai di approval . Pada form ini pilih tombol add maka akan tampil form Cash Payment, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


62

G. Sequence Diagram Laporan Penerimaan dan Pengeluaran Keuangan

Gambar 3.22 Sequence Diagram Laporan Bulanan

Laporan diakses oleh staff penerimaan dan pengeluaran keuangan memilih menu laporan kemudian pilih menu laporan yang akan dicetak. Setelah itu masukkan tanggal awal dan tanggal akhir laporan yang akan dicetak. Ketika pilih tombol print maka laporan akan tercetak


63

H. Sequence Diagram Purchase Order

Gambar 3.23 Sequence Diagram Purchase Order.

Purchase Order Form dapat diakses oleh purchasing ketika budget request form sudah selesai di approval oleh semua manager dan head principal , kemudian bagian purchasing membuat purchase order. Pada form ini pilih tombol add maka akan tampil form Purchase Order, kemudian masukkan semua data yang dibutuhkan dan pilih simpan. Ketika dipilih simpan maka data akan tersimpan.


64

I.

Sequence Diagram Approval Budget Request Form, Cash Payment Form, dan Purchasing Order Form (Manager Finance)

Gambar 3.24 Sequence Diagram Approval Form (Manager Finance)

Pada saat manager finance ingin mengapproval form seperti : Budget Request Form, Cash Payment Form dan Receipt Form, manager finance memilih dahulu form mana yang ingin di approval. Ketika dipilih simpan maka data akan tersimpan.


65

J.

Sequence Diagram Mengecek Laporan Bulanan Penerimaan dan Pengeluaran

Keuangan

Gambar 3.25 Sequence Diagram Mengecek Laporan Bulanan

Manager Finance mengecek laporan dengan cara mengakses menu laporan untuk menampilkan laporan penerimaan dan pengeluaran keuangan. Setelah itu masukkan tanggal awal dan tanggal akhir laporan yang akan dicetak. Ketika pilih tombol print maka laporan akan tercetak.


66

L. Sequence Diagram Approval Budget Request (Head Principal dan Manager Divisi)

Gambar 3.26 Sequence Diagram Approval Budget Request Form (Head Principal dan Manager Divisi)

Pada saat head principal ingin mengapproval form Budget Request Form, head principal memilih dahulu form tersebut untuk di approval. Ketika dipilih simpan maka data akan tersimpan. Pada saat manager divisi ingin mengapproval form Budget Request Form, manager divisi memilih dahulu form tersebut untuk di approval. Ketika dipilih simpan maka data akan tersimpan.


67

3.7.4

Class Diagram Perancangan class diagram menggambarkan kelas-kelas pada sistem serta

hubungan antara satu kelas dengan kelas lainnya, berikut adalah penggambaran class diagram.

Gambar 3.27 Class Diagram

Gambar diatas adalah gambar class diagram sistem pengelolaan keuangan dimana ada 7 kelas yaitu kelas mahasiswa, user, cash payment, purchase_order, invoice, budget request form, receipt form. Asosiasi yang terjadi adalah one to one dimana setiap transaksi harus ada satu user, satu bayar dan satu siswa dalam satu transaksi.


BAB III ANALISA PERANCANGAN SISTEM

Recommend Documents