Skripsi Akbar Riski

B. Prosedur Pelayanan Akademik 1. Dosen dan Mahasiswa mendapatkan informasi mengenai prosedur-prosedur pelayanan akademik prodi SI dari bagian Program Studi Sistem Informasi secara langsung. 2. Dosen mempelajari prosedur pelayanan akademik prodi SI. 3. Mahasiswa mempelajari prosedur pelayanan akademik prodi SI. 4. Mahasiswa mengetahui informasi mengenai prosedur pelayanan akademik prodi SI dengan bertanya kepada dosen. 5. Mahasiswa memberi pengetahuan atau informasi mengenai prosedur pelayanan akademik prodi SI kepada mahasiswa lainnya. C. Diskusi Antar Mahasiswa atau Dosen 1. Bahan diskusi atau pertanyaan ditanyakan oleh dosen secara langsung kepada mahasiswa. 2. Bahan diskusi dan pertanyaan ditanyakan oleh mahasiswa secara langsung kepada dosen ataupun mahasiswa lain. 3. Mahasiswa mempelajari pertanyaan secara langsung dari dosen atau mahasiswa lain. 117

4. Dosen mempelajari pertanyaan secara langsung dari mahasiswa. 5. Mahasiswa menjawab secara langsung kepada dosen yang bertanya. 6. Mahasiswa menjawab secara langsung kepada mahasiswa lain yang bertanya. 7. Dosen menjawab secara langsung kepada mahasiswa yang bertanya. 8. Dosen bertanya secara tidak langsung kepada mahasiswa melalui media sosial. 9. Mahasiswa bertanya secara tidak langsung kepada dosen ataupun mahasiswa lain melalui media sosial. 10. Dosen mempelajari pertanyaan secara tidak langsung (dari media sosial) dari mahasiswa. 11. Mahasiswa mempelajari pertanyaan secara tidak langsung (dari media sosial) dari dosen atau mahasiswa lain. 12. Dosen menjawab secara tidak langsung melalui media sosial kepada mahasiswa yang bertanya. 13. Mahasiswa menjawab secara tidak langsung melalui media sosial kepada dosen atau mahasiswa lain yang bertanya. 118

14. Dosen mendapatkan jawaban secara tidak langsung melalui media sosial dari mahasiswa yang menjawab. 15. Mahasiswa mendapatkan jawaban secara tidak langsung melalui media sosial dari dosen ataupun dari mahasiswa lain yang menjawab. 4.1.3 Identifikasi Masalah Berdasarkan hasil observasi dan wawancara dengan mahasiswa, dosen, dan prodi sistem informasi UIN Syarif Hidayatullah Jakarta, dapat diidentifikasi beberapa masalah dalam knowledge management yang saat ini berjalan, yaitu: a. Mahasiswa diberikan materi kuliah oleh dosen sebagai pedoman dalam belajar mata kuliah tertentu. Materi kuliah tersebut diberikan dalam beberapa bentuk yang berbeda-beda setiap dosennya, yaitu modul-modul e-book, file presentasi, video, dan sebagainya. Namun, tidak semua dosen memberikan materi kuliahnya kepada mahasiswa. Sehingga mahasiswa harus mencari materi yang sesuai secara mandiri, namun mahasiswa tidak tau materi mana yang memiliki kualitas yang baik dan sesuai. b. Mahasiswa biasanya diajar oleh dosen yang berbeda pada mata kuliah yang sama, hal ini menyebabkan mahasiswa yang berebeda dosen tidak memiliki pengetahuan yang sama 119

mengenai materi kuliah yang didapat, sehingga terjadi tidak meratanya penyebaran pengetahuan. c. Materi kuliah yang pernah dijadikan bahan ajar pada tahun- tahun sebelumnya tidak tersimpan dan terkelola sehingga tidak dapat diakses kembali. d. Untuk materi kuliah yang diperoleh mahasiswa dari internet, masih perlu diverifikasi kerelevanan materi dengan mata kuliahnya serta dengan pedoman yang dimiliki oleh dosen. e. Materi kuliah yang diperoleh mahasiswa dari buku fisik yang dipinjam dari perpustakaan, memiliki batas peminjaman sampai batas waktu tertentu, sehingga mahasiswa tidak dapat selalu menjadikan buku fisik tersebut sebagai pedoman belajarnya. f. Dalam berbagi materi kuliah dalam bentuk buku, mahasiswa harus meminjam kepada mahasiswa lain yang memiliki buku tersebut. Proses meminjam tergolong membutuhkan waktu dan tenaga yang tidak sedikit, dikarenakan antar mahasiswa tersebut harus saling menghubungi, mengadakan janji terkait kapan buku tersebut akan dipinjamkan, dan harus saling bertemu. g. Untuk materi berbentuk digital, mahasiswa biasanya melakukan sharing dengan menggunakan flashdisk, sehingga terdapat kerentanan dalam keamanan data, karena pertukaran flashdisk tersebut dapat memicu terjadinya penyebaran virus-virus 120

komputer, karena tidak ada jaminan setiap komputer yang dihubungkan dengan flashdisk bebas dari virus, ataupun virus dapat tersimpan pada flashdisk. h. Sedangkan sharing materi digital menggunakan pesan instan seringkali tidak terkelola dengan baik. Hal ini dikarenakan mahasiswa harus mencari materi-materi perkuliahan diantara pesan-pesan instan lainnya dan penyebarannya pun terbatas pada anggota grup pesan instan tersebut. Selain itu, materi kuliah yang dishare tidak dikategorikan berdasarkan mata kuliah yang terkait, sehingga akan menyulitkan dan membutuhkan waktu untuk mencari suatu materi kuliah yang telah dishare. Terlebih lagi, akan sangat sulit mencari materi perkuliahan yang telah lama dishare, bahkan pada beberapa platform pesan instan hanya dapat menyimpan suatu file dalam rentang waktu 30 hari. i. Untuk sharing materi kuliah dengan menggunakan email kurang diminati mahasiswa karena harus menyertakan seluruh alamat email mahasiswa agar email tersebut dapat terkirim ke semua mahasiswa yang dituju. j. Sedangkan untuk penyimpanan materi kuliah menggunakan cloud storage sangat terbatas pada jumlah file yang dapat disimpan, karena mayoritas cloud storage memberikan batas 121

