Testing Implementation

Untuk mengetahui kualitas sebuah software maka dilakukan testing implementation, tahapan dalam testing implementation adalah :

• Menentukan metodologi apa yang digunakan.
• Menetukan level quality standart yang ditinjau dari ke crusialan yang terjadi jika software tersebut gagal atau dapat dikatakan efek dari kegagalan software.
• Mengklasifikasikan resiko dan akibatnya.
• Menentukan strategi testing, terkait metode testing yaitu penggunaan white box testing ataupun blackbox testing, top down testing, dll

• Membuat Test Plan
•  Scope dan dari testing.
• Lingkungan Testing, terkait hardware, software requirement, dll
• Detail Test, berisi tujuan, identifikasi, requirement test dan test level dan test integration dan special test.
• Jadwal testing

• Membuat Test Design
• Menentuka fitur-fitur yang dilakukan testing
• Kriteria penerimaan test
• Test Idenfitikasi
• Kriteria kesuksesan dan kegagalan fitur.

•  Testing Implementation
• Pada testing implementation dilakukan functional test, integration test, dan special test.

Testing Implementation

Testing Implementation berarti melakukan testing pada software untuk menguji kualitas software berdasarkan functional test, integration test dan special test.

1. Functional Test

Functional test merupakan test yang dilakukan per functional atau per fitur yang ada. 

Dalam functional test harus menampilkan test case yang telah dibuat untuk membantu mengetahui scenario kesuksesan software. Menentukan kriteria kesuksesan yang telah dibuat pada tahapan test design. setelah itu dilakukan testing per functional. Kualitas software dapat dilihat dari kesuksesan jalannya software sesuai dengan test case dan kriteria kesuksesan.

2.  Integration Test.

Integration Test merupakan test yang dilakukan pada keseluruhan jalannya modul, 

3. Special Test.

Test dilakukan untuk pengecekan apakah font, form dan fitur-fitur pendukung lainnya dapat mempermudah pengguna dan sesuai dengan fungsinya. Special test juga dilakukan untuk melihat reability dan keamanan data yang diinputkan maka biasanya dilakukan testing dengan sql injection.

Berikut merupakan contoh testing implementation dari study kasus RANCANG BANGUNG SISTEM INFORMASI DAFTAR PENILAIAN PELAKSANAAN PEKERJAAN STUDI KASUS DI TEKNOLOGI INFORMASI ITS.

Testing Implementation

Progress Control

Pengerjaan proyek banyak yang tidak selesai tepat waktu, bisa lebih cepat maupun lebih lama ini merupakan masalah umum yang sering terjadi dalam proses development project. Salah satu tools yang mempunyai peran untuk mengontrol progress pengerjaan proyek agar waktu yang dipakai sesuai dengan yang telah disepakati dan dijadwalkan di awal dengan tidak mengalami over budgeting maupun under budgetin adalah Project Progress Control.

Project Progress Control

Bagaimana membangun dan merencanakan software yang berkualitas ?

Untuk menghasilkan software yang berkualitas tentunya tidaklah mudah, terdapat banyak faktor yang perlu diperhatikan, yaitu :

1. Kemanan
2. Kecepatan
3. Kemudahan penggunaan
4. dll

Dari faktor-faktor tersebut dalam setiap project IT membutuhkan Development and Quality plans untuk menjamin kualitas software dalam pembangunan dan perencanaannya.

Dalam proses development dan quality plans harus

1. Berdasarkan pada proposal yang terupdate
2. Harus lebih detail dan komprehensiv dibandingkan dengan proposal dalam hal
1. Jadwal
2. Biaya
3. Waktu
4. Resource, dll

Dalam Development plants terdapat beberapa element yang harus diperhatikan :

1. Project products
2. Project interfaces
3. Project methodology and development tools
4. SW development standards and procedures
5. The mapping of the development process.( proj. mgt. Gant )
6. Project milestones ( documents , code , report )
7. Project staff organization ( org. stru., prof. req., no of team mem., names of team leaders )
8. Development facilities ( SW, HW tools, space, period req. for each use )
9. Development risks ( see next slide )
10. Control methods
11. Project cost estimation

Semua item tersebut Include pada 9 knowledge area di Project Management

