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?
3
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)
7
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
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
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
I
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
I
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
