Criteria B and C: planning and system overview

Criteria B and C at a glance

Criteria B and C turn the specification from Criterion A into a plan and a design. B (Planning) is worth 4 marks and C (System overview) 6 marks. Each has a recommended length of only 150 words, because most of the evidence is diagrams and tables, and diagrams do not count towards the 2,000-word limit. Ten of the 30 marks therefore depend mainly on drawing the right diagrams and making them consistent with each other.

Both criteria must stay consistent with what comes before them: the plan in B with the problem and success criteria in A, and the system overview in C with both A and B. A component that appears in the decomposition but nowhere in the design, or a success criterion that no test in C checks, is a visible gap.

Criterion B: planning

Criterion B judges two things: how well you have broken the problem into parts, and whether your plan covers the success criteria with a sensible order and dates.

Decomposing the problem

Decomposition means breaking the problem scenario from Criterion A into smaller sub-problems or components, each of which can be designed, built and tested on its own. The IB describes a reasonable decomposition as one that breaks the problem into the essential components that support the construction of a plan. The usual way to show it is a decomposition diagram: the whole system at the top, its main components below, and the tasks inside each component below those.

Three choices make a decomposition reasonable rather than partial. The components are parts of the product ("Bookings", "Check-in"), not stages of the project. The breakdown stops at tasks small enough to plan, typically one to three days of work each. And every component is traced to success criteria, which is the link the B descriptors ask for.

YouTube

A plan with a chronology

The plan must cover the success criteria and include a proposed chronology for planning, designing, developing, testing and evaluating. Any clear form is acceptable; the IB names Gantt charts and agile charts as effective formats. A Gantt chart lists tasks down the side and time along the bottom, with a bar for each task's duration. Subtopic A1.3 uses Gantt charts to show how an operating system schedules processes on a CPU; the IA uses the same kind of chart for its original purpose, scheduling the work of a project.

The Gantt chart is named after Henry Gantt, who designed it in about 1910–1915 to schedule and track work. Source: Wikipedia, "Gantt chart".

The chart shows three planning decisions. The specification, plan and design come before any development; the riskiest rules (clashes and the weekly limit, SC2 and SC3) are built early, in sprint 2; and the last weeks hold testing, the video and the evaluation, so that the one draft your teacher reads is complete.

Agile development and sprints

Many IA plans follow an agile approach instead of a single long build. The product is built in short cycles, each ending with something that works and can be tested.

The agile approach was set out in the Manifesto for Agile Software Development, written by 17 software practitioners at Snowbird, Utah, in 2001. Sources: Wikipedia, "Agile software development" and "Scrum (software development)".

For an IA, agile suits a project where the client's feedback may change details: the head of music might see the first room grid and ask for lessons to be shown differently. It also reduces risk, because each finished sprint leaves tested, working parts even if a later sprint runs short. Its weakness for an IA is that Criterion B still needs a proposed chronology at the start, so the sprints must be planned in advance, then adjusted.

An agile plan is often shown as a sprint table. Each row is a piece of work written from the user's point of view, called a user story, tagged with the success criteria it serves and given a definition of when it is done.

Research in the plan

The plan may include research, such as the existing code libraries you will use. Recording it in B shows that you know which parts you will write yourself and which you will take from a library, which matters later in Criterion D. For the booking system, the research is short: the Flask web framework for pages and forms, the sqlite3 module from Python's standard library for the database, and a library function for hashing passwords, since writing a secure hashing function is neither the point of the project nor a safe thing to do from scratch.

A weak and a strong Criterion B

The weak sample's decomposition lists screens and a stage of work, misses the rules (clashes, limits, release, reports) and is not linked to any success criterion: a partial decomposition. The plan has a rough order but no tasks, no link to the success criteria and no time for evaluation, so it addresses only some of them. It fits the 1–2 band.

Criterion C: system overview

Criterion C is the design of the product. It asks for three things: a system model, algorithms for the components, and a testing strategy. The IB adds a test of quality: the overview should be clear enough for a third party to recreate the product.

The command terms mark different amounts of work. "Identifies algorithms" can be satisfied by naming them; "constructs algorithms that enable the product to perform" means writing them out fully enough that the product could be built from them. A testing strategy aligned with three success criteria matches the middle band, while the top band asks for alignment with the success criteria as a whole, so plan tests for all of them.

The system model

The system model is a set of diagrams showing the components of the system, how they are connected, the rules governing how they interact, and the design of the user interface. A complete system model does not include the algorithms: those come separately, one per component. Keeping the two apart makes the model easier to read and makes it obvious when a component has no algorithm.

Which diagrams make up the model depends on the computational context. Most products need one diagram showing the parts and the data moving between them, one showing the stored data, and the screen designs.

