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

Requirement Traceability Matrix

Definisi RTM

Requirements Traceability Matrix (RTM) ialah tabel yang berisi daftar requirements, atribut yang bervariasi untuk setiap requirement, dan status dari requirement untuk memastikan semua requirement telah terpenuhi. Atau Requirements Traceability Matrix  (RTM) adalah alat untuk membantu memastikan bahwa lingkup proyek, kebutuhan, dan penyampaian tetap "sebagaimana adanya" dibandingkan dengan baseline. Dengan demikian, penyampaian ditelusuri dengan membentuk thread untuk setiap kebutuhan dari inisiasi proyek untuk implementasi akhir.

Diagram diatas menunjukkan bahwa RTM dapat digunakan selama seluruh tahapan proyek untuk: 

• Melacak semua persyaratan dan apakah atau tidak mereka sedang dipenuhi oleh proses saat ini dan desain 
• Membantu dalam penciptaan RFP, Tugas Rencana Proyek, Dokumen Deliverable, dan Test Scripts 
• Membantu memastikan bahwa semua persyaratan sistem telah terpenuhi selama proses Verifikasi

Manfaat RTM

Penggunaan RTM dapat meningkatkan proses manajemen ruang lingkup. Hal ini juga membantu kontrol proses dan kualitas manajemen. RTM juga dapat dianggap sebagai proses mendokumentasikan koneksi dan hubungan antara persyaratan awal dari proyek dan produk akhir atau jasa yang dihasilkan. RTM juga digunakan untuk memverifikasi bahwa semua persyaratan terpenuhi dan untuk mengidentifikasi perubahan pada ruang lingkup saat terjadi.

RTM dalam Pengujian Perangkat Lunak

Requirements tracing adalah proses mendokumentasikan hubungan antara kebutuhan pengguna untuk sistem yang sedang dibangun dan produk kerja yang dikembangkan untuk melaksanakan dan memverifikasi kebutuhan. Produk-produk pekerjaan ini meliputi kebutuhan Software, spesifikasi desain, kode Software, rencana uji dan artefak lain dari proses pengembangan sistem. Requirements tracing membantu tim proyek untuk memahami bagian mana dari desain dan kode yang menerapkan kebutuhan pengguna dan tes yang diperlukan untuk memverifikasi bahwa kebutuhan pengguna telah diterapkan dengan benar. 

Requirements Traceability Matrix dokumen adalah output dari fase Manajemen Persyaratan SDLC. 

RTM digunakan untuk merekam hubungan kebutuhan, pengembangan, pengujian desain, dan output perangkat lunak. Perubahan kebutuhan juga direkam dan dilacak dalam RTM. RTM ini adalah dokumen yang sangat berguna untuk melacak waktu, manajemen perubahan dan manajemen risiko dalam pengembangan perangkat lunak. Template RTM menunjukkan pemetaan antara kebutuhan aktual dan kebutuhan user / kebutuhan sistem. Setiap perubahan yang terjadi setelah sistem dibangun dapat dilacak dampak perubahan pada  RTM melalui Matrix. Ini juga merupakan pemetaan antara kebutuhan aktual dan spesifikasi desain. 

Bagaimana Membuat RTM ?

Kebutuhan masing-masing harus unik dan jelas. Referensi seluruh proses harus konsisten dan unik. Untuk memastikan bahwa hal ini terjadi, Matrix menelusuri kebutuhan masing-masing dan menciptakan hubungan antara masing-masing proses. 

Berikut gambar tabel RTM berserta penjelasannya :

Req #: Jumlah kebutuhan; untuk setiap kebutuhan proyek, mulai daftar mereka pada RTM dalam urutan numerik dan kelompok mereka dengan fungsi. 

Nama: Masukkan nama dan deskripsi singkat tentang persyaratan 

RFP #: Request For Proposal (RFP); menentukan nomor identifikasi persyaratan seperti yang tercantum dalam RFP. 

DDD #: Deliverable Definition Document (Juga disebut sebagai Deliverable Expectation Document- DED); menggunakan nomor RFP persyaratan sebagai referensi untuk DDD yang dibuat untuk kebutuhan. 

PDF #: Buatlah daftar MS Project subtask dan nomor Tugas yang berkaitan dengan kebutuhan. 

TS #: Skrip uji harus disiapkan untuk proses pengujian yang sebenarnya. 

Verifikasi: Gunakan field ini untuk merekam penyelesaian proses signoff.

SQA Components in the Project Life Cycle

Pre-Project Software Quality Components (2)

                Development and Quality Plans               

Pengembangan dan Tujuan Rencana Kualitas

Berikut merupakan hal-hal yang harus dipersiapkan :

• Penjadwalan kegiatan pembangunan yang akan mengarah pada penyelesaian yang sukses dan tepat waktu proyek, dan memperkirakan sumber daya tenaga kerja yang diperlukan dan anggaran.
• Merekrut anggota tim dan mengalokasikan sumber daya pengembangan (menurut jadwal kegiatan dan perkiraan kebutuhan sumber daya tenaga kerja). 
• Menyelesaikan risiko pembangunan. 
• Menerapkan diperlukan aktivitas SQA.
• Menyediakan manajemen dengan data yang diperlukan untuk pengendalian proyek.

