Programming Project Notes
Programming Project Notes
1.1 Overview
There is no examination for this module and therefore it is tested totally by the submission of documentation.
The documentation should include all 18 sections listed below. These have all been defined more clearly to assist
the candidates and centres in knowing what is required. Candidates must be made aware that the nature of this
documentation makes it almost IMPOSSIBLE TO WRITE UP AFTER ALL THE WORK IS COMPLETED. For instance, the
testing process requires FULL PRINTED EVIDENCE and unless testing is ongoing and systematic, it will be difficult to
produce full documentation later. These notes should be covered in detail as part of class-work and be given to each
candidate when DEVELOPING the programs.
The aim of the project is to test a candidate’s ability to apply programming skills in the development of a REAL situation
(normally related to business) and extend him/herself beyond the classroom programming exercise stage.
The project must produce a working solution to a given problem. This problem should be of a NON-TRIVIAL nature;
avoid projects like payroll which can be very involved. Past projects on payroll have been naïve simplifications,
unrealistic and unworkable in the real world where a commercial payroll package may have hundreds of different
possible and complex adjustments to an employee’s monthly salary.
www.icm.education | [email protected]
1.3 Documentation and assessment
The following list gives indications of important areas to consider and the marks that will be available for each section.
Marks Explanation
1. 5 Definition of the problem and limitations of the programs. ALL programs have limitations and never
completely solve the problem – identify these. Explain WHY the program is being written and for whom.
DO NOT include a list of thanks to tutors/friends etc - this has nothing to do with the running of the
program, wastes time and will be ignored.
2. 5 Objectives of the program. This is not asking for AIMS. Objectives are measurable. A program either
produces an invoice or it does not. AIMS such as “to make the data entry easy for the user” are not
measurable and therefore should not be included.
3. 10 Analysis of the current situation. Explain in detail how the current system works. Include its
shortcomings and any additional user needs.
4. 5 Alternative solutions. Identify alternative ways in which the problem could be solved. Some alternative
ways are listed below but they need to be fully explained and justified:
i buy a ready written package (if it exists – so you must identify it). Why write payroll programs when a
package can be bought cheaply and working within hours? This is almost certainly the cheapest method
and so there must be good reasons to reject it.
ii develop using a database system.
iii develop in one of several languages.
State why your chosen method IS the most appropriate and why the others are rejected.
5. 10 Data input. List in data entry order, the specifications of each data set. It is useful to give each data set
a meaningful name – e.g. 1. customer registration data. Data should be treated as a group of fields rather
than many single items – e.g. all data for customer registration data or all data for an order item. For each
field in each data set, include (i) fieldname, (ii) data type, (iii) any restrictions on it and (iv) full validation. A
standard form could be devised.
6. 10 Output. Show a sample of every type of output whether on screen or on the printer. If the project is over-
complex, this could present a real problem.
7. 10 Files. Identify all files involved. For each file state:
(i) filename (ii) method or organisation (iii) method of access – there may be more than one access method
depending on which aspect of the processing is used – differentiate between these clearly (iv) fieldnames
(v) datatypes of each field (vi) field size. These last three items canbest be tabulated in a standard form.
8. 15 Process specification. Describe ALL the processes in turn. For each state:
(i) its purpose (ii) name the data input and output produced (iii) files involved and how each are accessed
for THIS process (iv) where this process occurs in relation to others – e.g. after A and before C where A
and C are named processes.
9. 20 Algorithm. This must use a structured approach. More emphasis will be placed on this section for projects
where some of the code is produced automatically by the system. Pseudo-code is preferred.
10. 20 Annotated structured listing. A full listing of the code should be given. It should follow the algorithm
CLOSELY. The code should contain the programmer’s notes to explain how a particular feature is
performed. Hand written comments should be added if these notes are incomplete. Program syntax
must be totally correct. Any syntax errors will invalidate any testing applicable to that section of code and
testing marks WILL BE REDUCED.
11. 5 Variables list. This must include EVERY variable used in the program except those input from fields of
a file. Each must show (i) which module/section uses that variable, (ii) variable type (iii) size (iv) why it is
needed. AVOID statements like “To hold customer number”. Every variable “holds” something and in this
case, WHY does the program need to have the customer number?- this is the reason for the variable’s
www.icm.education | [email protected]
existence. There should be some system in your list – list either by program module/section (this may
result in duplication) or perhaps alphabetical (but this must then show which module(s) use the variable).
12. 5 Test Plan. This is an outline showing the order in which processes/sections of code are tested. For
instance ADD A NEW CUSTOMER should be fully tested before attempting any orders for that customer,
amending customer details and certainly before deleting a customer record. Number each proposed test
for easy cross-referencing.
13. 15 Test Data. This MUST be comprehensive. Unless a significant number of data records are on file, the
testing will not show how a particular record is located or allow for multiple items such as a customer
ordering many different products. For each set of data, explain WHY it is present. e.g. If discounts are
offered, then there must clearly be data to test for a customer who earns (i) NO discount, (ii) discount at
one level (iii) discount at higher levels. In addition the test data must ensure that discounting does kick in
at the right point by having test data AT the changeover point and immediately below it. Cross-reference
each set to the Test Plan.
Testing must be FULLY documented. No documented testing will lose ALL the marks allocated for
sections 12,13, 14 and 15 – nearly 25% of the project.
14. 20 Testing. Include printed evidence for ALL significant tests (see the notes for section 15). For each output,
write in by hand, (i) a brief explanation of the purpose of the test (ii) cross reference to the test plan (iii)
mark/comment on printouts of all items which are correct and which were not previously tested (iv) mark/
comment on all items which are incorrect. For screen outputs, produce screen prints. For instance, as a
guide, to show that a new customer has been added to a file, produce a suitable report BEFORE the new
customer showing the customer details NOT present and the same print after the new customer has been
added – highlight the differences by hand with a brief comment.
15. 5 Log of Testing. After each test, record in table form, (i) date and time (ii) the test being performed (cross-
referenced to the Test Plan) (iii) the outcome of the test – either faults or processing assessed as being
correct (iv) first thoughts about the remedy for correcting any observed fault.
NOTE: It is not wrong to have tests which fail – all professional programmers make mistakes or overlook
some feature. It IS however wrong to ignore faults that occur. There is no need to record details of a test
that is a complete failure if this test is immediately followed by one that corrects some of these problems.
Past test logs seem to show the candidate as being a brilliant programmer - the whole program completed
in three runs and no errors! Is this likely?
16. 25 User manual. This should ideally be a SELF CONTAINED SECTION of the documentation describing (i)
the program in outline, (ii) its options and limitations, (iii) sample inputs and outputs (iv) errors/problems
which could occur and how to rectify them (v) operating instructions. If any part of this user manual
should ALSO be elsewhere in the whole documentation, it MUST be here but in its other locations, a cross
reference to the page number in the user manual can be given.
17. 10 Technical Documentation. This is for the maintenance programmer and relates to (i) any special methods
employed, (ii) formulae used, (iii) data structures used such as matrices/linked lists, (iv) comments about
the use of files, (v) back up procedures.
18. 5 Appraisals. This can be in two forms. If the program has been written for another user, that user should
give a CRITICAL appraisal of its use and any problems should be noted. It there is no available end-user,
the candidate can perform a self-appraisal but it must be CRITICAL. Are (i) there any features which
could be added later or improved further, (ii) any features still not working etc... This appraisal is about the
program, not the process of developing it so do not include problems you had with machine access etc.
A claim that the program works fully will be discounted if there is no testing to prove it. In short, writing a
few sentences to fill in this section is pointless unless it says something meaningful.
TOTAL 200 marks which will be halved to produce a percentage.
www.icm.education | [email protected]
1.4 OVERALL COMMENT
The candidate will gain more credit and marks for an honest assessment which shows that problems/errors have
occurred and the steps taken to put them right. This still applies if the submitted project still has some logic errors and
therefore only some of the submitted project is completed. This recognises that the creation of programs is not an exact
science but requires means of putting things right. A candidate who appears to claim that everything works first time is
not showing recognition of this process. There is also no point including sections of documentation that state very little
and are merely there to try to satisfy the examiner.
Note that the user manual should be self-contained. It need not be detachable but the pages, if given to the user, would
be all that the user needed. Therefore, other parts of the documentation should cross-reference into the user manual.
1.5 FORMS
Forms can be used to describe many items in this documentation. This can either be created by the candidate or
supplied by the centre itself. However, if a centre-supplied form is not as appropriate as it should be perhaps because it
was designed for a slightly different purpose, then the candidate should adapt it or design his/her own form.
www.icm.education | [email protected]