TIPS mengerjakan Tugas Proyek Perangkat Lunak
Tugas Proyek adalah bagian yang tak terpisahkan dari Perkuliahan Rekayasa Perangkat Lunak ataupun Analisa Perancangan Sistem. Tidak bisa dipungkiri, saya termasuk dosen yang mempercayai bahwa dengan memberikan "pengalaman" berdasarkan "real-case" kepada mahasiswa, maka teori2 yang berhubungan dengan perangkat lunak, akan bisa dipahami dengan lebih mendalam (entah benar atau tidak, saya hanya berangkat dari "pengalaman" saya sendiri). Alhasil, nilai kelulusan perkuliahan RPL atau ANAPRANCIS ini, akan sangat ditentukan oleh "keberhasilan" mengerjakan Tugas Proyek.
Untuk itu, mahasiswa PERLU menyiasati pembuatan Tugas Proyek tersebut dengan bijak. Berikut ini saya memberikan beberapa TIPS terkait pengerjaan Tugas Proyek Mahasiswa.
1. Kemampuan "SOFT" dalam "staffing the project".
Yang saya maksudkan dengan "staffing the project" adalah berkaitan erat dengan sisi "soft" proyek perangkat lunak. Sisi "SOFT" ini lebih terkait dengan aspek subyektifitas; terutama dalam MEMILIH rekan kelompok. Thumb of Rule dalam memilih rekan kelompok adalah PILIHLAH REKAN KELOMPOK yang bisa bekerja-sama dan bekerja-bersama. Bekerja sama dan bekerja-bersama adalah istilah yang serupa tapi tak sama. Bekerja sama bisa diartikan dengan saling-memiliki-perhatian sedangkan bekerja-bersama diartikan sebagai saling-terlibat. Dalam pandangan saya, keberhasilan kelompok dimana setiap anggotanya kelompoknya bekerja-bersama akan jauh lebih SUKSES jika dibandingkan dengan kelompok yang hanya bekerja-sama; apalagi untuk kelompok yang TIDAK bisa bekerja-sama.
Bertahun-tahun menjadi dosen pengasuh mata kuliah Rekayasa Perangkat Lunak, Analisa Perancangan Sistem, Pemodelan berorientasi Obyek dan Manajemen Proyek Perangkat Lunak; membuat saya semakin menyadari bahwa Keberhasilan Tugas Proyek lebih ditentukan dari sisi "SOFT"; bukan teknis maupun manajemen. Statistik KEBERHASILAN (setidaknya menurut pengalaman saya mengajar) ada pada kelompok2 yang BERHASIL ataupun CUKUP BERHASIL menciptakan suasana kondusif dalam "bekerja-sama" dan "bekerja-bersama". Sedangkan untuk kelompok2 yang hanya "baku-harap" (dialek Manado yang berarti tidak-saling bertanggung-jawab, lepas tangan), cenderung akan GAGAL dalam penyelesaian Tugas Proyek.
2. Aspek Teknis: Pengembang menggunakan “tools” yang baru atau belum dikuasai!
Mahasiswa memiliki kecenderungan untuk menggunakan “new software tools” yang belum pernah mereka gunakan sebelumnya. Mungkin kecenderungan ini disebabkan karena sifat mahasiswa yang ingin “up-to-date” dengan perkembangan terakhir. Mereka berpikir, dengan menggunakan tools yang baru, berarti lebih “modern”. Mereka lupa bahwa dalam pengembangan perangkat lunak, tidak hanya diperlukan tools”yang modern atau super canggih.
Penggunaan tools yang baru tidak dipersoalkan, sekiranya, mahasiswa menyadari bahwa implikasi yang muncul dari pilihan tersebut. Hal pertama adalah semakin dibutuhkan waktu yang lama dalam penyelesaian tugas proyek, karena mahasiswa membutuhkan waktu extra untuk menguasai tools yang baru tersebut. Hal kedua adalah meningkatkan resiko terjadinya “technical problems” akibat dari penggunaan tools yang belum sepenuhnya dikuasai.
Jika memang dalam kegiatan pengembangan perangkat lunak, dibutuhkan penggunaan “tools” yang baru, maka seyogianyalah, mahasiswa yang bersangkutan, bisa menyediakan waktu extra hingga mahir menggunakan tools yang diinginkan.
Aspek teknis ini yang saya nilai sering MENJADI PENYEBAB KEGAGALAN utama bagi mahasiswa2 dalam menyelesaikan Tugas Proyek.
Di sisi lain, seorang dosen SANGAT MENGANJURKAN agar supaya para mahasiswa bisa up-to-date dengan tools terkini; namun, dalam kenyataannya sering terjadi tidak demikian. Pengalaman saya, para mahasiswa cenderung menggunakan tools yang PROPRIETARY (misalnya produk2 dari Microsoft). Mereka telah begitu TERJAJAH oleh Microsoft, sehingga tidak bisa lagi memanfaatkan dengan jeli, produk2 open-source yang GRATIS, TIDAK MENGIKAT DAN MENJAMUR. Sekali lagi, ini adalah masalah "paradigma" berpikir, bukan masalah "teknis".
3. Aspek User: Ketidakpastian “requirements”.
Inilah TANTANGAN yang "sengaja" disediakan oleh dosen pengasuh yang menekankan pada "real-case scenario".
Tugas proyek mahasiswa yang berkaitan dengan pengembangan perangkat lunak, seperti misalnya pembangunan aplikasi tertentu, tak dapat dipungkiri harus berkaitan dengan end-user atau customer sebagai pengguna aplikasi tersebut. Ini berarti kepentingan (atau biasa kita terjemahkan sebagai “needs”) dari end-user harus kita perhatikan.
Proses memahami needs dari end-user merupakan suatu seni tertentu yang harus dikuasai mahasiswa. Kegagalan dalam memahami needs berakibat pada ketidakpastian requirements. Akibat yang terjadi adalah scope-creep; yakni semakin meluasnya requirements dari end-user.
Namun tidak bisa dipungkiri, ketidakpastian “requirements” ini juga disebabkan oleh end-user. Pada umumnya (menurut temuan penulis), end-user sendiri tidak terlalu memahami “requirements” yang mereka inginkan terhadap aplikasi yang akan dikembangkan.
Komitmen pada rencana kerja (seperti WBS) yang telah disepakati sebelumnya merupakan jawaban untuk mengatasi masalah ini. Selain itu, kemampuan mahasiswa dalam menemukan masalah yang akan diselesaikan dengan aplikasi yang akan dibangun merupakan suatu keharusan.
Jika kita mengingat perkataan dari Roger Pressman dalam bukunya yang berjudul Software Engineering: A Practitioner's Approach; maka beliau mengatakan bahwa:
TANTANGAN SESUNGGUHNYA bagi para pengembang aplikasi/sistem perangkat lunak adalah bagaimana membangun aplikasi/sistem yang sesuai dengan "user's needs and expectations".
Dogma ini HARUS dapat dipahami oleh setiap mereka yang menekuni software engineering. Sehingga, menerapkan Tugas Proyek dengan REAL-CASE STUDY adalah PILIHAN MUTLAK yang tidak bisa dihindari. Kesulitan2 yang SUDAH PASTI akan dihadapi oleh Tim Pengembang; harus disiasati dengan bijak.
3. Aspek Teknis: Sistem yang “incomplete”.
Masalah ini sedikit terkait dengan bahasan sebelumnya. Seringkali, mahasiswa terjebak dalam kecenderungan untuk “sesegera” mungkin menyelesaikan aplikasi yang diinginkan end-user; akibatnya mahasiswa tidak berusaha memahami sepenuhnya “proses bisnis” yang dimiliki oleh end-user sebagai bagian dari suatu organisasi yang lebih besar dan kompleks.
Seperti kita ketahui, sekarang ini, kebanyakan proyek pengembangan aplikasi modern ditujukan untuk menunjang “bisnis proses” dari suatu organisasi. Mau tidak mau, para pengembang aplikasi “harus” mencoba memahami gambaran besar bisnis proses yang dimiliki organisasi dan kemudian mengerti gambaran detail, yang mana aplikasi tersebut akan dibangun.
Pemahaman yang tidak komprehensif akan proses bisnis organisasi akan membuat tugas proyek mahasiswa tidak memiliki tingkat integrasi yang memadai dengan aplikasi-aplikasi lain yang telah dikembangkan terlebih dahulu (ataupun yang akan dikembangkan kemudian) dalam organisasi.
Salah satu cara mengatasi hal ini adalah dengan menggunakan metode “prototyping” dalam pengembangan perangkat lunak; sehingga “working-system” bisa segera dibangun mahasiswa dan ditunjukkan kepada end-user. Penyesuaian terhadap “working-system” ini bisa terus-menerus dilakukan hingga kebutuhan dari end-user dipenuhi.
Paradigma pemrograman berorientasi obyek dengan menggunakan metode Unified Software cukup SAKTI untuk mengatasi masalah ini. Sekali lagi, dibutuhkan pemahaman yang komprehensif bagi tim pengembang untuk memahami metode yang akan digunakan.
4. Aspek Manajemen: Kurangnya komitmen end-user dan pengembang.
Faktor ini merupakan salah satu “masalah klasik” dalam pengembangan perangkat lunak. Terlebih bila berhubungan dengan penyelesai tugas proyek mahasiswa. Pihak end-user sering menganggap remeh tugas proyek mahasiswa, apalagi jika penyelesaian tugas proyek tersebut harus menggunakan sumber daya end-user (misalnya waktu untuk wawancara maupun peralatan lain).
Permasalahan yang berkaitan dengan sikap mental dari end-user selaku pemilik proyek maupun mahasiswa selaku pengembang harus disikapi dengan bijaksana. Pihak end-user harus memiliki komitmen yang kuat dalam pengembangan proyek dengan cara memahami manfaat yang dapat diperoleh dari aplikasi yang akan dihasilkan. Pihak mahasiswa pun harus bisa menegaskan komitmen end-user dengan memaparkan rencana kerja proyek dengan terperinci dan menyeluruh. Dengan memiliki pemahaman akan manfaat yang dapat diperoleh dari adanya aplikasi yang akan dikembangkan, diharapkan bisa mempertegas komitmen dari end-user.
Terkadang tim pengembang sendiri tidak mempunyai dan menunjukkan komitmen yang serius dalam menyelesaikan tugas proyek. Sangat disayangkan, dalam pengalaman saya mengajar, maka masih ditemukan para mahasiswa dengan low-level commitment untuk menyelesaikan tugas proyek. Ditambah dengan suasana yang "longgar" dari dosen yang bersangkutan, maka kondisi "low-level commitment" ini akan terus terjadi.
Sekali lagi, ini BUKAN berkaitan dengan masalah teknis; melainkan masalah "moral" dari pribadi mahasiswa ataupun dosen yang bersangkuta. Jika ternyata hal ini terjadi dalam Kuliah yang cenderung hanya membahas Aspek Teknis "how-to" saja ... makan dosen pengajar tidak bisa disalahkan ...(paling tidak, itulah menurut saya). Dalam dunia akademis, tentu saja, kurangnya komitmen mahasiswa akan berpengaruh dalam "nilai akhir"; meskipun aspek penilaian dimensi ini masih subyektif menurut saya. Namun, jika terjadi dalam "dunia kerja" .. maka RESIKO yang ada sangatlah besar.
Selamat mengerjakan Tugas Proyek ...
Tidak ada komentar:
Posting Komentar