Chapter 11 Assuring the quality of software maintenance components

Transkripsi

1 Chapter 11 Assuring the quality of software maintenance components Bagian utama dari siklus hidup perangkat lunak adalah periode operasional, biasanya berlangsung selama 5 sampai 10 tahun, meskipun beberapa kasus perangkat lunak ada yang beroperasi untuk 15 tahun dan tidak jarang yang lebih. Apa yang membuat suatu paket software mampu mencapai "usia tua" dengan kepuasan pengguna tetap terjaga, sementara paket lain, melayani hampir populasi yang sama, "mati muda"? Faktor utamanya adalah kualitas pemeliharaan Pendahuluan Tiga komponen pelayanan pemeliharaan berikut adalah semuanya penting untuk keberhasilan: pemeliharaan korektif - layanan dukungan pengguna dan koreksi perangkat lunak. pemeliharaan adaptive - menyesuaikan paket perangkat lunak atas perbedaan dalam persyaratan baru dari pelanggan, perubahan kondisi lingkungan dan sejenisnya. pemeliharaan peningkatan fungsi - menggabungkan (1) pemeliharaan perfektif terhadap fungsi baru ditambahkan ke perangkat lunak misalnya untuk meningkatkan kinerja, dengan (2) kegiatan pemeliharaan preventif untuk meningkatkan kehandalan dan infrastruktur sistem agar pemeliharaan di masa depan dapat dikerjakan lebih mudah dan lebih efisien. Dimasukkannya layanan dukungan pengguna ("customer support service") dalam pemeliharaan korektif mungkin perlu beberapa klarifikasi. Pengguna support service adalah suatu solusi dari semua kesulitan yang timbul ketika pengguna menggunakan sistem perangkat lunak. Jasa koreksi perangkat lunak biasanya terintegrasi dalam layanan ini. Kesulitan pengguna mungkin telah disebabkan oleh: Kegagalan kode (code failure atau software failure). Kegagalan dokumentasi dalam user manual, layar bantuan atau bentuk lain dokumentasi yang disiapkan untuk user. Dalam hal ini, layanan support dapat menyediakan petunjuk yang benar bagi pengguna (meskipun tidak ada koreksi dari dokumentasi perangkat lunak itu sendiri). Dokumentasi tidak lengkap, samar-samar atau tidak tepat. Kurangnya pengetahuan pengguna terhadap sistem perangkat lunak atau kesulitan user dalam menggunakan dokumentasi yang disediakan. Dalam situasi ini tidak ada kegagalan sistem perangkat lunak yang dihadapi. Selain itu, penggabungan customer support service dan layanan koreksi perangkat lunak umumnya dicapai dalam kerjasama yang erat, dengan banyak berbagi informasi. Komponen lain dari layanan pemeliharaan - fungsi perbaikan dan pemeliharaan adaptif - cenderung tidak akan diprakarsai oleh pengguna layanan support. Dalam kebanyakan kasus, peningkatan fungsi dan tugas adaptif menampilkan karakteristik dari sebuah proyek kecil atau besar, tergantung pada kebutuhan pelanggan. Mengingat hal di atas, adalah wajar untuk menyertakan customer support service antara kegiatan pemeliharaan korektif. Seperti disebutkan dalam bab-bab sebelumnya, kombinasi dari tiga komponen pemeliharaan perangkat lunak mengkonsumsi lebih dari 60% dari desain total dan sumber daya pemrograman yang diinvestasikan dalam sebuah sistem perangkat lunak sepanjang siklus hidupnya (Pressman, 2000). Sementara yang lain memperkirakan bahwa sumber daya untuk