memori yang dapat digunakan secara gratis, sehingga mengharuskan user nya untuk membayar agar dapat menambah batas memori pada cloud storage tersebut. k. Dalam mencari solusi dari masalah-masalah terkait kegiatan perkuliahan, mahasiswa harus bertanya kepada mahasiswa lain yang sudah pernah mengalaminya dan mengetahui solusinya, sehingga mahasiswa yang tidak memiliki kenalan yang pernah mengalami masalah tersebut akan kesulitan. l. Untuk mendapatkan informasi mengenai prosedur pelayanan program studi, mahasiswa harus bertanya kepada mahasiswa lain yang mengetahui prosedur tersebut, namun tidak semua mahasiswa memiliki kenalan yang mengetahui prosedur pelayanan program studi, sehingga mahasiswa harus bertanya langsung ke pihak program studi. 4.1.4 Analisis Sistem Usulan Berdasarkan identifikasi masalah yang telah peneliti jabarkan sebelumnya, maka peneliti mengusulkan knowledge management system sharing materi kuliah, forum diskusi, dan prosedur pelayanan akademik sistem informasi UIN Jakarta yang dapat membantu mahasiswa dan dosen dalam menemukan atau mendapatkan materi kuliah dan prosedur pelayanan akademik prodi, menyimpan, dan mendistribusikannya, serta forum diskusi yang dapat menjadi wadah bagi mahasiswa maupun dosen 122

dalam mencari solusi atas setiap masalah-masalah yang terjadi terkait kegiatan-kegiatan perkuliahan. KMS ini dikembangkan pada platform mobile Android. Adapun sistem usulan yang diusulkan peneliti dapat dijelaskan dengan siklus knowledge management Zack dan Meyer, yaitu: 1. Akuisisi Data dan Informasi (Acquire) Pada tahap ini, materi kuliah dapat berasal dari dosen maupun mahasiswa, dan materi kuliah ini dapat diunggah maupun diunduh oleh mahasiswa maupun dosen. Materi kuliah yang diunggah akan dapat dikendalikan kualitasnya, dikarenakan setiap materi kuliah yang diunggah akan dilakukan approval atau validasi terlebih dahulu oleh admin ataupun Kaprodi SI, sehingga materi kuliah yang masuk sudah sesuai dan relevan dengan mata kuliah terkait. Jika terdapat materi kuliah yang tidak sesuai, maka admin ataupun Kaprodi SI dapat menolaknya ataupun menghapusnya jika materi tersebut telah diapprove sebelumnya. Materi kuliah dapat berasal dari beberapa file digital, yaitu e-book, e- journal, file berekstensi .ppt, .docx, .pdf, dan ekstensi-ekstensi lainnya. Dalam hal prosedur pelayanan akademik program studi SI, admin maupun Kaprodi SI dapat menginput prosedur-prosedur berbagai pelayanan akademik prodi pada sistem, sehingga dapat menjadi pusat pengetahuan bagi mahasiswa maupun dosen yang membutuhkan prosedur-prosedur pelayanan akademik. Kaprodi SI dan admin pun dapat 123

melakukan update ataupun delete terhadap prosedur-prosedur pelayanan akademik secara real-time apabila terdapat perubahan pada prosedur pelayanan akademik prodi. Mahasiswa atau dosen dapat mengajukan bahan diskusi pada forum yang tersedia dalam sistem, sehingga mahasiswa maupun dosen dapat saling memberi pendapat dan solusi dalam memecahkan permasalahan dalam kegiatan-kegiatan perkuliahan, serta mahasiswa dan dosen yang mengalami masalah yang sama dapat menjadikan diskusi tersebut sebagai acuan. 2. Penyempurnaan (Refine) Tahap penyempurnaan pengetahuan pada KMS ini dilakukan dengan mengelompokkan materi kuliah sesuai dengan mata kuliah yang menggunakan referensi dari kurikulum program studi informasi UIN Jakarta, dan pengelompokan mata kuliah berdasarkan semester terkait, serta materi kuliah tersebut diurutkan berdasarkan waktu upload. Materi kuliah tersebut dapat diedit dan dihapus oleh admin, Kaprodi SI, maupun oleh user yang mengupload materi kuliah tersebut. Pada prosedur pelayanan akademik, prosedur-prosedur tersebut juga dikelompokkan berdasarkan judul besar dari pelayanan tersebut. Prosedur-prosedur tersebut dapat diinput oleh admin dan Kaprodi SI. Namun mahasiswa dan dosen juga dapat melakukan request prosedur kepada pihak prodi dengan melalui proses approval oleh admin atau 124

