143

Bab IX
Pengujian dan Pengelolaan Perangkat Lunak

1. Unit Kompetensi : Memahami cara melakukan testing, memanajemen,

mengkonfigurasi, dan integrasi.

2. Elemen Kompetensi : Alur kerja untuk testing, manajemen, konfigurasi, dan

integrasi.

3. Kriteria untuk kerja : Membuat spesifikasi untuk testing, manajemen,

konfigurasi, dan integrasi.

9.1 Pengantar
Topik ini merupakan hal penting dalam jaminan kualitas perangkat lunak.
Pentingnya pengujian perangkat lunak dan metode implementasi atau pengelolaan
perangkat lunak dan implikasinya yang mengacu pada kualitas perangkat lunak.
Aspek ini tidak bisa ditawar-tawar karena melibatkan sederetan aktivitas produksi di
mana peluang terjadinya kesalahan manusia sangat besar dan karena
ketidakmampuan manusia untuk melakukan dan berkomunikasi dengan sempurna
maka pengembangan perangkat lunak perlu diiringi dengan aktivitas jaminan
kualitas.
Meningkatnya visibilitas (kemampuan) perangkat lunak sebagai suatu elemen
sistem dan “biaya” yang muncul akibat kegagalan perangkat lunak, memotivasi
dilakukannya perencanaan yang baik melalui pengujian yang teliti. Pada dasarnya,
pengujian merupakan satu langkah dalam proses rekayasa perangkat lunak yang
dapat dianggap sebagai hal yang merusak daripada membangun.
Sejumlah aturan yang berfungsi sebagai sasaran pengujian pada perangkat
lunak adalah:
a. Pengujian adalah proses eksekusi suatu program dengan maksud menemukan
kesalahan
b. Test case yang baik adalah test case yang memiliki probabilitas tinggi untuk
menemukan kesalahan yang belum pernah ditemukan sebelumnya
c. Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan
yang belum pernah ditemukan sebelumnya

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 144

Sasaran itu berlawanan dengan pandangan yang biasanya dipegang yang

menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak ada
kesalahan yang ditemukan. Data yang dikumpulkan pada saat pengujian dilakukan
memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa
menunjukkan kualitas perangkat lunak secara keseluruhan, tetapi ada satu hal yang
tidak dapat dilakukan oleh pengujian, yaitu pengujian tidak dapat memperlihatkan
tidak adanya cacat, pengujian hanya dapat memperlihatkan bahwa ada kesalahan
perangkat lunak.
Sedangkan proses pengelolaan sebagai bagian dari pengujian perangkat lunak
meliputi implementasi dan pengelolaan perangkat lunak dalam lingkungan nyata atau
dimana perangkat lunak tersebut dipergunakan. Pembahasan kita berfokus pada
masalah manajemen dan aktifitas proses khusus yang memastikan bahwa
pengembangan perangkat lunak dilakukan secara benar, memenuhi kriteria yang
sebenarnya, dan pada waktu yang tepat.

Gambar 9.1, Bagian-bagian dari penjaminan mutu perangkat lunak.

Penjaminan mutu perangkat lunak atau Perangkat lunak Quality Assurance
didefinisikan sebagai : kesesuaian yang diharapkan pada semua perangkat lunak
yang dibangun dalam hal fungsi yang diharapkan dan unjuk kerja, standar
pengembangan yang terdokumentasi dan karakteristik yang ditunjukkan oleh
perangkat lunak. Hal ini menekankan pada 3 hal yaitu:

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 145

a. Kebutuhan perangkat lunak adalah pondasi ukuran kualitas perangkat lunak,

apabila tidak sesuai dengan kebutuhan yang ditentukan maka kualitaspun
kurang
b. Jika menggunakan suatu standar untuk pengembangan perangkat lunak
maka jika tidak memenuhi standar tersebut maka dianggap kurang
berkualitas.
c. Sering terjadi ada kualitas yang secara langsung diutarakan (tersirat) seperti
kemudahan penggunaan dan pemeliharaan yang baik. Kualitas perangkat
lunak kerap dipertanyakan jika tidak memenuhi kebutuhan ini.

9.2 Penjaminan Mutu

Software Quality Assurance atau SQA merupakan perluasan dari definisi di atas.
SQA adalah serangkaian aktifitas yang sistematik dan terencana dalam rangka
memastikan kualitas dari program aplikasi yang dibuat atau perangkat lunak yang
dikembangkan. Kelompok SQA adalah sekumpulan orang-orang yang menjalankan
aktifitas-aktifitas SQA. Mereka bertindak selaku wakil dari klien, yaitu dengan
melihat dan memeriksa perangkat lunak dari sudut pandang klien.
SQA terdiri dari berbagai macam aktifitas yang berhubungan dengan dua kelompok
kepentingan yaitu:
 Praktisi atau orang-orang yang mengembangkan perangkat lunak yang
