Nama: Mugia Akbar

Nim: 1955201102

Kelas: B2 Malam

JAWABAN

Bab 3 Faktor kualitas perangkat lunak

Kami telah menetapkan (lihat Bab 2) bahwa dokumen persyaratan merupakan salah satu elemen
terpenting untuk mencapai kualitas perangkat lunak. Disini kita tanyakan: Apa yang dimaksud dengan
dokumen persyaratan perangkat lunak yang "baik"? Kami ingin menjelajah subjek dan aspek
penggunaan perangkat lunak apa yang harus dicakup dalam dokumen. Bab ini, oleh karena itu,
didedikasikan untuk tinjauan spektrum yang luas aspek penggunaan perangkat lunak yang mungkin
beroperasi sepanjang siklus hidup sistem perangkat lunak. Beberapa model SQA menunjukkan bahwa
spektrum yang luas dari persyaratan harus diklasifikasikan ke dalam 11 hingga 15 faktor (bidang
subjek) yang dapat digabung menjadi tiga atau empat kategori. Setelah menyelesaikan bab ini, Anda
akan dapat: Menjelaskan perlunya dokumen persyaratan yang komprehensif dan mencirikan isi
dokumen tersebut. Jelaskan struktur (kategori dan faktor) faktor klasik McCall model. Sebutkan
faktor-faktor, selain yang termasuk dalam model McCall, yaitu disarankan oleh model SQA alternatif.
Identifikasi siapa yang tertarik dengan definisi persyaratan kualitas

3.1 Kebutuhan akan kualitas perangkat lunak yang komprehensif

Persyaratan Sistem informasi penjualan baru kami tampaknya baik-baik saja, fakturnya benar, catatan
inventaris benar, diskon yang diberikan kepada klien kami ikuti persis kebijakan diskon kami yang
sangat rumit, tetapi penjualan baru kami sistem informasi sering gagal, biasanya setidaknya dua kali
sehari, setiap kali selama dua puluh menit atau lebih. Kemarin butuh satu setengah jam sebelum kita
bisa kembali bekerja. . . . Bayangkan betapa memalukannya untuk menyimpan manajer Softbest,
perusahaan perangkat lunak yang mengembangkan sistem penjualan terkomputerisasi kami, tidak
mengklaim bertanggung jawab “Baru setengah tahun yang lalu kami meluncurkan produk baru kami
– detektor radar. Firmware RD-8.1, yang tertanam dalam produk ini, tampaknya menjadi penyebab
keberhasilannya. Tapi, ketika kami mulai merencanakan pengembangan Eropa versi produk, kami
menemukan bahwa meskipun produk akan hampir mirip, departemen pengembangan perangkat lunak
kami perlu mengembangkan firmware baru; hampir semua desain dan pemrograman akan baru.”
“Percaya atau tidak, paket perangkat lunak kami 'Papan Tulis' untuk guru sekolah, baru diluncurkan
tiga bulan lalu, sudah terpasang di 187 sekolah. Itu tim pengembangan baru saja kembali dari
seminggu di Hawaii, liburan mereka bonus. Tapi kami tiba-tiba menerima keluhan setiap hari dari
Tim pemeliharaan 'Papan Tulis'. Mereka mengklaim bahwa kurangnya fitur deteksi kegagalan dalam
perangkat lunak, selain programmer yang buruk manual, telah menyebabkan mereka berinvestasi
lebih dari waktu yang diperkirakan untuk berurusan dengan bug atau menambahkan perubahan
perangkat lunak kecil yang disetujui sebagai bagian dari kontrak pembelian dengan klien.” “Versi
baru dari perangkat lunak kontrak pinjaman kami benar-benar akurat. Kita telah memproses 1200
permintaan pelanggan, dan memeriksa masing-masing kontrak keluaran. Tidak ada kesalahan. Tapi
kami memang menghadapi masalah tak terduga yang parah – melatih anggota staf baru untuk
menggunakan perangkat lunak ini membutuhkan sekitar dua minggu. Ini adalah masalah nyata di
departemen pelanggan yang mengalami pergantian karyawan yang tinggi. . . . Tim proyek
mengatakan itu sebagai mereka tidak diharuskan untuk menangani masalah pelatihan tepat waktu,
tambahan dua sampai tiga bulan kerja akan diperlukan untuk memecahkan masalah.”

3.2 Klasifikasi kebutuhan perangkat lunak ke dalam perangkat lunak

faktor kualitas Beberapa model faktor kualitas perangkat lunak dan kategorisasinya dalam faktor
kategori telah disarankan selama bertahun-tahun. Model klasik perangkat lunak faktor kualitas,
disarankan oleh McCall, terdiri dari 11 faktor (McCall et al., 1977). Model selanjutnya, yang terdiri
dari 12 hingga 15 faktor, disarankan oleh: Deutsch dan Willis (1988) dan oleh Evans dan Marciniak
(1987). Model alter native tidak berbeda secara substansial dari model McCall. McCall model faktor,
meskipun seperempat abad "pematangannya", terus berlanjut untuk menyediakan metode yang praktis
dan mutakhir untuk mengklasifikasikan kebutuhan perangkat lunak (Pressman, 2000).

3.3 Faktor kualitas perangkat lunak

operasi produk Menurut model McCall, lima faktor kualitas perangkat lunak termasuk dalam: kategori
operasi produk, yang kesemuanya berhubungan dengan persyaratan yang secara langsung
mempengaruhi pengoperasian perangkat lunak sehari-hari. Faktor-faktor tersebut adalah sebagai
berikut. Ketepatan Persyaratan kebenaran didefinisikan dalam daftar sistem perangkat lunak output
yang diperlukan, seperti tampilan kueri saldo pelanggan dalam penjualan sistem informasi akuntansi,
atau pasokan udara sebagai fungsi suhu ditentukan oleh firmware unit kontrol industri. Spesifikasi
keluaran biasanya multidimensi; beberapa dimensi umum termasuk: -Misi keluaran (misalnya,
cetakan faktur penjualan, dan alarm merah ketika suhu naik di atas 250 ° F) -Keakuratan yang
diperlukan dari keluaran-keluaran yang dapat dipengaruhi secara negatif oleh: data yang tidak akurat
atau perhitungan yang tidak akurat. -Kelengkapan informasi keluaran, yang dapat merugikan
dipengaruhi oleh data yang tidak lengkap. -Kekinian informasi (didefinisikan sebagai waktu antara
peristiwa dan pertimbangannya oleh sistem perangkat lunak). -Ketersediaan informasi (waktu reaksi,
didefinisikan sebagai waktu diperlukan untuk mendapatkan informasi yang diminta atau sebagai
reaksi yang diminta waktu firmware dipasang di peralatan terkomputerisasi). -Standar untuk
pengkodean dan pendokumentasian sistem perangkat lunak.
3.4 Faktor kualitas perangkat lunak