Kaprodi SI terlebih dahulu. Kaprodi SI dan admin dapat melakukan edit dan delete pada prosedur-prosedur yang telah diposting. Lalu, pada forum diskusi, diskusi-diskusi yang diajukan dikelompokkan berdasarkan kategori-kategori tertentu yang ditentukan oleh user yang mengajukan diskusi. Kaprodi SI dan admin dapat melakukan edit dan delete pada diskusi-diskusi yang tidak sesuai. Pada tahap penyempurnaan ini juga berlangsung beberapa langkah-langkah dari model knowledge conversion Nonaka dan Takeuchi, yaitu: 1. Socialization. Pada KMS ini, proses konversi pengetahuan tacit menjadi tacit ada pada forum diskusi, dimana mahasiswa maupun dosen dapat bertukar pendapat dan memberikan pertanyaan maupun solusi terkait topik-topik yang diajukan seputar permasalahan kegiatan-kegiatan perkuliahan. Setiap diskusi yang dibuat oleh mahasiswa ataupun dosen, harus melewati approval dari admin maupun Kaprodi SI, sehingga forum diskusi ini dalam pengawasan penuh admin dan Kaprodi SI. Admin dan Kaprodi SI dapat menghapus diskusi yang tidak relevan dengan topik kegiatan-kegiatan perkuliahan di prodi sistem informasi. 2. Externalization. 125

Tahap konversi dari tacit menjadi explicit pada KMS ini terjadi pada penginputan prosedur-prosedur pelayanan akademik prodi SI yang dilakukan oleh admin dan Kaprodi SI. Sehingga pengetahuan yang diinput mengenai prosedur pelayanan akademik prodi SI itu dapat menjadi acuan bagi mahasiswa atau dosen yang ingin mengurus pelayanan akademik tertentu. Selain itu, proses konversi ini juga terjadi pada menu sharing materi perkuliahan jika materi tersebut dibuat oleh mahasiswa atau dosen dan diposting ke dalam KMS. Selain itu, mahasiswa dan dosen juga dapat melakukan request prosedur pelayanan prodi, yang nantinya dapat dibuat oleh pihak prodi. Lalu, konversi ini juga terjadi pada forum diskusi, dikarenakan apabila diskusi tersebut berhasil menemukan jawaban yang tepat, maka dapat menjadi acuan bagi mahasiswa atau dosen yang mengalami permasalahan yang sama. Setiap mahasiswa dan dosen dapat melakukan voting komentar diskusi terbaik, sehingga setiap diskusi memiliki jawaban yang paling relevan dan dapat menjadi knowledge baru yang disebut sebagai knowledge diskusi, yang nantinya setiap diskusi tersebut akan ditampilkan berdasarkan kategorinya dengan jawaban terbaiknya, sehingga menjadi knowledge baru yang telah disempurnakan. 126

3. Combination. Tahap ini terjadi di dalam dan di luar lingkungan KMS. Pada lingkungan dalam KMS, tahap ini terjadi pada pengelompokkan materi kuliah berdasarkan mata kuliah, lalu materi kuliah tersebut juga dapat divote sebagai materi kuliah yang paling baik oleh mahasiswa dan dosen, sehingga materi kuliah yang memiliki jumlah vote terbanyak akan ditampilkan paling awal, pengelompokkan prosedur pelayanan akademik berdasarkan jenis layanan dan pengelompokkan forum diskusi berdasarkan kategori diskusi. Sedangkan pada lingkungan luar KMS, tahap ini terjadi jika materi perkuliahan yang didapat dari KMS, atau prosedur pelayanan akademik, atau hasil dari suatu diskusi dapat menjadi acuan bagi mahasiswa pada pengerjaan tugas kuliah, laporan praktik kerja lapangan, dan tugas akhir yang mengharuskan mahasiswa merujuk dari referensi tertentu, seperti jurnal, buku-buku, dan sebagainya serta dalam menyelesaikan permasalahan-permasalahan kegiatan perkuliahan. 4. Internalization. Pada konversi ini, mahasiswa mempelajari materi kuliah dan pengetahuan mengenai prosedur pelayanan akademik ataupun pengetahuan dari forum diskusi yang diperoleh dari sistem. Hal ini dapat memperkaya pengetahuan, wawasan, dan pengalaman mahasiswa. 127

Kemudian, mahasiswa dapat mengaktualisasikan pengetahuan tentang konsep dan keterampilan mereka pada masa depan. 3. Penyimpanan/Pengambilan (Store/Retrieve) Pada KMS ini, materi perkuliahan, prosedur pelayanan akademik prodi SI, serta forum diskusi yang telah diposting akan disimpan pada database yang menggunakan Google Firebase. Khusus untuk materi perkuliahan, mahasiswa dapat menyimpan materi perkuliahan ke perangkat pribadi mereka dengan mengunduhnya melalui fitur yang telah disediakan pada menu materi kuliah pada KMS ini. 4. Distribusi (Distribute) KMS ini dapat menjadi wadah pendistribusian pengetahuan pada materi perkuliahan, prosedur pelayanan akademik, maupun forum diskusi kepada seluruh mahasiswa dan dosen sistem informasi UIN Jakarta yang memiliki akses. Selain itu, pendistribusian ini tidak dibatasi waktu dan tempat, sehingga mahasiswa dan dosen dapat memperoleh pengetahuan-pengetahuan tersebut di mana saja dan kapan saja. Bentuk materi yang dibagikan dalam KMS ini juga cukup beragam, seperti materi tekstual dengan ekstensi .docx, .pptx, .pdf, dan lain-lain ataupun dalam bentuk gambar maupun video. 128

