Kerala Plus Two Computer Applications (DHSE) common mistakes
Kerala Plus Two Computer Applications (DHSE) · Understand the traps and how to avoid them.
When converting between decimal, binary, octal and hexadecimal, candidates convert the integer part correctly but drop or misplace the fractional part (for example writing 0.625 as .101 instead of .101, or padding the wrong side of the radix point), and produce answers with no base subscript.
Textbook drills emphasise whole-number conversions, so the multiply-by-2 method for fractions is under-practised; candidates also forget that binary fractions are read top-to-bottom from the multiplication remainders, and that grouping for octal/hex starts at the radix point and moves outward, not from the left edge of the string.
What to do instead
Build a fixed routine: convert the integer part by repeated division (remainders read bottom-up), then the fraction by repeated multiplication (integer parts read top-down), stop when the fraction reaches zero or the required precision, and always write the base as a subscript. For binary-to-octal/hex, pad with zeros on the left of the integer part and on the right of the fraction so each group has exactly 3 or 4 bits. Do five mixed conversions with fractions before the exam and check each by converting back.
Candidates classify software and memory incorrectly: they label firmware, utility programs and language translators as application software, or confuse RAM/ROM, primary/secondary storage, and volatile/non-volatile in one-word questions.
The system-versus-application split is taught with a few examples only, so anything not obviously a 'user program' gets guessed; memory terms are memorised as a list rather than by the property (volatility, access, purpose) that the question is actually testing.
What to do instead
Sort every named item by two questions: does it manage the machine (system software: OS, translators, utilities, firmware) or do a user's task (application software)? And does it lose contents on power-off (volatile: RAM, cache) or keep them (ROM, flash, disk)? Make a two-column table of ten examples you have seen in previous papers and place each one with a one-line justification.
In networking questions, candidates mix up the layers, devices and addressing: they place a switch or router at the wrong layer, call an IP address a physical address, or state that a hub filters traffic by MAC address.
Devices are memorised as a list without the function that determines the layer; MAC and IP are both called 'addresses', so the distinction between hardware addressing within a LAN and logical addressing across networks is blurred.
What to do instead
Learn each device by its forwarding decision: hub repeats to all ports (physical layer), switch forwards by MAC within a LAN (data link), router forwards by IP between networks (network). Attach one sentence to each: 'MAC is burned into the NIC and used inside a LAN; IP is assigned and used to route between networks.' Then answer ten 'which layer/which device' items and justify each aloud.
Candidates write HTML that renders but is structurally wrong: unclosed or improperly nested tags, attributes without quotes, lists or tables missing required child elements (tr without td, ul without li), and deprecated presentational tags such as <font> or <center> used where CSS is expected.
Browsers silently repair malformed markup, so practice in a browser never shows the error; candidates also copy old-style examples and never learn that the exam expects valid nesting and separation of structure from presentation.
What to do instead
Adopt a nesting rule (last opened, first closed) and type closing tags immediately after opening tags. Memorise the required children for the structures you will be asked to write: table > tr > td/th, ul/ol > li, select > option, and the head/body split with title inside head. Do all styling with an internal or external stylesheet using selectors, and validate by reading the code line by line as a parser would, not by looking at the page.
In spreadsheet questions, candidates write formulas without the leading =, use relative references where a copy must keep a fixed cell, or mis-handle text criteria in COUNTIF/SUMIF and the difference between COUNT and COUNTA.
The distinction between relative (A1), absolute ($A$1) and mixed references is taught abstractly; candidates also forget that criteria containing text or comparison operators must be quoted, and that COUNT counts numbers only while COUNTA counts non-empty cells.
What to do instead
Before writing any formula, ask: will this be copied, and which part must stay fixed? Then add $ to the row and/or column that must not move. Practise one fill-down exercise with each reference type and inspect what changed. For conditional functions, write the criterion exactly as the function needs it, e.g. COUNTIF(B2:B20,">=50") and SUMIF(A2:A20,"Science",C2:C20), and state in words what COUNT versus COUNTA would return for the same range.
Candidates answer SQL questions with the wrong clause order or the wrong clause for the job: they filter groups with WHERE instead of HAVING, put ORDER BY before GROUP BY, use = NULL instead of IS NULL, or select a non-aggregated column that is not in GROUP BY.
Queries are written by intuition rather than from the fixed evaluation order (FROM, WHERE, GROUP BY, HAVING, SELECT, ORDER BY), and NULL is treated as an ordinary value even though it is not equal to anything.
What to do instead
Write every query in the canonical order and annotate each line with its purpose. Memorise two rules: row-level filtering goes in WHERE, group-level filtering goes in HAVING; and NULL is tested only with IS NULL / IS NOT NULL. For aggregates, check that every selected column is either inside an aggregate function or listed in GROUP BY. Practise five queries that combine GROUP BY with HAVING and one that uses IS NULL.
Candidates confuse the algorithm and the program: they present pseudo-code or a flowchart as if it were C, mix English words into C statements, or write a loop whose condition and update do not guarantee termination (for example forgetting to increment the counter, or using = in a condition).
Flowchart and pseudo-code practice is done separately from coding, so the boundary between design and implementation is never made explicit; loop tracing is rarely done by hand, so off-by-one and infinite-loop errors go unnoticed.
What to do instead
Keep three distinct forms for the same problem: a flowchart, pseudo-code, and C. In C, every statement ends with a semicolon, conditions use == not =, and every loop has a visible initialisation, test and update. Before submitting, dry-run the loop for the first two and last two iterations in a trace table showing each variable's value; if the counter never reaches the exit condition, fix the update.
In C output and pointer questions, candidates predict the wrong result because they ignore the difference between pre- and post-increment, integer division and type conversion, operator precedence, and the effect of passing arguments by value versus by address.
These are side effects and representation rules rather than visible logic, so candidates read expressions left to right as arithmetic and assume a function can change a caller's variable just because it assigns to its parameter.
What to do instead
Learn the short list explicitly: x++ yields the old value then increments, ++x increments then yields; integer/integer truncates, so cast one operand for a real result; * and & bind tighter than arithmetic; and a function changes a caller's variable only through a pointer (or array). For any output question, rewrite the expression one operator at a time in a table of variable values, then state the printed result.
Candidates treat cyber ethics and security as general knowledge: they cannot distinguish virus, worm and Trojan, confuse phishing with pharming or spam, describe a firewall as antivirus software, or answer IT Act / IPR questions with vague statements rather than the specific concept asked.
These topics are revised by reading definitions once, without pairing each term with the mechanism that defines it (self-replication, disguise, deception, traffic filtering), and legal/ethical items are guessed because the exact scope of each term was never checked.
What to do instead
Build a comparison table with one row per threat and columns for how it spreads, whether it needs a host, whether it self-replicates, and its typical payload; do the same for phishing versus pharming (bait versus DNS/redirection) and firewall versus antivirus (traffic control versus file scanning). For ethics and law, learn the specific concept names and what each protects, and answer with the named term plus one sentence of justification rather than a general remark.
Candidates lose marks on structured and practical questions by not matching the answer to the command word: they give a one-line definition where 'explain with an example' is asked, omit the required number of points or steps, draw a table without headings, or leave out the final output/result of a program or query.
Under time pressure candidates answer the topic rather than the instruction, and they have not checked the mark allocation against the number of points expected, so multi-mark questions receive single-mark answers.
What to do instead
Before writing, underline the command word and the quantity in the question ('any four', 'with an example', 'step by step') and plan that many numbered points. For practical items, always finish with the expected output or result, label table columns, and give one concrete example wherever the question says 'example'. In the last ten minutes, re-read each answer against its command word and add the missing points rather than rewriting what is already correct.