"Many studies in industry have shown that a significant portion (between 50 and 65 percent) of errors and defects during the total development of software are introduced during the design phase or activities associated with design."
-- Ann Miller

Practice Description
Analysis and design methods should be based on the project's domain area, application area, and desired output design model.

Practice Essentials

• Design of software components should be done in accordance with structured methods that are defined in detail in the SDP.
   
• The software detailed design methods should be consistent with the design methods used for architecture design.
   
• End-user functionality should be visible in the software design description.
   
• The execution process should be visible in the software design, including performance, availability, concurrency, fault-tolerance, threads of control, and processes (groups of tasks that form an executable unit).
   
• Physical software components and their interfaces should be visible in a design description.
   
• The mapping of physical software components onto individual hardware components should be visible.
   
• States and state transition should be visible in the design description if the system has more than one state.
   
• Each of the above views of the software should be documented in a graphical notation.
   
• Operational scenarios should be defined that show how the different views of design work together.
   
• Reuse, COTS, GOTS, and program library software components should be mapped into the physical software and database components.
   
• System and software requirements should be traced to the software and database physical components.

Implementation Guidelines

• When reuse of existing software is planned, the system and software architectures will be designed to facilitate this reuse.
   
• When an incremental release life cycle model is planned, the system and software architectures will be completed in the first release or, at most, extended in releases after the first without changes to the architecture of previous releases.
   
• The system and software architectures will be verified using methods specified in the SDP. This verification will be conducted during a formal inspection of the software architecture and will include corroboration that the architecture will support all reuse, performance, interoperability, security, safety, and reliability requirements.
   
• The architecture will be under CM.
   
• The structured design method should be selected first, then select an automated tool that enforces the selected method.
   
• When an incremental-release life cycle model is followed, incremental releases should be defined in a way that gives low risk that design implemented in one release will be modified in a later release.
   
• Design should be verified by a formal structured method (inspection or simulation) before the design is put under CM.
   
• Design should be under CM change control before coding is begun to fill in the design.
   
• Each of the design views defined in the Unified Modeling Language (UML) notation guide should be considered:
   
  • Download UML from www.rational.com/UML
  • Static structure diagrams
  • Use CASE diagrams
  • Sequence diagrams
  • Collaboration diagrams
  • State chart diagrams
  • Activity diagrams
  • Implementation diagrams
     
• Design should not be represented in a program design language (pseudocode) because pseudocode affects the partitioning and complexity management reasons for design.
   
• Design should be done to minimize complexity and maximize understandability.
   
• Design diagrams should be developed with a CASE tool that enforces notation and semantic rules, not with a drawing tool.
   
• When substantial reuse is planned, design should minimize the need to modify the reuse software.
   
• The approach to design should never be to write code before design and then reverse engineer the design from this code.
   
• A programming language should be selected that was developed to implement the design method.
   
  • If C++ is selected to implement an OO design, remember that C, which was designed to manipulate computer hardware, is a major subset of C++.
  • Write programming standards and conventions for use of C++ to code OO design that restrict use of C syntax not appropriate for the design objectives of OO methods.

Things to Watch Out For

• Design often does not isolate and minimize that part of the software that implements security and safety requirements.
   
• Software Development Files, which contain critical design rationale information, are usually not deliverable.
   
• When CASE tools are used for design, CASE tool output files that contain the design are seldom deliverables.
   
• On some projects, the method for developing design is to skip design, write source code, and then reverse engineer the design diagram from the code with a tool.
   
• Many projects have no written guidelines concerning design quality and other design conventions and constraints.
   
• Programmers who modify the source code that implements the design sometimes change the design.
   
• Some projects, which use automatic code translation software to translate code from programming language X to programming language Y, end up with a design appropriate for language X being coded in language Y, which was not developed with that type of design in mind.
   
• Sometimes projects are forced into this because compilers are not available for the new platforms, and they do not have the funds to redesign the system.
   
• This saves a penny in development, but costs a dollar in maintenance.
   
• The structured analysis/design methodologies developed in the 1970s and 1980s are often described as "obsolete" by those who advocate OO methods such as UML. But survey after survey at software engineering seminars continue to find that only 20 to 30 percent of the project teams claim to be using OO methods. What are all the other project teams doing?
   
• No methodology seems to be the order of the day in many organizations, especially in those moving from RAD (Rapid Application Development) to FAD (Frantic Application Development).

Figuring Out Where You Are - Project Quicklook
 
Chapter 6 contains a series of detailed questions that can be applied to any program to determine the health of its design and coding approach. These questions should be applied on a regular basis. An inappropriate answer to any of the questions could indicate a serious problem and merits further investigation.

top

---