Its a different fun and as well as a challenge to write on something as basic as SDLC. SDLC stands for ‘Software Development Life Cycle’ and is the term which contains the different stages which happen when we develop a software.
I am sure that if you are in software development then this term wont be new for you but I am not sure whether we understand this in simpler terms. So I would explain this in brief with the help of a case-study.
Imagine that we have to develop a website for a ‘Taxi booking’ website. This taxi-booking site would offer its users the services of booking a taxi right from anywhere through internet. A user can just visit the site, fill the necessary information like source, destination, kind of taxi and be done with it. If you have to develop this website, you might get tempted to think that you can do it in jiffy since you know the requirements. Its a very simple problem to solve. Well, not really and that is why the first step in SDLC is the most critical and people who have been around would vouch that if we could do this first step really really well, rest of it is more of execution.
This first step is called ‘Requirement Gathering’ where you list down all the things which you would expect this software to do. You start with the big requirement and then break that further and keep on doing that when you are really confident that anyone who reads your list would understand exactly what you thought.
Practically you would never reach a stage called ‘Correct and Complete’ and but the intent is to reach that stage. In our case study this would mean answering questions like
– Do we need users to register with the website or can they just come, fill the form, pay and leave
– Will this service be in certain areas or all around the world ?
– How do we ensure that we do not promise delivery for an area which is not covered ?
– What happens if someone wants to cancel ?
– What about late reporting ?
– Would this work in all locales or just English ?
– Is there a plan to make it work for more locales later, so that necessary work at architecture level be put now ?
– What all browsers ?
– Is it a desktop accessible website or do we want to make it client agnostic and should work from mobile and other devices as well ?
– and so on
– and so forth
If you are the above text again, you would appreciate that making this website is much more than just saying that develop a taxi-booking site. An experienced ‘Requirements Gatherer’ would know these questions and would plan accordingly. For some of the these he would need help from Engineering, for some he would need support from Marketing, for others he might need a quick validation from User Research, so its not really a work of art entirely from one person or one function but instead a ‘collective work’ with inputs and support from various groups.
Without going too much deep in ‘Requirements Gathering’, we would go to next step which is ‘Engineering Design’. I wont take much time here and would explain it as a activity which is primarily done by software developers and involves deciding the architecture, components, databases, application servers, data-flow-diagrams and so on. A sort of blue-print of the code.
Close to this activity, another thing happens which is called ‘Test Engineering Planning’. While software coders are busy figuring out how to write code, software testers are planning on ‘how to test the code once its written’. This planning would involve the understanding of requirements as well as understanding the ‘Engineering Design’.
To Recap
Conceive the Idea -> Requirement Gathering -> Engineering Design
Conceive the Idea -> Requirement Gathering -> Test Engineering Planning
While this is being done, another important thing which happens is ‘UI Designing’. Essentially after you have a somewhat good enough ‘Requirements’ and some sort of high level ‘Engineering Design’, you know what is doable and what is not. After this point, UI folks comes into picture and start work on ‘User Interface’.
so as of now the situation is UI Design -> Code -> Test -> Code -> Test cycles -> some UI tweak based on bugs -> Code -> Test
and finally when we think that we are good enough, we reach the point where we need to worry about non-engineering things. So sometime around the end, you would start to engage Documentation guys (Help, Manual), Tech Support folks, Operations guy (to replicate CDs, post the electronic version at your website and so on).
Once everything is fine, you ship it. So that was about SDLC. I would try to write about some of the common models which people follow viz. Waterfall model, Spiral Model, Scrum etc.