Support Manual Review,, alias SMR..

Support manual review merupakan salah satu jenis review yang masuk dalam tinjauan desain formal. Tujuan dari review ini adalah untuk meninjau support manual(manual bantuan) seperti user guide, user manual, installation manual, dan dokumen yang berkaitan dengan itu agar dihasilkan dokumen yang berkualitas dan bermutu, sesuai dengan rencana SQA yang telah ditetapkan sebelumnya.

Komponen – komponen dari support manual review ini antara lain:

1. Infrastuktur SMR
   1. Mengembangkan daftar periksa untuk setiap jenis dokumen, atau setidaknya untuk umum.
   2. Melatih profesional untuk melakukan suatu hal teknis yang utama sebaik isu proses review. Para profesional terlatih melayani sebagai reservoir untuk tim SMR.
   3. Secara periodik menganalisa efektifitas dari SMR tentang deteksi kerusakan untuk meningkatkan metodologi SMR.
   4. Jadwal SMR sebagai bagian dari rencana kegiatan proyek dan mengalokasikan sumber daya yang diperlukan sebagai bagian integral dari prosedur standar pengembangan perangkat lunak.
   5. Partisipan (Tim) SMR

Tim review harus dibatasi dengan jumlah anggota 3-5 orang agar menjadi optimal.

1. Sesi SMR

• Mendiskusikan isu-isu profesional dengan cara yang konstruktif. Disini dituntut untuk menjaga agar suasana diskusi bebas dari ketegangan yang tidak perlu.
• Mempertahankan agenda review. Terhanyut pada agenda yang direncanakan biasanya mengganggu efisiensi review.
• Fokus pada deteksi kesalahan dengan memverifikasi dan memvalidasi komentar peserta. Menahan diri dari mendiskusikan solusi untuk kesalahan yang terdeteksi sehingga dapat menghemat waktu dan menghindari kemunduran jadwal.
• Dalam kasus ketidaksepakatan tentang pentingnya kesalahan, itu diharapkan untuk mengakhiri perdebatan dengan mencatat masalah ini dan pergeseran diskusi ke forum lain.
• Dokumen diskusi, terutama rincian komentar peserta dari hasil verifikasi dan validasi. Langkah penting ini terutama jika dokumentasi untuk melayani sebagai masukan atau dasar untuk penyusunan laporan review.
• Durasi sesi SMR tidak boleh lebih dari 2 jam.
• Siapkan laporan review, yang merangkum masalah yang dibahas dan item tindakan.
• Menetapkan prosedurtindak lanjut untuk memastikan kinerja yang memuaskan dari semua koreksi termasuk dalam daftar item tindakan.

1. Kegiatan setelah Review

ü  Menyiapkan laporan review yang berisi tentang hal-hal yang dibahas dalam review dan hasil dari pembahasan tersebut

ü  Melakukan kegiatan sebagai tindak lanjut dari review untuk memastikan bahwa perbaikan yang dilakukan (hasil review) memuaskan sehingga dihasilkan support manual yang berkualitas.

 

TRR (Test Readiness Review)

TUJUAN

Review uji kesiapan (TRR) merupakan salah satu proses SQA. Tujuan dari review ini adalah menyediakan manajemen dengan menjamin bahwa perangkat lunak telah menjalani pengujian secara menyeluruh dan siap untuk memasuki tahap pengujian selanjutnya.

Ruang lingkup Review Uji Kesiapan adalah untuk memeriksa produk tes dan hasil tes dari tahap uji coba yang  telah diselesaikan sebagai kelengkapan dan keakuratan, dan untuk memverifikasi bahwa kasus tes, tes skenario, skrip uji, lingkungan, dan data uji telah dipersiapkan untuk uji fase berikutnya. Masing-masing tim uji berkontribusi terhadap sebuah rilis aplikasi, harus mengadakan Review Uji Kesiapan untuk aplikasi tersebut. Semua tim uji berkontribusi terhadap sebuah rilis aplikasi akan mengadakan TRR dengan Organisasi  Enterprise pada saat aplikasi siap untuk integrasi ke dalam DCII.

