Paul Baumgarten | 2020.

Computer Science
Internal Assessment
Paul Baumgarten | 2020.3

INTERNAL ASSESSMENT

The Internal Assessment for Computer Science is an opportunity for you to showcase your algorithmic and technical prowess at
developing software intended to solve a legitimate, real world problem for someone.

Approximately 30 hours of class time will be devoted to the Internal Assessment. Beyond that it is expected you will contribute
at least the same amount of your own time towards the project.

You are graded according to the complexity and ingenuity demonstrated through your programming.

Your product may be developed using any programming language you are familiar with. That said, you do need to justify your
choice of language used. This must be done in relation to why it was the best fit for the scenario/problem you are tackling.

The documentation is loosely based on the software development life cycle, there are 5 criteria assessed, and a maximum
overall word count of 2000 applies.

Like other IAs, you receive formative feedback on a formal draft, and then submit a final for IB grading. After the final grading
the IBO will moderate a selection of 5 of the IA’s submitted.

The assessed deliverables for this IA can be summarized as follows:

Criterion A 1. Client and scenario 250 words

2. Rationale 250 words 6 marks

3. Success criteria n/a

Criterion B 4. Design diagrams n/a

6 marks
5. Record of tasks n/a

Criterion C 6. Product development 1000 words

12 marks
(complexity & ingenuity of programming techniques)

Criterion D 7. Video demonstrating success criteria 5-7 minutes

8. Extensibility of the product n/a 4 marks

(marked through items 4, 6, and 7)

Criterion E 9. Evaluation 250 words

6 marks
10. Recommendations for improvement 250 words
IB Diploma Computer Science Internal Assessment | page 3

CHOICE OF PROJECT

Find a client:

• The choice of client can make or break a project.

• The client can be a teacher, parent, friend or someone else entirely. They must be an actual person who exists and is
prepared to work with the student.
• Needs to be able to explain their needs and agree with the criteria.
• Needs to evaluate the solution when handed over to them and communicate the evaluation to the student.
• Note: Being your own client is not recommended and not usually something I would approve. In this scenario, you are
still required to have a third party advisor. The project **must have evidence** of the use of someone else who
advised them.

Find a meaningful project needed by the client:

• Students should undertake a challenging task using appropriate techniques to showcase their algorithmic thinking and
organizational skills.
• Must demonstrate Computational Thinking and include some original coding, though it may be an improvement or
addition to an existing project (clearly documented who is the author of which parts)
• Be wary of projects that are simply a GUI or a database with little to no computational thinking
• Check YouTube for sample project videos, there are some very good ones to be found.
• Does not have to use the programming language taught in class - use the one that best fits the project.
• It should be noted that products created using templates that show no evidence of modification in their structure,
design or functionality are not permitted.

Some ideas if you are completely stuck:

• Student council elections vote tally machine

• Booking / reservation system
• Product inventory system
• Family tree creator
• Calendar for a busy student
• Problem solving game (black jack, poker, chess, tic tac toe, monopoly)
• Robotics (arduino, raspberry pi. note: Lego is not considered powerful enough)
• Apps utilising GPS, camera etc (a race with waypoints, a virtual tour that tells you about your location)

Most importantly, find a meaningful, tangible project!

IB Moderator comment / advice:

Contrived tasks and clients were routinely seen in the weaker pieces submitted, where the student decides on a product
and then finds a client to match.

Some examples of trivial products include: Java programs that mainly focus on GUI and not on actual functionality, Java
programs that consist of one class only, Java programs consisting of a Greenfoot template with only two methods
overwritten, rudimentary versions of freely available games (like Sudoku), Access databases that contain just one or two
tables or non-relational tables, websites that are template-based (Wordpress, Wix or Weebly) or that have minimal content,
basic Excel projects, Scratch projects that had not been properly designed.
Paul Baumgarten | 2020.3

DELIVERABLES

Students must produce a solution that includes supporting documentation up to a maximum of 2,000 words. If the word limit is
exceeded, the teacher’s assessment of the documentation must be based on the first 2,000 words. Work that falls significantly
beneath the stated word count is unlikely to fully meet the stated requirements of the task and is likely to receive low marks.

Criterion Document Method of submission Recommended word count

A Description of scenario Extended writing 175-250
A Rationale for the Extended writing 175-250
proposed product
A Success criteria for Bullet points
product
B Record of tasks Record of tasks form
B Design overview Design overview document with, for example,
screenshots, flowcharts/pseudocode, tables and
diagrams
C Developing the Extended writing (with screen shot evidence 500-1000
product included). Justification of techniques used
D The functioning Video (4-7 minutes)
product
D Extensibility of product Assessed through "design overview" and "developing
the product"
E Evaluating the product Extended writing 175-250
E Recommendations for Extended writing 175-250
improving the product
Appendix To contain additional information as relevant

The sections labelled "Extended writing" all contribute to a combined total 2000 word limit.

From the IB (subject guide, p76): Students must produce a solution that includes supporting documentation up to a maximum of
2,000 words. If the word limit is exceeded, the teacher’s assessment of the documentation must be based on the first 2,000
words. Work that falls significantly beneath the stated word count is unlikely to fully meet the stated requirements of the task
and is likely to receive low marks.

APPENDICES

• Are not counted within the 2000 word limit.

• The marker is not obligated to read any section of the appendices not referred to in the main text.

Appendices can show, if appropriate, any additional information such as:

• transcript/evidence of consultation with the client/adviser

• transcript/evidence of feedback from the client/adviser
• additional videos or documents containing screenshots of the product functioning.
• code print out
IB Diploma Computer Science Internal Assessment | page 5