Selain itu terdapat pula elemen-elemen yang perlu diperhatikan dalam membuat Quality Plan, yaitu :

1. Tujuan kualitas (Quality Goal)
2. Merencanakan aktifitas review
1. Tipe
2. Scope
3. jadwal (prioritas)
4. Spesifikasi prosedur yang akan dilaksanakan
5. sapa yang bertanggung jawab
3. Merencanakan pengujian software
1. Unit test, integration dll
2. Rencana pengujian
3. Prosedur yang spesifik
4. Siapa yang bertanggung jawab
4. Rencana pengujian untuk pengembang eksternal
5. Manajemen konfigurasi

Software Testing

Software testing digunakan untuk menganalisa apakah software telah sesuai dengan requirement yang ada.
Pada umumnya ada 2 tipe software testing yaitu white box testing dan black box testing. Dimana black box testing digunakan untuk validasi sedangkan white box tetsing digunakan untuk verifikasi.

Software Testing

Document Control

Document Control digunakan untuk mengelola dan mengendalikan semua dokumentasi perusahaan, sehingga memastikan kepatuhan terhadap peraturan yang relevan.
Document Control juga memungkinkan untuk mengidentifikasi kasus ketidakpatuhan sehingga ini dapat ditangani dengan efektif dan cepat.
Berikut adalah materi terkait Document Control dari Galin,

Document Control

Configuration Management

Software Configuration Management bertujuan untuk melakukan identifikasi perubahan, mengendalikan perubahan, memastikan perubahan dilaksanakan, memberitahu perubahan pada semua pihak terkait.
Berikut adalah materi terkait tentang software configuration management.
Software Configuration Management

Bagaimana Menghitung Function Point

Mengerti Function Point

Untuk mengetahui ukuran software yang akan dibuat sangat penting karena akan berpengaruh pada biaya dalam produksi software tesebut. 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.

Function Point dikembangkan pertama kali oleh Allan J. Albrecht di pertengahan tahun 1970-an. Merupakan upaya untuk mengatasi kesulitan yang berhubungan dengan kode program sebagai ukuran dari ukuran perangkat lunak, dan untuk membantu dalam memprediksi effort dalam development perangkat lunak.

Function Point adalah sebuah sebuh teknik terstruktur dalam memecahkan masalah dengan cara memecah sistem menjadi komponen yang lebih kecil dan menetapkan beberapa karakteristik dari sebuah software sehingga dapat lebih mudah dipahami dan dianalisis.

Function Point mengukur dari perspektif Functional dari software yang akan dibangun, terlepas dari bahasa programaan, metode development atau platform perangkat keras yang digunakan,

Function Point harus dilakukan oleh orang terlatih dan berpengalaman dalam development software, karena dalam memberikan nilai-nilai dari setiap komponen Function point bersifat subyektif, dan akan wajar apabila hasil perhitungan function point seseorang akan berbeda dengan yang lain.

Pengerjaan Function poin harus dimasukkan sebagai bagian dari rencana proyek secara keseluruhan. Artinya harus dijadwalkan dan direncanakan pengerjaannya.

Hasil dari pengukuran menggunakan Function Point dapat digunakan untuk mengestimasi biaya dan effort yang diperlukan dalam development perangkat lunak.

Tahapan Menghitung Function Point

Selanjutnya akan langsung implementasi pada contoh soal.

 

Langkah pertama : 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. Dimana terdapat 5 komponen yaitu :

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

Dalam soal telah di definisikan 5 komponen tersebut, sehingga selanjutnya dapat dilakukan pembobotan perpointnya dengan ketentuan 30% simple, 40% complex dan 30% average. untuk lebih jelasnya seperti gambar dibawah ini.

 

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

Langkah Kedua : 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 

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

namun pada case study diatas nilai RCAF telah diketahui, yaitu 547

TAHAP 3 : Menghitung Function Point (FP)

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

Rumus FP

• FP = CFP x (0.65 + 0.01 x RCAF)

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

Sehingga dalam study kasus tersebut Function Pointnya adalah
FP = 547 x (0.65 + 0.01 x 547) = 667,34

Staff Training and Certification

