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.

Pre-Project Software Quality Components (1)

                            Contract Review                            

Pendahuluan: Penyelesaian Proyek CFV Perayaan 

KASUS kegagalan:

Kontrak proses review berasal dari pemasok-pelanggan hubungan, dan diharapkan memberikan kontribusi yang substansial untuk prepojects internal juga. Realistis profesional komitmen mengakibatkan kegagalan untuk mencapai kualitas yang diperlukan perangkat lunak. Dalam kebanyakan kasus, jadwal dan anggaran kegagalan yang disertai oleh lebih rendah dari kualitas perangkat lunak dapat diterima, karena tekanan excerted pada anggota tim dengan manajemen "untuk menghemat waktu" dan “untuk menghemat sumber daya".

Tinjauan Kontrak adalah unsur kualitas perangkat lunak yang mengurangi kemungkinan situasi yang tidak diinginkan tersebut.

Tinjauan Kontrak adalah persyaratan oleh ISO 9001 standar dan ISO 9000 - 3Guidelines

Proses Kontrak Review dan Tahapannya

Beberapa situasi dapat menyebabkan perangkat lunak perusahaan ("pemasok") untuk menandatangani kontrak dengan pelanggan.

Yang paling umum adalah: 

1. Partisipasi dalam tender. 
2. Pengajuan proposal sesuai dengan pelanggan itu RFP.
3. Penerimaan order dari pelanggan perusahaan 
4. Menerima permintaan dari sebuah internal atau perintah dari yang lain departemen dalam organisasi.

Proses Review

Proses pemeriksaan itu sendiri dilakukan di dua tahap :
- Tahap Satu - Kajian dari rancangan usulan sebelum diajukan kepada pelanggan potensial ("Proposal tinjauan rancangan").
- Tahap Dua - Review draft kontrak sebelum tanda tangan ("Kontrak tinjauan rancangan")

Tujuan Kontrak Review

Tujuan dari tinjauan usulan rancangan  adalah untuk memastikan bahwa kegiatan berikut telah dilakukan dengan memuaskan pengeluaran : 

1. Persyaratan pelanggan telah diklarifikasi dan didokumentasikan. 

2. Pendekatan alternatif untuk melaksanakan proyek memiliki telah diperiksa.

3. Formal aspek hubungan antara pelanggan dan perusahaan perangkat lunak telah ditetapkan. 

4. Identifikasi risiko perkembangan. 

5. Memadai estimasi sumber daya proyek dan jadwal telah disusun

6. Pemeriksaan kapasitas perusahaan sehubungan untuk proyek. 

7. Pemeriksaan kapasitas pelanggan untuk memenuhi nya komitmen. 

8. Definisi mitra dan subkontraktor partisipasi kondisi. 

9. Definisi dan perlindungan hak kepemilikan

Kontrak Review dan Draft Kontrak

Tujuan dari tinjauan draft kontrak adalah untuk memastikan bahwa kegiatan berikut telah menunjukkan kinerja yang memuaskan, yaitu :

1. Tidak ada masalah unclarified tetap dalam kontrak draft. 

2. Semua pemahaman berikutnya mencapai proposal dengan benar didokumentasikan. 

3. Tidak "baru" perubahan, penambahan, atau kelalaian telah memasuki draft kontrak

Implementasi Kontrak Review

Review kontrak bervariasi tergantung pada karakteristik proyek yang diusulkan. 

Faktor yang mempengaruhi tingkat peninjauan kontrak :

- Besarnya proyek 

- Kompleksitas teknis proyek

- Derajat semua kenalan dengan staf dan pengalaman di wilayah proyek 

- Kompleksitas Organisasi proy

Siapa yang melakukan peninjauan kontrak? 

- Pemimpin atau anggota lain dari tim usulan 

- Para anggota tim usulan 

- Seorang profesional dari luar atau staf anggota perusahaan yang bukan anggota tim usulan 

- Sebuah tim ahli dari luar

Subyek Kontrak Review

- Ulasan Kontrak yang memeriksa banyak sub bab, berdasarkan tujuan kontrak review. 

- Daftar periksa adalah alat yang berguna untuk membantu tim meninjau untuk mengatur pekerjaan mereka dan mencapai cakupan yang tinggi yang relevan pada sub bab.

Kontrak Review untuk Internal

