Section 7.1. Review the Design

7.1. Review the Design

In many project teams, the programmers begin coding as soon as they have a software requirements specification that everyone agrees on. Typically, the first programming tasks usually involve building a user interface that supports each use case, and creating an object model that implements each of the functional requirements.

The designers and programmers have several options:

• The programmers can simply start building the code and create the objects and user interface elements.

• Designers can build a user interface prototype to demonstrate to the users, stakeholders, and the rest of the team. Any code used to develop the prototype is typically thrown away once the design has been finalized.

• Pictures, flow charts, data flow diagrams, database design diagrams, and other visual tools can be used to determine aspects of the design and architecture.

• An object model can be developed on paper, either using code, simple class diagrams, or Unified Modeling Language (UML) diagrams.

• A written design specification is written, which includes some or all of these tools.

In order to ensure that the software is designed well, the project manager works with the team during the creation of the work breakdown structure and estimates (see Chapter 3) to determine which of these options is appropriate for the project. The design tasks should be estimated and included in the project schedule; this requires that the team agree on a single design approach from the outset of the project.

The design tasks should always include reviews, even when there is no written design specification. If the programmers dive immediately into the user interface design, they should hold a walkthrough with the users. This may involve taking screenshots of the UI and turning them into a slide presentation, or it may mean that the programmers give a thorough demonstration of the user interface.

Any written documentation should be reviewed and, if possible, inspected. However, it is important that the reviews and inspections reach the correct audience. Many users who have important input for the user interface may be uninterested or confused by object models and UML diagrams. If all of these elements are bundled into a single design specification, it is important that the scope of each review is clearit's reasonable to have individual people review only the part of the design specification that they are interested in.