Aqua and lime text is authored
by Mr. Donaldson.
Gold text is authored by IBO.
On Tuesday, February 12, 2002, this topic was discussed in great detail by Mr. Donaldson with his senior IB Higher Level Computer Science students of that year. Issues addressed by the IBO document of February, 2000, were debated. Mr. Donaldson's observations from that time morphed with his later revisions of February 20, 2004 are inserted below.
At Higher Level, the Mastery of Aspects part of the Internal Assessment requires candidates to be able to manipulate files directly.
Candidates must attempt to show mastery of the following aspects:
To satisfy these requirements, candidates must carry out file manipulation in such a way that files do not need to be read into RAM for manipulation.
For example, the record to be deleted must be found directly by searching the file in its actual location (by, for example, using a binary or linear search, reading a record, or small block of records, at once). The record could then be directly deleted (if the programming language supports this), or marked for deletion by using a flag field, or by using a rogue value in the key field.
Provided the file size alters, or a record marked for deletion is actually overwritten during the addition of new records, this manipulation would meet the requirement.
However, it is not acceptable, for example, to delete a record from a file, to read the whole file into a linked list or tree, to delete the node, and then to write the data back to the file. (However, this manipulation would satisfy the requirement of being able to delete a data item from a linked list or tree.) Similarly, when directly adding new records to a file, it is not acceptable to read the file into RAM, add the data, and rewrite the file.
To meet the requirements of the Mastery of Aspects for Higher Level, direct manipulation of files must be carried out in such a way that the whole file does not need to be read into RAM.
Criterion G states:
Candidates should give attention to issues of usability during the design stage. The documentation should include some explanations. of the reasons for some of the usability decisions. To be given credit candidates must include features which make the program more user-friendly, such as helpful menus, help instructions, useful guidance to the user during the execution of the program. These should be documented in some way, for example, if an output screen is particularly well designed for readability a hard copy should be provided and labelled as such. Screen dumps and even photographs may be helpful for this criterion.
This criterion refers to the user interface which the program presents to the user (for example, menus and help instructions, rather than internal error checking).
Criterion H states:
This refers to detecting and rejecting erroneous data input from the user, and preventing common run-time errors caused by calculations and data-file errors. Candidates are not expected to detect or correct intermittent or fatal hardware errors such as paper-out signals from the printer, or damaged disk drives, or to prevent data-loss during a power outage.
For this criterion, candidates must attempt to trap as many errors as possible.
If, the candidate's dossier genuinely has no need of error trapping (including no data input), and this is clearly documented and justified, the candidate can reach Achievement Level 2.
However, if the candidate's claim is incorrect (for example, the program accesses a file but there is no test to check that the file exists before access to it is attempted), a high score cannot be achieved.
The documentation in the dossier can take a variety of forms. For example, it could be a table with two columns, one which identifies any error possibilities, and one which shows the steps taken to trap the errors.
Criterion B states:
The solution to the problem should be thoroughly designed before any programs are written, and this design process must be documented. Good top-down design results in a flexible, general, extensible solution. In this category, both the quality of the resulting design and the design process are being evaluated. The design must include a detailed representation of the algorithms used (via pseudo-code, structure diagrams, etc.) that clearly illustrate the candidate's solution.
Top-down analysis (solution decomposition) means breaking down a problem into smaller problems. These are then broken down in turn until ultimately a pseudo-code representation is obtained which can be used as a basis for program construction. It is appropriate to use diagrams for the early stages. However, for the non-standard or non-trivial modules, the final stage must be pseudo-code at a level of detail equivalent to PURE. This final stage of design should lead easily into coding in an appropriate programming language. For example, an object-oriented design should be able to be coded into several object-oriented languages, whereas a procedure-oriented design should be able to be coded into any one of several block-structured languages.
This criterion refers to the documentation of the design process which does not include the final program listing.
|Incomplete||The first and last stages of a design and one or two stages in-between are included, but the design still contains obvious gaps.|
|Complete||All the relevant decomposition from the problem definition through all stages to the final stage are included.|
|Non-portable||The final stage of the design clearly demands the target programming language used by the candidate.|
|Portable||The final stage of the design can be coded into more than one appropriate modular language.|
For this criterion, candidates must explain the links between the levels of design to guide the reader through the design process.
Candidates must also document their dossiers thoroughly. To show mastery of an aspect, it is not sufficient if candidates only use it within a program: in the written documentation, candidates must include information about why a particular data structure is appropriate, how it is used (for example, how nodes are added, deleted and searched for) and where it is used in the program. In other words, candidates must provide cross-references between the documentation and specific procedures within the program.
If teachers add comments to dossiers as well as marking them, ready for moderation, this facilitates the moderation process. In addition, if teachers write a report for each candidate which justifies the Achievement Level awarded for each criterion, this also will facilitate the moderation process and make the feedback forms from the moderator more focused.