Chapter 8

Reviews
Proses pengembangan sebuah produk perangkat lunak secara umum, terutama dalam fase analisis dan
fase desain, adanya sebuah dokumen desain di mana kemajuan pekerjaan pembangunan yang
dilakukan dicatat. Seorang sistem analis atau analis akan menyiapkan dokumen akan memeriksa
berulang-ulang, itu harus diasumsikan, untuk mendeteksi setiap kesalahan yang mungkin terjadi. Selain
itu, pemimpin tim pengembangan juga diharapkan untuk memeriksa dokumen ini dan rinciannya untuk
mendeteksi setiap kesalahan yang tersisa sebelum memberikan persetujuan mereka.
Namun karena para profesional terlibat dalam memproduksi dokumen, mereka akan sulit bagi mereka
untuk mendeteksi beberapa kesalahan mereka sendiri. Oleh karena itu, hanya orang lain yang mampu
mereview produk dan mendeteksi kesalahan tanpa diketahui oleh tim pengembangan.
Seperti yang didefinisikan oleh IEEE (1990), proses review (peninjauan) adalah:
"Sebuah proses atau pertemuan selama pengerjaan sebuah produk atau seperangkat produk.
Peninjauan dilakukan terhadap personil proyek, manajer, pengguna, pelanggan, atau pihak lain
yang berkepentingan untuk mendapatkan komentar atau persetujuan."
Beberapa metodologi dapat diimplementasikan pada kegiatan review dokumen.
Dalam bab ini, akan dibahas metode berikut:
-

Review desain formal

Rekan review (pemeriksaan dan penelusuran)
Pendapat ahli.

8.1 Tujuan Review

Tujuan langsung :
-

Untuk mendeteksi kesalahan analisis dan desain serta hal-hal dimana koreksi, perubahan dan
penyelesaian diperlukan sehubungan dengan spesifikasi asli dan perubahan yang disetujui.
Untuk mengidentifikasi risiko baru yang dapat mempengaruhi penyelesaian proyek.
Untuk menemukan penyimpangan dari template dan prosedur gaya dan konvensi. Koreksi
terhadap penyimpangan ini diharapkan dapat berkontribusi untuk meningkatkan komunikasi dan
koordinasi yang dihasilkan dari keseragaman yang lebih besar dari metode dan gaya
dokumentasi.
Menyetujui analisis atau desain produk. Persetujuan memungkinkan tim untuk melanjutkan ke
tahap pengembangan berikutnya.

Tujuan tidak langsung :

-

Untuk menyediakan tempat pertemuan informal untuk pertukaran pengetahuan profesional

tentang metode pengembangan, alat dan teknik.
Untuk merekam kesalahan dalam analisis dan desain yang akan berfungsi sebagai dasar bagi
tindakan perbaikan di masa depan. Tindakan perbaikan yang diharapkan dapat meningkatkan
metode pengembangan dengan meningkatkan efektifitas dan kualitas, antara fitur-fitur produk
lainnya.

8.2 Review desain formal / Formal design reviews (DRs)

Review desain formal, disebut juga "review desain", "DRs" atau "review teknis formal (FTR)", berbeda
dari semua instrumen review lainnya dengan menjadi satu-satunya review yang diperlukan untuk

mendapatkan persetujuan suatu desain produk. Tanpa persetujuan ini, tim pengembangan tidak dapat
melanjutkan ke tahap berikutnya dari proyek pengembangan perangkat lunak. Review desain formal
dapat dilakukan seti.
Daftar umum review desain formal diberikan dalam Bingkai 8.2.
Frame 8 Some common formal design reviews
DPR
SRSR
PDR
DDR
DBDR
TPR
STPR
VDR
OMR
SMR
TRR
PRR
IPR

Development Plan Review

Software Requirement Specification Review
Preliminary Design Review
Detailed Design Review
Data Base Design Review
Test Plan Review
Software Test Procedure Review
Version Description Review
Operator Manual Review
Support Manual Review
Test Readiness Review
Product Release Review
Installation Plan Review

Sauer dan Jeffery (2000) membahas berbagai faktor yang mempengaruhi efektivitas DRs, berdasarkan
hasil penelitian dan survei yang luas tentang literatur. Diskusi kita pada review desain formal akan fokus
pada:
-

Para peserta
Persiapan-persipaan sebelum review
Sesi DR
Kegiatan Pasca-DR yang direkomendasikan

8.2.1 Para peserta di DR

