What is the software development life cycle (SDLC)?
The software development life cycle breaks up the process of creating an application or any software system into discrete stages. This framework enables the development teams and stakeholders to complete and evaluate each stage in turn and only move forward when they are confident that the product is ready to advance.
What are the 7 phases of the SDLC?
Companies turn to custom software because they have a need that an off-the-shelf application or system cannot fulfil. Developing a product to fill that gap has to be carried out according to a structured approach or the project has the potential to burst budgets and fail expectations. Knowing what needs to be done and when the software can be considered delivered can be difficult, especially for companies who have previously relied on existing software.
The SDLC is a well-established method of creating software and Blocshop is here to tell you that it doesn’t have to be an overwhelming process, as long as you understand the phases and what to expect.
Not everyone agrees that there are seven phases in the process. Some combine planning and requirements into the first step, others combine testing and deployment. Blocshop likes to keep these stages separate, so we end up with seven.
This stage of your project might begin with brainstorming if you aren’t yet sure of the scope or scale. You might decide to use a diagram such as a concept map or mind map to work out the limits of the project (try our own Gleek.io for creating quick, no-fuss diagrams – we couldn’t find the right design tool, so we built our own 😉). As you develop your understanding of what needs to be done, you’ll also start to identify individuals and departments that might need to be involved. Get their input. The planning phase needs to drill down into the business objectives of the project, its cost in terms of resources, how long it will take, and who will be responsible.
Covering everything you can in the planning stage will prevent a lot of pain in later stages, so don’t skimp on determining just what it is you need to build, why you need to build it, and how it will interact with the rest of the company systems and processes.
Once you know the scope of the project, it becomes easier to formally list the requirements. You can now carry out an analysis of the goals and deliverables, risks, and feasibility of the software.
At this point, you need to be working with all stakeholders to make sure that the project will meet their expectations and that they’re clear on what to expect. Detailed documentation is key here. If the project starts to go off the rails in any of the subsequent steps, you need to be able to refer back to the documentation and try to get it back on track.
Now that your team is confident about what should be built, they can move on to designing the architecture of the project, the technology stack to be used, the UI and UX – everything from the database design to the workflow. You might create some proof-of-concept mockups or prototypes, discuss alternatives, and generally make sure that the hardware and software to be used are suitable.
Now the coding starts. This phase can be slow, but if an agile approach is used, and the previous phases were properly explored and documented, a minimal viable product (MVP) should emerge and be ready for evaluation by all stakeholders. This is a risky stage, as there is a danger of feature creep if extra functionality starts to be added that wasn’t in the original requirements. If the temptation to go beyond the design docs is resisted and milestones are clearly tracked, the dev team should successfully make it through this phase and move on to testing the MVP.
This is where the MVP is put through its paces. There might be bugs, slowdowns, security holes, or problems with how data is handled. This is where these problems should be discovered. All stakeholders should have the opportunity to engage with the product and it might even be advisable to bring in user groups to find issues that aren’t obvious to people closely involved with development. On top of this, the developers will be running automated unit tests, integration tests, and generally trying their best to find any flaws.
The product works as expected and the problems have been fixed. It’s time to send it into the real world to do what it was made for. Deployment can be relatively painless, depending on the complexity of the application and the deployment method being used. Whether it operates as a standalone application or is a single service operating in tandem with other systems, the product has been released and is open to the use and abuse of the end users.
Now that the software is in the wild, and despite the rigorous testing in the testing phase, it can still behave in unexpected ways. Users have a knack of finding bugs that developers never imagined possible. The development team, or a support team, will continue to monitor and maintain the code. Fixes will inevitably be needed, features may be requested, or there may be changes in the underlying technology used that mean that updates and new versions will be released.
Blocshop and the SDLC
Blocshop follows these seven stages for every project we take on, but we’re flexible and experienced enough to be able to adapt to your needs. One of our guiding principles is that we always aim to reach an MVP as fast as possible, so that we can iterate and improve. This means that we’ll loop over these phases many times in the course of a big project. Throughout this process, we cooperate with the client to make sure that we’re delivering what’s needed, on time, and according to requirements.
If you think you need a custom software solution, contact us today to set up a call.