Knowledge Management System Life Cycle (KMSLC) dalam Software Engineering: Model, Tahapan, dan Studi Kasus Penelitian

Di banyak organisasi, informasi tersimpan sebagai berkas, percakapan, dan pengalaman anggota tim. Persoalannya bukan hanya ketiadaan aplikasi, melainkan bagaimana pengalaman itu ditangkap, dimodelkan, diverifikasi, ditemukan kembali, dan digunakan. Dalam rekayasa perangkat lunak, masalah tersebut diterjemahkan menjadi persyaratan, desain model data, kontrol kualitas, dan pengukuran manfaat sistem.

Fokus artikel: KMSLC sebagai process model pengembangan KMS; perbedaannya dengan SDLC umum, praktik SEMM, artefak setiap tahap, dan bukti dari publikasi yang terverifikasi. Contoh diagram kebutuhan dan metrik pelatihan yang dibuat untuk tutorial bukan hasil empiris yang diklaim berasal dari makalah.

1. Apa itu KMSLC dan mengapa relevan dengan Software Engineering?

KMSLC adalah kerangka siklus hidup pengembangan Knowledge Management System (KMS), yakni perangkat lunak yang mendukung penangkapan, penyimpanan, pengorganisasian, pencarian, berbagi, dan pemanfaatan pengetahuan. Sebuah portal dokumen belum tentu efektif sebagai KMS: dokumen dapat tersedia namun sulit ditemukan, tidak memiliki sumber otoritatif, atau telah kedaluwarsa. Artinya, keberhasilan KMS dinilai melalui mutu fungsi perangkat lunak dan pengelolaan siklus hidup pengetahuannya.

Dari perspektif SE, proses tersebut merupakan aktivitas rekayasa. Wawancara pengetahuan berperan sebagai requirements elicitation sekaligus knowledge elicitation; knowledge map adalah model domain; skema metadata menjadi desain informasi dan model data; sementara verifikasi–validasi membuktikan apakah perangkat lunak memenuhi persyaratan serta membantu pengguna menemukan dan memanfaatkan pengetahuan.

2. Landasan teori: dari KM menuju process model

Literatur klasik Knowledge Management oleh Elias M. Awad dan Hassan M. Ghaziri (2004) membahas siklus hidup sistem KM yang dipengaruhi pola pengembangan sistem konvensional, tetapi secara khusus menekankan pengetahuan dan perubahan organisasi. Sementara itu, knowledge capture sering membedakan pengetahuan tacit (misalnya kiat pakar) dengan pengetahuan explicit yang telah terdokumentasi. Proses codification menjembatani keduanya, tetapi tidak setiap pengalaman bisa atau perlu diubah menjadi teks statis.

Istilah model, method, dan technique sebaiknya dibedakan: KMSLC memberi struktur tahapan dan keterkaitannya; wawancara, observasi, UML, knowledge mapping, dan pengujian adalah teknik/metode yang dipilih untuk menjalankan tahapan tersebut. KMSLC bukan sebuah algoritma pencarian atau kerangka pemrograman.

3. Delapan tahap KMSLC Awad–Ghaziri

Delapan tahap berikut disajikan sebagai kerangka konseptual penuh dari sumber Awad–Ghaziri dan materi pengajaran terkait. Banyak penelitian terapan membatasi tahapan sesuai ruang lingkupnya, sehingga jangan menyamakan penggunaan sebagian tahap dengan implementasi lengkap siklus hidup.

1. Evaluate Existing Infrastructure

Audit sistem, jaringan, peran organisasi, serta praktik berbagi pengetahuan. Dari sisi SE, kumpulkan stakeholder, sistem lama, masalah, constraint, dan risiko integrasi.

ARTEFAK KELUARAN: As-is process, stakeholder register, system inventory, daftar masalah dan kebutuhan awal.

2. Form the KM Team

