SOFTWARE QUALITY ASSURANCE

JAMINAN KUALITAS PERANGKAT LUNAK

(SOFTWARE QUALITY ASSURANCE)

**mercubuana.ac.id

Pendekatan rekayasa perangkat lunak yang digambarkan bekerja kearah tujuan tunggal : menghasilkan perangkat lunak berkualitas tinggi.

Apa sebenarnya kualitas perangkat lunak itu ?

Menurut Philip Crosby, kualitas perangkat lunak : …… masalah manajemen kualitas bukanlah suatu hal yang tidak diketahui. Masalahnya adalah apa yang mereka pikir mereka tahu………

Banyak pengembang perangkat lunak terus percaya bahwa kualitas perangkat lunak merupakan sesuatu yang mulai anda khawatirkan setelah kode-kode dilahirkan. Tidak ada yang dapat melebihi suatu kebenaran.

Jaminan kualitas perangkat lunak (Software Quality Assurance [SQA]) adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak.

SQA meliputi :

1. Pendekatan manajemen kualitas
2. Teknologi rekayasa perangkat lunak yang efektif
3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak
4. Strategi pengujian multitiered (deret bertingkat)
5. Kontrol dokumentasi perangkat lunak dan perubahan yang dibuat untuknya
6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak
7. Mekanisme pengukuran dan pelaporan

PENDAHULUAN

Bila ada salju yang jatuh, maka tidak aka nada dua butir salju yang sama. Adalah sangat sulit untuk membayangkan bahwa butiran-butiran salju itu berbeda bentuk sama satu lain. Belum lagi bahwa setiap butir memiliki struktur yang unik. Untuk mengamati perbedaan diantara dua butir salju , kita harus mengamati butiran-butiran itu secara lebih dekat. Mungkin kita dapat melakukannya dengan menggunakan kaca pembesar. Kenyataannya, semakin dekat kita melihat, semakin besar perbedaan yang dapat kita amati.

Fenomena tersebut, variasi antar sampel, sangat sesuai dengan produk manusia seperti halnya ciptaan alam. Sebagai contoh, bila ada dua papan sirkuit yang identik diamati secara cukup dekat, kita dapat mengamati bahwa jalur kecil tembaga pada papan itu sangat berbeda secara geometri, penempatan dan ketebalannya, lokasi dan diameternya sangat bervariasi.

Semua bagian yang direkayasa dan dihasilkan menunjukkan keragaman. Keragaman antar sampel tidak akan nyata tanpa bantuan peralatan yang teliti untuk mengukurnya secara geometri , karakter listrik atau atribut bagian. Tetapi dengan peralatan yang sangat sensitive, kita dapat sampai pada kesimpulan bahwa tidak ada dua sampel yang benar-benar sama.

Apakah prinsip ini sama untuk perangkat lunak dan masalah-masalah fisik ?. Bayangkan lah sebuah program yang pada beberapa titik selama eksekusinya, penyeleksian rekaman dengan urutan naik berdasarkan medan kunci yang ditentukan. Sifat rekaman rekaman tidak dipentingkan. Sifat itu dapat berupa rekaman karyawan, database pelanggan, koordinat peta untuk system control penerbangan real time atau yang lainnnya.

Pemrogram yang menciptakan rutin sorting (atau memilihnya dari sebuah pustaka komponen reuseable) memilih menggunakan quicksort untuk memecahkan masalah yang ada. Dapatkah seorang pengamat produk akhir membedakan perangkat lunak  dari sebuah produk yang sangat  identik yang menggunakan, misalnya buble sort. Mungkin dapat, tetapi mungkin kita membutuhkan lebih banyak informasi dan peralatan yang sangat sensitive untuk membedakan antara kedua system tersebut.

Kontrol variasi merupakan inti dari control kualitas. Pemanufaktur ingin meminimalkan variasi antara produk yang mereka buat, bahkan dalam hal yang kecil sekalipun, seperti menduplikasi disket. Kita ingin meminimalkan variasi diantara pasangan disket yang identik. Hal ini tentu bukan masalah, menduplikasi disket merupakan operasi produksi yang sangat mudah, dan kita dapat menjamin bahwa duplikat perangkat lunak yang tepat selalu dapat dibuat.

Mesin duplikasi disket dapat benar-benar menggunakan dan berjalan dalam batas toleransi, sehingga pada proses yang sederhana sekalipun, seperti duplikas, masalah sehubungan dengan variasi diantara sampel dapat terjadi.

Bagaimana organisasi pengembang perangkat lunak melakukan control variasi ?. Dari satu proyek ke proyek lain, kita perlu meminimalkan perbedaan diantara sumber-sumber daya actual yang digunakan, termasuk penataan staf, perlengkapan dan waktu kalender. Secara umum kita perlu memastikan bahwa program pengujian kita sudah mencakup persentase perangkat lunak yang diketahui dari satu peluncuran ke peluncuran lain.

KUALITAS

American Heritage Dictionary mendefinisikan kata kualitas sebagai “sebuah karakteristik atau atribut dari sesuatu”. Sebagai atribut dari sesuatu, kualitas mengacu kepada

Karakteristik yang dapat diukur- sesuatu yang dapat dibandingkan dengan standar yang sudah diketahui, seperti panjang, warna, sifat kelistrikan, kelunakan dan sebagainya. Tetapi perangkat lunak, yang sebagian besar merupakan entitas intelektual, lebih menantang untuk di karakterisasi dari pada objek fisik.

KONSEP KUALITAS

• general objective: reduce the “variation between samples” ... but how does this apply to software?
• quality control: a series of inspections, reviews, tests
• quality assurance: analysis, auditing and reporting activities
• cost of quality

• appraisal costs
• failure costs
• external failure costs

