Implementation (writing the programme):

This part is the actual software program that you produce. The implementation has to be done using the design notes that you have previously created. It is accepted that during the design stage you would have created a part of your system to see how it is done or to test whether it is possible to do. This is known as prototyping. There are two types of prototyping, the Throw-Away type and the Evolutionary type, explained more in Module 4. The Throw-Away is discarded after it has served its purpose while the Evolutionary is developed when finished with into a sub-system of the whole. Both types may be used during the design process to give a better understanding of what is required at implementation by the developer and the users.

Before starting ensure you have all of your design notes with you before attempting to program anything to ensure you produce what has been required. Note the menu structure, note the data structures, note the input/output interfaces, note the sub-tasks.

Always show the testing of every piece of formula etc. in the implementation.
Make maximum use of the chosen software (Spreadsheet), show the examiner you are a skilled programmer. Use appropriate data capture procedures, show data being validated before being entered. Show how your solution related to the skill levels of the users, the resources available, the time constraints, the hardware and software capabilities. Make good all of your hard work in the Specification process to produce an effective solution to the original problem.

Testing:

All the system needs to be fully tested before allowing any customer to try out the system. The system has to conform to the design and implemented exactly to the users requirements.

A good plan would be to thoroughly test each sub-task as you finish implementing it. This is known as Module testing, as each section is referred to as a module. Test the important processes and data paths, choose valid and invalid data, always use data that is on the border between valid and invalid. Choose different scenarios where the data may be input. Check that the sub-system follows the design stage and does what you intend it to do. Has your system got all of the requirements that were agreed upon at the start. Your log book will prove invaluable at this stage.

A test plan:

For most of the tests a 'Print screen' of the input and output will show as evidence of the completed test. A test plan and its table need to show evidence of you choosing appropriate data carefully. Cross reference the evidence to your testing plan.

As your modules are completed, how will they fit together to provide the complete system. Testing at this stage is known as System testing. Test with realistic amounts of data, if you tested your prototype with 4 item of data and the system should manage ten thousand, then you will need to try out considerably more.

(All tests should be presented as Appendicies in the final documentation, they should also be referred to in your text).

The Evaluation

Evaluation:

The solution to your chosen problem needs to be evaluated. The evaluation is about the solution overall not just the software. This is an opportunity to refer back to the user to get an evaluation from them about how the system works in practice. You may want to use a questionnaire to assess the system, and show some analysis.

• Did the hardware or software used cause any problems, did the hardware contain enough memory to work efficiently?
• Does your final solution (the completed work) match with what was originally intended?
• Had some amendments have to be made because a module just wasn't possible to implement?
• Was the project too ambitious, did it have to be scaled down?
• Did you work successfully to the given timescale?
• Did you manage to improve upon any original designs with the approval of the users?

The User Documentation

User Documentation:

The user guide is to show you can explain your system you created in a non technical language but appropriate to the users of your system. Use extra effort on the presentation, although it is part of your project report anyone should be able to use it as a separate document. The document must show how the system is used, but it also needs to refer to the hardware and the software used. It should include normal and abnormal operations. Problems that may arise need documentation to show how to solve or escape from.
Always start with the most basic explanations, i.e. how to load and run the software. Gradually increase the skill level for explanations on what the system can do and how to do it. The end part should be for maintenance purposes for higher level skill users, i.e. how to create another macro when upgrading the system.

Checklist:

• a title
• a table of contents
• an introduction - what is the system and who is it for
• examples of screen displays, include data input, menus and data output
• examples of printed output, reports or mail-merge
• explanations of what the menus do
• special instructions for accepting data or amending the format or validation
• explanations of any manual procedures
• error recovery, how to cancel an input, how to go back a step, or power failure recovery
• explain your system, not how to use the software program
• test your user manual on someone unfamiliar to your system, do the understand it?

The Report

The Report:

Facts:

• The report is your evidence to show all of what you have done on your project
• The marking is based on the report alone, your working system will not be seen
• It always takes much longer to write up the report than expected
• The report becomes easier to complete if you do a draft after each section
• The report becomes easier to complete if you have made a log of everything you have done.
  

What is the report made up of?

• A title page, name of the project, date, name, candidate number, school, centre number.
• A table of contents with numbered pages, including Appendices for test data etc.
• Analysis, include summary of the interview, questionnaire, current system, user requirements.
• Design, user requirements into a specific system, testing strategy, show any hand written notes.
• Implementation, document the system not on the functions of MS Excel, describe what was built.
• Technical documentation should be used here: describe each object, summarise the purpose of each macro and module and when it is used, explain the customised features, explain any limitations and odd test results, list as a print out any associated code you have produced.
• Testing, plan and data, evidence in the Appendices, show had written analysis of tests.
• Evaluation, of how the system worked, the results, did it do what was intended/required.
• User Manual, based on non-technical language, designed for the system users.