Ada dua jenis TRR menurut sifat pertemuannya:

• Review Informal

Tidak dilakukan pertemuan secara formal, namun hasil dari pertemuan ini sama seperti pertemuan formal, yakni dokumen yang dihasilkan oleh TRR ini

• Review Formal

TRR formal dilaksanakan setiap adanya release aplikasi baru setelah selesainya  Uji integrasi perangkat lunak dan Uji Validasi Fungsi. Review Kesiapan Implemenasi dilaksanakan oleh Organisasi pengujian enterprise setelah selesainya Pengujian Serahterima enterprice dan Penilaian Operasional.

TINGKATAN TRR

Ada 3 level TRR pada level aplikasi, yakni:

• Development Test Readiness Review

TRR informal yang membahas  keberhasilan dan penyelesaian pengujian unit/ modul dari aplikasi yang dikembangkan

• Project Test Readiness Review

TRR formal yang membahas keberhasilan dan penyelesaian dari SIT (Tes integrasi perangkat lunak) dari aplikasi yang dikembangkan

• Enterprise Test Readiness Review

TRR formal yang membahas keberhasilan dan penyelesain dari FVT (Functional validation test) dari aplikasi yang dikembangkan. Enterprise test readiness review dibagi menjadi 2, yaitu:

• Acceptance Test Readiness Review

TRR formal yang membahas masalah keberhasilan dan penyelesaian Enterprise Integration Test (Pengujian Integrasi Enterprose)  dan Performance test (Pengujian Performansi) dari setiap rilis DCII

• Implementation Readiness Review

TRR formal membahas masalah keberhasilan dan penyelesaian dari Enterprise Acceptance Test (Pengujian Serang terima enterprise) dan yang berkaitas dengannya, jika tidak semua penilaian Operasional pada level enterprise diberikan pada rilis DCII

PARTISIPAN TRR

Berikut adalah partisipan dari TRR:

1. Development Test Readiness Review
   1. DCII Test Director
   2. Technical Project Officer
   3. Application Test Manager
   4. Project SQA Representatives
   5. Project Test Readiness Review
      1. DCII Test Director
      2. Technical Project Officer
      3. Functional Project Officer
      4. Application Test Director
      5. Application Test Manager
      6. Enterprise Test Director
      7. Test Integrator
      8. Certifying Subject Matter Experts
      9. Project SQA Specialists
   6. Enterprise Test Readiness Review and Acceptance Test Readiness Review
      1. Program Manager
      2. DCII Test Director
      3. Technical Project Officer
      4. Functional Project Officer
      5. Application Test Director
      6. Enterprise Test Director
      7. Test Integrator
   7. Implementation Readiness Review
      1. Program Manager
      2. DCII Test Director
      3. Enterprise Test Director
      4. Test Integrator
      5. Certifying Subject Matter Experts
      6. Operational Assessment Test Manager
      7. Project SQA Specialists

1. PERAN DAN TANGGUNGJAWAB PARTISIPAN REVIEW
   1. Koordinator Review

Merupakan perasn kunci dalam keseluruhan proses TRR. Seorang koordinator review harus mempunyai pengetahuan dan pengalaman mengenai TRR ini. Peran dari koordinator review adalah

ü  Bertangungjawab rehadap seluruh persiapan review

ü  Memastikan bahwa semua pe-review telah siap dan familiar dengan produk  yang akan direview. Jika pe-review belum siap maka diadakan penjadwalan ulang.

ü  Mengingatkan semua partisipan TRR mengenai tanggal , tempat dan lokasi review.

ü  Memulai pertemuan tepat waktu

ü  Menjaga agar pe-review tetap fokus terhadap produk yang di review.

ü  Berperan sebagai pe-review dan berpartisipasi dalam proses review