5. Presentasi (Present) Pada tahap ini, pengetahuan-pengetahuan yang telah diproses pada tahapan sebelumnya dapat diakses oleh pengguna, serta dapat dilakukan penilaian dan evaluasi terhadap KMS. Penilaian dan evaluasi dapat dilakukan setelah penerapan KMS ini dalam kurun waktu tertentu. Adapun aspek-aspek yang dapat menjadi bahan evaluasi adalah kepuasan pengguna, tingkat penerimaan sistem, penggunaan sistem, dan sebagainya. Pada tahap ini, KMS diukur keberhasilannya dalam memberikan value kepada penggunanya, yaitu mahasiswa dan dosen. Lalu, hasil analisis proses knowledge sharing dengan sub proses socialization dan exchange, yaitu: 1. Terjadi proses socialization pada forum diskusi dikarenakan pengetahuan dalam bentuk tacit yang berupa pengalaman dibagikan antar user. 2. Terjadi proses exchange pada sharing materi kuliah dan prosedur pelayanan akademik prodi dikarenakan user dapat menuangkan pengetahuannya dalam bentuk explicit berupa bacaan-bacaan yang mendukung materi kuliah yang dapat dipost ke dalam sistem dan nantinya dapat diakses oleh user lainnya sehingga terjadi proses pertukaran pengetahuan, danjuga pengetahuan explicit berupa prosedur pelayanan prodi yang diposting oleh pihak prodi. Secara keseluruhan, proses-proses yang diusulkan pada knowledge management system yang diusulkan dapat dilihat pada Gambar 4.4. 129

Gambar 4.4 Rich Picture Sistem Usulan Gambaran umum penjelasan proses-proses yang berjalan tersebut, yaitu: 1. Admin melakukan registrasi user. 2. Mahasiswa mengunggah materi perkuliahan ke KMS. 3. Dosen mengunggah materi perkuliahan ke KMS. 4. Materi perkuliahan diunduh atau divoting oleh mahasiswa ataupun dosen. 5. Dosen mempelajari materi kuliah yang telah diunduh dari KMS. 130

6. Mahasiswa mempelajari materi kuliah yang telah diunduh dari KMS. 7. Admin melakukan posting prosedur pelayanan akademik. 8. Kaprodi SI melakukan posting prosedur pelayanan akademik. 9. Prosedur pelayanan akademik yang telah diposting pada KMS dapat dilihat oleh mahasiswa maupun dosen. 10. Mahasiswa mempelajari prosedur pelayanan akademik dari KMS. 11. Dosen mempelajari prosedur pelayanan akademik dari KMS. 12. Dosen mengajukan pertanyaan pada forum diskusi di KMS. 13. Mahasiswa mengajukan pertanyaan pada forum diskusi di KMS. 14. Diskusi atau pertanyaan yang diajukan masuk ke dalam forum diskusi pada KMS dan bisa diakses oleh user yang lain untuk memberikan jawaban atau tanggapan. 15. Mahasiswa memberikan tanggapan ataupun voting pada forum diskusi yang telah diajukan di KMS. 16. Dosen memberikan tanggapan ataupun voting pada forum diskusi yang telah diajukan di KMS. 131

17. Admin mengelola data user, materi perkuliahan, forum diskusi, prosedur pelayanan akademik, maintenance, serta melakukan monitoring sistem. 18. Kaprodi SI mengelola materi perkuliahan, forum diskusi, prosedur pelayanan akademik, serta melakukan monitoring sistem. Adapun pemrosesan pengetahuan dan informasi yang masuk ke dalam KMS pada tahap refine dijelaskan menggunakan flowchart pada Gambar 4.5. Gambar 4.5 Flowchart Pemrosesan Knowledge dan Informasi pada KMS 132

4.1.5 Analisis Kebutuhan Sistem Untuk membangun knowledge management system yang diusulkan, perlu diidentifikasi kebutuhan-kebutuhan yang terkait dengan sistem. Peneliti mengidentifikasi kebutuhan-kebutuhan sistem dengan membaginya menjadi 2, yaitu kebutuhan fungsional dan non-fungsional. Adapun kebutuhan-kebutuhan tersebut peneliti jabarkan pada Tabel 4.2 dan Tabel 4.3. Tabel 4.2 Kebutuhan Fungsional Knowledge Management System ID Deskripsi F-001 Sistem menyediakan layanan mengelola data user F-002 Sistem menyediakan layanan mengelola knowledge F-003 meliputi materi perkuliahan dan prosedur pelayanan akademik prodi SI Sistem menyediakan layanan forum diskusi antar user. F-004 Sistem menyediakan layanan sharing knowledge meliputi materi perkuliahan dan prosedur pelayanan akademik prodi SI. F-005 Sistem memiliki pengaturan sistem. 133

Tabel 4.3 Kebutuhan Non-Fungsional Knowledge Management System ID Deskripsi NF-001 Sistem dikembangkan menggunkaan metode pengembangan sistem RAD dan pemodelan menggunakan UML. NF-002 Sistem menggunakan framework React Native dengan bahasa pemrograman JavaScript. NF-003 Sistem dikembangkan menggunakan tool Microsoft Visual Studio Code versi 1.46. NF-004 Aplikasi berbasis Android. NF-005 Manajemen database sistem menggunakan Google Firebase. NF-006 Aplikasi dikembangkan untuk device dengan sistem operasi Android versi 8.0 ke atas. NF-007 Aplikasi dikembangkan untuk device dengan minimal RAM 2GB dan free-space memory 100MB. 134

4.2 Design Workshop 4.2.1 Perancangan Proses 1. Use Case Diagram Use Case Diagram memberikan gambaran interaksi antara knowledge management system dengan sistem eksternal ataupun dengan user dari sistem itu sendiri. Use Case Diagram menggambarkan siapa saja yang menggunakan sistem atau dengan cara apa saja user melakukan interaksi dengan sistem. Pada langkah pertama, yang harus dilakukan dalam Use Case Diagram adalah identifikasi aktor yang dapat berinteraksi dengan sistem. Adapun identifikasi aktor yang dapat berinteraksi dengan sistem diuraikan pada Tabel 4.4. Tabel 4.4 Identifikasi Aktor pada Knowledge Management System ID Aktor Deskripsi AC-01 Mahasiswa Individu mahasiswa sistem AC-02 Dosen informasi UIN Jakarta yang terdaftar sebagai mahasiswa aktif. Individu dosen sistem informasi UIN Jakarta yang terdaftar sebagai dosen aktif. 135

