160 Perencanaan strategis penerimaan siswa dan mahasiswa baru. · PDF filePengelolaan pendaftaran calon siswa dan mahasiswa baru. a. Unit organisasi yang bertanggung jawab penuh dan

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.


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.


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.




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.



161




Direktur II.

6. Penyusunan materi ujian seleksi penerimaan mahasiswa baru.




Program Studi, Kepala Bagian Administrasi Akademik.


Administrasi Umum.

7. Pengelolaan pendaftaran calon siswa dan mahasiswa baru.





Akademik, Kepala Bagian Administrasi Umum.


Direktur II, Pembantu Direktur III.

8. Pengelolaan pembayaran administrasi penerimaan calon siswa dan mahasiswa

baru.




Bagian Keuangan.


Administrasi Akademik.

9. Pelaksanaan Ujian Saringan Masuk (USM) seleksi calon mahasiswa baru.





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.


adalah Ketua Program Studi.


Bagian Administrasi Akademik.

11. Penentuan kelulusan hasil Ujian Saringan Masuk (USM) seleksi calon

mahasiswa baru.





12. Pengumuman hasil Ujian Saringan Masuk (USM) seleksi calon mahasiswa

baru.


adalah Ketua Program Studi.


Bagian Administrasi Akademik.

13. Registrasi ulang siswa dan mahasiswa baru.


adalah Ketua Program Studi, Koordinator Jurusan.


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.


adalah Ketua Program Studi, Koordinator Jurusan.


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


17. Pelaksanaan orientasi studi dan pengenalan kampus.


adalah Pembantu Direktur III.

b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kabag

Perlengkapan dan Kerumahtanggaan, Kepala Bagian Kemahasiswaan,

Ketua Organisasi Kemahasiswaan.


Administrasi Umum, Kepala Bagian Marketing.

18. Pelaporan dan evaluasi siswa dan mahasiswa baru.




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.


Marketing.

19. Perencanaan strategis kurikulum dan kebijakan akademik.




Direktur I, Ketua Program Studi, Koordinator Jurusan.


Direktur II, Pembantu Direktur III.

20. Penetapan kurikulum.



164





21. Penentuan dosen-dosen pengajar dan wali akademik.







22. Pembuatan Surat Keputusan dosen-dosen pengajar dan wali akademik.





Akademik.

23. Rapat dosen dan wali akademik.




Program Studi, Koordinator Jurusan, Pembantu Direktur II, Pembantu

Direktur III.


Administrasi Akademik, Kepala Bagian Administrasi Umum, Kepala

Bagian Keuangan.

24. Penetapan kalender akademik.





165

c. Unit organisasi yang terlibat sebagian dalam proses adalah Bagian

Administasi Akademik.

25. Pengelolaan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM).




Bagian Kemahasiswaan.


Administrasi Akademik, Kepala Bagian Administrasi Umum.

26. Pelaksanaan perwalian (program D-3).




Program Studi.



27. Pengelolaan Perubahan Rencana Studi/PRS (program D-3).




Program Studi.



28. Pembuatan jadwal Kegiatan Belajar Mengajar (KBM).







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).





31. Pembentukan panitia ujian (UTS, UAS, komprehensif).





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).







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).




Program Studi, Koordinator Jurusan, Kepala Bagian Kemahasiswaan.

167


Direktur III.

35. Penyerahan berkas jawaban ujian siswa dan mahasiswa ke dosen yang

bersangkutan.







36. Penerimaan berkas nilai dari dosen.







37. Pemrosesan nilai di komputer.







38. Pencetakan Kartu Hasil Studi (KHS).





Akademik.

39. Pelaporan dan evaluasi kegiatan akademik.

168







40. Perencanaan dan kebijakan wisuda.





I.

41. Penetapan nama-nama panitia.




Program Studi, Koordinator Jurusan, Pembantu Direktur I.

42. Penerbitan Surat Keputusan panitia wisuda.





II.



43. Rapat panitia wisuda.







169

Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Kepala Bagian

Marketing.

44. Penetapan anggaran wisuda.




Bagian Keuangan.



45. Penetapan standar kelulusan.





46. Pembuatan ijazah, sertifikat dan transkrip nilai.





Akademik.

c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala

Bagian Administrasi Umum, Pembantu Direktur III, Kepala Bagian

Kemahasiswaan.

47. Pelaksanaan wisuda.







Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi

Kemahasiswaan, Kepala Bagian Marketing.

170

48. Pelaporan dan evaluasi kegiatan wisuda.







