Software Development Life Cycle

Learning Objectives

• Describe the SDLC and its phases.
• Compare the waterfall and agile models.
• Explain the types of testing, documentation and maintenance.
• Apply the SDLC to a small project.

What Is the SDLC and Its Phases

The Software Development Life Cycle (SDLC) is the step-by-step process used to plan, build, test, release and care for a software system. It turns an idea into a reliable product by managing quality and risk at every stage. Building software without a process leads to missing features, hidden bugs and expensive rework, which is why two teams start the same project and only the one that gathers requirements, designs, builds, tests, deploys and maintains succeeds. The phases also connect directly to the computational thinking of Week 1, decomposing the problem, focusing on what matters and applying clear steps.

The SDLC has six main phases. Requirements identifies the problem, the users and what the system must do, and produces a requirements document like the one drafted in Week 1. Design plans the architecture, the screens, the data model and the technology, and produces a design plan or diagram. Implementation writes the code that builds the system, transforming the design into working software. Testing checks for errors and confirms that the solution meets its requirements. Deployment releases the finished system where users can reach it, such as a web server or an app store. Maintenance fixes bugs, adds features and updates security after release, keeping the system useful over time. These six phases appear in almost every software project, in different orders and styles depending on the method chosen.

Waterfall versus Agile (Scrum)

The Waterfall model is the classic linear approach to the SDLC. Each phase is completed fully before the next begins, and work flows downward like water over a series of falls, requirements, design, implementation, testing and deployment. Waterfall works well when requirements are clear and unlikely to change, such as a fixed school record system, but its weakness is that changes are costly once earlier phases are finished. Agile builds software in small, repeated cycles, delivering a little working software again and again and gathering feedback after each cycle, which suits projects whose requirements change or are not fully known at the start.

Scrum is the most common Agile framework. It works in short fixed periods called sprints, usually one to four weeks. The product backlog is the ordered list of features and tasks still to be done. Sprint planning chooses the tasks for the next sprint from the backlog. A stand-up is a short daily meeting where the team reports progress and blockers. A sprint review shows the finished work and gathers feedback at the end of the sprint, and a retrospective is a meeting to discuss what went well and what to improve. Because a sprint produces working software, users can try it and give feedback early, so the final product matches what they really need.

Neither model is always best. A school library system with fixed, stable needs may suit Waterfall, while a new mobile app whose users keep suggesting features suits Scrum. Many real teams combine both, planning the overall structure with a Waterfall mindset while developing features in Agile sprints. The choice depends on how clear the requirements are, how likely they are to change and how important early feedback is, and engineers use computational thinking, analysing the project before choosing the method.

Applying the SDLC and Testing

Testing guards the quality of a system, because without it errors reach users, damage trust and create security holes. Testing happens at many levels. Unit testing checks a single function in isolation. Integration testing checks that different parts of the system work together. System testing checks the whole system against the requirements. User acceptance testing checks that real users can complete their tasks easily. Testing is not an afterthought; it runs through the whole life cycle, and bugs are far cheaper to fix early than after deployment.

The requirements document records what the system must do and who it serves, while the design document adds how it will be built, the screens, the database tables and the technologies, and together they guide implementation and testing. Applying the SDLC to a school result portal, requirements state that students must see their results, teachers must enter scores and only logged-in users may view data; design produces a web page with a login, tables of students and scores, and an HTML/CSS layout; implementation builds the pages and the server code that reads the database; testing checks logins and verifies that each student sees only their own result; deployment hosts the portal on a web server over HTTPS; and maintenance updates the portal, backs up data and fixes reported errors. This plan turns a rough idea into a secure, working system.

The SDLC matters because it manages complexity, reduces risk and protects quality, ensuring users get what they need, requirements are not forgotten, code is tested before users rely on it, and systems stay secure and up to date after release. Security must be designed through every phase, planned in requirements and design, tested for explicitly, and maintained after deployment with HTTPS, access controls and timely updates. Practical work for the week is to choose a small system such as a tuck-shop stock tracker, write one line for each SDLC phase, name the users and at least three requirements, describe the screens and the data stored, list the languages and tools, state two tests, describe deployment and two maintenance tasks, and choose between Waterfall and Scrum with a justification.

The SDLC Phases in Order

The Software Development Life Cycle breaks the building of software into ordered phases so that a team knows what to do next and what to produce at each stage. The full set of phases runs from planning through analysis, design, implementation, testing, deployment and finally maintenance. Working through these phases in order reduces guesswork, catches problems early and produces software that meets the needs of its users.

Planning defines the goals, budget, timeline and scope of the project. Analysis studies the problem in depth, talks to the intended users and writes down exactly what the software must do. Design decides how the software will be built, describing the architecture, screens, data structures and interfaces. Implementation is where programmers write the actual code based on those designs.

