- 1 Introduction
- 2 Criteria A – Planning
- 3 Criteria B – Design
- 4 Criteria C – Development
- 5 Criteria D – Functionality and extensibility
- 6 Criteria E – Evaluation
The IB Computer Science Internal Assessment is project that that will take approximately 30 hours of you class time, and likely a substantial portion of time outside of class. You will find a client, or adviser if you choose to be your own client, develop a product, and produce an approximately 2000 word report which covers the five criteria listed below.
Before starting on your project, or even before you start brainstorming ideas, you should look over the official guide, my brief overview and the online documentation. Take some time to go over the criteria as well as the examples of past IA submissions. When you look at the past submissions you will notice that many of the grades are lower than what you are likely aiming for. There are better examples of what to aim for that we will go over in class.
Choosing a project
For many students this is the hardest part of the project. It’s recommended that you find a client to work with, though you do have the option of being your own client with an adviser (usually your teacher). No matter which option you choose, you should try to stick to the following guidelines.
- Choose something you’ll enjoy
- Choose something that’s feasible
- Choose something that fits within the time constraints
The mistakes students often make revolve around these three (i.e. “I’m going to create the next Facebook”).
To client or not
Yes, there is a choice of whether to have a client or not. It is preferred that you get one as it makes the direction you take much easier. If you don’t have a client then you will need to consult with your teacher in order to make sure that you’ve laid out appropriate success criteria and are following them.
Criteria A – Planning
Planning is one of the most important parts of the of the project as it lays out the direction your project will take, and more importantly the limitations. The section will be broken into three pieces: the problem, the rationale for your solution, and the success criteria.
This section changes somewhat depending on whether you have a client or not, but both show an evolution of ideas working towards a proposed solution. Most importantly, this section should not be something like, “I really like video games, so I want to make one.” You or your client must have a motivation behind the project. This section is extended writing and generally takes about 250 words or so.
If you have a client this section should cover:
- Who your client is
- Your client’s problem
- What solutions has your client already tried and why are they inadequate
- Evidence of client consultation
- Your proposed solution
- If your adviser has approved
If you don’t have a client this section should cover:
- Your motivation behind the project
- Who your adviser is
- What solutions you have tried previously, or what experience you have
- Evidence of consultation with your adviser
- Your proposed solution
- If your adviser has approved
Rationale for the solution
In this section you will outline why your solution is appropriate for your client and why it’s feasible for you to create. There may be areas where you cannot meet the client’s needs, or your own expectations if you’re your own client, and they should be mentioned. Beyond providing reasons for why your proposal is appropriate you will also need to list the programming language or languages, as well as libraries and tools used. Putting your reasons into bullet points can help you make sense of your ideas.
These the metric by which you will judge the success of your product from the perspective of the client. Essentially, they are a list of the features that the user wants, and should be written in non-technical language. Examples of possible success criteria are:
- A menu at the top showing File, Edit and Help options
- A simple user interface with a 4 by 4 grid of clickable images that lead to their descriptions
- An administrative interface where users can be managed
Success criteria are from the client’s perspective and should not include technical details which will be outlined in the design and development stages.
The success criteria identified in criterion A will be used in criterion D to evaluate the effectiveness of the product.
Criteria B – Design
The design stage of the project is where you will layout how the interface and the underlying code will work. You outline how the user will navigate the project and show how plan to connect different functions, classes, and libraries into your finished product. The difficulty of doing this is raised somewhat by the fact that you can do no extended writing in this stage. Essentially you will be limited to the following:
- Drawings of the interface
- Flowcharts showing program navigation
- Tables listing UI features, functions, classes or libraries
- Short annotations as needed
Yes, you can make annotations, but they must not be explanations. Take a look at the examples below that might be attached to a drawing of a user interface:
- “Button opens window shown in figure 4”
- “Menu calls function described in section 2.1”
- “Menu allows users to select their window settings which are loaded from the settings.txt file.”
The first two examples are fine, while the last would likely be included in extended writing and not be included as part of the grade.
The overall structure of your design stage can follow whatever flow you think works best, but it’s recommended that you move from a top down approach, starting with the user perspective and moving towards that of the programmer. A bottom up approach could also be taken, but that may not be as clear for most IB graders. I’d recommend taking the following approach:
- Overview of the interface
- Details of the interface
- Table listing components of interface and code equivalent
- Flowcharts for the flow of how the user will use the program
- Broad overview of flow from code perspective
- Tables listing code components
- Detailed flowcharts expanding pieces of (5)
Below is an example of what (1) might look like:
Note that each section is labeled for reference later. You could then break out section 1 for example into something like this:
And then later add a flow chart detailing another aspect of the interface:
In addition to the designs themselves you will need to include your record of tasks which is list of the tasks you completed on which days and the time spent on them. The record of tasks document MUST be the one given by the IB. The format absolutely cannot change or you will end up losing a point.
Record of tasks
In order to get even a 1-2 on this section you MUST have your record of tasks, which can be found in the zip file here. The task sheet is quite important, and you should be adding to it as you go, or at least making notes of your progress elsewhere in order to more easily complete it later on.
Criteria C – Development
The primary purpose of this criteria is show evidence of the complexity involved in your project. What exactly is meant by complexity is not explicitly mentioned in the course materials, and is really up to the student to make evident. That means it’s up to you to prove that what you’ve done is complex, and to do that you must adequately explain what you’re doing.
Before we go into what the IB would like to see, there are a few things I’ve seen over the years that you should not do in this section.
- Cut and paste large chunks of code
- Use only extended writing with no diagrams, flowcharts or code snippets
- Leave out references to the libraries and/or resources you’ve used (that’s why you have a log)
These three big ones cost students points each year.
As mentioned, this section is all about complexity, but does that mean? Complexity can be things like algorithms, use of classes, file or database handling and such. The list below is a not checklist, and your program may have something which is not on it.
Examples of complexity
- User interface (code side)
- Sorting, searching, or use of complex data structures
- Any visualizations which are interactive program generated
- Object-oriented programming
- File handling
- Network programming
- Using certain frameworks
- Anything that uses common or self-developed algorithms
- Web design
You will have 1000 words of extended writing in order to describe the complex techniques you’ve used. That may sound like a lot, but using diagrams, code snippets and tables can help stretch that word count a bit. In structuring this section it’s recommended you have selected a minimum of 3 techniques and that you follow something like following:
- An overview of the complex techniques you’ll be discussing
- A section for each complex technique
- Within each section you should outline how it works by using code snippets, diagrams and references to research and resources.
Criteria D – Functionality and extensibility
This is one of the easier sections as all it requires is for you to create a video shorter than 7 minutes which shows that your product functions as intended. You should through every part of your program using sample input while narrating the process. You should hit the following areas:
- Show your product works as intended
- Show how it meets the success criteria (putting them on the screen can be helpful)
- Show how the product can be extended later on to accommodate changes.
Criteria E – Evaluation
In your final criteria you will need prove that you have completed all the success criteria, or note why you were not able to adequately achieve them. Some justification must be given in the form of an image or a short bit of extended writing. Don’t write too much, as you’ll need to save your word count for the last part.
The final thing you’ll need to do is show evidence of a final meet up with your client or adviser who will evaluate your product and make suggestions on how you could improve it. You should also make note of ways that you think it can be improved.