01 / Foundations

IB Computer Science Internal Assessment: Complete Guide

The IB Computer Science Internal Assessment is a significant piece of work. It gives you the chance to design, develop, and evaluate a software solution to a problem you care about.

If you are a student, you might feel anxious about this. That is normal. The IA can feel overwhelming. You might worry about choosing the right topic. You might wonder how to structure your work to meet all five criteria. You might ask yourself: “Is my idea good enough?” or “What if I cannot get my code to work?”

Let me reassure you. These are exactly the questions I hear from students every year. I have guided students through this process. I know where they struggle. I know what examiners are looking for.

Let me break down everything you need to know.

The IA accounts for 30% of your final grade at Standard Level and 20% at Higher Level. You have 35 hours allocated to complete it. The written documentation has a maximum of 2,000 words. You also need to submit a video of no more than 5 minutes demonstrating your solution in action.

The good news? You no longer need a client. The IB requires you to choose a real-world problem of your own choosing that can be addressed through a computational solution. This gives you freedom to explore a real-world problem that genuinely interests you, provided it can be solved computationally.

Let us start with the big picture.

03 / Criterion A

Criterion A: Problem Specification – Setting the Foundation

This is worth 4 marks. It is the foundation of your entire IA. I have seen students lose marks here because they rush through it. They want to start coding. That is a mistake. If your problem specification is weak, the rest of your IA will suffer.

What Examiners Look For

Examiners want to see three things:

• A suitable problem scenario that clearly identifies the issue
• Appropriate success criteria that can be tested
• A clear explanation of the computational context for the solution

The Problem Scenario

Start by describing the situation. What is the problem? Who does it affect? Why does it need a solution?

Here is something I have learned from marking IAs. Students who do well in this criterion are clear and specific. They do not write vague generalisations. They describe the problem in concrete terms.

Let me give you an example from a real student. She wanted to build a system for booking library study rooms. Here is how she described the problem:

“Students at my school frequently struggle to book study rooms. They walk to the library, find all rooms occupied, and waste time. There is no way to check availability from their phones. Staff spend time managing bookings on a paper sheet. This leads to frustration and wasted time for everyone involved.”

That is a good problem scenario. It is specific. It identifies real people who are affected. It explains why the current situation is unsatisfactory.

A weak version would be: “Students need better access to study rooms.” That is too vague. It does not explain who is affected or why it matters.

Here is another example from a student who built a system to help a small business track inventory:

“Jackson’s Hardware Store manages stock manually. Staff write down deliveries on paper. They update spreadsheets every Friday. Stockouts happen regularly because the manual process is slow and error-prone. Customers leave when items are unavailable. Staff spend hours counting stock instead of helping customers.”

Again, this is specific. It names the business. It explains the current process. It identifies the problems: stockouts, slow process, wasted time.

The Computational Context

Explain why computing is the right tool to solve this problem. What makes this a computational problem? What data needs to be processed? What algorithms might be useful?

For the library booking system, the student wrote:

“This is a computational problem because multiple users need to view and book rooms simultaneously. The system must manage concurrent booking requests to prevent double bookings. It must process real-time availability data. It must store and retrieve booking records efficiently.”

For the inventory system, the student wrote:

“This is a computational problem because it involves managing relationships between products, suppliers, and sales data. The system needs to track stock levels, generate reorder alerts, and process sales transactions consistently.”

This is your chance to show the examiner you understand the computational nature of your chosen problem. Do not just say “a computer would be good for this.” Explain specifically what computational processes are involved.

Success Criteria – The Most Important Part

This is one of the most important parts of your IA. Success criteria are measurable goals for your solution. They should be specific and testable.

Here is the same student’s success criteria for her library booking system:

• “The system will show real-time availability of study rooms within 3 seconds of loading the page.”
• “Users can book a room and receive a confirmation within 30 seconds.”
• “The system will prevent two users from booking the same room at the same time.”
• “A staff member can view and cancel bookings in under 1 minute.”
• “The system will send a reminder email to users 1 hour before their booking.”

Notice how each one is specific and measurable. That is what examiners want to see.

A weak version would be: “The system will be easy to use” or “The system will work well.” Those are not measurable.

How Many Success Criteria?

You should include enough success criteria to show that your solution addresses the problem meaningfully. In my experience, most students find that between 4 and 6 criteria gives them enough scope to demonstrate functionality without being excessive. The key is quality over quantity – each criterion should be meaningful and testable.