Pembantu Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi


49. Perencanaan dan kebijakan promosi.




Direktur I, Pembantu Direktur II, Pembantu Direktur III, Kepala Bagian

Marketing.

50. Pembentukan panitia promosi dan One Stop Service (OSS).





Administrasi Akademik, Pembantu Direktur II, Kepala Bagian

Administrasi Umum, Kepala Bagian Keuangan, Kabag Perlengkapan dan

Kerumahtanggaan, Pembantu Direktur III, Kepala Bagian


51. Penetapan anggaran promosi.




Bagian Keuangan, Kepala Bagian Marketing.

52. Penetapan metoda promosi.



171


Bagian Marketing.

53. Pelaksanaan promosi.




Bagian Marketing.

54. Pelaporan dan evaluasi kegiatan promosi.





Administrasi Akademik, Pembantu Direktur II, Kepala Bagian

Administrasi Umum, Kepala Bagian Keuangan, Kabag Perlengkapan dan

Kerumahtanggaan, Pembantu Direktur III, Kepala Bagian


55. Perencanaan dan kebijakan kerjasama.




Direktur II.



56. Penetapan kebijakan kerjasama (link and match).







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.





c. Unit organisasi yang terlibat sebagian dalam proses adalah Kepala

Bagian Marketing.

59. Pelaporan dan evaluasi kerjasama.




Direktur II.


Direktur I, Kepala Bagian Administrasi Umum, Kepala Bagian

Marketing.

60. Perencanaan dan kebijakan pengelolaan ikatan keluarga alumni.




Direktur III.


Direktur I, Pembantu Direktur II.

61. Penetapan kebijakan pengelolaan ikatan keluarga alumni.



b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Bagian

Bursa Kerja dan Alumni.


Kemahasiswaan.

62. Pembentukan Ikatan Keluarga Alumni (IKA).



173




Kemahasiswaan.

63. Pengelolaan dan pemeliharaan Ikatan Keluarga Alumni (IKA).






Kemahasiswaan.

64. Pelaporan dan evaluasi pengelolaan Ikatan Keluarga Alumni (IKA).




Direktur III, Bagian Bursa Kerja Khusus dan Alumni.


Kemahasiswaan.

65. Perencanaan dan kebijakan keuangan.




Direktur II.



66. Penetapan kebijakan keuangan.


adalah Pembantu Direktur II


Bagian Keuangan.

67. Penetapan anggaran.

174




Bagian Keuangan.

68. Penyusunan anggaran.




Bagian Keuangan.

69. Pengesahan anggaran.




Bagian Keuangan.

70. Revisi anggaran.




Bagian Keuangan.

71. Alokasi anggaran.




Bagian Keuangan.

72. Pengelolaan biaya pendidikan.




Bagian Keuangan.

73. Pengelolaan honor dosen.



175


Bagian Keuangan.

74. Monitoring anggaran.

c. Unit organisasi yang bertanggung jawab penuh dan pembuat keputusan


d. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Kepala

Bagian Keuangan.

75. Pelaporan dan evaluasi keuangan.




Direktur I, Kepala Bagian Keuangan.

76. Perencanaan dan kebijakan pengelolaan Ketua Organisasi Kemahasiswaan.




Direktur III.



77. Penetapan kebijakan pengelolaan Ketua Organisasi Kemahasiswaan.




Bagian Kemahasiswaan, Ketua Organisasi Kemahasiswaan.

78. Pembentukan Ketua Organisasi Kemahasiswaan.





79. Pengelolaan dan pemeliharaan Ketua Organisasi Kemahasiswaan.



176



80. Pelaporan dan evaluasi pengelolaan Ketua Organisasi Kemahasiswaan.




Direktur III, Kepala Bagian Kemahasiswaan, Ketua Organisasi

Kemahasiswaan.

81. Perencanaan dan kebijakan pengelolaan pengembangan perpustakaan.




Direktur I.


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.



b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah

Perpustakaan.

84. Pengadaan buku.




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.



b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah

Perpustakaan.

89. Perencanaan dan kebijakan kepegawaian.





90. Penetapan kebijakan dan aturan kepegawaian (bagi staf, dosen luar biasa,

dosen tetap dan pejabat struktural).




Direktur I, Bagian Kepegawaian.

91. Pengelolaan administrasi kepegawaian.




Kepegawaian.

92. Pengelolaan gaji dan honor.




Bagian Keuangan, Bagian Kepegawaian.

93. Pengembangan karir.

