Applied Software Project Management

Diagnosing Review Problems

Many organizations rely on their testers (or, in worse cases, their users) to find the bulk of the defects in the software they produce. When the defects are caused by simple coding errors or typos, they are easy to correct. Unfortunately, very few defects are caused by simple coding errors or typos. Most defects are introduced before a single line of code is written. Sometimes a programmer misunderstands the design; at other times, the entire team fails to take a stakeholder's needs into account and fails to build a needed feature into the software. Waiting until after the software is built to discover these problems results in an enormous amount of work to fix defects that should have been caught before a single line of code was written.

Problems Are Found Too Late

There are many problems that can be avoided by having the team adopt vision and scope documents, project plans, software requirements specifications, and other project documents. But what happens when the team doesn't catch an error in one of these documents until the software is built?

One of the most common causes of project failure is that requirements contain a defect that is not caught until much later in the project. Trying to fix that defect after the software is built can be so costly that it can destroy the project entirely. For example, suppose that a team member writes a use case document to describe a critical feature. The document is emailed around to the team, and everyone reads ...