Komponen Software Quality Assurance (SQA)

Komponen Sistem SQA diklasifikasikan sebagai berikut :

1. Arsitektur Komponen  Sistem SQA

Terdapat  6 komponen pada gambar arsitektur SQA diatas yang juga termasuk dalam komponen Sistem SQA, berikut ini penjelasan mengenai komponen sistem SQA selanjutnya yang juga termasuk penjelasan dari arsitektur SQA :

2. Komponen Pre-Proyek Penilaian 

Menjamin atas :

• Komitmen bahwa proyek sesuai dengan sumber daya, jadwal, dan anggaran yang telah ditentukan
• Pembangunan dan rencana kualitas telah ditentukan dengan benar

Pre-Proyek terdiri dari :

• Kontrak review

1. Klarifikasi kebutuhan pelanggan
2. Review jadwal proyek dan perkiraan kebutuhan sumber daya
3. Evaluasi kemampuan staf profesional untuk melaksanakan proyek
4. Evaluasi kemampuan pelanggan untuk memenuhi kewajibannya

• Pembangunan dan rencana kualitas

1. Jadwal
2. Kebutuhan manpower dan sumber daya hardware
3. Evaluasi risiko
4. Persoalan organisasi : anggota tim, sub kontraktor, dan rekanan
5. Metodologi proyek, tools pengembangan, dll
6. Rencana penggunaan ulang perangkat lunak (PL)

3. Aktivitas Daur Hidup Proyek 

Ada dua tahap, yaitu :

• Tahap siklus hidup pengembangan -> mendeteksi kesalahan desain dan programming.

1. Review ->  Formal Design Review, berupa Daftar Koreksi yang diperlukan (Action Items).
2. Pendapat ahli -> Memperkenalkan kemampuan eksternal tambahan ke dalam proses in-house development organisasi.
3. Pengujian PL -> Tes software komponen SQA yang resmi untuk meninjau jalannya software yang sebenarnya.
4. Jaminan kualitas untuk pekerjaan sub kontraktor dan kesediaan pelanggan

• Tahap operasi maintenance :

1. Corrective maintenance -> Koreksi kesalahan perangkat lunak dan kegagalan
2. Adaptive maintenance -> Mengadaptasi software saat ini untuk keadaan tambahan tanpa mengubah software
3. Functionality improvement maintenance -> Peningkatan dan perbaikan software.

• Komponen pre-maintenance :
• Maintenance kontrak review
• Rencana maintenance

• Komponen infrastruktur SQA :
• Prosedur maintenance dan instruksi
• Dukungan perlengkapan kualitas
• Maintenance pelatihan staf, pelatihan ulang, dan sertifikasi
• Tindakan preventive dan corrective maintenance
• Manajemen konfigurasi
• Kontrol dokumentasi maintenance dan laporan kualitas'

• Kontrol manajerial komponen SQA :
• Kontrol maintenance servis
• Metriks maintenance kualitas
• Biaya maintenance kualitas

4. Pencegahan dan Perbaikan Infrastruktur Proyek 

Tujuan utama : untuk melenyapkan atau mengurangi error yang didasarkan atas pengalaman SQA organisasi.


Mencakup :

1. Prosedur dan instruksi pekerjaan 

• Procedure : Perencanaan yang berlaku secara umum dan untuk melayani seluruh organisasi
• Intruksi pekerjaan : Petunjuk rinci untuk penggunaan metode yang diterapkan pada tiap kasus unik dan dikerjakan oleh tim khusus

2. Template dan checklist -> Merupakan perangkat kualitas pendukung yang didasarkan pada pengetahuan dan pengalaman organisasi.

3. Pelatihan staf, pelatihan ulang, dan sertifikasiSDM organisasi yang berpengetahuan dan update dapat dicapai oleh :

• Pelatihan karyawan baru dan pelatihan ulang karyawan yang memiliki perubahan tugas.
• Terus memperbarui staf sehubungan dengan perkembangan profesional dan in-house pengalaman yang diperoleh.
• Sertifikasi karyawan setelah pengetahuan dan kemampuan telah ditunjukkan.

4. Tindakan pencegahan dan perbaikan

5. Kontrol dokumentasi ->  Untuk memberikan bukti kinerja sistem SQA.

5. Komponen Manajemen SQA 

