IB Computer Science HL · Internal Assessment

Computational Solution Hub

Your IA is one coded computational solution assessed across five connected criteria. For HL it contributes 20% of the final subject result. Use this hub to check that the problem is suitable, the design leads to real algorithms, the testing produces evidence, and the final documentation stays aligned with the success criteria.

Course home 2027 case study

Before Criterion A

First check: is this a suitable computational solution?

2 / 8

A suitable IA problem

The problem genuinely needs a coded software solution, not only a static page, template or drag-and-drop product.

The problem has enough complexity and innovation for me to demonstrate decomposition, algorithmic thinking and programming.

I can explicitly show the algorithms I designed and then coded; copied/tutorial code does not carry the solution.

A feasible IA problem

I have the technical skills, hardware/software access and data needed to finish the product.

My success criteria describe measurable outcomes that can later be tested.

The solution is ambitious enough to solve a real problem but still realistic within the course timeline.

Complexity belongs to the problemDo not add advanced techniques only to look impressive. The techniques should be appropriate for the algorithms and success criteria. A simple-looking technique can be fully appropriate when it solves a meaningful part of a sufficiently complex problem.

Page 2 of 8

Overview

30 marks · five connected criteria

3 / 8

A · 4 marks

Problem specification

Describe measurable solution requirements, state appropriate success criteria, and explain the computational context. Recommended: about 300 words.

B · 4 marks

Planning

Decompose the problem reasonably and construct a plan that addresses the success criteria. Recommended: about 150 words.

C · 6 marks

System overview

Construct a complete system model, algorithms for its components, and a testing strategy aligned with the success criteria. Recommended: about 150 words.

D · 12 marks

Development

Construct a fully functional product using appropriate techniques, explain implementation choices, and describe the effectiveness of the testing strategy. Recommended: about 1,000 words.

E · 4 marks

Evaluation

Evaluate the extent to which the success criteria were met and justify meaningful, feasible improvements. Recommended: about 400 words.

Connection ruleCriterion A’s success criteria should remain visible through B planning, C testing design, D development/testing and E evaluation. Treat the five criteria as one chain rather than five unrelated mini-reports.

Page 3 of 8

Criteria A–C

Design evidence before code becomes the evidence

4 / 8

A — Problem specification

The scenario explains the actual problem and its measurable solution requirements.

Each success criterion is specific enough to test later rather than using words such as “good”, “easy” or “fast” without a measure.

The chosen computational context is explained: why this kind of software solution fits the problem.

B — Planning

The problem is decomposed into essential components/sub-problems.

The plan addresses all success criteria and includes design, development, testing and evaluation.

The plan was created to guide development; it is not a process journal written after the product was finished.

C1 — System model

The system model is the high-level design: components, how they connect, rules governing interaction and the user-interface design. Choose diagrams that fit your product.

A third party with appropriate programming knowledge could understand how the product is organized from my model.

C2 — Algorithms + testing strategy

The algorithms are separate from the system model. Show the important algorithms for individual components using pseudocode, flowcharts or clear structured natural language.

My algorithms are detailed enough to guide coding of the important components.

My testing strategy links to success criteria and major algorithms, including valid, extreme and invalid/unexpected data where appropriate.

Do not merge the three parts of CSystem model ≠ algorithms ≠ testing strategy. They support each other, but each provides different design evidence before/during development.

Page 4 of 8

Criterion D

Show that the algorithms became a working product

5 / 8

Product + implementation

The final product is fully functional against the intended requirements.

Key code excerpts show the techniques that implement important algorithms; excerpts are readable, commented where relevant and referenced to the full source code.

I explain why important implementation choices were appropriate instead of only naming a technique.

Testing that produces evidence

Functional testing: check whether the product meets the success criteria.

Structural testing: check major algorithms with inputs that cover important paths and edge cases.

My tests include valid, extreme and invalid/unexpected data where those categories make sense.

The documentation explains what the testing strategy revealed and why the strategy was effective.

The video shows the product’s full functionality and examples of the testing strategy; the documentation remains the main place where the testing strategy is explained.

Concrete structural-testing exampleIf an algorithm inserts into a sorted list, do not test only a “normal” middle insertion. Consider the empty list, the start, the middle and the end so important branches are actually exercised.

Page 5 of 8

Criterion E + submission

Evaluate with evidence, then package it correctly

6 / 8

E — Evaluation

I evaluate each success criterion using evidence from the completed product and testing rather than simply saying “met/not met”.

My improvements come from real limitations, testing evidence or a justified change in requirements.

Each improvement is specific, meaningful, feasible and justified by the benefit it would bring.

Weak improvement: “Make the interface better.”
Stronger: identify the observed usability problem, describe the change and explain the expected benefit.

Final submission: three files

1. Documentation PDF — five criterion sections; total ≤ 2,000 words; overall word count clearly stated on the first page.

2. Video — ≤ 5 minutes; demonstrates full functionality and examples of testing.

3. Appendices PDF — full source code plus other referenced supporting resources.

The appendices are not where you hide evidence needed for marks; the documentation and video must carry the assessed evidence.

Two important boundariesModerators stop reading after 2,000 words. Also, a missing core requirement is primarily a development gap; do not rely on “I would finish the required feature later” as your strongest Criterion E improvement.

Page 6 of 8

Year 2 course checkpoints

IA runs in parallel with the syllabus

7 / 8

L1–L9

Refine A/B/C. Keep the problem measurable, the plan aligned to success criteria, and the system model/algorithms/testing strategy usable for development.

L10–L32

Criterion D main development. Implement, test and keep an evidence log of important code, decisions and test outcomes.

L33–L39

Wrap D: select code excerpts, explain testing effectiveness, prepare the video and organize the appendix.

L40–L45

Criterion E, final consistency checks, authenticity checks and course submission.

L46–L55

IA is normally complete; homework shifts toward Paper 1, Paper 2 and the 2027 case study.

Evidence habitDuring development, record the reason for an important design/implementation decision and the test that verified it. This is much easier than trying to reconstruct every decision at the end.

Page 7 of 8

Authenticity and final check

Your solution must remain your own work

8 / 8

Academic integrity + AI use

All external information, code, libraries and resources are cited or acknowledged appropriately.

If I used an AI tool—for example to refine code or develop wording/ideas—I acknowledge that use and can identify what I used it for.

The decisions, algorithmic thinking and submitted solution remain my own work, and I can explain the submitted code.

Code excerpts in the documentation point clearly to the full readable source code in the appendix.

Teacher guidance

Discuss feasibility, algorithms, techniques and testing with your teacher while you work. The teacher can guide you but cannot choose the techniques or program the solution for you.

The teacher may read and advise on one draft without editing it for you. After you consider that advice, the next version submitted to the teacher is the final version.

Be ready to explain your code, design choices, testing and source use as part of authenticity checking.

Before final submissionOpen all three files. Confirm documentation ≤2,000 words, video ≤5 minutes, full source code is in the appendix, references are complete, and the product shown in the evidence is the product you are submitting.

Designed by David Xu

Educators and students are welcome to use these materials for non-commercial teaching and learning with attribution. Please share the original link when possible. Reposting, redistributing modified copies, removing attribution, or commercial use requires prior permission.

Page 8 of 8