CASE tools and their effect on software Quality

CASE tools and their effect on software Quality

CASE TOOLS : Tools yang terkomputerisasi untuk membantu developer pada fase software life cycle dan maintenance.

• Menyimpan semua informasi terkait project

• Menyimpan basis informasi untuk pengembangan proyek selanjutnya

• Mengenerate secara otomatis kode berdasarkan desain

Kontribsi CASE Tools untuk Software Maintenance Quality

O Corrective maintenance

O Adaptive maintenance

Memungkinkan adaptasi pada new users / sistem melalui dokumentasi

O Functional improvement maintenance

Menjamin konsistensi peningkatan sistem software saat ini

Kontribusi Case Tools Pada SQ

Cause of Software Error		Real CASE Tools
Kegagalan definisi kebutuhan		Jarang sekali pemeriksaan secara terkomputerisasi
Kegagalan komunikasi		Identifikasi kesalahan komunikasi secara terkompurisasi tidak mungkin dilakukan
Penyimpangan terhadap software reqirement		High Contribution Dideteksi dengan repository based requirement tracing tools &cross referenced query tools

Progress Checklist

Progress : 100 % Completion

No	Materi	Progress
	PART I INTRODUCTION
1	The Chalenge of Software Quality Assurance	Done
2	Software Quality Factors	Done
3	Priciples of SW Quality and Its Error Classification	Done
4	The components of the software quality assurance system – overview	Done
	Part II Pre-project software quality components
5	Contract review	Done
6	Development and quality plans	Done
	Part III SQA components in the project life cycle
7	Integrating quality activities in the project life cycle	Done
8	Reviews	Done
9	Software testing – strategies	Done
10	Software testing – implementation	Done
11	Assuring the quality of software maintenance components	Done
12	Assuring the quality of external participants’ contributions	Done
13	CASE tools and their effect on software Quality	Done
	Part IV Software quality infrastructure Components
14	Procedures and work instructions	Done
15	Supporting quality devices	Done
16	Staff training and certification	Done
17	Corrective and preventive actions	Done
18	Configuration management	Done
19	Documentation control	Done
	Part V Management components of software  Quality
20	Project progress control	Done
21	Software quality metrics	Done
22	Costs of software quality	Done
	Part VI Standards, certification and assessment
23	Quality management standards	Done
24	SQA project process standards – IEEE software engineering standards	Done
25	Management and its role in software quality assurance	Done
26	The SQA unit and other actors in the SQA system	Done

Chapter 26 The SQA unit and othe actors in the SQA system

Pada bab ini kami akan membahas tentang siapa saja orang-orang yang berada di dalam system dari SQA. Sama seperti organisasi lainnya terdiri dari pimpinan hingga sub-sub lainnya seperti gambar berikut :
Gambar SQA Unit
Seperti yang kami jelaskan sebelumnya jadi SQA sendiri memiliki pimpinan unit (head unit SQA), dan memiliki bawahan di bagian operational dan bagian pengembangan dan maintenance.

Head SQA unit
Tugas dari pimpinan terbagi menjadi 4 kategori :
- Perencanaan
- Mengelola unit dari tiap departemen (tiap unit)
- Tugas-tugas yang berhubungan dengan customer dan bagian lainnya sebagai peranan dari eksekutif  dalam kualitas software
- Sebagai bagian dari aktifitas pekerjaan SQA

Tugas perencanaan :
Pada kategori ini pemimpin melakukan 4 aktifitas seperti :
- mempersiapkan aktifitas dalam rangka program tahunan unit dan juga perencanaan budget
- Perencanaan dan pembaharuan dari system SQM
- Persiapan dari rekomendasi aktifitas SQA tahunan untuk departemen pengembangan dan maintenance
- Persiapan dari rencana pengembangan system SQA yang direkomendasi untuk departemen pengembangan dan maintenance.

Tugas mengelola :
- Mengelola aktifitas tim SQA
- Memonitoring implementasi dari program SQA
- Mempersiapkan laporan secara khusus dan periodic tentang status kualitas software berdasarkan laporan performa.

Aktifitas Profesional SQA
- Berpartisipasi didalam proyek
- Berpartisipaso pada review disain
- Mereview dan menyetujui ketika ada perubahan/penyimpangan dari spesifikasi
- Berkonsultasi pada manajer proyek dan ketua tim
- Berpartisipasi didalam forum atau komite SQA

