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 :)

Chapter 15 - Supporting Devices

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100024

Chapter 15 : Supporting Devices

Pada kali ini, kami akan membahas salah satu materi pada bab quality infrastructure components, yakni Supporting Devices.

TEMPLATE VS CHECKLIST 

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

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

Terima kasih :)

Chapter 14 - Procedure & Work Instructions

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 14 : Procedure & Work Instructions

Pada kali ini, kami akan membahas salah satu materi pada bab quality infrastructure components, yakni Procedure & Work Instructions.

Procedure adalah aktivitas detail/proses yang dilakukan sebagai metode dalam melakukan suatu tugas kerja.

Work instructions adalah perintah untuk melakukan  tugas kerja yang ditujukan khusus untuk seorang atau departemen tertentu.

Untuk lebih jelasnya mengenai procedure & work instructions, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

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

Terima kasih :)

Chapter 12 - SQA of External Participant

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 12 : SQA of External Participant

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni SQA of External Participant.

External Participants dapat diklasifikasikan menjadi tiga kelompok utama: 

• Subkontraktor

• Pemasok software COTS dan modul perangkat lunak yang digunakan kembali

• Pelanggan, diri mereka sebagai peserta dalam melaksanakan proyek

Untuk lebih jelasnya mengenai SQA of External Participant, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

http://prezi.com/la_rdlfw-eue/untitled-prezi/

Terima kasih :)

Chapter 11 - Assuring the quality of software maintenance components

Hani Rosdahlia 5210100020 

I Gusti Bagus Wiratama Putra 5209100004

Assuring the quality of software maintenance components

Komponen penentu kesuksesan maintenance adalah sebagai berikut :

1. Corrective maintenance : Kemampuan pembenaran terhadap error pada software
2. Adaptive maintenance : Kemampuan adaptasi software pada lingkungan / kebutuhan pelanggan baru

Functionality improvements maintenance :

• Perfective : Peningkatan performance melalui fungsi tambahan
• Preventive : Peningkatan reliabilitas, kemudahan pada infrastruktur, dan efisiensi maintenance masa akan datang

Objective

Tujuan penjaminan kualitas pada Software Component adalah :

• Menjamin ketercapaian tingkat kepercayaan terhadap pemenuhan kebutuhan yang dijanjikan
• Menjamin ketercapaian tingkat kepercayaan terhadap jadwal dan budget yang direncanakan sebelumnya
• Memanage efisiensi software maintenance dengan meningkatkan fungsionalitas dan menekan biaya

Foundation of High Quality

Foundation 1 : Software package quality

Yang termasuk di dalamnya adalah  beberapa yang dirumuskan oleh McCall, yaitu :

correctness, reliability, maintainability, flexibility, testability, portability, dan

interoperability

Foundation 2 : Maintenance Policy

Vesion development policy : berapa banyak versi yang harus diperasikan secara simultan

Change policy : metode untuk menangani adanya perubahan 

Pre-maintenance SQ Component

1. Maintenance Contract Review
      Baik untuk internal maupun exrernal cutomers membutuhkan maintenance contract untuk memastikan / mereview sejauh mana maintenance dilakukan, berapa sumberdaya yang digunakan, siapa yang melakukan (subkontrak, internal), berapa biaya yang diperlukan

2. Maintenance Plan

•       Daftar layanan maintenance yang dikontrakkan 
•       Organisasional dari tim maintenance
•       Fasilitas maintenance (Maintenance support center, documentation center)
•       Daftar resiko maitenance
•       Daftar prosedur dan kontrol dalam melakukan maintenance
•       Budget software maintenance

SQA Tools for Corrective Maintenance

Activities

- User support services :  Terkait dengan kegagalan code dan dokumentasi

- Software correction services :Terkait dengan pembenaran bug dan dokumentasi

Toolsnya adalah :

Mini Testing 

•      Dilakukan oleh tester, bukan programmer
•      Ada prosedur testingnya
•      Merekam semua error yang terdeteksi

SQA Infrastucture components for software maintenance

• Maintenance procedures & work instructions

