The Software Engineering Project (Year 12)

Need or opportunity — Start by showing the problem to fix (need) or a benefit to gain (opportunity). Gather information by interviews, surveys, observation and reading documents.

Feasibility — Assess scheduling feasibility (can it be built by the deadline?) and financial feasibility (cost v budget and benefit). Also technical and operational feasibility if asked.

Functional requirements — What the system must DO (e.g. user can log in, search products, export a report).

Performance requirements — How WELL it must do it: speed, capacity, reliability, availability, response time (e.g. page loads in under 2 seconds, supports 500 users).

Data structures and data types — Decide how data is stored and its types (string, integer, real, Boolean, date, array, record, file) using a data dictionary.

Boundaries — What is in scope and out of scope (what the system will and will not do, and what external systems/users it interfaces with). Shown with a context (level 0) diagram.

Tools to generate ideas — Brainstorming, mind-mapping, storyboards, data dictionaries, algorithm design (pseudocode/flowcharts), code generation, testing and debugging, installation, maintenance.

Direct — The old system is switched off and the new one is switched on at once. Cheapest and quickest; highest risk because there is no fallback if the new system fails. Suits small or low-risk systems or an urgent change. 2025 Q1 asked the match for 'pilot'.

Phased — The new system is introduced in stages (module by module), replacing old parts as each works. Lower risk, easier training, but takes longer and old and new must work together.

Parallel — Old and new run side by side for a period and outputs are compared. Safest (the old system is a backup, ideal for critical systems like payroll or life support) but costs more (double work, resources).

Pilot — The new system is installed for a small group, branch or location first, tested in the real world, then rolled out to everyone. Gives feedback and trained staff, but the rollout is slower and pilot users may not represent everyone.

Choosing — Critical = parallel. Small/urgent/low-risk = direct. Large system with separable parts = phased. Many sites = pilot.

What it is — A sequential, plan-driven approach in which each stage is finished before the next starts, 'falling' like water: requirements, design, development (build), testing, installation/deployment, maintenance.

Advantages — Clear structure and milestones, thorough documentation, easy to manage and budget, suits projects with stable, well-understood requirements.

Disadvantages — Inflexible to change, the client sees the product late, errors found late are costly to fix, no working software until the end.

Scale and types — Suits large, safety-critical or regulated projects (e.g. aviation, government, infrastructure) where requirements are fixed.

What it is — An iterative, incremental approach that delivers working software in short cycles (sprints, typically 1–4 weeks), with continuous client feedback and the ability to change requirements.

Rate of developing — A usable product is delivered early and improved each iteration, so the final solution evolves quickly.

Method tailoring — Teams adapt the approach (e.g. Scrum, Kanban, XP) to the project: roles, sprint length, meetings (daily stand-up, review, retrospective).

Iteration workflow — Plan the sprint, build, test, demo to the client, collect feedback, then repeat with the next backlog items.

Advantages — Flexible, early delivery of value, client involvement, early detection of problems.

Disadvantages — Less predictable cost and schedule, less documentation, needs an engaged client and an experienced, communicative team, scope creep.

Scale and types — Best for small to medium projects with changing or unclear requirements (apps, websites, startups).

WAgile — A hybrid that combines the structured planning and documentation of Waterfall with the iterative, flexible development of Agile.

When and how — Typically Waterfall-style requirements, planning and design up front (clear roadmap); Agile sprints for the development/testing phase; then a controlled Waterfall-style release. Analyse WHEN agile is applied (later stages) and HOW (iterations, feedback).

Scale and types — Medium to large projects where requirements are well defined upfront but expected to change during the build, or where regulation demands documentation yet teams want flexibility.

Compare — Waterfall: sequential, fixed requirements, late testing, heavy documentation, change is costly. Agile: iterative, evolving requirements, continuous testing, working increments, change welcomed. WAgile: mix.

2025 Q2 — Question matched characteristics to Waterfall or Agile; know the keywords: sequential/phases/documentation = Waterfall; sprints/iterations/feedback/flexible = Agile.

