Free Trial

Safari Books Online is a digital library providing on-demand subscription access to thousands of learning resources.

Share this Page URL
Help

Chapter 10. The Software Life Cycle > Implementation - Pg. 95

The Software Life Cycle 95 Implementation During the implementation, or coding stage of a software development project, software engineers complete detailed level designs and write code. One of the key processes level three organizations complete during the implementation stage is peer reviews. During a peer review, a group of devel- opers will meet to review a software module, including the code under development, the detailed design, and the requirements of the module. To someone who is not a software developer, getting a half dozen people in a room to review, line by line, hundreds of lines of code in a software module may seem like a large waste of time. In reality, however, code reviews are one of the common processes followed by successful software development organizations of all kinds. Here is the out- line for a sample code review: Attendees We typically try to have between four to eight code reviewers (peers of the developer) from the same or related application development teams. The developer's manager attends if possible. We typically try to involve a system architect or senior developer as a facilitator for the code review. Ground Rules We have found that these ground rules are essential to making a code review productive. We always review the ground rules at the start of each code review. · No grading. The purpose of the code review is not to grade or otherwise measure the perform- ance of a developer, but to identify and resolve any issues while the code is still under devel- opment. Unless this is perfectly understood and practiced, we often find a developer's peers are unwilling to raise issues with code in front of a manager or more senior developer for fear of having a negative impact on the developer. This dilutes the entire value of the code review. · No incomplete phrases. During the review, incomplete phrases are typically well understood by all given their context. However, two weeks later, a developer will typically not be able to un- derstand the meaning of an incomplete phrase noted in the meeting minutes. When everyone speaks and writes in complete sentences, it makes follow-up on the review much simpler. · Majority rules. Everyone must agree up front that when issues are raised, they will be discussed until everyone is in agreement. This is a peer review by developers working on the same or closely related applications. If there is any question as to the validity of the design or of a code segment, this is the time to resolve it. If there is not 100 percent agreement, then those in the minority must ultimately, if they cannot sway others to their case, side with the majority view. · Stay intellectually committed. It takes a lot of effort to follow, line by line, the code of another developer. However, everyone in the code review is making a major investment in the review for the benefit of the entire team. Everyone needs to be 100 percent committed to the review process and not duck what they perceive are issues. Requirements Review The developer presents the requirements that have been allocated to the module. Design Review The developer presents the detailed design of the module. Visual aids used include flow charts, UML diagrams, call graph trees, class hierarchies, and user interface components.