Difference between revisions of "Review Techniques"

From EUDP
Jump to: navigation, search
(How in detail)
(How in detail)
Line 1: Line 1:
 
 
== What ==
 
== What ==
  

Revision as of 12:32, 26 August 2009

What

Review documentation.

Tx oodocs a5a8a57702.gif

How

The dish

Review of documentation.

Ingredients

  • All produced documents.

Process

The EUDP-review is a method which distinguishes itself by transferring other people's knowledge and experience to the construction/product which is to be developed. Be it software, hardware or mechanics. The purpose of a review meeting is to consider and discuss the methods the developer has used to solve a specific task. At the meeting you will discuss e.g. defects, weaknesses, or give good advice as to the further development etc.

The review procedure should be applied as early in the project phase as possible. Additionally, you should review on a continuous basis throughout the entire project period. In other words you should hold a review meeting whenever you need to verify your construction/product.

How in detail

The procedure of a review should be as follows:

The developer invites competent colleagues to a review meeting. Appoint one to be the chairman. It is important that it is a person who is qualified to handle conflicts in a constructive way i.e. somebody who is able to deal with things professionally with emphasis on the further development of the construction or product in question. Besides the chairman, it can be a great advantage to appoint a note taker, so the developer can concentrate on the meeting without being disturbed in his thoughts and ideas. Alternatively, it could be a good idea to bring along a dictaphone.

Remember to provide the participants with documentation, diagrams, listed programs and the like before the actual meeting. Thereby, the participants have the opportunity to make preparations for the upcoming meeting.

At the meeting the developer explains how the construction/product he has developed works. The colleagues ask questions and try to find defects or weaknesses in the construction/product.

Do not be afraid to review! It is better to discover defects in the construction before it leaves for production. It is both cheaper and easier to deal with such issues in the construction phase. The earlier the better.

The participants have different tasks at the meeting. In the following you will find a list of the various tasks according to which role you play at the review meeting:


If you are the chairman, you have the following tasks:

  1.     Make sure that one person finishes speaking before you allow somebody new to talk. 
  2.     Make sure that the meeting is held in a proper and constructive tone.
  3.     If conflicts arise, make sure that an action plan is carried out.
  4.     If there is no note taker, write down notes to give to the developer after the meeting.


If you are the reviewer, you have the following tasks:

  1.     You need to form a clear picture of the construction/product that has been developed.
  2.     Ask how the developer has made it.
  3.     Ask elaborating questions which are related to no 1. and 2.  
  4.     Ask why the developer has made certain choices during the progress.
  5.     Ask questions beginning with: " Why didn't you do......?".
  6.     Or ask: "Did you consider .......... ?".
  7.     Look for defects and weaknesses in the construction/product.
  8.     Give constructive criticism.
  9.     Give credit to the developer, if he has developed good solutions.
 10.      REMEMBER THAT YOU ARE PRESENT AT THE MEETING TO HELP!
 11.      REMEMER THAT IT IS NOT YOUR CONSTRUCTION/PRODUCT!


If you are the developer, you have the following tasks:

  1.     Explain the functions of the construction/product in question:     divide the construction/product into smaller parts to give your audience a better overview.
   Any construction/product can be divided into mechanics, electronics and software. Electronics can be divided into printed circuit boards, which again can be divided into different parts of a diagram. Use the path of the signal, power supply or the like. Software can also be divided into parts such as different classes which are used in the same component, i.e. user interface, etc.
  2.     Do not keep anything secret.   
  3.     Inform about the choices you have made. Put emphasis on the difficult ones.
  4.     Be open-minded towards criticism. Remember that the participants are present to help.
  5.     Be open-minded towards corrections. Think about your product and its quality. Do not get offended. Appreciate feedback.
  6.     Remember to schedule a new review meeting.           

This were suggestions for the participants' different roles at review meetings. At the EUDP-project we believe reviewing to be a highly important aspect. Therefore, the EUDP-method highly recommends review meetings on a continuous basis throughout the entire project. Many companies have developed their own methods. Some follow the International standard: IEC 1160 and Amendment 1: IEC 61160.