Tugas SQA sub unit
Tugas SQA sub unit dibagi menjadi 2 yaitu :
Tugas terkait daur hidup proyek dan pengawasan
- Mengikuti perkembangan dari pengembangan dan maintenance sesuai dengan prosedur SQA
- Menyetujui dan merekomendasikan produk software sesuai dengan prosedur yang ada.
- Memonitoring penyapaian (delivery) dari layanan maintenance software kepada customer internal dan eksternal .
- Memonitoring kepuasan customer (survey, kuisioner, dll) dan selalu menjaga relasi yang baik terhadap perwakilan quality assurance customer.

Tugas partisipasi
- Mereview kontrak
- Menyiapkan dan memperbaharui perencanaan pengembangan proyek dan rencana kualitas
- Mereview desain
- Mereview desain dari sub contractor
- Testing software termasuk uji penerimanaan customer (acceptace test)
- Uji penerimaan dari software/produk sub contractor
- Instalasi produk software baru

Tugas SQA sub unit infrastructure operations
Tugas utama dari sub unit infratruktur adalah :
- Publikasi terkait versi terbaru prosedur , work instruction (instruksi), template,dan ceklist dalam bentuk hardcopy atau softcopy
- Menjalankan pelatihan dan instruksi sesuai dengan ketentuan yang berlaku dari prodedur SQA
- Memonitoring dan membantu implementasi dari prosedur SQA yang sudah direvisi
- Mengikuti perkembangan aktifitas sertifikasi staff
- Mengikuti perkembangan dari aktifitas manajemen konfigurasi
- Mengikuti perkembangan dari kesesuaian dengan dokumen prosedur dan instruksi kerja

Tugas SQA sub-unit audit dan tugas sertifikasi
Tugas utama dari sub-unit ini adalah :
- Audit internal (Fokus melihat keadaan internal unit dan juga menyiapkan laporan tahunan terkait temuan audit dan rekomendasi)
- Audit dari subcontractor dan supplier (Audit dari pihak subkontraktor dan supplier, dengan memberikan laporan untuk meningkatkan kinerja unit)
- Audit eksternal yang di evaluasi oleh lembaga audit (Lembaga tersebut akan memberikan masukan dengan tujuan untuk meningkatkan performa dalam bentuk laporan)
- Audit eksternal yang di evaluasi oleh customer (Audit yang diberikan oleh customer kepada unit untuk meningkatkan performa)

Tugas SQA sub-unit pembantu (support)
Tugas dari unit ini adalah :
- Mempersiapkan rencana proyek dan rencana kualitas
- Mereview proses staffing (perekrutan staff)
- Pengguna dari SQA system informasi
- Menentukan metodelogi yang dipake untuk mengindentifikasi resiko software, menentukan budget dan jadwal serta menentukan metrics dan biaya komponen software.

Tugas SQA sub-unit standart and procedure
- Menyiapkan lapotan tahunan untuk mengembangkan software baru
- Bertanggung jawab akan pengembangan software baru
- Mengikuti perkembangan pengembangan dan perubahan didalam standart SQA
- Melaksanakan perubahan dan beradaptasi dari prosedur
Tugas Pengembangan dan tugas maintenance
- Melakukan uji coba kualitas dan produktufitas dari pengembangan software
- Melakukan evaluasi kualitas dan produktifitas
- Mengembangkan solusi pada kesulitan ketika melakukan pengembangan software
- Mengembangkan metode baru dalam hal mengukur kualitas software dan produktifitas tim
Tugas SQA sub-unit Sistem informasi
- Mengembangkan system informasi SQA untuk memfasilitasi dan meningkatkan tiap fungsi pada proses pengembangan dan maintenance
- Memperbaharui Sistem informasi SQA
- Mengembangkan dan memaintenance internet organisasi dan website

Tugas SQA trustees
Sebagian besar tugas dari SQA trustees adalah :
- Membantu manajer unit melakukan tugas SQA
- Melaporkan ketidak sesuaian kejadian substansial dan juga sistematis
- Melaporkan kegagalan dari kualitas software kepada unit SQA
- Melakukan perubahan dan pembaharuan pada prosedur SQA dan instruksi kerja
- Melakukan peningkatan kepada keseluruhan organisasi dengan meningkatkan effisiensi dari pengembangan dan maintenance

Tugas SQA commitees
SQA comittess sebenarnya ada 2 yaitu ada yang permanen atau ad hoc(tidak permanen). Inti dari tugasnya adalah mengawasi perubahan software, tindakan pembenaran (corrective), prosedur, instruksi kerja,dan metode pengembagan software. Yang berbeda adalah yang permanen akan terus ada sedangkan ad hoc itu sementara jika ada kejadian khusus yang memerlukan perhatian lebih maka SQA ad hoc comitte akan muncul.