AC-03 Kepala Program Studi Individu yang memimpin Sistem Informasi UIN pelaksanaan seluruh kegiatan Jakarta (Kaprodi) Program Studi Sistem Informasi UIN Jakarta dan saat ini sedang menjabat sebagai Kaprodi SI UIN Jakarta. AC-04 Admin Individu yang mengelola KMS. Setelah itu, dilakukan identifikasi use case yang dibutuhkan setiap aktor pada knowledge management system ini. Identifikasi use case diuraikan pada Tabel 4.5. Tabel 4.5 Identifikasi Use Case pada Knowledge Management System ID Nama Use Deskripsi Partisipan Case UC-001 Login Use case ini Semua aktor menggambarkan kegiatan user untuk dapat masuk ke dalam sistem. UC-002 Logout Use case ini Semua aktor menggambarkan 136

kegiatan user untuk dapat mengakhiri sesi dan keluar dari sistem. UC-003 Kelola User Use case ini Admin menggambarkan kegiatan penambahan, perubahan, dan penghapusan data user. UC-004 Kelola Mata Use case ini Admin, Kaprodi Kuliah menggambarkan kegiatan penambahan, perubahan, dan penghapusan data mata kuliah. UC-005 Validasi Use case ini Admin, Kaprodi Materi Kuliah menggambarkan kegiatan validasi atau proses approving penambahan, perubahan, dan penghapusan materi 137

kuliah yang diajukan oleh user. UC-006 Kelola Materi Use case ini Admin, Kaprodi Kuliah menggambarkan proses perubahan, dan penghapusan materi kuliah. UC-007 Validasi Use case ini Admin, Kaprodi Forum Diskusi menggambarkan kegiatan validasi atau proses approving penambahan forum diskusi yang diajukan oleh user. UC-008 Hapus Forum Use case ini Admin, Kaprodi Diskusi menggambarkan penghapusan data forum diskusi. UC-009 Kelola Jenis Use case ini Admin, Kaprodi Pelayanan menggambarkan kegiatan penambahan, perubahan, dan 138

Akademik penghapusan data jenis Prodi pelayanan akademik prodi. UC-010 Kelola Use case ini Admin, Kaprodi Prosedur Pelayanan menggambarkan Akademik Prodi kegiatan penambahan, perubahan, dan penghapusan data prosedur pelayanan akademik prodi. UC-011 Validasi Use case ini Admin, Kaprodi Request Prosedur menggambarkan kegiatan validasi atau proses approving request prosedur pelayanan akademik prodi yang diajukan oleh user. UC-012 Prosedur Use case ini Mahasiswa, Pelayanan menggambarkan Dosen Akademik kegiatan melihat Prodi 139

prosedur pelayanan akademik prodi. UC-013 Forum Use case ini Mahasiswa, Diskusi menggambarkan Dosen, dan kegiatan penambahan, Kaprodi perubahan, dan penghapusan diskusi serta penambahan, perubahan, dan penghapusan komentar oleh user. UC-014 Materi Kuliah Use case ini Mahasiswa, menggambarkan Dosen kegiatan penambahan, perubahan, dan penghapusan materi kuliah oleh user. Setelah itu, berdasarkan identifikasi aktor dan identifikasi use case yang telah dibuat sebelumnya, peneliti membuat use case diagram yang menggambarkan interaksi antar aktor dan use case pada knowledge 140

management system. Use case diagram sistem ini digambarkan pada Gambar 4.6. Gambar 4.6 Use Case Diagram Knowledge Management System Kemudian, setiap use case pada diagram dijelaskan menggunakan use case narrative/scenario, yang menjelaskan interaksi antara aktor dengan use case tersebut. 141

Tabel 4.6 Use Case Scenario Login Use Case ID SC-001-01 Use Case Name Login Actor Admin, Kaprodi, Mahasiswa, Dosen Description Use Case ini mendeskripsikan tentang proses masuk ke dalam sistem. Precondition Aktor telah membuka sistem. Typical Course Actor Action System Response Events 1. Input nomor induk dan password. 2. Klik ‘Login’. 3. Sistem melakukan validasi dan autentikasi nomor induk dan password dengan database. 4. Menampilkan halaman utama sesuai aktor terkait. 142

Alternate Alt 4. Jika validasi atau autentikasi username dan password Course dengan database gagal, maka kembali ke step 1 dengan memunculkan pesan “Login gagal. Nomor induk atau Password salah, silahkan coba kembali”. Conclusion Use Case berakhir saat user telah masuk ke halaman utama sistem. Postcondition User telah masuk ke dalam sistem. Implementation Halaman login untuk semua aktor. Constraints and Specifications Tabel 4.7 Use Case Scenario Logout Use Case ID SC-002-01 Use Case Name Logout Actor Admin, Kaprodi, Mahasiswa, Dosen Description Use Case ini mendeskripsikan tentang proses mengakhiri sesi dan keluar dari sistem. Precondition Aktor telah melakukan login. Actor Action System Response 143

Typical Course 1. Klik menu ‘account’ 2. Menampilkan Events pada bottom halaman account. navigation bar. 3. Klik tombol 4. Sesi dihapus dan user ‘logout’. berhasil keluar dari sistem. Alternate - Course Conclusion Use Case berakhir saat user telah keluar dari sistem. Postcondition User telah keluar dari sistem. Implementation Halaman account. Constraints and Specifications Tabel 4.8 Use Case Scenario Kelola User/Tambah User Use Case ID SC-003-01 Use Case Name Kelola User/Tambah User Actor Admin 144

