1.

Konsep Dasar kualitas perangkat lunak (software quality)

1.1 Perbedaan quality control dan quality assurance
a. Quality Control adalah kegiatan untuk menahan produk dari pengiriman jika
tidak memenuhi syarat dan ketentuan.
b. Quality Assurance adalah penjaminan kualitas produk, minim akan kesalahan.

1.2 Pengertian dasar dari software errors, software fault, software failure
a. Software errors adalah sebuah aksi yang membuat hasil yang salah.
b. Software fault adalah kesalahan dalam langkah, proses, atau data dalam
software.
c. Software failure, yaitu ketidakmampuan software untuk melakukan fungsi
sesungguhnya.

1.3 Konsep dasar dan tujuan software quality assurance

Sebuah pola terencana dan sistematis dari semua proses yang diperlukan untuk
memberi kepercayaan bahwa barang atau produk sesuai dengan persyaratan teknis
yang ditetapkan.
Tujuan software quality assurance
- Menjamin kepercayaan bahwa software akan sesuai dengan persyaratan teknis
fungsional
- Memastikan kepercayaan bahwa software akan sesuai dengan penjadwalan
manajerial dan anggaran.
- Inisiasi dan pengelolaan kegiatan untuk peningkatan dan efisiensi
pengembangan software dan kegiatan software quality assurance

1.4 Hal-hal yang menyebabkan terjadinya software defect

- Kesalahan dalam menentukan requirement
- Kegagalan komunikasi antara client dan developer
- Penyimpangan yang disengaja dari software requirement
- Kesalahan logical design
- Kesalahan pengkodean
- Ketidaksesuaian dengan petunjuk dokumen dan pengkodean
- Kekurangan pada proses pengujian
- Kesalahan antarmuka pengguna dan prosedur
- Kesalahan dokumentasi
1.5 Faktor Kualitas Perangkat Lunak McCall
Model faktor kualitas perangkat lunak McCall dibagi menjadi 11 faktor. Faktor-
faktor tersebut dikelompokkan menjadi tiga kategori
1. Product Operation Factors
Menangani persyaratan yang secara langsung mempengaruhi operas software
sehari-hari. Product Operation terdiri dari:
a. Correctness
Pada faktor ini ditetapkan output yang dibutuhkan oleh suatu software, yaitu
output mission, akurasi output, kelengkapan informasi output, informasi
yang terbarukan, tersedianya informasi, serta standar untuk pengkodean dan
dokumentasi.
b. Realibility
Tingkat maksimum kegagalan suatu software yang diizinkan, baik itu secara
kesulurahan atau satu fungsi atau lebih.
c. Efficiency
Berhubungan dengan sumber daya yang dibutuhkan untuk menjalankan
semua fungsi pada software. Seperti hardware yang dibutuhkan dalam
menjalankan software tersebut.
d. Integrity
Berhubungan dengan keamanan dari suatu sistem, seperti pencegahan akses
dari orang yang tidak berwenang. Juga membedakan hak istimewa untuk
tiap personil.
e. Usability
Berhubungan dengan cakupan sumber daya manusia berupa staff yang
dibutuhkan untuk melatih karyawan baru dalam menjalankan sistem.
2. Product Revision Factors
Berhubungan dengan aktivitas perawatan software:
- Pemeliharaan korektif
- Pemeliharaan adaptif
- Pemeliharaan sempurna
 Faktor ini terdiri dari:
a. Maintainability
Menentukan upaya yang dibutuhkan oleh pengguna dan personil
pemeliharaan untuk mengidentifikasi alasan kegagalan, memperbaiki,
memverifikasi keberhasilannya. Mengacu pada struktur modular (ukuran),
dokumentasi program (standar), manual, dan lainnya.
b. Flexibility
Mengacu pada kemampuan dan upaya yang diperlukan untuk mendukung
perawatan adaptif dan perawatan sempurna, termasuk sumber daya
manusia, luasan kegiatan, dan lainnya.
c. Testability
Berhubungan dengan pengujian sistem serta pengoperasiannya.
- Untuk kemudahan pengujian, seperti menyediakan hasil yang telah
ditentukan serta file log.
- Untuk operasi, seperti diagnostik otomatis yang dilakukan oleh sistem
sebelum memulai sistem, laporan otomatis untuk kesalahan yang
terdeteksi
- Untuk perawatan, pemeriksaan diagnostik otomatis diterapkan oleh
teknisi perawatan untuk mendeteksi penyebab kegagalan.
3. Product Transition Factors
Mengacu pada adopsi lingkungan dan interaksi dengan sistem lain. Terdiri
dari:
a. Portability
Mengacu pada adaptasi terhadapt lingkungan lain yang terdiri dari
hardware, sistem operasi, dan lainnya.
b. Reusability
Berhubungan dengan penggunaan modul software yang awalnya dirancang
untuk satu proyek lalu digunakan kembali pada proyek yang sedang
dikembangkan. Dapat menghemat sumber daya, memperpendek waktu, dan
memberikan modul berkualitas tinggi.
 c. Interoperability
Berfokus pada pembuatan antarmuka dengan sistem software lain atau
dengan firmware lainnya. Menentukan nama software atau firmware yang
diperlukan oleh antarmuka. Dapat juga menentukan struktur output yang
diterima.

1.6 Model Faktor Lain

Selain faktor model McCall juga terdapat faktor model Deutsch and Willis serta
Evans and Marciniak. Berikut perbedaannya.

Alternative factor models

No. Software quality McCall’s classic Evans and Deutsch and
factor model Marciniak model Willis model
1 Correctness + + +
2 Reliability + + +
3 Efficiency + + +
4 Integrity + + +
5 Usability + + +
6 Maintainability + + +
7 Flexibility + + +
8 Testability +
9 Portability + + +
10 Reusability + + +
11 Interoperability + + +
12 Verifiability + +
13 Expandability + +
14 Safety +
15 Manageability +
16 Survivability +

a. Verifiability
Mendefinisikan fitur desain dan pemograman. Mengacu pada modularitas dan
kesederhanaan, dan kepatuhan terhadap pedoman dokumentasi dan
pemograman. Meningkatkan tinjauan design dan pengujian perangkat lunak.
b. Expandability
Mengacu pada upaya masa depan yang akan dibutuhkan untuk melayani
populasi yang lebih besar.
 c. Safety
Untuk menghindari kondisi berbahaya bagi pengoperasian peralatan akibat
kesalahan, termasuk memberikan sinyal alarm.
d. Manageability
Mengacu pada alat administrasi yang mendukung modifikasi perangkat lunak.
e. Survivability
Mengacu pada kontuinitas pelayanan. Menentukan waktu minimum yang
diizikan antara kegagalan, waktu maksimum yang diizinkan untuk pemulih
layanan.

2. Penjaminan kualitas perangkat lunak (software quality assurance)

2.1 Pengertian dan Fungsi software quality assurance
Menurut NASA software quality assurance adalah fungsi kualitas perangkat lunak
yang menjamin bahwa standar, proses, dan prosedur sesuai untuk proyek dan
diterapkan dengan benar.
- Kesesuaian dengan persyaratan perangkat lunak adalah dasar dari mana
kualitas perangkat lunak diukur
- Standar yang ditentukan digunakan untuk menentukan kriteria pengembangan
yang digunakan untuk memandu cara perangkat lunak direkayasa.
- Perangkat lunak harus sesuai dengan persyaratan implisit (kemudahan
penggunaan, perawatan, keandalan, dll)

2.2 Kegiatan-kegiatan dalam melaksanakan software quality assurance

- Siapkan rencana SQA untuk proyek
- Berpartisipasi dalam pengembangan deskripsi proses perangkat lunak.
- Tinjau kembali kegiatan rekayasa perangkat lunak untuk memverifikasi
kepatuhan terhadap proses perangkat lunak yang telah ditetapkan.
- Mengaudit software yang dibuat untuk memverifikasi kepatuhan terhadap
bagian proses software
- Pastikan bahwa penyimpanan dalam software atau produk kerja
didokumentasikan dan ditangani sesuai prosedur.
- Catat bukti ketidakpatuhan dan laporkan kepada manajemen.
 2.3 Keuntungan dan Kerugian yang diberikan software quality assurance
