Management and Its Role in SQA

The quality assurance organizational framework 

Managers:

- Eksekutif Top manajemen, terutama eksekutif yang bertanggung jawab dari SQA 

- Pengembangan perangkat lunak dan manajer pemeliharaan departemen 

- Software pengujian manajer departemen 

- Proyek manajer dan pemimpin tim proyek pembangunan dan pemeliharaan 

- Para pemimpin tim pengujian perangkat lunak 

Tester: 

- Anggota tim pengujian perangkat lunak

SQA professionals and interested practitioners:

- SQA trustees

- SQA committee members

- SQA forum members 

- SQA unit team members

Top management's overall responsibilities for software quality

• Menjamin kualitas produk perangkat lunak perusahaan dan layanan pemeliharaan perangkat lunak.
• Mengkomunikasikan pentingnya kualitas produk dan layanan selain kepuasan pelanggan kepada karyawan. 
• Memastikan penuh sesuai dengan kebutuhan pelanggan. 
• Pastikan bahwa  tujuan  SQA ditetapkan dan dicapai. 
• Memulai perencanaan dan mengawasi pelaksanaan perubahan untuk mengadaptasi sistem SQA perubahan terkait dengan, persaingan klien organisasi dan teknologi. 
• Campur tangan langsung untuk mengatasi situasi krisis dan meminimalkan kerusakan. 
• Memastikan ketersediaan sumber daya yang dibutuhkan oleh sistem SQA.

Software quality policy requirements

Kesesuaian dengan tujuan organisasi dan komitmen tujuan untuk : 

- Konsep jaminan kualitas Software umum 

- Standar mutu yang diadopsi oleh organisasi 

- Mengalokasikan sumber daya yang memadai untuk jaminan kualitas perangkat lunak 

- Berkelanjutan peningkatan kualitas organisasi dan produktivitas

The responsibilities of the executive in charge of software quality 

• Tanggung jawab untuk penyusunan program kegiatan tahunan dan anggaran SQA 
• Tanggung jawab untuk persiapan pengembangan sistem SQA berencana 
• Kontrol keseluruhan pelaksanaan program rutin tahunan SQA aktivitas SQA dan direncanakan proyek pembangunan 
• Penyajian dan advokasi masalah SQA kepada manajemen eksekutif

Typical items contained in management review reports 

Manajemen review adalah nama yang diberikan untuk pertemuan berkala yang diselenggarakan untuk memungkinkan eksekutif untuk mendapatkan gambaran masalah kualitas organisasi mereka perangkat lunak.

- Laporan kinerja secara berkala, termasuk metrik kualitas 

- Feedback kepuasan pelanggan 

- Menindaklanjuti laporan untuk program kegiatan SQA rutin tahunan dan pengembangan proyek SQA

- Ringkasan peristiwa kualitas khusus yang berkaitan dengan pelanggan, pemasok, subkontraktor, dll

- Tinjauan hasil signifikan dari audit mutu internal dan eksternal serta survei khusus 

- Identifikasi risiko kualitas perangkat lunak baru dan belum terpecahkan sudah ada risiko 

- Rekomendasi untuk perbaikan manajemen kualitas perangkat lunak.

The objectives of management reviews 

• Menilai pencapaian sasaran mutu ditetapkan untuk manajemen sistem kualitas perangkat lunak organisasi
• Lakukan update dan perbaikan sistem kualitas perangkat lunak manajemen dan tujuannya 
• Menguraikan petunjuk untuk menanggulangi kekurangan utama SQA dan masalah kualitas perangkat lunak manajemen
• Mengalokasikan sumber daya tambahan untuk sistem kualitas perangkat lunak manajemen.

Department management responsibilities for quality assurance

The quality system-related responsibilities:

• Penyusunan program tahunan departemen aktivitas SQA dan anggaran, berdasarkan program unit SQA yang direkomendasikan.
• Persiapan departemen rencana pengembangan sistem SQA, berdasarkan rencana Unit SQA yang direkomendasikan.
• Pengendalian kinerja tahunan program departemen aktivitas SQA dan proyek pembangunan 
• Penyajian masalah departemen SQA untuk eksekutif yang bertanggung jawab kualitas perangkat lunak.