What Makes a Success Criteria Strong vs Weak?

Here is a comparison that might help.

Weak: “The system will be user-friendly.”

Strong: “A first-time user can complete a booking without assistance in under 60 seconds.”

Weak: “The system will work with many users.”

Strong: “The system will handle up to 20 concurrent users without a delay exceeding 1 second.”

Weak: “The system will store data securely.”

Strong: “User passwords will be encrypted using SHA-256, and no plaintext passwords will be stored in the database.”

Do you see the difference? The strong versions are specific. They tell the examiner exactly what you mean. They can be tested objectively.

What Examiners Are Actually Looking For

Here is what distinguishes a weak Criterion A from a strong one in practice.

Weak Criterion A: The problem is described in very general terms. The success criteria are vague or not measurable. The computational context is not explained.

Example: “Students need a better way to book rooms. The system will be fast and easy to use.”

Strong Criterion A: The problem is described with specific details. The success criteria are measurable and testable. The computational context is clearly explained.

Example: The library booking example above.

The difference is specificity. Examiners cannot give marks for good intentions. They need to see concrete details.

What Makes a Success Criterion “Appropriate”?

This is a question I hear often. What does “appropriate” mean in the context of success criteria?

In my experience, appropriate success criteria tend to have certain characteristics. They are usually relevant to solving the problem. They are achievable within the time available. They are testable with available resources. They are clear and unambiguous.

These are practical considerations rather than formal IB requirements. The key point is that your success criteria should be realistic and testable.

How to Decide If Your Topic Is Suitable

This is one of the hardest decisions students face. Here is a simple test you can use as a screening method.

Ask yourself:

• Does this problem actually exist? (Is it a real problem?)
• Can I explain and demonstrate a solution clearly? (Will the examiner understand it?)
• Can I implement this in 35 hours? (Is the scope realistic?)
• Can I write 2,000 words about this? (Is there enough to explain?)

If you answer “no” to several of these questions, it may be worth reconsidering your topic or adjusting your approach.

Common Mistakes I See

Let me share the mistakes I see most often:

• A problem description that is too vague. For example, “Students need better study tools.” What does that mean? How will you test it?
• Success criteria that are not measurable. For example, “The system will be fast.” How fast? 1 second? 10 seconds? Without a specific number, this cannot be tested.
• Success criteria that are too easy. For example, “The system will have a login page.” That is a feature, not a criterion. It is too trivial.
• Success criteria that are too hard. For example, “The system will predict student attendance with 99% accuracy.” Are you sure you can achieve this? Be realistic.
• A weak explanation of computational context. For example, saying “a computer can solve this” without explaining what processing is involved.

What to Include

• A clear, specific problem scenario with evidence of who is affected
• Measurable success criteria that are specific, testable, and realistic
• An explanation of the computational context

04 / Criterion B

Criterion B: Planning – Structuring Your Approach

This is worth 4 marks. It focuses on how you planned your solution. Some students skip this section or treat it as a formality. That is a mistake. Your plan shows the examiner that you can manage a project systematically.

What Examiners Look For

Examiners want to see:

• A decomposition of the problem into manageable parts
• A plan for developing the solution that addresses the requirements of the solution in terms of the success criteria
• A clear plan showing how you will develop and test your computational solution in relation to the success criteria

Decomposition of the Problem

Break down your problem into smaller parts. Show the examiner you understand the structure of your solution. What are the main components? How do they fit together?

Let me use the library booking system example again.

The student decomposed her problem like this:

• User authentication: Login, register, logout
• Room management: View rooms, check availability, book a room, cancel a booking
• Notification system: Send email reminders, send booking confirmations
• Admin functions: View all bookings, cancel any booking, view statistics

Each component is clear. Each component has a specific purpose. This shows the examiner that the student understands the scope of her project.

For the inventory system, the decomposition looked like this:

• Product management: Add, edit, delete products
• Stock tracking: Update stock levels, low stock alerts
• Sales processing: Record sales, update inventory automatically
• Reporting: Generate sales reports, stock reports

Notice how each decomposition follows the same pattern: the system is split into logical, self-contained components.

How to Approach Decomposition

If you are unsure how to decompose your problem, one approach is to think about the user journey. What does a user do with your system?

For the library booking system, the user journey might be:

• User logs in
• User views available rooms
• User books a room
• User receives confirmation

Thinking about the user journey can help you identify what components your system needs. This is one possible method, not the only method.

Planning Your Development

You need a plan that shows what you will do and when. This could take different forms. Some students use a timeline. Others use a task list. The format does not matter as much as the content.

Your plan should show:

• What tasks you need to complete
• In what order you will complete them
• Roughly how long each task will take

Here is a simple example from the inventory system student:

Week 1: Set up database and basic structure
Week 2: Implement product management (add, edit, delete)
Week 3: Implement stock tracking and low stock alerts
Week 4: Implement sales processing
Week 5: Implement reporting
Week 6: Testing and refinement
Week 7: Documentation

This plan is simple but effective. It shows the examiner that the student thought about the sequence of tasks.

A Test Plan

Your test plan should connect to your success criteria. Consider how you will test each one.

For the library booking system, here is how one success criterion was tested:

Success Criterion: “The system will show real-time availability of study rooms within 3 seconds of loading the page.”

Test: Open the booking page 20 times. Measure the time from clicking the page to room availability being displayed. Record each measurement. If all 20 loads are under 3 seconds, the criterion is met.

Notice how this test is objective. There is a clear pass/fail condition. That is what examiners want to see.

Here is another example from the inventory system:

Success Criterion: “The system will alert staff when stock drops below 5 units.”

Test: Reduce stock of a product to 4 units. Check if the system generates an alert. Repeat with stock levels of 5, 4, 3, 2, 1, and 0. Record which levels trigger alerts.

This test is also objective. It tests the system under different conditions.

What Examiners Are Actually Looking For

Here is what distinguishes a weak Criterion B from a strong one.

Weak Criterion B: The decomposition is incomplete or unclear. The plan is missing or vague. The test plan is not linked to success criteria.

Strong Criterion B: The decomposition is thorough and clear. The plan shows realistic sequencing. The test plan is clearly connected to the success criteria.

The difference is clarity and completeness. Examiners need to see the logic behind your planning.

How to Know If Your Plan Is Good Enough

Ask yourself: Could someone else take my plan and build what I am describing? If yes, your plan is detailed enough. If no, you need more detail.

Common Mistakes I See

• Decomposition that is too vague. For example, “I will build the frontend and backend.” That is not a decomposition. You need specific components.
• A test plan that does not connect to the success criteria. For example, you have success criteria but you test completely different things.
• No evidence of planning. For example, a plan that is one sentence long.
• A plan that does not consider dependencies. For example, planning to test before the code is written.

What to Include

• A clear decomposition of the problem into components
• A plan showing tasks and timeline
• A clear plan showing how you will develop and test your computational solution in relation to the success criteria

05 / Criterion C

Criterion C: System Overview – Designing Your Solution

This is worth 6 marks. It focuses on the design and strategy behind your solution. Examiners want to see evidence of thoughtful design before you start coding.

What Examiners Look For

Examiners want to see:

• A system model that clearly explains how the solution works
• Clear algorithms and data structures that have been chosen appropriately
• A testing strategy that aligns with the success criteria and explains how the solution will be tested

System Model

Provide an overview diagram showing how your solution is structured. The exact type of diagram you choose will depend on your project. A system flowchart, architecture diagram, or class diagram may be appropriate.

The goal is to help the examiner understand how the components fit together.

For the library booking system, the student created a system diagram showing:

• A frontend (web interface) connected to
• A backend (application server) connected to
• A database

The diagram showed arrows between each component explaining the flow of data.

For the inventory system, the student created:

• A class diagram showing the relationships between Product, Stock, and Sale
• A flowchart showing the process of a sale from start to finish

Different projects need different types of diagrams. Choose what makes sense for your solution.

Algorithms

Explain the key algorithms in your solution. You do not need to explain every line of code. Focus on the most important parts.

Here is my advice. Show the examiner why you chose specific algorithms and data structures. What were the alternatives? Why is your choice appropriate?

Let me give you an example. For the library booking system, the student needed to prevent double bookings. She could have used a simple approach where she checked availability when a user requested a booking. But she was concerned about concurrency. What if two users clicked “book” at the same time?

She chose to use a database transaction with a locking mechanism. She explained: “I chose to use transactions because they handle concurrency issues. When a user attempts to book a room, the transaction checks availability. If the room is available, it reserves it. This prevents double bookings even if two users request the same room simultaneously.”

