IB Computer Science Internal Assessment

Checklist
READ THIS CARELFULLY

Before submission of any part of the IA, you must have checked your work thoroughly against
this list.

You must use the forms supplied by the IB.

CRITERION A

Use the following subtitles:

• The scenario
• Initial consultation with client and/or adviser
• The proposed product
• Specific performance (success) criteria

It is essential that you cover these seven points fully and, in the order, given:
1. Investigate a situation
2. Identify client/adviser by name
3. Explicitly consult the client (and/or adviser)
4. Describe the scenario with reference to the full consultation provided in the appendix.
5. Choose a solution
6. Describe the rationale for the solution and also for the software to be used
7. Outline Criteria for Success for the chosen solution

Description of the Scenario (250 words)

Who are the client and adviser?
Why have they been chosen?
Why is the product being developed? What is the problem that it solves?
Nothing about structure, implementation, design.

Rationale for the Proposed Product (250 words)

This section requires you to
• Justify the choice of product.
• Justify the choice of software being used to build it.
•
A range of evidence of communication with client and adviser.

The detail of the consultation must be present in the appendix and you should reference the
appendix point by point in the body of Criterion A to show how your choice of product and
development platform arise directly from your consultation.
If possible, give examples of the current, inadequate solution that you are aiming to replace.
Why will the product be developed?

It should be clear that your consultation has led to your rationale.

How will it be an effective solution to the problem?

Why Java app? (Sell Java!) Why standalone? Don’t say you are using Java because you know it.
That is not a good enough reason.

What other solutions did you consider? Justify this one.

What other solutions did you consider? Justify this one.

Show that you have considered things like:

1. The difficulty/skill-level required
2. Security/privacy implications
3. Ease of access to required data
4. Data format/Conversion issues
5. Hardware/software requirements
6. Time
7. Cost

Success Criteria for the Product

6-8 bullet points
Substantial, specific, measurable, testable
Evidence that the client/adviser has agreed the success criteria
Success Criteria do not count towards word count

CRITERION B
Record of Tasks
This is a record of your software development, not a record of your IA report writing. Don’t put
things like “Finished Criterion C.” Do put things like “Found a bug in the save method. Spent an
hour fixing it.”

“Must provide an overview of all five stages.”

Use official form provided by the IB

Key events in planning, designing, developing, testing and implementing the solution.

Don’t forget the implementation part. This means actually giving the solution to the client and
having them test and approve it, and then installing it on the client’s machine(s).
Don’t allow your record of tasks to fizzle out. You will instantly lose marks if it is deemed
incomplete in any way.

Any other issues that affect the project.

Expect to have 80+ entries in your record of tasks by the time you finish your project.

Design Overview
Lots of screenshots, flowcharts, tables, diagrams of key data structures, algorithms, classes
(UML), file formats

Must have:
• Prototype user interface diagrams.
• High-level architecture diagram showing the interaction between major components,
e.g. client, middleware, database, and data exchange formats, e.g. JSON.
• Diagrams of key data structures, e.g. linked lists, binary trees, etc.
• Principal algorithms. These should be detailed, low-level algorithms presented in
pseudocode or as flowcharts.
• UML diagrams.
• File format e.g. JSON, in monospaced font.
• There should be no extended writing in this section
• Evidence of a testing plan with inputs and expected and actual outputs. Must link
explicitly to the success criteria.

No screenshots from finished product. They must be different.

Justification of deign methodology (short paragraph or diagram).

Evidence of client feedback affecting the design as necessary.

Recent feedback on the OCC and from the moderators has suggested that the contents of
Criterion B has to be “Explained.” For this reason, include a textbox with a couple of paragraphs
explaining each of your sections in Criterion B.

Extensibility of Product
A separate extensibility section is not required but the IB state that even though the
extensibility mark is awarded as part of Criterion D, it will be assessed through the Design
Overview (Criterion B) and the code listing (Appendix).

Despite the fact that a separate section is not required, still add an extensibility section to the
appendix and reference it in the Design Overview. Note that this is in addition to rather than
instead of evidence of extensibility presented in the Design Overview.
There are some ways you can make your code extensible. If you have done any of these, draw
attention to them clearly in the Design Overview and the code listing. Your job is to show how
your program is user-friendly, scalable and accessible to further development in the future.
• Using file input and output rather than “hard-coding” data, e.g. configuration files for
settings
• Defining constants using the final keyword so that they can be changed easily
throughout the code
• Using linked lists (or ArrayLists or other built-in data structures) instead of arrays
• Designing in a modular way such that new modules can be added easily
• Allowing the user to add or delete their own data, i.e. not hard-coding the database
• Using standard data formats, like CSV, HTML, that can readily be used by other software
• Good programming style, so that if another programmer had to pick up the project, they
would find it easy:
o Meaningful variable names
o Standard capitalization in code
§ Proper case for classes
§ All caps for constants
§ Camel case for variables and methods
o Comments
o Encapsulation of instance variables
• Use of constants (e.g. final String FILE_PATH = “./img/”)
• Using relative paths rather than absolute paths
• Using linked lists rather than arrays OR detecting full array and resizing
• User documentation
• System documentation