Susun peran knowledge owner, domain expert, knowledge engineer, software engineer, UX researcher, QA, dan operator. Tanggung jawab konten dan perangkat lunak perlu dibedakan.

ARTEFAK KELUARAN: RACI, struktur tim, aturan persetujuan pengetahuan dan tanggung jawab teknis.

3. Knowledge Capture

Wawancarai ahli, telaah dokumen, buat knowledge map, klasifikasi tacit/explicit, tetapkan provenance dan aturan validasi konten. Di sini keluaran KM harus menjadi input requirements engineering.

ARTEFAK KELUARAN: Inventory knowledge, interview notes, knowledge map, taxonomy dan metadata specification.

4. Design KMS Blueprint

Rancang arsitektur komponen, persyaratan fungsional/nonfungsional, database, API, strategi pencarian, alur moderasi, UI dan model otorisasi.

ARTEFAK KELUARAN: SRS, UML, ERD, wireframe, API specification, architecture decision record.

5. Verify and Validate KMS

Lakukan review konten oleh pakar sekaligus verifikasi perangkat lunak: unit, integrasi, fungsional, usability, keamanan, serta acceptance.

ARTEFAK KELUARAN: Test plan, test cases, traceability, defect log, hasil validasi konten.

6. Implement KMS

Siapkan deployment, migrasi aset, pelatihan pengguna, serta monitoring dan backup. Implementasi bukan hanya coding: pengoperasian dan kesiapan organisasi harus diuji.

ARTEFAK KELUARAN: Release package, deployment checklist, SOP, user guide dan log migrasi.

7. Manage Change and Rewards

Bangun mekanisme kontribusi, peran kurator, persetujuan dan insentif agar pengetahuan terus diperbarui. Secara SE, ini mencakup governance perubahan dan pemeliharaan.

ARTEFAK KELUARAN: Change request, content governance, jadwal review, ownership matrix.

8. Post-System Evaluation

Ukur kualitas sistem sekaligus pemakaian pengetahuan. Temuan harus kembali ke backlog requirements, perbaikan arsitektur, dan revisi proses.

ARTEFAK KELUARAN: Evaluation report, KPI, backlog improvement, roadmap iterasi berikutnya.

4. KMSLC dalam Software Engineering Models and Methods (SEMM)

Dalam analisis bidang ilmu, KMSLC lebih tepat dibaca sebagai model proses pengembangan perangkat lunak khusus domain KMS. Ia mengatur urutan aktivitas rekayasa dan bentuk keputusan yang harus diambil. Metode seperti user interview, knowledge elicitation, requirements prioritization, UML, test design, dan evaluasi UX dapat diterapkan di dalamnya. KMSLC tidak identik dengan semua model KM seperti SECI, yang mempunyai fokus berbeda pada proses pembentukan/konversi pengetahuan.

5. Empat publikasi sebagai studi kasus dan pembanding

Empat studi menunjukkan cakupan rekayasa KMS dari domain pengetahuan menuju perangkat lunak. Tiga studi—hidroponik, kemahasiswaan, dan ukiran Bali—memberi bukti penerapan KMSLC pada objek berbeda; studi inovasi desa menambahkan perspektif evaluasi pengalaman pengguna (UXL), bukan penerapan KMSLC yang identik. Perbandingan berikut memusatkan perhatian pada artefak dan bukti rekayasa, pengujian, serta batas inferensi masing-masing penelitian.

5.0 Matriks komparasi penelitian dari perspektif Software Engineering

Perbandingan berikut memisahkan bukti yang dilaporkan publikasi dari interpretasi rekayasa perangkat lunak. Kolom terakhir bukan nilai pengujian semua studi; masing-masing penelitian mengukur aspek yang berbeda.

Dari matriks tersebut terlihat bahwa knowledge mapping berperan sebagai struktur domain yang memengaruhi desain sistem, sedangkan pengujian antarmuka dan pengujian jawaban pengetahuan harus dinilai secara terpisah. Itulah alasan KMSLC relevan untuk SEMM tetapi tidak boleh disamakan dengan satu model kualitas AI.