2 pemeliharaan berkisar dari lebih dari 50% (Lientz dan Swanson, 1980) menjadi sekitar 65-75% (McKee, 1984) dari total sumber daya pengembangan proyek. Distribusi sumber daya pemeliharaan untuk berbagai tipe layanan pemeliharaan diperkirakan sebagai berikut: Lientz and Oskarsson and Maintenance service Swanson (1980) Glass (1996) Corrective maintenance 22% 17% Adaptive maintenance 24% 23% Functionality improvement maintenance 54% 60% Bingkai 11,1 Kegiatan pemeliharaan Software QA: tujuan 1. Menjamin, dengan tingkat kepercayaan yang diterima, bahwa kegiatan pemeliharaan perangkat lunak adalah sesuai dengan persyaratan teknis fungsional. 2. Menjamin, dengan tingkat kepercayaan yang diterima, bahwa kegiatan pemeliharaan perangkat lunak sesuai dengan penjadwalan manajerial dan persyaratan anggaran. 3. Memulai dan mengelola kegiatan untuk memperbaiki dan meningkatkan efisiensi pemeliharaan perangkat lunak dan kegiatan SQA Landasan dari berkualitas tinggi Tak usah dikatakan bahwa kualitas paket perangkat lunak adalah suatu hal yang harus dipertahankan. Hal ini mungkin merupakan dasar yang paling penting yang mendasari kualitas layanan pemeliharaan. Landasan lain yang penting adalah kebijakan pemeliharaan Landasan 1: kualitas paket perangkat lunak Kualitas dari paket perangkat lunak yang harus dipertahankan jelas berasal dari keahlian dan usaha dari tim pengembangan serta kegiatan SQA yang dilakukan selama proses pembangunan. Jika kualitas paket yang rendah, pemeliharaan akan menjadi kurang atau tidak efektif. Berikut adalah 7 dari 11 faktor asli jaminan kualitas (lihat Bab 3) yang memiliki dampak langsung pada pemeliharaan perangkat lunak. Secara khusus, kita akan membahas dua dari lima faktor produk operasi, semua faktor produk revisi dan dua dari tiga faktor produk transisi. Faktor-faktor tersebut adalah sebagai berikut. (1) Kebenaran (correctness) - meliputi: Kebenaran output: Kelengkapan dari output yang ditentukan (dengan kata lain, tidak ada output yang telah ditentukan yang hilang), akurasi output (output semua sistem diproses dengan benar), up-to-datedness dari output (informasi diproses up to date seperti yang ditentukan) dan ketersediaan output (waktu reaksi tidak melebihi nilai maksimum yang ditentukan, terutama dalam aplikasi online dan real-time).

3 Kebenaran dokumentasi. Kualitas dokumentasi: kelengkapan, akurasi, gaya dan struktur dokumentasi. Dokumentasi meliputi format hard copy dan file komputer - manual tercetak serta elektronik "help" file - bahwa ruang lingkupnya meliputi instalasi manual, buku petunjuk dan manual programmer. Kualifikasi coding. Kepatuhan dengan instruksi pengkodean, terutama yang membatasi dan mengurangi kompleksitas kode dan menentukan gaya pengkodean standar. (2) Keandalan. Frekuensi kegagalan sistem serta waktu pemulihan. Tiga faktor produk revisi adalah sebagai berikut. (1) Maintainability. Persyaratan ini dipenuhi pertama dan terutama dengan mengikuti struktur perangkat lunak dan persyaratan gaya dan dengan menerapkan persyaratan dokumentasi programmer. (2) Fleksibilitas. Dicapai dengan perencanaan dan desain yang tepat, fitur yang menyediakan ruang aplikasi yang lebih luas dari yang diperlukan untuk populasi pengguna saat ini. Dalam prakteknya, ini berarti ruang yang tersisa untuk perbaikan fungsional di masa depan. (3) Testability. Testability termasuk ketersediaan diagnostik sistem yang akan diterapkan oleh pengguna serta diagnosa kegagalan untuk diterapkan oleh support center atau maintenance staff di sisi pengguna Terakhir, dua faktor transisi produk adalah sebagai berikut. (1) Portabilitas. Perangkat lunak berpotensi diaplikasikan pada hardware dan lingkungan sistem operasi yang berbeda. (2) Interoperabilitas. Kapasitas paket untuk dapat berkomunikasi dengan paket dan peralatan komputerisasi lainnya. Interoperabilitas yang tinggi dapat dicapai dengan menyediakan kapasitas untuk memenuhi standar antarmuka yang sudah dikenal dan mempunyai interface yang dapat diterapkan oleh produsen equipment dan perangkat lunak terkemuka.

