Apa saja komponen penyusunan Arsitektur SQA?

Arsitektur SQA

 Dari Arsitektur SQA tersebut dapat diklompokkan 6 komponen sistem SQA, yaitu:

1.       Pre-project components

2.       Software project life cycle components

3.       Infrastructure components for error prevention and improvement

4.       Management SQA components

5.       SQA standards, system certification, and assessment components

6.    Organizing for SQA – the human components

Berikut penjelasan masing-masing komponen diatas:

1.       Pre-project components

Merupakan langkah awal sebelum memulai proyek, yang harus dilakukan oleh pengembang yaitu:

 ·       Contract review

Bertujuan untuk mengembangkan software melalui kerangka negosiai kontrak dengan pelanggan. Sehingga melalui Review kontrak dapat disepakati kebutuhan apa yang diperlukan dalam proses pengembangan perangkat lunak.

Aktifitas kontak review, meliputi:

o   Klarifikasi kebutuhan pelanggan

o   Review jadwal proyek dan perkiraan kebutuhan sumber daya

o   Evaluasi kapasitas staf profesional untuk melaksanakan proyek

o   Evaluasi kapasitas pelanggan untuk memenuhi kewajibannya

o   Evaluasi risiko pengembangan.

·       Development and quality plans

Setelah proposal proyek selesai ditinjau, lalu kontrak telah di tandatangani. Maka tahap selanjutnya menyusun Development and quality plans. Berikut merupakan hal-hal yang harus dipersiapkan:

Tantangan utama dalam mengatur pengembangan proyek , yaitu:

·         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

Tantangan utama dalam mengatur rencana kualitas proyek, yaitu :

·         Pencapaian akhir kualitas

·         Kriteria awal dan akhir setiap tahap proyek

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

2.       Software project life cycle components

Pada komponen ini terbagi menjadi 2 tahap yaitu tahap pengembangan siklus hidup dan tahap operasi dan pemeliharaan. Berikut merupakan komponen utama yang harus direncanakan sebelum masuk ke dalam tahap inisiasi

1.          Review

Pada tahap ini mencakup review laporan desain, dokumen testing software, perencanaan instalasi software, user manual, dll.

Review dikategorikan menjadi 2 yaitu:

·        Formal design reviews (DRs)

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

Diperiksa oleh Komite-komite yang terdiri dari :

o   Pemimpin Proyek

o   Manajer Departemen

o   Ketua Insinyur Software

o   Ketua Departemen terkait

·       Peer reviews

Merupakan elemen penting yang dapat memberikan pertimbangan dan timbal balik karena ada saling pertukaran pendapat sebagai acuan untuk melangkah ke depannya. Peer Reviews dilakukan dengan tujuan Mendeteksi kemungkinan kesalahan dari banyak design dan pemrograman. Berikut merupakan hal-hal yang perlu di Review:

o Dokumen singkat

o Bab / bagian pada laporan

o Printout kode dari modul software

o Dari Review tersebut nantinya akan menghasilkan output sebagai berikut:

o Daftar Kesalahan yang terdeteksi

o 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

Pada tahap ini meliputi pengujian terhadap 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 yaitu untuk Mendeteksi kesalahan software dan kegagalan lainnya. Selain itu, untuk 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, terdiri dari:

•        Pemeliharaan review kontrak

•        Pemeliharaan rencana

Komponen Infrastruktur SQA, terdiri dari:

•        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, terdiri dari:

•        Pemeliharaan layanan kontrol

•        Pemeliharaan Kualitas metrik

•        Pemeliharaan biaya kualitas

5.         Jaminan Kualitas pekerjaan subkontraktor dan bagian persediaan customer

Pada tahap ini dibutuhkan upaya pemjaminan kualitas sebagai kontrol kualitas yang efektif. karena semakin komplek proyek maka dibutuhkan kontrak review yang ditandatangani semua pihak yang terlibat, antara lain: Subkontraktor, pihak pemasok software(COTS) dan pelanggan.

3.       Infrastructure components for error prevention and improvement

Komponen Infrastruktur untuk pencegahan kesalahan dan perbaikan bertujuan untuk  Menghilangkan/mengurangi tingkat kesalahan software. komponennya terdiri dari :

•        Prosedur dan instruksi kerja

•        Template dan checklist

•        Pelatihan staf, pelatihan ulang, dan sertifikasi

•        Pencegahan dan tindakan korektif