178




Kepegawaian.

94. Pelaporan dan evaluasi kepegawaian.




Kepegawaian.

95. Perencanaan dan kebijakan pemanfaatan serta pengembangan teknologi

informasi dan utilitas laboratorium.




Direktur I, Unit Pelaksana Teknis, Pembantu Direktur II.

96. Penetapan kebijakan dan aturan pemanfaatan serta pengembangan teknologi

informasi dan laboratorium.



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


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


101. Pelaporan dan evaluasi pemanfaatan serta pengembangan teknologi informasi

dan laboratorium.

179



b. Unit organisasi yang terlibat sepenuhnya dalam proses adalah Unit

Pelaksana Teknis.

102. Perencanaan dan kebijakan pemanfaatan serta pengembangan sarana dan

prasarana.




Direktur II.

103. Penetapan kebijakan pemanfaatan serta pengembangan sarana dan prasarana.





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


106. Pengelolaan sarana dan prasarana, unit organisasi yang terlibat sepenuhnya


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


109. Pelaporan dan evaluasi pemanfaatan serta pengembangan sarana dan

prasarana.





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.


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.


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.


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.


No. 1.2

Nama Sistem Pengelolaan Pembayaran Pendaftaran

Deskripsi Aplikasi ini untuk mencatat dan mengelola pembayaran pendaftaran.


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.


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.


No. 2.2

Nama Sistem Pembuatan KRS, KTS dan KTM

Deskripsi Aplikasi ini untuk mengelola pembuatan KRS, KTS dan KTM.

183


No. 2.3

Nama Sistem Perwalian

Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan perwalian.


No. 2.4

Nama Sistem Perubahan Rencana Studi

Deskripsi Aplikasi ini untuk mencatat dan mengelola Perubahan Rencana

Studi/PRS.


No. 2.5

Nama Sistem Penjadwalan KBM

Deskripsi Aplikasi ini untuk mencatat dan mengelola penjadwalan KBM.


No. 2.6

Nama Sistem Administrasi KBM

Deskripsi Aplikasi ini untuk mengelola administrasi KBM.


No. 2.7

Nama Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)

Deskripsi Aplikasi ini untuk mencatat dan mengelola penjadwalan ujian (UTS,

UAS, Sidang, Komprehensif).


No. 2.8

Nama Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)

Deskripsi Aplikasi ini untuk mengelola administrasi ujian (UTS, UAS, Sidang,

Komprehensif).


No. 2.9

Nama Sistem Pengelolaan Nilai

Deskripsi Aplikasi ini untuk mencatat dan mengelola nilai.


No. 2.10

Nama Sistem Pembuatan Kartu Hasil Studi

Deskripsi Aplikasi ini untuk mengelola pembuatan Kartu Hasil Studi.

184


No. 2.11

Nama Sistem Administrasi Dosen

Deskripsi Aplikasi ini untuk mengelola administrasi dosen.


No. 2.12

Nama Sistem Manajemen Kurikulum

Deskripsi Aplikasi ini untuk mengelola kurikulum.


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.


No. 3.2

Nama Sistem Administrasi Wisuda

Deskripsi Aplikasi ini untuk mengelola administrasi 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.


No. 5.2

Nama Sistem Pengelolaan Kerjasama

Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan kerjasama

dengan dunia industri.


No. 5.3

Nama Sistem Pengelolaan Alumni

Deskripsi Aplikasi ini untuk mencatat dan mengelola kegiatan alumni.


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.


No. 6.2

Nama Sistem Pengelolaan Honor Dosen

Deskripsi Aplikasi ini untuk mengelola pelaporan pembayaran honor dosen.


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


c_asalinformasi Char 3 Not null

n_asalinformasi Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmBadanHukum


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


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


c_grade Char 1 Not null

v_bobot Int 4

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmDosen


c_perguruantgg Char 6 Not null

c_programstudi Char 5 Not null


c_dosen Char 10 Not null

n_dosen Varchar 30

188

Tabel Name : TmDosen


i_gelar Varchar 10



i_agama Varchar 10



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


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


c_jabatan Char 1 Not null

n_jabatan Varchar 30

i_entry Char 15

d_entry Datetime 8

189

Tabel Name : Tmjenjang



n_jenjang Varchar 10

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmJnsBayar


i_pembayaran Char 30 Not null

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmJurusan





c_jurusan Char 2 Not null

n_jurusan Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmMahasiswa





c_jurusan Char 2 Not null





i_agama Varchar 10



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


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





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


