IB COMPUTER SCIENCE: The Program Dossier


Introduction

The program dossier is an individual piece of work completed during the course. It must address a single problem that can be solved using computer systems and which has an identified end- user. Your analysis, design and production of the final system must be well documented. You must use a logical approach and analytical thinking, from definition and decomposition of the problem through to its solution by constructing appropriate classes implementing algorithms and data structures in Java. The dossier is internally assessed by RJo and externally moderated by the IBO.

Time allowed

Times quoted here are recommended teacher contact time and do not include the time required by you to work on your own to develop and complete your dossier:

Choice of problem

Approach

The work on your dossier falls into four main stages:

  1. Analysis (completed by end of spring term Y12)
  2. Detailed design (completed by end of summer term Y12)
  3. The program (completed by end of automn term Y13)
  4. Documentation (completed by half term of spring term Y13).

You will complete these stages in order, although it may occasionally be necessary for you to return from (c) to (b) one or more times to refine your detailed design in a spiral of design and development (this will depend on the nature of your problem, open or closed). You are free to choose your design methodology (structured, top-down or object-oriented), try to choose one that is flexible and extensible. Retain design documentation from earlier stages to present as evidence in the final dossier. The rough deadlines given will vary from year to year.

Format

Program dossier templete >>

Assessment criteria

You are assessed against criteria, not against each other.

  1. Analysis
    1. Analysing the problem
      A thorough discussion of the problem that is being solved. You should concentrate on the problem and the goals that are being set, not on the method of solution. A good analysis includes information such as sample data, information and requests from the identified end-user, and possibly some background of how the problem has been solved in the past.
      This section of the program dossier would typically be two to three pages in length. It 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, including the user’s needs, required input and required output. For example, evidence could be sample data, interviews and so on, and could be placed in an appendix.
    2. Criteria for success
      Cclearly state the objectives/goals of the solution to the problem.
      This section would typically be one to two pages in length. Objectives should include minimum performance and usability. These criteria for success will be referred to in subsequent criteria, for example criterion C3 (Success of the program) and D2 (Evaluating solutions).
    3. Prototype solution
      The prototype solution must be preceded by an initial design for some of the main objectives that were determined to be the criteria for success. A prototype of the solution should be created. A prototype is the construction of a simple version of the solution that is used as part of the design process to demonstrate how the system will work. The prototype need not be functional, it could be constructed using a number of tools such as presentation software (e.g. PowerPoint), mind mapping or other graphics application for a simple Java program. The intent is to show the user how the system is expected to operate, what inputs are required and what outputs will be produced. A number of screenshots will be required for the user to be able to evaluate the solution properly. The prototype, at its simplest, could be a series of clear, computer-generated drawings, a hierarchical outline of features in text mode, or a series of screenshots. Documentation of user feedback could be, for example, a report of the user’s comments on the prototype.
  2. Detailed design
    1. Data structures
      You should choose data structures, at the design stage, that fully support the data-storage requirements of the problem, and that allow clear, efficient algorithms to be written. The data structures must fully support the objectives of the solution (criterion A2). The classes chosen should be logical in that the data is sensible for the objects in question and the methods are appropriate for the data given. This section of the program dossier could include class definitions, file structures, abstract data types (particularly at higher level) and some consideration of alternatives.
      This section would typically be two to five pages in length. Data structures and data members that are to be used in the programmed solution should be discussed here. Sample data, sketches/illustrations, including discussion of the way data objects will be changed during program execution should be demonstrated to achieve a level 3 in criterion B1.
    2. Algorithms
      You should choose algorithms, at the design stage, that fully support the processes needed to achieve the objectives of the solution (criterion A2), and provide sufficient support for the required data structures. The classes chosen should be logical in that the methods are appropriate for the data given. You must include parameters and return values.
      This section would typically be two to five pages in length. It can be a list or outline of all the algorithms, presented as text, possibly in outline format. Standard algorithms (such as search or sort) can simply be named (with parameters), but non-standard algorithms must be described in more detail.
    3. Modular organization
      You should choose modules, at the design stage, that incorporate the data structures and methods required for the solution (criteria B1 and B2) in a logical way. The data structures must fully support the objectives of the solution (criterion A2). You must present this organization in a structured way that clearly shows connections between modules (hierarchical decomposition or class dependencies). The connections between modules, algorithms and data structures must also be presented.
      This section would typically be three to five pages in length. A variety of presentations are possible here. Some possibilities are:
      • a top-down hierarchical decomposition chart containing the names of modules, showing connections between modules and showing details of which data structures and methods are connected with (or part of) which modules;
      • a text outline showing hierarchical decomposition (equivalent to above)
      • a hard copy of CRC cards showing dependencies between collaborating classes, with details of which data structures and methods are connected with (or part of) which classes.

      The design is assessed independently from the programming stage (stage C). The design should be complete, logical and usable, but you may deviate from it or expand it during stage (c), without penalty.
  3. The program
    1. Using good programming style
      Program listings must contain all the code written by you and, if a program listing displays code that was automatically generated by the development system or copied from another source, then this code must be clearly identified and distinguishable from that code written by you. Only the code designed and written by you can be taken into account.
      Good programming style can be demonstrated by program listings that are easily readable, even by a programmer who has never used the program. These would include small and clearly structured Java methods, sufficient and appropriate comments, meaningful identifier names and a consistent indentation scheme.
      A typical program should be approximately 1,000–3,000 (HL) or 500–2,000 (SL) lines of code in length. Comments should be included to describe the purpose and parameters of each method, and also when code is difficult to understand. The program should demonstrate the use of good programming techniques. It should include:
      • an identification header indicating the program name;
      • author, date, schoo;
      • computer used, IDE used, purpose.

      The program should possess good internal documentation, including:
      • constant, type and variable declarations that should have explanatory comments;
      • identifiers with meaningful names;
      • objects that are clearly separated and have comments for their parameters;
      • suitable indentation that illustrates various programming constructs.

      Generally, you will get achievement level 2 where two of these have been demonstrated, then achievement level 3 for three.
    2. Handling errors
      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. You 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.
      This section would typically be one to two pages in length. For this criterion, you must attempt to trap as many errors as possible. The documentation in the dossier can take a variety of forms. For example, you could highlight relevant comments within the program listing or they could produce a table with two columns, one you identifies any error possibilities, and one that shows the steps you took to trap the errors. It is not expected that you produce extra output for this section.
    3. Success of the program
      Evidence here will be from the hard copy output for criterion D1. We will run the program together to confirm that the program functions, and that it produces the hard copy output you have submitted with the program dossier.
  4. Documentation
    1. Including an annotated hard copy of the test output
      Your hard copy of test output should demonstrate that the program fulfills the criteria for success in criterion A2. The output must be annotated (this may be done by hand).

      Hard copy output from 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 should be done to illustrate the testing of different aspects of the program.
      All test runs should be annotated in such a way that you are stating what aspect of the program is being tested. Sample output must never be altered by hand, erased or covered up. 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 to add page numbers or annotate in order to highlight user friendliness or error-handling facilities, especially if these alterations would give an unrealistic impression of the performance of the program. Examples of such “abuse” include: lining up text that was not originally aligned; adding colour or other special effects; changing incorrect numerical output; erasing evidence of errors.
    2. Evaluating solutions
      The evaluation/conclusion section should be a critical analysis of the resulting solution. Effectiveness should be discussed in relation to the original description of the problem and the criteria for success that were stated in criterion A2. Efficiency may be discussed in general terms, for example BigO notation is not required. Suggested improvements and possible extensions should be realistic, for example 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.
      This section of the dossier would typically be two pages in length. The evaluation/conclusion 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 address the criteria for success?
      • Did it work for some data sets, but not others?
      • Does the program in its current form have any limitations?
      • What additional features could the program have?
      • Was the initial design appropriate?

      A thorough evaluation should also discuss possible future enhancements that could be made to the program.
  5. Holistic approach
    1. Holistic approach to the dossier
      The program dossier should be an ongoing process involving consultation between the you and me. You should be aware of the expectations on you from the beginning of the process and proactively seek feedback.
      In order to obtain the highest achievement level for this criterion you should have excelled in areas such as:
      • actively participating at all stages of the development of the dossier;
      • demonstrating a full understanding of the concepts associated with your dossier;
      • demonstrating initiative;
      • demonstrating perseverance;
      • showing insight;
      • preparing well to meet deadlines set by me.

      This list is not exhaustive.