mengerjakan pekerjaan teknik, yang menerapkan metode dan pengukuran
yang tepat, melakukan rapat teknis, dan menguji perangkat lunak.
 Kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan
kualitas, pencatatan, analisa dan pelaporan. Beberapa kegiatan dari kelompok
ini antara lain membuat rencana SQA untuk suatu proyek, . Ikut membuat
gambaran proses perangkat lunakg yang akan digunakan untuk proses
pembuatan perangkat lunak, melakukan review aktifitas rekayasa perangkat
lunak untuk memastikan kesesuaian dengan proses yang ditentukan,
melakukan audit hasil kerja perangkat lunak, memastikan penyimpangan
yang terjadi dalam kerja perangkat lunak serta hasil kerja terdokumentasi dan
diatasi sesuai dengan prosedur penjaminan mutu yang telah ditetapkan
sebelumnya.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 146

Sebuah strategi, untuk pengujian perangkat lunak mengintegrasikan metode

desain kasus pengujian perangkat lunak kedalam langkah-langkah terencanaan yang
tersusun rapi sehingga menghasilkan konstruksi perangkat lunak yang sukses. Oleh
karena itu, strategi pengujian manapun harus menyertakan perencanaan pengujian,
desain kasus pengujian, pelaksanaan pengujian dan koleksi serta evaluasi data
resultan.

Formal
Sofware Technical
Engineering Reviews Measurement
Methods

QUALITY

Standards
& SCM Testing
Procedures &
SQA

Gambar 9.2, Mutu sebagai titik utama dalam pengembangan perangkat lunak.
Metode Software Engineering menyediakan dasar dari mutu yang mana yang
akan dipakai seperti, metode Analisa, Disain dan Konstruksi berupa tindakan untuk
meningkatkan kualitas dengan menyediakan teknik yang seragam dan hasil yang
sesuai dengan keinginan. Metode Formal Technical Reviews menolong untuk
memastikan kualitas kerja produk merupakan hasil konsekuensi dari setiap langkah
software engineering. Metode Measurement diberlakukan pada setiap elemen dari
konfigurasi perangkat lunak. Metode Standards and Procedures membantu untuk
memastikan keseragaman dan formalitas dari SQA untuk menguatkan dasar “filosofi
kualitas total”. Metode Testing menyediakan cara terakhir dari tingkat kualitas mana
yang dapat dicapai dan dengan praktis dapat mengetahui letak kesalahan. Tujuan
utama dalam pengelolaan jaminan mutu perangkat lunak adalah untuk tidak menutup
kesalahan (defects) pada perangkat lunak termasuk pada kebutuhan dari analisa
kebutuhan, desain terdokumentasi dalam spesifikasi desain, pengkodean
(implementasi), sumber sistem dan lingkungan sistem, masalah-masalah hardware
dan antarmuka terhadap perangkat lunak.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 147

Strategi pengujian perangkat lunak haruslah cukup fleksibel untuk

mempromosikan kreatifitas dan penyesuaian yang diperlukan bagi pengujian semua
sistem perangkat lunak berskala besar. Pada saat yang sama, strategi haruslah cukup
kaku untuk mempromosikan perencanaan yang layak dan penelurusan manajemen
sebagai jalannya proyek.
Dalam berbagai bentuk, pengujian atau testing adalah proses yang bersifat
individu dan banyaknya jenis perbedaan dari variasi pengujian sebanyak perbedaan
dalam pendekatan pengembangan. Pada dekade sebelumnya, cara menghadapi
kesalahan pemrograman adalah disain yang hati-hati dan kecerdasan alami dari
pemrogram.. Sekarang kita berada pada masa dimana teknik desain modern dan
review dari teknik formal membantu kita untuk menurunkan jumlah dari kesalahan
yang terinisialisasi dan tidak dapat dipisahkan dari kode. Dengan cara yang sama,
metode pengujian yang berbeda diawali untuk mengikat kesalahan kedalam beberapa
pendekatan dan filosofi yang berbeda.
Pendekatan dan filosofi inilah yang akan disebut strategi dimana meliputi pengujian
atau testing adalah aktifitas yang dapat direncanakan kedepannya dan
penyelenggaraannya secara sistematis. Karena alasan ini untuk pengujian perangkat
lunak haruslah didefinisikan dalam proses rekayasa perangkat lunak.
Sejumlah strategi pengujian perangkat lunak telah diutarakan dalam berbagai
literatur. Semuanya menyediakan template atau media bantu bagi pengembang
perangkat lunak dengan template untuk pengujian dan semuanya memiliki memiliki
karakteristik umum yaitu pengujian dan validasi.
Pengujian dimulai pada level modul dan bekerja keluar kearah integrasi pada
sistem berbasiskan komputer Teknik pengujian yang berbeda sesuai dengan pokok-
pokok atau butir-butir yang berbeda pada waktunya. Pengujian biasanya dilakukan
oleh pengembang dan untuk proyek yang besar dilakukan oleh kelompok penguji
yang independent. Berbeda dengan pengujian, debugging adalah aktivitas yang
berbeda tetapi debugging harus diakomodasikan pada setiap strategi pengujian.
Sebuah strategi untuk pengujian perangkat lunak harus mencakup pula pengujian
tingkat rendah yang diperlukan untuk memverifikasi segmentasi kode sumber yang
kecil apakah telah dengan benar diimplementasikan sebaik pengujian pada pengujian
tingkat tinggi yang memvalidasi fungsi sistem utama dalam menghadapi kebutuhan
pemakai.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 148

