‘A’ Level Computing Project (OCR)

Important Note : The advice in this document is my own. It is not an official OCR document. I welcome all corrections, clarifications additions ...
Tim Ault February 2002.

A discussion topic on the Computing Project is here.

Index

Introduction

Definition and Analysis

Design

Software development, testing and implementation

Documentation

Evaluation

Introduction

You have to produce a computerised system to meet the requirements of a "third-party" user.

Third-party means not yourself and not your teacher(s). The third-party is another person who is willing to be involved in the project.

What language does the project have to be in?

The project doesn't have to involve programming. Any computerised system is acceptable. Your project could be in Visual Basic, Pascal, Delphi, C++ , Java or any other language. Many successful projects are done making use of a database management system such as Access, and if you are not seriously into programming, this is probably your best bet. Web-based projects are possible, but you should check with your teacher. A site written only in html is unlikely to get you high marks unless the analysis and design is very thorough, and this is difficult to do. There's no reason why a project shouldn't involve a range of packages and/or programming languages. Solutions to real-life problems often do.

How big does it need to be?

The board used to say that the project should take you 50 hours. In my experience it will take you longer than that. It shouldn’t take you more than 100 hours.

What is the marker looking for?

How well you can analyse the system required by the third-party user, and design, test, implement and document that system to the satisfaction of the user. (More details below).

What books should I read?

It’s well worth reading the chapters on Systems Analysis and Design in Pat Heathcote’s "A Level Computing" and in Ray Bradley’s "Understanding Computer Science for A level". If you're doing a project in Access, you'll find Pat Heathcote's "Successful ICT Projects in Access" very helpful.

What does the third party have to do?

1) Help you in the analysis stage when you find out the user’s requirements

2) Be involved in testing the program and write a short letter giving his/her reaction

3) Evaluate the final program to say to what degree it achieves its objectives. Again you will need to ask him/her to write a short letter.

Where can I find more information?

There is a lot of information about the projects in the purple specification booklet. The specification is also available on the OCR web site Computing page.

If you have other questions, ask your teacher for advice.

What needs to be in a project

Your project needs to be in the form of a report. This means that you are meant to take a step back from your project before you hand it in, and assess how well you have achieved what you set out to achieve, and how satisfied the user is with the computer system you have produced.

The report should be in 5 sections:

a) definition and analysis 25 marks

b) design 21 marks

c) software development, testing and implementation 35 marks

d) documentation 24 marks

e) evaluation 15 marks

total 120 marks

The project is 40% of the A2 which is 20% of the whole A level. A high mark in the project is the key to getting a final grade you are happy with. To get a good project mark, what’s needed is determination and organisation. (Ability to program or use a package helps a bit too!). If you ask for advice from your teacher, and plan your time so that you don’t end up trying to do everything in a rush at the last minute, you can do well.

Recommendations

• do a work plan – set yourself some deadlines so that you’ll know if you start to get behind
• keep a log of your progress and any problems you come up against. You’ll find this useful in c iii)
• do diagrams by hand if you like, so long as they are clear
• annotate (write on) your work to make it clear;
• check the spelling, punctuation and grammar of all documentation, especially the user guide
• the structure of your project should follow the sections listed above (where possible). This will make your project easy to mark and will make sure that you are given credit for work you have done. Make sure that the start of each section is clear (use large font, bold etc.).
• do an index - it’s OK to hand number the pages. Do this last!
• keep copies of your work in several places (hard disk, floppy disk, home/college).
• Try to finish your project before the due date. Then you will have time to read through this document again and fill in anything you have missed out!

a) definition and analysis

i) Nature of the problem 5 marks

This is the problem definition stage. Here you should describe the problem which you intend to overcome. The document you produce at this stage is sometimes called the "Terms of Reference".

Describe the organisation. (firm, business, etc.). Describe what they do.

Describe the current methods used in the area which you are concentrating on. (i.e. Describe the current system which you are planning to enhance or replace).

You should clearly state the origins and form of data. (i.e. Where does the data come from? Is it on pieces of paper or on microfilm, or does it arrive via a telephone conversation which is written down? etc.)

ii) Investigation and analysis 20 marks