That is a good explanation. It shows why a specific approach was chosen. It shows understanding of the problem.

For a different project type – say, a sorting algorithm for a list of student grades – the explanation might be: “I chose Quicksort because it has O(n log n) average-case complexity. This is appropriate for the expected data size of 200-300 records. Alternatives like Bubble Sort would be O(n²) and would perform poorly.”

Again, the explanation shows reasoning.

Data Structures

Explain what data structures you used and why.

For the library booking system:

“The data is stored in a MySQL database with three tables: users, rooms, and bookings. The bookings table links users to rooms with a timestamp. This allows me to query availability efficiently. The database schema is normalised to third normal form to avoid data redundancy.”

For a project without a database, the explanation might be:

“I used Python dictionaries to store user profiles. This provides O(1) lookup time, which is important because the system needs to find users quickly during login.”

The key is to explain why the data structure is appropriate.

Testing Strategy

You need a testing strategy that aligns with the success criteria and explains how the solution will be tested.

Let me explain what this means with examples.

Correctness Testing

This is the most basic type of testing. You give the system expected inputs and check that it produces expected outputs.

For the library booking system, a correctness test might be: “User A requests to book room 101 for Tuesday at 2pm. The system confirms the booking and adds it to the database. User B requests the same room at the same time. The system notifies User B that the room is not available.”

This tests that the system works correctly under normal conditions.

Reliability Testing

This tests how the system handles unexpected situations. What happens when a user enters invalid data? What happens when the database is slow? What happens when two users attempt the same action simultaneously?

For the library booking system, a reliability test might be: “User attempts to book a room for a time outside the opening hours. The system displays an error message and prevents the booking.”

Another reliability test might be: “User attempts to book a room without logging in. The system redirects to the login page.”

Efficiency Testing

This tests how well the system performs under different conditions. Does the system respond quickly when many users are active? Does the database handle concurrent requests well?

For the library booking system, an efficiency test might be: “10 users simultaneously request availability information. The system responds to all users within 2 seconds.”

Different Project Types, Different Testing

A web application might focus on response times and concurrent users. A desktop application might focus on memory usage. A mobile app might focus on battery consumption and network usage.

Think about what matters for your specific project. That is what you should test.

What Examiners Are Actually Looking For

Here is what distinguishes weak, adequate, and strong work in Criterion C.

Weak Criterion C: The system model is unclear. Algorithms are not explained. Testing is vague or missing.

Adequate Criterion C: The system model is clear. Algorithms are explained but without reasoning. Testing covers the basics.

Strong Criterion C: The system model is clear and detailed. Algorithms are explained with reasoning. The testing strategy is clearly explained and aligned with the success criteria.

What “Appropriate” Means for Algorithms and Data Structures

“Appropriate” in this context means:

• The algorithm/data structure is suitable for the problem
• The algorithm/data structure is efficient enough for the expected data
• The student can explain why it is suitable

If you choose a complex algorithm but cannot explain it, that is a problem. If you choose a simple algorithm but it works, that is fine. Simplicity with explanation is better than complexity without.

Common Mistakes I See

• System model that is unclear or poorly labelled. For example, using arrows without explaining what they represent.
• Algorithm explanations that are too brief. For example, “I used a sorting algorithm” without explaining which one or why.
• Testing strategy that is vague. For example, “I tested the system” without explaining what was tested or how.
• No connection between testing and success criteria. For example, testing features that are not in the success criteria.
• Choosing a complex algorithm without being able to explain it.

What to Include

• A system model with clear labels and explanations
• Algorithm explanations with reasoning for choices
• A testing strategy that aligns with the success criteria and explains how the solution will be tested

06 / Criterion D

Criterion D: Development – Building Your Solution

This is worth 12 marks. It is the largest criterion and carries the most weight. This is where the examiner sees what you actually built and how you built it.

What Examiners Look For

Examiners want to see:

• A fully functional product that meets the success criteria
• A clear justification of the product structure and techniques used
• Evidence of appropriate implementation choices
• Evidence of an effective testing strategy

Justifying Your Product Structure

This is where you explain how your solution is structured. What choices did you make? Why did you make them?

I often tell students: “Do not just show what you built. Show why you built it that way.”

Let me give you an example. A student built a library booking system using a web-based frontend with a SQL database. He justified his choice like this:

“I chose to build the system as a web application because students and staff need access from different devices. I used SQL for the database because the data structure is well-defined. I chose Python Flask for the backend because it is lightweight and well-suited for this type of application.”

That is a good justification. It explains the choices and provides reasoning.

Different projects justify different choices. A game might be justified by graphics capabilities. A mobile app might be justified by portability. The key is that the justification is specific to the project.

Implementation Choices

What algorithms and data structures did you use? Why were they appropriate? How did you implement them?

Here is an example from a student who built an inventory system:

“I used a MySQL database with three tables: products, suppliers, and sales. I chose this because inventory management requires maintaining relationships between these entities. I used SQL queries to track stock levels and generate reorder alerts.”

Another example from a student who built a game:

“I used Pygame for the graphics because it provides the rendering capabilities I need. I used a 2D array to represent the game board because it allows O(1) access to any position.”

The key is to show technical understanding. The examiner wants to know that you understand the technologies you are using.

How to Demonstrate Technical Decisions

Here is what I recommend. Identify several key technical decisions in your project. For each one:

• State what you chose
• Explain why you chose it
• Explain what alternative you considered
• Explain why the alternative was not chosen

This structure shows deep thinking. It shows the examiner you made deliberate choices, not random ones.

Testing Effectiveness

Show how you tested your solution. What did you test? What did you find? How did you address any issues?

Your testing should provide evidence that your solution works.

Let me give you an example of strong testing evidence from a student. She tested the booking feature and found a bug. She wrote:

“I tested the booking feature with two users attempting to book the same room simultaneously. Initially, the system allowed both bookings. I realised this was a concurrency issue. I fixed it by implementing a database transaction with row-level locking. After the fix, both users attempted to book simultaneously. The first booking succeeded. The second user received a notification that the room was not available.”

This is excellent evidence. It shows testing. It shows a problem was found. It shows the problem was fixed. The examiner can see the development process.

What Makes Strong Development Work?

Here is what distinguishes weak, adequate, and strong development work.

Weak Criterion D: The product does not fully work. There is little explanation of choices. Testing is minimal or absent.

Adequate Criterion D: The product works. There is some explanation of choices. Testing is present but basic.

Strong Criterion D: The product works fully. Choices are explained with reasoning. Testing is thorough and linked to success criteria.

What “Effective” Means for Testing Strategy

“Effective” in this context means:

• The testing shows evidence of careful planning
• The testing results show that the solution works
• The testing addresses the key aspects of the solution

If your testing is just “I tested it and it worked,” that is not effective. You need specific evidence.

The Video

Your video provides evidence of functionality and examples of your testing strategy. It should be no more than 5 minutes.

What to include in your video:

• A brief overview of the product
• A demonstration of full functionality
• Examples of the testing strategy you used

I have seen excellent IAs lose marks because the video was rushed. Practice before recording.

What If Your Product Is Not Fully Functional?

This is a question I hear from students often. What if you cannot get it working perfectly?

Here is the honest answer. Your product should be fully functional. But examiners understand that projects sometimes have issues. The key is honesty.

If a feature is not working as intended, be honest about it in your documentation. Explain what you tried. Explain what went wrong. Explain what you would do differently.

I have seen students lose more marks by hiding issues than by being honest about them. Candid evaluation tends to be viewed favourably when accompanied by thoughtful reflection on what was learned.

Common Mistakes I See

• Dumping entire code without explanation. The examiner does not need to see every line of code. They need to see the most important parts with explanations.
• No justification for implementation choices. For example, “I used this framework” without explaining why.
• Testing that is not clearly linked to the success criteria. For example, testing features that are not in the success criteria.
• Video that does not clearly demonstrate functionality. For example, the video is too fast, or the features are not shown clearly.
• Choosing technologies that are too complex without being able to justify them.

What to Include

• Evidence of a fully functional product
• Justification for product structure and techniques
• Explanation of implementation choices
• Evidence of testing effectiveness
• A video of no more than 5 minutes showing functionality and testing

07 / Criterion E

Criterion E: Evaluation – Reflecting on Your Solution

This is worth 4 marks. It focuses on reflection. Some students think of this as an afterthought. They rush through it. That is a mistake. The evaluation is your chance to show the examiner that you can think critically about your own work.

What Examiners Look For

Examiners want to see:

• Honest evaluation against the success criteria
• Discussion of limitations and how they could be addressed
• Realistic recommendations for improvement

Evaluate Success Criteria

Go through each success criterion. Did you meet it? Why or why not?

Let me be honest with you. Some students try to hide their failures. That is a mistake. Candid evaluation with thoughtful reflection is generally viewed favourably. If a criterion was not fully met, explain why. Show what you learned.

Here is an example from a student’s evaluation. She had a success criterion about speed. She wrote:

“I set a success criterion that the system would respond within 3 seconds. In testing, the average response time was 4.2 seconds. I did not fully meet this criterion because my initial database query was inefficient. I attempted to optimise it by adding indexes. This improved speed to 3.5 seconds but still not 3 seconds. If I had more time, I would rewrite the query to use a more efficient approach.”

This is an excellent evaluation. It is honest. It explains why the criterion was not met. It explains what was tried. It explains what would be done differently.

Discuss Limitations

Every solution has limitations. Acknowledging them shows maturity.

Questions to consider:

• What does not work perfectly?
• What would you do differently next time?
• What were the biggest challenges you faced?

For the library booking system, the student wrote:

“The system does not handle booking cancellations automatically. Users must contact staff to cancel. This is a limitation because it adds extra work for staff. In the future, I would add a self-cancellation feature.”

For the inventory system, the student wrote:

“The reporting feature is limited to sales reports. Stock reports are not included. This is a limitation because staff cannot track stock trends over time. In the future, I would add stock reports.”

Recommend Improvements

Think about the future. If you had more time, what would you add or change?

Make your recommendations realistic and specific. “I would add more features” is too vague. “I would implement user authentication to improve security” is better.

Here is a good recommendation:

“In the future, I would add a feature that allows users to view booking history. This would help users track their bookings and avoid duplicate bookings.”

What Examiners Are Actually Looking For

Here is what distinguishes weak, adequate, and strong evaluation.

Weak Criterion E: The evaluation is superficial. It says everything is good. It does not mention limitations. Recommendations are vague.

Adequate Criterion E: The evaluation covers the success criteria. Some limitations are mentioned. Recommendations are basic.

Strong Criterion E: The evaluation is honest and critical. Limitations are acknowledged and explained. Recommendations are specific and realistic.

The difference is depth. Examiners want to see that you can think critically about your own work.

What Makes a Recommendation “Realistic”?

A realistic recommendation is one that is achievable and addresses a real limitation. It would actually improve the solution. It is specific enough to act on.

If you recommend “implementing artificial intelligence” to solve a problem, consider whether that is actually feasible given the constraints of the project. In some cases it might be realistic; in others, not. The key is to consider what is actually achievable.

Common Mistakes I See

• Superficial reflection. For example, “I met all success criteria” without providing evidence.
• Only listing strengths without acknowledging weaknesses.
• Recommendations that are vague or unrealistic. For example, “I would add more features.”
• Failing to reference success criteria in the evaluation. For example, evaluating the product but not comparing it to the success criteria.
• Not explaining what was learned from the process.

What to Include

• Evaluation against each success criterion
• Honest discussion of limitations
• Realistic recommendations for improvement

08 / Common Mistakes

Common Mistakes That Cost Marks

Here are the most common mistakes I have seen students make over the years.

Mistake 1: Vague problem description
Why It Hurts: Examiners cannot understand the real issue. They cannot see why a solution is needed.
How to Avoid: Be clear and specific about the problem. Who is affected? What is the current situation? Why is it unsatisfactory?

Mistake 2: Poor success criteria
Why It Hurts: Success criteria that are not measurable cannot be tested. Examiners cannot verify if they were met.
How to Avoid: Make each criterion specific and measurable. Consider using numbers where appropriate, but not all criteria need numerical thresholds.

Mistake 3: Weak computational context
Why It Hurts: Does not show why computing is appropriate. Examiners may wonder why this is a computational solution.
How to Avoid: Clearly explain the computational nature of the problem. What data is processed? What algorithms are used?

Mistake 4: Incomplete testing
Why It Hurts: Insufficient evidence that the solution works as intended.
How to Avoid: Test for correctness, reliability, and efficiency. Document your testing.

Mistake 5: Code dumping
Why It Hurts: No evidence of thinking. Examiners cannot see the reasoning behind the code.
How to Avoid: Explain your implementation choices and techniques. Show only the most important code.