Unsur-unsur Rencana Pengembangan

Berikut unsur-unsur, masing-masing berlaku untuk komponen proyek yang berbeda, terdiri dari rencana pengembangan proyek:

1. Project products :

• Desain dokumen menentukan tanggal penyelesaian, menunjukkan barang-barang yang akan dikirimkan ke pelanggan ("deliverables") 
• Software produk (menentukan tanggal penyelesaian dan situs instalasi) 
• Pelatihan tugas (menentukan tanggal, peserta dan situs).

2. Project interfaces : 

• Antarmuka dengan paket software yang ada (antarmuka perangkat lunak) 
• Antarmuka dengan perangkat lunak lain dan / atau tim pengembangan perangkat keras yang bekerja pada sistem yang sama atau proyek (yaitu, kerjasama dan link koordinasi) 
• Antarmuka dengan perangkat keras yang ada (antarmuka hardware).

3. Project methodology, and development tools :

• Untuk diterapkan pada setiap fase proyek. 
• Harus mempertimbangkan pengalaman profesional staf, termasuk personil subkontraktor, walaupun hanya sementara

4. Software development standards and procedures :

• Sebuah daftar harus disiapkan dari standar pengembangan perangkat lunak dan prosedur yang harus diterapkan dalam proyek

5. The mapping of the development process :

• Melibatkan menyediakan definisi rinci dari setiap fase proyek.
• Deskripsi ini mencakup definisi input dan output, dan kegiatan spesifik yang direncanakan.
• Deskripsi kegiatan meliputi:
• Perkiraan durasi aktivitas tersebut. Perkiraan ini sangat tergantung pada pengalaman yang diperoleh dalam proyek-proyek sebelumnya.
• Urutan logis dimana setiap kegiatan yang akan dilakukan, termasuk deskripsi ketergantungan setiap kegiatan pada aktivitas sebelumnya selesai.
• Jenis sumber daya profesional yang diperlukan dan memperkirakan berapa banyak sumber daya yang diperlukan untuk setiap kegiatan.

6. Project milestone :

• Untuk tonggak masing-masing, penyelesaian waktu dan produk proyek (dokumen dan kode) harus didefinisikan.

7. Project staff organization :

Rencana organisasi terdiri dari: 

• Struktur organisasi: definisi tim proyek dan tugas mereka, termasuk tim terdiri dari pekerja sementara seorang subkontraktor. 
• Profesional persyaratan: sertifikasi profesional, pengalaman dalam bahasa pemrograman tertentu atau alat pembangunan, produk perangkat lunak tertentu dan jenis, dll.
• Jumlah anggota tim yang dibutuhkan untuk setiap periode waktu, sesuai dengan kegiatan yang dijadwalkan. Nama-nama pemimpin tim dan anggota tim.

8. Development facilities :

• Fasilitas pembangunan yang diperlukan termasuk hardware, software dan alat pengembangan perangkat keras, ruang kantor, dan item lainnya. 
• Untuk setiap fasilitas, periode yang diperlukan untuk penggunaannya harus ditunjukkan pada jadwal.

9. Development risk :

• Risiko perkembangan khas adalah: 
• Teknis gaps – lack pengetahuan profesional yang cukup memadai dan pengalaman untuk melaksanakan tuntutan kontrak pengembangan.
• Staf shortages – unanticipated  yang tidak diantisipasi dari staf profesional. 
• Interdependensi organizational elements – the likelihood bahwa pemasok perangkat keras khusus atau subkontraktor perangkat lunak, misalnya, tidak akan memenuhi kewajiban mereka sesuai jadwal. 
• Selanjutnya pembacaan untuk risiko pengembangan: 
• Ropponen & Lyytinen (2000) 
• Boehm & Ross (1989)
• Classes of software development risks
• Scheduling and timing risks
• System functionality risks
• Subcontracting risks
• Requirement management risks
• Resource usage and performance risks
• Personnel management risks
• Boehm & Ross’s Top 10 software risk :
• Developing wrong software functions
• Unrealistic schedules and budgets
• Developing wrong user interface
• Gold plating
• Continuing stream of requirement changes
• Shortfalls in externally furnished components
• Shortfalls in externally performed tasks
• Personnel shortfalls
• Real-time performance shortfalls
• Straining computer science capabilities tems
• The software risks management process

10. Control methods :

• Untuk mengendalikan pelaksanaan proyek, manajer proyek dan departemen manajemen menerapkan serangkaian praktek pemantauan ketika menyiapkan laporan kemajuan dan mengkoordinasikan pertemuan. 

11. Project cost estimation :

• Estimasi biaya proyek didasarkan pada perkiraan usulan biaya, diikuti dengan penelaahan menyeluruh terhadap relevansi lanjutan mereka berdasarkan diperbarui perkiraan sumber daya manusia, kontrak dinegosiasikan dengan subkontraktor dan pemasok, dan sebagainya.
• Rencana persetujuan pengembangan
• Rencana review pengembangan dan persetujuan yang akan selesai sesuai dengan prosedur yang diterapkan dalam organisasi.