5.1 Penelitian hidroponik: domain knowledge → software artifact

Artikel Wardhana, Nurhadryani, dan Wahjuni (2020) membangun KMS hidroponik berbasis web untuk mendukung Smart Society. Abstrak resmi menerangkan bahwa pengetahuan tacit dan explicit komunitas dikumpulkan, lalu knowledge map dipakai untuk kodifikasi sehingga diperoleh 34 pengetahuan eksplisit berupa video dan dokumen. Sistem dikembangkan dengan pendekatan berorientasi objek dan diuji oleh pakar; fungsi yang dilaporkan mencakup capture, sharing dan discovery.

Interpretasi SE: knowledge map dapat dibaca sebagai model domain, sedangkan fungsi capture/sharing/discovery merupakan kemampuan perangkat lunak yang bisa diturunkan menjadi functional requirements dan diuji. Angka 34 adalah hasil konten yang dilaporkan artikel, bukan metrik akurasi atau keberhasilan pengguna.

5.2 Penelitian kemahasiswaan: implementasi KMS berbasis web

Studi Utomo, Wardhana, dan Ramdani (2020) mengidentifikasi masalah dokumentasi pengetahuan dalam kegiatan kemahasiswaan. Artikel melaporkan pengembangan sistem menggunakan KMSLC dengan Laravel, PHP, dan MySQL. Fungsi yang dijelaskan adalah knowledge capture, forum untuk sharing, serta penelusuran sebagai discovery. Contoh ini menunjukkan hubungan antara metode pengembangan dengan keputusan teknologi implementasi; framework Laravel adalah technology stack, bukan KMSLC itu sendiri.

5.3 Penelitian inovasi desa: pelengkap perspektif UX

Penelitian Wardhana, Kartiko, Saputra, dan Fani (2022) melaporkan penggunaan User Experience Lifecycle (analisis, desain, prototipe, evaluasi), wawancara terhadap tujuh partisipan, pengujian think-aloud, serta skor SUS sebesar 74,5. Studi tersebut memberi contoh bagaimana kualitas pengalaman pengguna dievaluasi secara terpisah dari keberhasilan teknis pengembangan KMS. Skor SUS tidak otomatis membuktikan peningkatan kualitas pengetahuan atau produktivitas organisasi.

5.4 Analisis mendalam: KMSLC–SECI dan chatbot NLP pada KMS Ukiran Bali (JTIIK, 2023)

Penelitian Prabawa dan Wardhana (2023), Pengembangan Knowledge Management System Ukiran Kayu Khas Bali Berbasis Artificial Intelligence, dilakukan pada UKM Begeh Ukir yang memiliki pengetahuan tentang produk dan proses ukiran yang sebagian tersimpan pada pengalaman pengrajin. Masalah rekayasanya adalah bagaimana menangkap, menstrukturkan, dan menyediakan pengetahuan tersebut sebagai layanan perangkat lunak agar dapat diakses kembali. Publikasi ini menggabungkan KMSLC sebagai proses pengembangan KMS dan SECI sebagai model konversi pengetahuan. Baca publikasi resmi.

5.4.1 Knowledge acquisition: menjadikan pengetahuan domain sebagai bahan requirements

Penelitian memperoleh 16 pengetahuan eksplisit serta mendokumentasikan pengetahuan tacit melalui on-site observation. Dalam rekayasa perangkat lunak, keduanya merupakan bukti untuk domain analysis: perancang memerlukan bukan hanya daftar konten, tetapi juga sumber, konteks penggunaan, pemilik pengetahuan, dan aturan validasi. Dari sini dapat diturunkan kebutuhan seperti pengelolaan artikel pengetahuan, kategorisasi, pencarian, serta antarmuka tanya jawab.