IDENTIFICATION OF STUDENT WORK

The IB has made changes with respect to anonymity of student work. Students should not include any identifying information
within their IA work such as their name, name of school or name of teacher. Students are to only identify themselves using their
6 character IB code `abc123`.

USE OF PERSONAL INFORMATION

Given the nature of the project, students must take into account ethical problems and implications for undertaking research and
developing the solution, for example, ensuring the confidentiality and security of data. Wherever possible, original data should
be used or be collected by the student.

The following guidelines come from the IB and must be applied.

• Consent (preferably written) must be obtained from people who will be involved in the development of the solution
before any investigation is begun.
• All data collected must be stored securely in order to maintain confidentiality.
• Only the data collected for the solution can be used. It must not be used for any other purpose without explicit
permission.
Paul Baumgarten | 2020.3

CRITERION A: PLANNING

DELIVERABLE 1: THE SCENARIO

Criterion Document Method of submission Recommended word count

A Description of scenario Extended writing 175-250

The following key questions should be considered

• Who is the client?

• Is the choice of client appropriate?
• Why is the product being developed?

Before reaching a decision for the proposed product the student and/or computer science teacher must determine:

• if the student has the technical skills and access to the software required to develop the product
• whether the client’s hardware and software is compatible with the product
• if the data required for the product can be obtained by either the student and/or appropriate third parties
• how any security implications for the development and operation of the product can be resolved.

The rationale and success criteria should be developed in consultation with their client. The student needs to remember they
are producing software for a client/customer not for themselves. It is important that the software produced is what the
customer needs, not what the student wants. Therefore it is important that the criteria that will satisfy the client is thoroughly
understood. To that end, students should aim to conduct two interviews with the client in the planning phase.

• Interview 1 is to get the initial information from the client, to gather as clear a picture of the needs the software is to
solve as possible. Include the transcript of the 1st interview in an appendix and refer to it in your main text.
• Interview 2 is to present the proposed rationale and success criteria to the client for their approval. Amendments
should be made as per the client’s suggestions/requests so the final product has the best chance of meeting their
needs. Include the transcript of the 2nd interview and refer to it in the main text. Ensure the client adequately
communicates that the success criteria is satisfactory. It is recommended to have them sign their acceptance of the
final success criteria.

IB Moderator comment / advice:

Too many students decided on a product (“I want to make a website/program a game”) and then found a client to match.
Some schools adopted a standard approach where the teacher was the client, setting a task for the student. These
approaches should be discouraged. Contrived tasks and clients were routinely seen in the weaker pieces submitted.

IB Moderator comment / advice:

The scenario: It is important to concentrate on the problem your client is facing, and how does your client currently solve the
problem, and the reason the current solution is inadequate.

It is highly recommended to include detailed evidence of consultation with the client (as indicated in the subject report) in an
appendix that is referenced from Criterion A. However, in addition to this the candidate should also include evidence in
Criterion A itself. For example, "we discussed possible solutions...", "The client responded by ...", "we agreed on the main
goals" etc. so that it is clear to the moderator that genuine consultation has taken place with a real client.
IB Diploma Computer Science Internal Assessment | page 7

DELIVERABLE 2: RATIONALE FOR THE PROPOSED SOLUTION

Criterion Document Method of submission Recommended word count

A Rationale for the Extended writing 175-250
proposed product

The rationale behind the choice of the proposed product must be in extended writing, with reference to the student’s
consultations with the client and/or adviser, justifying how the choice of this particular product is an effective solution.

The rationale behind the choice of technology stack has been provided. Your choice of technology stack must be relevant to
your project, not simply because it is what you have the most experience with.

Some past examples that were not fully thought through:

• “An alarm clock to wake you in the morning” … does it really make sense that this would be a desktop web browser
app? Surely it requires to be a background system process. If you insist on using Java script, use Cordova to compile it
to a device app, otherwise make it a native app.
• “Map based tool for use on the road” … but was written in Java, but not made into an Android app instead only made
for Desktop use.

(refer subject guide, p82)

Paul Baumgarten | 2020.3

DELIVERABLE 3: SUCCESS CRITERIA

Criterion Document Method of submission Recommended word count

A Success criteria for Bullet points
product

The success criteria (that are evaluated in criterion E) should be listed in the form of bullet points.

Ensure you are specific! Avoid generic success criteria such as:

• Runs without bugs, runs without crashing

• User friendly in appearance

If the student is the client, they must have an adviser who can review the success criteria and provide the validation of the
product.

IB Moderator comment / advice:

Too many students had generic success criteria – these criteria must be specific and testable. The Criteria for Success are
essential to the project and must be explicitly addressed in the test plan and in the evaluation (and preferably also in the
video).

CRITERION A: MARKING GUIDE

Marks Description
0 The response does not reach a standard described by the descriptors below.
1-2 An appropriate scenario for investigation for an identified client is stated. The rationale for choosing the proposed
product is identified. The criteria for evaluating the success of the product are generally inappropriate.
3-4 An appropriate scenario for investigation for an identified client, providing evidence of consultation, is stated. The
rationale for choosing the proposed product is partially explained and includes some appropriate criteria for
evaluating the success of the product.
5-6 An appropriate scenario for investigation for an identified client, providing evidence of consultation, is described.
The rationale for choosing the proposed product is justified and includes a range of appropriate criteria for
evaluating the success of the product.
IB Diploma Computer Science Internal Assessment | page 9

CRITERION A: CHECKLIST

