Systems Life Cycle Planner

When an organisation replaces an old system (paper or computer) with a new one, the work follows the systems life cycle. Choose a scenario in the title bar, then work through the stages in order. Every decision is checked as you make it, with the reason; your first answer counts towards the score, and Review my plan lists your mistakes with the right answers.

• Analysis. The analyst researches the current system with four methods: observation (seeing what really happens), interviews (detail and follow-up questions, but slow for many people), questionnaires (many people, quickly and anonymously, but no follow-up) and examining documents (the data actually input, stored and output). The right method depends on what you need to find out and how many people there are. Analysis also identifies the inputs, processing and outputs, the problems with the current system, and the user and information requirements.
• Design. The file structures (field names, data types, field lengths), the input forms, the output formats (screens and reports), and the validation routines: range, length, type, character, format, presence, lookup and consistency checks, and check digits. A code with a leading zero (a phone number, a postcode) is stored as text, not as a number.
• Development and testing. A test plan gives each test's data, its type, the expected outcome and the actual outcome. Normal data is valid and should be accepted; abnormal data should be rejected (out of range, wrong type, missing); extreme data is valid data at the very limits, and should be accepted. Run the tests: each scenario's program has a fault that only one kind of test data finds.
• Implementation. Direct changeover (quick and cheap, but nothing to fall back on), parallel running (safest, but every job is done twice), pilot running (one branch first) and phased implementation (one part at a time). The simulation shows each method's timeline, its extra staff cost and, if the new system fails in a chosen week, how much of the organisation is left without a working system.
• Documentation. Technical documentation is for whoever maintains the system (program listing, flowcharts, file structures, variables, validation routines); user documentation is for the people who use it (how to run it, save, print, add and edit records, error messages, troubleshooting, glossary). Some items, such as the purpose, limitations, hardware and software requirements, input and output formats and sample runs, belong in both.
• Evaluation. Compare the solution with the original requirements, using test results and the users' responses; identify the limitations and the improvements needed.

Common exam mistakes: giving a method's advantage that doesn't fit the scenario (interviews "reach many people"); calling data just outside the range "extreme" (it's abnormal: extreme data is valid, at the limits); writing "it is cheaper" without saying why (no work is done twice); saying parallel running is "faster" (it's the slowest and dearest, but the safest); mixing up pilot (one whole branch tries everything) with phased (one part at a time, everywhere); putting the program code in the user guide.

A Level (9626) depth: the test strategy (black-box and white-box testing; unit, integration and system testing; alpha, beta and user acceptance testing), feasibility studies, and maintenance after evaluation (corrective, adaptive and perfective).

Objective: Cambridge IGCSE ICT (0417) section 7, the systems life cycle (analysis, design, development and testing, implementation, documentation, evaluation); Cambridge International A Level IT (9626), the systems life cycle (an A Level topic in the 2025–27 syllabus).