At Mobnia we pride ourselves in building digital products that help you succeed. But how do you build a software product that is reliable and robust? This is the first in a series of posts that address this question.
There are a few important steps required for a successful software development project. Different development models may handle them in different ways but they remain integral to any model you choose. This is an overview of these steps.
There has to be a plan for every project. You need to find out a few key things before starting. For instance, the why of the project - i.e what value will it be creating (value proposition) and who the customers are (customer segmentation). Determining what the customers need (MVP) and what they want (not necessarily the same thing). These are then turned into a requirements document.
This document tells customers what they're getting and project members what they'll be building. Very importantly it should also capture what constitutes the metrics of success for the client. This will serve as a guide to keep the project going in the right direction. You can always check back to see if some feature is included in the requirements or not.
When you have the requirements, you can map out the high-level design of your project. This design should specify things like the platforms the software will run on and its interfaces with external systems. It should also include high-level information on the project architecture specifying what the various components do and how they act, but as few details as possible on how they do their jobs. You need to ensure that it covers every aspect of the requirements.
The low-level design of a component of the project (broken down from the high-level design process), contains information about how the said component should work. It should be at a low enough level to be helpful to developers that will build the component. At this point, you may also discover interactions between application components that may require changes.
The developers take the low-level designs and refine them until they can be implemented as code. The code is tested as well, to remove bugs (as many as possible).
Bug-free code is unattainable. Several kinds of tests are however performed to limit the amount of bugs in the project. Developers test their own code, then other testers (who didn't write the code) test it. The code is then integrated with the rest of the project and the project is tested to ensure everything still works. It is important that bugs be discovered as early as possible. The longer they remain in the project, the harder they are to fix.
Deployment can be complicated and unpredictable, or really simple, depending on the nature of your project. The important thing is getting it out into the customers' hands. Because of the unpredictability of issues that could come up in this phase, you should budget some extra time in the project schedule to handle complications.
This is one of the most valuable steps of the software development process. For some reason, previously undiscovered bugs usually appear when the application is launched into the wild. Bug-fixing is then required. New features and enhancements are also constantly in the pipeline that may also introduce bugs. Software projects require maintenance even after deployment.
The project should be evaluated after it has been wrapped up. You need to find out what went right and what went wrong and learn lessons for the future.
In many cases, to save time, some of above tasks can be done simultaneously. The negative trade-off of this is that some bugs and problems could be discovered later in the process than would have been the case if each of the tasks was performed individually.