Kegiatan verifikasi menunjuk pada kumpulan aktifitas yang memastikan bahwa

perangkat lunak mengimplementasi sebuah fungsi spesifik. Sedangkan kegiatan
Validasi lebih mengarah ke sebuah kumpulan berbeda dari aktivitas yang
memastikan bahwa perangkat lunak yang telah dibuat dapat di-telurusi terhadap
kebutuhan pemakai.
9.3. Tahapan dan Jenis Penjaminan Mutu.
9.3.1. Tahapan Jaminan Mutu
Sebelum mengaplikasikan metode untuk mendesain test case yang efektif,
pengembang perangkat lunak harus memahami prinsip dasar yang menuntun
pengujian perangkat lunak, yaitu:
 Semua pengujian harus dapat ditelusuri sampai ke persyaratan
pelanggan, maksudnya mengungkap kesalahan dari cacat yang menyebabkan
program gagal.
 Pengujian harus direncanakan lama sebelum pengujian itu mulai,
maksudnya semua pengujian dapat direncanakan dan dirancang sebelum
semua kode dijalankan.
 Prinsip Pareto berlaku untuk pengujian perangkat lunak, maksudnya
dari 80% kesalahan yang ditemukan selama pengujian dapat ditelusuri sampai
20% dari semua modul program.
 Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian
“yang besar”, Selagi pengujian berlangsung maju, pengujian mengubah
focus dalam usaha menemukan kesalahan pada cluster modul yang
terintegrasi dan akhirnya pada sistem.
 Pengujian yang mendalam tidak mungkin karena tidak mungkin
mengeksekusi setiap kombinasi jalur skema pengujian dikarenakan jumlah
jalur permutasi untuk program menengah pun sangat besar.
 Untuk menjadi paling efektif, pengujian harus dilakukan oleh pihak
ketiga yang independent
Dalam lingkungan yang ideal, pengembang mendesain suatu program
komputer, sebuah sistem atau produk dengan testabilitas dalam pikirannya. Hal ini
memungkinkan individu yang berurusan dengan pengujian mendesain test case yang
efektif secara lebih mudah. Testabilitas adalah seberapa mudah sebuah program
computer dapat diuji.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 149

Karena sangat sulit, perlu diketahui apa yang dapat dilakukan untuk membuatnya
menjadi lebih mudah. Procedural dan menggunakannya sebagai pedoman untuk
menetapkan basis set dari jalur eksekusi.

Gambar 9.3, Hubungan Antara Metode Pengembangan dan Pengujian Perangkat

Lunak.
Diagram diatas menunjukkan dua langkah yaitu proses rekayasa perangkat
lunak (software engineering) dan proses strategi pengujian perangkat lunak. Untuk
proses software engineering :
Software Engineering mendefinisikan peran dari perangkat lunak dan mengarahkan
ke kebutuhan analisa perangkat lunak, sebagai pusat kriteria informasi, fungsi,
perilaku, performa, batasan dan validasi dari perangkat lunak yang dibangun.
Bergerak kedalam sepanjang spiral, hingga design dan terakhir proses koding (code).
Untuk proses strategi pengujian perangkat lunak :
Dimulai dari Unit Testing yang dikonsentrasikan pada setiap unit perangkat lunak
seperti yang diterapkan dalam kode sumber. Kemudian bergerak keluar hingga ke
integration testing dimana fokus pada desain dan konstruksi pada arsitektur
perangkat lunak. Kemudian bergerak lagi hingga ke validation testing dimana
kebutuhan dibentuk sebagai bagian dari software requirement analysis yang
divalidasi berdasarkan software yang dibentuk.
Terakhir pada sistem testing dimana software dan element system lainnya diuji secara
keseluruhan.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 150

9.3.2 Langkah-langkah Pengujian

Terdapat empat langkah pengujian yaitu :
 Unit testing – pengujian dilakukan pada setiap unit yaitu mencoba alur yang
