Kualitas Perangkat Lunak

Ini lanjutan dari bahasan sebelumnya mengenai rekayasa perangkat lunak...

B. Kualitas Perangkat Lunak

Kapankah kita dapat menyatakan bahwa sebuah perangkat lunak berkualitas ? 

Apa saja yang dijadikan sebagai parameter kulitas perangkat lunak ?

Perangkat lunak dapat dikatakan sebagai perangkat lunak yang berkualitas apabila :

1.      Perangkat lunak tersebut memenuhi keinginan pemesan atau pihak yang menggunakannya (user).

Keinginan user tersebut meliputi beberapa aspek, antara lain fitur dan antarmuka.

2.     Perangkat lunak tersebut  berfungsi dan dapat diimplementasikan dalam jangka waktu yang relatif lama.

3.     Mudah dimodifikasi untuk memenuhi kebutuhan yang berkembang.

4.     Mudah digunakan.

5.     Dapat mengubah atau membangun sesuatu dengan lebih baik. Sebagai contoh, bila perangkat lunak dikembangkan untuk menggantikan suatu proses atau fungsi manual, maka perangkat lunak tersebut harus dapat memberikan nilai tambah terhadap proses atau fungsi yang terdahulu.

Nilai tambah yang diberikan antara lain kecepatan pemrosesan, kemudahan proses, dan kehandalan data (jaminan bahwa data yang diolah, proses yang dilakukan, dan informasi yang dihasilkan adalah benar).

Dan dengan pertanyaan sebelumnya, kita dapat mengajukan pertanyaan “Kapan perangkat lunak dikatakan gagal atau tidak berkualitas ?”.

Baca Selengkapnya...

Perangkat lunak dikatakan gagal apabila :

1.      User tidak puas terhadap performansi perangkat lunak.

2.     Memiliki banyak kesalahan (error, kenyataan yang terjadi pengembang tidak mengakui bahwa dia telah melakukan kesalahan, sehingga dia mengatakan bahwa dalam perangkat lunaknya terdapat bugs = kutu).

3.     Bila perangkat lunak tersebut sulit untuk dimodifikasi untuk kebutuhan yang berkembang.

4.     Bila perangkat lunak tersebut sulit untuk dioperasikan.

5.     Menghasilkan sesuatu yang tidak dikehendaki. Misalnya perangkat lunak saat diperasikan, mengakibatkan register sistem menjadi kacau, sehingga sistem operasi yang kita gunakan menjadi tidak stabil.

Kita semua ingin membangun perangkat lunak yang berkualitas. Agar keinginan kita tersebut dapat tercapai, kita membutuhkan suatu disiplin ilmu untuk mendesain dan membangun perangkat lunak. Kita membutuhkan pendekatan rekayasa perangkat lunak.

B.1 Pentingnya Proses Rekayasa Perangkat Lunak

Setelah kita mengetahui gambaran umum perangkat lunak yang berkualitas dan kita pun ingin untuk dapat membangun perangkat lunak yang berkualitas. Kemudian mungkin timbul pertanyaan di pikiran kita. Mengapa kita mesti melalui tahap-tahap pembangunan perangkat lunak yang terlihat rumit dan harus melewati tahap-tahap tertentu? Mengapa kita tidak langsung menulis kode program perangkat lunak kita sambil mengira-kira dan menentukan fitur-fitur apa saja yang bakal dimiliki oleh perangkat lunak kita?

Pengembangan perangkat lunak secara umum melalui beberapa tahap yaitu:

1.      Analisis   2. Desain  3. Pengkodean   4. Testing  5. Maintenance atau perawatan

