Tugas Jaminan
Mutu Perangkat Lunak
Tantangan Software Quality Assurance
Disusun oleh:
ANIS FAGUSTINA M 0 5 0 9 0 1 0
J U R U S A N I N
F O R M A T I K A
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS SEBELAS MARET SURAKARTA
2012
Software Quality
Assurance [SQA]
adalah Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang
diaplikasikan pada seluruh proses perangkat lunak [1]. Dari sudut
pandang pengamatan tren rekayasa perangkat lunak saat ini, SQA diprediksi akan
menghadapi beberapa tantangan di masa depan, beberapa di antaranya adalah
·
kompleksitas
pertumbuhan dan packages perangkat lunak
·
integrasi pertumbuhan
dan kebutuhan interface
·
jadwal proyek yang
lebih pendek
·
tidak ditoleransinya
pertumbuhan produk perangkat lunak yang cacat
Tidak hanya yang tertera di atas. Tantangan yang dihadapi
terkait SQA tidak lain adalah tantangan utama dalam mengatur pengembangan
proyek, yaitu sebagai berikut:
·
Jadwal.
·
Tenaga
kerja yang diperlukan dan sumber hardware.
·
Evaluasi
resiko.
·
Keorganisasian
: anggota tim, subkontraktor dan kemitraan.
·
Metodologi
proyek dan perangkat pengembangan.
·
Penggunaan
kembali rencana software.
Tantangan utama lain adalah tantangan dalam mengatur rencana
kualitas proyek, yaitu :
·
Pencapaian
akhir kualitas.
·
Kriteria
awal dan akhir setiap tahap proyek.
Menurut Galin, secara umum tantangan SQA terbagi menjadi 2,
yaitu[4] :
a. Keunikan proses pengembangan software
Ketika
akan melakukan pengembangan perangkat lunak, hendaknya kita memperhatikan ciri
khas dari produk kita. Ciri khas yang di miliki inilah yang akan membedakan
dengan produk lain. Keunikan sangat patut untuk diperhatikan. Dan inilah yang
menjadi tantangan kedepannya. Terdapat
perbedaan antara software dengan produk industry lainnya, yaitu sebagai berikut.
|
Karakteristik
|
Software
|
Produk industry lainnya
|
|
Kompleksitas
|
Kompleksitasnya lebih tinggi dan memungkinkan
opsi-opsi operasional yang banyak
|
Kompleksitas
lebih rendah, lebih sedikit opsi operasionalnya
|
|
Visibilitas
|
Invisible, susah mendeteksi kecacatan produk dari
awal dengan penglihatan
|
Visible, dapat mendeteksi kecacatan produk dari awal
dengan penglihatan
|
|
Proses produksi dan pengembangan
|
Peluang deteksi kecacatan pada satu fase, yaitu
product development
|
Peluang deteksi kecacatan pada semua fase produksi
dan pengembangan (product development, production planning, manufacturing)
|
b. Lingkungan dimana metode SQA akan
dilakukan
Selain
keunikan yang diperhatikan, penempatan lingkungan pemakaian produk tersebut
sangat patut untuk diperhatikan juga. Berikut adalah karakteristik utama
lingkungan SQA, yaitu meliputi sebagai berikut.
1.
Contractual
condition
Pengembangan software dilengkapi
dengan kontrak yang berisi kebutuhan fungsional, kebutuhab non fungsional,
project budget, dan timeline.
2.
Subjection
to customer-supplier relationship
Diperlukan kerja sama yang kontinu
antara tim proyek dengan konsumen software untuk mendiskusikan berbagai macam
aspek proyek ataupun perubahan-perubahan yang terjadi.
3.
Interface
with other software
Suatu software package biasanya juga
terkait dengan interface packages lainnya, seperti :
·
Input
interface, dimana interface dari package lain ke dalam software
·
Output
interface, dimana interface dari software ke package lainnya
·
Input
& output interface pada mesin control
4.
Need
to carrying out and maintenance software despite any change
5.
Coordinate
dan corporate with other team
Diperlukan kerja sama antar anggota
tim proyek dengan tim lainnya, yaitu :
·
Tim
software lin dalam organisasi
·
Tim
dari konsumen yang berturut mengambil bagian dalam pengembangan software
·
Tim
pengembang hardware dan software dari supplier lain
·
Tim
pengembang hardware dalam organisasi
6. Teamwork
Coordinate and corporation scheme
Dari banyaknya tools
yang ada saat ini, terdapat 2 tools yang umum digunakan dalam penjaminan kualitas software yaitu
1.
Template, adalah sebuah format
dokumen yang berbentuk seperti daftar isi yang dibuat oleh organisasi atau unit
agar dapat diterapkan ketikan akan melakukan komplisasi laporan atau beberapa
jenis dokumen lainnya[5].
Dilihat dari 2 sudut pandang kegunaannya template yaitu dari
sudut pandang tim pengembang dan tim review. Template memberikan kontribusi
sebagai berikut.
ü
Dalam tim pengembang
template berguna untuk,
·
Memfasilitasi dalam
proses penyusunan dan penyimpanan dokumen.
·
Dokumen yang
disiapkan lebih lengkap
·
Menyediakan kemudahan
integrasi pada tim yang baru
·
Memudahkan dalam
tahap review karena sudah ada standart pada masing-masing struktur.
ü
Dalam tim review
template berguna untuk,
·
Memudahkan mendapatkan
informasi yang dibutuhkan untuk melakukan maintenance pada software atau
perangkat lunak.
Tidak jauh beda dari untung ruginya suatu pemanfataan suatu
produk. Sama dengan produk pada umumnya. Template pun memberikan keuntungan dan
kerugian. Tantangan dalam menggunakan template ini, dapat dilihat dari sisi
keuntungan dan kerugian yang ada. Keuntungan adalah suatu organisasi dapat
cenderung menghemat sumber daya internal mereka. Sedangkan kerugiannya
adalah perbaikan template harus dilakukan oleh tim profesional dan tidak
semua tim dalam suatu organisasi mengetahui keberadaan template.
Unit SQA biasanya bertanggung jawab untuk mempersiapkan
template yang profesional dari jenis laporan yang lebih umum dan dokumen yang
diperlukan staf organisasi. Dalam template pengorganisasian, unit SQA melakukan[5]
:
- Mempersiapkan template baru
- Implementasi template baru atau
meng-update
- Memperbaharui template
2.
Checklist , merupakan daftar item yang khusus dibuat untuk semua jenis
dokumen atau list-list kegiatan yang dapat mengukur dan memeriksa ke komplitan
dari sebuah aktivitas, tujuan dari checklist ini adalah menyediakan daftar item
agar dapat di verifikasi [5].
Sama halnya dengan template yang telah di paparkan di atas. Chehklist
ini juga dapat dlihat kegunaannya dari 2 sudut pandang yaitu dari sudut pandang
tim pengembang dan tim review. Berikut adalah bentuk kontribusi dari checklist.
ü
Dalam tim pengembang checklist
berguna untuk
·
Membantu developers
dalam persiapan mereka untuk tugas-tugas (misalnya instalasi perangkat lunak di
situs pelanggan)
·
Membantu developers
melakukan pemeriksaan sendiri pemeriksaan dokumen atau kode perangkat lunak
sebelum penyelesaian dan menemukan bagian yang tidak lengkap
ü
Dalam tim review
checklist berguna untuk,
·
Membantu
mengefisienkan waktu dalam melakukan aktifitas review pada sebuah perangkat
lunak
·
Dapat menjamin
kelengkapan dokumen review yang dilakukan tim review
Dalam suatu organisasi, persiapan dan pembaharuan checklist yang
dilakukan seperti promosi penggunaanya biasanya ditugaskan pada unit
SQA, unit SQA dilakukan :
- Persiapan
checklist baru
- Promosi
penggunaan checklist
- Meng-update checklist
Studi kasus[4] : IBM field service in operating
system
Fokus utama dari IBM adalah system development dan testing. Solusi
yang ditawarkan adalah mengumpulkan data software errors pada Remote Assitance
Information Network (RETAIN) dan menganalisa,melapokan error dengan Authorized
Program Analusis Reports (APARs).
Authorized Program Analusis Reports (APARs), meliputi :
·
APARs
menganalisa laporan error dengan mengklasifikasikan error menjadi 2 jenis,
regular (mempresentasikan tipe error dari software) dan overlay (software error
akibat kesalahan penyimpanan pada memory)
·
APARs
mengidentifikasi karakter software defect dari pemikiran akan penyebab error,
yakni error type (disebabkan low level programming) dan error trigger
(didasarkan pada klasifikasi event pemicu).
Error Types IBM meliputi
·
Unclassified
: Mengetahui error, namun tidak bisa mengatasi
·
Synchronization
: Kesalahan dalam menguci kode dan melakukan sinkronisasi kode
·
Data
Error : Kesalahan aritmatika yang menyebabkan error producing data
·
Sequence
Error : Kesalahan pengurutan, misalnya kesalahan tampilan pesan yang diikuti
kesalahan action
Error Trigger Events IBM meliputi
·
Boundary
Conditions : Kesalahan limitasi parameter input
·
Bug
Fixes : Bug yang sudah fixed masih tetap mengganggu customer environment
·
Recovery
or Error Handling : Error melakukan handling code dan proses recovery
REFERENSI