4 Landasan 2: kebijakan pemeliharaan (policy) Komponen utama kebijakan pemeliharaan yang mempengaruhi keberhasilan pemeliharaan perangkat lunak adalah kebijakan pengembangan versi dan perubahan yang akan diterapkan selama siklus hidup perangkat lunak. Kebijakan pengembangan versi Kebijakan ini terutama berkaitan dengan pertanyaan tentang berapa banyak versi perangkat lunak harus operasi secara bersamaan. Meskipun jelas bahwa ini bukan masalah untuk custom-made software yang melayani satu organisasi, jumlah versi menjadi masalah besar untuk paket perangkat lunak COTS yang direncanakan untuk melayani berbagai macam pelanggan. kebijakan Pengembangan Versi untuk yang kedua dapat mengambil "secara berurutan" atau "berbentuk pohon". Ketika mengadopsi kebijakan versi berurutan, hanya satu versi yang tersedia untuk seluruh pelanggan. Versi ini mencakup profesi aplikasi yang menunjukkan redundansi tinggi, atribut yang memungkinkan perangkat lunak untuk melayani kebutuhan semua pelanggan. Perangkat lunak ini harus direvisi secara berkala tetapi sekali versi baru selesai, itu menggantikan versi saat ini digunakan oleh seluruh user. Ketika mengadopsi kebijakan versi pohon, tim pemeliharaan perangkat lunak mendukung upaya pemasaran dengan mengembangkan versi khusus dan ditargetkan untuk kelompok pelanggan atau pelanggan umum setelah diminta. Sebuah versi baru diresmikan dengan menambahkan aplikasi khusus atau menghilangkan suatu aplikasi, tergantung pada apa yang relevan dengan kebutuhan pelanggan. Jika kebijakan ini diadopsi, paket perangkat lunak dapat berkembang menjadi sebuah paket multi-versi setelah beberapa tahun pelayanan, sehingga akan menyerupai pohon, dengan cabang utama dan beberapa cabang sekunder banyak, setiap cabang mewakili sebuah versi dengan revisi khusus. Berbeda dengan versi perangkat lunak sekuensial, bahwa pemeliharaan dan manajemen perangkat lunak versi pohon jauh lebih sulit dan memakan waktu. Untuk alasan efisiensi, organisasi-organisasi pembangunan perangkat lunak mencoba menerapkan kebijakan pohon versi terbatas, yang memungkinkan hanya sejumlah kecil dari versi perangkat lunak yang akan dikembangkan. Pengalaman sehari-hari dari tim pemeliharaan adalah termasuk mengatasi kesulitan yang diciptakan oleh struktur versi dari paket yang berkaitan dengan perangkat lunak itu sendiri: Proses koreksi gagal yang disebabkan oleh identifikasi tidak tepat struktur modul dari versi digunakan oleh pelanggan yang spesifik saat ini. Proses koreksi gagal yang disebabkan oleh penggantian salah dari modul rusak oleh modul versi lain yang kemudian terbukti tidak cocok untuk integrasi ke versi paket yang digunakan pelanggan. Berupaya untuk meyakinkan pelanggan untuk meng-update paket perangkat lunak mereka dengan menambahkan modul baru atau mengganti modul versi saat ini dengan versi baru. Setelah pelanggan setuju untuk mengupdate perangkat lunak mereka, ternyata muncul