Training dan Sertifikasi merupakan salah satu tools yang digunakan untuk membantu penjaminan kualitas perangkat lunak, terdapat beberapa tujuan dalam pelaksanaan training dan sertifikasi ini, yaitu :

1. Mengembangkan pengetahuan dan keterampilan staf baru yang dibutuhkan untuk melakukan pengembangan perangkat lunak & pemeliharaan.
2. Menjamin kesesuain standrt organisasi dengan produk.
3. Update kemampuan dan pengetahuan staff lama.
4. Mentransfer pengetahuan tentang SQA.

Profesi-profesi yang membutuhkan training dan sertifikasi adalah,

1.   System Analys
2.   Programmer
3.   software development team leader
4.   programming team leader
5.   software maintenance technician
6.   software tester
7.   software testing team leader

Pelaksanaan training dan sertfikasi tentunya tidak dapat dilakukan sembarangan, hal ini harus melalui proses. terdapat 8 proses dalam training dan sertifikasi. pada tiap-tiap proses ini terdapat poin-poin penting. Untuk lebih jelasnya akan saya jelaskan dalam mind map berikut:

 

Untuk lebih jelasnya dapat diunduh dilink berikut Staff Training & Certification Mind Map

Supporting Quality Device in SQA

Dalam Penjaminan Kualitas Perangkat lunak terdapat tools-tools pendukung penjaminan kualitas.

tools tools tersebut digunakan untuk mempermudah proses dokumentasi perangkat lunak. Terdapat 2 tools yang umumnya digunakan, yaitu :

1. Template. Format dokumen yang berbentuk seperti daftar isi yang dibuat oleh organisasi untuk keperluan penyusunan pembuatan laporan atau dokumen.
2. Checklist. Daftar item yang dibuat untuk setiap tipe dokumen atau list kegiatan yang disiapkan untuk mengukur dan memeriksa kekomplitan sebuah aktivitas.

Tools tersebut memiliki kegunaan masing-masing. Namun seperti fungsinya membantu penjaminan kualitas tools tersebut juga memiliki kendala-kendala yang umum terjadi. Kadang suatu organisasi kurang menyadari pentingnya penggunaan template untuk mempermudah dan menyamakan dokumentasi antar tim, sehingga kebanyakan dari mereka tidak memanfaatkan dengan baik template yang tela disediakan. Ini adalah salah satu kekurangan dari penggunaan template, dan ini juga yang menjadi tanggung jawab dalam SQA Unit yaitu mengenalkan penggunaan template yang digunakan kepada seluruh tim organisasti.

Untuk lebih jelasnya telah saya rangkum dalam mindmap sebagai berikut :

 

Dari gambar tersebut telah dijelaskan apa pengertian dari template dan checklist, kelebihan, fungsi tantangan dan peran dalam SQA. Untuk lebih jelasnya dapat diunduh pada link Supporting Quality Device in SQA .

Mengenal Requirement Traceability Matrix

Pengertian RTM

Requirement Treacibility Matrix ialah tabel yang berisi daftar requirements, atribut yang bervariasi untuk setiap requirement, dan status dari requirement untuk memastikan semua requirement telah terpenuhi.

Konsep Traceability Matrix adalah menelusuri Implementasi pada Top Level Requirement dan pengujian terhadap Top Level Requirement tersebut :

Tracebility matrix berbentuk tabel yang berfungsi untuk menelusuri requirement dalam melakukan pengetesan untuk memverifikasi apakah requirement sudah terpenuhi.

Matrix menghubungkan high level requirements, design specifications, test requirements, and code files. Dibuat berupa map dengan menyediakan link-link yang mampu menelusuri informasi requirement yang dibutuhkan.

Reqirement Treacibility Matrix digunakan dalam Quality Assurance sehingga dapat memastikan bahwa kebutuhan klien terpenuhi, dan perangkat lunak sesuai dengan yang diminta.

Bagaimana membuat RTM yang baik?

Kesuksesan project tidak akan tercapai tanpa manager proyek yang memiliki kemampuan organisasai yang baik. Dokumentasi requirement klien yang baik akan sangat membantu pengerjaan proyek. Manager yang baik harus mempu mengidentifikasikan requirement yang berhasil ataupun berpotensi gagal. Requirement treacibility matrix merupakan salah satu tools yang berguna untuk menelusuri informasi requirement.