Scenario

Evidence of consultation with client should be explicit and genuine

(eg: “we discussed”, “they said”, “we agreed”….)

Client interview in appendix (transcript or summary)

Client interview referred to in main text (appendix not credited if not

referred to)

Extended writing: 175-250 words

Rationale

Choice of project is justified

Choice of technology stack is justified and appropriate to the scenario.

Your selection must be justified in the context of the project, not
simply because it is what you have the most experience in.

Extended writing: 175-250 words

Success criteria

Functional and non-functional criteria have been provided

Criteria are specific and can be objectively measured in the evaluation

stage

Bulleted list - no word count

Paul Baumgarten | 2020.3

CRITERION B: SOLUTION OVERVIEW

DELIVERABLE 4: RECORD OF TASKS

Criterion Document Method of submission Recommended word count

B Record of tasks Record of tasks form

A Record of tasks form in the zip file must be used for the product proposed in criterion A. You must use the official IB supplied
template as shown below.

The record of tasks form addresses:

• a chronology of the key events in planning, designing, developing, testing and implementing the solution through the
Criterion column (ie: don’t use this to identify the “A”, “B”, “C”, “D”, “E” criteria).
• any other issues that may arise that may affect the development of the solution.

IB Moderator comment / advice (Subject report, May 2019):

Records of Tasks were generally only partially complete, typically because the final product had not been implemented/used
by the client. Some Records of Tasks focus incorrectly on the write-up of the project criteria rather than the actual product
design cycle stages (plan, design, develop, test and implement). A wide variety of test plans were seen. The better ones
aligned with the Criteria for Success.
IB Diploma Computer Science Internal Assessment | page 11

DELIVERABLE 5: DESIGN OVERVIEW

Criterion Document Method of submission Recommended word count

B Design overview Design overview document with, for example,
screenshots, flowcharts/pseudocode, tables and
diagrams

The information added must be in the following style(s):

• bullet points or tables to list information

• scanned diagrams or other appropriate images as part of the design process
• other styles of non-extended writing or diagrammatic representation such as flow charts, Gantt charts or spider
diagrams where appropriate.

If the student includes extended writing, the words will be included in the word count and the student will self-penalize if the
total number of words in the documentation exceeds 2000 (subject guide, p81) **see FAQ for more detail**

The design overview should include:

• design methodologies appropriate to the type of product being designed

• different levels of draft design, such as the overall structure and the internal layout of the product itself; this can also
include investigation into specific elements used within the product (such as classes, sub-classes, tables, queries, style
sheets, graphic elements, effects)
• evidence of a testing plan that addresses the main areas of functionality of the product.

For your screen mockups, while it is not mandatory (you can use paper & pencil), I highly recommend using a tool such as one of
the following:

• Adobe XD – Free download from https://adobe.com/products/xd.html

• MockFlow - Limited free plan from https://mockflow.com/
• Moqups – Limited free plan of 1 project of maximum 300 objects & 5 MB storage from https://moqups.com/

IB Moderator comment / advice (Subject report, May 2018):

The actual design overview should include many design components, for example:

