Information Technology (Pat) Assessment Tools

Problem Summary  

A brief description of the project including the purpose of the project, summary of functions and description of target user group(s)  

Motivation and Research  

A brief discussion of similar projects as a result of research. Research is correctly referenced and cited. A motivation is included for the project indicating how this project differs from existing projects. This section should NOT be longer than a page.  

Specification of Interface (including User Interface)

Specify the user interface and if relevant, the input/output from external hardware such as sensors

Interface Design

ALL interfaces linking the program to the outside environment including the user (barring the program's own data storage – this is dealt with in section 2.4 of this mark sheet) must be completely specified in this section. 

Data source and description (e.g. keystroke from user, joystick movement from user, server providing other players' data, temperature gauge providing temperature).

NB: Screen capture from a design tool (including IDE), sketches and mock-ups are acceptable.               No code is needed for this section.   

Program Flow

Describe the flow of events in the program using either flow charts or pseudocode to show how the program works internally in relation to the interface(s)  

Class Design and OOP Principles

The candidates must provide their class design represented as a UML class diagram with class name, fields, and methods demonstrating the application of OOP principles including possible inheritance. Only provide backend classes NOT user interface or GUI classes.

Secondary Storage Design   

Candidate must show how data structure in primary memory described in 2.3 will be permanently stored.

NB: Storage design should be done using tables in a database, text files, JSON files or a combination thereof. For a database, screenshots of tables with record structure and field types from database software are acceptable along with sample data for each table. For text files, an explanation of the structure of the file must be explained together with sample data. Storage can be local, remote or cloud based.  

Explanation of Secondary Storage Design

The candidate must provide an explanation of their secondary storage design. For example, a text file may have been a better solution than a database as the data to be stored is small in value and simple. The explanation must demonstrate a justification of the secondary storage design and an understanding of the implications of the chosen design.  

Explanation of Primary Data Structure related to Secondary Storage

Description of how the primary data structure described in class diagrams (assessed in 2.3) will represent the secondary storage design (assessed in 2.4). There should be a description for each backend class listed in 2.3 that will translate the data to and from secondary storage.  

Comments 

Code is commented using an API and/or comments which are placed inside source code to explain code, parameters and return types. Only backend classes need to have APIs; however all code needs to be commented. Comments need not be provided if descriptive names are used for methods, fields and variables.  

Inter-Code Communication Typed Methods/Functions and Parameters

code communication occurs between classes and within a class between methods.   

Querying and Manipulation of Data in Secondary Storage 

This section refers to the implementation of the primary data structure (section 2.3), the secondary data storage (section 2.4) and the representation of the secondary storage in the primary data structure (section 2.6). 

Defensive Programming 

Data validation, exception handling, error messages – consider all interfacing elements, not just user interface elements.  

Fulfilment of Specifications 

The project must be tested against the functions listed in Appendix B – 1.3 Specifications of Program Function. 

NB: This can only be assessed by running the compiled program. 

User Experience

NB: This can only be assessed by running the compiled program.

Externally Sourced Code  

NB: This must be present even if the candidate only declares that no external code has been used. No more than 20% of the code may be from an external source

Explanation of Critical Algorithms  

NB: The core algorithms that are critical to the correct functioning of the program. There may be only a few, or even only one critical algorithm. 

Programming code is NOT acceptable. Each algorithm must be included and the function of the algorithm explained.  

Advanced Techniques  

Advanced techniques include a minimum of TWO code/algorithm/features that is NOT part of the syllabus. Inheritance and complex SQL with more than three tables may be included.

NB: This must be present even if the candidate only declares that no advanced techniques have been used.  

Evaluation of Solution – against original problem description:  

An objective report on how the solution meets original problem. Should include suggestions on how to address failure if goals are not met. Do not penalise if goals are not met. Award marks for evaluating solution and presenting suggestions for failed solution.

Should the project satisfy all goals, then possible alternate solutions or improvements must be described.  

Functional Testing:  

At least TWO sets of functional testing evident together with the tester's name, the date the testing was performed and the result of each functional test. Each test should indicate whether the project satisfies the functions listed in Appendix B 1.3 Specifications of Program Function.

It is acceptable if some of the functions are not working as long as progression is seen through the testing process.   

Test Plan and Result for TWO input variables

The TWO input variables must be clearly identified. Testing should be done using standard, extreme and abnormal data.

Screenshots showing before and after of each test for each variable must be included .