EGEL Plus Ingeniería de Software common mistakes
EGEL Plus Ingeniería de Software · Understand the traps and how to avoid them.
Choosing the first technically plausible answer without eliminating options, so a distractor that sounds correct but violates a stated constraint (e.g., a design that ignores a non-functional requirement given in the stem) gets selected.
The exam rewards discrimination between near-correct options; candidates who read only until they find a familiar term stop before comparing alternatives, and under time pressure this habit compounds.
What to do instead
Adopt a fixed routine: read the stem twice, predict the answer before looking at options, then explicitly reject each remaining option with a one-line reason tied to a constraint in the stem.
Treating 'análisis' and 'diseño' as one phase, so questions asking what artifact or activity belongs to requirements analysis get answered with design-level concepts (classes, patterns, schemas).
In practice the boundary is blurred and many candidates learned them together; the exam separates them and uses vocabulary that distinguishes problem-space from solution-space artifacts.
What to do instead
Build a two-column mental map: analysis = what the system must do (use cases, domain model, requirements specification, actors); design = how it will do it (architecture, interfaces, class design, patterns). Classify each practice question by which column it belongs to before answering.
Confusing UML diagram types and their purposes, e.g., picking a sequence diagram where a communication/activity/state diagram is correct, or treating a class diagram as showing runtime behavior.
Candidates memorize diagram names but not the question each diagram answers (structure vs. behavior, interaction ordering vs. object relationships), and distractors exploit exactly that gap.
What to do instead
For each of the main UML diagrams, write one sentence: 'This diagram answers the question ___.' Then drill items by first identifying the question the stem is asking (who talks to whom, in what order, what states, what structure) and mapping it to the diagram.
Selecting a testing level or technique that does not match the defect class described, e.g., answering 'unit testing' when the stem describes integration failures, or 'black-box' when the stem requires examining internal logic.
Levels (unit, integration, system, acceptance) and techniques (black-box, white-box, boundary, equivalence) are often memorized as lists rather than as tools matched to a goal.
What to do instead
Practice a matching table: for each defect scenario, name the level that would catch it and the technique that would generate the test cases. Pay special attention to boundary value analysis vs. equivalence partitioning and to who performs each level.
Mixing up verification and validation, or confusing the purpose of a code review, walkthrough, and inspection when the stem describes a specific quality goal.
The terms are used loosely in industry, and candidates transfer that looseness into the exam, where the definitions are strict and the distractors hinge on them.
What to do instead
Anchor on the classic definitions: verification = 'are we building the product right' (conformance to spec), validation = 'are we building the right product' (meets user need). For reviews, memorize formality level and goal (walkthrough = informal, author-led; inspection = formal, moderator-led, defect detection).
Answering project-management items by intuition about 'best practice' rather than applying the specific technique the stem implies (e.g., estimating with function points vs. COCOMO vs. planning poker, or choosing a schedule-compression action without checking its cost/risk trade-off).
Candidates rely on general work experience, which often differs from the textbook framing the exam uses, and they skip the step of identifying which method or metric the question is testing.
What to do instead
Before answering, name the technique being tested and its defining inputs/outputs. For trade-off items, evaluate each option against the constraint stated (cost, risk, scope, quality) and pick the one that satisfies the constraint rather than the one that sounds most modern.
Confusing risk management steps (identification, analysis, response planning, monitoring) or picking a risk response that is mislabeled (avoid, mitigate, transfer, accept) for the scenario described.
The response categories overlap in casual speech-'mitigate' and 'avoid' are used interchangeably at work-so candidates map the scenario to the wrong label.
What to do instead
Memorize the four responses with a one-line test each: avoid = change the plan to eliminate the threat; mitigate = reduce probability or impact; transfer = shift financial consequence to a third party; accept = acknowledge and budget contingency. Classify the stem's action against these tests.
Treating architectural styles and patterns as interchangeable labels, e.g., choosing 'layered' when the stem describes pipes-and-filters, or recommending microservices where the stated constraints (small team, simple domain) argue against it.
Candidates learn pattern names without their quality attributes and trade-offs, so they select by familiarity rather than by fit to the non-functional requirements in the stem.
What to do instead
For each major style (layered, client-server, pipes-and-filters, event-driven, microservices, MVC), record the quality attributes it promotes and the ones it sacrifices. Answer by matching the stem's stated quality attribute (scalability, modifiability, performance) to the style that promotes it.
Mixing up process-model characteristics (waterfall, iterative, incremental, spiral, agile/Scrum) and Scrum roles/artifacts/events, e.g., attributing backlog ownership to the Scrum Master or treating the sprint review as a retrospective.
Terminology overlaps across frameworks and candidates generalize from partial exposure; distractors swap roles, ceremonies, and artifacts that are easy to conflate.
What to do instead
Build a compact reference card for each model (when it fits, key risk-handling mechanism) and a separate card for Scrum: Product Owner owns the backlog, Scrum Master facilitates, the team owns the increment; review = inspect the increment with stakeholders, retrospective = improve the team's process. Drill until role-artifact-event mappings are automatic.
Running out of time because of uneven pacing-lingering on hard quantitative or design items while leaving easy conceptual items unanswered, or changing correct answers late under pressure.
Candidates lack a time budget per question and treat every item as equally weighted, so a few hard items consume the clock; late-second-guessing is driven by anxiety rather than new evidence.
What to do instead
Set a per-question time cap, mark and skip items exceeding it, and return with remaining time. Only change an answer when you can cite a specific misread word or a concrete fact you had forgotten-never on a vague feeling.