ISO 9126

Setelah beberapa tahun, beberapa daftar karakteristik Kualitas perangkat lunak ditampilkan, seperti James McCall dan Barry Boehm. Mengetahui kesulitan pada definisi kualitas perangkat lunak yang baik dengan cara, misalnya menjadikan kesenangan kepada kesalahan perangkat lunak yang dapat ditolerir dan diperbaiki. Untuk beberapa ‘ketahanan’(robustness) yang berarti toleransi kesalahan input pada perangkat lunak, dengan kemampuan untuk merubah kode program tanpa menampilkan kesalahan. Standard ISO 9126 pertama kali diperkenalkan pada tahun 1991 melalui pertanyaan tentang definisi Kualitas perangkat lunak. Dokumen halaman-13 yang asli didesain sebagai fondasi lebih jauh, lebih detail, dan memiliki standard yang dapat diolah. Dokumen standard ISO 9126 sangat panjang. Hal ini dikarenakan orang memiliki motivasi berbeda yang memungkinkan untuk tertarik pada kualitas perangkat lunak :

• Acquirer adalah orang yang memperoleh perangkat lunak dari supplier eksternal.
• Developer adalah orang yang membangun produk perangkat lunak.
• Evaluator independent adalah orang yang menetapkan kualitas produk perangkat lunak – tidak untuk dirinya sendiri tetapi untuk komunitas user – misalnya melalui jenis tool tertentu dari sebuah perangkat lunak sebagai bagian dari aktifitas profesional.
  

ISO 9126 telah membagi dokumen menjadi tiga bagian kebutuhan. Disamping ukuran bagian dokumentasi, ISO 9126 tidak hanya mendefinisikan atribut kualitas perangkat lunak. Standard ISO 14598 memisahkan prosedur yang seharusnya dibawa saat menaksir derajat produk perangkat lunak untuk menyesuaikan diri pada karakteristik kualitas ISO 9126 yang dipilih. Hal ini mungkin saja tidak diperlukan, tetapi disetujuinya ISO 14598 dapat digunakan untuk menyelesaikan penilaian dalam membedakan bagian karakteristik kualitas pada ISO 9126 yang dibutuhkan.
Perbedaan antara atribut kualitas internal dan eksternal telah dicatat, ISO 9126 juga memperkenalkan tipe kualitas – quality in use – dimana mengikuti elemen yang telah diketahui :

• Effectiveness merupakan kemampuan untuk mencapai tujuan user melalui akurasi dan kelengkapan.
• Productivity merupakan upaya menghindari kelebihan penggunaan sumber daya, seperti biaya staff dalam mencapai tujuan user.
• Safety merupakan upaya menghindari kejahatan level resiko untuk orang dan entitas lain seperti business, perangkat lunak, property dan lingkungan
• Satisfaction merupakan kepuasan user dalam menggunakan perangkat lunak.

User pada konteks ini adalah orang yang tidak hanya bekerja secara nyata pada sistem perangkat lunak yang akan dibuat, tetapi juga orang yang akan merawat dan meningkatkan perangkat lunak. Ide kualitas dalam penggunaan underlines adalah Bagaimana mempersiapkan kualitas perangkat lunak sebagai atribut yang tidak hanya berlaku pada perangkat lunak tetapi juga pada konteks penggunaan. Mengambil skenario IOE sebagai contoh, misalnya variasi prosedur invoicing yang akan dipertimbangkan, tergantung pada tipe produk yang akan disajikan. Hal ini mungkin saja terdapat perbedaan input yang dibutuhkan pada situasi yang berbeda untuk perhitungan jumlah klien. Katakan invoices 95% yang digunakan dimiliki tipe produk A dan sisanya 5% ke produk B. Jika perangkat lunak ditulis secara khusus untuk aplikasi ini, maka di samping pengujian yang baik, beberapa kesalahan yang mungkin akan ditemukan, terdapat pada cara sistem operasional. Selagi dilaporkan dan diperbaiki, perangkat lunak mungkin saja dapat menjadi lebih ‘dewasa’ sehingga kesalahan perangkat lunak menjadi jarang. Hal ini terjadi jika ada kecepatan menukar antara produk B lebih mudah mengeluarkan faktur daripada peningkatan jumlah transaksi produk B. Oleh karena itu, perubahan penggunaan perangkat lunak harus melibatkan perubahan kebutuhan perangkat lunak, apa yang dapat diterima ke satu user mungkin tidak diterima oleh user lain.
ISO 9126 mengidentifikasi enam karakteristik kualitas perangkat lunak utama yaitu:

• Functionality: kemampuan menutupi fungsi produk perangkat lunak yang menyediakan kepuasan kebutuhan user.
• Reliability: kemampuan perangkat lunak untuk perawatan dengan level performansi.
• Usability: kemampuan yang berhubungan dengan penggunaan perangkat lunak.
• Efficiency: kemampuan yang berhubungan dengan sumber daya fisik yang digunakan ketika perangkat lunak dijalankan.
• Maintainanility: kemampuan yang dibutuhkan untuk membuat perubahan perangkat lunak
• Portability: kemampuan yang berhubungan dengan kemampuan perangkat lunak yang dikirim ke lingkungan berbeda.

ISO 9126 menyarankan sub-karakteristik untuk setiap karakteristik utama

‘Functionality compliance’ mengacu pada bagian perangkat lunak untuk mengaplikasikan standard atau kebutuhan legal. Umumnya hal ini digunakan untuk kebutuhan auditing. Sejak daftar asli 1999, sub-karakteristik yang disebut dengan ‘compliance’ telah ditambahkan pada ke-enam karakteristik ISO eksternal. Pada setiap kasus, hal ini mengacu pada standard spesifik manapun yang dapat menerapkan atribut kualitas tertentu.
‘Interoperability’ merupakan gambaran yang bagus pada usaha ISO 9126 untuk mengklarifikasi terminologi ‘interopability’ yang mengacu pada kemampuan perangkat lunak untuk berinteraksi dengan sistem lain. Kerangka ISO 9126 telah dipilih pada kata ini daripada ‘comparability’ karena nantinya akan mengakibatkan kebingungan dengan karakteristik yang dituju oleh ISO 9126 sebagai ‘replacability’

‘Maturity’ mengacu pada frekuensi kesalahan produk perangkat lunak yang memberikan dampak pada perangkat lunak yang digunakan sehingga kesalahan menjadi tidak nampak dan mudah dihilangkan. Hal ini menarik untuk ketahui bahwa ‘recoverability’ telah menjadi hal yang berbeda dari ‘security’ yang menggambarkan kontrol akses pada sistem.

Catatan bagaimana ‘learnability’ dibedakan dari ‘operability’. Tool perangkat lunak dapat dengan mudah dipelajari tetapi menghabiskan waktu untuk menggunakannya dikarenakan oleh cara penggunaannya membutuhkan jumlah menu besar. Hal ini dapat diaplikasikan untuk paket yang singkat, tetapi tidak ada sistem yang menggunakannya untuk sepanjang waktu setiap hari. Pada kasus ini ‘learnability’ telah disatukan pada biaya ‘operability’.
‘Attractiveness’ adalah tambahan terbaru pada sub-karakteristik usability dan sangat penting dimana user tidak dipaksa untuk menggunakan produk perangkat lunak tertentu, Misalnya, kasus game dan produk entertainment lain.

‘Analysability’ merupakan kemudahan untuk menentukan penyebab kesalahan. ‘Changebility’ merupakan kualitas lain dari ‘flexibility’ yang kemungkinan nantinya disebut sebagai ‘changebility’ yang memiliki arti tambahan yang sederhana dalam perbendaharan kata bahasa English – hal ini mungkin saja menandakan pemasok perangkat lunak yang selalu berubah.
Di sisi lain pengertian ‘Stability’, adalah tidak berarti perangkat lunak itu tidak pernah berubah. Hal ini berarti juga terdapat resiko yang kecil pada modifikasi perangkat lunak yang memiliki dampak tidak diduga.