5 masalah dan kegagalan yang timbul ketika mencoba untuk mengintegrasikan modul yang baru dikembangkan atau untuk mengganti dengan versi lanjutan dari modul yang dipakai saat ini. Kebijakan Perubahan (change policy) Kebijakan perubahan mengacu pada metode untuk memeriksa setiap permintaan perubahan dan kriteria yang digunakan untuk mendapatkan persetujuan. Sudah jelas bahwa kebijakan permisif, apakah dilaksanakan oleh CCB (the Change Control Board) Dewan Pengendalian Perubahan) atau badan lainnya yang berwenang untuk menyetujui perubahan memberikan kontribusi untuk peningkatan yang sering dibenarkan dalam beban tugas perubahan. Sebuah kebijakan yang seimbang, yang membutuhkan pemeriksaan menyeluruh dari permintaan perubahan, adalah lebih disukai karena memungkinkan staf untuk fokus pada perubahan yang paling penting dan menguntungkan, serta mereka mampu melakukannya dalam waktu yang wajar dan sesuai dengan standar kualitas diperlukan Komponen kualitas pra-pemeliharaan perangkat lunak Kegiatan pra-pemeliharaan SQA akan selesai sebelum memulai layanan pemeliharaan yang diperlukan adalah sangat penting. Termasuk didalamnya: Ulasan (review) kontrak pemeliharaan Konstruksi rencana pemeliharaan Ulasan (review) kontrak pemeliharaan Ketika mempertimbangkan kontrak pemeliharaan, perspektif yang luas harus diutamakan. Yang paling penting, kontrak pemeliharaan menghasilkan keputusan yang diperlukan tentang kategori jasa yang akan dikontrak. Keputusan ini tergantung pada jenis pelanggan yang dilayani: pelanggan khusus, pelanggan yang membeli paket perangkat lunak COTS, dan pelanggan internal Jadi, sebelum memulai untuk menyediakan layanan pemeliharaan perangkat lunak untuk salah satu pelanggan, kontrak pemeliharaan yang memadai harus diselesaikan yang menetapkan bawah seluruh cakupan kewajiban pemeliharaan sesuai dengan kondisi yang relevan. Kegiatan meninjau kontrak pemeliharaan meliputi review rancangan usulan serta review draft kontrak. Tentu, tinjauan atas tujuan dan pelaksanaan kontrak pemeliharaan mengikuti garis ulasan pra-proyek kontrak (lihat Bab 5). Daftar tujuan utama tinjauan kontrak pemeliharaan perangkat lunak adalah. (1) Klarifikasi Persyaratan pelanggan Isu-isu berikut perlu mendapatkan perhatian khusus:

6 Jenis layanan pemeliharaan korektif yang diperlukan: daftar layanan remote dan layanan di tempat yang akan diberikan, jam pelayanan, waktu respon, dll Ukuran populasi pengguna dan jenis aplikasi yang akan digunakan. Lokasi dari pengguna, terutama lokasi jarak jauh (atau luar negeri) dan jenis aplikasi yang terinstal di masing-masing. Pemeliharaan Adaptive dan perbaikan fungsi yang harus disediakan dan prosedur pengajuan permintaan pelayanan serta mengusulkan dan menyetujui kinerja layanan ini. (2) Tinjauan pendekatan alternatif untuk penyediaan pemeliharaan Pilihan berikut pantas mendapat pertimbangan khusus: Subkontrak untuk lokasi atau jenis layanan Kinerja beberapa layanan yang dilakukan oleh pelanggan sendiri dengan dukungan dari tim pemeliharaan supplier. (3) Review estimasi sumber daya pemeliharaan yang diperlukan Pertama, perkiraan ini harus diperiksa berdasarkan layanan pemeliharaan yang diperlukan, diklarifikasi oleh tim usulan. Kemudian, kapasitas perusahaan harus dianalisis untuk memenuhi komitmennya terhadap kompetensi profesional serta ketersediaan tim pemeliharaan. (4) Review jasa pemeliharaan yang akan diberikan oleh subkontraktor dan / atau pelanggan Review ini mengacu pada definisi layanan yang diberikan oleh setiap peserta, pembayaran kepada subkontraktor, jaminan kualitas dan tindak lanjut prosedur yang harus diterapkan. (5) Review perkiraan biaya pemeliharaan Perkiraan ini harus ditinjau berdasarkan sumber daya yang diperlukan Rencana Pemeliharaan Rencana pemeliharaan harus disiapkan untuk semua pelanggan, baik eksternal maupun internal. Rencana ini harus menyediakan kerangka kerja yang mencakup ketentuan pemeliharaan yang terorganisir. Oleh karena itu, seperti yang diharapkan, rencana pemeliharaan dan pengembangan (lihat Bab 6) didasarkan pada konsep serupa. Rencana tersebut meliputi sebagai berikut: (1) Sebuah daftar dari layanan pemeliharaan yang dikontrak Para pelanggan internal dan eksternal, jumlah pengguna, lokasi dari masing-masing pelanggan.