ü  Memastikan bahwa semua checklist, catatan review dan kesimpulan dari review telah selesai dikerjakan. Kemudian koordinator review berama dengan grup SQA melakukan follow up/ tindak lanjut dari review.

1. Presenter

Tugas utama dari presenter antara lain:

ü  Memberikan gambaran umum dari priduk yang di review

ü  Menjadi presenter saat review ketika ada klarifikasi

ü  Melakukan koreksi terhadap hasil pengujian sesuai kebeutuhan setelah dilakukan review

1. Panitera (Meeting Recorder)

Panitera mencatat semua kegiatan yang terjadi selama review, termasuk mencatat semua checklist. Panitera juga memberikan kesimpulan terhadap hasil review serta membuat laporan review.

1. Spesialis SQA

Spesialis SQA akan mereview pengujian produk dan aktifitas review untuk memastikan kecocokan dengan rencana SQA yang telah ditetapkan dan mengindentifikasi standar produk.

1. Petugas Review (Reviewer)

Melakukan review, meliputi semua pengujian dan beberapa tahapan, sertifikasi, hasil pengujian, dan laporan pengujian. Semua peviewer harus telibat dalam diskusi kelompok. Tujuan dari review adalah untuk me review hasil pengujian dan menyakinkan bahwa perangkat lunak siap untuk digunakan.

1. KRITERIA TRR

Beberapa proses  berikut menjelaskan kriteria sebelum revieew dilaksanakan

1. Development TRR
   1. Pegawai teknis proyek akan menjadi korrdinator dari tahapan ini. Manager penguji Aplikasi diberi tugas sebagai presenter review. Pegawai teknis proyek yang lain akan menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Menyelesaikan checklit pengujian modul, kasus mengujian modul, dan data laporan pengujian modul harus ditempatkan pada kontrol managemen.

ü  Laporan pengujian modul harus sudah didistribusikan pada selueuh partisipan

ü  Kasus pengujian, skenerio pengujian dan skrip pengujian telah didokumentasikan untuk Pengujian Integrasi perangkat lunak aplikasi dan siap digunakan

ü  Data pengujian telah disiapkan untuk Pengujian integrasi perangkat lunak

ü  Menyiapkan lingkungan pengujian

1. Project TRR
   1. Pegawai teknis proyek akan menjadi korrdinator dari tahapan ini. Manager penguji Aplikasi diberi tugas sebagai presenter review. Pegawai teknis proyek yang lain akan menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Software Test Plan, Software Integration Test cases, test scenarios, test scripts, automated test scripts, dan data pengujian telah ditempatkan pada kontrol konfigurasi managemen.

ü  Laporan Software Integration Test telah disiapkan dan didistribusikan pada seluruh partisipan

ü  Sesi yang bersesuaian dengan spesifikasi DCII telah divalidasi dan di sertifikasi oleh Technical Project Officer.

ü  Test Discrepancy Reports (TDRs) dari Software Integration Test telah ditutup.

1. Application Test Director atau Functional Project Officer memastikan bahwa hal-hal berikut ini telah siap/ selesai:

ü  Aplikasi Functional Validation Test (FVT) telah siap digunakan

ü  Data pengujian telah disipakan untuk aplikasi Functional Validation Test (FVT).

ü  Lingkungan pengujian telah disiapkan

ü  Matrik kebutuhan telah disesuaikan dengan memasukkan identifikasi kebutuhan, deskripsi kebutuhan, kasus pengujian yang berhubungan, skrip pengujian, file data pengujian, dan di sinkronkan dengan identifikasi FFMR untuk FVT

ü  Technical Action Manager dan akun pengawai telah dibuat untuk level pengujian dan even pengujian untuk FVT tanpa CMIS

1. Enterprise TRR
   1. Functional Project Officer akan menjadi koordinator review untuk Project TRR. Application Test Director atau application Functional Project Office diberi tanggungjawab sebagai presenter review. Functional Project Officer menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Software Test Plan, Software Integration Test cases, test scenarios, test scripts, automated test scripts, dan data pengujian telah ditempatkan pada kontrol konfigurasi managemen.

