The Software Development Life Cycle – Or 5 Things Not to Forget When Using Low Code BPM Applications
With lots of interest in and take up of Low Code/No Code BPM apps opening up the option to all and sundry to develop their own apps, we thought it would be pertinent to take a look at an important part of application development that will continue to exist with or without the need to code! The Software Development Life Cycle or SDLC.
What is a Software Development Life Cycle?
This is a series of phases that provide a model for the development and management of an application/system/software and is sometimes referred to as a System Development Life Cycle. The methodology can differ depending on industry but standards like ISO/IEC 12207 represent processes that provide a mode for the development, acquisition and configuration of software systems. The reason for the existence of an SDLC process is to ensure the end result is cost-efficient and fit for purpose. It usually consists of five stages:
- Requirements/Analysis
- Development
- Testing
- Release/Deployment
- Maintenance
Two different types of SDLC can be used - waterfall and agile. The waterfall process begins with a well thought-out plan and defined set of requirements. It is the more traditional model, has well-structured requirements to follow and works well for large projects that may take months to complete, while the alternative 'Agile SDLC', begins with less stringent guidelines and makes adjustments as needed throughout the process. The agile option may be more appropriate to Low Code application development as they're generally much shorter projects. However the same five phases listed below must still be taken into account at some level in both.
1. Requirements, Analysis & Governance
This stage involves determining the purpose and goals of the application, creating and documenting a set of definite requirements and metrics that need to be collected and possibly key performance indicators to examine later. This is vital and to overlook it just because you don't require code or an engineer would be a great mistake. Ignoring this important part of any project is a bad idea. We should always know why we're creating something, what we need from the application we're developing and how we're going to measure or determine its success following deployment. If governance is not already clear at this stage, it should be made clear before moving onto the second phase.
2. Design & Construction
The engineering of the software or system, or in the case of a Low Code option – dragging and dropping the elements you need! This phase will be based on the requirements set out in the Analysis phase. It would traditionally have included Risk Analysis, Functional Specifications and Non Functional specification, though a low code system may incorporate some of these elements and have them built in or with pre-built options to choose from. Again, you need to document the main design and construction decisions.
3. Testing
Static and dynamic analysis of the created application will need to be carried out. While many low code vendors may build in security measures, it will always be necessary to ensure the application is created in such a way that data collected or used is secure and compliant. Low code apps provide an intuitive user interface but you will still need to ascertain whether users understand how to use the application and determine if there are any flaws unseen during construction or development. Errors or issues discovered here mean you may be headed back to phase two or even phase one to make corrections or changes. On repeating either of those phases, it's still important to come back to a testing round again before moving onto deployment. Come back to testing as many times as you need to! If requirements are well documented, this is an easy task.
4. Release
The release phase actually takes two phases into account - a beta release, where the application is available for use by a limited audience that may also be asked to provide feedback, or with their use of the application monitored and analysed to assess if it is indeed fit for purpose, followed by a general or full release.
5. Maintenance
After a full release, the application now enters the maintenance phase. During this potentially ongoing stage, the application may still need be adjusted or further opportunities for improvement implemented which could lead your team to repeat any of the previous phases. One potential snafu you need to be aware of is that if your documentation of the app is inadequate, this will really catch you out in this phase. Good documentation will enable fast turnaround of changes and corrections, without documentation it could be difficult or, in the worst case scenario it might even be easier to redevelop the app. How much documentation do you need? The answer to this question depends on two factors: the low-code platform itself, and the complexity of the app. Ideally you will have standards and guidelines in place to help developers get the right balance. Regardless, you need to ensure that documentation is available at a level that will enable a suitably qualified individual to support, maintain and improve the app.