Description Use Case ini mendeskripsikan tentang proses menambahkan user yang dapat mengakses ke dalam sistem. Precondition Aktor telah melakukan login. Typical Course Actor Action System Response Events 1. Klik menu ‘kelola 2. Menampilkan user’ pada bottom halaman user. navigation bar. 3. Klik menu jenis user 4. Menampilkan yang ingin ditambah. halaman user Pada kasus ini, pilih mahasiswa yang berisi jenis user list data user dengan ‘mahasiswa’. jenis user mahasiswa. 5. Klik tombol ‘tambah 6. Menampilkan form user’. tambah user mahasiswa. 7. Mengisi form. 8. Klik tombol 9. Memvalidasi data dan ‘tambah’. menyimpan data user ke dalam database. 145

10. Menampilkan pesan “user berhasil ditambahkan”. 11. Menampilkan halaman user. Alternate Alt 4.a. Jika menu jenis user yang dipilih adalah dosen, maka Course sistem menampilkan halaman user dosen dan sistem menampilkan form tambah user dosen pada step 6. Alt 4.b. Jika menu jenis user yang dipilih adalah kaprodi, maka sistem menampilkan halaman user kaprodi dan sistem menampilkan form tambah user kaprodi pada step 6. Alt 4.c. Jika menu jenis user yang dipilih adalah admin, maka sistem menampilkan halaman user admin dan sistem menampilkan form tambah user admin pada step 6. Alt 10. Jika validasi data gagal, maka sistem menampilkan pesan “data tidak sesuai” dan kembali ke step 5. Conclusion Use Case berakhir setelah user telah ditambahkan dan sistem menampilkan halaman user. Postcondition Data user telah ditambahkan ke dalam database, sehingga user tersebut dapat melakukan login ke dalam sistem. 146

Implementation Halaman Tambah User. Constraints and Specifications Tabel 4.9 Use Case Scenario Kelola User/Edit User Use Case ID SC-003-02 Use Case Name Kelola User/Edit User Actor Admin Description Use Case ini mendeskripsikan tentang proses merubah data user yang sudah terdaftar dalam database. Precondition Aktor telah melakukan login dan data user yang ingin diubah harus sudah terdaftar terlebih dahulu. Typical Course Actor Action System Response Events 1. Klik menu ‘kelola 2. Menampilkan user’ pada bottom halaman user. navigation bar. 3. Klik menu jenis user 4. Menampilkan yang ingin diubah. halaman user mahasiswa yang berisi 147

Pada kasus ini, pilih list data user dengan menu ‘mahasiswa’. jenis user mahasiswa. 5. Klik user yang ingin 6. Menampilkan diubah pada list data halaman detail user user. yang dipilih. 7. Klik tombol ‘edit 8. Menampilkan form data user’. edit data user mahasiswa. 9. Mengisi form. 10. Klik tombol 11. Memvalidasi data dan ‘simpan’. menyimpan data user ke dalam database. 12. Menampilkan pesan “user berhasil diedit”. 13. Menampilkan halaman user. Alternate Alt 4.a. Jika menu jenis user yang dipilih adalah dosen, maka Course sistem menampilkan halaman user dosen dan sistem menampilkan form edit data user dosen pada step 8. 148

Alt 4.b. Jika menu jenis user yang dipilih adalah kaprodi, maka sistem menampilkan halaman user kaprodi dan sistem menampilkan form edit data user kaprodi pada step 8. Alt 4.c. Jika menu jenis user yang dipilih adalah admin, maka sistem menampilkan halaman user admin dan sistem menampilkan form edit data user admin pada step 8. Alt 12. Jika validasi data gagal, maka sistem menampilkan pesan “data tidak sesuai” dan kembali ke step 9. Conclusion Use Case berakhir setelah data user telah diubah dan sistem menampilkan halaman user. Postcondition Data user telah diubah dan disimpan ke dalam database. Implementation Halaman Edit User. Constraints and Specifications Tabel 4.10 Use Case Scenario Kelola User/Hapus User Use Case ID SC-003-03 Use Case Name Kelola User/Hapus User Actor Admin 149

Description Use Case ini mendeskripsikan tentang proses menghapus data user yang sudah terdaftar dalam database. Precondition Aktor telah melakukan login dan data user yang ingin dihapus harus sudah terdaftar terlebih dahulu. Typical Course Actor Action System Response Events 1. Klik menu ‘kelola 2. Menampilkan user’ pada bottom halaman user. navigation bar. 3. Klik menu jenis user 4. Menampilkan yang ingin dihapus. halaman user Pada kasus ini, pilih mahasiswa yang berisi menu ‘mahasiswa’. list data user sesuai jenis user mahasiswa yang dipilih. 5. Klik user yang ingin 6. Menampilkan dihapus pada list halaman detail user data user. yang dipilih. 7. Klik tombol ‘hapus 8. Menampilkan user’. konfirmasi pesan “apakah anda yakin menghapus user ini?”. 150

9. Klik tombol ‘ya’. 10. Sistem menghapus data user terkait, lalu menampilkan pesan “user berhasil dihapus” dan menampilkan halaman user. Alternate Alt 4.a. Jika menu jenis user yang dipilih adalah dosen, maka Course sistem menampilkan halaman user dosen. Alt 4.b. Jika menu jenis user yang dipilih adalah kaprodi, maka sistem menampilkan halaman user kaprodi. Alt 4.c. Jika menu jenis user yang dipilih adalah admin, maka sistem menampilkan halaman user admin. Alt 10. Jika tombol yang di klik pada step 9 adalah ‘tidak’, maka sistem kembali menampilkan halaman detail user yang dipilih. Conclusion Use Case berakhir setelah data user telah dihapus dan sistem menampilkan halaman user. Postcondition Data user telah dihapus dari database. 151