ADA 2 JENIS KUALITAS PERANGKAT LUNAK

Two kinds of software quality:

1. Quality of design:

the characteristics that the designers specify for an item.

Eg, requirements, specifications, and design

1. Quality of conformance:

the degree to which the design specifications are followed during manufacturing

Eg, implementation

PENGAWASAN KUALITAS (QUALITY CONTROL)

• Involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements
• Includes a feedback loop to the process
• May be manual, automated, or both

• Measurement + feedback

JAMINAN KUALITAS (QUALITY ASSURANCE)

• Consists of the auditing and reporting functions of management
• Tujuan :

• to provide management with the data necessary to be informed about product quality,
• thereby gaining insight and confidence that product quality is meeting its goal

BIAYA KUALITAS (QUALITY COSTS)

1. Prevention costs:
• quality planning, formal technical reviews, test equipment, training
2. Appraisal costs
• include activities to gain insight into product condition the “first time through” each process: in-process & inter-process inspection, equipment calibration & maintenance, testing
3. Failure costs:
• Internal Failure costs: rework, repair, failure mode analysis
• External Failure costs: complaint resolution, product return & replacement, help line support, warranty work
TUGAS MAHASISWA ;
CARI DAN KUMPULKAN KLIPING DARI KORAN, MAJALAH ATAUPUN INTERNET MASING-MASING 5 (LIMA) CONTOH UNTUK SETIAP BIAYA KUALITAS TSB DI ATAS.
KUALITAS PERANGKAT LUNAK
Conformance to
• explicitly stated functional and performance requirements,
• explicitly documented development standards, and
• implicit characteristics that are expected of all professionally developed software
Tiga poin penting dari definisi
1. Software requirements are the foundation from which quality is measured
2. Specified standards define a set of development criteria that guide the engineering
3. A set of implicit requirements often goes unmentioned (eg. Ease of use, maintainability)
JAMINAN KUALITAS PERANGKAT LUNAK
Definisi proses dan standar Pengukuran Rencana Uji coba dan Kaji ulang Analisa dan Pelaporan Kaji ulang bidang teknis
                        SQA
AKTIVITAS SQA
• Software engineers address quality by
• applying solid technical methods & measures,
• conducting formal technical reviews, and
• performing well-planned testing
• SQA group assists the software team in achieving a high quality product by addressing
• quality assurance planning,
• oversight,
• record keeping,
• analysis, &
• reporting
KAJI ULANG DAN INSPEKSI Jerry Weinberg menyebutkan bahwa :
THERE IS NO PARTICULAR REASON WHY YOUR FRIEND AND COLLEAGUE
CANNOT ALSO BE YOUR STERNEST CRITIC.
(Tidak ada alasan khusus mengapa teman dan kolega anda tidak dapat sebagai pengkritik yang tajam (terhadap anda))
APA YANG DIMAKSUD DENGAN KAJI ULANG (REVIEW)
• a meeting conducted by technical people for technical people
• a technical assessment of a work product created during the software engineering process
• a software quality assurance mechanism
• a training ground
BATASAN
• Between 3 and 5 people
• Advance preparation should occur but should require no more than 2 hours of work for each person
• Duration of review meeting should be less than 2 hours
YANG TIDAK TERMASUK DALAM POIN KAJIAN
• Rangkuman anggaran proyek
• Penilaian jadual
• Laporan perkembangan proyek secara menyeluruh
• Intrik-intrik politik atau mekanisme untuk balas dendam
MEMIMPIN KAJIAN
1. Be prepare – evaluate product before the review
2. Review the product, not the producer
3. Keep your tone mild, ask questions instead of making accusations
4. Stick to the review agenda
5. Raise issues, don’t resolve them
6. Avoid discussion of style, stick to technical correctness
7. Schedule reviews as project tasks
8. Record and report all review results
PANDUAN REVIEW
1. Review the product, not the producer
2. Set an agenda and maintain it
3. Limit debate and rebuttal
4. Enunciate the problem areas, but don’t attempt to solve every problem noted
5. Take written notes
6. Limit the number of participants and insists upon advance preparation
7. Develop a checklist for each product that is likely to be reviewed
8. Allocate resources and schedule time for FTRs
9. Conduct meaningful training for all reviewers
10. Review your early review
STATISTIK SQA
• KUMPULKAN INFORMASI TENTANG SEMUA KERUSAKAN
• TEMUKAN PENYEBAB DARI KERUSAKAN
• PINDAH UNTUK MENYEDIAKAN SECARA PASTI UNTUK KEPERLUAN PROSES
PRODUK & PROSES              PENGUKURAN PEMAHAMAN  BAGAIMANA MENINGKATKAN  KUALITAS KEANDALAN PERANGKAT LUNAK (SOFTWARE RELIABILITY)
• The probability of failure-free operation of a computer program in a specified environment for a specified time
• Measures:
MTBF = MTTF + MTTR
• Availability = (MTTF/(MTTF+MTTR)) * 100%
• Software safety is
• SQA activity that focuses on the identification & assessment of potential hazards that may affect software negatively and cause system to fail
ISO 9000
• Describes quality assurance elements in generic terms that can be applied to any business regardless of the products or services offered
• Elements of quality assurance system:
• organizational structure,
• procedures,
• processes, and
• resources to implement quality planning,
• quality control,
• quality assurance, and
• quality improvement
• ISO 9001 – for software engineering
PERENCANAAN SQA
• Provides road map for instituting software quality assurance
• The plan serves as template for SQA activities
• Contents:
• initial section – purpose and scope
• management section – organizational structure
• documentation section – project documents, models, technical documents, user documents
• test section
• tools & methods, SCM, contract, records maintenance,  training, risk