c_thnsmstr Char 5 Not null





c_dosenwali Char 10

q_jmlsks Int 4

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmMhsFRSDtl






191

Tabel Name : TmMhsFRSDtl





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





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


c_pejabat Char 5 Not null


n_pejabat Varchar 50

i_entry Char 15

d_entry Datetime 8

192

Tabel Name : TmPerguruanTinggi


c_badanhukum Char 7 Not null


n_perguruantgg Varchar 50


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








c_kelas Char 2 Not null

q_jmlpertemuan Int 4

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmPerkuliahanAbsn









c_absen1 Char 1

c_absen2 Char 1

c_absen3 Char 1

c_absen4 Char 1

193

Tabel Name : TmPerkuliahanAbsn


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









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






v_skslulus Int 4

194

Tabel Name : TmProgramStudi


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


c_propinsi Char 2 Not null

n_propinsi Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmRole


c_role Char 3 Not null

n_roledesc Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmSaudara





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





195

Tabel Name : TmSemester


c_semester Char 1 Not null

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmSemesterDesc


c_semester Char 1 Not null

n_semester Varchar 6

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmSiswaPpmb


c_pendaftaran Char 15 Not null

n_namasiswa Varchar 30

i_tempatlahir Varchar 20


i_agama Varchar 10


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


c_stsjabatan Char 1 Not null

n_stsjabatan Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TmUniversitas


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


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


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


c_bukti Char 15 Not null

197

Tabel Name : TtBayarKuliahDtl


i_pembayaran Char 30 Not null

v_jmlbayar Money 8

i_entry Char 15

d_entry Datetime 8

Tabel Name : TtKTM




i_programstudi Varchar 25

i_entry Char 15

d_entry Datetime 8

Tabel Name : TtPengalamanOrg





c_tahun Char 4 Not null


i_tempat Varchar 30

i_entry Char 15

d_entry Datetime 8

Tabel Name : TtSkripsi






n_judulskripsi Varchar 50

n_tmptskirpsi Varchar 50

n_pembimbing1 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


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


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

199

SPESIFIKASI ARSITEKTUR INTEGRASI TEKNIS

YAYASAN PENDIDIKAN ARIYANTI

VERSI 1 TAHUN 2008

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


- 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





5 2.1 Sistem Registrasi Ulang Siswa/Mahasiswa

Legacy integration




6 2.2 Sistem Pembuatan KRS, KTS dan KTM

Legacy integration




7 2.3 Sistem Perwalian Legacy integration




8 2.4 Sistem Perubahan Rencana Studi

Legacy integration




202

Tabel G.2 Tipe-tipe Integrasi (Lanjutan)

No. No.


Tipe Integrasi


yang Diintegrasikan

9 2.5 Sistem Penjadwalan KBM Legacy integration




10 2.6 Sistem Administrasi KBM Legacy integration




11 2.7 Sistem Penjadwalan Ujian (UTS, UAS, Sidang, Komprehensif)

Legacy integration




12 2.8 Sistem Administrasi Ujian (UTS, UAS, Sidang, Komprehensif)

Legacy integration




13 2.9 Sistem Pengelolaan Nilai Legacy integration




14 2.10 Sistem Pembuatan Kartu Hasil Studi

Legacy integration




15 2.11 Sistem Administrasi Dosen

Legacy integration




16 2.12 Sistem Manajemen Kurikulum

Legacy integration




17 2.13 Sistem Pelaporan Akademik







18 3.1 Sistem Pembuatan Ijazah, Sertifikat dan Transkrip Nilai

Legacy integration




19 3.2 Sistem Administrasi Wisuda

Legacy integration




20 3.3 Sistem Pelaporan Kegiatan Wisuda







21 5.3 Sistem Pengelolaan Alumni

Legacy integration




203

Tabel G.2 Tipe-tipe Integrasi (Lanjutan)

No. No.


Tipe Integrasi


yang Diintegrasikan

22 5.4 Sistem Pengelolaan Pelaporan Kegiatan BKK dan IKA

Composite integration

Mengintegrasikan dengan komponen aplikasi yang baru akan dikembangkan





23 6.1 Sistem Pengelolaan Pembayaran Biaya Pendidikan dari Siswa/Mahasiswa

Legacy integration




24 6.2 Sistem Pengelolaan Pembayaran Honor Dosen

Legacy integration




25 6.3 Sistem Pengelolaan Pelaporan Pembayaran Biaya Pendidikan Siswa/Mahasiswa





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


Tidak

Adapter dan interface