‘Portability compliance’ berhubungan erat dengan standard kemampuan yang digunakan pada platform manapun (portability). Standard bahasa pemrograman umum pada kasus ini digunakan pada lingkungan hardware/software. ‘Replacebility’ mengarah ke faktor yang memberikan ‘upward compatibility’ antara komponen software lama dan yang baru. Sedangkan ‘downwards compatibility' tidak dijelaskan pada pengertian definisi.
‘Co-existence’ mengarah pada kemampuan software untuk berbagi sumber daya dengan komponen software lain, tetapi tidak seperti ‘interopability’, dimana tidak ada data yang digunakan.
ISO 9126 menyediakan petunjuk untuk menggunakan kualitas karakteristik. Variasi dalam membedakan karakteristik kualitas tergantung pada tipe produk yang ditekankan.
Terdapat 5 langkah yang dikembangkan untuk kebutuhan produk software yaitu :

1. Menilai pentingnya masing-masing karakteristik kualitas aplikasi. Reliability akan berfokus pada sistem kerentanan keamanan (safety-critical) selama efisiensi itu merupakan keutamaan untuk sistem real time.
2. Memilih pengukuran kualitas eksternal menggunakan kerangka ISO 9126 yang berhubungan dengan prioritas utama kualitas. Realiability berarti memiliki waktu antara kesalahan yang akan menjadi keutamaan pengukuran, Dimana efisiensi dan lebih utamanya pada ‘time behaviour’, -respon waktu yang digunakan untuk pengukuran.
3. Pemetaan pengukuran pada tingkat kepuasan user. Untuk waktu respon, misalnya pemetaannya dapat dilihat pada Tabel 1.

Tabel 1. Pemetaan Pengukuran untuk Kepuasan User

4. Identifikasi yang berhubungan dengan pengukuran internal dan produk yang dihasilkan. Hal ini akan menjadi sesuatu yang penting saat software dikembangkan daripada mengevaluasi software yang dihasilkan. Untuk software baru, umumnya kualitas akhir produk akan membutuhkan penilaian selama pengembangan. Misalnya, pada kualitas eksternal dalam pertanyaan time behaviour, pada langkah desain software , perkiraan waktu eksekusi untuk sebuah proses dapat dihasilkan melalui pengujian kode software dan menghitung waktu untuk setiap perintah pada eksekusi proses secara umum. Menurut buku ini pemetaan antara karakteristik kualitas internal dan eksternal serta pengukuran disarankan sesuai standard ISO 9126 yang setidaknya meyakinkan elemen sebuah pendekatan.. Technical report merupakan bagian dari keseluruhan standart. Standart ISO 9126, digunakan untuk pemetaan pengukuran internal dan eksternal serta validasi pengukuran yang memiliki hubungan erat diantara dua kondisi yang semestinya dilakukan. Hal ini mencerminkan masalah sebenarnya pada pengembangan software terutama pengujian struktur kode dan prediksi kualitas eksternal secara akurat seperti reliability.
Menurut ISO 9126, pengukuran dapat bertindak sebagai indikator akhir kualitas software yang dilakukan pada pengembangan life cycle yang berbeda. Untuk langkah awal dalam penentuan kualitas produk dapat bersifat kualitatif. Penentuan tersebut berdasarkan ceklist , dimana pemenuhan kriteria definisi awal dibantu oleh penilaian ekspert (expert judgement). Sebagai produk yang berhubungan dengan penyelesaian, sasaran, kuantitatif, maka peningkatan pengukuran akan dilakukan kemudian.

5. Penilaian keseluruhan kualitas produk. Apakah penilaian tersebut memungkinkan untuk memperoleh nilai yang menghasilkan keputusan kualitas produk software? Hal ini merupakan perdebatan utama. Dapat dilihat bahwa kualitas yang didiskusikan dapat berbeda antara satu dengan yang lainnya. Pada beberapa kasus penilaian, dapat dihadirkan hasil kualitas produk. Misalnya karakteristik efisiensi time behaviour dan pemanfaatan sumber daya dapat ditingkatkan dengan cara memaksimalkan karakteristik sistem operasi dan hardware untuk menghasilkan software. Bagaimanapun juga penilaian dapat mempengaruhi biaya portability. Faktor ketakutan lain adalah menggabungkan penilaian karakteristik jaminan yang berbeda , pada prakteknya, bisa sangat berbeda dan dapat diukur dengan cara yang berbeda, dimana membuat perbandingan dan penggabungan yang bisa sangat bermasalah.

