Some software design tips
Filed Under Design, Tips, Techniques, Improvement, Development, Software | Posted on September 6, 2007
This is a very hard topic. Given the types of design practices followed, the various platforms for which software is made, and the thinking of different individuals regarding how to do effective design, you may or may not agree with what all appears in this article. So if you do not agree or have some comments, please provide those as well and I will try and modify after reviewing the comments.
So first of all, what is 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 high-level conceptualization, low-level component and algorithm implementation issues as well as the architectural view.
It is very important to have a good design and not to short-circuit the design process, only then will you have a software that allows addition of new modules and capabilities without shaking everything, a software that can be tested easily for quality, a software that does not break easily under stress or when somebody is deliberating trying to break the system, and most of all, the software can be easily maintained for a long time by a different set of people with minimum problems.
How do you go about the process of software design ?
You start with conceptualization. Designers tend to start thinking out the big issues in advance, including using techniques such as UML that allows them to get away from the coding thought process and more into an effective design mode. This allows the building of a well thought design rather than an initial system built on technical compromises that breaks under strain or makes change very difficult. However this should not mean that the designer is not well versed with coding, else you will have castle in the air approach. Essentially, the trade off is between making a good design not constrained by compromises but which is yet implementable.
Design should be flexible
It is a common paradigm of software development that requirements and specifications are never final when they should be (or they can change later). But a designer has a specific schedule, so the idea should be to build a system that can incorporate changes without having to redo the entire project, for example, building a component based architecture. However, proponents of Xtreme Programming oppose this, because it is more expensive to build, and you just need to build a structure that can grow.
Reusability
In many cases, there is an existing design for a component or module that can be used without any modification or with a slight modification. Designers and developers should use these components / modules. If you are able to reuse component libraries produced and (presumably) validated by a reputable outside source, rather than developing your own solution for every single problem you encounter, you can start trusting part of the software no less than you trust the machine on which it runs.
Getting the architecture right
Getting the architecture of the system is absolutely essential. If your architecture is flawed, you are either bound to redo or to fail, or to keep on doing patchwork which can be rather expensive. The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. The term also refers to documentation of a system’s software architecture. Documenting software architecture facilitates communication between stakeholders, documents early decisions about high-level design, and allows reuse of design components and patterns between projects.
Build a design that is accessible
Nowadays, there is an increased push for building software that is accessible to all sets of users including users who are handicapped in some way. It is already a part of Government regulations, and the concept is catching onto some extent, and will no doubt be pushed along as legal frameworks start to emerge. The accessibility and usability of software, and the amount of additional access technology configuration required, is determined primarily by the design techniques that the software author adopts. The basic ‘out of the box’ accessibility and usability of software is hugely improved for many users if software design teams use inclusive and user-centred design principles. 2 resources for helping with this are the ISO 9241-171 and the IBM software accessibility checklists.
Watch out for design patterns and use them effectively
A design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.
Get your documentation in shape and easy to understand, and comprehensive
So you know a lot about what the design is, and carry the information in your head and it all makes sense to you. Now, what about the next person who has to understand the design, or to a person who takes over after you move (leaving the company, or to another project). If the design is not easy to understand and detailed enough, it is likely that sections will have to be redone, so don’t compromise on the design documentation.
A design document is a description of a software product that a software designer writes in order to give a software development team an overall guidance of the architecture of the software project. It usually accompanies an architecture diagram and has pointers to the detailed feature specifications of smaller pieces of the design. A design document needs to be stable reference, and outline all parts of the software and how they will work. The document should give a fairly complete description.
The Software Design Document (SDD) is a comprehensive software design model consisting of four distinct but interrelated activities: data design, architectural design, interface design, and procedural design.
Get variety in design people
You might consider yourself as a very capable designer, or maybe the best, but it is always good to get more opinion. It is more than likely that another person will come up with a new thought or a refinement, plus will be able to catch mistakes (what!!) that you have made. Successful design is done by teams. Creative leaps might be taken by individuals, but design thrives on the different points of view found in teams. In addition, the process of discussion and debate that happens goes a long way in making the design stronger.
Client interaction
Typically, a client could be the external agency for which the software is being made or an internal customer who owns the software. It is essential that the client be involved in periodic reviews as the software is made. The design decides the infrastructure, the schedule, resource requirements as well as the total cost, so it is essential that the client be satisfied about the design. At the same time, it is essential that the review sessions move towards a solution, and not get into an reversal of previous decisions on a regular basis.
Leave a Reply