Berikut langkah-langka pembuatan RTM :

1. Buat template RTM. Developer dapat membuat template sendiri maupun menggunakan template yang tersedia di internet. Berikut salah satu contoh template yang umum digunakan dalam pembuatan RTM,

Untuk lebih jelasnya dapat diunduh di link berikut Template Requirement Traceability Matrix  

2.  Salin Business Requirement dari dokumen project. Identifikasikan business requirement sesuai dengan requirement yang telah dibuat.

3. Identifikasikan requirement dengan ID yang unik. ID seharusnya sudah diidentifikasikan untuk digunakan berkelanjutan dalam pembuatan RTM ini.

4. Copy Use Case ID ke RTM.

5. Inputkan System Requirement Specification (SRS) ke dalam treacibility matrix. hal ini digunakan untuk melacak kebutuhan bisnis ke kebutuhan sistem.

6. Inputkan data testing ke dalam treacibility matrix.

7. Review data. Matrix seharusnya sudah menunjukkan keterhubungan requirement ke hasil pengujian. Jika RTM sudah dapat dilakukan ketelusuran maka matrix sudah dikatakan berhasil. 

Sumber

RTM Case Study

Namun pada kenyataannya RTM sangat membingungkan untuk dibuat, RTM mengharuskan dibuat untuk pembaca awam lebih mudah memahami.

Berikut adalah RTM yang telah saya buat dengan study kasus Rancang Bangun Sistem Informasi Penilaian Kepegawaian Fakultas Teknologi Informasi.

 

Konten-konten RTM pada umumnya :

1. Introduction yang berisi tata cara penomeran. Hal ini difungsikan petunjuk bagi user untuk pembacaan dokumen RTM.

2. RTM, terdiri dari tabel-tabel yang dibuat tracea (menelusur) 

3. Business Requirement project

4. Functional Requirement project

Untuk lebih lengkapnya dapat diunduh dilink berikut

Requirement Traceability Matrix Rancang Bangun Sistem Informasi Penilaian Kepegawaian Fakultas Teknologi Informasi

Untuk penjelasannya agar lebih mudah dipahami dapat dibaca di laporan RTM, dapat diunduh di link berikut :

Laporan RTM Rancang Bangun Sistem Informasi Penilaian Kepegawaian Fakultas Teknologi Informasi

Arsitektur SQA

Komponen SQA sistem

Komponen SQA sistem diklasifikasikan sebagai berikut :

•          Komponen Pra-Proyek

•          Komponen Siklus Hidup Proyek Kegiatan Penilaian

•          Komponen Infrastruktur Pencegahan Kesalahan dan Perbaikan

•          Komponen Manajemen Kualitas Perangkat Lunak

•          Komponen Standardisasi, Sertifikasi dan Penilaian Sistem SQA

•          Mengorganisir SQA – Komponen Manusia

Berikut adalah Arsitektur komponen SQA Sistem :

Dari Gambar tersebut dijelaskan sebagai berikut :

1.       Komponen Pra-Proyek

Merupakan langkah persiapan sebelum melakukan proyek, terdapat beberapa langkah yang harus dilakukan tim developer agar terjamin kualitas software:

•          Contract Review

Aktifitas kontak review:

•          Klarifikasi kebutuhan pelanggan

•          Review jadwal proyek dan perkiraan kebutuhan sumber daya

•          Evaluasi kapasitas staf profesional untuk melaksanakan proyek

•          Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya

•          Evaluasi risiko pengembangan.

•          Development and Quality Plans

Isu utama dalam rencana pengembangan proyek :

•          Jadwal

•          Tenaga kerja yang diperlukan dan sumber Hardware

•          Evaluasi Resiko

•          Keorganisasian : anggota tim, subkontraktor dan kemitraan

•          Metodologi proyek, perangkat pengembangan,dll

•          Penggunaan kembali rencana software

Isu utama dalam rencana kualitas proyek :

•          Tujuan Kualitas

•          Kriteria awal dan akhir setiap tahap proyek

•          Daftar review, tes dan jadwal verifikasi lainnya serta kegiatan validasi

