Formal Design Review dan Peer Review dalam pengembangan software

Dalam sebuah SQA Architecture, yang memastikan langkah pengerjaan software berjalan dengan  baik adalah pada langkah Project Life Cycle. Dalam beberapa tahapan dalam langkah tersebut yang pertama adalah formal design review dan peer review.

                Sebelum membahas lebih lanjut mengenai kedua jenis review tersebut, kita coba melihat terlebih dahulu review dalam konteks pengembangan sebuah software. Review dilakukan saat setelah perencanaan software telah disahkan oleh pihak pengembang dan pelanggan. Setelah itu, dilakukan uji kembali guna melihat design keselurhan dari pengembangan software untuk di verifikasi kemudian di validasi.

                Kemudian dari situ kita bisa memastikan bahwa design dan pengembangan software telah memenuhi syarat yang telah kita inginkan. Dari jenis review yang ada, menurut Galin, ada 2 yakni Formal design review dan peer review, berikut detail penjelasannya :

Formal Design Review :

                Secara umum, Formal Design review atau biasa disebut dengan Design Review (DR) merupakan suatu review yang menjadi syarat mutlak. Tanpa ada persetujuan dari review ini, pengembangan software tidak dapat dilakukan. Menurut Galin, jenis – jenis dari DR antara lain :

-          DPR – Development Plan Review

-          SRSR – Software Requirement Specification Review

-          PDR – Preliminary Design Review

-          DDR – Detailed Design Review

-          DBDR – Data Base Design Review

-          TPR – Test Plan Review

-          STPR – Software Test Procedure Review

-          VDR – Version Description Review

-          OMR – Operator Manual Review

-          SMR – Support Manual Review

-          TRR – Test Readiness Review

-          PRR – Product Release Review

-          IPR – Installation Plan Review

Menurut Sauer dan Jeffery (200), diskusi dan focus dalam DR meliputi :

-          The participants

-          The prior preparations

-          The DR session

-          The recommended post-DR activities.

1.       Participant

Participant dalam formal design review terdiri dari :

§  Review leader

Memastikan bahwa review berjalan dengan baik, dengan syarat biasanya telah memiliki pengalaman dalam pengembangan software sebelumnya serta memiliki relasi yang kuat dengan project leader.

§   Review Team

Bagian dari tim yang terdiri dari orang2 yang dipercaya oleh ketua review untuk membantu pelaksanaan review

2.       Preparations

Persiapan yang dapat dilakukan antara lain :

§  Menyiapkan jobdesk untuk review tim serta segala persiapannya

§  Menyiapkan review tools yang dapat digunakan dalam proses review secara keseluruhan

§  Persiapan teknis dan administratif

3.       DR sessions

Merupakan sesi pelaksanaan review yang terdiri dari aktifitas

§  Presentasi design dokumen yang telah dibuat

§  Komentar serta evaluasi dari review team

§  Verifikasi dan validasi berdasarkan dari hasil komentar dan evaluasi yang didiskusikan bersama

§  Keputusan yang berupa :

·         FULL APPROVAL : disutujui semua design yang telah dibuat

·         PARTIAL APPROVAL : ada beberapa bagian yang harus direvisi dan proyek akan berjalan setelah revisi

·         DENIAL OF APPROVAL : penolakan dari design sehinngga development team harus mendesign ulang

4.       Recommended post DR terdiri dari hasil evaluasi dari proses revie

PEER REVIEW

                Sedangkan peer review cenderung lebih kompleks dan menyeluruh dimana terdiri dari beebrapa participant yang lebih yakni :

-          A review leader

-          The author

-          Specialized professional

Yakni ada tambahan review dari professional yang memang ditujukan untuk membantu proses review. Dimana disarankan berupa :

o   A designer : seorang yang mendesain system

o   A coder : yang melakukan code dari pengembang

o   A tester ; seorang tester professional

Sedangkan untuk walkthrough beberapa professional yang disarankan antara lain :

o   A standar enforcer : dimana seorang yang telah berpengalaman dalam penentuan standard an prosedur.

o   A maintenance expert : seseorang yang telah ahli dalam proses maintenance software sehingga bisa didapat masukan untuk proses implementasi software.

o   A user representative : calon user yang telah berpengalaman dalam penggunaan software sejenis

Peer review proses :

Dilaksanakan dalam sebuah dokumen dalam petunjuk2 Appendix C of MIL-STD-498 (DOD, 1994) dimana untuk system penilaian error didasarkan pada penilaian skala berikut :

Severity               Description

5 (critical)                     (1) Prevents accomplishment of essential capabilities.

(2) Jeopardizes safety, security or other critical requirements.

4                                  (1) Adversely affects the accomplishment of essential capabilities,

where no work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to project or

system maintenance, where no work-around solution is known.

3                                  (1) Adversely affects the accomplishment of essential capabilities,

where a work-around solution is known.

(2) Adversely affects technical, cost or schedule risks to the

development project or to the system maintenance, where a work-around solution is known.

2                                  (1) User/operator inconvenience that does not affect required mission

or operational essential capabilities.

(2) Inconvenience for developmentor maintenance personnel, but

does not prevent the realization of those responsibilities.

1                              (minor) Any other effect.