Project-related responsibilities:

• Pengendalian kepatuhan terhadap prosedur jaminan kualitas dalam unit departemen, termasuk CAB, SCM dan tubuh SCCA 
• Rinci tindak lanjut dari hasil tinjauan kontrak dan persetujuan usulan 
• Review kinerja unit kegiatan review direncanakan; persetujuan dokumen proyek dan penyelesaian proyek tahap 
• Tindak lanjut dari tes perangkat lunak; persetujuan produk perangkat lunak proyek. 
• Tindak lanjut dari kemajuan jadwal proyek pengembangan perangkat lunak dan penyimpangan anggaran. 
• Menganjurkan dan mendukung mangers proyek dalam menyelesaikan kesulitan. 
• Tindak lanjut dari kualitas layanan pemeliharaan 
• Rinci tindak lanjut dari risiko proyek dan solusi mereka 
• Tindak lanjut dari kepatuhan proyek dengan persyaratan pelanggan dan kepuasan pelanggan. Persetujuan perintah perubahan software besar dan penyimpangan yang signifikan dari spesifikasi proyek.

Project management responsibilities for quality assurance 

Professional hands-on tasks:

- Penyusunan rencana proyek dan kualitas dan update mereka. 

- Partisipasi dalam bersama pelanggan-pemasok komite Tutup tindak lanjut dari staf tim proyek, termasuk perekrutan, pelatihan dan pengajaran.

Standards, Certification and Assessment

Quality Management Standards

Berikut merupakan materi terkait tentang Quality Management Standards :

Quality management standards

View more presentations from PujiAgustin.

Bagaimana menghitung FP?

Salah satu cara yang populer untuk melakukan pengukuran perangkat lunak dapat mengunakan cara yang bernama FUNCTION POINT. Hasil dari metode Function Point akan lebih mudah dipahami oleh pengguna non teknis yang dapat membantu mengkomunikasikan informasi ukuran software ke pengguna atau client.

Berikut tahapan melakukan perhitungan Function Pont (FP) :

Tahap 1. Menghitung Crude Function Points (CFP)

Crude Function Points (CFP) adalah untuk menghitung bobot nilai dari komponen-komponen Function Point yang dikaitkan dengan software yang akan dibuat.

Komponen-komponen Function Point terdiri dari 5 buah yaitu sebagai berikut :

• Tipe Input, Berkaitan dengan interface yang lakukan pengguna/user dalam memasukan data pada aplikasi.
• Tipe Output, Berkaitan dengan output yang dihasilkan aplikasi untuk pengguna/user yang dapat berupa laporan di print atau yang ditampilkan pada layar.
• Tipe Query/Search/View, Berkaitan dengan query terhadap data yang tersimpan.
• Tipe File/Tabel/Database, berkaitan dengan logic penyimpan data yang dapat berupa file atau semacam database relational.
• Tipe Interface Eksternal, Berkaitan dengan komunikasi data pada parangkat/mesin yang lain, contoh nya adalah membuat aplikasi SMS Server yang membutuhkan. koneksi pada perangkat keras Modem telepon.

Selanjutnya setiap tipe komponen tersebut diberikan bobot berdasarkan kompleksitasnya, seperti yang ditujukan pada table dibawah ini.

* Nilai-nilai Bobot dari setiap komponen diatas adalah ketetapan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG).

Tahap 2. Menghitung Relative Complexity Adjustment Factor (RCAF)

RCAF digunakan untuk menghitung bobot kompleksitas dari software berdasarkan 14 karakteristik.

Penilaian Komplesitas memilik skala 0 s/d 5

• 0 = Tidak Pengaruh
• 1 = Insidental
• 2 = Moderat
• 3 = Rata-rata
• 4 = Signifikan
• 5 = Essential

Berikut ini adalah 14 Karakteritik Software :

