Page 141 -
P. 141
NOTE
We encourage anyone interested in developing unit testing and refac-
toring skills to read these excellent books:
• Pragmatic Unit Testing in Java with JUnit or Pragmatic Unit
Testing in C# with NUnit by Andy Hunt and Dave Thomas
(The Pragmatic Programmers, 2004).
• Refactoring: Improving the Design of Existing Code by Martin
Fowler (Addison Wesley, 1999), and Martin Fowler’s
web site http://www.refactoring.com.
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
DESIGN AND PROGRAMMING 133