2.       Komponen Siklus Hidup Software Proyek

Komponen utama :

1.       Review

·         Formal Design Review, berupa Daftar Koreksi yang diperlukan (Action Items)

Diperiksa oleh Komite-komite yang terdiri dari :

•          Pemimpin Proyek

•          Manajer Departemen

•          Ketua Insinyur Software

•          Ketua Departemen terkait

•          Peer Review

Dilakukan dengan tujuan Mendeteksi kemungkinan kesalahan dari banyak design dan pemrograman. Namun apa saja yang di Review?

–        Dokumen singkat

–        Bab / bagian pada laporan

–        Printout kode dari modul software

Dari Review tersebut nantinya akan menghasilkan output sebagai berikut:

–        Daftar Kesalahan yang terdeteksi

–        Ringkasan Kerusakan dan Statistik

2.       Pendapat Ahli

Memperkenalkan kemampuan eksternal tambahan ke dalam proses in-house development organisasi. Para ahli dibutuhkan pada beberapa situasi :

•       Kurangnya kemampuan profesional in-house pada daerah tertentu

•       Sulitnya menemukan calon yang cocok untuk berpartisipasi dalam tim design review

•       Dalam situasi yang ditandai dengan tekanan pekerjaan ekstrim, pendapat ahli dapat menggantikan inspeksi

•       Profesional in-house yang tidak dapat diakses sementara

•       Dalam kasus perselisihan besar di antara senior profesional organisasi, ahli eksternal dapat mendukung keputusan

3.       Pengujian Software

Tes software komponen SQA yang resmi untuk meninjau jalannya software yang sebenarnya. Pengujian dilakukan pada :

•       Modul Software

•       Integrasi Software

•       Paket keseluruhan Software (Sistem)

Tujuan dilakukannya pengujian ini adalah:

•       Mendeteksi kesalahan software dan kegagalan lainnya

•       Persetujuan formal dari modul atau setup integrasi

4.       Pemeliharaan Software

Layanan pemeliharaan software dikategorikan sebagai berikut :

•       Pemeliharaan Korektif

•       Koreksi kesalahan perangkat lunak dan kegagalan

•       Pemeliharaan Adaptif

•       Mengadaptasi software saat ini untuk keadaan tambahan tanpa mengubah software

•       Pemeliharaan Fungsi Perbaikan

•       Peningkatan dan perbaikan software

Komponen Pra-Perawatan

•       Pemeliharaan review kontrak

•       Pemeliharaan rencana

Komponen Infrastruktur SQA

•       Pemeliharaan prosedur dan instruksi

•       Perangkat pendukung kualitas

•       Pemeliharaan pelatihan staf, pelatihan ulang dan sertifikasi

•       Pemeliharaan tindakan pencegahan dan perbaikan

•       Konfigurasi Manajemen

Komponen Manajerial Kontrol SQA

•       Pemeliharaan layanan kontrol

•       Pemeliharaan Kualitas metrik

•       Pemeliharaan biaya kualitas

5.       Jaminan Kualitas pekerjaan subkontraktor dan bagian persediaan customer

3.       Komponen Infrastruktur untuk pencegahan kesalahan dan perbaikan

Tujuan : Menghilangkan atau setidaknya mengurangi tingkat kesalahan berdasarkan akumulasi pengalaman organisasi SQA

Komponen SQA ini meliputi :

•          Prosedur dan instruksi kerja

• Procedure : Perencanaan yang berlaku secara umum dan untuk melayani                seluruh organisasi

•    Work Instruction : Petunjuk rinci untuk penggunaan metode yang diterapkan                pada tiap kasus unik dan dikerjakan oleh tim khusus

•          Template dan checklist

Merupakan perangkat kualitas pendukung yang didasarkan pada pengetahuan dan pengalaman organisasi

        Kegunaan perangkat ini adalah :

–        Menyimpan waktu yang dibutuhkan untuk mendefiniskan struktur dari berbagai dokumen

–        Berkontribusi untuk kelengkapan dokumen dan review

–        Meningkatkan komunikasi antara tim pengembang dan review anggota komite dengan standardisasi dokumen dan agenda

•          Pelatihan staf, pelatihan ulang, dan sertifikasi