ü  Laporan Software Integration Test telah disiapkan dan didistribusikan pada seluruh partisipan

ü  Sesi yang bersesuaian dengan spesifikasi DCII telah divalidasi dan di sertifikasi oleh Technical Project Officer.

ü  Test Discrepancy Reports (TDRs) dari Software Integration Test telah ditutup.

ü  Parstisipan pengujian/ subyek fungsional direkomendasikan menjadi manager program

ü  Data yang bersesuaian telah dikumpulkan dan disimpan dalam FFMR

ü  Sertifikasi tahun 2000 telah selesai dan diterima oleh  manager program

1. Enterprise Test Director memastikan bahwa beberapa hal berikut telah siap:

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk pengujian intergrasi dan perfornansi enterprise

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk penilaian operasional

ü  Test Integrator telah mereview hasil pengujian dan mensertifikasi kesesuainnya dengan kebutuhan dan standar

ü  Data pengujian telah disiapkan untuk pengujian enterprise.

ü  Lingkungan pengujian telah disiapkan

ü  Matrik kebutuhan telah disesuaikan dengan memasukkan identifikasi kebutuhan, deskripsi kebutuhan, kasus pengujian yang berhubungan, skrip pengujian, file data pengujian, dan di sinkronkan dengan identifikasi FFMR untuk FVT

ü  Technical Action Manager dan akun pengawai telah dibuat untuk level pengujian dan even pengujian untuk FVT tanpa CMIS

1. Acceptance TRR
   1. Enterprise Test Director akan menjadi koordinator review untuk Project TRR. Enterprise Test Director atau ketua penguji Enterprise Test Director diberi tanggungjawab sebagai presenter review. Functional Project Officer menjadi panitera dan menyiapkan checklist review dan catatan kegiatan yang kemudian didistribusikan ke seluruh perserta review.
   2. Presenter review, memastikan bahwa hal berikut telah siap:

ü  Sesi yang bersesuain dnegan spesifikasi DCII telah divalidasi dan disertifikasi oleh Direktur penguji Enterprise

ü  Test Discrepancy Reports (TDRs) dari Enterprise Integration Test dan Performance Test telah direview pegawai fungsional dan teknis proyek

ü  Data yang bersesuaian telah dikumpulkan dan disimpan pada FFMR

ü  Sertifikasi telah selesai dan diterima

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk Enterprise Acceptance Test

ü  Kasus pengujian, skenario pengujian, skrip pengujian telah didokumentasikan dan siap digunakan untuk penilaian operasional dengan pengguna akhir.

1. Review Planning and Preparation

Koordinator review bertanggungjawab untuk menjadwalkan review, menyiapkan review pengujian produk, dan berperan sebagai moderator pada review. Koordinator review akan melakukan hal berikut:

1)      Mengkoordinasikan fasilitas review.

2)      Membuat agenda

3)      Mengingatkan semua partisipan:

ü  Menginformasikan kepada partisipan mengenai waktu, tempat dan lokasi review

ü  Mengingatkan presenter mengenai materi yang spesifik untuk di presentasikan dan waktunya

ü  Memberikan tugas kepada panitera atau partisipan review yang lain apabila ada tugas khusus

4)      Menyiapkan checklist

5)      Membuat paket review meliputi

ü  Agenda

ü  Checklist review

ü  Laporan pengujian

6)      Mendistribusikan paket review ke seluruh partisipan

Semua partisipan bertanggungjawab untuk melakukan penilaian/ koreksi terhadap paket review dan mendiskusikannya sesuai dengan bagian masing-masing.

1. Review Excecution

Koordinator review menverifikasi bahwa semua partisipan telah hadir dan siap untuk melakukan review.

1)      Koordinator review memperkenalkan tujuan dan ruang lingkup review

2)      Presenter review mencatat hal- hal yang berada di luar rencana kemudian menyiaplan rencana untuk menyelesaikannya

