IA · Book pp. 494–536
Internal assessment
You choose a problem, build software to solve it, and show your thinking. Marks go to that thinking, as well as to the product.
The big picture
The IA is marked by your teacher, then moderated by the IB. It is 30% of your grade at SL and 20% at HL, with about 35 hours of class time. SL and HL use the same criteria.
| Criterion | Title | Marks | Words |
|---|---|---|---|
| A | Problem specification | 4 | 300 |
| B | Planning | 4 | 150 |
| C | System overview | 6 | 150 |
| D | Development | 12 | 1000 |
| E | Evaluation | 4 | 400 |
What you submit
- Documentation: one PDF, with a section per criterion and the word count on the cover. At most 2,000 words, not counting code, comments or diagrams.
- Video: at most 5 minutes (MP4, AVI or WMV), showing functionality and examples of testing.
- Appendices: one PDF with your full source code. Without it, you cannot get full marks for the techniques in criterion D.
Choosing a problem
This is your most important decision, so talk to your teacher first. You can use any language and any topic in computing. Criterion D rewards algorithms and data structures, so look for a problem that really needs them.
- Aim for 80% sure. At 100%, the problem is probably too simple. At 50%, there are too many unknowns.
- Complex is not the same as large. Ten similar screens show nothing that two do not.
- Learn something new. The best products usually go a little beyond the syllabus, but keep it natural. A forced algorithm will not help.
- Do not neglect the writing. Brilliant code with weak documentation scores low.
Ideas to adapt
| Idea | Where the thinking is |
|---|---|
| Timetable clash finder | Sets and graph colouring |
| Sports tournament scheduler | Round-robin generation, and a database of results |
| Vocabulary trainer that spaces out revision | Priority queue, and a spaced-repetition algorithm |
| School bus route optimizer | Graph search and route optimization |
| Canteen queue simulator | Queues, random arrivals and measured waiting times |
| Plagiarism hint tool for code | Tokenizing, and a text-similarity measure |
These are starting points. Yours should solve a real problem that you can describe, with something that sets it apart.
Products that will not work
- Copied code, or a copied game without major, documented changes.
- A website built on a template, such as WordPress or Wix.
- Sample databases or templates that come with software.
- Apps made with wizards or drag-and-drop builders, with no real code.
- Anything that breaks the ethical requirements.
- Mostly interface with little logic, or one huge class.
Criterion A: Problem specification (4 marks, 300 words)
Everything later builds on this. To reach the top band, describe the problem through measurable requirements, state appropriate success criteria, and explain your choice of computational context.
- Problem scenario: what is wrong now, who is affected, why do existing solutions fall short, and what limits apply?
- Success criteria: usually 8 to 10. They are measurable, testable, achievable and about features.
- Computational context: what you will use, and why, compared with alternatives.
| Context | Think about |
|---|---|
| Language | Which language, why, and what are its weaknesses? |
| Software | Operating system, libraries and frameworks |
| Hardware | Any devices or infrastructure |
| Data | Format, structure, size, source, and any database engine |
| Implementation | Network, security and compatibility conditions |
⚠️ Common mistakes
Leaving out the core functions, or using subjective wording such as “looks good”. You will test and evaluate every criterion later, so write ones you can test.
Criterion B: Planning (4 marks, 150 words)
Two things are assessed: decomposition (breaking the problem into components), and a plan that covers your success criteria.
- Show every success criterion in the decomposition. A structure chart works well.
- Give each component time for planning, designing, developing, testing and evaluating.
- Include time for researching libraries and tools.
- A Gantt chart is a good format, with realistic dates.
⚠️ Common mistakes
- Writing the plan after the product is finished. It is a plan, and not a diary.
- A plan that contradicts your final product.
- Diagrams that break the rules of that diagram type.
- Leaving testing out of a stage.
Criterion C: System overview (6 marks, 150 words)
A third party should be able to rebuild your product from this section. It has three parts: a complete system model, algorithms for the key components, and a testing strategy aligned to your success criteria.
| Diagram | Include |
|---|---|
| User interface design | Always |
| Normalized ERD | If you have a database |
| Data dictionary | If you store data |
| UML class diagram | If you use OOP |
| Flowcharts | For procedural code |
| Component diagram | If you use physical hardware |
| Network diagram | If networking is involved |
Algorithms can be in natural language, flowcharts or pseudocode. You only need the key ones.
Testing strategy
- Functional testing: does each success criterion work from the user’s view?
- Structural testing: do the major algorithms and error paths work inside?
| Type | Meaning | If the limit is 5 MB |
|---|---|---|
| Valid | Normal data the program should accept | An 800 KB PNG |
| Extreme | Data at the very edge of what is allowed | A file of exactly 5 MB, the limit |
| Invalid | Data the program should reject | A 6 MB file, or a .docx |
Validate all input, with presence, length, type and format checks.
✏️ Book corrections
- Its example lists a file over the size limit as extreme data. That is invalid data. Extreme data is at the edge of what is allowed.
- Its A* tests say unit testing “should fail” for invalid input. A good test passes when the function correctly rejects bad input. A failing test means there is a bug.
⚠️ Common mistakes
Pseudocode hundreds of lines long, variables like person1 and person2 that should be an array, and tests such as “does not crash” that check nothing specific.
Criterion D: Development (12 marks, 1,000 words)
This is the largest criterion. The top band asks for a fully functional product, appropriate techniques, and for you to evaluate your choices and justify your testing.
The document
- Use subheadings based on your success criteria, and not the story of how you built it.
- Choose your five to seven most advanced techniques.
- For each, show a commented code excerpt with line numbers, referenced to your appendix.
- Explain why: compare it with a real alternative, and give your reason.
- Show test results, using your criterion C tables with a results column, across valid, extreme and invalid data.
- Say how complete your testing was, and why the strategy suited the product.
See a weak and a strong justification
Weak: “I used a dictionary because it is good for storing data.”
Strong: “Each lookup uses the student ID, so a dictionary gives O(1) average access. A sorted list with binary search would be O(log n), and would need re-sorting on every insert. I do not need ordered output, so the dictionary’s lack of order does not matter.”
The video
- One run-through of the product, then examples of testing.
- Show every success criterion, including bad input.
- Show internal changes too. After Save, open the database and show the new row.
- Do not explain code here.
⚠️ Common mistakes
Explaining what the code does, but not why it was chosen. And submitting one file of thousands of lines, as your code is part of this criterion.
Criterion E: Evaluation (4 marks, 400 words)
For the top band, evaluate how far each criterion was met, and justify your improvements.
- Use a table with every success criterion, and decide: met, partly met or not met.
- Use your test results as evidence, and weigh strengths against limits.
- Improvements should be specific, say how they would work, and say which issue they solve.
The book’s examples use client quotes from the old syllabus. No client is needed now, so refer to your testing instead.
Weak improvements
- More colours, more data or more functions, with no specific reason
- Finishing a success criterion you did not meet
- Adding a GUI to a command-line program
- Adding something essential that was missing, such as saving data
See a weak and a strong evaluation
Weak: “This criterion was met, and I had no bugs.”
Strong: “Partly met. All 40 valid routes were found within 10 seconds (tests 4 to 7), but one with 15 stops took 14 seconds on a slow network (test 8). So it fails for the largest inputs. Caching the distance data would remove the repeated requests that caused the delay.”
Academic integrity and ethics
Your teacher must confirm that the work is yours. Your school’s policy comes first, so read it.
- Code from elsewhere: add a comment where it is used, and a full reference in your bibliography.
- AI tools: the IB does not ban them, but it does not count what they produce as your work. Credit the tool in the text and bibliography, including your prompt and the date.
- Understanding: if AI improved your code, document this, and discuss and justify the changes.
Example of a citation in code
# Adapted from "Binary search", Python documentation, bisect module
# Retrieved 2 November 2026Ethical rules
- Get consent from anyone involved, before you start.
- Get written consent from the owner of any existing system you use.
- Store collected data securely, and keep it confidential.
- Use the data only for this project, unless you have explicit permission.
- Use original data where you can.
Quick quiz
Final checklist
- Every success criterion appears in A, B, C, D and E.
- The word count is on the cover, and is 2,000 or fewer.
- The video is under 5 minutes, and shows testing with bad input.
- The appendix has your full source code.
- All outside code and AI use is cited.