spesifik pada struktur modul kontrol untuk memastikan pelengkapan secara
penuh dan pendeteksian error secara maksimum. Pengujian unit: Komponen
individual yang diuji secara independen untuk memastikan kualitasnya.
Fokusnya untuk tidak menutup kesalahan pada perancangan dan
implementasi, meliputi: struktur data pada sebuah komponen logika program
dan struktur program pada sebuah komponen antar muka komponen fungsi
dan operasi dari sebuah komponen. Pihak yang melaksanakan pengujian
adalah pengembang dari komponen tersebut.
 Integration testing – pengujian dengan menggabungkan unit yaitu
pengalamatan dari isu-isu yang diasosiasikan dengan masalah ganda pada
verifikasi dan konstruksi program. Merupakan teknik sistematik untuk
membangun struktur program pada saat melakukan pengujian untuk mencari
kesalahan. Secara obyektif untuk mengambil modul unit test dan membangun
struktur program yang telah dirancang oleh desainnya. Tujuan utamanya
untuk menemukan kesalahan pada :
o Desain dan konstruksi arsitektur perangkat lunak.
o Fungsi-fungsi yang terintegrasi atau operasi pada level sub-sistem
o Interface dan interaksi diantaranya
o Integrasi sumber daya dan/atau integrasi lingkungan
Pihak yang melaksanakan pengujian adalah pengembang dan / atau test
engineer.
 High-order test yang dilaksanakan ketika software telah selesai diintegrasikan
atau dibangun menjadi satu dan tidak terpisah-pisah
 Validation test yaitu menyediakan jaminan akhir bahwa software memenuhi
semua kebutuhan fungsional, kepribadian dan performa.
Untuk lebih jelas urutan dan tahapan pengujian perangkat lunak sebagai bagian
dari penjaminan mutu dapat dilihat pada gambar berikut ini.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 151

Gambar 9.4, Langkah-langkah Pengujian

Jika pengujian telah selesai, berarti telah memenuhi kriteria:
 Dengan menggunakan model statisitik dan teori reliabilitas perangkat lunak,
model dari kegagalan perangkat lunak tidak terdeteksi selama pengujian sebagai
fungsi dari waktu eksekusi dapat dikembangkan
a. Sebuah versi dari model kegagalan yang disebut logarithmic Poisson
execution-time model.

Gambar 9.5, Grafik intensitas kegagalan sebagai fungsi dari waktu eksekusi
Fungsi diatas dapat disederhanakan menjadi
f(t) = jumlah kegagalan secara kumulatif yang diharapkan terjadi ketika
software telah diuji dalam waktu tertentu, t.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 152

l0 = inisial intensitas kegagalan software(kegagalan per unit dalam satuan

waktu) pada awal testing
p = reduksi secara eksponensial pada intensitas kegagalan atas error yang
tidak terdeteksi dan perbaikan yang dibuat

9.4 Jenis-Jenis Pengujian Untuk Penjaminan Mutu

Sasaran utama desain test case adalah untuk mendapatkan serangkaian
pengujian yang memiliki kemungkinan tertinggi di dalam pengungkapan kesalahan
pada perangkat lunak. Untuk mencapai sasaran tersebut, digunakan 4 kategori yang
berbeda dari tehnik disain test case: Pengujian white-box, pengujian black-box,
Integrasi Bottom-Up dan Integrasi Top-Down. Selanjutnya masing-masing kategori
dapat diuraikan sebagai berikut :
 Pengujian white-box berfokus pada struktur kontrol program. Test case
dilakukan untuk memastikan bahwa semua statemen pada program telah
dieksekusi paling tidak satu kali selama pengujian dan bahwa semua kondisi
logis telah diuji. Pengujian basic path, tehnik pengujian white-box, menggunakan
grafik (matriks grafiks) untuk melakukan serangkaian pengujian yang
independent secara linear yang akan memastikan cakupan. Pengujian aliran data
dan kondisi lebih lanjut menggunakan logika program dan pengujian loop
menyempurnakan tehnik white-box yang lain dengan memberikan sebuah
prosedur untuk menguji loop dari tingkat kompleksitas yang bervariasi.
Pengujian black-box didesain untuk mengungkap kesalahan pada persyaratan
fungsional tanpa mengabaikan kerja internal dari suatu program.
 Tehnik pengujian black-box berfokus pada domain informasi dari perangkat
lunak, dengan melakukan test case dengan menpartisi domain input dari suatu
program dengan cara yang memberikan cakupan pengujian yang mendalam.
Metode pengujian graph-based mengeksplorasi hubungan antara dan tingkah laku
objek-objek program. Partisi ekivalensi membagi domain input ke dalam kelas
data yang mungkin untuk melakukan fungsi perangkat lunak tertentu. Analisis
nilai batas memeriksaa kemampuan program untuk menangani data pada batas
yang dapat diterima. Metode pengujian yang terspesialisasi meliputi sejumlah
luas kemampuan perangkat lunak dan area aplikasi.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 153

