Transcript SQ – 2 – Pengantar Software Quality

SOFTWARE QUALITY
Pemodelan
Eko Prasetyo
Teknik Informatika
Univ. Pembangunan Nasional Veteran Jawa Timur
2011
1
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.
2
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.
3
Pandangan Software Quality
Transcendental view
 User view
 Manufacturing view
 Product view
 Value-based view

4
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
5
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.
6
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.
7
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
8
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
9
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.
10
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
11
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
12
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
13
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
14
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.
15
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.

16
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 ?
17
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
18
Model menurut Boehm (1978) –
Cont’d

Karakteristik level rendah (primitif) adalah metrik.
19
Model menurut Boehm (1978) –
Cont’d
20
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.
21
Model menurut ISO 9126 – Cont’d
22
Model menurut ISO 9126 – Cont’d

Breakdown faktor  subfaktor
23
Pengukuran Kualitas Perangkat
Lunak
24
TO BE CONTINUED…
ANY QUESTION ?
25