Rekayasa Perangkat Lunak Dian Wahyuningsih, S.Kom., MMSI

Mengapa harus belajar RPL Mengapa kita harus bersusah payah mempelajari RPL? Benarkah RPL berguna di dunia kerja? Siapa yang harus tau tentang RPL? Dan banyak lagi pertanyaan mengapa harus belajar “Rekayasa Perangkat Lunak” Jawaban yang pasti sangat sederhana adalah “Bahwa setiap pengembangan dan pembuatan perangkat lunak dengan disadari atau tidak, sesungguhnya selalu menjalankan langkah-langkah dari teori dan konsep RPL itu sendiri” Pasti banyak diantara kita, bahkan mungkin semuanya mengeluh dan bertanya, kenapa sih kita harus mempelajari matakuliah RPL? Bener nggak sih RPL itu nanti berguna pas di dunia kerja? Jawabannya pasti akan berguna Siapa yang harus tau tentang RPL? Yang pasti Dosen RPL, pengembang PL, bagaimana dengan pelanggan dan pengguna PL itu sendiri? Jika pelanggan mengerti tentang RPL, bisa kah kita membodohi orang tersebut?

Analogi... Pemusik yang belajar otodidak, yang tidak pernah mengenal not balok. Pemusik yang benar-benar paham tentang teori partitur. Bisakah keduanya memainkan alat musik? BISA Tapi bagaimana jika keduanya ditantang untuk bermain dalam sebuah orkestra? Siapa yang akan cepat beradaptasi? Dan kenapa? Tentu pemusik yang paham partitur yang akan mudah beradaptasi.

Analogi lanjutan... Programmer yang belajar otodidak untuk mengembangkan perangkat lunak. Programmer yang paham tentang bagaimana mengembangkan perangkat lunak. Bisakah mereka berdua menghasilkan perangkat lunak? BISA Tapi bagaimana jika keduanya ditantang dalam sebuah tender untuk membuat perangkat lunak? Manakah yang akan menang? Pemenangnya dapat dilihat dalam dua kacamata berbeda? Kita dapat melihatnya dari jawaban yang dipilih dari 3 pilihan ini “cepat, tepat, murah” Jika pelanggan memilih cepat dan tepat maka programmer yang paham RPL akan menang, namun jika yang dipilih adalah murah maka yang menang adalah programmer otodidak. Kenapa demikian?

Contoh: pentingnya memahami konsep dasar RPL Bagi Praktisi: Meski PL yang dihasilkan sudah dianggap “berkualitas” tetapi dalam sebuah proyek PL tetaplah dibutuhkan langkah-langkah yang secara teoritis sebenarnya telah tersedia dan nantinya akan mempermudah proses kerja, terlebih jika proyek PL yang dikerjakan memiliki skala yang cukup besar dan komplek sehingga membutuhkan kerjasama tim yang tidak sederhana. Saat sebuah proyek PL memasuki fase instalasi ke pelanggan/ pengguna, masih sangat lazim ditemui pengembang PL yang tidak begitu paham tahapan RPL pasca dianggap “selesai”, contohnya: proses penjaminan mutu, proses dokumentasi, dll yang pada akhirnya membuat praktisi terkesan tidak dapat dipercaya. Hal tersebut bukan berarti mereka tidak mampu melakukannya, namun lebih mengarah pada kenaifan pengembang dalam memahami konsep RPL.

Bagi Mahasiswa/ Akademisi: Bagi pengguna: Pengguna wajib memahami mengenai konsep dasar RPL, meski tidak memahami konsep secara utuh, tetapi selayaknya wajib memahami konsep RPL pasca PL dianggap layak pakai. Contoh umum, pengguna yang membeli PL hasil outsourcing berkewajiban memahami konsep RPL pasca produksi agar tidak terjadi kegagalan implementasi proyek. Misal tidak adanya proses testing proyek terhadap pengguna dan yang lebih penting tidak tersedianya dokumentasi tentang penggunaan perangkat lunak. Bagi Mahasiswa/ Akademisi: Dalam beberapa referensi, matakuliah RPL seharusnya berada pada semester awal karena merupakan pondasi awal dari segala jenis matakuliah yang diajarkan pada tahap selanjutnya. Konsep dasar RPL layaknya sebuah pondasi gedung yang tak terlihat tapi harus sangat kuat agar gedung dapat berdiri kokoh. Konsep dasar RPL merupakan langkah awal untuk mempelajari Pemrograman Berorientasi Objek, Desain Berorientasi Objek, APSI, sehingga PL yang dibangun dapat lebih terencana dan tertata dan proses pengembangannya menjadi lebih efektif dan efisien. Setelah kita tau pentingnya matakuliah RPL, selanjutnya masuk pada materi dasar RPL.