• detailed layout design sketches that include annotations for complex techniques,
• evidence of algorithmic thinking (in the form of
o flowcharts,
o UML diagrams,
o pseudo-code,
o ER diagrams,
o structured database decomposition using NF,
o query and macro design,
• and a test plan that addresses all success criteria.

All high scoring projects included a thorough design stage.

Paul Baumgarten | 2020.3

CRITERION B: MARKING GUIDE

Marks Description
0 The response does not reach a standard described by the descriptors below.
1-2 The record of tasks and the design overview, including an outline test plan, are limited. From this information it is
difficult to see how the product was developed.
3-4 The record of tasks and the design overview, including an outline test plan, are partially complete. They provide a
basic understanding of how the product was developed.
5-6 The record of tasks and the design overview, including an outline test plan, are detailed and complete. From this
information it is clear how the product was developed.

CRITERION B: CHECKLIST

Record of tasks

Record of tasks form provided (zero without) and uses the mandatory
template

Includes all 5 stages (plan, design, develop, test, implement) through

the Criterion column

Contains all necessary information (task number, planned action,

planned outcome, time estimate, target date, criterion).

Relates to the product proposed in Criterion A (not a record of making

some alternative product!)

Updated during the life of the project

Time frames are realistic.

Provides a realistic plan and timeline for managing the solution,

including the gathering of necessary information, the development of
the product and the testing process.

Provides detail of the implementation (training the client on the

system etc)

No word count applies

IB Diploma Computer Science Internal Assessment | page 13

Design overview

Design overview provided (zero without) and relates to the product

identified in Criterion A

Includes detail of the overall structure and internal structures of the

program

Includes diagrams as appropriate to the solution such as...

• DFD Context diagram
• DFD Level 0 diagram
• UML class diagrams (if an OOP methodology has been used)
• Database ERD diagram (if a relational database has been
used)
• Data dictionaries (for any data storage system used)
• Annotate screen mockups
• Pseudo code or flowcharts to document logic of key parts

Diagrams are correctly produced

• Error free construction
• Seems logical for the scenario

Sufficient in detail to indicate HOW the product will FUNCTION

• Technically
• User experientially

No word count applies (no extended writing expected)

Test plan (treated as part of design overview)

Test plan included as part of design overview (max of 4/6 without)

Test plan must address the success criteria identified in Criterion A

Recommend format as a table: Suggested columns: Action to test;

Method of testing; Expected result.

Test plan accounts for normal, abnormal and extreme inputs.

For instance: Test for error scenarios: If an positive integer is
expected, what happens? if negative, decimal or string is provided?

No word count applies (no extended writing expected)

Paul Baumgarten | 2020.3

CRITERION C: DEVELOPMENT

DELIVERABLE 6: DEVELOPING THE PRODUCT

Criterion Document Method of submission Recommended word count

C Developing the Extended writing (with screen shot evidence 500-1000
product included). Justification of techniques used

The information in the development documentation must provide a detailed account, using extended writing and other
appropriate information, to explain the following.

• The structure of the product and why it is appropriate

• The algorithmic thinking used in the development of the product
• The techniques used in the development of the product and reasons why they are appropriate to it (may include
screenshots, exemplar data, reference to information in the appendix)
• Any existing tools that are used in the development of the product, such as code libraries, software packages, web
hosting, security information or infrastructure issues

Any reference material such as templates, program code, applets or other materials that have been used or modified must be
acknowledged in this criterion. The code used in the product can be included in the appendix.

IB Moderator comment / advice (Subject guide):

It is essential that whatever form the solution takes it ensures the student can explicitly demonstrate and document his or
her algorithmic thinking skills.

IB Moderator comment / advice (May 2019 subject report):

The complexity of the product must be justified by the candidate in the write-up. A seemingly complex product without
proper explanations of complex techniques used in the product, only achieves moderate complexity. Similarly, high ingenuity
must be justified by algorithmic thinking (e.g. explanations of complex data structures, algorithms or macros).
IB Diploma Computer Science Internal Assessment | page 15

TECHNIQUES

In assessing INGENUITY, I make an on-balance assessment of:

• Structure and layout of your code is logical and easy to follow

• Comments in-line code (ideally following the conventions for your programming language)
• Names are meaningful and follow a consistent scheme (variables, methods, classes)
• Use of Input validation techniques
• Data is well structured (eg: use arrays/objects to avoid names like *player1, player2, player3*)
• Use of global variables is minimal or avoided altogether. Where used they have been well justified.
• Use of error checking to "fail gracefully" (file exceptions, network exceptions, user input exceptions etc)
• Use of presentation and logic code separation where practical (model-view-controller or similar)
• Use of an elegant abstraction of classes, properties and/or methods.
• Use of algorithmic thinking that is elegant &/or efficient in their operations. eg: You don't perform O(n^2) operations
when O(n) is feasible.
• Use encapsulation to avoid dependence on, or creation of side-effects
• Functions are sufficiently modular so each achieves one task

In assessing COMPLEXITY, I make an on-balance assessment of:

• Use of files and/or databases to save/load persistent data

• Use of remote API's (such as REST APIs, socket connections)
• Use of imported functionality from 3rd party modules and/or libraries
• Use of dynamic data structures where appropriate (arraylists, stacks, queues, linkedlists, binary trees, objects)
• Use of key-value pair dynamic data structure (Hashtables in Java, Dictionaries in Python, serialised/deserialised JSON)
• Use of object orientated design where appropriate
• Use of multidimensional arrays and/or collections
• Use of event handlers, call backs, &/or promises
• Use of complex presentation frameworks or templating languages such as Cordova, Electron, Kivy, React, Angular,
Handlebars, Jinga2
• Use of multiple programming languages (eg: Python or Java backend, non-trivial Javascript front end)
• Use of GPU programming, parallel processing, or multiple threads (if appropriate to the problem)
• Use of nested control structures where appropriate

You are not expected to use all the above items. They would not all be relevant to your scenario. They are a guide to items that
may indicate complexity in your programming skill.

Credit for these items is only awarded where the accompanying written work documents the use of the technique. No credit is
awarded for techniques used but not described.

The more of these skills you are able to demonstrate (and articulate through your Criterion C document) through your IA the
better.

IB Moderator comment / advice (2019 subject report):

Highly successful solutions tended to incorporate features from more than one software. For example, website projects that
incorporate JavaScript / PHP / SQL functionality, or programming projects that interact with sensors, Access databases or with
on‐line resources
Paul Baumgarten | 2020.3

CRITERION C: CHECKLIST

Product is compatible with the information in Criteria A & B

(ie: what you designed is what you made - automatic zero if not)

A list of techniques used in developing the product is identified

(see list of techniques that you can draw upon)

Techniques used are explained

• If complex techniques are not explained then complexity
score will be marked as "moderate" at most
• "High scoring solutions (complexity) incorporated features
from more than one software. For example, website projects
that incorporate JavaScript/PHP/SQL functionality, or
programming projects that interact with an Access database
or with on-line resources" (2015 subject report)

Evidence of algorithmic thinking provided

(ingenuity=moderate at best without)

Development documentation is a detailed account

Different algorithms used have been represented diagrammatically

Screen shots of programming code and rendered output screens have

been provided and annotated/described

Reference material must be acknowledged (source code, software

libraries from 3rd parties)

In-text citation and end-text referencing are used

Extended writing of process of development: Approximately 1000

words.
IB Diploma Computer Science Internal Assessment | page 17

CRITERION C: MARKING GUIDE

Marks Description
0 The response does not reach a standard described by the descriptors below.
1-4 The use of techniques demonstrates a low level of complexity and ingenuity or does not address the scenario
identified in criterion A. It is characterized by limited use of existing tools. There is no explanation of why the
techniques are used or how they are adequate for the task. Sources are used but are not identified.
5-8 The use of techniques demonstrates a moderate level of complexity and ingenuity in addressing the scenario
identified in criterion A. It is characterized by some appropriate use of existing tools. There is some attempt to
explain the techniques used and why they are adequate for the task. All sources are identified.
9-12 The use of techniques demonstrates a high level of complexity and ingenuity in addressing the scenario identified
in criterion A. It is characterized by the appropriate use of existing tools. The techniques are adequate for the task
and their use is explained. All sources are identified.

The table makes reference to "complexity and ingenuity". What happens when a student performs highly in one, but not in the
other? The following is a supplemental table produced by the IB to illustrate the balance struck:

Complexity

High Moderate Low

Ingenuity High 9-12 7-10 5-8

Moderate 7-10 5-8 3-6

Low 5-8 3-6 1-4

Within the range is decided by:

• Completeness of listed techniques

• Completeness of evidence of algorithmic thinking
• Completeness and detail of development documentation
• Quality of explanations including screenshots
• Inclusion of references where appropriate
Paul Baumgarten | 2020.3

CRITERION D: FUNCTIONALITY AND EXTENSIBILITY OF PRODUCT

DELIVERABLE 7: FUNCTIONALITY OF THE PRODUCT (VIDEO)

Criterion Document Method of submission Recommended word count

D The functioning Video (4-7 minutes)
product

The student must use the video to demonstrate the product functioning. Ensure your demonstration includes a variety of
situations (normal case, extraordinary case).

The following points should be observed

• The best videos tend to be those that “walk” the marker through each of the individual success criteria and
demonstrating and documenting the achievement of each.
• Strict 7 minute limit, the recommended length is 5 minutes
• Spend the last 30 seconds discussing expansion and modification of the product.
• MP4 format is "safest" (if the video is not compatible with the IB marker's computer they are not obligated to spend
time trying to fix it).
• It is also recommended to upload to YouTube (can set it to view with link only) as a backup option (but must still
provide a file on the USB as well)

IB Moderator comment / advice:

The video should be about 5 minutes and should only show the proper working of the final version of the solution. The
structure of the video should be scripted by the candidate.

Candidates are advised to test their screencasts on different media players and devices to ensure the playback is correct.

For example, the video could show the testing of the implemented solution following the test plan from criterion B.

Successful videos showed comprehensive evidence of the solution's functionality with lots of data, but were edited to avoid
viewing tedious data entry.

IB Moderator comment / advice (May 2019 subject report:

Too many students substitute 'showing full functionality' of the product with 'highlighting a functionality'. For example, a
screencast showing where 'edit' happens, but not showing the edited data or persistence after restarting.
IB Diploma Computer Science Internal Assessment | page 19

DELIVERABLE 8: EXTENSIBILITY OF THE PRODUCT

Criterion Document Method of submission Recommended word count

D Extensibility of product Assessed through "design overview" and "developing
the product"

The student should design the product so that it can be maintained by another party and/or be further developed. Therefore
the design of the product should include:

• appropriate folder structures

• appropriate data structures to abstract the problem
• intuitive file names
• intuitive variable and/or class naming conventions and,
• well commented code

IB Moderator comment / advice:

Extensibility is evidenced by a detailed design in criterion B, by a detailed description of the creation process in criterion C
and, in case of a programming project, by a properly structured and annotated code listing in an appendix.

IB Moderator comment / advice (May 2019 subject report):

Extensibility assesses how well-documented the solution is, which is not the same as suggesting improvements. Extensibility
was often impacted by a limited Design Overview and the failure to include an accessible version of the product (java vs jar
files or a database accessible in design view).
Paul Baumgarten | 2020.3

CRITERION D: CHECK LIST

Functionality (assessed through the video)

Video basics:
• Submitted (Criterion D maximum of 2 without)
• Playable (common format such as MP4)
• Approximately 5 minutes long, maximum of 7 minutes

Focus of video is on demonstrating the various functions of the

solution

Each of the Criterion A success criteria are demonstrated

Video demonstrates a range of situations, edge case scenarios, error

handling etc

Video demonstrates tests listed in the test plan (Criterion B)

Video does not document/discuss the development process (sticks to

the functionality).

Maximum 30 seconds discussing expansion and modification of the

product.

No written component / no word count applies

Product tested in more than one location under different conditions

NOT RELEVANT TO THE VIDEO BUT IS RELEVANT TO ENSURING YOUR
PRODUCT WILL WORK ON THE IB MARKERS COMPUTER
IB Diploma Computer Science Internal Assessment | page 21

Extensibility (assessed through the detail and clarity provided in Criterion B and C)

Code listing is provided in appendix

Code is well structured, formatted, and annotated

(in-code explanatory comments are provided, sufficient in number,
and meaningful)

Code variable, function and class names are 3rd-party-developer-

friendly

Generally accepted code conventions are adhered to

(camelCase, indentation etc)

Design overview (Criterion B) provides evidence that the product

could be further developed.

Comments included in the Criterion C text that indicate how the

product may be maintained by a 3rd party.

CRITERION D: MARKING GUIDE

Marks Description
0 The response does not reach a standard described by the descriptors below.
1-2 The video shows that the product functions partially. Some expansion and modification of the product is possible
but difficult.
3-4 The video shows that the product functions well. Some expansion and modifications of the product are
straightforward.
Paul Baumgarten | 2020.3

CRTERION E: EVALUATION

DELIVERABLE 9: EVALUATION OF THE PRODUCT

Criterion Document Method of submission Recommended word count

E Evaluating the product Extended writing 175-250

The evaluation of the product should refer directly to the success criteria in criterion A, feedback from the client/adviser, as well
as any other appropriate feedback obtained. Both the client and the student should provide evaluative feedback on each of the
individual success criteria points.

DELIVERABLE 10: RECOMMENDATIONS FOR THE FUTURE DEVELOPMENT OF THE PRODUCT

Criterion Document Method of submission Recommended word count

E Recommendations for Extended writing 175-250
improving the product

The student will use the feedback and the evaluation of the specific performance criteria to recommend possible future
developments to the product. These recommendations should explain the benefits of these developments.

IB Moderator comment / advice:

For full marks in Criterion E evidence of client feedback must be included (in an appendix) and it must be discussed and
referred to in the student's evaluation against the success criteria.

Recommendations should be realistic in relation to the actual product – for example 'adding network capability' is not a
realistic improvement for a low-level product. Recommendations for improvement should go beyond the success criteria that
have not been met.
IB Diploma Computer Science Internal Assessment | page 23

CRITERION E: CHECK LIST

Evaluation of product

Evaluation addresses all criteria for success (Criterion A)

References a full discussion of client feedback

Client feedback includes a questionnaire or interview

transcript/summary in appendix

Client feedback is referred to in the evaluation (otherwise no credit

for appendix)

Significant client feedback is discussed/analysed

Recommendations

Minimum 2 realistic/reasonable recommendations for improvement

Recommendations may come from student or client

Recommendations are justified

Recommendations go beyond success criteria that were not met

Criterion E Overall

Combined evaluation & recommendations: 350-500 words

CRITERION E: MARKING GUIDE

Marks Description
0 The response does not reach a standard described by the descriptors below.
1-2 There is a limited attempt to evaluate the product against the success criteria identified in criterion A. There is
limited evidence of feedback from the client/adviser and any recommendations for further improvement are
trivial or unrealistic.
3-4 The product is partially evaluated against the success criteria identified in criterion A including feedback from the
client/adviser. Recommendations for further improvement of the product are largely realistic.
5-6 The product is fully evaluated against the success criteria identified in criterion A including feedback from the
client/adviser. Recommendations for further improvement of the product are realistic.
Paul Baumgarten | 2020.3

REFERENCING

References must be included to show where statements, ideas and evidence come from. It is very important to cite all sources
used. If students do not reference their work, issues about the authenticity of the work may be raised.

Sources should be referred to in the text, and a standard referencing format should be used for the bibliography and footnotes.
Students should ensure that their method of referencing is consistent throughout, and that all the relevant information is
provided. The referencing system must enable the reader to locate the original sources easily.

The following guidance is based on the Harvard author-date system. It is offered only as an example: the IB permits any
accepted convention for citing and acknowledging sources.

Body text

Use brackets or parentheses to set off a reference in the text. Give the author’s last name, if it is not part of the text, the date of
publication and the page number(s).

(Johnson 2006, p.98)

A full reference should appear in the bibliography at the end of the piece of work.

Footnotes

Footnotes provide related information that does not belong in the text. There should be as few of these as possible and they
should be identified with a superscript number (for example 1) and placed at the bottom of the same page.

Bibliography

The bibliography, or list of references used, should appear in criterion C. List sources alphabetically by the last names of authors
or editors. If there is no author or editor, list sources by titles and put them in order by date.

Books: Author’s last name and first name, or initial if name is unknown. Date. Title (in italics). Place of publication. Publisher’s
name.

• Connolly, Thomas and Begg, Carolyn. 2002. Database systems (3rd edition). Harlow, England. Pearson Education.

Articles in journals: Author. Date. Title of the article (in quotation marks). Name of the journal (in italics). Volume number, first
and last pages.

• Lawes, Sheila. July 2008. “Moving towards a new IT paradigm”. Journal of Information Technology. Volume 47, Number
3, pp 13–28.

Information from the internet: Author’s name if possible. Title (in italics). Date site was visited. URL (address for the home page).
Heading as listed on the web page (if there is one).

• Lindsay, Julie. Welcome to Flat Classroom Internal assessment 2007, visited 17 July 2006. http://flatclassroomInternal
assessment.wikispaces.com/.

Unpublished interviews with a client and personal research such as questionnaires: Name (last name, first). Type of source.
Pertinent identifying information. Date.

• Student’s name, initial consultation with Mr Beharrel, online education consultant near Colchester, 12 August 2010.
IB Diploma Computer Science Internal Assessment | page 25

PACKAGING FOR SUBMISSION

# 1. GET THE TEMPLATE

The IB provides an official template ZIP file that contains the file/folder structure your submission requires. Download this, and
unzip the file to a folder on your computer.

2. PREPARE YOUR DOCUMENTS

You are required to submit the following documents:

• Crit_A_Planning.pdf
• Crit_B_Design.pdf
• Crit_B_Record_of_tasks.pdf
• Crit_C_Development.pdf
• Crit_D_Functionality.mp4
• Crit_E_Evaluation.pdf
• Appendix.pdf

To do:

• Convert your documents to PDFs

• Rename files as required (the above names must be used precisely)
• Copy them all to a /Documentation folder in the root folder of your project

3. PREPARE YOUR PRODUCT

Your product is required to be copied to a /Product folder in the root folder of your project.

If you need to give the marker special instructions on how to execute your project (passwords etc), those will be added to the
HTML cover sheet.
Paul Baumgarten | 2020.3

4. EDIT THE HTML FILE

Open the **index.html** cover sheet in a text editor such as Brackets or Atom.

Edit the relevant sections of the HTML file as follows:

• Candidate name: enter your six character IB code such as **abc123**

• Solution title: the name of your project
• User name: --leave blank--
• Links to: add links to your product here. If it is an online project you should provide a link to the online and offline
copies. Example HTML code follows:

<a href="https://www.mywebsite.com/">
Link to online version of project
</a> |
<a href="/Product/index.html">
Link to offline (local) version of project
</a><br>

• Directions to access product: Any relevant instructions for the examiner to execute your project
• Planning: Change this link so it will open your planning PDF file. For example:

<a href="/Documentation/Crit_A_Planning.pdf">Planning</a>

• Change the links for your Record of tasks, Design, Development, Video, Evaluation and Appendix as well
• Enter the total word count in the relevant section
• Save your index.html

5. ZIP AND NAME THE FOLDER

• ZIP the folder

• Rename your ZIP file to your six character IB code such as **abc123.zip**

6. SUBMIT YOUR 4ICCS FILE

The 4ICCS file is the IB document containing the reflection for your Group 4 project. While not weighted as part of your
Computer Science grade, it is still compulsory and must be submitted

• Download the blank 4ICCSe form

• Enter your group 4 project reflection and identifying details
• Save the PDF
• Submit it with your ZIP file (but **do not insert it into the ZIP file**)

7. SUBMIT TO TEACHER

And you are done!

IB Diploma Computer Science Internal Assessment | page 27

SAMPLE COVER PAGE

Paul Baumgarten | 2020.3

FAQ

WHAT ARE THE GRADE CUT OFFS?

While there is never any guarantee what the cut offs will be in any given year, past data is available and informative.

Year 1 2 3 4 5 6 7
2014 0% 20% 38% 53% 63% 75% 85%
2015 0% 20% 38% 53% 63% 75% 85%
2016 0% 18% 32% 47% 59% 71% 82%
2017 0% 18% 32% 47% 59% 71% 82%
2018 0% 15% 29% 44% 56% 68% 79%
0-4 5-9 10-14 15-18 19-22 23-26 27-34

CAN I DO GROUP WORK FOR MY IA?

The development of the solution must be undertaken by the student on an individual basis. Collaborative or group work may not
be undertaken by students. (subject guide, p76)

IS THERE A DIFFERENCE BETWEEN STANDARD LEVEL AND HIGH LEVEL?

No, the same assessment criteria are provided for SL and HL.

DOES MY PROJECT HAVE TO USE THE OPTION STUDIED (EG: OOP)?

In identifying a problem, students can select any topic that interests them. It does not have to be directly related to the specified
themes in the syllabus or to the option studied. (subject guide, p79)

HOW DO I TREAT PERSONAL INFORMATION I COLLECT AS PART OF MY PROJECT?

Given the nature of the project, students must take into account ethical problems and implications for undertaking research and
developing the solution, for example, ensuring the confidentiality and security of data. Wherever possible, original data should
be used or be collected by the student.

The following guidelines come from the IB and must be applied.

• Consent (preferably written) must be obtained from people who will be involved in the development of the solution
before any investigation is begun.
• All data collected must be stored securely in order to maintain confidentiality.
• Only the data collected for the solution can be used. It must not be used for any other purpose without explicit
permission.
IB Diploma Computer Science Internal Assessment | page 29

HOW IS INDIVIDUAL WORK AUTHENTICATED?

The completion of the solution must be entirely the work of the individual student. Students should not be discouraged from
showing individuality when completing the solution.

Students should be given a strict timetable and internal deadline for the submission of the rough draft of the solution; this
should include access to the product and associated documentation.

Supervision by the teacher should be on an individual basis and the rough draft checked once only. Repeated submission,
redrafting and remarking of the solution is not permitted. Where there is evidence of collaboration and where there are strong
similarities in the appearance of the different solutions, the work should not be accepted in rough draft. The final draft should
only be accepted if the teacher is convinced of its authenticity.

If teachers suspect that the student’s work is not individual or authentic and they have reasonable evidence, they should make
the student rewrite his or her written report. If time does not permit this, teachers must not sign Form 4/ICCSCS and must
submit the reasons for their suspicion under the heading “Relevant information”.

HOW DO I ACKNOWLEDGE SOURCES AND OTHER CODE?

Students must acknowledge all of the secondary sources they have used in the solution in criterion C. These can include
websites and any other published material. Students who fail to cite any one of the sources they have used will lose some of the
marks available in criterion C.

If students do not reference their work, they could be accused of malpractice.

Sources should be referred to in the text and a standard referencing format (title, author and date) should be used for
bibliographies and footnotes. Students should ensure that their method of referencing is consistent throughout, that all relevant
information is provided and that their system enables the reader to locate their original sources.

Programming code you have depended on (such as from a StackOverflow response) should include an in-text citation as a
comment within the programming code.

HOW MUCH ASSISTANCE AND GUIDANCE CAN I GET FROM MY TEACHER?

It is important that the solution is the student’s own work, although a first draft may be submitted and informal discussions
between the teacher and student can occur.

WHAT DO YOU MEAN BY A TRIVIAL PRODUCT?

This refers to a product that could be created by somebody who has never attended a computer science class. Typical examples
of trivial products include single page websites, flat-file databases, programming solutions consisting entirely of copied code.

Trivial products will result in the student losing marks in criterion C where the maximum mark for this type of product is likely to
be 4. The student may also lose marks in the following criteria:

Criterion B—because the designs will have significant omissions, for example, overall structure will be simplistic, there is likely to
be a limited range of resources and techniques, and the test plan may also be limited or non-existent.

Criterion D—as it may not be possible to determine the functionality and extensibility.

Other marks might be lost in other criteria and these will be evident at submission.
Paul Baumgarten | 2020.3

AM I EXPECTED TO PROVIDE A PRODUCT THE MODERATOR CAN EXECUTE ON THEIR EQUIPMENT?

The candidates are expected to include their product in their submission, as it is considered a subset of the solution. The
candidates do not need to consider the hardware/software available to the moderator when creating their product (and to do
so would go against the flexibility of choice intended by the redesigned course). For this reason the product is not required to
function straight off of the Hard Disk Drive. It is sufficient for the school to include in the submission only the files and folders
that are uniquely those of the candidate; the product at its most fundamental (and would work with the necessary
hardware/software “off the shelf” as it were). Font, browser, software, hardware issues can be resolved by the IB if necessary
(see below) and the school should not go out of their way to add extra elements to the product folder to help with the running
of the product. In some cases the moderator will not be able to run the product; this is not immediately an issue and is why the
video is required. All the marks for the IA are awarded (by the teacher and the moderator) against the written documentation
and video, and therefore there is no mark penalty for failing to include the product. However if the product is not included the
solution will be considered incomplete, from an administrative point of view, and the subject operations administrator at the IB
office will contact the school requesting the missing product(s).

The moderator will check that something is in the product folder (to ensure the submission meets the requirements outlined in
the guide) but will not immediately do anything with the product.

The product will need to run if necessary; by “necessary”, we mean if the moderator, principal moderator and/or the IB wants to
see exactly what the candidate has made in order to gauge authenticity. If the moderator feels there is a contradiction between
what is described in Sections A – C, and what is shown in the video (for example an elaborate and complex technique not
referenced by the candidate), they will investigate the product to ascertain if it is genuinely the work of the candidate. If the
moderator is unable to run the product, the moderator will contact the IB assessment centre who will escalate the situation and
make arrangements for the work to reach someone who can execute the product. This will only occur when authenticity is in
doubt, and the functioning of the product will have no bearing the marks awarded; instead it may affect the candidates overall
Diploma after an investigation from the Academic Honesty department. If the authenticity of the work is not in doubt, it will not
be necessary to run the product.

Source: https://internationalbaccalaureate.force.com/IBProgramme/s/question/0D50O00003Vy32YSAR/internal-assessment-
functional-product-what-to-submit-how-would-moderators-run-the-product-penalty-for-not-submitting-
it?s1oid=00D20000000BPOW&OpenCommentForEdit=1&s1nid=0DB0O000000Cbis&emkind=chatterPostNotification&s1uid=005
0O0000077ZxQ&emtm=1551375192260&fromEmail=1&s1ext=0

CAN I USE TEMPLATES AND WIZARDS?

No, if the product is based on a template or wizard that completely determines its structure and layout; then there is no original
input from the student. For example, this may be copying a web-based template, an exemplar database provided with the
software or significant blocks of code from an internet site.

However, if the student uses the template or wizard as a starting point in developing the product that is unrecognizable from
it—that is, making substantial and appropriate changes—this may be permissible. For example, a student may use a website
template, but has control over the structure and layout. In this situation, it is expected that appropriate techniques would be
used to develop the product.

WHAT HAPPENS IF MAJOR PARTS OF THE PRODUCT DO NOT WORK?

Where one major feature does not function as required, the student will probably lose two marks in criterion D. However, marks
may also be lost in criterion C as the solution may be deemed to be inappropriate.

WHAT HAPPENS IF MINOR PARTS OF THE SOLUTION DO NOT WORK?

The student will probably not be penalized in criterion D.

IB Diploma Computer Science Internal Assessment | page 31

WHAT HAPPENS IF NOT ALL OF THE PRODUCT CAN BE ASSESSED USING THE REQUIRED METHOD OF
SUBMISSION?

It is intended that the video of the product functioning will resolve this issue. However, if the product can still not be assessed IB
Answers should be contacted at the earliest opportunity.

Where the product is hosted online and this is used as a mechanism, in addition to the video, to demonstrate it functioning, the
student must not update the product from the date of submission until the end of the particular examination session (15
September for the May session and 15 March for the November session).

WHAT HAPPENS IF THERE IS NO EVIDENCE OF HOW THE PRODUCT WAS DEVELOPED?

Zero marks are awarded in criterion C and possibly other criteria depending on the teacher’s comments. If the teacher is not
sure the work is that of the student he or she should not sign Form 4/ICCSCS.

CAN THE STUDENT MAKE SEVERAL PRODUCTS TO SATISFY THE REQUIREMENTS FOR THE SOLUTION?

No. Only one product must be submitted, although students may integrate more than one software type within it. Examples
include a website that uses underlying data from a database or a website using applets developed in Java.

DOES THE PRODUCT HAVE TO ADDRESS A REAL PROBLEM?

Yes. The product must be real, current and able to be implemented.

DO IDEAS FOR THE PRODUCT HAVE TO BE RELATED TO THE SCHOOL?

No. Clients can come from businesses or other sources outside of the school environment such as family friends etc.

WHEN IS AN ANNOTATION TREATED AS CONTRIBUTING TOWARD THE WORD COUNT?

If forms, tables, bullet points or footnotes are used for extended text (for example, for explanation, analysis and evaluation),
thereby trying to exclude it from the word count, this text will be included in the word count.

Bullet point list, numbered list, footnotes, captions, tables, titles, annotations are not included in the word count IF they contain
short phrases or statements, as this is what they are meant for. If a candidate provides an extended writing in a table or a bullet
point list (such as explanations, analysis), in anticipation to exclude it from the word count, then this text will be included in the
word count.