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
1
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.
2
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.
3
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.
4
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.
5
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,
6
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.
7
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).
8
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:
9
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
