Software Quality Assurance

advertisement
UAS – REKAYASA PERANGKAT LUNAK
Software Quality Assurance
HANSI ADITYA KURNIAWAN
9106205405
PROGRAM MAGISTER
MANAJEMEN TEKNOLOGI INFORMASI
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
SURABAYA
2007
Tujuan dari topik Software Quality Assurance (SQA) sebenarnya adalah
untuk menghasilkan suatu produk perangkat lunak (software) yang berkualitas
tinggi. SQA merupakan salah satu aktivitas yang harus dijalani dalam suatu proses
pengembangan software seperti dapat terlihat pada Gambar 1.1.
Common process framework
Framework activities
Task Sets
Tasks
Milestones, Deliverables
SQA Points
Umbrella activities
Gambar 1.1 Proses Pengembangan Software
SQA meliputi beberapa konsep sebagai berikut:
1. Pendekatan kualitas manajemen,
2. Teknologi rekayasa perangkat lunak yang efektif (metode dan tools yang
digunakan),
3. Tinjauan teknis secara formal yang diaplikasikan melalui proses
pengembangan software,
4. Strategi uji coba software yang multitier,
5. Kontrol terhadap dokumentasi software dan perubahannya,
6. Prosedur untuk memastikan pemenuhan standar pengembangan software,
jika software tersebut diaplikasikan, dan
7. Mekanisme pengukuran dan laporan.
KONSEP KUALITAS
Kontrol terhadap kualitas yang umum digunakan adalah kontrol terhadap
variasi. Maksudnya adalah meminimalkan variasi terhadap sesuatu sehingga
kualitas suatu produk dapat terjaga. Hal ini berlaku juga pada pengembangan
software. Dari satu proyek pengembangan software ke proyek lainnya, maka
sedapat mungkin diminimalkan perbedaan antara sumber daya yang diperkirakan
dengan sumber daya yang sesungguhnya digunakan dalam proyek seperti staf,
peralatan, waktu, dan sebagainya. Selain itu, pada umumnya, kontrol kualitas ini
berlaku juga pada uji coba software dari versi satu ke pengembangan versi
berikutnya. Tidak hanya meminimalkan kesalahan (bugs / errors) dari sebuah
versi, akan tetapi juga harus dapat menurunkan kesalahan ketika mengembangkan
versi berikutnya. Hal yang lain berhubungan dengan kontrol terhadap kualitas
suatu software dapat terlihat pada minimalisasi terhadap perbedaan kecepatan dan
akurasi dari respon dukungan masalah yang dialami customer.
Kualitas
Kualitas suatu software dapat diukur melalui karakteristiknya, seperti
kompleksitas, kohesi, jumlah function points (FP), jumlah kode baris (lines of
codes (LOC)), dan masih banyak lagi. Ketika dilakukan pengukuran terhadap
karakteristik-karakteristik tersebut, maka akan muncul 2 jenis kualitas yaitu
sebagai berikut:
•
Quality of design
Kualitas ini sangat erat hubungannya dengan desain dari suatu produk
software. Tingkat material, toleransi, dan performa suatu spesifikasi
berkontribusi besar kepada kualitas. Selama semakin tinggi tingkat
material yang digunakan, semakin ketat toleransinya, dan semakin tinggi
performa level yang dispesifikasikan, maka kualitas software semakin
meningkat, jika produk tersebut sesuai spesifikasi pembuatannya. Dalam
pengembangan software, hal ini meliputi kebutuhan user, spesifikasi, dan
desain sistem.
•
Quality of conformance
Kualitas ini sangat erat hubungannya dengan tingkat spesifikasi desain
yang digunakan selama pembuatan software. Semakin tinggi tingkat
spesifikasinya,
maka
semakin
tinggi
pula
kualitasnya.
Dalam
pengembangan software, hal ini fokus pada implementasi. Jika
implementasi software mengikuti desain, dan hasilnya memenuhi
kebutuhan user serta mencapai tujuan, maka kualitas software tersebut
semakin tinggi.
Akan tetapi, tidak hanya kedua jenis kualitas tersebut yang harus
diperhatikan oleh para software engineers. Menurut Robert Glass, lebih dari
sekedar itu, yaitu:
User satisfaction = compliant product + good quality + delivery within budget and schedule
Menurut Glass, yang terpenting adalah kepuasan user, lebih dari hanya sekedar
kualitas yang bagus. Kualitas bagus tetapi user tidak puas, maka semuanya sia-sia.
Kontrol Kualitas
Kontrol kualitas dilakukan dengan inspeksi, review, dan pengujian untuk
memastikan suatu produk telah memenuhi kebutuhan yang diinginkan. Kontrol
kualitas termasuk feedback, yang berjalan terus menerus dalam proses
menciptakan suatu produk. Kombinasi dari pengukuran dan feedback dapat
membantu menghindarkan kegagalan proses untuk memenuhi kebutuhan.
Aktivitas pada kontrol kualitas dapat dilakukan secara otomatis, manual, atau
kombinasi dari keduanya.
Jaminan Kualitas
Jaminan kualitas terdiri dari proses audit dan melaporkan fungsi dari
manajemen. Tujuannya adalah untuk menyediakan data yang diperlukan kepada
manajemen tentang kualitas produk dan menunjukkan bahwa produk tersebut
sudah memenuhi kebutuhan yang ingin dicapai.
Biaya Kualitas
Studi tentang biaya kualitas menyediakan dasar dari biaya kualitas itu
sendiri, mengidentifikasi peluang untuk mengurangi biaya kualitas, dan
menyediakan normalisasi perbandingan. Biaya kualitas dapat dibagi menjadi
beberapa biaya yang berkaitan dengan pencegahan, penilaian, dan kegagalan.
Yang termasuk biaya pencegahan adalah:
•
Perencanaan kualitas
•
Review teknis formal
•
Perlengkapan pengujian
•
Pelatihan
Yang termasuk biaya penilaian adalah aktivitas untuk mendapatkan informasi
tentang kondisi produk dari setiap proses. Contohnya adalah:
•
Inspeksi proses dan antar-proses
•
Pengujian dan perawatan peralatan
•
Pengujian
Biaya kegagalan adalah biaya yang akan dihilangkan ketika tidak ada kerusakan
produk saat diberikan ke konsumen. Biaya kegagalan dibagi menjadi 2 yaitu biaya
kegagalan internal dan eksternal. Biaya kegagalan internal muncul ketika produk
diberikan kepada konsumen. Yang termasuk dalam biaya kegagalan internal
adalah:
•
Pengerjaan ulang
•
Perbaikan
•
Analisis kegagalan
Biaya kegagalan eksternal berkaitan dengan kerusakan produk setelah produk
tersebut sudah sampai kepada konsumen. Contoh dari biaya kegagalan eksternal
adalah:
•
Adanya komplain konsumen
•
Pengembalian dan penggantian produk
•
Dukungan bantuan
•
Jaminan
SOFTWARE QUALITY ASSURANCE
Banyak literatur yang mengungkapkan definisi dari kualitas software.
Salah satunya, kualitas software didefinisikan sebagai pemenuhan kebutuhan
fungsional dan performansi, yang secara eksplisit didokumentasikan sesuai
standar yang ada, serta secara implisit merupakan pemenuhan harapan dari para
pengembang software.
Latar Belakang
Seperti sudah disinggung sedikit di atas, jaminan kualitas adalah suatu
aktivitas tambahan dari semua bisnis yang menghasilkan produk untuk digunakan
oleh orang lain, yang sudah menjadi tanggung jawab dari pembuat produk
tersebut. Pada jaman sekarang ini, setiap perusahaan mempunyai mekanisme
masing-masing untuk menjamin kualitas dari produk tersebut, dimana hal ini
sudah menjadi kepedulian dari perusahaan.
Sejarah dari SQA berkembang secara paralel dengan sejarah dari
kualitas hardware. SQA diperkenalkan pertama kali pada saat kontrak pembuatan
software di bidang militer pada tahun 1970an, dimana kemudian berkembang ke
dunia komersial. Sebelumnya pada tahun 1950an dan 1960an, jaminan kualitas
suatu software merupakan tanggung jawab tunggal dari seorang programmer.
Akan tetapi, sekarang jaminan kualitas software sudah menjadi tanggung jawab
beberapa pihak, seperti software engineer, manajer proyek software, konsumen,
produsen, distributor, dan masing-masing individu yang terkait dengan produk
tersebut.
Aktivitas SQA
SQA mengandung bermacam-macam tugas yang berhubungan dengan
konstituensi yang berbeda, dimana para pembuat software akan mengerjakan
pekerjaan-pekerjaan teknikal sedangkan grup SQA mempunyai tanggung jawab
untuk merencanakan penilaian kualitas software, pencatatan, analisis, dan
pembuatan laporan atas kualitas software yang telah dibuat. Dari sini, kualitas
para pembuat software dapat dinilai melalui ukuran-ukuran dan metode-metode
tertentu, serta melalui pengujian-pengujian software. Oleh karena itu, para
pembuat software diharapkan dapat membuat suatu produk software yang
berkualitas tinggi. Berikut adalah aktivitas-aktivitas SQA:
•
Mempersiapkan perencanaan SQA untuk sebuah proyek.
•
Berpartisipasi dalam pengembangan sebuah deskripsi proyek software.
•
Meninjau aktivitas pembuatan software untuk memverifikasi pemenuhan
kebutuhan software yang telah didefinisikan sebelumnya.
•
Melakukan audit terhadap produk software untuk memverifikasi
pemenuhan kebutuhan software yang telah didefinisikan sebelumnya.
•
Memastikan
deviasi
dari
pengerjaan
software
dan
produknya
didokumentasikan sesuai format yang ditentukan.
•
Mencatat adanya ketidaksesuaian dan masalah yang terjadi untuk
dilaporkan ke manajemen senior.
Berikut akan dijelaskan satu studi kasus tentang SQA yang digunakan di
Departemen Pertahanan Energi Nuklir. Departemen ini merasa adanya masalah
yang terjadi dan dibutuhkan suatu SQA untuk melakukan audit dan analisis
terhadap masalah tersebut. Tools yang digunakan di studi kasus ini adalah
Integrated Safety Management (IST).
STUDI KASUS
SOFTWARE
QUALITY
ASSURANCE
(SQA)
YANG
BERKAITAN DENGAN KEAMANAN DI DEPARTEMEN
PERTAHANAN ENERGI NUKLIR
Pendahuluan
Departemen Energi dan kontraktornya melakukan pekerjaan berbahaya
yang diperlukan untuk keamanan negara dan memperbaiki lingkungan di fasilitas
produksi energi pertahanan nuklir. Performa dari pekerjaan ini yang paling
penting adalah perlindungan keselamatan bagi publik, pekerja, dan lingkungan itu
sendiri. Kunci dan tools yang digunakan untuk mencapai tujuan tersebut adalah
Integrated Safety Management (ISM), yaitu suatu sistem yang didesain untuk
menjamin syarat suatu keamanan yang terintegrasi dengan perencanaan dan
eksekusi suatu pekerjaan. Fungsi dari ISM adalah melakukan analisis tingkat
bahaya yang muncul dari pekerjaan tersebut dan mengidentifikasi kontrol
tindakan pencegahannya.
Tujuan dari software quality assurance (SQA) di sini adalah untuk
memastikan bahwa software yang dibuat dapat memenuhi syarat yang disebutkan
di ISM. Kode-kode komputer dan model-model serta data yang berhubungan
merupakan data yang penting untuk digunakan. Semuanya itu digunakan sebagai
pendekatan untuk menentukan SQA ketika software tersebut diimplementasikan.
SQA menyediakan ukuran yang didesain untuk memastikan suatu
software berjalan sesuai fungsinya secara konsisten dan modifikasi terhadap
software tersebut tidak menghasilkan suatu masalah yang besar. Ukuran tersebut
harus dipakai sepanjang pengembangan software secara sistematik, mulai testing,
dokumentasi, sampai eksekusi suatu software, dan saat pemeliharaan software.
Adanya pengarahan yang tidak jelas terhadap standar dan kebutuhan dari
SQA dan penggunaannya memunculkan bahaya yang harus segera dianalisis. Dari
sini, beberapa aspek ISM yang dapat digunakan sebagai tools SQA adalah sebagai
berikut:
•
Definisi dan batasan kerja harus diprioritaskan sebagai basis yang
signifikan
untuk
keamanan,
dimana
sering
diputuskan
dengan
menggunakan bantuan tools software.
•
Analisis terhadap bahaya membutuhkan kode berkualitas tinggi untuk
estimasi kepentingan dan konsekuensi akan potensi terjadinya kecelakaan.
•
Identifikasi terhadap kontrol membutuhkan kode berkualitas tinggi untuk
diputuskan terhadap kontrol administrasi dan signifikasi terhadap sistem,
struktur, dan komponen akan adanya keamanan.
•
Tingkah laku kerja yang aman membutuhkan konfidensi yang tinggi
dimana software komputer yaitu Software Instrumentation and Control
(I&C) akan beroperasi lebih tangguh.
Status SQA Sekarang Software di Departemen Pertahanan Energi Nuklir
Suatu integrasi dan infrastruktur yang efektif untuk implementasi SQA
belum ada di Departemen Pertahanan Energi Nuklir. Suatu infrastruktur yang
efektif termasuk riset yang sedang berjalan dan pengembangan dari kode-kode
program, program kontrol konfigurasi kode, pelatihan yang terstandar, dan
petunjuk dari kode-kode program tersebut. Dengan hal-hal ini, yang ditunjang
dengan elemen-elemen lainnya dapat diintegrasikan menjadi suatu infrastruktur
yang dapat memperbaiki masalah SQA di Departemen tersebut. Berikut adalah
fokus detail yang dilakukan:
•
Kode-kode untuk analisis masalah
Kode-kode tersebut digunakan untuk menghitung adanya konsekuensi
terjadinya masalah untuk mendukung identifikasi dan klasifikasi kontrol
serta analisis bahaya.
•
Software Instrumentation and Control (I&C)
Software ini digunakan untuk kontrol terhadap kinerja serta menyediakan
informasi tentang status proses atau sistem secara fisik.
Perbedaan (Gap) Infratruktur di Departemen Pertahanan Energi Nuklir
Sumber masalah yang dialami Departemen ini adalah tidak adanya
infrastruktur yang efektif untuk melakukan SQA. Fungsi umum dari SQA sudah
didefinisikan, akan tetapi tidak dijalankan secara efektif secara teknikal. Selain itu
tidak ada panduan dan training terhadap penggunaan kode-kode yang ada di
Departemen tersebut. Berikut adalah tindakan-tindakan yang dapat digunakan
untuk mengembangkan SQA menjadi lebih baik:
•
Cari
keuntungan
dari
penemuan
Accident
Phenomenology
and
Consequence (APAC). APAC adalah suatu metodologi program yang
dibuat pada tahun 1994 yang digunakan untuk memastikan penggunaan
kode-kode untuk analisis keselamatan dan dapat digunakan untuk
pengembangan kode-kode di masa mendatang. Tanggung jawab SQA
terhadap hal ini adalah:
-
Performa verifikasi dan validasi setelah pengembangan kode
analisis masalah.
-
Perawatan dan distribusi dari kode analisis masalah.
-
Identifikasi lingkup analisis masalah dimana kode yang sekarang
tidak ada dan tidak sesuai, sehingga dibutuhkan teknik dan tools.
-
Pengarahan dari riset dan pengembangan yang sesuai dan fokus
pada pengembangan kode baru untuk memenuhi kebutuhan
lingkup analisis masalah yang sudah didefinisikan sebelumnya dan
menjamin SQA diintegrasikan ke dalamnya.
•
Mengintegrasikan semua usaha dan program Departemen yang terkait
dengan SQA, seperti usaha untuk memperoleh efek yang produktif dan
realisasi yang kompleks. Berikut adalah pengukuran yang dapat dilakukan:
-
Pengembangan atau identifikasi dari standar verifikasi dan validasi,
serta menyetujui kriteria yang wajar di dalam penggunaannya.
-
Memindahkan putusan kepada Departemen untuk memilih standar
SQA yang akan digunakan di dalam operasinya. Termasuk di
dalamnya adalah dengan menggunakan sistem software I&C.
Kesimpulan
Karena di Departemen Pertahanan Energi Nuklir masih belum ada SQA
yang dijalankan, maka diharapkan Departmen dapat melakukan SQA dengan
menggunakan tools ISM. Untuk menerapkan hal tersebut, maka pihak
Departemen membutuhkan hal-hal sebagai berikut:
•
Membuat standar di Departemen untuk secara praktis diterapkan di SQA.
•
Mengidentifikasi semua elemen organisasi yang seharusnya terlibat peda
pembuatan, pengujian, dokumentasi, perawatan, serta eksekusi software.
•
Menyediakan dana yang cukup untuk menjalankan SQA.
•
Menediakan manajemen proyek yang fokus dan terintegrasi untuk
menjalankan SQA.
LAMPIRAN
Berikut adalah lampiran beberapa hasil yang didapatkan dari program
APAC. Tabel-tabel tersebut diambil dari informasi pembuat kode, organisasi, dan
status SQA dari kode. Pada bagian kolom Status SQA/V&V merupakan status
dari SQA yang ada di Departemen hasil dari analisa APAC pada Departemen
tersebut.
Keterangan:
•
Code adalah kode yang menjalankan suatu fungsi tertentu, sebagai contoh
adalah MACCS2 (MELCOR Accident Consequence Code System 2)
adalah suatu kode yang digunakan untuk menghitung kesehatan dan
konsekuensi ekonomi ketika ada kecelakaan akibat radioaktif.
•
Code Developer / Sponsor adalah pembuat kode atau sponsor dari
pembuat kode
•
Current Owner / Technical Support adalah pemilik dari pembuat kode.
•
Status Of SQA/V&V adalah status dari SQA suatu kode
•
General Comments adalah komentar dari internal Departemen
DAFTAR PUSTAKA
Defense Nuclear Facility Safety Board (2000), Quality Assurance For SafetyRelated Software At Department Of Energy Defense Nuclear Facility, Technical
Report
Pressman, R. (2005), Software Engineering : A Practitioner Approach, McGrawHill
Download