3)      Presenter review memperkenalkan hasil pengujian yang tertulis dalam laporan pengujian

4)      Presenter review menyediakan dokumen form sertifikasi dan mencatat hasil dari proses pengujian sertifikasi

5)      Presenter review menyediakan ekstraksi matrik kebutuhan

6)      Pe-review mencatat hal kebutuhan yang kurang

7)      Presenter review memberikan rekomendasi untuk pengembangan komponen perangkat pada tahapan berikutnya

8)      Presenter pengganti memberikan kesimpulan dari pengujian kesiapan pada tahap berikutnya

9)      Presenter pengganti memperkenalkan rencana pengujian perangkat lunak

10)   Koordinator review menyelesaikan ceklist review

11)   Panitera mencatat semua kegiatan yang dilakukan dalam catatan kegiatan

12)   Koordinator review menyimpulkan kegiatan review dan menutup review

13)   Koordinator review menyiapkan dan menyediakan catatan review dan mendistribusikan laporan kesimpulan review kepada semua partisipan

1. Exit Criteria

Berikut ini adalah hasil dari review

1. Completed Review Checklist
2. Review Summary Report
3. Review Action Item Notice
4. SQA Reports
5. Review Follow up

Selama tahap follow-up koordinator review dan spesialis SQA memastikan bahwa semua definisi telah diselesaikan dengan menggunakan catatan kegiatan untuk memastikannya

 

Jaminan Mutu Perangkat Lunak

Tujuan Rencana Pengembangan dan Kualitas

Perencanaan, sebagai suatu proses, memiliki beberapa tujuan, masing-masing dimaksudkan untuk mempersiapkan dasar yang memadai sebagai berikut:

Penjadwalan kegiatan pembangunan mengarah pada kesuksesan dan penyelesaian proyek tepat waktu, dan memperkirakan sumber daya tenaga kerja yang diperlukan dan anggaran.

Menetapkan suatu jadwal dari suatu proyek pembangunan agar pelaksanaanya dapat lebih terkontrok dan terarah. Proyek diselesaikan sesuai dengan jadwal kegiatan. Selain menetapkan jadwal, suatu pembangunan proyek juga memerlukan rencana mengenai tenaga kerja (sumber daya) dan anggaran yang diperlukan untuk menyelesaiakn proyek.

Merekrut anggota tim dan mengalokasikan sumber daya (menurut jadwal kegiatan dan perkiraan kebutuhan sumber daya tenaga kerja, termasuk keahlian masing-masing pekerja).

Perencanaan diperlukan agar diperolah tenaga kerja (sumber daya) yang sesuai dengan kebutuhan proyek, dan dapat menempatkan tenaga kerja pada posisi yang sesuai dengan kemampuan dan keahlian masing-masing pekerja.

Menyelesaikan risiko pembangunan.

Adanya suatu proyek tidak lepas dari adanya resiko pengerjaan proyek tersebut. Perencanaan proyek, meliputi perencanaan resiko proyek tersebut, termasuk analisa resiko,dan penyelesaian dari resiko tersebut. Dengan adanya perencanaan yang matang setiap muncul suatu resiko, maka dapat dikendalikan dengan tepat.

Melaksanakan keperluan kegiatan SQA.

Penilaian kulitas suatu perangkat lunak juga perlu direncanakan sejak awal. Sehingga dapay diketahui komponen-komponen yang digunakan dalam penilaian kualitas perangkat lunak. Dengan demikian dapat dihasilkan perangkan lunak berkualitas sesuai dengan indikator penilaiai kualitas yang ditetapkan sebelumnya.

Menyediakan manajemen dengan data yang diperlukan untuk kendali proyek.

Dengan adanya perencaan maka manajemen proyek dapat berjalan dengan lebih terarah dan terkontrol. Kendali proyek dapat dilakukan dengan mundah dengan data-data yang mendukung dalam penegndalian proyek.

2. Elements of Development Plan
Produk proyek

