Implementation:

This is where you show off your advanced database skills using screen print outs as evidence. Testing is also part of this section and screen print outs of testing in process also adds to the evidence that you actually did the project.
Explain what you did and why, show print outs, and annotate them to help your explanations. If things didn't go the way as planned, note it anyway, and explain how you changed it to get the desired results, you will get credit for showing your changes.
The more effort you put into your analysis and design, along with the users requirements, the easier this section will become. The log book of notes you need to keep will now become invaluable.
For each task start a new paragraph, give an explanation, show the evidence, and test it with the appropriate data, show amendments if necessary.
Reports can be used as evidence of the correct final results.
Print outs of screen shots must be large enough to be clearly read, remember the exam board need to read them as well. Don't just print out an error message for example, keep the background in to show what has given that error message.

Testing:

The tests done should be sorted into a list, or bulleted, or in a table. They need an extra column to show the actual result. An example of a table is in Unit 3. More tests should have been done to accommodate any extra functions or changes you have made. The end user must be involved to check you have included all the functions agreed upon during the analysis stage.
Check you have the following:

• every objective has been tested,
• large screen print outs for each test clearly annotated,
• test results that show that the functions do what they are supposed to do,
• testing results that are easy to read and understand,
• show corrective action has been taken when the test has shown any errors,
• ensure all are printed out as this is your evidence.
  

The User Guide

User Guide

The User Guide is the technical documentation to support all of your work. It will give the users helpful information on how to use your application. You will need a contents guide, and step by step instructions for each application function. Use screen print outs to help you explain. Use technical details for the software, common problems and how to recover from them, and how to install the software. The user guide should be read by the user to ensure that it covers what is needed. Aim the language at the skills of the users, from simple plain language to highly technical language.

Consider inserting the following headings:

• system requirements,
• how to install the software,
  getting started,
• start up procedures,
• sub headings for each section,
• normal error messages,
• saving data and files,
  back up procedures,
• security issues,
• glossary of terms.
  

The Evaluation

Evaluation

Start with assessing how your system performed against the performance criteria from the analysis and comment on how well it has performed. Always refer to the user requirements as they are what you have to produce.

• How would you have changed things to make improvements, what were the greatest problems, were you limited by anything, consider the users skills, the software being used and the capabilities of the hardware it is run on?
• How flexible is the system, can maintenance changes be made easily?
• How user friendly is it, consider your forms and reports?
• How fast does it respond to requests?
• Is it compatible with other software running i.e. spreadsheet charts, mail merge etc?
• Is it a high quality product, if it is explain why?
• Is it cost effective, or would it be cheaper to keep the original system?
• If you had lots of problems and the software doesn't do what you want it to do, do not despair, most of the marks given for the project are for how you write up the different sections.

The exam board will not see your database in action, they will only read your report.

Include in your evaluation:

• evidence of an understanding of how the solution meets the criteria,
• consider each performance criteria and state how the solution has been met,
• use the testing evidence to show it works correctly, quote the users comments,
• mention what didn't work and explain the reasons why,
• mention what improvements that could possibly be made if circumstances were different, and how they would meet the users requirements.
  

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:

The design of the report and how to type it up is the same for Unit 3. This is your second one and it should be of higher quality than your first.
Remember to use a consistent style, check and proofread your work, as the spell and grammar checker are useful but do not correct everything.
Keep the content concise and of high quality, use roughly 8,000 words, this does not include annotations or appendices.

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.