Gantt chart — A bar chart of tasks against time, showing start/end dates, durations, dependencies (a task that must finish before another starts) and the critical path. Used to schedule and track progress against the plan.

Tracking tools — Software tools such as Trello, Jira or MS Project/Excel for scheduling and tracking; collaboration tools such as Teams, Slack, GitHub.

Logbook / process diary — A dated record of what was done, decisions, problems and solutions, time spent; shows the development process and supports accountability and later maintenance.

Communication — Involve and empower the client, enable feedback (demos, reviews), and negotiate requirements and priorities.

Social and ethical issues — Working individually v collaboratively (fair division of work, credit, respect for different views); responding to stakeholders (honest reporting, managing expectations, confidentiality).

Quality assurance — Define the criteria on which quality will be judged; ensure requirements are met using continual checking; address compliance and legislative requirements.

Difficulties — Look for a solution online (forums, documentation; acknowledge sources and check licences), collaborate with peers, or outsource (hire others for a part: cost and control trade-off).

Backup and version control — Programmed (automated) backup and version control protect the work and allow recovery.

Data flow diagram (DFD) — Shows how data moves through a system (course-spec symbols). A CIRCLE is a process (uses input(s) to generate output(s)). A DATA STORE is an electronic file or non-computer storage. An EXTERNAL ENTITY is any person, organisation or element that provides data to or receives data from the system. A labelled CURVED ARROW is the flow of data between processes, data stores and external entities.

Level 0 DFD — Course spec: an overview of the entire system; it does not show data stores or internal processes. One process, external entities, labelled flows.

Level 1 DFD — Breaks the system process into main sub-processes and shows data stores. Must balance with level 0 (same inputs/outputs).

Structure chart — Hierarchy of modules from the top-level mainline down to sub-modules; shows how a program is divided into subroutines. Course-spec symbols: EMPTY circle = data movement between subroutines (parameters); FILLED circle = flag/control variable; small DIAMOND = decision (optional execution of a subroutine, selection); CURVED arrow = repetition. Detail for a lower-level subroutine goes in a separate chart with the same name: this is REFINEMENT.

Storyboard — A series of sketched screens showing the user's path through the UI with arrows (navigation) and notes on what each button or link does.

Flowchart — Top to bottom, left to right. Terminator (start/end), parallelogram (input/output), rectangle (process), diamond (decision with labelled arrows Yes/No), arrows for flow.

Decision tree — Root decision node, labelled branches, outcome leaves; shows the logic from conditions to actions.

Class diagram — Boxes divided into class name, attributes and methods; inheritance shown by an arrow from the subclass to the superclass.

Entity relationship diagram (ERD) — Shows tables (entities), attributes and the relationships (one-to-one, one-to-many, many-to-many) between them.

Abstraction and refinement — Hide detail at the top level and refine it into steps below (top-down design).

What it is — Course spec: a comprehensive description of each variable stored or referred to in a system. Records or arrays of records can be included.

Columns (course-spec example) — Variable, Data type, Format for display, Size in bytes, Size for display, Description, Example, Validation.

Example row (course spec) — PayRate | Floating Point | $NNN.NN | 4 bytes | 7 | Hourly rate of pay | $124.37 | Decimal greater than 20, less than 400.

Sizes in the spec example — Integer (Times_Late, 0-999) 2 bytes; floating point 4 bytes; Boolean 1 bit; string 1 byte per character (UserId 5 chars = 5 bytes); a date and time is always stored as 32 bits (4 bytes), whatever the display format (e.g. YYYY/MM/DD or DD/MM/YYYY hh:mm:ss); array of strings = size x number of items.

Format notation — X = a letter, N = a digit, e.g. UserId XXNNN (two letters then three digits, such as PT173); $NNN.NN for money.

Purposes — Describe data and data types, structure data, and record relationships; keeps types and validation consistent.

Choosing types — Name = string; whole count = integer; price/mark = real/floating point; yes/no = Boolean; birth date = date and time; single letter = char.