NO	KARAKTERISTIK	BOBOT
1.	Tingkat kompleksitas Komunikasi Data	[0/1/2/3/4/5]
2.	Tingkat kompleksitas Pemrosesan Terdistribusi	[0/1/2/3/4/5]
3.	Tingkat kompleksitas Performance	[0/1/2/3/4/5]
4.	Tingkat kompleksitas Konfigurasi	[0/1/2/3/4/5]
5.	Tingkat Frekuensi Penggunaan Software	[0/1/2/3/4/5]
6.	Tingkat Frekuensii Input Data	[0/1/2/3/4/5]
7.	Tingkat Kemudaaan Pengunaan Bagi User	[0/1/2/3/4/5]
8.	Tingkat Frekuensi Update Data	[0/1/2/3/4/5]
9.	Tingkat Kompleksitas Prosesing Data	[0/1/2/3/4/5]
10.	Tingkat Kemungkinan Penggunaan Kembali/Reusable Kode Program	[0/1/2/3/4/5]
11.	11. Tingkat Kemudahaan Dalam Instalasi	[0/1/2/3/4/5]
12.	Tingkat Kemudahaan operasional software (backup, recovery, dsbny)	[0/1/2/3/4/5]
13.	Tingkat Software dibuat untuk multi organisasi/perusahaan/client	[0/1/2/3/4/5]
14.	Tingkat kompleksitas dalam mengikuti perubahaan/fleksibel	[0/1/2/3/4/5]
	TOTAL	?

*Karakteristik diatas merupakan ketetapan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG).

Tahap 3. Menghitung Function Point (FP)

Adalah proses melakukan perhitungan untuk mendapat nilai Function point dari sofrware yang akan dibangun

Rumus FP :

*Angka 0.65 dan 0.01 adalah ketetepan atau konstanta yang dibuat oleh Function Point Internasional User Group (IFPUG)

Contoh studi kasus menggunakan perhitungan Functon Point

Studi kasus:

Akan dibangun sebuah software dalam pengelolahan Sistem Informasi Sumber Daya Manusia yang rencanakan untuk mengelola karyawan dari jumlah 10 hingga 200 karyawan dan akan menghasilkan berbagai macam laporan seperti absensi karyawan,sallery karyawan dan sebagainya. Aplikasi ini sangat memungkinkan berinteraksi dengan perangkat keras absensi seperti Fingger Print serta menyediakan webservice agar Software Sumber Daya Manusia ini dapat berkolaborasi Software Menajemen Proyek yang telah berjalanan.

Tahap 1. Menghitung Crude Function Points (CFP)

Crude Function Points (CFP) yang didapat 923

Tahap 2. Menghitung Relative Complexity Adjustment Factor (RCAF)

NO	KARAKTERISTIK	BOBOT
1.	Tingkat kompleksitas Komunikasi Data	3
2.	Tingkat kompleksitas Pemrosesan Terdistribusi	3
3.	Tingkat kompleksitas Performance	5
4.	Tingkat kompleksitas Konfigurasi	2
5.	Tingkat Frekuensi Penggunaan Software	5
6.	Tingkat Frekuensii Input Data	3
7.	Tingkat Kemudaaan Pengunaan Bagi User	5
8.	Tingkat Frekuensi Update Data	1
9.	Tingkat Kompleksitas Prosesing Data	3
10.	Tingkat Kemungkinan Penggunaan Kembali/Reusable Kode Program	3
11.	11. Tingkat Kemudahaan Dalam Instalasi	3
12.	Tingkat Kemudahaan operasional software (backup, recovery, dsbny)	2
13.	Tingkat Software dibuat untuk multi organisasi/perusahaan/client	3
14.	Tingkat kompleksitas dalam mengikuti perubahaan/fleksibel	4
	TOTAL	45

Tahap 3. Menghitung Function Point (FP)

FP = CFP x (0.65 + 0.01 x RCAF)

     = 923 x (0.65 + (0.01 x 45))

     = 1015.3