a. Keuntungan
- Software minim cacat laten, sehingga mengurangi usaha dan waktu yang
dihabiskan selama pengujian dan pemeliharaan.
- Keandalan yang lebih tinggi akan menghasilkan kepuasaan yang lebih besar
terhadap pelanggan.
- Mengurangi biaya pemeliharaan.
- Secara keselurahan mengurangi biaya siklus hidup software
b. Kerugian
- Sulit dilembagakan dalam organisasi kecil, jika sumber daya tidak tersedia
- Ini mewakili perubahan budaya. Perubahan tidaklah mudah.
- Membutuhkan pengeluaran dolar yang tidak secara eksplisit akan
dianggarkan untuk rekayasa perangkat lunak atau QA.

3. Pengetesan Perangkat Lunak (Software Testing)

3.1 Konsep Dasar Software Testing dan Perbedaannya dengan Debugging
a. Software Testing
Melakukan identifikasi bug/error/defect pada software tanpa mengoreksinya.
Biasanya profesional dengan latar belakang quality assurance terlibat dalam
identifikasi bug. Testing dilakukan pada tahap Software Testing
b. Debugging
Melakukan identifikasi, pengisolasian, dan perbaikan masalah/bug.
Pengembang melakukan pengkodean terhadap software untuk melakukan
debug ketika menemukan kesalahan dalam kode. Debugging adalah bagian dari
White Box atau Unit Testing. Debugging dapat dilakukan dalam tahap tahap
pengembangan saat melakukan Unit Testing atau secara bertahap sambil
memperbaiki bug yang dilaporkan.

3.2 Siapa yang melakukan Software Testing

- Software Tester
- Software Developer
- Project Manager
- End User
3.3 Tujuan (Langsung dan Tidak Langsung) Software Testing
a. Secara Langsung
- Mengidentifikasi dan mengungkapkan kesalahan sebanyak mungkin pada
software yang diuji.
- Untuk membawa software yang diuji, setelah mengoreksi kesalahan yang
terdektesi dan uji coba kembali, ke tingkat kualitas yang dapat diterima.
- Untuk melakukan tes yang dibutuhkan secara efisien dan efektif, sesuai
keterbatasan anggaran dan penjadwalan.
b. Secara Tidak Langsung
- Mengkompilasi catatan kesalahan software untuk digunakan dalam
pencegahan kesalahan (dengan tindakan perbaikan dan pencegahan)

3.4 Penyebab masih dijumpai bug setelah dioperasikan pengguna

- Pengguna mengeksekusi kode yang belum diuji.
- Pengguna mengeksekusi pernyataan dalam urutan berbeda dari yang diuji.
- Pengguna memasukkan kombinasi input yang belum teruji.
- Lingkungan pengoperasian pengguna tidak diuji.

3.5 Akibat yang ditimbulkan dari kegagalan software

a. Terhadap pelanggan dan pengguna langsung
- Membahayakan keamanan kehidupan manusia.
- Mempengaruhi pencapaian fungsi esensial organisasi, tidak ada
kemampuan penggantian sistem yang tersedia.
- Mempengaruhi fungsi firmware, menyebabkan kerusakan pada
keseluruhan sistem.
- Mempengaruhi penggunaan paket software untuk aplikasi bisnis
- Mempengaruhi berfungsinya paket software untuk pelanggan pribadi.
- Mempengaruhi fungsi aplikasi firmware tapi tanpa mempengaruhi
keseluruhan sistem.
- Ketidaknyamanan pengguna namun tidak mencegah pemenuhan
kemampuan sistem.
b. Terhadap Pengembang
- Kerugian finansial, diantaranya kerusakan dibayar untuk luka fisik,
kerusakan dibayarkan kepada organisasi karena tidak berfungsinya
 software, biaya pembelian diganti kepada pelanggan, biaya pemeliharan
yang tinggi untuk perbaikan sistem yang gagal.
- Kerusakan non kuantitatif, seperti mempengaruhi penjualan di masa depan
dan menurunkan panjualan saat ini.

3.6 Beda Test Unit, Test Tntegrasi, dan Test Sistem