5.4.2 Knowledge map sebagai domain model

Knowledge map yang dilaporkan dikelompokkan menjadi empat kategori, yaitu sanggah, bale, bahan, dan filosofi. Pembaca dapat memandang kategori itu sebagai konsep awal dari information architecture dan taksonomi metadata: entitas KnowledgeItem dapat terhubung ke Category, Author, Source, dan ReviewStatus. Bentuk entitas dan relasi ini adalah contoh desain lanjutan yang disarankan, bukan struktur database yang diklaim sudah digunakan oleh penelitian.

5.4.3 Blueprint sistem, UML, dan implementasi

Penelitian menggunakan perancangan berorientasi objek dengan UML lalu mengimplementasikan KMS berbasis web. Bagian chatbot dijelaskan dengan integrasi Gradio melalui REST API. Dari sudut SE, ini menunjukkan pemisahan perhatian antara model pengetahuan, fitur aplikasi, dan layanan NLP. Untuk sistem yang lebih besar, pemisahan komponen itu dapat dilanjutkan dengan kontrak API, autentikasi, audit perubahan pengetahuan, dan pengujian integrasi antarlayanan.

5.4.4 Pengujian black-box dan penghitungan ulang hasil

Pada pengujian chatbot, naskah menyatakan lima jawaban sesuai dari delapan pertanyaan. Oleh karena itu, untuk analisis kuantitatif dalam artikel pembelajaran ini digunakan angka yang dihitung dari jumlah uji yang disebutkan:

Ketepatan jawaban pada delapan kasus uji = (5 ÷ 8) × 100% = 62,5%.

Angka 62,5% merupakan hasil perhitungan ulang dari pembilang dan penyebut yang dinyatakan dalam naskah, bukan klaim bahwa publikasi mencetak angka ini sebagai persentase resminya. Evaluasi delapan pertanyaan belum cukup untuk menyimpulkan ketepatan chatbot pada keseluruhan domain ukiran Bali. Untuk replikasi ilmiah, diperlukan kumpulan soal yang lebih beragam, kriteria penilaian yang eksplisit, penyekatan data pengembangan dan pengujian, serta analisis per kategori pengetahuan.

5.4.5 KMSLC sebagai model proses: di mana kontribusi Software Engineering-nya?

Sintesis: studi ini memperkuat argumentasi bahwa kegiatan KMSLC dapat dikaji sebagai proses rekayasa perangkat lunak yang knowledge-intensive. Namun, penelitian tersebut terutama menunjukkan penerapan KMSLC untuk menghasilkan suatu sistem; kebaruan model/metode SEMM memerlukan pengujian kontribusi tertentu terhadap baseline pengembangan yang relevan.

6. Studi kasus tutorial: membangun KMS pengetahuan mahasiswa

Misalkan tim SE hendak membangun KMS untuk mendokumentasikan pengalaman organisasi kemahasiswaan, kebijakan kegiatan, laporan acara, dan praktik kerja. Studi kasus berikut adalah skenario pembelajaran yang disusun untuk artikel, bukan rekonstruksi data mentah dari penelitian 2020.

Langkah 1 — Definisikan masalah dan keberhasilan sistem

Masalah awal: informasi kegiatan tersimpan di berbagai grup dan berkas pribadi. Tujuan sistem adalah membuat proses penyerahan pengetahuan antarpengurus lebih mudah. Ukuran keberhasilan tidak boleh berhenti pada “website berhasil dibuat”, melainkan mencakup tingkat penemuan pengetahuan relevan, tingkat pembaruan konten, dan kemampuan pengguna menyelesaikan tugas.

Langkah 2 — Susun requirements

Dari observasi dan wawancara, contoh kebutuhan fungsional dapat dirumuskan: FR-01 pengguna dapat mengirim dokumen pengalaman; FR-02 kurator dapat memvalidasi konten; FR-03 pengguna dapat mencari berdasarkan topik; FR-04 sistem menyimpan riwayat revisi. Kebutuhan nonfungsional meliputi aksesibilitas, keamanan dan performa yang didefinisikan secara terukur.