7 Karakteristik layanan pemeliharaan korektif (terpencil dan di situs). Kewajiban untuk penyediaan layanan adaptif dan pemeliharaan peningkatkatan fungsional untuk setiap pelanggan. (2) Uraian tentang organisasi tim pemeliharaan Rencana Organisasi Tim pemeliharaan berfokus pada kebutuhan tenaga kerja, yang harus dipertimbangkan dengan cermat sesuai dengan kriteria ini: Jumlah anggota tim yang dibutuhkan. Jika layanan yang harus disediakan dari beberapa fasilitas, maka diperlukan tim untuk setiap fasilitas. Kualifikasi yang diperlukan untuk anggota tim sesuai dengan tugas-tugas pemeliharaan, termasuk pemahaman terhadap paket perangkat lunak yang akan dimaintenance. Struktur organisasi tim pemeliharaan, termasuk nama-nama pemimpin tim. Definisi tugas (tanggung jawab untuk pelanggan, jenis aplikasi, dll) untuk setiap tim. Kebutuhan akan pelatihan. (3) Daftar fasilitas pemeliharaan Pemeliharaan Fasilitas adalah infrastruktur yang memungkinkan untuk memberikan layanan yang meliputi: pusat Dukungan pemeliharaan (maintenance support center) dengan hardware dan peralatan komunikasi yang sudah terinstal untuk memberikan dukungan terhadap user dan layanan koreksi terhadap perangkat lunak. Sebuah pusat dokumentasi yang berisi satu set lengkap dokumen (dalam format cetak atau elektronik): - Dokumentasi perangkat lunak, termasuk dokumentasi pengembangan - Kontrak layanan - Konfigurasi perangkat lunak untuk setiap pelanggan dan versi dari paket perangkat lunak yang diinstal di setiap tempat, disediakan oleh manajemen konfigurasi - Catatan-catatan sejarah perawatan untuk setiap pengguna dan pelanggan. (4) Daftar risiko layanan pemeliharaan yang telah diidentifikasi layanan risiko Pemeliharaan berkaitan dengan situasi di mana kegagalan untuk memberikan perawatan yang memadai dapat diantisipasi. Resiko-resiko ini termasuk: kekurangan Staf, apakah layanan pemeliharaan pada seluruh organisasi, di sebuah pusat dukungan perawatan tertentu atau pada suatu aplikasi tertentu. Kualifikasi atau tingkat pemahaman yang tidak memadai dengan sebagian dari paket perangkat lunak untuk melakukan dukungan layanan kepadan pengguna dan / atau tugas pemeliharaan korektif. anggota tim kurang memenuhi syarat untuk melakukan perbaikan fungsional serta tugas-tugas adaptif.

