IB Higher Level Dossier Requirements

Use stiff (cardboard or plastic) dividers with tabs to separate and label each section.
Your dossier must contain the following sections:
- Preface must contain the following subsections.
  - Preamble
  - Acknowledgements
  - Annotated Bibliography of Material That Influenced This dossier
- Mastery Techniques Specified must contain at least nine of the following eleven subsections.
  1. Insert a new data item into a Linked List.
  2. Delete a data item from a Linked List.
  3. Search for a data item in a Linked List.
  4. Add directly a new record to a File.
  5. Delete directly a record from a File. [Click here for a discussion of this topic.]
  6. Search directly for a record in a File. [Click here for a discussion of this topic.]
  7. Merge two sorted Data structures.
  8. User-defined Functions.
  9. Using Pointers as Parameters.
  10. Recursion.
  11. Using more than one kind of Composite Data Structure.
- Criterion A: Analyzing the Problem
- Criterion B: Documenting the Design Process
- Criterion C: Using Appropriate Data Structures
- Criterion D: Using Efficient Algorithms
- Criterion E: Designing a Testing Strategy
- Criterion F: Annotated Hard Copy of the Test Output
- Criterion G: User-Friendly Features
- Criterion H: Handling Errors
- Criterion I: Implementing the Program
- Criterion J: Using Good Programming Style (Source Code Listing)
- Criterion K: Evaluating solutions
- Criterion L: User Documentation
- Criterion Appendix I: Elaboration on Standards Related To the Substantive Part of Your Dossier
- Criterion Appendix II: Elaboration on Standards Related To Some Technical Part of Your Dossier.
- Index
Compose an attractive Title Page for each section. Include at least one graphic on each title page that is somehow suggestive of the contents of the section identified by that title page.

Mastery Techniques

Do this in a wordprocessor.

