Software Design

A software developer wrote to me: “Is software design a theoretical concept to be taught in college but not used in industry? I have worked as developer for two years but rarely saw any design in my company. We often go from requirements to code to get projects complete faster. Is design necessary? Can you explain about software design?”

Answer: Software design is not a concept to be taught in college. It is widely used in software industry. “Code first, ask question later” is a bad habit and should not be used. It seems that your company management is not properly trained on software development process.

By definition, software design is a process of problem solving and planning for a software solution. In software, there are many possible solutions. There is no “right” or “wrong” solution but only “better” or “worse” depending on the problem that you are trying to solve. Because software is a product of the mind, not physical things like hardware, a house, or a bridge, you have no explicit rule that you must follow. However, there are two factors which will determine the designing of your solution: How well do you understand the problem? and how well do you understand your solution?

In software, understanding the problem means you must know about technical constraints, functional requirements, quality attributes, and business constraints. By knowing these constraints, you will set the limitation of your solution. Functional requirements are what the solution must do while quality attributes deal with how well it performs certain functions. The business constraints are limitation due to business reasons such as budget or schedule. You cannot exceed certain amount of money or take forever to build software.

The solution is all the possibilities that you can think of. As developer, it is your job to select the best possible solution to a problem. Your understanding of the problem limits your selection to a few so you must analyze them and select the best. If you cannot make decision, you may build a “prototype” or temporary solution and ask the customers to make decision for you.

In software design, there are few basic approaches. A Planned Design requires that the design must be completed before you can implement. This approach is associated with waterfall lifecycles. It is assumed that you know all requirements and they will not change. An Evolutionary Design allows you to design the solution incrementally as it is implemented. You start design in small piece then implement it to see how it work then continue to repeat the same step again until done. This approach is associated with the Spiral lifecycle or Incremental release lifecycle. The Emergent Design allows the design of the system to occur as the system is implemented without specific intentions. It is often associated with Agile approach such as Scrum. Since requirements may change anytime therefore design may also change with each Sprint.

There is no perfect solution as well as no perfect design approach in software. What you do is determined by the amount of risk that your team is going to take. Less risk implies that you anticipate less change as it gives you more options in your design. Architect and Design will depend on your team’s preferences and experience. A less experienced team should not choose a complex design because it is risky. The more you understand the problem and its constraints, the better you can come up with a design. If you time is short, if your budget is tight then you do not have much choice in designing. The less you know about a problem then you will have difficulty in making decision about your design and that is why requirements engineer and system architect are so important in software project.

To come up with better design, you must learn more about the problem that you are trying to solve. If your team feels that they do not know enough about the problem based on the requirements specification, you need to conduct discussions with customer and users to increase your knowledge about the problem. If the team feels there is a lot of risk on the project then you should explore prototype approach then get your users to try. Another option is to follow a design process such as the Architecture Centric Design Methodology (ACDM). ACDM is a staged design process that encourages teams to explore the design through experiments by addressing issues in proposed designs. ACDM strongly focuses on quality attributes and will help your team toward a planned design approach but the process can be adjusted to use a different design if your team wants to.

Sources

  • Blogs of Prof. John Vu, Carnegie Mellon University