8 (5) Daftar prosedur pemeliharaan dan kegiatan kontrol perangkat lunak yang diperlukan Sebagian besar prosedur yang diperlukan mengacu pada proses yang dilaksanakan oleh tim pemeliharaan korektif dan oleh pusat dukungan pengguna. Prosedur ini biasanya berhubungan dengan: Penanganan aplikasi pelanggan Penanganan laporan kegagalan perangkat lunak pelaporan periodik dan tindak lanjut dari layanan dukungan untuk pengguna pelaporan periodik dan tindak lanjut layanan pemeliharaan korektif Pelatihan dan sertifikasi anggota tim pemeliharaan. Untuk lebih lanjut tentang prosedur kualitas perangkat lunak, lihat Bab 14. (6) Anggaran pemeliharaan perangkat lunak Perkiraan anggaran yang digunakan dalam pemeliharaan korektif didasarkan pada rencana tenaga kerja suatu organisasi, fasilitas yang dibutuhkan dan investasi yang dibutuhkan untuk membangun fasilitas ini, kebutuhan tim pelatihan dan tugas-tugas lainnya. Hal-hal tersebut dapat disiapkan jika tenaga kerja, fasilitas dan prosedur telah ditetapkan. Perkiraan untuk pemeliharaan adaptif dan tugas-tugas perbaikan fungsi disiapkan disesuaikan dengan beban kerja yang disebabkan oleh perubahan dan perbaikan yang dilakukan alat jaminan kualitas Pemeliharaan perangkat lunak Berbagai alat jaminan kualitas perangkat lunak yang bagus digunakan selama periode operasional dari siklus hidup perangkat lunak. Sifat spesifik dari setiap komponen pemeliharaan perangkat lunak - pemeliharaan perbaikan, pemeliharaan adaptif, dan pemeliharaan perbaikan fungsi memerlukan alat SQA yang berbeda untuk digunakan untuk masing-masing jenis maintenance. Selanjutnya, periode operasional dari perangkat lunak biasanya membuat penggunaan intensif dari alat-alat infrastruktur SQA dan alat kontrol manajerial lebih mungkin. Beberapa indikasi dari tingkat sumber daya yang diinvestasikan dalam SQA selama pemeliharaan telah disiapkan oleh Perry (1995). Dalam sebuah survei yang dilakukan pada bulan November 1994, para peserta melaporkan bahwa berdasarkan pengalaman mereka, 31% dari jadwal pemeliharaan mereka didedikasikan untuk jaminan kualitas (ulasan dan tugas pengujian) Tool SQA untuk pemeliharaan korektif Kegiatan pemeliharaan korektif memerlukan terutama (a) layanan dukungan user dan koreksi perangkat lunak (b) layanan perbaikan bug. Layanan dukungan pengguna menangani kasus tentang kode perangkat lunak dan kegagalan dokumentasi, dokumentasi tidak lengkap atau samar; atau mungkin juga melibatkan instruksi dari pengguna yang tidak memiliki pengetahuan cukup dari perangkat lunak atau kegagalan dalam penggunaan dokumentasi yang tersedia.

9 Layanan koreksi software - perbaikan bug dan koreksi dokumentasi - diperlukan dalam kasus kegagalan perangkat lunak, dan biasanya diberikan selama periode awal operasional (meskipun sudah dilaksanakan dalam pengujian) dan akan terus diperlukan, meskipun relatif agak jarang. Tugas perbaikan terhadap bug kebanyakan memerlukan penggunaan sebagian kecil siklus hidup SQA, terutama pengujian mini (mini-testing). prosedur pengujian mini diperlukan untuk menangani patch perbaikan (skala kecil), ditandai oleh sejumlah kecil perubahan baris coding bersama-sama dengan tekanan yang kuat untuk menyelesaikan koreksi dengan cepat. Dalam rangka untuk menjamin kualitas "mini-testing", pedoman ini harus dipatuhi: Pengujian harus dilakukan oleh tester yang berkualitas, bukan oleh programmer yang melakukan perbaikan. Sebuah prosedur pengujian dokumen harus disiapkan. Termasuk dalam dokumen ini adalah deskripsi antisipasi dari efek perbaikan, ruang lingkup koreksi dan daftar kasus uji yang akan dilakukan. Sebuah prosedur pengujian ulang terhadap dokumen, mirip dengan prosedur pengujian dokumen, harus juga disiapkan untuk menangani pengujian dari perbaikan kesalahan dalam tes yang terdeteksi sebelumnya. Sebuah laporan pengujian yang mendokumentasikan seluruh kesalahan yang terdeteksi dalam setiap tahap pengujian dan pengujian ulang harus diselesaikan. Tugas Kepala tim pengujian adalah meninjau dokumentasi pengujian, kecukupan kasus uji dan hasil pengujian. Kepala tim bertanggung jawab atas persetujuan dari perangkat lunak yang diperbaiki untuk operasional (terkadang disebut "produksi"). Untuk perbaikan yang dianggap "sederhana dan sepele" dan dilakukan di lokasi pelanggan, maka proses pengujian mini dapat dihindari. Jasa pemeliharaan subkontrak (outsourcing), khususnya pengguna layanan dukungan, telah menjadi sangat umum jika terlalu merepotkan atau tidak ekonomis jika kontrak pemeliharaan dilakukan secara langsung. Tools SQA yang terintegrasi ke dalam kontrak, fokus pada: Prosedur untuk menangani kisaran tertentu atas panggilan pemeliharaan. Dokumentasi lengkap tentang prosedur pelayanan. Ketersediaan catatan yang mendokumentasikan sertifikasi profesional dari anggota tim subkontraktor pemeliharaan, untuk review kontrak. Hak kontraktor untuk melaksanakan kajian periodik dari layanan pemeliharaan serta survei kepuasan pelanggan. Kondisi terkait kualitas yang membutuhkan diterapkannya denda dan pemutusan kontrak subkontrak jika terjadi kasus yang ekstrim.