Start each technique at the top of a new, separate page.
Use a subheading identifying the technique at the top of a page where a new technique begins.
Leave a blank line and then reference the name of the file, page and line numbers in the source code from which the technique source code will be copied.
Each section of Mastery Techniques should include comments that describe the purpose and use of the technique in the program.
Copy the actual source code illustrating the technique in your program listing from your text file editor and paste it onto the corresponding page in your wordprocessor.
After the source code has been copied to your wordprocessor, don't forget to select and change the font of the source code to a nonproportional font such as Courier New so that the spacing of the original source code will remain intact. (Any text that is not source code may be in a proportional font.)
Create a footer and use the automatic page number function of your wordprocessor to automatically number your pages in your footer. In WordPerfect 10, click on Format --> Page --> Insert Page Number...
Place this section as your second section (just after Preface and before A: Analyzing the Problem

Section A: Analyzing the Problem [3 marks]

The documentation should contain a thorough discussion and analysis of the problem which is being solved. This should concentrate on the problem and the goals which are being set, not on the method of solution. A good analysis includes sample data, information and requests from the intended user, and possibly some background of how the problem has been solved in the past. - Syllabus 2000, page 47.

This should include a brief statement of the problem as seen by the end-user. A discussion of the problem from the end-user's point of view should take place with both the user's input and desired output being considered.

The analysis should state a clear understanding of the problem and demonstrate how the problem can be solved using a computer-based solution. This analysis should also take into account what input and output will occur and what calculations and/or processes will be necessary to obtain the desired output. -- Syllabus 2000, page 55.

Include the analyses that you did prior to developing your source code. This section should include:

A clear indication of how you learned the needs of the potential user(s). Give examples of the sample data that you gathered before you did your program. Examples of sources of sample data are:
- Requests from the intended user.
- A survey or questionnaire administered to one or more potential users.
- Photocopies illustrating fields of a database that already existed that your program will manage. Examples are airline schedules, genealogical databases, horticultural taxonomies.
- Citations of professional prescriptions that your program must adhere to. Examples are accounting conventions, sports formats, national and international rules and regulations.
- Published (textual or electronic) descriptions of data that you, the program's designer, analyze with the intent to design a database and management program. Examples are movies in the Entertainment Section of a local newspaper, comparisons of a range of products sold in local supermarkets, a collection of books discovered in a relative's home, variations in the local weather, various automobiles sold in your city.
Background on how the problem has been solved in the past.
"If I have seen further (than Descartes) it is by standing upon the shoulders of Giants." -- Isaac Newton

Examples of such background are:
- Analyses of noncomputerized products, past and present.
- Analyses of existing computer products. These may be commercial software, shareware, freeware or prior student IB dossiers.

Section B: Documenting the Design Process [6 marks]

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 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 and non-trivial modules, the final stage must be pseudo-code at a level of detail equivalent to PURE. This final state 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 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. -- Syllabus 2000, page 48.

An illustration indicating the top-down design of the solution to the problem should be produced.

Using pseudo-code or other suitable means candidates should created an algorithmic representation of their solution. The algorithms produced should be independent of the target programming language. A programmer using almost any high-level programming language should be able to generate a computer-based solution from the submitted algorithms. Thus, it is imperative that all algorithms/subalgorithms that are essential to the functioning of the resulting program be included. -- Syllabus 2000, page 55.

Documentation must be complete to get 4 out of 6. Furthermore, it must be portable as well to get 6 out of 6.

IB defines complete to mean that "all the relevant decomposition from the problem definition through all stages to the final stage are included." (Syllabus 2000, page 48)

IB defines portable to mean that "the final stage of the design can be coded into more than appropriate modular language." (Syllabus 2000, page 48)

Material that goes in this section includes:

Stepwise Refinement in System Design Specifications.
1. System Objectives.
2. System Context.
3. Functional Requirements, which included the performance subsystem.
4. Quality Requirements.
5. Future Requirements.
Structure Chart(s)
System Flowchart
Object Diagram(s)
UML Diagrams
Pseudo-Code of non-standard and non-trivial modules.
It is not required that your use PURE, but it is recommended that you do so that you will have a high comfort level with it on the IB exams in May.

Pseudocode is structured English that translates easily to a number of different computer programming languages. It should not look like C++ or Pascal or any other particular language.

Students who have a strong distasted for PURE should at least model their pseudocode after an established standard such as that used by Carrano et al in their Walls and Mirrors textbook.

Section C: Using Appropriate Data Structures [3 marks]

Candidates should choose data structures which fully support the data storage requirements of the problem, and which allow clear, efficient algorithms to be written. They need not go beyond the requirements of the syllabus in their quest for the best data structure, nor should they make clumsy choices due to a limited knowledge of the programming language. For example, an array A[1], A[2], ... A[10] is usually preferable to the single variables A1, A2, ... A10. -- Syllabus 2000, page 49.

Data structures that are to be used in the programmed solution to the problem should be discussed here. Some sketches/illustrations must appear in this discussion, including some sample values. -- Syllabus 2000, page 55.

You must indicate the data structures that you used and explain why they were appropriate.

The syllabus says that some sketches/illustrations "must appear" in this section.

Examples of the sort of discussion that should appear are:

A linked list may be more appropriate than a direct access file for searching or other manipulation because the dynamic memory in which a linked list functions is many times faster than the mechanical medium of a disk drive on which a text file functions.
Arrays are more appropriate than atomic variables for processing related ordinal data of the same data type because you can access array data with indices.
Constants are more appropriate than variables for data values that do not change during execution of a program because the compiler will flag erroneous changes of the identifier.
Direct file access is more appropriate (faster) than sequential file access for searching and sorting because direct file access allows access with fewer necessary visits to the data.
A linked list is more appropriate than an array where the maximum size of the data is unknown at compile time because a linked list can change its size dynamically during execution but an array cannot.
C++ structs and classes are more appropriate structures than C-type structs for packaging code because C++ structures allow the programmer to control the way in which a client program or other C++ structure may inspect or modify data in the class or C++ type struct.
C-type strings are more appropriate than a string class for direct access file handling because the size of class strings is dynamic. All direct access file records must be the same size because the formula for locating a record depends upon every record in a file being the same size. Since C-type strings are arrays of characters of a set size, their size may be kept constant.

To get maximum marks, IB insists that "all of the data structures that the candidate uses to solved the problem are appropriate." -- Syllabus 2000, page 49. Give a rationale for every structure used.

Section D: Using Efficient Algorithms [3 marks]

An efficient algorithm is usually one that executes rapidly and requires minimal storage (makes good use of available memory), but it could also refer to one that uses simple programming code. even though it is not faster, a loop for printing 20 numbers is more efficient than 20 print commands, because future modifications in the code will be much easier if a loop is used. Such immense inefficiencies in the code can be considered here. It is not necessary for candidates to present quantitative evidence of the efficiency of their algorithms. -- Syllabus 2000, page 49.

To get maximum marks, IB insists that "all of the algorithms that the candidate uses to solve the problem are efficient. -- Syllabus 2000, page 49.

Indicate the algorithms used in the program and discuss why they are more efficient than other possible less efficient algorithms. For example:

Select sort of a large number of data is more efficient than a binary sort because it is faster. It is faster because there are fewer comparisons.
Iteration is more efficient than recursion in terms of computer resources because less memory is accessed when using iteration. However, recursion is more elegant, that is more efficient in terms of the programmer's time because programmer's think more "naturally" with recursion than iteration.
Direct access file handling is more efficient than sequential access file handling in terms of speed but less efficient in terms of capacity because all records of a direct access file must be the same size, even when that means that a portion of some of the records is empty.

Look up "Big-O" in the indexes of your textbooks, such as page 397 of Walls and Mirrors. The syllabus says that it is not necessary to discuss efficiency in terms of Big-O in the dossier, but is certainly appropriate to do so.

Some online discussion of Big-O will be found by following the following links. Hit several of them and read Walls and MIrrors and you will understand this surprisingly difficult topic.

Click HERE For IBO Direction On Criteria E, F, G and H Taken From Teacher Support Material - Computer Science ©IBO, February 1999, pages C9 - C13.

Section E: Designing A Testing Strategy [3 marks]

Testing should follow a plan. It should never be random but should be thorough, well organized, and well documented. A comprehensive testingstrategy is desired; that is better than an immense number of random test cases. Testing plans should be described and indicate what candidates consider to be typical data and what results are expected. Candidates should also indicate what situations could arise if invalid data is used. This criterion is separate from the hard copy results of the tests. -- Syllabus 2000, page 50.

A strategy for testing the program must be included which specifies how the program is expected to behave when differing sets of valid and invalid data are inputted. Thus, the strategy should include consideration of what happens when various branches of the program are activated and must consider/discuss the consequences of inputting invalid data. To do this, a table of inputs and expected outputs should be submitted for a wide range of valid and invalid data. -- Syllabus 2000, page 56.

You must outline a "wide range of valid data" as well as "some invalid data".

Section F: Including an Annotated Hard Copy of the Test Output [3 marks]

The hard copy of test output should demonstrate the implementation of a thorough testing strategy (as indicated by criterion E). It may not be feasible to supply sample output for every single test-case in the testing plan - indeed, a procedure may be designed to automate the testing process and may run many millions of tests. However, at least a representative sample of the test-cases must be presented as sample runs. The output should cover the entire range of test-cases (both valid and invalid data) in the testing plan, and should be presented in an organized fashion (e.g. annotated). The teacher must confirm that each candidate has actually completed the testing as claimed in the documentation. (See Vade Mecum.) -- Syllabus 2000, page 50.

Section G: Incorporating User-friendly Features [2 marks]

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. -- Syllabus 2000, page 50.

Evidence of User Friendliness

Evidence of helpful menus, instructions, etc. that will aid the user in navigating through their program must be highlighted. This can be done in the following three ways:

by annotating relevant parts of the hard copy output
by annotating parts of the program code that generate menus and instructions
by reproducing (cut/paste) relevant parts of the hard copy output and/or by reproducing parts of the program code that generate the menus and instructions.

The length of this documentation will depend to a great extent on how much interaction there is between the program and the user. -- Syllabus 2000, page 56.

Section H: Handling Errors [2 marks]

Provide annotated screen dumps of all types of conceivable errors together with the program's response. Ensure that all screen dumps contain contextual explanations of what is happening in the screen dump. Explain the obvious, for what is "obvious" to the designer may well be invisible to the peruser.

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. -- Syllabus 2000, page 51.

Error handling facilities can be highlighted in the following two ways:

by annotating parts of the program code that contain error handling routines
reproducing (cut/paste) parts of the program code that contain error handling routines together with the relevant parts of the hard copy output.

-- Syllabus 2000, page 56.

The hard copy output should demonstrate the implementation of the testing strategy. One or more sample runs should be included to show that the different branches of the program have been tested; testing one set of valid data will not be sufficient. The hard copy submitted should demonstrate the program's responses to inappropriate or erroneous data, as well as to valid data. Thus the usefulness of the error-handling routines mentioned above should become evident. While at least one complete test run must be included in the dossier, it is not necessary that the hard copy reflect every key stroke of every test run. Cutting and pasting of additional test runs can be done to illustrate the testing of different aspects of the program.

"All test runs should be annotated in such a way that the candidate is stating what aspect of the program is being tested. Sample output must never be altered by hand, erased or covered up." (Emphasis Added)

Sample output can be 'captured' and combined electronically with explanatory annotations into a single document. However, it is forbidden to alter or reformat sample output in any fashion (except adding page numbers or annotating in order to highlight user friendliness or error-handling facilities as discussed above), especially if these alterations would give an unrealistic impression of the performance of the program. Examples of such 'abuse' include: lining up text which was not originally aligned, adding colour or other special effects, changing incorrect numerical output, erasing evidence of errors. -- Syllabus 2000, pages 56-57.

Section I: Implementing the Program [2 marks]

Provide annotated screen dumps of "typical" test runs. Demonstrate that sequencing corresponds precisely to the original functional specifications by labelling each screen shot with the functional specification.

Evidence here generally refers to hard copy output. Also, the design process should have been sufficiently thorough so that the resulting program has not had to be drastically restructured during the debugging phase. -- Syllabus 2000, page 52. -- Syllabus 2000, page 52.

Section J: Using Good Programming Style [2 marks]

Finish all source code and internal documentation.
- Ensure that all functions are separated into separate documentation (*.h) and implementation (*.cpp) files.
- Ensure that the documentation of all functions includes the function's purpose, preconditions and postconditions.
- Ensure that the beginning of every file of source code contains an identification header similar to the following.
```
/*==============================================================================

    File:      artdriv.cpp

    Purpose:   Demonstrates the construction of a menu that calls functions.

    Author:    Ayebee Wannabe

    School:    Sir Winston Churchill High School, Calgary, Alberta, Canada

    Teacher:   Mr. Gerry Donaldson

    Language:  Dev-C++ 4.01 using the MinGW (Minimalist GNU for Windows) compiler
    Target:    Real Mode Application (DOS)
    System:    AMD Athlon, 1100 MHz Running Under Windows 2000

    This Revision:  June 7, 2000

==============================================================================*/
```
- All modules (C++ functions) must be "small and clearly structured ...." (Syllabus 2000, p. 52)
- All identifier names must be "meaningful". (Syllabus 2000, p. 52)
- There must be a consistent indentations scheme. (Syllabus 2000, p. 52) This includes:
  - indenting about 2-3 spaces within blocks of code,
  - blank lines or a commented pattern between significant blocks of code, such as the ending of one function and the beginning of another, before the beginning and after the end of a loop, before the beginning and after the end of a switch statement, et cetera.
- Use syntax highlighting. (Suggested but not required in Syllabus 2000, p. 52)
- Use an IDE that numbers all lines. (Suggested but not required in Syllabus 2000, p. 52)
- Print your source code. Both Borland C++ 5.02 and Dev-C++ 4.01 support the following requirements.
  - Set the font size at 10 points using a non-proportional font such as Courier New.
  - Insert header(s) and/or footer(s) that incorporate the file names, dates and page numbers.
  - The pages should be numbered sequentially within each section of the dossier.
    It may be that you will have to neatly print the page numbers by hand because IDE printing functions cause each file to begin page numbering at page 1, but it is important that there be only one set of page numbers in each section; for example: J-1, J-2, J-3, et cetera.
    
    Alternatively, though it be cumbersome, you can print only the page numbers with a wordprocessor after printing the source code from an IDE without page numbers. You thus print the same pages twice: once from the IDE to get the source code with line numbers and syntax highlighting, and a second time using a wordprocessor to get the page numbers at the bottom of the page.
  - Use "syntax highlighting". Set font properties to emphasize different parts of syntax.
  - Set printing to wrap lines rather than truncate them, but that is the second best option. You should manually structure your code so that lines do not exceed the right margin.

Place the source code listing here. Readability and understandability are the objectives. Clarity, structure, and internal documentation determine how well this section is done. This section has been addressed extensively elsewhere.

Good programming style can be demonstrated by program listings which are easily readable, even by a programmer who has never used the program. This includes small and clearly structured modules which have abundant comments, meaningful identifier names, and a consistent indentation scheme. Convoluted, confusing syntax should be avoided whenever possible. Syntax highlighting and line numbering are not required, but are encouraged if they improve readability. -- Syllabus 2000, page 52.
The program should demonstrate the use of good programming techniques. It should include:

an identification header indicating the program name
author
school
computer used programming language used
date
purpose.

The program should possess good internal documentation, including:

constant, type and variable declarations which should have explanatory comments
identifiers which should have appropriate names
program and subprogram names which should be easy to identify
subprograms which must be clearly separated and have comments for their parameters
suitable indentation which should be used to illustrate various programming constructs.

The program should demonstrate a knowledgeable use of the various programming concepts (branching, iteration, etc.) that are required. Parameters should always be used appropriately, for example, to avoid side effects nonlocals should not be referenced within a subprogram.

Program listings must contain all the code written by candidates and, if a program listing displays code which was automatically generated by the development system, then this code must be clearly identified and distinguishable from that code written by the candidates. Only the code designed and written by candidates must be taken into account when applying the assessment criteria. -- Syllabus 2000, page 57.

Section K: Evaluating Solutions [3 marks]

Refer back to the analysis of the problem. State here that you accomplished what you set out to do. Address each of the following areas in separate subsections.

Effectiveness
Efficiency
Improvements and Extensions for Future Development
Alternative Approaches

The conclusion should be a critical analysis of the resulting solution. Efficiency may be discussed in general terms, e.g. BigO notation is not required. Effectiveness should be discussed in relation to the original description of the problem. Suggested improvements and possible extensions should be realistic, e.g. suggestions should not include statements such as "the program would be a lot better if it incorporated some artificial intelligence techniques such as speech recognition and natural language parsing." -- Syllabus 2000, page 53.
Conclusions/Evaluation
This item should include reflections on the effectiveness of the programmed solution of the original problem. It should discuss answers to the following questions:

did it work?
did it work for some data sets, but not others?
does the program in its current form have any limitations?

A thorough evaluation also discusses possible future enhancements that could be made to the program. -- Syllabus 2000, page 58.

Section L: Including User Documentation [2 marks]

State the obvious. Explicate the obscure.
Use screen dumps everywhere!

This is where top students blow the perfect 35. This is the user's "life line" to using your program!

Include the following sections of your user manual as they apply. Include others that you can think of that are not stated below.

Cover Page
Table of Contents (Not of your dossier, but of this User's Manual.)
System Requirements
Installation
Overview
Features
Options
Using Help
How to start up
How to create a record
How to save a record
How to retrieve a record
How to change a record
How to shut down
Technical Information
How and from where to get updated versions
FAQ (Frequently Asked Questions)
Support (Addresses may be but do not need to be real for purposes of this dossier.) Include hours available.
- email address (Reply within 24 hours of receipt.)
- snail address (Reply within 2 days of receipt.)
- phone number (7 am - 6 pm MST)
- fax number (Reply within 2 days of receipt.)
- ICQ# (8 am - 4 pm MST)
- web site
Index (Not of your dossier, but of this User's Manual.)

Good documentation usually includes both sample output and written instructions. It should be sufficiently complete that it will allow anyone unfamiliar with the program to start using it effectively after reading the instructions. This criterion does not refer to internal instruction. -- Syllabus 2000, page 53.
User documentation is a simplified set of instructions designed to help end-users operate the program effectively. In terms of the hardware, this documentation should provide information concerning the minimal computer system configuration necessary. The documentation should include any information required to load, start and run the program. A user must be provided with step-by-step instructions for operating the program, being told clearly:

what inputs are expected during various stages of the program's execution
what outputs can be expected.

-- Syllabus 2000, page 56.

Floppy or CD With Source Code, Data, and Executable Files [0 marks]

This is for Mr. Donaldson. IB only accepts hard copy (paper) evidence of your dossier.

For now your floppy or CD must contain the following files:

source code, project files and related data file(s) of your dossier program such that compilation is "automatic".
executable file(s) and related data file(s) of your dossier program such that execution is "automatic".

Floppy or CD With All Related Dossier Files [0 marks]

The following files are not required at this time, but they must be submitted before the end of the course. You are being informed of this now so that this knowledge might influence the way that you presently organize your files for this future assignment.

As a requirement of Computer Science 35IB, but not as a requirement for your IB Certificate, you will generate a web site presenting your dossier and all its files in various appropriate formats.

The entire dossier as submitted in the binder must be available as a single pdf file.
Source and data files must be in directories appropriate for successful compilation.
- All source code must be saved as appropriate text files: *.h, and *.cpp files.
- All data files must be in directories as specified in the source code.
Executable and data files must be in directories appropriate for successful execution.
All internal links must have relative addresses; not be "hard-wired" to specific directory paths.
Web files should be in homogeneous directories.
- The root directory must contain the index file: index.htm or index.html.
- multimedia files must be organized in directories by their file type. For example, graphics files (*.gif, *jpg) must be separated from other files.
- Source code and/or data files should have their own root directory.

[Home of Gerry Donaldson's Com Sci Gate]

csgate@donaldson.org
ICQ# 62833374

URL: http://donaldson.org/ Last Revised: February 6, 2002