Pengukuran telah dicatat pada penilaian kualitas yang dapat dilaksanakan untuk beberapa alasan yang berbeda : untuk menilai pengembangan software, acquisition atau penilaian independent.
Selama pengembangan produk software, penilaian diarahkan kepada kebutuhan yang utama dari keinginan developer terhadap kualitas. Tujuannya digunakan untuk identifikasi kemungkinan kelemahan sejak awal dan kebutuhan pada kasus yang menghasilkan pembobotan kualitas secara keseluruhan
Pada situasi ini dimana user yang berpotensi adalah menilai sejumlah perbedaan produk software untuk memilih yang terbaik sesuai keinginan mereka, hasilnya akan mengarah ke produk A yang lebih memuaskan daripada produk B atau C. Di sini terdapat beberapa ide mengenai hasil kepuasan relatif dan pertimbangan dalam berusaha untuk membuat suatu model kepuasan user. Satu pendekatan mengenali beberapa level kualitas menjadi sebuah kewajiban. Jika sebuah produk gagal meraih kewajiban level rating maka produk tersebut harus ditolak, tanpa melihat seberapa bagus kemungkinan di masa yang akan datang. Karakteristik kepuasan user mungkin saja diinginkan tetapi tidak dibutuhkan. Untuk rating kepuasan user dapat dibagi menjadi beberapa range, misalnya 0-5. Rating kepuasan user berdasarkan pada pengukuran yang obyektif untuk beberapa fungsi dan berhubungan dengan perbedaan nilai pengukuran ke level kepuasan user yang berbeda– lihat tabel 2.

Tabel 2. Pemetaan Respon Waktu terhadap Kepuasan User

Sebagai tambahan pada rating kepuasan, rating pada range 1-5 dapat digunakan sebagai patokan untuk kepentingan setiap karakteristik kualitas, dll. Skor yang menggambarkan tentang kurang lebihnya kualitas dapat dilakukan dengan cara mengkalikan setiap rating dengan pembobotan yang diperoleh melalui perkalian antara (importance rating) keutamaan rating dan nilai kualitas (quality score). Skor pembobotan ini dapat dijumlahkan untuk mendapatkan skor keseluruhan produk. Skor untuk produk yang berbeda dapat dipesan untuk mendapatkan pilihan skala awal. Misalnya kualitas dua produk kemungkinan dibandingkan dalam hal usability, efisiensi dan maintainaibility. Keutamaan setiap kualitas kemungkinan masing-masing bernilai 3, 4 dan 2, dengan nilai maksimum 5. Pengujian kualitas dapat menghasilkan situasi seperti pada tabel 3.
Situasi akhir , dimana penilaian kualitas dapat bertindak sebagai tim penilai yang bekerja atas nama komunitas user secara keseluruhan. Misalnya praktisi mungkin dapat menilai tool software yang mensupport kinerja anggotanya. Tidak seperti pemilihan oleh individual user / purchaser, percobaan dibuat untuk menghasilkan penilaian software yang obyektif, pada lingkungan user secara independent. Hal ini jelas bahwa hasil pengukuran akan memiliki banyak pertimbangan tergantung pada pembobotan yang diberikan pada setiap karakteristik software, dan perbedaan user akan memiliki kebutuhan nilai yang berbeda.

Read More..

Menempatkan Kualitas Perangkat Lunak pada Perencanaan Proyek

Kualitas akan berfokus pada semua langkah perencanaan dan pelaksanaan proyek, dapat dilihat pada gambar 1

Gambar 1. Penempatan Kualitas Perangkat Lunak

• Langkah 1: identifikasi ruang lingkup dan sasaran proyek. Beberapa sasaran berhubungan dengan kualitas aplikasi yang akan dikerjakan.
• Langkah 2: identifikasi infrastruktur proyek. Dengan langkah ini maka memerlukan identifikasi standard instalasi dan prosedur. Beberapa diantaranya akan berbicara tentang kualitas
• Langkah 3: analisis karakteristik proyek. Pada analisis karakteristik proyek berdasarkan kualitas, aplikasi akan diimplementasikan untuk melihat kebutuhan khusus kualitas. Misalnya pada keamanan kritis (keamanan data) yang ekstrim dari keseluruhan tambahan batas aktifitas yang bisa digunakan sebagai pengembangan versi ke n dimana tim pengembang pada software versi sebelumnya akan sama berjalan secara paralel dengan output yang akan di cross cek untuk bahan perdebatan.
• Langkah 4: identifikasi produk dan aktifitas proyek. Poin ini sangat penting dimana masukan, keluaran dan kebutuhan proses di identifikasi untuk setiap proyek. Kebutuhan alami digambarkan lebih jelas pada bab ini.
• Langkah 5: tinjau ulang dan publikasi perencanaan. Pada langkah ini keseluruhan aspek kualitas perencanaan proyek akan di tinjau ulang.