Nilai FP untuk proyek Software dalam pengelolahan Sistem Informasi Sumber Daya Manusia adalah 1015.3 FP.

Tahap 4. Konversi FP menjadi Biaya

Misalkan kita mempunyai table yang berisikan tarif untuk setiap nilaI FP sebagai berikut :

NO	TIPE PROJEK	TARIF/FP	JAM/FP	ALOKASI SDM
1	Web Profile	Rp. 20.000	1	2
2	Sistem Informasi	Rp. 100.000	1	5
3	E-Commerce	Rp. 40.000	1	2

Tabel tarif tersebut dihasilkan berdasarkan data history atau pengalaman dari perusahaan sendiri dalam developing software atau pengalaman perusahaan lain. Setiap perusahaan bisa berbeda-beda tarifnya karena bersifat subyektif.

Dan mengenai Tarif Rupiah per-FP setiap peruhaan bisa berbeda-berbeda tergantug dari kredibilitas perusahaan di pasar, semakin banyak berhasi menyelesaikan proyek sejenis atau memiliki produk yang laku di pasaran akan membuat tarif per FP nya meningkat.

Proyek Software dalam pengelolahan Sistem Informasi Sumber Daya Manusia adalah 1015.3 FP dengan Tarif Rupiah/FP untuk jenis Sistem Informasi adalah Rp. 100.000.  Maka Dapat dihasilkan sebagai berikut.

• Estimasi Biaya Development Software : Rp 100.000 x 1015.3 =Rp. 101.530.000
• Estimasi Khusus Produksi Software : 1 Jam x 1015.3 = 1015 Jam atau 127 Hari Kerja (Asumsi 1 Hari Kerja sama dengan 8 Jam)atau 5 Bulan (Asumi 1 bulan 25 Hari Kerja)

Costs of Software Quality

Pada buku Galin dituliskan: "Kami akan mengatakan bahwa biaya kualitas perangkat lunak - penilaian ekonomi dari pengembangan kualitas perangkat lunak dan perawatan - hanya kelompok lain dari metrik kualitas perangkat lunak, di mana nilai-nilai keuangan yang digunakan sebagai alat ukur. Namun, metrik kualitas dan biaya kualitas keduanya mendukung pengendalian manajemen dan pengambilan keputusan, biaya kualitas adalah metrik yang menampilkan karakteristik yang unik."

Berikut merupakan materi terkait tentang Cost of Software Quality :

Costs of software quality

View more presentations from PujiAgustin.

Project Progress Controls

The Components of Project Progress Control

Komponen utama dari project progress control adalah:

Penjelasan :

Control of risk management activities

- List item risiko perangkat lunak berdasarkan kategori dan tanggal yang direncanakan sousi mereka 

- List pengecualian software risk items – overrun solution dates.

Project schedule control

- Klasifikasi daftar kegiatan tertunda. 

- Klasifikasi daftar keterlambatan kegiatan kritis - penundaan yang dapat mempengaruhi tanggal penyelesaian proyek. 

- Perbarui jadwal kegiatan, menurut laporan kemajuan dan tindakan koreksi. 

-  Klasifikasi daftar pencapaian tertunda. 

- Perbarui jadwal pencapaian, menurut laporan kemajuan dan tindakan koreksi diterapkan.

Project resource control

- Rencana alokasi sumber daya proyek

     *Untuk kegiatan dan modul perangkat lunak 

     *Untuk tim dan unit pengembangan 

     *Untuk jangka waktu yang ditentukan, dll 

- Pemanfaatan sumber daya proyek 

- Pemanfaatan pengecualian sumber daya proyek 

- Memperbarui sumber daya recana alokasi yang dihasilkan sesuai dengan laporan kemajuan dan langkah-langkah reaksi diterapkan

Project budget control

- Rencana anggaran proyek

     *Untuk kegiatan dan modul perangkat lunak 

     *Untuk tim dan unit pengembangan 

     *Untuk jangka waktu yang ditentukan, dll 

 - Pemanfaatan laporan anggaran proyek 

- Pemanfaatan penyimpangan anggaran proyek - dengan masa atau akumulasi 

