BAB III ANALISA DAN PERANCANGAN APLIKASI
3.1. Tinjauan Organisasi Berdasarkan Peraturan Menteri Pendidikan dan Kebudayaan Republik Indonesia Nomor 1 Tahun 2012 Tentang Organisasi dan Tata Kerja Kementerian Pendidikan dan Kebudayaan pasal 240: “Direktorat Pembinaan Sekolah Dasar mempunyai tugas melaksanakan perumusan dan koordinasi pelaksanaan kebijakan serta fasilitasi penerapan standar teknis di bidang Sekolah Dasar dan kesetaraan Sekolah Dasar”. 3.1.1. Tugas Pokok dan Fungsi Direktorat Pembinaan Sekolah Dasar Dalam melaksanakan tugas sebagaimana dimaksud dalam Pasal 240, Direktorat Pembinaan Sekolah Dasar menyelenggarakan fungsi: 1. perumusan kebijakan di bidang pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar; 2. koordinasi pelaksanaan kebijakan di bidang pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar; 3. fasilitasi dan pemberian bimbingan teknis penerapan norma, standar, prosedur, dan kriteria pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar; 4. pelaksanaan kerja sama dan pemberdayaan peran serta masyarakat di bidang pembinaan Sekolah Dasar dan kesetaraan Sekolah Dasar; 5. evaluasi penerapan norma, standar, prosedur, dan kriteria pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar; dan 6. pelaksanaan administrasi Direktorat Pembinaan Sekolah Dasar. Direktorat Pembinaan Sekolah Dasar dalam melaksanakan tugas dibagi menjadi : 1. Subdirektorat Program dan Evaluasi; 2. Subdirektorat Pembelajaran; 3. Subdirektorat Sarana dan Prasarana; 47
48 4. Subdirektorat Kelembagaan dan Peserta Didik; 5. Subbagian Tata Usaha; dan 6. Kelompok Jabatan Fungsional.
Direktorat Pembinaan SD
Subbag Tata Usaha
Subdit Program dan Evaluasi
Seksi Perencanaan
Subdit Pembelajaran
Subdit KPD
Subdit Sarpras
Seksi Evaluasi
Pokja Perencanaan dan Rehabilitasi
Pokja DAK dan BOS
Gambar 3. 1 Struktur Organisasi Direktorat Pembinaan Sekolah Dasar
3.1.2. Tugas Pokok Subdit Program dan Evaluasi Subdit
Program
dan
Evaluasi
dalam
melaksanakan
tugasnya
menyelenggarakan fungsi sebagai berikut : 1.
penyusunan bahan perumusan kebijakan di bidang pembinaan Sekolah Dasar dan kesetaraan Sekolah Dasar;
2.
pengumpulan, pengolahan, dan penyajian data dan informasi pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar;
3.
penyusunan program, kegiatan, dan anggaran Direktorat;
4.
koordinasi pelaksanaan kerja sama dan pemberdayaan peran serta masyarakat di bidang pembelajaran, sarana dan prasarana, kelembagaan, dan peserta didik Sekolah Dasar dan kesetaraan Sekolah Dasar;
49 5.
pemantauan dan evaluasi pelaksanaan program, kegiatan, dan anggaran Direktorat; dan
6.
penyusunan laporan Direktorat.
3.1.3. Struktur Kegiatan Rehabilitasi Ruang Kelas Sekolah Dasar Output kegiatan rehabilitasi ruang kelas sekolah dasar merupakan bagian dari Kegiatan Penjaminan Kepastian Layanan Pendidikan yang terdapat dalam DIPA Direktorat Pembinaan Sekolah Dasar. Semenjak tahun 2005 sampai dengan 2013 menjadi tanggung jawab Subdirektorat Program dan Evaluasi. Struktur kelompok kerja (Pokja) Rehabilitasi Ruang Kelas dapat digambarkan sebagai berikut: PPK
BPP
PO Rehabilitasi
Pokja Keuangan
Pokja Pendataan, Pemberkasan
Pokja Kesekretariatan, Pengarsipan,
Pokja Laporan
Gambar 3. 2 Struktur Kelompok Kerja Rehabilitasi
3.1.3.1. Tugas PPK Pejabat Pembuat Komitmen (PPK) Rehabilitasi bertanggung jawab sepenuhnya atas terselenggaranya rehabilitasi ruang kelas sekolah dasar dari mulai proses rekapitulasi usulan, perancangan penetapan quota, penetapan sk, retur, pelaksanaan penyaluran hingga pada tahap pelaporan baik laporan pertanggungjawaban keuangan kegiatan dan penyajian data laporan akhir pelaksanaan oleh sekolah. 3.1.3.2. Bendahara Pengeluaran Pembatan (BPP) BPP bertanggungjawab terhadap pendanaan pelaksanaan kegiatan rehabilitasi sesuai dengan anggaran yang tertuang dalam Rencana Kerja Anggaran dan Lembaga (RKAKL Direktorat Pembinaan Sekolah Dasar).
50 3.1.3.3. Tugas Pokja Rehabilitasi Rincian tugas kelompok kerja rehabilitasi adalah sebagai berikut: 7.
mengkoordinasikan
kegiatan
rehabilitasi
SD
(penyusunan
petunjuk
pelaksanaan rehabilitasi, penyusunan instrumen verifikasi dan validasi, pemberkasan, pencairan, penyaluran dana, workshop/sosialisasi, monitoring dan evaluasi); 8.
mengkoordinasikan penyusunan jadwal/rencana kegiatan rehabilitasi SD;
9.
mengkoordinasikan penyusunan laporan kegiatan rehabilitasi SD.
3.1.3.4. Tugas Pokja Keuangan Rincian tugas kelompok kerja keuangan adalah sebagai berikut: 1.
menyusun jadwal/rencana penyerapan dana
2.
mengajukan TUP/LS kegiatan
3.
melakukan GU Nihil (pertanggungjawaban)
4.
menyusun laporan bulanan, triwulanan, tahunan (daya serap)
5.
pencatatan keuangan dalam BKU, pencatatan persediaan, menyusun rencana kas, menyusun POK
6.
memungut, menyetorkan dan mencatat/pembukuan pajak-pajak
7.
membuat rekap pengajuan LS rehabilitasi
8.
menyelesaikan retur-retur pelaksanaan rehabilitasi
9.
menghimpun laporan sekolah penerima Bansos rehab
3.1.3.5. Tugas Pokja Pendataan dan Pemberkasan Rincian tugas kelompok kerja pendataan dan pemberkasan adalah sebagai berikut: 1.
input kelengkapan dokumen (merekap data SD, proposal, MoU, SK, SPTJM, PU)
2.
proses
pencairan
Satker/SPM/SP2D)
dan
penyaluran
dana
(mengajukan
SPP-LS
ke
51 3.
menyampaikan laporan perkembangan rehab ke lintas sektoral.
3.1.3.6. Pokja Kesekretariatan dan Pengarsipan Rincian tugas kelompok kerja kesekretariatan dan pengarsipan adalah sebagai berikut: 4.
menghimpun, menatausahakan/mendokumentasikan; data rehab, data SD dan dokumen perencanaan
5.
mengarsipkan dan menatausahakan data SD, dokumen rehab dan dokumen perencanaan (RAB, kontrak, RKAKL, TOR, dll.)
6.
mengarsipkan dan menatausahakan, dokumen (SK-SK, dan
surat
masuk/keluar) 7.
menghimpun dan mendokumenkan laporan akhir/pertanggungjawaban
3.1.3.7. Pokja Laporan Rincian tugas kelompok kerja laporan adalah sebagai berikut: 1.
menghimpun data, dokumen rehabilitasi, dan dokumen perencanaan
2.
menyampaikan laporan perkembangan (mingguan, bulanan) kepada: Mendikbud, Wamendik, Dirjen Dikdas, Direktur PSD, Kasubdit, UKMP3 dan instansi lain yang relevan.
3.
koordinasi dengan penanggungjawab rehabilitasi di provinsi dan kab./kota
4.
menyusun laporan perkembangan rehabilitasi
3.2. Analisa Prosedur Bantuan Rehabilitasi Ruang Kelas Analisis prosedur bantuan rehabilitasi ruang kelas menguraikan prosedur bantuan rehabilitasi dengan tujuan untuk mendefinisikan dan mengevaluasi permasalahan-permasalahan untuk mendapatkan informasi kebutuhan dalam perancangan aplikasi. Tahapan ini penting dalam pengembangan sistem karena apabila terjadi kesalahan maka akan menyebabkan kesalahan pada tahap selanjutnya. Mekanisme pelaksanaan kegiatan rehabilitasi ruang kelas dapat sebagai berikut:
52 1.
pengajuan usulan oleh Dinas Pendidikan Kabupaten/Kota, Dinas Pendidikan Provinsi atau unsur masyarakat ke Direktorat Pembinaan Sekolah Dasar;
2.
Pokja Pendataan dan Pemberkasan melakukan rekapitulasi usulan dan melakukan proses validasi secara manual numenklatur sekolah berdasarkan data pokok pendidikan sekolah sekolah dasar;
3.
Pejabat Pembuat Komitmen (PPK) Rehabilitasi bersama-sama dengan Pokja Keuangan dan Pokja Rehabilitasi
melakukan proses pengkuotaan per
kabupaten/kota secara proporsional dan disesuaikan dengan alokasi anggaran rehabilitasi ruang kelas pada tahun berjalan berdasarkan DIPA Direktorat Pembinaan Sekolah Dasar dan melaporkan kepada Direktur Pembinaan Sekolah Dasar untuk mendapatkan persetujuan; 4.
Pokja Rehabilitasi mengirimkan surat pemberitahuan kuota dengan lampiran daftar usulan sekolah ke masing-masing kabupaten/kota disertai dengan instrumen verifikasi;
5.
Dinas Pendidikan Kabupaten/Kota melakukan proses seleksi dan verifikasi terhadap sekolah-sekolah calon penerima rehabilitasi disesuaikan dengan kuota yang diberikan oleh Pokja Rehabilitasi;
6.
Dinas Pendidikan Kabupaten/Kota melakukan perhitungan pembiayaan rehabilitasi ruang kelas berdasarkan indek kemahalan konstruksi dan satuan biaya per ruang yang terlampir dalam instrumen verifikasi;
7.
Dinas Pendidikan Kabupaten/Kota membuat Surat Pertanggungjawaban Mutlak (SPTJM) dengan lampiran daftar sekolah yang lolos proses verifikasi sesuai dengan kuota;
8.
Dinas Pendidikan Kabupaten/Kota mengirimkan SPTJM, daftar sekolah yang lolos verifikasi sesuai dengan kuota dan instrumen verifikasi;
9.
Pokja Rehabilitasi melakukan proses validasi dan merekap sekolah yang lolos verifikasi dan menyerahkan berkas verifikasi kepada Pokja Pendataan dan Pemberkasan untuk proses perekaman data verifikasi;
53 10.
Pokja Rehabilitasi menyusun dan mengajukan SK dengan lampiran rekapitulasi sekolah dan mengajukan Draft SK kepada Pokja Rehabilitasi untuk dimintakan persetujuan kepada Direktur;
11.
SK Penetapan penerima bantuan yang telah disetujui dan ditandatangani Direktur digunakan oleh Pokja Rehabilitasi sebagai dasar mengundang sekolah dalam rangka proses sosialisasi dan penandatangan Surat Perjanjian Pemberian Bantuan;
12.
Pokja Keuangan mengajukan Surat Permohonan Pencairan Dana (SPP) dengan lampiran daftar rekening sekolah dan jumlah dana ke Satuan Kerja Direktorat (Satker) untuk diterbitkan Surat Perintah Membayar (SPM);
13.
Satker mengajukan SPM ke KPPN Jakarta III untuk diterbitkan Surat Perintah Pembayaran Dana (SP2D);
14.
KPPN Jakarta III mengirimkan SP2D ke Bank Penyalur dan tembusan Satker Direktorat Pembinaan Sekolah Dasar;
15.
Bank Penyalur melakukan proses pencairan dana rehabilitasi;
16.
Satker Direktorat memberikan copy SP2D ke PPK Rehabilitasi;
17.
Sekolah menerima dana bantuan dan mengirimkan Surat Pemberitahuan Penerimaan Dana Bantuan ke PPK Rehabilitasi;
18.
Sekolah melaksanakan proses rehabilitasi dan mengirimkan laporan capaian fisik dan keuangan per periodik (30%, 70% 100%);
19.
Staf Direktorat Pembinaan Sekolah Dasar mencatat laporan rehabilitasi ruang kelas dari sekolah;
20.
Pokja Rehabilitasi Ruang Kelas membuat laporan pelaksanaan rehabilitasi dan dilampiri rekapitulasi realisasi rehabilitasi; dan
21.
Pokja Pelaporan menyusun semua laporan kegiatan rehabilitasi.
Proses pelaksanaan rehabilitasi ruang kelas sebagaimana telah diuraikan di atas dapat digambarkan secara garis besar dengan richt picture diagram sebagai berikut:
54
Gambar 3. 3 Mekanisme Penetapan SK Penerima Rehabilitasi
Gambar 3. 4 Mekanisme Penyaluran Dana ke Rekening Sekolah
55
3.2.1. Use Case Diagram Sistem Berjalan Dari rincian tugas setiap kelompok kerja (Pokja), uraian prosedur dan ricth picture mekanisme pemberian bantuan rehabilasi ruang kelas di atas dapat digambarkan sistem yang sedang berjalan dengan menggunakan use case diagram sebagai berikut:
Gambar 3. 5 Use Case Bantuan Rehabilitasi Ruang Kelas pada sistem berjalan
3.2.2. Skenario Usecase Rehabilitasi Ruang Kelas Berjalan Mekanisme pemberian bantuan rehabilitasi ruang kelas sekolah dasar sebagaimana telah digambarkan dalam usecase diagram di atas, dapat diuraikan dalam penjelasan rinci dalam Skenario usecase dalam tabel berikut:
56 Tabel 3. 1 Skenario Use Case Mengelola Pendataan Nama Use Case: Skenario : Aktor Utama Aktor Alternatif Diskripsi Singkat
Mengelola Data Pendataan dan Pemberkasan Mengelola Data Pendataan dan Pemberkasan Pokja Pendataan Menggambarkan proses pengelolaan berkas dan data-data usulan , pengelolaan berkas-berkas verifikasi, dan berkas pendandatangan perjanjian dengan sekolah.
Alur Aktivitas Tindakan Utama
Aktor 1. Pemohon mengirimkan usulan ke Direktorat Pembinaan Sekolah Dasar 2. Pokja Pendataan melakukan identifikasi usulan rehabilitasi ruang kelas dan menvalidasi dengan data referensi pendidikan apakah sekolah sudah teregistrasi referensi pendidikan yang dikeluarkan oleh Pusat Data Pendidikan. 3. Pokja Pendataan dan Pemberkasan melakukan transformasi data usulan dengan merekam data usulan menggunakan Ms. Excel. 4. Pokja Pendataan membuat Daftar Usulan Sekolah 5. Pokja Pendataan membuat rekapitulasi per kabupaten/kota yang berisi jumlah sekolah, jumlah ruang kelas rusak. 6. Pokja Pendataan dan Pemberkasan melaporkan hasil rekapitulasi dan Daftar Usulan yang telah dibuat kepada Pokja Rehabilitasi untuk dikuotakan 7. Pokja Pendataan dan Pemberkasan membuat laporan usulan 8. Pokja Pendataan dan Pemberkasan menyerahkan berkas usulan kepada Pokja Kesekretariatan dan Pengarsipan untuk disimpan. 9. Merekap data-data verifikasi berdasarkan instrumen verifikasi 10. Membuat rekap sekolah calon penerima sebagai lampiran Surat Keputusan Direktur
Aliran Alternatif Pra Kondisi Paska Kondisi
Tidak ada Tidak Ada Tidak Ada
Tabel 3. 2 Tabel Skenario Use Case Proses Quota Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Proses Quota Pokja rehabilitasi Menggambarkan proses penetapan quota ruang kelas per kabupaten/kota secara proporsional berdasarkan anggaran tahun berjalan.
57 Aliran Aktivitas: 1. Aliran Dasar
Aliran Alternatif Pra Kondisi Paska Kondisi
Aktor 1. Pokja Rehabilitasi menerima rekapitulasi dan daftar usulan rehabilitasi dan melaporkan kepada PPK Rehabilitasi. 2. Pokja Rehabilitasi melakukan indek alokasi sasaran kebutuhan ruang kelas secara proporsional 3. Pokja Keuangan menyesuaikan kebutuhan anggaran. 4. PPK Rehabilitasi menyerahkan draft quota kepada PPK Rehabilitasi. 5. PPK Rehabilitasi mengajukan rancangan quota rehabilitasi ruang kelas dilampiri dengan daftar sekolah untuk mendapatkan persetujuan Direktur. 6. Direktur menyetujui rancangan quota. Tidak ada Tidak Ada Tidak Ada
Tabel 3. 3 Skenario Use Case Koordinasi dan Verifikasi Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Koordinasi dan Verifikasi Pokja Rehabilitasi, Dinas Pendidikan Kabupaten/Kota Menggambarkan proses koordinasi, sosialisasi dan penyampaian informasi penetapan quota, mekanisme verifikasi dan validasi dan penyampaian informasi proses verifikasi yang harus dilakukan dan hal-hal yang harus dipenuhi oleh Dinas Pendidikan Kabupaten/Kota
Alur Aktivitas :
Aktor
1. Aliran Dasar
1. Pokja Rehabilitasi menginformasikan mekanisme pelaksanaan rehabilitasi dan penetapan quota dan daftar usulan sekolah kepada Dinas Pendidikan Kabupaten/Kota terkait. 2. Pokja Rehabilitasi menyerahkan panduan dasar verifikasi sebagai acuan Dinas Pendidikan Kabupaten/Kota untuk melakukan proses verifikasi 3. Dinas Pendidikan melakukan proses verifikasi ke sekolah 4. Dinas Pendidiakan membuat Surat PertanggungJawaban Mutlak dan lampiran sekolahsekolah yang lolos verifikasi 5. Dinas Pendidikan mengirimkan berkas verfikasi ke Prokja Rehabilitasi 6. Pokja rehabilitasi menyerahkan berkas verifikasi ke Pokja Pendataan untuk dilakukan proses rekapitulasi dan penerbitan lampiran surat penetapan. 7. Pokja rehabilitasi menyerahkan lampiran SK ke Pokja Rehabilitasi untuk dibuatkan konsideran SK dan untuk mendapatkan persetujuan dan tandatangan Direktur 8. Pokja pendaataan menyiapkan berkas-berkas surat
58 perjanjian Aliran Alternatif Pra Kondisi Paska Kondisi
Tidak Ada Tidak Ada
Tabel 3. 4 Skenario Use Case Menetapkan SK Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Menetapkan SK Direktur
Alur Aktivitas: 1. Aliran Dasar
Aktor 1. PPK Rehabilitasi berdasarkan mengajukan Konsideran SK kepada Direktur
Menggambarkan proses penetapan SK oleh Direktur
2. Direktur menyetujui dan menandatangani SK Aliran Alternatif
Pra Kondisi Paska Kondisi
Dalam kondisi tertentu bisa terjadi ada revisi dari Direktur, maka PPK Rehabilitasi melakukan revisi sesuai dengan arahan Direktur. SK telah ditandatangani Direktur, dan dijadikan dasar untuk melakukan proses sosialisasi oleh Pokja Rehabilitasi
Tabel 3. 5 Skenario Use Case Sosialisasi Nama Use Case Aktor Utama Aktor Alternatif Diskripsi
Sosialisasi Pokja Rehabilitasi, Sekolah
Alur Aktivitas: 1. Aliran Dasar
AKTOR 1. Pokja Rehabilitasi menyampaikan informasi detail pelaksanaan rehabilitasi kepada sekolah-sekolah yang sudah ditetapkan dalam SK Penetapan dalam forum sosialisasi 2. Sekolah mengikuti proses sosialisasi 3. Pokja Pendataan menyiapkan Surat Perjanjian Pemberian Bantuan yang akan ditandatangani oleh PPK
Menggambarkan proses penyampaian informasi pelaksanaan rehabilitasi kepada sekolah. Dalam pelaksaan sosialisasi sekolah dampingi oleh staf/atau petugas dari dinas pendidikan kabupaten/kota, dan dari Direktorat dilibatkan banyak narasumber dari instansi perpajakan, inspektorat, dan pemangku kebijakan terkait rehabilitasi ruang kelas di lingkungan Direktorat Pembinaan Sekolah Dasar. Dalam sosialisai ini dilakukan penandatangan perjanjian pemberian bantuan antara Pejabat Pembuat Komitmen Rehabilitasi dengan Kepala Sekolah yang bertindak untuk dan atas nama sekolah.
59 Rehabilitasi dan Kepala Sekolah. 4. PPK Rehabilitasi mengatur jalannya MoU 5. Sekolah Menandatangan SPPB 6. Kepala Sekolah menandatangani Surat Pernjanjian Pemberian Bantuan sebagai Pihak II selaku dan atas nama sekolah. 7. PPK Rehabilitasi mendandatangani Surat Perjanjian Pemberian Bantuan sebagai Pihak I selaku dan atas nama Direktorat Pembinaan Sekolah Dasar 8. Pokja Rehabilitasi menyerahkan SPPB ke Pokja Kesekretariatan dan Pengarsipan untuk disimpan. 9. Membuat laporan sosialisasi Aliran Alternatif Pra Kondisi Paska Kondisi
Kepala Sekolah sudah harus hadir pada saat penandatangan SPPB karena penandatangan SPPB tidak bisa diwakilkan. Tidak Ada
Tabel 3. 6 Skenario Use Case Memproses Pencairan Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Alur Aktivitas: 1. Aliran Dasar
Memproses Pencairan Kepala Satker, PPK Rehabilitasi, Kepala KPPN, Pokja Keuangan Menggambarkan rehabilitasi
1.
2.
3.
4.
5. 6. 7. 8.
proses
pengajuan
pencairan
dana
Aktor Berdasarkan SK Direktur dan SPPB yang sudah ditandatangani Pokja Pendataan menyiapkan lampiran Pengajuan Pencairan Dana yang berisi daftar sekolah, rekening dan nilai dana yang akan dicairkan dan menyerahkan kepada Pokja Keuangan untuk dibuatkan SPP LS Pokja Keuangan membuat Surat Permohonan Pencairan (SPP) dilampiri dengan Lampiran Pengajuan Pencairan yang dibuat oleh Pokja Pendataan dan Pemberkasan, selanjutnya dimintakan persetujuan dan tanda tangan PPK Rehabilitasi. SPP dan lampiran yang sudah ditandatangani PPK Rehabilitasi diajukan ke Satuan Kerja (Satker) Direktorat untuk diterbitkan Surat Perintah Membayar (SPM) dan Lampiran SPM. SPM dan lampiran SPM diajukan ke KPPN Jakarta III untuk diterbitkan Surat Perintah Pencairan Dana (SP2D) oleh Kepala KPPN. SP2D dikirimkan ke Bank Penyalur dan salinan SP2D diserahkan ke Satker Direktorat. Pokja Keuangan merekap SPM dan SP2D Pokja Keuangan membuat laporan pengajuan pencairan Pokja Keuangan menyerahkan SPM dan SP2D ke Pokja
60
Aliran Alternatif
Pra Kondisi Paska Kondisi
Keskretariatan dan Pengarsipan untuk disimpan Dalam kondisi kegagalan transfer dana bantuan yang disebabkan hal-hal tertentu, Bank Penyalur mengirimkan Surat Pemberitahuan Retur (SPR) ke KPPN Jakarta III dan diteruskan ke Satker Direktorat untuk ditindak lanjuti oleh Pokja Rehabilitasi. Tidak Ada
Tabel 3. 7 Skenario Use Case Menyalurkan Dana Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Menyalurkan Dana Bank Penyalur Menggambarkan proses pengiriman dana bantuan oleh Bank Penyalur
Alur Aktivitas:
Aktor
1. Aliran Dasar
1. Berdasarkan SP2D dari KPPN Jakarta III Bank Penyalur melakukan transfer dana ke rekening sekolah. 2. Sekolah menerima dana bantuan dan melaporkan jumlah dan tanggal penerimaan dana melalui Surat Pernyataan Penerimaan Dana ke Pokja Pendataan dan Pemberkasan. 3. Pokja Pendataan dan Pemberkasan melakukan pencatatan Surat Pemberitahuan dan Rekapitulasi penerimaan dana sekolah. 4. Pokja Pendataan dan Pemberkasan menyerahkan Surat Pemberitahuan Penerimaan/Belum menerima kepada Pokja Kesekretariatan dan Pengarsipan untuk disimpan.
Aliran Alternatif Pra Kondisi Paska Kondisi
Tidak Ada
Tabel 3. 8 Skenario Use Case Mengelola Pelaksanaan Rehabilitasi Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat Alur Aktivitas: 1. Aliran Dasar
Mengelola Pelaksanaan Rehabilitasi Sekolah Usecase ini menggambarkan proses pelaksanan pekerjaan rehabilitsasi ruang kelas di tingkat sekolah Aktor 1. Sekolah melaksanakan pekerjaan dalam jangka waktu 90 hari kalender 2. Sekolah menyusun Tim Teknis Pelaksana Rehabiitasi Ruang Kelas SD 3. Sekolah melaksanakan rehabilitasi ruang kelas sesuai dengan RAB 4. Sekolah menyusun laporan periodik dan mengirimkan ke Direktorat melalui Dinas Pendidikan. 5. Sekolah menyusun laporan akhir pertanggung jawaban dan mengirimkan laporan akhir pertanggung jawaban melalui
61
6. 7. Aliran Alternatif Pra Kondisi Paska Kondisi
Dinas Pendidikan Pokja Keuangan merekap laporan periodik dan laporan akhir sekolah. Pokja Keuangan menyerahkan laporan sekolah kepada Pokja Kesekretariatan dan Pengarsipan untuk disimpan.
Tidak Ada
Tabel 3. 9 Skenario Use Case Mengelola Laporan Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Mengarsipkan Dokumen Kegiatan Pokja Pelaporan, Pokja Pendataan Usecase ini menggambarkan pelaksanaan rehabilitasi
Alur Aktivitas: 1. Aliran Dasar Aliran Alternatif Pra Kondisi Paska Kondisi
proses
pengelolaan
laporan
Aktor Membuat laporan-laporan rehabilitasi.
kegiatan
laporan
pelaksanaan
Tidak Ada
Tabel 3. 10 Skenario Use Case Mengarsipkan Dokumen Kegiatan Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat
Mengarsipkan Dokumen Kegiatan Pokja Kesekretariatan dan Pengarsipan Usecase ini menggambarkan proses pengarsipan dokumen kegiatan rehabilitasi
Alur Aktivitas:
Aktor
1. Aliran Dasar
Menerima, menghimpun, mencatat dan mengarsipan laporan pelaksanaan rehabilitasi.
Aliran Alternatif Pra Kondisi Paska Kondisi
Tidak Ada
Tabel 3. 11 Skenario Use Case Mengajukan Usulan Nama Use Case Aktor Utama Aktor Alternatif Diskripsi Singkat Alur Aktivitas: 1. Aliran Dasar Aliran Alternatif Pra Kondisi Paska Kondisi
Mengajukan Usulan Pemohon Usecase ini menggambarkan proses pengajuan usulan sekolah untuk mendapatkan bantuan rehabilitasi ruang kelas. Aktor Mengajukan usulan sekolah untuk mendapatkan bantuan rehabilitasi ruang kelas ke Direktorat Pembinaan Sekolah Dasar
Tidak Ada
62 Berdasarkan analisa use case sistem berjalan terdapat proses dapat diketahui bahwa masih banyak proses administrasi tidak sistematis. Terutama pada pekerjaan-pekerjaan yang menyangkut perekaman data, penyimpanan data dan pengolahan data-data rehabilitasi yang tidak melekat pada lembaga dalam bingkai sebuah sistem yang efektif, tetapi melekat pada pegawai secara personal. Kondisi kebergantungan kepada personal secara langsung maupun tidak langsung akan mempengaruhi kinerja sistem Direktorat pada umumnya. 3.3. Perancangan Aplikasi Pengelolaan administrasi rehabilitasi ruang kelas di Direktorat Pembinaan Sekolah Dasar tidak lepas dari tata kelola berkas yang harus ditata sedemikian rupa. Sehingga perancangan aplikasi rehabilitasi yang dilakukan diharapkan dapat membantu mempercepat proses administrasi berkas yang tidak bersifat fisik, tetapi berhubungan erat dengan dokumen-dokumen fisik rehabilitasi. Tata kelola dokumen non fisik seperti pengelolaan data-data data usulan sekolah, data hasil verifikasi,
data
pengajuan
pencairan,
pencatatan
SPM,
SP2D,
Surat
Pemberitahuan Retur, Surat Pernyataan Dana Belum Masuk, Surat Pemberitahuan Dana Masuk, pencatatan laporan sekolah, Rekapitulasi/Laporan Usulan, Laporan Realisasi per tahun, Laporan Retur harus dirancang dengan baik untuk mempercepat dan mempermudah proses pernyiapan dan pencatatan dokumendokumen rehabilitasi tersebut. 3.3.1. Usulan Rancangan Sistem Sistem Aplikasi Pengelolaan Rehabilitasi Ruang Kelas Sekolah Dasar Tahap perancangan aplikasi untuk membangun suatu aplikasi dengan mengkonfigurasikan komponen-komponen perangkat lunak dan perangkat keras sehingga menghasilkan sistem aplikasi yang baik. Pemodelan aplikasi diusahakan mendekati sama realitas yang terjadi dalam proses bantuan rehabilitasi. Dengan menggunakan diagram-diagram UML penggambaran rancangan ini diharapkan dapat dipahami dengan mudah sehingga pada tahap implementasi tidak ada kesulitan.
63 3.3.2. Use Case Diagram Sistem Aplikasi Usulan
Gambar 3. 6 Usecase Diagram Sistem Aplikasi Usulan
64 3.3.3. Definisi Aktor Sistem Aplikasi Usulan Berikut adalah deskripsi pendefinisian aktor pada sistem administrasi pengelolaan bantuan rehabilitasi: Tabel 3. 12 Tabel Definisi Aktor No
Nama Aktor
1
User
2
Admin Pendataan
3
Admin Keuangan
4
Administrator
Deskripsi Petugas yang memiliki hak akses untuk melakukan operasi pengelolaan data usulan sekolah dan data hasil verifikasi sekolah penerima bantuan rehabilitasi User yang berperan untuk membuat lampiran SK, lampiran nomor Surat Pernjanjian Pemberitahuan Bantuan (SPPB), yang merupakan bagian dari usecase pengelolaan pencairan, operasi data referensi surat pemberitahuan pemberitahuan retur (SPR) dari Satuan Kerja Direktorat dan membuat laporan usulan, laporan realisasi, profil bantuan per sekolah, laporan retur pada tahun anggaran berjalan. User yang memiliki akses pengelolan proses pengajuan pencairan dana (SPP) pencairan bantuan dan mengelola laporan User yang memiliki hak akses untuk mengelola data usulan dan verifikasi, juga memiliki hak akses untuk melakukan operasi terhadap datadata master. Data master meliputi master sekolah, master IKK dan master user.
3.3.4. Skenario Use Case Sistem Aplikasi Usulan Skenario usecase dalam tabel-tabel berikut ini menggambarkan proses masing-masing usecase. 3.3.5.1. Skenario Use Case Login Tabel 3. 13 Skenario Use case Login Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat:
Login Login aplikasi User mulai menggunakan aplikasi Ketika user mulai menggunakan aplikasi, aplikasi melakukan
65 validasi username, password dan hak akses User yang -
Aktor Use Case Terkait: Stakeholders
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Kondisi Pengecualian:
Staf Subdit Program dan Evaluasi, Pegawai Bagian Keuangan Output Kegiatan Perencanaan, Pimpinan User harus sudah terdaftar dan memiliki username dan password User menggunakan aplikasi sesuai hak akses. Aktor Aplikasi 1. User membuka aplikasi 1.1. Menampilkan Frame Utama dalam kondisi non aktif dan menampilkan dialog login 2. Memasukkan username 2.1. Validasi dan verifikasi dan password username password dan hak akses 2.1. Apabila username dan password ditolak karena validasi dan verifikasi maka : a. login dibatalkan b. login ditahan hingga username dan password benar
3.3.5.2. Skenario Use Case Mengelola Referensi Tabel 3. 14 Skenario Use Case Mengelola Data Referensi Nama Use Case: Skenario:
Mengelola Referensi Mengelola Referensi Sekolah, Referensi IKK, Referensi Surat Pemberitahuan Retur, Data User Pemicu Kejadian: Administrator melakukan manipulasi data referensi Deskripsi Singkat: Ketika ada item referensi baru, data referensi yang harus di ubah atau data referensi yang seharusnya dihapus. Aktor Adminstrator Use Case yang Terkait: Stakeholders Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai user Pra Kondisi: Administrator sudah mengakses frame referensi Paska Kondisi Item referensi direkam Alur Aktivitas: Aktor Aplikasi 1. Administrator membuka 1.1. Menampilkan frame salah satu sub menu referensi referensi 2. Memverifikasi data 2.1. Menampilkan informasi data referensi referensi 3. Menambahkan data 3.1. Menambahkan data referensi referensi 3.2. Menampilkan informasi data referensi berhasil ditambahkan 4. Mengulang langkah 2, 3 jika diperlukan 5. Menutup frame referensi 5.1. Frame referensi ditutup Kondisi 2.1. Jika berhubungan dengan data individu sekolah, dan sekolah
66 Pengecualian:
tidak belum tidak memiliki npsn maka administrator dapat menghubungi Pusat Data Statistik Pendidikan untuk mendapatkan npsn dan menginput sebagai data referensi setelahnya. 3.1. Jika terjadi kesalahan dalam input data referensi, maka administrator dapat melakukan: a. melakukan perubahan terhadap data yang sudah diinput b. menghapus data yang sudah diinput untuk selanjutnya menginput ulang dengan data yang benar
3.3.5.3. Skenario Use Case Mengelola Usulan Tabel 3. 15 Skenario Use Case Mengelola Usulan Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat:
Aktor Use Case Terkait: Stakeholders
Mengelola Usulan Mengelola Usulan Sekolah User melakukan manipulasi data usulan Ketika ada item data baru usulan sekolah yang harus dimasukkan, data usulan yang harus di ubah, dan data item usulan yang harus dihapus. Pencetakkan laporan jika ada permintaan laporan detail usulan per sekolah. User yang -
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Kondisi Pengecualian:
Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai user User sudah mengakses frame administrasi usulan Item usulan sekolah direkam Aktor Aplikasi 1. User membuka salah 1.1. Menampilkan frame sub menu administrasi administrasi usulan sekolah usulan sekolah 2. Memverifikasi data 2.1. Menampilkan informasi data usulan referensi sekolah 3. Meng-input data detail 3.1. Validasi data usulan usulan 3.2. Menambahkan data item usulan baru 3.3. Menampilkan informasi data baru berhasil di input. 6. Mengulang langkah 2, 3 jika diperlukan 7. Menutup frame 7.1. Frame administrasi usulan administrasi usulan ditutup 2.1. Jika data usulan tidak ada dalam referensi sekolah, maka user dapat melakukan: a. memilih tidak menginput data usulan b. meminta administrator untuk melakukan penambahan data referensi dan melanjutkan menambahkan data usulan
67 setelahnya. 3.1. Jika terjadi kesalahan dalam input data usulan, maka user dapat melakukan: a. melakukan perubahan terhadap data yang sudah diinput b. menghapus data yang sudah diinput untuk selanjutnya menginput ulang dengan benar
3.3.5.4. Skenario Use Case Mengelola Verifikasi Tabel 3. 16 Skenario Use Case Mengelola Verifikasi Nama Use Case: Skenario: Pemicu Kejadian:
Mengelola Verifikasi Mengelola Verifikasi Usulan Sekolah User menerima berkas verifikasi sekolah dari Dinas Pendidikan Kabupaten/Kota Deskripsi Singkat: Ketika berkas verifikasi diterima user memvalidasi berkas dan menambahkan item verifikasi ke daftar verifikasi sekolah, jika mengharuskan adanya perubahan data verifikasi user mengubah atau menghapus data verifikasi, aplikasi memverifikasi bobot kerusakan dan menghitung biaya rehabilitasi. Aktor User Use Case yang Extends : Mengelola Usulan Terkait: Stakeholders Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai user Petugas Dinas Pendidikan Kabupaten/Kota yang menyerahkan dan bertanggung jawab terhadap berkas verifikasi. Petugas validasi yang ditugaskan melakukan bimbingan teknis pengisian berkas verifikasi. Pra Kondisi: User sudah mengakses frame administrasi verifikasi Paska Kondisi Item Sekolah yang diverifikasi disimpan Alur Aktivitas: Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame menu administrasi administrasi verifikasi verifikasi sekolah sekolah 2. Memverifikasi data 2.1. Menampilkan informasi data sekolah individu sekolah 3. Menambahkan item 3.1. Menambahkan item verifikasi verifikasi 3.2. Mengkalkulasi biaya 3.3. Menampilkan informasi penambahan item 3. Menutup frame 3.1. Frame administrasi administrasi verifikasi verifikasi di tutup Kondisi 2.1. Jika data usulan tidak ada dalam referensi sekolah, maka user Pengecualian: dapat melakukan: a. memilih tidak menginput data usulan b. meminta administrator untuk melakukan penambahan data referensi dan melanjutkan menambahkan data usulan setelahnya. 3.1. Jika terjadi kekeliruan input data verifikasi maka user dapat
68 melakukan: a. melakukan perubahan terhadap data yang sudah diinput b. menghapus data yang sudah diinput selanjutnya menginput ulang dengan benar
3.3.5.5. Skenario Use Case Membuat Lampiran SK Tabel 3. 17 Skenario Use case Membuat Lampiran SK Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat:
Aktor Use Case Terkait: Stakeholders
Membuat Lampiran SK Membuat Lampiran Rencana PengajuanSK Permintaan untuk pengajuan Penetapan Sekolah Penerima Rehab Ketika data-data verifikasi sudah diinput dan akan dimasukkan dalam lampiran pengajuan SK user harus menambahkan sekolah ke daftar lampiran SK. Admin pendataan yang Include: Mengelola Verifikasi
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Kondisi Pengecualian:
Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin pendataan PPK Rehabilitasi yang akan melakukan pengajuan SK Kepala Subdit Program dan Evaluasi mengetahui. Direktur mengesahkan Admin pendataan mengakses frame Proses SK Lampiran SK dibuat, dicetak dan diajukan sebagai lampiran Konsideran SK ke Direktur Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame Proses menu Proses SK SK 2. Melihat Daftar Verifikasi 2.1. Menampilkan informasi data Sekolah verifikasi sekolah yang berstatus belum proses SK 3. Menambahkan item 3.1. Menambahkan item lampiran SK lampiran SK 3.2. Mengupdate status proses SK 3.3. Menampilkan informasi penambahan lampiran 3.4. Menampilkan informasi sekolah dalam proses SK 4. Mencetak Lampiran SK 5. Menutup frame Proses 5.1. Frame Proses SK ditutup SK 6. PPK Mengajukan SK ke Direktur 3.1. Jika terjadi kekeliruan penambahan data verifikasi maka user dapat menghapus dan menambahkan dengan dengan benar. 6.1. Jika SK sudah ditandatangani Direktur dan sudah mendapatkan nomor pembukuan dari Bagian Tata Usaha, maka user harus melakukan update nomor SK
69 3.3.5.6. Skenario Use Case Membuat Nomor SPPB Tabel 3. 18 Skenario Use Case Membuat Nomor SPPB Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat:
Aktor Use Case Terkait: Stakeholders
Membuat Nomor SPPB Membuat Nomor SPPB untuk proses penandatangan MoU Disusun jadwal sosialisasi Membuat nomor Surat Perjanjian Pemberian Bantuan yang akan digunakan dalam proses penandatangan mou dengan sekolah pada saat sosialisasi dilaksanakan. Admin pendataan yang Include: Membuat Nomor SK
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin pendataan Staf yang ditugaskan dalam proses sosialisasi Sekolah yang mengikuti proses sosialisasi PPK Rehabilitasi dan BPP dalam hal penandatangan SPPB dan Kwitansi Admin pendataan sudah mengakses frame Proses SPPB Nomor SPPB dibuat Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame Proses menu Proses SPPB SPPB 2. Melihat Daftar SK 2.1. Menampilkan informasi sekolah dalam daftar SK 3. Menambahkan item 3.1. Menambahkan item sekolah lampiran sekolah dengan nomor SPPB 3.2. Menampilkan informasi penambahan item 4.
Mengekspor ke format CSV 5. Menutup frame Proses 5.1. Frame Proses SPPB ditutup SPPB 3.1. Jika terjadi kekeliruan penambahan data SPPB maka user dapat menghapus dan menambahkan dengan dengan benar. 4.1. User menyerahkan file CSV ke staf yang ditugaskan dalam proses sosialisasi untuk digunakan dalam proses mailmerge SPPB.
Kondisi Pengecualian:
3.3.5.7. Skenario Use Case Proses Membuat Lampiran SPP Tabel 3. 19 Skenario Use case Membuat Lampiran SPP Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat:
Membuat Lampiran SPP Membuat Nomor SPP untuk pengajuan pencairan dana Pengajuan pencairan dana akan dilakukan Ketika berkas Surat Perjanjian Pemberian Bantuan (SPPB) sudah
70 diterima, pengajuan SPP dilakukan berdasarkan SPPB yang sudah ditandatangani. Admin Keuangan yang Include: Membuat Nomor SPPB
Aktor Use Case Terkait: Stakeholders
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin keuangan Staf yang ditugaskan dalam proses sosialisasi Sekolah yang mengikuti proses sosialisasi PPK Rehabilitasi dan BPP dalam hal penandatangan SPPB dan Kwitansi Admin keuangan sudah mengakses frame Proses SPP Lampiran SPP dibuat Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame Proses menu Proses SPP SPP 2. Melihat Nomor SPPB 2.1. Menampilkan informasi sekolah dalam daftar SPPB 3. Menambahkan item 3.1. Menambahkan item sekolah lampiran SPP 3.2. Menampilkan informasi penambahan item 4. 5. 6.
7.
Kondisi Pengecualian:
3.1. 7.1. 7.2. 7.3.
Mencetak Lampiran SPP Menutup frame Proses 5.1. Frame Proses SPP ditutup SPP Mengajukan Surat Pengajuan Pencairan dengan Lampiran SPP ke Satker. Satker menerbitkan SPP dan mengajukan ke KPA untuk diterbitkan SPM, mengajukan SPM ke KPPN untuk diterbitkan SP2D Jika terjadi kekeliruan penambahan data SPP maka user dapat menghapus dan menambahkan dengan dengan benar. Jika nomor SPP sudah terbit dan diterima dari Satker, maka admin keuangan melakukan update nomor SPP. Jika SPM sudah terbit dan diterima admin keuangan mengupdate nomor SPM Jika nomor SP2D sudah terbit dan diterima maka admin keuangan melakukan update nomor SP2D
3.3.5.8. Skenario Use Case Mengelola Referensi Retur Tabel 3. 20 Skenario Use case Mengelola Referensi Retur Nama Use Case:
Mengelola Referensi Retur
71 Skenario: Pemicu Kejadian: Deskripsi Singkat:
Aktor Use Case Terkait: Stakeholders
Membuat Data Referensi Retur Surat Pemberitahuan Retur dari KPPN diterima Ketika berkas surat pemberitahuna retur direrima dari KPPN, dilakukan proses perekaman surat pemberitahuan retur dalam data referensi SPR. Admin Keuangan yang Spesialisasi: Mengelola Referensi Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin keuangan
Pra Kondisi: Paska Kondisi Alur Aktivitas:
Admin keuangan sudah mengakses frame Proses SPP Item referensi SPR dibuat Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame menu Referensi Surat Referensi Surat Pemberitahuan Retur Pemberitahuan Retur 2. Melihat Nomor SPP 2.1. Menampilkan informasi sekolah dalam daftar SPP yang SP2Dnya sudah terbit 3. Menambahkan item 3.1. Menambahkan item sekolah sekolah 3.2. Menampilkan informasi penambahan item 4.
Menutup frame 4.1. Frame Proses Surat Referensi Surat Pemberitahuan Retur ditutup Pemberitahuan Retur 5. Menginformasikan kepada sekolah tentang status retur 6. Sekolah mengirimkan rekening revisi 3.1. Jika terjadi kekeliruan penambahan data sekolah maka user dapat menghapus dan menambahkan dengan dengan benar.
Kondisi Pengecualian:
3.3.5.9. Skenario Use Case Membuat Lampiran Pengajuan Retur Tabel 3. 21 Skenario Use case Membuat Lampiran Pengajuan Retur Nama Use Case: Skenario: Pemicu Kejadian: Deskripsi Singkat: Aktor Use Case Terkait: Stakeholders
Membuat Lampiran Pengajuan Retur Membuat Nomor Pengajuan pencairan ulang sekolah yang retur Rekening revisi diterima Ketika rekening perbaikan dari sekolah sudah diterima, dilakukan ralat pengajuan pencairan dengan lampiran sekolah retur. Admin Keuangan yang Include: Mengelola Referensi SPR Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin keuangan PPK dan BPP dalam hal penandatangan ralat
72 Pra Kondisi: Paska Kondisi Alur Aktivitas:
Admin keuangan sudah mengakses frame Proses Retur Lampiran ralat dibuat Aktor Aplikasi 1. User membuka sub 1.1. Menampilkan frame Proses menu Proses Retur Retur 2. Melihat Nomor Surat 2.1. Menampilkan informasi Pemberitahuan Retur sekolah dalam daftar Surat Pemberitahuan Retur 3. Menambahkan item 3.1. Menambahkan item sekolah rekening revisi lampiran 3.2. Menampilkan informasi penambahan item 4.
Kondisi Pengecualian:
Mencetak Lampiran Retur 5. Menutup frame Proses 5.1. Frame Proses SPP ditutup SPP 6. Mengajukan Surat Pengajuan Pencairan dengan lampiran sekolah ke Satker. 3.1. Jika terjadi kekeliruan penambahan data retur maka user dapat menghapus dan menambahkan dengan dengan benar.
3.3.5.10. Skenario Use Case Mengelola Laporan Sekolah Tabel 3. 22 Skenario Use case Mengelola Laporan Sekolah Nama Use Case: Skenario:
Mengelola Laporan Sekolah Mencatat Laporan Penerimaan Dana dan Laporan Akhir Pertanggung Jawaban Pemicu Kejadian: Laporan Penerimaan Dana dan Laporan Akhir Pertanggungjawaban diterima Deskripsi Singkat: Ketika sekolah sudah menerima dana, sekolah mengirimkan surat pemberitahuan penerimaan dana, ketika pelaksanaan rehabiltais ruang kelas selesai sekolah mengirimkan laporan akhir pertanggungjawaban Aktor Admin Pendataan Use Case yang Terkait: Stakeholders Staf Subdit Program dan Evaluasi yang memiliki hak akses sebagai admin pendataan Sekolah sebagai penerima bantuan Pra Kondisi: Admin pendataan sudah mengakses frame administrasi laporan sekolah Paska Kondisi Laporan sekolah dicatat Alur Aktivitas: Aktor Aplikasi 1. Sekolah mengirimkan laporan penerimaan dana 2. Admin pendataan 2.1. Mengupdate tanggal laporan
73
3.
4. Kondisi Pengecualian:
2.1. 4.1.
mencatat surat penerimaan daan Sekolah mengirimkan laporan akhir pertanggung jawaban Admin pendataan 4.1. mengupdate laporan tanggal mencatat laporan akhir laporan akhir Jika terjadi kekeliruan update laporan admin pendataan dapat membatalkan pencatatan laporan. Jika terjadi kekeliruan update laporan admin pendataan dapat membatalkan pencatatan laporan
3.3.5. Activity Diagram Sistem Aplikasi Usulan Untuk menggambarkan aliran fungsionalitas dari aplikasi digunakan activity diagram sebagai berikut: 3.3.5.1. Activity Diagram Login
Gambar 3. 7 Activity Diagram Usulan Login
74 3.3.5.2. Activity Diagram Mengelola Referensi
Gambar 3. 8 Activity Diagram Mengelola Referensi
75 3.3.5.3. Activity Diagram Mengelola Usulan
Gambar 3. 9 Activity Diagram Mengelola Data Usulan
76 3.3.5.4. Activity Diagram Mengelola Verifikasi
Gambar 3. 10 Activity Diagram Mengelola Data Verifikasi
77 3.3.5.5. Activity Diagram Membuat Lampiran SK
Gambar 3. 11 Activity Diagram Membuat Lampiran SK
78 3.3.5.6. Activity Diagram Membuat Nomor SPPB
Gambar 3. 12 Activity Diagram Membuat Lampiran SPPB
79 3.3.5.7. Activity Diagram Membuat Lampiran SPP
Gambar 3. 13 Activity Diagram Membuat Lampiran SPP
80
3.3.5.8. Activity Diagram Membuat Lampiran Retur
Gambar 3. 14 Activity Diagram Lampiran Retur
81 3.3.5.9. Activity Diagram Mengelola Laporan
Gambar 3. 15 Activity Diagram Mengelola Laporan Sekolah
82
Gambar 3. 16 Activity Diagram Mengelola Laporan
3.3.6. Class Diagram Struktur kelas pada proses analisa perancangan sistem aplikasi administrasi rehabilitasi diidentifikasi dari use case diagram dan diskripsi use case diagram yang telah diuraikan pada definisi sebelumnya. Dari sejumlah kandidat kelas yang diperoleh dilakukan eliminasi sehingga diperoleh kelas-kelas yang efektif untuk pengembangan aplikasi. Rancangan aplikasi ini menggunakan pattern DAO (Direct Acces Object) dalam proses manipulasi database ke dalam DBMS. Kelaskelas dalam layer DAO merupakan kelas interface yang berisi enkapsulasi dari metode-metode manipulasi database. Secara detail kelas-kelas yang berhubungan dengan graphical user interface (GUI) dan kelas yang mengatur peran User terhadap aplikasi tidak dibahas dalam analisa desain aplikasi, tetapi akan
83 diimplementasi pada tahap pemrograman. Konsekwensinya setiap kelas yang berkorelasi dengan database harus dibuatkan kelas DAO. Dalam rancangan aplikasi ini beberapa metode atau atribut kelas sengaja tidak dituliskan secara detail karena keterbatasan media. Selanjutnuya secara parsial kelas-kelas yang diperoleh dan hubungan antar kelas (multiplicity) akan diilustrasikan dan dideskripsikan dalam gambar-gambar berikut.
Gambar 3. 17 Multiciplicity Class Diagram Sekolah dan Wilayah dan Realization
84 Class diagram pada gambar 3.24 menunjukkan beberapa kelas berasosiasi dengan kelas yang lain dengan derajat multiplicity yang berbeda. Sebagai contoh adalah hubungan antara kelas provinsi dan kelas kabupaten/kota dinyatakan dengan simbol asosiasi dengan tingkat multiciplicity dalam derajat relasi one to many, dimana setiap satu dan hanya satu provinsi memiliki setidaknya satu atau banyak kabupaten/kota dan banyak kabupaten berada dalam satu dan hanya satu provinsi. Kelas WilayahDAOInterface dan SekolahDAOInterface merupakan penerapan enkapulasi dalam perancangan sistem berbasis objek, dimana kedua kelas tersebut hanya merupakan kelas yang berisi metoda tanpa attribut lainnya. Simbol realization menjelaskan bahwa metoda yang ada di dalam kedua kelas WilayahDaoInterface akan diimplementasikan dalam kelas WilayahDAOImplement
demikian
juga
dengan
interface
SekolahDAOInterface
diimplementasikan oleh kelas SekolahDAOImplement.
Gambar 3. 18 Multiciplicity Class Diagram IKK dan Realization
akan
85 Keterangan Gambar: IKK = Indek Kemahalan Konstruksi DAO = Direct Acces Objcet Derajat multiplicity class diagram IKK ditujukkan dalam ilustrasi gambar di atas, dimana dalam satu tahun anggaran memiliki banyak IKK dan banyak IKK dimiliki oleh satu dan hanya satu kelas KabKota. Selanjutnya metoda-metode dalam IKK dienkapsulasi dalam kelas IkkDAOInterface yang memiliki hubungan realization
dengan kelas IkkDAOImplement. Kelas IkkDAOInterface akan
mengatur akses dengan datasource dengan menggunakan kelas DatabaseUtilities yang dalam pendekatan model tradisional memiliki derajat relasi one to one .
Gambar 3. 19 Multiciplicity Class Diagram UsulanBantuan dan Realization UsulanDAO
86 Assosiation class diagram UsulanBantuan dengan kelas Tahun dan Sekolah memiliki derajat relasi one to one, yang menunjukkan bahwa dalam tahun yang sama hanya ada satu sekolah dalam kelas UsulanBantuan. Enkapsulasi metoda dalam kelas interface UsulanDaoInterface diimplementasikan oleh kelas UsulanDAOImplement.
Gambar 3. 20 Multiciplicity Class Diagram Verifikasi dan Realization VerifikasiDAO
Dari ilustrasi gambar 3.27 dapat dijelaskan multiplicity dari kelas Verifikasi dengan kelas UsulanBantuan memiliki derajat one to many yang berarti bahwa dalam setiap verifikasi dapat dilakukan untuk satu atau banyak usulan bantuan. Dalam proses manipulasinya menggunakan kelas DatabaseUtilities untuk sebagai
87 yang berperan untuk menampung koneksi ke database dan kelas DAO interface dan implement seperti penjelasan kelas-kelas sebelumnya.
Gambar 3. 21 Multiciplicity Class Diagram yang terlibat dalam use case Proses SK
Keterangan Gambar: nomorRSK = Nomor Rencana Lampiran SK Dari ilustrasi gambar 3.28 dapat dijelaskan multiplicity dan realization dari kelas-kelas yang terlibat dalam proses pengajuan SK memiliki derajat one to one. Dimana kelas Verifikasi memiliki hubungan asosiasi dalam derajat relasi one to one terhadap kelas LampiranSK. Dalam kelas LampiranSK satu lampiran hanya memiliki satu SK. Demikian juga dengan kelas DatabaseUtilities berbuhungan one to one dengan kelas SKDAOInterface dan LampiranSKDAO Interface. Proses
88 implementasi dari kelas interface SK dan Lampiran SK diimplementasikan dalam kelas SKDAOImplement dan LampiranSKDAOImplement. Dalam proses pengajuan pencairan kelas-kelas yang terlibat adalah sebagiamana dalam diilustrasikan dalam gambar berikut.
Gambar 3. 22 Multiciplicity Class Diagram yang terlibat dalam use case Proses Pengajuan Pencairan
Keterangan Gambar: SPPB = Surat Perjanjian Pemberian Bantuan RSPP = Rencana Lampiran Surat Pencairan SPP = Surat Pengajuan Pencairan SPM = Surat Perintah Membayar SP2D = Surat Perintah Pencairan Dana Derajat multiplicity yang antar kelas dalam proses pengajuan pencairan dalam pendekatan pembangunan sistem konvensional pada umumnya one to one.
89 Dalam gambar di atas mendiskripsikan secara jelas bahwa satu Lampiran SK memiliki satu SPPB dan sebaliknya. Perbedaan pada kelas SPP, SPM, dan SP2D yakni satu dan hanya satu SPP, SPM dan SP2D bisa memiliki setidaknya satu atau lebih LampiranRSPP. Enkapsulasi metode-metode pada kelas DAOInterface diimplementasikan menggunakan kelas DAOImplement untuk mengakses datasource dengan menggunakan kelas DatabaseUtilities.
Gambar 3. 23 Multiciplicity Class Diagram yang terlibat dalam use case Proses Pengajuan Retur
Keterangan Gambar: SPR = Surat Pemberitahuan Retur RSPP = Rencana Lampiran Surat Pengajuan Pencairan
90 Dalam analisa class diagram proses pengajuan retur seperti gambar di atas, ada tingkat multiciplicity 0..* seperti hubungan antara kelas SP2D dengan kelas SPR atau antar kelas RencanaSPP dengan kelas SPR. Artinya satu dan hanya satu SP2D boleh jadi tidak memiliki SPR atau memiliki banyak SPR, demikian juga setiap RencanaSPP boleh jadi tidak memiliki sama sekali SPR atau memiliki banyak
SPR.
Selanjutnya
multiplicity
kelas
RencanaSPP
dengan
SPR
menunjukkan derajat many to many sehingga assosiasi yang terjadi memunculkan kelas PengajuanPencairan.
Gambar 3. 24 Multiciplicity Class Diagram yang terlibat dalam use case Proses Pengajuan Retur
Dalam analisa class diagram proses pelaporan kelas RencanaSPP memiliki derajat multiplicity many to many sehingga memunculkan assosiasi kelas baru DetailLaporan. Dalam tahap akhir analisa perancangan class diagram dapat digambarkan
secara
keseluruhan
sebagaimana gambar berikut.
dengan
menyembunyikan
kelas
DAO
91
Gambar 3. 25 Class Diagram Sistem Administrasi Pengelolaan Bantuan Rehabilitasi
92
3.3.7. Rancangan Model Konseptual Aplikasi
93 Gambar 3. 26 Struktur Table dalam Rancangan Basis Data Aplikasi Pengelolaan Bantuan Rehabilitasi Ruang Kelas
3.3.8. Perancangan Basis Data Struktur basis data digunakan dalam perancangan aplikasi administrasi pengelolaan rehabilitasi ruang kelas untuk menentukan struktur fisik database dan menunjukan karakteristik dari elemen-elemen dalam tabel-tabel database. Jenis tabel dalam rancangan database aplikasi ini terdiri dari tabel master dan transaksi sebagai yang secara detail diuraikan dalam tabel-tabel di bawah. Hasil akhir dari analisa perancangan basis data adalah sebagaimana diilustrasikan dalam gambar 3.26. 3.3.9.1. Tabel Master 1. Nama File Media Isi Primary key Struktur
: : : : :
ref_provinsi harddisk data-data provinsi provinsi_kode lihat tabel
Tabel 3. 23 Struktur Basis Data Tabel Ref_Provinsi No 1. 2. 3.
Nama Field PROVINSI_ID PROVINSI_NAMA CREATED_ON
Rancangan Kode
2. Nama File Media Isi Primary key Foregn key Struktur
Tipe Data
Ukuran
VARCHAR VARCHAR DATE
6 40
Keterangan Kode Provinsi Nama Provinsi Tanggal Input
: format untuk kode provinsi adalah xxxxxxxx, dimana dua digit pertama merupakan kodifikasi dari provinsi : : : : : :
ref_kabkota harddisk data-data kabkota kabkota_kode provinsi_id lihat tabel
Tabel 3. 24 Struktur Basis Data Tabel Ref_KabKota No 1. 2. 3. 4. 5.
Nama Field KABKOTA_ID KABKOTA_NAMA PROVINSI_ID CREATED_ON LAST_UPDATED
Tipe Data
Ukuran
VARCHAR VARCHAR VARCHAR DATE TIMESTAMP
6 45 6
Keterangan Kode Kabupaten/Kota Nama Kabupaten/Kota Kode Provinsi Tanggal Input Tanggal Update Terakhir
94 Rancangan Kode : format untuk kode kabupaten/kota adalah xxxxxxxx, dimana dua digit pertama merupakan kode dari provinsi, dua digit kedua merupakan kode kabupaten/kota
3. Nama File Media Isi Primary key Foreign key Struktur
: : : : : :
ref_wilayah harddisk data-data wilayah kecamatan kecamatan_id kabkota_id, provinsi_id lihat tabel
Tabel 3. 25 Struktur Basis Data Tabel Ref_Wilayah No 1. 2. 3. 4. 5. 6. 7. 8.
Nama Field
Tipe Data
KECAMATAN_ID KECAMATAN_NAMA KABKOTA_ID PROVINSI_ID STATUS_WILAYAH KETERANGAN CREATED_ON LAST_UPDATED
Rancangan Kode
4. Nama File Media Isi Primary key Struktur
VARCHAR VARCHAR VARCHAR VARCHAR CHAR VARCHAR DATE TIMESTAMP
Ukuran 6 80 6 6 1 255
Keterangan Kode Kecamatan Nama Kecamatan Nama Kabupaten/Kota Nama Provinsi 1 = Aktif, 0 Non Aktif Tanggal input Update terakhir
: format untuk kode kecamatan adalah xxxxxxxx, dimana dua digit ketiga merupakan kode dari kecamatan, dua digit kedua merupakan kode kabupaten/kota : : : : :
Tahun harddisk data-data tahun anggaran, ikk dan biaya tahun_id lihat tabel
Tabel 3. 26 Struktur Basis Data Tabel Tahun No 1. 2. 3. 4. 5.
Nama Field
Tipe Data
TAHUN_ID TAHUN_ANGGARAN BIAYA_FISIK BIAYA_MEUBELAIR PERCEN_MANAJEMEN
Rancangan Kode
VARCHAR VARCHAR INTEGER INTEGER DECIMAL(6,2)
Ukuran
Keterangan
4 9 11 11 6
Kode tahun Tahun anggaran Biaya Fisik Biaya Meubelair % Biaya Manajemen dari Biaya Fisik
: format untuk kode kecamatan merupakan kode tahun anggaran
adalah
xxxx,
95 5. Nama File Media Isi Primary key Foreign key Struktur
: : : : : :
Ref_Sekolah harddisk data-data detail sekolah sebagai referensi npsn kecamatan_id, kabkota_id, provinsi_id lihat tabel
Tabel 3. 27 Struktur Basis Data Tabel Ref_Sekolah No
Nama Field
Tipe Data dan Ukuran
1.
NPSN
VARCHAR(8)
2. 3. 4. 5. 6.
NAMASD ALAMAT KELURAHAN KECAMATAN_ID KABKOTA_ID
VARCHAR(70) VARCHAR(90) VARCHAR(40) VARCHAR(6) VARCHAR(6)
7. 8. 9. 10. 11. 12.
PROVINSI_ID STATUS JENJANG CREATED_ON LAST_UPDATED KODE_POS
VARCHAR(6) ENUM('NEGERI','SWASTA') ENUM('SMP','SD') DATETIME TIMESTAMP VARCHAR(10)
Rancangan Kode
Keterangan Nomor Statistik Sekolah Nama Sekolah Alamat Sekolah Kelurahan Kode Kecamatan Status Sekolah = Negeri, Swasta Kode Provinsi
: format untuk kode kecamatan adalah xxxxxxxx, dimana 8 digit tersebut merupakan kode sekolah
6. Nama File Media Isi Primary key Foreign key Struktur
: : : : : :
User harddisk data-data user yang menggunakan aplikasi iduser role_id lihat tabel
Tabel 3. 28 Struktur Basis Data Tabel User No 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Nama Field IDUSER NAMA STATUS USERNAME PASSWORD ROLE_ID TELEPON EMAIL CREATED_ON LAST_UPDATED
Rancangan Kode
Tipe Data VARCHAR(12) VARCHAR(25) VARCHAR(12) VARCHAR(60) VARCHAR(25) CHAR(4) VARCHAR(20) VARCHAR(60) DATE TIMESTAMP
Keterangan Kode User Nama User 1 = Aktif; 0 = Non Aktif Username yang digunakan login sistem Password user Kode peran user
Tanggal insert Update terakhir
: format untuk id user adalah USR-xxx dua digit pertama merupakan prefik user dan tiga digit kedua merupakan nomor urut user.
96
7. Nama File Media Isi Primary key Struktur
: : : : :
role harddisk data peran user dalam aplikasi role_id lihat tabel
Tabel 3. 29 Struktur Basis Data Tabel Role No 1. 2. 3.
Nama Field
Tipe Data
ROLE_ID ROLE_NAMA CREATED_ON
Rancangan Kode
8. Nama File Media Isi Primary key Struktur
Ukuran
CHAR VARCHAR DATE
Keterangan
4 20
Kode peran Nama Peran Tanggal insert
: format untuk role adalah x merupakan nomor urut kode peran. : : : : :
ref_spr harddisk data-data surat pemberitahuan retur nomor_retur lihat tabel
Tabel 3. 30 Struktur Basis Data Tabel Ref_SPR No 1. 2. 3. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Nama Field SPR_KODE NOMOR_SPR TANGGAL_SPR NOMOR_SP2D NOMOR_REKENING ATAS_NAMA_REKENING BANK_RETUR DANA ALASAN_RETUR NOMOR_RSPP STATUS_PROSES CREATED_ON
Rancangan Kode
Contoh
Tipe Data VARCHAR(12) VARCHAR(25) DATE VARCHAR(25) VARCHAR(30) VARCHAR(40) VARCHAR(50) INT(11) VARCHAR(100) VARCHAR(14) ENUM('0','1') DATE
Nomor Referensi SPR Format yyyy-MM-dd
: format kode nomor_retur adalah xxxx-xxx-xxxxxx dengan penjelasan bahwa tiga digit pertama merupakan prefix, empat digit kedua pertama adalah tahun anggaran, empat digit terakhir adalah nomor urut detail surat pemberitahuan retur. : SPR-2014-0001
3.3.9.2. Tabel Transaksi 1. Nama File
Keterangan
: usulan_bantuan
97 Media Isi Primary key Foreign key Struktur
: : : : :
harddisk data-data usulan sekolah usulan_key usulan_npsn, iduser lihat tabel
Tabel 3. 31 Struktur Basis Data Tabel Usulan_Bantuan No
Nama Field
Tipe Data/Ukuran
1. 2. 3. 4. 5. 6.
USULAN_KEY USULAN_NPSN USULAN_JML_ROMBEL USULAN_JML_SISWA USULAN_JML_RK USULAN_RK_SEDANG
VARCHAR(14) VARCHAR(8) INT(4) INT(4) INT(4) INT(4)
7.
USULAN_RK_BERAT
INT(4)
8. 9.
USULAN_TAHUN USULAN_TGL_INPUT
VARCHAR(4) DATE
10. 11. 12. 13. 14. 15.
USULAN_NODISPOSISI USULAN_KORESPONDEN IDUSER STATUS_VERIFIKASI LAST_UPDATED SOFT_DELETED
VARCHAR(50) VARCHAR(50) VARCHAR(12) ENUM('0','1') TIMESTAMP ENUM('0','1')
Rancangan Kode
Keterangan Kode Usulan NPSN Sekolah Jumlah Rombongan Belajar Jumlah Siswa Jumlah Ruang Kelas Jumlah Usulan Ruang Kelas Rusak Sedang Jumlah Usulan Ruang Kelas Rusak Berat Nomor Disposisi Nama dan Telepon Korespondensi
1 = Sudah 0 = Belum
: format kode usulan key adalah xx-xxxxxxxxx dengan penjelasan bahwa dua digit pertama adalah prefik usulan (US) empat digit kedua berisi tahun dan empat digit terakhir adalah nomor urut usulan. : US-201400001
Contoh
2. Nama File
: verifikasi
Media Isi Primary key Struktur
: : : :
harddisk data-data verifikasi terhadap usulan verifikasi lihat tabel
Tabel 3. 32 Struktur Basis Data Verifikasi No 1. 2. 3. 4. 5. 6.
Nama Field VERIFIKASI_KODE USULAN_KEY NAMA_KEPSEK NIP_KEPSEK TELEPON_KEPSEK JML_SISWA
Tipe Data VARCHAR(40) VARCHAR(28) VARCHAR(30) INT(4) INT(4) INT(3)
Keterangan Kode Verifikasi Kode Usulan
Jumlah Siswa
98
No
Nama Field
Tipe Data
Keterangan
7. 8. 9.
JML_ROMBEL JML_RK RK_RUSAK
10.
RERATA_RUSAK
INT(3) DOUBLE(6,2) ENUM('RINGAN', 'SEDANG', 'BERAT') INT(12)
11. 12. 13. 14. 15. 16. 17.
KRITERIA_RUSAK BIAYA_REHABILITASI NOMOR_REKENING AN_REKENING NAMA_BANK BANK_ID STATUS_SK
VARCHAR(30) VARCHAR(50) VARCHAR(60) ENUM('0','1') ENUM('0','1') VARCHAR(4) ENUM('0','1')
18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28.
JENIS_PEMBIAYAAN BEA_FISIK BEA_MEUBELAIR BEA_MANAJAMEN TAHUN MASALAH PENYELESAIAN NO_SURAT_TUGAS_KEPSEK TGL_SURAT_TUGAS_KEPSEK CREATED_ON LAST_UPDATED
ENUM('0','1') INT(11) INT(11) INT(11) TIMESTAMP VARCHAR(255) VARCAHR(255) VARCHAR(30) VARCHAR(12) DATE VARCHAR(40)
Rancangan Kode
Jumlah Rombongan Belajar Jumlah Ruang Kelas Jumlah Ruang Kelas Rusak Rata-rata tingkat kerusakan ruang kelas rusak Biaya rehabilitasi Nomor rekening sekolah Atas nama rekening sekolah Status 1: sudah sk, 0: belum sk Status 1: sudah Mou, 0: belum Mou Status 1: Persentase, 0: Paket
: format kode verifikasi_kode adalah xx-xxxxxxxxx dengan penjelasan bahwa dua digit pertama adalah prefik usulan (VR) empat digit kedua berisi tahun dan empat digit terakhir adalah nomor urut verifikasi. : VR-201400001
Contoh
3. Nama File
: detail_sk
Media Isi Primary key Organisasi Ukuran Struktur
: : : : : :
harddisk data-data lampiran sk usulan_key Squential 42 byte lihat tabel
Tabel 3. 33 Struktur Basis Data Detail_SK No 1. 2. 3. 4. 5. 6. 8.
Nama Field NOMOR_RSK VERIFIKASI_KODE GROUP_LAMPIRAN NOMOR_SK TANGGAL_SK STATUS_SPPB CREATED_ON
Tipe Data VARCHAR(12) VARCHAR(12) VARCHAR(12) VARCHAR(25) DATE ENUM('0','1') DATE
Keterangan Nomor Urut Rencana Lampiran SK Kode Verifikasi Nomor Group Rencana Lampiran SK Nomor SK Status 0=belum, 1 = sudah
99 Rancangan Kode Kode Nomor RSK
: format kode nomor rencana SK terdiri dari 12 digit (xxxxxxxxxxxxx) dengan penjelasan bahwa empat digit pertama adalah tahun anggaran, tiga digit merupakan infix dari rencana lampiran ska berisi kode RSK dan lima digit terakhir adalah nomor urut lampiran SK. Contoh : 2014RSK00001 Kode Group Lampiran : terdiri dari 10 digit dengan rancangan kode x.xxxxxxx dimana satu digit pertama merupakan prefix, empat digit kedua merupakan tahun anggaran, dan tiga digit terakhir merupakan nomor urut group rencana lampiran SK. Contoh : G.2014-001 4. Nama File
: detail_sppb
Media Isi Primary key Foreign key Struktur
: : : : :
harddisk data-data nomor sppb nomor_sppb nomor_rsk lihat tabel
Tabel 3. 34 Struktur Basis Data Detail_SPPB No
Nama Field
1. 2. 3. 4. 5. 6.
NOMOR_SPPB TANGGAL_SPPB NOMOR_RSK STATUS_SPP JANGKA_WAKTU CREATED_ON
Rancangan Kode
Contoh 5. Nama File Media Isi Primary key Foreign key Struktur
Tipe Data VARCHAR(14) DATE VARCHAR(12) ENUM('0','1') INT(3) DATE
Keterangan Nomor Surat Perjanjian
1 = sudah 2 = belum Tanggal insert
: format kode nomor_sppb adalah xxxxxxxxxxxx dimana empat digit pertama merupakan 4 digit pertama merupakan prefix, empat digit kedua merupakan tahun anggaran dan 6 digit terakhir merupakan nomor urut SPPB : SPPB2014000001 : detail_spp : : : : :
harddisk data-data detail pengajuan pencairan dana nomor_rspp nomor sppb lihat tabel
Tabel 3. 35 Struktur Basis Data Tabel Detail_SPP No
Nama Field
Tipe Data
Keterangan
100 1. 2. 3.
NOMOR_RSPP TANGGAL_RSPP GROUP_RSPP
VARCHAR(14) DATE VARCHAR(12)
4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
NOMOR_SPPB NOMOR_SPP TANGGAL_SPP NOMOR_SPM TANGGAL_SPM NOMOR_SP2D STATUS_RETUR TANGGAL_SP2D TANGGAL_DANA_MASUK TANGGAL_LAPORAN_DITERIMA LAST_UPDATED
VARCHAR(25) VARCHAR(25) DATE VARCHAR(25) DATE VARCHAR(25) ENUM('0','1') DATE DATE DATE TIMESTAMP
Rancangan Kode
Contoh
6. Nama File
Nomor Rencana SPP Nomor Group Rencana SPP
: format kode nomor_rspp adalah xxxxxxx-xxxxxxx dengan penjelasan bahwa empat digit pertama adalah tahun anggaran, tiga digit merupakan infix dari rencana lampiran ska berisi kode SPP dan enam digit terakhir adalah nomor urut detail spp. : 2014SPP-000001
: detail_retur
Media Isi Primary key Foreign key Struktur
: : : : :
harddisk data-data pengajuan retur nomor_retur spr_kode lihat tabel
Tabel 3. 36 Struktur Basis Data Tabel Detail_Retur No
Nama Field
Tipe Data
1.
NOMOR_RETUR
VARCHAR(12)
2.
SPR_KODE
VARCHAR(12)
3. 4. 5. 6. 7.
BANK_REVISI REK_REVISI AN_REVISI CREATED_ON GROUP_PENGAJUAN
VARCHAR(50) VARCHAR(50) VARCHAR(50) DATE VARCHAR(12)
8. 9.
NOMOR_TU TANGGAL_NOMOR_TU
VARCHAR(25) DATE
Rancangan Kode
Contoh
Keterangan Nomor Pengajuan Retur Nomor Referensi SPR
Nomor Group pengajuan retru
: format kode pengajuan retur terdiri dari 12 digit dengan fomat xxxx.xxxx-xxx dengan penjelasan bahwa empat digit pertama prefix, 4 digit kedua merupakan tahun anggaran dan 3 digit berikutnya merupakan nomor urut. : GSPR.2014-001
101
3.3.9.
Squence Diagram Dalam perancangan sistem administrasi pengelolaan bantuan sekolah dasar
interaksi aktor dengan aplikasi digambarkan dengan menggunakan squence diagram dimana penggambarannya menggunakan model. Untuk beberapa squence seperti tambah IKK, update dan hapus ikk digambarkan sedikit lebih rinci dengan melibatkan kelas DAO, selebihnya penggambaran squence diagram hanya melibatkan aktor dan aplikasi sebagai obyek dan pesan-pesan diantara keduanya. Rancangan detail ineteraksi ini selanjutnya akan diimplementasikan dalam tahap pemrograman. 3.3.9.1.
Squence Diagram Use Case Mengelola Referensi
Pengelolaan data master terdiri atas referensi Sekolah, referensi IKK, referensi tahun biaya, referensi surat pemberitahuan retur dan user. Dalam squence diagram ini ini hanya digambarkan referensi IKK dan referensi sekolah yang cukup mewakili sequence urutan perilaku aplikasi untuk referensi tahun biaya dan referensi surat pemberitahuan retur.
3.3.9.1.1.
Squence Diagram Referensi Sekolah
3.3.9.1.1.1. Squence Diagram Tambah Sekolah
Gambar 3. 27 Squence Diagram Tambah Sekolah
102 3.3.9.1.1.2. Squence Diagram Update Sekolah
Gambar 3. 28 Squence Diagram Tambah Sekolah
3.3.9.1.1.3. Squence Diagram Hapus Sekolah
Gambar 3. 29 Squence Diagram Hapus Sekolah
103 3.3.9.1.1.4. Squence Diagram Cari Sekolah
Gambar 3. 30 Squence Diagram Cari Sekolah
3.3.9.1.2. 3.3.9.1.2.1.
Squence Diagram Referensi IKK Squence Diagram Tambah IKK
Gambar 3. 31 Squence Diagram Tambah IKK
104
3.3.9.1.2.2.
Squence Diagram Update IKK
Gambar 3. 32 Squence Diagram Ubah IKK 3.3.9.1.3.
Squence Diagram Referensi Tahun
3.3.9.1.3.1. Squence Diagram Tambah Tahun
Gambar 3. 33 Squence Diagram Tambah tahun
105 3.3.9.1.3.2.
Squence Diagram Update Tahun
Gambar 3. 34 Squence Diagram Update tahun 3.3.9.1.4.
Squence Diagram Manipulasi User
Gambar 3. 35 Squence Diagram Manipulasi User
106 3.3.9.2.
Squence Diagram Use Case Mengelola Usulan
3.3.9.2.1. Squence Diagram Tambah Usulan
Gambar 3. 36 Squence Diagram Tambah Usulan 3.3.9.2.2. Squence Diagram Ubah Usulan
Gambar 3. 37 Squence Diagram Ubah Usulan 3.3.9.2.3. Squence Diagram Hapus Usulan
Gambar 3. 38 Squence Diagram Hapus Usulan
107 3.3.9.2.4. Squence Diagram Cari Usulan
Gambar 3. 39 Squence Diagram Cari Usulan
3.3.9.3.
Squence Diagram Use Case Mengelola Verifikasi
3.3.9.3.1. Squence Diagram Tambah Verifikasi
Gambar 3. 40 Squence Diagram Tambah Verifikasi
108 3.3.9.3.2. Ubah Verifikasi
Gambar 3. 41 Squence Diagram Ubah Verifikasi
3.3.9.3.3. Squence Diagram Hapus Verifikasi
Gambar 3. 42 Squence Diagram Hapus Verifikasi
109
3.3.9.3.4. Cari Verifikasi
Gambar 3. 43 Squence Diagram Cari Verifikasi 3.3.9.4.
Squence Diagram Use Case Membuat Lampiran SK
3.3.9.4.1. Squence Diagram Menambah Rencana SK
Gambar 3. 44 Squence Diagram Membuat Pengajuan Rencana SK 3.3.9.4.2. Squence Diagram Delete Lampiran Rencana SK
Gambar 3. 45 Squence Diagram Delete Lampiran Rencana SK
110 3.3.9.4.3. Squence Diagram Update Nomor SK
Gambar 3. 46 Squence Diagram Update Nomor SK
3.3.9.5.
Squence Diagram Use Case Membuat Nomor SPPB
3.3.9.5.1. Squence Diagram Save SPPB
Gambar 3. 47 Squence Diagram Insert SPPB 3.3.9.5.2. Squence Diagram Delete SPPB
Gambar 3. 48 Squence Diagram Delete SPPB
111 3.3.9.5.3. Squence Diagram Ekspor Detil Nomor SPPB
Gambar 3. 49 Squence Diagram Ekspor Detail SPPB 3.3.9.6.
Squence Diagram Use Case Membuat Lampiran SPP
3.3.9.6.1. Squence Diagram Tambah Lampiran SPP
Gambar 3. 50 Squence Diagram Tambah Lampiran SPP 3.3.9.6.2. Squence Diagram Hapus Lampiran SPP
Gambar 3. 51 Squence Diagram Hapus Lampiran SPP
112 3.3.9.6.3. Squence Diagram Cetak Lampiran SPP
Gambar 3. 52 Squence Diagram Cetak Lampiran SPP 3.3.9.7.
Squence Diagram Use Case Lampiran Pengajuan Retur
Gambar 3. 53 Squence Diagram Manipulasi Data Pengajuan Retur 3.3.9.8.
Squence Diagram Use Case Mengelola Laporan
Gambar 3. 54 Squence Diagram Manipulasi Data Laporan Sekolah
113
Gambar 3. 55 Squence Diagram Cetak Laporan
3.3.10. Perancangan Antarmuka Analisis perancangan
antarmuka (interface) dalam sistem aplikasi
pengelolaan bantuan rehab ini meliputi:
perancangan struktur menu utama,
perancangan frame-frame input, perancangan keluaran. Perancangan antarmuka dimaksudkan agar mendapatkan gambaran jelas tentang bagaimana tampilan aplikasi, sehingga pada saat implementasi dalam tahap pemrograman dapat dilakukan dengan efektif. 3..3.10.1. Struktur Menu Utama Struktur menu dalam perancangan Aplikasi Administrasi Pengelolaan Bantuan Rehabilitasi Ruang Kelas di Direktorat Pembinaan SD terdapat empat menu utama
yaitu menu file, menu referensi, menu administrasi dan menu
laporan. Menu-menu tersebut berfungsi untuk media interaksi antara user dengan aplikasi dalam pengelolaan database master dan transaksi seperti gambar berikut:
114
Aplikasi SPAB Login
File
Referensi
Administrasi
Laporan
Logout
Referensi Sekolah
Administrasi Usulan
Rekapitulasi Usulan
Login
Referensi IKK
Administrasi Verifikasi
Rekapitulasi Realisasi
Exit
Referensi Tahun Biaya
Proses SK
Referensi SPR
Proses SPPB
User
Proses SPP
Rekapitulasi Retur
Administrasi Retur
Administrasi Laporan Sekolah
Gambar 3. 56 Struktur Menu Aplikasi
3..3.10.2. Perancangan Input 3.3.10.2.1. Rancangan Form Login
Gambar 3. 57 Rancangan Dialog Login
115 3.3.10.2.2. Perancangan Form Referensi 3.3.10.2.2.1. Form Referensi Sekolah
Gambar 3. 58 Rancangan Frame Referensi Sekolah
3.3.10.2.2.2. Dialog Pencarian Sekolah
Gambar 3. 59 Rancangan Dialog Pencarian Referensi Sekolah
116 3.3.10.2.2.3. Form Referensi IKK
Gambar 3. 60 Rancangan Frame Referensi IKK
3.3.10.2.2.4. Form Referensi SPR
Gambar 3. 61 Rancangan Frame Referensi SPR
117 3.3.10.2.2.5. Form Referensi Tahun Biaya
Gambar 3. 62 Rancangan Frame Referensi Tahun Satuan Biaya
3.3.10.2.2.6. Form User
118 Gambar 3. 63 Rancangan Frame User
3.3.10.2.3. Perancangan Form Administrasi 3.3.10.2.3.1. Perancangan Frame Administrasi Usulan
Gambar 3. 64 Rancangan Frame Usulan Bantuan
3.3.10.2.2.7. Dialog Pencarian Sekolah Usulan
Gambar 3. 65 Rancangan Dialog Pencarian Usulan
119 3.3.10.2.2.8. Form Administrasi Verifikasi
Gambar 3. 66 Rancangan Frame Administrasi Verifikasi
3.3.10.2.2.9. Dialog Pencarian Verifikasi
Gambar 3. 67 Rancangan Dialog Pencarian Verifikasi
120 3.3.10.2.2.10. Form Administrasi Proses SK
Gambar 3. 68 Rancangan Frame Proses SK
3.3.10.2.2.11. Dialog Pencarian untuk Proses SK
Gambar 3. 69 Rancangan Dialog Pencarian Data Verifikasi
121 3.3.10.2.2.12. Frame Administrasi Proses SPPB
Gambar 3. 70 Rancangan Frame Proses SPPB
3.3.10.2.2.13. Dialog Pencairan Lampiran RSK
Gambar 3. 71 Rancangan Dialog Pencarian Lampiran SK
3.3.10.2.2.14. Form Administrasi SPP
Gambar 3. 72 Rancangan Frame Administrasi SPP
122 3.3.10.2.2.15. Dialog Pencarian SPPB
Gambar 3. 73 Rancangan Dialog Pencarian SPPB
3.3.10.2.2.16. From Administrasi Proses Retur
Gambar 3. 74 Rancangan Frame Administrasi Proses Retur
123 3.3.10.2.2.17. Rancangan Dialog Pencarian RSPP
Gambar 3. 75 Rancangan Dialog Pencairan RSPP
3.3.10.2.2.18. Rancangan Dialog Pencarian SPR
Gambar 3. 76 Rancangan Dialog Pencarian SPR
3.3.10.2.2.19. Form Rekapitulasi
Gambar 3. 77 Rancangan Frame Cetak Laporan
124 3..3.10.3. Perancangan Output 3.3.9.1.5.
Rancangan Output Rekapitulasi Usulan Per Provinsi
Gambar 3. 78 Rancangan Laporan Usulan Per Provinsi
3.3.9.1.6.
Racangan Rekapitulasi Usulan Per Kabupaten/Kota
Gambar 3. 79 Rancangan Laporan Usulan Per Kabupaten/Kota
3.3.9.1.7.
Rancangan Laporan Detail Usulan
Gambar 3. 80 Rancangan Laporan Detail Usulan
125 3.3.9.1.8.
Rancangan Output Laporan Verifikasi
Gambar 3. 81 Rancangan Laporan Verifikasi
3.3.9.1.9.
Rancangan Lampiran SK
Gambar 3. 82 Rancangan Lampiran SK
3.3.9.1.10.
Rancangan Lampiran SPP
Gambar 3. 83 Rancangan Lampiran SPP
126 3.3.9.1.11.
Rancangan Laporan Detail Penyaluran Dana
Gambar 3. 84 Rancangan Laporan Detail Penyaluran
3.3.9.1.12.
Rancangan Laporan Retur
Gambar 3. 85 Rancangan Laporan Retur