GUI atau Graphical User Interface, arsitektur client/ server, dokumentasi dan
fasilitas help dan sistem real time masing-masing membutuhkan pedoman dan
tehnik khusus untuk pengujian perangkat lunak.

Gambar 9.6, Blok Diagram Pengujian Black-Box & White Box.

 Integrasi Top-Down adalah pendekatan incremental dengan menggerakkan
ke bawah melalui hirarki control, dimulai dengan control utama. Strategi
intergrasi top-down memeriksa control mayor atau keputusan pada saat awal
di dalam proses pengujian. Pada struktur program yang difaktorkan dengan
baik, penarikan keputusan terjadi pada tingkat hirarki yang lebih tinggi
sehingga terjadi lebih dulu. Strategi top-down kelihatannya tidak sangat
rumit, tetapi di dalam praktenya banyak menimbulkan masalah logistic.
Biasanya masalah ini terjadi jika dibutuhkan pemrosesan di dalam hirarki
pada tingkat rendah untuk menguji secara memadai tingkat yang lebih tinggi.
 Pengujian Integrasi Bottom-up memulai konstruksi dan pengujian dengan
modul atomic (modul pada tingkat paling rendah pada struktur program).
Karena modul diintegrasikan dari bawah ke atas, maka pemrosesan yang
diperlukan untuk modul subordinate ke suatu tuingkat yang diberikan akan
selalu tersedia dan kebutuhan akan stub dapat dieliminasi. Strategi integrasi
bottom-up dapat diimplementasi dengan langkah-langkah:
1. Modul tingkat rendah digabung ke dalam cluster (build) yang melakukan
subfungsi perangkat lunak spesifik.
2. Driver (program control untuk pengujian) ditulis untuk mengkoordinasi
input dan output test case cluster diuji
3. Driver diganti dan cluster digabungkan dengan menggerakkannya ke atas
di dalam struktur program.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 154

9.5 Pengukuran Kualitas Perangkat Lunak

The Institute of Electrical and Electronic Engineers (IEEE) mendefinisikan
kualitas sebagai "the degree to which a system, component or process meets
customer or user needs or expectations" (IEEE90). Definisi dari IEEE digunakan
dalam konteks suatu sistem perangkat lunak secara rinci. kualitas adalah suatu atribut
dari sistem yang berjalan yang sangat erat kaitannya dengan resiko.
Semakin tinggi resiko yang didapatkan dan kemudian dikuranginya maka akan tinggi
kualitas yang dihasilkannya. Dengan cara yang sama, lebih cepat resiko dikenali dan
dikurangi, akan lebih tinggi pula kualitasnya. Hasil dari sebuah aktivitas yang
terencana, bukan kejadian yang spontan berbanding terbalik dengan delivery date
85% kesalahan ada pada proses,15% pada pada sumber daya manusia yang terlibat.
Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi
yaitu: pemodelan proses pengembangan (process), pemodelan pengukuran produk
(product), dan pemodelan manajemen dan interaksi manusia (human). Pemahaman
suatu disiplin melibatkan pembangunan model, pengujian model dan pelajaran untuk
dipahami dalam aplikasi yang nyata. Pengembang kualitas prima perangkat lunak
harus berhadapan dengan unsur-unsur pada kotak berikut ini.

Model [M] [M*PROCESS] [M*PRODUCT] [M*HUMAN]

Testing [T] Process Product Human = [T*PROCESS] [T*PRODUCT] [T*HUMAN]
Data [D] [D*PROCESS] [D*PRODUCT] [D*HUMAN]

Unsur-unsur perangkat lunak utama dari sistem kualitas perangkat lunak

ditunjukkan pada gambar di bawah. Pengintegrasian dari semua unsur-unsur sistem
kualitas memerlukan suatu model.
Permasalahannya untuk diperbaiki oleh dua model berikut :
 Penanganan kompleksitas dalam disiplin dari sistem kualitas dan unsur-unsurnya
dan
 Penunjukan beberapa kelemahan dari model existing process.
Kompleksitas proses pengembangan dan dokumentasinya serta perubahan
dokumentasi selama pemeliharaan adalah permasalahan penting dalam peningkatan
kualitas.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 155

