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 III-1
III-2 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 berlangsung kegiatan belajar mengajar.
siswa
selama
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
III-3 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
III-4 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
III-5 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.
2.
Mata pelajaran
Fitur ini berisi informasi mengenai mata pelajaran yang
III-6 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
11.
Soal ujian
III-7 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
III-8 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
III-9 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 nonfungsional framwork yang akan dibangun. Tabel 3.7 – Kebutuhan Non-Fungsional Framework
SRS SRS-N-01
Kebutuhan NonFungsional Keamanan data
Keterangan 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.
III-10 3.3.1. Pemodelan Fungsionalitas
Autentikasi Pengguna
Melihat Kalendar
Melihat Jadwal
Melihat Nilai
Melihat Laporan Viewer Melihat Silabus
Melihat Presensi
Mengedit Nilai
Membuat Laporan
Editor
Mengedit Kalendar
Mengedit Jadwal
Mengedit Silabus
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.
III-11 Tabel 3.8 – Definisi Aktor
No.
Aktor
Deskripsi
AC-001
Viewer
Aktor ini hanya memiliki akses untuk melihat fiturfitur 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 yang diambil oleh siswa pada semester berjalan.
III-12 No.
Use Case
Deskripsi
UC-008
Mengedit kalender
Melakukan perubahan terhadap kalender akademik sekolah.
UC-009
Melihat kalender
Menampilkan kalender akademik yang berisi harihari 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 1. Memilih halaman edit nilai
Reaksi Sistem 2. Menampilkan halaman utama edit nilai yang berisi daftar pelajaran yang berhubungan dengan pengguna.
3. Memilih salah satu pelajaran
III-13 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 5b. Memilih mengedit nilai kemudian mengubah nilai tersebut. Pengguna lalu memilih untuk menyimpan nilai tersebut
Reaksi Sistem
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 5c. Melakukan penambahan komponen nilai
Reaksi Sistem 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 5d. Memilih untuk menghitung nilai akhir.
Reaksi Sistem
III-14 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.
III-15
Editor
: TableNilai
: FormEditNilai
: Nilai
: HitungNilai
showEditNilai() getListPelajaran() listPelajaran
showEditNilai() ViewNilai() getNilai() nilai tableNilai
update() submit() Calculate()
{optional}
setNilaiAkhir() setValue()
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
III-16 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
III-17
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
III-18
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
III-19 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.6 – Kartu Hot Spot Informasi Tambahan Silabus
III-20
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.
III-21
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
III-22 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.
III-23 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.