- Memperbarui rencana anggaran yang dihasilkan sesuai dengan port kemajuan laporan dan tindakan koreksi

Software Quality Infrastructure Components (2)

                 Configuration Management                  

Definisi:

Merupakan tools manajemen konfigurasi yang dipakai untuk menyimpan versi komponen sistem, membangun sistem dari komponen, dan memantau rilis versi sistem ke pelanggan beserta hasil laporannya.

Tujuan:

Tujuan utama dari manajemen konfigurasi adalah untuk memonitor informasi konfigurasi jaringan dan sistem, sehingga semua versi perangkat keras, lunak, dan konfigurasi dapat dilacak dan semua potensi masalah bisa dihilangkan (atau diantisipasi).

Berikut merupakan materi terkait dengan Software Configuration Management :

Software Configuration Management

View more presentations from PujiAgustin.

                     Documentation Control                        

Controlled Document and Quality Record - Definitions 

Controlled Document

Sebuah dokumen yang saat ini masih penting atau mungkin menjadi penting untuk pengembangan dan pemeliharaan sistem perangkat lunak serta untuk pengelolaan hubungan sekarang dan masa depan dengan pelanggan. Oleh karena itu, persiapan, penyimpanan, pencarian dan pembuangan dikendalikan oleh prosedur dokumentasi. 

Quality Record

Sebuah catatan kualitas adalah jenis khusus dari dokumen terkendali. Ini adalah dokumen pelanggan bertarget yang mungkin diperlukan untuk menunjukkan kepatuhan penuh dengan persyaratan pelanggan dan operasi yang efektif dari sistem jaminan kualitas perangkat lunak seluruh proses pembangunan dan pemeliharaan.

Objectives for Managing Controlled Documents

• Untuk menjamin kualitas dokumen. 
• Untuk menjamin kelengkapan teknis dan sesuai dengan prosedur struktur dokumen dan instruksi.
• Untuk menjamin ketersediaan masa depan dokumen yang mungkin diperlukan untuk pemeliharaan perangkat lunak sistem, atau tanggapan terhadap keluhan masa depan pelanggan. 
• Untuk mendukung penyelidikan penyebab kegagalan perangkat lunak sebagai bagian dari tindakan korektif dan lainnya.

Typical Components of Documentation Control Procedures

• Definisi dari daftar jenis dokumen dan update untuk dikendalikan (beberapa diklasifikasikan sebagai catatan mutu). 
• Persiapan dokumen kebutuhan. 
• Dokumen persetujuan kebutuhan. 
• Dokumen penyimpanan dan pengambilan kebutuhan, termasuk penyimpanan terkontrol versi dokumen, revisi dan pembuangan, keamanan dokumen.

Decision issues regarding controlled documents list

• Memutuskan jenis dokumen yang dikategorikan sebagai dokumen terkendali dan jenis dokumen yang terkontrol, diklasifikasikan sebagai catatan kualitas. 
• Memutuskan tentang tingkat yang memadai kontrol untuk setiap jenis dokumen terkendali. 
• Menindaklanjuti kepatuhan dengan daftar jenis dokumen terkendali. 
• Menganalisis tindak lanjut temuan dan memulai pembaruan yang diperlukan, perubahan, kepindahan dan penambahan pada daftar jenis dokumen terkendali.

Software Quality Infrastructure Components (1)

Komponen infrastruktur adalah alat yang digunakan untuk mencegah kesalahan perangkat lunak dan meningkatkan tingkat kualitas seluruh organisasi.

             Procedures and Work Instructions            

Manfaat :

• Peforma pekerjaan, proses atau aktivitas  pada cara yang paling efektif dan efisien.
• Efektif dan efisien komunikasi antara pengembang dan tim pemeliharaan yang dapat mengurangi kesalahpahaman yang menyebabkan kesalahan perangkat lunak. 
• Koordinasi sederhana antara pekerjaan-pekerjaan dan aktivitas yang dilakukan oleh berbagai tim yang berarti lebih sedikit kesalahan.