Rencana pengembangan termasuk produk berikut:

Desain dokumen untuk menetapkan tanggal penyelesaian, menunjukkan item-item yang akan dikirimkan kepada konsumen (“kiriman”)
Produk perangkat Lunak (menentukan waktupenyelesaian dan tempat instalasi)
Pelatihan tugas (menentukan waktu, peserta dan situs).

Interface proyek

Interface proyek meliputi:

Interface dengan paket perangkat lunak yang ada (inteface perangkat lunak)
Interface dengan tim pengembangan perangkat lunak dan atau perangkat keras lain yang bekerjasama pada sistem atau proyek yang sama (yaitu kerjasama dan koordinasi link)
Interface dengan hardware yang ada ( hardware interface ).

Metodologi dan peralatan yang diperlukan dalam pengerjaan setiap tahapan proyek
Pengembangan standart dan prosedur software

Sebuah daftar harus disiapkan dari standar pengembangan dan prosedur perangkat lunak yang harus diterapkan dalam proyek tersebut.

Pemetaan dari proses pengambangan

Pemetaan proses pembangunan melibatkan detail definisi dari setiap fase proyek. Deskripsi ini mencakup definisi dari input dan output, dan aktivitas spesifik yang direncanakan.

Deskripsi Kegiatan meliputi:

Perkiraan durasi aktivitas tersebut. Perkiraan ini sangat tergantung pada pengalaman yang diperoleh dalam proyek sebelumnya.
urutan logis di mana setiap kegiatan yang akan dilakukan, termasuk deskripsi ketergantungan setiap kegiatan di kegiatan yang telah diselesaikan sebelumnya.
jenis sumber daya profesional yang dibutuhkan dan perkiraan tentang berapa banyak sumber daya yang diperlukan untuk setiap kegiatan.

Milestone Proyek

Pendefinisian masing-masing milestone yakni kapan suatu tahapan diselesaikan (meliputi waktu, dokumentasi dan kode).

Organisasi Staff Proyek

Rencana organisasi terdiri dari:

Struktur organisasi: mendefinisikan tim proyek dan tugas-tugas mereka,termasuk tim yang terdiri dari pekerja sementara sebuah subkontraktor.
Profesional Requirements: sertifikasi profesional, pengalaman dalambahasapemrograman spesifik atau alat pengembangan, pengalaman dengan produk perangkat lunak khusus dan jenisnya, dan sebagainya.
Jumlah anggota tim diperlukan untuk setiap periode waktu, tergantung pada kegiatan yang dijadwalkan. Diharapkan bahwa tim akan dimulai kegiatan merekadi waktu yang berbeda, dan jumlah tim mereka dapat bervariasi dari satuperiode ke periode berikutnya, tergantung pada kegiatan yang direncanakan.
Nama pemimpin tim dan anggota tim. Kesulitan diharapkantimbul sehubungan dengan tugas jangka panjang anggota staf untuktim karena perubahan tidak diantisipasi dalam tugas-tugas mereka saat ini.Oleh karena itu, nama-nama staf diperlukan untuk membantu melacak partisipasimerekasebagai anggota tim.

Fasilitas Pembangunan

Pembangunan sarana dan prasarana yang diperlukan meliputi perangkat keras, perangkat lunak dan piranti keras pengembangan, ruang kantor, dan item lainnya. Untuk masing-masingfasilitas, periode yang diperlukan untuk penggunaan harus ditunjukkan pada jadwal(timetable)

Development Risk

Pengembangan risiko melekat dalam setiap proyek. Untuk memahami kegunaan mereka, dan bagaimana mereka dapat dikendalikan, pertama-tama kita harus mendefinisikan konsepnya. Dvelopment risk adalah “suatu negara atau pemilik tugas pembangunan atau lingkungan, yang jika diabaikan, akan meningkatkan kemungkinan kegagalan proyek” (Ropponen dan Lyytinen, 2000).

