The software development life cycle
The software development life cycle (SDLC) is the set of stages used to build a program:
- Analysis: understand the problem, talk to users, write requirements (what the program must do) and success criteria.
- Design: plan the solution: break it into parts (decomposition), draw flowcharts or pseudocode, plan the data and the screens.
- Implementation (coding): write the code, one part at a time.
- Testing: check it works and meets the requirements.
- Deployment: give it to users.
- Maintenance: fix bugs, add features, keep it working.
Waterfall and agile
Waterfall goes through the stages once, in order; good when requirements are fixed. Agile (iterative) builds a small working version, gets feedback, and repeats in short cycles called sprints; good when needs change.
Designing a program: purpose, users and structure
Start with the purpose: what problem does it solve, and for whom? Think about all users, including people with poor eyesight or slow internet (accessibility, big buttons, clear language).
Use procedural design: split the program into subroutines (functions/procedures) that each do one job, e.g. get_age(), check_age(), save_member(). Pass data through parameters and return values instead of using many global variables. Small parts are easier to write, test, reuse and share among a team.
Write comments, use meaningful names and consistent indentation so others can maintain the code.
Testing: test data and test cases
A test case lists the input, the expected output and the actual output. For a rule 'age 11 to 18':
- Normal data: typical valid values, e.g. 15 → accepted.
- Boundary data: at the edges, e.g. 11 and 18 → accepted; 10 and 19 → rejected.
- Erroneous (invalid) data: wrong type or impossible, e.g. −3, 'abc' → rejected with a message.
Iterative testing happens while you code; final testing checks the finished program against every requirement. Users can do acceptance testing.
Errors, debugging and robust programs
- Syntax error: breaks the language rules (missing bracket); the program will not run.
- Runtime error: crashes while running (divide by zero, file not found).
- Logic error: runs but gives the wrong answer, e.g.
age > 11instead ofage >= 11wrongly rejects 11.
Debugging: reproduce the bug, trace the code (print values or use a debugger with breakpoints), fix, and test again.
A robust program does not crash on bad input: it uses input validation (range, type, length, presence and format checks), exception handling, and for security checks passwords (authentication) and never trusts user input.
Teamwork, tools and the project
An IDE (integrated development environment) gives an editor, error highlighting, a debugger and a run button in one place.
Version control (e.g. Git) saves snapshots called commits. You can see who changed what, go back to an older version, and let many people work on branches and then merge.
Teams have roles: product owner or client, developers, testers, designer, project manager. A simple plan uses a task board (to do / doing / done), a timeline and regular short meetings.
A school software project usually needs: problem statement, requirements, design (flowcharts, screen sketches, data tables), code with comments, a test table with evidence, user feedback and an evaluation of what to improve.
Key formulas and definitions
- SDLC: Analyse → Design → Code → Test → Deploy → Maintain (→ repeat)
- Test case = input + expected output + actual output + pass/fail
- Test data types: normal, boundary, erroneous
- Error types: syntax, runtime, logic
- Validation checks: range, type, length, presence, format
Worked examples
1. Write test data for a field that accepts marks from 0 to 100.
Normal: 45, 78. Boundary: 0, 100 (accept) and −1, 101 (reject). Erroneous: 'fifty', blank, 12.5 if only whole numbers are allowed.
2. The code is: if age > 11 and age <= 18: accept. The input 11 is rejected. What kind of error is it and how do you fix it?
A logic error: the program runs but gives the wrong result. Change > to >= so 11 is included.
3. A library app will change often as students ask for features. Waterfall or agile?
Agile: short cycles let the team release a small version, collect feedback and adapt.
4. Decompose 'an online quiz app' into subroutines.
show_question(), get_answer(), check_answer(), update_score(), show_result(), save_high_score().
5. Why commit to version control after each working change?
If a later change breaks the program you can go back to the last working commit, and teammates can see and merge your change.
6. A program crashes when the user types letters instead of a number. Make it robust.
Validate input: check the text is a whole number before converting (or catch the exception), then show 'Please enter a number' and ask again instead of crashing.
Common mistakes
- Starting to code before writing requirements, then building the wrong thing.
- Testing only normal data and forgetting boundary and wrong data.
- Confusing a logic error (wrong answer) with a syntax error (won't run).
- Thinking the job ends at release; maintenance usually takes the most time.