Merupakan pelengkap dari beberapa tujuan, salah satunya adalah mengontrol aktivitas pembangunan dan perawatan serta memperkenalkan lebih awal dukungan manajerial untuk mencegah atau meminimalisir kegagalan jadwal dan anggaran serta akibatnya.

Terdiri dari :

• Kontrol progress proyek (mencakup kontrol kontrak maintenance) -> Untuk mendeteksi munculnya situasi yang menyebabkan penyimpangan dan rencana proyek dan kinerja pemeliharan layanan.
• Penggunaan sumber daya
• Jadwal
• Aktivitas manajemen risiko
• Anggaran

• Metriks kualitas PL -> Pengukuran SQA untuk kualitas fungsional, produktivitas dan aspek organisasi proyek.
• Kualitas pembangunan PL dan aktivitas maintenance
• Pembentukan kelompok produktivitas
• Help desk dan maintenance tim produktivitas
• Tingkat kegagalan PL
• Selisih jadwal

• Biaya kualitas PL ->    Biaya pengendalian dikombinasikan dengan biaya kegagalan, sehingga terdapat kesiapan manajemen untuk mengalokasikan dana atau dengan mengefisienkan anggaran.

6. Standarisasi, Sertifikasi dan Penilaian Sistem SQA 

Tujuan :

• Pengetahuan profesional internasional
• Perbaikan koordinasi kualitas sistem organisasi dengan organisasi lain yang sejenis
• Penilaian pencapaian kualitas sistem sesuai dengan skala umum

Standar yang digunakan :

• Standar manajemen kualitas : SEI CMM, ISO 9001, dan ISO 9000-3
• Standar proses proyek : IEEE 1012, ISO / IEC 12207

7. Organisasi SQA (Komponen Manusia)

Tujuan utama :

• Memulai dan mendukung pelaksanaan komponen SQA

• Mendeteksi deviasi dari prosedur SQA dan metodologi

• Mengusulkan perbaikan komponen SQA

Memiliki aktor-aktor :

• Manajer

• Personal pengujian

• Unit dan praktisi SQA yang tertarik pada kualitas PL

Unit SQA -> Bagian dari basis SQA organisasi yang mengabdikan diri sepenuhnya untuk hal-hal SQA. Dengan tugas mereka adalah sebagai kekuatan penggerak utama, inisiator dan koordinator dari sistem SQA.

Wali SQA -> Anggota tim pengembang dan pemeliharaan yang memiliki  minat khusus dalam kualitas software dan siap mengabdikan diri.

Anggota Komite -> Anggota dari pengembangan berbagai software dan pemeliharaan unit dan biasanya diangkat untuk layanan ad hoc.

Forum SQA -> profesional dan praktisi yang memenuhi atau mempertahankan sebuah situs Internet  yang sukarela untuk diskusi tentang kualitas masalah yang berhubungan dengan proses pembangunan dan pemeliharaan.

8. Pertimbangan pembangunan sebuah komponen sistem organisasi SQA

• Pertimbangan Organisasi
• Jenis Klien pengembangan software
• Jenis Klien perawatan software
• Rentang produk
• Ukuran organisasi
• Tingkat dan sifat kerjasama dengan organisasi lain
• Tujuan Optimisasi
• Pertimbangan Proyek dan Layanan pemeliharaan
• Tingkat Kompleksitas software dan Kesulitan
• Tingkat pengalaman staf dengan teknologi proyek
• Tingkat penggunaan kembali software dalam proyek-proyek baru
• Pertimbangan Profesional Staf
• Kualifikasi profesional
• Tingkat kenal dengan anggota tim

Homework - mindmap Software Quality Metrics

Software metrics dikategorikan menjadi dua, yaitu Process metrics dan Product metrics. Setiap kategori tersebut terdiri dari beberapa sub kategori. Berikut ini merupakan gambaran Software Quality Metrics yang saya visualisasikan dengan mindmap beserta penjelasannya (pada posting yang sebeelumnya hanya gambar metrik saja belum ada penjelsannya) :)

Semoga Bermanfaat :)

Homework

Software metrics dikategorikan menjadi dua, yaitu Process metrics dan Product metrics. Setiap kategori tersebut terdiri dari beberapa sub kategori. Berikut ini merupakan gambaran Software Quality Metrics yang saya visualisasikan dengan minddmap :)

Semoga bermanfaat :)