Ketika istilah "software engineering"Â pertama kali digunakan pada Konferensi NATO 1968, banyak yang menganggapnya sebagai sebuah lelucon intelektual. Bagaimana mungkin "rekayasa" bisa diterapkan pada sesuatu yang tak terlihat, tak berbentuk, dan masih sangat baru seperti perangkat lunak?
Namun, lima dekade kemudian, artikel karya Nancy Mead, David Garlan, dan Mary Shaw dari Carnegie Mellon University (CMU) membuktikan bahwa bukan hanya mungkin, tapi juga perlu dan mendesak. Dalam artikel berjudul "Half a Century of Software Engineering Education: The CMU Exemplar", ketiganya merefleksikan perjalanan pendidikan RPL, dengan menjadikan CMU sebagai contoh dan tonggak sejarah. Saya melihat tulisan ini sebagai panggilan untuk introspeksi dan aksi.
Pendidikan RPL: Dari Teori ke Studio
Hal yang paling saya kagumi dari pendekatan CMU adalah bagaimana mereka memosisikan pendidikan RPL bukan sekadar sebagai pelatihan teknis, melainkan sebagai pendidikan rekayasa sejati. Mereka menyadari bahwa perangkat lunak adalah produk rekayasa kompleks, yang tidak cukup dikuasai hanya dengan belajar struktur data dan algoritma.
Program Master of Software Engineering (MSE) di CMU, misalnya, sudah sejak awal mengadopsi pendekatan berbasis studio, di mana mahasiswa bekerja dalam tim, mengelola proyek nyata, dan berinteraksi dengan real stakeholders. Ini bukan simulasi, tapi pengalaman langsung yang dirancang untuk menanamkan prinsip-prinsip seperti rekonsiliasi antar batasan, pengambilan keputusan berbasis trade-off, dan tanggung jawab profesional.
Pilar Pendidikan RPL: Kombinasi Ilmu, Teknik, dan Manusia
Artikel ini menekankan tiga fondasi pendidikan RPL yang kokoh:
Teknis (Ilmu Komputer): Pemahaman mendalam tentang abstraksi, struktur, dan model formal.
-
Rekayasa: Penerapan prinsip teknik dalam membangun sistem berkualitas tinggi.
Sosial-Ekonomi: Kesadaran terhadap konteks pengguna, biaya, kebijakan, dan dampak sosial teknologi.
Kita sering melihat program pendidikan saat ini terjebak hanya pada aspek pertama. Kita melatih coder, bukan engineer. Padahal, seperti yang disebutkan oleh penulis, banyak masalah perangkat lunak modern bukan karena kurangnya kemampuan teknis, melainkan karena kegagalan memahami sistem secara holistik, bekerja dalam tim, dan menyadari bahwa setiap baris kode punya dampak.
