Upload
dangdat
View
217
Download
0
Embed Size (px)
Citation preview
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
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 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
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 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.
III-10
3.3.1. Pemodelan Fungsionalitas
Autentikasi Pengguna
Melihat Kalendar
Melihat Jadwal
Melihat Nilai
Melihat Silabus
Melihat Laporan
Viewer
Melihat Presensi
Mengedit Nilai
Membuat 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.
III-11
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
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 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
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 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
5d. Memilih untuk menghitung nilai akhir.
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 : FormEditNilai : TableNilai : HitungNilai : Nilai
showEditNilai()
showEditNilai()
submit()
ViewNilai()
setValue()
setNilaiAkhir()
Calculate()
tableNilai
getNilai()
nilai
{optional}
update()
getListPelajaran()
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
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.