GOAL ORIENTED REQUIREMENT ENGINEERING (GORE) MODEL
Skripsi
Oleh :
ROSYIDA NURUL FUADIYATI 1113091000025
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA
2018 M/ 1440 H
GOAL ORIENTED REQUIREMENT ENGINEERING (GORE) MODEL
Skripsi
Sebagai Salah Satu Syarat untuk Memperoleh Gelar Sarjana Komputer (S.Kom)
Oleh :
ROSYIDA NURUL FUADIYATI 1113091000025
PROGRAM STUDI TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH JAKARTA
2018 M/ 1440 H
LEMBAR PERSETUJUAN
ANALISIS REQUIREMENT SISTEM EVALUASI DOSEN OLEH MAHASISWA (EDOM) ONLINE UIN SYARIF HIDAYATULLAH DENGAN GOAL ORIENTED REQUIREMENT ENGINEERING (GORE)
MODEL
Skripsi
Oleh :
Rosyida Nurul Fuadiyati 1113091000025
Menyetujui,
Mengetahui,
Ketua Program Studi Teknik Informatika
Arini, MT
NIP. 19760131 200901 2 001 Dosen Pembimbing I,
Dr. Imam Marzuki Shofi, MT NIP. 19720205 200801 1 010
Dosen Pembimbing II,
Fenty Eka Muzayyana A, M.Kom NIP. 19760805 200912 2 003
LEMBAR PENGESAHAN
Skripsi berjudul Analisis Requirement Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah dengan Goal Oriented Requirement Engineering (GORE) Model yang ditulis oleh Rosyida Nurul Fuadiyati, NIM 1113091000025 telah diujikan dalam sidang munaqasyah Fakultas Sains dan Teknologi UIN Syarif Hidayatullah Jakarta pada 1 Oktober 2018. Skripsi ini telah diterima sebagai salah satu syarat memperoleh gelar Sarjana Komputer (S.Kom) pada Program Studi Teknik Informatika.
Jakarta, 1 Oktober 2018 Tim Penguji
Tim Pembimbing
Mengetahui, Dosen Pembimbing I,
Dr. Imam Marzuki Shofi, MT NIP. 19720205 200801 1 010
Dosen Pembimbing II,
Fenty Eka Muzayyana A, M.Kom NIP. 19760805 200912 2 003
Ketua Program Studi Teknik Informatika
Arini, MT
NIP. 19760131 200901 2 001 Penguji I,
Nurhayati, Ph.D NIP. 19690316 199903 2 002
Penguji II,
Nenny Anggraini, S.Kom, MT NIDN. 0310097601
Dekan Fakultas Sains dan Teknologi
Dr. Agus Salim, M.Si NIP. 19720816 199903 1 003
PERNYATAAN ORISINALITAS
Dengan ini saya menyatakan bahwa :
1. Skripsi ini merupakan hasil karya asli saya yang diajukan untuk memenuhi salah satu persyaratan memperoleh gelas Strata 1 di UIN Syarif Hidayatullah Jakarta 2. Semua sumber yang saya gunakan dalam penulisan ini telah saya cantumkan
sesuai dengan ketentuan yang berlaku di UIN Syarif Hidayatullah Jakarta 3. Apabila di kemudian hari terbukti karya ini bukan hasil karya asli saya atau
merupakan hasil jiplakan karya orang lain, maka saya bersedia menerima sanksi yang berlaku di UIN Syarif Hidayatullah Jakarta
Jakarta, 1 Oktober 2018
Rosyida Nurul Fuadiyati
PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI
Sebagai civitas akademik UIN Syarif Hidayatullah Jakarta, saya yang bertanda tangan di bawah ini:
Nama : Rosyida Nurul Fuadiyati
NIM : 1113091000025
Program Studi : Teknik Informatika Fakultas : Sains dan Teknologi Jenis Karya : Skripsi
demi pembuatan ilmu pengetahuan, menyetujui untuk memberikan kepada UIN Syarif Hidayatullah Jakarta Hak Bebas Royalti Noneksklusif (Non-exclusive Royalti Free Right) atas karya ilmiah yang berjudul:
ANALISIS REQUIREMENT SISTEM EVALUASI DOSEN OLEH MAHASISWA (EDOM) ONLINE UIN SYARIF HIDAYATULLAH DENGAN GOAL ORIENTED REQUIREMENT ENGINEERING (GORE)
MODEL
beserta perangkat yang ada (jika diperlukan). Dengan Hak Bebas Royalti Noneksklusif ini UIN Syarif Hidayatullah Jakarta berhak menyimpan, mengalihmedia/ formatkan, mengelola dalam bentuk pangkalan data (database), merawat, dan mempublikasikan tugas akhir saya selama tetap mencantumkan nama saya sebagai penulis/ pencipta dan sebagai pemilik Hak Cipta. Demikian pernyataan ini saya buat dengan sebenarnya.
Jakarta, 1 Oktober 2018 Yang menyatakan,
(Rosyida Nurul Fuadiyati)
Nama : Rosyida Nurul Fuadiyati Program Studi : Teknik Informatika
Judul : Analisis Requirement Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah Dengan Goal Oriented Requirement Engineering (GORE) Model
ABSTRAK
Evaluasi Dosen Oleh Mahasiswa (EDOM) merupakan bentuk penilaian kinerja dosen untuk mengetahui seberapa besar kompetensi yang dimiliki guna peningkatan mutu pendidikan. Hasil kuesioner terhadap mahasiswa dan dosen serta wawancara dengan Lembaga Penjaminan Mutu (LPM) UIN Syarif Hidayatullah menyimpulkan bahwa pelaksanaan EDOM Online yang diterapkan oleh LPM UIN Syarif Hidayatullah belum optimal. Hal tersebut dikarenakan goal yang diharapkan oleh LPM tidak tersampaikan dengan jelas, sehingga kebutuhan para stakeholder tidak terwakilkan oleh adanya sistem EDOM Online. Dengan melakukan analisis requirement diharapkan mampu membantu pengidentifikasi goals yang diinginkan.
Metode requirement engineering yang digunakan adalah metode Goal-Oriented Requirement Engineering (GORE) dengan menggunakan pendekatan Knowledge Acquisition in autOmated Spesification atau Keep All Objects Satisfied (KAOS).
Hasil yang didapatkan dari analisis ini adalah kesenjangan antara goal yang sebenarnya ingin dicapai dengan requirement yang ada pada sistem EDOM Online saat ini.
Kata Kunci : Evaluasi Dosen Oleh Mahasiswa (EDOM), Goal Oriented Requirements Engineering (GORE), Knowledge Acquisition in autOmated Spesification atau Keep All Objects Satisfied (KAOS)
Jumlah Pustaka : 11 Buku, 16 Jurnal, dan 3 Website.
Jumlah Halaman : xiv + 114 Lembar
Name : Rosyida Nurul Fuadiyati Study Program : Teknik Informatika
Title : Analisis Requirement Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah Dengan Goal Oriented Requirement Engineering (GORE) Model
ABSTRACT
Evaluasi Dosen Oleh Mahasiswa (EDOM) is a form of lecturer performance assessment to find out how much competence they have in order to improve the quality of education. Questionnaire results for students and lecturers as well as interviews with the Lembaga Penjaminan Mutu (LPM) UIN Syarif Hidayatullah concluded that the implementation of EDOM Online by LPM UIN Syarif Hidayatullah was not optimal. This is because the goals expected by the LPM are not conveyed clearly, so that the needs of the stakeholders are not represented by the existence of the EDOM Online system. By analyzing requirements, it is expected to be able to help the desired goal identifiers. The requirements engineering method used is the Goal-Oriented Requirement Engineering (GORE) method using the Knowledge Acquisition approach in autOmated Specification or Keep All Objects Satisfied (KAOS). The results obtained from this analysis are the gap between the actual goals to be achieved with the requirements that exist in the current EDOM Online system.
Keywords : Evaluasi Dosen Oleh Mahasiswa (EDOM), Goal Oriented Requirements Engineering (GORE), Knowledge Acquisition in autOmated Spesification or Keep All Objects Satisfied (KAOS)
KATA PENGANTAR
Puji syukur penulis panjatkan kepada Allah SWT, karena atas nikmat dan rahmat-Nya sehingga penulis dapat menyelesaikan skripsi ini. Penulisan skripsi ini dilakukan dalam rangka memenuhi salah satu syarat untuk mencapai gelar Sarjana Komputer Program Studi Teknik Informatika Fakultas Sains dan Teknologi Universitas Islam Negeri Syarif Hidayatullah Jakarta. Proses penyelesaian skripsi ini tidak lepas dari berbagai bantuan, dukungan, saran, dan kritik yang telah penulis dapatkan, oleh karena itu dalam kesempatan ini penulis ingin mengucapkan terima kasih kepada:
1. Allah SWT yang telah memberikan nikmat, rahmat, dan karunia-Nya kepada penulis .
2. Keluarga tercinta, Bapak Tugi (Alm), Mama Farida Nur’aini, dan Mas Syariful Anam Rifai yang telah mencurahkan kasih sayang, do’a, dan dukungan penuh kepada penulis dalam mengerjakan skripsi.
3. Bapak Dr. Agus Salim, M.Si., selaku Dekan Fakultas Sains dan Teknologi.
4. Ibu Arini, ST. MT., selaku ketua Program Studi Teknik Informatika, serta Bapak Feri Fahrianto, M.Sc., selaku sekretaris Program Studi Teknik Informatika.
5. Bapak Dr. Imam Marzuki Shofi, MT., selaku Dosen Pembimbing I dan Ibu Fenty Eka Muzayyana Agustin, M.Kom., selaku Dosen Pembimbing II yang telah memberikan bimbingan, motivasi, dan arahan kepada penulis sehingga skripsi ini bisa selesai dengan baik.
6. Seluruh Dosen, Staf Karyawan Fakultas Sains dan Teknologi, khususnya Program Studi Teknik Informatika yang telah memberikan bantuan dan kerjasama yang telah terjalin dari awal perkuliahan.
7. Pihak Lembaga Penjaminan Mutu UIN Syarif Hidayatullah, Bapak Jejen Jaenudin selaku Kepala Pusat Audit dan Penjaminan Mutu yang telah bersedia membantu penulis dalam mengumpulkan data yang dibutuhkan.
8. Teman seperjuangan seperskripsian, yang hampir selalu bareng progress skripsinya dan selalu bareng kalau bimbingan, Qurrotul Aini.
9. Rakhmat Hidayat, Mochamad Tri Dharmawan, Bintang Maliki Sarwoko, Fidaq Imaduddin Ashsidiq, Dzul Fadli Rahman, Muhammad Dirga Dzulfiqar, Atqia Aulia, dan Adhyaksa Herdhianto. Terimakasih karena telah menyediakan waktu untuk menemani dan membantu penulis selama masa perkuliahan hingga menyelesaikan skripsi, serta dukungan dan doanya.
10. Sahabat setia, teman rumpi ‘urgent gils’ yang selalu jadi pelipur lara semasa kuliah, Sarah Khairunnisa, Syinsyina Arifa, dan Imelda Ristanti Julia.
11. Teman – teman seperjuangan Teknik Informatika angkatan 2013 khususnya TI – A, TI – B, juga TI – C. Terimakasih buat semua kenangan dan kebersamaan selama ini.
12. Muhammad Ashari, yang senantiasa memberikan semangat, dukungan, dan doa. Terimakasih untuk semua waktu dan bantuannya kepada penulis, sehingga penulis dapat menyelesaikan skripsi ini.
13. Seluruh pihak yang tidak dapat penulis sebut satu persatu yang secara langsung maupun tidak langsung membantu penulis dalam menyelesaikan skripsi ini.
Akhir kata, penulis berharap semoga skripsi ini bermanfaat serta menambah wawasan dan pengetahuan bagi pembaca. Penulis menyadari bahwa skripsi ini masih jauh dari sempurna, untuk itu kritik dan saran yang bersifat membangun sangat diharapkan dengan mengirimkan melalui email ke [email protected].
Jakarta, 1 Oktober 2018
Rosyida Nurul Fuadiyati
DAFTAR ISI
LEMBAR PERSETUJUAN ... ii
LEMBAR PENGESAHAN ... iii
PERNYATAAN ORISINALITAS ... iv
PERNYATAAN PERSETUJUAN PUBLIKASI SKRIPSI ... v
ABSTRAK ... vi
ABSTRACT ... vii
KATA PENGANTAR ... viii
DAFTAR GAMBAR ... xii
DAFTAR TABEL ... xiv
BAB I PENDAHULUAN ... 1
1.1. Latar Belakang Masalah ... 1
1.2. Tujuan Penelitian ... 6
1.3. Manfaat Penelitian ... 6
1.3.1. Penulis ... 6
1.3.2. Universitas ... 6
1.3.3. Pengguna ... 6
1.4. Rumusan Masalah ... 6
1.5. Batasan Masalah ... 7
1.6. Metodologi Penelitian ... 7
1.6.1. Metode Pengumpulan Data ... 7
1.6.2. Metode Penelitian... 7
1.6.3. Analisis Kesenjangan ... 8
1.7. Sistematika Penulisan ... 8
BAB II LANDASAN TEORI ... 10
2.1. Sistem ... 10
2.2. Evaluasi Dosen Oleh Mahasiswa (EDOM) ... 10
2.3. Requirement Engineering (RE) ... 11
2.4. Requirement Elicitation ... 14
2.4.1. Teknik Elicitation Artefact-Driven ... 14
2.4.2. Teknik Elicitation Stakeholder-Driven ... 19
2.5. Goal Oriented Requirement Engineering (GORE) ... 24
2.5.1. Definisi GORE ... 24
2.5.2. Konsep Goal, Requirement, dan Agent ... 24
2.5.3. Metode GORE ... 26
2.6. Knowledge Acquisition in Automated Specification atau Keep All Objects Satisfied (KAOS) ... 29
2.6.1. Konsep KAOS ... 29
2.6.2. Model Pendekatan KAOS ... 30
2.6. Metode Pengumpulan Data ... 37
2.6.1. Observasi ... 37
2.6.2. Kuesioner ... 37
2.6.3. Wawancara ... 38
2.6.4. Studi Literatur ... 38
2.7. Definisi Analisis Kesenjangan ... 39
BAB III METODOLOGI PENELITIAN ... 41
3.1. Kuesioner ... 41
3.2. Studi Literatur ... 41
3.3. Studi Latar Belakang (Background Study) ... 42
3.4. Observasi... 42
3.5. Wawancara ... 42
3.6. Goal Oriented Requirement Engineering (GORE) Pendekatan Knowledge Acquisition in autOmated Specification atau Keep All Objects Satisfied (KAOS) ...42
3.6.1. Membangun Goal Model ... 43
3.6.2. Membangun Responsibility Model ... 43
3.6.3. Validasi Goal Model ... 44
3.6.4. Validasi Responsibility Model... 44
3.7. Analisis Kesenjangan ... 44
3.8. Kerangka Berpikir ... 45
BAB IV ANALISIS SISTEM ... 46
4.1. Analisis Sistem EDOM Online yang Sedang Berjalan Saat Ini ... 46
4.1.1. Analisis Dokumen ... 46
4.1.2. Analisis Fungsi-fungsi yang Terdapat pada Sistem EDOM Online Saat Ini ...49
4.1.3. Requirement sistem EDOM Online saat ini ... 61
4.2. Analisis Pemodelan Goal Sistem EDOM Online ... 62
4.2.1. Analisis Pemodelan Goal Model Awal ... 63
4.2.2. Responsibility Model Awal ... 71
4.3. Analisis Hasil Validasi Model Goal Diagram ... 74
4.3.1. Analisis Pemodelan Goal Model Akhir ... 74
4.3.2. Responsibility Model Akhir... 79
BAB V HASIL DAN PEMBAHASAN ... 81
5.1. Analisis Kesenjangan ... 81
5.1.1. Jumlah responden tiap dosen sesuai dengan jumlah peserta mata kuliah …...85
5.1.2. Setiap fakultas dapat melihat hasil EDOM di fakultasnya... 86
5.1.3. Stabilitas sistem terjaga ... 87
BAB VI PENUTUP ... 88
6.1. Kesimpulan ... 88
6.2. Saran ... 90
DAFTAR PUSTAKA ... 91
LAMPIRAN ... 94
DAFTAR GAMBAR
Gambar 1. 1. Hasil kuesioner mahasiswa (mengisi EDOM tiap semester) ... 3
Gambar 1. 2. Hasil kuesioner mahasiswa (pengisian form EDOM) ... 3
Gambar 1. 3. Hasil kuesioner mahasiswa (pentingnya EDOM) ... 3
Gambar 1. 4. Hasil kuesioner dosen (pentingnya EDOM) ... 4
Gambar 2. 1. Tiga Dimensi Requirement Engineering ... 12
Gambar 2. 2. Model pendekatan KAOS ... 31
Gambar 2. 3. Goal model ... 33
Gambar 2. 4. Conflict pada goal diagram ... 34
Gambar 2. 5. Responsibility model ... 35
Gambar 2. 6. Operation model ... 37
Gambar 3. 1. Kerangka berpikir ... 45
Gambar 4. 1. Flowchart pelaksanaan EDOM Online ... 48
Gambar 4. 2. Halaman group penilaian dosen ... 50
Gambar 4. 3. Halaman edit pada halaman group penilaian dosen ... 50
Gambar 4. 4. Halaman list penilaian dosen ... 51
Gambar 4. 5. Halaman edit pada halaman list penilaian dosen ... 52
Gambar 4. 6. Halaman homebase dosen ... 52
Gambar 4. 7. Halaman edit data pada halaman homebase dosen ... 53
Gambar 4. 8. Halaman revisi data pegawai pada halaman homebase dosen ... 54
Gambar 4. 9. Halaman detil revisi data pegawai pada halaman homebase dosen 54 Gambar 4. 10. Halaman jadwal angket dosen ... 55
Gambar 4. 11. Halaman edit data pada halaman jadwal angket dosen ... 56
Gambar 4. 12. Halaman rekap angket dosen... 57
Gambar 4. 13. Halaman rekap angket dosen per fakultas ... 58
Gambar 4. 14. Halaman rekapitulasi dosen mengajar... 59
Gambar 4. 15. Formulir kuesioner EDOM Online ... 60
Gambar 4. 16. Requirement yang terdapat pada sistem EDOM Online saat ini ... 62
Gambar 4. 17. Pemodelan goal diagram awal ... 64
Gambar 4. 18. Amanat SISDIKNAS harus ada evaluasi untuk dosen sebagai tolak ukur penilaian kinerja dosen ... 65
Gambar 4. 19. Sistem EDOM Online dibangun secara efektif ... 67
Gambar 4. 20. Hasil report sesuai ... 68
Gambar 4. 21. Setiap fakultas dapat melihat hasil EDOM di fakultasnya ... 70
Gambar 4. 22. Responsibility dari PUSTIPANDA ... 72
Gambar 4. 23. Responsibility dari mahasiswa ... 72
Gambar 4. 24. Responsibility dari sistem ... 73
Gambar 4. 25. Responsibility dari LPM ... 73
Gambar 4. 26. Pemodelan goal diagram akhir ... 75
Gambar 4. 27. Amanat SISDIKNAS harus ada evaluasi untuk dosen sebagai tolak ukur penilaian kinerja dosen (diagram akhir) ... 76
Gambar 4. 28. Stabilitas sistem terjaga (diagram akhir) ... 77
Gambar 4. 29. Hasil report sesuai (diagram akhir) ... 78
Gambar 4. 30. Setiap fakultas dapat melihat hasil EDOM di fakultasnya ... 79
Gambar 4. 31. Responsibility dari PUSTIPANDA (diagram akhir) ... 79
Gambar 4. 32. Responsibility dari mahasiswa (diagram akhir) ... 80
Gambar 4. 33. Responsibility dari sistem (diagram akhir) ... 80
Gambar 4. 34. Responsibility dari LPM (diagram akhir) ... 80
Gambar 5. 1. Pemodelan hasil analisis kesenjangan antara goal yang ingin dicapai dengan requirement yang terdapat pada sistem EDOM Online saat ini ... 82
Gambar 5. 2. Hasil Presentase Keberhasilan ... 84
DAFTAR TABEL
Tabel 1. 1. Hasil kuesioner dosen ... 3
Tabel 2. 1. Perbandingan metode GORE ... 27
Tabel 2. 2. Studi literatur sejenis ... 38
Tabel 5. 1. Hasil analisis kesenjangan ... 83
Tabel 5. 2. Perbandingan jumlah peserta mata kuliah dengan jumlah responden EDOM Online ... 85
1.1. Latar Belakang Masalah
Menurut Undang-Undang Nomor 14 Tahun 2005 Tentang Guru dan Dosen, Dosen adalah pendidik profesional dan ilmuwan dengan tugas utama mentransformasikan, mengembangkan, dan menyebarluaskan ilmu pengetahuan, teknologi, dan seni melalui pendidikan, penelitian, dan pengabdian kepada masyarakat. Dosen wajib memiliki kualifikasi akademik, kompetensi, sertifikat pendidik, sehat jasmani dan rohani, dan memenuhi kualifikasi lain yang dipersyaratkan satuan pendidikan tinggi tempat bertugas, serta memiliki kemampuan untuk mewujudkan tujuan pendidikan nasional. Kompetensi tenaga pendidik, khususnya dosen, diartikan sebagai seperangkat pengetahuan, keterampilan dan perilaku yang harus dimiliki, dihayati, dikuasai dan diwujudkan oleh dosen dalam melaksanakan tugas profesionalnya. Kompetensi sebagaimana dimaksud meliputi kompetensi pedagogik, kompetensi kepribadian, kompetensi sosial, dan kompetensi profesional yang diperoleh melalui pendidikan profesi (Presiden Republik Indonesia, 2005).
Menurut Peraturan Pemerintah Nomor 37 Tahun 2009 Tentang Dosen, dosen wajib melaksanakan tridharma perguruan tinggi dengan beban kerja paling sedikit sepadan dengan 12 (dua belas) sks dan paling banyak 16 (enam belas) sks pada setiap semester sesuai dengan kualifikasi akademik. Pelaksanaan tugas utama dosen ini perlu dievaluasi dan dilaporkan secara periodik sebagai bentuk akuntabilitas kinerja dosen kepada para pemangku kepentingan (Pemerintah Republik Indonesia, 2009). Evaluasi kinerja dosen bertujuan untuk (1) meningkatkan profesionalisme dosen dalam melaksanakan tugas, (2) meningkatkan proses dan hasil pendidikan, (3) menilai akuntabilitas kinerja dosen di perguruan tinggi, (4) meningkatkan atmosfer akademik di semua jenjang perguruan tinggi, dan (5) mempercepat terwujudnya tujuan pendidikan nasional (Dsepdiknas, 2010).
Tugas untuk melaksanakan evaluasi merupakan tugas yang dilakukan terus-menerus sebagai bentuk akuntabilitas terhadap pemangku kepentingan, oleh
karena itu sebaiknya tidak dilakukan oleh suatu panitia ad hoc tetapi dilakukan oleh sebuah struktur kelembagaan yang ada dan melekat pada sistem di perguruan tinggi tersebut misalnya Lembaga Penjaminan Mutu, LP3I atau yang lain (Depdiknas, 2010).
Dalam rangka mengkonsolidasikan diri sejalan dan mendukung sebagai universitas riset, Rektor UIN Syarif Hidayatullah Jakarta membentuk unit peningkatan mutu yang bernama Center for Quality Development and Assurance (CeQDA) atau Pusat Peningkatan dan Jaminan Mutu (PPJM) UIN Syarif Hidayatullah Jakarta yang saat ini menjadi Lembaga Penjaminan Mutu (LPM).
LPM merupakan bagian penting dari upaya peningkatan mutu perguruan tinggi secara keseluruhan, elemen yang diharapkan berperan untuk memperjelas, menumbuhkan, mengkonsolidasi, mempercepat, mensistematisasikan serta melembagakan gerakan mutu pendidikan tinggi mulai dari tingkat universitas, fakultas, hingga program studi (LPM UIN Syarif Hidayatullah, n.d.). Pengolahan laporan nilai kinerja dosen UIN Syarif Hidayatullah merupakan salah satu pekerjaan rutinitas yang dilakukan pada setiap semester di unit Lembaga Penjaminan Mutu (LPM).
Peranan dosen sebagai pengajar sangat menentukan dalam usaha untuk meningkatkan mutu Perguruan Tinggi khususnya mutu Proses Belajar Mengajar.
Di UIN Syarif Hidayatullah, untuk menjaga mutu pendidikan dilakukan dengan cara evaluasi langsung dari mahasiswa terhadap dosen pengampunya. Menurut Peraturan Pemerintah Republik Indonesia Nomor 37 Tahun 2009 Tentang Dosen, cara evaluasi guna peningkatan mutu pendidikan tersebut dengan menggunakan program Evaluasi Dosen oleh Mahasiswa (EDOM) yaitu sistem evaluasi kinerja dosen dalam proses pembelajaran untuk mengetahui seberapa besar kompetensi yang dimiliki dosen (Pemerintah Republik Indonesia, 2009). Pengisian EDOM pada UIN Syarif Hidayatullah menggunakan alat bantu kuesioner dan dilakukan diakhir semester tepatnya ketika ingin melihat Index Prestasi (IP). Kemudian hasil atau laporan hasil dari EDOM diberikan langsung kepada setiap Dosen sesuai dengan mata kuliah yang diampunya. Saat ini sistem informasi EDOM telah dikembangkan secara terkomputerisasi yang dilakukan secara online. Namun
masih memiliki beberapa kendala seperti masih kurang optimal dalam penerapannya.
Berdasarkan kuesioner online yang penulis lakukan terhadap 101 responden mahasiswa UIN Syarif Hidayatullah Jakarta, terlihat hasilnya dalam diagram berikut:
Gambar 1. 1. Hasil kuesioner mahasiswa Gambar 1. 2. Hasil kuesioner mahasiswa (mengisi EDOM tiap semester) (pengisian form EDOM)
Gambar 1. 3. Hasil kuesioner mahasiswa (pentingnya EDOM)
Sedangkan berdasarkan kuesioner online yang penulis lakukan terhadap 7 responden dosen UIN Syarif Hidayatullah Jakarta, didapatkan hasil presentase yang dirangkum dalam tabel dan diagram berikut:
Tabel 1. 1. Hasil kuesioner dosen
Mengetahui adanya EDOM Ya 85,7%
Tidak 14,3%
Mengetahui tujuan EDOM Ya 71,4%
Tidak 28,6%
Mengetahui manfaat EDOM Ya 71,4%
Tidak 28,6%
5,0%
31,7%
25,7%
11,9%
25,7%
Seberapa sering Mahasiswa mengisi form EDOM pada AIS?
Tidak Pernah Kadang-kadang Jarang Sering Selalu
74,3%
25,7%
Apakah Mahasiswa mengisi form EDOM sesuai jumlah dosen pada sejumlah mata kuliah yang diikuti?
Ya Tidak
1,0%
13,9%
51,5%
23,8%
9,9%
Seberapa penting EDOM?
Sangat Tidak Penting Tidak Penting Cukup Penting Penting Sangat Penting
Gambar 1. 4. Hasil kuesioner dosen (pentingnya EDOM)
Seperti data responden di atas, berdasarkan hasil wawancara yang penulis lakukan kepada Bapak Jejen selaku Kepala Pusat Audit dan Penjaminan Mutu bahwa mahasiswa seharusnya mengisi EDOM sejumlah mata kuliah yang diikuti, tetapi pada kenyataannya ketika satu mata kuliah diisi EDOMnya mahasiswa tersebut sudah dapat melihat Index Prestasi (IP) dan Kartu Hasil Studi (KHS) miliknya, sehingga jumlah responden untuk setiap dosen tidak sesuai dengan jumlah peserta mata kuliah. Diungkapkan pula bahwa hal tersebut tidak sesuai dengan requirement sistem EDOM itu sendiri.
Hasil kuesioner di atas hanya dilakukan sebagai data pendukung, sedangkan untuk melakukan analisis hanya berdasarkan wawancara. Berdasarkan hasil kuesioner dan wawancara sebagai penguat latar belakang masalah tersebut, maka dapat disimpulkan bahwa pelaksanaan EDOM Online yang diterapkan oleh LPM UIN Syarif Hidayatullah belum optimal karena masih ada sejumlah mahasiswa yang belum mengisi EDOM secara rutin dan lengkap di tiap akhir semester, tetapi tetap dapat melihat IP ataupun KHS. Hal tersebut dikarenakan goal yang diharapkan oleh LPM tidak tersampaikan dengan jelas, sehingga kebutuhan para stakeholder atau dalam kasus ini adalah mahasiswa dan dosen tidak terwakilkan oleh adanya sistem EDOM Online.
Suatu sistem informasi memiliki kriteria-kriteria yang menyebabkan penerapannya dalam suatu perusahaan dapat memiliki kemungkinan sukses atau gagal. Lyytinen dan Hirschheim mengungkapkan terdapat empat kategori kegagalan penerapan sistem informasi, yaitu: 1. Correspondences failure, terjadi ketika sistem informasi tidak mampu memenuhi tujuan dari desainnya; 2. Process failure, terjadi ketika sistem informasi tidak dapat dikembangkan karena melebihi
28,6%
42,8%
28,6%
Seberapa penting EDOM?
Sangat Tidak Penting Tidak Penting Cukup Penting Penting Sangat Penting
biaya yang direncanakan atau melewati batas waktu penyelesaian yang ditentukan;
3. Interaction failre, dikarenakan pengguna jarang atau tidak merawat sistem informasi yang ada; 4. Expectation failure, dimana sistem informasi tidak mampu memenuhi harapan dari para stakeholder (Yeo, 2002).
Seringkali penerapan sistem informasi, terutama yang berbasis IT belum memberikan hasil yang optimal karena ketidaksesuaian tujuan yang diharapkan dari sistem yang dikembangkan dengan requirement yang ada saat ini. Studi yang dilakukan oleh The Standish Group mencatat bahwa presentase akumulatif kegagalan oleh suatu proyek pengembangan software sebagian besar disebabkan oleh masalah requirement dan spesifikasinya (Wahono, 2003). Sedangkan, analisis requirement merupakan langkah awal dalam pengembangan sistem dan harus menarik perhatian khusus bagi pengembang sistem serta harus didukung dengan metode yang efektif (Winter & Strauch, 2003).
Meningkatnya fokus terhadap hasil produksi memungkinkan kurangnya perhatian pada proses identifikasi dan pengumpulan requirement saat mengembangkan sistem informasi, serta tidak terpeliharanya dokumentasi yang mencerminkan keadaan sebuah sistem informasi (Lapouchnian, 2005). Melihat kondisi LPM UIN Syarif Hidayatullah yang kurang optimal dalam hal pendokumentasian dan penetapan requirement dalam mengembangkan sistem informasi, penulis termotivasi melakukan analisis requirement terhadap sistem yang telah ada yaitu Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online dengan melakukan analisis kesenjangan antara goal yang sebenarnya ingin dicapai dengan requirement yang ada pada sistem EDOM Online saat ini. Kasus ini digunakan karena sistem yang dikembangkan diharapkan mampu merubah pola kerja dan meningkatkan efisiensi serta efektifitas dengan menggunakan teknologi informasi terkini. Sistem ini memerlukan perencanaan pengembangan yang dapat mewakili kebutuhan para stakeholder tersebut namun harus sesuai dengan goal yang diharapkan oleh LPM. Salah satu metode requirement engineering yang membantu pengidentifikasi goals yang diinginkan adalah metode Goal-Oriented Requirement Engineering (GORE) dengan menggunakan pendekatan Knowledge Acquisition in autOmated Spesification atau Keep All Objects Satisfied (KAOS).
1.2. Tujuan Penelitian
Adapun tujuan dari penelitian ini adalah menentukan kesenjangan antara requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah saat ini dengan goal yang ingin dicapai dari analisis menggunakan Goal Oriented Requirement Engineering (GORE) model.
1.3. Manfaat Penelitian 1.3.1. Penulis
Manfaat penelitian ini bagi penulis adalah menerapkan ilmu dan pengetahuan selama kuliah.
1.3.2. Universitas
Manfaat penelitian ini bagi Universitas agar penelitian ini dapat menjadi referensi untuk penelitian selanjutnya.
1.3.3. Pengguna
Manfaat penelitian ini bagi pengguna adalah:
1. Memberikan gambaran mengenai requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online sesuai dengan Goal Oriented Requirement Engineering (GORE) model sehingga pembaca lebih mudah memahaminya.
2. Pengguna dapat mengetahui kesenjangan antara requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online saat ini dengan goal yang ingin dicapai.
1.4. Rumusan Masalah
Berdasarkan dari uraian latar belakang di atas maka dapat dirumuskan permasalahannya adalah bagaimana menganalisis requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah dengan Goal Oriented Requirement Engineering (GORE) model?
1.5. Batasan Masalah
Untuk mencapai penelitian yang lebih terarah dan dengan menimbang keterbatasan yang ada, maka penulis hanya membatasi pada :
1. Analisis goal dilakukan pada sistem EDOM Online pada UIN Syarif Hidayatullah Jakarta.
2. Penulis berfokus pada pembuatan goal model dan responsibility model dalam pendekatan Knowledge Acquisition in autOmated Specification atau Keep All Objects Satisfied (KAOS).
3. Requirement yang digunakan untuk analisis Goal Oriented Requirement Engineering (GORE) berdasarkan hasil wawancara.
1.6. Metodologi Penelitian
Pada penyusunan penelitian “Analisis Requirement Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah dengan Goal Oriented Requirement Engineering (GORE) Model”, penulis menggunakan pengumpulan data dan proses perancangan dengan metode :
1.6.1. Metode Pengumpulan Data 1. Kuesioner
2. Observasi 3. Wawancara
4. Studi Latar Belakang 5. Studi Literatur
1.6.2. Metode Penelitian
Dalam menganalisis requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online ini, penulis menggunakan metode Goal Oriented Requirement Engineering (GORE) dan pendekatan Knowledge Acquisition in autOmated Specification atau Keep All Objects Satisfied (KAOS) yang berfokus pada:
1. Membangun Goal Model
2. Membangun Responsibility Model
3. Validasi Goal Model
4. Validasi Responsibility Model
1.6.3. Analisis Kesenjangan
Analisis kesenjangan yang dilakukan adalah analisis kesenjangan antara goal yang sebenarnya ingin dicapai dengan requirement dan fungsi yang telah terealisasi pada sistem EDOM Online saat ini dengan memetakan goal dalam bentuk diagram.
1.7. Sistematika Penulisan
Sistematika penulisan skripsi ini dibagi menjadi beberapa bagian, yaitu:
BAB I PENDAHULUAN
Menjelaskan tentang latar belakang diambilnya judul skripsi Analisis Requirement Sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online UIN Syarif Hidayatullah dengan Goal Oriented Requirement Engineering (GORE) Model dan penulis juga memberikan rumusan masalah dimana rumusan ini diambil dari permasalahan yang terdapat pada latar belakang. Lalu penulis juga memaparkan batasan massalah, tujuan yang akan dicapai dalam skripsi ini, dan manfaat dengan adanya penulisan skripsi dan sistem yang akan dibuat. Kemudian penulis juga menjelaskan sistematika penulisan dalam skripsi yang dibuat.
BAB II LANDASAN TEORI
Bab ini menjelaskan tentang landasan teori yang berisi teori-teori yang menunjang dan mendasari penulisan dalam skripsi ini.
BAB III METODOLOGI PENELITIAN
Pada bab ini akan dibahas mengenai pemaparan metodologi penelitian yang penulis gunakan dalam pengumpulan data maupun analisis sistem yang dilakukan pada penelitian, dan kerangka penelitian.
BAB IV ANALISIS SISTEM
Pada bab ini membahas tentang analisis requirement sistem Evaluasi Dosen oleh Mahasiswa (EDOM) Online, yaitu menggunakan metode Goal Oriented Requirement Engineering (GORE) dan pendekatan Knowledge Acquisition in autOmated Specification atau Keep All Objects Satisfied (KAOS).
BAB V HASIL DAN PEMBAHASAN
Pada bab ini data atau informasi hasil penelitian diolah, dianalisis, ditafsirkan, dikaitkan dengan landasan teori serta metodologi yang digunakan sehingga analisis sistem sesuai dengan tujuan yang ditentukan.
BAB VI PENUTUP
Pada bab ini akan memaparkan kesimpulan dari pembahasan yang telah dilakukan pada bab sebelumnya dan memberikan saran untuk pengembangan sistem lebih baik ke depannya.
DAFTAR PUSTAKA LAMPIRAN
2.1. Sistem
Sutabri menjelaskan sistem adalah sekelompok unsur yang erat hubungannya satu dengan yang lain yang berfungsi bersama-sama untuk mencapai tujuan tertentu (Sutabri, 2012).
Menurut teori Indrajit, sistem mengandung arti kumpulan-kumpulan dari komponen-komponen yang memiliki unsur keterkaitan antara satu dengan lainnya (Hutahaean, 2014).
Sekelompok penulis (Johnson dkk., 1967) mendefinisikan suatu sistem sebagai “bagian-bagian yang terhimpun atau terorganisasi atau terkombinasi yang membentuk suatu kesatuan yang akan membantu menentukan sistem yang lebih tepat sebagai suatu kesatuan dari komponen-komponen yang didesain untuk memenuhi tujuan tertentu yang telah direncanakan” (Anwar, 2009).
Berdasarkan kedua pendapat di atas mengenai definisi sistem, penulis dapat mengambil kesimpulan bahwa sistem merupakan sekelompok unsur yang berkaitan antara satu dengan lainnya untuk mencapai tujuan tertentu.
2.2. Evaluasi Dosen Oleh Mahasiswa (EDOM)
Evaluasi Dosen oleh Mahasiswa, instrumen untuk menilai kinerja dosen dalam proses pembelajaran di akhir semester (Universitas Indonesia, 2007). EDOM (Evaluasi Dosen oleh Mahasiswa) adalah rangkaian proses evaluasi untuk memperoleh informasi dari mahasiswa secara objektif mengenai kinerja dosen dalam proses pembelajaran (Fakultas Kedokteran Universitas Warmadewa, n.d.).
Evaluasi Dosen oleh Mahasiswa (EDOM) merupakan salah satu bentuk monitoring universitas dalam memonitor aktivitas dosen dalam bidang pengajaran di kelas. Mahasiswa tentunya mengetahui secara persis kondisi pengajaran dosen, sehingga EDOM ini hadir sebagai bentuk penilaian langsung mahasiswa terhadap dosennya. Evaluasi oleh mahasiswa ini dilakukan secara periodic, dimana
dilakukan setiap semester setelah pembelajaran berakhir. Hal ini dimaksudkan agar mutu setiap dosen tetap terjaga dengan baik (UIN Syarif Hidayatullah, 2016).
Dengan mengisi EDOM berarti mahasiswa telah berpartisipasi untuk membantu meningkatkan mutu pembelajaran. EDOM bermanfaat bagi dosen untuk memperbaiki diri bila memang masih terdapat kekurangan serta mengembangkan potensi dan kelebihan yang dimilikinya. Bagi manajemen universitas, fakultas, dan departemen (program studi), hasil EDOM dapat dijadikan acuan dalam menyusun program peningkatan mutu proses pembelajaran dan kinerja dosen. Dan yang terpenting bagi mahasiswa, dapat merasakan peningkatan mutu proses pembelajaran yang terus menerus (Universitas Indonesia, 2007).
2.3. Requirement Engineering (RE)
Requirement Engineering adalah cabang rekayasa perangkat lunak yang berhubungan dengan elicitation, refinement, analisis, dan lain-lain dari kebutuhan sistem perangkat lunak. Kebutuhan yang tidak memadai, tidak lengkap, ambigu, atau tidak konsisten memiliki dampak yang signifikan terhadap kualitas perangkat lunak. Oleh karena itu, requirement engineering merupakan kegiatan utama dalam pengembangan sistem perangkat lunak (Lapouchnian, 2005).
Banyak definisi yang diungkapkan peneliti terkait RE. Menurut Nuseibeh dan Easterbrook, RE adalah proses untuk menemukan tujuan (purpose) dari sistem software dengan mengidentifikasi stakeholder dan kebutuhan-kebutuhannya dan dengan mendokumentasikannya dalam bentuk yang dapat diterima dalam analisis, komunikasi, dan implementasi berikutnya (Nuseibeh & Easterbrook, 2000).
Selain itu, menurut Zave dalam Parveen dan Imam requirement engineering adalah cabang dari software engineering yang berkaitan dengan tujuan- tujuan dunia nyata untuk, fungsi-fungsi dari, dan batasan-batasan pada sistem software. RE juga berkaitan dengan hubungan dari faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, dan evolusinya seiring dengan waktu serta pada jajaran keluarga software tersebut (Parveen & Imam, 2016).
Akan tetapi sedikit perhatian yang diberikan dalam literatur requirement egineering untuk memahami mengapa sistem tersebut dibutuhkan dan apakah spesifikasi kebutuhan telah benar-benar memenuhi kebutuhan stakeholder (Lapouchnian, 2005). Why, what, dan who dikenal sebagai tiga dimensi dalam RE.
Ketiga dimensi tersebut seharusnya dapat terjawab dalam proses RE (Lamsweerde, 2009).
Gambar 2. 1. Tiga Dimensi Requirement Engineering (Sumber:Requirements Engineering, From System Goals to
UML Models to Software Specification, 2009)
Dimensi why fokus pada alasan kontekstual terhadap usulan versi baru dari sistem yang secara eksplisit merupakan obyektif (objectives) yang harus dipenuhi berdasarkan keterbatasan-keterbatasan (limitations) dari system-as-is dan peluang- peluang eksploitasi dari system-as-is tersebut (Lamsweerde, 2009).
Dimensi what fokus pada layanan fungsional (functional services) system- to-be yang harus disediakan untuk memenuhi obyektif yang diidentifikasi pada dimensi why (Lamsweerde, 2009). Diantara layanan-layanan tersebut akan diimplementasikan oleh system-to-be, dan sebagian yang lain akan direalisasikan melalui prosedur manual device. Layangan-layanan sistem, konstrain dan asumsi dapat diidentifikasi oleh obyektif sistem/bahasa yang telah disetujui dan diformulasikan dengan istilah/bahasa yang tepat/cermat dimana semua pihak yang berkepentingan memahami (understand) untuk memvalidasi dan merealisasikannya.
Sedangkan dimensi who mengarah pada penugasan (assignment) tanggungjawab untuk mencapai obyektif, layanan, dan konstrain diantara komponen-komponen pada system-to-be, manusia, alat (devices), atau software (Lamsweerde, 2009). Penugasan tanggungjawab ini mungkin saja membutuhkan evaluasi terhadap opsi-opsi alternatif, satu tanggungjawab (tanggungjawab yang sama) dapat/memungkinkan ditugaskan pada komponen sistem yang berbeda dimana masing-masing penugasannya tersebut mempunyai pro dan kontranya masing-masing.
Van Lamsweerde menjelaskan beberapa aktivitas yang dicakup oleh requirement engineering adalah (Lapouchnian, 2005):
Domain analysis: lingkungan untuk system-to-be dipelajari. Para stakeholder yang relevan diidentifikasi dan diwawancarai. Masalah dengan sistem saat ini ditemukan dan peluang untuk perbaikan diselidiki. Tujuan untuk sistem target diidentifikasi.
Elicitation: model alternatif untuk sistem target dianalisis untuk memenuhi tujuan yang diidentifikasi. Requirement dan asumsi pada komponen model tersebut diidentifikasi. Skenario dapat dilibatkan untuk membantu dalam proses elicitation.
Negotiation and agreement: requirement dan asumsi alternatif dievaluasi; risiko dianalisis oleh para stakeholder; alternatif terbaik dipilih.
Spesification: requirement dan asumsi dirumuskan secara tepat.
Spesification analysis: spesifikasi diperiksa untuk masalah seperti ketidaklengkapan, inkonsistensi, dll. Dan untuk kelayakan.
Documentation: berbagai keputusan yang dibuat selama proses requirement engineering didokumentasikan bersama dengan alasan dan asumsi yang mendasarinya.
Evolution: persyaratan dimodifikasi untuk mengakomodasi koreksi, perubahan lingkungan, atau tujuan baru.
Pada penelitian ini, penulis fokus dalam penentuan goal yang sebenarnya ingin dicapai untuk dapat menemukan kesenjangan yang terjadi antara goal yang sebenarnya ingin dicapai dengan software requirement saat ini. Pemetaan goal pada
penelitian ini dengan menggunakan metode Goal Oriented Requirement Engineering (GORE). Kelebihan GORE yaitu menjadi salah satu cara untuk memecahkan permasalahan yang kompleks dan rumit karena telah dilengkapi juga pada sisi high-level dan dapat direpresentasikan serta dimengerti para stakeholder (Lapouchnian, 2005). Selain itu, dalam GORE, goals dapat memberikan abstraksi dasar untuk mengatasi dimensi why dalam RE (Lamsweerde, 2009).
2.4. Requirement Elicitation
2.4.1. Teknik Elicitation Artefact-Driven
Untuk mendukung proses akuisisi, ada teknik yang lebih mengandalkan jenis artefak yang spesifik. Artefak tersebut dapat lihat masing-masing secara lebih terperinci sebagai berikut (Lamsweerde, 2009):
2.4.1.1. Studi Latar Belakang (Background Study)
Jika kita tidak terbiasa dengan system-as-is, kita dapat memperoleh pengetahuan tentang sistem, organisasi di sekitarnya dan domain yang mendasarinya dengan mengumpulkan, membaca, dan mensintesis dokumentasi yang relevan:
a. Untuk mempelajari tentang organisasi, kita dapat mempelajari dokumen seperti bagan organisasi, rencana bisnis, panduan kebijakan, laporan keuangan, notulen rapat penting, deskripsi pekerjaan, formulir bisnis, dan sejenisnya
b. Untuk mempelajari tentang domain, kita dapat mempelajari buku, survei, dan artikel yang diterbitkan. Kita harus mempelajari peraturan yang diberlakukan di dalam domain, jika ada. Kita juga dapat melihat laporan tentang sistem serupa di domain itu.
c. Untuk mempelajari tentang sistem secara spesifik, kita dapat mempelajari laporan yang mendokumentasikan arus informasi, prosedur kerja, aturan bisnis, formulir yang dipertukarkan antara unit organisasi, dan sebagainya. Jika tersedia, laporan tentang cacat, keluhan, dan permintaan perubahan sangat membantu dalam menemukan masalah dengan system-as-is. Jika sistem sudah
berbasis perangkat lunak, dokumentasi perangkat lunak yang relevan seperti panduan pengguna harus dipertimbangkan juga.
Studi latar belakang terkadang disebut analisis konten. Kekuatan dari teknik ini adalah ia menyediakan informasi dasar yang akan dibutuhkan, khususnya terminologi yang digunakan, tujuan dan kebijakan yang harus dipertimbangkan, pembagian tanggung jawab di antara para stakeholder dan sebagainya. Teknik ini memungkinkan kita untuk mempersiapkan sebelum bertemu dengan para stakeholder. Oleh karena itu muncul sebagai prasyarat untuk teknik elicitation lainnya.
Masalah utama dengan studi latar belakang adalah jumlah dokumentasi yang mungkin perlu kita pertimbangkan. Ada banyak dokumen, beberapa di antaranya bisa sangat banyak. Informasi kunci harus diekstraksi dari sekumpulan rincian yang tidak relevan. Beberapa dokumen juga bisa jadi tidak akurat atau usang.
2.4.1.2. Pengumpulan Data (Data Collection)
Kami dapat melengkapi studi latar belakang dengan mengumpulkan fakta dan angka yang relevan yang juga tidak tersedia secara eksplisit dalam dokumen, seperti data pemasaran, statistik penggunaan, angka kinerja, biaya rata-rata, dan sebagainya. Kita dapat mencapai ini dengan memilih set data yang representatif dari populasi yang tersedia, atau melalui beberapa studi eksperimental.
Pengumpulan data dapat membantu untuk memperoleh persyaratan non- fungsional yang terkait dengan penggunaan, kinerja dan biaya. Harga yang harus dibayar adalah waktu yang diperlukan untuk mendapatkan data yang representatif dan cukup akurat. Untuk mencapai kesimpulan yang dapat diandalkan, kami perlu menerapkan metode sampling statistik. Data yang dikumpulkan kemudian harus ditafsirkan dengan benar jika kita ingin memperoleh requirements yang memadai darinya.
2.4.1.3. Kuesioneer
Teknik ini terdiri dari mengajukan daftar pertanyaan spesifik kepada stakeholder terpilih. Setiap pertanyaan dapat diberikan konteks yang singkat dan membutuhkan jawaban yang singkat dan terstandardisasi dari daftar jawaban yang sudah ditentukan sebelumnya. Stakeholder hanya perlu mengembalikan kuesioner yang ditandai dengan jawaban yang menurut mereka paling tepat.
Di sisi positifnya, kuesioner dapat memungkinkan kami untuk memperoleh informasi subjektif segera, dengan biaya rendah (dalam hal waktu elicitation), jarak jauh dan dari sejumlah besar orang.
Di sisi minus, informasi yang diperoleh cenderung bias pada beberapa alasan: sampel orang kepada siapa kuesioner dikirim, bagian dari orang yang bersedia untuk menanggapi, set pertanyaan dan set jawaban yang telah ditentukan.
Tidak ada interaksi langsung dengan responden dan sedikit ruang untuk menyediakan konteks yang mendasari pertanyaan. Responden mungkin tidak memahami implikasi dari jawaban mereka. Responden yang berbeda dapat menafsirkan pertanyaan atau jawaban yang sama dengan cara yang berbeda.
Sebagai akibatnya, beberapa jawaban dapat memberikan informasi yang tidak akurat, tidak memadai atau tidak konsisten.
2.4.1.4. Repertory grids dan card sorts untuk akuisisi berdasarkan konsep Teknik-teknik ini kadang-kadang digunakan untuk akuisisi pengetahuan dalam pengembangan sistem pakar. Idenya adalah untuk memperoleh informasi lebih lanjut dari konsep-konsep domain yang tersedia dengan meminta para pemangku kepentingan untuk mengkarakterisasi konsep-konsep pengkategorian tersebut.
Teknik akuisisi berdasarkan konsep ini sederhana, murah, mudah digunakan, dan terkadang efektif dalam meminta informasi yang hilang tentang konsep domain. Namun, mereka dapat menghasilkan hasil subjektif tanpa jaminan akurasi dan relevansi dengan dunia masalah. Mereka juga dapat menjadi sangat kompleks untuk mengelola konsep-konsep besar.
2.4.1.5. Storyboards dan skenario untuk penjelasan masalah dunia
Storyboard menceritakan sebuah kisah tentang system-as-is atau system- to-be dalam urutan snapshot. Setiap snapshot dapat diwakili dalam bentuk sugestif untuk cepat, pemahaman yang mudah, misalnya kalimat, sketsa, gambar, slide, tangkapan layar, dan sebagainya. Storyboard bisa pasif atau aktif:
a. Dalam mode pasif, stakeholder diberi tahu cerita. Storyboard digunakan untuk penjelasan atau validasi.
b. Dalam mode aktif, stakeholder berkontribusi pada cerita. Storyboard digunakan untuk eksplorasi bersama.
Storyboard dapat dibuat lebih terstruktur dengan membuat aspek-aspek berikut eksplisit di samping cerita:
a. Siapa pemainnya
b. Apa yang terjadi pada mereka
c. Bagaimana itu terjadi melalui episode tertentu d. Mengapa ini terjadi
e. Bagaimana jika peristiwa seperti ini terjadi f. Apa yang bisa salah sebagai konsekuensinya
Skenario menggambarkan urutan khas interaksi antara komponen- komponen sistem yang memenuhi tujuan implisit. Jumlah bentuk terstruktur dari storyboard meliputi dimensi who, what, dan how.
Skenario banyak digunakan di seluruh siklus hidup perangkat lunak.
Dalam requirements engineering ada dua kegunaan utama:
a. Menjelaskan bagaimana system-as-is berjalan sering dibuat lebih sederhana melalui contoh konkret dari rangkaian interaksi kehidupan nyata.
b. Menjelajahi bagaimana system-to-be harus dijalankan sering dibuat lebih mudah melalui contoh konkret dari urutan interaksi hipotetis. Contoh-contoh tersebut memberikan dasar yang baik untuk elicitation lebih lanjut:
1. Kami dapat menanyakan pertanyaan spesifik tentang mereka
2. Kami mungkin secara khusus mendapatkan tujuan yang mendasarinya 3. Kami dapat menggeneralisasikannya ke dalam model perilaku sistem yang
diinginkan
2.4.1.6. Mock-up dan prototipe untuk feedback awal
Prototipe perangkat lunak adalah implementasi cepat dari beberapa aspek system-to-be. Tujuannya adalah untuk mendapatkan feedback awal dari para stakeholder dan segera mendorong lebih lanjut. Fokusnya secara umum adalah pada requirement yang tidak jelas, sulit dirumuskan atau sulit dimengerti.
Prototyping sebagai kendaraan elicitation memiliki keunggulan:
bereksperimen dengan beberapa rasa konkret dari apa yang mungkin terlihat seperti sistem membantu kita memahami implikasi dari beberapa requirement, mengklarifikasi yang lain, mengubah requirement yang tidak memadai menjadi yang memadai, dan memperoleh requirement yang tersembunyi di pikiran stakeholder. Kita dapat menggunakan prototipe untuk tujuan lain selain elicitation dan validasi, seperti pelatihan pengguna sebelum produk akhir tersedia dan simulasi komponen stubb selama pengujian integrasi.
Prototyping memiliki keterbatasan juga. Prototipe tidak mencakup semua aspek dari perangkat lunak yang akan ada. Paling sering meninggalkan beberapa fungsi samping dan membatasi diri pada beberapa requirement non-fungsional (seperti useability requirement). Requirement tentang kinerja, biaya, keandalan, real-time, kendala atau interoperabilitas dengan perangkat lunak lain diabaikan.
Karena itu, prototipe dapat menyesatkan dan menetapkan harapan stakeholder terlalu tinggi. Selain itu, prototipe sekali-sekali sering dibangun melalui sarana
‘cepat dan kotor’; kode yang dihasilkan umumnya tidak efisien dan tidak terstruktur dengan baik. Mengubah prototipe sekali-sekali menjadi yang evolusioner karena itu mungkin cukup sulit. Sebaliknya, prototipe evolusi mahal dan mungkin perlu waktu terlalu lama untuk mengembangkannya dengan memperhatikan perhatian utama untuk mendapatkan persyaratan yang memadai dengan segera. Dalam semua kasus, mungkin ada ketidakkonsistenan antara requirement yang diperbarui dan kode prototipe; Kepercayaan pada hasil yang diperoleh melalui prototyping akan menurun dalam hal ketidaksesuaian kode-kebutuhan.
2.4.1.7. Knowledge Reuse
Sistem jarang dipahami dari awal. Requirement engineer dan stakeholder cenderung menggunakan kembali pengetahuan dari pengalaman masa lalu dengan sistem terkait. Pengetahuan tersebut dapat merujuk pada organisasi tuan rumah, ke domain di mana dunia masalah berakar, untuk jenis masalah yang dialami dengan sistem serupa, dan jenis kebutuhan yang perlu dipertimbangkan untuk mengatasi masalah tersebut.
Di sisi positifnya, upaya elicitation dapat sangat berkurang ketika sistem target cukup ‘dekat’ dengan sistem yang dikenal digunakan kembali, di mana
‘dekat’ mengacu pada beberapa jarak konseptual, disengaja atau perilaku. Argumen tentang manfaat pola desain berlaku sama di sini. Secara khusus, fragmen pengetahuan yang digunakan kembali dapat mengkodifikasikan RE berkualitas tinggi yang dilakukan di masa lalu. Hasilnya karena itu cenderung memiliki kualitas yang lebih baik dan diperoleh melalui proses yang lebih dipandu. Elicitation berbasis reuse juga mendorong abstraksi dan terminologi umum untuk pola berulang organisasi, konsep, tujuan, tugas, perilaku, dan masalah.
Pada sisi negatifnya, terkadang sulit untuk mengidentifikasi abstraksi yang tepat, menyusunnya, dan menentukannya secara tepat untuk dapat digunakan kembali secara signifikan. Mungkin juga sulit untuk menentukan apakah fragmen kandidat layak digunakan kembali; jarak kemiripan tidak mudah ditentukan dan diukur. Komposisi fragmen dari beberapa domain dan integrasi mereka dari domain yang kompleks. Terlalu banyak waktu yang mungkin dihabiskan untuk memvalidasi fitur yang tidak pantas dan adaptasi yang rumit. Tidak kurang pentingnya, skalabilitas teknik berbasis reuse terikat oleh ketersediaan dukunan alat yang efektif.
2.4.2. Teknik Elicitation Stakeholder-Driven
Teknik dalam bagian ini lebih mengandalkan jenis interaksi khusus dengan para stakeholder. Untuk mendapatkan informasi yang memadai dan relevan tentang organisasi, domain dan masalah dengan system-as-is, interaksi langsung dengan
pemilik informasi tersebut terbukti sangat berharga. Teknik tersebut diulas secara rinci sebagai berikut (Lamsweerde, 2009):
2.4.2.1. Wawancara
Wawancara umumnya dianggap sebagai teknik utama untuk elicitation persyaratan.
Dua jenis wawancara secara tradisional dibedakan:
a. Dalam wawancara terstruktur, kami telah menyiapkan serangkaian pertanyaan yang telah ditetapkan. Set ini disusun sesuai dengan tujuan spesifik yang terkait dengan wawancara. Beberapa pertanyaan mungkin terbuka, yang lain mungkin meminta pilihan di antara beberapa jawaban yang disediakan.
b. Dalam wawancara tidak terstruktur, tidak ada seperangkat pertanyaan yang ditetapkan sebelumnya. Wawancara terdiri dari diskusi bebas dan informal dengan para stakeholder tentang sistem apa adanya, bagaimana cara kerjanya, apa masalah yang dirasakan oleh orang yang diwawancara, dan bagaimana dia ingin masalah seperti itu ditangani dalam sistem baru .
Sebuah wawancara terstruktur mendukung diskusi yang lebih fokus dan menghindari bertele-tele antara isu-isu yang tidak terkait. Wawancara yang tidak terstruktur memungkinkan untuk eksplorasi masalah yang mungkin terlewatkan.
Oleh karena itu, wawancara yang efektif harus mencampur dua mode, dimulai dengan bagian terstruktur, diikuti oleh yang tidak terstruktur.
Di sisi positifnya, mereka mendukung elicitation informasi yang berpotensi penting yang tidak dapat diperoleh melalui latar belakang studi- biasanya, deskripsi tentang bagaimana hal itu benar-benar terjadi dalam praktek, keluhan pribadi, saran untuk perbaikan, persepsi dan perasaan dan sejenisnya.
Wawancara juga memungkinkan pencarian langsung, fleksibel, dan terus-menerus untuk informasi yang relevan melalui pertanyaan-pertanyaan baru yang dipicu bentuk jawaban untuk jawaban sebelumnya
Pada sisi negatifnya, kadang-kadang sulit untuk membandingkan apa yang dikatakan oleh orang yang diwawancarai yang berbeda dan mengintegrasikan masukan mereka ke dalam suatu pengetahuan yang koheren. Informasi subyektif
harus ditafsirkan, dan batas antara informasi subjektif dan obyektif belum tentu jelas untuk ditetapkan. Tidak kurang pentingnya, efektivitas wawancara cukup tergantung pada sikap pewawancara dan kesesuaian pertanyaan.
2.4.2.2. Observasi dan Studi Etnografi
Teknik ini didasarkan pada premis bahwa memahami tugas dengan mengamatinya ketika dilakukan mungkin lebih mudah daripada membiarkan seseorang menjelaskannya kepada kita. Intinya khususnya berlaku untuk proses bisnis atau prosedur kerja yang melibatkan banyak orang yang mungkin tidak menyadari apa yang dilakukan orang lain, atau tidak memiliki waktu untuk menjelaskannya.
Observasi tugas bisa pasif atau aktif:
a. Dalam kasus observasi pasif, requirement engineer tidak mengganggu orang- orang yang terlibat dalam tugas. Dia hanya menonton dari luar dan merekam apa yang sedang terjadi melalui catatan, kamera video, dll. Seperti dalam pengumpulan data, rekaman ini harus disortir dan diinterpretasikan dengan benar 1. Analisis protokol adalah kasus khusus observasi pasif di mana subjek
melakukan tugas dan secara bersamaan menjelaskannya
2. Studi etnografi adalah kasus khusus observasi pasif di mana requirement engineer mencoba, selama periode yang panjang, untuk menemukan sifat- sifat yang muncul dari kelompok sosial yang terlibat dalam proses yang diamati. Pengamatan tidak hanya mengacu pada kinerja tugas tetapi juga untuk sikap peserta tugas, reaksi mereka dalam situasi tertentu, gerakan mereka, percakapan, lelucon, dll.
b. Dalam kasus observasi aktif, requirement engineer terlibat dalam tugas, kadang sampai pada titik di mana dia menjadi anggota tim kerja.
Kekuatan utama dari teknik observasi adalah kemampuan mereka untuk mengungkapkan pengetahuan tacit yang tidak akan muncul melalui teknik lainnya.
Ada pengalaman terbatas untuk memperkuat argumen ini, terutama di domain kontrol lalu lintas udara. Pengamatan berbasis etnografi diterapkan di sana untuk menganalisis bagaimana pengendali menangani strip kertas yang mewakili rencana
penerbangan. Pengamatan mengungkapkan model mental yang implisit dari lalu lintas udara yang diperlukan oleh sistem versi otomatis untuk melestarikan. Secara lebih umum, akar-akar antropologi dari teknik etnografi membuat mereka sangat cocok untuk sistem organisasi yang rumit di mana ciri-ciri khusus-budaya perlu ditemukan dan diperhitungkan. Kekuatan nyata lainnya dari teknik-teknik semacam itu adalah kontekstualisasi mereka terhadap informasi yang diperoleh.
Namun, teknik-teknik berbasis observasi memiliki keterbatasan yang serius. Pertama-tama, mereka mahal untuk digunakan. Untuk mencapai kesimpulan yang berarti, observasi harus dilakukan selama periode signifikan, pada waktu yang berbeda dan di bawah kondisi beban kerja yang berbeda. Meski begitu, kesimpulan bisa tidak akurat, karena orang cenderung berperilaku berbeda ketika mereka diamati. Pengamat harus diterima oleh sekelompok orang yang diamati, yang mungkin sulit dan membutuhkan waktu ekstra. Menganalisis catatan untuk menyimpulkan fitur yang muncul mungkin juga cukup sulit. Menunjuk fitur yang relevan dari sekumpulan detail yang tidak relevan mungkin juga jauh dari sepele dan tunduk pada kesalahan interpretasi. Tidak kurang pentingnya, teknik berbasis observasi pada dasarnya berorientasi pada pemahaman tentang bagaimana system- as-is berfungsi. Mereka lebih lemah dalam menunjukkan masalah dan peluang untuk ditangani oleh sistem yang akan ada.
2.4.2.3. Sesi Kelompok
Teknik ini didasarkan pada premis bahwa ada lebih banyak ruang untuk persepsi, penilaian, dan penemuan dalam sekelompok orang, berkat keragaman anggotanya dan interaksi di antara mereka. Elicitaton berlangsung selama serangkaian lokakarya kelompok, masing-masing biasanya memakan waktu beberapa hari, dipisahkan oleh kegiatan tindak lanjut individu.
Sesi kelompok dapat terstruktur dan tidak terstruktur:
a. Dalam sesi grup terstruktur, peran masing-masing peserta didefinisikan dengan jelas, misalnya pemimpin, moderator, reporter, pengguna, manajer, atau pengembang. Setiap peserta harus berkontribusi pada elaborasi requirement bersama sesuai dengan peran dan sudut pandang spesifiknya. Elaborasi tersebut
umumnya difokuskan pada fitur-fitur tingkat tinggi dari produk target. Sinergi kelompok diharapkan muncul di beberapa titik.
b. Dalam sesi kelompok yang tidak terstruktur, juga disebut sesi brainstorming, peran masing-masing peserta kurang jelas ditetapkan:
1. Pada tahap pertama, setiap peserta harus secara spontan menghasilkan sebanyak mungkin ide untuk memperbaiki tugas atau mengatasi masalah yang dikenal. Pembentukan gagasan harus bebas dari prasangka, sensor atau kritik oleh orang lain.
2. Pada tahap kedua, para peserta perlu bersama-sama untuk mengevaluasi setiap ide sehubungan dengan kriteria yang disepakati seperti efektivitas, kelayakan dan biaya, untuk memangkas beberapa ide dan memprioritaskan yang lain sesuai dengan kriteria ini.
Sesi grup memiliki beberapa manfaat. Gaya interaksi mereka yang kurang formal dapat mengungkap aspek sistem sebagaimana adanya atau masalah tentang sistem yang akan tetap tersembunyi di bawah interaksi formal selama wawancara.
Sinergi dalam kelompok-kelompok terstruktur dapat menghasilkan penyelesaian sudut pandang yang lebih baik dan jauh lebih mudah. Kebebasan berpikir dalam sesi brainstorming dapat menghasilkan cara yang lebih inventif untuk mengatasi masalah yang dikenal. Berbagai macam ide juga dapat dikumpulkan dengan cepat.
Teknik-teknik berbasis kelompok juga memiliki kelemahan. Komposisi kelompok sangat penting. Aktor kunci perlu dilibatkan. Orang-orang seperti itu pada umumnya sangat sibuk dan mungkin tidak dapat menghabiskan waktu yang signifikan dalam lokakarya yang berurutan. Pemimpin harus memiliki profil yang tinggi, baik secara teknis maupun dalam hal keterampilan komunikasi. Ada risiko yang terkait dengan dinamika kelompok yang dapat mengakibatkan bias, informasi yang tidak memadai atau tidak lengkap yang ditimbulkan - khususnya, dominasi oleh beberapa individu dan kesulitan bagi orang lain dalam berkomunikasi. Kurang fokus dan struktur dalam sesi dapat mengakibatkan kurangnya hasil nyata dan buang-buang waktu. Tidak kurang pentingnya, masalah teknis lebih mungkin ditangani hanya secara dangkal mengingat waktu yang dialokasikan dan tingkat rata-rata keahlian kelompok dalam isu-isu tersebut.
2.5. Goal Oriented Requirement Engineering (GORE) 2.5.1. Definisi GORE
Menurut teori Lapouchnian pada buku Goal-Oriented Requirements Engineering: An Overview of the Current Research, GORE merupakan pendekatan di dalam RE berorientasi Goal dan Actor yang akhir-akhir ini berkembang cukup pesat. Salah satu alasan kemunculan GORE ini adalah dirasakannya kekurangcukupan dalam pendekatan analisis tradisional ketika berkenaan dengan sistem software yang lebih kompleks dan agar dapat lebih dipahami oleh stakeholder (Shofi & Budiardjo, 2011).
Sementara menurut teori Adikara F., Sitohang B., dan Hendradjaya B., GORE merupakan rekayasa kebutuhan yang merasionalisasikan berbagai kebutuhan yang diperlukan oleh sebuah sistem yang akan dibuat berdasarkan dari tujuan-tujuan yang dirumuskan, sehingga diharapkan kebutuhan yang didapatkan bukan hanya berdasarkan data dan proses bisnis manual (Puteri, Oktafani Z., Muqtadiroh, Feby Artwodini., Nisafani, 2014).
Dari kedua pendapat di atas mengenai definisi GORE dapat diambil kesimpulan bahwa GORE merupakan pendekatan rekayasa kebutuhan berorientasi Goal dan Actor yang merasionalisasikan berbagai kebutuhan yang diperlukan oleh sebuah sistem yang akan dibuat berdasarkan dari tujuan-tujuan yang dirumuskan agar dapat lebih dipahami oleh stakeholder.
2.5.2. Konsep Goal, Requirement, dan Agent
Goal merupakan salah satu komponen penting dalam proses Requirement Engineering (RE). Terdapat beberapa definisi goal dalam literatur RE saat ini. Van Lamsweerde mendefinisikan goal sebagai tujuan bahwa sistem harus dicapai melalui kerjasama antara agent dalam system-to-be dan lingkungannya. Anton menyatakan bahwa goal adalah tujuan tingkat tinggi yang dimiliki organisasi, bisnis, atau sistem dan dengan goal tersebut mereka memperoleh alasan mengapa sistem tersebut dibutuhkan dan menjadi pemandu sebuah keputusan di berbagai tingkat dalam perusahaan (Lapouchnian, 2005).
Requirement adalah goal dibawah tanggung jawab suatu agent tunggal dari system-to be. Requirement sesuai dengan apa yang disebut sebelum software requirement. Goal dapat sesuai software requirement atau tidak, tergantung pada sistem agent yang terlibat dalam memenuhi goal tersebut (Lamsweerde, 2009).
Agent adalah komponen sistem aktif yang memainkan peran spesifik dalam goal satisfaction. Untuk memenuhi peran tersebut, agent perlu membatasi perilakunya dengan kontrol yang memadai terhadap item sistem. Agent sistem menentukan ruang lingkup sistem. Goal satisfaction mungkin melibatkan berbagai agent sistem (Lamsweerde, 2009):
a. Human agent yang memainkan peran spesifik, seperti unit organisasi, operator atau pengguna akhir.
b. Device seperti sensor, aktuator, instrumen pengukuran atau media komunikasi.
c. Komponen perangkat lunak yang ada (existing software components) seperti peninggalan (legacy), off-the-shelf atau komponen asing dalam sistem terbuka.
d. Komponen perangkat lunak baru (new software components) yang membentuk perangkat lunak seperti pengendali perangkat lunak, manajer informasi atau web service.
Pada berbagai tingkat abstraksi (level of abstraction), yaitu pada higher levels dan lower levels. Sebuah goal pada suatu level dapat disempurnakan (refine) ke subgoal pada level selanjutnya (Lamsweerde, 2009).
a. Higher-level goal merupakan goal yang masih kasar (coarser-grained goal) yang menyatakan tujuan strategis yang berkaitan dengan bisnis atau organisasi, misalnya:
Kapasitas transportasi sistem akan meningkat 50%.
Sistem perpustakaan harus menyediakan akses efektif ke keadaan seni.
Pertemuan akan dijadwalkan untuk memaksimalkan kehadiran peserta yang diundang.
b. Lower-level goal merupakan goal yang lebih halus (finer-grained goal) yang menyatakan tujuan teknis terkait dengan pilihan desain sistem, misalnya:
Perintah akselerasi harus dikirim ke setiap kereta setiap 3 detik.
Pengingat untuk salinan buku yang tidak dikembalikan akan diterbitkan setiap minggu setelah berakhirnya masa pinjaman.
Ketika tidak ada tanggal yang dapat ditemukan di luar semua tanggal yang dikecualikan yang dikembalikan oleh peserta, kendala harus dilemahkan dengan menjatuhkan batasan dari peserta berprioritas rendah.
Perbedaan tingkat goal dan perincian menunjukkan mekanisme penataan spesifikasi berdasarkan contribution link di antara goal. Goal yang masih kasar dapat disempurnakan menjadi goal yang lebih halus yang berkontribusi padanya atau, sebaliknya, goal yang lebih halus dapat diabstraksikan ke arah goal yang lebih kasar yang mereka kontribusikan. Misalnya, lower-level goal:
Perintah akselerasi harus dikirim ke setiap kereta setiap 3 detik.
diharapkan untuk berkontribusi pada higher-level goal:
Sistem harus menjamin transportasi yang aman bagi semua penumpang
melalui higher-level goal menengah di sepanjang rantai kontribusi.
2.5.3. Metode GORE
Menurut Imam M. Shofi dan Eko K. Budiardjo, beberapa metode/teknik yang telah dikembangkan dalam GORE: Deriving Tabular Event-Based Specifications from goal oriented requirement model (DTEBS), GBRAM (Goal- Based Requirements Analysis Method), AGORA (Attributed Goal-Oriented Requirements Analysis Method), Visual Variability Analysis for goal models (VVA), Goal-Oriented Idea Generation Method (GOIG), Deriving Operational Software Specifications (DOSS), Agent-Based Tactics for goal-oriented requirements elaboration (A-BT), dan goal oriented requirement elicitation based on General System Thinking Heuristics (GSTH). Selain itu ada juga: Non- Functional Requirements Framework (NFR Framework), i*/Tropos, Knowledge Acquisition in autOmated Specification atau Keep All Objects Satisfied (KAOS), maupun Goals-Skills-Preferences Framework (GSP Framework). Terdapat juga metode: i*, ConGolog, Albert language, F3. Sedangkan Van Lamsweerd menjelaskan bahwa gabungan NFR, i*, dan Tropos dikembangkan lagi menjadi metode GRL (Shofi & Budiardjo, 2011).
