160 Perencanaan strategis penerimaan siswa dan mahasiswa baru. · PDF filePengelolaan pendaftaran calon siswa dan mahasiswa baru. a. Unit organisasi yang bertanggung jawab penuh dan
Post on 03-Mar-2018
220 Views
Preview:
Transcript
160
1. Perencanaan strategis penerimaan siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Pembantu Direktur
II, Pembantu Direktur III.
2. Pembentukan panitia penerimaan siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Pembantu Direktur II, Kepala Bagian Keuangan, Kabag
Perlengkapan dan Kerumahtanggaan, Pembantu Direktur III, Kepala Bagian
Kemahasiswaan, Ketua Organisasi Kemahasiswaan, Kepala Bagian
Marketing.
3. Penetapan anggaran penerimaan siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur III.
4. Penjadwalan kegiatan penerimaan siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik, Pembantu Direktur II, Pembantu Direktur III.
5. Penentuan standarisasi penerimaan siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
161
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur II.
6. Penyusunan materi ujian seleksi penerimaan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Kepala Bagian Administrasi Akademik.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Umum.
7. Pengelolaan pendaftaran calon siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Kepala Bagian Administrasi Umum.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur II, Pembantu Direktur III.
8. Pengelolaan pembayaran administrasi penerimaan calon siswa dan mahasiswa
baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
9. Pelaksanaan Ujian Saringan Masuk (USM) seleksi calon mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Kepala Bagian Administrasi Akademik.
162
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kabag
Perlengkapan dan Kerumahtanggaan.
10. Penilaian hasil Ujian Saringan Masuk (USM) seleksi calon mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Ketua Program Studi.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Akademik.
11. Penentuan kelulusan hasil Ujian Saringan Masuk (USM) seleksi calon
mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Kepala Bagian Administrasi Akademik.
12. Pengumuman hasil Ujian Saringan Masuk (USM) seleksi calon mahasiswa
baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Ketua Program Studi.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Akademik.
13. Registrasi ulang siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Ketua Program Studi, Koordinator Jurusan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Akademik, Kepala Bagian Keuangan.
14. Pengukuran seragam, unit organisasi yang terlibat sepenuhnya dalam proses
adalah Kepala Bagian Administrasi Umum.
15. Outsourcing penjahitan seragam.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Ketua Program Studi, Koordinator Jurusan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Umum, Kepala Bagian Keuangan.
16. Pembagian seragam.
163
a. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Umum.
b. Unit organisasi yang terlibat sebagian dalam proses adalah Kabag
Perlengkapan dan Kerumahtanggaan.
17. Pelaksanaan orientasi studi dan pengenalan kampus.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kabag
Perlengkapan dan Kerumahtanggaan, Kepala Bagian Kemahasiswaan,
Ketua Organisasi Kemahasiswaan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Umum, Kepala Bagian Marketing.
18. Pelaporan dan evaluasi siswa dan mahasiswa baru.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Kepala Bagian
Administrasi Akademik, Pembantu Direktur II, Kepala Bagian Keuangan,
Kabag Perlengkapan dan Kerumahtanggaan, Pembantu Direktur III,
Kepala Bagian Kemahasiswaan, Ketua Organisasi Kemahasiswaan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Marketing.
19. Perencanaan strategis kurikulum dan kebijakan akademik.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur II, Pembantu Direktur III.
20. Penetapan kurikulum.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
164
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
21. Penentuan dosen-dosen pengajar dan wali akademik.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
22. Pembuatan Surat Keputusan dosen-dosen pengajar dan wali akademik.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik.
23. Rapat dosen dan wali akademik.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Pembantu Direktur II, Pembantu
Direktur III.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik, Kepala Bagian Administrasi Umum, Kepala
Bagian Keuangan.
24. Penetapan kalender akademik.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
165
c. Unit organisasi yang terlibat sebagian dalam proses adalah Bagian
Administasi Akademik.
25. Pengelolaan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Kemahasiswaan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik, Kepala Bagian Administrasi Umum.
26. Pelaksanaan perwalian (program D-3).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
27. Pengelolaan Perubahan Rencana Studi/PRS (program D-3).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Bagian
Administasi Akademik.
28. Pembuatan jadwal Kegiatan Belajar Mengajar (KBM).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Bagian
Administasi Akademik.
166
29. Pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM) unit organisasi
yang terlibat sepenuhnya dalam proses adalah Kepala Bagian Administrasi
Akademik.
30. Pengawasan Kegiatan Belajar Mengajar (KBM).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
31. Pembentukan panitia ujian (UTS, UAS, komprehensif).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Pembantu Direktur II, Kepala Bagian Administrasi Umum,
Kepala Bagian Keuangan, Kabag Perlengkapan dan Kerumahtanggaan,
Pembantu Direktur III, Kepala Bagian Kemahasiswaan.
32. Pembuatan jadwal ujian (UTS, UAS, komprehensif).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
33. Pembuatan daftar hadir (UTS, UAS, komprehensif) unit organisasi yang
terlibat sepenuhnya dalam proses adalah Kepala Bagian Administrasi
Akademik.
34. Pengawasan ujian (UTS, UAS, komprehensif).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Kemahasiswaan.
167
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur III.
35. Penyerahan berkas jawaban ujian siswa dan mahasiswa ke dosen yang
bersangkutan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
36. Penerimaan berkas nilai dari dosen.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
37. Pemrosesan nilai di komputer.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
38. Pencetakan Kartu Hasil Studi (KHS).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik.
39. Pelaporan dan evaluasi kegiatan akademik.
168
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
40. Perencanaan dan kebijakan wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Pembantu Direktur
I.
41. Penetapan nama-nama panitia.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Pembantu Direktur I.
42. Penerbitan Surat Keputusan panitia wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Pembantu Direktur
II.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Administrasi Akademik.
43. Rapat panitia wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Pembantu Direktur II, Kepala Bagian Administrasi Umum,
Kepala Bagian Keuangan, Kabag Perlengkapan dan Kerumahtanggaan,
169
Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Kepala Bagian
Marketing.
44. Penetapan anggaran wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur III.
45. Penetapan standar kelulusan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan.
46. Pembuatan ijazah, sertifikat dan transkrip nilai.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala
Bagian Administrasi Umum, Pembantu Direktur III, Kepala Bagian
Kemahasiswaan.
47. Pelaksanaan wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Pembantu Direktur II, Kepala Bagian Administrasi Umum,
Kepala Bagian Keuangan, Kabag Perlengkapan dan Kerumahtanggaan,
Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi
Kemahasiswaan, Kepala Bagian Marketing.
170
48. Pelaporan dan evaluasi kegiatan wisuda.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi
Akademik, Pembantu Direktur II, Kepala Bagian Administrasi Umum,
Kepala Bagian Keuangan, Kabag Perlengkapan dan Kerumahtanggaan,
Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi
Kemahasiswaan, Kepala Bagian Marketing.
49. Perencanaan dan kebijakan promosi.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Pembantu Direktur II, Pembantu Direktur III, Kepala Bagian
Marketing.
50. Pembentukan panitia promosi dan One Stop Service (OSS).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Kepala Bagian
Administrasi Akademik, Pembantu Direktur II, Kepala Bagian
Administrasi Umum, Kepala Bagian Keuangan, Kabag Perlengkapan dan
Kerumahtanggaan, Pembantu Direktur III, Kepala Bagian
Kemahasiswaan, Kepala Bagian Marketing.
51. Penetapan anggaran promosi.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan, Kepala Bagian Marketing.
52. Penetapan metoda promosi.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
171
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Marketing.
53. Pelaksanaan promosi.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Marketing.
54. Pelaporan dan evaluasi kegiatan promosi.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Ketua Program Studi, Koordinator Jurusan, Kepala Bagian
Administrasi Akademik, Pembantu Direktur II, Kepala Bagian
Administrasi Umum, Kepala Bagian Keuangan, Kabag Perlengkapan dan
Kerumahtanggaan, Pembantu Direktur III, Kepala Bagian
Kemahasiswaan, Kepala Bagian Marketing.
55. Perencanaan dan kebijakan kerjasama.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur II.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur III.
56. Penetapan kebijakan kerjasama (link and match).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Umum.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur III.
57. Penetapan daftar nama dunia industri unit organisasi yang bertanggung jawab
penuh dan pembuat keputusan adalah Pembantu Direktur II.
172
58. Pelaksanaan kerjasama dengan dunia industri.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Administrasi Umum.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala
Bagian Marketing.
59. Pelaporan dan evaluasi kerjasama.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur II.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Kepala Bagian Administrasi Umum, Kepala Bagian
Marketing.
60. Perencanaan dan kebijakan pengelolaan ikatan keluarga alumni.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur III.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur II.
61. Penetapan kebijakan pengelolaan ikatan keluarga alumni.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Bursa Kerja dan Alumni.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Kemahasiswaan.
62. Pembentukan Ikatan Keluarga Alumni (IKA).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
173
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Bursa Kerja dan Alumni.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Kemahasiswaan.
63. Pengelolaan dan pemeliharaan Ikatan Keluarga Alumni (IKA).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Bursa Kerja dan Alumni.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Kemahasiswaan.
64. Pelaporan dan evaluasi pengelolaan Ikatan Keluarga Alumni (IKA).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur III, Bagian Bursa Kerja Khusus dan Alumni.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala Bagian
Kemahasiswaan.
65. Perencanaan dan kebijakan keuangan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur II.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur III.
66. Penetapan kebijakan keuangan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
67. Penetapan anggaran.
174
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
68. Penyusunan anggaran.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
69. Pengesahan anggaran.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
70. Revisi anggaran.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
71. Alokasi anggaran.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
72. Pengelolaan biaya pendidikan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
73. Pengelolaan honor dosen.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
175
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
74. Monitoring anggaran.
c. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II
d. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan.
75. Pelaporan dan evaluasi keuangan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Kepala Bagian Keuangan.
76. Perencanaan dan kebijakan pengelolaan Ketua Organisasi Kemahasiswaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur III.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur I, Pembantu Direktur II.
77. Penetapan kebijakan pengelolaan Ketua Organisasi Kemahasiswaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Kemahasiswaan, Ketua Organisasi Kemahasiswaan.
78. Pembentukan Ketua Organisasi Kemahasiswaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Kemahasiswaan, Ketua Organisasi Kemahasiswaan.
79. Pengelolaan dan pemeliharaan Ketua Organisasi Kemahasiswaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur III.
176
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Kemahasiswaan, Ketua Organisasi Kemahasiswaan.
80. Pelaporan dan evaluasi pengelolaan Ketua Organisasi Kemahasiswaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi
Kemahasiswaan.
81. Perencanaan dan kebijakan pengelolaan pengembangan perpustakaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I.
c. Unit organisasi yang terlibat sebagian dalam proses adalah Pembantu
Direktur II.
82. Penetapan kebijakan pengembangan perpustakaan.
a. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I
b. Unit organisasi yang terlibat sebagian dalam proses adalah Perpustakaan.
83. Penetapan kebijakan pengelolaan perpustakaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah
Perpustakaan.
84. Pengadaan buku.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Ketua
Program Studi, Koordinator Jurusan, Kepala Bagian Administrasi Umum,
Kepala Bagian Keuangan, Perpustakaan.
85. Pengelolaan perpustakaan, unit organisasi yang terlibat sepenuhnya dalam
proses adalah Perpustakaan.
177
86. Pemeliharaan perpustakaan, unit organisasi yang terlibat sepenuhnya dalam
proses adalah Perpustakaan.
87. Pengawasan pemanfaatan perpustakaan, unit organisasi yang terlibat
sepenuhnya dalam proses adalah Perpustakaan.
88. Pelaporan dan evaluasi pengelolaan perpustakaan.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah
Perpustakaan.
89. Perencanaan dan kebijakan kepegawaian.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Pembantu Direktur II.
90. Penetapan kebijakan dan aturan kepegawaian (bagi staf, dosen luar biasa,
dosen tetap dan pejabat struktural).
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Bagian Kepegawaian.
91. Pengelolaan administrasi kepegawaian.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Kepegawaian.
92. Pengelolaan gaji dan honor.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala
Bagian Keuangan, Bagian Kepegawaian.
93. Pengembangan karir.
178
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Kepegawaian.
94. Pelaporan dan evaluasi kepegawaian.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian
Kepegawaian.
95. Perencanaan dan kebijakan pemanfaatan serta pengembangan teknologi
informasi dan utilitas laboratorium.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur I, Unit Pelaksana Teknis, Pembantu Direktur II.
96. Penetapan kebijakan dan aturan pemanfaatan serta pengembangan teknologi
informasi dan laboratorium.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Unit
Pelaksana Teknis.
97. Pengembangan teknologi informasi dan laboratorium, unit organisasi yang
terlibat sepenuhnya dalam proses adalah Unit Pelaksana Teknis.
98. Pengelolaan teknologi informasi dan laboratorium, unit organisasi yang
terlibat sepenuhnya dalam proses adalah Unit Pelaksana Teknis.
99. Pengawasan pemanfaatan teknologi informasi dan laboratorium, unit
organisasi yang terlibat sepenuhnya dalam proses adalah Unit Pelaksana
Teknis.
100. Pemeliharaan teknologi informasi dan laboratorium, unit organisasi yang
terlibat sepenuhnya dalam proses adalah Unit Pelaksana Teknis.
101. Pelaporan dan evaluasi pemanfaatan serta pengembangan teknologi informasi
dan laboratorium.
179
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur I.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Unit
Pelaksana Teknis.
102. Perencanaan dan kebijakan pemanfaatan serta pengembangan sarana dan
prasarana.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Direktur Pendidikan.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Pembantu
Direktur II.
103. Penetapan kebijakan pemanfaatan serta pengembangan sarana dan prasarana.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kabag
Perlengkapan dan Kerumahtanggaan.
104. Pengembangan sarana dan prasarana, unit organisasi yang terlibat sepenuhnya
dalam proses adalah Kabag Perlengkapan dan Kerumahtanggaan.
105. Pengadaan sarana dan prasarana, unit organisasi yang terlibat sepenuhnya
dalam proses adalah Kabag Perlengkapan dan Kerumahtanggaan.
106. Pengelolaan sarana dan prasarana, unit organisasi yang terlibat sepenuhnya
dalam proses adalah Kabag Perlengkapan dan Kerumahtanggaan.
107. Pengawasan pemanfaatan sarana dan prasarana, unit organisasi yang terlibat
sepenuhnya dalam proses adalah Kabag Perlengkapan dan Kerumahtanggaan.
108. Pemeliharaan sarana dan prasarana, unit organisasi yang terlibat sepenuhnya
dalam proses adalah Kabag Perlengkapan dan Kerumahtanggaan.
109. Pelaporan dan evaluasi pemanfaatan serta pengembangan sarana dan
prasarana.
a. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan
adalah Pembantu Direktur II.
b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kabag
Perlengkapan dan Kerumahtanggaan.
180
LAMPIRAN D (INFORMATION RESOURCE CATALOG)
Nama Aplikasi akademik LPP Nama Lengkap Aplikasi akademik unit LPP (Lembaga Pendidikan dan Pelatihan) Grup Aplikasi akademik Kategori Proses transaksi dan informasi Penanggung Jawab/Pengelola
Kepala Bagian Akademik Unit LPP
Unit Pengguna Akademik LPP Deskripsi Aplikasi ini digunakan untuk mengelola data dari fungsi akademik unit LPP.
Fungsi-fungsi yang disediakan oleh aplikasi diantaranya adalah pencatatan dan pengelolaan data siswa/i, dosen, kegiatan belajar mengajar, kegiatan ujian dan pengelolaan nilai.
Status Operational Operasional Lokasi Server Jenis Penggunaan Batch Waktu Penggunaan Jam kerja (Senin – Jumat : 07.00 – 17.00, Sabtu : 07.00 – 14.00) Mulai Implementasi (Aktif)
1999
Pengembang In house Perangkat Lunak Clipper 5.2, DOS Perangkat Keras PC Standar (Sekelas Pentium) Network LAN, RJ-45, UTP Cable, Windows Server 2000 Preceeding System Succeeding System Isu Jangka Panjang Integrasi dengan aplikasi keuangan akan memudahkan pemeriksaan kondisi
keuangan siswa/siswi. Keterangan
Nama Aplikasi keuangan LPP
Nama Lengkap Aplikasi keuangan unit LPP (Lembaga Pendidikan dan Pelatihan) Grup Aplikasi keuangan Kategori Proses transaksi dan informasi Penanggung Jawab/Pengelola
Kepala Kepala Bagian Keuangan Unit LPP
Unit Pengguna Keuangan LPP Deskripsi Aplikasi ini digunakan untuk mengelola data dari fungsi keuangan unit LPP.
Fungsi-fungsi yang disediakan oleh aplikasi diantaranya adalah pencatatan dan pengelolaan pembayaran biaya pendidikan siswa/i yang mengikuti kursus singkat dan perkuliahan selama satu tahun, pengelolaan pembayaran honor dosen, pengelolaan kas, pengelolaan piutang serta pembuatan laporan keuangan seperti arus kas dan buku besar.
Status Operational Operasional Lokasi Server Jenis Penggunaan Batch Waktu Penggunaan Jam kerja (Senin – Jumat : 07.00 – 17.00, Sabtu : 07.00 – 14.00) Mulai Implementasi (Aktif)
2006
Pengembang Jasa Sarana Informatika Perangkat Lunak Clipper 5.2, DOS Perangkat Keras PC Standar (Sekelas Pentium) Network LAN, RJ-45, UTP Cable, Windows Server 2000 Preceeding System Succeeding System Isu Jangka Panjang Integrasi dengan aplikasi akademik akan memudahkan pengelolaan karena
tidak perlu input data siswa/siswi secara berulang-ulang. Keterangan
181
Nama Aplikasi akademik ASM Nama Lengkap Aplikasi akademik unit ASM (Akademi Sekretari dan Manajemen) Grup Aplikasi akademik Kategori Proses transaksi dan informasi Penanggung Jawab/Pengelola
Kepala Bagian Akademik Unit ASM
Unit Pengguna Akademik ASM Deskripsi Aplikasi ini digunakan untuk mengelola data dari fungsi akademik unit ASM.
Fungsi-fungsi yang disediakan oleh aplikasi diantaranya adalah pencatatan dan pengelolaan data mahasiswa/i, dosen, kegiatan belajar mengajar, kegiatan ujian dan pengelolaan nilai.
Status Operational Operasional Lokasi Server Jenis Penggunaan Batch Waktu Penggunaan Jam kerja (Senin – Jumat : 07.00 – 17.00, Sabtu : 07.00 – 14.00) Mulai Implementasi (Aktif)
2005
Pengembang Grup IPTN Perangkat Lunak Visual Basic dan pengelola basis data/DBMS SQL Server 2000 Perangkat Keras PC Standar (Sekelas Pentium) Network LAN, RJ-45, UTP Cable, Windows Server 2000 Preceeding System Succeeding System Isu Jangka Panjang Integrasi dengan aplikasi keuangan akan memudahkan pemeriksaan kondisi
keuangan mahasiswa/mahasiswi. Keterangan
Nama Aplikasi keuangan ASM
Nama Lengkap Aplikasi keuangan unit ASM (Akademi Sekretari dan Manajemen) Grup Aplikasi keuangan Kategori Proses transaksi dan informasi Penanggung Jawab/Pengelola
Kepala Kepala Bagian Keuangan Unit ASM
Unit Pengguna Keuangan ASM Deskripsi Aplikasi ini digunakan untuk mengelola data dari fungsi keuangan unit ASM.
Fungsi-fungsi yang disediakan oleh aplikasi diantaranya adalah pencatatan dan pengelolaan pembayaran biaya pendidikan mahasiswa/i yang mengikuti perkuliahan selama tiga tahun, pengelolaan pembayaran honor dosen, pengelolaan kas, pengelolaan piutang serta pembuatan laporan keuangan seperti arus kas dan buku besar.
Status Operational Operasional Lokasi Server Jenis Penggunaan Batch Waktu Penggunaan Jam kerja (Senin – Jumat : 07.00 – 17.00, Sabtu : 07.00 – 14.00) Mulai Implementasi (Aktif)
2006
Pengembang Jasa Sarana Informatika Perangkat Lunak Clipper 5.2, DOS Perangkat Keras PC Standar (Sekelas Pentium) Network LAN, RJ-45, UTP Cable, Windows Server 2000 Preceeding System Succeeding System Isu Jangka Panjang Integrasi dengan aplikasi akademik akan memudahkan pengelolaan karena
tidak perlu input data mahasiswa/mahasiswi secara berulang-ulang. Keterangan
182
LAMPIRAN E (DESKRIPSI APLIKASI) Kelompok Aplikasi 1 Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
No. 1
Nama Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
Deskripsi Aplikasi ini untuk mengelola data pendaftar, administrasi
pengelolaan pembayaran, administrasi penerimaan calon
siswa/mahasiswa baru, pengelolaan USM dan pelaporan kegiatan
penerimaan siswa/mahasiswa baru.
Kelompok Aplikasi 1 Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
No. 1.1
Nama Sistem Pendaftaran Calon Siswa/Mahasiswa Baru
Deskripsi Aplikasi ini untuk mencatat dan mengelola data pendaftar calon
siswa/mahasiswa baru.
Kelompok Aplikasi 1 Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
No. 1.2
Nama Sistem Pengelolaan Pembayaran Pendaftaran
Deskripsi Aplikasi ini untuk mencatat dan mengelola pembayaran pendaftaran.
Kelompok Aplikasi 1 Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
No. 1.3
Nama Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa
baru
Deskripsi Aplikasi ini untuk mencatat dan mengelola Ujian
Saringan Masuk seleksi calon mahasiswa baru.
Kelompok Aplikasi 1 Sistem Informasi Penerimaan Siswa/Mahasiswa Baru
No. 1.4
Nama Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
Deskripsi Aplikasi ini untuk mengelola pelaporan kegiatan penerimaan
siswa/mahasiswa baru.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.1
Nama Sistem Registrasi Ulang Siswa/Mahasiswa
Deskripsi Aplikasi ini untuk mencatat dan mengelola registrasi ulang baik
siswa/mahasiswa baru maupun lama.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.2
Nama Sistem Pembuatan KRS, KTS dan KTM
Deskripsi Aplikasi ini untuk mengelola pembuatan KRS, KTS dan KTM.
183
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.3
Nama Sistem Perwalian
Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan perwalian.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.4
Nama Sistem Perubahan Rencana Studi
Deskripsi Aplikasi ini untuk mencatat dan mengelola Perubahan Rencana
Studi/PRS.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.5
Nama Sistem Penjadwalan KBM
Deskripsi Aplikasi ini untuk mencatat dan mengelola penjadwalan KBM.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.6
Nama Sistem Administrasi KBM
Deskripsi Aplikasi ini untuk mengelola administrasi KBM.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.7
Nama Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)
Deskripsi Aplikasi ini untuk mencatat dan mengelola penjadwalan ujian (UTS,
UAS, Sidang, Komprehensif).
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.8
Nama Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)
Deskripsi Aplikasi ini untuk mengelola administrasi ujian (UTS, UAS, Sidang,
Komprehensif).
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.9
Nama Sistem Pengelolaan Nilai
Deskripsi Aplikasi ini untuk mencatat dan mengelola nilai.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.10
Nama Sistem Pembuatan Kartu Hasil Studi
Deskripsi Aplikasi ini untuk mengelola pembuatan Kartu Hasil Studi.
184
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.11
Nama Sistem Administrasi Dosen
Deskripsi Aplikasi ini untuk mengelola administrasi dosen.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.12
Nama Sistem Manajemen Kurikulum
Deskripsi Aplikasi ini untuk mengelola kurikulum.
Kelompok Aplikasi 2 Sistem Informasi Akademik
No. 2.13
Nama Sistem Pelaporan Akademik
Deskripsi Aplikasi ini untuk mengelola pelaporan akademik baik untuk
kepentingan internal maupun eksternal (Kopertis).
Kelompok Aplikasi 3 Sistem Informasi Wisuda
No. 3.1
Nama Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai
Deskripsi Aplikasi ini untuk mengelola pembuatan ijazah, sertifikat dan
transkrip nilai.
Kelompok Aplikasi 3 Sistem Informasi Wisuda
No. 3.2
Nama Sistem Administrasi Wisuda
Deskripsi Aplikasi ini untuk mengelola administrasi wisuda.
Kelompok Aplikasi 3 Sistem Informasi Wisuda
No. 3.3
Nama Sistem Pelaporan Kegiatan Wisuda
Deskripsi Aplikasi ini untuk mengelola pelaporan kegiatan wisuda.
Kelompok Aplikasi 4 Sistem Informasi Promosi
No. 4.1
Nama Sistem Informasi Promosi
Deskripsi Aplikasi ini untuk mengelola kegiatan promosi.
Kelompok Aplikasi 4 Sistem Informasi Promosi
No. 4.2
Nama Sistem Pelaporan Kegiatan Promosi
Deskripsi Aplikasi ini untuk mengelola pelaporan kegiatan promosi.
185
Kelompok Aplikasi 5 Sistem Informasi Pengelolaan BKK dan IKA
No. 5.1
Nama Sistem Pengelolaan Dunia Industri
Deskripsi Aplikasi ini untuk mencatat dan mengelola daftar nama perusahaan.
Kelompok Aplikasi 5 Sistem Informasi Pengelolaan BKK dan IKA
No. 5.2
Nama Sistem Pengelolaan Kerjasama
Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan kerjasama
dengan dunia industri.
Kelompok Aplikasi 5 Sistem Informasi Pengelolaan BKK dan IKA
No. 5.3
Nama Sistem Pengelolaan Alumni
Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan alumni.
Kelompok Aplikasi 5 Sistem Informasi Pengelolaan BKK dan IKA
No. 5.4
Nama Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA
Deskripsi Aplikasi ini untuk mengelola pelaporan kegiatan BKK dan IKA.
Kelompok Aplikasi 6 Sistem Informasi Pengelolaan Keuangan
No. 6.1
Nama Sistem Pengelolaan Pembayaran Biaya Pendidikan dari
Siswa/Mahasiswa
Deskripsi Aplikasi ini untuk mencatat dan mengelola pembayaran biaya
pendidikan dari siswa/mahasiswa.
Kelompok Aplikasi 6 Sistem Informasi Pengelolaan Keuangan
No. 6.2
Nama Sistem Pengelolaan Honor Dosen
Deskripsi Aplikasi ini untuk mengelola pelaporan pembayaran honor dosen.
Kelompok Aplikasi 6 Sistem Informasi Pengelolaan Keuangan
No. 6.3
Nama Sistem Pengelolaan Pelaporan Keuangan
Deskripsi Aplikasi ini untuk mengelola pelaporan keuangan.
186
LAMPIRAN F (KATALOG DATA)
1. Basis Data Aplikasi Akademik LPP Tabel Name : Siswa
Field Name Type Length Description
nis Character 10
nmsis Character 25
tmp_lahir Character 10
tgl_lahir Date 8
kelamin Logical 1
alamat Character 25
kota Character 25
kodepos Character 5
telpon Character 25
2. Basis Data Aplikasi Akademik ASM Tabel Name : TmAsalInformasi
Field Name Type Length Description
c_asalinformasi Char 3 Not null
n_asalinformasi Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmBadanHukum
Field Name Type Length Description
c_badanhukum Char 7 Not null
n_badanhukum Varchar 50
d_tglberdiri Datetime 8
a_alamat Varchar 30
a_kota Varchar 20
a_kodepos Char 5
a_telpon Char 15
a_fax Char 15
a_email Varchar 50
a_website Varchar 50
i_noakta Varchar 30
d_tglakta Datetime 8
i_nopn Varchar 30
d_tglpn Datetime 8
i_entry Char 15
d_entry Datetime 8
187
Tabel Name : TmBioData
Field Name Type Length Description
C_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
n_mahasiswa Varchar 30
i_tmptlahir Varchar 20
d_tgllahir Datetime 8
i_agama Varchar 10
i_jeniskelamin Varchar 6
i_goldarah Varchar 2
a_alamatasal Varchar 30
a_tlpasal Varchar 15
a_alamat Varchar 30
a_tlp Varchar 15
i_sklhasalnm Varchar 30
i_sklhasalalmt Varchar 30
i_sklhasaltlp Varchar 15
i_hobi Varchar 30
i_olahraga Varchar 30
i_olahragaaktf Bit 1
i_kesenian Varchar 30
i_kesenianaktf Bit 1
i_pekerjaan Varchar 30
i_jabatan Varchar 30
i_pekerjaanalmt Varchar 30
i_statuskawin Varchar 15
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmBobotNilai
Field Name Type Length Description
c_grade Char 1 Not null
v_bobot Int 4
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmDosen
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_dosen Char 10 Not null
n_dosen Varchar 30
188
Tabel Name : TmDosen
Field Name Type Length Description
i_gelar Varchar 10
i_tmptlahir Varchar 20
d_tgllahir Datetime 8
i_agama Varchar 10
i_jeniskelamin Varchar 6
i_goldarah Varchar 2
a_alamat Varchar 30
a_kota Varchar 20
a_kodepos Char 5
a_telpon Varchar 15
a_handphone Varchar 15
a_email Varchar 40
i_nomorktp Varchar 25
c_jabatan Char 1
c_stsjabatan Char 1
c_pendidikan Char 1
n_sekolah Varchar 40
i_bidgilmu Varchar 40
i_akta Bit 1
i_ijin Bit 1
i_nip Varchar 10
c_ptinduk Char 6
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmImage
Field Name Type Length Description
c_image Char 10 Not null
g_image Image 16
c_statusprn Bit 1
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmJabatan
Field Name Type Length Description
c_jabatan Char 1 Not null
n_jabatan Varchar 30
i_entry Char 15
d_entry Datetime 8
189
Tabel Name : Tmjenjang
Field Name Type Length Description
c_jenjang Char 1 Not null
n_jenjang Varchar 10
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmJnsBayar
Field Name Type Length Description
i_pembayaran Char 30 Not null
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmJurusan
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_jurusan Char 2 Not null
n_jurusan Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmMahasiswa
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_jurusan Char 2 Not null
c_nim Char 15 Not null
n_mahasiswa Varchar 30
i_tmptlahir Varchar 20
d_tgllahir Datetime 8
i_agama Varchar 10
i_jeniskelamin Varchar 6
i_goldarah Varchar 2
i_almtorgtua Varchar 30
i_kotaorgtua Varchar 20
c_kdposorgtua Char 5
c_prporgtua Char 2
a_alamat Varchar 30
a_kota Varchar 20
a_kodepos Char 5
a_telpon Varchar 15
190
Tabel Name : TmMahasiswa
Field Name Type Length Description
a_handphone Varchar 15
a_email Varchar 40
i_tahunmasuk Char 4
i_btssemester Char 5
d_tglmasuk Datetime 8
c_stsmasuk Char 1
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmMataKuliah
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_matakuliah Char 10 Not null
c_semester Char 1
n_matakuliah Varchar 40
q_sks Int 4
q_pertemuan Int 4
q_praktek Int 4
q_prakteklpgn Int 4
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmMhsFRS
Field Name Type Length Description
c_thnsmstr Char 5 Not null
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
c_dosenwali Char 10
q_jmlsks Int 4
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmMhsFRSDtl
Field Name Type Length Description
c_thnsmstr Char 5 Not null
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
191
Tabel Name : TmMhsFRSDtl
Field Name Type Length Description
c_nim Char 15 Not null
c_dosen Char 10 Not null
c_matakuliah Char 10 Not null
c_kelas Char 2 Not null
c_dosenwali Char 10
q_jmlsks Int 4
v_absen Int 4
v_uts Numeric 5
v_uas Numeric 5
c_grade Char 1
i_entry Char 15
d_entry datetime 8
Tabel Name : TmOrangtua
Field Name Type Length Description
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
n_bapakotw Varchar 30
n_ibuotw Varchar 30
a_alamatotw Varchar 30
a_alamatotwtlp Varchar 15
i_kerjabotw Varchar 30
i_kerjabotwalmt Varchar 30
i_kerjabotwtlp Varchar 15
i_kerjaiotw Varchar 30
i_kerjaiotwalmt Varchar 30
i_kerjaiotwtlp Varchar 15
v_jmlsaudara Int 4
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmPejabat
Field Name Type Length Description
c_pejabat Char 5 Not null
i_jabatan Varchar 30
n_pejabat Varchar 50
i_entry Char 15
d_entry Datetime 8
192
Tabel Name : TmPerguruanTinggi
Field Name Type Length Description
c_badanhukum Char 7 Not null
c_perguruantgg Char 6 Not null
n_perguruantgg Varchar 50
d_tglberdiri Datetime 8
a_alamat Varchar 30
a_kota Varchar 20
a_kodepos Char 5
a_telepon Char 15
a_fax Char 15
a_email Varchar 50
a_website Varchar 50
i_nosk Varchar 30
d_tglsk Datetime 8
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmPerkuliahan
Field Name Type Length Description
c_thnsmstr Char 5 Not null
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_dosen Char 10 Not null
c_matakuliah Char 10 Not null
c_kelas Char 2 Not null
q_jmlpertemuan Int 4
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmPerkuliahanAbsn
Field Name Type Length Description
c_thnsmstr Char 5 Not null
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_dosen Char 10 Not null
c_matakuliah Char 10 Not null
c_nim Char 15 Not null
c_absen1 Char 1
c_absen2 Char 1
c_absen3 Char 1
c_absen4 Char 1
193
Tabel Name : TmPerkuliahanAbsn
Field Name Type Length Description
c_absen5 Char 1
c_absen6 Char 1
c_absen7 Char 1
c_absen8 Char 1
c_absen9 Char 1
c_absen10 Char 1
c_absen11 Char 1
c_absen12 Char 1
c_absen13 Char 1
c_absen14 Char 1
c_absen15 Char 1
c_absen16 Char 1
c_absen17 Char 1
c_absen18 Char 1
c_absen19 Char 1
c_absen20 Char 1
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmPerkuliahanNilai
Field Name Type Length Description
c_thnsmstr Char 5 Not null
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_dosen Char 10 Not null
c_matakuliah Char 10 Not null
c_nim Char 15 Not null
v_absen Int 4
v_uts Numeric 5
v_uas Numeric 5
c_grade Char 1
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmProgramStudi
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
d_tglberdiri Datetime 8
v_skslulus Int 4
194
Tabel Name : TmProgramStudi
Field Name Type Length Description
i_emailps Varchar 50
n_programstudi Varchar 50
i_noskopr Varchar 30
d_tglskopr Datetime 8
i_noskakrdts Varchar 30
d_tglskakrdts Datetime 8
c_akreditas Char 1
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmPropinsi
Field Name Type Length Description
c_propinsi Char 2 Not null
n_propinsi Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmRole
Field Name Type Length Description
c_role Char 3 Not null
n_roledesc Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmSaudara
Field Name Type Length Description
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
n_saudara Varchar 30 Not null
i_anakke Int 4
i_usia Int 4
i_statuskawin Varchar 15
i_pendidikan Varchar 10
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmSemester
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
195
Tabel Name : TmSemester
Field Name Type Length Description
c_semester Char 1 Not null
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmSemesterDesc
Field Name Type Length Description
c_semester Char 1 Not null
n_semester Varchar 6
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmSiswaPpmb
Field Name Type Length Description
c_pendaftaran Char 15 Not null
n_namasiswa Varchar 30
i_tempatlahir Varchar 20
d_tgllahir Datetime 8
i_agama Varchar 10
i_jeniskelamin Varchar 6
i_asalsekolah Varchar 30
i_asalsekolahalmt Varchar 30
i_asalsekolahthlls Char 4
i_almtasal Varchar 30
i_almtasalkota Varchar 20
i_almtasaltlp Char 15
i_alamat Varchar 30
i_telpon Char 15
i_sekolahhis Varchar 30
i_sekolahhisml Char 4
i_sekolahhissl Char 4
n_orangtua Varchar 30
i_orangtuaalmt Varchar 30
i_orangtuakota Varchar 20
i_orangtuajob Varchar 30
c_jurusan Varchar 50
c_informasiasal Char 3
v_nilai Real 4
n_keterangan Varchar 50
i_entry Char 15
d_entry Datetime 8
196
Tabel Name : TmStsJabatan
Field Name Type Length Description
c_stsjabatan Char 1 Not null
n_stsjabatan Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmUniversitas
Field Name Type Length Description
c_universitas Char 6 Not null
n_universitas Varchar 50
i_kota Varchar 20
i_entry Char 15
d_entry Datetime 8
Tabel Name : TmUserid
Field Name Type Length Description
c_userid Char 15 Not null
c_password Char 15
c_owner Varchar 30
c_role Char 3
d_expire Datetime 8
i_entry Char 15
d_entry Datetime 8
Tabel Name : TtBayarKuliah
Field Name Type Length Description
c_bukti Char 10 Not null
d_tglbukti Char 10
c_nim Char 15
c_programstudi Char 5
c_jenjang Char 1
c_thnsmstr Char 5
v_bayar Money 8
n_penyetor Varchar 30
n_bgkeuangan Varchar 30
n_penerima Varchar 30
i_terbilang Varchar 75
i_entry Char 15
d_entry Datetime 8
Tabel Name : TtBayarKuliahDtl
Field Name Type Length Description
c_bukti Char 15 Not null
197
Tabel Name : TtBayarKuliahDtl
Field Name Type Length Description
i_pembayaran Char 30 Not null
v_jmlbayar Money 8
i_entry Char 15
d_entry Datetime 8
Tabel Name : TtKTM
Field Name Type Length Description
c_nim Char 15 Not null
n_mahasiswa Varchar 25
i_programstudi Varchar 25
i_entry Char 15
d_entry Datetime 8
Tabel Name : TtPengalamanOrg
Field Name Type Length Description
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
c_tahun Char 4 Not null
i_jabatan Varchar 30
i_tempat Varchar 30
i_entry Char 15
d_entry Datetime 8
Tabel Name : TtSkripsi
Field Name Type Length Description
c_perguruantgg Char 6 Not null
c_programstudi Char 5 Not null
c_jenjang Char 1 Not null
c_nim Char 15 Not null
n_judulskripsi Varchar 50
n_tmptskirpsi Varchar 50
n_pembimbing1 Varchar 30
n_pembimbing2 Varchar 30
n_pembimbing3 Varchar 30
d_tglsidang Datetime 8
i_nilai Char 1
i_entry Char 15
d_entry Datetime 8
198
3. Basis Data Aplikasi Keuangan LPP Tabel Name : Fmgl
Field Name Type Length Description
kodegl Character 10
namagl Character 50
balance Character 1
report Character 1
yatidak Character 1
aktiva Character 1
labarugi Character 1
fuseri Character 3
fusere Character 3
timei Character 8
timee Character 8
tglupdi Date 8
tglupde Date 8
4. Basis Data Aplikasi Keuangan ASM Tabel Name : Fmgl
Field Name Type Length Description
kodegl Character 10
namagl Character 50
balance Character 1
report Character 1
yatidak Character 1
aktiva Character 1
labarugi Character 1
fuseri Character 3
fusere Character 3
timei Character 8
timee Character 8
tglupdi Date 8
tglupde Date 8
200
LAMPIRAN G (SPESIFIKASI ARSITEKTUR INTEGRASI TEKNIS)
1. Pendahuluan
Dokumen ini menyajikan spesifikasi arsitektur integrasi teknis yang digunakan
sebagai tuntunan dalam melakukan integrasi sistem bagi Yayasan Pendidikan
Ariyanti (YPA). Dokumen ini memberikan tuntunan bagi semua keputusan dan
rancangan yang terkait dengan integrasi dalam organisasi sehingga dapat
memastikan konsistensi, reusability dan manfaat ekonomis bagi organisasi.
2. Ruang Lingkup
Ruang lingkup arsitektur integrasi teknis memfokuskan pada fungsi utama bidang
akademik dan fungsi pendukung keuangan dan unit-unit organisasi yang terkait
dengan fungsi-fungsi tersebut. Integrasi dilakukan untuk aplikasi-aplikasi internal
YPA pada level data dengan pembatasan pada pemilihan arsitektur middleware
yang tidak merujuk pada teknologi tertentu.
3. Partisipan Kunci
Partisipan kunci dalam membuat arsitektur integrasi teknis adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung
jawab terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap
mengenai partisipan kunci beserta kelompok dan peranan mereka disajikan dalam
Tabel G.1 berikut ini :
Tabel G.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
201
Pada Tabel G.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Requirement Arsitektur Integrasi
4.1 Tipe-tipe Integrasi
Tipe-tipe integrasi yang akan dilakukan perlu didefinisikan. Data yang diperoleh
dari bagian sebelumnya digunakan untuk meramalkan kemungkinan requirement
pada bagian ini. Tipe-tipe integrasi pada Tabel G.2 didefinisikan untuk
menentukan ruang lingkup investasi.
Tabel G.2 Tipe-tipe Integrasi
No. No.
Aplikasi Kandidat Aplikasi
Tipe Integrasi
Keterangan Aplikasi Legacy
yang Diintegrasikan
1 1.1 Sistem Pendaftaran Calon Siswa/Mahasiswa Baru
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
2 1.2 Sistem Pengelolaan Pembayaran Pendaftaran
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
3 1.3 Sistem Pengelolaan Ujian Saringan Masuk seleksi calon mahasiswa baru
4 1.4 Sistem Pelaporan Penerimaan Siswa/Mahasiswa Baru
Information integration
Mengintegrasikan data dari seluruh unit organisasi
- Aplikasi akademik LPP
- Aplikasi akademik ASM
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
5 2.1 Sistem Registrasi Ulang Siswa/Mahasiswa
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
6 2.2 Sistem Pembuatan KRS, KTS dan KTM
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
7 2.3 Sistem Perwalian Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
8 2.4 Sistem Perubahan Rencana Studi
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
202
Tabel G.2 Tipe-tipe Integrasi (Lanjutan)
No. No.
Aplikasi Kandidat Aplikasi
Tipe Integrasi
Keterangan Aplikasi Legacy
yang Diintegrasikan
9 2.5 Sistem Penjadwalan KBM Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
10 2.6 Sistem Administrasi KBM Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
11 2.7 Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
12 2.8 Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
13 2.9 Sistem Pengelolaan Nilai Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
14 2.10 Sistem Pembuatan Kartu Hasil Studi
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
15 2.11 Sistem Administrasi Dosen
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
16 2.12 Sistem Manajemen Kurikulum
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
17 2.13 Sistem Pelaporan Akademik
Information integration
Mengintegrasikan data dari seluruh unit organisasi
- Aplikasi akademik LPP
- Aplikasi akademik ASM
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
18 3.1 Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
19 3.2 Sistem Administrasi Wisuda
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
20 3.3 Sistem Pelaporan Kegiatan Wisuda
Information integration
Mengintegrasikan data dari seluruh unit organisasi
- Aplikasi akademik LPP
- Aplikasi akademik ASM
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
21 5.3 Sistem Pengelolaan Alumni
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi akademik LPP
- Aplikasi akademik ASM
203
Tabel G.2 Tipe-tipe Integrasi (Lanjutan)
No. No.
Aplikasi Kandidat Aplikasi
Tipe Integrasi
Keterangan Aplikasi Legacy
yang Diintegrasikan
22 5.4 Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA
Composite integration
Mengintegrasikan dengan komponen aplikasi yang baru akan dikembangkan
- Aplikasi akademik LPP
- Aplikasi akademik ASM
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
23 6.1 Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
24 6.2 Sistem Pengelolaan Pembayaran Honor Dosen
Legacy integration
Integrasi aplikasi yang telah ada (legacy application)
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
25 6.3 Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa
Information integration
Mengintegrasikan data dari seluruh unit organisasi
- Aplikasi keuangan LPP
- Aplikasi keuangan ASM
4.2 Layanan dan Teknologi Integrasi
Bagian ini menuntun pemilihan teknologi untuk proyek tertentu. Meliputi vendor
dan solusi serta teknologi yang dipilih. Selain itu perlu didaftarkan tipe-tipe
layanan dan teknologi integrasi yang dapat digunakan untuk
mengimplementasikan layanan tersebut. Hasil penilaian arsitektur saat ini dan
produk-produk saat ini dalam organisasi digunakan sebagai dasar dalam
menentukan apakah vendor atau teknologi tertentu telah diinstalasi. Tabel G.3
menyajikan secara lengkap layanan integrasi, rekomendasi penggunaannya serta
teknologi integrasi yang dapat digunakan.
Tabel G.3 Layanan Integrasi Layanan Integrasi
Teknologi Integrasi
Penggunaan yang Direkomendasikan
Vendor/Teknologi yang Dipilih
Telah Diinstalasi?
Adapter Saat paket adapter tersedia bagi aplikasi target
- Tidak
Web service
Untuk SOA, composite application, legacy integration, custom application interface, dan integrasi B2B
Middleware untuk aplikasi legacy
Tidak
API-digunakan dengan paket aplikasi
Jika tidak ada lagi yang tersedia
Middleware untuk aplikasi legacy
Tidak
Adapter dan interface
Screen scraping-digunakan dengan legacy application
Jika tidak ada lagi yang tersedia atau untuk solusi cepat dan taktis
Middleware untuk aplikasi legacy
Tidak
204
Tabel G.3 Layanan Integrasi (Lanjutan) Layanan Integrasi
Teknologi Integrasi
Penggunaan yang Direkomendasika
n
Vendor/Teknologi yang Dipilih
Telah Diinstalasi
? JMS messaging
Aplikasi-aplikasi JAVA - Tidak
Proprietary messaging
Jika telah diinstalasi atau jika fungsi diperlukan
- Tidak
SOAP XML messaging pada internet
- Tidak
FTP Jika tidak ada lagi yang tersedia
- Tidak
Messaging dan layanan konektivitas
VAN EDI, layanan elektronis B2B
- Tidak
Layanan/broker integrasi
Digunakan untuk routing satu-ke-banyak atau banyak-ke-banyak, arsitektur hub and spoke
- Tidak
Enterprise Service Bus (ESB)
Digunakan untuk routing satu-ke-banyak atau banyak-ke-banyak, arsitektur bus, dapat dihubungkan dengan layanan integrasi lain
- Tidak
Routing
BPM High level routing dan manajemen proses bisni
- Tidak
Layanan integrasi-biasanya memiliki tool pemetaan grafis
Digunakan untuk integrasi satu-ke-banyak atau banyak-ke-banyak
- Tidak
Intelligent adapters-translasi dan transformasi terjadi pada adapter
Model komputasi terdistribusi yang scalable; metadata pemetaan disimpan dalam simpanan terpusat
- Tidak
Translasi dan transformasi
XSLT Transfomasi XML - Tidak EII Untuk data
teragregasi, seperti menyajikan single view bagi konsumen atau menyatukan data dari unit-unit organisasi
- Tidak
(ECM) Untuk mengintegrasikan data yang tidak terstruktur, termasuk dokumen, gambar, suara, video dan sebagainya
- Tidak
Integrasi informasi
Simpanan metadata
Untuk menciptakan format kanonik untuk informasi enterprise
- Tidak
Integrasi portal
Portal enterprise dan web
Menyediakan interface tunggal bagi informasi dan aplikasi yang berlainan
- Tidak
205
Tabel G.3 Layanan Integrasi (Lanjutan) Layanan Integrasi
Teknologi Integrasi
Penggunaan yang Direkomendasikan
Vendor/Teknologi yang Dipilih
Telah Diinstalasi?
Server aplikasi dan web
Digunakan untuk mengembangkan aplikasi atau komponen aplikasi atau layanan bisnis baru
- Tidak
Web service orchestration
Digunakan untuk “menyusun” aplikasi berbasis komponen
- Tidak
Composite application
Web service Digunakan untuk membuat layanan aplikasi yang digunakan dalam composite application
- Tidak
BPM Memodelkan, implementasi dan manajemen proses bisnis terintegrasi
- Tidak
BAM Monitoring secara real-time terhadap proses dan dashboard; dapat merupakan bagian dari tool BAM
- Tidak
B2B Server Digunakan untuk integrasi dengan partner dan supplier, membentuk komunitas on-line. Mengintegrasikan dengan aplikasi back-endmelalui adapter atau server EAI
- Tidak
EDI Digunakan untuk partner besar, dengan solusi EDI yang telah ada. Digunakan dengan VAN
- Tidak
Integrasi proses
Web service Digunakan sebagai interface terstandarisasi
- Tidak
Integrasi mobile
Server integrasi mobile
Menyajikan informasi bagi berbagai perangkat mobile yang berasal dari informasi atau business rule umum
- Tidak
Integrasi keamanan
Server integrasi keamanan
Mengintegrasikan sistem keamanan yang berlainan
- Tidak
5. Deskripsi Arsitektur Integrasi
Deskripsi arsitektur terdiri atas dua view, yaitu conceptual view dan development
view.
206
5.1 Conceptual View
Conceptual view memperlihatkan seluruh komponen dan keterhubungan
diantaranya. Conceptual view ini dapat digambarkan dalam berbagai cara.
Conceptual view dapat menunjukkan bagaimana seluruh layanan dapat saling
bersesuaian dan menunjukkan hubungan baik di dalam maupun di luarnya.
Gambar G.1 Tipe-tipe Enterprise Application Integration (9)
Sebelum melakukan integrasi, dalam hal ini adalah integrasi aplikasi, organisasi
perlu memahami elemen proses dan data yang memerlukan integrasi, karena
integrasi aplikasi dapat dilakukan pada berbagai level, yaitu (Gambar G.1) :
1. Level data.
Integrasi aplikasi level data (Gambar G.2) merupakan proses serta teknik dan
teknologi pemindahan data antar simpanan data. Level data menggambarkan
ekstrasi informasi dari suatu basis data, pemrosesan informasi sesuai
kebutuhan dan melakukan update pada basis data lain. Pengaksesan data
dalam konteks integrasi aplikasi memerlukan keterhubungan antara lojik dari
aplikasi dan user interface guna dapat mengekstrasi atau mengisi data secara
langsung ke dalam basis data.
207
Gambar G.2 Integrasi Level Data (9)
Terdapat banyak teknologi dan teknik untuk memindahkan data dari satu basis
data ke basis data lain, diantaranya database replication software, message
broker dan custom built. Software yang diletakkan antara basis data bertugas
untuk melakukan ekstrasi, merubah format dan meng-update satu basis data
sehingga dapat dipahami oleh basis data lain. Data direplikasi saat terdapat
update pada tabel yang bersesuaian. Terdapat dua pendekatan integrasi
aplikasi pada level data , yaitu :
b. Database-to-database
Saling berbagi informasi pada level basis data, baik pada konfigurasi one-
to-one, one-to-many, maupun many-to-many. Pendekatan bagi database-
to-database adalah dengan middleware basis data dan software replikasi
basis data.
c. Federated database
Juga bekerja pada level basis data, namun tidak hanya melakukan replikasi
data antara basis data, melainkan memperbolehkan pengaksesan sejumlah
basis data dari berbagai brand, model skema menggunakan model basis
data virtual. Model basis data virtual hanya terdapat pada perangkat lunak
dan dipetakan pada basis data yang terhubung secara fisik. Penggunaan
basis data virtual sebagai single point integrasi aplikasi, mengakses data
dari sejumlah sistem melalui interface basis data tunggal. Manfaat dari
pendekatan ini adalah pada middleware untuk berbagi informasi antar
208
aplikasi dan bukan pada custom solution. Middleware digunakan untuk
menyembunyikan perbedaan dari basis data yang diintegrasikan.
2. Level application interface.
Integrasi aplikasi pada level application interface (Gambar G.3) merupakan
interface yang di-expose dari packaged application atau custom application
sedemikian sehingga aplikasi eksternal dapat memperoleh akses terhadap
berbagai level atau layanan tanpa membuat perubahan terhadap aplikasi
tersebut. Penyajian interface bertujuan untuk menyediakan akses terhadap
proses bisnis dan data yang dienkapsulasi dalam aplikasi yang dibuat dan
menyediakan mekanisme yang memungkinkan informasi yang dienkapsulasi
dapat di-share.
Gambar G.3 API Penghubung dengan Sumber Daya (9)
Mekanisme yang dibuat untuk menghubungkan sejumlah sumber daya seperti
application server, middleware layer maupun basis data merupakan
application programming interface (API). API memungkinkan adanya
permintaan layanan terhadap ketiga entitas tersebut guna memperoleh nilai
(Gambar G.3).
3. Level metoda.
Integrasi aplikasi level metoda dimaksudkan untuk berbagi business logic
yang terdapat dalam enterprise. Mekanisme berbagi metoda diantara aplikasi
209
diantaranya distributed object, application server, transaction processing
monitor, framework dan membuat aplikasi baru yang mengkombinasikan dua
aplikasi atau lebih. Terdapat dua pendekatan dasar yaitu membuat sejumlah
shared application server yang ada dalam shared physical server.
4. Level user interface.
Integrasi aplikasi level user interface merupakan integrasi aplikasi dengan
menggunakan user interface (dikenal juga dengan istilah screen scraping).
5.2 Development View
Development view merupakan deskripsi mengenai bagaimana, kapan tool dan
interface yang berlainan dapat digunakan, untuk menuntun tim pengembangan
yang menggunakan arsitektur integrasi.Untuk setiap aspek arsitektur integrasi,
haruslah terdapat deskripsi mengenai bagaimana developer menerapkan arsitektur
tersebut. Hal ini dapat meliputi bahasa yang didukung dan tata cara dimana
layanan dan kemampuan diakses, tool untuk pengembangan integrasi, serta tool
untuk konfigurasi dan administrasi. Selain itu, interface standar yang digunakan
juga harus didefinisikan.
5.2.1 Penentuan Komponen Data yang Diintegrasikan
Integrasi aplikasi akan dimulai dengan menentukan data karena untuk kasus
aplikasi di YPA, permasalahan utama terletak pada redundansi data. Hal ini
memberikan gambaran bahwa apa yang sebenarnya terdapat dalam basis data.
Terdapat tiga langkah dasar dalam menerapkan integrasi aplikasi level data, yaitu
mengidentifikasi data, membuat katalog data dan membuat skema data. Tujuan
dari penentuan data ini adalah untuk memahami dimana data berada (where),
memperoleh informasi mengenai data (where) dan mengaplikasikan prinsip-
prinsip untuk menentukan data apa yang mengalir (which), ke mana (where) dan
mengapa (why).
Hasil pemetaan antara entitas data yang dihasilkan dan digunakan aplikasi legacy
menunjukkan bahwa terdapat entitas yang diciptakan oleh lebih dari satu aplikasi,
210
sebagai contoh adalah entitas pendaftar yang diciptakan oleh aplikasi penerimaan
siswa LPP dan juga oleh aplikasi penerimaan mahasiswa ASM. Berdasarkan hasil
pemetaan ini, diidentifikasi entitas-entitas yang akan diintegrasikan sehingga
cukup dengan sekali penciptaan, maka data dapat digunakan pada aplikasi lain.
Entitas data yang akan diintegrasikan adalah entitas pendaftar, mata kuliah,
siswa/mahasiswa, dosen dan komponen biaya karena entitas ini diciptakan
berulang kali serta digunakan pada sub sistem lainnya.
5.2.2 Katalog Data
Pembuatan katalog dimaksudkan untuk mengetahui identitas untuk masing-
masing atribut dari tiap tabel. Berdasarkan katalog inilah akan ditentukan atribut
mana yang memiliki pengaruh terhadap atribut pada tabel lain sehingga akan
memudahkan proses integrasi pada level data. Definisi untuk data bagi masing-
masing basis data dari keempat aplikasi yaitu aplikasi akademik dan keuangan
unit LPP dan ASM disajikan dalam bentuk katalog data pada lampiran.
5.2.3 Skema Basis Data
Setelah informasi mengenai data diidentifikasi dalam bentuk katalog data, langkah
selanjutnya adalah membuat skema relasi antar tabel sehingga dapat diketahui
tabel yang mempengaruhi tabel lain dari antara aplikasi dalam enterprise. Skema
relasi antar tabel dapat dilihat pada Gambar G.4 yang menunjukkan
keterhubungan tabel dari keempat kelompok aplikasi. Tabel-tabel yang
memberikan pengaruh terhadap aplikasi lain yaitu pendaftar, siswa, mahasiswa,
dosen dan komponen biaya. Tabel-tabel tersebut juga memiliki permasalahan
utama yaitu dibuat lebih dari satu kali oleh lebih dari satu aplikasi yang
mengakibatkan redundansi data. Sehingga permasalahan ini dapat diselesaikan
dengan melakukan integrasi antar tabel-tabel tersebut.
211
* kddosennmdosen gelar
tmptlahir tgllahir agama
jeniskelamin alamat
kota kodepos telpon pendidikan
nmuniv
Tabel Dosen
tglmasuk* nis
nm_sistmp_lahirtgl_lahir
jk alamat kota kodepos
telpon
Tabel Siswa
* kd_pendaftarannm_pendaftartmp_lahirtgl_lahir
jk alamat kota kodepos
telpon
Tabel Pendaftar
c_perguruantggc_programstudic_jenjang
* c_dosenn_doseni_gelari_tmptlahird_tgllahiri_agamai_jeniskelamini_goldaraha_alamata_kotaa_kodeposa_telpona_handphonea_emaili_nomorktpc_jabatanc_stsjabatanc_pendidikann_sekolahi_bidgilmui_aktai_ijini_nipc_ptinduki_entryd_entry
Tabel TmDosen
c_perguruantggc_programstudic_jenjangc_jurusan
* c_nimn_mahasiswa
i_tmptlahird_tgllahiri_agamai_jeniskelamini_goldarahi_almtorgtuai_kotaorgtuac_kdposorgtuac_prporgtuaa_alamata_kotaa_kodeposa_telpona_handphonea_emaili_tahunmasuki_btssemesterd_tglmasukc_stsmasuki_entryd_entry
Tabel TmMahasiswa
* c_pendaftarann_namasiswai_tempatlahird_tgllahiri_agamai_jeniskelamini_asalsekolahi_asalsekolahalmti_asalsekolahthllsi_almtasali_almtasalkotai_almtasaltlpi_alamati_telponi_sekolahhisi_sekolahhismli_sekolahhissln_orangtuai_orangtuaalmti_orangtuakotai_orangtuajobc_jurusanc_informasiasalv_nilain_keterangani_entryd_entry
Tabel TmSiswaPPMB
* nisnmsistmp_lahirtgl_lahir
kelamin alamat kota kodepos
telpon
Tabel Siswa* nim
nmmhstmp_lahirtgl_lahir
kelamin alamat kota kodepos
telpon
Tabel Mahasiswa
Aplikasi Keuangan LPP
Aplikasi Keuangan ASM
Aplikasi Akademik ASM
Aplikasi Akademik LPP
* kodegl namagl balance report yatidak aktiva labarugi fuseri fusere timei timee tglupdi
tglupde
Tabel FmGL
* kodegl namagl balance report yatidak aktiva labarugi fuseri fusere timei timee tglupdi
tglupde
Tabel FmGL
Gambar G.4 Skema Relasi Basis Data
5.2.4 Penentuan Teknologi Integrasi Aplikasi
Berdasarkan kebutuhan untuk menggabungkan aplikasi yang tidak merubah lojik
aplikasi serta memperhatikan skema relasi basis data dan skema aplikasi yang
memerlukan pertukaran data antar aplikasi dari tabel-tabel master yang tidak
memiliki keterkaitan lojik secara erat antar basis data maka disimpulkan bahwa
keempat kelompok aplikasi memerlukan adanya integrasi pada tingkatan data.
212
Integrasi pada level data dipilih karena tidak adanya akses terhadap lojik atau
source code dari masing-masing aplikasi. Integrasi dapat dilakukan pada level
data dengan menempatkan software diantara basis data dari keempat aplikasi.
Software ini bertugas untuk melakukan ekstraksi informasi dari suatu basis data,
melakukan reformat terhadap data dengan merubah isi dan skema jika diperlukan
serta melakukan update basis data. Data direplikasi diantara basis data saat terjadi
update dari sisi basis data manapun ke tabel yang bersesuaian.
5.2.5 Integrasi Level Data
Sebelum melakukan perpindahan data antar basis data, perlu dipahami metadata
dari masing-masing basis data. Pemahaman ini sangatlah penting karena basis
data dari keempat aplikasi di YPA dibuat dengan platform yang berbeda.
Pemahaman yang dimaksud di sini bertujuan untuk dapat mengkomunikasikan
format setiap tabel yang akan diintegrasikan dari masing-masing basis data.
Sebagai contoh untuk memindahkan data dosen dari basis data aplikasi akademik
LPP ke basis data aplikasi akademik ASM perlu memperhatikan struktur dari
masing-masing tabel. Pengabaian terhadap struktur atau format data akan
mengakibatkan error baik bagi basis data sumber maupun basis data tujuan.
Keputusan lain yang harus dibuat juga terkait dengan frekuensi perpindahan data
sehingga setiap terjadi event, akan memberikan signal mengenai kapan data harus
disalin, apakah real time atau batch. Untuk kasus YPA, dimana data yang
dipindahkan adalah data dari tabel master yang diperlukan oleh aplikasi lain dan
mempengaruhi informasi di aplikasi lain, maka perpindahan harus dilakukan
secara real-time. Terdapat banyak teknik dan teknologi untuk memindahkan data
dari satu basis data ke basis data lain termasuk diantaranya adalah software
replikasi, message brokers dan custom-built. Apapun teknologi yang digunakan,
tujuan dari software tersebut adalah menyediakan kemampuan untuk mengekstrasi
informasi dari basis data, melakukan reformat data (melakukan perubahan skema
maupun isi) dan melakukan update di basis data lain.
213
Integrasi pada level data bertanggung jawab terhadap pengaksesan data dari satu
aplikasi ke aplikasi lain. Oleh karenanya, level ini harus menyediakan layanan
transportasi dan transformasi data. Integrasi pada level data merupakan integrasi
pada tingkat rendah yang berarti proses integrasi tidak memerlukan pemahaman
mengenai lojik aplikasi sehingga lojik aplikasi akan diabaikan dengan langsung
melakukan pembacaan dan penulisan data dari aplikasi sumber ke aplikasi tujuan.
5.2.5.1 Tipe Middleware
Middleware adalah software yang memfasilitasi komunikasi antara dua atau lebih
sistem perangkat lunak. Tipe middleware yang dipilih untuk kasus di YPA adalah
database-oriented middleware, merupakan middleware yang memfasilitasi
komunikasi antara basis data, mekanisme yang mengekstraksi informasi baik dari
basis data lokal maupun remote.
Database-oriented middleware bekerja dengan dua tipe basis data yaitu call-level
interface (CLI) dan native database. CLI menyediakan akses pada sejumlah basis
data melalui interface umum, banyak digunakan pada basis data relasional (contoh
ODBC, JDBC). Sedangkah native database middleware tidak menggunakan API,
namun mengakses feature dan fungsi basis data tertentu, hanya menggunakan
mekanisme aslinya.
Alasan dipilihnya database-oriented middleware dalam kasus YPA, dikarenakan
sejumlah manfaat yang dapat diperoleh, yaitu (Gambar G.5) :
1. Interface terhadap aplikasi.
2. Kemampuan untuk dapat mengkonversi bahasa aplikasi sehingga dapat
dipahami oleh basis data target.
3. Kemampuan untuk dapat mengirimkan query terhadap basis data melalui
jaringan.
4. Kemampuan untuk dapat memproses query pada basis data target.
5. Kemampuan untuk dapat memindahkan tanggapan sebagai hasil dari query
kembali melalui jaringan kepada aplikasi yang meminta.
214
6. Kemampuan untuk mengkonversi tanggapan ke dalam format yang dapat
dipahami oleh aplikasi yang meminta.
Kemampuan tersebut perlu didukung oleh kemampuan untuk dapat memproses
permintaan secara simultan.
Gambar G.5 Fungsi Database-Oriented Middleware
5.2.5.2 Model Middleware
Pemahaman terhadap karakteristik tiap middleware diperlukan untuk
mengevaluasi setiap teknologi dari vendor. Terdapat dua tipe model middleware
yaitu lojik (logical) dan fisik (physical). Model middleware lojik menggambarkan
bagaimana informasi mengalir dalam enterprise secara konseptual, sedangkan
middleware fisik menggambarkan bagaimana sebenarnya informasi mengalir dan
teknologi yang digunakan.
Middleware dapat bekerja pada konfigurasi point-to-point atau many-to-many.
Middleware point-to-point menghubungkan satu aplikasi dengan satu aplikasi lain
misalnya aplikasi akademik LPP dengan aplikasi akademik ASM. Sedangkan
middleware many-to-many menghubungkan banyak aplikasi dengan banyak
aplikasi lain.
Jenis komunikasi middleware terdiri atas asynchronous dan synchronous.
Middleware asynchronous merupakan middleware yang dapat memindahkan
informasi antara satu atau banyak aplikasi dalam mode asinkron yang artinya
bersifat decouple dan satu aplikasi tidak tergantung terhadap aplikasi lain yang
terhubung saat melakukan pemrosesan sehingga tidak akan melakukan block
terhadap aplikasi lain dalam melakukan pemrosesan. Sedangkan middleware
synchronous bersifat tightly couple, yang sangat tergantung pada middleware
untuk memproses satu atau lebih function call.
215
Untuk kasus YPA, maka model middleware yang cocok adalah many-to-many
asynchronous. Pemilihan middleware dengan konfigurasi many-to-many untuk
kasus aplikasi di YPA karena jika melihat skema relasi basis data (Gambar G.4),
maka terdapat banyak keterhubungan point-to-point. Sedangkan penggunaan jenis
komunikasi asynchronous karena antar aplikasi tidak memiliki keterkaitan erat
(loosely coupled) sehingga tidak perlu melakukan blocked terhadap aplikasi lain
dalam melakukan pemrosesan.
5.2.5.3 Topologi Integrasi Aplikasi
Ilustrasi pada Gambar G.6 diberikan untuk memberikan pemahaman mengenai
bagaimana suatu data disimpan antar tabel dan basis data. Sebagai contoh saat
data dosen disimpan pada basis data aplikasi akademik LPP, maka akan
menciptakan event, informasi baru ini akan disalin ke aplikasi akademik ASM.
Frekuensi perpindahan data bersifat real-time, artinya data pada suatu tabel akan
di-update setiap terjadi event pada suatu tabel yang bersesuaian.
Kompatibilitas data terkait dengan sintaks dan semantik data. Permasalahan
mengenai format dan struktur data merupakan permasalahan kompatibilitas
sintaks data yang dapat diatasi dengan melakukan penyesuaian format dan
struktur data antar aplikasi. Sedangkan permasalahan semantik data adalah
dihasilkannya suatu data dari hasil gabungan dan transformasi menjadi format
record baru.
Jika memperhatikan skema relasi basis data (Gambar G.4) dapat dilihat bahwa
perpindahan data antar basis data hanya melibatkan permasalahan sintaks data,
yang artinya hanya memerlukan penyesuaian struktur dan format data dari basis
data sumber ke basis data tujuan. Sebagai contoh untuk memindahkan isi field
kddosen dari tabel dosen di basis data akademik LPP ke field c_dosen pada tabel
TmDosen di basis data akademik ASM hanya perlu memperhatikan struktur dan
format data yang telah didefinisikan pada katalog data (lampiran F) yaitu
penyesuaian dari tipe character berukuran 6 dengan tipe varchar berukuran 10.
216
Gambar G.6 Integrasi Level Data Kasus YPA
Untuk mengintegrasikan aplikasi, maka perlu adanya pembentukan arsitektur bagi
bagaimana aplikasi tersebut saling terhubung. Pada dasarnya terdapat 3 jenis
arsitektur integrasi aplikasi yaitu :
1. Hub-and-spoke
Dengan arsitektur hub-and-spoke, tool integrasi aplikasi bertindak sebagai
pusat dari aplikasi yang terhubung dan bekerja seperti hub informasi. Setiap
aplikasi langsung dikoneksikan dengan hub sehingga akan mengurangi
kompleksitas integrasi. Interaksi aplikasi dengan aplikasi lain dilakukan
melalui hub, jadi tidak ada koneksi secara langsung antar aplikasi. Arsitektur
integrasi ini memiliki kelebihan dalam meminimasi integrasi interface,
memungkinkan komunikasi sinkron/asinkron, berorientasi proses bisnis,
memfasilitas model publish/subscribe, memungkinkan guna ulang,
mengurangi kompleksitas implementasi, memungkinkan manajemen/
administrasi terpusat. Namun arsitektur ini juga memiliki kelemahan yaitu
mengakibatkan kegagalan terpusat, kemungkinan besar terjadinya bottleneck
jika integrasi dilakukan pada sistem besar dan permasalahan seputar
performansi.
217
2. Federated
Pada arsitektur federated, tidak terdapat server integrasi aplikasi.
Transformasi data dan pengontrolan workflow secara langsung ditempelkan
pada aplikasi melalui modul. Integrasi antar sistem direalisasikan melalui
keterhubungan secara langsung. Komunikasi antara sistem menggunakan bus
topology dengan format message yang bersifat product-dependent. Arsitektur
ini tidak mengikuti ide integrasi enterprise karena masih terdapat koneksi
point-to-point sehingga cocok untuk proyek integrasi kecil.
3. Bus topology
Bus topology digunakan untuk merealisasikan komunikasi antara sistem yang
berbeda. Kelemahan dari arsitektur ini adalah setiap modul harus di-install
pada setiap sistem yang diintegrasikan. Komponen ini yang bertanggung
jawab menghubungkan sistem yang terintegrasi dengan bus sehingga seluruh
aplikasi terintegrsi. Terdapat server yang mengelola seluruh workflow dan
transformasi data. Manfaat dari topology ini adalah untuk memperoleh
scalability dimana jumlah sistem terintegrasi tidak akan mempengaruhi
performansi, memperoleh performansi yang tinggi dengan arsitektur
terdistribusi dan pengelolaan yang terpusat.
Untuk kasus aplikasi di YPA, integrasi menggunakan arsitektur bus topology
(Gambar G.6), dimana setiap sistem diintegrasikan melalui bus dan transformasi
data dikelola oleh server. Arsitektur ini diharapkan dapat memberikan skalabilitas
pada komponen-komponen yang diintegrasikan sehingga memiliki performansi
yang tinggi.
6. Profil Standar-standar
Bagian ini menspesifikasikan seluruh standar (Tabel G.4) yang digunakan oleh
organisasi yang relevan dengan arsitektur integrasi. Spesifikasi lengkap juga harus
mencakup kebijakan tata kelola yang mendefinisikan bagaimana memenuhi
standar yang akan dikelola, serta proses dan tuntunan untuk menyetujui solusi
yang tidak sesuai dengan standar.
218
Tabel G.4 Standar Protokol komunikasi TCP/IP Interface apllikasi Middleware aplikasi dan web service Format message SQL Model proses Business Process Modeling Metadata Metadata transformasi dan translasi data
7. Service Level Agreements
Service level requirements meliputi availabilitiy, integrity, scalability,
maintainalibity, manageability, usability, performance, transaction services,
persistence dan directory services.
7.1 Availability
Terdapat dua tipe ukuran availability : system availability (8 x 5, 24 x 7) dan
availability dari integrasi (real time, periodic atau batch). Ukuran ini didefinisikan
saat informasi yag telah diintegrasikan telah siap digunakan. Pada kasus di YPA,
system availability disesuaikan dengan jam kerja yaitu 24x7 dengan availability
integrasi bersifat real time.
7.2 Integrity and Delivery Service
Integrity atau informasi terintegrasi terletak pada integritas transmisi dan juga
integritas informasi yang diperoses. Integritas transmisi dipastikan dengan
transmission services seperti guaranteed delivery, once-and-only once delivery
serta persistent message stores. Integritas dari proses informasi tergantung pada
validitas proses translasi dan transformasi serta pemrosesan informasi oleh sistem
target. Ukuran ini dapat berupa dalam error rates.
7.3 Scalability
Scalability requirements menentukan tipe arsitektur dan teknologi yang dipilih
untuk implementasi, dan merupakan faktor yang penting dalam perencanaan dan
pengadaan kapasitas. Scalability requirements harus didefinisikan bagi kebutuhan
organisasi baik dalam rangka pendek maupun jangka panjang. Scalability
requirements dapat didefinisikan melalui parameter berikut ini :
• Jumlah informasi yang dilewatkan.
• Rata-rata transaksi (waktu/volume).
219
• Jumlah aplikasi yang diintegrasikan.
• Koneksi end-user secara simultan.
7.4 Maintainability and Manageability
Maintanability dan management requirements dapat didefinisikan melalui
layanan-layanan berikut ini :
• Monitoring dan alerting.
• Startup, shutdown dan restart.
• Troubleshooting dan level of support.
• Maintainability terhadap kode dan penggunaan tool.
• Instalasi dan pengelolaan release of update dan kemampuan untuk melakukan
rollback.
• Scheduling.
• Integrasi dengan tool yang ada.
Setelah menentukan manageability requirements, direkomendasikan untuk
membuat ringkasannya untuk tujuan perencanaan enterprise. Lalu memberikan
manageability requirements rating bagi tiap aplikasi atau proyek yang melakukan
hal ini. Rating ini menyediakan summary view terhadap seluruh manageability
requirements. Berikut ini adalah rating yang dapat digunakan :
• Level 1. Startup, shutdown dan restart, troubleshooting, scheduling remote
installation.
• Level 2. Level 1 ditambah dengan update dan rollback, repository aplikasi
terintegrasi.
• Level 3. Level 2 ditambah real time monitoring dan alert, integrasi penuh
pada pengembangan dan tool manajemen.
7.5 Usability
Usability (Tabel G.5) merujuk pada seberapa mudah tiap tipe user dalam
menggunakan sistem. Definisikan seluruh tipe user dari sistem, tipe akses dan
usability yang diperlukan.
220
Tabel G.5 Tipe User Tipe User Usability Requirements
Developer <spesialis integrasi legacy >
Programming interfaces
Analyst Modeling interface Designer Modeling dan configuration interface Jajaran business manager Browser-based portal atau dashboard Business user lain Browser-based portal
Operational manager Interface untuk management tool, portal interface bagi operational status
Operator Interface antar aplikasi
7.6 Performance
Performance requirements (Tabel G.6) mendefinisikan level of service dari
infrastruktur yang perlu disediakan untuk mendukung user bisnis, proses dan
transaksi. Performance requirements juga digunakan dalam Capacity Planning
View (terdapat dalam bagian ke-9 dari template spesifikasi arsitektur integrasi
teknis ini).
Tabel G.6 Performansi Response time Real-time Throughput Jumlah transaksi, volume data Turnaround time Detik, menit, jam, hari
Jumlah simulataneous user Subtotal berdasarkan tipe user yang terdefinisi dalam usability
Jumlah aplikasi yang terhubung
1. Aplikasi akademik unit LPP 2. Aplikasi akademik unit ASM 3. Aplikasi keuangan unit LPP 4. Aplikasi keuangan unit ASM
7.7 Transaction Services
Transaction services meliputi dukungan transaksi terdistribusi. Informasi ini
menentukan bagaimana transaksi akan dikelola dan bagaimana integritas transaksi
tetap dipertahankan. Bagian ini juga mendefinisikan requirements untuk
mendukung standar-standar enterprise dan regulator. Requirement layanan
transaksi di YPA terdapat pada Tabel G.7 berikut ini :
Tabel G.7 Transaction Service No.Layanan Transaksi
Requirement
T1 Sistem dapat dipergunakan 24x7 karena budaya kerja di YPA yang tidak hanya mengandalkan pada aturan jam kerja, namun seringkali harus menambah jam kerja (lembur).
T2 YPA memerlukan sistem yang dapat menyediakan hak akses sesuai tingkatan user.
T3
Sistem menyediakan kemampuan pengaksesan data dari berbagai tempat dengan tetap mempertahankan integritas dan konsistensi data. Oleh karenanya diperlukan middleware yang mampu melakukan translasi dan transformasi data secara real-time.
T4 Minimasi perubahan interface karena mempengaruhi adaptasi user terhadap sistem.
221
7.8 Persistence Services
Persistence diperlukan untuk meningkatkan reliability saat harus pulih dari suatu
kondisi kegagalan. Kemampuan untuk dapat me-restart sistem yang mengalami
kegagalan tanpa menggagalkan proses integrasi merupakan dasar penggunaan
persistence service. Tipe penggunaan lain dari persisted data meliputi
kemampuan untuk me-rollback setiap aksi, melaksanakan audit terhadap aktivitas
atau menggunakan kumpulan data untuk menganalisa aktivitas pada infrastruktur.
Bagian ini mendefinisikan requirements untuk menyediakan simpanan bagi data
integrasi dan informasi status selama dan setelah penggunaan infrastruktur
integrasi. Requirement layanan persistence di YPA terdapat pada Tabel G.8
berikut ini :
Tabel G.8 Persistence Service No.Layanan Transaksi
Requirement
P1 Tersedianya pencegahan terhadap ancaman fisik yang menyebabkan kegagalan sistem seperti gangguan listrik dan kesalahan penanganan oleh user.
P2 Tersedianya metoda mirroring data bersifat real-time untuk mencegah hilangnya data sebagai akibat kegagalan sistem.
P3 Jika terjadi kegagalan pada sistem, maka sistem mampu melakukan rollback menuju kondisi sebelum sistem mengalami kegagalan.
P4 Tersedianya fasilitas pengawasan kegiatan terhadap sistem.
P5 Sistem memiliki fasilitas informasi status selama dan setelah penggunaan infrastruktur integrasi.
7.9 Directory Services
Directories dapat menyediakan transparansi lokasi dengan membolehkan aplikasi
untuk dapat “mencari” aplikasi lain yang akan diintegrasikan. Directory
menyimpan informasi konfigurasi pada sumber daya atau user yang nantinya
dapat digunakan oleh suatu aplikasi atau proses integrasi. Directory juga dapat
digunakan untuk menyimpan informasi pengamanan. Tabel G.9 menggambarkan
tipe-tipe informasi untuk menspesifikasikan directory services.
Tabel G.9 Directory Service Nama
Komponen Tipe
Komponen Lokasi Deskripsi
Field-field Lain
Jajaran manajemen
User
Ruang direksi, ruang pembantu direktur, ruang kepala program studi dan ruang ketua koordinator jurusan.
Penyediaan data dan informasi oleh jajaran manajemen.
Disesuaikan jumlah manajemen.
222
Tabel G.9 Directory Service (Lanjutan) Nama
Komponen Tipe
Komponen Lokasi Deskripsi
Field-field Lain
Operator User Ruang bagian akademik, ruang keuangan
Pengguna sistem. Disesuaikan jumlah karyawan bagian akademik dan keuangan.
Server Hardware Ruang unit pelaksana teknis
Tempat server. 2
Client Hardware Ruang direksi, ruang pembantu direktur, ruang kepala program studi dan ruang ketua koordinator jurusan, ruang bagian akademik, ruang keuangan
Tempat client.
7.10 Service Level Summary Table
Service Level Summary Table bermanfaat untuk menyajikan aggregate view dari
service level requirements. Tabel G.10 menyajikan service level summary.
Tabel G.10 Service Level Summary Table
Aplikasi
Akademik LPP
Aplikasi Akademik
ASM
Aplikasi Keuangan LPP
Aplikasi Keuangan
ASM Availability Real-time; 24x7 Real-time; 24x7 Real-time; 24x7 Real-time; 24x7 Integrity dan delivery service
Guaranteed Guaranteed Guaranteed Guaranteed
Scalability
• Koneksi dihitung berdasarkan bandwidth jaringan
• Transaksi lokasi
• Volume data
• Koneksi dihitung berdasarkan bandwidth jaringan
• Transaksi lokasi
• Volume data
• Koneksi dihitung berdasarkan bandwidth jaringan
• Transaksi lokasi
• Volume data
• Koneksi dihitung berdasarkan bandwidth jaringan
• Transaksi lokasi
• Volume data Maintainability dan manageability
Level 2 Level 2 Level 2 Level 2
Usability
• Developer <spesialis integrasi legacy >
• Analyst • Designer • Jajaran
business manager
• Business user lain
• Operational manager
• Operator
• Developer <spesialis integrasi legacy >
• Analyst • Designer • Jajaran
business manager
• Business user lain
• Operational manager
• Operator
• Developer <spesialis integrasi legacy >
• Analyst • Designer • Jajaran
business manager
• Business user lain
• Operational manager
• Operator
• Developer <spesialis integrasi legacy >
• Analyst • Designer • Jajaran
business manager
• Business user lain
• Operational manager
• Operator
223
Tabel G.10 Service Level Summary Table (Lanjutan)
Aplikasi
Akademik LPP Aplikasi
Akademik ASM Aplikasi
Keuangan LPP
Aplikasi Keuangan
ASM Performance Response time,
througput, simulataneous user
Response time, througput, simulataneous user
Response time, througput, simulataneous user
Response time, througput, simulataneous user
Transaction services
Transaksi terdistribusi
Transaksi terdistribusi
Transaksi terdistribusi
Transaksi terdistribusi
Persistence Simpanan untuk data dan informasi integrasi untuk recovery, playback dan analisis
Simpanan untuk data dan informasi integrasi untuk recovery, playback dan analisis
Simpanan untuk data dan informasi integrasi untuk recovery, playback dan analisis
Simpanan untuk data dan informasi integrasi untuk recovery, playback dan analisis
Directory services
User dan hardware disesuaikan kebutuhan dan jumlah user
User dan hardware disesuaikan kebutuhan dan jumlah user
User dan hardware disesuaikan kebutuhan dan jumlah user
User dan hardware disesuaikan kebutuhan dan jumlah user
8. Pengamanan
Pengamanan merupakan salah satu tipe dari service-level requirement, namun
merupakan topik yang penting sehingga perlu dibahas dalam bagian tersendiri.
Spesifikasi ini harus dimulai dengan meringkaskan top-level security requirement
dengan mengkategorisasikan atau menentukan tipe aplikasi yang akan
memanfaatkan arsitektur tersebut. Hal ini dapat dilakukan dengan cara yang
umum, sebagaimana ditunjukkan pada Tabel G.11 berikut, namun akan lebih
efektif jika didefinisikan lebih terperinci.
Tabel G.11 Security Requirement
Au
then
tica
tio
n
Au
tho
riza
tio
n
Au
dit
ing
Co
nfi
den
tiality
No
nre
pu
dia
tio
n
Internal data Partner data Customer data Internal appplication Partner application Customer application Internal process Partner process Customer process
224
8.1 Authentication
Authentication service mengkonfirmasi identitas user. Spesifikasi secara rinci
mengenai authorization service requirement meliputi hal-hal berikut :
• Daftar tipe user. Tipe user berkorelasi dengan tipe aplikasi atau layanan yang
diakses. Meliputi : designer, programmers, managers, jajaran business user,
konsumen dan partner.
• Level authentication untuk tiap tipe user atau peranannya. Level
authentication dapat meliputi : password, password dengan key encryption
baik public/private, digital certificate atau biometrics.
• Apakah unitary login akan didukung. Unitary logic mendefinisikan apakah
authentication dapat dilakukan sekali pada seluruh aplikasi dan layanan. Hal
ini memerlukan directory untuk seluruh layanan secara terpusat.
• Definisi mengenai bagimana user account akan dikelola. User account
harus secara konstan diciptakan, dibuat dan di-update berdasarkan perubahan
yang terjadi dalam bisnis. Sangtlah penting untuk memiliki proses formal
yang mendefinisikan bagaimana informasi akan tetap tersinkronisasi.
Authentication service YPA secara lengkap disajikan pada Tabel G.12 berikut ini :
Tabel G.12 Authentication Service
Daftar tipe user
Level authentication untuk Tiap Tipe User
atau Peranannya
Apakah Unitary Login
akan Didukung
Definisi Mengenai Bagimana User Account akan
Dikelola Developer <spesialis integrasi legacy >
Mengelola pemrograman Ya
Analyst Memodelkan interface Ya Designer Pemodelan dan konfigurasi Ya
Jajaran business manager
Mengakses browser-based portal atau dashboard (Level 1)
Ya
Business user lain
Mengakses browser-based portal (Level 1)
Ya
Operational manager
Mengelola interface untuk management tool, portal interface bagi operational status (Level 0)
Ya
Administrator Mengelola user account Ya
User account secara konstan diciptakan, dibuat dan di-update berdasarkan perubahan yang terjadi dalam bisnis
Operator Mengelola aplikasi (bervariasi dari Level 2)
Ya
225
8.2 Authorization
Authorization level menentukan operasi apa yang diotorisasi bagi user atau proses
untuk menggunakan sejumlah data atau melaksanakan aplikasi. Bagian ini
mendefinisikan kategori authorization, didasarkan pada aplikasi dan/atau
sensitivitas data. Authorization biasanya didefnisikan dengan matriks CRUD yang
mendefnisikan hak untuk menciptakan/(c)reate, membaca/(r)ead,
memperbaharui/(u)pdate atau menghapus/(d)elete informasi. Tabel G.13
menyajikan authorization level dalam menentukan otorisasi user di YPA.
Tabel G.13 Authorization
Daftar tipe user Aplikasi
Akademik LPP
Aplikasi Akademik
ASM
Aplikasi Keuangan
LPP
Aplikasi Keuangan
ASM Developer <spesialis integrasi legacy >
<C, R, U, D> <C, R, U, D> <C, R, U, D> <C, R, U, D>
Analyst <C, R, U, D> <C, R, U, D> <C, R, U, D> <C, R, U, D> Designer <C, R, U, D> <C, R, U, D> <C, R, U, D> <C, R, U, D> Jajaran business manager
<R> <R> <R> <R>
Business user lain <R> <R> <R> <R> Operational manager
<R> <R> <R> <R>
Administrator <C, R, U, D> <C, R, U, D> <C, R, U, D> <C, R, U, D> Operator <C, R, U> <C, R, U> <C, R, U> <C, R, U>
8.3 Perimeter Security
Bagian ini harus dapat menunjukkan bagaimana arsitektur integrasi akan bekerja
dengan perimeter security dan tipe atau kategori integrasi yang akan diperlukan
untuk dapat menggunakan perimeter security feature. Perimeter security
merupakan kombinasi dari firewall, encryption, authentication services dan
arsitektur untuk melindungi enterprise terhadap kondisi dunia luar. Konfigurasi
dari perimeter security akan menentukan rancangan arsitektur integrasi yang
terkait dengan penggunaan eksternal.
Untuk menjaga keamanan sistem, diperlukan pengendalian terhadap sistem
informasi, yang mencakup beberapa kontrol (Tabel G.14), yaitu :
1. Kontrol administratif.
2. Kontrol pengembangan dan pemeliharaan sistem.
3. Kontrol operasi.
4. Proteksi terhadap pusat data secara fisik.
226
5. Kontrol perangkat keras.
6. Kontrol terhadap akses komputer.
7. Kontrol terhadap akses informasi.
8. Kontrol terhadap perlindungan terakhir.
9. Kontrol aplikasi.
Tabel G.14 Security Kontrol Definisi
Kontrol administratif
• Mempublikasikan kebijakan kontrol secara formal. • Mempublikasikan prosedur dan standar. • Perekrutan personel dengan hati-hati. • Pemisahan tugas dalam suatu pekerjaan. • Membuat rencana pemulihan terhadap bencana.
Kontrol pengembangan dan pemeliharaan sistem
• Melakukan audit terhadap proses untuk menjamin pengendalian dan penelusuran sistem.
• Mengkaji pascaimplementasi. • Memastikan pemeliharaan yang dilakukan terotorisasi. • Mengaudit dokumentasi.
Kontrol operasi
• Mengontrol akses terhadap pusat data. • Mengontrol personel pengoperasi. • Mengontrol pemeliharaan peralatan. • Mengontrol penyimpan arsip. • Melindungi virus.
Proteksi terhadap pusat data secara fisik
• Mengontrol lingkungan. • Melindungi terhadap kebakaran dan banjir. • Menyiapkan sumber listrik darurat, misal: UPS (uninterruptable
power supply).
Kontrol perangkat keras
• Menerapkan sistem komputer yang berbasis fault-tolerant (toleran terhadap kegagalan).
• Toleransi terhadap kegagalan pada penyimpan eksternal antara lain dilakukan melalui disk mirroring atau disk shadowing, yang menggunakan teknik dengan menulis seluruh data ke dua disk secara paralel.
Kontrol terhadap akses komputer
• Setiap pemakai sistem diberi otorisasi yang berbeda-beda. • Setiap pemakai dilengkapi dengan nama pemakai dan password.
Kontrol terhadap akses informasi
Penggunaan enkripsi.
Kontrol terhadap perlindungan terakhir
• Rencana darurat (emergency plan) menentukan tindakan-tindakan yang harus dilakukan oleh para pegawai manakala bencana terjadi.
• Rencana cadangan (backup plan) menentukan bagaimana pemrosesan informasi akan dilaksanakan selama masa darurat.
• Rencana pemulihan (recovery plan) menentukan bagaimana pemrosesan akan dikembalikan ke keadaan seperti aslinya secara lengkap, termasuk mencakup tanggung jawab masing-masing personil.
• Rencana pengujian (test plan) menentukan bagaimana komponen-komponen dalam rencana pemulihan akan diuji atau disimulasikan.
Kontrol aplikasi Rencana pemulihan dari bencana.
8.4 Auditing
Bagian ini akan mendefinisikan kategori untuk melakukan audit yang didasarkan
pada tipe aplikasi dan sensitivitas data yang diproses. Kategori dasar mengenai
auditing adalah :
• Level 0. Tidak memelihara informasi.
227
• Level 1. Memelihara informasi berdasarkan tipe interaksi dan partisipan.
• Level 2. Hanya memelihara instruksi untuk tiap interaksi.
• Level 3. Memelihara informasi dan setiap interaksinya secara lengkap.
Requirement kinerja dan sumber daya merupakan tradeoff dalam membuat
pembedaan untuk tiap level.
8.5 Confidentiality
Confidentiality merujuk pada level privacy yang diperlukan transmisi.
Confidentiality biasanya diterapkan pada level encryption yang digunakan, namun
harus juga dapat direfleksikan dalam alur komunikasi yang digunakan.
8.6 Nonrepudiation
Nonrrepudiation (Tabel G.15) sangatlah penting untuk transaksi B2B. Spesifikasi
tersebut harus mendefinisikan level nonrepudiation service yang diperlukan dan
tipe serta kategori aplikasi yang memerlukannya.
G.15 Nonrepudiation Tipe Nonrepudiation Tipe Aplikasi
Sesi nonrepudiated communication Integrasi aplikasi sederhana atau pertukaran data diantara aplikasi.
Layanan nonrepudiated middleware Integrasi dimana interaksi disertakan dengan infrastruktur middleware.
Nonrepudiated transaction Pemrosesan transaksi. Aksi-aksi nonrepudiated application yang terdiri atas berbagai transaksi
Proses bisnis kompleks.
9. Capacity Planning View
Bagian ini (Tabel G.16) menspesifikasikan pendekatan-pendekatan rancangan
untuk memperoleh tanggapan aplikasi tertentu, throughput, kapasitas, reliability
dan availability serta scalability. Informasi yang diperoleh dari Service Level
Requirement merupakan masukan untuk capacity planning. Tujuannya adalah
untuk mendefinisikan bagaimana seluruh service level requirement dapat
dipenuhi.
228
G.16 Capacity Planning View Requirement Pendekatan Perancangan
Availability Rencana back-up dan recovery, rencana redundancy, fail-over, disaster site.
Response time Network bandwidth, high-speed access, akses yang terlokasi, interaksi manusia yang teroptimasi, optimalisasi kinerja aplikasi, optimalisasi basis data.
Throughput Network bandwidth, high-speed access, optimalisasi kinerja aplikasi, optimalisasi basis data, kapasitas simpanan.
Turnaround time Network bandwidth, high-speed access, optimalisasi kinerja aplikasi, optimalisasi basis data, real-time alerts.
Jumlah user Connection management, caching, lokalisasi akses melalui redundant store, optimalisasi interaksi manusia, kinerja aplikasi, optimalisasi basis data.
Jumlah aplikasi yang terhubung
Point-to-pont integration dengan jumlah aplikasi 4.
Layanan-layanan transaksi
Monitor transaksi, layanan-layanan transaksi dengan aplikasi.
Persistence Storage system, kemampuan recovery dan playback, analytical tool. Directory service Directory server, administrative tool.
10. Merancang Batasan dan Tuntunan
Seluruh batasan dan tuntunan khusus untuk para arsitek, perancang dan
pengembang harus didefinisikan pada bagian ini. Sejumlah area yang perlu
dipertimbangkan dalam menetapkan batasan dan tuntunan adalah :
• Batasan kinerja yang telah diketahui.
• Formatting tuntunan untuk data.
• Batasan untuk definisi metadata dan registrasi.
• Pilihan penggunaan berbagai tipe interface.
• Kasus implementasi keamanan khusus.
• Penyimpangan terhadap arsitektur integrasi yang diperbolehkan.
11. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Arsitektur integrasi teknis menyajikan enterprise building code untuk seluruh
proyek integrasi. Arsitektur ini terdiri atas spesifikasi semua proyek yang akan
menjadi acuan saat memilih teknologi integrasi. Spesifikasi mendefinisikan
seluruh aspek arsitektur integrasi dan kemudahan akses sehingga informasi dapat
mudah ditemukan an dipahami. Arsitektur integrasi teknis dikendalikan oleh
business requirement.
230
LAMPIRAN H (SPESIFIKASI ARSITEKTUR INTEGRASI LAYANAN)
1. Pendahuluan
Spesifikasi ini menyediakan arsitektur dan tuntunan rancangan untuk menerapkan
pendekatan arsitektur berorientasi layanan untuk integrasi sistem bagi Yayasan
Pendidikan Ariyanti (YPA). Dokumen ini akan menjadi spesifikasi rancangan dan
arsitektur untuk mengembangkan aplikasi.
2. Ruang Lingkup
Ruang lingkup dari spesifikasi ini terbatas pada aplikasi atau sistem yang
memfokuskan pada fungsi utama bidang akademik dan fungsi pendukung
keuangan dan unit-unit organisasi yang terkait dengan fungsi-fungsi tersebut.
Dokumen ini mendefinisikan arsitektur dan rancangan untuk menerapkan
pendekatan arsitektur berorientasi layanan.
3. Partisipan Kunci
Partisipan kunci dalam membuat arsitektur integrasi layanan adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung
jawab terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap
mengenai partisipan kunci beserta kelompok dan peranan mereka disajikan dalam
Tabel H.1 berikut ini :
Tabel H.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
231
Pada Tabel H.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Business Event
Business event mendefinisikan aktivitas bisnis yang harus didukung oleh sistem.
Business event adalah sesuatu yang terjadi dalam business environment, terjadi
pada waktu tertentu, dan harus ditanggapi oleh sistem. Penyajian aktivitas yang
terjadi dalam bisnis dan sistem yang diperlukan untuk menanggapi dapat disajikan
dalam bentuk events table. Terdapat dua jenis event yaitu business events dan
temporal events. Business events adalah aktivitas yang terjadi dalam bisnis dan
dapat dideteksi dengan mendefinisikan setiap aktivitas bisnis dalam lingkup
sistem. Temporal events terjadi pada waktu yang telah ditetapkan. Temporal
events terjadi karena permintaan kebijakan bisnis dimana aktivitas sistem tertentu
terjadi pada waktu tertentu atau karena sistem menghasilkan output berbasis
waktu. Business events yang terkait dengan proses layanan di YPA terdapat dalam
Tabel H.2 berikut :
Tabel H.2 Business Events No.
Event Business Event Deskripsi Event Tanggapan
E1 Pengelolaan pendaftaran calon siswa dan mahasiswa baru
Event ini dimulai dari calon siswa/mahasiswa melakukan pendaftaran. Bagian Pendaftaran unit LPP dan ASM akan melakukan pendataan.
R1.1 Mendata calon siswa/mahasiswa
E2
Pengelolaan pembayaran administrasi penerimaan calon siswa dan mahasiswa baru
Event ini dimulai setelah calon siswa/mahasiswa melakukan pendaftaran. Siswa/mahasiswa diminta membayar biaya formulir pendaftaran di Bagian Pendaftaran unit LPP dan ASM. Kepala Bagian Keuangan bertanggung jawab terhadap pengelolaan pembayaran.
R2.1 Mengelola pembayaran pendaftaran calon siswa/mahasiswa
E3
Penilaian hasil Ujian Saringan Masuk (USM) seleksi calon mahasiswa baru
Event ini dimulai setelah mahasiswa melakukan pembayaran. Mahasiswa mengikuti USM dan hasilnya akan dikelola oleh Bagian Akademik unit ASM.
R3.1 Memeriksa jurusan dan program studi yang dipilih
R3.2 Mengelola hasil USM
232
Tabel H.2 Business Events (Lanjutan) No.
Event Business Event Deskripsi Event Tanggapan
E4 Pelaporan dan evaluasi penerimaan siswa dan mahasiswa baru
Event ini dilakukan secara periodik untuk melaporkan hasil penerimaan siswa/mahasiswa baru. Laporan dibuat oleh setiap bagian yang terlibat baik unit LPP maupun ASM bagi kepentingan pihak manajemen.
R4.1 Mengelola pelaporan penerimaan siswa/mahasiswa baru
E5 Penetapan kurikulum Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menghasilkan kurikulum.
R5.1 Mengelola kurikulum
E6 Penentuan dosen-dosen pengajar dan wali akademik
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menetapkan dosen pengajar dan wali akademik.
R6.1 Mengelola dosen pengajar dan wali akademik
E7 Registrasi ulang siswa dan mahasiswa
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaksanakan registrasi ulang siswa/mahasiswa.
R7.1 Memeriksa jurusan dan program studi yang dipilih
R7.2 Mengelola registrasi ulang siswa/mahasiswa
E8 Pengelolaan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM).
R8.1 Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
E9 Pelaksanaan perwalian (program D-3)
Event ini dikelola Bagian Akademik unit ASM untuk melaksanakan perwalian.
R9.1 Mengelola perwalian
E10 Pengelolaan Perubahan Rencana Studi/PRS (program D-3)
Event ini dikelola Bagian Akademik unit ASM untuk melaksanakanPerubahan Rencana Studi/PRS.
R10.1 Mengelola Perubahan Rencana Studi/PRS
E11 Pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat jadwal Kegiatan Belajar Mengajar (KBM).
R11.1 Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
E12 Pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat daftar hadir Kegiatan Belajar Mengajar (KBM).
R12.1 Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
E13 Pembuatan jadwal ujian (UTS, UAS, komprehensif)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat jadwal ujian (UTS, UAS, komprehensif).
R13.1 Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)
E14 Pembuatan daftar hadir (UTS, UAS, komprehensif)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat pembuatan daftar hadir (UTS, UAS, komprehensif).
R14.1 Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)
E15 Pemrosesan nilai Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk memproses nilai.
R15.1 Mengelola nilai
E16 Pencetakan Kartu Hasil Studi (KHS)
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk menghasilkan Kartu Hasil Studi (KHS).
R16.1 Mengelola pencetakan Kartu Hasil Studi (KHS)
E17 Pelaporan dan evaluasi kegiatan akademik
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaporkan kegiatan akademik bagi manajemen.
R17.1 Mengelola pelaporan kegiatan akademik bagi manajemen
233
Tabel H.2 Business Events (Lanjutan) No.
Event Business Event Deskripsi Event Tanggapan
E18 Pembuatan ijazah, sertifikat dan transkrip nilai
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk membuat ijazah, sertifikat dan transkrip nilai.
R18.1 Mengelola pembuatan ijazah, sertifikat dan transkrip nilai
E19 Pelaporan dan evaluasi kegiatan wisuda
Event ini dikelola Bagian Akademik unit LPP maupun ASM untuk melaporkan siswa/mahasiswa yang telah lulus.
R19.1 Mengelola pelaporan siswa/mahasiswa yang telah lulus
E20 Pengelolaan biaya pendidikan
Event ini dilakukan Bagian Keuangan untuk mengelola pembayaran biaya pendidikan.
R20.1 Mengelola pembayaran biaya pendidikan
E21 Pengelolaan honor dosen Event ini dilakukan Bagian Keuangan untuk mengelola pembayaran honor dosen.
R21.1 Mengelola pembayaran honor dosen
E22 Pelaporan dan evaluasi keuangan
Event ini dilakukan Bagian Keuangan untuk melaporkan pembayaran biaya pendidikan.
R22.1 Mengelola Pelaporan dan evaluasi keuangan
Tanggapan sistem yang didefinisikan dalam events table digunakan untuk
menentukan layanan sistem yang harus disediakan. Sejumlah layanan atau fungsi
telah ada pada sistem dan fungsionalitas lain yang baru mungkin muncul dan
harus dikembangkan serta diintegrasikan. Deskripsi layanan mendefinisikan
lingkup fungsionalitas yang diperlukan untuk melaksanakan layanan bisnis
tertentu. Untuk memaksimalkan business agility dan IT investment, business
service harus didefinisikan pada tingkatan yang mengoptimasi guna ulang (reuse).
5. Layanan
Tanggapan sistem yang telah didefinisikan pada Event Table mendefinisikan
layanan-layanan esensial yang harus disediakan oleh sistem. Sejumlah
fungsionalitas yang diperlukan yang telah ada dan fungsionalitas baru lain harus
dibangun lalu diintegrasikan. Deskripsi layanan mendefnisikan lingkup
fungsionalitas yang diperlukan untuk melaksanakan layanan bisnis tertentu.
Untuk memaksimalkan business agility dan IT investment, layanan-layanan bisnis
harus didefinisikan pada level terendah sehingga dapat mengoptimalisasi guna
ulang. Tight cohesion membuat pengelompokan yang ketat yang merelasikan
fungsi-fungsi ke dalam layanan-layanan bisnis, sedangkan loose coupling antara
layanan ukuran rancangan yang akan menghasilkan rancangan yang lebih
reusable. Deskripsi layanan harus mencakup metoda yang didukung oleh layanan,
input dan output serta deskripsi umum. Level deskripsi ini cukup untuk
234
mengembangkan Web service atau interface lainnya. Dimulai dari definisi level
bisnis, lalu diturunkan ke level yang seperlunya sehingga dapat merubah deskripsi
layanan menjadi Web service.
5.1 Tabel Kategori Layanan
Tabel kategori layanan (Tabel H.3) mendaftar seluruh tanggapan yang diperlukan
untuk business event, mendefinisikan apakah fungsi telah ada dalam satu atau
sejumlah sistem atau apakah fungsionalitas itu baru. Tabel tersebut juga
mendefinisikan layanan untuk menyediakan fungsionalitas tersebut. Layanan pada
bagian ini direka-reka berdasarkan definisi layanan dan diperbaiki lebih lanjut
pada tahapan selanjutnya. Saat mendefinisikan layanan, pikirkan modul-modul
dalam aplikasi yang telah ada yang telah melaksanakan layanan atau modul-
modul untuk pengembangan.
Tabel H.3 Kategori Layanan
Tanggapan Deskripsi Kategori Layanan Sistem yang
Telah Ada/Baru
R.1.1 Mendata calon siswa/mahasiswa
Menyediakan layanan pendataan calon siswa/mahasiswa
Pengelolaan penerimaan siswa/mahasiswa baru
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R2.1 Mengelola pembayaran pendaftaran calon siswa/mahasiswa
Menyediakan layanan pengelolaan pembayaran pendaftaran
• Pengelolaan penerimaan siswa/mahasiswa baru
• Pengelolaan keuangan
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
R3.1 Memeriksa jurusan dan program studi yang dipilih
R3.2 Mengelola hasil USM
• Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih
• Menyediakan layanan pengelolaan hasil USM
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R4.1 Mengelola pelaporan penerimaan siswa/mahasiswa baru
Menyediakan layanan pembuatan laporan PMB
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R5.1 Mengelola kurikulum
Menyediakan layanan pengelolaan kurikulum
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R6.1 Mengelola dosen pengajar dan wali akademik
Menyediakan layanan pengelolaan dosen pengajar dan wali akademik
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
235
Tabel H.3 Kategori Layanan (Lanjutan)
Tanggapan Deskripsi Kategori Layanan Sistem
yang Telah Ada/Baru
R7.1 Memeriksa jurusan dan program studi yang dipilih
R7.2 Mengelola registrasi ulang siswa/mahasiswa
• Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih
• Menyediakan layanan pengelolaan registrasi ulang
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R8.1 Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
Menyediakan layanan pengelolaan pembuatan KTS dan KTM
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R9.1 Mengelola perwalian
Menyediakan layanan pengelolaan perwalian
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R10.1 Mengelola Perubahan Rencana Studi/PRS
Menyediakan layanan pengelolaan PRS
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R11.1 Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
Menyediakan layanan pengelolaan KBM
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R12.1 Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
Menyediakan layanan pembuatan daftar hadir KBM
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R13.1 Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)
Menyediakan layanan pembuatan jadwal ujian
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R14.1 Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)
Menyediakan layanan pembuatan daftar hadir
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R15.1 Mengelola nilai Menyediakan layanan pengelolaan nilai
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R16.1 Mengelola pencetakan Kartu Hasil Studi (KHS)
Menyediakan layanan pencetakan KHS
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
236
Tabel H.3 Kategori Layanan (Lanjutan)
Tanggapan Deskripsi Kategori Layanan Sistem
yang Telah Ada/Baru
R17.1 Mengelola pelaporan kegiatan akademik bagi manajemen
Menyediakan layanan pembuatan laporan kegiatan akademik
Pengelolaan kegiatan akademik
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R18.1 Mengelola pembuatan ijazah, sertifikat dan transkrip nilai
Menyediakan layanan pembuatan ijazah, sertifikat dan transkrip nilai
Pengelolaan kegiatan wisuda
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R19.1 Mengelola pelaporan siswa/mahasiswa yang telah lulus
Menyediakan layanan pembuatan laporan siswa/mahasiswa yang telah lulus
Pengelolaan kegiatan wisuda
• Aplikasi akademik LPP
• Aplikasi akademik ASM
R20.1 Mengelola pembayaran biaya pendidikan
Menyediakan layanan pengelolaan pembayaran biaya pendidikan
Pengelolaan keuangan • Aplikasi keuangan LPP
• Aplikasi keuangan ASM
R21.1 Mengelola honor dosen
Menyediakan layanan pengelolaan honor dosen
Pengelolaan keuangan • Aplikasi keuangan LPP
• Aplikasi keuangan ASM
R22.2 Mengelola Pelaporan dan evaluasi keuangan
Menyediakan layanan pembuatan laporan keuangan
Pengelolaan keuangan • Aplikasi keuangan LPP
• Aplikasi keuangan ASM
5.2 Tabel Definisi Layanan
Tiap layanan harus diuraikan sesuai fungsi dan sistem yang digunakan untuk
mengimplementasikan fungsi tersebut. Tabel H.4 terdiri atas pengelompokkan
seluruh fungsi dan tanggapan secara bersama-sama sehingga akan membentuk
modul yang kohesif. Sebagai contoh, layanan tersebut harus mengelola sejumlah
data tertentu, atau harus melakukan layanan tertentu yang digunakan oleh aplikasi
lain. Harus terdapat loose coupling antara layanan. Tiap layanan harus
berinteraksi dengan layanan lain melalui interface yang telah terdefinisi.
Perubahan pada satu layanan akan berdampak pada fungsionalitas layanan lain.
Deskripsi yang tersedia harus dapat mendefinisikan bagaimana layanan
seharusnya diimplementasikan. Sebagai contoh :
237
• Deskripsi layanan 1. Web service yang mengabstraksi koneksi dan lookup
basis data serta mengelola pemeliharaan pencatatan konsumen, mendukung
operasi pencocokan, pembacaan, penciptaan, pembaharuan dan penghapusan.
• Deskripsi layanan 2. Interface untuk account receivable.
Tabel H.4 Kategori Layanan Layanan Fungsi Deskripsi
Telah Ada/Baru
Pengelolaan penerimaan siswa/mahasiswa baru
Mendata calon siswa/mahasiswa
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
• Pengelolaan penerimaan siswa/mahasiswa baru
• Pengelolaan keuangan
Mengelola pembayaran pendaftaran calon siswa/mahasiswa
Pengembangan middleware antar aplikasi
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
Pengelolaan kegiatan akademik
• Memeriksa jurusan dan program studi yang dipilih
• Mengelola hasil USM
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pelaporan penerimaan siswa/mahasiswa baru
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola kurikulum Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola dosen pengajar dan wali akademik
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
• Memeriksa jurusan dan program studi yang dipilih
• Mengelola registrasi ulang siswa/mahasiswa
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola perwalian Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
238
Tabel H.4 Kategori Layanan (Lanjutan) Layanan Fungsi Deskripsi
Telah Ada/Baru
Pengelolaan kegiatan akademik
Mengelola Perubahan Rencana Studi/PRS
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola nilai Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pencetakan Kartu Hasil Studi (KHS)
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan akademik
Mengelola pelaporan kegiatan akademik bagi manajemen
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan wisuda
Mengelola pembuatan ijazah, sertifikat dan transkrip nilai
Pengembangan middleware antar aplikasi
• Aplikasi akademik LPP
• Aplikasi akademik ASM
Pengelolaan kegiatan wisuda
Mengelola pelaporan siswa/mahasiswa yang telah lulus
Pengembangan middleware antar aplikasi
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
239
Tabel H.4 Kategori Layanan (Lanjutan) Layanan Fungsi Deskripsi Telah Ada/Baru
Pengelolaan keuangan
Mengelola pembayaran biaya pendidikan
Pengembangan middleware antar aplikasi
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
Pengelolaan keuangan
Mengelola honor dosen Pengembangan middleware antar aplikasi
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
Pengelolaan keuangan
Mengelola Pelaporan dan evaluasi keuangan
Pengembangan middleware antar aplikasi
• Aplikasi keuangan LPP
• Aplikasi keuangan ASM
5.3 Tabel Interface Layanan
Standar Web service (Tabel H.5) mendefnisikan bagaimana menspesifikasikan
interface, namun tidak mendefinisikan data dan fungsionalitas yang harus dimiliki
oleh interface. Service Interface Specification menyediakan informasi yang
diperlukan untuk menghasilkan Web Service atau aplikasi atau interface
komponen lainnya. Menggunakan tabel Service Definition untuk mendaftar input,
output dan metoda yang perlu didukung interface, dan menentukan bagaimana
interface akan diimplementasikan. Input harus mencakup seluruh data field
dan/atau fungsi yang harus didukung interface. Begitu pula dengan output yang
harus mencakup seluruh data field dan/atau fungsi yang harus didukung interface.
Tabel H.5 Service Interface Layanan Nama Layanan
Input • Input data master, seperti data pendaftar, data mahasiswa/siswa, data dosen, data mata kuliah, data komponen biaya.
• Input data transaksi seperti pendaftaran, pembayaran biaya pendaftaran, pembayaran biaya pendidikan, penjadwalan kegiatan belajar mengajar, penjadwalan ujian, pengelolaan nilai.
Output • Seluruh laporan yang terkait dengan kegiatan akademik. • Seluruh laporan yang terkait dengan keuangan.
Method Pengaksesan data antar basis data baik antar aplikasi akademik dan keuangan. Implementation Middleware basis data
6. Use Case
Use case mendefinisikan actor dan bagaimana mereka dapat berinteraksi dengan
layanan sistem. Actor merepresentasikan suatu peran, dapat berupa mansia,
komputer lain, bagian dari perangkat keras atau sistem perangkat lunak lain.
Mereka harus dapat menyediakan stimuli untuk menginisiasi event yang pada
240
gilirannya memerlukan tanggapan (atau layanan) dari sistem. Use case
menggambarkan behavior dari sistem saat salah satu dari actor mengirimkan
stimulus tertentu. Menggambarkan business event dan tanggapan sistem pada
stimulus event yang memicu use case-input dari dan output pada actor lain, serta
behavior yang mengkonversi input menjadi output.
6.1 Use Case Diagram
Komponen dasar dari use case diagram adalah actor, use case dan association.
Untuk menghasilkan use case, identifikasi primary actor dalam sistem, lalu
prioritaskan layanan yang akan diimplementasikan. Direkomendasikan untuk
membuat use case bagi tiap layanan yang diusulkan.
Actor
Actor digambarkan menggunakan stick figure, dan peran dari tiap user dituliskan di bawah icon tersebut. Actor dapat berupa manusia, komputer lain, bagian dari perangkat keras atau sistem perangkat lunak lain.
Use Case Use case digambarkan dengan elips. Nama dari use case ditulis di dalam elipse.
Association Association merupakan penghubung antara actor dengan use case dan mengindikasikan bahwa actor tersebut berpartisipasi dalam use case dalam berbagai bentuk.
Use case diagram dapat digunakan untuk menggambarkan keterhubungan
diantara user, event dan service. Use case mendefinisikan actor dan bagaimana
mereka berinteraksi dengan layanan sistem. Actor adalah yang melaksanakan
peran, dapat berupa manusia, komputer lain, perangkat keras atau bahkan sistem
perangkat lunak lain. Actor memberikan stimuli untuk menginisiasi event yang
memerlukan tanggapan (atau layanan) dari sistem. Use case menggambarkan
behavior dari sistem saat actor memberikan stimuli tertentu, menggambarkan
business event dan tanggapan sistem terhadap event stimulus yang memicu use
case, input dari output bagi actor lain dan behavior yang merubah input menjadi
output. Komponen dasar use case diagram adalah actor, use case dan association.
Actor digambarkan dengan simbol orang, peran dari user ditulis dibawahnya. Use
case digambarkan dengan elips, nama dari use case dituliskan di dalam elips.
Nama use case
Nama Peran Actor
241
Association digambarkan dengan garis antara actor dan use case yang
mengindikasikan bahwa actor berpartisipasi pada use case tersebut.
Siswa LPP
Mahasiswa ASM
pendataan pendaf tar
pembay aran biay a pendaf taran
pengelolaan hasil USM
pengelolaan kurikulum
pengelolaan dosen
pengelolaan jadwal kuliah
pengelolaan jadwal ujian
pengelolaan administrasi KBM
pengelolaan nilai
Pendaf tar
pemeriksaan jurusan
<<include>>
Bagian Pendaf taran
Bagian Akademik
pengelolaan perwalian/PRS
Wali Akademik
pengelolaan ijazah, sertif ikat, transkrip
pelaporan kegiatan PMB
pengelolaan pelaporan akademikBagian Akademik
pengelolaan kegiatan wisuda
Manajemen
pengelolaan KTS/KTM
pengelolaan KHS
pengelolaan registrasi ulang
<<include>>
Peserta Didik
pengelolaan pelaporan keuanganpengelolaan pembay aran biay a pendidikan
Bagian Keuangan
Dosen
pengelolaan honor dosen
Bagian Keuangan
Gambar H.1 Use Case Diagram
242
Gambar H.1 menunjukkan use case diagram yang menunjukkan keterhubungan
antara user, kejadian (event) dan layanan (service) serta mendefinisikan actor dan
bagaimana mereka berinteraksi dengan layanan-layanan yang tersedia dalam
sistem di YPA. Actor yang terlibat dan menggunakan layanan sistem adalah
pendaftar, bagian pendaftaran, bagian akademik, peserta didik, siswa LPP dan
mahasiswa ASM yang merupakan instance dari peserta didik, dosen, wali
akademik yang merupakan instance dari dosen, Kepala Bagian Keuangan serta
manajemen. Use case yang merupakan apa yang dikerjakan oleh sistem
digambarkan dalam bentuk elips, contoh use case pada Gambar H.1 adalah
pendataan pendaftar. Garis yang menghubungkan antara actor dengan use case
atau antara use case dengan use case lainnya, sebagai contoh antara actor
“pendaftar” dengan use case “pendataan pendaftar” menunjukkan adanya
hubungan atau asosiasi dan bagaimana actor terlibat dalam use case atau antara
use case.
Gambar H.1 menunjukkan adanya berbagai macam asosiasi yaitu asosiasi include
dan generalization-inheritance. Asosiasi include menunjukkan suatu use case
yang menggunakan use case lain, sebagai contoh adalah use case pengelolaan
hasil USM juga menyertakan use case pemeriksaan jurusan. Asosiasi
generalization-inheritance menunjukkan bahwa suatu use case mewarisi use case
lainnya atau suatu actor mewarisi actor lainnya, sebagai contoh adalah use case
siswa LPP dan mahasiswa ASM yang mewarisi use case peserta didik.
6.2 Spesifikasi Use Case
Spesifikasi Use case (Tabel H.6) berisi teks yang lebih jauh memberikan
gambaran mengenai user case yang telah dibuat. Spesifikasi teks biasanya
digunakan untuk menggambarkan kesalahan selama menentukan behavior
tertentu, dan aksi perbaikan apa yang harus diambil oleh sistem. Spesifikasi ini
dapat dikustomisasi atau diperluas untuk menangani isu-isu tertentu dalam
implementasi atau organisasi.
243
Tabel H.6 Spesifikasi Use Case Use Case Nama Use Case
Primary actor Bagian Pendaftaran, Pendaftar, Bagian Akademik, Dosen, Manajemen, Siswa Didik, Siswa LPP, Mahasiswa ASM, Wali Akademik, Bagian Akademik, Kepala Bagian Keuangan.
Abstract Terdiri atas sejumlah use case yaitu : pendataan pendaftar, pembayaran biaya pendaftaran, pelaporan kegiatan PMB, pemeriksaan jurusan, pengelolaan kurikulum, pengelolaan dosen, pengelolaan hasil USM, pengelolaan jadwal kuliah, pengelolaan administrasi KBM, pengelolaan KTM/KSM, pengelolaan registrasi ulang, pengelolaan nilai, pengelolaan perwalian/PRS, pengelolaan KHS, pengelolaan ijazah, sertifikat dan transkrip, pengelolaan kegiatan wisuda, pengelolaan pelaporan akademik, pengelolaan pembayaran biaya pendidikan, pengelolaan pelaporan keuangan.
Goal Integritas antar sistem dan juga dengan actor. Precondition Persiapan penerimaan pendaftaran siswa/mahasiswa. Trigger Pendaftaran siswa/mahasiswa, registrasi ulang siswa/mahasiswa,
pembayaran pendaftaran dan biaya pendidikan. Skenario umum Proses dimulai secara umum dari pengelolaan penerimaan
siswa/mahasiswa, pengelolaan kegiatan akademik, pengelolaan kegiatan wisuda dan pengelolaan keuangan.
Tanggapan/output bagi operasi yang berhasil
Jumlah tanggapan adalah 20
Ekstensi/jalur alternatif tanggapan/output bagi operasi yang tidak berhasil
-
Ketergantungan - Requirement reference - Screen reference Menu Backend reference - Catatan -
7. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Sistem yang diintegrasikan diharapkan tetap menyediakan layanan yang diminta
tanpa banyak merubah interface karena user telah terbiasa dengan interface pada
aplikasi legacy.
245
LAMPIRAN I (SPESIFIKASI ARSITEKTUR INTEGRASI INFORMASI)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan rancangan untuk menerapkan pendekatan
yang dikendalikan informasi untuk mengintegrasikan sistem bagi Yayasan
Pendidikan Ariyanti (YPA). Dokumen ini merupakan tuntunan untuk membentuk
spesifikasi arsitektur informasi bagi integrasi informasi berdasarkan aplikasi atau
informasi yang dikendalikan solusi-solusi bisnis.
2. Ruang Lingkup
Ruang lingkup dari spesifikasi informasi memfokuskan pada fungsi utama bidang
akademik dan fungsi pendukung keuangan dan unit-unit organisasi yang terkait
dengan fungsi-fungsi tersebut. Dokumen ini terdiri atas definisi informasi bisnis
yang diperlukan untuk mendasari arsitektur integrasi. Informasi bisnis meliputi
informasi yang mengalir pada fungsi akademik dan keuangan.
3. Partisipan Kunci
Partisipan kunci dalam membuat arsitektur integrasi informasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung
jawab terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap
mengenai partisipan kunci beserta kelompok dan peranan mereka disajikan dalam
Tabel I.1 berikut ini :
Tabel I.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
246
Pada Tabel I.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Pemetaan Requirement Menjadi Integrasi Informasi
Bagian ini digunakan untuk mengidentifikasi dan memetakan seluruh requirement
ke dalam pola rancangan untuk integrasi informasi (Tabel I.2). Terdapat dua pola
rancangan dasar yaitu information aggregation dan publishing. Untuk
mengidentifikasi requirement informasi bisnis yang perlu didefinisikan sebagai
bagian dari spesifikasi ini dimulai dengan Statement of Purpose dan lingkup
tanggung jawab yang terdefinisi dalam Business Strategies dan Initiatives
Specification. Lalu menggunakan pola rancangan untuk mengidentifikasi
pendekatan implementasi yang terbaik.
Tabel I.2 Pemetaan Requirement Menjadi Pola Rancangan Integrasi Informasi
Nama Aplikasi
Business Owner
Deskripsi Aplikasi
Informasi
Aggregation atau
Publishing
Sumber Data yang
Terlibat
Outcome Aliran
Informasi
Aplikasi akademik LPP
Pembantu Direktur I
Aplikasi yang mendukung fungsi akademik untuk unit LPP
Aggregation Sistem informasi akademik
Interface untuk entry data, memproses dan menghasilkan informasi akademik
Aplikasi akademik ASM
Pembantu Direktur I
Aplikasi yang mendukung fungsi akademik untuk unit ASM
Aggregation Sistem informasi keuangan
Interface untuk entry data, memproses dan menghasilkan informasi keuangan
Aplikasi keuangan LPP
Pembantu Direktur II
Aplikasi yang mendukung fungsi keuangan untuk unit LPP
Aggregation Sistem informasi akademik
Interface untuk entry data, memproses dan menghasilkan informasi akademik
Aplikasi Pembantu Direktur II
Aplikasi yang mendukung fungsi keuangan untuk unit ASM
Aggregation Sistem informasi keuangan
Interface untuk entry data, memproses dan menghasilkan informasi keuangan
247
5. Data Flow Diagram
Data Flow Diagram menggambarkan aliran informasi dalam sistem. Tujuan
pembuatan data flow diagram adalah untuk menentukan sistem mana yang terlibat
dalam pertukaran data dan kemudian menentukan integritas aturan pada sistem
(dilakukan dalam Relationship Model, bagian 7).
5.1 Context Diagram
Context diagram atau diagram konteks pada Gambar I.1 terdiri atas 4 entitas
eksternal yaitu dosen, pendaftar, siswa/mahasiswa dan manajemen. Entitas dosen
memberikan aliran data identitas dosen ke dalam sistem. Entitas pendaftar
memberikan aliran data identitas pendaftar ke dalam sistem dan menerima aliran
data bukti pembayaran dari sistem. Entitas siswa/mahasiswa menerima aliran data
Kartu Hasil Studi (KHS), ijazah, sertifikat dan transkrip nilai dari sistem.
Manajemen menerima aliran data laporan Penerimaan Mahasiswa Baru (PMB),
akademik, wisuda dan keuangan.
bukti pembayaran
data pembayaran
data mata kuliah
data dosen
data siswa_mahasiswa
form pembayaran pendaftaran
form pembayaran
nilai
nilai
khs
sertifikatijazah transkrip
laporan akademiklaporan wisuda
laporan keuangan
laporan pmb
identitas dosen
bukti pembayaran
identitas pendaftar
Pendaftar
0
Sistem Informasi Akademik YPA
+Dosen
Manajemen
Siswa_Mahasiswa
Bagian Keuangan
Bagian Akademik
Gambar I.1 Context Diagram
248
5.2 Data Flow Diagram (DFD) Level 1
Data flow diagram (diagram arus data) level 1 pada Gambar I.2 terdiri atas 4
proses yaitu pengelolaan PMB, pengelolaan kegiatan akademik, pengelolaan
wisuda dan pengelolaan keuangan. DFD level 1 terdiri atas sejumlah aliran data
yang mengakses 11 simpanan yaitu data pendaftar, pembayaran pendaftaran, hasil
usm, perwalian, kurikulum, dosen, siswa, mahasiswa, nilai, komponen biaya, dan
pembayaran biaya pendidikan.
laporan akademik
laporan wisuda
laporan pmb
laporan keuangan
Komponen BiayaKomponen Biaya
transaksi pembayaran biaya pendidikan
transaksi pembayaran
identitas pendaftar
identitas siswa
identitas dosen
nilai
trans perwalian prstrans perwalian prs
nilainilai
identitas siswa
identitas mahasiswa
identitas mahasiswa
identitas dosen
kurikulum
identitas siswa
identitas mahasiswa
identitas siswa
identitas pendaftar
identitas dosen
kurikulum
hasil usm
transaksi pembayaran
hasil usm
transaksi pembayaran
identitas pendaftar
identitas pendaftar
bukti pembayaran
identitas pendaftar
Pendaftar
1
Pengelolaan PMB
+
Data Pendaftar
Data Pembayaran Pendaftaran
Data USM
2
Pengelolaan Kegiatan Akademik
+
Data Kurikulum
Data Dosen
Data Siswa
Data Mahasiswa
3
Pengelolaan Wisuda
+
DataNilai
Perwalian PRS
Dosen
4
Pengelolaan Keuangan
Data Pembayaran Biaya Pendidikan
Data Komponen Biaya
Manajemen
Manajemen
Manajemen
Gambar I.2 DFD Level 1
249
5.3 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 1 Pengelolaan
PMB
Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses
nomor 1 yaitu proses pengelolaan PMB pada Gambar I.3 terdiri atas 4 proses
yaitu pendataan pendaftar, pengelolaan pembayaran pendaftaran, pengelolaan usm
dan pengelolaan laporan PMB. DFD tersebut terdiri atas sejumlah aliran data yang
mengakses 4 simpanan yaitu data pendaftar, hasil usm, komponen biaya dan
pembayaran pendaftaran.
[komponen biaya]
[laporan pmb]
[transaksi pembayaran]
[hasil usm]
[hasil usm]
identitas pendaftar
[transaksi pembayaran]
[bukti pembayaran]
[identitas pendaftar]
[identitas pendaftar]
[identitas pendaftar]
Pendaftar
1.1
Pendataan Pendaftar Data Pendaftar
1.2
Pengelolaan Pembayaran Pendaftaran
Data Pembayaran Pendaftaran
1.3
Pengelolaan USM Data USM
1.4
Pengelolaan Laporan PMB
Manajemen
Data Komponen Biaya
Gambar I.3 DFD Level 2 Dekomposisi Proses 1
5.4 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 2 Pengelolaan Kegiatan Akademik
Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses
nomor 2 yaitu proses pengelolaan kegiatan akademik pada Gambar I.4 terdiri atas
8 proses yaitu penetapan kurikulum, penetapan dosen/wali akademik, registrasi
ulang, pengelolaan KTS/KTM, perwalian/PRS, pengelolaan jadwal, pengelolaan
nilai dan pengelolaan laporan akademik. DFD tersebut terdiri atas sejumlah aliran
data yang mengakses 7 simpanan yaitu data pendaftar, perwalian, kurikulum,
dosen, siswa, mahasiswa dan nilai.
250
[data dosen]
[data mata kuliah]
[nilai]
[nilai]
[data siswa_mahasiswa]
[identitas mahasiswa]
[khs]
[laporan akademik]
[identitas dosen]
[trans perwalian prs]
[trans perwalian prs]
[nilai]
[nilai]
identitas dosen
identitas siswa
identitas pendaftar
kurikulum
identitas mahasiswa
kurikulum
identitas dosen
identitas mahasiswa
identitas siswa
kurikulum
identitas mahasiswa
[kurikulum]
[kurikulum]
[identitas mahasiswa]
[identitas dosen]
[identitas siswa][identitas siswa]
[identitas pendaftar]
[identitas dosen]
2.1
Penetapan Kurikulum
2.2Penetapan Dosen dan
Wali Akademik
2.3
Registrasi Ulang
2.4
Pengelolaan KTS KTM
2.5
Perwalian dan PRS
2.6
Pengelolaan Jadwal
+
2.7
Pengelolaan nilai
2.8
Pengelolaan Laporan Akademik
Data Kurikulum
Data Dosen : 1
Data Pendaftar
Data Siswa : 1
Data Mahasiswa
Data Siswa : 2
Data Dosen : 2
DataNilai : 1
DataNilai : 2
Perwalian PRS : 1
Perwalian PRS : 2
Dosen
Manajemen
Siswa_Mahasiswa
Dosen
Bagian Akademik
Bagian Akademik
Bagian Akademik
Bagian Akademik
Gambar I.4 DFD Level 2 Dekomposisi Proses 2
251
5.5 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 3 Pengelolaan Wisuda
Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses
nomor 3 yaitu proses pengelolaan kegiatan akademik pada Gambar I.5 terdiri atas
4 proses yaitu pengelolaan ijazah, pengelolaan transkrip, pengelolaan sertifikat
dan pengelolaan laporan wisuda. DFD tersebut terdiri atas sejumlah aliran data
yang mengakses 4 simpanan yaitu data kurikulum, siswa, mahasiswa dan nilai.
kurikulumkurikulum
kurikulum [kurikulum][sertifikat]
[ijazah][transkrip]
[laporan wisuda]
identitas siswa
identitas mahasiswa
nilai
identitas mahasiswa
identitas mahasiswa
identitas siswaidentitas siswa
[identitas siswa]
[identitas mahasiswa]
nilainilai[nilai]
Data Mahasiswa : 1
Data Siswa : 1
DataNilai
3.1
Pengelolaan Ijazah
3.2
Pengelolaan Transkrip
3.3
Pengelolaan Sertifikat
Data Mahasiswa
: 2
3.4Pengelolaan
Laporan Wisuda
Data Siswa : 2
Manajemen
Siswa_Mahasiswa
Siswa_Mahasiswa
Data Kurikulum : 1
Data Kurikulum : 2
Gambar I.5 DFD Level 2 Dekomposisi Proses 3
252
5.6 Data Flow Diagram (DFD) Level 3 Dekomposisi Proses 2.6 Pengelolaan Jadwal
Data flow diagram (diagram arus data) level 2 untuk mendekomposisi proses
nomor 2.6 yaitu proses pengelolaan jadwal pada Gambar I.6 terdiri atas 2 proses
yaitu pengelolaan jadwal kuliah dan ujian. DFD tersebut terdiri atas sejumlah
aliran data yang mengakses 2 simpanan yaitu data kurikulum dan dosen.
kurikulumidentitas dosen
[kurikulum][identitas dosen]
Data Dosen Data Kurikulum
2.6.1
Pengelolaan Jadwal Kuliah
2.6.2
Pengelolaan Jadwal Ujian
Gambar I.6 DFD Level 3 Dekomposisi Proses 2.6
6. Metadata Model
Tiap aplikasi memerlukan model metadata (Tabel I.2) yang mengkombinasikan
model baru untuk aplikasi dengan model yang telah ada pada masing-masing
sumber data yang digunakan. Metadata model digunakan untuk mendefinisikan
aturan pengaksesan dan transformasi, menetapkan turunan data dan
memungkinkan analisis dampak. Metadata untuk sumber data yang telah ada
harus ditangkap dari tiap elemen.
253
Tabel I.2 Pemetaan Requirement Menjadi Pola Rancangan Integrasi Informasi
Nama elemen data
Pendaftar, pembayaran biaya pendaftaran, jadwal USM, hasil USM, registrasi ulang siswa/mahasiswa baru, program studi, jurusan, ruang belajar, periode semester, registrasi ulang siswa/mahasiswa lama, siswa/mahasiswa, mata kuliah, dosen, alokasi kelas, perwalian, jadwal kuliah, berita acara kuliah, jadwal ujian, berita acara ujian, nilai, ijazah dan sertifikat, pangsa pasar, target, alumni, perusahaan, komponen biaya, pembayaran biaya pendidikan, piutang siswa/mahasiswa
Sumber data Dari entitas luar yaitu pendaftar, dosen, siswa, mahasiswa dan manajemen; dari hasil pemrosesan sistem lain.
Deskripsi Entitas-entitas data master diintegrasikan dengan tujuan menghilangkan redundansi, inkonsistensi dan data yang terisolasi
Tipe dan format data
Disesuaikan dengan Clipper 5.2 dan SQL Server 2000
Nama kanonik
Integrasi enterprise
Format kanonik
SQL
Basic metadata
Aturan transformasi
Dari sumber ke format kanonik
Interface SQL
Semantic metadata
Aturan integritas
Penggunaan middleware untuk menghubungkan data (pendaftar, siswa, mahasiswa, dosen, komponen biaya) sesuai dengan skema relasi pada Gambar G.4
Keamanan tambahan
Parameter keamanan
Daftar kontrol akses, directory
Platform
1. Microcomputer a. PC Server (Intel) b. PC Client (Intel)
2. Perangkat input (input device) c. Mouse d. Keyboard e. Scanner
3. Perangkat Output dan Tampilan Grafis (output & graphics display) a. Line printer b. Dot matrix printer c. Monitor d. Speaker
4. Media Simpanan (storage media) a. Floppy Disk b. Harddisk c. Compact Disk (CD)
Removeable disk
OS Server : Windows Server 2000, Client : Windows XP, Windows 2000 Professional, Windows Vista
DBMS Clipper 5.2, SQL Server 2000 Manajemen tambahan
Platform aplikasi
1. Sistem Operasi (operating system) a. Microsoft Windows 2000 Server b. Microsoft Windows 2000 Professional c. Microsoft Windows XP d. Microsoft Windows Vista
2. Sistem Pengelola Basis Data (Database Management System) a. Microsoft Access b. SQL Server
3. Bahasa Pemrograman (language) a. Clipper b. Visual Basic
4. Spreadsheet Microsoft Excel
5. Pengolah kata Microsoft Word
6. Presentasi Microsoft Power Point
7. Pengolah Gambar a. Corel Draw
254
Tabel I.2 Pemetaan Requirement Menjadi Pola Rancangan Integrasi Informasi (Lanjutan)
Platform aplikasi
b. Microsoft Visio 8. Pengolah Foto
Adobe Photoshop 9. Software lain
a. Anti virus (McAfee, Antivir, AVG) b. Internet Explorer c. Total Commander d. Nero e. Adobe Acrobat Reader f. Winzip
Pemilik sistem
Yayasan Pendidikan Ariyanti, Unit Akademik LPP dan ASM, Unit Keuangan LPP dan ASM
Lokasi sistem Bagian akademik dan keuangan LPP serta ASM Informasi layanan
Web service directory
Informasi skema message
Message repository
7. Model Keterhubungan
Relationship table (Tabel I.3) mendefinisikan pemetaan data antara aplikasi baru
dengan sistem yang telah ada juga aturan integritas antar obyek dan sistem data.
Perlu dicatat bahwa sistem/layanan dan nama elemen data sumber yang disertakan
di sini untuk menyediakan turunan. Sistem/layanan disertakan sehingga
memungkinkan analisis terhadap dampak. Business rule meliputi aggregation dan
penguraian aturan tertentu pada aliran data.
Tabel I.3 Model Keterhubungan Nama kanonik Integrasi aplikasi Nama elemen data sistem/layanan sumber
Pendaftar, siswa, mahasiswa, dosen, komponen biaya
Sistem/layanan sumber Aplikasi akademik dan keuangan Business rule Aturan aggregation dan parsing Nama elemen data sistem atau elemen target
Pendaftar, siswa, mahasiswa, dosen, komponen biaya
Sistem atau layanan target Aplikasi akademik dan keuangan Aturan integritas Aturan rollback dan kompensasi Requirement keamanan Aturan enkripsi, nonrepudiation dan akses
8. Review Rancangan Informasi
Review rancangan informasi sangatlah kritis bagi kesuksesan dan agility pada
sistem. Review rancangan harus meliputi seluruh stakeholder yang relevan,
didefinisikan berdasarkan partisipan kunci. Seluruh bagian dari model perlu di-
review dan diverifikasi. Para partisipan perlu memverifikasi porsi informasi yang
menjadi tanggung jawab mereka, termasuk definisi seluruh elemen, bagaimana
255
diciptakan dan di-update, format serta mekanisme akses. Business user harus
menyediakan definisi informasi yang diperlukan dalam aplikasi baru. Lebih lanjut,
menjadi hal yang kritikal bagi para stakeholder untuk memastikan bagaimana
mereka dapat menghadapi pertentangan pada sumber data yang mengandung
“standar emas” bagi organisasi saat terjadi konflik atau duplikasi. Hal ini
seringkali menjadi tugas yang sulit yang harus dihadapi oleh tim. Seluruh proses
harus di-review untuk mencari peluang bagi peningkatan konsistensi dan kualitas
informasi pada organisasi.
Tuntunan berikut ini dapat dipergunakan untuk dapat mencapai keberhasilan
design review :
• Pastikan bahwa seluruh stakeholder hadir.
• Jelaskan proses dan aturan-aturan mendasar sebelum memulai design review.
• Kritisi rancangannya, dan bukan orangnya.
• Perancang diperbolehkan hanya melakukan klarifikasi rancangan dan
menyediakan informasi background. Mereka harus dapat “mempertahankan”
rancangannya.
• Identifikasi sistem perekaman informasi.
• Definisikan proses untuk kualitas data.
9. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Data dan informasi merupakan hal yang penting dalam proyek integrasi. Integrasi
dihadapkan pada permasalahan mengkomunikasikan pertukaran data yang
memiliki tipe dan format berbeda. Arsitektur integrasi informasi diharapkan dapat
mendefinisikan infrastruktur dan proses yang memungkinkan informasi yang
mengalir antar seluruh unit akademik dan keuangan di YPA. Pendefinisian
informasi yang tidak tergantung pada suatu teknologi atau tool tertentu sangatlah
baik untuk menjaga long-term agility dan reuse.
257
LAMPIRAN J (SPESIFIKASI ARSITEKTUR INTEGRASI PROSES)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan rancangan dalam menerapkan pendekatan
yag dikendalikan proses untuk integrasi sistem bagi Yayasan Pendidikan Ariyanti
(YPA). Dokumen ini adalah tuntunan untuk menghasilkan spesifikasi proses
untuk composite application atau proses yang dikendalikan solusi bisnis.
2. Ruang Lingkup
Ruang lingkup spesifikasi proses terbatas pada proyek integrasi pada fungsi utama
bidang akademik dan fungsi pendukung keuangan dan unit-unit organisasi yang
terkait dengan fungsi-fungsi tersebut. Dokumen ini mendefinisikan proses bisnis
dan arsitektur integrasi yang mendasarinya.
3. Partisipan Kunci
Partisipan kunci dalam membuat arsitektur integrasi informasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung
jawab terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap
mengenai partisipan kunci beserta kelompok dan peranan mereka disajikan dalam
Tabel J.1 berikut ini :
Tabel J.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
Pada Tabel J.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
258
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Deskripsi Proses Bisnis
Bagian ini mengidentifikasi dan menggambarkan seluruh proses bisnis yang telah
teridentifikasi dalam requirement (Tabel J.2). Nama dan pemilik bisnis
mengidentifikasi tiap proses bisnis. Deskripsi proses disediakan bersama dengan
event yang memulai proses, business service yang menjadi bagian dari proses dan
outcome yang diharapkan bagi akhir suatu proses. Jika tidak ada layanan yang
didefinisikan, maka definisikan fungsi yang dilakukan sebagai bagian dari proses.
Untuk mengidentifikasi proses bisnis yang perlu didefinisikan sebagai bagian dari
spesifikasi ini, mulai dengan Statement of Purpose dan lingkup tanggung jawab
yang terdefinisi dalam Business Strategies dan Initiative Specification.
Tabel J.2 Deskripsi Proses Bisnis Nama Proses Bisnis
Pemilik Proses Bisnis
Deskripsi Proses Bisnis
Kickoff Event
Layanan yang Terdapat
dalam Proses
Outcome Proses Bisnis
Proses bisnis akademik dan keuangan YPA
Dosen, Calon Siswa/Mahasiswa, Siswa/Mahasiswa, Mentor, Kepala Bagian Keuangan, Bagian Akademik, Dosen Wali, Wali Kelas, Manajemen
Diuraikan secara terinci pada bagian setelah Gambar J.1
Pengisian formulir pendaftaran
• Isi formulir pendaftaran
• Pengelolaan pembayaran pendaftaran dan biaya pendidikan
• Input data pendaftar
• Pengelolaan kas masuk dan keluar
• Pemeriksaan status keuangan siswa/mahasiswa
• Pembuatan surat tagihan tunggakan
• Pengelolaan pembayaran honor dosen
• Pembuatan laporan keuangan
• Perwalian • Pengelolaan
KBM • Pengelolaan
ujian
• Laporan akademik
• Laporan keuangan
259
Tabel J.2 Deskripsi Proses Bisnis (Lanjutan) Nama Proses Bisnis
Pemilik Proses Bisnis
Deskripsi Proses Bisnis
Kickoff Event
Layanan yang
Terdapat dalam Proses
Outcome Proses Bisnis
Proses bisnis akademik dan keuangan YPA
Dosen, Calon Siswa/Mahasiswa, Siswa/Mahasiswa, Mentor, Kepala Bagian Keuangan, Bagian Akademik, Dosen Wali, Wali Kelas, Manajemen
Diuraikan secara terinci pada bagian setelah Gambar J.1
Pengisian formulir pendaftaran
• Pengelolaan nilai
• Pengelolaan wisuda
• Pembuatan laporan akademik
• Evaluasi laporan akademik dan keuangan
• Laporan akademik
• Laporan keuangan
5. Model Aliran Proses
Model aliran proses merupakan kombinasi dari event yang memulai proses, actor
yang terlibat pada proses, layanan yang disediakan oleh komponen software
dalam sistem, message yang dilewatkan antara layanan, dan business rule yang
mengontrol aliran proses. Tiap model aliran proses memiliki deskripsi pada tiap
entitas, juga diagram proses.
Arsitektur integrasi proses juga penting dalam rangka penyelarasan antara
teknologi informasi dengan bisnis yang dimulai dengan pemodelan proses bisnis
yang dapat dipahami oleh para pelaku bisnis sehingga terdapat kesepahaman
antara staf IT dengan pelaku bisnis. Proses lalu diotomatisasi berdasarkan model
teresbut. Hal ini akan mengurangi adanya salah interpretasi terhadap business
requirement atau kesalahan proses. Proses dapat tersebar diantara unit bisnis
sehingga tidak hanya satu atau sekelompok orang saja yang memiliki suatu end-
to-end process. Model proses akan menyajikan pemahaman mengenai bagaimana
bisnis dilakukan di dalam enterprise dan harus dikelola sebagai aset yang bernilai.
Proses bisnis (Gambar J.1) dimulai ketika calon siswa/mahasiswa mengajukan
permohonan menjadi siswa/mahasiswa dengan mengisi formulir pendaftaran
disertai dengan pembayaran biaya formulir di Bagian Pendaftaran (Mentor).
Bagian Pendaftaran lalu memasukkan data di formulir pendaftaran dan
pembayaran biaya formulir ke aplikasi keuangan.
261
Setelah formulir yang telah terisi diserahkan ke Bagian Pendaftaran, calon
mahasiswa mengikuti Ujian Saringan Masuk (USM). Jika lulus, maka mahasiswa
ASM menyerahkan biaya pendidikan semester 1 (angsuran 1) dan uang seragam di
Kepala Bagian Keuangan serta mengisi fomulir biodata dan menyerahkan biodata
tersebut ke Bagian Akademik. Sedangkan siswa LPP tidak mengikuti ujian saringan
masuk. Kepala Bagian Keuangan akan memasukkan transaksi pembayaran ke
komputer lalu memberikan bukti pembayaran rangkap ke-1 (bukti pembayaran
adalah 3 rangkap, rangkap ke-2 dilampirkan dalam laporan keuangan periodik,
sedangkan rangkap ke-3 diarsip) dan formulir Kartu Rencana Studi (KRS) kosong 3
rangkap pada mahasiswa. Formulir KRS yang diterima oleh mahasiswa tersebut akan
digunakan untuk melakukan perwalian dengan dosen wali. KRS yang telah terisi
akan didistribusikan, rangkap 1 dipegang oleh Bagian Akademik, rangkap 2
dipegang oleh dosen wali, sedangkan rangkap 3 dipegang oleh mahasiswa.
Berdasarkan formulir biodata yang masuk, Bagian Akademik mengukur seragam,
kemudian memasukkan data mahasiswa baru dan menetapkan Nomor Induk
Mahasiswa (NIM) atau Nomor Induk Siswa (NIS) di aplikasi akademik sehingga
status calon siswa/mahasiswa berubah menjadi siswa/mahasiswa. Kepala Bagian
Keuangan akan memeriksa apakah data keuangan di komputer sama dengan jumlah
uang fisik dan kwitansi pembayaran yang diperoleh. Setelah dilakukan pemeriksaan,
maka uang fisik diserahkan ke bank dan Kepala Bagian Keuangan melakukan
pengelolaan kas pada aplikasi keuangan.
Pada tahun akademik berjalan, Bagian Akademik melakukan beberapa kegiatan yang
terkait dengan belajar mengajar, yaitu :
1. Menetapkan wali kelas/dosen wali.
2. Menetapkan dosen-dosen pengajar dengan terlebih dahulu melakukan rapat
koordinasi dan menerbitkan SK mengajar.
3. Mengalokasikan mata kuliah (baik tetap berdasarkan paket maupun tambahan
seperti beauty class, table manner, berbagai seminar dan pelatihan). Untuk
semester 1 dan 2, mata kuliah yang diambil siswa/mahasiswa berupa mata kuliah
paket, sedangkan untuk mahasiswa mulai semester 3 sampai dengan 6 dapat
262
mengambil mata kuliah pada semester sebelum atau sesudahnya dengan
ketentuan bahwa mata kuliah di semester ganjil hanya dapat diambil di semester
ganjil, dan begitu juga mata kuliah di semester genap hanya dapat diambil di
semester genap.
4. Mengalokasikan kelas berdasarkan mata kuliah dan jumlah siswa/mahasiswa
yang mengambil mata kuliah.
5. Menerbitkan Kartu Tanda Siswa (KTS)/Kartu Tanda Mahasiswa (KTM), Kartu
Peserta Ujian (KPU), Kartu Hasil Studi (KHS), transkrip nilai dan sertifikat bagi
siswa/mahasiswa.
6. Membuat daftar hadir kuliah, UTS dan UAS bagi siswa/mahasiswa serta dosen.
7. Menerbitkan surat yang terkait dengan kegiatan akademik baik bagi orang tua
siswa/mahasiswa, dosen maupun instansi/perusahaan.
Pelaksanaan UTS adalah pada pertemuan ke 7 sedangkan UAS pada pertemuan ke
14 tahun akademik berjalan. Setelah penyelenggaraan UTS dan UAS, dosen diberi
waktu 1 minggu untuk mengoreksi nilai dan mengisikan nilai pada daftar hadir nilai
UTS atau UAS yang terdiri dari 3 rangkap, rangkap 1 dan 2 untuk Bagian Akademik
sedangkan rangkap ke-3 dipegang oleh dosen yang bersangkutan. Bagian Akademik
mengumumkan nilai dari nilai rangkap ke-2, sedangkan rangkap ke-1 digunakan
untuk memasukkan nilai ke aplikasi akademik dan diberikan ke Kepala Bagian
Keuangan untuk perhitungan honor ujian, kemudian diarsip. Pada akhir semester,
Bagian Akademik akan memberikan kartu hasil studi (KHS) bagi siswa/mahasiswa
dan juga wali kelas/dosen wali. Dosen wali memasukkan nilai yang tertera di KHS
ke kartu kuning sehingga dapat dijadikan dasar untuk melakukan perwalian semester
yang akan datang. Selain KHS, hasil kemajuan akademik siswa/mahasiswa juga
dihasilkan dalam bentuk transkrip nilai. Perbedaan antara KHS dan transkrip nilai
adalah KHS diterbitkan untuk menunjukkan prestasi akademik satu semester terakhir
yang telah ditempuhnya, sedangkan transkrip nilai diterbitkan untuk menunjukkan
prestasi akademik keseluruhan semester (dari semester satu sampai dengan semester
terakhir yang telah ditempuhnya).
263
Setiap semester, Kepala Bagian Keuangan melakukan penagihan biaya pendidikan
sebanyak 3 kali yaitu di awal semester, menjelang UTS dan menjelang UAS melalui
surat penagihan angsuran biaya pendidikan untuk mahasiswa. Saat mahasiswa
membayar, maka Kepala Bagian Keuangan akan memasukkan data pembayaran ke
aplikasi keuangan dan memberikan bukti pembayaran rangkap ke-1 (bukti
pembayaran adalah 3 rangkap, rangkap ke-2 dilampirkan dalam laporan keuangan
periodik, sedangkan rangkap ke-3 diarsip). Selain mengelola pemasukan dari
siswa/mahasiswa, Kepala Bagian Keuangan juga mengelola pengeluaran seperti
pembayaran honor/gaji dosen baik tetap maupun luar biasa yang dilakukan setiap
bulan. Bagian akademik dan keuangan setiap bulan secara periodik melaporkan
kegiatan akademik dan laporan keuangan kepada pihak manajemen yaitu Pembantu
Direktur I dan II untuk kemudian diteruskan ke Direktur.
6. Review Rancangan Proses
Review rancangan proses kritikal bagi kesuksesan dan agility sistem. Review
rancangan harus meliputi seluruh stakeholder yang relevan, didefinisikan
berdasarkan partisipan kunci. Seluruh bagian dari model perlu di-review dan
diverifikasi. Para partisipan perlu memverifikasi porsi proses yang menjadi tanggung
jawabnya, termasuk seluruh tugas, fungsi dan/atau layanan, input untuk dan output
dari tiap layanan, keputusan yang bersamaan dengan proses, business rules yang
menentukan aliran proses, juga seluruh aturan pengecualian dan kompensasi. Seluruh
proses harus di-review untuk mendapatkan peluang mengurangi waktu dan biaya
serta meningkatkan fleksibilitas dan manfaat bisnis.
7. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Tujuan integrasi adalah untuk mendukung proses bisnis sehingga dapat
meningkatkan efisiensi bisnis. Integrasi pada tingkatan proses mendefinisikan
interaksi pada sistem melalui pendefinisian workflow bisnis. Meskipun arsitektur
integrasi proses merupakan langkah terakhir yang perlu didefinisikan dalam siklus
integrasi, namun sangatlah penting bahkan menjadi titik tolak solusi integrasi. Solusi
integrasi dapat menggabungkan berbagai style integrasi.
265
LAMPIRAN K (SPESIFIKASI IMPLEMENTASI INTEGRASI APLIKASI)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan implementasi dalam pengembangan integrasi
aplikasi. Integrasi aplikasi menyajikan pemecahan permasalahan sehingga dua
aplikasi atau lebih dapat berkomunikasi untuk menyelesaikan tugas tertentu.
Beberapa jenis permasalahan yang termasuk ke dalam integrasi aplikasi yaitu :
a. Mengkoordinasikan aksi dan mereplikasi transaksi pada berbagai aplikasi.
b. Membuka legacy system dan memperluasnya menjadi berbasis Web.
c. Membuat user interface baru.
d. Transaksi business-to business.
e. Menyebarkan aplikasi dalam bentuk yang dapat diakses oleh beragam perangkat
mobile atau hend-held device.
Dokumentasi ini juga menggambarkan permasalahan teknis yang terkait dengan
implementasi dan menyediakan konteks implementasi secara spesifik.
Manfaat dari integrasi enteprise dapat direalisasikan saat suatu organisasi
menggunakan strategi bisnis untuk mengendalikan strategi dan arsitektur integrasi.
Berdasarkan hasil analisis terhadap as-is system, diperoleh hasil bahwa fungsi utama
yaitu akademik dan juga fungsi pendukung keuangan masing-masing telah didukung
oleh 4 kelompok aplikasi. Pada perjalanannya, aplikasi-aplikasi tersebut dibuat oleh
sejumlah vendor dalam rentang waktu yang berlainan sehingga berdampak pada
perbedaan teknologi mulai dari bahasa pemrograman, database management system
sampai dengan teknologi perangkat keras yang mendukungnya. Sedangkan
identifikasi terhadap kebutuhan sistem mendatang (to-be system) menuntut adanya
integritas diantara sejumlah entitas data serta aplikasi yang mengelolanya. Sebagian
besar data, aplikasi serta teknologi saat ini dinyatakan telah dapat memenuhi
kebutuhan bisnis baik saat ini maupun untuk masa mendatang, namun perlu
dilakukan optimalisasi.
267
Kesenjangan (gap) diantara kondisi as-is dengan to-be menunjukkan bahwa
optimalisasi yang dimaksud adalah melakukan kegiatan integrasi. Berdasarkan
kesenjangan antara as-is dan to-be serta adanya pengendali serta requirement bisnis
mengenai integrasi, maka dibuat kebijakan untuk membuat arsitektur integrasi dan
melakukan implementasi integrasi. Kegiatan integrasi dibagi ke dalam kegiatan
stratejik dan taktis.
Kegiatan stratejik pertama dalam proyek integrasi adalah pembentukan arsitektur
integrasi teknis, yang pembahasannya telah dilakukan pada lampiran G. Hasil dari
dokumentasi tersebut digunakan pada bagian ini sebagai dasar untuk melakukan
kegiatan taktis yaitu mengimplementasikan integrasi aplikasi. Gambar K.1
menunjukkan bagaimana hasil analisis kondisi saat ini digunakan untuk menentukan
kebutuhan sistem mendatang. Berdasarkan kebijakan yang diperoleh sebagai hasil
identifikasi terhadap kesenjangan serta adanya pengendali dan requirement bisnis
maka dilakukan kegiatan stratejik dan taktis integrasi teknis.
2. Ruang Lingkup
Ruang lingkup spesifikasi integrasi aplikasi terbatas pada aplikasi yang
diintegrasikan yaitu aplikasi akademik dan keuangan LPP serta ASM. Spesifikasi ini
meliputi unit organisasi, user dan aplikasi yang dilibatkan serta hasil akhir yang
diharapkan.
3. Partisipan Kunci
Partisipan kunci dalam mengimplementasikan integrasi aplikasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung jawab
terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap mengenai
partisipan kunci beserta kelompok dan peranan mereka disajikan dalam Tabel K.1
berikut ini :
268
Tabel K.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
Pada Tabel K.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Pola dan Layanan Implementasi Integrasi Aplikasi
Terdapat sejumlah pola implementasi dasar untuk solusi integrasi aplikasi, namun
bagian ini hanya mendefnisikan pola tertentu yang digunakan dan menyediakan
konfigurasi komponen implementasi tertentu. Pola-pola integrasi yang banyak
digunakan diantaranya :
a. Message broker
b. Enterprise Service Bus (ESB)
c. Legacy integration
d. B2B integration
e. Portal
f. Mobile integration
4.1 Message Broker
Message broker cocok digunakan untuk mengkoordinasikan berbagai aplikasi,
replikasi sejumlah transaksi dan untuk aplikasi B2B. Implementasi message broker
terdiri atas integration hub yang menyediakan layanan transformasi untuk
mengkonversi message menjadi format yang tepat bagi aplikasi penerima. Broker
menyediakan intelligent routing untuk mengelola kompleksitas perpindahan message
269
antar aplikasi serta translasi dan transformasi yang pada umumnya melalui
proprietary graphical-mapping tool. Adapter menyediakan interface ke dalam
aplikasi dan menjadi titik dimana aplikasi dapat saling mengirim dan menerima
message. Pola integrasi ini tidak digunakan untuk kasus YPA.
4.2 ESB
Enterprise Service Bus (ESB) lebih fleksibel dan scalable dibandingkan dengan
message broker, namun lebih kompleks untuk diimplementasikan, bahkan sampai
saat ini masih belum terdapat standar yang diterima secara luas oleh dunia industri.
Web service membuat service bus menjadi pendekatan yang lebih komersial bagi
integrasi aplikasi. Pada dasarnya, ESB memecahkan permasalahan bisnis yang sama
dengan message broker, namun memiliki arsitektur yang berbeda.
ESB menyediakan layanan konektivitas, meliputi transport protocol, message
protocol, message routing dan guaranteed delivery. ESB juga menyediakan sejumlah
transformasi data dasar seperti translasi XML melalui XSLT style sheet, namun untuk
transformasi data yang kompleks diperlukan tool translasi dan transformasi tambahan.
ESB memiliki adapter atau connector ke dalam aplikasi yang menyediakan interface
aplikasi sebagai metoda komunikasi. Interface ini menyediakan layanan yang
kemudian dapat diregistrasi ke dalam directory. Request dapat disimpan ke dalam
lokasi tertentu atau diarahkan berdasarkan aturan tertentu. Pola integrasi ini tidak
digunakan untuk kasus YPA.
4.3 Legacy Integration
Tujuan dari integrasi legacy adalah mengintegrasikan data, aplikasi atau proses
legacy tanpa melakukan perubahan terhadap aplikasi legacy. Hal ini dapat dilakukan
dengan membuat interface baru pada legacy system. Bagian ini mendefinisikan tipe
interface yang dapat digunakan, yaitu :
a. Database interface. Merupakan adapter pada level basis data yang
memungkinkan front-end application mengakses data dengan database call
native, seperti JDBC, ODBC dan ADO.
270
b. Messaging interface. Suatu message interface dapat digunakan jika suatu
integrasi mengikutsertakan pemrosesan transaksi. Interface ini meliputi
connector untuk JCA dan SOAP messaging, atau solusi tertentu seperti IBM MQ
Series dan TIBCO Rendezvous pada mainframe.
c. Screen/report interface. Seringkali, satu-satunya cara untuk mengakses data
mainframe adalah melalui screen interface atau report interface, yang juga
disebut dengan screen scraping atau report scraping. Kedua interface ini
memiliki cara kerja yang sama, didefinisikan untuk mengekstraksi informasi ke
dalam layar atau laporan. Teknologi interface menangkap bit-bit data dan
mengarahkannya kepada Web browser.
d. Service interface. Interface level layanan, juga disebut dengan legacy wrapping,
memungkinkan proses dan fungsi-fungsi mainframe dikemas dengan interface
Web service, .Net, Java atau CORBA. Interface Web service bagi proses dan
layanan mainframe menyediakan metoda untuk integrasi legacy yang paling
adaptable dan reusable, namun memiliki initial investment yang paling tinggi.
Pola integrasi dengan legacy integration dapat dilihat pada Gambar K.2.
Gambar K.2 Pola Legacy Integration (4)
Permasalahan yang terjadi pada tingkatan teknis di YPA menunjukkan bahwa
diperlukan integrasi antar aplikasi legacy yang menitikberatkan integrasi pada level
data. Berdasarkan alasan inilah maka diperlukan adapter pada level basis data yang
memungkinkan front-end application mengakses data dengan database call native,
menggunakan Data Source Open Database Connectivity (ODBC) dan ActiveX Data
Object (ADO).
271
Tabel K.2 menyediakan definisi layanan untuk melakukan integrasi legacy, yang
terdiri atas layanan integrasi, nama vendor atau produk, serta implementasi.
Tabel K.2 Implementasi Integrasi Legacy Layanan Integrasi
Vendor/Produk/Kustomisasi Implementasi
Data interface ODBC, ADO Open Database Connectivity (ODBC), ActiveX Data Object (ADO)
Message interface - - Screen/report interface
- Menyediakan seluruh informasi akademik dan keuangan
Service interface - Layanan kegiatan akademik dan keuangan
4.3.1 Penggunaan Data Source ODBC untuk Kasus YPA
Untuk kasus di YPA, pengaksesan berbagai macam sistem manajemen basis data
yang dikelola oleh Clipper dan SQL Server dapat menggunakan Data Source Open
Database Connectivity (ODBC) sehingga aplikasi legacy yang sama mampu
mengakses basis data berformat *.dbf (untuk Clipper) dan juga basis data SQL
Server. Hal ini dapat dilakukan dengan menambahkan komponen-komponen
software yaitu driver ke dalam sistem. Penambahan dan pengkonfigurasian driver-
driver tersebut, dilakukan melalui data source.
4.3.2 Membuka Data Source (ODBC)
Membuka data source (ODBC) dapat dilakukan dengan langkah-langkah berikut ini:
1. Pada taskbar, klik Start, lalu klik Control Panel.
2. Klik ganda Administrative Tool, perhatikan Gambar K.3.
Gambar K.3 Administrative Tool
3. Klik ganda icon Data Source (ODBC), maka akan muncul ODBC Data Source
Administrator seperti Gambar K.4.
272
Gambar K.4 ODBC Data Source Administrator
4.3.3 Membuat Driver Baru
Bila ingin menambahkan driver baru ke dalam sistem melalui ODBC dengan
menggunakan System DSN, maka dapat dilakukan langkah-langkah berikut ini :
1. Pada kotak dialog ODBC Data Source Administrator, buka tab System DSN, lalu
klik Add. Perhatikan Gambar K.5.
Gambar K.5 Tab System DSN pada ODBC Data Source Administrator
2. Akan muncul kotak dialog Create New Data Source yang menyediakan pilihan
driver yang akan digunakan, perhatikan Gambar K.6. Untuk mengkoneksikan
dengan SQL Server, pilih SQL Server. Pilih Finish.
273
Gambar K.6 Create New Data Source
3. Isi Name, Description (opsional) dan Server penghubung ke SQL Server.
Perhatikan Gambar K.7. Klik Next.
Gambar K.7 Create New Data Source to SQL Server
4. Bila server SQL Server tidak menggunakan login user dan password, maka pilih
With Windows NT authentication using then network login ID. Hal ini akan
menyebabkan pengaksesan terhadap akses secara otomtais saat login ke sistem
operasi. Namun jika sebaliknya, maka harus mengisi Login ID dan Password.
Perhatikan Gambar K.8. Klik Next.
274
Gambar K.8 Create New Data Source to SQL Server
5. Langkah berikutnya adalah menentukan basis data yang digunakan, lalu klik
Next dan Finish. Akan muncul kotak dialog untuk menguji basis data dengan
cara memilih Test Data Source.
6. Bila koneksi ODBC yang dibuat berhasil, maka akan muncul pesan pada kotak
dialog SQL Server ODBC Data Source Test. Klik OK, dan akan kembali ke
kotak dialog ODBC Data Source dengan penamaan koneksi yang telah dibuat.
Klik OK untuk keluar dari jendela koneksi ODBC.
4.4 B2B Integration
Integrasi B2B biasanya meliputi layanan integrasi aplikasi, namun menambah
layanan lain yang diperlukan untuk melakukan integrasi dengan aplikasi di luar
organisasi, seperti :
a. B2B connectivity melalui B2B server atau pertukaran eksternal.
b. Berbagai konektivitas untuk partner, seperti Edi, HTML, XML dan FTP.
c. Pengamanan B2B tambahan untuk transaksi enkripsi, autentifikasi pengirim dan
memastikan tidak adanya penolakan transaksi.
d. Manajemen partner, meliputi proses, business rule dan service level
management.
Pola integrasi ini tidak digunakan untuk kasus YPA.
275
4.5 Portal
Portal menyediakan integrasi yang dimaksudkan untuk memperluas fungsionalitas
mainframe menjadi Web dan menyediakan customer-facing application. Terdapat
banyak cara untuk menyediakan layanan integrasi portal, dapat berupa koneksi
point-to-point bagi tiap aplikasi yang diintegrasikan dengan penggunaan API,
interface basis data, Web service atau adapter. Portal dapat menjadi bagian dari
solusi server aplikasi dan server aplikasi tersebut dapat menyediakan layanan-
layanan integrasi. Message broker dan ESB dapat menyediakan layanan integrasi
bagi portal. Saat portal memerlukan pengaksesan secara real-time terhadap data
enterprise yang diagregasi, maka dapat digunakan Enterprise Information
Integration (EII). Lebih lanjut, jika portal mendukung transaksi bisnis dan juga data
aggregation, maka dapat digunakan beragam teknologi. Pola integrasi ini tidak
digunakan untuk kasus YPA.
4.6 Mobile Integration
Pola mobile integration serupa dengan integrasi B2B. Terdiri atas integrasi back-end
application dan server integrasi mobile dapat mengambil informais yang sama dari
berbagai sistem sumber lalu menyesuaikan format bagi berbagai piranti target secara
fleksibel. Reliability dan security mrupakan kunci dalam mobile integration
dikarenakan jaringan mobile seringkali tidak dapat diandalkan dan memiliki tingkat
pengamanan yang rendah. Pola integrasi ini tidak digunakan untuk kasus YPA.
5. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Dokumentasi ini disajikan untuk mengidentifikasi berbagai skenario integrasi
aplikasi, karena usaha integrasi tidak dapat diselesaikan hanya dengan memilih satu
solusi tunggal tapi memerlukan penggabungan berbagai teknologi integrasi. Cara
yang terbaik adalah dengan memilih teknologi integrasi yang tepat sesuai dengan
permasalahan. Berdasarkan hasil analisis, menunjukkan bahwa untuk implementasi
integrasi teknis YPA, yang diperlukan adalah teknologi integrasi sistem legacy
dengan penyediaan database interface.
277
LAMPIRAN L (SPESIFIKASI IMPLEMENTASI INTEGRASI INFORMASI)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan implementasi untuk pengembangan solusi
integrasi informasi. Integrasi menyajikan gaya integrasi khusus yaitu untuk
memecahkan masalah akan kebutuhan pengaksesan informasi dari beragam sumber.
Sejumlah masalah yang terkait dengan integrasi informasi adalah :
a. Membuat single view mengenai kosumen atau sumber daya lain.
b. Inventori dan manajemen data enterprise.
c. Pelaporan dan analisis real-time.
d. Updating data warehouse.
e. Membuat virtual data warehouse.
f. Menyediakan infrastruktur untuk manajemen informasi enterprise termasuk
seluruh format media digital.
g. Updating informasi umum pada seluruh sumber daya informasi.
h. Membuat aplikasi portal yang terdiri atas data yang terstruktur dan juga tidak
terstruktur dari sejumlah sistem yang berbeda.
Berdasarkan hasil analisis terhadap as-is system, diperoleh hasil bahwa informasi
yang mengalir di YPA mayoritas berada pada fungsi akademik mulai dari
penerimaan siswa/mahasiswa baru, pengelolaan kegiatan akademik, pengelolaan
kegiatan wisuda, promosi serta pengelolaan bursa kerja dan alumni. Selain informasi
akademik, pembahasan juga dilakukan pada fungsi keuangan yang merupakan
pendukung fungsi utama akademik. Hasil identifikasi terhadap kebutuhan sistem
mendatang (to-be system) menuntut adanya integritas diantara sejumlah proses dan
juga aliran data diantara sejumlah proses tersebut. Sebagian besar proses dan aliran
data saat ini dinyatakan telah dapat memenuhi kebutuhan bisnis baik saat ini maupun
untuk masa mendatang, namun perlu dilakukan optimalisasi.
279
Kesenjangan (gap) diantara kondisi as-is dengan to-be menunjukkan bahwa
optimalisasi yang dimaksud adalah melakukan kegiatan integrasi. Berdasarkan
kesenjangan antara as-is dan to-be serta adanya pengendali serta requirement bisnis
mengenai integrasi, maka dibuat kebijakan untuk membuat arsitektur integrasi dan
melakukan implementasi integrasi. Kegiatan integrasi dibagi ke dalam kegiatan
stratejik dan taktis.
Kegiatan stratejik setelah mendefinisikan arsitektur layanan dalam proyek integrasi
adalah pembentukan arsitektur integrasi informasi, yang pembahasannya telah
dilakukan pada lampiran I. Hasil dari dokumentasi tersebut digunakan pada bagian
ini sebagai dasar untuk melakukan kegiatan taktis yaitu mengimplementasikan
integrasi informasi. Gambar L.1 menunjukkan bagaimana hasil analisis kondisi saat
ini digunakan untuk menentukan kebutuhan sistem mendatang. Berdasarkan
kebijakan yang diperoleh sebagai hasil identifikasi terhadap kesenjangan serta
adanya pengendali dan requirement bisnis maka dilakukan kegiatan stratejik dan
taktis integrasi informasi.
2. Ruang Lingkup
Ruang lingkup dari spesifikasi integrasi terbatas pada informasi dan sistem tertentu
yang diintegrasikan yaitu aplikasi akademik dan keuangan LPP serta ASM.
Spesifikasi ini meliputi unit organisasi, user dan aplikasi yang dilibatkan serta hasil
akhir yang diharapkan.
3. Partisipan Kunci
Partisipan kunci dalam mengimplementasikan integrasi aplikasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung jawab
terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap mengenai
partisipan kunci beserta kelompok dan peranan mereka disajikan dalam Tabel L.1
berikut ini :
280
Tabel L.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
Pada Tabel L.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Pola dan Layanan Integrasi Informasi
Terdapat sejumlah pola implementasi integrasi informasi. Bagian ini hanya
membahas pola-pola tertentu yang seringkali digunakan dan menyediakan rincian
konfigurasi mengenai komponen implementasi tertentu. Pola-pola tersebut adalah :
a. Integrasi data.
b. Integrasi konten yang tidak terstruktur.
c. Integrasi repository metadata.
4.1 Integrasi Data
Integrasi data terdiri atas data yang terstruktur, umumnya ditemukan pada berbagai
basis data dalam organisasi. Integrasi dan agregasi data meliputi pengaksesan sumber
data yang terpisah seolah-olah basis data tersebut tunggal (termasuk kemampuan
untuk membuat SQL antar basis data), translasi dan transformasi, mendukung
berbagai view (virtual table) dari informasi, data cleansing dan manajemen transaksi
saat diperlukan untuk mempublikasikan perubahan data. Tabel L.2
menspesifikasikan seluruh layanan integrasi yang disediakan disertai rincian
implementasi yang relevan.
281
Tabel L.2 Implementasi Integrasi Data Layanan Integrasi
Vendor/Produk/Kustomisasi Implementasi
Tool integrasi data Penambahan fungsi bagi legacy system
Penambahan modul konversi tabel, penyesuaian format tabel dan perekaman record data dari basis data sumber ke basis data tujuan
EII - Modul-modul program yang tersedia
Translasi dan transformasi
-
Penambahan modul konversi tabel, penyesuaian format tabel dan perekaman record data dari basis data sumber ke basis data tujuan
Akses sumber data ODBC System DSN Open Database Connectivity (ODBC)
Metadata repository - SQL Server
Query Sintaks SQL
1. Sintaks koneksi ke basis data dengan ODBC • set [nama koneksi] =
new adodb.connection • [nama koneksi].open
“[nama basis data]” 2. Sintaks menampilkan isi record
select [nama field/*] from [nama tabel] where [kondisi]
3. Sintaks hapus record delete from [nama tabel] where [kondisi]
4. Sintaks update record update [nama tabel] set [nama field] = [harga field] where [kondisi]
5. Sintaks memasukkan data insert into [nama tabel] ([nama field]) values ([nilai])
6. Sintaks menjalankan eksekusi [nama koneksi].execute [perintah]
View - View untuk menampilkan hasil perhitungan dan laporan akademik serta keuangan
Data cleansing - Menggunakan script Replikasi/sinkronisasi data
- Bagian dari teknologi server dan penggunaan script
Manajemen transaksi - -
Pengamanan - Otorisasi dan autentifikasi
4.2 Integrasi Konten Tidak Terstruktur
Data yang tidak terstuktur yang perlu diintegrasikan dengan Web portal dan aplikasi
termasuk dokumen, gambar, foto, audio, video dan media dijital laiinnya. Seluruh
konten yang tidak terstruktur ini memerlukan sejumlah layanan. Layanan yang
disediakan oleh ECM meliputi content repository, kemampuan pencarian (query),
pengontrolan versi (check in/out), replikasi perubahan konten, integrasi, content
rendering (translasi/transformasi), pengamanan, pemodelan dan manajemen proses
serta content delivery. Pola integrasi ini tidak digunakan untuk kasus YPA.
282
4.3 Integrasi Metadata Repository
Metadata repository pada intinya adalah basis data yang mengandung informasi
mengenai sumber data. Metadata repository enterprise terdiri atas seluruh metadata
sumber informasi dan aplikasi serta berisi informasi mengenai bagaimana mengakses
informasi tersebut. Metadata repository yang aktif juga terdiri atas mekanisme
pengaksesan. Metadata repository juga terdiri atas deskripsi metada baru seperti
canonical format yang dapat dipetakan ke dalam sumber metadata maupun langsung
dengan mengaplikasi aturan transformasi dan perhitungan. Pada prinsipnya,
metadata repository harus dapat menyediakan tingkat abstraksi yang memudahkan
konsolidasi, integrasi dan pengelolaan informasi terdistribusi. Pola integrasi ini tidak
digunakan untuk kasus YPA.
5. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Berdasarkan pola ketiga pola integrasi yang dikemukakan di atas, integrasi data
dipilih untuk menyelesaikan kasus YPA. Integrasi data merupakan kegiatan awal
proyek integrasi, dimana mekanismenya adalah memindahkan record-record data
yang bersesuaian dari suatu basis data ke basis data lain. Meskipun integrasi data
berarti melakukan integrasi antara data yang terstruktur dengan data tidak terstruktur
(seperti format dijital) namun pembahasan untuk kasus YPA dibatasi pada integrasi
data yang terstruktur. Terdapat beberapa best practice dalam integrasi informasi,
yaitu :
a. Membuat enterprise metadata repository (EMR).
Membuat enterprise metadata repository yang komprehensif yang menyediakan
informasi mengenai berbagai tipe mengenai sumber informasi enterprise.
b. Mengorganisasikan “center of excelence”.
Tunjuk orang yang bertanggung jawab terhadap kualitas data dalam sistem
sumber. Orang ini juga harus bertanggung jawab terhadap peninjauan ulang
rancangan dan memastikan makna semantik data selalu benar saat dipetakan
dalam format kanonik.
c. Mengidentifikasi “gold standard” untuk data.
Membuat arsitektur informasi yang menyertakan informasi pada sumber record
untuk tiap entitas bisnis yang harus konsisten pada enteprise.
283
d. Memastikan pengujian yang tepat terpenuhi.
Membuat rencana pengujian untuk memastikan bahwa query-query untuk data
view akan menghasilkan tanggapan yang benar.
284
SPESIFIKASI IMPLEMENTASI INTEGRASI COMPOSITE
APPLICATION
YAYASAN PENDIDIKAN ARIYANTI
VERSI 1 TAHUN 2008
285
LAMPIRAN M (SPESIFIKASI IMPLEMENTASI INTEGRASI COMPOSITE APPLICATION)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan implementasi untuk pengembangan solusi
integrasi composite application. Integrasi menyajikan gaya integrasi khusus yaitu
untuk memecahkan masalah akan kebutuhan pengaksesan informasi dari beragam
sumber. Sejumlah masalah yang terkait dengan integrasi composite application
adalah :
a. Menambahkan modul fungsionalitas baru pada aplikasi yang telah ada.
b. Memperluas fungsionalitas dari paket aplikasi.
c. Menyusun solusi bisnis baru dari modul-modul yang telah ada.
Berdasarkan hasil analisis terhadap as-is system, diperoleh hasil bahwa layanan
akademik dan keuangan masing-masing telah didukung oleh fungsionalitas aplikasi
legacy. Namun fungsionalitas yang tersedia bersifat stovepipe untuk suatu aplikasi
tertentu dimana masing-masing fungsi tidak dapat berkomunikasi dan saling berbagi
data maupun informasi dengan fungsi lain. Sedangkan identifikasi terhadap
kebutuhan sistem mendatang (to-be system) menuntut adanya integritas diantara
sejumlah layanan atau fungsionalitas aplikasi. Sebagian besar layanan saat ini
dinyatakan telah dapat memenuhi kebutuhan bisnis baik saat ini maupun untuk masa
mendatang, namun masih harus diupayakan integrasi pada sejumlah fungsi dari
sejumlah aplikasi.
Kesenjangan (gap) diantara kondisi as-is dengan to-be menunjukkan bahwa
diperlukan integrasi. Berdasarkan kesenjangan antara as-is dan to-be serta adanya
pengendali serta requirement bisnis mengenai integrasi, maka dibuat kebijakan untuk
membuat arsitektur integrasi dan melakukan implementasi integrasi. Kegiatan
integrasi dibagi ke dalam kegiatan stratejik dan taktis.
287
Kegiatan stratejik yang terkait dengan fungsionalitas atau layanan yang harus
tersedia pada sistem di YPA adalah pembentukan arsitektur integrasi layanan, yang
pembahasannya telah dilakukan pada lampiran H. Hasil dari dokumentasi tersebut
digunakan pada bagian ini sebagai dasar untuk melakukan kegiatan taktis yaitu
mengimplementasikan integrasi composite application. Gambar M.1 menunjukkan
bagaimana hasil analisis kondisi saat ini digunakan untuk menentukan kebutuhan
sistem mendatang. Berdasarkan kebijakan yang diperoleh sebagai hasil identifikasi
terhadap kesenjangan serta adanya pengendali dan requirement bisnis maka
dilakukan kegiatan stratejik dan taktis integrasi teknis.
2. Ruang Lingkup
Ruang lingkup dari spesifikasi integrasi terbatas pada informasi dan sistem tertentu
yang diintegrasikan yaitu aplikasi akademik dan keuangan LPP serta ASM.
Spesifikasi ini meliputi unit organisasi, user dan aplikasi yang dilibatkan serta hasil
akhir yang diharapkan.
3. Partisipan Kunci
Partisipan kunci dalam mengimplementasikan integrasi aplikasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung jawab
terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap mengenai
partisipan kunci beserta kelompok dan peranan mereka disajikan dalam Tabel M.1
berikut ini :
Tabel M.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
288
Pada Tabel M.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
4. Pola dan Layanan Integrasi Informasi
Hanya terdapat satu pola integrasi composite application namun dapat
diimplementasikan dengan beragam cara. Composite application terdiri atas layanan
dan/atau komponen atau sistem yang dapat disebut sebagai layanan. Layanan-
layanan tersebut memiliki interface standar dan diintegrasikan dengan aplikasi
melalui lojik program atau orchestration engine. Gambar M.1 menyajikan arsitektur
integrasi composite application dengan layanan-layanan yang tersedia. Layanan
tersebut dapat diiimplementasikan melalui platform aplikasi, message broker, ESB,
atau adapter.
Gambar M.1 Pola Integrasi Composite Application (4)
Tabel M.2 berikut ini menyajikan implementasi integrasi composite application,
yang terdiri atas sejumlah layanan yaitu development dan deployment, interface
layanan, translasi dan transformasi, orchestration, portal, messaging dan security.
289
Tabel M.2 Implementasi Integrasi Composite Application Layanan Integrasi
Vendor/Produk/Kustomisasi Implementasi
Development dan deployment
- -
Interface layanan - -
Translasi dan transformasi
- Membuat fungsionalitas untuk melakukan translasi dan transformasi data
Orchestration - -
Portal - -
Messaging - -
Security - Otorisasi dan autentifikasi
5. Kesimpulan dan Rekomendasi untuk Langkah Selanjutnya
Integrasi composite merupakan bentuk penyusunan aplikasi. Idenya adalah
menyusun komponen aplikasi atau layanan bisnis yang ada dan menggabungkannya
dengan layanan baru. Untuk kasus YPA, integrasi composite dilakukan dengan cara
menambahkan fungsi pada aplikasi yang menggunakan bahasa pemrograman Visual
Basic dan SQL Server (DBMS) sehingga dapat mengakses tabel berformat *.dbf.
291
LAMPIRAN N (SPESIFIKASI IMPLEMENTASI INTEGRASI PROSES)
1. Pendahuluan
Spesifikasi ini menyediakan tuntunan implementasi untuk pengembangan solusi
integrasi proses. Integrasi menyajikan gaya integrasi khusus yaitu untuk mengelola
integrasi dari tingkatan end-to-end business process. Spesifikasi ini cocok untuk
peningkatan proses bisnis, mengiterasi otomatisasi antar entitas bisnis dan
mengimplementasikan solusi industri dan compliance.
Berdasarkan hasil analisis terhadap as-is system, diperoleh hasil bahwa proses bisnis
tersebar pada sejumlah unit-unit organisasi, jadi suatu fungsi tidak hanya milik suatu
unit organisasi tertentu saja. Sebagai contoh untuk fungsi penerimaan
siswa/mahasiswa baru melibatkan sejumlah unit organisasi yaitu Mentor, Bagian
Akademik bahkan Kepala Bagian Keuangan untuk melakukan pembayaran biaya
pendaftaran. Hal ini menunjukkan perlu adanya integrasi pada tingkatan proses
sehingga dapat diketahui fungsi-fungsi yang perlu diotomatisasi. Identifikasi
terhadap kebutuhan sistem mendatang (to-be system) menuntut adanya integritas dan
otomatisasi diantara sejumlah proses. Sebagian besar proses saat ini seringkali dilihat
sebagai milik suatu unit, sehingga otomatisasi hanya terjadi pada suatu unit. Padahal
pada kenyataannya terjadi aliran data dan informasi diantara proses-proses.
Kesenjangan (gap) diantara kondisi as-is dengan to-be menunjukkan bahwa
diperlukan integrasi. Berdasarkan kesenjangan antara as-is dan to-be serta adanya
pengendali serta requirement bisnis mengenai integrasi, maka dibuat kebijakan untuk
membuat arsitektur integrasi dan melakukan implementasi integrasi. Kegiatan
integrasi dibagi ke dalam kegiatan stratejik dan taktis.
Kegiatan stratejik yang terkait dengan integrasi proses adalah pembentukan arsitektur
integrasi proses, yang pembahasannya telah dilakukan pada lampiran J. Hasil dari
dokumentasi tersebut digunakan pada bagian ini sebagai dasar untuk melakukan
kegiatan taktis yaitu mengimplementasikan integrasi proses.
293
Gambar N.1 menunjukkan bagaimana hasil analisis kondisi saat ini digunakan untuk
menentukan kebutuhan sistem mendatang. Berdasarkan kebijakan yang diperoleh
sebagai hasil identifikasi terhadap kesenjangan serta adanya pengendali dan
requirement bisnis maka dilakukan kegiatan stratejik dan taktis integrasi teknis.
2. Ruang Lingkup
Ruang lingkup dari spesifikasi integrasi terbatas pada proses bisnis yang akan
diintegrasikan dan diotomatisasi proses akademik dan keuangan LPP serta ASM.
Spesifikasi ini meliputi seluruh entitas bisnis dan sistem.
3. Partisipan Kunci
Partisipan kunci dalam mengimplementasikan integrasi aplikasi adalah unit-unit
organisasi yang terdefinisi dalam pemodelan bisnis di Bab III (Gambar III.6)
ditambah dengan unit khusus yang dibentuk sebagai pihak yang bertanggung jawab
terhadap seluruh kegiatan integrasi yaitu IT Executive. Uraian lengkap mengenai
partisipan kunci beserta kelompok dan peranan mereka disajikan dalam Tabel N.1
berikut ini :
Tabel N.1 Partisipan Kunci Kelompok Partisipan Peran
Stakeholder utama
IT Executive Bertanggung jawab pada seluruh kegiatan integrasi.
Stakeholder utama
Bagian Dokumentasi Bertanggung jawab pada dokumentasi kegiatan integrasi.
Audience System Analyst Bertanggung jawab menganalisa kondisi bisnis, sistem dan teknologi informasi saat ini.
Audience System Designer Bertanggung jawab menentukan kebutuhan data, aplikasi dan teknologi integrasi.
Audience Programmer Bertanggung jawab membuat middleware yang memampukan komunikasi antar aplikasi level data.
Audience Teknisi Bertanggung jawab menyediakan perangkat keras yang diperlukan dalam melakukan integrasi.
Pada Tabel N.1, terdapat dua kelompok partisipan kunci yaitu audience dan
stakeholder utama. Audience meliputi seluruh anggota dalam organisasi IT yang
memiliki peranan dalam melaksanakan integrasi. Stakeholder utama terdiri atas IT
executive dan juga orang-orang yang bertanggung jawab pada pemeliharaan
dokumen.
294
4. Pola dan Layanan Integrasi Informasi
Integrasi proses terdiri atas sejumlah pola yaitu :
a. Process automation
b. Process activity monitoring
c. Process collaboration
4.1 Process Automation
Process atutomation memerlukan layanan integrasi aplikasi. Solusi tersebut dapat
menyediakan sejumlah layanan integrasi seperti adapter atau dapat menyediakan
integrasi dengan solusi EAI. Terdapat sejumlah tool BPM yang dapat melakukan
keduanya sehingga menghasilkan fleksibilitas implementasi. Layanan-layanan yang
termasuk ke dalam process automation meliputi pemdolan proses, simulasi proses
dan manajemen proses juga dukungan terhadap proses dan transaksi jangka panjang,
manajemen business rule, dukungan transaksi termasuk kompensasi transaksi juga
seluruh layanan integrasi aplikasi yang diperlukan. Tabel N.2 menspesifikasi seluruh
layanan integrasi yang disediakan untuk integrasi otomatisasi proses disertai rincian
implementasi.
Tabel N.2 Implementasi Integrasi Otomatisasi Proses Layanan Integrasi
Vendor/Produk/Kustomisasi Implementasi
Pemodelan proses Business Process Modeling (BPM) Penggunaan BPM untuk memodelkan proses bisnis
Simulasi proses - - Process management
- -
Rule management - - Workflow management
- Penggunaan IDEF sebagai alternatif memodelkan proses
Application interface
- Data interface (ODBC dan ADO)
Middleware integration
- -
Process repository - -
BAM - -
4.2 Process Activity Monitoring
Process monitoring, juga disebut dengan business activity monitoring (BAM),
menyediakan real-time visibility dalam proses bisnis. BAM dapat menjadi bagian
dari manajemen proses bisnis atau menjadi solusi yang berdiri sendiri. Layanan yang
295
disediakan oleh BAM meliputi management dashboard dengan key performance
indicator (KPI) yang relevan dengan peran dalam organisasi, real-time analytic
untuk mempopulasi dashboard serta agen atau event manager untuk mengenali
event-event yang relevan. Layanan memiliki sejumlah kemampuan untuk mengambil
informasi dari analytical data store secara real-time. BAM juga dapat terdiri atas
kemampuan untuk pemodelan dan pengembangan dalam mendefinisikan solusi
BAM sehingga masing-masing bersifat unik. Pola integrasi ini tidak digunakan
dalam kasus YPA.
4.3 Process Collaboration
Collaborative process integration menyediakan platform untuk mengintegrasikan
pekerjaan dari sejumlah anggota tim yang berbeda dalam lokasi yang berbeda.
Collaborative solution meliputi collaboration portal yang menyediakan akses
terhadap seluruh artifak proyek termasuk deliverable, catatan-catatan pertemuan,
hasil diskusi dan lain-lain. Project repository sangatlah penting untuk mengelola
artifak-artifak proyek. Repository dapat menjadi bagian dari collaboration platform
atau diintegrasikan dengan content management. Version control dengan fasilitas
check-in dan check-out dapat juga menjadi bagian dari platform atau disediakan pada
integrasi melalui content management system atau version control system. Solusi
untuk proses ini dapat mengkombinasikan keduanya. Project management juga dapat
disediakan oleh platform, atau diintegrasikan dengan project management system.
Workflow seringkali dilibatkan sebagai bagian dari platform untuk mengelola
collaborative process. Project coordination disediakan dengan kalender atau
penjadwalan pertemuan elektronis. Dikarenakan banyaknya penggunaan e-mail,
sebagai alat komunikasi proyek, maka integrasi e-mail menjadi hal yang penting.
Platform kolaborasi harus memperhatikan pengamanan role-based dengan pemberian
otorisasi bertingkat sehingga hak-hak akses dapat menjadi artifak yang terdefinisi.
top related