Software Quality Assurance

Software Proses

Proses Pengembangan PL memiliki sebuah

framework proses umum yang terdiri dari:

Framework Activities untuk semua proyek PL

Tugas-tugas pekerjaan
project milestones
Hasil pekerjaan PL dan penyelesaian
Poin-poin jaminan kualitas

Umbrella activities terjadi pada seluruh proses

Jaminan Kualitas PL (Software Quality Assurance)

Manajemen konfigurasi PL
Metrik atau pengukuran PL
2

Proyek PL

Bagaimanakah tim Anda

menjamin KUALITAS
produk
Perangkat Lunak Anda?

Manajemen Kualitas PL

Sasarannya: Kepuasan Customer

User Satisfaction =

Kesesuaian produk +
kualitas baik +
selesai sesuai dengan budget dan jadwal

Bagaimanakah tim Anda mengelola kualitas

pengembangan PL?
4

Terminologi Proses Kualitas

Quality Objectives/Tujuan Kualitas

Quality Policy/Kebijakan Kualitas
Quality Management (QM)
Quality System (QS)
Quality Control (QC)
Quality Assurance (QA)
Software Quality Assurance (SQA)
Verification and Validation (V & V)
Total Quality Management (TQM)
Continuous Improvement
5

Terminologi Proses Kualitas

Tujuan Kualitas :
Mencapai dan menopang kualitas produk/layanan
untuk memenuhi kebutuhan customer
Memberikan jaminan ke manajemen bahwa
kualitas telah dicapai dan dipelihara
Memberikan jaminan ke customer bahwa kualitas
telah tercapai

Kebijakan Kualitas

Sasaran dan arah kualitas keseluruhan dari sebuah

organisasi terkait dengan kualitas yang secara
formal dinyatakan oleh top manajemen
6

Terminologi Proses Kualitas

Quality Management (QM)

Adalah aspek fungsi manajemen keseluruhan yang

menentukan dan menerapkan kebijakan kualitas
(ISO9000)

Quality System (QS)

Adalah struktur, tanggung jawab, prosedur, proses

dan sesumber organisasi untuk penerapan
manajemen kualitas (ISO9000)

Terminologi Proses Kualitas

Quality Control (QC)

Adalah teknik dan aktifitas operasional yang
digunakan untuk memenuhi kebutuhan kualitas
(ISO9000)
Meliputi evaluasi unjuk kerja, membandingkan
tujuan dan tindakan, pengecekan produk

Terminologi Proses Kualitas

Quality Assurance (QA)

Semua tindakan sistematis dan terencana untuk
menjamin bahwa sebuah produk/layanan akan
memenuhi kebutuhan /memuaskan(ISO9000)
Sekumpulan aktifitas yang dirancang untuk
mengevaluasi proses dimana produk
dikembangkan atau dirakit (IEEE Standards )
Quality assurance meliputi pengecekan proses

Terminologi Proses Kualitas

Quality Assurance (QA) ...

Tujuan:

Untuk mencegah terjadinya masalah;

Mendeteksi masalah ketika terjadi;
Mengetahui penyebabnya;
Menyelesaikan sampai akar; dan
Mencegah masalah terjadi lagi

10

Terminologi Proses Kualitas

Perbedaan QC / QA

QC bekerja dengan produk

Mengukur produk berdasarkan standard

Mengenali kerusakan/cacat
Sebatas pada melihat produk

QA bekerja dengan proses

Sebuah fungsi yang mengatur kualitas

setup QC
Menggunakan hasil QC untuk mengevaluasi dan
meningkatkan proses yang menghasilkan produk
11

Terminologi Proses Kualitas

EVALUATION OBJECTIVES
of a

GOALS

SOFTWARE QUALITY FUNCTION

Standards

Standards

SATISFIED
NEEDS
METHODS

Standards

PERFORMANCE

12

Terminologi Proses Kualitas

Verifikasi dan Validasi

Verifikasi:

Validasi:

Membangun produk secara BENAR

Verifikasi melibatkan pengujian bahwa apa yang telah
dibangun sudah benar.
Membangun produk yang tepat
Validasi melibatkan pengecekan bahwa kebutuhan
customer telah dipenuhi.