Tugas SQA forum
Tugas dari SQA forum berfokus kepada :
- Implementasi dan pembaharuan prosedur SQA
- Metrics kualitas
- Tindakan pembenaran (jika ada kegagalan)
- Permasalahan kualitas system
- Permasalahan dalam manajemen kualitas
Untuk peserta dari forum ini adalah keseluruhan sub unit dan juga perwakilan customer. Forum ini memfasilitasi jika terjadi permasalahan pada software baik itu masalah pengembangan , kegagalan software, dan permasalahan lainnya.

Chapter 24 SQA project process standarts- IEEE software engineering standarts

Pada  bab ini kami hanya menjelaskan secara singkat saja terkait standart yang dikeluarkan oleh IEEE. Menjelaskan konsep dari IEEE/EIA standarts 12207, secara umum :
- Penerapan dari standart dan adaptasinya dengan menyatukan semua elemen
- Penerapannya untuk semua peserta didalam siklus hidup software.
- Flexibilitas dan ketanggapan terhadap perubahan teknologi
- Keterkaitan software dengan sistemnya
- Konsistensi TQM (total management consept)
- Tidak adanya sertifikasi dari perusahaan/organisasi –si pengembang
- Sebagai acuan

Untuk konsep yang berkaitan dengan tugas :
- Terkait tentang alokasi dari tanggung jawab untuk aktifitas dan tugas
- Modularitas dari siklus hidup komponen software
- Tingkatan dari kesesuaian tugas
- Lingkungan dari tugas evaluasi

Arsitektur dari siklus hidup software terdiri 4 level dan 3 proses :
Level :
1. Proses class
2. Process
3. Aktifitas
4. Tugas
Untuk prosesnya :
1. Siklus proses primary
2. Siklus proses supporting
3. Siklus prises organisasi

Kemudian ada IEEE std 1012 terkati verifikasi dan validasi berisi tentang :
- Definisi secara keseluruhan tentang aktifitas Validasi dan Verifikasi
- Kebutuhan V&V (validasi&verifikasi) pada ranah integritas software
- Kebutuhan perspektif
- Kesesuaian dan kecocokan terhadap standart internasional
- Penggunaan metrics V&V

Ada IEEE std 1028, berfokus kepada:
- Review manajemen
- Review teknis
- Inspeksi
- Panduan
- Audit

Chapter 25 Management and Its role in sfotware quality assurance

Seperti yang telah dijelaskan juga dengan Ibu hanim tentang level dari management dan juga sesuai dengan yang dijelaskan pada buku galin ini bahwa manajemen terdiri dari 3 level :
-    Top manajement
-    Department manajement
-    Project manajement
Level 1 Top Management
Tanggung jawab dari top level manajement :
-    Memastikan kualitas dari produk dalam hal ini software dari perusahaan dan bagaimana cara memaintenance software tersebut
-    Mengkomunikasikan pentingnnya kualitas produk dan layanan sebagai tambahan kepada kepuasan pelanggan kepada semua karyawan di semua level
-    Memastikan kualitas tujuan yang telah dibuat untuk SQA organisasi dan yang ingin di capai.
-    Merencanakan dan mengawasi implementasi dari peubahan yang diperlukan untuk mengadaptasi system SQA untuk semua internal dan juga eksternal organisasi
-    Langsung terjun langsung untuk menangani permasalahan yang kritis
-    Memastikan ketersediaan sumberdaya yang dibutuhkan oleh system SQA
Adapun kebijakan dari kualitas software, harus memenuhi kebutuhan sebagai berikut :
-    Kesesuaian terhadap maksud dan tujuan perushaaan
-    Komitmen terhadap konsep SQA
-    Komitmen terhadap standart kualitas yang diadopsi organisasi
-    Komitmen untuk mengalokasikan sumberdaya yang memadai untuk SQA
-    Komitmen untuk terus mengembangkan organisasi
Untuk tanggung jawab dari Top level manajemen (executive) adalah :
-    Tanggung jawab untuk mempersiapkan program SQA tiap tahunya dan mempersiapkun budget
-    Bertanggung jawab terhadap persiapan dari perencanaan pengembangan system SQA
-    Kendali keseluruhan dari implementasi aktifitas SQA yang ritun ada setiap tahunnya dan juga kendali penuh dari proyek SQA yang baru direncanakan
-    Bagaimana cara penyampaian kepada pihak executive lainnya

Level 2:  Department , department memiliki tanggung jawab sebagai berikut :
Dibagi menjadi 2 jenis tanggung jawab,
Tanggung jawab kualitas :
-    Mempersiapkan program SQA pertahunnya dan buget, berdasarkan program yang direkomendasikan oleh unit SQA
-    Mempersiapkan perencanaan sistem SQA department, berdasarkan rekomendasi unit SQA
-    Kontrol dari performa dari aktifitas tahunan department dan proyek pengembangan
-    Menyampaikan permasalahan SQA yang ada di department ke Top level manajemen