revisi produk menurut model McCall dari faktor kualitas perangkat lunak, tiga faktor kualitas terdiri
dari kategori revisi produk. Faktor-faktor ini berhubungan dengan persyaratan yang mempengaruhi
rangkaian lengkap kegiatan pemeliharaan perangkat lunak: pemeliharaan korektif (koreksi kesalahan
dan kegagalan perangkat lunak), pemeliharaan adaptif (menyesuaikan perangkat lunak saat ini dengan
keadaan dan pelanggan tambahan tanpa mengubah perangkat lunak) dan penyempurnaan
pemeliharaan (peningkatan dan peningkatan perangkat lunak yang ada dengan sehubungan dengan
masalah yang terbatas secara lokal). Ini adalah sebagai berikut Pemeliharaan Persyaratan rawatan
menentukan upaya yang akan dibutuhkan oleh pengguna dan personel pemeliharaan untuk
mengidentifikasi alasan kegagalan perangkat lunak, memperbaiki kegagalan, dan memverifikasi
keberhasilan koreksi. Ini persyaratan faktor mengacu pada struktur modular perangkat lunak, internal
dokumentasi program, dan manual programmer, di antara item lainnya Fleksibilitas Kemampuan dan
upaya yang diperlukan untuk mendukung aktivitas pemeliharaan adaptif tercakup dalam persyaratan
fleksibilitas. Ini termasuk sumber daya (yaitu dalam hari kerja) diperlukan untuk mengadaptasi paket
perangkat lunak ke berbagai pelanggan dari perdagangan yang sama, dari berbagai tingkat kegiatan,
dari rentang yang berbeda produk dan sebagainya Kemampuan untuk diuji Persyaratan testabilitas
berhubungan dengan pengujian sistem informasi sebagai: maupun dengan pengoperasiannya.
Persyaratan testabilitas untuk kemudahan pengujian adalah terkait dengan fitur khusus dalam program
yang membantu penguji, misalnya dengan memberikan hasil antara dan file log yang telah ditentukan
sebelumnya

3.5 Faktor kualitas perangkat lunak

transisi produk Menurut McCall, tiga faktor kualitas termasuk dalam kategori transisi produk,
kategori yang berkaitan dengan adaptasi perangkat lunak untuk lingkungan lain dan interaksinya
dengan sistem perangkat lunak lain. Portabilitas Persyaratan portabilitas cenderung pada adaptasi
sistem perangkat lunak ke sistem lainnya lingkungan yang terdiri dari perangkat keras yang berbeda,
sistem operasi yang berbeda, Dan seterusnya. Persyaratan ini memungkinkan untuk terus
menggunakan yang sama perangkat lunak dasar dalam situasi yang beragam atau untuk
menggunakannya secara bersamaan dalam beragam perangkat keras dan situasi sistem operasi. Dapat
digunakan kembali Persyaratan penggunaan kembali berhubungan dengan penggunaan modul
perangkat lunak awalnya dirancang untuk satu proyek dalam proyek perangkat lunak baru yang
sedang dikembangkan. Mereka juga dapat memungkinkan proyek masa depan untuk menggunakan
modul atau grup tertentu modul perangkat lunak yang dikembangkan saat ini. Penggunaan kembali
perangkat lunak adalah diharapkan dapat menghemat sumber daya pengembangan, mempersingkat
periode pengembangan, dan menyediakan modul berkualitas lebih tinggi. Manfaat kualitas yang lebih
tinggi ini didasarkan pada asumsi bahwa sebagian besar kesalahan perangkat lunak telah terdeteksi
oleh aktivitas jaminan kualitas yang dilakukan pada perangkat lunak asli, oleh pengguna perangkat
lunak asli, dan selama penggunaan kembali sebelumnya. Masalah penggunaan kembali perangkat
lunak menjadi subjek standar industri perangkat lunak (lihat IEEE, 1999) Interoperabilitas Persyaratan
interoperabilitas berfokus pada pembuatan antarmuka dengan sistem perangkat lunak lain atau dengan
firmware peralatan lain (misalnya, firmware dari antarmuka mesin produksi dan peralatan pengujian
dengan perangkat lunak kontrol produksi). Persyaratan interoperabilitas dapat menentukan: nama
perangkat lunak atau firmware yang memerlukan antarmuka. Mereka bisa juga menentukan struktur
keluaran yang diterima sebagai standar dalam industri tertentu atau area aplikasi.

3.6 Model alternatif dari faktor kualitas perangkat lunak

Dua model faktor, muncul selama akhir 1980-an, dianggap sebagai alternatif untuk model faktor
klasik McCall (McCall et al., 1977), layak diskusi: Model faktor Evans dan Marciniak (Evans dan
Marciniak, 1987). Model faktor Deutsch dan Willis (Deutsch dan Willis, 1988)

3.6.1 Perbandingan formal dari model alternatif Faktor-faktor yang termasuk dalam berbagai model

faktor dibandingkan pada Tabel 3.1. Faktor tambahan didefinisikan sebagai berikut. Verifiabilitas
(disarankan oleh Evans dan Marciniak) Persyaratan verifikasi menentukan fitur desain dan
pemrograman yang memungkinkan verifikasi desain dan pemrograman yang efisien. Sebagian besar
persyaratan verifikasi mengacu pada modularitas, kesederhanaan, dan kepatuhan terhadap
dokumentasi dan panduan pemrograman. Keamanan (disarankan oleh Deutsch dan Willis)
Persyaratan keselamatan dimaksudkan untuk menghilangkan kondisi berbahaya bagi operator
peralatan sebagai akibat dari kesalahan dalam perangkat lunak kontrol proses. Ini kesalahan dapat
mengakibatkan reaksi yang tidak tepat terhadap situasi berbahaya atau terhadap kegagalan untuk
memberikan sinyal alarm ketika kondisi berbahaya yang akan dideteksi oleh perangkat lunak muncul
Pengelolaan (disarankan oleh Deutsch dan Willis) Persyaratan pengelolaan mengacu pada alat
administratif yang mendukung modifikasi perangkat lunak selama pengembangan dan pemeliharaan
perangkat lunak periode, seperti manajemen konfigurasi, prosedur perubahan perangkat lunak, dan
sejenisnya. Kelangsungan hidup (disarankan oleh Deutsch dan Willis) Persyaratan kelangsungan
hidup mengacu pada kontinuitas layanan. Ini mendefinisikan waktu minimum yang diizinkan antara
kegagalan sistem, dan maksimum waktu yang diizinkan untuk pemulihan layanan, dua faktor yang
berkaitan dengan layanan kontinuitas. Meskipun persyaratan ini dapat merujuk secara terpisah ke total
dan kegagalan sebagian layanan, mereka terutama diarahkan untuk kegagalan esensial fungsi atau
layanan. Ada kesamaan yang signifikan antara kemampuan bertahan hidup faktor dan faktor
keandalan yang dijelaskan dalam model McCall.

3.6.2 Perbandingan model faktor – analisis isi Setelah membandingkan isi dari model faktor,
kami menemukan bahwa dua dari lima faktor tambahan, Expandability dan Survivability, sebenarnya
mirip faktor sudah termasuk dalam model faktor McCall, meskipun di bawah berbeda nama,
Fleksibilitas dan Keandalan. Selain itu, faktor Testabilitas McCall dapat dianggap sebagai salah satu
elemen dalam faktor Maintainability-nya sendiri. Ini menyiratkan bahwa perbedaan antara tiga model
faktor adalah jauh lebih kecil dari yang awalnya dirasakan. Artinya, model faktor alternatif tambahkan
hanya tiga faktor "baru" ke model McCall: Kedua model menambahkan faktor Verifiability. Model
Deutsch dan Willis menambahkan faktor Keamanan dan Pengelolaan