Semua DRs dilakukan oleh seorang pemimpin review dan tim review. Pemilihan peserta yang tepat
adalah suatu kepentingan khusus karena kekuatan mereka untuk menyetujui atau menolak suatu desain
produk.
Pemimpin Review
Penunjukan seorang pemimpin review yang tepat adalah faktor utama yang mempengaruhi keberhasilan
DR itu, karakteristik berikut harus dicari dari seorang kandidat untuk posisi ini:
-

Pengetahuan dan pengalaman dalam pengembangan proyek dari jenis yang sama dengan yang
direview. Pengetahuan dengan proyek saat ini tidak diperlukan.
Senioritas, sama atau lebih tinggi dari pemimpin proyek.
Sebuah hubungan baik dengan pemimpin proyek dan timnya.
Bukan anggota tim proyek.
Jadi, kandidat yang tepat untuk pemimpin review tim termasuk manajer departemen
pengembangan, para kepala insinyur perangkat lunak, para pemimpin proyek lain, kepala unit
jaminan kualitas perangkat lunak, atau kepala insinyur perangkat lunak dari sisi pelanggan.

Departemen pengembangan sekala kecil dan software house kecil biasanya memiliki tingkat kesulitan
yang lebih besar untuk menemukan kandidat yang tepat untuk memimpin tim peninjau. Salah satu solusi
yang mungkin untuk masalah ini adalah penunjukan konsultan eksternal untuk posisi ini.

Tim Review
Seluruh tim review harus dipilih diantara anggota senior tim proyek bersama-sama dengan profesional
senior yang sesuai untuk ditugaskan untuk proyek lain dan departemen, perwakilan pelanggan
pengguna, dan dalam beberapa kasus adalah konsultan pengembangan perangkat lunak. Hal ini
diinginkan untuk membentuk tim review dengan anggota mayoritas dari luar staf proyek.
Sebuah tim review yang terdiri dari 3 sampai 5 anggota diharapkan menjadi tim yang efisien, mengingat
keragaman pengalaman dan pendekatan di antara para peserta bisa terjamin. Sebuah tim yang terlalu
besar cenderung menciptakan masalah koordinasi, buang waktu sesi review dan mengurangi tingkat
persiapan, berdasarkan kecenderungan yang mengasumsikan bahwa orang lain telah membaca
dokumen desain tertentu.

8.2.2 Persiapan untuk DR

Meskipun persiapan untuk sesi DR harus dilengkapi oleh ketiga peserta utama dalam review (pemimpin
review, tim review dan tim pengembangan) setiap peserta diminta untuk fokus pada aspek-aspek yang
berbeda dari suatu proses.

Persiapan pemimpin review

Tugas utama pemimpin review di tahap persiapan adalah:
-

Untuk menunjuk anggota tim

Untuk membuat jadwal sesi-sesi review
Untuk mendistribusikan dokumen desain antar anggota tim (hard copy, file elektronik, dll).

Ini sangat penting bahwa sesi review dijadwalkan segera setelah dokumen desain telah dibagikan
kepada anggota tim review. Ketepatan waktu sesi review mencegah tertundanya waktu bagi tim proyek
memulai tahap perkembangan selanjutnya, artinya dapat mengurangi risiko perubahan jadwal
pengembangan.
Persiapan tim review
Anggota tim diharapkan dapat review dokumen desain dan daftar komentar mereka sebelum sesi review
dimulai. Dalam kasus dimana dokumen yang cukup besar, pemimpin review dapat meringankan beban
dengan menentukan bahwa setiap anggota tim review hanya mengerjakan bagian tertentu dari dokumen.
Persiapan tim pengembangan
Kewajiban utama tim pengembang dalam sesi review adalah untuk menyiapkan presentasi singkat dari
dokumen desain. Dengan asumsi bahwa anggota tim review telah membaca dokumen desain secara
menyeluruh dan sekarang memahami garis besar proyek, maka presentasi harus fokus pada isu-isu
profesional utama menunggu persetujuan dari tim review.

8.2.3 Sesi DR

Pengalaman pemimpin review ini dalam memimpin diskusi dan mengatur agenda adalah kunci sukses
untuk sesi DR. Agenda khas sesi DR meliputi:
1) Sebuah presentasi singkat dari dokumen desain.

2) Komentar yang dibuat oleh anggota tim review.

