Choosing an application design strategy
The design process occupies a significant place in software development, for it marks transition from the problem phase to the solution phase. The contents of the Software Requirements Specification document (SRS) document that describes the project objectives serve as a basis for the design. The two popular design approaches—the top-down and bottom-up, significantly influence the project’s cost and completion time. Choosing the ‘right’ approach is not entirely straight-forward because each has its own advantages and disadvantages. This essentially necessitates intense brain-storming by the design and development teams to finalize the strategy.
This approach considers the entire application as an interconnection of different modules. Each module is further decomposed into smaller components. The degree of system refinement increases with each level of decomposition. In a broad sense, this approach can be viewed as the reverse engineering of a system.
From a specifications perspective, top-down approach is preferable. With a clear picture of all the modules that need to be designed, this approach complies well with the contents of the SRS document. This ensures clarity in the functional requirement of each module.
This approach involves building the system from the lowest possible level to the highest, until the end result is obtained. Greater emphasis is laid on lower level design parameters such as compatibility with the platform in which the software is likely to be deployed, and interconnection between different modules. In a nutshell, bottom-up approach specifies the individual elements constituting a system in greater detail.
Which among the two is better?
Top-down approach tends to assume a high degree of clarity among both clients and consultants during the design and development phases. Hence, it specifies the exact modules to be designed; once there is clarity on the modules to be designed, coding the modules is a fairly straight-forward process. In reality this is seldom the case. Project requirements tend to change and consultants are bound to fine-tune the design accordingly. If the new set of requirements cannot be accommodated within a module already designed (using top-down approach), then the entire process has to be redone. For example, accommodating a demand for cloud level compatibility is difficult, when the original design did not incorporate it. This leaves little room for agility.
Also, the potential problems introduced by the ‘interconnection’ between modules could go unchecked until the final phase of testing. A complete top-down approach could potentially avoid addressing issues of platform level compatibility.
The bottom-up approach, on the other hand is more flexible. Working from the lowest level of the system, ensures that issues like platform compatibility are addressed, at the very beginning. In the event of upgrading an existing product with new features, bottom-up approach allows the teams to focus on the exact module that needs to be changed. Making changes to a small portion or increment of the whole product allows changes to be introduced more easily, unlike the top-down approach. Essentially, the bottom-up approach allows more agility.
The biggest encouragement for developers to go for bottom-up approach is the ability to reuse the code. This essentially yields smaller programs and thereby lesser complexity during testing or debugging.
Testing: an important consideration
An important activity in any software development process is the testing. Testing smaller parts of the application to rectify errors at an early stage—incremental testing, has become the norm. It is worth emphasizing here that bottom-up approach allows greater room for incremental testing than the top-down approach. This is advantageous because rectifying an error in the small part of a system costs a lot less than testing the whole system. Integration testing, performed during the integration of different modules is easier with bottom-up approach.
On the other hand, top-down approach offers little or no room for incremental testing, as no module can be tested until it is fully complete. Also, any faults in the design could potentially go unchecked due to lesser scope for examining the lower level.
All these do not mean that bottom-up approach is the method to be adopted in designing, while top-down could be shunned. Excessive concentration on the low-level requirements could result in higher level requirements being missed out, which the top-down approach guarantees.
In reality, no project can be implemented entirely using a single approach. Teams are required to leverage the advantages of both the approaches to deliver the project at the shortest possible time and by consuming limited resources.