EVALUASI SKEMA BASIS DATA AKADEMIK TERINTEGRASI
MENGGUNAKAN
OBJECT-ORIENTED METRICS
DAN
PENGEMBANGAN PROTOTIPE PENDAFTARAN
ONLINE
SEMINAR
PUNGKI PRAYUGHI
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR
PERNYATAAN MENGENAI TESIS DAN
SUMBER INFORMASI SERTA PELIMPAHAN HAK CIPTA*
Dengan ini saya menyatakan bahwa tesis berjudul Evaluasi Skema Basis Data Akademik Terintegrasi Menggunakan Object-Oriented Metrics dan Pengembangan Prototipe Pendaftaran Online Seminar adalah benar karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi mana pun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhir tesis ini.
Dengan ini saya melimpahkan hak cipta dari karya tulis saya kepada Institut Pertanian Bogor.
Bogor, Oktober 2015
Pungki Prayughi
RINGKASAN
PUNGKI PRAYUGHI. Evaluasi Skema Basis Data Akademik Terintegrasi Menggunakan Object-Oriented Metrics dan Pengembangan Prototipe Pendaftaran
Online Seminar. Dibimbing oleh IRMAN HERMADI dan HERU SUKOCO.
Dewasa ini peranan sistem informasi yang berkualitas di pendidikan tinggi sangatlah penting, terutama dalam pemenuhan kebutuhan pelayanan yang efektif dan efisien bagi pemangku kepentingan. Sekolah Pascasarjana (SPs) Institut Pertanian Bogor (IPB) merupakan penyelenggara pendidikan pascasarjana yang mempunyai tanggung jawab dalam mengembangkan sistem informasi yang berkualitas untuk mendukung proses bisnisnya.
Penelitian ini melakukan evaluasi sistem yang berjalan di SPs IPB dan melakukan analisis dan perancangan sistem menggunakan pendekatan sistem berorientasi objek berdasarkan skema kelas diagram terintegrasi yang telah dibangun oleh Direktorat Integrasi Data dan Sistem Informasi (DIDSI) IPB. Pengembangan prototipe pendaftaran seminar hasil penelitian secara online
dirancang dengan tujuan untuk mengurangi beban pelayanan administrasi akademik, serta memberikan kemudahan pelayanan bagi mahasiswa dan pengelola. Prototipe yang dikembangkan menggunakan skema basis data terintegrasi IPB yang terlebih dahulu dilakukan pengujian menggunakan teknik tradisional dan
Object-Oriented Metrics (OOM) dengan pendekatan Goal Questions Metrics (GQM) untuk
menghasilkan rancangan sistem yang berkualitas, lebih reliable, usable dan
maintainable.
Pengujian dilakukan untuk mengetahui tingkat complexity, coupling dan
cohesion (CCC) rancangan kelas dengan menggunakan metrik, diantaranya: Lines
of Codes (LOC), Weighted Methods per Class (WMC), Coupling Between Objects
(CBO), Tight Class Cohesion (TCC), Loose Class Cohesion (LCC), dan Lack of
Cohesion on Method (LCOM). Penelitian ini menghasilkan kriteria pengukuran
tingkat metrik CCC, dengan hasil sembilan belas rancangan kelas bernilai sangat baik dan baik, sembilan kelas dikategorikan sebagai rancangan yang kurang baik, tiga rancangan kelas memperoleh nilai tidak baik. Hasil perancangan ulang dilakukan terhadap tiga rancangan kelas yang tidak baik dengan membagi ke beberapa kelas yang lebih kecil, dan memperoleh hasil nilai CCC yang lebih baik setelah dilakukan pengujian ulang, serta dijadikan rekomendasi kepada pihak pengelola. Hasil pengamatan pada sistem yang berjalan menyatakan bahwa sistem belum berjalan optimal, serta responden juga sangat setuju pada penambahan fitur pelayanan online kedepan.
Kata kunci: Coupling Between Objects, Goal Question Metrics, Lack Cohesion on
SUMMARY
PUNGKI PRAYUGHI. Evaluation of Integrated Academic Database Scheme Using Object-Oriented Metrics and Online Registration Seminar Prototype
Development. Supervised by IRMAN HERMADI and HERU SUKOCO.
The importance of quality of information system in higher education is crucial nowadays, especially in meeting the needs of an effective and efficient services for the stakeholders. Bogor Agricultural University (IPB) Graduate School (SPs) as a postgraduate education provider has a responsibility to develop quality information systems to support the business processes.
This study evaluated the running system at the Graduate School of IPB and performed analysis and design of systems using object-oriented approach based on an integrated class diagram scheme that has been built by DIDSI IPB. Development of prototype online registration seminar was designed to reduce the burden of academic administrative services, as well as provided benefits service for students and SPs. The prototype, using an integrated database schema IPB, was first tested using traditional techniques and OOM with the approach of GQM to produce a high quality system design, more reliable, usable and maintainable.
Testing was conducted to determine the level of complexity, coupling and cohesion (CCC) design class by using metrics, such as Lines of Codes (LOC), Weighted Methods per Class (WMC), Coupling Between Objects (CBO), Tight Class Cohesion (TCC), Loose Class Cohesion (LCC), and Lack of Cohesion on Method (LCOM). This research provided metrics measurement criteria CCC level, with the results that nineteen-class design is excellent and well design, nine classes categorized as not well design, three draft classes were received grades as poorly designed. Observations on the running systems stating that the system was not yet functionally optimal, and respondents also strongly agreed on the additional features of online services in the future.
© Hak Cipta Milik IPB, Tahun 2015
Hak Cipta Dilindungi Undang-Undang
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan atau menyebutkan sumbernya. Pengutipan hanya untuk kepentingan pendidikan, penelitian, penulisan karya ilmiah, penyusunan laporan, penulisan kritik, atau tinjauan suatu masalah; dan pengutipan tersebut tidak merugikan kepentingan IPB
Dilarang mengumumkan dan memperbanyak sebagian atau seluruh karya tulis ini
Tesis
sebagai salah satu syarat untuk memperoleh gelar Magister Komputer
pada
Program Studi Ilmu Komputer
EVALUASI SKEMA BASIS DATA AKADEMIK TERINTEGRASI
MENGGUNAKAN
OBJECT-ORIENTED METRICS
DAN
PENGEMBANGAN PROTOTIPE PENDAFTARAN
ONLINE
SEMINAR
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR
BOGOR 2015
PRAKATA
Puji dan syukur penulis panjatkan kepada Allah Subhanahu Wa Ta’ala atas segala karunia-Nya sehingga karya ilmiah ini berhasil diselesaikan. Tema yang dipilih dalam penelitian berdasarkan atas apa yang dibutuhkan di institusi tempat saya berkarir dan untuk memberikan kemudahan dalam menjalankan proses administrasi dan layanan di Sekolah Pascasarjana IPB. Penelitian ini mulai pada bulan September 2014 dengan judul Evaluasi Skema Basis Data Akademik Terintegrasi Menggunakan Object-Oriented Metrics dan Pengembangan Prototipe Pendaftaran Online Seminar.
Terima kasih penulis ucapkan kepada Bapak Irman Hermadi, SKom MS PhD dan DrEng Heru Sukoco, SSi MT selaku pembimbing, serta Bapak DrEng Wisnu Ananta Kusuma, ST MT, Ibu Dr Yani Nurhadryani, SSi MT dan Bapak Toto Haryanto, Skom MKom yang telah banyak memberi masukkan dan saran. Penghargaan setinggi-tingginya penulis sampaikan kepada Bapak Dr Ir Dahrul Syah, MScAgr beserta segenap Pimpinan Sekolah Pascasarjana IPB, Ibu Ir Ratu Siti Zaenab, M.Si atas arahan dan dukungannya, serta seluruh rekan Tenaga Kependidikan Sekolah Pascasarjana IPB atas kerjasamanya selama ini, tidak lupa kepada mendiang Ibu Dr Dra Nastiti Kusumorini atas nasihat, dukungan dan kepercayaannya.
Ungkapan terima kasih yang sangat kepada Almarhum ayah dan ibu tercinta, serta seluruh keluarga, atas segala doa dan kasih sayangnya. Kepada istriku tersayang Inge Julia Puspitahati and my angels Tabinazzahra, Muhammad Dhiaraja, dan Rafa Reisya Rizki, terima kasih atas segalanya.
Terima kasih juga penulis sampaikan kepada teman-teman seperjuangan yang selalu membantu, antara lain; Puspa Eosina Hosen, Vidy Nalendra, Kana Saputra Siregar, Tengku Khairil Ahsyar, Akbar Sugih Miftahul Huda, Pizaini, A. Muh. Yakin Amin, Firmansyah Ibrahim, Rusdee Leekha, dan spesial untuk Wisard Widsli Kalengkongan untuk bantuannya membangun SEMORA hingga dapat terwujud, M. Syafiuddin Usman, Pangudi Citraning Putra, Riva Aktivia, Halimah Tus Sa'diah, Indah Puji Astuti, Yuyun Khairunisa, Melly Br Bangun, Zakhi Firmansyah, Irma Anggraeni, dan teman Sinergi (Fast-Track ILKOM), serta teman-teman lain yang saya tidak dapat sebutkan satu per satu.
Bagaimanapun Penulis menyadari bahwa masih terdapat banyak kekurangan pada penelitian ini dan masih jauh dari sempurna, semoga karya ilmiah ini bermanfaat.
Bogor, Oktober 2015
DAFTAR ISI
DAFTAR TABEL vi
DAFTAR GAMBAR vi
DAFTAR LAMPIRAN vi
1 PENDAHULUAN 1
Latar Belakang 1
Perumusan Masalah 3
Tujuan Penelitian 3
Manfaat Penelitian 3
Ruang Lingkup Penelitian 3
2 TINJAUAN PUSTAKA 4
Sekolah Pascasarjana IPB 4
Kuesioner dan Pengujian Instrumen Penelitian 5
Analisis dan Perancangan Berorientasi Objek 5
Spesifikasi Kebutuhan Perangkat Lunak 6
Deskripsi Perancangan Perangkat Lunak 6
Deskripsi Uji Perangkat Lunak 7
Pengukuran Rancangan 7
Goal Question Metrics 7
Tradisional Metrics 8
Object Oriented Metrics 8
Kompleksitas 9
Coupling 9
Cohesion 9
User Acceptance Testing 11
Scrum Backlog Product 11
3 METODE 12
Evaluasi sistem yang berjalan 12
Pengumpulan Kebutuhan 12
Penyusunan kuesioner 13
Penyebaran kuesioner 13
Pengujian Instrumen Penelitian 13
Pengolahan dan Analisis Data Kuesioner 14
Analisis 14
Perancangan 14
Pengukuran Rancangan 15
Goal Question metrics 15
Object Oriented Metrics 15
User Acceptance Testing 16
4 HASIL DAN PEMBAHASAN 17
Evaluasi sistem yang berjalan 17
Pengumpulan Kebutuhan 19
Penyusunan Kuesioner 19
Penyebaran Kuesioner dan Pengujian Instrumen Penelitian 20
Penyebaran kuesioner tahap satu 20
Pengujian Instrumen 20
Penyebaran kuesioner tahap dua 21
Pengolahan dan Analisis Data dengan Skala Likert 22
Analisa 23
Use Case Diagram Pelayanan Akademik 24
Use Case Description Pelayanan Akademik 24
Perancangan 30
Design Class Diagram Pendaftaran Online Seminar 33
Deskripsi Uji Perangkat Lunak 35
Object-oriented Measurement 36
Goal-Questions-Metrics 36
Scrum backlogproduct 43
Prototipe Pendaftaran Online Seminar Penelitian 45
Tujuan pengembangan prototipe 46
Prototipe pendaftaran online seminar 46
User Acceptance Testing 50
Pengujian prototipe 50
5 SIMPULAN DAN SARAN 53
Simpulan 53
Saran 53
DAFTAR PUSTAKA 54
DAFTAR TABEL
1. Pembagian kelas interval dan kriteria (Riduwan dan Akdon 2013) 14 2. Observasi jenis pelayanan administrasi akademik di SIMAK SPs berdasarkan
POB SPs IPB 17
3. Statistik frekuensi pelayanan SIMAK SPs berdasarkan POB SPs IPB 18 4. Hasil uji validitas dan reliabilitas instrumen penelitian 20 5. Hasil penilaian kuesioner tendik dengan skala Likert 22 6. Hasil penilaian kuesioner mahasiswa dengan skala Likert 23
7. Kode kelas sistem pelayanan akademik 34
8. Deskripsi uji perangkat lunak pendaftaran online seminar 35
9. Goal Question Metrics 36
10. Hasil pengukuran Object-Oriented measurement 37
11. Kompleksitas kelas 38
12. Klasifikasi kelas berdasarkan metrik CBO 39
13. Klasifikasi kelas berdasarkan metrik cohesion 39
14. Klasifikasi kategori penilaian rancangan 40
15. Pengukuran berdasarkan tingkat kompleksitas, coupling dan cohesion 40
16. Kode kelas usulan pembagian kelas 42
17. Hasil pengukuran OO Metrics terhadap kelas baru 43
18. Hasil pengukuran kelas baru 43
19. Scrum backlog product prototipe pendaftaran online seminar 44
20. Hasil pengujian prototipe 50
DAFTAR GAMBAR
1. Arsitektur sistem informasi SPs yang berjalan 4
2. Metodologi penelitian 12
3. Grafik frekuensi pelayanan POB SPs 11 19
4. Jenis kelamin Tendik 21
5. Pengalaman dengan SIMAK 21
6. Jenis kelamin mahasiswa 21
7. Pengalaman menggunakan SI 21
8. Intensitas mengakses SIMAK SPs 22
9. Domain model class diagram 24
10. Use case pelayanan akademik berdasarkan POB 25
11. Use case diagram pendaftaran online seminar 28
12. Activity diagram pendaftaran seminar 29
13. Sequence diagram pendaftaran seminar 30
14. Design class diagram mahasiswa berdasarkan strata 31
15. Design class diagram status dan pekerjaan objek pegawai 32
16. Design class diagram kurikulum dan kegiatan perkuliahan 33
17. Design class diagram pendaftaran online seminar 34
18. Interaction diagram sistem pendaftaran online seminar hasil 35
19. Pemecahan dari kelas MataKuliah 41
20. Pemecahan dari kelas SeminarMahasiswa 41
22. Arsitektur pendaftaran online seminar 45
23. Halaman muka pendaftaran online 46
24. Detail pemrasaran pada halaman muka 46
25. Fitur informasi jadwal seminar 47
26. Fitur informasi dan status akademik pemrasaran 48
27. Fitur pemilihan waktu seminar 48
28. Fitur mengunggah makalah seminar 49
29. Fitur persetujuan pendaftaran seminar 49
30. Fitur pemilihan moderator seminar 50
DAFTAR LAMPIRAN
1. Kuesioner peranan SIMAK dalam pelayanan terhadap mahasiswa 57
2. Kuesioner peranan SIMAK bagi Tendik 61
3. Daftar spesifikasi kebutuhan perangkat lunak SIMAK Multistrata DIDSI
IPB 67
4. Hasil uji validitas dan reliabilitas instrumen kuesioner responden Tendik 69 5. Hasil uji validitas dan reliabilitas instrumen kuesioner responden
mahasiswa 72
6. Hasil penilaian skala likert kuesioner Tendik 74 7. Hasil penilaian skala likert kuesioner Mahasiswa 76
8. Data hasil kuesioner responden mahasiswa 78
9. Data hasil kuesioner responden tendik 79
1
PENDAHULUAN
Latar Belakang
Penerapan teknologi informasi yang berkualitas di pendidikan tinggi saat ini merupakan hal yang sangat penting dalam mendukung pelayanan kepada
stakehoders terutama tuntutan penyelenggaraan proses yang efektif dan efisien.
Implementasi teknologi informasi dan komunikasi (TIK) di Perguruan Tinggi dapat memberikan manfaat nilai tambah bagi proses belajar mengajar (Tri Dharma Perguruan Tinggi) dan aktivitas pengelolaan institusi Perguruan Tinggi (Indrajit 2014).
Pemanfaatan TIK di pendidikan tinggi yaitu untuk melengkapi bukan untuk menggantikan, serta untuk memenuhi kebutuhan pendidikan tinggi yang selama ini belum dapat terpenuhi, seperti yang dirumuskan oleh UNESCO (1998) dalam (Indrajit 2014) yang mengatakan kehadiran TIK bagi dunia pendidikan sebagai “to meet the unmeet educational needs”. Penerapan sistem informasi merupakan salah satu pemanfaatan teknologi informasi di institusi pendidikan tinggi, seperti halnya penerapan sistem informasi manajemen akademik (SIMAK) di Sekolah Pascasarjana (SPs) Institut Pertanian Bogor (IPB).
SPs adalah penyelenggara administrasi akademik dan penjamin mutu pendidikan pascasarjana di IPB (SK MWA No.17/MWA-IPB/2003), baik penyelenggaraan program Magister Sains (S2), program Doktor (S3) dari sembilan Fakultas, serta empat penyelenggaraan multidisiplin (Katalog SPs 2013). Jumlah mahasiswa aktif kurang lebih 3800 setiap semesternya, dengan proses sistem pelayanan administrasi loket berdasarkan 27 jenis pelayanan administrasi akademik (Prosedur Operasional Baku (POB) SPs IPB 2006).
Dalam menjalankan proses bisnisnya SPs IPB ditopang oleh SIMAK, sistem yang dibangun pada tahun 2011 ini berbasis web. SIMAK yang beroperasi saat ini belum mengakomodir semua kebutuhan administrasi akademik dan secara sistem tidak terintegrasi, sehingga menyebabkan timbulnya permasalahan yang fatal di mana di antaranya terjadi kesalahan dan inkonsistensi data. Dalam memenuhi kebutuhan pelayanan yang belum terakomodasi pada SIMAK, pihak SPs diharuskan mengambil data langsung dari basis data dan mengolah secara manual. Keterbatasan di atas berkontribusi pada waktu penyelesaian proses pelayanan administrasi akademik yang terlalu lama, sehingga jarang digunakan bahkan dapat ditinggalkan penggunanya.
Menurut Reddy et al. (2009) sistem informasi mempunyai kemampuan menyimpan dan mengolah data menjadi informasi, serta menyebarkan informasi kepada pemangku kepentingan untuk mendukung proses bisnis suatu organisasi. Sistem informasi yang baik dapat memberikan dampak yang efektif dan efisien bagi operasional suatu organisasi, sistem informasi dapat mengoptimalkan tenaga (Tendik) dan biaya operasional, serta diharapkan mampu membantu organisasi menjalankan proses bisnisnya secara cepat dan akurat (Suskamiyadi et al. 2014).
2
sistem berorientasi objek antara lain enkapsulasi, polymorphism, coupling, dan
cohesion yang menambah efisiensi perancangan (Khalid et al. 2010).
Dalam mengembangkan sistem yang perlu diperhatikan dan tidak kalah pentingnya selain langkah analisis dan perancangan, yaitu pengujian perangkat lunak, maka dalam penelitian ini dilakukan pengukuran kualitas rancangan perangkat lunak berorientasi objek dengan melakukan pengukuran tingkat kompleksitas, coupling, dan cohesion dengan metode object oriented (OO) metrics. Seperti pengujian dua model metrik, yaitu Tight Class Cohesion dan Loose Class
Cohesion sebagai alat kontrol yang efektif dalam pengukuran rekayasa perangkat
lunak berorientasi objek (Hermadi et al. 2002). Dalam pengukuran sistem berorientasi objek class cohesion merupakan atribut penting, di mana pengujian
class cohesion dilakukan pada tahap perancangan merupakan cara yang tepat untuk
mendapatkan perangkat lunak yang mudah dipahami dan maintainable (Dallal dan Briand 2010).
Penelitian terkait penggunaan OO measurements pada sistem berorientasi objek dilakukan Suresh et al. (2012), dalam penelitiannya melakukan evaluasi peranan traditional dan OO measurements untuk mengukur kehandalan dan mengukur kompleksitas sistem Automated Teller Machine (ATM). Penelitian terkait lainnya dilakukan oleh Chowdhury (2009) yang melakukan pengujian
metrics (complexity, coupling, dan cohesion)sebagai indikator untuk memprediksi
kerentanan rancangan sistem berorientasi objek Mozilla Firefox release (1.0 (R1.0) sampai dengan 3.0.6 (R3.0.6)).
Pada penelitian ini akan dilakukan pengukuran terhadap rancangan kelas dengan menggunakan tradisional metrics seperti Lines of Codes, Number of
Atribute, Number of Method, dan OO metrics di antaranya Weight Methods per
Class, Coupling Between Objects, Tight Cohesion Metrics, Loose Cohesion Metrics
serta Lack Cohesion on Metrics. Sebelumnya dilakukan evaluasi system yang sedang berjalan dengan pendataan fitur-fitur yang terdapat pada SIMAK SPs sesuai POB SPs, menganalisa data transaksi pelayanan di loket administrasi akademik SPs. Pengumpulan kebutuhan pada penelitian ini dilakukan dengan teknik observasi, wawancara, dan menggunakan kuesioner untuk dapat mengetahui harapan dan kebutuhan para pemangku kepentingan.
Kuesioner menggunakan pertanyaan tertutup dengan teknik purposive
sampling dengan kriteria responden yang dipakai yaitu mahasiswa aktif IPB
program S2 dan S3, purposive sampling merupakan metode penetapan sampel responden berdasarkan pada kriteria tertentu (Siregar 2013). Instrumen pada kuesioner diuji validitas dan reliabilitas dengan Pearson Product Momen dan Alpha
Cronbach's, serta pengolahan dan analisis data dengan Skala Likert dengan interval
1-4. Pengujian instrumen kuesioner dilakukan untuk mengetahui apakah butir pertanyaan kuesioner valid dan handal dalam mengukur variabel yang diukur. Apabila dinyatakan tidak valid maka butir pertanyaan tesebut tidak akan dipergunakan pada tahap analisis selanjutnya (Siregar 2013). Pada penelitian ini disusun juga alat kontrol dan acuan pengerjaan pengembangan sistem dengan menggunakan scrum backlog product dengan skala prioritas kebutuhan, backlog
product digunakan sebagai landasan bagi pengembang dalam proses implementasi.
3 pelayanan administrasi baik dari segi efisiensi waktu dan efektifitas proses pekerjaan, dikarenakan pendaftaran online memberikan keuntungan bagi pihak pengelola serta bagi mahasiswa dengan dapat menghemat waktu, dapat melakukan pendaftaran kapan saja dan di mana saja (Farhan 2014).
Perumusan Masalah
SIMAK SPs IPB saat ini belum dapat membantu semua proses bisnis SPs IPB, dan masih terjadi kesalahan dalam pelayanan karena masih dikerjakan secara manual, seperti kesalahan jumlah penagihan biaya pendidikan yang disebabkan oleh kesalahan perhitungan dan inkonsistensi data yang disebabkan sistem tidak terintegrasi. Beban layanan administrasi akademik yang sangat besar mengakibatkan proses bisnis SPs IPB khususnya pelayanan administrasi akademik tidak optimal.
Tujuan Penelitian
Tujuan dari penelitian ini adalah melakukan evaluasi SIMAK SPs IPB, menguji kualitas rancangan Sistem Terintegrasi IPB menggunakan OO metrics, dan membuat prototipe pendaftaran online seminar hasil penelitian menggunakan basis data terintegrasi IPB.
Manfaat Penelitian
Manfaat penelitian yang diharapkan adalah membantu meningkatkan kualitas layanan akademik SPs IPB dengan membantu pelaksanaan proses bisnis, dan memberikan layanan administrasi akademik online dengan harapan lebih banyak mahasiswa yang terlayani dengan berbagai kemudahan.
Ruang Lingkup Penelitian
Penelitian ini akan dilaksanakan dengan ruang lingkup, sebagai berikut: 1. Melakukan integrasi data antara Divisi Administrasi Akademik dan Divisi
Administrasi Keuangan SPs IPB,
2. Mahasiswa aktif penyelenggaraan kelas reguler program S2 dan S3,
3. Analisis dan perancangan sistem informasi dengan model pendekatan Object
Oriented (OO), pengukuran kualitas menggunakan OO metrics, dan
pengujian menggunakan user acceptance testing, serta scrum backlog
product sebagai alat kontrol,
4. Pengembangan prototipe difokuskan pada pendaftaran online pelaksanaan seminar hasil penelitian,
4
2
TINJAUAN PUSTAKA
Sekolah Pascasarjana IPB
SPs IPB merupakan penyelenggara pendidikan pascasarjana pertama di Indonesia sejak tahun 1975, sampai dengan saat ini SPs IPB menjalankan perannya sebagai penyelenggara administrasi akademik dan penjamin mutu pendidikan pascasarjana di IPB yang merupakan sebagian dari tugas dan wewenang SPs IPB (SK MWA No.17/MWA-IPB/2003). Dalam menjalankan perannya SPs IPB dibantu 4 divisi pelaksana, namun keempat divisi tersebut tidak terintegrasi, sehingga menyebabkan timbulnya permasalahan yang fatal di mana di antaranya terjadi kesalahan dan inkonsistensi data. Dalam memenuhi kebutuhan pelayanan yang belum terakomodasi pada SIMAK, pihak SPs diharuskan mengambil data langsung dari basis data dan mengolah secara manual, seperti dapat dilihat pada Arsitektur sistem informasi SPs IPB dapat dilihat pada Gambar 1.
Beban pelayanan administrasi SPs IPB saat ini meliputi seluruh Fakultas dan Program Studi (PS) baik program Magister Sains (S2), program Doktor (S3), serta multidisiplin (Katalog SPs 2013). Jumlah mahasiswa aktif kurang lebih 3800 setiap semesternya dan proses pelayanan dilaksanakan dengan sistem pelayanan loket dengan 27 jenis pelayanan administrasi akademik (Prosedur Operasional Baku (POB) SPs IPB 2006).
Pemangku kepentingan SPs meliputi mahasiswa, dosen, staf administrasi di SPs IPB dan di departemen sebagai pengguna, Pimpinan SPs sebagai pemilik produk, dan pengelolaan sistem ditangani oleh DIDSI IPB. Menurut Satzinger (2007), pemangku kepentingan ialah semua individu yang mempunyai kepentingan pada suksesnya penerapan sistem. Pemangku kepentingan merupakan faktor kunci dalam sukses atau tidaknya penerapan TIK dalam pendidikan, pembelajaran, dan pengelolaan perguruan tinggi yang berkualitas, pentingnya peran pemangku kepentingan dalam sukses atau tidaknya penerapan sistem informasi pada Perguruan Tinggi dilakukan Perbawaningsih (2013).
Pengguna Internal Pemilik produk (Pimpinan SPs IPB)
Divisi SPs
Basis Data SIMAK SPs
SIMAK SPs
Pengguna eksternal
Mahasiswa
Departemen
5
Kuesioner dan Pengujian Instrumen Penelitian
Kuesioner adalah teknik pengumpulan data yang digunakan untuk penelitian dan dimungkinkan untuk dianalisis dan dipelajari sifat-sifat, serta karekteristik
stakeholders suatu organisasi (Siregar 2013). Beberapa jenis kuesioner digunakan
untuk pengumpulan data, salah satunya berupa close ended question, di mana responden tidak diberikan kesempatan berpendapat. Contoh close ended question
yaitu penggunaan kuesioner dengan penilaian skala Likert.
Skala Likert digunakan mengukur sikap, persepsi, dan pendapat seorang atau sekelompok orang tentang gejala sosial (Riduwan dan Akdon 2013). Skala Lkert
mempunyai bentuk jawaban yang terdiri dari sangat setuju, setuju, tidak setuju, dan sangat tidak setuju, dengan bentuk pernyataan yang positif dan negatif. Pemberian skor pada pernyataan yang positif adalah 4,3,2, dan 1; dan untuk pernyataan yang negatif adalah 1,2,3, dan 4 (Siregar 2013).
Pengujian instrumen penelitian merupakan hal penting dari bagian baik atau tidaknya, dan layak atau tidaknya kuesioner yang disusun. Pengujian validitas dan reliabilitas instrumen penelitian termasuk dalam kriteria pengujian instrumen (Siregar 2013):
1. Validitas Product Momen
Pengujian terhadap instrumen kuesioner pada tahap ini untuk mengetahui apakah butir pertanyaan valid atau tidak. Instrumen dapat dikatakan valid apabila hasil pengujian menggunakan uji validitas Product Momen memiliki nilai r hitung > nilai r tabel dengan taraf signifikan (0,05 atau 0,01). Pengujian validitas dilakukan untuk mengetahui apakah butir-butir pertanyaan dapat dipakai untuk mengukur konsep yang dipakai dalam penelitian (Widoyoko 2012).
2. Reliabilitas Alpha Cronbach's
Pertanyaan yang telah dinyatakan valid akan kembali dilakukan pengujian dengan uji reliabilitas Alpha Cronbach's. instrumen dikatakan reliabel jika memiliki koefisien alpha lebih besar dari r tabel (r hasil > r tabel), nilai signifikansi yang dipergunakan didapat dari r tabel (0,05 atau 0,01) dengan N-2. Semakin besar nilai Alpha Cronbach’s, maka semakin tinggi tingkat reliabilitas kuesioner penelitian yang digunakan atau konsisten dari beberapa responden (Siregar 2013 dan Widoyoko 2012).
Pengolahan dan analisis data hasil kuesioner akan ditentukan presentase kelompok responden untuk setiap instrumen penelitian, dengan menghitung total skor setiap instrumen dibandingkan dengan jumlah skor ideal (skor tertinggi) (Riduwan dan Akdon 2013).
Analisis dan Perancangan Berorientasi Objek
Analisis dan perancangan sistem dengan pendekatan berorientasi objek dapat menciptakan sistem baru yang responsif dengan menawarkan teknik pendekatan yang mendukung metode yang logik, cepat, serta teliti. Menurut Hermadi et al.
6
lebih mudah diperbaiki, dan lebih dapat digunakan kembali (reused) terutama pada pengembangan industri perangkat lunak. Terdapat dua dokumentasi teknis yang perlu dihasilkan, pada tahap analisis dokumen teknis berupa Spesifikasi Kebutuhan Perangkat Lunak (SKPL), yang merupakan dokumen hasil analisis yang berisi spesifikasi kebutuhan pengguna pada perangkat lunak yang akan dibangun.
Spesifikasi Kebutuhan Perangkat Lunak
Kebutuhan perangkat lunak terbagi atas kebutuhan fungsional, yaitu kebutuhan berdasarkan aktifitas sistem, prosedur dan proses bisnis yang didokumentasikan dalam bentuk model-model. Model tersebut menggambarkan kebutuhan berdasarkan aktifitas sistem, prosedur dan proses bisnis, serta dapat mempresentasikan aspek penting dari dunia nyata dapat berbentuk diagram dan
charts (Satzinger 2007). Hasil analisa kebutuhan fungsional sistem akan
divisualisasikan dengan model-model, yaitu use case diagrams (diagram kasus),
class diagrams (diagram kelas), diagram yang menggambarkan sejumlah informasi
yang dimiliki objek (atribut atau propertis), use case description yaitu langkah-langkah rinci dari setiap use case untuk menyelesaikan suatu proses bisnis.
Adapun manfaat mendeskripsikan langkah tersebut adalah untuk membuat sistem yang kuat, komprehensif dan serta benar-benar memenuhi kebutuhan pengguna (Satzinger 2007). Visualisasi kebutuhan fungsional sistem lainnya adalah activity diagrams (diagram aktifitas) yang merupakan teknik dokumentasi arus kerja sistem yang efektif dari setiap skenario use case (Satzinger 2007), dan
Sequence diagrams (diagram urutan) merupakan visualisasi kebutuhan fungsional
yang menggambarkan bagaimana aktor berinteraksi dengan memberikan input dan menerima output dari sistem (Satzinger 2007). Dokumentasi hasil analisa tersebut diperuntukan bagi kebutuhan konsumen yang selanjutnya akan dideskripsikan dalam perancangan perangkat lunak.
Deskripsi Perancangan Perangkat Lunak
Pada tahap perancangan sistem berorientasi objek dideskripsikan perancangan dari perangkat lunak yang akan dikembangkan, diperuntukan bagi profesional pengembang perangkat lunak yang bertujuan untuk memberikan landasan yang diperlukan dalam proses pengkodean, serta menggambarkan apa yang dilakukan oleh sistem (Satzinger 2007), lain halnya dengan SKPL yang dibuat untuk kebutuhan kostumer dan pengguna. Tahap perancangan merupakan jembatan antara tahap analisis dan implementasi, di mana pengembang membuat program berdasarkan model perancangan dan mengujinya (Satzinger 2007)
Model perancangan yang digunakan adalah design class diagrams,
merupakan sebuah set navigasi (antara kelas, atribut, propertis dan metode),
Interaction diagrams (diagram interaksi). Model perancangan design class
diagrams bertujuan untuk memberikan landasan yang diperlukan dalam proses
7
Deskripsi Uji Perangkat Lunak
Deskripsi Uji Perangkat Lunak (DUPL) merupakan dokumen yang mendeskripsikan semua tahapan pengujian yang dilakukan terhadap perangkat lunak yang akan kembangkan. Penyusunan dokumen uji ini berdasarkan dokumen DPPL yang telah dirancang, dan dokumen ini menjadi acuan pada pelaksanaan user
acceptance testing.
Pengukuran Rancangan
Menurut Fenton (1997) measurement merupakan satu kesatuan dalam rekayasa perangkat lunak, berdasarkan definisi rekayasa perangkat lunak yang dikeluarkan IEEE, yang menyebutkan penerapan rekayasa perangkat lunak adalah suatu aplikasi yang sistematik, disiplin, pengembangan dengan pendekatan kuantitatif, pengerjaan dan pemeliharaan perangkat lunak.
Kegagalan rekayasa perangkat lunak dapat berupa melewati tenggat waktu, dana yang membengkak, produk tidak sesuai fungsi (cacat), dan produk yang gagal. Seperti laporan pengembangan perangkat lunak yang didanai pemerintah Amerika Serikat: Berhasil (1.77%), Operasional melalui perbaikan (2.95%), Pengerjaan ulang atau ditinggalkan (19.2%), pengembangan yang telah didanai namun tidak pernah rampung (28.8%), dan tidak dapat digunakan (47.27%). Menurut Fenton (1997), salah satu penyebab kegagalan di atas dikarenakan kegagalan dalam mengukur dan menspesifikasi kualitas dari atribut produk perangkat lunak, seperti
reliability, dan maintainabilty.
Maintainable merupakan salah satu dari enam faktor pengukuran kualitas
perangkat lunak yang ditetapkan ISO 9126 tahun 1992 tentang penetapan standar evaluasi produk perangkat lunak: Quality Characteristics and Guidelines for their Use yang dirancang berdasarkan McCall model tahun 1977 (Fenton 1997). Rancangan perangkat lunak dikatakan maintainable apabila dapat mudah dimengerti, ditingkatkan, dan benar (Fenton 1997), maka pada penelitian ini akan dilakukan pengukuran maintainability rancangan kelas. Sebelum melakukan pengukuran metrik, langkah yang perlu ditempuh adalah menentukan apa yang perlu diukur, langkah yang akan dilakukan adalah dengan menggunakan pendekatan Goal-Question-Metric (GQM) yang merupakan paradigma yang efektif dalam penentuan dan implementasi penentuan metrik yang akan dipergunakan (Fenton 1997).
Goal Question Metrics
Pendekatan GQM adalah berdasarkan asumsi bahwa untuk menentukan tujuan suatu organisasi, pertama harus menetapkan tujuan operasional yang diterjemahkan oleh kerangka pemikiran dan ditunjang oleh data-data (Basili et al.
1994). Metodologi GQM sebagai pengukuran kinerja perangkat lunak telah banyak digunakan untuk memantau dan mengevaluasi kinerja perangkat lunak produk, proses dan sumber daya (Mahmood et al. 2008). Pada penelitian ini GQM digunakan untuk penentuan measurement perangkat lunak, yaitu untuk mengetahui tingkat maintainability rancangan basis data terintegrasi IPB.
8
1. Level konseptual (Goal), di mana tujuan didefinisikan untuk sebuah objek dengan berbagai alasan, di antaranya: sehubungan dengan kualitas model, berbagai sudut pandang, relatif terhadap lingkungan tertentu. Objek pengukuran berupa produk, proses, dan sumberdaya.
2. Level operasional (Question), merupakan satu set pertanyaan yang digunakan untuk mengkarakterisasi cara penilaian / pencapaian tujuan tertentu. Pertanyaan mencoba untuk mengkarakterisasi obyek pengukuran (produk, proses, sumber daya) sehubungan dengan masalah kualitas dan menentukan kualitas dari sudut pandang yang dipilih.
3. Level kuantitatif (Metric), merupakan satu set data yang terkait dengan setiap pertanyaan dengan jawaban secara kuantitatif. Data terkait dapat berupa obyektif maupun subyektif.
Tradisional Metrics
Pengukuran terhadap perangkat lunak dapat diklasifikasikan menjadi tradisional dan OO metrics, di mana tradisional dan OO metrics berperan penting dan menyediakan informasi yang berharga dalam pengembangan perangkat lunak, seperti memberikan informasi dasar bagi penyusunan pengujian perangkat lunak yang berkualitas dengan memprediksi fault dan mengukur kompleksitas dari sistem yang sedang dikembangkan (Suresh et al. 2012).
Pengukuran secara tradisional dilakukan dengan menghitung atribut internal dari entitas, yaitu lines of code (LOC). LOC adalah jumlah baris kode yang dihasilkan pada setiap modul, perhitungan LOC merupakan cara tradisional yang biasa digunakan dalam mengukur besaran suatu produk atau modul (Fenton 1997). Hal yang perlu diperhatikan dalam perhitungan LOC, yaitu jumlah baris kosong, dan baris komentar yang dalam beberapa perhitungan tidak dipakai karena menulis komentar bisa dikatakan lebih mudah dibanding menuliskan sesuatu yang sulit seperti menuliskan algoritma yang kompleks (Fenton 1997), demikan juga penulisan pendeklarasian data, serta penulisan baris instruksi yg terpisah.
Fenton (1997) juga menyebutkan pengukuran dengan menghitung LOC juga dipengaruhi oleh tujuan kegunaannya, seperti menghitung jumlah baris instruksi yang dijalankan, mengetahui modul maintainability dan modul reability. LOC termasuk dalam McCabe metrics suite (Kaur et al. 2006), jumlah LOC yang tinggi mengindikasikan tingginya tingkat kompleksitas suatu aplikasi, dan mengidentifikasikan banyaknya test cases yang diperlukan (Suresh et al. 2012). Pengukuran tradisional lainnya yaitu dengan menghitung jumlah atribut, seperti pengukuran number of atribut (NOA) pada setiap kelas, dan number of method
(NOM) yang digunakan. Namun LOC hanya dipergunakan untuk mengestimasi besarnya effort, dan hanya dapat dibandingkan dengan perangkat lunak yang ditulis menggunakan bahasa pemrograman yang sama (Suresh et al. 2012).
Object Oriented Metrics
Object oriented metrics merupakan cara tepat untuk mengukur kualitas
9 Fenton (1997) terdapat tiga dasar entitas kelas yang dapat diukur pada rekayasa perangkat lunak, yaitu: proses, produk, dan sumberdaya (entitas yang dibutuhkan pada aktifitas proses).
Kompleksitas
Untuk mengetahui tingkat kompleksitas hasil perancangan rangkaian selain tradisional metrik digunakan juga pengukuran metrik berorientasi objek atau OO
metrics. Pengukuran yang biasa digunakan untuk metrik berorientasi objek adalah
rangkaian metrik Chidamber and Kemerer (CK) (Suresh et al. 2012), yaitu:
Weighted Methods per Class (WMC), dengan persamaan:
��� = ∑ �� �
�=1
…………...……… (1)
Di mana untuk kelas C, dengan M1, M2, …, Mn adalah bobot, dan C1,C2,...,Cn adalah kompleksitas.
Nilai WMC yang tinggi akan menghalangi penggunaan kembali kelas (reuse), dan untuk menghindari tingginya nilai WMC diperlukan untuk mengurangi jumlah metode pada kelas tersebut atau kompleksitasnya (Suresh et al. 2012). Sedangkan untuk mengukur seberapa kompleks tingkat pengujian suatu rancangan, dapat dilakukan dengan mengukur coupling rancangannya.
Coupling
Metrics yang digunakan untuk mengukur tingkat keterhubungan antar objek,
Coupling Between Object (CBO) merupakan pengukuran yang menghitung berapa
kelas yang berhubungan dengan kelas lain yang diukur atau menentukan tingkat ketergantungan antar modul. Sebuah prosedur dikatakan mempunyai rancangan yang baik apabila memiliki coupling yang rendah (Eder et al. 1992).
CBO sangat baik untuk mengukur kompleksitas tingkat pengujian rancangan objek, semakin tinggi nilai CBO maka akan semakin tinggi tingkat ketelitian pengujian (Suresh et al. 2012).
Cohesion
Hal penting lainnya pada pengukuran perangkat lunak berorientasi objek yaitu mengukur tingkat keterikatan antar elemen pada suatu modul (cohesion). Eder
et al. (1992) menyebutkan tujuan umum dari perancangan metrik berorientasi objek
adalah mengukur coupling dan cohesion dari OO sistem. Cohesion adalah tingkat keterikatan antar elemen pada suatu modul, semakin tinggi tingkat kohesi, maka dapat diartikan sebuah prosedur telah mempunyai rancangan yang baik (Eder et al.
1992).
Sedangkan menurut Hermadi et al. (2004) cohesion merupakan hal penting untuk menghasilkan perangkat lunak yang handal dan maintainable. Bieman and Kang’s Class Cohesion Metrics mendefinisikan class cohesion merupakan sebuah atribut kelas menggambarkan keterikatan antar komponen. Komponen itu adalah
instance variables metode, dan inherited methods (Hermadi et al. 2002).
Dua Class Cohesion MetricsBieman and Kang’s mendefinisikan konektifitas
10
yang sama disebut number of directly connected (NDC). Apabila dua metode mengakses secara terhubung langsung atau tidak secara langsung dinamakan
number of indirectly connected (NIC), serta number of possible connected (NPC)
adalah jumlah maksimal koneksi yang memungkinkan dalam kelas dengan persamaan (2):
NPC = (NOM x (NOM – 1)) / 2 ………. (2) Bieman dan Kang mengusulkan dua langkah Class Cohesion Metrics untuk mengevaluasi hubungan antara kelas kohesi dan private reuse dalam sistem (Hermadi et al. 2002). Untuk mengukur tingkat kohesi, digunakan dua persamaan
Class Cohesion MetricsBieman and Kang’s, yaitu persamaan (3) dan (4):
a. Tight Class Cohesion (TCC), didefinisikan sebagai presentase dari kelas yang
terkoneksi secara langsung. Diukur dengan persamaan ini:
TCC = NDC / NP ………. (3)
b. Loose Class Cohesion (LCC), didefinisikan sebagai jumlah relatif dari kelas
yang tidak terkoneksi secara langsung. Diukur dengan persamaan:
LCC = (NDC+NIC) / (NP) …………..……… (4)
Nilai LCC selalu lebih besar atau sama dengan nilai TCC. Class Cohesion
Metric dapat mengindikasikan besar derajat konektifitas antara visible methods
pada kelas, nilai TCC dan LCC yang lebih besar dari 0,5 memiliki tingkat kohesif yang baik demikian sebaliknya apabila nilai lebih kecil (Beiman dan Kang 1995).
Cara lain untuk mengukur tingkat keterikatan pada kelas yaitu dengan Lack
of Cohesion on Method (LCOM), yang bertujuan untuk mendeteksi tinggi
rendahnya tingkat keterikatan pada kelas, nilai LCOM yang tinggi berarti rendahnya tingkat keterikatan (Kaur et al. 2013). Menurut Hitz (1995) LCOM merupakan jumlah pasangan metode yang beroperasi pada set yg terpisah yang mengakses instace variable yang sama, dikurangi dengan jumlah pasangan metode yang bekerjasama pada setidaknya satu instance variable.
Hitz dan Montazeri mendefinisikan LCOM4 yaitu jumlah komponen yang terkoneksi pada suatu kelas, di mana komponen yang terkoneksi itu adalah satu rangkaian metode yang terkait (variabel pada kelas). Nilai LCOM4 menunjukkan apakah kelas kohesif atau tidak, yaitu:
LCOM4=1 mengindikasi kelas mempunyai tingkat kohesi yang baik.
LCOM4>=2 mengindikasikan terdapat masalah kohesi pada kelas, sebaiknya kelas dibagi menjadi kelas yang lebih kecil (Shaik et al. 2010). Menurut Suresh et al.
(2012), kelas dibagi menjadi kelas yang lebih kecil untuk mengurangi kompleksitas perancangannya.
LCOM4=0 terjadi dikarenakan tidak ada metode pada kelas, di mana metode hanya mengakses variabelnya sendiri, hal ini juga diindikasikan kelas yang tidak kohesif (Shaik et al. 2010).
Pada penelitian ini digunakan pengukuran secara tradisional dan OO metrics
11 positif dengan kerentanan kelas berkorelasi positif dengan kerentanan kelas pada tahap perancangan (Chowdhury 2009), dan metrik tersebut merupakan indikator terbaik mengukur reliabilitas sistem yang dapat memberikan informasi tak ternilai bagi pengembang, coders, dan penguji sistem (Suresh et al. 2012). Metrik CBO digunakan untuk memprediksi bugs pada sistem (Gupta et al. 2015) dan menilai
reuse, maintainability, testability suatu sistem (Hitz dan Montazeri 1996), dan
untuk mengukur kompleksitas sistem digunakan NOA, NOM, serta TCC dan LCC untuk mengukur tingkat kohesif rancangan.
User Acceptance Testing
Perangkat lunak yang dikembangkan akan digunakan banyak penguna yang mempunyai demografi yang beragam, dan tidak mungkin pengembang perangkat lunak dapat memastikan bagaimana reaksi penguna terhadap perangkat lunak yang telah dikembangkan (Pressman 2010). Untuk mengetahui apakah perangkat lunak yang telah dikembangkan dapat diterima dengan baik oleh penguna digunakan beta test atau User Acceptance Testing (UAT), UAT dilakukan pada lingkungan langsung pengguna yang tidak terkontrol untuk menemukan defect dan error
(Pressman 2010). Terdapat langkah-langkah yang perlu dilakukan dalam melaksanakan UAT, yaitu: pemilihan atribut pengujian dilakukan untuk memenuhi tujuan obyektif organisasi, dan hasil pengujian akan ditindaklanjuti oleh pihak pengembang.
Scrum Backlog Product
Dokumen lainnya yang diperlukan pada pengembangan sistem yaitu Scrum
Backlog Product atau Produk Backlog, yang merupakan suatu mekanisme kontrol
yang dapat mengkoordinasikan jadwal, pemilihan jenis pekerjaan yang perlu dilakukan, estimasi penyelesaian pekerjaan, dan prioritas pekerjaan kebutuhan pengguna(Satzinger 2007). Untuk mekanisme kontrol, pembagian tugas, estimasi waktu penyelesaian dan penentuan prioritas pekerjaan disusun scrum backlog
product sebagai pedoman pelaksanaan pengembang perangkat lunak pada tahap
implementasi (Satzinger 2007). Scrum backlog product akan disesuaikan dengan kebutuhan pengembangan sistem pada penelitian ini dan ketersediaan sumberdaya di SPs IPB.
Backlog product terdiri atas backlog item yang merupakan tugas yang harus
12
3
METODE
Penelitian ini melakukan evaluasi sistem yang berjalan, analisis dan perancangan sistem informasi pelayanan administrasi akademik SPs IPB dengan menggunakan skema basis data terintegrasi, serta pengujian rancangan skema basis data terintegrasi, pembuatan prototipe pelayanan administrasi akademik sesuai kebutuhan guna mendukung proses bisnis SPs, adapun langkah-langkah penelitian sebagai berikut, seperti pada Gambar 2.
Mulai
Evaluasi Sistem yang berjalan (Fitur, ketersediaan dok teknis, dan
manual)
Analisis Perancangan
Sesuai
kebutuhan User Acceptance Testing
ya
Selesai Pengumpulan kebutuhan
(POB, stakeholders) OO measurement
Hasil pengukuran ideal (best practices)? ya
SKPL DPPL, DUPL, produk
backlog Hasil pengukuran
tidak tidak
DUPL
Pembuatan prototipe
Gambar 2 Metodologi penelitian
Evaluasi sistem yang berjalan
Pada tahap ini akan dilakukan pendataan fitur-fitur yang terdapat pada SIMAK SPs sesuai POB SPs, menganalisa data transaksi pelayanan di loket administrasi akademik SPs, dan mempelajari dokumen teknis SIMAK SPs.
Pengumpulan Kebutuhan
Pada tahap pengumpulan kebutuhan ini dilakukan observasi ke divisi pelaksana, wawancara dengan tenaga kependidikan (SPs IPB dan pengelola Program Studi). Pada tahap ini dilakukan identifikasi kebutuhan stakeholders
13 utama SIMAK SPs, langkah selanjutnya yaitu mengidentifikasi prioritas pengembangan sistem.
Penyusunan kuesioner
Penyusunan kuesioner digunakan close ended question, dengan menggunakan penilaian skala likert dengan memakai interval 1-4. Penyusunan kuesioner terdiri dari kuesioner bagi responden Tendik dan kuesioner yang ditujukkan bagi mahasiswa aktif pascasarjana. Penyusunan kuesioner didasarkan pada kuesioner Evaluasi Pengguna Sistem Aplikasi (EPSA) IPB-Program I-MHERE B.2.C Direktorat Komunikasi dan Sistem Informasi (DKSI) IPB tahun 2012 (http://cris-evaluation.event.ipb.ac.id/jadwal) dengan dilakukan perubahan sesuai kebutuhan penelitian.
Beberapa pertanyaan pada kuesioner EPSA IPB dijadikan satu kategori pertanyaan pada penelitian ini karena dinilai masih relevan dalam satu kategori, seperti pertanyaan pada kategori dukungan (support) dan kategori bantuan manajemen. Kategori kepuasan user dalam menggunakan sistem informasi dan kategori peningkatan kinerja user digabung menjadi satu kategori. Kategori reward
and punishment tidak dipakai pada penelitian ini karena dianggap tidak relevan.
Penyebaran kuesioner
Penyebaran kuesioner kepada responden dilakukan dengan dua tahap, pada tahap awal penyebaran kuesioner diperlukan untuk mengetahui valid atau tidaknya setiap instrumen yang dipakai dalam kuesioner tersebut. Penyebaran kuesioner tahap ini akan diberikan kepada tendik dan mahasiswa masing-masing tigapuluh responden. Kemudian hasil dari penyebaran kuesioner pertama akan dilakukan pengujian instrumen penelitian.
Setelah didapatkan hasil pengujian instrumen tahap selanjutnya adalah menyebarkan kuesioner tahap 2, pada tahap ini dilakukan penyebaran kuesioner kepada responden tendik di lingkungan SPs maupun di lingkungan departemen, serta penyebaran kuesioner bagi mahasiswa dilakukan ke berbagai program studi. Penyebaran dilakukan dengan dua cara yaitu secara manual, dan dengan menggunakan kuesioner secara online dengan fasilitas Google Form secara bersamaan dengan teknik purposive sampling. Penyebaran kuesioner secara online
dilakukan untuk memaksimalkan penyebaran kuesioner responden mahasiswa, baik yang berada dalam lingkungan kampus maupun diluar area kampus yang sedang melakukan penelitian.
Pengujian Instrumen Penelitian
14
Pengolahan dan Analisis Data Kuesioner
Pada tahap ini dilakukan pengujian data hasil kuesioner tahap kedua dengan menggunakan penilaian skala Likert dengan interval 1-4, penentuan interval ditentukan dengan ketentuan sebagai berikut: I =100, maka I / jumlah maksimal
Likert = 100 / 4 = 25. Interval kelas seperti pada Tabel 1.
Tabel 1 Pembagian kelas interval dan kriteria (Riduwan dan Akdon 2013)
Kelas Interval Kriteria
0% - 25% Sangat Tidak Setuju (STS)
26% - 50% Tidak Setuju (TS)
51% - 75% Setuju (S)
76% - 100% Sangat Setuju (SS)
Cara mendapatkan kelompok nilai interval masing-masing butir pertanyaan dilakukan perhitungan untuk mendapatkan skor total, skor total masing-masing instrumen penelitian diperoleh dari total dari perkalian jumlah responden yang memilih item dengan bobot pilihan jawaban. Total skor masing-masing instrumen dibagi dengan nilai Y (jumlah responden x skor maksimum) dikalikan 100% untuk memperoleh nilai skala Likert. Hasil perhitungan kemudian dimasukkan kedalam kelas interval untuk mendapatkan kriteria STS, TS, S, atau SS seperti pada Tabel 1, kriteria tersebut memberikan gambaran tanggapan dari keseluruhan responden terhadap masing-masing butir pertanyaan, serta pengelompokan berdasarkan presentase jawaban pilihan responden akan ditampilkan sebagian dari instrumen penelitian.
Analisis
Setelah informasi kebutuhan pengguna didapatkan, akan dilakukan analisa terhadap skema basis data terintegrasi IPB, analisa dilakukan untuk menentukan kelas mana yang sesuai proses bisnis SPs IPB. Spesifikasi kebutuhan sistem yang diperlukan bagi perancangan sistem terkait administrasi dan pelayanan akademik yang akan dikembangkan kemudian divisualisasikan melalui model. Hasil analisis kebutuhan fungsional sistem akan divisualisasikan dengan model-model, yaitu use
case diagrams (diagram kasus), use case description yaitu langkah-langkah rinci
setiap use case untuk menyelesaikan suatu proses, data model class diagrams yaitu diagram yang menggambarkan sejumlah informasi yang dimiliki objek (atribut atau propertis), activity diagrams (diagram aktifitas), dan sequence diagrams (diagram urutan).
Perancangan
Pada tahap perancangan sistem berorientasi objek model spesifikasi kebutuhan sistem akan dikembangkan sesuai kebutuhan sistem, dengan mendeskripsikan model dengan model perancangan design class diagrams,
merupakan sebuah set navigasi (antara kelas, atribut dan metode), Interaction
diagrams (diagram interaksi). Pada tahap ini juga akan disiapkan pengujian
15 yang dilakukan terhadap perangkat lunak yang akan kembangkan. Penyusunan pengujian ini berdasarkan dokumen perancangan teknis yang telah dirancang, dan akan menjadi acuan pada pelaksanaan user acceptance testing.
Matrik deskripsi uji perangkat lunak terdiri atas kelas uji, butir uji, dan identifikasi penomoran SKPL dan penentuan penomoran DUPL, di mana kelas uji merupakan daftar fungsi-fungsi yang akan diuji, butir uji adalah poin-poin dari kelas uji. Identifikasi SKPL pada DUPL berdasarkan pada SKPL SIMAK Multistrata DIDSI IPB tersedia pada Lampiran 3, kemudian pemberian penomoran identifikasi DUPL berdasarkan urutan butir uji, dan pengujian yang dilakukan adalah pengujian sistem dengan teknik black box.
Langkah selanjutnya adalah menyusun mekanisme kontrol, pembagian tugas, estimasi waktu penyelesaian dan penentuan prioritas pekerjaan, pada penelitian ini akan digunakan scrum backlogproduct. Pada tahap ini akan diidentifikasi backlog item pengembangan sistem, kemudian menentukan jenis pekerjaan (task) untuk mendukung item pengembangan di atas, setelah task ditentukan masing-masing diberi penanggungjawabnya atau siapa yang mengerjakannya.
Selain pembagian tugas, pada scrum backlog product akan ditentukan estimasi waktu penyelesaian dan kontrol waktu penyelesaian (day of sprint), serta prioritas pengerjaan dengan menyusun task berdasarkan tingkat prioritas. Penyusunan backlog product pada pengembangan prototipe pendaftaran online
seminar akan disesuaikan dengan kebutuhan penelitian ini dan ketersediaan sumberdaya di SPs IPB.
Pengukuran Rancangan Goal Question metrics
Salah satu konsep dasar pengembangan sistem berorientasi objek yang berkualitas tinggi, yaitu produk lebih dapat diandalkan (reliable), lebih mudah diperbaiki (maintainable), dan lebih dapat digunakan kembali (reused).
Pada penelitian ini GQM yang digunakan didasarkan pada pengukuran tingkat maintainability rancangan basis data terintegrasi IPB, dengan tujuan mengukur tingkat testability, understandability, modifiablity, dan expandibility
rancangan kelas. Setelah tujuan ditentukan, langkah selanjutnya adalah menyusun pertanyaan-pertanyaan terkait tujuan yang akan dicapai, serta metrics yang diperlukan untuk mendukung pertanyaan tesebut. Langkah selanjutnya adalah melakukan pengukuran terhadap metrics yang telah ditentukan.
Object Oriented Metrics
Pada tahap ini dilakukan pengukuran OO metrics dan tradisional metrics
berdasarkan yang telah ditentukan pada GQM, akan ditentukan besarnya pengukuran metrics per kelas yang telah ditentukan sesuai kebutuhan pengembangan sistem pada tahap analisis. Hasil pengukuran dicari nilai total (), simpangan baku (SB), nilai minimal dan maksimal, dan nilai rata-rata dari seluruh kelas yang diukur dipakai untuk menentukan tinggi rendahnya kelas yang akan diukur.
Pada penelitian ini akan dinilai tingkat kompleksitas, coupling dan cohesion
16
memiliki tingkat kompleksitas dan coupling yang rendah dan memiliki nilai
cohesion yang tinggi. Hasil pengukuran dari setiap kelas dinyatakan mempunyai
nilai ideal berdasarkan best practices, yang disusun berdasarkan nilai kriteria rancangan apakah sangat baik, apabila rancangan memenuhi semua kriteria yang sesuai, rancangan baik apabila memiliki dua kriteria yang sesuai, rancangan kurang baik apabila hanya memiliki satu, serta apabila rancangan tidak ada yang sesuai, maka rancangan kelas dinyatakan tidak baik. Apabila terdapat rancangan yang dinilai tidak baik, maka akan dilakukan perancangan ulang. Hasil perbaikan rancangan akan menjadi rekomendasi atau usulan bagi pengelola guna menghasilkan sistem yang sesuai dengan kebutuhan.
Pengembangan Prototipe
Pengembangan prototipe dibangun dengan menggunakan rancangan basis data terintegrasi yang telah dikembangkan DIDSI IPB, dengan menggunakan kelas terkait proses bisnis pascasarjana dan beberapa perubahan, penambahan yang dibutuhkan bagi pengembangan sistem pada penelitian ini. Dalam pengembangan prototipe akan digunakan MySql sebagai basis data, server apache, bahasa pemrograman PHP, dan diintegrasikan menggunakan Yii framework.
User Acceptance Testing
17
4
HASIL DAN PEMBAHASAN
Evaluasi sistem yang berjalan
Dalam menjalankan proses bisnisnya SPs IPB ditopang oleh SIMAK, sistem yang dibangun pada tahun 2011 ini berbasis web dengan menggunakan bahasa pemrograman PHP Hypertext Preprocessor (PHP) dan Framework Code Igniter
serta basis data Structured Query Language (SQL) server.
Hasil observasi menunjukkan jenis pelayanan pada SIMAK yang dapat diakses () dan yang belum dapat diakses (X) oleh Tendik maupun mahasiswa. Jenis pelayanan yang telah diakomodir bagi mahasiswa baru satu pelayanan yaitu POB-SPs 04, serta hasil observasi menunjukkan terdapat kendala pada output bagi jenis pelayanan yang dapat diakses oleh Tendik, seperti pada Tabel 2.
Tabel 2 Observasi jenis pelayanan administrasi akademik di SIMAK SPs berdasarkan POB SPs IPB
Jenis Pelayanan Kode
POB Administrasi FRS &
18
Jenis Pelayanan Kode
POB Surat Ijin Prapenelitian
& Penelitian
POB-SPs 09
7 X X
Surat Keterangan Lulus & Ijazah
POB-Permohonan Aktif dari Cuti Akademik
Observasi yang kedua yaitu menganalisa data jumlah transaksi pelayanan loket Divisi Administrasi Akademik SPs selama periode Januari 2014 – Maret 2015 dengan menggunakan Analisis Deskriptif Frekuensi SPSS pada Tabel 3. Hasil analisis tidak menghasilkan nilai N yang hilang (N Missing), analisis juga menunjukkan POB SPs 05 dan POB SPs 11 memiliki data transaksi pelayanan yang tinggi dengan rata-rata 171.5 dan 102.8. POB SPs 11 memiliki distribusi data yang lebih kecil dibanding POB SPs 05 dengan standar deviasi 33.4, hal ini menunjukkan nilai rata-rata POB SPs 11 lebih akurat dibanding POB SPs 05 (Field 2009), dan tingkat variasinya lebih kecil dibanding POB SPs 05 (Riduwan dan Akdon 2013).
Transaksi yang tinggi menunjukkan kontribusi pada beban pelayanan loket administrasi akademik, namun pelayanan POB SPs 05 lebih banyak dilakukan secara desentralisasi pada tingkat Departemen dan dapat dilakukan secara kolektif di pelayanan SPs. Pada Gambar 3 menunjukkan transaksi pelayanan POB SPs 11 selama 15 bulan.
Tabel 3 Statistik frekuensi pelayanan SIMAK SPs berdasarkan POB SPs IPB
19
Gambar 3 Grafik frekuensi pelayanan POB SPs 11
Pada grafik menunjukkan intensitas pelayanan meningkat cukup tinggi pada beberapa bulan tertentu, jumlah transaksi pelayanan tertinggi terjadi pada periode akhir semester dan pula akhir tahun ajaran, yang berarti batas studi mahasiswa tertentu. Hal tersebut berimbas pada tingginya tingkat pelayanan administrasi akademik, maka pada penelitian ini POB SPs 11 direkomedasikan beralih pelayanan menjadi pelayanan online. Untuk lebih memperkuat lagi apa yang telah diperlihatkan pada observasi di atas, pada penelitian ini digunakan kuesioner guna menangkap kebutuhan pengguna, terutama dari Tendik dan mahasiswa.
Pengumpulan Kebutuhan Penyusunan Kuesioner
Kuesioner penelitian disusun didasarkan pada kuesioner Evaluasi Pengguna Sistem Aplikasi IPB - Program I-MHERE B.2.C oleh Direktorat Komunikasi dan Sistem Informasi (DKSI) IPB tahun 2012 (
http://cris-evaluation.event.ipb.ac.id/jadwal) dengan perubahan sesuai kebutuhan penelitian.
Hasil penyusunan kuesioner disediakan pada Lampiran 1 untuk responden Mahasiswa dan Lampiran 2 untuk responden Tendik.
Pertanyaan kuesioner dibagi menjadi Bagian A yaitu identifikasi responden, dan Bagian B yaitu pertanyaan terkait penggunaan SIMAK SPs yang terbagi menjadi beberapa kategori pertanyaan, yaitu:
Pertanyaan kuesioner bagi mahasiswa terdiri dari 3 kategori, yaitu:
1. Interaksi responden dengan SIMAK yang berjalan saat ini (13 pertanyaan), 2. Kelengkapan dokumen teknis dan dukungan teknis SIMAK yang berjalan
saat ini (7 pertanyaan),
3. Fitur dan pelayanan online pada SIMAK (12 pertanyaan).
0 20 40 60 80 100 120 140 160 180 200
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
POB-SPs 11
POB-SPs 11
rataan = 102.82
bulan Jumlah
20
Sedangkan untuk Tendik terdiri dari 5 kategori pertanyaan, yaitu:
1. Interaksi responden dengan SIMAK yang berjalan saat ini (8 pertanyaan), 2. Dukungan dan kelengkapan dokumen teknis SIMAK (9 pertanyaan), 3. Fitur, data, informasi dan pelayanan online pada SIMAK (19 pertanyaan),
4. Reability, usability, dan maintainability SIMAK (12 pertanyaan),
5. Kepuasan pengguna dan peran SIMAK dalam peningkatan kinerja pengguna (7 pertanyaan).
Penyebaran Kuesioner dan Pengujian Instrumen Penelitian
Pada penelitian ini penyebaran kuesioner dilakukan dalam dua tahap dan dilakukan pengujian instrumen penelitian, langkah yang dilakukan sebagai berikut:
Penyebaran kuesioner tahap satu
Pada tahap satu, kuesioner responden mahasiswa dan tendik disebar secara manual ke beberapa PS dan di SPs, dengan jumlah responden masing-masing berjumlah 30 responden.
Pengujian Instrumen
Pada tahap ini dilakukan pengujian validitas Product Momen dan reliabilitas
Alpha Cronbach's dengan SPSS ver 19 memberikan hasil apakah butir pertanyaan
valid atau tidak, serta apakah pertanyaan reliabel atau konsisten. Hasil pengujian validitas kuesioner Tendik tahap satu dengan N=30 dan nilai signifikansi sebesar 0.374 pada r tabel 0.05. Hasil pengujian validitas butir pertanyaan B1.1, B3.1, B3.5, B3.6, dan B3.19 memiliki nilai r hitung < r tabel, maka butir pertanyaan tesebut tidak dipergunakan pada tahap analisis selanjutnya karena dianggap tidak valid. Rekap hasil pengujian validitas dan reliabilitas instrumen penelitian dapat dilihat pada Tabel 4.
Tabel 4 Hasil uji validitas dan reliabilitas instrumen penelitian Kode
Kategori
Jumlah Instrumen
Product Momen Alpha Cronbach's
Valid Tidak Reliabel Tidak
Kuesioner Mahasiswa
B1 13 12 1 12 0
B2 7 7 0 7 0
B3 12 8 4 8 0
Kuesioner Tendik
B1 8 5 3 5 0
B2 9 9 0 9 0
B3 19 19 0 19 0
B4 12 12 0 12 0
B5 7 7 0 7 0
21 Selanjutnya pengujian terhadap instrumen kuesioner mahasiswa dilakukan hasil pengujian dengan N=30 dan nilai signifikansi sebesar 0.374 pada r tabel 0.05. Hasil pengujian menunjukkan tiga butir pertanyaan yaitu: B1.8, B1.11, dan B1.12 dinyatakan tidak valid (r hitung < r tabel) maka tidak disertakan pada tahap selanjutnya. Hasil Pengujian reliabilitas Alpha Cronbach's dengan N=30 menunjukkan semua butir pertanyaan dinyatakan reliabel atau konsisten, di mana r hitung > r tabel 0.05 sebesar 0.374, hasil pengujian dapat dillihat pada Lampiran 5. Setelah semua instrumen diuji, kuesioner kembali disebarkan kepada responden tendik dan mahasiswa.
Penyebaran kuesioner tahap dua
Pada tahap dua penyebaran kuesioner, responden kuesioner terbagi atas kelompok Mahasiswa dengan 114 responden dan 30 responden bagi kelompok Tendik. Identifikasi kepada responden menghasilkan demografi responden sebagai berikut:
1. Demografi responden Tendik:
Gambar 4 Jenis kelamin Tendik Gambar 5 Pengalaman dengan SIMAK Tingkat pendidikan responden Tendik cukup merata mencakup sarjana (33%), diploma tiga (37%) dan lulusan SMA (30%). Reponden memiliki pengalaman kerja lebih dari 3 tahun dalam menggunakan SIMAK sebesar 60% dan berpengalaman bekerja pada unit terkait lebih dari 10 tahun cukup banyak (33%), menggambarkan responden Tendik cukup berpengalaman pada bidang administrasi akademik dan SIMAK di SPs seperti pada Lampiran 9.
2. Demografi responden mahasiswa adalah sebagai berikut:
Gambar 6 Jenis kelamin mahasiswa Gambar 7 Pengalaman menggunakan SI Responden mahasiswa terdiri atas 55% laki-laki dan 45% responden perempuan, dengan mayoritas usia antara 20 sampai dengan 29 tahun. Mayoritas responden adalah mahasiswa S2 sebesar 91%, dengan pengalaman menggunakan sistem informasi lebih dari dua tahun (75%) seperti pada Lampiran 8.
57%
43% Laki-laki
Peremp uan
3%
3% 34% 60%
Tidak pernah
< 1 tahun
1-3 tahun
> 3 tahun
55%
45% Laki-laki
Peremp uan
8% 10%
7% 75%
Tidak pernah < 1 tahun
1-2 tahun
22
Gambar 8 Intensitas mengakses SIMAK SPs
Gambar 8 memperlihatkan sebagian besar responden kurang dalam mengakses SIMAK SPs yang semestinya menjadi sumber informasi akademik yang penting bagi mahasiswa aktif SPs IPB, hal tersebut dapat menunjukkan SIMAK yang berjalan saat ini hanya dibutuhkan pada saat tertentu. Untuk mendapatkan hasil yang lebih jelas atas kebutuhan pengguna, dilakukan pengolahan dan analisis data hasil penyebaran kuesioner kepada responden dengan menggunakan skala
Likert.
Pengolahan dan Analisis Data dengan Skala Likert
Tahap selanjutnya dilakukan penilaian terhadap butir-butir pertanyaan kuesioner tersebut menggunakan skala Likert dengan interval 1-4 terhadap tigapuluh responden Tendik, hasil penilaian seperti pada Tabel 5:
Tabel 5 Hasil penilaian kuesioner tendik dengan skala Likert
Kode Pertanyaan Indeks Kriteria
B1 Rata-rata interaksi responden dengan SIMAK 66.1 S
B2 Rata-rata kelengkapan dokumen dan dukungan
teknis SIMAK
66.5 S
B3 Rata-rata fitur dan pelayanan online SIMAK 79.3 SS
B4 Rata-rata reliability, usability, dan maintainability
SIMAK
73.0 S
B5 Rata-rata kepuasan pengguna 65.7 S
Rata-rata 70.1 S
Hasil pengukuran menunjukkan bahwa pengguna setuju peran SIMAK SPs saat ini sudah baik, kriteria B3 memperoleh nilai rata-rata cukup tinggi sebesar 79.3 yang menyatakan meskipun peran SIMAK dianggap sudah cukup efektif, namun responden sangat setuju pada pengembangan SIMAK yang lebih baik kedepan, sesuai dengan kebutuhan pengguna:
1. Responden sangat tidak setuju (78.3 dalam skala Likert) atau 24 responden (80%) memilih tidak setuju bahwa tidak diperlukan perangkat lunak lainnya dalam penyelesaian pekerjaan selain SIMAK, seperti pada Lampiran 8a.
2. Responden menyatakan sangat setuju (77.5) dengan integrasi data antar unit/divisi diperlukan diakomodir di SIMAK,
0%
93%
5%2% Tidak pernah
Kadang-kadang
Hampir setiap hari
23 3. Responden menyatakan sangat setuju (86.7) dengan pendaftaran seminar hasil
penelitian perlu difasilitasi secara online,
4. Responden sangat setuju (84.2) dengan pendaftaran seminar secara online akan memudahkan pengguna mendapatkan informasi terkait pelaksanaan seminar,
5. Responden menginginkan penambahan fitur pada SIMAK (82.5) untuk mendukung pekerjaan.
Pengumpulan kebutuhan bagi mahasiswa dapat diperoleh dari penilaian terhadap 114 responden mahasiswa disajikan pada Tabel 6, sebagai berikut: Tabel 6 Hasil penilaian kuesioner mahasiswa dengan skala Likert
Kode Pertanyaan Indeks Kriteria
B1 Rata-rata interaksi responden dengan SIMAK SPs 72.2 S
B2 Rata-rata kelengkapan dokumen dan dukungan
teknis SIMAK 65.3 S
B3 Rata-rata fitur dan pelayanan online SIMAK 77.1 S
Rata-rata 71.5 S
Hasil pengukuran data kuesioner bagi mahasiswa juga menunjukkan hasil yang relatif sama dengan apa yang diperoleh Tendik yaitu memperoleh rata-rata 71.7 (setuju), dan rata-rata 77.1 (sangat setuju) dengan dengan pengembangan pelayanan online SIMAK SPs kedepan. Demikian hasil pengumpulan kebutuhan mahasiswa, sebagai berikut:
1. Responden menyatakan kebutuhan atas SIMAK sangat diperlukan (79.2), dan informasi sangat diperlukan dalam menunjang aktifitas akademik (84.2), 2. Responden mahasiswa juga menyatakan sangat setuju (86.4) dengan
pendaftaran seminar hasil penelitian perlu difasilitasi secara online, seperti halnya responden Tendik,
3. Responden menyatakan pendaftaran online seminar akan memudahkan koordinasi dengan dosen pembimbing (83.8), dan memudahkan memperoleh jadwal pelaksanaan seminar terkini (84.9).
Analisis dan perancangan sistem online yang akan dilakukan ialah sistem pelayanan POB-SPs 11 berdasarkan hasil observasi dan analisa data pelayanan di atas.
Analisa
Hasil analisa kebutuhan yang telah dilakukan pada tahapan di atas divisualisasikan dengan model-model, yaitu domain class diagram, use case
diagram, use case description dan activity diagram. Domain class diagram pada
Gambar 9 menggambarkan relational antara kelas pada skema basis data terintegrasi IPB yang menggunakan pola pendekatan player-role. Pola player-role