Implementation Halaman Detail User. Constraints and Specifications Tabel 4.11 Use Case Scenario Kelola Mata Kuliah/Tambah Mata Kuliah Use Case ID SC-004-01 Use Case Name Kelola Mata Kuliah/Tambah Mata Kuliah Actor Admin, Kaprodi Description Use Case ini mendeskripsikan tentang proses menambah data mata kuliah ke dalam database. Precondition Aktor telah melakukan login ke dalam sistem. Typical Course Actor Action System Response Events 1. Klik menu ‘materi 2. Menampilkan kuliah’ pada bottom halaman kelola materi navigation bar. kuliah. 3. Klik menu ‘mata 4. Menampilkan kuliah’. halaman kelola mata kuliah. 152

5. Pilih semester yang 6. Menampilkan list diinginkan pada mata kuliah pada drop-down list ‘pilih semester terkait jika semester’. sudah pernah melakukan input mata 7. Pilih tombol ‘tambah kuliah sebelumnya. mata kuliah’. 8. Menampilkan form tambah mata kuliah. 9. Mengisi form. 10. Klik tombol 11. Menampilkan pesan ‘tambah’. “apakah anda yakin data yang diinput 12. Klik tombol ‘ya’. sudah benar?”. 13. Sistem memvalidasi form dan menyimpan data mata kuliah ke dalam database. 14. Menampilkan pesan “mata kuliah berhasil ditambah” dan menampilkan 153

Alternate halaman kelola mata Course kuliah. Alt 13.a. Jika aktor memilih tombol ‘tidak’, maka sistem akan menampilkan kembali form tambah mata kuliah beserta data input yang sudah diisi sebelumnya pada step 8. Alt 13.b. Jika validasi data gagal, maka sistem akan menampilkan pesan “data tidak sesuai” dan menampilkan kembali form tambah mata kuliah pada step 8. Conclusion Use Case berakhir setelah data user telah dihapus dan sistem menampilkan halaman user. Postcondition Data mata kuliah telah ditambah ke dalam database. Implementation Halaman Tambah Mata Kuliah. Constraints and Specifications Tabel 4.12 Use Case Scenario Kelola Mata Kuliah/Edit Mata Kuliah Use Case ID SC-004-02 Use Case Name Kelola Mata Kuliah/Edit Mata Kuliah Actor Admin, Kaprodi 154

Description Use Case ini mendeskripsikan tentang proses merubah data mata kuliah pada database. Precondition Aktor telah melakukan login ke dalam sistem dan sudah ada data mata kuliah yang telah diinput sebelumnya. Typical Course Actor Action System Response Events 1. Klik menu ‘materi 2. Menampilkan kuliah’ pada bottom halaman kelola materi navigation bar. kuliah. 3. Klik menu ‘mata 4. Menampilkan kuliah’ halaman kelola mata kuliah. 5. Pilih semester yang 6. Menampilkan list diinginkan pada mata kuliah pada drop-down list ‘pilih semester terkait. semester’. 7. Pilih mata kuliah 8. Menampilkan yang ingin diubah halaman detail mata datanya. kuliah yang dipilih. 9. Klik tombol ‘edit 10. Menampilkan form mata kuliah’. edit mata kuliah. 155

11. Mengisi form. 12. Klik tombol 13. Menampilkan pesan ‘simpan’. “Apakah anda yakin data yang dimasukkan 14. Klik tombol ‘ya’. sudah benar?”. 15. Memvalidasi data dan menyimpannya ke dalam database. Alternate 16. Menampilkan pesan Course “data mata kuliah berhasil diubah” dan menampilkan halaman kelola mata kuliah. Alt 15.a. Jika aktor memilih tombol ‘tidak’, maka sistem kembali menampilkan form edit mata kuliah pada step 10. Alt 15.b. Jika validasi data gagal, sistem menampilkan pesan “data tidak sesuai” dan menampilkan form edit mata kuliah pada step 10. Conclusion Use Case berakhir setelah data mata kuliah telah diubah dan sistem menampilkan halaman kelola mata kuliah. 156

Postcondition Data mata kuliah telah diubah pada database. Implementation Halaman Edit Mata Kuliah. Constraints and Specifications Tabel 4.13 Use Case Scenario Kelola Mata Kuliah/Hapus Mata Kuliah Use Case ID SC-004-03 Use Case Name Kelola Mata Kuliah/Hapus Mata Kuliah Actor Admin, Kaprodi Description Use Case ini mendeskripsikan tentang proses menghapus data mata kuliah pada database. Precondition Aktor telah melakukan login ke dalam sistem dan sudah ada data mata kuliah yang telah diinput sebelumnya. Typical Course Actor Action System Response Events 1. Klik menu ‘materi 2. Menampilkan kuliah’ pada bottom halaman kelola materi navigation bar. kuliah. 157

3. Klik menu ‘mata 4. Menampilkan kuliah’. halaman kelola mata kuliah. 5. Pilih semester yang diinginkan pada 6. Menampilkan list drop-down list ‘pilih mata kuliah pada semester’. semester terkait. 7. Pilih mata kuliah 8. Menampilkan yang ingin dihapus halaman detail mata datanya. kuliah yang dipilih. 9. Klik tombol ‘hapus 10. Menampilkan pesan mata kuliah’. konfirmasi “apakah anda yakin 11. Klik tombol ‘ya’. menghapus mata kuliah ini?”. 12. Menghapus data mata kuliah dari database. 13. Menampilkan pesan “mata kuliah berhasil dihapus” dan menampilkan 158