3) Verifikasi dan validasi di mana setiap komentar dibahas untuk menentukan tindakan yang
diperlukan (koreksi, perubahan dan penambahan) yang harus tim proyek lakukan.
4) Keputusan tentang desain produk (dokumen), yang menentukan kemajuan proyek. Keputusankeputusan ini dapat mengambil tiga bentuk:
- Persetujuan penuh - memungkinkan untuk langsung berlanjut ke tahap berikutnya dari
proyek. Persetujuan penuh dapat disertai dengan tuntutan beberapa koreksi kecil yang akan
dilakukan oleh tim proyek.
- Persetujuan parsial - persetujuan untuk langsung berlanjut ke tahap berikutnya dari beberapa
fase proyek, dengan item tindakan utama (koreksi, perubahan dan penambahan) yang
diminta untuk proyek lainnya.
- Persetujuan ditolak - menuntut pengulangan DR. Keputusan ini diterapkan karena terdapat
beberapa cacat utama, cacat yang sangat kritis.
8.2.4 Kegiatan pasca review
Selain dari laporan DR, tim DR atau yang mewakili diperlukan untuk menindaklanjuti kinerja kegiatan
koreksi dan untuk memeriksa bagian yang dikoreksi.
Laporan DR
Salah satu tanggung jawab pemimpin review adalah masalah laporan DR segera setelah sesi review.
Cepatnya penyampaian laporan DR memungkinkan tim pengembang untuk melakukan koreksi
sebelumnya dan meminimalkan penundaan petugas sehubungan dengan jadwal proyek.
Bagian utama laporan memuat:
-

Sebuah ringkasan diskusi review.

Keputusan tentang kelanjutan proyek.
Sebuah daftar lengkap dari tindakan yang dibutuhkan - koreksi, perubahan dan penambahan
bahwa tim proyek harus lakukan. Untuk setiap item tindakan, tanggal penyelesaian proyek harus
ditentukan dan anggota tim yang bertanggung jawab harus dibuat daftarnya.
Nama dari anggota tim review yang ditugaskan untuk menindaklanjuti pekerjaan koreksi.

Form yang ditampilkan dalam Lampiran 8A menyajikan item data yang perlu didokumentasikan untuk
laporan DR inklusif.
Proses tindak lanjut
Orang yang ditunjuk untuk menindaklanjuti kegiatan koreksi, biasanya seorang pemimpin review sendiri,
diperlukan untuk menentukan apakah setiap item tindakan telah memuaskan sebagai syarat agar proyek
dapat dilanjutkan ke tahap berikutnya. Tindak lanjut harus sepenuhnya didokumentasikan sebagai bahan
klarifikasi dari koreksi di masa depan, jika perlu.
13 " pedoman emas " menurut Pressman untuk pelaksanaan desain review yang sukses
(Pressman 2000, Bab 8)
Infrastruktur Desain review

Mengembangkan checklist untuk setiap jenis dokumen desain, atau setidaknya untuk dokumen
yang bersifat umum.
Melatih para profesional senior tentang masalah teknis serta masalah proses suatu review. Para
profesional yang terlatih berfungsi sebagai reservoir untuk tim DR.
Secara berkala menganalisis efektivitas DR terakhir sehubungan dengan cacat yang terdeteksi
untuk meningkatkan metodologi DR.

Menjadikan jadwal DRs sebagai bagian dari rencana kegiatan proyek dan mengalokasikan
sumber daya yang dibutuhkan sebagai bagian integral dari prosedur standar operasi
pengembangan perangkat lunak organisasi.

Tim desain review

tim Review harus dibatasi dalam ukuran, biasanya 3-5 anggota sudah optimal.

Sesi desain review

Mendiskusikan isu-isu profesional dalam cara yang konstruktif dan menahan diri dari isu-isu
pribadi.
Patuhi agenda review. Melemceng dari agenda yang direncanakan akan mengganggu efisiensi
review ini.
Fokus pada proses deteksi cacat dengan memverifikasi dan memvalidasi komentar-komentar
peserta. Tidak membahas solusi untuk memperbaiki cacat yang terdeteksi sehingga dapat
menghemat waktu dan tidak lepas dari agenda.
Jika ada ketidaksepakatan tentang pentingnya sebuah kesalahan, maka segera akhiri
perdebatan dan membawa masalah ini ke forum lain untuk dibahas.
Mendokumentasikan hasil diskusi dengan benar, terutama rincian komentar peserta dan hasil
verifikasi dan validasi. Langkah ini terutama penting jika dokumentasi digunakan sebagai
masukan atau dasar untuk penyusunan laporan review.
Durasi sesi review tidak boleh lebih dari 2 jam.