You need to interview the user(s) to find out what system they want you to produce. You can ask a variety of questions, but make sure to include detailed questions about the data which the system needs to store. You need to record how you obtained this information - include an account of the questions/ answers at the interview(s) or a transcript of the important parts of the interview (if you were able to record it). It’s a good idea to summarise what you learnt from the interview(s).

From your interview you should begin to have an idea of how your system will work. In the analysis section you need to discuss the user’s requirements in detail. You should now be beginning to form ideas about how to meet their requirements, and you should document how you intend to do this. It doesn’t matter at all if your ideas develop as you work on them – in fact this is a good thing, and the more evidence you can provide of this the better! The examiners are looking for evidence that you have tried hard to find out what sort of system the user wants. The more you can involve the user in your developing ideas the better. Some good projects involve 3 or more mini-interviews in which you and the user develop ideas together. For example: Most projects involve screens and reports and you could work on designs for these together. Use diagrams to express your ideas as much as you can. (system flowcharts, screen designs, report designs, entity-relationship diagrams, data flow diagrams etc.). Important! You should consider alternative approaches (say 3) at this stage and evaluate them against each other.

You should now be able to produce the requirements specification. This document should clearly list the user's main requirements and explain each requirement in more detail if needed.

Here is a description of a good Systems Analysis section : "Excellent user involvement with detailed recording of the user’s requirements. Alternative approaches have been discussed in depth. All other items must be present showing a thorough analysis of the system to be computerised. A detailed requirements specification has been produced"

b) design

i) Nature of the solution - 13 marks

Your ideas should now be taking shape, and you should be ready to produce a systems design. The items you need to include here will depend on the sort of project you are doing, but will often consist of diagrams (data flow diagram/ outline flowchart) and a description. Produce designs for records, files and data structures if you can. If relevant, you should include designs of data capture forms, input layouts (screen designs) and output formats (printouts, more screen designs). The important thing is to get your ideas down on paper in the way the user can understand. You need to agree this systems design with the users, and provide evidence that you have done so. You could get the user to sign and date the design to show that you have agreed it.

If you are doing a programming project, you should by now have a fair idea of the shape the program is going to take. If the program is going to involve any algorithms, now is the time to design them, at least in outline. If you can't do this, you might have to think again about wha project you should be doing!

Part of your design should be a detailed summary of the aims and objectives of the new system. These should be agreed with the user. You need to state what results are required of the system, how accurately and for what purposes. Using "bullet points" is a very good idea here. You will need to refer back to this section when you evaluate your project - see section e i) below.

You should justify decisions you have made about the design, wherever possible.

You should mention any limitations of the design. i.e. What does your program not do which it could do with more time etc.

It is sometimes difficult to know where section a ii) ends and where section b i) begins. In practice one tends to lead to the other, and the diagrams you do to clarify your ideas at the analysis stage become part of the systems design. It's probably a good idea to make sure that you have sufficient material in each of the two sections, and you may find that you are repeating yourself a bit.

For full marks, the design should be sufficiently detailed that you could hand it over to someone else and they would be able to develop the system using the information provided!

ii) Intended benefits - 3 marks

The benefits of the new system should be discussed. You should discuss at least three benefits.

iii) Limits / restraints - 5 marks

You should discuss here any limits / restraints which apply to the system you are designing. e.g. hardware limitations (computer, storage); limitations of time and cost;

This section should also include an estimate of the size of the files which will be required for the implemented system. During your interview, you need to ask questions which will allow you to do this. (e.g. How many orders does the company receive per year? How many stock items are there? etc.)

c) Software development, testing and implementation

i) development and testing - 18 marks

By now, you have developed your system. This section is in two parts.

For development, you need to provide a technical description of how the system corresponds to the design. If you have used a programming language, you will probably print out the code and annotate it (explain what each section does). You should also explain why you wrote the program the way you did, and how this follows on from the design specification you did in b ii). If you have used a database or other package, you can use the package to print out technical details of table, relationships, queries etc. You should explain how the way you structured the data and the way you have tailored the package corresponds to the design specification.

For the testing, you should produce a test plan, carry it out, and provide clear evidence that you have done so.