Screen scraping-digunakan dengan legacy application

Jika tidak ada lagi yang tersedia atau untuk solusi cepat dan taktis


Tidak

204

Tabel G.3 Layanan Integrasi (Lanjutan) Layanan Integrasi

Teknologi Integrasi

Penggunaan yang Direkomendasika

n


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


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



• Volume data



• Volume data



• 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



business manager



• Operator



business manager



• Operator



business 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



Transaction services

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



Directory services

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.

229

SPESIFIKASI ARSITEKTUR INTEGRASI LAYANAN


VERSI 1 TAHUN 2008

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





Tabel H.1 berikut ini :

Tabel H.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






231

Pada Tabel H.1, terdapat dua kelompok partisipan kunci yaitu audience dan




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.


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.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.


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.2 Mengelola hasil USM

• Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih

• Menyediakan layanan pengelolaan hasil USM

Pengelolaan kegiatan akademik



R4.1 Mengelola pelaporan penerimaan siswa/mahasiswa baru

Menyediakan layanan pembuatan laporan PMB




R5.1 Mengelola kurikulum

Menyediakan layanan pengelolaan kurikulum




R6.1 Mengelola dosen pengajar dan wali akademik

Menyediakan layanan pengelolaan dosen pengajar dan wali akademik




235

Tabel H.3 Kategori Layanan (Lanjutan)

Tanggapan Deskripsi Kategori Layanan Sistem

yang Telah Ada/Baru


R7.2 Mengelola registrasi ulang siswa/mahasiswa

• Menyediakan layanan pemeriksaan jurusan dan program studi yang dipilih

• Menyediakan layanan pengelolaan registrasi ulang




R8.1 Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)

Menyediakan layanan pengelolaan pembuatan KTS dan KTM




R9.1 Mengelola perwalian

Menyediakan layanan pengelolaan perwalian




R10.1 Mengelola Perubahan Rencana Studi/PRS

Menyediakan layanan pengelolaan PRS




R11.1 Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)

Menyediakan layanan pengelolaan KBM




R12.1 Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)

Menyediakan layanan pembuatan daftar hadir KBM




R13.1 Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)

Menyediakan layanan pembuatan jadwal ujian




R14.1 Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)

Menyediakan layanan pembuatan daftar hadir




R15.1 Mengelola nilai Menyediakan layanan pengelolaan nilai




R16.1 Mengelola pencetakan Kartu Hasil Studi (KHS)

Menyediakan layanan pencetakan KHS




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




R18.1 Mengelola pembuatan ijazah, sertifikat dan transkrip nilai

Menyediakan layanan pembuatan ijazah, sertifikat dan transkrip nilai

Pengelolaan kegiatan wisuda



R19.1 Mengelola pelaporan siswa/mahasiswa yang telah lulus

Menyediakan layanan pembuatan laporan siswa/mahasiswa yang telah lulus




R20.1 Mengelola pembayaran biaya pendidikan

Menyediakan layanan pengelolaan pembayaran biaya pendidikan

Pengelolaan keuangan • Aplikasi keuangan LPP


R21.1 Mengelola honor dosen

Menyediakan layanan pengelolaan honor dosen



R22.2 Mengelola Pelaporan dan evaluasi keuangan

Menyediakan layanan pembuatan laporan keuangan



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



• Pengelolaan penerimaan siswa/mahasiswa baru

• Pengelolaan keuangan

Mengelola pembayaran pendaftaran calon siswa/mahasiswa





• Memeriksa jurusan dan program studi yang dipilih

• Mengelola hasil USM





Mengelola pelaporan penerimaan siswa/mahasiswa baru





Mengelola kurikulum Pengembangan middleware antar aplikasi




Mengelola dosen pengajar dan wali akademik





• Memeriksa jurusan dan program studi yang dipilih

• Mengelola registrasi ulang siswa/mahasiswa





Mengelola pembuatan Kartu Tanda Siswa (KTS) dan Kartu Tanda Mahasiswa (KTM)





Mengelola perwalian Pengembangan middleware antar aplikasi



238

Tabel H.4 Kategori Layanan (Lanjutan) Layanan Fungsi Deskripsi

Telah Ada/Baru


Mengelola Perubahan Rencana Studi/PRS





Mengelola pembuatan jadwal Kegiatan Belajar Mengajar (KBM)





Mengelola pembuatan daftar hadir Kegiatan Belajar Mengajar (KBM)





Mengelola pembuatan jadwal ujian (UTS, UAS, komprehensif)





