Reviews are a critical part of any process ensuring the quality of work created meets the expectations of the company and client. The challenge for any review is to ensure the focus is on clearly defined, measurable, value-added expectations. The next few posts will focus on how to construct an objective, team building review process complete with templates.
Software Reviews
Software reviews are the responsibility of the Project Manager, Business Analyst, Development Staff and Quality Assurance Team. There are basically four steps to the software review process: Scope Definition, Project Scheduling, Preparation and the Review.
| Step | Roles | Purpose |
|---|---|---|
| Scope Definition | PM, BA, Dev, QA | Ensure that the meeting is focused on the criteria that is important to the project. |
| Project Scheduling | PM, Dev, QA | Ensure that adequate time is given in the project at the appropriate review points to prepare for the meeting, conduct the meeting and make the necessary corrections. |
| Preparation | QA | This is the point where the developers assigned to review the product or the QA team reviews the work product preparing for the software review meeting. |
| Review Meeting | QA, Dev (PM, BA optional) | This is when the results of the review are discussed with the development staff and corrective actions are agreed upon and defined for the product. Optional follow-up review meetings scheduled as necessary. |
Scope Definition
Before the development team can be expected to create a software product in compliance with project expectations they first must understand the customer’s needs. Unfortunately it is too easy for the Business Analyst to become distracted by the features and capabilities of the system forgetting to identify how well those needs should perform. Too often the Project Manager and Business Analyst mistakenly assume that the development team can infer the quality expectations from the project’s functional requirements.
A review conducted without clearly defined quality expectations easily falls prey to personal preference arguments because there is no clear, measurable, quality criteria by which to grade the work product. Lack of clearly defined quality expectations in a project can become the root of an argumentative, frustrating and demeaning quality review meeting.
Each role plays a pivotal part to help define the product scope. In addition to the customer, the Project Manager, Business Analyst, Development Team and Quality Assurance Staff need to be active participants when defining the expectations for the software product. The PM ensures that realistic and attainable expectations are defined within the scope of the project acting as the final decision maker for all decisions. The Business Analyst ensures that the customer’s needs and expectations are represented, understood and documented. The developers help explain the impact of the expectations on time and cost. The Quality Assurance team ensures that any internal company quality standards are included in the plan.
A Software License Agreement documents the criteria by which a product is determined to be successfully implemented and how failure to meet the quality expectations will be addressed. The quality expectations in the Software License Agreement are non-functional requirements. To be effective all reviews must be performed in alignment with these quality expectations.
The following list of non-functional requirements can be used as a template to help define the expectations for the software product. Rate each quality on a scale from 0 to 9 where 0 is not necessary at all and 9 is critical to the success of the project. Provide details explaining why the criteria is important or unimportant to the business and how to determine that the criteria is implemented correctly.
The collected information sets expectations for the review process ensuring that value-added problems are corrected while other qualities can be given less focus. These quality goals help the development team understand where to focus their attention during the design and coding phases. Furthermore, quality goals encourage an impartial review based on measurable criteria instead of personal preferences.
| Quality | Description | Rating | Success Criteria Justification |
|---|---|---|---|
| Accessibility | Does the solution need to provide assistive technologies for people with special needs? | [0-9] | Reasoning and measurable criteria |
| Availability | Are there specific days, hours or a percentage of time that the system is expected to be operational. | ||
| Efficiency | How much of a resource can the system consume? Is it acceptable if the application uses 6 GB of RAM and 100% CPU for an hour? | ||
| Extensibility | How important is it that the system be capable of supporting additional capabilities? Are plug-ins or add-ins necessary? | ||
| Interoperability | How well does the system need to integrate with or be used by other systems? | ||
| Maintainability | How important is it that the system be debugable, able to support new features or requirements, or be adapted to operate in new environments? | ||
| Portability | Does the system need to run on multiple platforms? Is the system expected to operate on Windows, Unix, Mac, Mobile Devices or other platforms? | ||
| Responsiveness | How quickly does the system need to execute a given action? For a web site is a ten second post-back acceptable? | ||
| Resilience | How well should the system be able to manage invalid inputs? Should it be able to continue operation when hardware fails or network outages occur? | ||
| Scalability | Does the system need to be capable of handling large volumes of utilization growth? | ||
| Security | How likely is the system to be attacked? How sensitive is the data in the system? How much will people trust the system? Would people be willing to give personal information if asked? | ||
| Stability | What impact would any defects that make their way into production have on the data or operation of the company? How much impact would a failure have on the image of the development team or company? What impact would a failure have on the client? | ||
| Supportability | Does the product need to be supported by more than one or two programmers? Will the product be transitioned to another team, department or company? How much documentation is necessary to ensure an effective transition to different support groups or teams? | ||
| Testability | Will the system need to be part of a nightly build and test process? How important is it for the system to be proven after a bug fix or change request? | ||
| Usability | How important is it for the system to be naturally intuitive reducing the need to refer to documentation or other external resources to use the system? Does the system need to reduce eye-strain or repetitive fatigue? Does the system need to be constructed in accordance with a usability guide such as the Apple iPhone Usability Guide or Microsoft Usability Guide. |
Notice how these qualities help the development staff understand how to construct the system. For example, if the system needs to be constructed so that it is testable then the design may require a Model-View-Controller pattern. Should the system need to be extensible a factory pattern or command pattern may be required. So while the functional requirements can be implemented in any number of ways the non-functional, quality attributes help the developer narrow the design options to a more applicable, value-added code strategy.
Preparation
Once a work product has been completed the individuals assigned the responsibility to ensure the quality of the system will need time to review the design and/or code.
The reviewer will check for the following conditions in the work product:
- Is each feature implemented?
- Is each feature complete or have any requirements been missed?
- How well has each feature been implemented? Does the design address the quality expectations for each feature?
- Has each feature, behavior and requirement been tested?
Software Review Meeting
It is important that both experienced and unseasoned developers participate in the meeting. While it is expected that unseasoned developer’s work products will be reviewed it is equally important that experienced employees have their work reviewed as well. The review offers an excellent on the job training opportunity for the unseasoned employees. Even seasoned employees identify mistakes or tasks that could had been done better when going thru a review. Often the unseasoned employee is the one doing the most research and learning. They may be more likely to come across a new concept, strategy or tool that may improve the quality of the code. For many reasons it is important to leave egos at the door when entering a review meeting. Everybody has something to offer in the review!
Nobody should be immune to the review process. No matter how experienced all work products should be reviewed. No matter how much a person learns there is always opportunity to learn more. In a properly conducted review both the reviewee and the reviewers will have the opportunity to leave the meeting with a new perspective.
Equally important is the need to control oneself during the review. Ask yourself, “Am I pointing out a valid issue that violates the quality requirements for the project or am I simply pointing out a way of coding that I don’t like?” The purpose isn’t to make the reviewee code the way the reviewer codes. Everyone has a different way of thinking and solving problems. Everyone should have the artistic license to write the solution in the best way that he or she sees fit so long as the work product does not violate predefined quality expectations.
Avoid focusing on artistic, stylistic issues. They offer no immediate or long term value to the project. Stylistic issues simply divide the team. The only person who wins a stylistic argument is the individual with the most authority. Focusing on stylistic issues will lower team moral resulting in poor quality products.
Summary
Programming is part art and part science. The review should not be used to stifle creativity but instead ensure the proper focus of the individuals capabilities. The reviewee should never be expected to surrender their own unique individuality. Each person in the team has a different perspective that adds value to the group as a whole. The review should never make any individual feel less valuable than another. Having predefined, measurable qualities improves the effectiveness of the review as a constructive, value-added, team building activity.
Larry Steinle 
Leave a Reply