Your test plan should include test data, expected results and actual results.

It is important to test valid, invalid and extreme cases.

You should do at least 10 test runs. Ideally you should do a lot more.

Usually it’s best to set out a test plan as a table with the following column headings:

Test number, description, data input, expected results, actual results, reference (use this to link the test plan to the screen captures – see below)

It is essential to provide evidence of testing. This evidence may be in the form of printed output (perhaps screen captures), photographs or VHS video! If you are using windows, you can capture the current windows with alt_print screen and paste it into word. Print this out for each test and you have your evidence.

It is a good idea to annotate printed output

You can ask your teacher to initial the test plan as proof that interactive tests have been done.

Refer to the specification for further details of what is required here.

ii) implementation (user testing) - 10 marks

In an ideal world, your program would be in use by the time you hand in your project. In practice this is quite difficult to achieve, but you need to do an implementation plan which includes as many of the following as you can:

• Allow the user to test the program; make a record of their comments and of any problems which they spot. If you make changes to your program as a result of comments the user makes, it’s a good idea to document them here.You should get the user to write a letter which refers to the testing they have done and its results.
• Plan how you are going to change over to the new system (see Heathcote for more details on implementation methods)
• Give details of any training that the user will need in order to be able to use the system

iii) appropriateness of structure and exploitation of available facilities - 7 marks

Discuss the hardware and software which were available for you to use and how suitable they were in solving the problem.

Describe the problems that were encountered and how you overcame them.

(It’s a good idea to keep a log of problems as you go along and to include it here.)

d) documentation

i) technical documentation - 10 marks

You need to provide technical documentation which could be referred to by another programmer and would allow them to change and maintain your program. Remember that you may not be on hand to do this work yourself! This should be a stand-alone guide. It may repeat information from other sections, particularly the design section. The exact contents differ from project to project, and will consist of some of the following:

• description of files used
• description of record structures
• description of data structures
• screen layouts
• report layouts
• menu structure diagram
• program listing with comments (can also be annotated)
• descriptions of each module
• detailed flowcharts
• details of algorithms / formulae used
• module hierarchy chart
• a technical description of how the solution relates to the analysis performed
• database modelling and organisation including relationships
• hardware and software requirements
• Make sure your documentation has an index so that it is easy to find things.

ii) user guide - 14 marks

This document should guide the user through all the operations they would need to perform. You should include:

• a diagram of the screens (see windows help on "Transferring data between windows applications" - using alt_print screen)
• input formats
• print options
• how to make backups
• security - passwords etc.
• list of common errors which may occur and what to do
• how to install the program and initialise files ready for use

Your guide should be "non-technical" and easy to follow for someone with little computing knowledge. Make sure your guide has an index. If you have time, you may include a glossary.

The user guide can be a booklet or it can be in hypertext form. A hypertext guide will need to be printed out in full.

For full marks, good on-screen help should exist.

e) evaluation

i) Discussion of the degree of success in meeting the original objectives - 6 marks

In section b i) (Nature of the Solution) you stated your objectives. You now have to assess how well the system you have produced meets these objectives.

You should match all the original objectives to the achievements, taking into account the limitations. Where you have failed to meet an objective, or have not fully met one, give a reason why you failed to do so. You can still score high marks, even if you didn’t do everything you originally set out to do, so long as you explain why!

Again you need to involve the user at this stage. Ask the user to write a letter or complete a questionnaire to say how well you have achieved the objectives, and refer to this letter/ questionnaire in your report. See also part iii below.

ii) Evaluate the users’ response to the system - 5 marks

You will be awarded marks for the ease of use (user-friendliness) of your system and the degree of satisfaction indicated by the user. In this section you could list some of the features which make your system easy to use. You could mention some of the following: clear menu structure, on-screen help, default values for data input, use of number keys for choices, availability of reports / lookup screens, well indexed user-guide, clear on-screen help facility. You need to refer to the user’s feedback letter or report which should comment on the ease of use of the system and the degree to which it meets their requirements.

iii) Future developments - 4 marks

What enhancements / improvements could be made to the system if time permitted?

Some of these could be features which you decided not to include at this stage. Some could be solutions to problems which have emerged during testing.