This module covers the software side of a computer system: what the operating system does, how programs written by people become something the processor can run, how a processor reacts to events, what utility programs are for, and why some computers are built into machines. It sits in the software and systems area of Cambridge IGCSE Computer Science 0478. Check the current syllabus on the Cambridge page for the exact wording of each learning objective in your exam year.
Most questions here ask you to name, explain or compare. Marks go to precise statements that match a given situation, not to long general essays.
What should you know before you start?
You should be comfortable with the idea of a processor, main memory and storage from hardware and processing. You also need to know that a program is a list of instructions, and that the processor can only run instructions in machine code.
No programming skill is needed for this module. Reading a short piece of pseudocode helps in two lessons, and you can run the matching code in the safe Python reasoning sandbox if you want to see it happen.
One orienting example: saving a file while music plays
A student types an essay in a word processor, listens to music, and presses save. Four different kinds of software and system ideas are already involved.
The word processor and the music player are application software: each does a job the user wants. The operating system shares the processor and memory between them (multitasking), shows the windows (user interface), and writes the file to the disk (file management). If the student plugs in a USB drive, the hardware signals the processor with an interrupt, and the OS loads the right driver.
A utility such as a backup tool may later copy the essay to another drive. The code of every program was translated into machine code by a compiler or interpreter before it could run.
In what order should you study the lessons?
- Distinguish operating system and application roles: the base idea, and it gives you a sorting habit for every later term.
- Compare interpreter and compiler behaviour: how program code becomes runnable, and why error messages differ.
- Explain an interrupt using a scenario: how the processor responds to events without losing its place.
- Identify a utility function: the maintenance tools that are not part of the core OS and not ordinary applications.
- Discuss an embedded system with its constraints: a design discussion that pulls the earlier ideas together.
Then try the software and systems practice set. The restricted pseudocode trace trainer is useful for the two lessons that include a trace.
Which traps cost the most marks?
- Vague function names. “The OS manages the computer” earns nothing. “The OS allocates memory to each running program” earns a mark.
- Reversed translators. A compiler translates the whole program before it runs. An interpreter translates and runs one statement at a time.
- Interrupt as a pause button. An interrupt does not stop the program for good. The processor finishes the current instruction, saves its state, runs a routine, then resumes.
- Utility versus application. A utility maintains or protects the system. An application serves the user’s own task.
- Listing, not discussing. For embedded systems, state the constraint and tie it to the device in the question.
How should you use the practice set?
Work through the lessons first, then attempt the practice set on paper without notes. Write full sentences, because that is how the exam rewards you. Afterwards, log each wrong answer with its cause in the mistake log and retest queue, so the same slip does not return a week later.
If you want a teacher to look at how you phrase these answers, our online one-to-one Computer Science tuition works from your own written responses. The wider route is in the Computer Science learning guide.