After implementation comes testing, where the finished software is run with real and artificial data to find errors before users see them. Deployment releases the approved software to its users, whether on school computers, in an app store or as a web service. Maintenance keeps the software working over time through bug fixes, updates and new features. For a school result portal, this order means understanding what parents and teachers need before a single line of code is written.

Other SDLC Models

Waterfall and Agile are not the only ways to run the SDLC. The Spiral model combines elements of both. Each loop of the spiral moves through planning, risk analysis, engineering and evaluation, and the project moves outward through the spiral as it grows. The spiral model is known for its strong focus on risk, making it a good choice for large, complex and safety-critical systems where a serious mistake would be costly.

Waterfall suits projects with clear, fixed requirements such as a payroll system whose rules are already set by law. Agile suits projects where requirements are uncertain or likely to change, such as a new mobile app being shaped by user feedback. The Spiral model suits large, high-risk systems such as banking platforms or hospital record systems. Many real-world teams blend approaches, keeping the control of a structured life cycle while developing feature by feature.

Types of Testing, Documentation and Maintenance

Unit testing checks a single function in isolation to verify it produces the correct result for a given input. Integration testing checks that different components work together correctly, such as confirming that a results screen can read data from the database. System testing runs the whole software against the requirements to confirm it behaves as specified. Acceptance testing is the final check where the intended users confirm that the software meets their needs.

Documentation keeps a project manageable. The requirements document captures what the software must do, the design document explains how it will be built, and user documentation tells people how to use the finished product. Maintenance is the longest phase because software is changed for years after release. Corrective maintenance fixes bugs, adaptive maintenance keeps software working as the environment changes, and perfective maintenance adds features or improves performance.

Practical Work

1. List the phases of the SDLC in order and state one output of each.
2. Use a table to compare waterfall and agile.
3. Explain the purpose of user acceptance testing.
4. Explain why maintenance continues after release.

Scenario-Based Questions

1. A state government commissions a new student records system with clear, fixed requirements: admission, grading, transcripts and graduation tracking. The requirements will not change. Recommend Waterfall or Agile (Scrum) and justify your choice by referencing at least two features of each model.
2. A startup is building a new social media app. Users keep requesting new features after every demo. Recommend Waterfall or Agile (Scrum) and explain why your chosen model handles changing requirements better.
3. A school commissions a website project. The development team uses Scrum with two-week sprints. Describe what happens in one sprint: the sprint planning meeting, the daily work, the sprint review and the sprint retrospective.
4. A programmer builds a function calculateFee(amount, rate) that computes interest. Explain why unit testing this single function is the first testing step, then describe integration testing and system testing for the complete fee management application.
5. A team follows the SDLC to build a library management system. For each phase (requirements, design, implementation, testing, deployment, maintenance), state one specific activity or output that applies to this project.
6. After deploying a school portal, the IT team discovers that the login page allows unlimited password attempts. Under which SDLC phase should this have been caught, what kind of testing would have revealed it, and how should the team fix it?
7. A project manager must choose between finishing the entire SDLC before releasing any part of the system or delivering working features after every sprint. Compare the risks of each approach for a hospital patient management system where reliability is critical and explain the consequences of choosing wrong.

Lesson objectives

By the close of the week, candidates should be able to:

1. List the six SDLC phases.
2. Name two deliverables per phase.
3. Compare waterfall and agile.
4. Write a test case.
5. Justify a model for a school system.

Key vocabulary

• SDLC: the staged process for building software.
• Requirement: a statement of what the system must do.
• Feasibility study: an assessment of technical and economic viability.
• Test case: a documented input, expected and actual result.
• Maintenance: correcting software after release.

Common misconceptions

• "Testing happens only after coding." Tests are written from requirements and run throughout.
• "Maintenance means repairing hardware." Software maintenance covers fixes and updates.

Teacher activities

1. Starter: list three causes of failure.
2. Teach the six phases.
3. Compare waterfall and agile.
4. Model three login test cases.
5. Set the result-system scenario.
6. Review two justifications.

Student activities

1. List three failure causes.
2. Order the phase cards.
3. Match deliverables to phases.
4. Write three login test cases.
5. Choose a model.
6. Defend the choice.

Practical / learning evidence

ss3_test_plan_nwosu.docx lists six phases with two deliverables, a model comparison, three login test cases and a justified choice. Each case needs input, expected and actual results.

Resources and preparation

Phase cards, projector and a test-case template. Offline route: cards and paper test logs with the same rubric.

Assessment for learning

Check phase order and deliverable fit. Award marks for a complete test case.

Inclusion and homework

Supply phase cards with two starters; extend others to the cost of a late defect. Homework: add a wrong-password test case.