a. Unit Test
Menangani hal-hal kecil seperti modul, fungsi, objek, kelas.
b. Integration Test
Uji integrasi berhubugan dengan unit yang merupakan subsistem atau sumber
daya utama lainnya
c. System Test
Mengacu pada keseluruhan paket software atau sistem

3.7 Dimana dan siapa yang melaksanakan masing-masing test tersebut

a. Dimana
Biasanya di situs pengembang software. Untuk system test, uji di situs
pengembang atau pelanggan (situs target)
b. Siapa
- Unit Testing: Programmer dan/atau tim pengembang
- Integration Testing: Tim pengembang
- System Testing: Tim uji independen (tim internal atau eksternal(konsultan))

3.8 Dasar Putusan Mengakhiri Software Testing

1. Rute Implementasi selesai
- Uji sampai semuanya bebas dari kesalahan
- Semua pengujian, pengujian regresi.
- Mengabaikan batas anggaran dan jadwal.
- Berlaku untuk pendekatan kesempurnaan.
2. Model Aplikasi Matematika
- Pemodelan digunakan untuk memperkirakan presentase kesalahan yang
tidak terdeteksi berdasarkan tingkat deteksi kesalahan.
- Berhenti apabila tingkat deteksi turun di tingkat tertentu.
3. Rute Penyemaian Kesalahan
- Disini kita membuang kesalahan sebelum melakukan pengujian
 - Asumsi yang mendasarinya adalah persentase kesalahan benih yang
ditemukan akan sesuai dengan persentase kesalahan sebenarnya yang
terdeteksi.
- Berhenti setelah sisa persentase kesalahan benih yang tidak terdeteksi
mencapai tingkat yang telah ditentukan.
4. Tim Uji Coba Independen Ganda
- Dua tim menerapkan proses pengujian secara mandiri.
- Bandingkan daftar kesalahan yang terdeteksi.
- Hitung jumlah kesalahan yang tersisa tanpa terdeteksi
- Banyak statisik
- Biaya tinggi
5. Penghentian setelah sumber daya mereda
- Berhenti saat anggaran dan waktu untuk pengujian habis.
- Sangat umum di industri.

3.9 Pengaruh tingkat resiko terjadinya kesalahan software

a. Module/application issues
- Besarnya
- Kompleksitas dan kesulitan
- Persentase software asli (vs. persentase software yang digunakan kembali)
b. Programmer issues
- Kualifikasi professional
- Pengalaman dengan materi khusus modul
- Ketersediaan dukungan professional
- Kenalan dengan programmer dan kemampuan untuk mengevaluasi
kemampuannya.

3.10 Yang perlu direncanakan dan disusun sebelum melakukan software testing
a. Lingkup uji
- Paket perangkat lunak yang akan diuji.
- Dokumen yang memberikan dasar untuk test yang direncakan
b. Lingkungan pengujian
- Situs pengujian
- Konfigurasi hardware dan firmware yang dibutuhkan
- Organisasi yang berpartisipasi
 - Persyaratan tenaga kerja
- Persiapan dan pelatihan yang dibutuhkan tim uji
c. Rincian uji
- Situs pengujian
- Tujuan uji
- Rujuk silang ke dokumen yang relevan
- Kelas uji
- Uji tingkat
- Persyaratan uji kasus
- Persyaratan khusus
- Data yang akan direkam
d. Jadwal uji
- Persiapan
- Pengujian
- Koreksi kesalahan
- Tes regresi

4. Pemeliharaan perangkat lunak (software maintenance)

4.1 Pengertian, perlunya, dan tujuan maintenance software
Maintenance software adalah proses memodifikasi sistem software atau komponen
setelah pengiriman untuk memperbaikin kesalahan, memperbaiki kinerja atau
atribut lainnya, atau menyesuaikan diri dengan lingkungan yang berubah.
Perubahan mungkin merupakan perubahan sederhana untuk memperbaiki
kesalahan pengkodean, perubahan yang lebih luas untuk memperbaiki kesalahan
desain atau peningkatan yang signifikan untuk mempernbaiki kesalahan spesifikasi
atau mengakomodasi persyaratan baru.

