Good design work shows that you have analysed the problem in detail (gaining good marks on the Analysis section) and makes you consider the “advanced” Access features you could use to implement a solution (gaining good marks on the Implementation section). Effectively, your design contributes towards over a third of the marks available.
In this section of your project you are trying to take the end-user’s specification and produce a workable database solution on PAPER. A relatively competent 3rd party should be able to implement your ideas from the paperwork alone. This part of your project will involve you:
- Identifying the required outputs
- Identifying input data
- Specifying the processing that needs to be carried out (i.e. how to get the outputs you want)
- Devising a test strategy and plan
- Planning a schedule of activities to ensure that the project is finished by the deadline
Preparation
Obviously, before writing up this section of your report you’ll need to do a lot of thinking and planning.
While you’re working through the preparation section of this document complete Appendix B. When your preparation is complete see your teacher to arrange an interview to discuss your initial design ideas. THIS IS VERY IMPORTANT! Good ideas can fail because of poor design!
Make sure that your teacher agrees that your design is workable and that it contains sufficient depth to gain you a good mark before tackling the paperwork.
Database Design
Consider your research and own ideas and try to identify the entities (objects/people/things) involved in the system you are proposing and the relationships (transactions) between them.
In Appendix B section 1 draw a rough ER-D (entity relationship diagram) for each relationship you identify in the system.
Identifying Outputs
Look back at your specification and research to help identify what outputs you’ll have to produce. This part of the design process is particularly important as it will determine EXACTLY what input data your are going to need and what processing will have to be carried out on the data to achieve the desired results.
In Appendix B Section 2 list the reports or other outputs (mailing labels, form letters etc.) that you intend your system to produce.
Identifying Inputs and Data Stores
You should now have some kind of idea about what data you’ll need to input and/or have stored in order to produce your output. Look at your E-RD and proposed outputs. What data are you going to need to accomplish your objectives? At some stage in the future you, or the end-user is going to have to input this data.
In Appendix B Sections 3 and 4 list the input/stored data required for each output you have identified. As an example:
Output = Menu
Input data = Meal details (Name, description, price etc.)
Method of input = Menu form
Processing
As this is your first Access project this will probably prove to be your most difficult task - how to get from A (input) to B (output). Look at the user-requirements/objectives and your output ideas and try to identify any outputs and requirements that cannot come from stored data alone. Examples: archiving data; calculations, records that meet a specific criteria etc.
As part of your preparation you only need to identify processing in plain English e.g. archive last weeks orders, multiply price by quantity on an order, calculate VAT on an invoice, identify overdue subscriptions etc.
Complete Appendix B Section 5 with as many processing requirements as you can identify. Where might you need an action query or macro? Don’t bother including routine processes such as add/amend/delete records for every table/form.
Menus and Navigation
Your system has to be user friendly. How are you going to achieve this? The user interface should be structured logically so that a novice has no problems “navigating” it e.g. (s)he should be presented with a main menu from which (s)he can make a simple choice. Start thinking about how the end-user will access the forms/reports/features that you have created and try to design a “navigation” system for your application. Look at the example on page 186 of Heathcote (2nd Edition) for some ideas and then complete Appendix B section 6.
Test Plan
Testing accounts for a significant proportion of the marks in the Implementation and Testing section of your report
It’s important at the design stage of a project to think about how you are going to test your prototype. For your testing you’ll need to draw up a test plan that shows that you have carefully chosen your test data and tested each module thoroughly. In order to do this you’ll need to make sure you understand:
a) What the objectives of testing are
b) Types of testing
c) What normal, extreme and erroneous test data are
Read Heathcote pages 188-190 and make sure you understand these concepts. Start thinking about which elements of your solution need to be tested, why and how?
Paperwork
You could use the following outline plan to write up your design. This is not prescriptive and you may choose to include more headings:
1. Consideration of a possible solution
- Comparison of alternative solutions
Your project could probably be implemented using software applications other than Access (for example a spreadsheet package). One solution might even be to streamline/improve a paper-based system. You need to justify the use of a RDBMS by comparing Access with at least one other package.
Compare two or three packages using the example format provided in Appendix C.
Note: You don’t have to list the user requirements/objectives as they have already been stated in your specification. They are shown here to illustrate how your comparison of packages should relate to your objectives. Each row in the table should be numbered to relate back to one or more of your original numbered objectives.
1.2 Justification for Chosen Solution
Write a short paragraph to explain why you have chosen Access. In addition to your reference to 1.1 try to relate your explanation to the key advantages of a RDBMS: the reduction of redundancy, inconsistency, program/data dependency.
- Database Design
2.1 Entity-Relationship Diagram
Explain briefly what an E-RD is and draw a diagram to provide evidence that you have normalised the data in your system (in a minor project you do not have to formally document the process of normalisation). The diagram should be annotated if necessary to explain the exact nature of the relationships (e.g. one salesperson is allocated one company car – one-to-one relationship). Write a brief sentence to explain the purpose of each table in your design e.g. Customers – this will hold details such as the name and address of existing customers. In the case of “link” tables such as Orders explain why the link is necessary.
2.2 Data Descriptions
You will need to describe in detail the attributes of every piece of stored data in your system. For each table described in 2.1 above complete a table design sheet – Appendix D.
Attention to detail here is particularly important. You receive better marks for showing an appreciation of the importance of data type, field length, format, default values, validation rules and input masks. Annotate your design sheets to explain why you have made decisions e.g. Why is the product description field data type memo? Why did you use a lookup field on the customer’s courtesy title?
- Input
3.1 Forms - Background
Explain why the use of forms is important in a database application. Remember that you are designing a system for another user and not yourself. Your end-user may be a database novice and could easily get into trouble trying to enter, amend or delete data at table and query level. Using input forms protects her or him from the reality of the database – they don’t need to know how that data is stored in different tables or how to perform operations such as searching the database. The forms you create will act as a “bridge” between a novice user and a complex system e.g. one important use of forms is the implementation of “form level validation” – the use of tools such as check boxes, radio buttons and combo/list boxes to limit data entry.
Re-read your tutorial notes and the Access help files (about forms) for helpful information about what you could include in this section.
3.2 Input Forms
Input forms need to be designed/sketched by hand (or using a DTP package). Your form designs should be annotated to describe each form element used. The designs do not need to be works of art but should contain enough detail and information to allow a 3rd party to implement the design as you intended.
Try and maintain a consistent look and style for each form.
Your input forms may develop as your project progresses – you may find that an idea doesn’t work or that there is a better solution to the one you originally designed. This is unimportant! You can show, by including the original designs, how your project has progressed.
- Output
4.1 Reports/Other Output - Background
Explain why the use of reports is important in a database application.
Re-read your tutorial notes and the Access help files (about reports) for helpful information about what you could include in this section.
- Reports/Other Output
Reports and other output (form letters, mailing labels etc.) need to be designed/sketched by hand (or using a DTP package). Your designs should be annotated to describe each element used. The designs do not need to be works of art but should contain enough detail and information to allow a 3rd party to implement the design as you intended.
Try and maintain a consistent look and style for each report/output.
Your reports/output may develop as your project progresses – you may find that an idea doesn’t work or that there is a better solution to the one you originally designed. This is unimportant! You can show, by including the original designs, how your project has progressed.
- Menu Design
- Menu Design
Draw an organisation chart style diagram to show how the end-user will “navigate” your application. See Heathcote page 186 (2nd edition) for an example.
- Security
Some, if not all, of the data in your application is going to be commercially sensitive. Assigning passwords and/or security levels allows you to control who sees what in your application. Explain why security is necessary (refer to the DPA) and explain how you will protect the data in the application.
- Test Plan
- Testing
Write a few short paragraphs about the nature and purpose of testing to show that you recognise why testing is so important.
- Test Plan
Your test plan is very important! A good design will take into account any and all possibilities of why the system might fail. Using the example format below draw up a reasonably exhaustive test plan for your project – this will probably run to 3 or 4 pages!
It cannot be emphasised enough how important this element of your design is. Make sure that every field and control in your application is tested. Look back at your input/output/table designs and identify what you need to test. Make sure that you test relationships, calculations, expressions, macros, data types, field lengths, validation rules and input masks.
Use realistic data! A customer name is “Mrs. Everard” and NOT “xuudruhf”. Make sure you include extreme and erroneous data in your test plan
Note that the last column is empty. You’ll only fill this in after actually implementing your solution. Before completing the table re-read Heathcote pages 188-190 to recall the purpose of testing and what constitutes good test data.
Try to be systematic in drawing up your plan. Take one module (function) at a time and think about how you can test each element. Read section D and appendix F for some guidance about producing the test plan.
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.
- 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).
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!
SECTION D - TESTING
Section D – Testing (12 Marks)
Testing should really be an on-going process throughout the implementation of your project. You should test each module as it is completed to ensure there are no major design flaws before moving onto the next module (see appendix F). This is particularly important in the design of a relational database where seemingly minor faults in a module design can have wider implications later on.
Testing is included as a separate section of your project documentation because many students fail to fully understand its importance and as a consequence fail to provide sufficient evidence that they have produced a workable solution to their problem.
Preparation
Before embarking on your testing:
1. Read appendix F and make sure that you understand the different types of testing you will need to carry out and the reasons for these tests.
2. Make sure you understand the nature of “good” testing. Read or reread Heathcote pages 188-189 (2nd Edition). Pay particular attention to Heathcote’s words “…it’s not sufficient to think up a few tests you are fairly sure will not make your program crash or give a wrong result; you must use tests and test data which has been carefully thought out to test all parts of the program”.
3. Make sure that you understand the distinction between normal, extreme and erroneous test data. Start thinking about how these concepts apply to your project and try to draw up data sets that will test how your database performs under different conditions.
4. Look carefully at the system requirements of your project and/or your designs. Try and identify the operations your database is expected to perform – calculations, opening a form or report with data already in it. How are you going to test these operations?
5. Does your project include any validation rules? If so these need to be tested. Identify wherever validation and/or input masks have been used and consider what type of type of data you could use to test the validation.
6. Consider your original qualitative objectives. One of them should have been the creation of an intuitive, user-friendly system. Only the end-user can test whether you have achieved this. Draft an interview pro forma or questionnaire for your end-user to complete when they have tested the finished system.
Paperwork
You could use the following outline plan to write up your testing section. Hard copy evidence of test runs (referred to in the last column of the table) should be included in your appendices, should be clearly cross-referenced in the test plan and should be clearly annotated to show evidence of a successful test run.
1. Testing
1.1 Module Testing
If you’ve followed the steps outlined above writing up this part of your project should be fairly easy, although time-consuming!
Appendix F uses the example of one module to show how you can use tables to organise module testing. Note: It does not include a full set of tests or test data and is for illustration only. You will need to test all modules and include more tests for each module.
Make sure that the evidence referred to in the tables is fully annotated and where possible cross-referenced to your test plan. Printouts with “… no annotation and no cross-referencing to the test plan are virtually useless!” – Heathcote
- System Testing
Most, if not all, of your modules can be tested in isolation. Once all the modules are complete you need to test the entire system with a realistic set of test data. You need to provide some evidence that your modules work together.
- End-User Testing
Include a copy of your questionnaire completed by the end-user in your appendices. Restate your qualitative objectives and any other requirements the end-user asked for in the original specification and produce a short report (no more than one side of A4) cross-referenced to the end-user’s comments.
Don’t be afraid to include “negative” criticism! In the real world projects like this might take months, or even years, to get right – you’ve had 2 months!
There are many reasons why an objective might not have been achieved:
- The end-user wasn’t clear enough about her/his objectives
- There wasn’t enough time to carry out all the tasks
- The objective wasn’t realistic to start with
- New ideas made the objective redundant
In Section F – Evaluation you are credited for recognising the limitations of the solution you have produced.
Get the end-user to sign and date your report to show that (s)he agrees with your evaluation of the end-user testing.
SECTION E – USER GUIDE
Section E – Documentation: The User Guide (9 Marks)
A typical system will come with two pieces of documentation:
Preparation
Read the notes below:
1. Technical Documentation
Technical documentation is provided for the person who will administer your system when it is in place. (S)he will be responsible for ensuring that the system is maintained and/or updated if the organisation decides to extend the system. In order to do this (S)he will need to know about the structure of your system – how are tables related, which controls are dependent on others, how are controls formatted etc.
Your paperwork in the design and implementation sections covers this to a large degree and you can ignore this aspect of documentation.
2. User Guide/Manual
The people who will be using your system on a day-to-day basis may need to be trained in its use or may encounter occasional problems. If your system is intuitive the user guide will be fairly short. It should include:
- A table of contents
- Introduction – what the system is about and who it is for;
- Modules – how to use each part of the system e.g. what do the various buttons on a form do?
- Special Considerations – explain any special validation rules that might apply
- Error Messages – error messages that may be displayed and what to do in that event
- A help number or Email address
Paperwork
Your user guide should be aimed at an entirely non-technical user and where possible should use plain English rather than geek-speak. Presentation is very important, use screenshots rather than long descriptive lists. The user guide should be a separate document from your project paperwork.
- User Guide
Using the criteria outlined in the preparation section prepare a user guide for your project.
SECTION F – EVALUATION
Section F - Evaluation
The system life cycle is a continuous process – problems are analysed, solutions are designed, implemented and tested and then the whole process starts again! Look at any popular piece of software and you’ll find it’s in its nth version (Paintshop Pro 7, Office 2000, Flash 5 etc.) Why? After completing projects good system designers carry out a thorough evaluation of their solutions. Features that work well in the solution will be incorporated into later versions while those features that are missing or don’t perform as well as expected are either added or replaced.
It’s tempting, after mastering Access and producing a workable solution, to sit back, think “I’ve finished!” and produce a 3 line evaluation patting yourself on the back for a job well done. Don’t!
- No design is perfect.
- Due to time limits you may not have been able to satisfy all the user requirements.
- You may have had ideas about a feature you would like to have used but at this stage, didn’t know how to do it.
- You may have expected Access to perform a function beyond its capabilities.
- Your testing will have identified these limitations and/or other errors – how many calculated fields did you leave named as “expr1”or formatted as number when they should have been currency?
- Evaluation accounts for 10% of the total mark!
- Three lines is hardly likely to gain 10%
- You need to evaluate your project against your original specification, identify its limitations and identify potential improvements.
Preparation
Evaluation is all about assessing what was successful AND how your solution could be improved:
- Look at you original objectives. Make a note of those you achieved and those that weren’t achieved. You’ll need to look at your testing to find evidence that you actually fulfilled these objectives. Make a note of the pages that show the evidence.
- Try and evaluate why some objectives weren’t achieved and make notes on why not. You don’t need to know the solution but try to explain how your solutions failed. Be honest!
- Make sure you have an end-user questionnaire. See Section D. Your end-user is the only person who can truly evaluate the system. (S)he should have evaluated your system already. Try and get them to complete a summary evaluation (cross-referenced to the original user requirements) printed or written on company notepaper.
Paperwork
Your evaluation must prove two things:
- You have, as far as possible, satisfied the user requirements
- You have taken account of the limitations of your solution
You could use the following outline plan to write up your evaluation. This is not prescriptive and you may choose to include more headings:
- Evaluation
1.1 User requirements
Restate your original user requirements and/or objectives as a numbered list. This will provide a checklist for you to evaluate your project against
1.2 System Evaluation
Work through the numbered list systematically and evaluate how well you have met your objectives – some will have been completely met, others partially met and others not met at all. Be honest in your evaluation. You’ll be given credit for recognising the limitations of your solution.
Don’t make broad, sweeping statements such as “it worked well”. Each of the comments in your evaluation must be cross-referenced to evidence – either the results of your testing or feedback provided by the end-user.
- Enhancements
Even if your system met all the end-user requirements and passed rigorous testing it is likely that it could still be improved. Write a few paragraphs outlining how your system could be improved. This may include minor enhancements (such as adding or removing controls from a form) or major upgrades (adding completely new modules).