skripsiatl

Ini adalah pengalaman hidup yang saya alami ketika rapat di kantor.

Saya baru tahu bahwa membuat kenari tua yang lelah berkicau bernyanyi bukan perkara mudah. Selama ini saya menganggap hanya ada tiga cara untuk membuat burung kenari mau bernyanyi (Yoshikawa, 1937).

– Bunuh saja!

– Buat agar burung tersebut ingin bernyanyi.

– Tunggu.

Bisa dikatakan bahwa saya coba ketiganya, namun bisa dikatakan saya gagal.

Ketika ngobrol dengan seorang teman, dia mengajukan pilihan yang berbeda, dan langsung saya praktekkan.

– Pinta agar burung tersebut diam.

Ternyata mangkus lho! Hasil yang selama ini saya inginkan saya dapatkan. beneran deh, “Indonesia is where miracles happen!”, he he he. Lha, orang indonesia ya gitu itu, kalau ada tombol dilarang pencet, dipencet! Ada rambu lalu lintas dilarang berenti, berhenti dia!

Sekedar jahil doank,

Salah satu fungsi dari perekayasa perangkat lunak (atau penganalisa sistem, meski sebenarnya istilah ini sangat menyesatkan) adalah membangun rancangan pengujian validasi dan pengujian performa perangkat lunak.

Bagi pengguna Bahasa Java tentu pernah mengenal JUnit dan konsep Test Driven Software Development (silahkan baca ringkasannya di http://en.wikipedia.org/wiki/Test-driven_development). untuk pengguna .Net, csUnit (http://www.csunit.org/) adalah salah satu alat yang bisa diandalkan.

Alat pengujian unit sesungguhnya hanya merupakan alat pengujian validasi, namun beberapa dirancang untuk mendapatkan waktu eksekusi, sehingga dapat digunakan untuk pengujian performa sederhana.

Skema yang ditawarkan simpel, perekayasa membangun rancangan pengujian unit dengan csUnit (atau alat pengujian lain) dan pemprogram membangun kelas / komponen sesuai dengan standard pengujian tersebut.

Dalam model ini, penurunan rancangan perangkat lunak ke rancangan pengujian dapat memakan 80 % usaha pembangunan perangkat lunak, karena perekayasa harus memastikan seluruh kebutuhan validasi dan performa terangkum dalam rancangan pengujian setiap modul. Pekerjaan pembangunan rencana uji merupakan pekerjaan yang sangat berat.

Bila konsep ini diterapkan, kecepatan kerja seluruh tim pengembangan perangkat lunak bisa turun drastis (dibandingkan metoda pengembangan perangkat lunak tangkas seperti Pemrograman Ekstrem misalnya), namun bila dilaksanakan dengan baik, ngga ada lagi istilah pemrogram salah interpretasi desain, dan refaktor dapat lebih mudah dilakukan (tinggal lihat perubahan kecepatan eksekusinya)

Kalau  konsep ini ditawarkan ke badan pengembang perangkat lunak pembaca, para perekayasanya siap ngga, he he he? Berani ngga, ngambil resiko diuber – uber calon pengguna karena permintaannya ngga kunjung selesai?