CPN CPE Software Engineering common mistakes
CPN CPE Software Engineering · Understand the traps and how to avoid them.
When asked to distinguish verification from validation, the candidate labels any test activity as validation, or treats 'verification' as equivalent to 'testing' rather than to 'building the product right against the specification'.
The pair is memorised as a slogan without being anchored to artifacts. Candidates forget that verification compares work products to their specifications (reviews, inspections, static analysis, unit tests against design) while validation compares the delivered product to user needs (acceptance testing, operational use). Because most exam scenarios describe testing, the candidate defaults to 'validation' whenever the word test appears.
What to do instead
Build a two-column mental table before answering: left column = 'against specification' (requirements review, design review, code inspection, unit test, integration test), right column = 'against user need' (acceptance test, beta/operational use, prototype evaluation). For each scenario, first ask 'what artifact is the reference: the spec or the stakeholder need?' and answer only then. Practise by re-labelling every test technique you know as verification-oriented or validation-oriented and justify the label in one sentence.
The candidate treats iterative, incremental, and agile as synonyms and selects a lifecycle model on the basis of the label rather than on the risk profile, requirement stability, and delivery cadence described in the scenario.
Textbooks present these models side by side, so the candidate memorises definitions in isolation and never learns the discriminating criteria. Under time pressure the word 'agile' in a scenario becomes a magnet, even when the scenario describes high regulatory documentation needs or a fixed-price contract with stable requirements where a V-model or staged waterfall is defensible.
What to do instead
Memorise a decision table keyed on four scenario signals: requirement volatility, need for early feedback, contractual/regulatory documentation burden, and team/architecture risk. For each model (waterfall, V-model, incremental, iterative/RUP-style, spiral, agile/Scrum, continuous delivery) write one line stating which signal combination favours it. When practising, underline the signals in the stem before looking at the options, and eliminate any option that contradicts a stated constraint.
On maintenance questions, the candidate classifies a change by what was edited rather than by its intent, so an adaptive change is called corrective because the code fix looked like a bug fix, or a perfective change is called corrective because a user reported it.
The four ISO-style maintenance categories (corrective, adaptive, perfective, preventive) are defined by purpose, not by file or by who requested the change. Candidates learn the definitions as vocabulary and then apply them to surface features of the change request instead of the underlying driver: correcting a defect, adapting to an environment change, improving performance or maintainability, or forestalling future failure.
What to do instead
For every maintenance scenario, write the driver in a single sentence beginning 'The system must change because...'. If the reason is a fault producing wrong behaviour, it is corrective; if an external environment (OS, law, hardware, third-party API) changed, it is adaptive; if the user wants new or better capability, it is perfective; if the change reduces future risk without immediate benefit, it is preventive. Also practise spotting compound requests and naming the dominant category.
The candidate answers coupling and cohesion questions by counting relationships between modules instead of judging the type of relationship, and therefore rates a module with many data-parameter calls as more tightly coupled than one sharing global state.
Coupling and cohesion are taught as scales with named levels, but candidates reduce them to 'fewer connections = better' heuristics. They then mis-rank data coupling versus common (global) coupling and control coupling, and confuse logical cohesion (a module that does several related things selected by a flag) with functional cohesion. The result is a plausible but wrong ranking.
What to do instead
Memorise the coupling ladder from best to worst (data, stamp, control, external, common, content) and the cohesion ladder from best to worst (functional, sequential, communicational, procedural, temporal, logical, coincidental), each with one concrete example. When a question asks which design is best, evaluate the type of each relationship, not the count, and justify the ranking in one sentence per module. Redraw any given module structure and label each edge with its coupling type.
The candidate confuses black-box and white-box coverage criteria and claims that statement coverage subsumes branch coverage, or that 100% branch coverage guarantees detection of all faults.
Coverage criteria are learned as definitions rather than as a subsumption hierarchy. Candidates forget that branch coverage implies statement coverage but not the converse, that condition and MC/DC coverage are stronger than branch coverage, and that path coverage is infeasible for loops. They also overstate what coverage proves, ignoring that coverage measures exercised structure, not correctness of assertions.
What to do instead
Draw the subsumption chain once and keep it: statement < branch/decision < condition < MC/DC < multiple-condition, with path coverage noted as generally infeasible. For every coverage question, first ask which criterion is stronger and whether a counterexample exists where the weaker criterion is satisfied but the stronger is not (for example, a short-circuited condition where branch coverage misses an operand). Separately memorise the caveat that high coverage with weak oracles still permits many faults.
When asked to choose a design pattern, the candidate picks the pattern whose name sounds most sophisticated (for example Visitor or Abstract Factory) rather than the one whose intent matches the stated variability, and then justifies it with a benefit that the scenario does not require.
Patterns are memorised by name and structure, not by intent, forces, and consequences. Candidates cannot quickly map a stated problem ('families of related objects must vary together', 'algorithm should be selectable at runtime', 'object structure is stable but operations vary') to the pattern whose intent matches, so they default to the most familiar or most impressive name.
What to do instead
Build a one-page intent index: for each pattern record the problem it solves, the key variability it encapsulates, and one consequence or trade-off. Practise by reading a scenario, stating the variability axis in one sentence, and only then naming the pattern. Reject any option whose intent does not match that axis, and be ready to state one drawback of your chosen pattern, since exam items often test trade-off awareness.
The candidate treats version control, build automation, and continuous integration as interchangeable configuration-management activities, and answers configuration-management questions by describing branching policy when the question asked about configuration identification, status accounting, or audit.
Configuration management is a cluster of distinct activities (identification, control, status accounting, audit, plus build and release management) that candidates learn as a single block labelled 'Git and CI'. They therefore answer identification questions with branching strategies and audit questions with build pipelines, missing the specific activity the item targets.
What to do instead
Memorise the five configuration-management activities with one artifact each: identification (configuration items and baselines), control (change requests and change control board), status accounting (records of what changed and its state), audit (functional and physical configuration audit verifying the product matches its documentation), and build/release management. For each question, name the activity being described before choosing an answer, and eliminate options that belong to a different activity.
On effort-estimation and engineering-economics items, the candidate applies a formula mechanically without checking unit consistency, discounting convention, or whether the scenario is asking for effort, duration, or cost.
Function points, COCOMO-style effort equations, earned value, and net present value are memorised as formulas but not as dimensional quantities. Candidates mix person-months with calendar months, apply a productivity rate in the wrong direction, ignore whether cash flows are discounted at the start or end of a period, and misread CPI and SPI definitions (CPI = earned value / actual cost, SPI = earned value / planned value).
What to do instead
Before computing, write the units of every given value and the units of the requested answer, and state the formula in words ('effort in person-months equals size times productivity factor'). For earned value, memorise the two ratios and their interpretation (CPI below 1 means over budget; SPI below 1 means behind schedule) and sanity-check the sign of every variance. For NPV, fix the discounting convention in the scenario and apply it consistently. Practise a small numeric example of each formula until unit errors disappear.
When a scenario describes a security concern, the candidate recommends encryption as a universal control, or confuses authentication with authorisation and input validation with output encoding, instead of selecting the control that addresses the described threat.
Security controls are memorised as a list of technologies without being mapped to threat categories. Candidates do not distinguish confidentiality, integrity, and availability goals, nor the difference between proving identity (authentication), granting permission (authorisation), and making untrusted data safe for its sink (validation and encoding). Encryption then becomes the default answer even for injection or access-control problems.
What to do instead
Memorise a threat-to-control map: injection to input validation plus parameterised queries; cross-site scripting to context-aware output encoding; broken access control to server-side authorisation checks; credential theft to strong authentication and session management; data exposure to encryption in transit and at rest. For each scenario, first name the security goal being violated and the attack class, then select the control that directly addresses it, and reject controls that mitigate a different threat.
The candidate answers process and lifecycle questions by describing what a team should do in an ideal process rather than what the described model actually prescribes, and therefore selects CMMI-style answers for agile scenarios or Scrum answers for staged-plan-driven scenarios.
Process models are learned as aspirational best practice rather than as prescriptive frameworks with specific roles, artifacts, and ceremonies. Candidates blur CMMI maturity levels, ISO-style process assessment, Scrum roles and events, and Kanban flow policies, so they answer from general good sense and pick the option that sounds most professional rather than the one the named model mandates.
What to do instead
For each framework, memorise its distinctive vocabulary and artifacts: CMMI process areas and maturity levels; Scrum's three roles, five events, and three artifacts with their purposes; Kanban's work-in-progress limits and flow metrics; XP's engineering practices. When a question names a framework, answer strictly within that framework's vocabulary and reject options that import another model's terms. Where the question asks for judgement rather than prescription, look for the constraint in the stem (regulation, contract, team size) and let it drive the answer.