3.6.3 Struktur model faktor alternatif Namun demikian, terlepas dari kesamaannya, kategori yang
digunakan oleh model faktor asli pengganti dan klasifikasi faktor spesifik ke dalam ini kategori
berbeda dari yang ditawarkan oleh model McCall. Tabel 3.2 membandingkan struktur ketiga model
menurut faktor dan klasifikasinya ke dalam kategori

3.7 Siapa yang tertarik dengan definisi persyaratan kualitas?

Secara alami, orang mungkin berpikir bahwa hanya klien yang tertarik secara menyeluruh
mendefinisikan persyaratannya untuk memastikan kualitas produk perangkat lunak yang
dikontraknya. Dokumen persyaratan yang dia siapkan memang berfungsi sebagai perlindungan
mendasar terhadap kualitas rendah. Namun, analisis kami tentang berbagai faktor kualitas
menunjukkan bagaimana pengembang perangkat lunak dapat menambahkan persyaratan yang
mewakili kepentingannya sendiri. Berikut ini adalah beberapa contohnya: (1) Persyaratan dapat
digunakan kembali. Dalam kasus di mana klien mengantisipasi pengembangan dalam waktu dekat
dari sistem perangkat lunak tambahan yang memiliki kekuatan kesamaan dengan perangkat lunak ini,
klien sendiri akan memulai persyaratan penggunaan kembali. Dalam kasus lain, klien tertarik untuk
menggunakan kembali bagian dari sistem perangkat lunak yang dikembangkan sebelumnya dalam
sistem baru. Namun, kemungkinan besar pengembang, yang melayani berbagai macam klien, akan
mengenali manfaat potensial dari penggunaan kembali, dan akan memasuki penggunaan kembali ke
dalam daftar persyaratan yang harus dipenuhi oleh tim proyek. (2) Persyaratan verifikasi. Persyaratan
ini dimaksudkan untuk meningkatkan tinjauan desain dan pengujian perangkat lunak yang dilakukan
selama pengembangan perangkat lunak. Tujuan mereka adalah untuk menghemat sumber daya
pembangunan dan mereka, oleh karena itu, menarik bagi pengembang. Namun, klien biasanya tidak
tertarik untuk menempatkan persyaratan yang berhubungan dengan aktivitas internal perusahaan tim
pengembang.

3.8 Kepatuhan perangkat lunak dengan faktor kualitas

Sepanjang proses pengembangan perangkat lunak, sejauh mana proses sesuai dengan persyaratan
berbagai faktor kualitas adalah diperiksa oleh tinjauan desain, inspeksi perangkat lunak, pengujian
perangkat lunak, dan sebagainya maju. Diskusi komprehensif tentang tinjauan desain, pengujian
perangkat lunak, metrik kualitas perangkat lunak, dan alat lain untuk memverifikasi dan memvalidasi
kualitas perangkat lunak disediakan dalam neraca buku ini. Selanjutnya, kepatuhan produk perangkat
lunak terhadap persyaratan milik berbagai faktor kualitas diukur dengan metrik kualitas perangkat
lunak, ukuran yang mengukur tingkat kepatuhan. Untuk memungkinkan pengukuran kepatuhan yang
valid, sub-faktor telah ditentukan untuk itu: faktor kualitas yang mewakili berbagai atribut dan aspek
penggunaan perangkat lunak. Metrik kualitas perangkat lunak disarankan untuk masing-masing ini
sub-faktor. Bab 21 didedikasikan untuk subjek metrik perangkat lunak. Tabel 3.3 menyajikan
beberapa sub-faktor ini, yang sebagian besar adalah disarankan oleh Evans dan Marciniak (1987).

Ringkasan
(1) Perlunya kelengkapan dokumen persyaratan dan isinya. Banyak kasus kepuasan pelanggan yang
rendah adalah situasi di mana proyek perangkat lunak telah memenuhi persyaratan dasar kebenaran
dengan memuaskan, sementara menderita dari kinerja yang buruk di bidang penting lainnya seperti
pemeliharaan, keandalan, penggunaan kembali perangkat lunak, atau pelatihan. Salah satu penyebab
utama penyimpangan ini adalah kurangnya mendefinisikan persyaratan yang berkaitan dengan aspek-
aspek fungsionalitas perangkat lunak. Oleh karena itu, diperlukan definisi kebutuhan yang
komprehensif yang akan mencakup semua aspek penggunaan perangkat lunak di seluruh tahapan
siklus hidup perangkat lunak. Model faktor mendefinisikan spektrum yang luas dari kebutuhan
perangkat lunak. Kami mengharapkan bahwa individu-individu yang mendefinisikan persyaratan
perangkat lunak akan mengacu pada setiap faktor dan, karenanya, memeriksa kebutuhan untuk
memasukkan persyaratan masing-masing dalam dokumen persyaratan mereka.

(2) Struktur (kategori dan faktor) model faktor klasik McCall. Model faktor McCall
mengklasifikasikan semua persyaratan perangkat lunak ke dalam 11 kualitas perangkat lunak faktor.
Kesebelas faktor tersebut dikelompokkan menjadi tiga kategori – operasi produk, revisi produk dan
transisi produk – sebagai berikut: Faktor operasi produk: Kebenaran, Keandalan, Efisiensi, Integritas,
Kegunaan. Faktor revisi produk: Pemeliharaan, Fleksibilitas, Kemampuan untuk diuji. Faktor transisi
produk: Portabilitas, Reusabilitas, Interoperabilitas.

(3) Faktor tambahan yang disarankan oleh model faktor alternatif. Dua model faktor dari akhir 1980-
an, alternatif dari faktor klasik McCall modelnya, adalah: Model faktor Evans dan Marciniak. Model
faktor Deutsch dan Willis. Model alternatif ini menyarankan untuk menambahkan lima faktor ke
model McCall. Dua dari faktor-faktor ini sangat mirip dengan dua faktor McCall; hanya tiga faktor
yang "baru": Kedua model menambahkan faktor Verifiability. Model Deutsch dan Willis
menambahkan faktor Keamanan dan Pengelolaan

(4) Mereka yang tertarik dalam mendefinisikan persyaratan kualitas perangkat lunak. Klien bukan
satu-satunya pihak yang tertarik untuk mendefinisikan persyaratan secara menyeluruh yang menjamin
kualitas produk perangkat lunak. Pengembang sering tertarik pada menambahkan persyaratan yang
mewakili kepentingannya sendiri, seperti persyaratan reusability, verifia bility dan portability.
Namun, ini mungkin tidak menarik bagi klien. Dengan demikian, seseorang dapat mengharapkan
bahwa suatu proyek akan dilaksanakan menurut dua dokumen persyaratan: Dokumen persyaratan
klien Dokumen persyaratan tambahan pengembang.