Dokumentasi yang dievaluasi sering sangat banyak dan kompleks. Oleh karena itu,
hubungan kompleksitas antara produk data teknis, dokumentasi perencanaan,
pengujian kebutuhan dan tahapan unsur-unsur life cycle pengembangan yang
berbeda mengakibatkan dokumentasi ini sulit untuk dievaluasi dalam meyakinkan
semua aktivitas telah cukup dikerjakan. Dokumentasi menyediakan komunikasi antar
semua kelompok terkait dengan pengembangannya dan kendali proses proyek
tersebut.
Menurut Schweiggert perlu beberapa pertimbangan untuk masalah dokumentasi:
“Software in the application process must be constantly adapted and altered. The
maintenance programmer usually does not have the time alteration to
documentation. Often suitable tools are not available either. This causes the quality
of documentation to suffer”
Metoda tradisional untuk verifikasi kualitas, seperti checklist bisa gagal dalam proses
pengembangan software yang kompleks. Audit dan review tidak bisa dilakukan tanpa
menggunakan bantuan dan alat yang membantu mengidentifikasi pemenuhan standar
dan prosedur. Lebih dari itu, kompleksitas proses pengembangan dan perubahan
yang tak terkontrol dari unsur-unsur proses secara negatif berdampak pada kualitas.
Daur hidup pengembangan perangkat lunak yang berbeda dapat diusulkan. Hal ini
dapat memungkinkan adanya perbedaan motivasi, kekuatan dan kelemahan. Tidak
ada model lifecycle atau daur hidup yang umum disesuaikan dengan lingkungan
pengembangannya. Dalam model daur hidup tradisional, hubungan antara tahapan
unsur-unsur daur hidup pengembangan perangkat lunak yang berbeda tidaklah cukup
terwakili. Oleh karena itu, sulit untuk menguraikan efek segala perubahan dalam
kebutuhannya yang ditetapkan atas kualitas, keselamatan dan sasaran hasil dari
perangkat lunak. Lebih dari itu, keberadaan komputer dapat membantu untuk
aplikasi model proses yang tidak fleksibel dan sulit untuk ditangani karena
kekompleksitasnya. Dalam lifecycle pengembangan perangkat lunak, identifikasi
hubungan antara kelompok organisasi sangat penting untuk beberapa pertimbangan
berikut:
 Pengembangan Proses harus berhadapan dengan kompleksitas dan perubahan
kebutuhan, pengujian metoda, teknologi, ukuran dan lain lain;
 Kesalahan perangkat lunak yang dihasilkan baik dalam suatu tahapan proses
pengembangan software maupun sebagai alat penghubung antara dua tahapan;

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 156

 Dukungan kuat dari manajemen puncak merupakan suatu faktor utama dalam
mempengaruhi proses pengembangan tersebut.
Kualitas perangkat lunak (software quality) adalah tema utama kajian dan
penelitian turun temurun dalam sejarah ilmu rekayasa perangkat lunak. Kajian
dimulai dari apa yang akan diukur (apakah proses atau produk), apakah memang
perangkat lunak bisa diukur, sudut pandang pengukur dan bagaimana menentukan
parameter pengukuran kualitas perangkat lunak. Bagaimanapun juga mengukur
kualitas perangkat lunak memang bukan pekerjaan mudah. Ketika seseorang
memberi nilai sangat baik terhadap sebuah perangkat lunak, orang lain belum tentu
mengatakan hal yang sama. Sudut pandang seseorang tersebut mungkin berorientasi
ke satu sisi masalah (misalnya tentang reliabilitas dan efisiensi perangkat lunak),
sedangkan orang lain yang menyatakan bahwa perangkat lunak itu buruk
menggunakan sudut pandang yang lain lagi (useabilitas dan aspek desain).
Kualitas perangkat lunak dapat dilihat dari sudut pandang proses pengembangan
perangkat lunak (process) dan hasil produk yang dihasilkan (product). Dan penilaian
ini tentu berorientasi akhir ke bagaimana suatu perangkat lunak dapat dikembangkan
sesuai dengan yang diharapkan oleh pengguna.

Gambar 9.7, Hubungan kualitas, perangkat lunak dan karakteristik

Dari sudut pandang produk, pengukuran dapat dilakukan dengan cara sebagai
berikut, dalam pembahasan ini, kita akan melihat parameter dan metode pengukuran
menurut Kelvin dalam Wahono (2006),
Pendekatan engineering menginginkan bahwa kualitas perangkat lunak ini dapat
diukur secara kuantitatif, dalam bentuk angka-angka yang mudah dipahami oleh
manusia.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 157

Untuk itu perlu ditentukan parameter atau atribut pengukuran. Menurut taksonomi
McCall, atribut tersusun secara hirarkis, dimana level atas (high-level attribute)
disebut faktor (factor), dan level bawah (low-level attribute) disebut dengan kriteria
(criteria). Faktor menunjukkan atribut kualitas produk dilihat dari sudut pandang
pengguna. Sedangkan kriteria adalah parameter kualitas produk dilihat dari sudut
pandang perangkat lunaknya sendiri. Faktor dan kriteria ini memiliki hubungan
sebab akibat (cause-effect). Tabel berikut menunjukkan daftar lengkap faktor dan
kriteria dalam kualitas perangkat lunak menurut McCall
Tabel 9.1, Faktor dan Kriteria Kualitas
Faktor (efek) Kualitas Kriteria Kualitas