Procedures and Procedures Manuals

Procedures

Prosedur menyediakan semua rincian yang dibutuhkan untuk melaksanakan pekerjaan sesuai dengan metode prosedur untuk memenuhi fungsi pekerjaan tersebut. Rincian ini dapat dilihat sebagai lima isu, yaitu :

The Five W's:

■ What activities have to be performed?

■ HoW should each activity be performed?

■ When should the activity be performed?

■ Where should the activity be performed?

■ Who should perform the activity?

Typical Contents of a Procedure

1. Introduction *

2. Purpose

3. Terms and abbreviations *

4. Applicable documents

5. Method

6. Quality records and documentation

7. Reporting and follow up *

8. Responsibility for implementation *

9. List of appendices *

...Appendices *

* Sections included only if applicable

The Procedures Manual

Pengumpulan semua prosedur SQA biasanya disebut sebagai prosedur manual SQA. Isi prosedur manual organisasi seseorang bervariasi sesuai dengan:

■ Jenis-jenis pengembangan perangkat lunak dan aktivitas pemeliharaan yang dilakukan oleh organisasi

■ Batasan aktivitas termasuk dalam masing-masing jenis aktivitas

■ Batasan pelanggan (misalnya, internal, pelanggan dari custom-made software, pelanggan perangkat lunak Cots) dan pemasok (misalnya, pengembangan diri dan pemeliharaan, subkontraktor, pemasok perangkat lunak Cots dan modul perangkat lunak yang digunakan kembali)

■ Konsep yang mengatur pada pilihan metode yang diterapkan oleh organisasi untuk mencapai tujuan SQA yang diinginkan.

Work Instructions and Work Instruction Manuals

Instruksi kerja menangani penerapan prosedur, disesuaikan dengan kebutuhan tim proyek tertentu, pelanggan, atau pihak lain yang relevan. Sementara metodologi umum mendefinisikan prosedur, rincian tepat yang memungkinkan aplikasi untuk proyek tertentu atau unit sering diletakkan dalam prosedur kerja.

Motivations for Updating Procedures

• Perubahan teknologi pada alat pengembangan, perangkat keras, peralatan komunikasi, dll  
• Perubahan area aktivitas organisasi 
• Pengguna proposal untuk perbaikan 
• Analisis kegagalan maupun keberhasilan (Pengalaman dari tim SQA) 
• Proposal untuk perbaikan yang diprakarsai oleh laporan audit Internet 
• Belajar dari pengalaman organisasi lain

                   Supporting Quality Devices                 

Templates

Pada rekayasa perangkat lunak, template merujuk ke format (terutama daftar isi) dibuat oleh unit atau organisasi, untuk diterapkan ketika menyusun laporan atau beberapa jenis lain dari dokumen. Penerapan template mungkin wajib bagi beberapa dokumen dan pilihan untuk orang lain, dalam beberapa kasus hanya bagian dari template (misalnya, bab-bab tertentu atau struktur umum) yang diminta.

Berikut tiga contoh template : 

■ Frame 10,2: Software test plan (STP) 

■ Frame 10,3: Software test description (PMS) 

■ Frame 10,4: Software test report (STR)

The Contribution of Templates

Untuk tim pengembangan: 

■ Memfasilitasi proses penyusunan dokumen. 

■ Dokumen yang disiapkan oleh pengembang lebih lengkap.

■ Menyediakan untuk integrasi mudah dari anggota tim baru. 

■Memfasilitasi review dokumen. 

Untuk tim pemeliharaan perangkat lunak: 

■ Mengaktifkan lokasi mudah informasi.

Sources for Updating Templates

■ Usulan dan saran pengguna. 

■ Perubahan area aktivitas organisasi. 

■ Proposal diprakarsai oleh pengkajian desain dan tim inspeksi.

■ Analisis kegagalan maupun keberhasilan. 

■ Pengalaman organisasi lain. 

■ Tim inisiatif SQA.

Checklists