Dari segi proyek :
-    Kontrol dari pemenuhan terhadap kualitas prosedur pemastian (assurance) di dalam unit department
-    Pendetailan hasil dari review kontrak terbaru dan persetujuan proposal pengembangan
-    Mereview dari performa tiap unit
-    Mengikuti hasil dari tes software
-    Mengikuti progress dari jadwal pengembangan software dan budget
-    Menyarankan dan membantu manajer proyek dalam menyelesaikan masalah jadwal proyek, budget dan jika ada kesulitan negosisasi terhadap customer
-    Mengikuti kualitas dari ketentuan layanan service
-    Mengikuti tiap detail dari resiko proyek dan solusinya
-    Mengikuti pemenuhan proyek dengan kebutuhan customer dan kepuasan customer
-    Menyetujui perubahan besar pada software dan perubahan yang signifikan dari spesifikasi proyek.

Level 3 tanggung jawab dari Project Manajement untuk pemastian kualitas
Manajer proyek secara garis besar bertanggung jawab terhadap semua anggota tim sesuai dengan prosedur dan instruksi yang diberikan. Dan terbagi menjadi 2 tugas utama :

Tugas professional
-    Persipan dari proyek dan rencana kualitas dan pembaharuan perencanaan
-    Berpartisipasi kedalam ranah supplier-kustomer
-    Memantau perekrutan staff secara langsung, terkait perekrutan,pelatihan, dan instruksi

Tugas manajement
-    Mereview performa aktifitas dan pembenaran, termasuk berpartisipasi didalam beberapa review saja
-    Memantau pengembangan software dan maintenance performa unit
-    Melakukan acceptance test
-    Menginstal software pada lokasi customer
-    Pelatihan SQA dan instruksi dari anggota tim proyek
-    Mengalokasikan jadwal dan sumber daya ke aktifitas proyek
-    Menangani permintaan customer dan kepuasan akan software
-    Mengebangkan resiko yang ada pada saat pengembangan

Chapter 23 Quality Management Standart

Didalam pengembagan sebuah software , kita perlu memiliki standart agar selalu menjaga konsistensi kualitas dari software yang kita buat. Sama halnya untuk QMS (Quality Management Standart) ,QMS sendiri adalah standrat yang digunakan oleh manajemen untuk mempertahankan kualitas dari segi manajemen, proses pengembangannya, hingga produknya .Secara garis besar QMS dalam konteks setrifikasi digunakan untuk :
-    Membuat kualitas dari produk dan layanan maintenance tetap terjaga (konsisten)
-    Sebagai landasan evaluasi antara customer dan supplier dalam bagian dari supplier QMS
-    Membantu pengembangan software organisasi dalam rangka meningkatkan kualitas dari QMS dan meningkatkan kepuasan customer denngan standart keluhan yang dibuat.
Sedangkan dalam konteks assessment / penilaian :
-    Memberikan tools kepada oerganisasi untuk melakukan penilaian sendiri (self-assessment) tentang seberapa baik kah mereka mendevelope sebuah program/software
-    Sebagai tool untuk meningkatkan prosess dari pengembangan dan maintenance
-    Membantu perusahaan/organisasi memilih supplier yang berpotensial (dilihat dari segi efisiensi dan effektifitas dr supplier)
-    Memberikan panduan kepada tim penilai (assessor) dalam rangka program pelatihan.
Adapun standart yang dikeluarkan oleh organisasi internasional seperti :

ISO 9001 dan ISO 9000-3
ISO 9000-3 merupakan pengebangan dari ISO 9001 dimana ISO ini memberikan standart sebagai acuan/panduan (guidelines) terkait bagaimana memanajemen organisasi dengan baik. Adapun 8 fokus dari ISO 9000-3 ini :