Quality Assurance memastikan bahwa

Verification dan Validation mendapat tempat.
13

Terminologi Proses Kualitas

Total Quality Management (TQM)

Mengatur kualitas sebuah perusahaan lebih

daripada hanya sekedar menerapkan sebuah
sistem kualitas ... Hal ini diciptakan oleh adanya
pembentukan budaya kualitas yang meresap pada
seluruh organisasi

Budaya kualitas:
Dedikasi kpada kepuasan customer
penekanan pada perbaikan yang berkelanjutan
Komunikasi dan kerja tim
Memberdayakan anggota tim
Komitmen dengan managemen tim

14

Software Quality Management

Environment
MANAGEMENT

CONTROL

CONTROL
INFORMATION

SOFTWARE
DEVELOPER

SOFTWARE
QUALITY FUNCTION
15

Ukuran Tim Software Quality

=>4%

SAMPLE OF 135 ORGANISATIONS (1983)

=<4%

Software Quality Staff / Development Staff

=< 3%

=< 1%

Sekitar 3% adalah ideal, yaitu dengan 30-33 pengembang,

perlu 1 orang SQA.
Jika terdapat 10-15 orang dalam tim, maka satu orang
untuk setengah minggu harus bertindak sebagai SQA.

16

Peran Tim Software Quality

Review
Applications
Provide
T echnical Advice
Review
and Build a
Quality Environment
Develop Standards
and Guidelines
Analyse Development Errors
17

Tugas Tim Software Quality

ROLE

CHALLENGE

TASKS

Review
Applications

W
hentoabort aproject
Executivemanagement ignorance
User ignorance
Audit requirements

Evaluate systemsinall phases

Provide management withtechnical assessment
Ascertainuser requirementsaremet
Ascertainaudit requirementsaremet

Provide
Technical
Advice

Changingtechnology
Useof consultants
Abilitytokeepcurrent technically
Complexityof systems

Knowcurrent technology
Act asinternal consultant
Act astechnical consultant
Knowmanysystems

Reviewand
Builda
Quality
Environment

Howtoevaluatesoftwareproducts
Buildaqualityenvironment

Evaluatesoftwareproducts
Counsel management

Develop
Standards
and
Guidelines

Fewsystemsandprogrammingstandards
Professionalism

Helpset standards
Evaluate qualityof work

Analyse
Development
Errors

Knowtypeof problems
Knowcost of problems
Knowmagnitudeof problems

Quantifyproblems
Identifyproblems
Determinecost of problems
18

Peran Utama Tim Software Quality

Peran utama Tim SQ adalah Review Applications.

Review Applications meliputi:

Verification (membangun dengan benar) and
Validation ( membangun produk yang benar)
Software Reviews
Pemantauan pada pengiriman bagian2 produk
Testing
Audit bagian software yang ditentukan
19

Apa itu Software Review?

Evaluasi elemen software untuk

memeriksa/mengontrol perbedaan dari hasil
yang direncanakan sampai rekomendasi
perbaikan. ex: Design Review, Code Review
Ada 3 Tipe:

Walkthrough
Software Inspection
Technical Review

20

Tiga Tipe Software Review

Walkthrough: Evaluasi pada elemen software

tertentu identifikasi kesalahan dan memberikan
solusi. Pembangun menjelaskan dan ada tanya jawab
yang diatur oleh moderator
Software Inspections : evaluasi dokumen dan
program sebelum technical review atau testing.
Pemeriksaan oleh rekan dengan checklist hal-hal
yang perlu verifikasi dengan tujuan identifikasi
ketidak sesuaian dengan spek dan standar, dan
mengukur perkembangan.

21

Software Inspections
Without Inspection
No. of Employees

Requirements
Planning
Design

With Inspection
Coding
Testing

Time
22

Inspection Process

Planning
Follow-up
Overview
Individual
Preparation

Rework

Inspection
Meeting
23

Software Inspection Overview

Operation 1

Fix short term problems

Error
feedback

Feedback

Rework

Analysis

Learning input for inspectors

What error types to look for
Better ways to find error types
24

Software Inspection Overview

Operation 1

Fix short term problems

Rework
Error
feedback

Feedback

