Software Engineering › Notes › The Software Engineering Project (Year 12)

The Software Engineering Project (Year 12)

Define and analyse the requirements of a problem

• 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.

Implementation (conversion) methods

• 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.

Waterfall

• 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.

Agile

• 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 (hybrid) and Waterfall v Agile comparison

• 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.

Project management, communication and ethics

• 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.

Modelling tools: DFD, structure charts, storyboards, flowcharts, class diagrams

• 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).

Data dictionary

• 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.

Quality assurance, testing methods and test data

• 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.

Debugging tools and error types

• 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.

Maintenance, version control, stubs and drivers, optimisation

• 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.

Skeleton: Compare two methods (Waterfall v Agile or implementation methods) (4-5 marks)

• 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).

Skeleton: Justify an implementation method or approach for a scenario (5 marks)

• 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.

Part 2. School notes (Canvas, 12SENX2) by syllabus dot point

Corrections are marked in the text. Anything not marked is the school wording.

Define and analyse the requirements of a problem, including demonstrating need(s) or opportunities, assessing scheduling and financial feasibility, generating requirements including functionality and performance, defining data structures and data types and defining boundaries.

The process of defining and analysing a problem's requirements is critical because it influences the project's outcome. Requirements are a system's specific features to solve a problem. They provide clear, measurable goals to guide development and ensure the system meets user needs and can be tested for success.

Step 1: Demonstrating Needs or Opportunities

Why is the project needed?

• Conducting a feasibility study Interviews with stakeholders to understand their needs.

Questionnaires to gather input from a wide range of users.

Observations of current systems or processes to pinpoint inefficiencies.

Step 2: Scheduling and Feasibility

By assessing both scheduling and financial feasibility, the development team ensures that the project remains within scope and can be delivered on time and within budget.

Scheduling feasibility - estimating the duration of the project, Gantt Chart

Financial feasibility – estimating developmental costs and comparing them with the budget.

Step 3: Generating Requirements

Specific requirements in terms of functionality and performance should be generated and documented in a software requirements specification (SRS), which will be a reference throughout the development process.

Functional requirements describe the specific actions the system must perform.

Performance requirements specify how well the system should perform these functions.

E.g.: Speed, Reliability, Scalability

Step 4: Data Structures and Data Types

Defining the data structures and types is essential for fast, efficient, reliable data management and processing.

E.g.: Product names are strings and quantities are integers in an inventory management system.

Defining Boundaries

Defining a system's boundaries controls the project's scope, preventing scope creep and added expenses.

Explore tools used to develop ideas and generate solutions, including brainstorming, mind-mapping and storyboards, data dictionaries, selecting appropriate data types, algorithm design, code generation, testing and debugging, installation, and maintenance.

Brainstorming, mind-mapping and storyboards

Brainstorming helps generate ideas and explore potential solutions. It involves team members contributing their thoughts freely. Mind mapping allows developers to structure information non-linearly, showing how different concepts are connected.

Algorithm Design

Algorithm design involves creating step-by-step instructions to solve a specific problem. Effective algorithms are designed to be both efficient and scalable.

Code Generation

Code generation is the process of translating the algorithm or system design into actual code in a programming language.

Testing and Debugging

Testing involves running the program under various conditions to identify any issues or bugs.

Unit testing: Testing individual components or functions.

Integration testing: Ensuring that different modules of the system work together correctly.

System testing: Testing the entire system to verify that it meets the requirements.

Installation

Installation is the process of transferring the software from the development environment to the end-user environment. It often involves setting up databases and configuring hardware. Thorough documentation and testing of the installation process are essential to ensure the system works as intended in the target environment.

Maintenance

Maintenance is the ongoing process of updating and improving the software after its installation. Effective maintenance ensures the software meets user needs and remains relevant in a changing technological landscape.

Corrective maintenance: Fixing problems or defects that arise post-deployment.

Adaptive maintenance: Updating the software to work in a new or changing environment (e.g., when hardware or operating systems are updated).

Perfective maintenance: Enhancing or adding new features to improve performance or functionality.

Investigate types of software implementation methods, including direct, phased, parallel, and pilot.