•        Konfigurasi manajemen

•        Kontrol Dokumentasi.

4.       Management SQA components

Komponen Manajemen SQA ini bertujuan menjadi kontrol pengembangan dan pemeliharaan kegiatan.

Komponen Kontrol Meliputi :

•        Proyek kemajuan kontrol

•        Metrik kualitas software

•        Biaya kualitas software

5.       SQA standards, system certification, and assessment components

komponen memiliki tujuan, yaitu :

·         Pemanfaatan pengetahuan profesional internasional.

·         Peningkatan koordinasi dengan sistem mutu organisasi lain .

·         Evaluasi profesional tujuan dan pengukuran prestasi.

Berikut merupakan beberapa acuan standart, yaitu:

·         Manajemen kualitas standart, meliputi:

o   SEI CMM Standart penilaian

o   ISO 901 dan ISO 9000-3 standart

·         Proses Proyek Standart, meliputi:

o   IEEE 1012 Standart

o   ISO/IEC 12207 Standart

6.       Organizing for SQA – the human components

komponen ini termasuk dalam manajemen organisasi, software testing personal dan SQA Unit. Tujuan utamanya yaitu:

·         Mengembangkan dan mendukung pelaksanaan komponen SQA.

·         Mendeteksi penyimpangan dari prosedur SQA dan metodologi.

·         Menunjukkan perbaikan komponen SQA.

Mengenal Requirement Traceability Matrix

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

Tracebility matrix berbentuk tabel yang digunakan untuk menelusuri requirement dalam melakukan testing untuk memverifikasi apakah requirement sudah terpenuhi atau belum. Matrix menghubungkan high level requirements, design specifications, test requirements, and code files. Matrix tersebut berupa map dengan menyediakan link-link yang mampu menelusuri informasi requirement yang dibutuhkan. RTM digunakan untuk penjaminan kualitas software sehingga dapat memastikan bahwa kebutuhan klien terpenuhi, dan perangkat lunak sesuai dengan yang diminta oleh klien.

berikut merupakan contoh dari RTM

buka link dibawah ini untuk mengetahui Langkah-langkah membuat RTM

http://www.ehow.com/how_2077277_create-requirements-traceability-matrix.html

Referensi

http://sib-a.com/download/semester5/mpsi/bab_5.pdf

http://www.ieee.li/tmc/traceability_matrix_sample.pdf

http://www.ehow.com/how_2077277_create-requirements-traceability-matrix.html

Apa saja penyebab error pada software?

Klasifikasi penyebab Software Error

Software error menyebabkan kualitas software yang jelek. software error dapat terjadi karena:

·         Code error

·         Procedure error

·         Documentation error

·         Software data error

 9 penyebab software Error

1.     Kesalahan mendefinisikan kebutuhan

Biasanya penyebab dari kesalahan mendefinisikan kebutuhan yaitu,

·         Keliru dalam definisi persyaratan

·         Tidak adanya persyaratan penting

·         Definisi persyaratan tidak lengkap

·         Pencantuman persyaratan yang tidak perlu

2.     Ada kesalahpahaman antara client dan developer

Biasanya penyebab dari Ada kesalahpahaman antara client dan developer, yaitu:

·         Kesalahpahaman akibat komunikasi yang cacat antara klien-developer

·         Kesalahpahaman perubahan kebutuhan klien yang disampaikan kepada pengembang, seperti:

o   Dalam bentuk tertulis

o   secara lisan

o   Tanggapan terhadap masalah-masalah desain,dll 

3.     Penyimpangan dari Requirement yang telah dibuat

Biasanya penyebab dari Penyimpangan dari Requirement yang telah dibuat, yaitu:

·         Para pengembang menggunakan kembali modul Software yang diambil dari proyek sebelumnya

·         Karena tekanan waktu anggaran

·         Karena perbaikan tidak disetujui

4.     Salah melogikakan kebutuhan

Biasanya penyebab dari Salah melogikakan kebutuhan, yaitu:

·          Jenis kesalahan biasanya datang dari arsitek sistem, analis sistem, SW Engineer

·          kesalahan umum termasuk:

a) kesalahan dalam membuat Algoritma yang mewakili persyaratan Software

b) Kesalahan mendefinisi Proses yang mengandung pengurutan

c) Keliru dalam definisi kondisi batas

d) Kelalaian dari yang dibutuhkan software sistem 

5.     Coding Error

