Lompat ke konten Lompat ke sidebar Lompat ke footer

Memahami Pengukuran Kualitas Produktivitas Perangkat Lunak

Memahami Pengukuran Kualitas Produktivitas Perangkat Lunak - 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.
Memahami Pengukuran Kualitas Produktivitas Perangkat Lunak_
image source: objectsharp.com
baca juga:
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 Organization for Standarization (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 (w) dari setiap kriteria (biasanya 0 <= w <= 1)
  • Tahap 3: Tentukan skala dari nilai kriteria (misalnya, 0 <= nilai kriteria <=10)
  • Tahap 4: Berikan nilai pada tiap kriteria
  • Tahap 5: Hitung nilai total dengan rumus Fa = w1c1 + w2c2 + … + wncn


Contoh pengukuran perangkat lunak

Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan elektronik (electronic device). Perangkat lunak yang pertama bernama TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran dapat dilihat pada Table 3 dan 4.


Dari penghitungan yang ada di Tabel 4, dapat kita simpulkan bahwa dari faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8, sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).

Mengapa Software Quality Engineering perlu dipikirkan?

Penerapan suatu rumusan pemrograman sederhana jawaban bisa diperkenalkan cara yang berikut:
RISK= F (1/quality) Atau kualitas yang ditingkatkan untuk mengurangi resiko
Suatu metode di mana hasil dari resiko dari kualitas yang pudar dapat dimanifestasikan lebih banyak, bagaimanapun untuk seorang pemakai yang berpengalaman dikenali dalam contoh berikut:

  • Kerugian Sosial atau profesional (nformasi/data, waktu, uang, pekerjaan dll.)
  • Kerugian kesehatan atau kehidupan ( contoh: pasien over-X-rayed dalam suatu  rumah sakit)


Jelaslah bahwa sebagai pemakai mungkin akan bermimpi untuk mengharapakan adanya bug-free yang merupakan tingkatan paling tinggi kualitasnya dengan harga yang serendah-rendahnya. Akan tetapi seberapa besar hal tersebut terjadi, tergantung dari SQE oleh perusahaan pengembangan software. Paling mungkin ada suatu kesempatan untuk tidak membeli perangkat lunak yang jelas ada cacat produksinya. Rendahnya kualitas perangkat lunak merupakan resiko yang didapat suatu organisasi yang membelinya dan terkadang suatu pengembang ataupun supplier tidak ambil pusing bahkan tidak mau disalahkan.

Berdasarkan pengalaman, resiko yang paling besar sebagai hasil dari rendahnya kualitas perangkat lunak sering didapatkan oleh pemakai dan hanya sedikit yang didapatkan oleh penyalur perangkat lunak. Karena itu harus ada suatu kompromi antara developer atau supplier dan pemakai tentang perangkat lunak yang akan dibeli sehingga diharapkan tidak ada yang dirugikan dari transaksi yang terjadi. Menentukan Kualitas Perangkat Lunak Dipandang dari sudut hipotesis, para ahli dalam membuat dan menentukan kualitas perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi dan meningkatkan mutu perangkat lunak sepanjang lifecycle-nya. Pengetahuan yang luas tentang rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan sistematis dengan mempertimbangkan pengalaman yang diperolehnya. Jika mungkin, disesuiakan dengan praktek industri sebenarnya.

Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements didapatkan dengan adanya prasyarat:

  • Kualitas kebutuhan (Quality requirements)
  • Pengukuran kualitas dan instrument evaluasi (Quality measurement and evaluation instruments)
  • Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation)


Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat diperlukan terutama bagi kalangan ahli software dalam mempertimbangkan dan memperoleh kebutuhan yang berkualitas sehingga benar-benar didapatkan high-level stakeholder’s requirements. Karena itu untuk mendapatkan kemudian untuk QR digambarkan pengukuran kualitas dalam gambar di bawah ini:


Model dekomposisi yang diusulkan didasarkan pada model kualitas dari ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External Quality requirements), yang mana pada gilirannya berperan untuk menetapkan kebutuhan mutu internal (Internal Quality requirements). Model tersebut didokumentasikan dengan baik sehingga relatif mudah untuk dipelajari dan digunakan akan tetapi sedikit statis dalam perubahannya. Karena itu, ahli SQ yang baik seharusnya mengetahuinya tidak hanya apa? tetapi juga bagaimana? Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan dan mengendalikan kualitas kebutuhan.


Pada gambar di atas, anak panah dengan garis yang tidak putus-putus menunjukkan alur tentang ” bagaimana”, yaitu menanyakan tentang eksekusi dekomposisi kebutuhan. Yang ada dalam kotak berisi tentang pertanyaan ” apa ” , yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses dekomposisi. Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari traceability kebutuhan. Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas membutuhkan ahli yang berkompeten tentang SQ untuk mengatur proses definisi dan analisis kebutuhan. Komponen dari The Quality measurement and evaluation instruments memiliki tujuan untuk mendidik para ahli SQ tentang keberadaan model kebutuhan dan mengukur pemilihan perangkat lunak dalam proses mendukung aktivitasnya. Demikian juga, dua unsur tersebut sebaiknya didokumentasikan sehingga mudah untuk dipelajari walau sedikit statis. Rancang bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu instrumen ke dalam tahapan lifecycle perangkat lunak trlihat pada gambar di bawah sangat sedikit didokumentasikan dan memerlukan riset lebih lanjut.


Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh dua Komponen yang sebelumnya di mana pengetahuan dasar telah didaptkan. Implementasi sekarang memerlukan aplikasi yang praktis tidak sekedar dengan pengetahuan tersebut tetapi juga dalam proses pengembangan perangkat lunak.

Sekian artikel tentang Memahami Pengukuran Kualitas Produktivitas Perangkat Lunak. Semoga bermanfaat.
Nikita Dini
Nikita Dini Blogger, Internet Marketer, Web Designer

Posting Komentar untuk "Memahami Pengukuran Kualitas Produktivitas Perangkat Lunak"