Software Design
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.