Alternate halaman kelola mata Course kuliah. Alt 12. Jika aktor memilih tombol ‘tidak’, maka sistem akan kembali ke step 6. Conclusion Use Case berakhir setelah data mata kuliah telah dihapus dari database dan sistem menampilkan halaman kelola mata kuliah. Postcondition Data mata kuliah telah dihapus pada database. Implementation Halaman Kelola Mata Kuliah. Constraints and Specifications Tabel 4.14 Use Case Scenario Validasi Materi Kuliah Use Case ID SC-005-01 Use Case Name Validasi Materi Kuliah Actor Admin, Kaprodi Description Use Case ini mendeskripsikan tentang proses validasi atau approving penambahan, perubahan, dan penghapusan materi kuliah yang diajukan oleh user. 159

Precondition Aktor telah melakukan login ke dalam sistem. Typical Course Actor Action System Response Events 1. Klik menu ‘materi 2. Menampilkan kuliah’ pada bottom halaman kelola materi navigation bar. dan mata kuliah. 3. Klik menu ‘materi 4. Menampilkan kuliah’ halaman kelola materi kuliah. 5. Klik tombol 6. Menampilkan list ‘approval materi pengajuan kuliah’. penambahan, perubahan, dan penghapusan materi kuliah yang telah diajukan oleh user dan menunggu validasi. 7. Pilih pengajuan yang 8. Menampilkan dikehendaki. halaman detail materi kuliah terkait. 160

9. Klik tombol 10. Mengubah status ‘setujui’. pengajuan dari ‘pending’ menjadi ‘disetujui’ dan menyimpannya ke dalam database. Alternate 11. Menampilkan pesan Course “pengajuan telah disetujui” dan kembali menampilkan list pengajuan yang telah diajukan oleh user dan menunggu validasi. Alt 10. Jika aktor memilih tombol ‘tolak’, maka sistem menampilkan pesan konfirmasi “apakah anda yakin menolak pengajuan ini?”, jika aktor klik tombol ‘ya’, maka sistem akan menghapus data materi kuliah tersebut, dan menampilkan kembali list materi kuliah yang telah diunggah oleh user dan menunggu verifikasi. Jika aktor memilih tombol ‘tidak’, maka sistem akan menampilkan kembali halaman detail materi kuliah terkait. 161

Conclusion Use Case berakhir setelah pengajuan penambahan, perubahan, atau penghapusan materi kuliah dapat disetujui ataupun ditolak. Postcondition Data materi kuliah dapat diubah statusnya menjadi ‘disetujui’ atau ‘ditolak’. Implementation Halaman Kelola Materi Kuliah. Constraints and Specifications Tabel 4.15 Use Case Scenario Kelola Materi Kuliah Use Case ID SC-006-01 Use Case Name Kelola Materi Kuliah Actor Admin, Kaprodi Description Use Case ini mendeskripsikan tentang proses perubahan, dan penghapusan data materi kuliah pada database. Precondition Aktor telah melakukan login ke dalam sistem. Actor Action System Response 162

Typical Course 1. Klik menu ‘materi 2. Menampilkan Events kuliah’ pada bottom halaman kelola materi navigation bar. kuliah. 3. Klik menu ‘materi 4. Menampilkan list kuliah’. mata kuliah. 5. Pilih salah satu 6. Menampilkan list semester yang mata kuliah sesuai dikehendaki pada semester yang dipilih. dropdown list pilih semester. 8. Menampilkan list materi kuliah yang 7. Pilih salah satu mata sudah divalidasi oleh kuliah. admin sesuai mata kuliah yang dipilih. 9. Pilih materi kuliah yang ingin diubah. 10. Menampilkan halaman detail materi 11. Klik tombol ‘edit’. kuliah yang dipilih. 13. Mengisi form. 12. Menampilkan form edit materi kuliah. 163

14. Klik tombol 15. Menampilkan pesan ‘simpan’. konfirmasi “apakah anda yakin data yang 16. Klik tombol ‘ya’. dimasukkan sudah benar?”. 19. Pilih materi kuliah yang ingin dihapus. 17. Memvalidasi data dan menyimpannya ke 21. Klik tombol ‘hapus’. dalam database. 18. Menampilkan pesan “detail materi kuliah berhasil diubah” dan kembali menampilkan list data materi kuliah yang sudah diapprove pada mata kuliah terkait. 20. Menampilkan halaman detail materi kuliah yang dipilih. 22. Menampilkan pesan “apakah anda yakin 164

23. Klik tombol ‘ya’. ingin menghapus materi kuliah ini?”. 24. Menghapus data materi kuliah dari database. Alternate 25. Menampilkan pesan Course “materi kuliah berhasil dihapus” dan kembali menampilkan list data materi kuliah yang sudah diapprove pada mata kuliah terkait. Alt 17.a. Jika aktor memilih tombol ‘tidak’ maka sistem akan menampilkan kembali step 12. Alt 17.b. Jika validasi data gagal, maka sistem akan menampilkan pesan “data tidak tepat” dan menampilkan kembali form edit materi kuliah pada step 12. Conclusion Use Case berakhir setelah data materi kuliah diubah, dan dihapus dari database serta menampilkan halaman list data materi kuliah. 165

Postcondition Data materi kuliah dapat diubah dan dihapus. Implementation Halaman Kelola Materi Kuliah. Constraints and Specifications Tabel 4.16 Use Case Scenario Validasi Forum Diskusi Use Case ID SC-007-01 Use Case Name Validasi Forum Diskusi Actor Admin, Kaprodi Description Use Case ini mendeskripsikan tentang proses validasi atau approval forum diskusi yang diajukan oleh user. Precondition Aktor telah melakukan login ke dalam sistem dan sudah ada data forum diskusi yang telah diajukan oleh user. Typical Course Actor Action System Response Events 1. Klik menu ‘forum 2. Menampilkan diskusi’. halaman kelola forum diskusi yang berisi list forum diskusi yang 166