Dokumen tersebut membahas tentang proses pengembangan perangkat lunak dan manajemen kualitas perangkat lunak. Secara ringkas, dokumen tersebut menjelaskan bahwa (1) proses pengembangan perangkat lunak memiliki framework proses yang terdiri dari aktivitas-aktivitas proyek dan jaminan kualitas, (2) tim jaminan kualitas perangkat lunak berperan untuk mereview aplikasi melalui verifikasi, validasi, dan review perangkat lunak, (3

1. Software Quality Assurance

2. 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

3. Proyek PL
3
Bagaimanakah tim Anda
menjamin KUALITAS
produk
Perangkat Lunak Anda?

4. 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

5. 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 andValidation (V &V)
 Total Quality Management (TQM)
 Continuous Improvement
5

6. 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

7. 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)
7

8. 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
8

9. 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
9

10. 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

11. 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

12. Terminologi Proses Kualitas
12
Standards
Standards Standards
GOALS
METHODS PERFORMANCE
SATISFIED
NEEDS
of a
SOFTWARE QUALITY FUNCTION
EVALUATION OBJECTIVES

13. Terminologi Proses Kualitas
 Verifikasi danValidasi
 Verifikasi:
 Membangun produk secara BENAR
 Verifikasi melibatkan pengujian bahwa apa yang telah
dibangun sudah benar.
 Validasi:
 Membangun produk yang tepat
 Validasi melibatkan pengecekan bahwa kebutuhan
customer telah dipenuhi.
 Quality Assurance memastikan bahwa
Verification danValidation mendapat tempat.
13

14. 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

15. Software Quality Management
Environment
15
MANAGEMENT
SOFTWARE
DEVELOPER
SOFTWARE
QUALITY FUNCTION
INFORMATION
CONTROL CONTROL

16. UkuranTim Software Quality
16
=< 1%
=< 3%
=<4%
=>4%
Software Quality Staff / Development Staff
SAMPLE OF135 ORGANISATIONS (1983)
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.

17. PeranTim Software Quality
17
Review
Applications
Provide
Technical Advice
Review
and Build a
Quality Environment
Develop Standards
and Guidelines
Analyse Development Errors

18. TugasTim Software Quality
18
ROLE CHALLENGE TASKS
Review
Applications
Whentoabortaproject
Executivemanagementignorance
Userignorance
Auditrequirements
Evaluate systemsinallphases
Provide managementwithtechnicalassessment
Ascertainuserrequirementsaremet
Ascertainauditrequirementsaremet
Provide
Technical
Advice
Changingtechnology
Useofconsultants
Abilitytokeepcurrenttechnically
Complexityofsystems
Knowcurrenttechnology
Actasinternalconsultant
Actastechnicalconsultant
Knowmanysystems
Reviewand
Builda
Quality
Environment
Howtoevaluatesoftwareproducts
Buildaqualityenvironment
Evaluatesoftwareproducts
Counselmanagement
Develop
Standards
and
Guidelines
Fewsystemsandprogrammingstandards
Professionalism
Helpsetstandards
Evaluate qualityofwork
Analyse
Development
Errors
Knowtypeofproblems
Knowcostofproblems
Knowmagnitudeofproblems
Quantifyproblems
Identifyproblems
Determinecostofproblems

19. Peran UtamaTim Software Quality
Peran utamaTim 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

20. 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

21. TigaTipe 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

22. 22
Software Inspections
Time
No. of Employees
Planning
Requirements
Design Coding
Testing
Without Inspection
With Inspection

23. 23
Inspection Process
Planning
Overview
Individual
Preparation
Rework
Follow-up
Inspection
Meeting

24. 24
Software Inspection Overview
Operation 1 I
Rework
Analysis
Fix short term problems
Error
feedback
•Learning input for inspectors
•What error types to look for
•Better ways to find error types
Feedback

25. 25
Software Inspection Overview
Operation 1 Operation 2I
Rework
Analysis
Fix short term problems
Error
feedback
•Learning input for inspectors
•What error types to look for
•Better ways to find error types
•Error prone modules
ranked.
•Error types
distributions ranked
For Special Attentions
Feedback
Feed forward

26. 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

27. 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

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

29. Inspection che
Fault class Inspection check
Data faults 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
faults
If a linked structure is modified, have all links been
correctly reassigned?
If dynamic storage is used, has space been allocated
correctly?
Is space explicitly de-allocated after it is no longer
required?
Exception
management faults
Have all possible error conditions been taken into
account?

30. 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

31. TigaTipe Software Review (cont)
 Technical Review : review semua bagian
software untuk membuktikan kesesuaian
dengan spesifikasi, dibangun sesuai standard
dan semua perubahan sudah
diterapkan/dilakukan
31

32. Synchronous Review Process

33. Asynchronous Review Process

34. 34
Technical Reviews
Rework/Follow-up
Suitability for
the intended
use?
Software Product
•Review Report
•Action Item List
Technically Qualified Team
Evaluates

35. 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.

36. Referensi
 Ch. 26, Quality Management, Software Engineering:A
Practitioner's Approach, 6/e, Pressman Roger S.,
2005, McGraw-Hill
 Romi SatrioWahono, 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