Before writing one line of code, the first step in a software project is the design step. Whether the design step takes five minutes, five days, or five months, depends on the scope of the project and the seriousness and maturity of the software team. In my opinion, spending an adequate amount of time on the software design is what differentiates between a professional and an amateur development team and what makes the difference between a highly successful and a less successful final product.
Before discussing the best approaches to a successful design I would like to provide my own definition of “software design.”
Software Design: is the process by which the customer requirements, and the architecture (consisting of the rules and the logic of the software project) are defined and extracted from the “customer’s story.”
Customer Requirements
The customer requirements are the first part of the design process. Many times, the customer does not know exactly what s/he wants. This makes sense, since the customer doesn’t fully understand the limits and abilities of the software. It is the software development team’s responsibility to teach the customer about the system’s possibilities and to define the project requirements based on the “desires” of the customer. This process is best achieved by sitting down with the customer and having them tell their story of the final product. In this session (or multiple sessions, for a complex project) it is important to learn how the customer intends to use the software, once developed.
Architecture
The word architecture is an interesting choice when talking about software. True, just like any other engineering project, a software project does have its own architecture. However, unlike a hardware project, or a mechanical project, a software project is much more dynamic. New requirements, that were not there at the start of the design, always come up. Thus, the architecture of the software needs to be adaptive to future, unknown requirements. (See the article on Software Maintenance where I compare software development to growing a garden.)
For example, assume that a customer asks us to develop an elevator controller for their four stories building. One approach would be to assume that each floor is a state and the software controls the transition between the four states (floors). A better approach would be to design an elevator controller that could handle an infinite number of floors. Instead of considering each floor a separate state, the elevator controller would have only three states: up, down and stop. At each floor the software would then handle the transition between these three states.
In the elevator controller example, the second architectural choice is more desired. Sooner or later, there will be a new set of requirements that will need to support more floors.
At DMMD we prefer designing modular software that is similar to an IKEA furniture. Visere 5 is entirely SDK based. The main executable is a backbone that handles the communication between the SDKs. The rest of Visere is made up of plug-ins. This provides a very flexible architecture that can be customized for 1D, 2D, and 3D applications. Having different plug-ins allows DMMD to develop customized plug-ins for different customers.
In my next post, I will go over my preferred software design strategies and discuss how to cement the architectural design ideas. I will also discuss methodologies for keeping track of new requirements.
– Darian Muresan
no comments