Pelatihan staf, instruksi dan sertifikasi          

        SDM 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.

•          Pencegahan dan tindakan korektif

Pencegahan dan tindakan korektif

        Penelitian sistematis berdasarkan data yang dikumpulkan dari kegagalan dan kesuksesan proses SQA, dapat di list sebagai berikut :

–        Implementasi perubahan yang mencegah kegagalan serupa di masa depan

–        Koreksi kesalahan serupa yang ditemukan di proyek lain atau kegiatan lain

–        Menerapkan metodologi yang terbukti sukses untuk meningkatkan probabilitas ulangan keberhasilan

•          Konfigurasi manajemen

•          Kontrol Dokumentasi.

Untuk memberikan bukti kinerja sistem SQA. Berisi informasi penting untuk jangka panjang pengembangan dan pemeliharaan sistem software, seperti hasil pengujian software, desain review, laporan masalah dan laporan audit. Kegiatan kontrol dokumentasi ini memerlukan :

–        Definisi jenis kontrol dokumentasi yang diperlukan

–        Spesifikasi format, metode identifikasi, dll

–        Definisi proses review dan persetujuan untuk setiap kontrol dokumen

–        Definisi metode penyimpanan arsip

4.       Komponen Manajemen SQA     

Bertujuan menjadi kontrol pengembangan dan pemeliharaan kegiatan serta pengenalan awal manajerial untuk mencegah atau meminimalkan jadwal dan anggaran kegagalan.

Komponen Kontrol Meliputi :

•          Proyek kemajuan kontrol

–        Untuk mendeteksi munculnya situasi yang menyebabkan penyimpangan dan rencana proyek dan kinerja pemeliharan layanan

•          Metrik kualitas software

–        Pengukuran SQA untuk kualitas fungsional, produktivitas dan aspek organisasi proyek

•          Biaya kualitas software

–        Biaya pengendalian dikombinasikan dengan biaya kegagalan, sehingga terdapat kesiapan manajemen untuk mengalokasikan dana atau dengan mengefisienkan anggaran.

5.       Komponen SQA standar, sistem sertifikasi, dan penilaian.

Pada komponen ini bertujuan :

1.       Pemanfaatan pengetahuan profesional internasional.

2.       Peningkatan koordinasi dengan sistem mutu organisasi lain .

3.       Evaluasi profesional tujuan dan pengukuran prestasi.

SQA Standar diklasifikasikan menjadi :

•          Manajemen kualitas standar

Organisasi mendapatkan manfaat dari standar mutu manajemen pengembangan software, pemeliharaan dan infrastruktur. Fokus pada apa yang diperlukan dan memberikan keputusan tentang “bagaimana” cara mencapainya bagi organisasi.Organisasi yang memenuhi kualitas dapat memperoleh sertifikasi SQA. Contoh jenis standarnya adalah :

–        SEI CMM standar penilaian

–        ISO 9001 dan ISO 9000-3 standar

•          Proses proyek standar

Standar profesional yang menyediakan metodologi pedoman (berhubungan dengan pertanyaan “bagaimana”) untuk pengembangan tim. Contoh jenis standarnya :

–        IEEE 1012 standar

–        ISO / IEC 12207 standar

6.       Pengorganisasian untuk SQA – komponen manusia

Tujuan utama dari pengorganisasian SQA adalah :

1.       Untuk mengembangkan dan mendukung pelaksanaan komponen SQA.

2.       Untuk mendeteksi penyimpangan dari prosedur SQA dan metodologi.

3.       Untuk menunjukkan perbaikan komponen SQA.

Manajemen peran dalam SQA

Tanggung jawab manajemen puncak, departemen dan manajemen proyek, guna:

1.       Definisi dari kebijakan kualitas

2.       Menindak lanjut secara efektif dari penerapan kebijkan kualitas

3.       Alokasi sumber daya yang cukup untuk melaksanakan kebijakan kualitas

4.       Penugasan staf yang memadai

5.       Menindak lanjut kepatuhan prosedur jaminan kualitas

6.       Memberikan solusi dari jadwal, anggaran dan kesulitan hubungan pelanggan

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.

SQA wali , komite dan forum

·   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

7.       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