Software inspection is one of the most common sorts of review practices to be found in most software projects. The main focus or goal involved in any inspection is for the team to reach a majority agreement on a new or improved work product and then go on to approve it for use in the general project.

Most software inspections include 2 major processes known as software requirement specifications and the test plans. An inspection involves a work product being carefully selected for a review and then a team of developers are gathered for an inspections feedback meeting to review the software in question.

A chair is chosen to preside and moderate the meeting to ensure the smooth running of the meeting as software inspections are known for the time they take to complete. Each software inspector prepares for the inspection by carefully reading the work product and then formatting constructive feedback for the team making a note of any defects they have found.

This is the main purpose of any planned inspection, to identify and rectify any defects within the work product. A defect is defined as any part of the work product that would prevent a potential inspector from approving it. If the product was being inspected for software requirements specification then a defect would be any part of the text which an inspector believes is a defect of disagrees with, these defects are then discussed collectively within the meeting.

The first structured software inspection process was developed my Michael Fagan in the mid - 1970s and it has later been extended and modified, to meet the needs of a more modern inspection process. Any inspection process should have an entry criteria, this will determine if and when the inspection process is ready to begin, this is vital for preventing unfinished or inadequate work products from entering the inspection process. The entry criteria usually consist of a checklist which includes item such as - the document has been spell checked.

There are 6 main areas to any competent inspections process and usually consist of planning, preparation, inspection meeting, rework and follow-up. There is a certain degree of flexibility in this approach but sticking to the guidelines where possible will ensure a smooth and efficient software review process. If you are part of a software inspection team it is important you fully understand the work product in question and make accurate notes about any defects involved.

If you would like to learn more about Software Inspection please visit our Code Review Site

This entry was posted on Thursday, June 25th, 2009 at 9:31 pm and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.