"The overall process for designing a user interface begins with the creation of different models of system function (as perceived from the outside). The human- and computer-oriented tasks that are required to achieve system function are then delineated; design issues that apply to all interface designs are considered; tools are used to prototype and ultimately implement the design model; and the result is evaluated for quality."

--Roger S. Pressman 

Design Twice, Code Once

In many ways, building a software system resembles building a house. In both cases, shoddy work on the foundation will not only make the rest of the project difficult, it will cause repeated problems over time. Design is literally the foundation upon which the entire software superstructure is going to be built.
 
Design is not easy. It is inherently a mental process. The objective is to decide which components will make up a system, identify how those components will interact, and then record those decisions for later use. As the complexity of the system being developed increases, so does the inability of the human mind to deal with this complexity. In fact, studies have shown that 50 to 65 percent of defects can be traced to design.
While there is no sure method for success, any time software is to be developed, good design principles will help in dealing with difficult problems.

Key principles include:

• A clear, well-understood design and analysis methodology should be followed. The method should be selected based on the project's domain area, application area, and desired output model. Always remember that the objective is to answer the "how" question; for example, how will requirements be satisfied?
   
• Any analysis and design method is necessarily an iterative approach. It will proceed through a series of refinements to reach a clear statement of "how" things are going to work. The methodology should allow for this iteration as well as facilitate the engineers in tracing requirements through these iterations to their final design solution.
   
• At each stage of refinement, the method should minimize the number of components with which an engineer has to deal with (typically 5 to 9 items), especially if there are a large number of interactions. There is a close analogy here to the principle of "span of control" in establishing an organization. In the same way that a manager would find it difficult to monitor the functions and interactions of a large number of sub-units, the software engineer will have a difficult time envisioning and comprehending the interactions of a large number of components.
   
• The Software Development Plan (SDP) should describe in detail the methodology to be followed by the development team. The plan should reflect how the analysis and design method supports later stages of the software development process.
   
• During analysis and design, the software engineer will make decisions about the software architecture; i.e., what software components exist and how these components will interact among themselves and with their environment. The methodology followed should facilitate recording and communicating these decisions to team members. In doing so it is crucial that the following types of information be communicated:
   
  • How end-user functionality (requirements) is being satisfied by the design.
  • The execution process the software product must support. Key characteristics that should be visible in the software design include performance, availability, concurrency, fault-tolerance, threads of control, and processes (groups of tasks that form an executable unit).
  • Software components and their interfaces.
  • The relationship between hardware and software components.
  • States and state transitions.
     
• There are many ways to describe the multitude of information that goes into the design of a system. Since pictures tend to be a compact way of presenting a great deal of information, the software should be documented in a graphical notation.
   
• Remember that the ultimate authority for system performance is the user. Since design decisions will constrain how the system is used, it is critically important that the user review the design. Often the best way to get feedback is to describe operational scenarios that show how the system will operate.
   
• The product of design is a set of "blueprints" for coders' use in system implementation. These blueprints can and should be taken through a series of formal inspections

Since analysis and design is a demanding, mental process, it is sometimes difficult to determine when it's time to "stop." The program manager must strike a delicate balance between allowing coding to start too early (before all design decisions have been made and documented) and slowing the schedule. One technique is to use a "pull" system, whereby the coding team "pulls" the design description into the coding phase rather than having it "pushed" by the designers. The transition criteria for moving a component from the design stage to coding should be clearly delineated in the SDP. The criteria should reflect acceptance by the coders as well as meeting quality criteria (e.g., some defect density as determined by formal inspections).

top

---