Direct

In direct conversion, the old system is entirely replaced by the new system at a specific time. This is used when it is impractical to operate both systems simultaneously.

• Fast and clean – Do not need to maintain two systems at once
• Must be thoroughly tested or at risk of operational disruptions with no backup systems
• Users must be fully trained before the switchover. E.g.: A bank installing new ATMs with new touch screen features would use direct conversion. It would be impractical to have old and new ATMs operating side by side, as it would confuse customers and duplicate work.

Parallel

Parallel conversion involves running both the old and new systems simultaneously for a period.

• Allows users to gradually familiarise themselves with the new system while retaining the security of the old system.
• Has the old system as a backup if problems occur with the new system.
• Resource-intensive, as both systems must be maintained for operation until the new system meets requirements. E.g.: A hospital installing new life support systems uses parallel conversion. Staff would continue to monitor patients manually while becoming familiar with the automated monitoring system, ensuring patient safety throughout the transition.

Phased

In phased conversion, the new system is introduced gradually, often in stages. As parts of the new system are implemented, the corresponding parts of the old system are removed.

• Useful for large or complex systems where implementing everything at once would be overwhelming or risky.
• Allows users to adapt gradually, reduces the likelihood of errors, and makes the process more manageable for developers and users.
• It takes longer than other methods, and coordination between different system parts is crucial. E.g.: A school can use phased implementation to implement a learning management system, using it in selected classes for marking rolls to eventually marking assignments, ensuring each module’s functionality before implementing the next module.

Pilot

The pilot conversion method involves installing the new system for a small group of users before rolling it out to the entire organisation. This allows the system to be tested in a real-world environment, providing valuable feedback to developers and ensuring that any issues are addressed before full-scale implementation. The pilot users can also assist in training others when the system is eventually rolled out.

Used for new or highly complex systems where there is uncertainty about how the system will perform under real-world conditions. It limits the impact of any issues to a small group.

E.g.: A new ticketing system for a travelling circus could be piloted at a single location to ensure it works properly before being used across all venues.

Research and use the Waterfall software development approach, including logical progression of steps used throughout the life cycle, stages of ‘falling water’, advantages and disadvantages and scale and types of developments.

Refer to the above notes.

The Waterfall approach is a traditional, linear methodology where each phase of the project must be completed before moving on to the next.

Advantages

The clear linear structure is easy to follow and manages large teams with different skill sets, as each team knows precisely what is expected at each stage.

The developers and stakeholders have a shared understanding of the project's goals, where requirements are fully documented before the project starts.

A structured approach ensures every aspect of a large-scale project is meticulously planned and executed.

Disadvantages

Inflexibility: it is difficult to go back and make changes without causing delays and increasing costs.

Late Testing: Issues or defects may not be discovered until the completion of the developmental phase.

Poor Adaptation to changes in requirements

Longer timeframes because of the sequential nature of the Waterfall

Scale and Types of Developments

The Waterfall approach is typically used for large-scale and complex projects where the requirements are well understood from the outset and unlikely to change. These projects involve significant time, money, and resources, and usually have strict performance, safety, or regulatory requirements.

E.g.:

Aviation software that requires extensive testing and validation is well-suited to Waterfall due to its structured, rigorous testing phase.

Research and use the Agile software development approach, including the rate of developing a final solution, method tailoring, iteration workflow, and scale and types of development.

Agile is a flexible and iterative approach to software development that focuses on delivering small, functional increments of a solution quickly while continuously adapting to changes based on user feedback and collaboration.

Rate of Development

Agile is fast at delivering working versions of solutions through fast iterations. Each iteration focuses on delivering a functional increment of the software, allowing the team to respond quickly to changing requirements or feedback.

• The Minimum Viable Product is released ASAP. Agile ensures that the project delivers value even before it's fully complete.

Method Tailoring

Method tailoring refers to the flexibility Agile offers in adapting its developmental process to suit the project's unique demands rather than adhering to rigid guidelines.

Agile includes a variety of frameworks with flexibility in their cores. By mixing frameworks, the developmental process can be customised.

