Skip to end of metadata
Go to start of metadata

Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software is determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.

The software requirements analysis (SRA) step of a software development process yields specifications that are used in software engineering. If the software is "semiautomated" or user centered, software design may involve user experience design yielding a story board to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-formal methods like Unified Modeling Language and Fundamental modeling concepts. In either case some documentation of the plan is usually the product of the design.

A software design may be platform-independent or platform-specific, depending on the availability of the technology called for by the design.

The act of design includes:

  • Consideration of many possible technology options
  • Examination and identification of constraints
  • Thought about the pros and cons of using various patterns and styles
  • Comparing various splits of role and responsibility
  • Looking at various tradeoffs of complexity versus function
  • Formulation of opinion on possible future directions of system growth

A large proportion of this information is lost when the design document is written, because the focus is typically on providing a (notionally) definitive view of how a system should be structured which might be in the form of a bunch of UML diagrams or merely a collection of Visio-type diagrams and explanation of what each of the boxes in the diagrams does. At the code-level there is almost no chance that any of this information will have been retained. Yet this information is of high value since it:

  • is the explanation as to why a design is the way it is
  • provides reviewers with a clearer view of what was and was not considered
  • forms the basis for assessment of the maturity of a designer and can be used for coaching/mentoring
  • can provide insight for those with less experience
  • contains assumptions which if breached by changes in circumstance would dictate a re-design
  • dictates to a large extent how suitable for purpose a design might be
    Thus I believe It's important to expose elements of the act of design via documentation alongside the design itself, conversations during the design work etc.

SOA Design rules

FAQ

  • [Question still to be asked..]
Labels:
glossary glossary Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.