CRITERION C
Developing the Product
In general, writing and screenshots showing explicit identification, explanation and justification
of the structure of the product. More than anything this section involves explaining your
techniques and highlighting and justifying your complexity.

List of techniques must be explained, not just identified, e.g. algorithms, data structures,
software tools and user interface. It is not sufficient jus to add a code snippet; this does not
constitute an explanation. (Note that the earlier recommendation for a table of algorithmic
thinking using the five types (abstractly, ahead, concurrently, logically, procedurally) has now
been removed.)

“Ingenuity” means algorithmic thinking, individuality, relativity.

Higher complexity means higher marks, but the complexity needs to be justified.
Need to consider complexity and ingenuity separately and combined in a matrix like TOK and
EE.

List of reference or citations should be given in Criterion C (TSM).

Techniques used, e.g.

• Multithreading
• Use of third-party/specialist libraries
• Abstract data structures, e.g. arrays, lists, stacks, queues, tables, trees, etc.
• Algorithms (any big sorting, searching, processing, checking, calculating, positioning, etc.
anything with nested loop or nested ifs (SL only))
• Anything advanced like: recursion, lambda functions, inner classes, etc.
• File reading/writing
• Linking with other systems, e.g. public financial, sports, movie databases
• Integrating several technologies, e.g. PHP, MySQL, JavaScript
• Mobile software, watches, locals windows, breakpoints, run to cursor

Show an example of your file format in a monospaced font or as a screenshot and annotate it
showing how entries are read and converted to objects.

List and explain any third-party tools used, e.g. software, libraries, databases. All sources
referenced. This is crucial. Screenshots of GUI building in Netbeans, debugging, API classes,
java.awt/javax.swing for all of you, etc.

Must reference any and all tools that are not yours.

“Almost anything can be considered complexity, from UI considerations, to validation. Just

make sure that students document everything that is good about the application.”

Some previous IAs have an Algorithmic Thinking or Computational Thinking section: this is NOT
required. Do not include it.

CRITERION D
The Functioning Product
Video 2-7 minutes
“The video should only show the proper working of the solution as outlined by the Criteria for
Success.”

If you fail to demonstrate that your criteria for success have been met – even just one of them -
-- then you will lose marks.

Definitely use audio because number of words is limited.

Plan what you are going to show and say.

Brief sentence of introduction saying in plain English what the application does.

“Explicitly demonstrate and document his or her algorithmic thinking skills”

The video should address the success criteria stated in the planning criterion.

Several “runs” of the program should show different inputs and outputs.

Creation, editing and deletion of one data item, from scratch.

Mention of every success criterion with a demonstration that it has been fulfilled.

Show the testing in the video.

If necessary, cut to example with loads of data already added to show sorting, searching,
filtering, etc.

Mention of key data structures and algorithms.

If relevant, quickly tab to a piece of code in Netbeans to showcase your programming, but if
relevant, quickly tab to a piece of code in Netbeans to showcase your programming, but don’t
trawl through the code – you are supposed to be showing the working product.

CRITERION E
Evaluating the Product
You must provide the details of the client’s evaluation of the product against the success
criteria. This means not just evidence that evaluation has taken place, but a transcript of
interview with the client.

This section requires a strong contribution from the client and the client must comment on
each success criterion separately. It is not enough that the client say that “the success criteria
have been fulfilled.”

Genuine feedback must be provided by the client and evaluation must be based on that
feedback.

Being together testing table (results), success criteria and adviser/client feedback.

To what extent did the product meet the criteria.

“For full marks, evidence of feedback should be included (typically in the appendix) and
referred to in the candidate’s evaluation against the Criteria for Success.”
Recommendations for improving the product
Must be realistic and useful.
Explain why and how these constitute improvements

APPENDICES
Material in the appendix cannot be used to score marks. It is purely supplementary.

All material in the appendix must be referenced in the main body of the report.

“Examiners should not be expected to search through the appendix.”

A fully commented code listing should be present in the appendix and source files should be
supplied in the Product folder.

If you are using Java, then you must provide Javadoc documentation.

At least one comment for every class and method. It’s also good to comment main loops.

Screenshots of class and folder structures in this cannot be determined from either the product
or the documentation.

Additional evidence of the product functioning when this cannot be seen from the version sent
for moderation, for example short video of an interactive website or rendering of an image or
object in software that is not available to the moderator.

It should be noted that any material in an appendix must be clearly reference in the main body
of text.

OTHER POINTS:
Students should include the total number of words on the coversheet.

Note from the recent subject report:

As a general comment, it is recommended that students be encouraged to directly address and
summarize the consultation process and link to the justification and eventual success criteria
and not rely on appendices. The testing table should be directly linked to the success criteria
and the student must include a summary of the feedback that is linked to the evaluation, and
the evaluation should easily be seen to relate to the testing table and success criteria.