Langkah 3 — Bentuk knowledge map dan metadata

Pisahkan konten menjadi kegiatan, prosedur, pengurus, hasil evaluasi, dan praktik baik. Untuk setiap item, sediakan title, summary, category, author, reviewer, status, created_at, reviewed_at, valid_until, version, dan source_reference. Dengan metadata, perangkat lunak dapat melakukan review status, pencarian terarah, dan mendeteksi konten yang perlu diperbarui.

Langkah 4 — Desain arsitektur

Contoh implementasi modern menggunakan frontend web, API backend, PostgreSQL, object storage, search index, dan audit logging. Pemilihan stack adalah contoh rancangan rekayasa dan bukan klaim stack penelitian Utomo dkk. yang dilaporkan menggunakan Laravel/MySQL.

Pengguna / Kurator
       |
     Web UI
       |
  API + Auth + RBAC
       |
  Knowledge Service ---- Search Service
       |                       |
 PostgreSQL                Search Index
       |
 Object Storage (dokumen/video)
       |
 Audit & Review Scheduler

Langkah 5 — Rancang verifikasi dan validasi

Unit test memverifikasi aturan status dokumen. Integration test memeriksa hubungan API–database–storage. Acceptance test memastikan kurator dapat meninjau pengetahuan. Usability testing menilai apakah mahasiswa bisa menemukan prosedur yang dibutuhkan tanpa kebingungan. Evaluasi kualitas konten melibatkan pakar domain secara terpisah.

7. Contoh artefak: dari kebutuhan ke pengujian

Salah satu ciri analisis SE yang kuat adalah traceability. Setiap masalah atau tujuan harus dapat ditelusuri menuju requirement, artefak desain, implementasi, skenario uji, dan hasil evaluasi. Tanpa keterlacakan, penelitian mudah berubah menjadi daftar fitur yang tidak mempunyai justifikasi empiris.

Jangan hanya menghitung jumlah artikel yang tersimpan. Pada kualitas pengetahuan, perhatikan validitas sumber dan kemutakhiran; pada kualitas perangkat lunak, perhatikan kemampuan pencarian, keselamatan akses, stabilitas, serta pengalaman pengguna.

8. Testing, evaluasi, dan contoh metrik kuantitatif

Contoh hasil riil yang dihitung ulang: kesesuaian chatbot ukiran Bali

Penelitian Prabawa dan Wardhana (2023) melaporkan jumlah uji chatbot berupa delapan pertanyaan dengan lima jawaban sesuai. Jika answer correctness didefinisikan sebagai proporsi jawaban yang memenuhi kriteria kesesuaian pada kumpulan uji itu, maka:

Answer correctness = jumlah jawaban sesuai / jumlah pertanyaan × 100%
                   = 5 / 8 × 100%
                   = 62,5%

Interpretasi yang sah hanya terbatas pada delapan kasus uji yang disebutkan. Metrik ini berbeda dari precision@k pencarian dokumen, task success rate penggunaan antarmuka, atau SUS. Kesimpulan lebih luas memerlukan test set independen yang lebih besar dan penilaian konsisten oleh pakar domain.

Berikut rumus contoh untuk mengukur prototipe KMS. Ini adalah metrik rekayasa yang direkomendasikan untuk tutorial; jangan dinisbatkan sebagai hasil angka penelitian Wardhana dkk. tanpa pengukuran.

Contoh perhitungan task success

Dalam simulasi, lima mahasiswa masing-masing menyelesaikan dua tugas pencarian. Delapan dari sepuluh percobaan berhasil. Maka:

Task success rate = (8 / 10) × 100% = 80%

