Blogs ariefbb | Information Technology Best Practice – ITB Rotating Header Image

Kuliah ITB

Migrasi Yes , Migrasi No , Transformasi LMS Kuliah ITB

Sebagai penanggung jawab teknis sistem e-learning di ITB , dihadapkan pada kondisi perkembangan perangkat

  1. Software LMS moodle sudah berevolusi jauh dengan mengedepankan fitur-fitur web terkini ,
  2. Bahasa pemrograman PHP berkembang serta juga mengalami perubahan , bahkan fitur sekarang (5.4, red) sudah jauh berbeda dengan fitur pendahulunya (5.1,5.2)
  3. Database MySQL , walau tidak signifikan juga mengalami perubahan .

Di sisi lain , pertumbuhan jumlah pengguna laptop di kalangan mahasiswa bergerak cukup pesat. Selain itu , penggunaan gadget dan perangkat mobile semakin intensif di kalangan mahasiswa dan dosen.

Untuk pemanfaatan e-learning dan blendedlearning secara optimal diperlukan

  1. Pemahaman terhadap karakterstik user sebagai pengguna termasuk IT user behaviour
  2. Memperhatikan kebutuhan-kebutuhan masing-masing tipikal user
  3. Perangkat yang digunakan oleh user termasuk , karakteristik akses, teknologi, gadget

Dengan enforcement di atas , perlu diambil suatu tindakan masif . Berupa transformasi atau migrasi teknologi lama (LMS 1.9) ke teknologi baru (LMS 2.4) . Namun pada saat migrasi muncul faktor penentu kesuksesan migrasi

  1. Perpindahan konten yang harus dilakukan secara masif ,
  2. Perpindahan user yang jumlahnya cukup besar
  3. Perilaku user yang sudah terbiasa dengan sistem eksisting
  4. Infrastruktur pendukung

Kendala yang dihadapi pada poin (1) Perpindahan konten yang dilakukan secara masif adalah

  1. Karakteristif konten yang beragam
  2. Struktur course yang digunakan oleh masing-masing user berbeda-beda
  3. Jumlah course yang sudah sangat banyak

Solusi untuk menangani kendala ini maka langkah yang diambil adalah dengan menjadikan LMS lama sebagai modul yang tetap ‘live’ dan dapat diakses oleh user . LMS lama dalam hal ini dijadikan sebagai modul atau sub bagian dari sistem LMS yg baru . User yang memerlukan bahan materi atau konten dari konten lama bisa mengakses-nya pada saat diperlukan (just in time) .

Kendala yang dihadapi pada poin (2) dan (3) terkait dengan user , 

1. Akses user , dengan jumlah user yang sudah cukup  besar , maka perlu antisipasi supaya user dapat mengakses ke sistem baru tanpa harus registrasi ulang . (registrasi ulang untuk sistem yang sama pasti ‘annoying’) .

2. Privilege user harus sama , sementara sistem baru (LMS 2.4) tidak bisa upgrade secara langsung harus install dari scratch.

3. Look and feel dari sistem , dibuat harus ‘mirip’

4. Tailor made plugins harus tetap bisa jalan dan berfungsi di LMS yang lama .

Solusi untuk menangani ini adalah dengan meng-copy eksisting tabel user pada database lama ke database yang baru . Pada saat coba diterapkan, wow .. struktur tabel berbeda jauh . Membuat SQL yang sudah diimpor harus diedit ulang per row data . (very annoying) . Walaupun sukses dilakukan tetap ada sekian banyak data yang terhapuskan serta membutuhkan waktu yang cukup lama .

Muncul kebutuhan baru juga , bahwa sistem lama tetap bisa diakses dan menjadi satu kesatuan dengan sistem yang baru . Hal tersebut untuk meminimalisir komplen user , karena saat berpindah harus selalu login .

Berkaca dari atas, maka langkah yang perlu dilakukan adalah

  1. membuat modul ‘dbauth’ yang memungkinkan user untuk login dari database lama dan kemudian bisa masuk ke database baru .
  2. membuat modul ‘integrasi’ yang bisa menangkap (catch) session saat user sukses login di aplikasi lama untuk user bisa browsing lintas aplikasi .

Alhasil metodologi tersebut saat ini berhasil diterapkan pada sistem Kuliah Online ITB (http://kuliah.itb.ac.id)  . Untuk optimisasi-nya masih menunggu respon user (komplen) yang diterima dari bagian helpdesk .