Mistake 6: Superficial evaluation
Why It Hurts: Misses opportunity for reflection. Examiners cannot see if you learned from the project.
How to Avoid: Be honest about limitations and lessons. Evaluate against your success criteria.

Mistake 7: Overly ambitious project
Why It Hurts: Cannot complete on time. The product is incomplete. The documentation is rushed.
How to Avoid: Choose a realistic scope. Start simple. Build from there.

Mistake 8: Poor documentation
Why It Hurts: Examiner cannot follow your thinking. The reasoning is not clear.
How to Avoid: Document as you go, not at the end. Explain your decisions.

Mistake 9: Video too long or unclear
Why It Hurts: Examiner cannot verify functionality. The features are not shown clearly.
How to Avoid: Practice. Keep it to no more than 5 minutes. Show functionality clearly. Show testing.

Mistake 10: Inconsistent criteria
Why It Hurts: The five criteria do not align. What was planned in Criterion A is not delivered in Criterion D.
How to Avoid: Check consistency. Does your product match your success criteria? Does your evaluation reference your success criteria?

09 / Submission

Word Count, Format & Submission

Understanding the word count rules is essential. Many students lose marks because they misunderstand what counts.

Word Count Rules

• Maximum 2,000 words for the written documentation
• Code excerpts, comments, and diagrams are excluded from the word count
• Extended writing such as explanations within tables is counted

What Counts Toward the Word Limit?

Counts: Written explanations, analysis, evaluation, descriptions

Does Not Count: Code excerpts, comments, diagrams

Submission Requirements

• Written documentation – single PDF document
• Appendices – a single PDF including the full source code and other resources developed by the student that are referred to in the documentation
• Video – no more than 5 minutes demonstrating functionality
• The product itself is part of the assessed solution, while the documentation, video and appendices have specified submission requirements

SL vs HL Differences

• IA weighting: SL 30%, HL 20%
• Criteria: Same five criteria for both SL and HL
• Word count: 2,000 words for both
• Video: no more than 5 minutes for both

10 / Checklist

Final IA Submission Checklist

Criterion A – Problem Specification

• Problem scenario is clearly described with specific details
• Success criteria are measurable and testable
• Computational context is explained with specific reasoning

Criterion B – Planning

• Problem is decomposed into manageable parts with clear components
• Plan for solution development is clear with tasks and timeline
• A clear plan showing how you will develop and test your computational solution in relation to the success criteria

Criterion C – System Overview

• System model explains how the solution works with clear labels
• Key algorithms are explained with reasoning
• A testing strategy that aligns with the success criteria and explains how the solution will be tested

Criterion D – Development

• Product is fully functional
• Product structure is justified with reasoning
• Implementation choices are explained with technical depth
• Testing effectiveness is demonstrated with evidence
• Video (no more than 5 minutes) shows functionality and testing

Criterion E – Evaluation

• Success criteria are evaluated honestly with specific evidence
• Limitations are discussed honestly
• Recommendations for improvement are realistic and specific

Submission Format

• Written documentation is a single PDF
• Word count is within 2,000 words
• Code excerpts, comments, and diagrams are excluded from word count
• Appendices are a single PDF including full source code and other resources developed
• Video is no more than 5 minutes

11 / Final Thoughts

Final Thoughts

The IB Computer Science IA is a significant project. It requires planning, coding, testing, and reflection. It can feel overwhelming at times.

Here is what I want you to remember.

You need to build something that works, that meets clear success criteria, and that you can explain clearly. But the assessment also considers your system overview, algorithms, techniques, implementation choices, testing effectiveness, and evaluation across Criteria A–E.

I have seen students succeed with simple projects that were well-documented. I have seen students struggle with ambitious projects that were poorly explained. Documentation clarity is important, as is the quality and suitability of the computational solution.

Start early. I cannot stress this enough. Document as you go. Do not leave it to the end. Test thoroughly. Be honest in your evaluation.

The IA is not just about the code. It is also about demonstrating the computational thinking process, algorithmic thinking and programming skills that underpin your solution. You can identify a problem, plan a solution, build it, test it, and evaluate what you created against your success criteria.

IA requirements can feel daunting, but they are also an opportunity. You have the chance to work on something you genuinely care about.

Focus on the process. Trust the structure. And if you need help, find someone who understands the requirements.

For more resources and personalised guidance, visit IB Computer Science Tutor.