Goal: Have high-level idea what SDLC is and consists of.
Let’s assume that SDLC has five acts, stages, phases, steps (will be using those interchangeably). Five is more than enough to start with and not feel lost. Most of the SDLC definitions are kind of arbitrary, sugar-coated and mechanical like ‘SDLC is…. the cost-effective and time-efficient process that development teams use to design and build high-quality software.’ Yeah. Sure. SDLC abstracts the different acts for creating software. If this does not resonate, imagine it as a daily routine. Wake up, be cranky, pee-crap, wash, brush teeth, eat, do stuff, eat, pee-crap, brush teeth, go to sleep. Why does SDLC exists? Because it is useful. It is nice to know what to do, to have a generic, high level and actionable plan.
Identify
Figure out what is that you want to achieve. What is the primary goal? What is the big problem you want to solve, what need do you wish to serve? Why it is a problem, why there’s a need? This stage applies regardless of business, industry, domain. In our case what we want is a service, website > ‘We want to build a website where people can share images, comment, connect and have fun‘.
Define
After you have a good idea about the goal, then it is time to define how to solve it. That means solutions to a set of smaller problems. We can call them features, requirements, functionality. During this phase one should define the MVP (and/or TVP ;)). This phase is for getting into the details. How much details? Unknown. Depends on the context. Using our goal – the image sharing website, let’s assume we have defined the following requirements:
- Have front (landing) page
- Have user registration page
- Have user profile space, from where users can manage their images
Plan
This is the phase where one needs to do a deep, collaborative dive. How much is the work? Can it be done in time, how exactly would it be done, who would do what, what issues there could be, how it would fit into the overall architecture (if there is any), what would this mean in future, how it would affect current functionality (if any). What are the more precise, detailed requirements? How would things look, how usable? How to check they work, how to make sure they are secure? Lots of things to do here.
Execute
This is the phase where work gets done. The less questions and ambiguous answers in the previous phases, the more here. This phase includes several processes and practices that need to be followed in order to get adequate results, meet the requirements and ensure somewhat of a quality. It is also the stage in which most software projects fail. Cutting corners in the previous two is one of the reasons.
Release
That’s the happy phase. Where whatever was built is released to the world. It also could be the crying phase where the expected outcome was different, much different, than the actual one.
Those are the five main acts. In the next posts we’ll take sneak peak into what they imply, require, mean.