Software Development Lifecycle (SDLC)

The stages

A requirement typically travels through these stages, shown here with the question each one answers:

Stage	Question
Plan and analyse	What problem are we solving, and for whom?
Design	How will we solve it, and what does it touch?
Implement	Write the code, in small reviewed changes.
Test	Does it work, and did we break anything else?
Deploy	Get it into production safely.
Operate and maintain	Is it healthy, and what do we learn from real use?

The stages are activities that need no separate departments. In a small team one person may do all of them in one afternoon.

Who is involved and where work goes back

Stage	Typically involved	Can be sent back when
Plan and analyse	Product owner, business analyst, users	Requirements are unclear or rejected at acceptance
Design	Developers, architect	Review finds the design does not fit
Implement	Developers, reviewers	A pull request review requests changes
Test	Testers or QA, developers	Tests fail or a bug is found; the change returns to implement
Deploy	Developers, operations	The release fails or is rolled back after release
Operate and maintain	Operations, support, product owner	Monitoring or user feedback shows a problem, which becomes new work

Work rarely moves in one direction. A failed review, failed tests, a rejected acceptance or a rollback sends it back to an earlier stage.

Models

• Waterfall finishes each stage before starting the next. It suits work where requirements are fixed and change is expensive, but feedback arrives late.
• Iterative and agile approaches repeat the whole cycle in short rounds, so that real feedback shapes the next round. See Agile, Scrum and Kanban.
• Most real teams mix both: some up-front design, then incremental delivery.

Where you fit in

For a typical task, the path in a modern team looks like this:

1. A requirement becomes a ticket or user story.
2. You make a branch, implement the change and write tests.
3. You open a pull request and a colleague reviews it.
4. A CI/CD pipeline builds and tests the change, then deploys it through the environments.
5. Monitoring and user feedback show whether it worked, and the next task follows from what they show.

Try it

Pick a small change that was recently released in your team. Trace it backwards: find the pull request, the ticket it came from, and the pipeline run that deployed it. Write down which SDLC stage each artefact belongs to and which stage you could not find any trace of.