Biasanya penyebab dari Coding Error, yaitu:

·         Ketidakpahaman dokumentasi desain

·         Kesalahan Linguistik dalam bahasa pemrograman

·         Kesalahan dalam pemilihan data

6.     Ketidaksesuaian antara dokumentasi dan koding

Biasanya penyebab dari Ketidaksesuaian antara dokumentasi dan koding karena Kesalahan yang disebabkan  kesulitan:

·         untuk berkoordinasi dengan modul kode yang dikembangkan oleh tim yang tidak memenuhi

·         untuk sepenuhnya memahami pekerjaan yang dihadapi oleh individu yang menggantikan posisi anggota tim yang tidak memenuhi

·         untuk meninjau desain yang disusun oleh tim yang tidak memenuhi

·         memahami SW dan dokumentasinya ketika pengguna menemukan bug dan pengembang mencoba untuk mengubah SW yang ada

7.     Kekurangan dari proses testing

Biasanya penyebab dari Kekurangan dari proses testing, yaitu:

·         rencana pengujian yang tidak lengkap

·         Kegagalan karena kesalahan dokumen dan laporan

·         Kegagalan untuk segera memperbaiki Software Error yang  terdeteksi sebagai akibat dari indikasi yang tidak tepat alasan untuk Error.

·         ketidak lengkapan koreksi dari pendeteksian Error

8.     Procedures Error

Biasanya penyebab dari Procedures Error, yaitu kesalahan dalam mendefinisikan kegiatan yang harus diambil oleh pengguna. Misalnya kesalahan dalam mengurutkan procedures.

9.     Dokumentasi Error

Biasanya penyebab dari Dokumentasi Error, yaitu kesalahan dalam mendesain dokumen dan user manual

Apa itu Software Quality?

Software Quality adalah  Tingkat dimana suatu sistem, komponen, atau proses memenuhi persyaratan yang ditentukan sesuai dengan kebutuhan pelanggan atau harapan pengguna (IEEE)

 Software  terdiri dari 4 komponen (IEEE & ISO):

1.       Computer program ("Kode")

2.       Procedures

3.       Documentation

4.       Data Diperlukan untuk mengoperasikan sistem SW

 keseluruhan empat komponen penting untuk menjamin kualitas dari proses pengembangan Software  dan layanan pemeliharaan Software. Sehingga jaminan kualitas Software (SQA) selalu mencakup:

·         Kualitas Kode

·         Kualitas prosedur

·         Kualitas dokumentasi

·         Kualitas data yang diperlukan Software

Definisi kualitas : menurut (Crosby, 1979) kualitas yaitu Kesesuaian dengan persyaratan, sedangkan (Juran, 1988) mengatakan kualitas yaitu Produk fitur yang memenuhi kebutuhan pelanggan dan dengan demikian, menghasilkan kepuasan pelanggan dan bebas dari kekurangan.

Bagaimana Keunikan dari proses pengembangan software

Terdapat Perbedaan penting Keunikan Proses Pengembangan Perangkat Lunak Software dan Produk Industri Lainnya:

1.       Product kompleksitas: banyak jutaan  kompleksitas modus operasional meningkat.

2.       Product visibilitas: Software produk tidak terlihat. Lalu dalam  produk industri Cacat mudah untuk dideteksi dan dapat dideteksi selama proses produksi.

3.       Produk development and production process : Peluang untuk mendeteksi cacat atau bug yang terbatas.

Berikut merupakan Faktor-faktor yang Mempengaruhi Deteksi Cacat di Software Product vs Industri Product

Characteristic	Software Product	Industrial Product
Complexity	Biasanya, produk yang sangat kompleks memungkinkan untuk jumlah yang sangat besar  dalam pilihan operasional	Tingkat kompleksitas yang jauh lebih rendah, sehingga paling banyak (ribu) pilihan operasional
Visibility of product	Produk tak terlihat, sehngga  sulit  untuk mendeteksi cacat atau kelalaian	Produk terlihat, memungkinkan pendeteksian cacat dapat efektif
Nature of development and production process	Peluang untuk mendeteksi cacat muncul hanya dalam satu tahap, yaitu tahap pengembangan produk	peluang untuk mendeteksi cacat muncul dalam semua tahap pengembangan dan produksi: -pengembangan produk        -produk perencanaan produksi           -Manufacturing

Kesimpulan: 

