Terjemahan Corrective and preventive actions (CAPA)

Chapter 17

Corrective and preventive actions (CAPA)

Corrective and preventive actions (CAPA) , merupakan kegiatan sistematis dalam melaksanakan perbaikan tingkat efektifitas dan efisiensi operasional di suatu organisasi. Ini adalah beberapa aktivitas  yang tidak dimaksudkan untuk memperbaiki secara langsung dari cacat(defect) yang terdeteksi, namun CAPA ini ditujukan untuk
menghilangkan penyebab yang menimbulkan berbagai macam cacat (defect) di semua bagian organisasi pengembangan perangkat lunak.

Dengan mempromosikan perbaikan terus-menerus dari efektivitas dan efisiensi, Proses CAPA telah menjadi salah satu alat utama mencapai tujuan SQA yang berorientasi perfoma: pemenuhan kebutuhan fungsional dan manajerial  sementara mengurangi biaya pengembangan software, maintenance, dan aktifitas jaminan kualitas, lihat Bagian 2.5.3.

Proses CAPA adalah subjek dari bab ini. Bagian terakhir dari bab ini akan menyajikan ilustrasi pelaksanaannya.

Pentingnya CAPA dalam sistem SQA ditekankan oleh ISO 9000-3 standar (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 (elemen-elemen ini berada di judul "pencegahan cacat"),diringkas oleh Paulk et al. (1995).

Setelah menuntaskan chapter ini pembaca akan mampu menjawab pertanyaan-pertanyaan berikut:

1.       Menelaskan perbedaan antara tindakan koreksi cacat dan korektif dan preventif.

2.       Menyebutkan jenis utama dari sumber-sumber internal untuk proses CAPA.

3.       Menyebutkan Daftar dan menjelaskan pendekatan utama untuk pengenalan CAPA.

4.       Menjelaskan CAPA yang utama diikuti dengan tugas-tugasnya.

5.       Menyebutkan yang berperan dalam proses CAPA dan kontribusi mereka terhadap kesuksesan suatu  implementasi.

17.1 Pendahuluan: revisi tim pengmbangan "3S" (Sahara Software Specialists) 

Kami menggambarkan tindakan korektif dan preventif dengan melanjutkan kasus "35" proyek Apollo Ltd dari Bab 16. Proyek ini, dilengkapi dengan Tim 7, telah operasi selama sekitar tujuh bulan, tetapi masalah dalam tim terus berlanjut. Menjaga pengalaman sebelumnya dalam pikiran, Manajer  Departemen  pengmbangan merasa bahwa penyebab kesulitan Tim harus dianalisis. Dia percaya bahwa beberapa kesimpulan yang dicapai akan tepat dan dapat diterapkan di seluruh Departemen.

Peserta pada pertemuan yang diselenggarakan oleh manajer Departemen termasuk pimpinan  Tim 7, kepala unit SQA dan kepala HRD. Mereka mendefinisikan tujuan mereka sebagai: "Untuk mendeteksi penyebab sistematis dari fungsi  Tim 7 yang tidak tepat dan untuk merancang langkah-langkah untuk mencegah terulangnya masalah ". Mereka mengemukakan tentang  pembatalan pelatihan Athena application generator dan perekrutan yang gagal dari programmer pengganti. Selain beberapa kesimpulan pribadi, para peserta merekomendasikan bahwa tindakan berikut harus diambil:

(1)     Prosedur pelatihan harus diperbarui untuk menyertakan klausul yang mengharuskan konsultan khusus atau mentor untuk mendukung anggota tim dalam kasus ketidakmampuan menjalani  pelatihan yang dibutuhkan sebelum pengenalan aplikasi baru.

(2)     Programmer  harus ditambahkan ke daftar posisi yang memerlukan sertifikasi (Sertifikasi prosedur lampiran).

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

(4)     “The new Focus “Versi  6.1 ditemukan jauh melebihi  Versi  sebelumnya  5.1 dalam hal kualitas dan produktivitas. Diputuskan bahwa semua Departemen tim akan mulai menggunakan Versi 6.1 dalam tiga bulan ke depan. Yang direkomendasikan tindakan yang didasarkan pada perbandingan kinerja Versi 6.1 dari “Focus application generator “(digunakan untuk integrasi B, C, D, E dan G)  sedangkan untuk  Versi 5.1 (digunakan untuk integrasi A dan F), kedua  versi  telah diterapkan secara teratur oleh Tim 7 untuk 10 bulan terakhir.

Sebelum menutup pertemuan, salah satu peserta berkomentar bahwa materi  pertemuan mereka seharusnya sudah dilaksanakan jauh hari oleh CAB  (Dewan Corrective Action), panitia  menekankan  untuk  mereview kejadian tersebut  dan supaya memulai tindakan seperti ini untuk kasus-kasus lain yang serupa dengan proyek Apollo. Peserta lainnya sepakat. Sebuah investigasi singkat mengungkapkan bahwa komite CAB perusahaan tidak aktif lagi semenjak  pengunduran diri pimpinan terakhirnya dan keberangkatan dari “3S” (Sahara Software Specialists) sekitar 17 bulan yang lalu. Mereka juga menemukan bahwa tidak ada internal audit yang pernah mereview ktifitas CAB meskipun prosedur perusahaan menuntut audit ini. Oleh karena itu, para peserta menambahkan dua item tindakan ke daftar rekomendasi:

(5)     Untuk "mengaktifkan kembali" Panitia, pertama-tama, menemukan calon yang tepat untuk menjadi pimpinan CAB dan memperbaharui aktivitas lumpuh nya.

(6)     Menyiapkan lampiran baru untuk prosedur audit kualitas di lingkungan internal ddalam menangani kegiatan CAB.

Ke-enam rekomendasi di atas  adalah contoh dari Corrective and preventive actions (CAPA).

17.2. Definisi Tindakan CAPA

1.     Corrective Actions:

Proses umpan balik secara berkala mencakup pengumpulan informasi tentang kualitas ketidaksesuaian, identifikasi dan analisis sumber dari penyimpangan serta pengembangan dan asimilasi praktek dan prosedur perbaikan , bersama-sama dengan kontrol terhadap implementasi dan pengukuran hasil keluaran

2.     Preventive Actions:

Proses feedback secara berkala mencakup pengumpulan informasi tentang potensi masalah dalam hal kualitas, identifikasi dan analisis penyimpangan dari standar kualitas, pengembangan dan asimilasi praktek dan prosedur perbaikan, bersama-sama dengan kontrol terhadap implementasi dan pengukuran hasil keluaran.

Perlu ditekankan bahwa perbedaan analitik antara korektif dan tindakan preventive  agak seperti dibuat-buat, seperti dapat dilihat melalui unsur-unsur analog dalam definisinya. Ini berarti bahwa item yang jelas dari informasi dapat mendukung tindakan korektive dan preventif. Selain itu, harus diingat tentang dua aspek CAPA ini dibuat,dalam prakteknya, respon bersama, sehingga mereka akan diperlakukan sebagai satu kesatuan di akhir bab ini.

17.3 Proses CAPA

Keberhasilan operasi dari proses CAPA meliputi kegiatan sebagai berikut:

1.     Pengumpulan informasi

2.     Analisis informasi

3.     Perancangan solusi dan metoda yang dikembangkan

4.     Penerapan metoda yang dikembangkan

5.     Follow up

Proses secara teratur dibentuk oleh aliran informasi dari berbagai sumber. Dalam rangka untuk memperkirakan keberhasilan proses, umpan balik tertutup diterapkan untuk mengontrol arus informasi, untuk pelaksanaan perubahan hasil secara praktek dan prosedur bersama-sama dengan pengukuran hasil.

Sebuah gambaran skematik dari proses CAPA ditunjukkan pada Gambar 17.1. Setiap tahap akan dibahas secara  terpisah dalam bab ini.

17.4 Pengumpulan informasi

Berbagai sumber informasi, internal dan eksternal, yang melayani Proses CAPA adalah sangat luar biasa. Mengikuti dikotomi istilah internal / eksternal ,maka terdapat  empat informasi utama dari  sumber informasi internal :

1.     Proses pengembangan software

2.     Maintenance software

3.     Infratruktur SQA

4.     Prosedur manajemen kualitas software

Adapun sumber informasi dari eksternal, adalah:

1.     Komplain pelanggan

2.     Statistik pelayanan pelanggan (customer service)

3.     Kritik dan saran pelanggan

Klasifikasi ini berkaitan dengan CAPA, yang disajikan lebih rinci di kerangka berikut:

Proses pengembangan software

·         laporan manajemen risiko Software

·         laporan review Desain

·         Laporan Pemeriksaan

·         laporan Walkthrough

·         Laporan pendapat Ahli '

·         ulasan Uji Coba

·         Laporan khusus pada kegagalan pembangunan dan keberhasilan

·         Proposal disarankan oleh anggota staf.

Pemeliharaan Software

·         Aplikasi statistik Pelanggan

·         Permintaan perubahan Software diprakarsai oleh aplikasi pelanggan

·         Permintaan perubahan Software diprakarsai oleh staf pemeliharaan

·         Laporan khusus pada kegagalan pemeliharaan dan keberhasilan

·         Proposal disarankan oleh anggota staf.

Kelas infrastruktur SQA sumber

·         Laporan audit mutu internal

·         Laporan audit kualitas eksternal

·         Kinerja tindak lanjut dari staf yang terlatih dan bersertifikat

·         Proposal disarankan oleh anggota staf.

Perangkat Lunak kualitas prosedur manajemen kelas sumber

·         laporan kemajuan Proyek

·         metrik kualitas laporan Software

·         laporan biaya kualitas Software

·         Proposal anggota staf.

  

Klasifikasi alternatif sumber informasi (seperti yang ditunjukkan pada Gambar 17,1) membedakan antara proses pengembangan terkait dengan  produk serta  infrastruktur terkait (termasuk manajerial dan pemeliharaan) sumber informasi. Analisis akumulasi informasi seperti yang dilaporkan dalam berbagai dokumen merupakan subyek dari bagian berikutnya.

17.5 Analisis informasi yang terkumpul

Operasi rutin dari proses CAPA diharapkan dapat menciptakan aliran besar dokumen yang berkaitan dengan berbagai informasi.

Analisis meliputi:

Penyaringan Informasi dan mengidentifikasi perbaikan yang potensial.

Dokumen yang diterima dari berbagai sumber informasi dan telah dikaji oleh para profesional untuk mengidentifikasi peluang potensial CAPA. Tahap ini meliputi perbandingan dokumen dari jenis yang sama yang diterima dari berbagai unit serta perbandingan dokumen dari berbagai jenis terkait dengan kasus yang sama.

Analisis Pengembangan potensial.

 Upaya diarahkan untuk menentukan:

·         Jenis yang diharapkan dan tingkat kerusakan akibat kesalahan diidentifikasi.

·         Penyebab kesalahan. Penyebab khasnya adalah ketidakpatuhan terhadap pekerjaan instruksi dan prosedur, pengetahuan teknisyang tidak memadai, ekstrim waktu dan / atau tekanan anggaran karena perkiraan yang kurang realistis, dan kurangnya pengalaman dengan tool pengembangan baru.

·         Perkiraan tingkat kedalaman luasnya organisasi yang merupakan kesalahan potensial masing-masing Jenis. Informasi ini diperlukan untuk memperkirakan total kerusakan yang diharapkan dan untuk menentukan prioritas setiap kasus kesalahan.

Menyusun umpan balik tentang isi dan keteraturan informasi yang diterima dari sumber-sumber informasi yang ditunjuk.

Dua persyaratan yang berlawanan akan mempengaruhi respon pada tahap ini –analisis komprensif dari kumpulan informasi yang  saling bertentangan dengan kebutuhan untuk bereaksi dengan cepat untuk merespon suatu kesalahan. Resolusi konflik ini terletak pada organisasi dan metode.

Sebuah tim profesional yang ditugaskan untuk menangani informasi yang masuk tanpa delay harus dibuat segera. Tim ini akan menetapkan prioritas untuk menangani solusi kesalahan yang telah teridentifikasi, dimana untuk  kasus dengan prioritas rendah akan ditunda atau bahkan tidak dilakukan penanganan sama sekali.

17.6.1 Pengembangan solusi

Solusi untuk mengidentifikasi penyebab dari kesalahan sistem perangkat lunak yang berulang diperlukan untuk:

1.     Menghilangkan terulangnya jenis kesalahan yang telah terdeteksi

2.     Kontribusi peningkatan efisiensi dengan memungkinkan produktivitas yang lebih tinggi dan jadwal yang lebih singkat.

Beberapa petunjuk sebagai solusi yang biasanya dilakukan:

·         Memperbarui prosedur yang terkait. Perubahan bisa mengacu  kepada sekumpulan prosedur,dari segala sesuatu yang terkait dengan tahapan kerja yang spesifik dari pengembangan perangkat lunak atau pemeliharaannya (misalnya, perubahan gaya komentar software, perubahan prosedur review klausul kontrak yang berhubungan dengan proposal untuk proyek kecil) dengan prosedur yang bersifat umum (misalnya perubahan prosedur perekrutan karyawan, perubahan jumlah maksimum dan minimum peserta dalam ulasan desain formal).

·         Perubahan disini prakteknya, termasuk memperbarui instruksi kerja yang relevan (jika memang ada).

·         Beralih ke alat pengembangan yang lebih efektif dan tahan terhadap kesalahan yang sudah terdekteksi

·         Pengembangan dalam pelaporan, termasuk perubahan isi laporan, frekuensi laporan dan penyerahan laporan. Arahan ini bertujuan agar kesalahan dapat teridentifikasi lebih dini.

·         Pelaksanaan training, retraining dan pembaharuan staff. Arah ini diambil hanya dalam kasus-kasus ketika kekurangan pelatihan yang sama ditemukan di beberapa tim.

Perlu dicatat bahwa:

·         Dalam banyak kasus, solusi yang dianjurkan menggabungkan beberapa item tindakan,dari satu tindakan atau beberapa tindakan.

·         Mengubah dan memperbarui prosedur dan instruksi kerja perlu dibahas dan disetujui oleh badan yang ditugaskan untuk pengembangan dan pemeliharaan.

·         Kembali ke contoh kita, "3S" kasus disini menampilkan enam contoh CAPA:

·         Memperbarui prosedur yang ada (rekomendasi (1), (2), (3) dan (6))

·         Penggantian alat pengembangan yang mempunyai efisiensi rendah dan tidak efektif dengan alat yang lebih baik (rekomendasi  point(4))

·         Peningkatan dalam pengoperasian alat infrastruktur SQA (rekomendasi point (5)).

Untuk memperjelas titik yang dibuat, dua contoh berikut mungkin akan membantu.

Contoh A: Prosentase yang tinggi  dari beberapa defect yang parah

Analisis metrik kualitas perangkat lunak untuk Departemen Pengembangan dari "Peak Performance Software Ltd" mengidentifikasi proporsi yang tinggi dari besarnya perangkat lunak yang cacat dengan parah dalam proyek yang diselesaikan oleh dua tim dari enam tim. Disini ditemukan bahwa tuntutan sumber daya tim untuk memperbaiki cacat jauh lebih tinggi dibandingkan dengan tim lain.

Analisis ini didasarkan pada informasi terdokumentasi terkait dengan dua tim ini, saat ini para mantan tim proyek ', di samping proyek-proyek yang dilakukan oleh empat tim lainnya yang dianggap  "sehat". Temuan menunjukkan bahwa karakteristik umum untuk sebagian besar modul yang rusak adalah kehadiran algoritma dari kompleksitas sedang hingga kompleksitas tinggi. Pertanyaan yang berkaitan dengan tool SQA yang diterapkan oleh semua tim mengungkapkan perbedaan yang berarti dalam sejumlah aplikasi yang diperiksa, terutama dalam analisis dan tahap desain. Sementara itu tim "sehat" memperlakukan kegiatan inspeksi  sebagai prosedur standar yang lebih-atau-kurang tergantung kerumitan modul , sedangkan tim lain yang menggunakan kegiatan inspeksi lebih rendah. Solusi CAPA merekomendasikan  untuk memperkenalkan definisi jenis-jenis modul yang memerlukan pemeriksaan dalam inspeksi instruksi kerja.

Contoh kedua mengilustrasikan bagaimana proses CAPA dapat menghasilkan temuan dan rekomendasi yang tak terduga.

Contoh B: Kenaikan panggilan help desk yang membutuhkan layanan di tempat pelanggan

Sebuah perusahaan pemograman yang sempurna" secara teratur mengoperasikan dua tim help desk untuk mendukung pengguna dari dua produk perangkat lunak yang paling populer: Tim 1 mengkhususkan diri dalam titik penjualan (POS) paket, Tim 2 dalam paket akuntansi.

Manajemen Unit Help Desk merumuskan beberapa metrik kualitas yang baru untuk mendukung kontrol efektivitas dan efisiensi tim 'Metrik baru ini menekankan pengendalian dari beberapa pelayanan yang dilakukan di lokasi pelanggan, dikarenakan biaya tinggi pelayanan, dan terus melacak dari dua variabel (metrik), yaitu prosentase dari kunjungan pelanggan dan waktu rata-rata per kunjungan teknisi ke lokasi. Laporan metrik triwulan untuk kedua tim help desk ditunjukkan pada Tabel 17.1.

Laporan untuk kuartal keempat memicu sinyal peringatan kepada manajemen perusahaan. Sedangkan Tim 2 menunjukkan stabilitas dalam kinerjanya, di sisi lainnya sebuah perubahan yang berbahaya teredeteksi dalam kinerja Tim 1.

Pihak manajemen sangat prihatin dengan peningkatan yang berarti dari persentase kunjungan pelanggan di lokasi dan waktu rata-rata per kunjungan teknisi ke lokasi. Tim perbaikan dan pencegahan (tim CAPA) dipimpin oleh seorang anggota staf unit SQA yang ditunjuk. Tim CAPA mengadakan tiga pertemuan panjang yang ditujukan untuk mewawancarai pemimpin tim help desk, meninjau contoh laporan kunjungan pelanggan mereka ke lokasi dan memeriksa laporan rinci statistik bulanan. Tim juga mengamati tim “help desk” di tempat kerja selama satu sore.

Tim CAPA menemukan bahwa semenjak tahun sebelumnya terdapat salah satu operasi yang konservatif untuk Tim 2, menampilkan beberapa regresi dalam efisiensi mereka, dalam kurun satu tahun terdapat  perubahan besar dalam operasional dari Tim 1.Selama kuartal pertama dan kedua, tim telah menginvestasikan upaya yang berarti dalam perbaikan user interface dari paket POS dan menambahkan beberapa hal yang membantu pesan kesalahan. Selain itu, user manual yang telah direvisi diterbitkan. Semua perbaikan ini termasuk dalam Versi baru 6.4 yang menggantii Versi 6,3 dari paket POS yang telah melayani perusahaan selama 20 bulan terakhir. Versi 6.4 telah dipasang oleh sebagian besar pengguna selama kuartal ketiga.

Analisis statistik operasi bulanan mengungkapkan ternyata  laporan perkuartal yang digunakan saat ini adalah tidak benar. Tanpa diduga, masalah segera menjadi jelas dalam dua kuartal terakhir Tim 1 telah benar-benar mencapai pengurangan substansial dari  jumlah effort help desk, yang diukur dalam jam layanan help desk per pelanggan. Selain itu, penurunan dramatis dalam jumlah panggilan pengguna yang diamati, jelas sebagai akibat dari lebih user friendly dan lebih handalnya dari  versi baru paket aplikasi. Kenaikan rata-rata waktu yang dihabiskan pada pelanggan Kunjungan situs adalah karena persentase yang lebih tinggi dari layanan sekarang diberikan kepada pelanggan baru.

Tim CAPA berdasarkan kesimpulan hasil revisi, Laporan kuartalan yang diperpanjang, disajikan pada Tabel 17.2. Penerapan dari  revisi laporan help desk per triwulan untuk Tim 2 menunjukkan angka penurunan konstan dalam efisiensi dan efektivitas layanan HD tim.

Dua tindakan korektif yang diusulkan oleh tim CAPA:

(1) Untuk mengganti laporan kuartalan yang saat ini digunakan dengan yang lebih komprehensif, berdasarkan pada baris Tabel 17.2.

(2) Sebuah penyelidikan praktek dilaksanakan oleh Tim 2 disarankan untuk mencapai perbaikan substansial dalam kinerja tim.

17.6.2 Pelaksanaan proses CAPA

Implementasi solusi CAPA bergantung pada instruksi yang tepat dan seringnya pelatihan namun  paling banyak tergantung pada  kerjasama unit dan individu yang terkait.

Oleh karena itu, keberhasilan pelaksanaan mengharuskan anggota staff yang ditargetkan diyakinkan terhadap kelayakan solusi yang ditawarkan.

Tanpa kerjasama, kontribusi dari CAPA maka dapat menimbukan ketidak beresan.

17,7 Tindak Lanjut kegiatan

Tiga tugas pokok tindak lanjut diperlukan untuk memfungsikan korektif dan proses tindakan pencegahan dalam setiap organisasi:

1.     Tindak lanjut alur pengembangan dan pemeliharaan terhadap catatan CAPA . Hal ini memungkinkan umpan balik yang mengungkapkan kasus tidak adanya pelaporan serta pelaporan berkualitas rendah, yang mana terdapat rincian penting yang hilang atau tidak akurat. Jenis tindak lanjut dilakukan terutama melalui analisis informasi aktivitas jangka panjang, yang menghasilkan umpan balik kepada sumber-sumber informasi CAPA.

2.     Tindak lanjut penerapan CAPA. Kegiatan ini dimaksudkan untuk menunjukkan apa saja tindakan-tindakan yang dirancang berupa:

·         kegiatan pelatihan

·         penggantian dari tool-tool development

·         perubahan prosedur (setelah persetujuan)

semua telah dilaksanakan . Umpan balik yang memadai dikirimkan ke badan-badan yang bertanggung jawab untuk pelaksanaan tindakan perbaikan dan pencegahan.

3.     Tindak lanjut hasil CAPA. Tindak lanjut hasil yang nyata dari metode perbaikan ',seperti yang diamati oleh tim proyek dan unit organisasi, memungkinkan penilaian sejauh mana tindakan korektif atau preventif telah mencapai hasil yang diharapkan. Umpan balik terhadap hasil dikirimkan ke pengembang metode perbaikan '. Dalam kasus kinerja rendah, maka diperlukan formulasi dari tindakan korektif yang direvisi atau yang baru, ini merupakan tugas yang dilakukan oleh tim CAPA

Jelas, kegiatan tindak lanjut rutin  yang langsung memeriksa informasi yang masuk dan memulai alur yang memadai dari umpan balik adalah link penting dalam kegiatan-kegiatan berantai CAPA.

17,8 Pengorganisasian untuk tindakan preventif dan korektif

Kinerja yang tepat dari kegiatan ini CAPA tergantung pada keberadaan unit organisasi ini yang permanen serta tergantung dari banyaknya partisipasi  dari tim  ad hoc.

Organisasi inti ini, umumnya dikenal sebagai komite Dewan Corrective Action (CAB), meskipun mungkin memiliki judul lain dalam organisasi yang berbeda, Dewan mempromosikan penyebab CAPA dalam organisasi. Tugasnya meliputi:

®  Mengumpulkan informasi data CAPA dari berbagai sumber

®  Verifikasi data yang terkumpul

®  Menentukan anggota team Ad-hoc CAPA sesuai kebutuhan

®  Mempromosikan penerapan CAPA di setiap unit, departmen, project, dll

®  Menindaklanjuti informasi, progress, penerapan dan hasil CAPA

Metode CAPA.

Anggota unit SQA, profesional tingkat atas dan pembangunan dan manajer departemen pemeliharaan merupakan kandidat  alami untuk menjadi anggota dari komite CAB.

Sekelompok komplementer calon peserta, diambil dari reguler Staf, bergabung dengan upaya CAPA sebagai anggota tim ad hoc CAPA. Mereka secara teratur fokus pada:

■ Analisis informasi yang berkaitan dengan topik tim

■ Inisiasi dari pengamatan dan pertanyaan tambahan

■ Identifikasi penyebab kesalahan

■ Pengembangan dari solusi dan tindakan korektif -preventif yang relevan

■ Penyusunan revisi pelaksanaan yang diusulkan

■ Analisis hasil pelaksanaan CAPA dan revisi CAPA jika diperlukan.

Kebanyakan anggota tim ad hoc CAPA adalah anggota departemen, berpengalaman di dalam materi utama. Dalam kasus di mana pengetahuan lokal adalah tidak memadai,maka  para ahli internal atau eksternal kadang-kadang lainnya diminta untuk bergabung dengan tim.

Ringkasan

1)     Jelaskan perbedaan antara koreksi defect dengan tindakan korektif dan preventif .

