D05 PROGRAMMING PROJECT

Prerequisites None beyond those required for any student undertaking the Diploma Course.

Assessment By the submission of a fully-tested and documented suite of programs as detailed in this syllabus.

When a candidate is studying with a School/College then his/her project will be assessed by that School/College in accordance with the details contained herein. Where candidates are studying by Correspondence or by Self-Study, they should use the facilities of a Professional or Educational Institution in order to complete their projects and then the assessment would be carried out by such an Institution. In extremis, the candidate may submit his/her project direct to IMIS for marking; this should be considered as a last resort only, because additional time would be required during which IMIS would have the suite of programs assessed.

1. To demonstrate competence in the use of a procedural programming language.
2. To analyse a business problem and to develop an appropriate solution to it using the chosen programming language.
3. To demonstrate the use of a variety of techniques for testing and debugging programs. These should include the use of test plans for valid and invalid data, and the use of trace techniques to monitor the values of variables.
4. To demonstrate an awareness of the importance of program and of system testing to ensure that each program and also the suite of programs function correctly under all conditions.
5. To produce documentation, both user and technical, to support the suite of programs.
6. To evaluate the final solution to the business problem.

It is the responsibility of the School/College to submit to IMIS the full specifications for the project(s) to be undertaken by their students. A typical specification will consist of the following:

1. An overview of the business problem to be solved.

2. An indication of the size of the problem e.g. number of customers, types of data items etc.

3. A description of any special processing requirements e.g. stock replenishment formulae.

4. An indication of the method of input and the type of output required.

5. A list of constraints associated with the project e.g. hardware and software to be used, common file structures if linked with another project etc.

6. The procedural language to be used e.g. BASIC, C, COBOL, FORTRAN, MODULA-2, PASCAL, etc.

This specification should be submitted to IMIS Headquarters at the very least six months (preferably longer) before the projects are due to be completed (see below); this is to give time for them to be approved or, where they are not accepted, for adequate feedback to be sent to the School/College.

Schools/Colleges are advised to create a bank of project specifications (after approval for use by the Institute) and to build upon and to use this bank rather than be required to submit new specifications at every examination date. It is not appropriate that candidates from one centre should all be doing the same project, nor is it considered appropriate that candidates should work together - the Project is designed to demonstrate the abilities and the work of each candidate individually. However there may be occasions when one large Project is created which can be segmented into two or more parts without overlap (as with the decomposition of a large system into sub-systems).

Each School/College must supply to the Institute a complete mark allocation for each Project candidate. This should reach the Institute by no later than 15th April (for June examinations) or 15th October (for December examinations). The assessment of the Project (plus an oral presentation) is based upon the following breakdown of marks:-

Approach 15%

Program Development 65%

Documentation 20%

100%

IMIS reserves the right to attend the oral presentation.

Upon receipt of the centre’s mark allocation, IMIS will select which student Projects they wish to inspect and the School/College is responsible for ensuring that the full Project of each selected candidate is sent to IMIS by the fastest possible means. These projects are non-returnable and they must be fully annotated by the local assessor.

At least 20% of the projects undertaken at each centre will be required for this moderation process. Since centres will not have access to the candidate’s examination numbers at the time of submission, the Institute will use both Student number and Examination number as identifiers.

Projects, Test Data and Disks must reach the Institute by the 15th May for June examinations and 15th November for the December examinations.

In order that candidates may have realistic chances of success, they must ensure the following:

1. That their Project matches the specification submitted by their centre to IMIS on their behalf (see Task 1 of Tasks for Examination/Teaching Centres).

2. That their Project specification covers a realistic business application system such as:

2.1 Order Processing

2.2 Sales Accounting

2.3 Sales Analysis

2.4 Customer Billing

2.5 Point-of-Sales Recording

2.6 Telephone Sales Support

2.7 Purchase Accounting and Analysis

2.8 Stock Control and Replenishment

2.9 Production Management

2.10 General Ledger Accounting

2.11 Payroll

3. That the Project demonstrates as many as possible (and at least three) of the following Information Technology concepts:

3.1 Data validation

3.2 File updating

3.3 File sorting

3.4 File merging

3.5 File searching

3.6 File Security

3.7 Use of serial, sequential, indexed sequential and/or random files

3.8 Use of database

3.9 On-line processing

3.10 Screen design

4. That there is a proper design to the Project and this is shown by the use of Jackson Structured Programming (JSP) or by an equivalent method.

5. That there is ample evidence of the planning and control that has gone into the development of the Project.

Tasks for the Candidate

6. That, after coding is completed, there is ample evidence of both program and system testing.

7. That all required documentation is completed.

8. That, upon completion, the following items are available for submission to IMIS:

8.1 System specification - this is a technical document which describes the design of the programs and files.

8.2 Sample input/output - this is a set of examples of input forms and screens and output screens and reports.

8.3 Source coding - this should be the computer print-out lists of all programs and any associated job control procedures.

8.4 File print-outs - this is a listing of the file contents before and after the updating of a master file.

8.5 File print-outs - these are the details of all test data used together with expected and actual out puts resulting from processing.

8.6 User guide - this is to describe how the suite of programs can be installed and operated by the user.

8.7 Project report - this is to describe the approach adopted, methods used, problems encountered and how overcome, and a review of the overall subject of the Project.

Candidates are advised that programming in formal coding languages may take far longer than expected to do effectively. The Project must therefore be well managed in terms of time allocation. It is suggested that candidates allocate an absolute minimum of 120 hours on the Project, spread out over at least 24 weeks.

The following table provides guidelines for the minimum allocation of time:

Problem definition 5

Planning and Control 5

Design 15

Coding 30

Testing 30

Implementation 5

System Documentation 10

User Documentation 10

System Report 10

120

Much importance is attached to ensuring that each candidate has demonstrated good professional practice. In particular, the candidate is expected to approach the Project in a well-structured manner, covering the three inter-related activities of problem definition, problem modelling and the coding and implementation of the problem solution.

The use of structure diagrams, decision tables, structured English etc. are to be encouraged. All programming must be modular, well-structured and suitably annotated. Suites of programs must always be supported by full documentation, suitable for the developer and for the user separately.