Evolusi PL Pengembangan PL dibagi menjadi 5 tahap, yaitu: Tahap Pertama (1950 – 1960) : ciri-ciri nya berorientasi Batch, distribusi software nya terbatas sehingga bersifat custom software. Tahap Kedua ( 1960 – 1970) : ciri-ciri nya multi user dan dapat saling berbagi (adanya interaksi antara manusia dan komputer), real time, product software, serta mulai muncul istilah database dalam PL. Tahap Ketiga (1970 – 1990) : PL sudah menggunakan sistem terdistribusi Tahap Keempat (1990 – 2000) : penemuan kecerdasan buatan, jaringan syaraf tiruan, sistem pakar dan logika fuzzy. Jaringan komputer, pemrosesan komputer paralel sangat mendominasi pada era ini Tahap kelima (2000 – sekarang) : penggunaan media digital, media web berkembang pesat, meluasnya wireless, teknologi meluas hingga ke mobile computing, mobile programming, perangkat keras sudah semakin kecil namun powerfull, dilakukan berbagai penelitian yang menghasilkan model proses / paradigma pengembangan PL untuk mengatasi krisis PL Hanya dibuat sesuai pesana Sudah banyak produk yang dilempar ke pasaran. Perangkat lunak sudah menggunakan sistem terdistribusi, sehingga penyampaian informasi dari komputer sumber ke komputer tujuan akan terasa sangat cepat. Dalam era ini, perangkat keras dari suatu komputer harganya sangat murah.  Selain itu, pesanan perangkat lunak sudah sangat mendominasi dari penyelesaian suatu masalah sehingga penggunaan software pada masa itu sudah sedemikian jauh. Tingkat kecerdasan dari perangkat lunak semakin ditingkatkan sehingga perangkat lunak atau software dilatih mempunyai kecerdasan seperti yang dimilik manusia.  Terbukti dengan adanya penemuan kecerdasan buatan, jaringan syaraf tiruan, sistem pakar dan logika fuzzy. Jaringan komputer, pemrosesan komputer paralel sangat mendominasi pada era ini.  Dan, pada masa ini pula pemrograman sudah berorientasi obyek (OOP).

Pendahuluan Perangkat lunak dan rekayasa perangkat lunak! Apa perbedaanya? Perangkat lunak komputer : merupakan produk yang dibuat oleh pengembang perangkat lunak yang dapat membantu dalam jangka waktu yang panjang. Rekayasa perangkat lunak : secara umum RPL adalah sebuah disiplin ilmu yang mencakup segala hal yang berhubungan dengan proses pengembangan PL sejak dari tahap perancangan hingga implementasi serta pasca implementasi sehingga siklus hidup PL dapat berlangsung secara efisien dan terukur.

Perangkat Lunak Produk PL Karakteristik PL Generic : PL yang dibuat untuk dijual atau dipopulerkan. Contoh SO dan perangkat pendukungnya (aplikasi perkantoran, dll). Custom : PL yang dibuat karena ada pesanan. Karakteristik PL PL dibangun dengan rekayasa, bukan diproduksi secara manufaktur atau pabrikan. PL tidak pernah usang, karena kecacatan PL dapat diperbaiki. Barang produksi pabrikan biasanya komponen barunya akan terus diproduksi, namun PL biasanya terus diperbaiki (update).

Aplikasi dari PL PL sistem : kumpulan program yang ditulis untuk memenuhi kebutuhan program yang lain (compiler, editor, driver, dll) PL real time : PL yang memonitor, menganalisis, mengontrol sesuatu secara waktu nyata, reaksi yang dibutuhkan pada PL harus langsung menghasilkan respon yang diinginkan (ATM, SI pemesanan tiket pesawat, dll) PL bisnis : PL mandiri yang mengelola informasi bisnis (aplikasi penjualan, pembayaran, dll) PL untuk rekayasa dan keilmuan : PL yang mengimplementasikan algoritma yang terkait dengan keilmuan (PL bidang astronomi) PL tambahan (embedded software) : PL yang berada dalam suatu produk/ sistem dan digunakan untuk menjalankan dan mengendalikan fitur dan fungsi sistem itu sendiri (fungsi digital dalam mobil seperti kendali bahan bakar, dll) PL komputer personal : PL untuk PC (office untuk pemrosesan teks, angka, dll) PL berbasis web : PL yang dapat diakses menggunakan browser.

Rekayasa Perangkat Lunak Kriteria PL antara lain: Dapat terus dipelihara setelah PL selesai dibuat seiring berkembangnya teknologi dan lingkungan (maintainability) Dapat diandalkan dengan proses bisnis yang dijalankan dan perubahan yang terjadi (dependability dan robust) Efisien dari segi sumber daya dan penggunaan Kemampuan untuk dipakai sesuai dengan kebutuhan Sehingga untuk dapat menjadi PL yang baik adalah PL harus dapat memenuhi kebutuhan pelanggan atau pemakai atau berorientasi pada pelanggan, bukan berorientasi pada pembuat. Karena RPL adalah sebuah kegiatan untuk membangun dan menggunakan prinsip rekayasa untuk menghasilkan PL yang bernilai ekonomi yang dipercaya dan bekerja secara efisien menggunakan mesin, pada akhirnya banyak PL yang sudah dibuat tidak dapat digunakan karena tidak memenuhi kebutuhan pelanggan atau ada masalah non teknis seperti pelanggan yang enggan memakai PL dengan berbagai alasan. Oleh karena itu