Ketepatan (correctness) Kelengkapan, konsistensi, traceability

Keandalan (reliability)
Efisiensi (efficiency)
Integritas (integrity)
Kegunaan (usability)
Perbaikan (maintainability)
Pengetesan (testability)
Fleksibelitas (fleksibility)
Portabilitas (portability)
Penggunaan Kembali (reusability)
Interoperabilitas (interoperability)
Akurasi, toleransi kesalahan, konsistensi,
kesederhaan
Efisiensi eksekusi, efisiensi storage
Kontrol akses, akses audit
Komunikasi, pengoperasian, training
Konsistensi, singkat, sederhana, teratur, self-
documentation
Kesederhanaan, teratur, instrumentasi,
selfdocumentation
Expandability, generality, teratur, self-
documentation
Software system independence, hardware
independence, self-documentation, teratur
Generality, Software system independence,
hardware independence, self-documentation,
teratur
Communication commonality, data
commonality,
Modularity

Kualitas software diukur dengan metode penjumlahan dari keseluruhan

criteria dalam suatu faktor sesuai dengan bobot (weight) yang t elah ditetapkan.
Rumus pengukuran yang digunakan adalah:
Fa = w1c1 + w2c2 + … + wncn
Dimana:
Fa adalah nilai total dari faktor a
wi adalah bobot untuk kriteria i
ci adalah nilai untuk kriteria i

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 158

Kemudian tahapan yang harus kita tempuh dalam pengukuran adalah sebagai
berikut:
1. Tentukan kriteria yang digunakan untuk mengukur suatu faktor
2. Tentukan bobot (w) dari setiap kriteria (biasanya 0 <= w <= 1)
3. Tentukan skala dari nilai kriteria (misalnya : 0 <= nilai kriteria <= 10)
4. Berikan nilai pada tiap criteria
5. Hitung nilai total dengan rumus
Fa = w1c1 + w2c2 + … + wncn
Untuk mempermudah pemahaman, akan diberikan sebuah contoh pengukuran
kualitas perangkat lunak dari faktor usabilitas (usability). Yang akan diukur adalah
dua buah perangkat lunak yang memiliki fungsi untuk mengkontrol peralatan
elektronik (electronic device). Perangkat lunak yang pertama bernama
TukangKontrol, sedangkan kedua bernama Caktrol. Contoh dan hasil pengukuran
dapat dilihat pada Table 9.2 dan 9.3.

Tabel 9.2, Contoh Pengukuran Usabilitas Dua Perangkat Lunak

Tabel 9.3, Hasil Pengukuran Usabilitas Dua Perangkat Lunak

Dari penghitungan yang ada di Tabel 9.3, dapat kita simpulkan bahwa dari
faktor usabilitas, kualitas dari perangkat lunak bernama TukangKontrol lebih baik
daripada Caktrol. Nilai total TukangKontrol untuk faktor usabilitas adalah 16.8,
sedangkan Caktrol adalah 10.2 (dari maksimum total nilai 20).

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 159

9.6 Pemodelan Pengukuran Kualitas Perangkat Lunak

Para ahli menyarankan bahwa dalam membuat dan menentukan kualitas
perangkat lunak sebaiknya menerapkan, mengukur, mengevaluasi dan meningkatkan
mutu perangkat lunak sepanjang daur hidupnya. Pengetahuan yang luas tentang
rekayasa perangkat lunak memerlukan suatu pendekatan yang terstruktur dan
sistematis dengan mempertimbangkan pengalaman yang diperolehnya. Jika mungkin,
disesuaikan dengan praktek industri sebenarnya.
Suatu pendekatan terstruktur tidak terbatas pada tiga komponen utama yang terpusat
pada inti pengetahuan perangkat lunak. Contohnya komponen Quality Requirements
didapatkan dengan adanya prasyarat:
 Kualitas kebutuhan (Quality requirements)
 Pengukuran kualitas dan instrument evaluasi (Quality measurement and
evaluation instruments)
 Implementasi kualitas dalam lifecycle (In-lifecycle quality implementation)
Pengetahuan dalam mendapatkan komponen Quality requirement (QR) sangat
diperlukan terutama bagi kalangan ahli software dalam mempertimbangkan dan
memperoleh kebutuhan yang berkualitas sehingga benar-benar didapatkan high-level
stakeholder’s requirements. Karena itu untuk mendapatkan kemudian untuk QR
digambarkan pengukuran kualitas dalam gambar di bawah ini.

Gambar 9.8, Model Dekomposisi quality requirement menurut Suryn dkk

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 160