Unsur-unsur Rencana Kualitas

1. Quality goals

• "Tujuan Kualitas" mengacu pada persyaratan substantif sistem perangkat lunak yang dikembangkan secara berkualitas. 
• Ketika memilih tujuan kualitas: 
• Kuantitatif measures – assessments yang lebih obyektif kinerja perangkat lunak. 
• Tindakan kualitatif 
• Help desk system (HDS) requirements and quantitative goals

2. Planned review activities

• Rencana mutu harus menyediakan daftar lengkap semua kegiatan review yang direncanakan: desain ulasan (DRs), inspeksi desain, inspeksi kode, dll, dengan berikut ditentukan untuk setiap kegiatan:
• Ruang lingkup tinjauan kegiatan 
• Jenis tinjauan kegiatan  
• Jadwal tinjauan kegiatan (seperti yang didefinisikan oleh prioritas dan kegiatan berikutnya dari proses proyek) 
• Spesifik prosedur yang harus diterapkan 
• Siapa yang bertanggung jawab untuk melaksanakan tinjauan kegiatan 

3. Planned software tests

• Rencana mutu harus menyediakan daftar lengkap dari tes perangkat lunak yang direncanakan: 
• Unit, integrasi atau sistem lengkap untuk diuji 
• Jenis kegiatan pengujian yang akan dilakukan, termasuk spesifikasi tes perangkat lunak komputerisasi untuk diterapkan 
• Jadwal yang direncanakan uji 
• Spesifik prosedur yang harus diterapkan 
• Siapa yang bertanggung jawab untuk melaksanakan tes

4. Planned acceptance tests for externally developed software

• Item yang akan disertakan: 
• Membeli perangkat lunak 
• Software yang dikembangkan oleh subkontraktor 
• Pelanggan yang dipasok perangkat lunak

5. Configuration management

• Rencana mutu harus menentukan alat manajemen konfigurasi dan prosedur, termasuk perubahan-kontrol prosedur dimaksudkan untuk diterapkan di seluruh proyek.
• Rencana mutu dapat dibuat sebagai bagian dari rencana pengembangan atau sebagai dokumen independen. 
• Dalam beberapa kasus, rencana dibagi menjadi beberapa dokumen berdasarkan kategori item, seperti rencana DR, rencana pengujian, dan rencana untuk tes perangkat lunak eksternal yang dikembangkan penerimaan. 
• Review dan persetujuan rencana mutu harus dilakukan sesuai dengan prosedur standar organisasi untuk rencana tersebut.

Pengembangan dan Rencana Kualitas untuk Proyek-proyek Kecil

• Sudahjelas bahwa perkembangan dan prosedur rencana mutu diterapkan pada proyek besar tidak dapat secara otomatis diterapkan untuk proyek-proyek kecil.
• Direkomendasikan unsur rencana pengembangan dan kualitas untuk proyek-proyek kecil:
• Rencana pengembangan - produk, benchmark, risiko, biaya.
• Rencana kualitas - tujuan kualitas.

Pentingnya Rencana Pengembangan dan Kualitas untuk Proyek-proyek Kecil

• Pemahaman yang lebih komprehensif dan menyeluruh dari tugas tercapai. 
• Tanggung jawab yang lebih besar untuk memenuhi kewajiban dapat diberikan. 
• Menjadi lebih mudah bagi manajemen dan pelanggan untuk berbagi kontrol proyek dan untuk mengidentifikasi penundaan tak terduga sejak dini. 
• Pemahaman lebih baik mengenai persyaratan dan jadwal dapat dicapai antara pengembang dan pelanggan.

Pengembangan dan Rencana Kualitas untuk Proyek-proyek Internal

• Proyek - proyek internal dimaksudkan untuk digunakan oleh departemen lain dalam organisasi atau dengan seluruh organisasi, serta proyek-proyek yang berhubungan dengan pengembangan perangkat lunak paket untuk pasar perangkat lunak. 
• Tidak ada badan eksternal berpartisipasi sebagai pelanggan. 
• Bisa skala menengah atau besar. 
• Prosedur yang direkomendasikan - mengobati proyek internal sebagai "proyek biasa".

Pentingnya Rencana Pengembangan dan Kualitas untuk Proyek-proyek Internal

• Departemen pengembangan akan menghindari kerugian yang terjadi pada jadwal yang tidak realistis dan anggaran, serta kerusakan konsekuen untuk proyek lain dan reputasi perusahaan. 
• "Customer" internal akan menikmati penurunan risiko penyelesaian akhir dan pelampauan anggaran di samping dan dengan pengendalian proyek peningkatan dan koordinasi dengan pengembang.
• Perusahaan akan menikmati penurunan risiko masuk akhir perangkat lunak produk ke pasar, mengurangi risiko penurunan reputasi akibat pasokan terlambat, dan mengurangi risiko terjadinya overruns anggaran.