Kegiatan pasca review

Siapkan laporan review, berupa rangkuman isu yang didiskusikan danitem tindakan.
Menetapkan prosedur tindak lanjut untuk memastikan kinerja yang memuaskan dari semua
koreksi masuk ke dalam daftar item tindakan.

8.3 Peer reviews

Dua metode peer review, inspeksi dan penelusuran, dibahas dalam bagian ini. Perbedaan utama
antara review desain formal dan metode peer review terletak pada peserta mereka dan otoritas.
Sementara sebagian besar peserta dalam DRs memegang posisi tinggi hingga pemimpin proyek dan
perwakilan pelanggan, sedangkan peserta dalam peer review adalah, seperti yang diharapkan,
setara pemimpin proyek, anggota departemen dan unit lainnya. Perbedaan utama lainnya terletak
pada tingkat otoritas dan tujuan dari setiap metode review. Review desain formal berwenang untuk
menyetujui dokumen desain, sehingga pekerjaan pada tahap selanjutnya dari proyek dapat dimulai.
Otoritas ini tidak diberikan kepada peer review, yang tujuan utama terletak pada mendeteksi
kesalahan dan penyimpangan dari standar yangdibuat.
Sekarang ini, dengan munculnya alat desain terkomputerisasi, termasuk CASE tools, beberapa
profesional cenderung mengurangi nilai review manual seperti inspeksi dan penelusuran. Namun
demikian, survei perangkat lunak di masa lalu meyakini bahwa peer review adalah metode yang
sangat efisien dan efektif.
Apa yang membedakan walkthrough dan inspeksi adalah tingkat formalitas, dimana inspeksi lebih
formal. Inspeksi menekankan pada tindakan korektif. Temuan hasil inspeksi juga dimasukkan ke
dalam upaya untuk meningkatkan metode pengembangan. Sedangkan temuan hasil walkthrough
adalah terbatas hanya sebatas memberikan komentar pada dokumen review.
Inspeksi biasanya didasarkan pada infrastruktur yang komprehensif, termasuk:

Pembuatan checklist inspeksi untuk setiap jenis dokumen desain serta bahasa coding dan alat,
yang secara berkala diperbarui.

Pengembangan tabel frekuensi jenis cacat khas, berdasarkan temuan sebelumnya.

Pelatihan kompetensi profesional dalam hal proses inspeksi untuk sebagai syarat menjadi
pimpinan atau anggota tim inspeksi.
Secara periodik mengadakan analisis efektivitas inspeksi terakhir untuk meningkatkan
metodologi inspeksi.
Menginformasikan jadwal inspeksi ke dalam rencana kegiatan proyek dan alokasi sumber daya
yang diperlukan, termasuk sumber daya untuk koreksi cacat terdeteksi.

8.3.1 Peserta peer review

Tim peer review terdiri dari 3-5 peserta. Dalam kasus tertentu, penambahan 1-3 peserta
diperbolehkan.
Semua peserta harus rekan-rekan dari desainer atau penulis sistem perangkat lunak.
Faktor utama yang berkontribusi terhadap keberhasilan dari peer review adalah kelompok
"campuran" (yang berbeda antara inspeksi dan penelusuran).
Sebuah tim peer review yang disarankan termasuk:

Seorang pemimpin review

Penulis program
Profesional khusus.

Pemimpin Review
Peran pemimpin review ("moderator" dalam inspeksi, "koordinator" dalam walkthrough) hanya sedikit
berbeda menurut jenis peer review. Calon untuk posisi ini harus:
1) Berpengalaman dalam pengembangan proyek serupa sebelumnya dan mengenal teknologinya.
Pengetahuan awal dengan proyek saat ini tidak diperlukan.
2) Menjaga hubungan baik dengan penulis dan tim pengembangan.
3) Berasal dari luar tim proyek.
4) Memperlihatkan pengalaman dalam koordinasi dan kepemimpinan dalam pertemuan profesional.
5) Untuk inspeksi, pelatihan sebagai moderator juga diperlukan.
Penulis
Penulis adalah, selalu menjadi peserta dalam setiap jenis peer review.
Profesional khusus
Para profesional khusus berpartisipasi dalam dua metode peer review berbeda dengan review.
Untuk inspeksi, para profesional yang direkomendasikan adalah:

Seorang desainer: analis sistem bertanggung jawab untuk analisis dan desain sistem perangkat
lunak yang sedang di-review.
Seorang coder atau pelaksana: seorang profesional yang bertugas untuk coding, dipilih
pemimpin tim pengkodean.
Seorang tester: profesional yang berpengalaman, sebaiknya pemimpin tim pengujian yang
ditetapkan, yang berfokus pada identifikasi kesalahan desain biasanya terdeteksi selama fase
pengujian.

Untuk walkthrough, para profesional yang direkomendasikan adalah:

Seorang Penegak standar. Ini anggota tim, yang mengkhususkan diri dalam pengembangan
standar dan prosedur, diberikan tugas mencari penyimpangan dari standar-standar dan prosedur.
Kesalahan jenis ini yang secara substansial mempengaruhi efektivitas jangka panjang tim,

pertama karena mereka menyebabkan kesulitan tambahan untuk anggota baru bergabung
dengan tim pengembangan, dan kemudian karena mereka akan mengurangi efektivitas tim yang
akan mempertahankan sistem.
Seorang ahli pemeliharaan yang dipanggil untuk fokus pada masalah pemeliharaan, fleksibilitas
dan testability (lihat Bab 3), dan untuk mendeteksi cacat desain yang mampu menghambat
koreksi bug atau kinerja perubahan masa depan.
Seorang wakil dari pengguna. Partisipasi internal atau eksternal dalam tim panduan
berkontribusi untuk validitas review karena dia memeriksa sistem perangkat lunak dari sudut
pandang userconsumer daripada desainer -pemasok.

Tugas tim
Dalam melakukan sesi review membutuhkan tugas tugas khusus untuk anggota tim. Dua diantaranya
adalah presenter dokumen dan juru tulis, yang mendokumentasikan hasil diskusi.

Presenter. Selama sesi inspeksi, presenter dokumen dipilih oleh moderator, biasanya, presenter
bukanlah penulis dokumen. Dalam banyak kasus seorang programmer (coder) bertugas sebagai
presenter karena ia adalah anggota tim yang paling memahami logika desain dan implikasinya
untuk coding. Sebaliknya, untuk sesi walkthrough biasanya dipilih penulis dokumen sebagai
presenter.
Juru tulis (notulen). Pemimpin tim biasanya bertugas sebagai juru tulis untuk sesi ini, dan
mencatat semua cacat yang akan dikoreksi oleh tim pengembangan.

8.3.2 Persiapan untuk sesi peer review

Tugas utama pemimpin review di tahap persiapan adalah:

Untuk menentukan, bersama dengan penulis, bagian dari dokumen desain yang harus direview.
Bagian tersebut dapat:
o Bagian yang paling sulit dan kompleks
o Bagian yang paling kritis, di mana cacat dapat menyebabkan kerusakan parah pada
program aplikasi dan pengguna
o Bagian yang rentan terdapat cacat.
Untuk memilih anggota tim.
Untuk membuat jadwal sesi peer review.
Untuk mendistribusikan dokumen kepada anggota tim sebelum sesi review.

Persiapan tim peer review untuk sesi review

Persiapan yang diperlukan anggota tim inspeksi adalah cukup menyeluruh, sedangkan yang diperlukan
anggota tim walkthrough adalah yang singkat.
Anggota tim Inspeksi diharapkan untuk membaca bagian dokumen yang akan terakhir dan daftar
komentar mereka sebelum sesi inspeksi dimulai. Persiapan awal Ini dimaksudkan untuk menjamin
efektivitas sesi. Mereka juga akan diminta untuk berpartisipasi dalam pertemuan review. Pada pertemuan
ini, anggota tim inspeksi diperlukan untuk review bagian-bagian dokumen yang dipilih: proyek secara
umum, logika, proses, output, input, dan interface.
Sebuah alat penting yang mendukung review ini adalah checklist.
Sebentar sebelum sesi walkthrough, anggota tim membaca materi dalam rangka untuk mendapatkan
gambaran umum dari bagian yang direview, proyek dan lingkungannya. Dalam kebanyakan organisasi
mempekerjakan orang dalam walkthrough, peserta tim tidak diharuskan untuk mempersiapkan komentar
mereka diawal.

8.3.3 Sesi peer review

