Work Related | 1st August 2019
Software Development Life Cycle or SDLC in short is a term used to describe the steps which are, or should be, taken during the development of software. In this article I will talk about my thoughts on what SDLC should be.
SDLC serves a very specific purpose: quality control. No matter what steps are taken or for what reason, the entire process is meant to control the quality of the software which is deployed to production and on which the business will run. My definition for SDLC is: A series of steps taken during the development of a solution to adhere to a certain set of quality requirements and a process surrounding those steps.
I have created a scale in which I divide maturity in SDLC.
In my mind the best and most efficient way to work is a change based method. By this I mean a developer changes something and that "change" is pulled through the process. Another way to do this is by collecting all changes into a release and pulling the release through the entire process. This has a couple of inefficiencies though: There is a reason for every change to be made, this is one of the first steps in the process and this means you start individually per change and later bundle them. Second reason is every change can fail somewhere in the process and will block the other changes from progressing. By handling every change independently the developers are able to work more independently, have more control over their "own" work and the business can possibly get fixes and features faster.
Apart from all the technical measures which can be taken in the process there are steps which should be implemented on a process level to improve the overall quality of the changes. First there must be a reason to change something, this is commonly called a business case. This reason should be valid not only to the business but also for the project. What I am saying here is that a requested feature does not always have to be implemented in the project it is requested for, you might have another project which has this feature or is a better place. If the reason is valid the requirements for the change should be known; Technical and Business requirements: what should be changed and how, what does the business expect? Keep asking the business questions! They often do not really know what they want in your opinion so make it as clear as possible what you will deliver. Tools exists to help you with requirement analysis, for technical requirements I have found the goSDL tool by Slack to be useful.
There are two processes which should be taken into account as part of your total SDLC:
Maintenance and Decommissioning.
Maintenance are the agreements to which extend you take action on unexpected behaviour of the software. The maintaining team should be capable of delivering on the promises made and have the resources to do so; A 24/7 response can not be done if the response team is 1 person.
Decommissioning is the process of removing a project from use by the business. The term legacy applications is found frequently whilst newer applications already exist to take over (part of) the functionality. Policies and agreements should be implemented (and followed) to decommission old projects. As a rule of thumb try to have functionality only exist in one application at a time.
Technical debt, or however you call it, is all the technical stuff the team is aware of which should be acted on but do not directly provide business value. Whilst not strictly needed to be part of your SDLC process/implementation/considerations I think you can have significant impact with adding this. Because the more technical debt you have the more instable the application can be considered.