Code walkthrough is an informal code analysis technique. I a walkthrough session, the material being examined is presented by a review and evaluated by a team of reviewers. The reviewer “walks though” the work product, and reviewers raise questions on the issues of concern. A walkthrough is not a project review, but is rather an in depth examination of selected work products by individuals who are qualified to give expert opinions.

Members of a walkthrough team may include the project leader, other members of the project team, a representative from the quality assurance group, a technical writer, and other technical personnel who have an interest in the project. Customers and users should be included in walkthrough during the requirements and preliminarily design phases, but they are usually excluded from subsequent walkthrough sessions.

During the walkthrough session, problems are not resolved. Rather the goal is to discover and make note of problem areas. They are resolved by the reviewer, once the walkthrough session gets over. A follow-up meeting or follow-up memo should be used, which will inform the reviewers of actions taken. The reviewer may work with one or more reviewers to resolved problems, but it is the reviewer’s to ensure that the problems noted during the walkthrough are solved.

Even though a code walkthrough is an informal analysis technique, several guidelines have evolved over the years for making this technique more effective and useful. These guidelines are based on personal experience, common sense, and several subjective factors. Some of these guidelines are as follows:

•    The team performing the code walk through should not be either too big or too small. Ideally, it should consist of three to seven members.

•    The duration of a code review should be of a reasonable duration. A balance should be struck between the length of the review and the attention span of the reviewers.

•    Discussion should focus on discovery of errors and not on how to fix the discovered errors.

•    Major issues should be addressed. Although it is sometimes difficult to distinguish between major and minor issues, walkthrough sessions should not degenerate into detailed discussions of minor problems.

Factors that contribute to the success of walkthrough include emphasizing the detection of major problems, limiting the time duration of each walkthrough and scheduling walkthrough for each team member on a regular basis.

•    Walkthrough improve project team communication and project moral by involving team members in the walkthrough process.

•    Walkthrough are an excellent educational medium for new team members.

•    As early the bugs are found in the life cycle of a product, the cheaper and easier they are to fix.

•    If someone else looks at your code or design, they are likely to find mistakes you missed.

•    You can learn a lot by reading other people’s code.

•    The process of explaining your software to someone else can help you actuality review tour own program, rather than just looking at and seeing what you expect or want to see.

•    When done right, code and design reviews can save time and improve quality over the entire project life cycle.

The disadvantage of code walkthrough is that they take time, not only of the person actively working on the project, but also for other people who are usually under deadline pressure themselves.

For more help in Code Walkthroughs click the button below to submit your homework assignment