Proses RPL Tahapan umum RPL Dapat diibaratkan seperti membuat baju, ada proses perencanaan model, membuat pola, memotong kain dan dijahit, dilanjutkan dengan pengepasan oleh pengguna. Proses tersebut dapat dilakukan berulang-ulang sampai PL memenuhi kebutuhan pengguna. Untuk membangun PL yang baik diperlukan tahan RPL, PL yang dibangun tanpa tahapan rekaya seperti membuat baju tanpa pola. Baju jadi namun belum tentu enak/ pas untuk dipakai

Proses PL Pengumpulan spesifikasi (specification) : mengetahui apa saja yang harus dapat dikerjakan sistem PL dan batasan pengembangan PL. Pengembangan (development) : pengembangan PL untuk menghasilkan PL. Validasi (validation) : memeriksa apakah PL sudah memenuhi keinginan pelanggan. Evolusi (evolution) : mengubah PL untuk memenuhi perubahan kebutuhan pelanggan.

Praktik RPL Esensi Pahami permasalahannya (komunikasi dan analisis) : (1) Siapa saja yang terkait dalam pemecahan masalah/ siapa stakeholdernya? (2) Apa saja yang tidak diketahui/ data, fungsi, fitur apa yang dibutuhkan untuk memecahkan masalah? (3) Dapatkah masalah dikategorikan/ menyajikan masalah menjadi lebih kecil agar mudah dipahami? (4) dapatkah masalah terwakili secara grafis? Rancang solusinya (pemodelan dan rancangan PL) : (1) Pernahkah menemui masalah serupa? (2) Pernahkah masalah serupa dipecahkan? (3) Dapatkah sub masalah didefinisikan? (4) Dapatkah kita mengajukan solusi yang menghasilkan implementasi yang efektif? Laksanakan rancangannya (pengaktifan kegiatan penulisan kode) : (1) Apakah solusinya cocok dengan rencananya? (2) Apakah masing-masing komponen solusi terbukti tepat? Periksa ketepatan hasilnya (pengujian dan penjaminan kualitas) : (1) Mungkinkah kita menguji setiap komponen? (2) Apakah solusi menghasilkan sesuatu yang cocok dengan data, fungsi dan fitur yang dibutuhkan? beberapa pertanyaan sederhana untuk dapat menggali setiap esensi

Prinsip umum Alasan keberadaan PL Tetap sederhana Pertahankan Visi Apa yang dibuat akan dipakai oleh pelanggan Membuka diri terhadap masa depan Rancanglah selangkah kedepan sehingga dapat digunakan kembali Berpikirlah

Teknologi Informasi Sosial Sebuah PL dianggap berkualitas jika memenuhi kebutuhan pelanggan dan sesuai keinginan pelanggan. Kendala sering kali muncul bukan karena masalah teknik pengembangna PL, namun sering kali pada kondisi lingkungan pelanggan, misal pelanggan yang “gaptek”, pelanggan yang tidak mau beralih ke sistem terkomputerisasi, disiplin, dll. Sehingga, beberapa hal yang perlu dilakukan sebelum mulai menggembangkan PL: Pengetahuan lingkungan tentang teknologi informasi dan komputer. Pengetahuan tentang budaya lokal (“social knowledge/ local knowledge”), apakah lingkungan memungkinkan untuk dikembangkannya PL. Pengetahuan tentang apa saja yang bisa dibatasi dan yang tidak, sehingga saat pengembangan PL dapat mendefinisikan aturan main dari PL. Tidak gaptek Misal mengembangkan PL web pada daerah terpencil yang tidak mendukung Internet Jangan sampai pada saat mengembangkan PL pengguna menambahkan sesuatu diluar kesepakatan, misal mengubah teknologi yang dipakai.

Konversi PL Setelah PL selesai dikembangkan dan siap digunakan, harus ada pelatihan secara bertahap, karena mengubah kebiasaan lingkunagn tidak semudah membalikkan telapak tangan, dibutuhkan penyesuaian pada pengguna PL, yang terpenting adalah komunikasi dan kerjasama yang baik antara pengembang dan pengguna. Ada 4 cara melakukan konversi dari cara kerja lama ke cara kerja baru, harus dilihat sumber daya, dana dan waktu yang dibituhkan. Konversi paralel Konversi langsung Konversi per fase Konversi pilot / single location Menjalankan kedua sistem bersama-sama sampai sistem baru dapat berjalan mandiri. Diperlukan banyak waktu dan tenaga Dilakukan pergantian secara ekstrim dari sistem lama ke sistem yang baru. Sulit di awal namun tidak akan memakan waktu yang lebih lama Dilakukan perubahan per fungsi kegiatan, misal tahap pertama fungsi entri data, dilanjutkan dengan tahap perhitungan, lanjut lagi ke tahap pelaporan, sampai semua tahapan selesai. Dilakukan konversi per unit kerja, misal tahap pertama bagian penerimaan, dilanjutkan dengan bagian akademik, lalu bagian keuangan.

Time to quiz....