Mengelola pembuatan daftar hadir (UTS, UAS, komprehensif)





Mengelola nilai Pengembangan middleware antar aplikasi




Mengelola pencetakan Kartu Hasil Studi (KHS)





Mengelola pelaporan kegiatan akademik bagi manajemen





Mengelola pembuatan ijazah, sertifikat dan transkrip nilai





Mengelola pelaporan siswa/mahasiswa yang telah lulus




239

Tabel H.4 Kategori Layanan (Lanjutan) Layanan Fungsi Deskripsi Telah Ada/Baru

Pengelolaan keuangan

Mengelola pembayaran biaya pendidikan





Mengelola honor dosen Pengembangan middleware antar aplikasi




Mengelola Pelaporan dan evaluasi keuangan




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 -


Sistem yang diintegrasikan diharapkan tetap menyediakan layanan yang diminta

tanpa banyak merubah interface karena user telah terbiasa dengan interface pada

aplikasi legacy.

244

SPESIFIKASI ARSITEKTUR INTEGRASI INFORMASI


VERSI 1 TAHUN 2008

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





Tabel I.1 berikut ini :

Tabel I.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






246

Pada Tabel I.1, terdapat dua kelompok partisipan kunci yaitu audience dan




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


hasil usm


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]



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


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 dosen]

[identitas siswa][identitas siswa]


[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


251

5.5 Data Flow Diagram (DFD) Level 2 Dekomposisi Proses 3 Pengelolaan Wisuda


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]


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


252

5.6 Data Flow Diagram (DFD) Level 3 Dekomposisi Proses 2.6 Pengelolaan Jadwal


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.


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.

256

SPESIFIKASI ARSITEKTUR INTEGRASI PROSES


VERSI 1 TAHUN 2008

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





Tabel J.1 berikut ini :

Tabel J.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






Pada Tabel J.1, terdapat dua kelompok partisipan kunci yaitu audience dan


258



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.

260

Gambar J.1 Integrasi Proses Bisnis

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.


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.

264

SPESIFIKASI IMPLEMENTASI INTEGRASI APLIKASI


VERSI 1 TAHUN 2008

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.

266

Gambar K.1 Roadmap Implementasi Integrasi Aplikasi

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


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


Stakeholder utama






Pada Tabel K.1, terdapat dua kelompok partisipan kunci yaitu audience dan




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


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.


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.

276

SPESIFIKASI IMPLEMENTASI INTEGRASI INFORMASI


VERSI 1 TAHUN 2008

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.

278

Gambar L.1 Roadmap Implementasi Integrasi Informasi

279


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 beserta kelompok dan peranan mereka disajikan dalam Tabel L.1

berikut ini :

280

Tabel L.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






Pada Tabel L.1, terdapat dua kelompok partisipan kunci yaitu audience dan




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


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


-

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



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


VERSI 1 TAHUN 2008

285

LAMPIRAN M (SPESIFIKASI IMPLEMENTASI INTEGRASI COMPOSITE APPLICATION)

1. Pendahuluan


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.


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.

286

Gambar M.1 Roadmap Implementasi Integrasi Composite Application

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 beserta kelompok dan peranan mereka disajikan dalam Tabel M.1

berikut ini :

Tabel M.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






288

Pada Tabel M.1, terdapat dua kelompok partisipan kunci yaitu audience dan




dokumen.


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


Development dan deployment

- -

Interface layanan - -


- Membuat fungsionalitas untuk melakukan translasi dan transformasi data

Orchestration - -

Portal - -

Messaging - -

Security - Otorisasi dan autentifikasi


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.

290

SPESIFIKASI IMPLEMENTASI INTEGRASI PROSES


VERSI 1 TAHUN 2008

291

LAMPIRAN N (SPESIFIKASI IMPLEMENTASI INTEGRASI PROSES)

1. Pendahuluan


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.


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.

292

Gambar N.1 Roadmap Implementasi 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 beserta kelompok dan peranan mereka disajikan dalam Tabel N.1

berikut ini :

Tabel N.1 Partisipan Kunci Kelompok Partisipan Peran

Stakeholder utama


Stakeholder utama






Pada Tabel N.1, terdapat dua kelompok partisipan kunci yaitu audience dan




dokumen.

294


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


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.

160 Perencanaan strategis penerimaan siswa dan mahasiswa baru. · PDF filePengelolaan pendaftaran calon siswa dan mahasiswa baru. a. Unit organisasi yang bertanggung jawab penuh dan

Documents