SOFTWARE QUALITY Pemodelan Eko Prasetyo Teknik Informatika Univ. Pembangunan Nasional Veteran Jawa Timur 2011

What Is Quality ? Definisi menurut Juran [1988] – “fitness for use” – yang mengindikasikan referensi pada karakteristik kebutuhan dan produk. “Sesuai dengan spesifikasi” Suatu produk atau jasa yang ukuran karakteristiknya memenuhi spesifikasi yang sudah ditetapkan – sehingga selaras dengan spesifikasi yang sudah didefinisikan sebelumnya. “Memenuhi kebutuhan customer” Produk atau jasa yang memenuhi harapan customer – eksplisit atau tidak.

Dasar proses manajerial untuk pekerjaan pengelolaan kualitas Quality Planning Proses yang mengidentifikasi customer, kebutuhan customer, dan proses yang akan menerimakan produk dan jasa dengan atribut yang benar dan kemudian menfasilitasi pemindahan pegetahuan ini untuk menghasilkan kekuatan organisasi Quality Qontrol Proses dimana produk diuji dan dievaluasi dengan kebutuhan yang dinyatakan oleh customer Masalah yang terdeteksi kemudian diperbaiki. Quality Improvement Proses dimana mekanisme tambahan diletakkan ditempat sehingga kualitas dapai dicapai secara kontinyu. Termasuk pengalokasian sumber daya, penugasan orang-orang untuk menjaga kualitas proyek, pelatihan, dimana secara umum diadakan struktur permanen untuk menjaga kualitas.

Pandangan Software Quality Transcendental view User view Manufacturing view Product view Value-based view

Pandangan Software Quality – Cont’d Transcendental view Kualitas adalah sesuatu yang dapat dikenali tapi tidak dapat didefinisikan. Bersifat subyektif dan tidak quantifiable dalam pendefinisian kualitas software. Software melewati harapan customer. User view atau “fitness for purpose” Mencapai kebutuhan user Sangat personal (subyektif) Produk berkualitas bagus jika mempunyai banyak pengguna Untuk mengidentifikasi atribut produk yang dipandang penting oleh user Meliputi: reliability, performance/efisiensi, maintainability dan usability

Pandangan Software Quality – Cont’d Manufacturing view Berfokus pada pencapaian spesifikasi dan kapasitas organisasi untuk memproduksi software menurut proses software. Kunci: Apakah software memenuhi kebutuhan ? Banyaknya penyimpangan dari kebutuhan akan mengurangi kualitas produk Konsep proses memainkan peran kunci Produk diproses “sejak awal” sehingga biaya dapat dikurangi: Biaya pengembangan Biaya perawatan Keselarasan dengan kebutuhan akan mengarahkan pada keseragaman produk. Kualitas produk dapat meningkat terus dengan meningkatkan proses.

Pandangan Software Quality – Cont’d Product view Hipotesis: Jika produk diolah dengan properti internal yang baik maka produk mempunyai properti kualitas yang baik pula. Misalnya: Modularity akan menghidupkan testability. Value-based view Gabungan : keunggulan dan harga. Kualitas diukur dengan keunggulan, keuntungan diukur dengan harga. Ide: Berapa banyak customer yang akan membayar pada level kualitas tertentu Kualitas tidak dapat dipahami jika produk tidak membuat nilai ekonomis Pandangan value-based membuat trade-off antara harga dan kualitas.

Pengukuran Kualitas Software Alasan developer memandang kualitas secara kuantitatif Pengukuran dapat memunculkan baseline kualitas Pengukuran adalah kunci peningkatan proses Kebutuhan untuk peningkatan dapat diinvestigasi setelah melakukan pengukuran

Pengukuran Kualitas Software – Cont’d Pengukuran dalam pandangan user Fungsionalitas dapat diukur dengan mudah Apakah pengujian kasus fungsionalitas berhasil ? Pengukuran fungsionalitas = rasio jumlah test cases yang berhasil dengan total jumlah test cases yang didesain untuk menverifikasi fungsionalitas. Menerapkan teknik Gilb Konsep kualitas dapat dipecah menjadi bagian komponen sampai dapat dnyatakan dalam istilah yang secara langsung dapat mengukur kualitas Misalnya: Usability dapat dipecah menjadi Learnability Understandability Operability

Pengukuran Kualitas Software – Cont’d Pengukuran dalam pandangan perusahaan Perusahaan menginginkan defect count and rework cost. Defect count: Jumlah total cacat yang terdeteksi selama pengembangan dan operasi. Dapat mengukur kualitas hasil kerja Cara menganalisis cacat: Untuk setiap cacat, identifikasi fase pengembangan dimana dia muncul Kategorikan cacat, misal berdasarkan modul Normalisasi jumlah cacat Defect density: Jumlah cacat per 1000 lines of code Memisahkan cacat yang ditemukan selama operasi dari yang ditemukan selama pengembangan Rework cost: Berapa banyak biaya untuk membenahi cacat yang diketahui ? Development rework cost: Biaya perbaikan yang terjadi sebelum produk dikeluarkan. Ini adalah ukuran development efficiency. Operation rework cost: Biaya perbaikan yang terjadi ketika produk dalam pengoperasian. Ini adalah ukuran delivered quality.