Bibliografi yang dipilih

1. Deutsch, M. S. dan Willis, R. R. (1988) Rekayasa Kualitas Perangkat Lunak, Total Pendekatan
Manajemen Teknis, Ch. 3, Prentice Hall, Tebing Englewood, NJ.

2. Donahue G. M. (2001) “Usability and the bottom line”, IEEE Software, 18 (1), 31–37.

3. Evans, M. W. dan Marciniak, J. J. (1987) Jaminan Kualitas Perangkat Lunak dan Manajemen, Bab
7 dan 8, John Wiley & Sons, New York.

4. Ferre, X., Juristo, N., Windl, H. dan Constantine, L. (2001) "Memperkenalkan kegunaan",
Perangkat Lunak IEEE, 18 (1), 20–21.

5. IEEE (1999) “IEEE Std 1517-1999 – Standar IEEE untuk Teknologi Informasi – Proses Siklus
Hidup Perangkat Lunak – Proses Penggunaan Kembali”, dalam Perangkat Lunak IEEE Koleksi
Standar Teknik, Institut Listrik dan Elektronika Insinyur, New York.

6. Juristo, N., Windl, H. dan Constantine, L. (2001) “Dasar-dasar kegunaan untuk perangkat lunak
pengembang”, Perangkat Lunak IEEE, 18 (1), 22–29.

7. McCall, J., Richards, P. dan Walters, G. (1977) Faktor dalam Kualitas Perangkat Lunak, Vols 1-3,
NTIS AD-A049-014, 015, 055, November 1977.

8. Pressman, R. S. (2000) Rekayasa Perangkat Lunak – Pendekatan Praktisi, Adaptasi Eropa oleh D.
Ince, 5th edn, Ch. 19, McGraw-Hill Internasional, London.

9. Vincent, J., Waters, A. dan Sinclair, J. (1988) Jaminan Kualitas Perangkat Lunak, Vol. 2, Panduan
Program, Lampiran B, Prentice Hall, Englewood Cliffs, NJ.

Tinjau pertanyaan
3.1 (1) Apa saja tiga kategori faktor yang termasuk dalam model faktor McCall?

(2) Faktor apa saja yang termasuk dalam masing-masing kategori?

3.2 Dokumen persyaratan perangkat lunak untuk tender pembangunan “Super-lab”, sistem perangkat
lunak untuk mengelola laboratorium rumah sakit, terdiri dari bab-bab sesuai dengan faktor kualitas
yang diperlukan sebagai berikut: kebenaran, keandalan, efisiensi, integritas, kegunaan, rawatan,
fleksibilitas, testability, portabilitas, reusability dan kemampuan interoper. Dalam tabel berikut Anda
akan menemukan bagian yang diambil dari yang disebutkan dokumen persyaratan. Untuk setiap
bagian, isikan nama faktor yang paling sesuai persyaratan (pilih hanya satu faktor per bagian
persyaratan).

Topik untuk diskusi

3.1 Empat keluhan “tetapi” disebutkan di Bagian

3.1. Semuanya mencerminkan item yang hilang dari dokumen persyaratan.

(1) Termasuk dalam faktor apa persyaratan yang hilang itu?

(2) Dapatkah Anda menyarankan persyaratan kualitas perangkat lunak yang dapat mengisi
kesenjangan?

3.2 Beberapa profesional mengklaim bahwa peningkatan kegunaan perangkat lunak harus melibatkan:
penurunan efisiensi. Yang lain mengklaim tidak ada ketergantungan antara efisiensi perangkat lunak
dan kegunaan.

(1) Apakah Anda setuju dengan kelompok pertama atau kedua?

(2) Diskusikan jawaban Anda. 3.3 Kota Mountain View telah memutuskan untuk mengembangkan
paket perangkat lunak yang akan melayani klub pemuda yang dioperasikan oleh kota. Tugas utama
perangkat lunak adalah: Tindak lanjut pembayaran bulanan anggota. Menyiapkan daftar peserta dalam
berbagai kursus yang ditawarkan oleh klub. Pembuatan reminder notice kepada peserta kursus yang
tidak hadir secara reguler. Laporan statistik tentang keanggotaan dan partisipasi dalam aktivitas klub.
Kota ini sudah mengimplementasikan paket perangkat lunak berikut: Penagihan pajak Perpustakaan
Umum Tindak lanjut sekolah dan kontrol pencapaian Tagihan konsumsi air. Dewan Kota telah
meminta Unit Teknologi Informasi untuk melaporkan kepada dewan tentang kemungkinan
penggunaan kembali paket perangkat lunak kota yang sudah tersedia ke kota dalam paket perangkat
lunak klub pemuda.

(1) Bisakah Anda menyarankan modul mana dari paket perangkat lunak kota yang ada? digunakan
kembali dalam perangkat lunak baru? Buat daftar asumsi Anda tentang isi dari paket perangkat lunak
yang ada dan perangkat lunak baru yang diperlukan.

(2) Bisakah Anda menilai modul yang digunakan kembali yang disarankan dalam

(1) sesuai dengan ruang lingkupnya? upaya adaptasi yang diperlukan untuk menerapkan modul yang
digunakan kembali di klub pemuda paket perangkat lunak?
3.4 Dikatakan bahwa kegagalan untuk memenuhi persyaratan interoperabilitas dapat berdampak
negatif tingkat kebenaran sistem perangkat lunak, dan bahkan dapat menyebabkan ketidaksesuaian
dengan persyaratan kebenaran.

(1) Uraikan pernyataan di atas dan jelaskan keterkaitan antar faktor tersebut.

(2) Berikan contoh situasi di mana efek seperti itu diharapkan.

3.5 Diklaim bahwa sehubungan dengan mata pelajaran di mana kualitatif dan kuantitatif persyaratan
dapat didefinisikan, alternatif kuantitatif harus lebih disukai.

(1) Berikan tiga contoh masing-masing alternatif kualitatif dan kuantitatif persyaratan.

(2) Jelaskan mengapa pelanggan harus memilih opsi kuantitatif.

(3) Jelaskan mengapa pengembang perangkat lunak harus memilih opsi kuantitatif.

Bab 4 Komponen sistem jaminan kualitas perangkat lunak – gambaran

umum

4.1 Sistem SQA – arsitektur SQA Sistem SQA

selalu menggabungkan berbagai komponen SQA, semuanya yang digunakan untuk menantang banyak
sumber kesalahan perangkat lunak dan untuk mencapai tingkat kualitas perangkat lunak yang dapat
diterima. Seperti yang dinyatakan dalam Bab 1, tugas SQA unik di bidang jaminan kualitas karena
karakteristik khusus perangkat lunak. Selain itu, lingkungan di mana pengembangan dan
pemeliharaan perangkat lunak yang dilakukan secara langsung mempengaruhi Komponen SQA (lihat
Bab 1). Komponen sistem SQA dapat diklasifikasikan menjadi enam kelas: Komponen pra-proyek.
Untuk memastikan bahwa (a) komitmen proyek telah: didefinisikan secara memadai dengan
mempertimbangkan sumber daya yang dibutuhkan, jadwal, dan anggaran; dan (b) rencana
pengembangan dan kualitas telah ditentukan dengan benar. Komponen penilaian kegiatan siklus hidup
proyek. Kehidupan proyek siklus terdiri dari dua tahap: tahap siklus hidup pengembangan dan tahap
operasi-pemeliharaan.