Beberapa tipe dari resiko pengembangan perangkat lunak antara lain:

ü  Kesenjangan teknologi: yakni kurangnya pengetahuan profesional yang memadai dan berpengalaman cukup untuk melaksanakan tuntutan kontrak pembangunan software, adanya perbedaan pengalaman dan penegtahuan antara naggota satu dengan yang lainnya

ü  Kekurangan staf: kekurangan staff yang tidak bisa ditangani oleh staf profesional pembangun software yang lain

ü  Independensi eleman organisasi: adanya independensi dari organisasi pembuat software yang lain, sehingga apabila perusahaan meminta perusahaan lain untuk mengerjakan suatu proyek, maka kemungkinan akan ada perbedaan tipe pembuatan perangkat lunak dari perusahaan yang berbeda. Sehingga dimungkinkan penyelesaian proyek tidak sesuai jadwal.

Metode Kontrol

Untuk mengendalikan pelaksanaan proyek, manajer proyek dandepartemen manajemen menerapkan serangkaian pemantauan saatmenyiapkan laporan kemajuan dan rapat koordinasi.

Estimasi Biaya Proyek

Estimasi biaya proyek didasarkan pada perkiraan biaya proposal, diikuti oleh review menyeluruh berdasarkan perbaharuan estimasi sumber daya manusia, negosiasi kontrak dengan subkontraktor dan pemasok, dan sebagainya. Sebagai contoh, bagian dari proyek, direncanakan akan dilakukan oleh tim pengembangan internal, perlu dilakukan oleh subkontraktor, karena tidak tersedianya tim. Perubahan alam ini biasanya terlibat dalam anggaran tambahan substansial.

3. The elements of quality plan
Quality Goal

Menetapkan suatu rencana mengenai kualitas software, yakni kualitas perangkat lunak yang dicapai setelah perangkat lunak selesai dibangun. Penilaian kualitas suatu perangkat lunak biasanya diganti dengan ukuran kuantitatif yang menunjukkan kualitas perangkat lunak tersebut. Hal ini diukur melalui performansi perangkat lunak baik selama pengembangan dan selama dilakukan pengujian yang diukur secara kuantitatif.

Planned review activities

Quality plan harus menyediakan beberapa daftar dari review diantaranya: design review (DRs), design inspections, code inspections, dll dengan ketentuan dari setiap aktivitas:

Scope dari review activity
Tipe dari review activity
Jadwal dari rview
Prosedur yang digunakan
Siapa yang bertanggungjawab untuk melakukan review

Planned software test

Quality plan harus menyediakan daftar planned software test.

Unit, integrasi atau sistem yang lengkap untuk dites
Tipe dari tes yang akan dilakukan, termasuk spesifikasi dari software yang akan dites.
Jadwal tes
Prosedur yang akan digunakan
Siapa yang bertanggungjawab untuk melakukan tes

Planned acceptance test for externally development software

Perencanaan pengujian pada saat meneriman perangkat lunak dari perusahaan lain. Ada kalanya suatu perusahaan tidak bisa mennyelesaikan proyek perangkat lunak sendirian, sehingga meminta perusahaan lain untuk mengerjakan modul berkaitan dengan perangkat lunak tersebut,  setelah itu modul diintegrasikan dengan perangkat lunak yang dibangun oeh perusahaan yang mempunyai proyek. Dalam hal ini perlu diadakan pengujian terhadap modul yang dikerjakan oleh perusahaan lain tersebut. Pengujian yang dilakukan perlu direncanakan sejak awal, sehingga didapatkan modul perangkat lunak yang sesuai dengan proyek yang dilaksanakan dan sesuai dengan perencanaan proyek (meliputi biaya, waktu, dan ruang lingkup proyek)
Configuration management
Untuk merencanakan kualitas suatu perangkat lunak perlu adanya suatu manajemen konfigurasi dan prosedur, meliputi adanya perubahan suatu prosedur yang berpengaruh pada pengerjaan proyek secara keseluruhan.