1. The goal of the inspection is for all of the inspector to reach consensus on a work product and approve it for use in the project.
2. The job of the inspection team is to work with the author of the document in order to identity any defects and provide a solution to fix it.
3. A moderator need to be selected to control the inspection meeting and be able to objectively evaluate the work product being inspected. The moderator need compile all of the defect resolutions into an inspection log.
------------------------------------------------------------------------------------------------------------------
| work product name: | test plan | work product version: | 1.0 |
------------------------------------------------------------------------------------------------------------------
| Attendees: | Mike, Barbara, Jill |
-------------------------------------------------------------------------------------------------------------------
| Time spent | 3 hours |
-------------------------------------------------------------------------------------------------------------------
| |
-------------------------------------------------------------------------------------------------------------------
| Issue no. | Section/page | Identified by | Issue |
--------------------------------------------------------------------------------------------------------------------
| 1 | global | Jill | the term "standard" should be replaced with |
--------------------------------------------------------------------------------------------------------------------
| 2 | section 3.1 line 1 | Mike | |
--------------------------------------------------------------------------------------------------------------------
3. Inspect the work product
During the inspection meeting, the moderator does not actually read each page out loud or give the team time to read the page. The team members read the document prior to the inspection, during their preparation. When the moderator goes through the document page by page, he simply asks the reviewers for their defects on page 1; once those are done, he asks for the defects on page 2 ...
The steps of inspection includes:
1) preparation - each inspector reviews the printed copy of the work product individually, prior to the inspection meeting.
2) overview - the moderator verifies that each inspection team member has read the printed copy of the work product.
3) page-by-page review - the moderator asks for defects on every page.
4) rework - after the inspection meeting, the author makes the changes in the inspection log and works with the inspection team members to resolve all open issues.
5) follow-up - the moderator distributes the updated work product to the inspection team.
6) approval - if any inspector feels that there are still further issues, another inspection meeting can be held. Otherwise, approve the updated work product.
More information on inspection can be found in "Software inspection " by Tom Gilb and Dorothy Graham (Addison Wesley, 1993) and "Peer reviews in software " by Karl Wiegers (Addison Wesley, 2002) Information on the effectiveness of software inspection can be found in the Software Technology Roadmap: http://www.sei.cmu.edu/str/
4. Walkthroughs
A walkthrough is an informal way of presenting a technical document in a meeting. The author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments, and ensuring that everyone present understands the work product. Work products that are commonly reviewed using a walkthrough include design specification and use cases.
5. Code reviews
In a code review, a defect is a block of code that does not properly implement its requirements, that does not function as the programmer intended, or that is not incorrect but could be improved.
The first task in a code review is to select the sample of code to be inspected. It's impossible to review every line of code. The candidate portion of the code to be reviewed is:
1) the portion of the software that only one person has the expertise to maintain.
2) the portion implements a highly abstract or tricky algorithm.
3) the code written by someone who is inexperienced or has not written that kind of code before.
4) an area of code that will be especially catastrophic if there are defects.
5) an object, library, or API that is particularly difficult to work with.
0 comments:
Post a Comment