Checklist digunakan oleh pengembang perangkat lunak mengacu pada daftar item yang dibuat secara khusus untuk setiap jenis dokumen, atau beberapa dari persiapan yang akan selesai sebelum melakukan suatu aktivitas (misalnya, menginstal paket perangkat lunak di lokasi pelanggan). Checklist direncanakan bersifat komprehensif jika tidak lengkap. Biasanya, penggunaan checklist cenderung dipertimbagkan sebagai alat infrastruktur opsional, tergantung utamanya pada daftar atribut profesional, pengguna berkenalan dengan daftar dan ketersediaan. 

The Contribution of Checklists
Untuk tim pengembangan:
■ Membantu pengembang melakukan sendiri pemeriksaan dokumen atau kode perangkat lunak sebelum penyelesaian.
■ Membantu para pengembang dalam persiapan untuk pekerjaan mereka.

Untuk tim peninjau:
■ Memastikan kelengkapan tinjauan dokumen oleh anggota tim review.
■ Memfasilitasi perbaikan efisiensi dari sesi review.

Sources for Updating Checklists
Untuk memperbarui checklist hampir sama seperti memperbarui template

■ Usulan dan saran pengguna. 

■ Perubahan area aktivitas organisasi. 

■ Proposal diprakarsai oleh pengkajian desain dan tim inspeksi.

■ Analisis kegagalan maupun keberhasilan. 

■ Pengalaman organisasi lain. 

■ Tim inisiatif SQA.

 Berikut merupakan gambarr tabel DR checklist untuk dokumen spesifikasi kebutuhan :

               Staff Training and Certification                 

The Objectives of Training and Certification

■ Untuk mengembangkan ilmu pengetahuan dan keterampilan yang dibutuhkan staff baru. 

■ Untuk menjamin kesesuaian dengan standar organisasi untuk produk perangkat lunak (dokumen dan kode). 

■ Untuk memperbarui ilmu pengetahuan dan keterampilan dari staf veteran. 

■ Untuk  mentransmisikan ilmu pengetahuan tentang prosedur SQA.

■ Untuk memastikan bahwa kandidat untuk posisi kunci cukup berkualitas.

The Training and Certification Process

Berikut merupakan gambar proses training dan sertifikasi :

Pelatihan dan sistem sertifikasi menuntut bahwa aktivitas berikut secara teratur dilakukan: 

■ Determine the professional knowledge requirements for each position

Profesi: analis sistem, programmer, pengembangan perangkat lunak ketua tim, pemimpin tim pemrograman, perangkat lunak teknisi pemeliharaan, software tester, perangkat lunak pengujian pemimpin tim. 

Kebutuhan pengetahuan: pengetahuan dan keterampilan dari topik rekayasa perangkat lunak; pengetahuan tentang topik SQA.

■ Determine the professional training and updating needs

Training: untuk karyawan baru.

Retraining: bagi karyawan ditugaskan untuk posisi baru atau menerima tugas baru.

Updating: untuk anggota staf sesuai tuntutan posisi mereka.

■ Plan the professional training program

■ Plan the professional updating program

■ Define positions requiring certification

■ Plan certification processes

Contoh: ketua tim pengembangan perangkat lunak, pemimpin tim pemrograman, teknisi pemeliharaan perangkat lunak, pemimpin tim pengujian perangkat luna , auditor mutu internal.

■ Deliver training, updating and certification programs

- Topik meliputi rekayasa perangkat lunak, SQA & keterampilan manajemen,sesuai kebutuhan pada perusahaan. 

- Mendapatkan program kuliah singkat, demonstrasi, dan kursus panjang. 

- Dapat dilakukan oleh unit pelatihan organisasi, lembaga pendidikan, lembaga kejuruan.

■ Perform follow-up of trained and certified staff.

- Pengumpulan metrik kinerja secara berkala.

- Kuesioner diisi oleh staf yang terlatih dan bersertifikat, atasan, pelanggan dan lainnya. 

- Analisis prestasi yang luar biasa & kegagalan. 

- Khusus yang direview produk perangkat lunak