SPM Sains Komputer common mistakes
SPM Sains Komputer · Understand the traps and how to avoid them.
When asked to convert between number systems (binary, octal, decimal, hexadecimal), the candidate converts only the integer part and ignores the fractional part, or pads binary groups from the left instead of grouping from the radix point when converting to octal/hexadecimal.
Textbook examples in SPM revision materials almost always use whole numbers, so candidates rehearse a partial procedure and never see the rule that fractional digits must be grouped outward from the decimal point and padded on the right.
What to do instead
Before every conversion, split the value at the radix point and handle the two parts separately. For binary-to-octal/hex, group from the radix point outward and pad the outer group with zeros on the correct side. Practise three fractional conversions per sitting and verify by converting back to the original base.
The candidate describes CPU fetch-decode-execute or the roles of RAM, ROM and cache by listing component names only, without stating what each component does with data or the order of operations.
Candidates memorise noun lists from notes and assume naming the parts earns the mark, when the marking scheme rewards process descriptions and sequence.
What to do instead
Write each answer as a short chain: what is fetched, from where, into which register, what the control unit does, and where the result goes. Practise rewriting any component list as a numbered sequence of events, then check that every named part appears with an action attached.
For network questions, the candidate mixes up the OSI/TCP-IP layer at which a device or protocol operates (for example placing a switch at the network layer, a router at the data link layer, or IP at the transport layer) and cannot map a scenario to the correct layer.
Device and protocol lists are memorised as flat vocabulary rather than as a layered stack, so candidates have no anchor for deciding where a device belongs when the question describes an unfamiliar scenario.
What to do instead
Build a one-page table with columns for layer number, layer name, protocol examples, device examples and a one-line function. For each practice scenario, first ask what unit of data is being handled (frame, packet, segment) and let that determine the layer before naming the device.
When asked to design or trace an algorithm, the candidate writes only the final output or a vague description of the steps, omitting initialisation, the loop condition and the update inside the loop, so the trace cannot be followed.
Candidates treat pseudocode as prose and underestimate how strictly the marking scheme checks for initialisation, condition and update; they also skip dry-running their own solution.
What to do instead
Adopt a fixed skeleton for every algorithm answer: declare and initialise variables, state the loop condition, state the update, then state the output. After writing, trace the algorithm by hand with a small sample input, recording variable values line by line in a table, and fix any step where a variable is used before it is set.
The candidate confuses = with == in conditions, or writes a loop whose condition can never become false, and does not notice because the logic looks correct at a glance.
Assignment and comparison use similar symbols and candidates read code for meaning rather than checking syntax character by character; infinite loops are rarely tested in class exercises with small inputs.
What to do instead
Keep a personal checklist of syntax traps to scan for after writing any control structure: assignment versus comparison, loop variable updated inside the loop, condition direction, and off-by-one bounds. Deliberately trace a loop for the first three and the last iteration to confirm it terminates.
In database questions, the candidate draws an entity relationship diagram without identifying the primary key and foreign key, or writes a query that selects columns without a WHERE clause when the question asks for a filtered subset, and cannot explain why a relation is in a given normal form.
Candidates learn SQL syntax and ER symbols separately from the design reasoning, so they produce diagrams and queries that are syntactically plausible but semantically wrong for the stated requirement.
What to do instead
For every design question, underline the nouns (entities) and verbs (relationships) in the scenario first, then assign a primary key to each entity and place foreign keys on the many side. For queries, rewrite the requirement as 'show which columns, from which table, matching which condition' before typing SQL. For normalisation, test each relation against one concrete anomaly example rather than reciting definitions.
When asked about interface design or the software development life cycle, the candidate lists generic principles (easy to use, attractive, user friendly) without tying them to the stated user, task or device, and skips stages such as requirements analysis or testing when describing a development model.
These topics are taught as slogan lists, and candidates do not realise that the marks come from applying the principle to the given scenario and from naming stages in order with their outputs.
What to do instead
Answer in the form principle, application, effect: name the design principle, say exactly where it appears in the described screen, and state the effect on the named user. For life cycle questions, produce a numbered stage list with the deliverable of each stage, then check that testing and maintenance both appear.
On security questions, the candidate names a threat or control without distinguishing prevention from detection, or recommends a control that does not address the stated vulnerability (for example suggesting a firewall against a phishing email, or antivirus against weak passwords).
Threat and control lists are memorised as paired vocabulary, and candidates match on keyword overlap rather than reasoning about the attack path.
What to do instead
For each scenario, state the attack path in one sentence (who does what to which asset), then choose the control that breaks that specific step, and label it as preventive, detective or corrective. Build a two-column table of threats against controls that actually interrupt them, and practise rejecting one plausible but mismatched control per scenario.
In social impact and ethics questions, the candidate gives a one-sided answer that lists only benefits or only harms, and uses vague terms such as 'more efficient' or 'bad for society' without a named example, stakeholder or consequence.
Candidates write the first idea that comes to mind and stop, because they do not realise that balanced evaluation with concrete examples is what earns the higher marks.
What to do instead
Structure every impact answer as: benefit to a named stakeholder, harm to a named stakeholder, and a judgement with a reason. Replace every vague adjective with a concrete instance (which job, which group of users, which law or policy) before finishing the sentence.
For project and coursework work, the candidate documents only the finished product, omitting problem statement, requirements, design evidence, testing records and evaluation, and cannot explain design decisions when questioned.
Candidates equate coursework with building something that works, and leave documentation until the end, so the evidence of process is reconstructed from memory and is thin or inconsistent with the artefact.
What to do instead
Keep a dated project log from the first week recording decisions, alternatives considered and test results. Before submission, check the artefact against a checklist of required sections (problem, requirements, design, implementation, testing with input and expected versus actual output, evaluation, further work) and confirm every claim in the report can be pointed to in the artefact.