Nilai 80% menunjukkan ada dua tugas gagal pada sampel contoh ini. Peneliti tetap perlu membaca observasi, bukan hanya menyimpulkan sistem “baik” dari satu persentase.

Contoh precision@5

Untuk kueri “cara mengajukan dana kegiatan”, penilai domain menandai empat dari lima hasil teratas relevan. Maka:

Precision@5 = 4 / 5 = 0,80

Precision tinggi belum tentu berarti recall tinggi. Evaluasi mesin pencari perlu memakai kumpulan kueri dan relevansi yang dinilai konsisten, bukan satu contoh.

Contoh content freshness

Jika ada 12 dokumen kedaluwarsa dari 120 konten aktif:

Outdated content rate = (12 / 120) × 100% = 10%

Angka ini membantu menentukan prioritas review, tetapi batas masa berlaku harus ditetapkan sesuai jenis pengetahuan.

9. KMSLC, SDLC, Agile, SECI, dan UXL: bukan sinonim

Kombinasi yang masuk akal ialah KMSLC untuk kerangka proses, teknik requirements engineering untuk elisitasi, Agile untuk pengelolaan iterasi implementasi, serta UXL untuk menguji pengalaman pengguna. Kombinasi ini merupakan usulan integrasi metodologis, bukan klaim bahwa seluruh pendekatan tersebut digunakan bersama dalam publikasi terdahulu.

10. Bagaimana menjadikannya riset Software Engineering?

Penelitian SE yang kuat tidak cukup menyatakan “menggunakan KMSLC untuk membuat website”. Rumusan ilmiahnya dapat menguji masalah rekayasa yang terdefinisi, misalnya keterlacakan antara pengetahuan yang ditangkap dengan requirements, kualitas knowledge representation terhadap retrieval, atau pengaruh mekanisme review terhadap defect pengetahuan yang ditampilkan.

Jika penelitian bertujuan mengusulkan model/method baru, tentukan baseline dan perubahan yang benar-benar baru—misalnya mekanisme requirements-to-knowledge traceability—kemudian ukur kualitas dan biaya penerapannya. Kebaruan tidak muncul semata-mata karena mengganti bahasa pemrograman atau menambahkan AI/RAG.

11. FAQ

12. Referensi dan bacaan lanjutan

Prabawa, I. P. R. I., & Wardhana, A. C. (2023). Pengembangan Knowledge Management System Ukiran Kayu Khas Bali Berbasis Artificial Intelligence. Jurnal Teknologi Informasi dan Ilmu Komputer, 10(6), 1379–1388. https://doi.org/10.25126/jtiik.2023107576.

1. Awad, E. M., & Ghaziri, H. M. (2004). Knowledge Management. Prentice Hall. Pratinjau buku.
2. Wardhana, A. C., Nurhadryani, Y., & Wahjuni, S. (2020). Knowledge Management System Berbasis Web tentang Budidaya Hidroponik untuk Mendukung Smart Society. JTIIK, 7(3), 619–628. DOI.
3. Utomo, A. P., Wardhana, A. C., & Ramdani, C. (2020). Pengembangan Sistem Manajemen Pengetahuan pada Unit Kemahasiswaan. Jurnal E-Komtek, 4(2), 155–167. DOI.
4. Wardhana, A. C., Kartiko, C., Saputra, W. A., & Fani, T. (2022). User Experience Lifecycle pada Aplikasi Knowledge Management System Inovasi Desa. Jurnal Media Informatika Budidarma, 6(1), 99–109. DOI.
5. Materi pembelajaran Knowledge Management Systems Life Cycle, Università di Bologna. Materi ringkasan siklus hidup.

Untuk menelusuri publikasi lainnya, lihat profil Google Scholar penulis. Informasi yang diklaim sebagai temuan penelitian pada artikel ini merujuk pada abstrak dan metadata penerbit; artefak contoh yang dibuat khusus untuk tutorial tidak dinyatakan sebagai dokumen asli penelitian.