Memang pertanyaan atau ungkapan yang kita pikirkan sebelumnya, benar untuk pembangunan sebuah perangkat lunak yang kecil. Kita tidak perlu melewati tahap-tahap rekayasa perangkat lunak tersebut. Yang kita perlukan adalah sedikit analisis kebutuhan perangkat lunak. Kita hanya perlu mengetahui apa fungsi perangkat lunak yang akan kita bangun, siapa pemakainya, akan dioperasikan dalan lingkungan operasi dan implementasi apa, dan beberapa pertimbangan sederhana lain. Contoh sebuah perangkat lunak kecil yaitu : perangkat lunak untuk menghitung faktorial, konversi suhu Celcius ke Fahrenheit, dan sebagainya.

Ukuran perangkat lunak relatif sulit untuk ditentukan. Bila kita membandingkan ukuran pengembangan perangkat lunak dengan pembangunan sebuah gedung, pembangunan sebuah gedung relatif lebih mudah kita tentukan. Misalnya dengan parameter luas lahan, lokasi, dan jenis bahan. Namun perangkat lunak membutuhkan disiplin-disiplin ilmu lain (software metrics dan software measurement) untuk dapat menentukan ukuran perangkat lunak. 

Namun mungkin sebagai pedoman kita, perangkat lunak dapat diukur dengan Kilo Lines of Codes (KLOC) atau baris kode program dalam ribuan. Bila perangkat lunak yang kita bangun, memiliki proses yang masih tergolong sederhana dan kira-kira hanya memiliki beberapa puluh baris instruksi, maka proses  rekayasa perangkat lunak kurang perlu kita butuhkan. Kita hanya perlu membuat sedikit dokumentasi teknis perangkat lunaknya saja. Dan sebagai saran, tambahkan komentar-komentar program pada program-sumber kita. Sehingga bila perangkat lunak perlu dikembangkan, kita dapat mengetahui pada proses yang mana kita akan melakukan modifikasi.

Namun sebagai seorang analis/desainer perangkat lunak, kita akan sering bergelut dengan pengembangan perangkat lunak yang berukuran sedang hingga sangat besar.

Nah, sehubungan dengan pertanyaan awal tadi, Mengapa kita mesti melalui tahap-tahap pembangunan perangkat lunak yang terlihat rumit dan harus melewati tahap-tahap tertentu? Mengapa kita tidak langsung menulis kode program perangkat lunak kita sambil mengira-kira dan menentukan fitur-fitur apa saja yang bakal dimiliki oleh perangkat lunak kita? Kita akan dengan mudah memahaminya dengan meninjau mitos-mitos yang ada di masyarakat dan kenyataan yang terjadi.

B.3 Mitos Tentang Perangkat Lunak

Dalam pengembangan perangkat lunak, terutama pada awal manusia mengenal perangkat lunak, selalu ada mitos-mitos yang tertanam di pikiran dan sikap manusia. Dari tingkat pelaku manajemen, komsumen, hingga ke pelaku teknis (pengembang PL), selalu memiliki anggapan-anggapan dan sikap yang ternyata tidak dapat diterapkan pada pengembangan perangkat lunak :

1.   Mitos pada tingkat manajemen

Manajer yang bertanggung jawab terhadap pengembangan perangkat lunak, seperti manajer di bidang-bidang lain, sering berada dalam tekanan dalam pengelolaan budged, pelaksanaan rencana sehingga sesuai jadwal, dan tangung jawab untuk meningkatkan kualitas bisnis. Mereka berpegangan pada mitos perangkat lunak untuk mengurangi tekanan ini.

a.    Mitos: Orang-orang kami memiliki piranti pengembangan perangkat lunak yang modern dan kami juga memiliki komputer yang memanfaatkan teknologi terbaru. Kami pasti dapat membangun PL yang sangat berkualitas.

Fakta: Pengembangan perangkat lunak membutuhkan lebih dari sekedar komputer atau bahkan mainframe terbaru. Computer Aided Software Engineering (CASE) tools atau piranti bantu pengembangan perangkat lunak, (alat bantu dan metode rekayasa perangkat lunak, contohnya SSADM, Power Analist) lebih dibutuhkan dari sekedar perangkat keras yang berteknologi terbaru.

