Nama: Agus Indrawan

Nim: 1955201109

Kelas : B2 Malam

Resume 11

Bab 17 Tindakan perbaikan dan pencegahan

Kegiatan sistematis yang mengimplementasikan perbaikan di seluruh organisasi efektivitas dan

efisiensi operasional termasuk dalam kategori korektif dan pencegahan (CAPA). Ini adalah kegiatan
yang tidak dimaksudkan untuk menangani koreksi langsung dari cacat yang terdeteksi tetapi untuk
menghilangkan penyebab cacat tersebut di seluruh departemen pengembangan perangkat lunak.
Dengan mempromosikan perbaikan terus-menerus dari efektivitas dan efisiensi, the Proses CAPA
telah menjadi salah satu alat utama yang digunakan untuk mencapai tujuan berorientasi kinerja SQA:
pemenuhan persyaratan fungsional dan manajerial. sekaligus mengurangi biaya pelaksanaan
pengembangan, pemeliharaan, dan perangkat lunak kegiatan penjaminan mutu. Untuk lebih lanjut
tentang tujuan SQA, lihat Bagian 2.5.3. Proses CAPA adalah subjek dari bab ini. Bagian terakhir
menyajikan ilustrasi penerapannya. Pentingnya CAPA dalam sistem SQA ditekankan oleh ISO standar
9000–3 (lihat ISO, 1997, Bagian 4.14 dan ISO/IEC, 2001, Bagian 8.5.2 dan 8.5.3). Prinsip-prinsip yang
mendasari proses adalah elemen utama dari Pedoman CMM (muncul di bawah judul "pencegahan
cacat") dirangkum oleh Paulk et al. (1995).

17.1 Pendahuluan: tim pengembangan “3S” ditinjau Kembali

Kami mengilustrasikan tindakan perbaikan dan pencegahan dengan melanjutkan kasus tersebut
Proyek “35” untuk Apollo Ltd dari Bab 16. Proyek ini, diselesaikan oleh Tim 7, telah beroperasi sekitar
tujuh bulan tetapi masalah tim lanjut. Dengan mengingat pengalaman sebelumnya, Development
Manajer departemen merasa bahwa penyebab kesulitan Tim seharusnya dianalisis. Dia percaya
bahwa beberapa kesimpulan yang dicapai dapat diterapkan dengan tepat di seluruh Departemen.
Peserta pada pertemuan yang diselenggarakan oleh manajer Departemen termasuk pemimpin Tim 7,
kepala unit SQA dan kepala unit Departemen Sumber Daya Manusia. Mereka mendefinisikan tujuan
mereka sebagai: “Untuk mendeteksi penyebab sistematis untuk fungsi Tim 7 yang tidak tepat dan
untuk merancang langkah-langkah untuk mencegah kekambuhannya”. Mereka mengangkat
pembatalan Pelatihan pembuat aplikasi Athena dan perekrutan a pemrogram pengganti Selain
beberapa kesimpulan pribadi, para peserta merekomendasikan agar tindakan berikut diambil:
(1) Prosedur pelatihan harus diperbarui dengan memasukkan klausula yang mewajibkan konsultan
atau mentor khusus untuk mendukung anggota tim jika tidak mampu menjalani pelatihan yang
diperlukan sebelum pengenalan aplikasi baru.

(2) Pemrogram harus ditambahkan ke dalam daftar posisi yang membutuhkan sertifikasi (lampiran
prosedur sertifikasi).

(3) Penunjukan mentor untuk jangka waktu minimal tiga bulan untuk karyawan departemen baru dan
dua bulan untuk pergantian karyawan posisi harus ditambahkan ke prosedur perekrutan. Modifikasi
dari periode pendampingan memerlukan persetujuan dari manajer Departemen.

(4) Focus Versi 6.1 baru ditemukan jauh melebihi Versi 5.1 sebelumnya dalam hal kualitas dan
produktivitas. Diputuskan bahwa semua Departemen tim akan mulai menggunakan Versi 6.1 dalam
tiga bulan ke depan. Tindakan yang disarankan didasarkan pada perbandingan kinerja Versi 6.1
Generator aplikasi fokus (digunakan untuk Integrasi B, C, D, E dan G) ke versi 5.1 (digunakan untuk
Integrasi A dan F), kedua versi memiliki telah diterapkan secara rutin oleh Tim 7 selama 10 bulan
terakhir.

17.2 Tindakan perbaikan dan pencegahan – definisi

Frame 17.1 menyajikan definisi korektif dan standar yang paling inklusif tindakan pencegahan
sehubungan dengan pengembangan dan pemeliharaan perangkat lunak t harus ditekankan bahwa
perbedaan analitik antara korektif dan tindakan pencegahan agak artifisial, seperti yang dapat dilihat
dari elemen analog dalam definisi mereka. Ini berarti bahwa barang-barang tertentu dari informasi
dapat mendukung tindakan perbaikan dan pencegahan. Selanjutnya, harus diingat bahwa kedua aspek
CAPA menciptakan, dalam praktiknya, tanggapan bersama; oleh karena itu, mereka akan diperlakukan
sebagai satu di sisa bab.

17.3 Proses tindakan perbaikan dan pencegahan

Operasi yang sukses dari proses CAPA mencakup kegiatan berikut:

■ Pengumpulan informasi

■ Analisis informasi

■ Pengembangan solusi dan metode yang diperbaiki

■ Penerapan metode yang ditingkatkan

■ Tindak lanjut.
Proses ini secara teratur diberi makan oleh aliran informasi dari berbagai sumber. Untuk
memperkirakan keberhasilan proses, loop umpan balik tertutup diterapkan untuk mengontrol aliran
informasi, implementasi perubahan yang dihasilkan dalam praktek dan prosedur bersama-sama
dengan pengukuran hasil.

17.4 Pengumpulan informasi

Berbagai sumber informasi, internal dan eksternal, yang melayani Proses CAPA cukup luar biasa.
Mengikuti internal/eksternal ini dikotomi, empat sumber informasi internal utama adalah

(1) Proses pengembangan perangkat lunak,

(2) Pemeliharaan perangkat lunak,

(3) infrastruktur SQA dan

(4) Prosedur pengelolaan kualitas perangkat lunak. Luar

sumber informasi terutama statistik aplikasi pelanggan dan keluhan pelanggan. Klasifikasi ini, yang
berkaitan dengan CAPA, disajikan dalam Bingkai 17.2.

17.5 Analisis informasi yang dikumpulkan

Pengoperasian rutin proses CAPA diharapkan dapat menciptakan aliran yang massif dokumen yang
berhubungan dengan berbagai informasi.

Analisis melibatkan:

■ Menyaring informasi dan mengidentifikasi potensi perbaikan. Dokumen yang diterima dari berbagai
sumber informasi ditelaah oleh para profesional untuk mengidentifikasi peluang potensial untuk
CAPA. Tahap ini meliputi perbandingan dokumen sejenis yang diterima dari berbagai unit serta
perbandingan dokumen dari berbagai jenis terkait kasus yang sama.

■ Analisis perbaikan potensial. Upaya diarahkan untuk menentukan:

– Jenis dan tingkat kerusakan yang diharapkan akibat kesalahan yang teridentifikasi.

– Penyebab kesalahan. Penyebab tipikal adalah ketidakpatuhan terhadap pekerjaan instruksi dan
prosedur, pengetahuan teknis yang tidak memadai, tekanan waktu dan/atau anggaran yang ekstrem
karena perkiraan yang tidak realistis, dan kurangnya pengalaman dengan alat pengembangan baru.

– Estimasi sejauh mana kesalahan potensial di seluruh organisasi masing-masing Tipe. Informasi ini
diperlukan untuk memperkirakan total kerusakan yang diharapkan dan untuk menentukan prioritas
setiap kasus gangguan.
■ Menghasilkan umpan balik tentang isi dan keteraturan informasi diterima dari sumber informasi
yang ditunjuk.

17.6 Pengembangan solusi dan implementasinya

Solusi untuk mengidentifikasi penyebab kesalahan sistem perangkat lunak berulang adalah diperlukan
untuk:

■ Hilangkan pengulangan jenis kesalahan yang terdeteksi

■ Berkontribusi pada peningkatan efisiensi dengan memungkinkan produktivitas yang lebih tinggi dan
jadwal yang lebih singkat. Beberapa arah untuk solusi biasanya diambil:

■ Memperbarui prosedur yang relevan. Perubahan dapat mengacu pada spektrum prosedur, dari yang
terkait dengan tahapan tertentu dari pengembangan perangkat lunak atau pemeliharaan (misalnya,
perubahan gaya komentar perangkat lunak, perubahan prosedur tinjauan kontrak dalam klausul yang
berhubungan dengan proposal kecil proyek) hingga prosedur yang bersifat umum (misalnya
perubahan karyawan prosedur rekrutmen, perubahan jumlah maksimum dan minimum peserta
dalam tinjauan desain formal).

■ Perubahan dalam praktik, termasuk pemutakhiran instruksi kerja yang relevan (jika ada).

■ Beralih ke alat pengembangan yang lebih efektif dan tidak terlalu rentan terhadap kesalahan yang
terdeteksi.

■ Peningkatan metode pelaporan, termasuk perubahan isi laporan, frekuensi tugas pelaporan dan
pelaporan. Arah ini diharapkan meningkatkan prospek untuk mengidentifikasi kesalahan sistem
perangkat lunak dan kesalahannya deteksi dini, keduanya menghasilkan pengurangan kerusakan yang
substansial.

■ Prakarsa untuk melatih, melatih kembali atau memperbaharui staf. Arah ini diambil hanya dalam
kasus ketika kekurangan pelatihan yang sama ditemukan di beberapa tim

17.7 Tindak lanjut kegiatan

Tiga tugas tindak lanjut utama diperlukan untuk berfungsinya proses tindakan korektif dan
pencegahan di organisasi mana pun:

■ Tindak lanjut alur pengembangan dan pemeliharaan catatan CAPA dari berbagai sumber informasi.
Hal ini memungkinkan umpan balik itu mengungkap kasus tidak adanya pelaporan serta pelaporan
berkualitas rendah, di mana detail penting hilang atau tidak akurat. Jenis tindak lanjut ini dilakukan
terutama melalui analisis informasi kegiatan jangka panjang, yang menghasilkan umpan balik ke
sumber informasi CAPA.

■ Tindak lanjut implementasi. Kegiatan ini dimaksudkan untuk menunjukkan apakah tindakan yang
ditentukan – kegiatan pelatihan, penggantian alat pengembangan, perubahan prosedur (setelah
persetujuan) – telah dilakukan dalam praktek. Umpan balik yang memadai disampaikan kepada
badan-badan yang bertanggung jawab pelaksanaan tindakan perbaikan dan pencegahan.

■ Tindak lanjut dari hasil. Tindak lanjut dari hasil aktual metode yang ditingkatkan, seperti yang
diamati oleh tim proyek dan unit organisasi, memungkinkan penilaian sejauh mana tindakan korektif
atau pencegahan memiliki tercapai hasil yang diharapkan. Umpan balik tentang hasil dikirim ke
pengembang metode yang ditingkatkan. Dalam kasus kinerja rendah, perumusan tindakan korektif
yang direvisi atau baru diperlukan, tugas dilakukan oleh tim CAPA.

17.8 Pengorganisasian tindakan pencegahan dan perbaikan

Kinerja yang tepat dari kegiatan CAPA ini tergantung pada keberadaan a unit organisasi inti permanen
serta banyak peserta tim ad hoc. Inti ini, umumnya dikenal sebagai Dewan Tindakan Korektif (CAB)
komite, meskipun mungkin memiliki judul lain di organisasi yang berbeda, mempromosikan penyebab
CAPA di dalam organisasi. Tugasnya antara lain:

■ Mengumpulkan catatan CAPA dari berbagai sumber

■ Menyaring informasi yang dikumpulkan

■ Menominasikan seluruh tim CAPA ad hoc untuk mengikuti mata pelajaran tertentu, atau memimpin
beberapa tim

■ Mempromosikan penerapan CAPA di unit, proyek, dll.

■ Menindaklanjuti pengumpulan informasi, analisis data, kemajuan yang dibuat oleh tim ad hoc dan
implementasi serta hasil perbaikan metode CAPA. Anggota unit SQA, profesional tingkat atas dan
pengembangan dan manajer departemen pemeliharaan adalah kandidat alami untuk menjadi anggota
komite CAB.

Ringkasan

(1) Jelaskan perbedaan antara koreksi cacat dan korektif dan preventif tindakan.

■ Koreksi cacat adalah aktivitas terbatas yang diarahkan pada solusi segera dari cacat terdeteksi dalam
proyek atau sistem perangkat lunak.
■ Tindakan korektif dan pencegahan memiliki cakupan yang lebih luas; mereka dimaksudkan untuk
memulai dan memandu kinerja tindakan di seluruh organisasi yang akan menghilangkan penyebab
kesalahan yang diketahui atau potensial. (2) Sebutkan jenis sumber internal utama untuk proses CAPA.

Ada empat jenis sumber informasi utama yang mendukung dan memberi makan proses CAPA:

■ Proses pengembangan perangkat lunak

■ Pemeliharaan perangkat lunak

■ Prosedur infrastruktur SQA

■ Prosedur manajemen kualitas perangkat lunak.

(3) Sebutkan dan jelaskan pendekatan utama untuk pengenalan CAPA.

Lima pendekatan yang umum digunakan:

■ Memperbarui prosedur yang relevan.

■ Mengubah praktik pengembangan atau pemeliharaan perangkat lunak dan memperbarui pekerjaan
instruksi.

■ Mengubah alat pengembangan perangkat lunak saat ini menjadi lebih efektif yang kurang rawan
kesalahan.

■ Meningkatkan metode pelaporan dengan merevisi isi tugas dan frekuensi pelaporan.Pendekatan ini
dimaksudkan untuk mencapai deteksi kesalahan lebih awal dan dengan demikian mengurangi ganti
rugi.

■ Memulai pelatihan, pelatihan ulang dan pemutakhiran staf.

bibliografi terpilih

1. ISO (1997) ISO 9000-3:1997(E), Manajemen Mutu dan Jaminan Mutu Standar – Bagian 3: Pedoman
Penerapan ISO 9001:1994 ke Pengembangan, Pengadaan, Instalasi dan Pemeliharaan Software
Komputer, 2nd edn, Organisasi Internasional untuk Standardisasi (ISO), Jenewa.

2. ISO/IEC (2001) “ISO 9000-3:2001 Rekayasa Perangkat Lunak dan Sistem – Pedoman Penerapan ISO
9001:2000 pada Perangkat Lunak, Final draft”, Organisasi Internasional untuk Standardisasi (ISO),
Jenewa, tidak diterbitkan draf, Desember 2001.

3. Paulk, M.C., Weber, C.V., Curtis, B. dan Chrissis, M.B. (1995) Kemampuan Model Kematangan:
Panduan untuk Meningkatkan Proses Perangkat Lunak, Addison Wesley, Reading, MA.
Tinjau pertanyaan

17.1 Analisis kasus yang dibahas dalam Bagian 17.5 melibatkan identifikasi penyebab cacat tetapi juga
menentukan jenis dan tingkat kerusakan yang diharapkan kesalahan yang teridentifikasi, diikuti
dengan persiapan perkiraan kerusakan tersebut dan distribusi informasi di seluruh organisasi tentang
cacat masing-masing dan ganti rugi.

(1) Beberapa profesional SQA percaya bahwa analisis kasus harus dibatasi untuk mengidentifikasi
penyebab cacat. Apa kamu setuju?

(2) Buat daftar argumen Anda. 17.2 Metode pelaporan yang ditingkatkan disebutkan (dalam Bagian
17.6) sebagai solusi yang memungkinkan untuk cacat yang teridentifikasi, meskipun tidak ada
perubahan praktik kinerja yang direkomendasikan dalam CAPA terkait.

(1) Beberapa profesional SQA percaya bahwa CAPA tidak memiliki tempat untuk perubahan metode
pelaporan. Apa kamu setuju? Buat daftar argumen Anda.

(2) Jika Anda tidak setuju, cantumkan kemungkinan kontribusi yang dapat dibuat oleh CAPA
mengubah metode pelaporan.

17.3 Bagian 17.7 mencantumkan tiga tugas utama tindak lanjut CAPA.

(1) Sebutkan tiga tugas.

(2) Jelaskan, dengan kata-kata Anda sendiri, pentingnya tugas tindak lanjut untuk keberhasilan proses.

Topik untuk diskusi

17.1 Bingkai 17.2 mencantumkan empat jenis sumber informasi CAPA internal.

(1) Mengingat banyaknya sumber informasi CAPA internal, bersifat eksternal sumber informasi yang
diperlukan?

(2) Jika Anda yakin bahwa sumber informasi eksternal diperlukan, buatlah daftar argumen Anda dan
jelaskan kontribusi khusus mereka terhadap proses CAPA. 17.2 Pernyataan Software Ltd adalah rumah
perangkat lunak yang berspesialisasi dalam pengembangan sistem penagihan yang dibuat khusus
untuk industri manufaktur. Biasa Kontrak “Perangkat Lunak Pernyataan” menawarkan layanan
jaminan selama 12 bulan kepada pelanggan. Meja bantuan (HD) perusahaan menyediakan solusi
untuk panggilan pelanggan melalui telepon atau di tempat. Laporan kinerja kuartal terakhir
menunjukkan penurunan kualitas layanan,

Bab 18 Manajemen konfigurasi

Ini dan banyak pertanyaan serupa mencerminkan fakta bahwa sistem perangkat lunak yang aktif
adalah sistem yang terus berubah. Bahkan perangkat lunak berukuran sedang sistem, melayani hanya
satu organisasi, biasanya mengalami puluhan hingga ratusan perubahan setiap tahun; Oleh karena itu,
langkah-langkah penjaminan mutu harus direncanakan memberikan tanggapan yang akurat untuk
banyak pertanyaan yang mirip dengan contoh kami. Jika paket perangkat lunak melayani berbagai
pelanggan, jumlah perubahan dan pertanyaan yang harus ditanggapi akan berlipat ganda. Jelas,
kebutuhan untuk mengatasi perubahan perangkat lunak yang cepat adalah salah satunya tugas
penting tim pengembangan dan pemeliharaan sistem perangkat lunak. Tugas mencakup jaminan
kualitas yang memadai dari semua perubahan yang dilakukan dan dokumentasi yang sesuai serta
identifikasi versi (atau rilis) perangkat lunak yang diinstal oleh setiap pelanggan. Upaya yang
diperlukan untuk mendokumentasikan berbagai item serta manfaat dari dokumentasi yang tepat
dapat dihargai hanya pada akhir masa layanan karena sistem perangkat lunak harus dipertahankan
selama bertahun-tahun, terlepas dari perubahan lingkungan teknologi dan pergantian staf.

18.1 Konfigurasi perangkat lunak, itemnya danpengelolaan

Unit kode perangkat lunak, dokumen atau perangkat keras didefinisikan sebagai SCI jika diasumsikan
bahwa itu mungkin diperlukan untuk pengembangan lebih lanjut dari sistem perangkat lunak
dan/atau pemeliharaannya. Dengan kata lain, kriteria utama mengatur klasifikasi item non-kode
sebagai SCI dan pencantumannya dalam aversi konfigurasi perangkat lunak adalah potensi
kontribusinya terhadap perangkat lunak proses pengembangan dan pemeliharaan. Konfigurasi
perangkat lunak terdiri dari SCI sebanyak yang diasumsikan oleh pengembang akan diperlukan di masa
mendatang, dengan setiap SCI disetujui, diidentifikasi dan terdaftar. SCI dikumpulkan di setiap versi
konfigurasi perangkat lunak secara alami sesuai dengan komponen perangkat lunak dan definisi
perangkat lunak ditinjau dalam Bagian 2.1. SCIs umumnya ditempatkan ke dalam empat kelas,

sebagai berikut:

■ Dokumen desain

■ Kode perangkat lunak

■ File data, termasuk file kasus pengujian dan skrip pengujian

■ Alat pengembangan perangkat lunak.

Daftar jenis SCI yang umum disajikan dalam Frame 18.2.

18.2 Manajemen konfigurasi perangkat lunak – tugas dan organisasi

18.2.1 Tugas manajemen konfigurasi perangkat lunak Tugas manajemen konfigurasi perangkat lunak
dapat diklasifikasikan menjadi

empat kelompok:

■ Mengontrol perubahan perangkat lunak

■ Rilis SCI dan versi konfigurasi perangkat lunak

18.2.2 Otoritas konfigurasi perangkat lunak

Secara praktis terbukti dengan sendirinya bahwa otoritas untuk mengawasi pelaksanaannya tugas-
tugas di atas sangat penting dalam mengembangkan perangkat lunak dan/atau memelihara
organisasi. Prosedur SCM menentukan siapa yang bertanggung jawab atas masalah SCM. Ini tanggung
jawab biasanya diberikan kepada profesional senior atau komite yang didedikasikan untuk masalah
SCM. Di banyak organisasi, kontrol perubahan perangkat lunak ditangani oleh komite khusus yang
dibentuk untuk hal-hal seperti itu, biasa disebut otoritas kontrol perubahan perangkat lunak (SCCA)
atau papan kontrol perubahan perangkat lunak (SCCB). Tubuh ini sering disebut kontrol perubahan
otoritas (CCA) atau dewan kontrol perubahan (CCB). Selama tahap pengembangan, manajer proyek
dapat dibebankan dengan kewenangan untuk melaksanakan tanggung jawab SCM. Kegiatan yang
terlibat dalam mewujudkan masing-masing tujuan di atas dibahas dalam Bagian 18.3 hingga 18.6.
Bagian 18.7 membahas alat SCM terkomputerisasi.

18.3 Kontrol perubahan perangkat lunak

Manajemen perubahan perangkat lunak mengontrol proses memperkenalkan perubahan terutama

dengan melakukan hal berikut:

■ Memeriksa permintaan perubahan dan menyetujui penerapan permintaan yang sesuai.

■ Menjamin kualitas setiap versi baru dari konfigurasi perangkat lunak sebelumnya itu menjadi
operasional.

18.3.1 Persetujuan untuk melaksanakan perubahan yang diusulkan Setelah versi dasar dari sistem
perangkat lunak menjadi operasional, itu adil masalah waktu sebelum proposal perubahan mulai
mengalir. Inisiatif ini mungkin berhubungan dengan satu atau beberapa SCI. Untuk
mengkoordinasikan upaya yang diinvestasikan dan menjamin bahwa perubahan mengikuti prioritas
proyek atau pelanggan, anbadan yang berwenang harus menganalisis permintaan dan membuat
keputusan yang diperlukan.

Faktor-faktor yang mempengaruhi keputusan apakah akan menerapkan usulan perubahan antara lain:
■ Kontribusi yang diharapkan dari perubahan yang diusulkan

■ Urgensi perubahan

■ Pengaruh perubahan yang diusulkan pada jadwal proyek, tingkat layanan, dll.

■ Upaya-upaya yang diperlukan untuk membuat perubahan menjadi operasional

■ Diperlukan upaya jaminan kualitas perangkat lunak

■ Perkiraan sumber daya profesional yang dibutuhkan dan biaya untuk melakukan perubahan.

Item informasi yang diperlukan sebelum keputusan tentang proposal perubahan dapat dibuat
tercermin dalam isi permintaan perubahan perangkat lunak yang khas (SCR) formulir. (Informasi yang
sama dapat diungkapkan sebagai permintaan perubahan – CR – atau permintaan perubahan teknik –
ECR.) Lihat Frame 18.4 untuk contoh. Terlepas dari urgensi yang dirasakan dari perubahan, keputusan
yang menguntungkan tidak secara otomatis diberikan kepada inisiatornya. CCA dapat menyetujui
permintaan untuk implementasi segera, menunda atau menolaknya.

18.4 Rilis versi konfigurasi perangkat lunak

Kebutuhan untuk merilis versi konfigurasi perangkat lunak baru biasanya berasal dari satu atau lebih
dari kondisi berikut:

■ SCI yang rusak

■ Fitur khusus yang diminta oleh pelanggan baru

■ Inisiatif tim untuk memperkenalkan peningkatan SCI. Sebuah diskusi tentang isu-isu berikut, yang
semuanya merupakan bagian dari proses rilis versi konfigurasi perangkat lunak, menempati sisa
bagian ini:

■ Jenis rilis konfigurasi perangkat lunak

■ Rencana manajemen konfigurasi perangkat lunak (SCMP)

■ Model evolusi konfigurasi perangkat lunak

■ Dokumentasi versi konfigurasi perangkat lunak.

18.5 Penyediaan layanan informasi SCM

SCM diharuskan untuk memberikan informasi kepada para profesional, terutama pengembang, tim
pemeliharaan, dan perwakilan pelanggan, yang telah meminta bahwa perubahan diperkenalkan
dalam sistem perangkat lunak. Informasi yang diberikan dapat diklasifikasikan ke dalam informasi yang
berkaitan dengan kontrol perubahan perangkat lunak dan informasi yang berhubungan dengan SCI
dan versi konfigurasi perangkat lunak. Informasi yang berkaitan dengan kontrol perubahan perangkat
lunak

■ Mengubah informasi status permintaan – berdasarkan catatan untuk setiap pengajuan SCR dan
keputusan yang dibuat.

■ Ubah informasi kemajuan pesanan – berdasarkan catatan untuk setiap SCO yang disetujui,
jadwalnya, kemajuan implementasi dan hasil pengujian. Informasi tentang keterlambatan kinerja juga
dapat diberikan. Informasi tentang SCI dan versi konfigurasi perangkat lunak

■ Salinan versi SCI yang akurat (SCI kode, SCI dokumen, dll.) dan seluruh versi konfigurasi perangkat
lunak.

■ Laporan lengkap tentang perubahan yang diperkenalkan di antara rilis yang berurutan (versi
dan/atau revisi) kode SCI serta antara rilis berturut-turut dari jenis SCI lainnya.

■ Salinan dokumentasi versi SCI dan versi konfigurasi perangkat lunak dokumentasi (VDD).

■ Versi terperinci dan riwayat revisi untuk SCI dan konfigurasi perangkat lunak untuk SCI atau sistem
perangkat lunak tertentu.

■ Informasi kemajuan tentang versi dan rilis yang direncanakan (biasanya disertakan dalam SCMP).

■ Informasi berkorelasi tentang versi yang dipasang di situs tertentu dan tentangnya situs itu sendiri.

■ Daftar situs tempat menginstal versi konfigurasi perangkat lunak tertentu. Penyediaan layanan
informasi di atas secara praktis tidak mungkin untuk sistem SCM manual. Hanya layanan
terkomputerisasi yang diharapkan dapat mengatasi hal ini tugas secara efektif dan dapat diandalkan.
Untuk lebih lanjut tentang subjek ini, lihat Bagian 18.7.

18.6 Audit manajemen konfigurasi perangkat lunak

SCM melibatkan pelaksanaan berbagai macam tugas oleh otoritas SCM, CCB dan banyak lainnya yang
terlibat dalam pengembangan perangkat lunak dan pemeliharaan. Semua tugas masing-masing
didefinisikan dalam prosedur SCM. Audit SCM dilakukan oleh otoritas SCM dan CCB untuk kontrol
kepatuhan dengan prosedur SCM. Audit SCM dapat digabungkan dengan masalah kualitas internal
(lihat Bab 27), dan diharapkan untuk memulai pembaruan dan perubahan prosedur dan instruksi SCM.
Oleh karena itu, SCM audit memeriksa apakah dan bagaimana tugas-tugas ini dilakukan untuk sampel
permintaan perubahan, SCI, dan versi konfigurasi perangkat lunak. Audit SCM mungkin juga dilakukan
untuk sampel rilis yang direncanakan, sebagaimana ditentukan dalam SCMP. Namun, meskipun kami
mengharapkan audit SCM untuk menghasilkan informasi mengenai tingkat kepatuhan terhadap
prosedur SCM (termasuk kegagalan tipikal prosedur tersebut), mereka tidak dapat berfungsi sebagai
alat penegakan kepatuhan. Berikut ini adalah daftar bit khas informasi kontrol yang SCM audit
dimaksudkan untuk menemukan dan mengirimkan kepada manajemen:

■ Persentase perubahan yang tidak disetujui yang dimasukkan ke dalam sistem selama
pengembangan atau pengoperasian.

■ Persentase SCO tidak dilaksanakan sesuai instruksi dan tidak sepenuhnya sesuai dengan prosedur.

■ Persentase tinjauan desain dan pengujian perangkat lunak dari SCI yang telah diubah tidak dilakukan
sesuai dengan prosedur yang relevan.

■ Persentase SCO yang telah diselesaikan sesuai jadwal.

■ Persentase kasus di mana SCI tidak terpengaruh oleh perubahan diperiksa, dengan beberapa
perubahan yang diperlukan tidak diterapkan.

■ Persentase SCI baru yang didokumentasikan dengan baik dan versi konfigurasi perangkat lunak.

■ Persentase penginstalan versi konfigurasi perangkat lunak baru yang terdokumentasi dengan baik.

■ Persentase kasus kegagalan mengirimkan semua informasi terkait versi kepada pelanggan.

■ Jumlah kasus yang dicatat setiap tahun di mana koordinasi kerja SCI mekanisme gagal (yaitu, tidak
mencegah tim yang berbeda untuk secara bersamaan memperkenalkan perubahan dalam SCI yang
sama).

18.7 Alat terkomputerisasi untuk mengelola perangkat lunak konfigurasi

Alat SCM terkomputerisasi telah ada di pasaran selama bertahun-tahun. Ini alat terkomputerisasi
berbeda dalam tingkat kelengkapan, fleksibilitas aplikasi dan kemudahan penggunaan. Alat yang lebih
komprehensif dapat menyediakan sebagian besar atau hampir semua layanan informasi SCM
tercantum dalam Bagian 18.5. Diharapkan alat yang terkomputerisasi akan dapat memenuhi
kebutuhan tersebut diperlukan tingkat akurasi dan kelengkapan informasi, dan dengan tingkat
ketersediaan yang diperlukan (diukur dengan waktu respons dari permintaan informasi untuk
ketentuannya). Alat SCM terkomputerisasi juga mengoperasikan mekanisme koordinasi pekerjaan
pada SCI berubah dan mencegah tim yang berbeda secara bersamaan memperkenalkan perubahan
dalam SCI yang sama. Manfaat tambahan dari penggunaan sistem SCM terkomputerisasi adalah
tingkat keamanan tinggi yang mampu disediakannya:
■ Ini mengamankan versi kode dan versi file dokumentasi dengan melindunginya dari segala
perubahan, penghapusan, dan kerusakan lainnya.

■ Mengaktifkan prosedur pencadangan yang diperlukan untuk penyimpanan file SCM yang aman. Alat
yang disempurnakan saat ini ditandai dengan kapasitas input yang lebih mudah, koordinasi tim
pendukung SCM yang beroperasi dalam pengembangan yang berbeda lingkungan, termasuk tim yang
terdistribusi secara geografis, dan penyediaan berbagai opsi pelaporan yang diperluas.

Ringkasan

(1) Menentukan versi konfigurasi perangkat lunak.

Versi konfigurasi perangkat lunak adalah kumpulan versi SCI yang disetujui yang merupakan sistem
perangkat lunak terdokumentasi pada titik waktu tertentu. Masing-masing kegiatan dikendalikan oleh
prosedur manajemen konfigurasi perangkat lunak.

(2) Jelaskan tugas manajemen konfigurasi perangkat lunak.

Tugas manajemen konfigurasi perangkat lunak diklasifikasikan ke dalam empat kelompok berikut:

■ Pengendalian perubahan perangkat lunak

■ Rilis SCI dan versi konfigurasi perangkat lunak

■ Penyediaan layanan informasi SCM

■ Verifikasi kepatuhan terhadap prosedur SCM.

(3) Sebutkan tugas utama kontrol perubahan perangkat lunak.

Tugas utama manajemen perubahan perangkat lunak dapat digambarkan sebagai:

■ Memeriksa permintaan perubahan dan menyetujui penerapan permintaan tersebut memenuhi

syarat.

■ Mengontrol perubahan dan memastikan kualitas perubahan yang disetujui.

■ Mendokumentasikan perubahan yang disetujui.

■ Menerapkan mekanisme yang mencegah lebih dari satu tim secara bersamaan memperkenalkan
perubahan ke dalam SCI yang sama

Bibliografi terpilih
1. IEEE (1998) “IEEE Std 828–1998–IEEE Standard untuk Konfigurasi Perangkat Lunak Rencana
Manajemen”, dalam Pengumpulan Standar Rekayasa Perangkat Lunak IEEE, The Institut Insinyur
Listrik dan Elektronik, New York.

2. ISO (1997) ISO 9000–3:1997(E), Manajemen Mutu dan Jaminan Mutu Standar – Bagian 3: Pedoman
Penerapan ISO 9001:1994 ke Pengembangan, Pengadaan, Pemasangan dan Pemeliharaan Perangkat
Lunak Komputer, edisi ke-2, International Organization for Standardization (ISO), Jenewa, paragraf
4.8.

3. ISO/IEC (2001) “ISO 9000–3:2001 Rekayasa Perangkat Lunak dan Sistem – Pedoman Penerapan ISO
9001:2000 pada Perangkat Lunak, Final draft”, Organisasi Internasional untuk Standardisasi (ISO),
Jenewa, tidak diterbitkan draf, Desember 2001.

4. Leon, A. (1999) Panduan Manajemen Konfigurasi Perangkat Lunak, Artech Rumah, Boston, MA.

5. Paulk, M.C., Weber, C.V., Curtis, B. dan Chrissis, M.B. (1995) Kemampuan Model Kematangan:
Panduan untuk Meningkatkan Proses Perangkat Lunak, Addison Wesley, Reading, MA, hlm. 180–191.

6. Pressman, R.S. (2000) Rekayasa Perangkat Lunak – Pendekatan Praktisi, Adaptasi Eropa oleh D. Ince,
edisi ke-5, McGraw-Hill International, London.

7. Siegel, G.S. dan Donaldson S.D. (1999) “Manajemen konfigurasi perangkat lunak – tampilan yang
praktis”, dalam G.G. Schulmeyer dan J.I. McManus (eds), Handbook of Jaminan Kualitas Perangkat
Lunak, edisi ke-3, Prentice Hall, Upper Saddle River, NJ, hlm. 255–290.

8. Van Vliet, H. (2000) Prinsip dan Praktik Rekayasa Perangkat Lunak, Ch. 4, Yohanes Wiley & Sons,
New York.

Tinjau pertanyaan

18.1 Salah satu tugas SCTopik untuk diskusi

18.1 Salah satu tugas SCM adalah: “Menerapkan mekanisme yang mengoordinasikan perubahan
dibuat untuk SCI dengan mencegah lebih dari satu tim secara bersamaan memperkenalkan perubahan
ke dalam SCI yang sama”.

(1) Jelaskan dengan kata-kata Anda sendiri pentingnya tugas ini dan kontribusinya kualitas perangkat
lunak.

(2) Berikan contoh yang mengilustrasikan konsekuensi dari kegagalan SCM efektif menerapkan tujuan
ini
18.2 Keberhasilan sistem SQA sangat bergantung pada kepatuhan prosedur SCM.

(1) Mengacu pada tugas kontrol perubahan perangkat lunak SCM, jelaskan sendiri kata-kata risiko
yang ditimbulkan terhadap kualitas perangkat lunak dengan kepatuhan sebagian terhadap SCM
Prosedur.

(2) Mengacu pada rilis versi baru dari sistem perangkat lunak, jelaskan di kata-kata Anda sendiri risiko
yang ditimbulkan terhadap kualitas perangkat lunak dengan kepatuhan Sebagian untuk prosedur SCM.

(3) Alat apa yang tersedia untuk verifikasi kepatuhan terhadap prosedur SCM? 18.3 Dua SCR telah
diajukan ke CCB untuk pengambilan keputusan. Beberapa karakteristik mereka adalah:

SCR–1:

■ Diharapkan untuk berkontribusi secara substansial terhadap penjualan terkemuka perusahaan

paket perangkat lunak

■ Esensi perubahan: pengenalan fungsi perangkat lunak baru

■ Diperlukan perubahan pada dua SCI perangkat lunak

■ SCI lain yang diharapkan terpengaruh oleh perubahan yang diminta – tidak ada

■ Perkiraan sumber daya profesional yang dibutuhkan – 40 hari kerja

■ Perkiraan jadwal pelaksanaan – 2 bulan.M adalah menyediakan informasi tentang lokasi yang
diberikan versi konfigurasi perangkat lunak diinstal (Tabel 18.2). Jelaskan penggunaan potensial untuk
jenis informasi ini dan kontribusinya terhadap kualitas perangkat lunak. 18.2 Dokumen desain atau
file kode sumber diidentifikasi dan disimpan sebagai SCI (lihat Frame 18.2) untuk alasan yang jelas:
pengembangan lebih lanjut dari sistem perangkat lunak atau koreksinya tidak dapat terjadi tanpa
salinan akurat dari item-item ini. Jelaskan dengan kata-kata Anda sendiri mengapa yang berikut ini
harus diidentifikasi dan disimpan sebagai SCI:

(1) Uji kasus

(2) Penyusun

(3) Rencana instalasi perangkat lunak

(4) File permintaan perubahan perangkat lunak.

18.3 SCR yang berkaitan dengan hanya dua SCI sumber perangkat lunak telah disetujui.
Namun, rencana pengujian perangkat lunak yang disiapkan oleh Unit Pengujian menyebutkan
sembilan di antaranya SCI sumber perangkat lunak sistem. Jelaskan dengan kata-kata Anda sendiri
mengapa menguji kedua SCI mungkin tidak cukup ditentukan dalam SCR setelah diubah.

18.4 Disebutkan bahwa riwayat versi dari konfigurasi sistem perangkat lunak mencakup rilis versi
baseline, intermediate, dan revisi.

(1) Jelaskan dengan kata-katamu sendiri fungsi dari setiap jenis pelepasan.

(2) Jelaskan dengan kata-kata Anda sendiri pentingnya versi baseline.

18.5 Frame 18.6 adalah template yang mencantumkan item informasi yang diperlukan untuk
perangkat lunak dokumentasi versi konfigurasi (VDD). Daftar kemungkinan penggunaan untuk setiap
item informasi yang disebutkan dalam template.

Topik untuk diskusi

18.1 Salah satu tugas SCM adalah: “Menerapkan mekanisme yang mengoordinasikan perubahan
dibuat untuk SCI dengan mencegah lebih dari satu tim secara bersamaan memperkenalkan perubahan
ke dalam SCI yang sama”.

(1) Jelaskan dengan kata-kata Anda sendiri pentingnya tugas ini dan kontribusinya kualitas perangkat
lunak.

(2) Berikan contoh yang mengilustrasikan konsekuensi dari kegagalan SCM efektif menerapkan tujuan
ini

18.2 Keberhasilan sistem SQA sangat bergantung pada kepatuhan prosedur SCM.

(1) Mengacu pada tugas kontrol perubahan perangkat lunak SCM, jelaskan sendiri kata-kata risiko
yang ditimbulkan terhadap kualitas perangkat lunak dengan kepatuhan sebagian terhadap SCM
Prosedur.

(2) Mengacu pada rilis versi baru dari sistem perangkat lunak, jelaskan di kata-kata Anda sendiri risiko
yang ditimbulkan terhadap kualitas perangkat lunak dengan kepatuhan Sebagian untuk prosedur SCM.

(3) Alat apa yang tersedia untuk verifikasi kepatuhan terhadap prosedur SCM? 18.3 Dua SCR telah
diajukan ke CCB untuk pengambilan keputusan. Beberapa karakteristik mereka adalah: SCR–1:

■ Diharapkan untuk berkontribusi secara substansial terhadap penjualan terkemuka perusahaan

paket perangkat lunak

■ Esensi perubahan: pengenalan fungsi perangkat lunak baru

■ Diperlukan perubahan pada dua SCI perangkat lunak

■ SCI lain yang diharapkan terpengaruh oleh perubahan yang diminta – tidak ada

■ Perkiraan sumber daya profesional yang dibutuhkan – 40 hari kerja

■ Perkiraan jadwal pelaksanaan – 2 bulan.