Criterion D: Development

Marks: 12 • Recommended words: 1,000

Criterion D is the largest criterion, worth almost half the IA’s 30 marks and the only one that assesses the product itself. Criteria A, B, C and E are process-oriented; Criterion D asks what you built and how.

You support this criterion with three pieces of evidence:

The documentation (1,000 words) justifying the structure of the product, explaining and evaluating the techniques used, and describing and justifying the testing strategy.
The video (up to 5 minutes) demonstrating the product’s full functionality and giving examples from your testing.
The appendices containing the full source code, which referenced excerpts in the documentation point to.

The development must be consistent with Criterion A (problem specification), Criterion B (planning) and Criterion C (system overview). You should be implementing the design you described, not a different product.

1. The video

The video provides evidence of the functionality of the product and examples of your testing strategy in action.

Video requirements

Length: no longer than five minutes. This is a hard limit stated in the 2027 IA guide.
Format: mp4, .avi, .wmv (or any common format).
Must demonstrate the full functionality of the product.
Must demonstrate examples of the testing strategy from Criterion C.
Must be narrated. Silent screencasts lose Criterion D marks because the examiner cannot tell what is being demonstrated or why. Talk through what you are doing as you do it.
Submitted as a separate file alongside the documentation and appendices.

What to include

Brief introduction (~15 seconds): name of the product, the problem it solves.
Functionality demonstration (~3 minutes): walk through every feature, narrated, with test data. Annotate on screen which success criterion is being demonstrated as you go.
Testing examples (~90 seconds): pick a handful of rows from your testing strategy table (especially boundary and abnormal cases) and run them. Show the input, the expected outcome, and the actual result.

What to leave out

Code walk-throughs. The code goes in the appendices and the documentation. The video is about the product, not the source.
Extensibility demonstrations. Extensibility is no longer a separate assessment item in the 2027 syllabus, so do not spend video time on it.
Intro animations, credits, background music. Keep it functional.

Recording tools

macOS Screenshot / QuickTime (Cmd-Shift-5): built in, records screen with audio.
Windows Xbox Game Bar (Win+G): built in, records screen with audio.
OBS Studio: free, cross-platform, more control than the built-ins.

Good audio matters more than good video. A decent microphone and a quiet room beat any camera.

2. Justifying the product structure

In the documentation, you must justify the structure of the product, why the structure is appropriate, and the techniques used.

The structure

Describe the high-level structure (typically the classes, modules, or services) and explain why this structure was chosen. Link the explanation back to the system model in Criterion C.

Useful questions to answer:

Why this number of components, and not fewer or more?
Why these boundaries between components?
What does each component own, and what does it not touch?
How does the structure make the product maintainable or extensible?

A one-paragraph justification tied to a class diagram from Criterion C is usually enough.

The techniques

The 2027 guide lists four categories of technique that count:

Category	What it means	Examples
Loops	Iteration constructs used for non-trivial work	`while` loops with complex exit conditions, nested iteration, iterator patterns
Data structures	Data organisations appropriate to the problem	`ArrayList`, `HashMap`, binary search tree, stack, queue, linked list
Existing libraries	Third-party or standard-library code that solves part of your problem	JavaFX for UI, JDBC for databases, JSON parsers, regex engines, CSV libraries
Integration of software tools	Combining multiple tools into a coherent product	Database + front-end + file export, REST API + local cache, file I/O + GUI + validation layer

For each important technique:

Identify the technique clearly.
Explain the choice: why this technique, given the problem and the data.
Show a referenced code excerpt in the documentation that points to the full code in the appendix.
Where appropriate, evaluate the choice: what did it gain you, what did it cost?

One complex technique well-justified scores higher than five superficial ones. Do not pile on data structures or patterns hoping quantity matters. Examiners reward depth of justification, not breadth of feature list.

The command-term ladder for implementation choices

The “implementation choices” strand is where most IAs lose marks within Criterion D, and the gap is almost always between stating and evaluating. The rubric uses four command terms in order:

Mark band	Command term	What it looks like in your prose
1-3	States	“I used a HashMap to store the recipes.”
4-6	Outlines	“I used a HashMap because it gives fast lookup by name.”
7-9	Explains	“I used a HashMap because lookup-by-name is the dominant operation, and the alternative ArrayList would require linear search per lookup.”
10-12	Evaluates	“I used a HashMap because lookup-by-name is the dominant operation. ArrayList would force linear search per lookup, which would slow noticeably above 100 recipes (I measured this in test 4). The trade-off is that I lost ordering for free; I addressed this by sorting on display, which adds O(n log n) per render but is only triggered on view changes.”

The command-term progression also applies to the effectiveness of testing strategy strand:

States the testing strategy used: “I ran the tests in my testing strategy table.”
States the effectiveness: “The testing strategy was effective because most tests passed.”
Describes the effectiveness: “The strategy uncovered a unit-conversion bug in SC4 (test 7) and a validation gap in SC2 (test 3). After fixes, all tests passed; the strategy gave confidence that the core workflow worked.”
Justifies the effectiveness: “Adding boundary tests for empty lists and abnormal tests for invalid units revealed two defects in the pantry comparator that happy-path testing had missed. The strategy was effective because it triggered failures in the highest-risk part of the product (data aggregation across heterogeneous units), but it would not have caught concurrent-access defects, mitigated here by the product being single-user, single-process.”

Code excerpts in the documentation

Any code you show in the documentation must:

Include relevant comments explaining what the code is doing at the level a reader needs.
Be consistent in style (naming conventions, indentation, bracket placement) throughout the solution.
Be readable: meaningful identifiers, short enough to follow, with complex expressions split across lines.
Reference the full source code submitted as an appendix. The convention is to reference by class and method name (e.g. “see ShoppingList.generate() in Appendix A”), so the examiner can find the full implementation without searching the whole codebase.

Excerpts, comments and diagrams are not counted toward the 1,000-word limit, so use them liberally.

3. Testing in the documentation

The testing strategy from Criterion C is deployed and reported on in Criterion D. You must:

Describe the testing strategy as it was actually carried out.
Justify its effectiveness: explain why these tests give confidence in the product.
Include testing for correctness (the product produces the right output), reliability (it handles unexpected input, edge cases, repeated use), and efficiency (it performs acceptably on realistic data sizes).
Support the description with examples in the video.

You do not need to reproduce the entire testing strategy table from Criterion C. Reference it and focus on what the testing revealed about the product.

Testing in the video is required, not optional. A documentation section saying “the strategy was effective” without video evidence of the actual tests being run stays in the middle band. Pick a handful of tests (especially boundary and abnormal ones) and run them on camera with narration.

4. AI tools in the IA

The 2027 syllabus permits using generative AI for code, but treats it as a coding technique that must be justified like any other. To award marks for code that AI helped produce, the examiner needs to see:

A justification for choosing the AI tool: why was it appropriate for this specific problem or sub-problem, and what alternatives were considered?
An explanation of how the AI-produced code works: what algorithm or technique is the AI implementing, how does it integrate with the rest of your code, and what data does it process?
A clear citation at the point of use in the documentation, with a corresponding entry in the appendices listing the tool, the prompt, and what you changed yourself.
Evidence that you understand it. If a viva or follow-up question would expose the AI-produced code as a black box, the examiner cannot credit it.

The IB position is explicit: using AI without understanding it does not score. Even where AI is used to good effect, the IA must still demonstrate your own algorithmic thinking elsewhere in the solution. Letting AI write the whole product is not a route to marks.

Mark bands

Marks	Level descriptor
0	The response does not reach the standard described below.
1–3	The response: constructs a product with very limited functionality; constructs a product using no appropriate techniques to implement the algorithms; states the choices made to implement the algorithms; states the testing strategy used.
4–6	The response: constructs a product that has limited functionality; constructs a product using at least one appropriate technique to implement the algorithms; outlines the choices made to implement the algorithms; states the effectiveness of the testing strategy.
7–9	The response: constructs a product that has partial functionality; constructs a product that uses some appropriate techniques to implement the algorithms; explains the choices made to implement the algorithms; describes the effectiveness of the testing strategy.
10–12	The response: constructs a fully functional product; constructs a product that uses appropriate techniques to implement the algorithms; evaluates the choices made to implement the algorithms; justifies the effectiveness of the testing strategy.

The four thresholds to watch:

Functionality: very limited → limited → partial → fully functional.
Techniques: none appropriate → at least one → some → all appropriate.
Discussion of choices: states → outlines → explains → evaluates.
Testing: states → states effectiveness → describes effectiveness → justifies effectiveness.

To land in the top band, every dimension needs to be at its top level. A fully functional product with only “states” about techniques does not get 10+.

What “fully functional” means

For the 10–12 band the rubric requires “a fully functional product.” In practice this means every success criterion from Criterion A produces working behaviour as demonstrated in the video, not just “the product runs without crashing.” A product that runs cleanly but only meets four of seven success criteria is partial functionality, not full, and it sits in 7–9.

Appendices and full marks

Solutions that do not include an appendix with the full source code cannot be awarded full marks for the techniques demonstrated in Criterion D.

This is a hard rule. Always submit the appendix.

Word count and formatting

Recommended word count: 1,000 (excluding code excerpts, comments and diagrams).
Include the overall documentation word count on the first page of the full PDF.
Suggested section heading in the single-PDF documentation: “Criterion D: Development”.

Common pitfalls

Narrating what you did instead of justifying choices. The top band needs you to evaluate: say what each technique gained, what alternatives existed, and what the trade-off was.
Video longer than 5 minutes. The guide sets five minutes as a maximum; anything beyond that breaches a submission requirement.
Demonstrating code in the video. Code belongs in the documentation and appendices.
Missing the appendix with full source code. Caps you below full marks for techniques regardless of what the documentation says.
Techniques that do not match what the algorithms need. Using a HashMap when an array would do, or writing a bubble sort when a standard-library sort would be clearer, signals poor technique choice.
Testing strategy reported only as “all tests passed.” You need to say what the tests revealed (including failures you fixed) and why the strategy gave confidence in the product.

Where this criterion most often loses marks

Effectiveness of testing stated generically. Even strong IAs often drop here because the effectiveness is asserted (“the strategy was effective”) without specifics. Say what the tests revealed.
Code without comments. Excerpts in the documentation that do not annotate non-trivial blocks make it impossible to evaluate the technique choices, which caps the techniques strand below the top band.
Implementation choices “outlined” rather than “evaluated”. The single most common pull-down in this strand for otherwise strong IAs. See the command-term ladder above.
Configuration or data files maintained “outside” the product. A JSON config, a CSV of seed data, a separate questions file: anything the user has to edit by hand counts against “fully integrated” and drops functionality from “full” to “partial”.
Functionality demonstrated only for some SC. If your product supports search but the video only shows search-by-brand, the strand is “partial functionality”. The video is the evidence.
Inefficient techniques that work but don’t hold up to scrutiny. Retyping a full record to change one field, or reloading the whole file every keystroke, still count as appropriate techniques, but the implementation-choices strand suffers because the choice is hard to defend.