Program dossier marksheet >>

Mastery

You must show mastery of various aspects of Java by documenting evidence in your program dossier.

  1. Standard level
    To achieve a mastery factor of 1.0, you must have mastered at least 10 of the following 15 aspects:
    1. Arrays.
    2. User-defined objects.
    3. Objects as data records.
    4. Simple selection (if...else).
    5. Complex selection (nested if, if with multiple conditions or switch).
    6. Loops.
    7. Nested loops.
    8. User-defined methods.
    9. User-defined methods with parameters (the parameters have to be useful and used within the method body).
    10. User-defined methods with appropriate return values (primitives or objects).
    11. Sorting.
    12. Searching.
    13. File I/O.
    14. Use of additional libraries (such as utilities and graphical libraries not included in the IBO libraries).
    15. Use of sentinels or flags.

    A list of 15 from which you must use 10 provides you with the option to choose algorithms and data structures appropriate to the problem rather than contriving a solution to fit the mastery aspects. Where one aspect includes others, all are credited, for example aspect 10 will also satisfy aspects 8 and 9 (always provided that the use is non-trivial, well-documented and appropriate).

    An example of an SL project - The DVD Shop.

  2. Higher Level
    To achieve a mastery factor of 1.0, you must have mastered at least 10 of the following 19 aspects:
    1. Adding data to an instance of the RandomAccessFile class by direct manipulation of the file pointer using the seek method.
    2. Deleting data from an instance of the RandomAccessFile class by direct manipulation of the file pointer using the seek method. (Data primitives or objects may be shuffled or marked as deleted by use of a flag field, therefore files may be ordered or unordered).
    3. Searching for specified data in a file.
    4. Recursion.
    5. Merging two or more sorted data structures
    6. Polymorphism.
    7. Inheritance.
    8. Encapsulation
    9. Parsing a text file or other data stream
    10. Implementing a hierarchical composite data structure. A composite data structure in this definition is a class implementing a record style data structure. A hierarchical composite data structure is one that contains more than one element and at least one of the elements is a composite data structure. Examples are, an array or linked list of records, a record that has one field that is another record, or an array.
    11. The use of any five standard level mastery factors (this can be applied only once
    12. Up to four aspects can be awarded for the implementation of abstract data types (ADT's).
    13. ADT 2
    14. ADT3
    15. ADT4
    16. Use of additional libraries (such as utilities and graphical libraries not included in syllabus appendix 2 Java Examination Tool Subsets).
    17. Inserting data into an ordered sequential file without reading the entire file into RAM.
    18. Deleting data from a sequential file without reading the entire file into RAM.
    19. Arrays of two or more dimensions.

    Where one aspect includes others, all are credited (always provided that the use is non-trivial, well documented and appropriate).

    An example of an HL project - Air Traffic Control.


4/1/10 9:09 PM - @ The International School of Toulouse.