10 Alat SQA untuk pemeliharaan fungsi perbaikan Karena kesamaan tugas pemeliharaan fungsi perbaikan untuk tugas-tugas proyek pengembangan perangkat lunak, alat siklus hidup proyek (review dan pengujian) secara teratur diterapkan untuk pemeliharaan fungsi perbaikan. Alat-alat yang sama juga diterapkan secara teratur untuk tugas pemeliharaan adaptif skala besar di mana, sekali lagi, karakteristiknya mirip dengan tugas-tugas pemeliharaan peningkatan fungsionalitas komponen infrastruktur SQA untuk pemeliharaan perangkat lunak Kontribusi alat infrastruktur SQA untuk pemeliharaan tidak dimulai dengan terjadinya proses pemeliharaan. Jelas, sebuah aplikasi yang memadai dari alat infrastruktur SQA memberikan kontribusi besar terhadap efisiensi dan efektivitas kegiatan tim pemeliharaan. Dengan kata lain, alat ini memberikan kontribusi untuk jaminan pemeliharaan kualitas dalam dua cara: pertama, dengan mendukung tim pengembangan perangkat lunak ketika memproduksi perangkat lunak berkualitas tinggi, dan kedua, dengan mendukung pemeliharaan yang bertanggung jawab atas pemeliharaan produk perangkat lunak yang sama. Tools khusus infrastruktur SQA yang diperlukan untuk proses perawatan perangkat lunak, terutama perawatan korektif, mempunyai karakteristik khusus. Infrastruktur khusus alat SQA adalah: prosedur pemeliharaan dan instruksi kerja perangkat pendukung berkualitas Pelatihan dan sertifikasi tim pemeliharaan tindakan Pencegahan dan korektif manajemen Konfigurasi Dokumentasi dan kontrol rekaman kualitas. Pemeliharaan prosedur dan instruksi kerja Prosedur perawatan yang paling khusus dan instruksi kerja yang diterapkan untuk pemeliharaan korektif dan kegiatan dukungan pengguna, misalnya: Penanganan permintaan secara remote untuk layanan dalam kasus kegagalan perangkat lunak penanganan permintaan pelanggan On-situs untuk layanan dalam kasus kegagalan perangkat lunak layanan dukungan Pengguna kontrol jaminan kualitas terhadap koreksi perangkat lunak dan kegiatan dukungan pengguna

11 Survei Kepuasan pelanggan Sertifikasi anggota tim pemeliharaan korektif dan dukungan pengguna. Mendukung kualitas perangkat Departemen pemeliharaan diharapkan dapat mengembangkan perangkat khusus untuk mendukung koreksi perangkat lunak dan dukungan aktivitas pengguna: template, daftar dan sejenisnya. Perangkat tersebut dapat mencakup: Daftar lokasi penyebab kegagalan - untuk diterapkan oleh teknisi pemeliharaan. Template untuk laporan bagaimana kegagalan perangkat lunak diselesaikan, termasuk temuan dari proses koreksi. Daftar untuk mempersiapkan dokumen prosedur pengujian mini. Pelatihan dan sertifikasi tim pemeliharaan Pelatihan tim pemeliharaan yang berhubungan dengan tugas-tugas perbaikan fungsional tidak berbeda secara substansial dengan pelatihan tim pengembangan perangkat lunak lainnya. Namun, pelatihan khusus dan sertifikasi sangat penting untuk tim pemeliharaan koreksi. Sumber: Software Quality Assurance From Theory To Implementation By Daniel Galin Terjemahan: Dadang Latif, M.Kom