Keutamaan Kualitas perangkat lunak

Kita berharap kualitas menjadi fokus pada semua prosedur barang dan jasa. Bagaimanapun juga, karakteristik khusus perangkat lunak menjadi hal yang tak mudah dimengerti (intangibility) dan kompleksitas, membuat permintaan khusus

• Meningkatkan perangkat lunak secara kritis. End user umumnya tertarik tentang kualitas umum perangkat lunak, terutama yang dapat diandalkan. Hal ini akan menyebabkan peningkatkan ketergantungan suatu organisasi pada sistem komputer dan perangkat lunak sehingga lebih berguna untuk area keamanan kritis (pengamanan data), misalnya pengontrolan pesawat terbang (aircraft)
• Hal yang tidak dimengerti (intangibility) oleh perangkat lunak membuat kesulitan untuk mengetahui pekerjaan tertentu dalam memuaskan customer di proyek. Hasil pekerjaan ini menjadi sesuatu yang dapat dimengerti (tangible) dengan menuntut developer menghasilkan ‘deliverables’ yang dapat diuji untuk kualitas
• Penjumlahan kesalahan selama pengembangan perangkat lunak. Sebagai pengembangan sistem komputer , jumlah langkah output dibuat dari satu langkah input ke langkah selanjutnya, kesalahan pada deliverables awal akan ditambahkan pada langkah berikutnya, yang mengarahkan ke penjumlahan efek merugikan. Umumnya pada proyek berikutnya dimana kesalahan ditemukan menjadi lebih mahal untuk diperbaiki. Sebagai tambahan, karena jumlah kesalahan sistem tidak diketahui, fase debugging proyek menjadi sulit sekali untuk dikontrol.Untuk alasan inilah manajemen kualitas merupakan bagian utama keseluruhan manajemen proyek.

Mendefinisikan Kualitas Perangkat Lunak

Kualitas merupakan kata yang meragukan dan dibutuhkan untuk definisi yang secara hati-hati untuk dimaknai. Untuk sistem perangkat lunak apapun, seharusnya ada tiga spesifikasi yaitu ;

• Spesifikasi fungsional
  Spesifikasi ini menggambarkan apa yang dikerjakan sistem – hal ini merupakan fokus utama metodologi seperti Unified Software Development Process
• Spesifikasi kualitas (atau atribut)
  Spesifikasi ini memfokuskan pada , bagaimana fungsi beroperasi.
• Spesifikasi sumber daya
  Spesifikasi ini berfokus pada seberapa banyak yang harus dihabiskan oleh sistem

