Software Design

{excerpt}Software design is a *process* of problem-solving and planning for a software solution.{excerpt} 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.

{include:Design-Time Governance - SOA Design Rules}