The preliminary design is a key step in the early stages of software development, where customer requirements and use cases support the creation of the system architecture. User Interface documents, screen navigation flow, entity relationship diagrams, and system architecture documents are some of the items that should be included in the design. With these inputs, the preliminary design will present the visual representation of the system at project outset. As developers, we often obtain an assignment and want to go directly into the development phase without fully understanding the customer’s request. However, creating the preliminary designs improve Software Development by giving you a floor plan, ensuring shared understanding, preventing mistakes, identifying risks, and supporting additional research.
Benefits of a Preliminary Design Phase
Provides You With A Blue Print: Think of the design as your floor plan for that dream house you want. The dream house can’t be created without detailed planning and design based on the contractor’s understanding of your final vision. This same concept applies when it comes to creating software. Once the high-level vision of a system is understood, we need to break it down into pieces in order to formulate a plan of action.
Ensures Shared Understanding: A preliminary design provides a reference point to open a dialogue between the development staff and the customer to ensure the application flow is adequate. This may be your first opportunity to ensure that your understanding of the application as the developer is the same as the customer’s.
Prevents Mistakes: “Measure twice, cut once”; taking the old carpentry advice and applying it to software development, the preliminary design helps the developer ensure they have included everything they need before getting into the heavy work. It provides an opportunity to ensure all data elements are being captured in a clear and concise manner prior to full blown development.
Identifies Risks: During the formulation of a preliminary design, we should always be mindful of risks and strive to create an architecture that is flexible and contains reusable components. Areas of duplication should be refactored as the design is created and reviewed by the development team. As new features are requested a flexible architecture can be easily tailored to implement the new changes.
Supports Additional Solution Research: The preliminary design could also provide time to do valuable research by analyzing the success and failures of similar projects. Items such as scalability and site demand could greatly benefit from such an analysis. Many times projects are viewed as a failure when users aren’t able to utilize an application. This is usually the result of a lack of analysis to determine the necessary infrastructure to support the utilization demands once it has been placed into production.
How to Get Started
A solid approach to creating a good design would be to first create an application flow chart. From there, begin to break things down into features or modules. After isolating the features, begin creating graphical user interface (GUI) mock-ups detailing the data elements and the initial navigational flow. Create the conceptual database design to include tables, stored procedures, etc. needed to implement the feature. After completing the previous artifacts, begin creating the middle tier design, keeping in mind how a given feature fits into the overall design. Make sure incremental peer reviews are conducted within the team so that the developers are in tune with the architecture and areas for improvement can be identified. There will undoubtedly be problems that will arise throughout the development process but taking the time to think through and document the design strategy will minimize the impact to the project in the long run.
Regardless of the development methodology, the preliminary design should prove to be a vital aspect of the formulation of a solution. Sure, taking the time to draft the design may seem time consuming but it will save you time in the long run.