Melihat kondisi tersebut tentukan faktor dan karakteristik untuk menjamin kualitas perangkat lunak

KUALITAS PERANGKAT LUNAK:

Definisi, Pengukuran dan Implementasi

Definisi

Berbagai macam definisi kualitas perangkat lunak [software quality] tergantung dari mana pemakai [user] memandang dan melihat sesuai dengan kebutuhannya. Menurut Crosby [1979:34] mendefinisikan kualitas atau mutu sebagai “conformance to requirements”. Selama seseorang dapat berdebat tentang perbedaan antara kebutuhan, keinginan dan kemauannya, definisi kualitas harus mempertimbangkan perspektif pemakai tersebut. Kunci utama pertanyaan untuk sebuah definisi kualitas adalah siapa pemakainya, apa yang penting bagi merekadan bagaimana prioritasnya tentang metode apa yang dibangun, dibungkus untuk mendukung sebuah produk?

 Untuk menjawab pertanyaan tersebut, kita harus mengenali herarki dari kualitas perangkat lunak. Pertama, suatu produk perangkat lunak harus menyediakan fungsi suatu jenis dan waktu yang sama ketika pemakai memerlukannya. Kedua, produk harus berjalan. Jika produk memiliki kecacatan maka produk tersebut tentunya tidak ada konsistensi kelayakan. Para pemakai tidak akan menggunakannya dengan mengabaikan atribut-atribut yang menyertainya. Hal tersebut tidak berarti bahwa kecacatan selalu menjadi prioritas yang paling utama dalam menolak suatu produk tetapi akan menjadi sangat penting dalam melihat layak atau tidaknya. Jika tingkatan cacat minimum belum dicapai maka berbagai hal tidak ada yang perlu dipertimbangkan. Di luar ambang kualitas tersebut, bagaimanapun juga sesuatu yang berhubungan dengan pertimbangan dan penilaian cacat suatu produk perangkat lunak seperti halnya kegunaan, kecocokan, kemampuan, dan lainnya tergantung pada pemakai tersebut memandang dan menilainya termasuk didalamnya aplikasinya dan lingkungan software yang menyertainya [Humphrey, 1994].

The Institute of Electrical and Electronic Engineers [IEEE] mendefinisikan

kualitas sebagai “the degree to which a system, component or process meets customer or user needs or expectations” [IEEE90]. Definisi dari IEEE digunakan dalam konteks suatu sistem perangkat lunak secara rinci. kualitas adalah suatu atribut dari sistem yang berjalan yang sangat erat kaitannya dengan resiko. Semakin tinggi resiko yang didapatkan dan kemudian dikuranginya maka akan tinggi kualitas yang dihasilkannya. Dengan cara yang sama, lebih cepat resiko dikenali dan dikurangi, akan lebih tinggi pula kualitasnya. Hasil dari sebuah aktivitas yang terencana, bukan kejadian yang spontan berbanding terbalik dengan delivery date 85% kesalahan ada pada proses,15% pada pada SDM.

Menurut definisi dalam Steve McConnell’s Code Complete membagi perangkat lunak ke dalam dua hal yaitu: : internal dan external quality characteristics. Karakteristik kualitas eksternal merupakan bagian-bagian dari suatu produk yang berhubungan dengan para pemakainya, sedangkan karakteristik kualitas internal tidak secara langsung berhubungan dengan pemakai. Software Quality didefinisikan sebagai: kesesuaian yang diharapkan pada semua software yang dibangun dalam hal fungsi software yang diutamakan dan unjuk kerja software, standar pembangunan software yang terdokumentasi dan karakteristik yang ditunjukkan oleh software. Definisi ini menekankan pada 3 hal yaitu:

1. kebutuhan software adalah fondasi ukuran kualitas software, jika software

    Tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun kurang

2. jika menggunakan suatu standar untuk pembangunan software maka jika

    software tidak memenuhi standar tersebut maka dianggap kurang berkualitas

3. seringkali ada kualitas yang secara langsung diutarakan [tersirat] seperti

    kemudahan penggunaan dan pemeliharaan yang baik. Kualitas software

    dipertanyakan jika tidak memenuhi kebutuhan ini.