complexity yang  besar serta invisibility(tak terlihat) perangkat lunak, antara karakteristik produk lainnya, membuat pengembangan metodologi SQA dan kesuksesan implementasi merupakan tantangan yang  profesional tinggi.

Software Quality Metrics

Software quality metrics terdiri dari 2 kategori, yaitu:
1. Process Metrics
kategori ini terkait dengan proses pengembangan perangkta lunak (software development process).
Process Metrics pengembangan perangkat lunak dapat masuk ke dalam salah satu dari kategori berikut:
a. Software process quality metrics :  dapat diklasifikasikan menjadi dua kelas yaitu Error density  metrics dan Error severity metrics. Error density metrics melibatkan 2 langkah yang pertama "Software Volume" Beberapa metrik kepadatan menggunakan jumlah baris kode sementara lalu yang lain menerapkan fungsi poin (FP). kemudian langkah yang kedua "Errors counted measures" yaitu Beberapa berhubungan dengan jumlah kesalahan dan yang lain untuk jumlah bobot kesalahan.
kemudian Error severity metrics digunakan untuk mendeteksi situasi yang merugikan dari peningkatan parahnya jumlah kesalahan dalam situasi di mana kesalahan dan bobot kesalahan yang diukur dengan metrik kepadatan kesalahan umumnya menurun.
b. Software process timetable metrics : merupakan Pendekatan alternatif menghitung rata-rataketerlambatan penyelesaian milestone.
c. Error removal effectiveness metrics : dapat mengukur efektivitas dari penghapusan kesalahan  (effectiveness of error removal) oleh sistem jaminan kualitas perangkat lunak setelah periode operasi  rutin (biasanya 6 atau 12 bulan) dari sistem. Metrik yang menggabungkan catatan kesalahan dari tahap  pengembangan dengan catatan kegagalan disusun selama tahun pertama (atau periode tertentu) dari operasi rutin.
d. Software process productivity metrics : mencakup metrik "langsung" metrik yang menangani proyek produktivitas sumber daya manusia serta "tidak langsung" metrik yang fokus pada sejauh mana penggunaan kembali perangkat lunak. Penggunaan kembali perangkat lunak secara substansial mempengaruhi  produktivitas dan efektivitas.

2. Product Metrics
kategori ini terkait dengan software maintenance. kemudian susunannya diklasifikasikan sebagai berikut:
a. HD quality metrics: jenis dari HD (Help desk Service) quality metrics terdiri dari:
• HD calls density metrics-> tingkat permintaan pelanggan untuk layanan HD yang diukur dengan jumlah panggilan.
• Severity of HD calls metrics-> merupakan metrik dari keparahan masalah HD yang terangkat.
• Success of the HD services–> tingkat keberhasilan dalam menanggapi panggilan. Sebuah  kesuksesan dapat dicapai dengan melengkapi layanan yang diperlukan dalam waktu yang ditentukan dalam  kontrak layanan.
b.  HD productivity and effectiveness metrics : Productivity metrics berhubungan dengan total sumber daya yang diinvestasikan selama periode yang ditentukan, sedangkan effectiveness metrics berhubungan dengan sumber daya yang diinvestasikan dalam menanggapi HD customer call.
c.  Corrective maintenance quality metrics : menangani beberapa aspek kualitas layanan pemeliharaan yang diklasifikasikan sebagai berikut:
• Software system failures density metrics –> menangani tingkat permintaan untuk pemeliharaan korektif, berdasarkan catatan kegagalan yang diidentifikasi selama operasi normal sistem perangkat lunak.
• Software system failures severity metrics –> menangani keparahan kegagalan sistem perangkat lunak yang dilayani oleh tim pemeliharaan korektif.
• Failures of maintenance services metrics –> menangani kasus-kasus dimana layanan pemeliharaan tidak dapat menyelesaikan koreksi dari kegagalan atau bahwa koreksi yang dilakukan tersebut gagal.
• Software system availability metrics –> menangani tingkat gangguan yang terjadi pada pelanggan yang diwujudkan dengan periode waktu di mana layanan dari sistem perangkat lunak tidak tersedia atau hanya sebagian yang tersedia.
d. Corrective maintenance productivity and effectiveness metrics : berkaitan dengan total sumber daya manusia yang diinvestasikan dalam menjaga sistem perangkat lunak tertentu, corrective maintenance effectiveness berkaitan dengan sumber daya yang diinvestasikan di koreksi dari kegagalan tunggal.