Data flow diagram

The booking system's DFD has two external entities (the student and the head of music), five numbered processes and four data stores. Each arrow is labelled with the data that travels along it.

Entity–relationship diagram

The data stores in the DFD become tables in the database. The ER diagram defines them precisely: each table's attributes, its primary key, its foreign keys and the relationships between tables, drawn in crow's foot notation as in subtopic A3.2, Database design.

The status attribute is a design decision worth one sentence in the documentation: keeping released and cancelled bookings, instead of deleting them, lets the weekly report (SC6) count no-shows.

Wireframes

The system model must include the design of the user interface, and wireframes are the usual way to show it. One wireframe for each main screen is enough, with numbered notes linking parts of the screen to the success criteria they serve.

Algorithms for each component

Each component of the system model needs an algorithm. The IB names natural language (numbered steps in plain English), flowcharts and pseudocode as suitable forms. Choose the form that makes each algorithm clearest: a flowchart for logic with several decisions, numbered steps for a simple sequence, pseudocode for anything with loops and data structures.

The make-booking algorithm has three checks before anything is saved, so a flowchart shows its decisions clearly. Each refusal ends with its own output, and the success path continues through connector A.

The clash test inside the flowchart's second decision is the most important algorithm in the product, and it is easy to get wrong, so it deserves its own pseudocode. Two time intervals overlap exactly when each one starts before the other ends.

FUNCTION clashes(room, new_start, new_end)
    // Bookings that still hold the room, and blocks, for this room on this date
    FOR EACH item IN active bookings and blocks for room on the date of new_start
        IF new_start < item.end AND item.start < new_end THEN
            RETURN TRUE        // the two intervals overlap
        END IF
    END FOR
    RETURN FALSE
END FUNCTION

FUNCTION minutes_left(student, new_start)
    monday <- date of the Monday on or before new_start
    used <- 0
    FOR EACH booking OF student WITH status booked OR checked_in
            AND start >= monday 00:00 AND start < monday 00:00 + 7 days
        used <- used + length of booking in minutes
    END FOR
    RETURN 180 - used
END FUNCTION

The strict "less than" in the clash test is what allows back-to-back bookings, as SC2 requires. The table checks the condition against an existing booking from 10:00 to 10:30, which is also the start of a good test plan.

Not every component needs this much detail. The table gives a suitable form for each of the booking system's components.

The testing strategy

The testing strategy is a systematic plan for checking that the product works as intended and handles unexpected or incorrect input. The IB suggests showing it as a table of proposed test data and expected outcomes, and that table is usually called a test plan.

A strong test plan has four qualities. Every success criterion has at least one test. Each rule is tested with normal, boundary and erroneous data (subtopic B2.1, Programming fundamentals). Expected outcomes are exact ("refused with 'Slot taken'; no new row in BOOKING"), so that pass or fail needs no judgement. And at least one test checks efficiency, since Criterion D asks for testing of correctness, reliability and efficiency.

A weak and a strong Criterion C

The weak sample's model is limited and has no design of its own (a screenshot is the product, not a model), no relationships, and no blocks, notices or check-ins. The algorithm is identified, not constructed: "checks it is free" hides the whole clash rule. The testing strategy covers at most one success criterion with no measurable outcome. Each part fits the 1–2 band.

The strong sample constructs a complete model (data, processes, interface), constructs algorithms detailed enough to build from, and describes a testing strategy aligned with every success criterion, with boundaries chosen from the algorithms themselves (T6 tests the strict "less than"; T8 and T9 sit either side of 180 minutes). It fits the 5–6 band, and a third party could rebuild the product from it.

Checklist

• To do:

  My decomposition diagram breaks the problem (not the documentation) into components and tasks.

• To do:

  Every component is tagged with the success criteria it serves, and every success criterion appears at least once.

• To do:

  My plan has dates and covers planning, design, development, testing and evaluation, with the draft deadline in it.

• To do:

  I have chosen between a Gantt chart and an agile sprint plan, and my sprints deliver complete success criteria.

• To do:

  I have recorded the libraries I will use and what I will write myself.

• To do:

  My system model shows every component, how they connect and the data stored, using the right diagrams for my context.

• To do:

  My system model includes wireframes of the main screens, drawn before building them.

• To do:

  My algorithms are separate from the model, one per component, in a clear form (flowchart, pseudocode or steps).

• To do:

  I have checked my key algorithm against boundary cases, as with the clash-test table.

• To do:

  My test plan covers every success criterion, with normal, boundary and erroneous data and at least one efficiency test.

• To do:

  Every expected outcome is exact enough to pass or fail without judgement.

• To do:

  A classmate could rebuild my product from Criterion C alone.