4.2 Komponen pra-proyek Komponen

SQA yang termasuk di sini dimaksudkan untuk meningkatkan persiapan langkah-langkah yang
diambil sebelum memulai pekerjaan pada proyek itu sendiri: Tinjauan kontrak Rencana
pengembangan dan kualitas.

4.2.1 Peninjauan kontrak Perangkat lunak dapat dikembangkan dalam kerangka kontrak yang
dinegosiasikan dengan pelanggan atau sebagai tanggapan atas pesanan internal yang berasal dari yang
lain departemen. Perintah internal mungkin memerlukan permintaan untuk mengembangkan a sistem
perangkat lunak firmware untuk disematkan di dalam produk perangkat keras, dan memesan produk
perangkat lunak untuk dijual sebagai paket, atau pesanan untuk pengembangan perangkat lunak
administrasi untuk diterapkan dalam perusahaan. Dalam semua kasus ini, unit pengembangan
berkomitmen pada kesepakatan yang disepakati spesifikasi fungsional, anggaran dan jadwal. Oleh
karena itu, kegiatan tinjauan kontrak harus mencakup pemeriksaan rinci tentang

(a) rancangan proposal proyek dan

(b) rancangan kontrak. Secara khusus, kegiatan review kontrak meliputi: Klarifikasi kebutuhan
pelanggan Tinjauan jadwal proyek dan perkiraan kebutuhan sumber daya Evaluasi kapasitas staf
profesional untuk melaksanakan usulan proyek Evaluasi kapasitas pelanggan untuk memenuhi
kewajibannya Evaluasi risiko pembangunan. Pendekatan serupa diterapkan dalam tinjauan kontrak
pemeliharaan. Seperti tinjauan memperhitungkan bahwa selain koreksi kesalahan, layanan
pemeliharaan mencakup adaptasi perangkat lunak dan aktivitas pengembangan perangkat lunak
terbatas demi peningkatan kinerja (disebut "pemeliharaan peningkatan fungsionalitas").

4.2.2 Rencana pengembangan dan kualitas Setelah kontrak pengembangan perangkat lunak telah
ditandatangani atau komitmen dibuat untuk melakukan proyek internal untuk kepentingan departemen
lain organisasi, sebuah rencana disiapkan dari proyek ("rencana pengembangan") dan kegiatan
penjaminan mutu terpadu (“rencana mutu”). Rencana ini termasuk rincian tambahan dan revisi yang
diperlukan berdasarkan rencana sebelumnya yang memberikan dasar untuk proposal dan kontrak saat
ini. Hal ini cukup umum untuk beberapa bulan berlalu antara pengajuan tender dan penandatanganan
kontrak. Selama periode ini, perubahan dapat terjadi dalam ketersediaan staf, kemampuan profesional,
dan sebagainya. Rencana tersebut kemudian direvisi untuk mencerminkan perubahan yang terjadi
selama ini. Jadwal Sumber daya tenaga dan perangkat keras yang dibutuhkan Evaluasi risiko Masalah
organisasi: anggota tim, subkontraktor, dan kemitraan Metodologi proyek, alat pengembangan, dll.
Rencana penggunaan kembali perangkat lunak. Masalah utama yang dibahas dalam rencana kualitas
proyek adalah: Sasaran kualitas, dinyatakan dalam istilah terukur yang tepat Kriteria untuk memulai
dan mengakhiri setiap tahap proyek Daftar ulasan, tes, dan verifikasi dan validasi terjadwal lainnya
Kegiatan

4.3 Komponen siklus hidup proyek perangkat lunak

Siklus hidup proyek terdiri dari dua tahap: siklus hidup pengembangan tahap dan tahap operasi-
pemeliharaan. Beberapa komponen SQA memasuki kehidupan proyek pengembangan perangkat
lunak siklus pada titik yang berbeda. Penggunaannya harus direncanakan sebelum proyek inisiasi.
Komponen utamanya adalah: Ulasan Pendapat ahli Pengujian perangkat lunak Pemeliharaan
perangkat lunak Jaminan kualitas pekerjaan subkontraktor dan suku cadang yang dipasok pelanggan.
4.3.1 Ulasan Tahap desain dari proses pengembangan menghasilkan berbagai dokumen Produk yang
dicetak meliputi laporan desain, dokumen uji perangkat lunak, rencana instalasi perangkat lunak dan
manual perangkat lunak, antara lain. Ulasan dapat dikategorikan sebagai formal design review (DRs)
dan peer review. Ulasan desain formal (DR) Sebagian besar dari dokumen-dokumen ini
membutuhkan profesional formal persetujuan kualitasnya sebagaimana diatur dalam kontrak
pengembangan dan dituntut oleh prosedur yang diterapkan oleh pengembang perangkat lunak. Harus
menekankan bahwa pengembang dapat melanjutkan ke tahap berikutnya dari proses pengembangan
hanya dengan menerima persetujuan resmi dari dokumen-dokumen ini

4.3.2 Pendapat ahli Pendapat ahli mendukung upaya penilaian kualitas dengan memperkenalkan
tambahan kemampuan eksternal ke dalam proses pengembangan internal organisasi. Beralih ke ahli
luar mungkin sangat berguna dalam situasi berikut: Kemampuan profesional internal yang tidak
memadai di area tertentu. Dalam organisasi kecil dalam banyak kasus sulit untuk menemukan cukup
cocok kandidat untuk berpartisipasi dalam tim peninjau desain. Dalam situasi seperti itu, ahli luar
dapat bergabung dengan komite DR atau, sebagai alternatif, ahli mereka pendapat dapat
menggantikan DR. Dalam organisasi kecil atau dalam situasi yang dicirikan oleh pekerjaan yang
ekstrem tekanan, pendapat ahli luar dapat menggantikan inspeksi. Tidak dapat diaksesnya profesional
internal untuk sementara (menunggu akan menyebabkan penundaan substansial dalam jadwal
penyelesaian proyek). Dalam kasus ketidaksepakatan besar di antara para profesional senior
organisasi, seorang ahli dari luar dapat mendukung keputusan

