SECTION C – IMPLEMENTATION

Section C – Implementation (20 Marks)

 

Now you have designed your system you need to implement it to make sure it actually works! Remember, you can only get marks for implementation based on the written evidence you supply. As you are working with a short deadline you’ll need to be organised to ensure that you can implement your solution AND document it in the time available. If you don’t have access to a PC outside of school there is still a lot of work that you can be doing at home:

• Read software guides and/or tutorials to help you overcome any problems you encounter
• Refine your designs – remember these can be hand drawn
• Create sets of test data
• Draw up test plans
• Plan/draft your documentation
• Plan how you are going to make the best use of your next practical session

 

Use your time constructively!

Preparation

 

Good organisation is essential if you are going to score well on the implementation. Many good projects fail to impress the examiner because students have not given enough thought to documenting their implementation. It’s not enough to produce a fantastic working database! The only evidence you can submit to the examiner is paper-based and without this paperwork you cannot be credited for what you have achieved.

• Buy a binder or folder and keep everything related to your project carefully stored in it. This should be divided into sections so that you can quickly find what you are looking for. At this stage you may choose to keep your notes in plastic wallets, for organisational purposes, but your finished report must not be handed in inside either a ring binder or wallets.

 

• Make sure you have your design documentation in front of you and use it. You need to ensure that you don’t forget to implement all elements of your design. If your design needs to be altered for any reason do so, and make a note of why. This is inevitable, as you’ll be learning how to use Access as you create your application and will be finding new and better ways of accomplishing your objectives. Under these circumstances you will be credited rather than penalised for showing how your designs have developed.

• Make sure that you take two backup copies of your work after every revision. Blaming Microsoft, the school network and the family dog wont bring back your project if you lose it! It’s a good idea to “time stamp” backups with the date/time in the file name so that if things go terribly wrong you can systematically work backwards through your backups until you find a “good” version.

 

• Create a project implementation log to record what you did, when and why. Fill this in religiously at the end of every practical session (leave about 10 minutes at the end of the session) and note what you did and any problems you encountered.

• Take screenshots as you implement the solution to show how the design progresses to finished application. It’s far easier to document the implementation as you go along rather than finish the practical work and then have to reproduce what you did just to get a screen dump. Documenting your project in this way allows you to show how your design has progressed.

 

Paperwork

 

You could use the following outline plan to write up the implementation section of your project. This is not prescriptive and you may choose to include more headings:

1.         Planning for Implementation

1.1       Tasks/Subtasks
Look at your objectives and designs and identify the main tasks you will need to complete. Each of these tasks can probably be sub-divided into a series of smaller, more, manageable subtasks. Draw up a numbered table that identifies that subtasks you intend to tackle.

1.2       Schedule
Using your list of tasks/subtasks prepare either a simple diary or a Gantt chart to provide a schedule for implementing and testing your solution. Testing is a very important element of your project, so make sure you allocate an appropriate amount of time for testing (see Section D). Don’t forget that you will also need time to produce a user guide and evaluate the project.

2. Implementation

 

2.1       Project Implementation Log
Keeping a log of what you did, when and why is very important. This will provide the only evidence that you have actually implemented your solution! Use the example format below to create a project implementation log – a detailed record of what you did each lesson (or session).

Date	Time Spent	Activity	What Next?
	25 minutes	tblProducts and tblSuppliers created
	5 minutes	Created one-to-many relationship between tblProducts & tblSuppliers	Test relationship
	5 minutes	Added records to tblSuppliers
	15 minutes	Tested referential integrity by adding normal and erroneous data to tblProducts

Make notes as you work and write-up the log after every session. Use this document to explain technical points in detail. Comments in the log should be cross-referenced to hard copy evidence where possible. In the example above I would expect to see:

• A screen dump of both tables in design view annotated to explain exactly how the tables have been set up – keys, field lengths, data types, format, validation, input masks etc.
• A screen dump of the relationship window showing the link between the tables and that referential integrity has been enforced.
• A screen dump showing both tables open in datasheet view to prove that data has been entered and that normal data has been accepted and erroneous data rejected.

 

All elements of your implementation need to be fully documented. Remember, the examiner is a 3rd party who may have little knowledge of the background to the project. He/she should be capable of implementing your design from the documentation alone. All printouts and screen dumps should be fully annotated. This is particularly important when using wizards – annotation helps to explain how you have edited and customised the wizard-generated solution. You know exactly what you have done but the examiner can only award you marks for what he/she can see in front of them.

You shouldn’t assume that the examiner is an Access “guru”. He/she will certainly understand the basic concept of databases but may be more familiar with Lotus Approach or Borland Paradox. It is your responsibility to ensure that the examiner understands how you have exploited the features of your chosen software. Annotation helps you to explain features of your project that can’t easily be shown by printouts alone e.g. format of a calculated control on a form.

All printouts should be dated to show progression in your work. It’s inevitable that you will deviate from your original design and this should be shown with appropriate explanations. Appendix E contains a sample implementation log.

Do not use the built-in Access Documenter to provide the sole evidence of implementation, as this will simply produce pages of meaningless “code”. If you do make use of the Documenter you should be very selective in its use and hand annotate any output you use.

Make sure that you systematically document your implementation in the way described above. It will take longer than you expect to complete the paperwork. Completing the documentation in parallel with the implementation and testing means that you document it while it’s still fresh in your mind, you have a better idea of how long it will take you to complete the project and when you have completed the practical work all you will need to do is proof-reading, adding a table of contents, page numbers and appendices. Don’t leave it all until the last minute!