Modul ke:
Fakultas
Program Studi
Testing dan Implementasi Sistem Informasi
DASAR – DASAR PENGUJIAN
PERANGKAT LUNAK (LANJUTAN)
Dosen : Agung Priambodo, S.Kom, M.Kom
Sistem Informasi
Fakultas Imlu Komputer
www.mercubuana.ac.id
KONTRAK PERKULIAHAN
Mata Kuliah : Testing dan Implementasi sistem/ 3 SKS
• Kode Mata Kuliah : UMB
• Pengajar : Agung Priambodo
• Semester : Ganjil TA 2016-2017
DESKRIPSI MATA KULIAH
Memahami Konsep Matrik Kualitas Perangkat
Lunak
TUJUAN INSTRUKSIONAL
Mahasiswa diharapkan mampu memahami
Metrik dari kualitas perangkat lunak, serta
kerangka kerja untuk metrik perangkat lunak
teknis
KRITERIA PENILAIAN
Penilai dalam perkuliahan ini akan dilakukan seobjektif mungkin sesuai dengan upaya mahasiswa dalam pencapaian kemampuan. Beberapa hal yang menjadi variable penilaian adalah :
Absensi : 10% dengan minimal kehadiran 75%.
Makalah, presentasi, tugas : 20% diperoleh dari rata2 tugas mingguan.
Ujian Tengah Semester : 30%
Ujian Akhir Semester : 40%
Tujuan Pembelajaran
Mahasiswa memahami Konsep Metrik teknis untuk perangkat
lunak, Kerangka Kerja, Untuk Metrik Perangkat Lunak Teknis,
Metrik Untuk Model Analisis, Metrik untuk Kualitas Spesifikasi,
Metrik Untuk Model Disain, Metrik Disain Tingkat komponen,
Metrik Untuk Kode Sumber, Metrik Untuk Pengujian, Metrik
Untuk Pemeliharaan
Metrik teknis untuk perangkat lunak
1. Kualitas Perangkat Lunak
Titik penting untuk kualitas perangkat lunak :
Persyaratan perangkat lunak adalah dasar di mana kualitas diukur. Kurangnya penyesuaian ke persyaratan berarti kurangnya kualitas.
Standar yang dispesifikasi menentukan serangkaian kriteria pengembangan yang menuntun cara dimana perangkat lunak direkayasa. Bila kriteria itu tidak diikuti, maka kurangnya kualitas akan menjadi hal yang sering terjadi.
Ada serangkaian persyaratan implisit yang sering tidak tercantum (misalnya, keinginan akan maintainabilitas yang bagus). Bila perangkat lunak menyesuaikan dengan persyaratan eksplisit tetapi gagal memenuhi persyaratan implisit, maka kualitas perangkat lunak patut dicurigai.
Kualitas perangkat lunak adalah gabungan kompleks dari berbagai faktor yang akan
bervariasi pada aplikasi dan pelanggan yang berbeda yang membutuhkannya.
Faktor Kualitas McCall
McCall dan kawan – kawannya mengusulkan kategori mengenai faktor – faktor yang mempengaruhi kualitas perangkat lunak, yang berfokus pada tiga aspek penting :
•Karakteristik operasional
•Kemampuan mengalami perubahan
•Kemampuan beradaptasi dengan lingkungan baru
Dengan mengacu faktor diatas McCall memberikan gambaran berikut :
• Kebenaran
• Reliabilitas
• Efisiensi
• Integritas
• Usabilitas
• Maintainabilitas
• Fleksibilitas
• Testabilitas
• Portabilitas
• Reusabilitas
• Interoperabilitas
• Audibilitas
• Akuras
• Kelengkapan
• Keringkasan
• Konsistensi
• Kelaziman data
• Toleransi kesalahan
• Efisiensi eksekusi
• Ekspandibilitas
• Generalitas
• Instrumentasi
• Modularitas
• Operabilitas :
• Keamanan
• Pendokumentasian diri
• Kesederhanaan
• Traceabilitas
• Training
FURPS
Hewlett-Packard mengembangkan serangkaian faktor kualitas perangkat lunak yaitu :
Functionality, dinilai melalui evaluasi bentuk himpunan dan kemampuan program, generalitas fungsi – fungsi yang disampaikan dan keamanan keseluruhan sistem.
Usability, dinilai dengan mempertimbangkan faktor manusia, keseluruhan estetika, konsistensi dan dokumenatasi.
Reliability, dievaluasi melalui pengukuran frekuensi dan besarnya kegagalan, akurasi hasil output, mean time between failure, kemampuan untuk pulih dari kegagalan dan prediktabilitas program.
Performance, diukur melalui kecepatan pemrosesan, waktu respon, konsumsi kode sumber, throughput dan efisiensi.
Supportability, menggabungkan kemampuan untuk memperluas program,
kemampuan beradaptasi dan kemampuan pelayanan, serta testabilitas,
kompatibilitas, kecocokan dimana suatu sistem dapat dipasang dan kecocokan
dimana masalah dapat dilokalisasikan.
Beralih ke Pandangan Kuantitatif Menurut Cavano dan McCall :
Penentuan kualitas adalah suatu faktor kunci dalam kejadian sehari – hari. Pada situasi – situasi itu kualitas dinilai secara langsung dan mendasar: membandingkan objek secara berdampingan di bawah kondisi identik dan konsep yang telah ditentukan. Supaya bernilai, penilaian harus dilakukan seorang pakar.
Subyektifitas dan spesialisasi juga berfungsi untuk menentukan kualitas perangkat lunak. Untuk membantu memecahkan masalah tersebut, diperlukan definisi mengenai kualitas perangkat lunak yang lebih teliti. Juga cara untuk menarik pengukuran kuantitatif terhadap kualitas perangkat lunak untuk analisis obyektif.
2. Kerangka Kerja Untuk Metrik Perangkat Lunak Teknis Tantangan Metrik Teknis
Secara analogi, diandaikan sebuah metrik untuk mengevaluasi sebuah mobil yang sangat
“menarik”. Banyak peneliti menekankan desain badan, yang lainnya mempertimbangkan karakteristik mekanik. Yang lain lagi masalah biaya atau kinerja atau keiritan bahan bakar.
Dengan demikian akan sulit menarik nilai tunggal untuk kata “menarik” karena setiap karakteristik dapat menjadi aneh bagi karakteristik yang lain. Masalah yang sama juga muncul pada perangkat lunak komputer.
Prinsip Pengukuran
Roche mengusulkan proses pengukuran ditandai dengan lima aktivitas :
Formulasi - derivasi dari pengukuran dan metrik perangkat lunak yang sesuai bagi representasi perangkat lunak yang sedang dipertimbangkan
Koleksi – mekanisme yang digunakan untuk mengakumulasi data yang diperlukan untuk menarik metrik yang diformulasikan
Analisis – komputasi metrik dan aplikasi dari piranti matematis
Interpretasi – evaluasi terhadap metrik yang menghasilkan usaha untuk mendapatkan wawasan ke dalam kualitas representasi
Umpan balik – rekomendasi yang ditarik dari interpretasi metrik teknis yang ditransmisikan ke tim perangkat lunak
Meskipun formulasi adalah titik awal yang kritis, koleksi dan analisis merupakan aktivitas yang mengendalikan proses pengukuran. Roche mengusulkan prinsip – prinsip sebagai berikut untuk aktivitas – aktivitas berikut :
Setiap kali dimungkinkan, koleksi dan analisis data harus diotomatisasi
Teknik statistik yang berlaku harus diaplikasikan untuk membangun hubungan antara atribut produk internal dan karakteristik eksternal (misalnya, apakah tingkat kompleksitas arsitektur dikorelasikan dengan jumlah cacat yang dilaporkan dalam penggunaan produksi?)
Pedoman dan rekomendasi yang interpretatif harus dibangun bagi masing – masing metrik
Atribut Metrik Perangkat Lunak Efektif
Ejiogu mendefinisikan serangkaian atribut yang harus dicakup oleh metrik perangkat lunak yang efektif. Metrik dan pengukuran terhadapnya haruslah :
Sederhana dan dapat dihitung. Harus sangat mudah untuk mempelajari bagaimana menggunakan metrik tersebut.
Persuasif secara empiris dan intuitif. Metrik tersebut harus memenuhi gagasan intuitif perekayasa mengenai atribut produk yang dipertimbangkan (misalnya, metrik yang mengukr kohesi modul harus bertambah nilainya dan tingkat kohesinya).
Konsisten dan obyektif. Metrik tersebut harus selalu memberikan hasil yang tidak ambigu.
Konsisten dalam pemakaian unit dan dimensinya. Komputasi matematis dari metrik tersebut harus menggunakan pengukuran yang tidak menyebabkan kombinasi unit yang aneh.
Misalnya memerbanyak orang pada tim proyek dengan menggunakan variabel bahasa pemrograman dalam program.
Tidak tergantung pada bahasa pemrograman. Metrik harus didasarkan pada model analisis, model disain atau struktur program itu sendiri. Tidak tergantung pada tingkah laku dari sintaks bahasa pemrograman atau semantiknya.
Mekanisme yang efektif bagi umpan balik yang berkualitas. Metrik memberi informasi yang dapat membawa kepada produk akhir yang berkualitas tinggi.
3. Metrik Untuk Model Analisis
Metrik Berbasis Fungsi
Metrik Function Point dapat digunakan sebagai alat untuk memprediksi ukuran suatu sistem yang akan didapat dari model analisis. Sebagai contoh model analisis yang sederhana,
perhatikan gambar diagram alir data dari suatu fungsi perangkat lunak ‘Safe Home’ berikut.
Fungsi tersebut mengatur interaksi pemakai, dengan menerima password pemakai untuk mengaktivasi/deaktivasi sistem dan memperbolehkan penyelidikan pada status zona keamanan dan berbagai sensor keamanan.
Diagram aliran data dievaluasi untuk menentukan pengukuran kunci yang diperlukan untuk penghitungan metrik function point.
Jumlah user input : tiga yaitu password, panic button dan activate/deactivate Jumlah user output : dua yaitu messages dan sensor status
Jumlah user inquiry : dua yaitu zone inquiry dan sensor inquiry Jumlah file : satu yaitu system configuration file
Jumlah interface eksternal : empat yaitu test sensor, zone setting, activate/deactivate dan alarm alert
Data historis memberikan kepada manajer proyek informasi perencanaan yang penting yang didasarkan pada model analisis daripada perkiraan awal.
Metrik Bang
Dikembangkan oleh Tom Demarco, metrik bang adalah indikasi ukuran sistem yang tidak tergantung pada ukuran sistem. Untuk menghitung metrik bang perekayasa perangkat lunak harus lebih dahulu mengevaluasi serangkaian primitive – elemen model analisis yang tidak dibagi – bagi lebih lanjut pada tingkat analisis. Primitive ditentukan dengan mengevaluasi model analisis dan mengembangkan perhitungan untuk item – item berikut :
Primitive Fungsional (FuP). Transformasi yang muncul pada tingkat terendah diagram alir data.
Elemen Data (DE). Atribut suatu objek data, elemen data bukanlah gabungan data dan muncul pada kamus data.
Objek (O). Objek data.
Hubungan (RE). Hubungan antar objek data.
Keadaan (ST). Jumlah keadaan yang dapat diobservasi oleh pemakai dalam diagram transisi keadaan.
Modified manual function primitive (FuPM). Fungsi – fungsi yang berada di luar batas sistem dan harus dimodifikasi untuk mengakomodasi sistem baru.
Input data element (DEI). Elemen – elemen data yang merupakan input ke sistem.
Output data element (DEO). Elemen – elemen data yang merupakan output dari sistem.
Retained data element (DER). Elemen – elemen data yang ditahan (disimpan) oleh sistem.
Data tokens (TCi). Token data (item data yang tidak dibagi lagi dalam sebuah functional primitive) yang ada pada batas functional primitive ke I (dievaluasi untuk masing – masing primitive).
Metrik untuk Kualitas Spesifikasi
David dan rekan – rekannya mengusulkan daftar karakteristik yang dapat digunakan untuk memperkirakan kualitas model analisis dan spesifikasi persyaratan yang sesuai :
• Kekhususan (kurangnya ambiguitas)
• Kelengkapan
• Kebenaran
• Understandbilitas
• Verifiabilitas
• Konsistensi internal dan eksternal
• Kemampuan pencapaian
• Keringkasan
• Kemampuan penelusuran
• Kemampuan modifikasi
• Ketelitian
• Reusabilitas
4. Metrik Untuk Model Disain
Metrik Disain Tingkat Tinggi
Metrik disain tingkat tinggi berfokus pada karakteristik arsitektur program dengan tekanan pada struktur arsitektur serta keefektifan modul.
Carl dan Glass menentukan pengukuran kompleksitas disain perangkat lunak :
Kompleksitas struktural Kompleksitas data
Kompleksitas sistem
Fenton mengusulkan sejumlah metrik morfologi sederhana yang
memungkinkan arsitektur program yang berbeda
diperbandingkan dengan menggunakan serangkaian dimensi
langsung.
Ukuran = n + a
Dimana n adalah jumlah simpul (modul) dan a adalah jumlah busur (garis kontrol).
Ukuran = 17 + 18 = 35
Kedalaman = jalur terpanjang dari simpul akar (puncak) ke simpul daun = 4 Lebar = jumlah maksimum simpul pada setiap tingkat arsitektur = 6
Rasio busur ke simpul, r = a / n
Untuk arsitektur diatas r = 18 / 17 = 1,06.
Metrik Disain Tingkat komponen
Metrik disain tingkat komponen berfokus pada karakteristik dari komponen perangkat lunak dan mencakup pengukuran kohesi, perangkaian dan kompleksitas modul.
5. Metrik Untuk Kode Sumber
Teori Halstead tentang teori ilmu perangkat lunak menggunakan hukum kuantitatif untuk pengembangan perangkat lunak komputer.
Pengukuran tersebut seperti tertulis di bawah ini :
n
1– jumlah operator berbeda yang tampak pada suatu program n
2– jumlah operand berbeda yang tampak pada suatu program N
1– jumlah total kejadian operator
N
2– jumlah total kejadian operan
6. Metrik Untuk Pengujian
Metrik function-based dapat digunakan sebagai prediktor untuk keseluruhan usaha pengujian.
Pada saat pengujian dilakukan, ada tiga pengukuran yang berbeda yang memberikan indikasi kelengkapan pengujian. Pengukuran lebar pengujian memberikan indikasi berapa banyak persyaratan (dari total jumlah persyaratan) yang telah diuji. Kedalaman pengujian adalah pengukuran presentase basis path independen yang dicakup oleh pengujian vs jumlah total basis path pada program. Akhirnya ketika pengujian dilakukan dan data kesalahan dikumpulkan, profil kesalahan dapat digunakan untuk memprioritaskan dan mengkategorikan kesalahan – kesalahan yang diungkap.