4.3.3 Pengujian perangkat lunak Tes perangkat lunak adalah komponen SQA formal yang ditargetkan
untuk ditinjau dari pengoperasian perangkat lunak yang sebenarnya. Tes didasarkan pada daftar yang
disiapkan kasus uji yang mewakili berbagai skenario yang diharapkan. Tes perangkat lunak
memeriksa modul perangkat lunak, integrasi perangkat lunak, atau seluruh paket perangkat lunak
(sistem). Tes berulang (biasanya disebut "tes regresi"), dilakukan setelah koreksi temuan tes
sebelumnya, dilanjutkan sampai memuaskan hasil diperoleh. Tujuan langsung dari pengujian
perangkat lunak, selain: deteksi kesalahan perangkat lunak dan kegagalan lain untuk memenuhi
persyaratan, adalah persetujuan formal dari modul atau pengaturan integrasi sehingga fase
pemrograman berikutnya dapat dimulai atau sistem perangkat lunak yang lengkap dapat dikirim dan
dipasang. Program pengujian perangkat lunak dibangun dari berbagai pengujian, beberapa manual dan
ada yang otomatis. Semua tes harus dirancang, direncanakan dan disetujui sesuai dengan prosedur
pengembangan. Laporan pengujian akan mencakup daftar rinci kesalahan yang terdeteksi dan
rekomendasi tentang kinerja pengujian berulang sebagian atau lengkap setelah putaran berikutnya
koreksi berdasarkan temuan tes. (Kelebihan dan kekurangan dari pengujian otomatis dibahas nanti.)
Direkomendasikan bahwa pengujian perangkat lunak dilakukan oleh unit pengujian luar yang
independen dan bukan oleh tim proyek, karena tim proyek secara alami akan kesulitan mendeteksi
kesalahan yang mereka lakukan. gagal untuk mendeteksi selama pengembangan serta untuk
menghindari konflik kepentingan.

4.3.4 Komponen pemeliharaan perangkat lunak Layanan pemeliharaan perangkat lunak bervariasi
dalam jangkauan dan disediakan untuk ekstensif periode, seringkali beberapa tahun. Layanan ini
termasuk dalam kategori berikut: Pemeliharaan korektif – Layanan dukungan pengguna dan koreksi
kode perangkat lunak dan kegagalan dokumentasi. Pemeliharaan adaptif – Adaptasi perangkat lunak
saat ini dengan keadaan dan pelanggan baru tanpa mengubah produk perangkat lunak dasar. Adaptasi
ini biasanya diperlukan ketika sistem perangkat keras atau komponen mengalami modifikasi
(penambahan atau perubahan). Pemeliharaan peningkatan fungsionalitas – Peningkatan fungsional
dan kinerja terkait perangkat lunak yang ada, dilakukan dengan hormat untuk masalah terbatas.

4.3.5 Jaminan kualitas peserta eksternal kerja Subkontraktor dan pelanggan sering kali bergabung
dengan pengembang yang dikontrak langsung (“pemasok”) dalam melaksanakan proyek
pengembangan perangkat lunak. Itu semakin besar dan kompleks proyek, semakin besar kemungkinan
eksternal peserta akan diperlukan, dan semakin besar proporsi pekerjaan yang dikirimkan kepada
mereka (subkontraktor, pemasok perangkat lunak COTS dan pelanggan). Motivasi untuk beralih ke
peserta eksternal terletak pada: sejumlah faktor, mulai dari kepentingan ekonomi hingga teknis hingga
personel, dan mencerminkan tren yang berkembang dalam alokasi pekerjaan terlibat dalam
menyelesaikan proyek yang kompleks. Kontribusi eksternal peserta dapat bervariasi. Dengan
demikian, tugas tersebut mungkin berkaitan dengan membawa keluar tugas bertahap seperti
pemrograman atau pengujian, atau seluruh rentang tugas dibutuhkan oleh tahap pengembangan
proyek.

4.4 Komponen infrastruktur untuk pencegahan kesalahan dan peningkatan Sasaran

infrastruktur

SQA adalah pencegahan kesalahan perangkat lunak atau, setidaknya, penurunan tingkat kesalahan
perangkat lunak, bersama dengan peningkatan produktifitas. Komponen infrastruktur SQA
dikembangkan secara khusus untuk akhir ini. Komponen-komponen ini dirancang untuk melayani
berbagai proyek dan layanan pemeliharaan perangkat lunak. Selama beberapa tahun terakhir, kita
telah menyaksikan meningkatnya penggunaan alat otomatis terkomputerisasi untuk aplikasi ini
komponen. Kelas komponen SQA ini meliputi: Prosedur dan instruksi kerja Template dan daftar
periksa Pelatihan staf, pelatihan ulang, dan sertifikasi Tindakan pencegahan dan perbaikan
Manajemen konfigurasi Kontrol dokumentasi.

4.4.1 Prosedur dan instruksi kerja Prosedur jaminan kualitas biasanya memberikan definisi rinci untuk
kinerja jenis kegiatan pembangunan tertentu dengan cara yang menjamin pencapaian hasil yang
berkualitas secara efektif. Prosedur direncanakan untuk dapat diterapkan secara umum dan untuk
melayani seluruh organisasi. Instruksi kerja, dalam kontras, memberikan petunjuk rinci untuk
penggunaan metode yang diterapkan dalam kasus yang unik dan dipekerjakan oleh tim khusus.
Prosedur dan instruksi kerja didasarkan pada akumulasi pengalaman dan pengetahuan organisasi;
dengan demikian, mereka berkontribusi pada yang benar dan kinerja efektif dari teknologi dan
rutinitas yang mapan. Karena mereka mencerminkan pengalaman masa lalu organisasi, perawatan
konstan harus diambil untuk memperbarui dan menyesuaikan prosedur dan instruksi tersebut dengan
kondisi teknologi, organisasi, dan lainnya saat ini

4.4.2 Mendukung perangkat berkualitas Salah satu cara untuk menggabungkan kualitas yang lebih
tinggi dengan efisiensi yang lebih tinggi adalah dengan menggunakan perangkat pendukung
berkualitas, seperti template dan daftar periksa. Perangkat ini, berdasarkan sebagai mereka berada
pada akumulasi pengetahuan dan pengalaman organisasi profesional pengembangan dan
pemeliharaan, berkontribusi untuk memenuhi SQA tujuan oleh: Menghemat waktu yang diperlukan
untuk menentukan struktur berbagai dokumen atau menyiapkan daftar mata pelajaran yang akan
ditinjau. Berkontribusi pada kelengkapan dokumen dan ulasan. Meningkatkan komunikasi antara tim
pengembangan dan anggota komite review dengan menstandardisasi dokumen dan agenda.

4.4.3 Pelatihan, instruksi dan sertifikasi staf Banalitas pernyataan bahwa seorang profesional yang
terlatih dan terpelajar staf adalah kunci untuk kinerja yang efisien dan berkualitas, tidak membuat
pengamatan ini menjadi kurang benar. Dalam kerangka SQA, menjaga sumber daya manusia
organisasi berpengetahuan dan diperbarui pada tingkat diperlukan dicapai terutama dengan: Melatih
karyawan baru dan melatih kembali karyawan yang telah tugas yang diubah. Terus memperbarui staf
sehubungan dengan perkembangan profesional dan pengalaman langsung yang diperoleh di rumah.
Sertifikasi karyawan setelah pengetahuan dan kemampuan mereka telah didemonstrasikan.

4.4.4 Tindakan pencegahan dan perbaikan Studi sistematis dari data yang dikumpulkan mengenai
contoh kegagalan dan keberhasilan berkontribusi pada proses penjaminan mutu dalam banyak hal.
Diantara mereka kita bisa daftar: Implementasi perubahan yang mencegah kegagalan serupa di masa
depan. Koreksi kesalahan serupa yang ditemukan di proyek lain dan di antara aktivitas yang dilakukan
oleh tim lain. Menerapkan metodologi yang terbukti berhasil untuk meningkatkan kemungkinan
keberhasilan yang berulang