·         Koreksi Cacat adalah aktivitas terbatas diarahkan solusi langsung dari cacat terdeteksi dalam sebuah proyek atau sistem perangkat lunak.

·         tindakan korektif dan preventif mempunyai lingkup yang lebih luas, tondakan ini dimaksudkan untuk memulai dan memandu kinerja dari aktivitas-aktivitas yang luas organisasi serta akan menghilangkan penyebab kesalahan yang diketahui atau yang berpotensi.

2)     Sebutkan jenis utama sumber internal untuk proses CAPA.

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

      i.        Proses pengembangan software

     ii.        Maintenance software

    iii.        Infratruktur SQA

    iv.        Prosedur manajemen kualitas software

3)     Susunan dan penjelasan pendekatan utama untuk pengenalan CAPA.

Lima pendekatan yang umum digunakan:

      i.        Pembaruan prosedur yang terkait

     ii.        Perubahan dalam pengerjaan, mencakup pembaruan instruksi kerja

    iii.        Beralih ke alat pengembangan yang lebih efektif dan tahan terhadap kesalahan yang sudah terdekteksi

    iv.        Pengembangan dalam pelaporan, termasuk perubahan isi laporan, frekuensi laporan dan penyerahan laporan. Arahan ini bertujuan agar kesalahan dapat teridentifikasi lebih dini.

     v.        Pelaksanaan training, retraining dan pembaharuan staff