1.    Customer focus ( Perusahaan atau organisasi sangat mengandalkan customer sebagai penggerak roda perekonomian organisasi oleh karena itu harus mengerti kebutuhan customer-nya saat ini atau masa yang akan datang.
2.    Leadership ( Karena pepmimpin yang menentukan masa depan organisasi (visi) , maka bagaimana caranya si pemimpin ini menciptakan dan menjaga lingkungan/ usasana  sedemikian rupa agar para bawahannya selalu senang dan mampu bekerja dengan suasana tanpa ada tekanan).
3.    Involvement of people (People disini adalah orang-orang yang berada di organisasi dari top level management hingga lower management, gimana caranya ISO ini memberikan standart tentang bagaimana people ini dapat memberikan keuntungan bagi organisasi).
4.    Process approach (Memberikan panduan tentang proses yang dapat meningkatkan effisiensi dari keseluruhan aktifitas organisasi).
5.    System approach to management (Melihat system yang ada pada organisasi dengan demikian ISO dapat memberikan panduan untuk meningkatkan effisiensi dan efektifitas dari system tersebut).
6.    Continual Improvement ( Standarisasi bagaimana caranya terus meningkatkan performa perusahaan/organisasi kedepannya)
7.    Factual approach to decision making (Tentang bagaimana caranya membuat keputusan yang efektif berdasarkan informasi yang telah dianalisa)
8.    Mutual supportive supplier relationship (Tentang bagaimana cara organisasi dan supplier menjalin kerjasama yang saling menguntungkan)

Untuk mendapat pengakuan internasional perusahaan/organisasi harus mampu memenuhi 3 requirement (kebutuhan) berikut :
1.    Mengembangkan Sistem SQA perusahaan
2.    Mengimplementasikan system SQA perusahaan
3.    Sendang menjalani audit sertifikasi
Ketiga kebutuhan diatas harus dipenuhi perusahaan melalui planning yang matang dan sumberdaya yang dibutuhkan untuk melakukan aktifitas tersebut. Sebelum melakukan sertifikasi organisasi perlu melakukan survey internal seperti :
-    Mencari tahu perbandingan antara tim SQA yang bekerkerja dan hilangnnya prosedur yang dibutuhkan.
-    Mencaritahu perbandingan staff yang mengerti dan berpengetahuan yang diperlukan untuk prosedur SQA dan tool SQA
-    Perbandingan terkait dokumentasi dari pengembangan dan juga aktifitas maintenance.
-    Perbandingan atau keseimbangan terkait konfigurasi kemampuan dan implementasi system
-    Perbandingan terkait teknis dari manajerial dalam control progress proyek
-    Perbandingan terkait unit SQA organisasi dan kemampuannya
Untuk sertifikasi berikutny ada CMM dan CMMI (capability Maturity Model)
Sertifikasi ini dikembangkan oleh Carnegie Mellon University Software Engineering Institute (SEI) adalah untuk memberikan basis terkait pengembangan software.

Konsep dari CMM adalah :
-    Pengimplementasian dari manajemen yang spesifik dari manajemen kualitas software  meningkatkan kemampuan organisasi untuk mengontrol kualitas dan meningkatkan produktifitas proses.
-    Pengimplementasian 5 kevek dari CMM mampu membuat organisasi untuk mengevaluasi ketercapaian dan menentukan apa yang akan dilakukan untuk mencapai kemampuan (capability) selanjutnya.( 5 level : 1. Inisiasi, 2. Memanajemen (mengelola), 3. Mendefinisikan, 4. Mengelola secara kuantitatif, 5. Mengoptimasi ).
-    Area proses secara umum menjelaskan moden dengan “apa” yang diimplementasikan di organisasi bukannya “bagaimana”.

ISO/IEC 15504
Merupakan sertifikasi/standart terkait dengan penilaian dari proses dalam mengembangkan proses. Dikembangkan oleh ISO dan IEC (International Organization of Standardization) (International Electrotechnical Commision). Adapun area yang dinilai :
-    Customer-Supplier (CUS)
-    Engineering (ENG)
-    Support (SUP)
-    Management (MAN)
-    Organization (ORG)

Dibuatnya ISO/IEC 15504 agar :
-    Mengharmonisasikan dari metodelogi penilaian independen dengan cara memberikan framework(kerangka) konsep berdasarkan “apa” bukan “ bagaimana “.
-    Menuniversalkan kemampuan kepada semua kategori dari supplier software dan customer dari organisasi sama halnya juga dengan kategori software.
-    Profesionalisme
-    Mendapat pengakuan dari dunia

Chapter 22 Cost of Software Quality

Pada bab ini, kami akan menjelaskan tentang biaya-biaya yang dikeluarkan ketika pengembangan software termasuk biaya kegagalan dalam bentuk metrics perhitungan. Tujuan pembuatan metrics ini adalah :
-    Sebagai bentuk pengawasan terkait pengeluaran perusahan
-    Mengevaluasi kerusakan terkait perekonomian yang di timbulkan oleh kegagalan software untuk memberi masukan dalam perencanaan budget SQA.
-    Sebagai perencanaan evaluasi untuk meningkatkan atau malah menurunkan kegiatan SQA atau sebagai investasi terbaru dari SQA infrastructure* dengan melihat performa keuangan sebelumnya.
*SQA infrastructure (kerangka dari SQA seperti kebijakan(policy), portofolio, work instructure, dsb)

Pada bab ini akan membahas 2 biaya :
1.    Biaya control/pengawasan (Cost of Control)
Adalah sebuahsebuah biaya yang dikeluarkan pada saat melakukan tindakan pencegahan dan pendeteksian dari error software untuk meminimalisir sampai batas penerimaan (acceptance).
Biaya control terbagi menjadi 2 :    
a.    Prevention Cost
Kalau dilihat dari namanya adalah sebuah biaya yang dikeluarkan untuk pencegahan error dari software yang dikembangkan.
b.    Apprisal Cost
Sesuai dengan namanya yaitu pengeluaran biaya pada saat pendeteksian error.

2.    Biaya kegagalan dari control/pengawasan  (Cost of failure of control )
Adalah biaya yang dikeluarkan pada saat gagal melakukan pengawasan(control) dan pendektesian error.

Biaya kegagalan control (cost of control) terbagi menjadi 2:
a.    Internal failure (kegagalan internal)
Adalah biaya yang dikeluarkan ketika melakukan review desain, tes software, dan tes penerimaan(acceptance) oleh customer dan harus selesai sebelum di instal oleh customer. Termasuk biaya pada saat mendisain ulang , biaya memprogram ulang , dan biaya pada saat melakukan tes ulang setelah melakukan perbaikan.
b.    External failure cost (kegagalan eksternal)
Adalah ke semua biaya yang dikeluarkan dalam proses perbaikan kegagala (failure) yang diidentifikasi oleh pelanggan atau tim maintenance sebelum software tersebut di instal. Eksternal failure cost meliputi penanganan keluahan pelanggan dan perbaikan selama masa garansi ataupun telah berakhir, pada saat melakukan pembenaran/perbaikan dari bug selama proses maintenance (regular operation), membayarkan biaya kepada customer terkait kegagalan software pada saat digunakan oleh customer, dan membayarkan asuransi terkait klaim terkait kegagalan software sebagai bentuk kompensasi kepada pelanggan.

Dibawah ini terdapat grafik sebagai ilustrasi dari biaya dari konsep keseimbangan kualitas dan relasi antara control/pengawasan dan kegagalan dari biaya control untuk semua level kualitas.

Grafik cost of software quality balance by quality level

Dapat kita lihat, software tersebut dikatakan optimal jika berada garis yang bertitik-titik. Dapat kita lihat untuk level kualitas , yang paling bagus adalah berada di tengah tengah tidak kurang atau tidak lebih, begitu juga dengan biaya dari kualitas berada di tengah-tengah pula. Seperti yang kita ketahui jika terlalu bagus juga tidak baik pasti ada sesuatu yang kita abaikan, jika ada yang kurang apa lagi untuk itu perlu adanya keseimbangan.

Kekurangan dari penerapan metrics cost of software quality
-    Ketidak akuratan dan/atau ketidak lengkapan pengidentifikasian dan klasifikasi dari biaya qualitas
-    Pengabaian pelaporan oleh member tim dan lainnya
-    Ketidaktepatan pelaporan dari biaya software, khususnya biaya internal (yang biasa taboo untuk di bahas) dan biaya eksternal.
-    Ketidaktepatan pencatatan dari baiaya kegagalan eksternal terhadap customer terkait biaya kompensansi yang diberikan kepada customer pada saat proses perbaikan software. Jadi pada saat melakukan klaim, permasalahan yang dilaporkan tidak dicatat namun diberikan kompensasinya begitu saja.

Chapter 21 Software Quality Metrics

Pada pembahasan kali ini kami hanya akan membahas teori secara garis besarnya saja untuk rumus akan tetap kami tampilkan pada saat kami meberikan contoh soal. Untuk rumus kami dapatkan dari buku galin : Software Quality Assurance-from theory to implementation dimana rumus-rumus yang ada tidak harus sama dan mungkin saja berbeda dari sumber-sumber lainnya.
Software quality metrics
Menurut IEEE, 1990 Software Quality Metrics adalah sebuah pengukuran kualitas apakah sebuah software tersebut sudah dapat dikatakan berkualitas dapat menggunakan SQM (Software Quality Metrics) ini. Tujuan dalam membuat SQM ini adalah :

1.    Memfasilitasi management dalam hal control(pengawasan)  sebagai langkah perencanaan dan eksekusi.
2.     Untuk mengidentifikasi situasi saat ini sehingga dapat memutuska apakah perlu dikembangkan lebih lanjut, di maintenance, di perbaharui, ataukah perlu diadakannya tindakan pembenaran (corrective).
Metriks juga memberikan perbandingan dari performa dari date dengan indicator serta nilai-nilai yang kualitiatif seperti :
-    Menentukan kualitas standard software
-    Target kualitas
-    Pencapaian kualitas tahun sebelumnya
-    Pencapaian kualitas proyek sebelumnya
-    Level kualitas rata-rata
-    Pencapaian kualitas rata-rata perusahaan
-    Sebagai best Practice pada industri
Secara garis besar metriks dibagi menjadi 2 :
-    Metriks prosess
Biasanya terdiri dari proses pada saat pengembangan software

-    Metriks produk
Berkaitan tentang maintenance sebuah software (setelah melewati masa develop,ent)
Adapun hal-hal yang diukur ,sebagai berikut :
•    Kualitas
•    Waktu
•    Keefektifan
•    Produktifitas

Metriks Proses
Didalam pengembangan sebuah software tentu ada proses didalamnya, adapun proses tersebut terbagi menjadi 4 kategori :
-    Metriks kualitas dari software process
-    Metriks waktu dari software process
-    Metriks efektifitas menghilangkan error (Error removal effectiveness metrics)
-    Metriks produktifitas dari software process

Metriks kualitas dari software process
Didalamnya terdapat 2 metriks yang di klasifikasikan menjadi 2 :

•    Error Density Metrics
Adalah sebuah pengukuran dimana mengkalkulasikan jumlah error berdasarkan intensitas/volume  pelaporan yang dilaporkan oleh pengembang

•    Error Severity Metrics
Adalah sebuah pengukuran dimana mengkalkulasikan kerusakan yang ditimbulkan biasanya dilihat dari baris kode dan error pada saat melakukan pengembangan.
Metriks waktu dari software process
Biasanya hanya mencari rata-rata dari keterlambatan proyek pada milestone (titik penting).
Metriks keefektifitas menghilangkan error
Dilakukan perhitungan pada saat berjalan selama 6-12 bulan dalam masa pengembangan  software oleh tim SQA. Tujuannya adalah mencari keefektifan dalam menghilangkan error.
Metriks produktifitas dari software process
Digunakan untuk melihat produktifitas dari sumberdayanya dilihat dari proses pengembangan software (dapat dikatakan ini dilakukan di akhir sebagai bahan evaluasi). Dan juga untuk menghitung seberapa banyak baris kode yang digunakan pada saat melakukan pengembangan dengan tujuan dikedepannya pengembang bisa memperkirakan seberapa sumber daya manusia yang digunakan untuk “n”(seberapa banyak) baris kode.

Matriks Produk
Adalah matriks yang digunakan pada saat software itu telah berhasil dibuat dan sudah diberikan kepada customer (fase operasional). Pada saat operasional ini perlu adanya ke 2 tipe dari customer service untuk memberikan feedback kepada pengembang , sebagai berikut :

-    Help Desk service (HD)
Tujuan dari HD ini adalah membantu customer secara teknis dengan memberi solusi dari permasalahan yang dihadapi customer dengan software yang mereka beli. Contoh : user tidak mengerti bagaimana cara menyimpan pekerjaan mereka pada software yang mereka beli, kemudian HD memberitahukannya dengan cara klik File>kemudian Save.

-    Corrective maintenance service
Membantu customer dengan mencatat semua permasalahan terkait software (bug) sehingga dapat di perbaiki dengan cara memberikan update terbaru atau patch. Jadi ketika ada customer yang menelpon adanya bug maka ini di kategorikan sebagai telepon corrective maintenance sehingga tim maintenance akan segera memperbaiki permasalahan ini dan memberikan update. Contoh pada web : Seperti yang kita ketahui jika web browser firefox mengalami crash maka system otomatis akan memberikan kita pilihan apakah kita ingin melaporkannya kepada firefox atau tidak.
Dari kedua jenis layanan yang diberikan oleh pengembang terdapat 4 matriks pengukuran :
1.    HD quality metrics
2.    HD productivity Metrics
3.    Corrective maintenance quality metrics
4.    Corrective maintenance productivity and effectiveness metrics.

Kemudian didalam proses maintenance ini ada 3 aktifitas utama yang di lakukan :
1.    Corrective maintenance : perbaikan secara langsung dari pendektesian kegagalan (bug) pada saat software itu berjalan.
2.    Adaptive maintenance : Melakukan adaptasi dari software yang ada sebagai kebutuhan baru (new requirement) untuk software yang akan dating.
3.    Functional improvement maintenance : Adalah penambahan fungsi baru dalam rangka peningkatan reliabilitas software terhadap permasalahan yang di hadapi customer pada saat menggunakan software.

HD quality metriks
Terdapat 2 tipe dari metriks ini, yaitu :
-    HD calls density metrics ( pengukuran dimana seberapa sering customer melakukan panggilan telepon ke bagian HD)
-    HD success metrics (pengukuran dimana keberhasilan dari HD menyelesaikan masalah dilihat dari lamanya melakukan panggilan dengan customer)

HD productivity and effectiveness metrics
Adalah sebagai pengukuran produktifitas dari seberapa banyak sumberdaya (resource) yang dibutuhkan untuk menangani panggilan pelanggan. Secara garis besar dibagi menjadi 2 :
1.    HD productivity metrics (pengukuran produktifitas dari staff yang menghandle panggilan)
2.    HD effectiveness metrics (keefektifan dari staff yang menghandle panggilan)

Corrective maintenance quality metrics
Seperti yang sudah dijelaskan di atas tentang corrective maintenance yaitu tentang perbaikan/pembenaran terhadap software pada saat melakukan maintenance,namun pada bagian ini kami menjelaskan tentang pengukuran terhadap kegagalan system, terbagi menjadi 4 :
1.    Software system failures density metrics : Adalah pengukuran dimana dilihat dari seberapa banyak masalah yang timbul pada saat melakukan pengoperasian/penggunaan software tersebut.
2.    Software system failures severity metrics : Adalah seberapa parahnya dampak kerusakan/kegagalan yang ditimbulkan (bug) pada saat softwareitu dijalankan.
3.    Failures of maintenance service metrics : Adalah pengukuran kegagalan pada saat melakukan maintenance. Tidak semua bug yang diperbaiki itu akan terselesaikan dengan baik, walaupun sudah dibenarkan namun timbul masalah baru lagi maka ini digunakan untuk pengukuran kegagaln pada saat proses maintenance.
4.    Software system availability metrics
Adalah sebagai metriks pengukuran dari permasalahan yang ditimbulkan pada saat proses maintenance. Misalkan saja setalah di perbaiki hanya sebagian system saja (ataupun keseluruhan system gagal) yang berjalan dan system menjadi tidak stabil.

Software corrective maintenance productivity and effectiveness metrics
Berhubungan tentang metriks pengukuran tentang seberapa besar SDM yang di alokasikan untuk melakukan maintenance dan juga ketepatan penggunaan SDM tersebut apakah sesuai dengan hasil yang diharapkan.
Implementasi dari SQM (Software Quality Metrics)
Dalam melakukan implementasi SQM perusahaan (software house) memerlukan :
1.    Pemahaman terhadap SQM itu sendiri
2.    Penggunaan SQM secara berkelanjutan, sebagai data untuk meng-improve perushaana
3.    Data (penggunaan baris kode, sumberdaya, dsb)

Dalam implementasinya SQM dapat dimodifikasi sesuai apa yang diinginkan oleh persahaan . Untuk metodeloginya sendiri sebagai berikut :
-metode-
Batasan dalam software metrics
Disetiap system pasti memiliki batasan masing-masing untuk software metrics memiliki batasan sebagai berikut :
-    Masalah Budget (akan meningkan atau turun tergantung Sumberdaya yang digunakan)
-    Masalah tingkah laku manusia (ada yang malas dan ada yang rajin(terkait produktifitas))
-    Ketidakpastian terhadap validitas data.

=Soal=

Chapter 19 - Configuration Manager

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100024

Chapter 19 : Configuration Manager

Pada kali ini, kami akan membahas salah satu materi pada bab quality infrastructure components, yakni Configuration Manager. Software Configuration Manager adalah

Komponen SQA yang menangani perubahan – perubahan yang terjadi dan memberikan jawaban akurat atas penyelidikan pada perubahan – perubahan tersebut.

Untuk lebih jelasnya mengenai configuration manager , kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/pzhso2h038jf/untitled-prezi/

Terima kasih :)

Chapter 17 - Corrective and Preventive Actions

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100024

Chapter 17 : Corrective and Preventive Actions

Pada kali ini, kami akan membahas salah satu materi pada bab quality infrastructure components, yakni Corrective and Preventive Actions. Corrective and Preventive Actions adalah

Tools dalam SQA untuk memenuhi kebutuhan fungsional dan manajerial dengan menekan biaya pada pengembangan software

Untuk lebih jelasnya mengenai corrective and preventive actions, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/lo-v3aerhrh_/untitled-prezi/

Terima kasih :)

Chapter 16 - Training Instructions

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100024

Chapter 16 : Training Instructions

Pada kali ini, kami akan membahas salah satu materi pada bab quality infrastructure components, yakni training instructions. Training instruction bertujuan untuk

Mengembangkan pengetahuan dan keterampilan staff baru terkait tugas kerjanya.

Untuk lebih jelasnya mengenai training instruction, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/w-sojezdhhsm/untitled-prezi/

Terima kasih :)