4.4.5 Manajemen konfigurasi Operasi pengembangan dan pemeliharaan perangkat lunak reguler
melibatkan: aktivitas intensif yang memodifikasi perangkat lunak untuk membuat versi dan rilis baru.
Kegiatan ini dilakukan selama seluruh periode layanan perangkat lunak (biasanya berlangsung
beberapa tahun) untuk mengatasi koreksi yang diperlukan, adaptasi dengan kebutuhan pelanggan
tertentu, peningkatan aplikasi, Dan seterusnya. Anggota tim yang berbeda melakukan kegiatan ini
secara bersamaan, meskipun mungkin terjadi di lokasi yang berbeda. Akibatnya, serius bahaya
muncul, baik karena kesalahan identifikasi versi atau rilis, hilangnya catatan yang menggambarkan
perubahan yang diterapkan, atau hilangnya dokumentasi. Akibatnya kegagalan dapat disebabkan.
Manajemen konfigurasi menangani bahaya ini dengan memperkenalkan prosedur untuk mengontrol
proses perubahan. Prosedur ini berhubungan dengan persetujuan perubahan, pencatatan perubahan
yang dilakukan, penerbitan versi dan rilis perangkat lunak baru, rekaman versi dan spesifikasi rilis
perangkat lunak yang diinstal di setiap situs, dan pencegahan perubahan apa pun dalam versi dan rilis
yang disetujui setelah diterbitkan. Sebagian besar sistem manajemen konfigurasi menerapkan alat
terkomputerisasi untuk menyelesaikan tugas-tugas mereka. Sistem terkomputerisasi ini menyediakan
pembaruan dan versi yang tepat dari perangkat lunak yang diinstal untuk tujuan pengembangan lebih
lanjut atau koreksi. Prosedur konfigurasi perangkat lunak umumnya mengotorisasi dan administrator
atau komite manajemen konfigurasi untuk mengelola semua operasi manajemen konfigurasi yang
diperlukan.

4.4.6 Kontrol dokumentasi SQA membutuhkan penerapan langkah-langkah untuk memastikan

efisiensi jangka panjang ketersediaan dokumen utama yang terkait dengan pengembangan perangkat
lunak ("dokumen terkontrol"). Tujuan dari satu jenis dokumen yang dikendalikan – catatan kualitas –
terutama untuk memberikan bukti kinerja sistem SQA. Oleh karena itu, kontrol dokumentasi
mewakili salah satu blok bangunan dari setiap sistem SQA. 4.5 Komponen SQA Manajemen
Komponen SQA manajerial mendukung kontrol manajerial perangkat lunak proyek pembangunan dan
jasa pemeliharaan. Komponen kontrol meliputi: Kontrol kemajuan proyek (termasuk kontrol kontrak
pemeliharaan) Metrik kualitas perangkat lunak Biaya kualitas perangkat lunak.

4.5.1 Kontrol kemajuan proyek Tujuan utama dari komponen kontrol kemajuan proyek adalah untuk
mendeteksi munculnya situasi apa pun yang dapat menyebabkan penyimpangan dari proyek rencana
dan kinerja layanan pemeliharaan. Jelas, efektivitas dan efisiensi tindakan korektif yang diterapkan
tergantung pada penemuan situasi yang tidak diinginkan secara tepat waktu. Kegiatan pengendalian
proyek berfokus pada: Penggunaan sumber daya Jadwal Kegiatan manajemen risiko Anggaran.

4.5.2 Metrik kualitas perangkat lunak Pengukuran berbagai aspek kualitas perangkat lunak dianggap
sebagai alat yang efektif untuk mendukung kegiatan pengendalian dan inisiasi proses perbaikan
selama pengembangan dan fase pemeliharaan. Pengukuran ini berlaku untuk kualitas fungsional,
produktivitas, dan aspek organisasi proyek. Di antara metrik kualitas perangkat lunak yang tersedia
atau masih dalam proses pengembangan, kami dapat membuat daftar metrik untuk: Kualitas
pengembangan perangkat lunak dan aktivitas pemeliharaan Produktivitas tim pengembang Meja
bantuan dan produktivitas tim pemeliharaan Kerapatan kesalahan perangkat lunak Jadwal
penyimpangan.

4.5.3 Biaya kualitas perangkat lunak Biaya kualitas yang dikeluarkan oleh pengembangan perangkat
lunak dan aplikasi adalah, menurut model biaya kualitas yang diperluas, biaya pengendalian (biaya
pencegahan, biaya penilaian, dan persiapan manajerial dan biaya pengendalian) dikombinasikan
dengan biaya kegagalan (biaya kegagalan internal, kegagalan eksternal) biaya, dan biaya kegagalan
manajerial). Manajemen sangat tertarik pada jumlah total biaya kualitas. Diyakini bahwa sampai
tingkat tertentu, memperluas sumber daya yang dialokasikan untuk mengendalikan kegiatan
menghasilkan jauh lebih besar penghematan biaya kegagalan sekaligus mengurangi biaya kualitas
total. Dengan demikian, manajemen cenderung menunjukkan kesiapan yang lebih besar untuk
mengalokasikan dana untuk menguntungkan proposal untuk meningkatkan penerapan komponen
sistem SQA yang ada dan pengembangan lebih lanjut dari komponen baru.

4.6 standar SQA, sertifikasi sistem, dan penilaian komponen

Alat eksternal menawarkan jalan lain untuk mencapai tujuan jaminan kualitas perangkat lunak. Secara
khusus, tujuan utama dari kelas komponen ini adalah: (1) Pemanfaatan pengetahuan profesional
internasional. (2) Peningkatan koordinasi dengan sistem mutu organisasi lain. (3) Evaluasi profesional
yang objektif dan pengukuran prestasi dari sistem mutu organisasi.

4.6.1 Standar manajemen mutu Organisasi jelas dapat memperoleh manfaat dari standar kualitas yang
kedua sub-kelas yang memandu pengelolaan pengembangan perangkat lunak, pemeliharaan, dan
infrastruktur. Standar-standar ini berfokus pada apa yang dibutuhkan dan meninggalkan keputusan
tentang bagaimana mencapainya bagi organisasi. Aplikasi dari sistem mutu manajerial memberikan
penilaian yang cukup objektif terhadap pencapaian organisasi. Organisasi yang memenuhi kualitas
persyaratan pencapaian kemudian dapat mencari sertifikasi SQA. Contoh paling familiar dari jenis
standar ini adalah: Standar penilaian SEI CMM Standar ISO 9001 dan ISO 9000-3. 4.6.2 Standar
proses proyek Standar proses proyek adalah standar profesional yang memberikan pedoman
metodologis metode (berkaitan dengan pertanyaan "bagaimana") untuk pengembangan tim. Contoh
terkenal dari jenis standar ini adalah: Standar IEEE 1012 Standar ISO/IEC 12207

4.7 Pengorganisasian untuk SQA – komponen manusia