4.2 Karakteristik Maintenance Software

1. Kendala sistem yang ada
Pemeliharan dilakukan pada sistem operasi. Karena itu, semua modifikasi
harus kompatibel dengan kendala arsitektur, desain, dan kode yang ada.
2. Jangka waktu yang lebih pendek
 Aktivitasi maintenance mungkin berlangsung dari beberapa jam sampai
beberapa bulan, sedangkan pengembangan software mungkin akan
berlangsung satu tahun lebih.
3. Data uji tersedia
Dalam pengembangan perangkat lunak, uji kasus dirancang dari nol,
sedangkan perawatan software dapat memilih subset dari kasus uji ini dan
menjalankannya sebagai tes regresi.

4.3 Beda pengembangan dengan pemeliharaan

4.4 Jenis-jenis layanan pemeliharaan perangkat lunak

1. Corrective Maintenance
Layanan dukungan pengguna dan koreksi software yang berfokus pada
perbaikan cacat
2. Adaptive Maintenance
Mengadaptasi paket software dengan perbedaan persyaratan pelanggan baru,
mengubah kondisi lingkungan dan sejenisnya.
3. Functionality imporvement maintenance yang terdiri dari
a. Perfective maintenance
Fungsi baru ditambahkan ke software sehingga bisa meningkatkan
performa. Meliputi semua upaya untuk meningkatkan kualitas software.
Termasuk rekonstruksi kode, membuat dan memperbarui dokumentasi,
memperbaiki keandalan atau efisiensi
b. Preventive maintenane
Meningkatkan kehandalan dan infrastruktur sistem agar rawatan masa
depan lebih mudah dan efisien. Mencegah kinerja sistem dari merendahkan
 ke tingkat yang tidak dapat diterima. Terjadi saat software diubah untuk
meningkatkan dukungan atau kendalan masa depan, atau untuk memberikan
dasar bagi penyempurnaan di masa depan.

4.5 Jenis maintenance software yang paling banyak dibutuhkan

Menurut Lient and Swanson pada tahun 1980 jenis maintenance software yang
paling banyak dibutuhkan yaitu Functionality improvement maintenance dengan
angka 54% dan pada tahun 1996 dilakukan penelitian oleh Oskarsson and Glass dan
hasilnya Functionality improvement maintenance masih tetap menjadi jenis
maintenance software yang paling banyak dibutuhkan.

4.6 Faktor-faktor kualitas yang terkait dengan maintenance software

- Correctness
- Reliability
- Maintainability
- Flexibility
- Testability
- Portability
- Interoperability

Faktor kualitas terkait dengan setiap jenis maintenance software karena adanya
maintenance contract review yaitu kegiatan yang meliputi ulasan draft proposal dan
draft kontrak. Rencana perawatan harus disiapkan untuk semua pelanggan,
eksternal dan internal.

4.7 Hal-hal yang menyebabkan pemeliharaan perangkat lunak tidak efisien

Faktor-faktor yang mempengaruhi maintenance
- Kurangnya model atau ketidaktahuan model yang tersedia
- Kurangnya dokumentasi
- Kurangnya waktu untuk memperbarui dokumentasi yang ada

Faktor lainnya (Studi tahun 1994)

- Kualitas aplikasi asli
- Kualitas dokumentasi
- Rotasi pemeliharaan orang

Faktor selebihnya (Studi Yip tahun 1995)

- Kekurangan sumber daya manusia
- Masalah perbedaan gaya pemograman
- Kekurangan dokumentasi dan alat-alat
- Managemen maintenance yang buruk
- Kebijakan dokumentasi
- Pergantian
 KUALITAS PERANGKAT LUNAK

RANGKUMAN
Disusun untuk Memenuhi Tugas Individu
pada Mata Kuliah Kualitas Perangkat Lunak
yang Diampu oleh Drs. Djalal Er Riyanto, M.IKom

Disusun Oleh :
Randy Ichsan Adlis 24010313120006

DEPARTEMEN ILMU KOMPUTER/INFORMATIKA

FAKULTAS SAINS DAN MATEMATIKA
UNIVERSITAS DIPONEGORO
SEMARANG
2017