• Supporting quality devices

• Training & certifiation

• Preventive & corrective actions

• Configuration management

• Documentation and quality recird control

Chapter 10 - Software Testing (Implementation)

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 10 : Software Testing (Implementation)

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni Software Testing.

Software Testing adalah proses formal dalam mengeksekusi software dalam unit, integrasi, maupun sistem untuk menganalisa perbandingan antara kebutuhan pelanggan dan kenyataan pada program 

Untuk lebih jelasnya mengenai software testing bagian implementasi, kami menampilkan materi dalam bentuk prezi. Visit this link, please :)

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

Terima kasih :)

Chapter 9 - Software Testing (Strategies)

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 9 : Software Testing (Strategies)

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni Software Testing.

Software Testing adalah proses formal dalam mengeksekusi software dalam unit, integrasi, maupun sistem untuk menganalisa perbandingan antara kebutuhan pelanggan dan kenyataan pada program 

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

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

Terima kasih :)

Chapter 20 Project Progress Control

Project Progress Control digunakan sebagai cara untuk mendeteksi lebih dini event-event yang tidak biasa terjadi. Adapun komponen-komponen utama pada Project Progress Control sebagai berikut :
- Aktifitas kontrol manajemen resiko
Berkaitan tentang aktifitas melakukan pengelolaan resiko dimana mengidentifikasi resiko-resiko yang mengancam proyek.
- Kontrol jadwal proyek
Berkaitan tentang pengawasan terdahap penjadwalan proyek dan mencegah terjadinya keterlambatan proyek .
- Kontrol Sumberdaya proyek
Berfokus kepada sumberdaya manusianya dan juga fasilitas testingnya.
- Kontrol budget proyek

Adalah sebuah pengawasan terkait dengan budget proyek. Adapun yang dikontrol pada bagian ini adalah :
• Sumberdaya manusia
• Pengmbangan dan fasilitas untuk testing
• Pembelian software
• Pembelian hardware
• Pembayaran kepada sub kontraktor

Pengimplementasian dari control progress proyek harus sesuai dengan prosedur yang menentukan hal-hal berikut :
Alokasi Tanggung jawab (siapa saja yang bertanggung jawab dalam melakukan tugas control progress)
• Frekuensi dari pelaporan yang dibutuhkan pada setiap unit proyek
• Suatu situasi yang membutuhkan manajemen bawah untuk melaporkan secepatnya kepada atasan.

Peranan tools dalam melakukan control progress dari proyek
Tools sangat membantu dalam meringankan beban kita sebagai manusia untuk melakukan sesuatu. Adapun manfaat menggunakan tools ini dapat membantu pada area sebagai berikut :
- Aktifitas kontrol manajemen resiko
- Dapat mebantu mengkategorikan resiko dan juga pengelolaan tanggal pemecahan solusi
Kontrol jadwal proyek
- Membuat daftar klasifikasi dari aktifitas yang tertunda
- Membuat daftar klasifikasi dari aktifitas kritkal
- Memperbaharui jadwal aktifitas yang dibuat berdasarkan laporan progress

Kontrol sumberdaya proyek
- Rencana pengalokasian sumberdaya proyek
- Pemanfaatan sumberdaya proyek
Pada control budget
- Membantu merencanakan budget proyek
- Membuat daftar pemanfaatan budget

Chapter 19 Documentation Control

Controlled Document (Dokumentasi yang terkontrol) adalah dokumen yang berisi dokumentasi pengembangan dan maintenance sebuah software yang dibuat di Internal perusahaan sendiri. Dalam implementasinya control dokumen sangat perlu dilakukan untuk menjaga sebuah software tersebut tetap terdokumentasi dengan baik. Bayangkan saja ketika kita ingin mengembangkan sebuah software yang sudah ada tanpa ada dokumentasi sebelumnya tentu akan memakan waktu lama dan juga biaya yang sangat besar, oleh karena itu akan lebih memudahkan programmer ketika pengembangan sebelumnya programmer-programer terdahulu melakukan pendokumentasian dengan baik. Pendokumentasian ini merupakan salah satu bagian dari SQA (Software Quality Assurance) untuk memastikan sebuah software tersebut terjaga kualitasnya. Aada juga yang disebut dengan Quality Record (catatan kualitas) dimana merupakan dokumen special yang berfokus pada kebutuhan kustomer dan keefektifan pengoperasian dari system SQA.Untuk prosedurnya sendiri terbagi menjadi 4:

- List dokumen yang sudah terkontrol
- Persiapan dokumen control
- Persetujuan dokumen control
- Permasalahan dari penyimpanan dan pengambilan dokumen  control

List dokumen yang terkontrol
Pada bagian ini pihak yang bertanggung jawab melakukan control dokumen melakukan :
- Menentukan tipe dokumen mana yang dapat dikategorikan sebagai dokumen yang terkontrol dan tipe dokumen control yang diklasifikasikan sebagai quality record.
- Menentukan level dari control yang memungkinkan untuk setiap dokumen yang dikategorikan sebagai dokumen control.
- Menganalisa temuan terbaru dan melakukan pembaharuan, perubahan, dan tambahan-tambahan lainnya pada dokumen control.

Persiapan dokumen control
Pada bagian ini pihak yang melakukan control mempersiapkan 3 kebutuhan yaitu : Structure (Template), Identification Method (Memberikan kode versi dan revisi), dan Standart Orientation and reference information (Berisi tentang data si penulis dokumen ). Untuk reference information diberi data tentang penulis yang berisi tentang :
- Penulis dokumen
- Tanggal pembuatan
- Orang yang menyetujui dokumen (beserta jabatan)
- Tanggal persetujuan
- Tanda tangan dari penulis dan orang yang menyetujui
- Penjelasan dari perubahan yang telah dilakukan pada dokumen yang baru
- Daftar dari versi dan revisi sebelumnya
- Daftar orang-orang yang pernah melihat dokumen tersebut

Persetujuan dokumen control
Pada bagian ini hanya menjelaskan tentang siapa yang boleh dan bertanggung jawab dalam menyetujui dokumen dan tipe-tipe dokumen apa saja yang dapat disetujui. Untuk orang yang boleh melakukan persetujuan adalah orang orang yang telah dipercayakan perusahaan sebagai reviewer yang memiliki keahlian di bidangnya. Selanjutnya ada proses persetujuan, untuk proses persetujuannya memerlukan persetujuan dari pihak reviewer untuk verifikasi dan validasi dokumen control sehingga kualitas dapat terjaga.

Permasalahan dokumen control terkait penyimpanan dan pengambilan dokumen
Dokumen control ini harus dijaga dengan baik, sehingga tidak terjadi kerusakan dan kehilangan. Bayangkan saja jika sebuah software sensitive seperti perbankkan itu mengalami kerusakan ataupun kehilangan akan merugikan bank tersebut. Dan pada bagian ini menentukan bagaimana dokumen yang tidak terpakai itu dibuang dan cara membuangnya. Hal ini dibuat agar tidak jatuh ketangan yang salah.

Chapter 8 - Review

Hani Rosdahlia 5210100020

I Gusti Bagus Wiratama Putra 5209100004

Chapter 8 : Review

Pada kali ini, kami akan membahas salah satu materi pada bab project life cycle SQA components, yakni review.
Review adalah.

Proses pertemuan antara satu set elemen suatu pekerjaan (project personnel, manajer, pengguna, pelanggan, dan pihak lainnya) untuk merumuskan suatu persetujuan (IEEE,1990)

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

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

Terima Kasih :)

Chapter 6 Development and Quality Plans

Pada bab ini akan membahas tentang elemen-elemen apa saja yang ada pada saat pengembangan dan juga pada saat quality plan. Lalu mengidentifikasikan resikonya.
Planning (perencanaan) , memiliki beberapa tujuan ditiap tujuan tersebut harus memiliki beberapa landasan yang memadai seperti :
- Penjadwalan aktifitas pengembangan, sehingga semua dapat tersusun rapi serta dapat dibuat perkiraan waktu, sumberdaya, dan budget.
- Merekrut anggota tim dalam proses pengembangan proyek
- Mencari solusi terkait dengan resiko pengembangan
- Mengimplementasikan aktifitas SQA yang dibutuhkan
- Memberikan manajemen data-data yang diperlukan untuk mengontrol proyek