• Scrum: Often used for complex projects, it emphasises short, time-boxed iterations called sprints, with regular meetings (e.g., daily stand-ups) to keep the team on track.

Iteration Workflow

Agile development is conducted through short, repeatable development stages called iterations. Each iteration results in a working software version that stakeholders can test, review, and evaluate.

Planning

Design and Development

Testing

Feedback and Evaluation

Iterative Cycle

Scale and Types of Developments

Agile is highly adaptable and can be applied to both small and large-scale projects

Small Projects: The flexibility of small teams allows for quick decision-making and fast adaptation to change.

Large Projects: Agile can be applied by breaking the project down into smaller, self-organising teams focusing on a component or feature of the larger system.

E.g.:

• Mobile and Web applications

Research the WAgile software development approach, including understanding it is a hybrid model, analysis of the ‘when’ and ‘how’ intervention is applied during the development life cycle, and scale and types of developments.

WAgile is a hybrid software development approach that combines the structured, linear nature of the Waterfall methodology with the flexible, iterative elements of the Agile methodology.

Understanding WAgile as a Hybrid Model

WAgile combines the predictability of Waterfall with the adaptability of Agile. WAgile integrates both by starting with the structured planning and documentation from the Waterfall approach, which provides clarity and a roadmap for the project. Then, Agile’s iterative development cycles are incorporated into the later stages of development, allowing for flexibility, regular feedback, and adaptation to change. This makes WAgile suitable for projects that need a balance between formal planning and flexibility in execution.

When and How Intervention Is Applied During the Development Lifecycle

Scale and Types of Developments

WAgile is suited to medium- to large-scale projects where both structure and flexibility are needed. The hybrid approach works well when the project’s requirements are well-defined upfront, but are expected to change during the development process.

Small-scale projects: WAgile’s overhead of initial planning may be excessive.

E.g.:

• Large-scale web applications

Apply project management to plan and conduct the development and implementation of a project and software engineering solution, including scheduling and tracking using a software tool, including Gantt charts, using collaboration tools.

Project Management Tools

• Gantt chart
• Version control system
• Logbook
• Installation guide
• Technical Manual

System Modelling Tools

• DFD Level 0
• DFD Level 1
• Pseudocode
• Structure Chart
• UML
• Data dictionary
• Flowchart
• ORM

Explore social and ethical issues associated with project work, including working individually, collaboratively and responding to stakeholders.

Working Individually [Ethical]

Without input from others, individuals allow personal biases to influence the design and implementation of the project, potentially overlooking vital details. Ethically, it’s important to challenge one's assumptions and seek feedback from external sources when necessary.

Working Collaboratively [Ethical]

An ethical approach to teamwork involves ensuring that tasks are distributed fairly among team members based on their skills and capacities.

Responding to Stakeholders [Ethical]

Ethical project management requires prioritising the needs and safety of users, ensuring that the software does not harm them or compromise their privacy and data.

Explore communication issues associated with project work, including involving and empowering the client, enabling feedback, and negotiating.

Involving and Empowering the Client

Involving the client early and consistently ensures that the final product aligns with their vision and needs. It also enhances the client’s trust in the project team and allows for smoother collaboration.

Strategies to Empower the Client

Provide the client with detailed project plans, timelines, and updates

Regularly delivered prototypes help clients visualise progress and meet their needs.

Visibly act on Feedback

Negotiating

Negotiation plays a key role in resolving conflicts and ensuring that both the client and the development team are satisfied with the project's direction, helping balance the client’s desires with the realities of development.

Effective Negotiation Techniques

Understand Both Sides

Focus on Solutions

Be Transparent

Set Clear Boundaries

Any negotiated changes to the project should be documented

Investigate how software engineering solutions are quality assured, including defining criteria on which quality will be judged, ensuring requirements are met using a continual checking process, addressing compliance and legislative requirements.

Quality Assurance (QA) is a systematic process that ensures a software product meets defined quality standards. QA also addresses legal and regulatory compliance, ensuring the software is functional, safe, and lawful.

E.g.: QA of a mobile application would test key performance metrics such as scalability against the requirement definition.

Part 3. Where this has been examined (see ../../question_bank.md)