Sedangkan definisi kualitas menurut The International Standards Organization [ISO] mendefinisikannya sebagai: “the totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs [11].” ISO menyoroti pada fitur-fitur dan karakteristik dari produk atau layanan dalam kemampuannya memenuhi kebutuhan yang ditentukan. menyediakan model yang berbasikan obyek dalam 3 konteks dasar yaitu: quality, requirements dan characteristics. Standar dapat membantu mendefinisikan suatu terminologi, seperti halnya kata “kualitas” [quality]. Meskipun demikian, rata-rata suatu kata tertentu tidak menggunakan standar adalah sering sesuai dengan arti yang dimaksud. Hal ini juga benar untuk definisi ISO 8204 untuk mutu: “Keseluruhan karakteristik dari suatu kesatuan dalam kemampuannya untuk memenuhi dan memuaskan pemakai yang dinyatakan dan disiratkan dalam suatu kebutuhan.“ Makna tersebut artinya, diperlukan suatu kualitas produk perangkat lunak yang mempunyai karakteristik tertentu yang dihubungkan dengan kebutuhan pemakai dan membuat puas penggunanya. Kualitas perangkat lunak adalah keberadaan karakteristik dari suatu produk ang dijabarkan dalam kebutuhannya, artinya kita harus melihat terlebih dahulu karakteristik-karakteristik apa yang berhubungan atau tidak dengan kebutuhankebutuhan yang diiinginkan oleh pemakai. Karakteristik yang dimaksud yaitu contra-productive characteristics dan neutral characteristic. Mengetahui

karakteristik tersebut diperlukan untuk mengurangi kontra produktif dari kualitas perangkat lunak yang dimaksud dan relevan atau tidak perangkat lunak tersebut untuk kebutuhan suatu organisasi. Tidak hanya adanya keberadaan karakteristik tersebut tetapi juga tidak adanya kontra produktif dari suatu karakteristik dari suatu perangkat lunak yang diinginkan [Petrasch, 1999: 2].

Kebutuhan dan karakteristik berperan penting dalam mendefinisikan suatu kualitas. Oleh karena itu, suatu model yang berbasiskan obyek bermanfaat dalam pemahaman yang lebih baik untuk masalah ini. Gambar di bawah menunjukkan suatu produk perangkat lunak, dimana untuk memenuhi suatu kebutuhan diperlukan karakteristik yang sesuai. Keberadaan hubungan antara kebutuhan dan karakteristik menjadikan dimungkinkannnta statemen yang jelas tentang kualitas suatu produk. 

Hal lain yang perlu diperhatikan dalam kualitas perangkat lunak adalah quality assurarance [QA] yang merupakan cctivity of providing evidence needed to establish confidence mong ll concerned,that quality-related activities are being performed effectively [J.M.Juran]. Selain itu harus adanya software quality management [SQM]. Tujuan dari SQM adalah untuk mengembangkan suatu pemahaman kuantitatif dari kualitas proyek produk perangkat lunak dan mencapai tujuan spesifik kualitasnya yang digambarkan dalam table sederhana berikut:

Pengukuran Kualitas Perangkat Lunak

Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu: pemodelan proses pengembangan [process], pemodelan pengukuran produk [product], dan pemodelan manajemen dan interaksi manusia [human]. Pemahaman suatu disiplin melibatkan pembangunan model, pengujian model dan pelajaran untuk dipahami dalam aplikasi yang nyatal. Pengembang kualitas prima perangkat lunak harus berhadapan dengan unsur-unsur matriks berikut:

Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN]

Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT]   [T*HUMAN]

Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN]

Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak ditunjukkan pada gambar di bawah. Pengintegrasian dari semua unsur-unsur system kualitas memerlukan suatu model. Permasalahannya untuk diperbaiki oleh dua model berikut [1] penanganan kompleksitas dalam disiplin dari sistem kualitas dantunsur-unsurnya dan [2] penunjukan beberapa kelemahan dari model existing process. Kompleksitas proses pengembangan dan dokumentasinya serta perubahan dokumentasi selama pemeliharaan adalah permasalahan penting dalam peningkatan kualitas. Dokumentasi yang dievaluasi sering sangat banyak dan kompleks. Oleh karena itu, hubungan kompleksitas antara produk data teknis, dokumentasi perencanaan, pengujian kebutuhan dan tahapan unsur-unsur life cycle pengembangan yang berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar semua kelompok terkait dengan pengembangannya dan kendali proses proyek tersebut. Schweiggert mencatat beberapa pertimbangan untuk krisis dokumentasi:

“Software in the application process must be constantly adapted and altered. The

maintenance programmer usually does not have the time alteration to

documentation. Often suitable tools are not available either. This causes the

quality of documentation to suffer”

Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses pengembangan software yang kompleks. Audit dan review tidak bisa dilakukan tanpa menggunakan bantuan dan alat yang membantu mengidentifikasi pemenuhan standar dan prosedur. Lebih dari itu, kompleksitas proses pengembangan dan perubahan yang tak terkontrol dari unsur-unsur proses secara negatif berdampak pada kualitas. Lifecycle pengembangan software yang berbeda dapat diusulkan. Hal ini dapat memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak ada model lifecycle yang universal disesuaikan dengan lingkungan pengembangannya. Dalam model lifecycle tradisional, hubungan antara tahapan unsur-unsur lifecycle pengembangan software yang berbeda tidaklah cukup terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam kebutuhannya yang ditetapkan atas kualitas, keselamatan dan sasaran hasil dari perangkat lunak. Lebih dari itu, keberadaan komputer dapat membantu untuk aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani karena kekompleksitasnya. Dalam lifecycle pengembangan software, Identifikasi hubungan antara kelompok organisasi sangat penting untuk beberapa

pertimbangan berikut: [1] Pengembangan Proses harus berhadapan dengan kompleksitas dan perubahan kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain; [2] Kesalahan perangkat lunak yang dihasilkan baik dalam suatu tahapan proses pengembangan software maupun sebagai alat penghubung antara dua tahapan; [3] Dukungan kuat dari manajemen puncak merupakan suatu faktor utama dalam mempengaruhi proses pengembangan tersebut. Menururut Wahono [2006], Deras masuknya produk perangkat lunak dari luarnegeri di satu sisi menguntungkan pengguna karena banyaknya pilihan produk dan harga. Namun di sisi lain cukup mengkhawatirkan karena di Indonesia tidak ada institusi yang secara aktif bertugas membuat standard dalam pengukuran kualitas perangkat lunak yang masuk ke Indonesia. Demikian juga dengan produk-produk perangkat lunak lokal, tentu akan semakin meningkat daya saing internasionalnya apabila pengembang dan software house di Indonesia mulai memperhatikan masalah kualitas perangkat lunak ini. Kualitas perangkat lunak [software quality] adalah tema kajian dan penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak [software engineering]. Kajian dimulai dari apa yang akan diukur [apakah proses atau produk], apakah memang perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan parameter pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi ke satu sisi masalah [misalnya tentang reliabilitas dan efisiensi perangkat lunak], sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk menggunakan sudut pandang yang lain lagi [usabilitas dan aspek desain].

Apa yang diukur?

Pertanyaan pertama yang muncul ketika membahas pengukuran kualitas perangkat lunak, adalah apa yang sebenarnya mau kita ukur. Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan perangkat lunak [ process] dan hasil produk yang dihasilkan [product]. Dan penilaian ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan sesuai dengan yang diharapkan oleh pengguna. Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara sebagai berikut:

Parameter dan metode pengukuran menurut Kelvin dalam Wahono [2006], When you can measure what you are speaking about, and express it in numbers, you know something about it. But when you can not measure it, when you can not express it in numbers, your knowledge is of a meagre and unsatisfactory kind. Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh manusia. Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi McCall, atribut tersusun secara hirarkis, dimana level atas [high-level attribute] disebut faktor [factor], dan level bawah [low-level attribute] disebut dengan kriteria [criteria]. Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan sebab akibat [cause-effect]. Tabel berikut menunjukkan daftar lengkap faktor dan kriteria dalam kualitas perangkat lunak menurut McCall

Kualitas software diukur dengan metode penjumlahan dari keseluruhan kriteria

dalam suatu faktor sesuai dengan bobot [weight] yang telah ditetapkan. Rumus

pengukuran yang digunakan adalah:

Fa = w1c1 + w2c2 + … + wncn

Dimana:

Fa adalah nilai total dari faktor a

wi adalah bobot untuk kriteria i

ci adalah nilai untuk kriteria i

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai

berikut:

Tahap 1: Tentukan kriteria yang digunakan untuk mengukur suatu faktor

Tahap 2: Tentukan bobot