Pada bagian ini perencanaan dibagi menjadi 2 :
1. Perencanaan Pengembangan
2. Perencanaan Kualitas

Perencanaan Pengembangan
Perencanaan pengembangan dipersiapkan untuk memenuhi landasan tujuan perencanaan,diantaranya :
1. Produk dari proyek
2. Interface Proyek ( Interface terhadap software yang sudah ada ataupun software lainnya)
3. Metodelogi proyek dan tools pengembangan
4. Standart pengembangan software dan prosedur
5. Memetakan proses pengembangan ( agar lebih detail tiap fase proyek)
6. Titik temu proyek (berkaitan tentang waktu penyelesaian dan produk)
7. Pengelolaan staff proyek (dibagi bedasarkan tugas masing-masing, dan untuk menjadi professional diperlukan sertifikasi dan training)
8. Fasilitas pengembangan (hardware, infrastruktur,dsb)
9. Resiko pengembangan (berkaitan tentang resiko kesenjangan teknologi,kurangnnya staff, dsb)
10. Metode pengendalian (control) (berkaitan tentang monitoring proyek)
11. Perkiraan biaya proyek (merupakan perkiraan biaya yang harus dikeluarkan dalam mengembangkan proyek)

Perencanaan Kualitas
Didalam perencanaan kualitas maka perlu adanya elemen berikut :
1. Tujuan Kualitas (Quality Goals)
2. Aktifitas review yang terencana (berisi review scope,type,jadwal,prosedur,yang bertanggung jawab untuk me-review)
3. Uji coba software secara terencana (tes integration, tipe tes (white , black box testing), Jadwal yang terencana, prosedur, dan yang bertanggung jawab melakukan tes)
4. Merencanakan tes acceptance untuk software yang di kembangkan diluar (sesuai apa tidak, dengan yang dibutuhkan)
5. Manajemen Konfigurasi (berkaitan tentang tools yang berkaitan dengan managemen dan juga prosedur)
Rencana kualitas dapat berupa dokumen yang dipersiapkan sebagai bagian dari rencana pengembangan dimana dibuat sebagai dokumen independent. Review dan persetujuan dari rencana kualitas perlu dilakukan sesuai dengan standart perusahaa dam prosedur yang berlaku.

Keuntungan dalam membuat rencana persiapan , jika dilihat dari segi
Departemen Developer(pengembang)
1. Menghindari overbudget.
2. Menghindari kerusakan dari proyek lainnya yang mengalami keterlambatan
3. Menhindari kehilangan “status” pasar, seperti reputasi yang di akibatkan dari keterlambatan proyek.

Pelanggan internal (pengguna si divisi itu sendri) :
1. Meminimalkan penyimpangan dari tanggal yang direncanakan dan tidak overbudget
2. Memiliki pengawasan terhadap proses pengembangan( identifikasi sejak dini terkait permasalahan yang akan menghambat di kemudian hari)
3. Dampak yang ditimbulkan oleh keterlambatan internal sedikit.

Organisasi :
1. Mengurangi resiko kehilangan pasar (market loss) dikarenakan keterlambatan datangnnya produk
2. Mengurangi resiko dituntut oleh customer karena keterlambatan supply
3. Mengurangi resiko kerusakan reputasi perusahaan
4. Mengurangi resiko permintaan penambahan budget

Chapter 5 Contract Review

Dalam melakukan kontrak pasti kita akan melakukan  analisa sebelum deal dengan kontrak yang dibuat oleh software house atau perusahaan developer lainnya. Jangan sampai kontrak yang sudah buat tidak kita lihat dan dapat menyebabkan kesalahpahaman karena segala kebutuhan customer dijelaskan di dalam kontrak, oleh karena itu perlu dilakukan review kontrak. Dalam prosesnya dibagi menjadi 2 tahapan :
- Tahap 1 : Mereview terlebih dahulu draft proposal sebelium mengajukan ke customer potensial
- Tahap 2 : Mereview kontrak sebelum menandatanganinya