b.   Mitos:   Jika jadwal pengembangan perangkat lunak terlambat dari rencana, kita dapat menambah programmer (sering disebut Mongolian Horde Concept).

        Fakta:  Pengembangan perangkat lunak bukan proses mekanis seperti proses manufaktur. Dalam bukunya “The Mythical Man-Month ”, F. Brooks mengatakan “Adding people to a late project makes it later”. Artinya dengan menambah pemrogram dalam sebuah pengembangan perangkat lunak yang terlambat, akan memperlambat pengembangannya. Karena ketika pemrogram baru ditambahkan, programmer yang telah bekerja sebelumnya, harus menghabiskan waktu untuk mengajari dan menjelaskan sistem yang sedang dibangun, sehingga akan banyak waktu terbuang. Penambahan sumber daya manusia dalam proyek pengembangan perangkat lunak dapat dilakukan dengan rencana awal yang matang.

2.   Mitos pada konsumen (customer)

a.    Mitos: Pernyataan global mengenai tujuan pemesanan perangkat lunak telah cukup untuk digunakan sebagai dasar memulai penulisan program, detail kemudian.

Fakta:   Definisi awal yang kurang jelas merupakan sebab utama kegagalan pengembangan perangkat lunak. Deskripsi yang formal dan detil terhadap domain, fungsi, perilaku, performansi, antarmuka, batasan desain, dan kriteria validasi adalah hal yang vital. Karakteristik-karakteristik ini hanya dapat ditentukan melalui komunikasi antara konsumen (customer) dan pengembang.

b.   Mitos:   Kebutuhan perangkat lunak memungkinkan untuk berubah, tapi tenang saja karena perubahan itu akan mudah diakomodasi karena perangkat lunak bersifat fleksibel.

Fakta:    Benar bahwa kebutuhan PL dapat berubah, tetapi efeknya bermacam-macam, tergantung kapan perubahan tersebut dilakukan. Semakin dini perubahan kebutuhan tersebut dilakukan, maka biaya (tenaga) yang dibutuhkan semakin kecil.

  

3.   Mitos pada pengembang perangkat lunak

a.    Mitos:   Sekali kita telah menulis program yang berhasil dieksekusi, maka tugas kita telah selesai

Fakta:   Bahwa semakin cepat kita memulai menulis program (coding) sebelum semua analisa dan desain selesai, maka waktu yang kita butuhkan untuk menyelesaikan perangkat lunak akan semakin lama. Hal ini berhubungan dengan proses analisa kebutuhan, pencarian kesalahan, manajemen perubahan perangkat lunak, dan berbagai aspek lain yang semakin sulit dirunut.

                Kemudian, sebenarnya tugas yang lebih berat adalah pasca coding, yaitu testing dan delivery ke customer. Selalu dibutuhkan penyesuian terhadap sitem customer dan customer memerlukan layanan support dan service. Bila kita ingin usaha kita di bidang pengembangan perangkat lunak ini terus berjalan, maka kita harus mempertimbangkan beberapa hal tersebut.

b.   Mitos:   Satu-satunya produk (deliverable) yang penting untuk kesuksesan suatu produk adalah program yang dapat dieksekusi.

Fakta:   Program yang dapat dieksekusi (working program) hanyalah salah satu elemen dari produk konfigurasi perangkat lunak. Dokumentasi dan petunjuk support perangkat lunak adalah elemen lain yang sangat penting.

c.    Mitos:     Dokumentasi perangkat lunak hanyalah sebagi kumpulan dokumen yang membebani dan tidak berarti, yang dapat memperlambat kerja kita.

Fakta:     Rekayasa perangkat lunak bukanlah hal tentang pembuatan dokumen, tetapi merupakan proses pembangunan kualitas. Kualitas yang bagus berdampak kepada pengurangan usaha kerja ulang untuk perbaikan dan perubahan yang memang sering dan selalu terjadi, sehingga pada proses berikutnya kita dapat menghemat waktu.