Model dekomposisi yang diusulkan didasarkan pada model kualitas dari

ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari
penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External
Quality Requirements), yang mana pada gilirannya berperan untuk menetapkan
kebutuhan mutu internal (Internal Quality requirements). Model tersebut
didokumentasikan dengan baik sehingga relatif mudah untuk dipelajari dan
digunakan akan tetapi sedikit statis dalam perubahannya. Karena itu, ahli SQ yang
baik seharusnya mengetahuinya tidak hanya apa? tetapi juga bagaimana?.
Pendekatan ini ditujukan oleh model tersebut untuk proses praktis dalam melukiskan
dan mengendalikan kualitas kebutuhan

Gambar 9.9, Proses Praktis definisi dan control quality requirement menurut Suryn
dkk.
Pada gambar di atas, anak panah dengan garis yang tidak putus-putus
menunjukkan alur tentang " bagaimana", yaitu menanyakan tentang eksekusi
dekomposisi kebutuhan. Yang ada dalam kotak berisi tentang pertanyaan " apa " ,
yaitu menggambarkan kebutuhan apa yang diakibatkan oleh proses dekomposisi.
Sedangkan anak panah dengan garis putus-putus menandai adanya alur pokok dari
traceability kebutuhan.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 161

Pengetahuan teoritis dan praktis yang menjawab pertanyaan diatas membutuhkan

ahli yang berkompeten tentang Software Quality (SQ) untuk mengatur proses
definisi dan analisis kebutuhan. Komponen dari The Quality Measurement and
Evaluation Instruments memiliki tujuan untuk mendidik para ahli SQ tentang
keberadaan model kebutuhan dan mengukur pemilihan perangkat lunak dalam
proses mendukung aktivitasnya. Demikian juga, dua unsur tersebut sebaiknya
didokumentasikan sehingga mudah untuk dipelajari walau sedikit statis. Rancang
bangun merupakan bagian dari pengetahuan dimana pemetaan tentang suatu
instrumen ke dalam tahapan daur hidup perangkat lunak trlihat pada gambar di
bawah sangat sedikit didokumentasikan dan memerlukan riset lebih lanjut .

Gambar 9.10, Pemetaan pengukuran kualitas software dan evaluasi fase lifecycle
software
Komponen terakhir dari hasil lifecycle quality implementation diakibatkan oleh
dua Komponen yang sebelumnya di mana pengetahuan dasar telah didapatkan.
Implementasi sekarang memerlukan aplikasi yang praktis tidak sekedar dengan
pengetahuan tersebut tetapi juga dalam proses pengembangan perangkat lunak.

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 162

9.7 Rangkuman
Penjaminan mutu perangkat lunak atau Perangkat lunak Quality Assurance
didefinisikan sebagai : kesesuaian yang diharapkan pada semua perangkat lunak
yang dibangun dalam hal fungsi yang diharapkan dan unjuk kerja, standar
pengembangan yang terdokumentasi dan karakteristik yang ditunjukkan oleh
perangkat lunak.
Software Quality Assurance atau SQA merupakan perluasan dari definisi di
atas. SQA adalah serangkaian aktifitas yang sistematik dan terencana dalam rangka
memastikan kualitas dari program aplikasi yang dibuat atau perangkat lunak yang
dikembangkan.
Prinsip dasar yang menuntun pengujian perangkat lunak, yaitu:
 Semua pengujian harus dapat ditelusuri sampai ke persyaratan
pelanggan.
 Pengujian harus direncanakan lama sebelum pengujian itu mulai,
 Prinsip Pareto berlaku untuk pengujian perangkat lunak.
 Pengujian harus mulai “dari yang kecil” dan berkembang ke pengujian
“yang besar”.
Digunakan 4 kategori yang berbeda dari tehnik disain test case: Pengujian
white-box, pengujian black-box, Integrasi Bottom-Up dan Integrasi Top-Down.
Sistem dari kualitas perangkat lunak terintegrasi dalam tiga disiplin aplikasi yaitu:
pemodelan proses pengembangan (process), pemodelan pengukuran produk
(product), dan pemodelan manajemen dan interaksi manusia (human).
Model dekomposisi yang diusulkan didasarkan pada model kualitas dari
ISO/IEC 9126 dalam konjungsi dengan standar TL 9000, dimana kontribusi dari
penggunaan QR adalah untuk menetapkan kebutuhan mutu eksternal (External
Quality Requirements), yang mana pada gilirannya berperan untuk menetapkan
kebutuhan mutu internal (Internal Quality requirements).

9.8 Soal-soal
1. Sebutkan pihak-pihak yang melaksanakan pengujian perangkat lunak.
2. Sebutkan empat langkah pengujian perangkat lunak.
3. Apa yang dimaksud dengan pengujian White Box?

Buku Ajar Rekayasa Perangkat Lunak – Bab IX

 163

Buku Ajar Rekayasa Perangkat Lunak – Bab IX