Kontrak ini baik digunakan pada saat :
- Berpartisipasi dalam tender
- Menerima pesanan software dari customer
- Mendapat permintaan pengembangan software dari internal perusahaan atau dari divisi lainnya di dalam satu organisasi.
Jadi kontrak wajib hukumnya dibuat jika customer ingin melakukan kerjasama dibidang pengembangan software. Review kontrak  terbagi menjadi 2:
- Review draft proposal
- Review draft kontrak

Dan ditiap review diatas terdapat tujuan-tujuan dan apa saja yang harus dipenuhi ketika melakukan review.
Review draft proposal dibuat untuk mengetahui apakah draft yang dibuat telah memenuhi hal-hal dibawah ini:
- Kebutuhan Kustomer telah terdokumentasi dengan baik
- Semua pendekatan dalam proyek telah di periksa dengan baik
- Aspek formal kustomer dengan software house telah dibuat
- Identifikasi resiko
- Perkiraan sumberdaya dan jadwal yang memadai
- Memeriksa kapasitas perusahaan di proyek
- Memeriksa kapasitas kustomer dalam proyek
- Keterlibatan kontraktor dan Sub kontraktor
- Pendefinisian hak kepemilikan

Review draft Kontrak , dilakukan untuk melihat aktifitas berikut telah terpenuhi :
- Tidak ada lagi isu-isu atau masalah terkait dengan kebutuhan data yang belum terklarifikasi
- Kesepemahaman antara customer dan juga software house telah terdokumentasi dengan baik
- Ketika membuat draft kontrak tidak lagi tambahan, perubahan, ataupun kelalaian. Intinya harus fix ketika dikasikan draft ini ke customer

Dalam Implementasinya,  ada beberapa factor yang dapat mempengaruhi review kontrak :
- Besarnya proyek
- Kompleks atau tidakya proyek itu
- Tingkat pendidikan staff dan pengalaman kerja
- Organisasi proyek yang kompleks (jika banyak kontraktor,sub,partner,dan customer yang terlibat , maka akan perlu  usaha yang lebih pula dalam proses review kontrak).

Dalam review kontrak semua orang berhak melakukan review kontrak namun hanya orang-orang yang berkepentingan saja seperti pimpinan dan juga staff yang di tunjuk untuk mengangani proposal kontrak , orang lain juga berhak untuk menangangi review kontrak namun yang di tunjuk oleh perusahaan. Ketika perusahaan mengambil orang lain dalam menangani kontrak  biasanya kontrak-kontrak yang besar. Didalam implementasinya ada permasalahan terkait dengan kontrak yang besar(yang biasanya terkait dengan proyek-proyek besar) :
- Waktu
- Review kontrak memerlukan pekerjaan yang professional (tidak boleh sembarang orang bisa melakukan review)
- Tim yang bisasanya melakukan review sangat sibuk.

Untuk menangani masalah diatas maka perlu dilakukan :
- Membuat jadwal ,kapan dilakukan review kontrak
- Dilakukan secara team sehingga meringankan kerja tim reviewer
- Menunjuk pimpinan reviewer

Jika melakukan pengembangan proyek internal (in-house proyek), perusahaan perlu juga membuat kontrak hal ini untuk menjelaskan apa saja kebutuhan proyek dan kapasitas tiap individunya dalam mengembangkannya, namun permasalahan pada umumnya yang terjadi adalah :
- Informasi terkait kebutuhan proyek yang kurang memadai
- Kesalahan perkiraan sumberdaya
- Kesalahan penjadwalan
- Informasi terkait resiko yang kurang memadai
Untuk itu jika melakukan in-house proyek perlu adanya hubungan dan komunikasi yang baik antar divisi dan pengembang yang ingin mengembangkan proyek internal tersebut. Karena hampir tidak mungkin proyek dapat berjalan dengan baik jika tidak ada komunikasi yang baik pula.