Sebuah sesi yang khas dalam peer review mengambil formulir berikut. Presenter membaca bagian dari
dokumen dan menambahkan, jika diperlukan, penjelasan secara singkat tentang isu yang terlibat dengan
kata-katanya sendiri. Saat sesi berlangsung, para peserta memberikan komentar mereka atau
memberikan reaksi terhadap komentar-komentar yang muncul. Diskusi harus dibatasi pada identifikasi
kesalahan, bukan pada solusi tentatif. Tidak seperti sesi inspeksi, agenda sesi walkthrough biasanya
dibuka dengan presentasi singkat penulis atau gambaran proyek dan bagian desain yang akan direview.
Sesi dokumentasi
Dokumentasi yang dihasilkan pada akhir sesi inspeksi jauh lebih komprehensif daripada sesi
walkthrough.
Dua dokumen yang harus dibuat setelah sesi inspeksi dan kemudian didistribusikan di antara peserta
sesi adalah:
(1) Laporan temuan sesi inspeksi. Laporan ini, dibuati oleh juru tulis, harus selesai dan
didistribusikan segera setelah penutupan sesi.Tujuan utamanya adalah untuk menjamin
dokumentasi yang masih banyak kesalahan yang diidentifikasi untuk segera koreksi dan ditindak
lanjuti.
(2) Laporan ringkas sesi inspeksi. Laporan ini harus disusun oleh pemimpin inspeksi sesaat setelah
sesi atau serangkaian sesi. Laporan berupa rangkuman temuan-temuan inspeksi dan sumber
daya yang diinvestasikan dalam inspeksi, juga menyajikan kualitas dasar dan metrik efisiensi.
Laporan ini berfungsi terutama sebagai masukan untuk analisis yang ditujukan untuk perbaikan
proses inspeksi dan tindakan korektif pada dokumen atau proyek tertentu.

8.3.4 Kegiatan pasca-peer review

Sebuah elemen fundamental membedakan antara dua metode peer review dibahas di sini adalah
masalah pasca-peer review.
Proses inspeksi, berbeda dengan walkthrough, tidak berakhir dengan sesi review atau distribusi laporan.
Pasca-kegiatan inspeksi dilakukan untuk membuktikan:

Koreksi cepat efektif dan pengerjaan ulang dari semua kesalahan

Mengirim laporan inspeksi kepada Corrective Action Board (CAB) untuk dianalisis. Tindakan ini
memulai tindakan korektif dan pencegahan yang akan mengurangi cacat masa depan dan
meningkatkan produktivitas

Perbandingan dari metode peer review, peserta dan elemen proses yang disajikan dalam Gambar 8.2.
8.3.5 Tingkat efisiensi peer review
Masalah efisiensi pendeteksian cacat dengan metode peer review dibandingkan dengan metode lain
dalam SQA terus-menerus diperdebatkan. Beberapa metrik yang lebih umum diterapkan untuk
memperkirakan efisiensi peer review, seperti yang disarankan dalam literatur, adalah:

efisiensi deteksi pada peer review (rata-rata jam kerja per cacat terdeteksi).
kepadatan d eteksi cacat pada peer review (jumlah rata-rata cacat terdeteksi per halaman dari
dokumen desain).

efektivitas peer review internal (persentase cacat dideteksi oleh peer review sebagai persentase
dari keseluruhan cacat terdeteksi oleh pengembang).

8.4 A comparison of the team review methods

Perbandingan 3 metode tim review adalah sebagai berikut:

8.5 Pendapat ahli

Metode review terakhir adalah penggunaan pendapat ahli. Pendapat ahli, disiapkan oleh para ahli di luar,
mendukung evaluasi kualitas dengan memperkenalkan kemampuan tambahan untuk staf review internal.
Kegiatan jaminan mutu internal organisasi dengan demikian diperkuat. Mengirimkan para ahli di luar
keahlian mereka dengan baik:

Mempersiapkan penilaian ahli tentang sebuah dokumen atau bagian kode.

Berpartisipasi sebagai anggota dari sebuah tim inspeksi review desain internal.

Penilaian ahli luar serta partisipasi nya sebagai anggota eksternal dari tim review yang paling
menguntungkan dalam situasi berikut:

Kurangnya kemampuan profesional internal di area khusus.

Kurangnya internal profesional untuk berpartisipasi dalam tim review karena tekanan beban kerja
dan akan menyebabkan penundaan besar dalam jadwal penyelesaian proyek.
Keraguan yang disebabkan oleh perselisihan utama di antara profesional senior organisasi.
Dalam organisasi kecil, di mana jumlah kandidat yang cocok untuk tim review tidak cukup.

10