Beberapa kualitas dapat diidentifikasi untuk menghasilkan perangkat lunak yang mencerminkan pandangan eksternal perangkat lunak yang akan diliki user, sebagaimana pada kasus usability. Kualitas eksternal akan dipetakan ke faktor internal dimana developer akan bersikap waspada. Hal ini bisa diperdebatkan, misalnya kode yang tersusun dengan baik (well-constructed code) umumnya memiliki kesalahan lebih sedikit dan peningkatan kemampuan untuk digunakan.
Mendefinisikan kualitas tidak cukup hanya dengan jika kita melakukan keputusan yang sesuai dengan kebutuhan sistem sehingga kita perlu melakukan pengukuran kualitas. Untuk setiap karakteristik kualitas, satu atau lebih pengukuran yang ditemukan akan menghasilkan nilai derajat kualitas.
Pengukuran yang baik harus dapat menghubungkan jumlah unit sampai keadaan yang maksimal. Jumlah maksimum kesalahan pada program, misalnya kesalahan yang berhubungan dengan ukuran program sehingga pengukuran kesalahan per seribu baris kode (fault per thousand line of code) akan lebih membantu daripada jumlah kesalahan (total fault) pada program sebagai jaminan kualitas program.
Mencoba untuk menemukan pengukuran untuk kualitas tertentu membantu mengklarifikasi apakah kualitas itu. Yang dipertanyakan adalah, dampak terhadap ‘Bagaimana kita mengetahui kapan hal ini akan berhasil?’ menjawab tentang sasaran kualitas akan dijelaskan lebih lanjut.
Kemungkinan pengukuran kualitas dapat dilakukan secara langsung atau indirect dimana sesuatu yang diukur bukan kualitasnya sendiri tetapi indikator kualitas yang dihadirkan. Misalnya jumlah permintaan oleh user diterima dengan bantuan pengoperasian aplikasi perangkat lunak tertentu dapat menjadi pengukuran usability secara indirect. Dengan identifikasi manajemen pengukuran pengaturan program bagi tim anggota proyek sangat penting untuk meningkatkan kualitas pengukuran itu sendiri. Misalnya jumlah kesalahan yang ditemukan di baris program tidak bisa dihitung, pada dasarnya hal itu memerlukan proses pemeriksaan yang lebih teliti, sehingga kesalahan lebih mudah ditemukan. Meningkatkan pengukuran ini bisa saja dilakukan, tentu saja, dengan mengetahui kesalahan yang ada melalui langkah pemeriksaan daripada menghilangkan kesalahan dari awal – dimana hal ini bukan faktor utama.
Kebutuhan utama untuk spesifikasi karakteristik kualitas adalah

• Definisi / deskripsi: definisi karakteristik Kualitas.
• Skala: unit pengukuran.
• Uji: uji praktis yang dilakukan dimana dihasilkan atribut Kualitas
• Penerimaan secara sederhana : nilai terburuk yang mungkin saja diterima jika karakteristik lain dibandingkan dengan kualitas, dan saat produk belum diterima.
• Batas target: batas nilai dimana perencanaan pengukuran nilai Kualitas seharusnya diperbaiki.
• Sekarang: hasil yang diharapkan sekarang

Oleh karena itu ada pengukuran yang dapat diaplikasikan lebih dari satu ke karakteristik kualitas. Saat melakukan daftar (drafting) spesifikasi kualitas karakteristik kualitas mungkin saja akan terbagi dalam beberapa sub-karakteristik. Misalnya sub-karakteristik dari ‘usability’ mungkin saja dapat dijelaskan (communicativeness). Satu aspek yang mungkin saja menjadi pemahaman struktur menu, adalah begitu mudahnya menemukan perintah untuk menyelesaikan beberapa fungsi. Aspek lain dari penjelasan tersebut adalah bagaimana mengatakan keberadaan pesan kesalahan yang muncul, melalui halaman “help”

Read More..

KUALITAS PERANGKAT LUNAK

Ketika kualitas pada umumnya disetujui menjadi ‘barang bagus’, apa yang dimaksud orang pada kata ‘kualitas’ pada sebuah sistem dapat menjadi hal yang meragukan. Oleh karena itu dibutuhkan definisi yang lebih tepat untuk kualitas pada sistem. Bagaimanapun juga, hal ini tidak cukup - kita membutuhkan keputusan secara obyektif dimana sistem menemui kebutuhan kualitas dan pengukuran. Hal ini akan menjadi fokus seseorang seperti Brigette pada Britghtmouth College pada proses pemilihan paket.

Untuk seseorang-seperti Amanda pada IOE-pengembang software, pengukuran kualitas tidak hanya berfokus pada hasil akhir, tetapi juga pada proses. Amanda mungkin ingin menilai kualitas sistem akhir selama dalam proses pengembangan, dan juga meyakinkan pengembangan metode yang digunakan untuk menghasilkan kualitas. Hal ini akan mengarah ke penekanan yang berbeda-daripada berfokus pada kualitas sistem akhir, customer yang berpotensi (customer yang memiliki keinginan untuk membeli software) mungkin akan mencoba untuk melakukan cek ke supplier dalam penggunaan metode terbaik.

Dapat dibaca pada kualitassoftware.pdf
Untuk contoh implementasi bisa dibaca pada 785.pdf

Read More..