Software Development Lifecycle & Modern Processes

What Is the SDLC?

The Software Development Lifecycle (SDLC) is a framework that describes the stages software goes through from initial idea to retirement. Every piece of software, whether it’s a 50-line script or a distributed platform, passes through these stages — the question is whether you manage them deliberately or let them happen chaotically.

The six core phases are:

1. Requirements & Planning. What are we building? Why? For whom? What constraints exist? This is where you define the problem before jumping to solutions.
2. Design. How will the system be structured? What components exist? How do they communicate? This is the architecture phase — the blueprints.
3. Implementation. Writing the code. In 2026, this increasingly means directing AI to write code while you review and refine.
4. Testing. Does the system do what it’s supposed to? Does it handle edge cases? Does it perform under load? Testing is not an afterthought — it’s an engineering discipline.
5. Deployment. Getting the software to users. This ranges from copying a script to a server to orchestrating a zero-downtime rollout across global infrastructure.
6. Maintenance & Evolution. The longest phase. Software that’s in use needs bug fixes, feature additions, performance improvements, and security patches. Most software spends 80% of its life here.

Waterfall: The Sequential Model

Waterfall is the oldest formal SDLC methodology. It treats software development as a linear sequence: finish one phase completely before starting the next. It looks like this:

Requirements
    |
    v
  Design
    |
    v
Implementation
    |
    v
  Testing
    |
    v
 Deployment
    |
    v
Maintenance

When Waterfall Works

• Requirements are fixed and well-understood. Embedded systems for a satellite, regulatory compliance software, safety-critical medical devices.
• The cost of change is extremely high. If deploying a fix means recalling hardware or shutting down a power plant, you want to get it right the first time.
• External constraints demand sequential sign-off. Government contracts, construction projects, and regulated industries often require phase-gate approvals.

When Waterfall Fails

• Requirements are uncertain or evolving. If users don’t know what they want until they see a prototype, Waterfall guarantees you’ll build the wrong thing.
• Feedback comes too late. You discover problems in testing that should have been caught in design, but going back means restarting.
• It assumes perfect knowledge upfront. In practice, you learn the most about a problem while building the solution.

For engineers coming from construction or manufacturing, Waterfall feels natural — it mirrors the design-bid-build process. But software is fundamentally more malleable than concrete. The cost of changing software is (usually) much lower than the cost of changing a building, which means the rigidity of Waterfall is often unnecessary overhead.

Agile: Iterative and Incremental

Agile emerged in the early 2000s as a reaction to Waterfall’s rigidity. Instead of completing all requirements before all design before all implementation, Agile cycles through all phases in short iterations:

Iteration 1:  [Requirements -> Design -> Build -> Test -> Deploy]
                                                        |
Iteration 2:  [Requirements -> Design -> Build -> Test -> Deploy]
                                                        |
Iteration 3:  [Requirements -> Design -> Build -> Test -> Deploy]
                                                        |
                                                       ...

Core Values (from the Agile Manifesto)

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Note: the Manifesto says “over,” not “instead of.” The items on the right still have value; the items on the left have more value.

Scrum

Scrum is the most common Agile framework. Its key elements:

• Sprints: Fixed-length iterations, typically 1–4 weeks.
• Product Backlog: A prioritized list of everything the product needs.
• Sprint Planning: The team selects items from the backlog for the upcoming sprint.
• Daily Standup: A 15-minute daily meeting. What did you do? What will you do? What’s blocking you?
• Sprint Review: Demo working software to stakeholders at the end of each sprint.
• Sprint Retrospective: The team reflects on the process and identifies improvements.

Kanban

Kanban is a lighter-weight Agile approach focused on flow rather than fixed iterations:

• Visualize the workflow: A board with columns (To Do, In Progress, Review, Done).
• Limit work in progress (WIP): Restrict how many items can be in any column at once. This prevents bottlenecks and forces completion.
• Manage flow: Optimize for throughput and cycle time, not sprint velocity.