Operation 2

Analysis

For Special Attentions

Error prone modules

ranked.
Error types
distributions ranked

Learning input for inspectors

What error types to look for
Better ways to find error types

Feed forward
25

Prosedur Inspeksi
Program yg akan diinspeksi diserahkan kpd team
inspeksi
Kode dan dokumen terkait didistribusikan dlm tahap
peninjauan saat mendeskripsikan apa yg menjadi tujuan
program
Harus berlangsung relatif singkat (tidak lebih dari 2 jam)
Tim tidak boleh menyarankan bgm cacat harus
diperbaiki
Setelah inspeksi, program diubah oleh pembuatnya utk
membetulkan masalah yg ditemukan
Inspeksi ulang tidak mutlak harus dilakukan

Team Inspeksi

Tim paling sedikit terdiri dari 4 orang

Pembuat program adalah org yg bertanggung jawab
menghasilkan program yg akan di inspeksi
Inspector adalah orang yg menemukan error, hal-hal
yg tidak terdeteksi dan ketidak konsistenan pd
program
Reader (pembaca) adalah oarng yg menguraikan
program dgn kata-katanya sendiri dlm rapat inspeksi
Moderator adalah org yg menangani proses &
memfasilitasi inspeksi

Inspection checklists
(daftar error)
Untuk memandu kegiatan inspeksi
Tergantung bahasa pemrograman yang
digunakan
Contoh : inisialisasi, penamaan constanta,
Examples: Initialisation, Constant naming, loop
termination, dll.

Fault class
Data faults

Inspection check
Are all program variables initialised before their values
are used?
Have all constants been named?
Should the lower bound of arrays be 0, 1, or something
else?
Should the upper bound of arrays be equal to the size of
the array or Size -1?
If character strings are used, is a delimiter explicitly
assigned?
Control faults
For each conditional statement, is the condition correct?
Is each loop certain to terminate?
Are compound statements correctly bracketed?
In case statements, are all possible cases accounted for?
Input/output faults
Are all input variables used?
Are all output variables assigned a value before they are
output?
Interface faults
Do all function and procedure calls have the correct
number of parameters?
Do formal and actual parameter types match?
Are the parameters in the right order?
If components access shared memory, do they have the
same model of the shared memory structure?
Storage management If a linked structure is modified,
have all links been
faults
correctly reassigned?
If dynamic storage is used, has space been allocated
correctly?
Is space explicitly de-allocated after it
is no longer
required?
Exception
Have all possible error conditions been taken
into
management faults
account?

Inspection che

Pengukuran Proses Inspeksi

500 statement/jam selama peninjauan

125 source statement/jam saat persiapan

individu

90-125 statements/jam saat rapat

Sehingga Inspeksi adalah proses yang sangat

mahal

Tiga Tipe Software Review (cont)

Technical Review : review semua bagian

software untuk membuktikan kesesuaian
dengan spesifikasi, dibangun sesuai standard
dan semua perubahan sudah
diterapkan/dilakukan

31

Synchronous Review Process

Asynchronous Review Process

Technical Reviews
Technically Qualified Team
Evaluates
Suitability for
the intended
use?

Software Product

Rework/Follow-up

Review Report
Action Item List
34

Families of Review Methods

Method Family

Typical Goals

Typical Attributes

Walkthroughs

Minimal overhead
Developer training
Quick turnaround

Little/no preparation
Informal process
No measurement
Not FTR!

Technical
Reviews

Requirements elicitation
Ambiguity resolution
Training

Formal process
Author presentation
Wide range of discussion

Inspections

Detect and remove all

defects efficiently and
effectively

Formal process
Checklists
Measurements
Verify phase

Source: Johnson, P. M. (1996). Introduction to formal technical reviews.

Referensi

Ch. 26, Quality Management, Software Engineering: A

Practitioner's Approach, 6/e, Pressman Roger S.,
2005, McGraw-Hill
Romi Satrio Wahono, Teknik Pengukuran Kualitas
Perangkat Lunak,
http://romisatriawahono.net/?p=155
Stephen H. Kan., Software Quality Metrics Overview,
http://www.awprofessional.com/articles/article.asp?
p=30306&rl=1
36