Bagian sebelumnya menunjukkan bahwa komponen SQA tidak dapat diterapkan dalam kekosongan
organisasi: mereka membutuhkan basis organisasi. Pangkalan ini termasuk manajemen organisasi,
personel pengujian perangkat lunak dan unit SQA selain profesional dan praktisi lain yang tertarik
pada kualitas perangkat lunak (pengurus SQA, anggota komite SQA dan forum SQA anggota). Semua
ini membentuk kerangka kualitas perangkat lunak organisasi atau, dalam istilah kami, basis organisasi
SQA. Tujuan utama dari SQA dasar organisasi adalah sebagai berikut: Untuk mengembangkan dan
mendukung implementasi komponen SQA. Untuk mendeteksi penyimpangan dari prosedur dan
metodologi SQA. Untuk menyarankan perbaikan pada komponen SQA. Meskipun seluruh basis
organisasi SQA berbagi tujuan ini, masing-masing segmen dasar organisasi berkonsentrasi pada
tugas-tugas tertentu.
4.7.1 Peran manajemen dalam SQA Tanggung jawab manajemen puncak (melalui eksekutif yang
bertanggung jawab atas) kualitas perangkat lunak), manajemen departemen dan manajemen proyek
termasuk berikut ini: Definisi kebijakan mutu Tindak lanjut implementasi kebijakan mutu yang efektif
Alokasi sumber daya yang cukup untuk menerapkan kebijakan mutu Penugasan staf yang memadai
Tindak lanjut kepatuhan prosedur jaminan kualitas Solusi masalah jadwal, anggaran dan hubungan
pelanggan.

4.7.2 Satuan SQA Unit dan penguji perangkat lunak ini adalah satu-satunya bagian dari basis
organisasi SQA yang mengabdikan diri penuh waktu untuk masalah SQA. Semua segmen lain dari
SQA basis organisasi (staf manajerial dan profesional) hanya berkontribusi sebagian dari waktu
mereka untuk masalah kualitas perangkat lunak. Dengan demikian, tugas unit SQA adalah sebagai
penggerak utama, pemrakarsa, dan koordinator sistem SQA dan penerapannya. Tugas ini dapat
dipecah menjadi beberapa peran utama: Persiapan program kualitas tahunan Konsultasi dengan staf
internal dan pakar luar tentang perangkat lunak masalah kualitas Pelaksanaan audit penjaminan mutu
internal Kepemimpinan berbagai komite penjaminan mutu Mendukung komponen infrastruktur
penjaminan mutu yang ada dan pembaruan, dan pengembangan komponen baru.

4.7.3 Pembina, komite, dan forum SQA Pengawas SQA adalah anggota tim pengembangan dan
pemeliharaan yang memiliki: minat khusus dalam kualitas perangkat lunak dan siap untuk
mengabdikan sebagian dari mereka waktu untuk masalah ini. Kontribusi mereka meliputi:
Memecahkan masalah kualitas tim atau unit lokal Mendeteksi penyimpangan dari prosedur dan
instruksi kualitas Memulai perbaikan dalam komponen SQA Melaporkan ke unit SQA tentang
masalah kualitas di tim atau unit mereka. Anggota komite SQA adalah anggota dari berbagai
pengembangan perangkat lunak dan unit pemeliharaan, dan biasanya ditunjuk untuk layanan jangka
atau ad hoc. Itu masalah utama yang ditangani oleh komite adalah: Solusi masalah kualitas perangkat
lunak. Analisis catatan masalah dan kegagalan serta catatan lainnya, diikuti dengan memulai tindakan
korektif dan pencegahan bila perlu. Inisiasi dan pengembangan prosedur dan instruksi baru;
memperbarui bahan yang ada. Inisiasi dan pengembangan komponen SQA baru dan peningkatan
komponen yang ada.

4.8 Pertimbangan yang memandu konstruksi sebuah sistem SQA

organisasi Sistem jaminan kualitas perangkat lunak berbeda di antara mereka sendiri, menunjukkan:
fleksibilitas yang melekat dalam konstruksi sistem tersebut. Apalagi variasi dalam karakteristik
organisasi tertentu yang menggunakan sistem SQA adalah: tercermin dalam pertimbangan yang
diterapkan, yang berarti bahwa organisasi yang berbeda menggunakan sistem SQA yang berbeda.
Keputusan mengenai sistem manajemen kualitas perangkat lunak organisasi jatuh ke dalam dua
kategori utama:
(a) Basis organisasi SQA (b) Komponen SQA yang akan diterapkan dalam organisasi dan sejauh
mana penggunaannya. Keputusan ini dipengaruhi oleh sejumlah pertimbangan mendasar yang:
mencerminkan karakteristik

(a) organisasi, (b) proyek pengembangan perangkat lunak dan layanan pemeliharaan yang akan
dilakukan, dan (c) staf profesional organisasi.

Pertimbangan utamanya adalah sebagai berikut. Pertimbangan organisasi: Jenis klien pengembangan
perangkat lunak. Kemungkinan klien termasuk: pembeli paket perangkat lunak, pelanggan paket
perangkat lunak yang dibuat khusus, dan pelanggan internal (departemen organisasi dan sub unit).
Jenis klien pemeliharaan perangkat lunak. Pelanggan pemeliharaan mungkin berbeda secara
substansial dari klien pengembangan perangkat lunak. Untuk misalnya, unit pemeliharaan internal
dapat melayani perangkat lunak yang dibeli paket atau perangkat lunak yang dibuat khusus yang
dikembangkan secara khusus untuk departemen organisasi oleh rumah perangkat lunak. Juga, rumah
perangkat lunak mungkin mempekerjakan sub kontraktor untuk memelihara paket perangkat lunaknya
yang dijual kepada klien selama masa garansi dan setelahnya. Berbagai produk. Situasi yang mungkin
bervariasi dari berbagai produk ke kisaran terbatas yang mencakup produk dan/atau layanan khusus.
Ukuran organisasi. Ukuran umum dari ukuran organisasi adalah jumlah profesional yang
dipekerjakan. Secara umum, semakin besar jumlah profesional yang diduduki oleh organisasi,
semakin besar jumlah spesialisasi yang berbeda, dan semakin besar variasi SQA komponen yang
dikembangkan dan diterapkan. Tingkat dan sifat kerjasama dengan organisasi lain yang membawa
keluar proyek terkait. Berbagai pilihan koperasi yang tersedia meliputi organisasi yang melaksanakan
seluruh proyek secara mandiri (tidak ada kerja sama), organisasi yang melakukan proyek dengan
mitra, dan organisasi yang mempekerjakan subkontraktor untuk menyelesaikan bagian-bagian tertentu
dari suatu proyek. Biasanya, semakin besar kerjasama semakin besar jumlah yang dibutuhkan
komponen SQA. Tujuan optimasi. Organisasi diharuskan untuk memilih komponen SQA sambil
mempertimbangkan kontribusi gabungan yang optimal dalam bidang-bidang berikut:

(a) kualitas perangkat lunak, (b) produktivitas tim, (c) proses efisiensi, dan (d) penghematan finansial