2025 Q15a — A dropdown-completion data dictionary question (3 marks: all dropdowns correct = 3, five = 2, three = 1). The completed table is an image in the MG, so check the format/size/validation logic using the rules above.

Unit testing — Test each small part (function/module) on its own.

Integration (subsystem) testing — Test that modules work correctly together and pass data across interfaces.

System testing — Test the complete system against the requirements.

Acceptance testing — The client/end users test that the system meets their needs before it is accepted.

Black box — Tester knows inputs and outputs but not the code. White box :: Tester sees the internal code and tests every path. Grey box :: Partial knowledge of the internals.

Functional v non-functional — Functional: does the feature do what it should. Performance/volume testing: speed and load with a large amount of data.

Beta testing — Real users outside the team trial a near-final version and report problems.

Live v simulated data — Live data = real data from the real environment. Simulated (test) data = created to imitate real conditions safely and to include extreme cases.

Boundary values — Test at and either side of the limits (e.g. valid range 1–10: test 0, 1, 10, 11).

Path coverage — Choose data so every path through the code (each branch/loop) runs at least once.

Faulty and abnormal data — Wrong type, empty, too large, negative, special characters, to confirm the program handles errors without crashing.

Test plan — Lists each test, the test data, expected output and actual output, with pass/fail; comparing actual to expected output shows the result.

Report to synthesise feedback — Collect user and tester feedback, summarise it, and decide changes; evaluate effectiveness against the requirements.

Breakpoint — A marker on a line where execution pauses so you can inspect the program state.

Single line stepping — Run one line at a time to follow the flow and see where it goes wrong.

Watches — Track chosen variables as they change.

Interfaces between functions — Check the values passed into and returned from functions (parameters and return values).

Debugging output statements — Print statements that show a variable's value or that a section of code has been reached.

IDE debugger — Debugging features built into an integrated development environment (VS Code, PyCharm, IDLE).

Syntax error — Breaks the language rules (missing colon, bracket or misspelt keyword); the program will not run.

Logic error — The program runs but gives wrong results (wrong operator, off-by-one, wrong condition); found by testing and desk checking.

Runtime error — Occurs during execution (divide by zero, file not found, wrong type, index out of range); handle with try/except.

Desk checking — Manually tracing an algorithm with sample data in a trace table; peer checking is another person doing it.

2025 Q15b answer (3 marks) — Outline TWO tools: e.g. breakpoints halt execution at a line to check variables or step through; debugging output statements show that a section has been reached or print a variable's contents. 'Outline' = what it is and what it does, not just a name.

Corrective — Fix errors and bugs found after release.

Adaptive — Change the software to suit a new environment (new operating system, hardware, law or regulation).

Perfective — Improve performance or add features and usability (user requests).

Version control — Track changes, branch, merge, revert; supports teams and keeps history (Git, GitHub).

Stub — A simple placeholder for a low-level module that is not built yet; returns a fixed value so top-level modules can be tested (top-down integration).

Driver — A temporary piece of code that calls and tests a module that has no mainline yet (bottom-up testing).

Language-dependent code optimisation — Improving speed or memory use using features of the specific language (2025 Q4). Python examples: use list comprehensions instead of loops, use built-in functions (sum, sorted), use a set or dictionary for fast lookups, avoid repeated work in loops (store results), use generators.

Language-independent — General improvements that work in any language: better algorithm, remove redundant code, reduce nested loops.

Define — One line each.

Similarity — One shared point (both include testing; both aim to deliver a working solution).

Difference 1 — Process or timing (sequential v iterative; all at once v staged).

Difference 2 — Risk, cost or flexibility.

Judgement — Which suits the scenario, and why (size, risk, requirement stability).

Choose — State the one you recommend.

Reason 1 — Link its feature to the scenario (critical, many sites, small team).

Reason 2 — Another benefit with the scenario.

Reject — Briefly say why one alternative is less suitable.

Risk — Name the main drawback and how to reduce it.