Model menurut McCall (1977) Berusaha untuk menjembatani gap antara user dan developer dengan berfokus pada sejumlah faktor kualitas software yang merefleksikan pandangan user dan prioritas developer. Kualitas produk software: Product Revision Kemampuan untuk mengalami perubahan Product Transition Beradaptasi pada lingkungan yang baru Product Operations Karakteristik pengoperasian

Model menurut McCall (1977) – Cont’d Product Revision, termasuk: Maintainability Usaha yang dibutuhkan untuk menempatkan dan menyelesaikan kesalahan program dalam lingkungan operasi Flexibility Kemudahan membuat perubahan yang butuhkan oleh perubahan dalam lingkungan pengoperasian Testability Kemudahan pengujian program, untuk meyakinkan bahwa program bebeas error dan memenuhi spesifikasinya

Model menurut McCall (1977) – Cont’d Product Transition Portability Usaha yang dibutuhkan untuk memindahkan program dari satu lingkungan ke lingkungan lain Reusability Kemudahan penggunaan kembali osftware dalam konteks yang berbeda. Iteroperability Usaha yang dibutuhkan untuk memasangkan sistem dengan sistem yang lain

Model menurut McCall (1977) – Cont’d Product Operations Correctness Tingkatan dimana software mencapai spesifikasinya Reliability Kemampusan sistem untuk tidak gagal Efficiency Efisien dalam eksekusi dan penyimpanan Umumnya diartikan penggunaan resource, seperti: waktu processor, memori, dsb. Integrity Perlindungan program dari akses yang tidak berkepentingan Usability Kemudahan penggunaan software

Model menurut McCall (1977) – Cont’d Model dirinci kedalam 3 tipe karakter kualitas dalam hirarki dari faktor, kriteria dan metrik: 11 faktor (spesifikasi) Menggambarkan pandangan eksternal software oleh user Menggambarkan perbedaan jenis karakter perilaku sistem 23 kriteria kualitas (membangun) Menggambarkan pandangan internal software oleh developer Atribut satu atau lebih faktor kualitas Metrik (kontrol) Didefinisikan dan digunakan untuk memberikan skala dan metode untuk pengukuran Bertujuan meng-capture beberapa spek kriteris faktor.

Model menurut McCall (1977) – Cont’d Ide dibalik McCall adalah bahwa faktor kualitas yang disintetiskan harus memberikan gambaran kualitas software secara lengkap. Metrik kualitas software aktual didapat dengan menjawab “ya” atau “tidak” pada pertanyaan yang mengukur kriteria kualitas. Metrik dapat disintetiskan per kriteria kualitas, perfaktor kualitas,atau per produk.

Model menurut Boehm (1978) Mendefinisikan kualitas software dengan memberikan sejumlah atribut dan metrik. Mirip dengan model McCall, memberikan hierarki model kualitas yang terstruktur menjadi karakteristik level tinggi, level pertengahan, primitif – setiap karakter berkontribusi pada semua bagian level kualitas. Karakteristik level tinggi Merepresentasikan dasar kebutuhan level tinggi dari penggunaan aktual dimana kualitas software dapat dibentuk. Tiga pertanyaan utama pembeli software: As-is utility: Seberapa (mudah,handal,efisien) saya dapat menggunakannya ? Maintainability: Seberapa mudah dipahami, dimodifikasi, diuji kembali ? Portability: Bisakah saya menggunakannya jika saya mengubah lingkungan saya ?

Model menurut Boehm (1978) – Cont’d Karakteristik level tengah Mengambarkan 7 faktor kualitas yang menggabungkan representasi kualitas yang dibutuhkan dari software Portability – Umumnya mengkarakterkan penggunaan Reliability – Karakter as-is utility Efficiency - Karakter as-is utility Usability - Karakter as-is utility, human engineering Testability – Karakteristik maintainability Understandibility - Karakteristik maintainability Flexibility - Karakteristik maintainability, modifiability

Model menurut Boehm (1978) – Cont’d Karakteristik level rendah (primitif) adalah metrik.

Model menurut Boehm (1978) – Cont’d

Model menurut ISO 9126 ISO 9126: Software Product Evaluation: Quality Characteristics and Guidelines for their Use-standard Didasarkan pada model McCall dan Boehm, tetapi juga memasukkan unsur functionality sebagai parameter.

Model menurut ISO 9126 – Cont’d

Model menurut ISO 9126 – Cont’d Breakdown faktor  subfaktor

Pengukuran Kualitas Perangkat Lunak

TO BE CONTINUED… ANY QUESTION ?