Internal assessment is an integral part of the course and is compulsory for both SL and HL students. It
enables students to demonstrate the application of their skills and knowledge, and to pursue their personal
interests, without the time limitations and other constraints that are associated with written examinations.
The internal assessment should, as far as possible, be woven into normal classroom teaching and not be a
separate activity conducted after a course has been taught.
The internal assessment requirements at SL and at HL are the same. However, these requirements contribute
to a different percentage of the overall mark. Students are required to produce a solution that consists of a
cover page, the product and the documentation. The focus of the solution is on providing either an original
product or additional functionality to an existing product for a client.
The internal assessment component (solution), as well as being practical and productive, forms an important
part of the assessment of the computer science course. It is imperative, therefore, that the teacher provides
appropriate guidance to students.
The solution submitted for internal assessment must be the student's own work . However, it is not the
intention that students should decide upon a title or topic and be lef t to work on the internal assessment
component without any further support from the teacher. The teacher should play an important role during
both the planning stage and the period when the student is working on the internally assessed work. It is
the responsibility of the teacher to ensure that students are familiar with:
• the requirements of the type of work to be internally assessed
• the ethical guidelines mentioned in the " Requirement s and recommendations" section of this
document
• the assessment criteria; students must understand that the work submit ted for assessment must
address these criteria effectively.
Teachers and students must discuss the internally assessed work. Students should be encouraged to initiate
discussions with the teacher to obtain advice and information, and students must not be penalized for
seeking guidance. However, if a student could not have completed the work without substantial support
from the teacher, this should be recorded on the appropriate form from the Handbook of procedures for the
Diploma Programme.
It is the responsibility of teachers to ensure that all students understand the basic meaning and significance
of concepts that relate to academic honest y, especially authenticity and intellectual property. Teachers
must ensure that all student work for assessment is prepared according to the requirements and must
explain clearly to students that the internally assessed work must be entirely their own.
As part of the learning process, teachers can give advice to students on a first draft of the internally assessed
work. This advice should be in terms of the way the work could be improved, but this first draft must not be
heavily annotated or edited by the teacher. The next version handed to the teacher after the first draft must
be the final one.
All work submitted to the IB for moderation or assessment must be authenticated by a teacher, and must
not include any k nown instances of suspec ted or conf irmed malprac tice. Each student must sign the
coversheet for internal assessment to confirm that the work is his or her authentic work and constitutes the
final version of that work. Once a student has officially submitted the final version of the work to a teacher
(or the coordinator) for internal assessment, together with the signed coversheet, it cannot be retracted.
Authenticity may be checked by discussion with the student on the content of the work, and scrutiny of one
or more of the following:
• the student's initial proposal
• the first draft of the written work
• the references cited
• the style of writing compared with work known to be that of the student.
The requirement for teachers and students to sign the coversheet for internal assessment applies to the
work of all students, not just the sample work that will be submitted to an examiner for the purpose of
moderation. If the teacher and student sign a coversheet, but there is a comment to the effect that the
work may not be authentic, the student will not be eligible for a mark in that component and no grade will
be awarded. For further details refer to the IB publication Academic honesty and the relevant articles in the
General regulations: Diploma Programme.
The same piece of work cannot be submitted to meet the requirements of both the internal assessment and
the extended essay.
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.
It is recommended that a total of approximately 30 teaching hours for both SL and HL should be allocated
to the work. Weighting at SL: 30% Weighting at HL: 20%
This should include:
• time for the teacher to explain to students the requirements of the internal assessment, including
codes of ethical behaviour and confidentiality
• class time for students to work on the internal assessment
• time spent by the student making arrangements to collect data as appropriate
• time for consultation between the teacher and each student
• time to review and monitor progress, and to check authenticity.
Additional time may be needed outside normal class time for students to work independently, such as
acquiring additional skills required for the project and consulting with other people.
Teachers and students will need to discuss issues relating to the design of the product, the collection of data
and consultations with others. Students should be encouraged to initiate discussions with the teacher to
obtain advice and information, and will not be penalized for seeking advice.
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 must be applied.
• Consent 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.
Teachers should refer to the Ethical practice in the Diploma Programme poster for further guidance.
Schools are advised to follow local best practice in health and safety for research linked to the development
of the solution. Each school is ultimately responsible for the health and safety of students.
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.
For internal assessment, a number of assessment criteria have been identified. Each assessment criterion has
level descriptors describing specific levels of achievement together with an appropriate range of marks. The
level descriptors concentrate on positive achievement, although for the lower levels failure to achieve may
be included in the description.
Teachers must judge the internally assessed work at SL and at HL against the criteria using the level
descriptors.
• The same assessment criteria are provided for SL and HL.
• The aim is to find, for each criterion, the descriptor that conveys most accurately the level attained
by the student, using the best-fit model. A best-fit approach means that compensation should be
made when a piece of work matches different aspects of a criterion at different levels. The mark
awarded should be one that most fairly reflects the balance of achievement against the criterion. It is
not necessary for every single aspect of a level descriptor to be met for that mark to be awarded.
• When assessing a student 's work , teachers should read the level descriptors for each criterion until
they reach a descriptor that most appropriately describes the level of the work being assessed. If a
piece of work seems to fall between two descriptors, both descriptors should be read again and the
one that more appropriately describes the student's work should be chosen.
• Where there are two or more marks available within a level, teachers should award the upper marks if
the student's work demonstrates the qualities described to a great extent. Teachers should award the
lower marks if the student's work demonstrates the qualities described to a lesser extent.
• Only whole numbers should be recorded; partial marks, that is fractions and decimals , are not
acceptable.
• Teachers should not think in terms of a pass or fail boundary, but should concentrate on identifying
the appropriate descriptor for each assessment criterion.
• The highest level descriptors do not imply faultless performance but should be achievable by a
student. Teachers should not hesitate to use the extremes if they are appropriate descriptions of the
work being assessed.
• A student who attains a high achievement level in relation to one criterion will not necessarily attain
high achievement levels in relation to the other criteria. Similarly, a student who attains a low level of
achievement for one criterion will not necessarily attain low achievement levels for the other criteria.
Teachers should not assume that the overall assessment of the students will produce any particular
distribution of marks.
• It is recommended that the assessment criteria be made available to students.
The requirement of the internal assessment is to develop a solution for a specified client to a specified
problem or an unanswered question.
The solution is assessed using five criteria.
• Planning
• Solution overview
• Development
• Functionality and extensibility of product
• Evaluation
The term "solution" refers to all the work submitted by the student for the internal assessment; the term
"product" refers to the completed software only. The product is a subset of the solution.
The terms "developer" and "student" are synonymous.
The term "client " refers to the person for whom the product is being developed. The student may also be
the client.
The term "adviser" refers to a third party the student must identify to assist him or her in the development
of the product.
There are three scenarios for the development of the product.
1. The student is developing the product for a third party who is the client and also acts as the adviser.
2. The student is developing the product for a third party who is the client. Another person acts as the
adviser.
3. The student is the client (developing the product for himself or herself ). An appropriate adult must act
as the adviser.
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.
Students should undertake a challenging task using appropriate techniques to showcase their algorithmic
thinking and organizational skills.
The solution may take one of these forms:
• Creating a new system, such as an OOP program, a relational database, a simulation or a stand-alone/
web-based application
• Adding functionality to an existing system, such as connecting a webpage(s) to a database, writing a
function for Moodle, writing a plug-in, or developing a stand-alone application
It is essential that whatever form the solution takes it ensures the student can explicitly demonstrate and
document his or her algorithmic thinking skills.
Examples are illustrated in the teacher support material.
It should be noted that products created using templates that show no evidence of modification in their
structure, design or functionality are not permitted. Examples of inappropriate products include:
• the development of a programming product only using copied code
• the development of a website (product) using a web-based template that determines its structure and layout
• the use of unmodified exemplar products or templates provided with software such as the Northwind database in MS Access
• a product that does not meet the ethical requirements outlined in the " Requirements and recommendations" section of this document.
Students will need to work closely with the adviser throughout the development of the solution. Therefore
it is recommended that wherever possible, students select an adviser who is known to them or their family.
This could include members of the school community, local clubs or businesses.
The internal assessment consists of three parts:
All three of these must be submitted digitally for moderation.
Instructions for the submission of student work can be found in the Handbook of procedures for the Diploma Programme.
Students should aim to develop a product that uses appropriate (complex) techniques, is fully functional
and allows the moderator, if possible, access to its complete internal structure.
The moderator must be able to see the product functioning as a video. The video should address the
success criteria stated in the planning criterion.
Any text within the product is not included in the overall word count for the solution.
This information must be read in conjunction with that in the "Organization of documentation" section.
A zip file is available on the OCC that contains the cover page and templates required for submitting the solution.
The final documentation consists of:
• Information added to the Record of tasks form and in the information linked to the design overview
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 2,000.
The Record of tasks form in the zip file must be used.
• A series of documents that use text (extended writing) that:
– describes the scenario, client requirements and/or adviser input
– justifies the rationale behind the proposed product
– explains the techniques used to develop the product
– evaluates the success of the product in resolving the original problem and client and/or adviser feedback
– recommends further improvements to the product.
This should be the only information that is included in the word count and it must not exceed 2,000 words.
It is recommended that the blank files in the zip file are used for the documentation.
• Appendix/appendices that show, if appropriate, any additional information such as:
– evidence of consultation with the client/adviser
– evidence of feedback from the client/adviser
– additional videos or documents containing screenshots of the product functioning.
The documentation must be located in the Documentation folder. It is associated with assessment criteria
A—E and any additional material in the appendices of this guide.
The table below indicates the content and nature of each of the files and the criterion that it relates to.
| Document | Method of submission | Criterion |
| Description of scenario | Extended writing | A Planning |
| Rationale for the proposed product | Extended writing | A Planning |
| Success criteria for product | Bullet points | A Planning |
| Record of tasks | Record of tasks form | B Solution overview |
| Design overview | Design overview document, for example, screenshots, flowcharts, tables, diagrams | B Solution overview |
| Developing the product | Extended writing with screenshot evidence | C Development |
| The functioning product | Video (2–7 minutes in length) demonstrating the product |
D Functionality and extensibility of product |
| Extensibility of product | Assessed through design overview and developing the product | D Functionality and extensibility of product |
| Evaluating the product | Extended writing | E Evaluation |
| Recommendations for improving the product | Extended writing | E Evaluation |
| Appendix | To contain additional information such as client meeting transcripts Information in the appendix might give extra detail/evidence for a point made in the main text but must be refered to explicitly. |
n/a |
Students are advised to use the following guidelines to develop the solution. This will ensure it fulfills the requirements of the assessment criteria.
Prior to developing the product the teacher must have:
• approved the choice of client/adviser and scenario
• reviewed preliminary designs and checked that the:
– templates provided in the zip file are being used
– proposed timeline for completing the product is realistic
– scope and nature of the product are appropriate.
The scenario
The following key questions should be considered.
• Who is the client/adviser?
• Is the choice of client/adviser appropriate?
• Why is the product being developed?
Rationale for proposed solution
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.
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.
Success criteria
The success criteria (that are evaluated in criterion E) should be listed in the form of bullet points.
If the student is the client, they must have an adviser who can review the success criteria and provide the
validation of the product.
Advice from pre 2019 sample feedback: "Include an interview with your client in the appendix and in section A this should be summarised and referenced"
Advice from 2021 subject reports: "consult with the client about the issues with the current situation and use this information in their description of the scenario"
Advice from 2022 subject reports: The interview with your client needs to be a meaningful exploration of what they would want from the proposed product type. Not just asking them what they think of your idea.
Also the rationale for choosing the software and technologies for development should not be generic but should relate to the product type and be compared to other possibilities.
A Record of tasks form in the zip file must be used for the product proposed in criterion A.
The record of tasks form must show a chronology of the key events in planning, designing, developing, testing and implementing the solution
and any other issues that may arise that may affect the development of the solution.
The design overview should include:
• the likely layout of the product in terms of how it will function from the users perspective.
• the data input, storage and output requirements of the product.
• design methodologies appropriate to the type of product being designed.
(you could discuss how the data the program requires might be stored and accessed by the program - database, files, classes)
(you could discuss how the program elements will be connected - webpages with hyperlinks and session data, imported modules, graphics suites, styling suites)
• 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. The student must submit final versions of the Record of tasks form and the design overview. However, the teacher will need to see earlier versions to determine whether the product proposed is appropriate and feasible.
Feedback from 2019 sample: "For completeness this overview should include: overall structure, internal structures and descriptions of specific elements, such as layout design, query design, non-standard algorithms, data structures, file structure"
Advice from 2022 subject report: provide evidence of detailed non-standard algorithmic design and data structure design
Advice from 2022 subject report: In the record of tasks include a proper implementation stage during which the client should use the final product for its intended purpose
Advice from 2023 sample feedback: "The Record of Tasks should include all the stages in their correct order. Elements of design overview should be explained to count towards the highest mark band. Final product elements (user interfaces and codes) in design are discounted because design must precede development. The design overview should include internal structures (data structures, object details, UML diagrams, algorithms, database/file structure description etc.) and the overall structure (user interfaces and connections between them). These must be well-explained. A test plan should be included addressing how each Criteria for Success stated in criterion A will be tested"
The product must be compatible with the information in criterion A and criterion B.
The student must present a list of the techniques used in developing the product.
The techniques may include algorithmic thinking, data structures, software tools and user interface. This list
need not be exhaustive but should illustrate how the major components of the product were developed.
The student must provide evidence of algorithmic thinking. Pseudocode development advice.
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.
Feedback from 2019 sample: "The list of techniques must be a complete listed. Explanations of techniques and algorithms need to be detailed."
Advice from 2023 sample feedback: "Techniques must be explained and justified for the upper mark in a mark range to be awarded. To obtain higher marks the student must provide a complete list of techniques used, detailed development documentation, explanations with screenshots and include references where appropriate. Any included code/ERD/SQL statements must be explained and commented to show evidence of algorithmic thinking."
This criterion should be completed as two parts and does not require any additional written documentation.
Functionality of the product
The student must use the video to demonstrate the product functioning. This evidence will be supported by viewable source code and, where possible, by a runnable product linked to from the cover page.
Extensibility of 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 and data structures, intuitive file and/or class naming conventions and, where appropriate, comments in the code.
Feedback from 2019 sample: "The screencast should show (only) the full functionality of the product in relation to the CfS. One test-run is typically not enough to show full functionality. For extensibility the product must be accessible at design level or in form of an annotated code listing"
Advice from 2020 subject reports: "use realistic and sufficient amounts test data both valid and erroneous"
Advice from 2021 subject reports: "show full functionality of the product as a solution using enough test data both valid and erroneous, provide more detail in Criterion B, Criterion C, and add comments in the code to support Extensibility"
This criterion should be completed as two parts.
Evaluation of the product
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.
Recommendations for the future development of 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.
Feedback from 2019 sample: "The students must do a full evaluation after implementing the product and it being used by the client, addressing all the criteria for success and including a full discussion of the product with reference to substantial and explicit client feedback, which must be included in an appendix."
Advice from 2022 subject report: Unfulfilled Criteria for Success are typically considered trivial improvements, as are generic suggestions for 'more data' or 'more functionality'.
Advice from 2023 sample feedback: "Success criteria must be evaluated with explicit feedback from the client. For complete evaluation, students must evaluate the success criteria based on client feedback by making direct references to interviews/questionnaires in an appendix (explicit evidence) and discussing the client's opinion. Full credit cannot be given for trivial and/or vague recommendations for improvement. Good recommendations for improvement must be different from criteria for success, well-explained and justified for maximum marks. "
General overview
The computer science internal assessment focuses on the balance between the level of algorithmic thinking
and problem-solving required to develop a product within the framework of the design cycle.
The assessment criteria
Criteria A, B and E are process-oriented and examine how the internal assessment task was carried out and
allow common assessment criteria to be applied to different types of product from the different options.
Criterion C is a holistic assessment of the final product and assesses the student 's understanding of the
concepts involved in its development. Criterion D is a holistic assessment of the functionality and future
extensibility of the product.
The success criteria identified in criterion A will be used in criterion D to evaluate the effectiveness of the
product.
| 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. |
• The student must provide a record of tasks and a design overview that includes an outline test plan.
• The Record of tasks form must be used.
• The record of tasks and design overview must refer to the product proposed in criterion A.
| 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. |
• The student must identify techniques used in developing the product.
• The student must explain the techniques, with screenshots, that were used to develop the product
identified in criterion A, explaining why they have been used and why they are adequate for the task.
| 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. |
This criterion assesses the extent to which the product:
• functions, as evidenced in the video
• can be expanded and modified by future users as evidenced in the design and development
documentation.
| 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. |
• The student must evaluate the effectiveness of the product based on feedback from the client/adviser.
This must include direct references to the success criteria identified in criterion A.
• The student must recommend proposals for the future improvement of the product.
| 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. |