III-1
BAB III
ANALISIS
Bab tiga membahas analisis domain yang berisi hasil eksplorasi terhadap aplikasi sistem informasi sekolah dan perbandingan fitur-fitur yang ada untuk mendapatkan kebutuhan framework. Kemudian, dilakukan pemodelan terhadap framework yang dilanjutkan dengan analisis hot spot dan analisis kebutuhan dokumentasi framework.
3.1. Analisis Domain
Sistem informasi adalah sekumpulan perangkat keras, perangkat lunak, brainware, prosedur dan aturan yang diorganisasikan secara integral untuk mengolah data menjadi informasi yang bermanfaat guna memecahkan masalah dan pengambilan keputusan dalam suatu organisasi [WIK08]. Sedangkan sistem informasi sekolah merupakan sistem informasi yang diterapkan di suatu sekolah. Tujuannya untuk meningkatkan efektifitas dan efisiensi manajemen sekolah, meningkatkan kecepatan dan validitas pengambilan keputusan yang berkaitan dengan kegiatan akademik maupun operasional, meningkatkan kualitas layanan bagi peserta didik dan mengangkat citra sekolah.
Aplikasi sistem informasi sekolah berupa perangkat lunak yang terdiri dari beberapa subsistem yang terintegrasi. Subsistem-subsistem tersebut diantaranya adalah sistem informasi akademik, kepegawaian, perpustakaan, administrasi dan subsistem lainnya sesuai dengan kebutuhan sekolah. Sistem informasi kepegawaian menangani masalah karyawan dan guru seperti penanganan gaji dan absensi. Sistem informasi administrasi menitikberatkan pada masalah pendaftaran siswa baru, pembayaran SPP, inventori, dan lain-lain. Manajemen perpustakaan ditangani oleh sistem informasi perpustakaan. Sedangkan sistem informasi akademik membantu kelancaran proses belajar mengajar seperti mengatur jadwal pelajaran, pembuatan kalender akademik, absensi siswa, penilaian, dan lain-lain.
3.1.1. Eksplorasi Aplikasi Sistem Informasi Sekolah
Cakupan domain sistem informasi sekolah cukup luas mulai dari bidang akademik, kepegawaian, perpustakaan, administrasi dan lain sebagainya. Untuk membangun keseluruhan sistem tersebut akan membutuhkan sumber daya yang besar dan
memakan waktu yang lama. Oleh karena itu, dalam tugas akhir ini akan dibatasi hanya pada masalah akademik saja di mana bidang akademik merupakan hal yang utama dalam institusi pendidikan, sedangkan bidang lainnya merupakan pendukung untuk kelancaran pengelolaan sekolah. Batasan ini sesuai dengan ruang lingkup dan batasan masalah yang dijelaskan pada Subbab 1.4.
Pada Subbab 2.4.1 dijelaskan cara untuk mengetahui kebutuhan framework dan mengidentifikasi permasalahan. Untuk mendapatkan deskripsi domain yang akan dilingkupi framework, dilakukan eksplorasi terhadap aplikasi-aplikasi sistem informasi sekolah. Ada empat aplikasi sistem informasi sekolah yang dieksplorasi yaitu Academic School System (ASS), Sistem Infromasi Sekolah (Sisfokol), Suteki SI Sekolah dan DigiSchool.
3.1.1.1. Academic School System (ASS)
Academic School System (ASS) adalah contoh aplikasi sistem informasi sekolah yang lebih memfokuskan fungsinya pada kegiatan akademik yang berhubungan dengan kegiatan belajar mengajar, seperti penanganan absen, penanganan nilai, pengumpulan tugas, dan lain-lain.
ASS merupakan aplikasi custom build berbasis web (web bassed) yang dikembangkan menggunakan bahasa pemrograman PHP 5.0 dan menggunakan basis data MySQL. Pengguna sistem informasi akademik ini adalah siswa, guru, karyawan tata usaha, orangtua dan administrator.
Fitur yang disediakan ASS untuk menunjang kegiatan akademik sekolah dapat dilihat pada Tabel 3.1.
Tabel 3.1 – Fitur Academic School System (ASS)
No. Nama Fitur Keterangan
1. Presensi Mencatat dan menampilkan kehadiran siswa selama
berlangsung kegiatan belajar mengajar.
2. Nilai Nilai setiap siswa akan dipublikasikan di web sehingga siswa
dapat setiap saat melihat nilai yang mereka peroleh, dan bagi orang tua hal ini dapat membantu mengawasi perkembangan putra-putrinya selama belajar di sekolah. Guru pun diharapkan akan lebih transparan dalam proses penilaian karena semua nilai baiki itu tugas, ujian, dan komponen penilaian lainnya
No. Nama Fitur Keterangan
dapat diakses dengan mudah. Untuk menjaga privasi, setiap siswa hanya dapat melihat nilainya sendiri (tidak dapat melihat nilai siswa lain) dan beberapa informasi tambahan seperti nilai tertinggi, nilai terendah dan nilai rata-rata. Begitu juga dengan orang tua hanya dapat melihat nilai putra-putrinya.
3. Silabus Fitur ini memberikan fasilitas kepada para siswa untuk melihat
resume pelajaran yang diajarkan pada masa pelajaran. Dengan adanya fitur ini, maka siswa dapat lebih mengerti inti dari semua pelajaran. Dan di sini juga terdapat bahan pelajaran yang diajarkan di kelas.
4. Jadwal Fitur ini memberikan informasi mengenai jadwal kegiatan
belajar mengajar baik yang sudah lewat maupun yang akan datang. Informasi mengenai guru yang mengajar pun ditampilkan disini.
5. Tugas Selain mengumumkan tugas pada saat tatap muka dikelas, guru
juga dapat mempublikasikannya pada ASS. Dengan demikian, siswa akan selalu diingatkan mengenai tugas yang harus mereka kumpulkan beserta detail tugasnya dan juga hal-hal lain yang berhubungan dengan tugas tersebut.
6. Kalender akademik Kalendar akademik menampilkan lamanya jadwal belajar
mengajar selama satu semester, waktu pelaksanaan Ujian Tengah Semester dan Ujian Akhir Semester, hari libur nasional, kegiatan - kegiatan yang dilaksanakan sekolah dan hal penting lainnya yang perlu diketahui dalam satu tahun ajaran.
3.1.1.2. Sistem Informasi Sekolah (Sisfokol)
Sisfokol v1.0 adalah sistem informasi sekolah yang bersifat open source berlisensi GNU/GPL versi 2. Pengembangnya adalah Open Source Hajirobe dan didistribusikan oleh Biasawae Production. Sisfokol tidak hanya menangani masalah akademik saja, tetapi juga keuangan, kepegawaian dan inventaris.
Sama seperti ASS, Sisfokol merupakan aplikasi berbasis web yang dikembangkan menggunakan bahasa pemrograma PHP dan menggunakan basis data MySQL. Pengguna Sisfokol adalah siswa, orang tua, pegawai, guru, wali kelas, dan administrator.
Fitur yang disediakan Sisfokol yang berhubungan dengan kegiatan akademik dapat dilihat pada Tabel 3.2
Tabel 3.2 – Fitur Sisfokol
No. Nama Fitur Keterangan
1. Agenda sekolah Menampilkan kejadian-kejadian (events) yang dilakukan
oleh sekolah
2. Kalender akademik Menampilkan kejadian-kejadian (events) yang
berhubungan dengan kegiatan akademik
3. Jadwal pelajaran Menampilkan jadwal belajar mengajar untuk siswa dan
guru.
4. Ekstrakurikuler Fitur ini memberikan informasi kegiatan ekstrakurikuler
yang ada di sekolah seperti jadwal kegiatan dan anggota.
5. Presensi Mencatat dan menampilkan kehadiran siswa selama
berlangsung kegiatan belajar mengajar.
6. Nilai Menyimpan informasi nilai tiap siswa sehingga dapat
dilihat oleh siswa yang bersangkutan dan orang tuanya.
7. Raport Menampilkan buku raport yang isinya nilai akhir tiap
pelajaran, nilai kegiatan ekstrakurikuler yang diambil siswa dan presensi siswa selama satu semester.
9. Soal ujian Guru dapat menyimpan soal ujian baik itu essay maupun
pilihan ganda.
3.1.1.3. Suteki SI Sekolah
Suteki SIS adalah aplikasi yang dapat membantu mengelola data-data penting di suatu sekolah yang dikembangkan oleh CV Suteki Global Informatika. Aplikasi ini telah digunakan oleh beberapa sekolah, diantaranya:
1. SMAN 53 Jakarta Timur 2. SMPN 1 Bandung
3. MAN 1 Model Lubuklinggau 4. SMPN 2 Cilegon
5. SMAN 1 Subang
6. Madrasah Aliyah Al-Badar Parepare 7. SMAN 1 Segedong
Beberapa fitur yang dimiliki aplikasi ini adalah data siswa, data guru dan karyawan, kehadiran siswa, kehadiran guru dan karyawan, kedisipinan, keuangan siswa, honor
guru, pengumuman, data instansi, dan cadangan data. Dari fitur-fitur tersebut yang berhubungan dengan kegiatan akademik adalah kehadiran siswa, kedisiplinan dan pengumun. Keterangan detail fitur akademik tersebut dapat dilihat pada Tabel 3.3. Tabel 3.3 – Fitur Suteki SI Sekolah
No. Nama Fitur Keterangan
1. Presensi Fitur ini berguna untuk memeriksa data kehadiran siswa
setiap hari. Proses pengisian data kehadiran dapat dilakukan secara manual (menggunakan keyboard), barcode reader, maupun alat pemindai sidik jari. Proses pencarian data kehadiran dan pembuatan laporan kehadiran siswa sangat mudah dan cepat.Pencarian data kehadiran siswa dapat dilakukan berdasarkan nama atau NIS siswa pada suatu periode waktu (misal dari tanggal 1 januari 2007 sampai dengan 1 Juni 2007) atau sekelompok siswa dengan kategori tertentu sesuai dengan filter pencarian yang telah disediakan.
2. Kedisiplinan Fitur ini berisikan informasi mengenai peraturan sekolah
beserta "poin hukuman" yang akan dikenakan untuk setiap pelanggaran kedisiplinan yang dilakukan siswa. Setiap siswa yang melakukan pelanggaran secara otomatis akan
mendapatkan poin hukuman sesuai dengan bentuk pelanggaran yang dilakukan.
3. Pengumuman Fitur pengumuman digunakan untuk membuat pengumuman
dan informasi singkat yang akan disosialisasikan kepada guru, karyawan dan murid. Pengumuman dan informasi singkat akan ditampilkan pada halaman depan program.
3.1.1.4. DigiSchool
DigiSchool dikembangkan oleh PT Indosat Mega Media bekerja sama dengan PT Multimedia Solusi Prima. Pengguna sistem informasi berbasis web ini adalah siswa, guru, staf akademik dan staf perpustakaan. Fitur digiSchool yang berhubungan dengan kegiatan akademik dapat dilihat pada Tabel 3.4.
Tabel 3.4 – Fitur DigiSchool
No. Nama Fitur Keterangan
1. Nilai Menyimpan informasi nilai tiap siswa sehingga dapat
dilihat oleh siswa yang bersangkutan dan orang lain yang berhak.
No. Nama Fitur Keterangan
diambil oleh siswa. Buku-buku referensi, silabus, bahan ajar yang dapat diunduh, serta tugas-tugas dapat dilihat disini.
3. Jadwal KBM Menampilkan informasi jadwal kegiatan belajar mengajar
tiap hari dan slot waktu KBM. Informasi guru yang mengajar juga ditampilkan disini.
4. Komunikasi Guru dengan siswa dapat saling berkirim pesan untuk
memudahkan komunikasi antara keduanya.
3.1.2. Perbandingan Fitur
Eksplorasi terhadap aplikasi-aplikasi tersebut memberikan gambaran mengenai permasalahan yang dilingkupi framework. Tabel 3.5 berisi daftar lingkup permasalahan yang ditangani oleh keempat aplikasi dan dukungan tiap-tiap aplikasi terhadap lingkup masalah tersebut.
Tabel 3.5 – Lingkup Masalah Framework
No. Lingkup Masalah ASS Sisfokol SI Sekolah DigiSchool
1. Kehadiran siswa
2. Pembuatan kalender akademik
dan pengumuman
3. Penilaian tiap mata pelajaran
4. Pembuatan laporan kemajuan
akademik siswa
5. Pengaturan jadwal pelajaran
6. Kegiatan belajar mengajar
7. Kegiatan ekstra kulikuler
8. Perwalian
9. Kedisiplinan
10. Komunikasi
Dari dukungan aplikasi-aplikasi sistem informasi sekolah terhadap lingkup masalah pada Tabel 3.5, ditentukan batasan masalah yang akan dilingkupi framework. Banyaknya tanda centang menandakan lingkup masalah tersebut harus dapat ditangani framework yang dibangun. Sebaliknya, framework yang akan dibangun tidak perlu menangani lingkup masalah di mana hanya sebagian kecil aplikasi yang mendukungnya seperti pada lingkup masalah kegiatan ekstrakurikuler, perwalian, kedisiplinan, komunikasi, dan soal ujian.
Lingkup masalah yang ditangani oleh framework meliputi: 1. Kehadiran siswa,
2. Pembuatan kalender akademik dan pengumuman, 3. Penilaian tiap mata pelajaran,
4. Pembuatan laporan kemajuan akademik siswa, 5. Pengaturan jadwal pelajaran
6. Kegiatan belajar mengajar tiap hari
Keenam lingkup masalah framework tersebut akan menjadi kebutuhan framework.
3.2. Analisis Kebutuhan Framework
Berdasarkan klasifikasi framework pada Subbab 2.3, framework yang akan dibangun memiliki klasifikasi sebagai berikut:
1. Lingkup: enterprise application framework
Framework aplikasi sistem informasi sekolah yang akan dibangun mendukung pengembangan aplikasi untuk pengguna akhir (end user) dan produk secara langsung.
2. Teknik pengembangan: gray-box framework
Gray-box framework memadukan white-box dan black-box dengan mengambil keuntungan yang dimiliki dari masing-masing teknik tersebut. Gray-box framework menggunakan pendekatan pewarisan (inheritance) dan komposisi (composition), bisa terdiri dari kelas abstrak dan kelas kongkrit
3. Tingkat generalitas: vertikal framework
Framework yang akan dibangun ditujukan untuk pengembangan aplikasi yang spesifik pada domain masalah sekolah.
Berdasarkan analisis domain pada Subbab 3.1, didapat kebutuhan fungsional dan kebutuhan non-fungsional framework. Kebutuhan fungsional merupakan fitur yang harus ada pada aplikasi yang akan dibangun agar aktivitas dalam lingkungan organisasi, dalam hal ini sekolah, dapat berjalan. Penentuan kebutuhan fungsional framework didasarkan pada lingkup masalah yang ditangani framework yang telah dijelaskan pada Subbab 3.1.2. Tabel 3.6 berisi kebutuhan fungsional framework yang akan dibangun.
Tabel 3.6 – Kebutuhan Fungsional Framework
SRS Kebutuhan Fungsional Keterangan
SRS-F-01 Penilaian tiap mata pelajaran Menyimpan seluruh komponen nilai setiap
siswa seperti nilai tugas, kuis, pekerjaan rumah, ulangan, ujian semester dan lainnya. Kemudian mengalkulasi sesuai dengan kebijakan sekolah hingga diperolah nilai akhir. Sama seperti absensi, nilai siswa dapat dilihat orang lain yang berhak yaitu wali siswa dan guru.
SRS-F-02 Pencatatan kehadiran siswa Mencatat kehadiran siswa dalam kegiatan
belajar mengajar, membuat laporan kehadiran dalam jangka waktu tertentu, dan juga memberikan akses pada penguna yang berhak untuk melihat kehadiran siswa.
SRS-F-03 Pembuatan silabus pelajaran Silabus pelajaran berisi rencana pelajaran untuk satu semester. Resume dan bahan pelajaran dalam bentuk softcopy dapat diambil disini.
SRS-F-04 Pembuatan kalendar
akademik
Kalendar akademik menampilkan agenda penting dalam satu tahun ajaran atau semester seperti libur nasional, ujian, dan kegiatan lainnya yang diadakan sekolah. Selain itu, pembuatan surat yang berisi pengumuman kegiatan-kegiatan di sekolah dapat dilakukan secara otomatis sehingga membantu tugas dari staf administrasi.
SRS-F-05 Pengaturan jadwal pelajaran Informasi mengenai jadwal pelajaran seperti waktu, mata pelajaran, pengajar dan ruang belajar bagi kelas yang menerapkan kelas
SRS Kebutuhan Fungsional Keterangan
berpindah (moving class) disediakan disini. Fitur ini juga mengatur alokasi guru dalam mengajar dan ruangan agar tidak bentrok.
SRS-F-06 Pembuatan laporan kemajuan
prestasi siswa
Laporan kegiatan belajar mengajar, prestasi akademik siswa selama satu semester dapat dihasilkan secara otomatis.
Tidak seperti kebutuhan fungsional, kebutuhan non-fungsional tidak secara langsung berhubungan dengan proses bisnis dalam kegiatan akademik tetapi lebih pada dukungan agar proses bisnis yang dikelola sistem informasi akademik ini berjalan dengan lancar dan sesuai harapan pengguna. Tabel 3.7 berisi kebutuhan non-fungsional framwork yang akan dibangun.
Tabel 3.7 – Kebutuhan Non-Fungsional Framework
SRS Kebutuhan Non-
Fungsional
Keterangan
SRS-N-01 Keamanan data Data yang disimpan pada basis data harus
dijamin keamanannya baik dari pengguna yang tidak mempunyai hak akses hingga ancaman hilangnya data akibat rusaknya perangkat keras. Sistem harus dapat melakukan autentifikasi dan memberikan otorisasi pada pengguna sesuai dengan peranannya. Selain itu, back-up terhadap basis data harus dapat dilakukan sistem secara berkala.
3.3. Pemodelan Framework
Pemodelan framework akan lebih memperjelas spesifikasi framework yang akan dibangun sesuai dengan hasil analisis pada Subbab 3.2.1. Pemodelan yang dilakukan mencakup pemodelan fungsionalitas, pemodelan interaksi elemen dalam sistem, dan pemodelan kelas potensial.
Pemodelan fungsionalitas menghasilkan diagram use case. Skenario use case dan sequence diagram dihasilkan dari pemodelan interaksi elemen dalam sistem. Sedangkan pemodelan kelas potensial menghasilkan identifikasi paket dan kelas analisis.
3.3.1. Pemodelan Fungsionalitas Autentikasi Pengguna Melihat Kalendar Melihat Jadwal Melihat Nilai Melihat Silabus Melihat Laporan Viewer
Melihat Pres ensi
Mengedit Nilai
Mem buat Laporan
Mengedit Kalendar
Mengedit Jadwal
Mengedit Silabus Editor
Mengedit Presensi
Gambar 3.1 – Diagram Use Case Aplikasi Sistem Informasi Sekolah
Diagram use case pada Gambar 3.1 memberikan gambaran fitur yang dicakup framework yang akan dibangun. Dari tiap use case yang terdefinisi dihasilkan sekenario use case, baik untuk kasus normal maupun alternatif.
Penentuan aktor didasarkan pada jumlah tipe orang atau sistem lain yang menggunakan sistem. Pada diagram use case Gambar 3.1 terdiri dari 2 aktor yaitu editor dan viewer. Aktor-aktor lainnya seperti siswa, guru, dan staf dapat diturunkan dari kedua aktor tersebut. Tabel 3.8 berisi definisi tiap aktor.
Tabel 3.8 – Definisi Aktor
No. Aktor Deskripsi
AC-001 Viewer Aktor ini hanya memiliki akses untuk melihat
fitur-fitur yang ada pada aplikasi. Siswa, orang tua, dan wali siswa merupakan contoh Viewer.
AC-002 Editor Sama seperti viewer tapi memiliki akses untuk
mengubah isi dari fitur-fitur perangkat lunak. Contoh aktor ini adalah guru dan staf administrasi.
Sedangkan penentuan use case didasarkan pada fungsi-fungsi yang diimplementasikan dalam aplikasi. Tabel 3.9 berisi penjelasan tiap use case yang terdapat pada diagram use case dan Tabel 3.10 memperlihatkan keterhubungan kebutuhan framework dengan use case. Untuk setiap use case yang terdefinisi dibuat skenario use case. Skenario use case Mengedit Nilai dapat dilihat pada Tabel 3.11 hingga Tabel 3.14. Sedangkan skenario untuk seluruh use case dapat dilihat pada lampiran A Subbab 2.3.4.
Tabel 3.9 – Deskripsi Use Case
No. Use Case Deskripsi
UC-001 Autentikasi pengguna Melakukan autentikasi terhadap pengguna agar
dapat menggunakan aplikasi.
UC-002 Mengedit nilai Fungsi ini digunakan untuk memasukan atau
mengubah nilai yang didapat siswa pada mata pelajaran tertentu.
UC-003 Melihat nilai Pegawai, siswa maupun guru dapat melihat nilai
yang diperoleh oleh siswa, baik itu rincian nilai maupun nilai akhir yang diperoleh.
UC-004 Mengedit presensi Mengisi dan mengubah kehadiran tiap siswa.
UC-005 Melihat presensi Menampilkan absensi siswa, jumlah hadir, sakit,
izin dan tanpa keterangan.
UC-006 Mengedit silabus Fungsi ini digunakan untuk menambahkan,
mengurangi ataupun mengubah silabus mata pelajaran.
UC-007 Melihat silabus Pada halaman ini, terdapat silabus mata pelajaran
No. Use Case Deskripsi
UC-008 Mengedit kalender Melakukan perubahan terhadap kalender akademik
sekolah.
UC-009 Melihat kalender Menampilkan kalender akademik yang berisi
hari-hari belajar mengajar, libur sekolah, libur nasional, dan kegiatan lainnya yang berhubungan dengan akademik sekolah.
UC-010 Mengedit jadwal Melakukan perubahan terhadap jadwal pelajaran
yang diselenggarakan.
UC-011 Melihat jadwal Menampilkan jadwal pelajaran dan guru yang
mengajar dalam satu minggu.
UC-012 Membuat laporan Membuat raport siswa.
UC-013 Melihat laporan Menampilkan rekapitulasi nilai dan kehadiran dalam
jangka waktu tertentu (semester) untuk melihat kemajuan prestasi siswa.
Tabel 3.10 – Keterhubungan Kebutuhan Framework dengan Use Case
Nomor SRS Nomor Use Case
SRS-F-01 UC-002, UC-003 SRS-F-02 UC-004, UC-005 SRS-F-03 UC-006, UC-007 SRS-F-04 UC-008, UC-009 SRS-F-05 UC-010, UC-011 SRS-F-06 UC-012, UC-013 SRS-N-01 UC-001
Tabel 3.11 – Skenario Normal Use Case Mengedit Nilai
Aksi Aktor Reaksi Sistem
1. Memilih halaman edit nilai
2. Menampilkan halaman utama edit nilai yang berisi daftar pelajaran yang
berhubungan dengan pengguna. 3. Memilih salah satu pelajaran
Aksi Aktor Reaksi Sistem
4. Menampilkan halaman edit nilai pelajaran yang dipilih
Beberapa hal yang dapat dilakukan pengguna yaitu:
5a. Memasukan nilai yang diperoleh tiap siswa ke sistem kemudian memilih untuk menyimpan nilai tersebut
5b. Sub skenario UC-002-S01 5c. Sub skenario UC-002-S02 5d. Sub skenario UC-002-S03
6a. Sistem melakukan penyimpanan pada basis data kemudian menampilkan konfirmasi bahwa nilai telah disimpan
Tabel 3.12 – Sub Skenario UC-002-S01
Aksi Aktor Reaksi Sistem
5b. Memilih mengedit nilai kemudian mengubah nilai tersebut. Pengguna lalu memilih untuk menyimpan nilai tersebut
6b. Mengubah basis data sesuai dengan perbahan yang dilakukan pengguna kemudian menampilkan konfirmasi perubahan tersebut.
Tabel 3.13 – Sub Skenario UC-002-S02
Aksi Aktor Reaksi Sistem
5c. Melakukan penambahan komponen nilai
6c. Menampilkan form penambahan komponen nilai.
7c. Memasukan nama komponen nilai yang akan ditambahkan dan juga bobot nilai tersebut.
8c. Meyimpanan penambahan tersebut pada basis data kemudia menambahkan kolom yang berisi komponen nilai yang baru pada tabel nilai.
Tabel 3.14 – Sub Skenario UC-002-S03
Aksi Aktor Reaksi Sistem
Aksi Aktor Reaksi Sistem
6d. Melakukan perhitungan nilai akhir berdasarkan bobot pada setiap komponen nilai, menyimpan nilai akhir tersebut pada basis data kemudian menampilkannya pada halaman edit nilai.
3.3.2. Pemodelan Interaksi Elemen
Pemodelan interaksi elemen dilakukan dengan membuat sequence diagram. Sequence diagram menggambarkan interaksi antara pengguna dengan sistem maupun interaksi antar elemen atau objek dalam sistem. Untuk setiap kasus normal pada skenario use case, didefinisikan sequence diagram. Contoh sequence diagram untuk use case Mengedit Nilai digambarkan pada Gambar 3.2. Sedangkan untuk keseluruhan sequence diagram untuk tiap use case dapat dilihat pada lampiran A. Ada sedikit perbedaan antara sequence diagram pada pembangunan framework yang menggunakan notasi UML-F seperti dijelaskan pada Subbab 2.5. Pada Gambar 3.2 dapat dilihat penggunaan tag {optional} pada objek HitungNilai. Tag tersebut menandakan bahwa implementasi HitungNilai merupakan pilihan bagi pengembang aplikasi.
3.3.3. Pemodelan Paket dan Kelas Analisis
Berdasarkan objek yang teridentifikasi dalam pendefinisian sequence diagram, diperoleh kelas-kelas yang terdapat pada Tabel 3.15. Pada tahap analisis framework ini, teridentifikasi 30 kelas potensial yang terbagi ke dalam 7 paket. Pembagian paket berdasarkan fitur-fitur framework yang telah didefinisikan pada Tabel 3.9. Keterhubungan antar paket dapat dilihat pada Gambar 3.3.
Editor : FormEditNilai : TableNilai : Nilai : HitungNilai showEditNilai() showEditNilai() submit() ViewNilai() s etValue() setNilaiAkhir() Calculate() tableNilai getNilai() nilai {optional} update() getLis tPelajaran() listPelajaran
Gambar 3.2 – Sequence Diagram untuk Use Case Mengedit Nilai Tabel 3.15 – Kelas-Kelas Potensial Tahap Analisis
No. Nama Kelas Jenis
Paket Autentikasi 1. FormLogin boundary 2. Autentikasi controller 3. User entity Paket Nilai 4. FormLihatNilai boundary 5. FormEditNilai boundary 6. TableNilai controller 7. HitungNilai controller 8. Nilai entity Paket Presensi 9. FormLihatPresensi boundary 10. FormEditPresensi boundary 11. TablePresensi controller 12. Kehadiran entity
No. Nama Kelas Jenis Paket Silabus 13. FormLihatSilabus boundary 14. FormEditSilabus boundary 15. TableSilabus controller 16. SilabusInfo controller 17. SilabusPelajaran entity Paket Kalendar 18. FormLihatKalendar boundary 19. FormEditKalendar boundary 20. TableKalendar controller 21. Agenda entity Paket Jadwal 22. FormLihatJadwal boundary 23. FormEditJadwal boundary 24. TableJadwal controller 25. JadwalPelajaran entity Paket Laporan 26. FormLihatLaporan boundary 27. FormEditLaporan boundary 28. TableLaporan controller 29. KomponenLaporan controller 30. Raport entity
Gambar 3.3 – Diagram Paket Tahap Analisis
3.4. Analisis Hot Spot
3.4.1. Hot Spot Card
Seperti telah dijelaskan pada Subbab 2.2.3, hot spot merupakan bagian framework yang dapat diubah sesuai dengan kebutuhan aplikasi yang akan dikembangkan. Dengan melakukan eksplorasi lebih mendalam terhadap fitur-fitur aplikasi pada domain yang sama, dapat diketahui fungsi-fungsi mana saja yang berubah-ubah pada tiap aplikasi. Dari hasil eksplorasi tersebut dihasilkan kartu hot spot untuk mengidentifikasi kebutuhan aplikasi yang berubah-ubah [PRE00]. Sebuah kartu hot spot berisi nama hot spot, tingkat fleksibilitas, deskripsi framework dan fungsionalitas pada sekurangnya dua aplikasi yang berbeda. Layout kartu hot spot dapat dilihat pada Gambar 3.4
Gambar 3.4 – Layout Hot Spot Card [PRE00]
Untuk membangun framework yang lengkap dengan banyak hot spot agar dapat mengakomodasi fleksibilitas aplikasi yang dibangun dibutuhkan iterasi yang berulang. Semakin banyak iterasi yang dilakukan, akan semakin banyak variasi yang ditemukan. Tetapi hal tersebut memakan waktu yang lama. Oleh karena itu, pada tugas akhir ini hanya dilakukan satu kali iterasi selama proses pengembangan framework. Hal ini sudah cukup untuk membangun framework sederhana sesuai dengan batasan masalah pada Subbab 1.4. Beberapa variasi yang terdapat pada aplikasi yang dieksplorasi adalah sebagai berikut:
1. ASS, Sisfokol dan DigiSchool yang menangani masalah penilaian mata pelajaran memiliki fitur yang berbeda dalam hal perhitungan nilai akhir. Perhitungan nilai akhir pada Sisfokol dan digiScool tidak dilakukan secara otomatis melainkan harus dimasukan secara manual oleh guru. Berbeda dengan ASS yang dikembangkan secara khusus untuk sebuah sekolah, perhitungan nilai akhir dilakukan secara otomatis sesuai bobot tiap mata pelajaran. Kartu hot spot perhitungan nilai akhir dapat dilihat pada Gambar 3.5.
2. ASS memiliki fitur menampilkan silabus pelajaran dan pengumuman tugas yang diberikan oleh guru. Sisfokol tidak menampilkan silabus pelajaran seperti pada ASS, tetapi memiliki fitur untuk menampilkan soal ujian. Fitur yang berbeda juga terdapat pada DigiSchool. Selain dapat melihat silabus pelajaran, pengguna juga dapat melihat informasi mengenai pelajaran tersebut dan guru yang mengajar. Selain itu, buku-buku yang berhubungan dengan pelajaran tersebut dapat diakses pada fitur referensi dan pengguna juga dapat
mengunduh bahan ajar yang disampaikan di kelas. Kartu hot spot informasi tambahan silabus dapat dilihat pada Gambar 3.6.
3. Laporan pada sisfokol berbentuk buku raport siswa yang berisi nilai akhir tiap mata pelajaran yang diikuti siswa, laporan kegiatan ekstrakurikuler dan rekapitulasi ketidakhadiran siswa selama satu semester. Sedangkan SI Sekolah hanya menghasilkan laporan rekapitulasi kehadiran siswa dalam jangka waktu tertentu. Kartu hot spot isi laporan dapat dilihat pada Gambar 3.7.
Gambar 3.5 – Kartu Hot Spot Perhitungan Nilai Akhir
Gambar 3.7 – Kartu Hot Spot Isi Laporan
3.4.2. Kelas-Kelas Hot Spot
Berdasarkan kartu hot spot pada Subbab 3.4.1 dan hasil pemodelan kelas potensial framework pada Subbab 3.3.3, dapat ditentukan kelas mana saja memiliki hot spot. Ada tiga kelas yang diidentifikasi memiliki hot spot yaitu kelas Table_Nilai, Silabus_Info, dan Komponen_Laporan. Keterhubungan hot spot dengan kelas dapat dilihat pada Tabel 3.16.
Tabel 3.16 – Keterhubungan Hot Spot dengan Kelas
No. Nama Hot Spot Nama Kelas
1. Perhitungan Nilai Akhir Table_Nilai
2. Informasi Tambahan Silabus Silabus_Info
3. Isi Laporan Komponen_Laporan
3.4.2.1. Kelas Table_Nilai
Kelas Table_Nilai bertanggungjawab untuk mengambil nilai dari basis data sesuai permintaan pengguna, menambahkan nilai baru pada basis data, dan mengubah nilai pada basis data. Metode hitungNilai pada kelas Table_Nilai memiliki tagged value variable dan dynamic yang berarti pengembang aplikasi harus mengimplementasikan metode tersebut pada saat implementasi framework. Diagram kelas Table_Nilai dapat dilihat pada Gambar 3.8.
Gambar 3.8 – Diagram Kelas Table_Nilai
3.4.2.2. Kelas Silabus_Info
Kelas Silabus_Info bertanggungjawab untuk memberikan informasi tambahan pada silabus. Tagged value extensible menandakan antarmuka kelas ini tergantung instansiasi framework yang memungkinkan pendefinisian metode baru untuk menambah fungsionalitas kelas. Metode show pada kelas Silabus_Info memiliki tagged value variable dan static yang berarti pengembang aplikasi harus mengimplementasikan metode tersebut pada saat implementasi framework untuk menampilakan informasi tambahan pada silabus. Diagram kelas Silabus_Info dapat dilihat pada Gambar 3.9.
Gambar 3.9 – Diagram Kelas Silabus_Info
3.4.2.3. Kelas Komponen_Laporan
Kelas ini fungsinya hampir sama dengan kelas Silabus_Info. Komponen_Laporan bertanggungjawab untuk menampilkan komponen tambahan pada laporan. Tagged
value extensible menandakan antarmuka kelas ini tergantung instansiasi framework yang memungkinkan pendefinisian metode baru untuk menambah fungsionalitas kelas. Metode show pada kelas Silabus_Info memiliki tagged value variable dan static yang berarti pengembang aplikasi harus mengimplementasikan metode tersebut pada saat implementasi framework untuk menampilkan komponen yang akan ditambahkan. Diagram kelas Komponen_Laporan dapat dilihat pada Gambar 3.10.
Gambar 3.10 – Diagram Kelas Komponen_Laporan
3.5. Analisis Kebutuhan Dokumentasi Framework
Sebelum menentukan jenis dokumentasi yang akan dibuat, harus diketahui dahulu untuk siapa framework dibangun. Pengguna framework terdiri dari beberapa macam yaitu pengembang aplikasi (application developer), pemelihara framework (framework maintainer), pengembang framework lain, dan pemeriksa framework (framework verifier). Pengguna framework yang akan dikembangkan dalam tugas akhir ini adalah pengembang aplikasi, oleh karena itu dokumentasi yang disertakan harus disesuaikan dengan kebutuhan pengembang aplikasi.
Seperti telah dijelaskan pada Subbab 2.6, dibutuhkan usaha yang tidak sedikit untuk memahami sebuah framework, terutama bagi pengembang aplikasi yang pertama kali menggunakan framework untuk membuat aplikasi. Dokumentasi dibuat dengan maksud meringankan beban pengembang aplikasi dalam memahami framework sehingga pengembang dapat lebih berkonsentrasi pada tujuannya yaitu membuat aplikasi.
Dokumentasi bukan merupakan produk “gratis” dari proses pengembangan framework tetapi dibutuhkan usaha dan sumber daya yang cukup besar untuk membuatnya. Pengembang framework harus menyediakan waktu dan tenaga tambahan untuk membuat dokumentsi framework yang baik dan mudah dipahami pengguna.
Oleh karena itu, pembuatan dokumentasi harus disesuaikan dengan kebutuhan pengguna framework yaitu pengembang aplikasi. Subab 2.6 menjelaskan beberapa jenis dokumentasi yang dapat membantu pengguna framework dari mulai Cookbook , Subbab 2.6.1, hingga design notebook, Subbab 2.6.6. Tidak semua jenis dokumentasi tersebut dibutuhkan oleh pengembang aplikasi karena pengembang aplikasi tidak perlu secara mendalam mengetahui detail dari framework seperti kelas-kelas yang ada, hubungannya, peubah dan konstanta pada tiap kelas tersebut. Pengembang aplikasi hanya perlu mengetahui bagaimana menginstansiasi hot spot pada framework sesuai dengan kebutuhan perangkat lunak yang dikembangkan.