4)     Jelaskan tugas-tugas tindak lanjut CAPA yang utama

Tiga tugas pokok tindak lanjut yang diperlukan untuk proses CAPA ysng sukses adalah:

®  Tindak lanjut alur pengembangan dan pemeliharaan terhadap catatan CAPA

®  Tindak lanjut penerapan CAPA

®  Tindak lanjut hasil CAPA

 (5) Daftar peserta dalam proses CAPA dan kontribusi mereka terhadap sukses implementasi.

Proses CAPA dilakukan oleh upaya bersama dari CAPA badan permanen bersama-sama dengan peserta tim ad hoc. Permanen CAPA tubuh, biasanya disebut CAB, mengaktifkan proses CAPA oleh informasi skrining, menunjuk anggota ditargetkan hoc CAPA tim ad, mempromosikan pelaksanaan dan mengikuti proses. Tugas hoc CAPA tim ad adalah untuk menganalisis informasi tentang diberikan topik selain untuk mengembangkan solusi dan proses CAPA. Para anggota tim diharapkan untuk menerapkan CAPA dan menggunakan CAB-memberikan bantuan, jika diperlukan.

Sebagian besar anggota tim ad hoc CAPA adalah anggota staf departemen berpengalaman dalam materi pelajaran

Terjemahan dari : 

Galin,  Daniel. 2004.  Software  Quality  Assurance  From  theory  to
implementation. England. Addison-Wesley.