Kanban is often a better fit for maintenance work, support teams, or situations where priorities change daily.

DevOps: Closing the Gap

Traditional organizations separated development teams (who write code) from operations teams (who deploy and maintain it). This created a wall: developers threw code over the wall, operations caught it (or didn’t), and both blamed each other when things broke.

DevOps is a culture and set of practices that tears down this wall. The core idea: the team that builds the software is also responsible for running it.

  Plan -> Code -> Build -> Test -> Release -> Deploy -> Operate -> Monitor
    ^                                                                  |
    |__________________________________________________________________|
                          Continuous Feedback

CI/CD: The DevOps Engine

Continuous Integration (CI) means every developer merges their changes into a shared branch frequently (at least daily), and every merge triggers automated builds and tests. If the build breaks, it gets fixed immediately.

Continuous Delivery (CD) extends CI: every change that passes the automated pipeline is ready to deploy to production. Continuous Deployment goes one step further — every passing change is automatically deployed.

Lean: Eliminate Waste

Lean thinking, borrowed from Toyota’s manufacturing system, focuses on eliminating waste from the development process. The seven wastes in software development:

1. Partially done work. Features that are started but not shipped. They cost effort but deliver zero value.
2. Extra features. Building things nobody asked for or needs. The most expensive waste.
3. Relearning. Losing knowledge because it wasn’t documented or the team turned over.
4. Handoffs. Every time work passes between people, information is lost.
5. Task switching. Context-switching between projects destroys productivity.
6. Delays. Waiting for approvals, environments, dependencies, or decisions.
7. Defects. Bugs that escape to production. The later you find them, the more expensive they are.

Lean thinking is not a methodology you “adopt” — it’s a lens you apply to any methodology. You can practice Lean within Scrum, Kanban, or even Waterfall.

How AI Changes the SDLC

AI is reshaping the SDLC in specific, measurable ways:

SDLC Phase	AI Impact	What Remains Human
Requirements	AI can help analyze user feedback at scale and generate user stories	Understanding stakeholder needs, resolving conflicts, prioritizing
Design	AI can suggest patterns and generate architecture diagrams from descriptions	Evaluating trade-offs, choosing the right pattern for the context
Implementation	AI generates code from specs, autocompletes functions, writes boilerplate	Reviewing generated code, ensuring correctness, handling edge cases
Testing	AI generates test cases, identifies untested paths, creates mock data	Defining what “correct” means, designing test strategies
Deployment	AI optimizes deployment configurations, predicts failure risks	Go/no-go decisions, rollback strategies, incident response
Maintenance	AI identifies code smells, suggests refactoring, triages bugs	Architectural evolution, technical debt prioritization

Exercise 2.1: SDLC Mapping

Quiz

Question: Your team is building a new plugin for a commercial FEM (Finite Element Method) package. The plugin needs to read proprietary model files, run a custom post-processing algorithm, and display results in the FEM package’s UI. Requirements are well-defined by the FEM vendor’s API documentation, but the post-processing algorithm is still being researched. Which methodology approach makes the most sense?

1. Pure Waterfall — requirements are well-defined, so follow the sequential model.
2. Pure Agile — iterate on everything in 2-week sprints.
3. Hybrid — use Waterfall for the well-defined file I/O and UI integration, and Agile iterations for the research-driven algorithm component.
4. Skip the methodology and just start coding — the team is small enough.

Answer

c) Hybrid — use Waterfall for the well-defined file I/O and UI integration, and Agile iterations for the research-driven algorithm component.

This is a common real-world pattern. The file I/O and UI integration have stable requirements (the FEM vendor’s API won’t change mid-project), so a sequential approach is efficient. But the post-processing algorithm is still being researched, which means requirements will evolve — that demands iteration. A hybrid approach matches the methodology to the uncertainty level of each component. Option (d) is tempting for small teams but leads to exactly the problems the SDLC is designed to prevent: missed requirements, no testing strategy, and painful deployment.