Use some of these features:

• Related tables, identifying fields, primary keys, and types of relationship
• Queries
• Forms to enter data
• Reports
• Macros
• Buttons to run macros
• Customised icons and toolbars

• A splash-screen opening form i.e. Welcome to…
• A customised front end (switchboard) to hide the package from the user
• Parameter queries
• Lookup fields
• Validation and input masks
• Sub forms
• Customised forms to enter, e.g. list boxes, combo boxes
• Grouped data in reports
• List boxes

• Booking facilities at a leisure centre
• Finding details from a pupil's school database
• Running a video shop / library
• Car hire database
• Tickets for the school play
• Stock control in a school department
• Stock control in a shop
• Rail ticket price calculator
• Equipment repairs database
• Newspaper shop delivery database
• Bank statements

• Much of the work done in the second year builds upon the work of the first year. The marks that you get are completely within your control. You need to manage your time effectively, and put in the appropriate effort.
• The deadlines for completing parts of the project are there to help you, at the end there is a strict deadline for the final presentation report so that it can be marked and sent off to the exam board to meet their deadline.
• The project needs to be based on a real problem with real users, that is why you are given the Summer holiday to prepare. You need to have real constraints on the requirements and feedback from the potential users.
• The project will assess your ability to use ICT tools and techniques to solve a real problem.
  

The Analysis

The analysis is an investigation into how the system works, it should also include some background information about the organisation, and a list of requirements for the new IT system that is to be developed. This is the most important section as it gives you a clear idea of what you are about to do. If the analysis is wrong you could be developing a system that will not be useful to the end users.

• A summary of the overall project.
• Background information on the organisation, and where they are now.
• A problem statement about what is wrong and how you intend to improve it.

• Interview the manager, use questionnaires for the users, and summarise the results.
• Justify why the current system can improve with changes.
• Show actual copies of documents, i.e. input and output; e.g. invoices, letters, log book of transactions, company logo. These give more understanding of the system.
• Describe the input processes and the output results in detail, list in a table.
• Produce a Data Flow Diagram of the above processes, if you are working on a section of the whole system then expand on only that, else expand the whole system.
• List the software you will use, justify your use of it by explaining what the advanced features that you will be using are. What other available software is there? If the organisation doesn't have the software can you justify the benefits of buying it?
• What hardware will your system run on, as an IT specialist you should be technical here? What hardware do you have at your disposal to complete the project?
• What are the IT / database skills levels of the staff who will use the program, consider user friendliness, on-line help, non technical dialogue or high user skills. Consider the look / feel of the input / output screens. Will the users require training?
• The constraints or limiting factors when implementing a new system generally fall into software, hardware, user skills, and a budget, consider the effect of these on your proposed new system.
  What security will be programmed in, and what needs to be kept private and why (consider the Data Protection Act).
• If any training is necessary for any staff, give details of what this will entail.
• List all of the end users requirements, these must relate directly to interviews and questionnaires.
• Get the end user or manager to countersign your list as approval.

Objectives of the New System:

The objectives are an outline of what the proposed new system has to do to address the list of user requirements.
The objectives must specify the actual purpose of the proposed new system, an example of a list of objectives was given in the notes for Unit 3.

Performance Indicators and Criteria:

This is where the success of the project can be measured to see how well it meets the users requirements.
The performance criteria can assist with the design plans and testing strategy.
Qualitative objectives include: human computer interface, help, menus, buttons, consistency between tables and forms etc.
Quantitative objectives include: details of amounts of data used, printing times, processing times, weekly or monthly automatic processing etc.

Personal Skills:

You may find it useful to type a couple of paragraphs about your own personal database skills, what areas you need to learn more, and how you will acquire your new skills to complete the project.

Planning:

You will need to show how you intend to complete the project by the given deadline. In real life situations a plan is drawn up which includes a schedule of activities and the personnel involved. The plan may contain milestones, (when certain modules have been completed), and a final deadline when all work must be completed. It may contain a skills plan where personnel develop their own personal skills in a various component or module.

A table divided week by week is necessary to plan each week ahead, and what activity you will be doing. It is rather like a diary, i.e.
Week: Week 4, Sept ...,
Task: The final interview with the manager we agreed on....,
Where: Worked at home,
Comment: Got all the details I need to type up a complete summary...
A table divided week by week may also be used for your skills plan.
A Gantt chart is necessary for your project milestones and deadlines.

Data Flow Diagrams:

A data flow diagram shows the flow of data through a sequence of processing steps in a system, and what data stores are used. Data flow diagrams are useful for showing the following:

• The origin of the data.
• What processing is done on it, by what and whom.
• Who uses the data.
• What data is stored and where.
• What output is received and who uses it.

The four symbols opposite are most commonly used, although there are no set rules for symbols:

Different systems have different levels of diagram, the more complex the system the more levels of diagram may be used to gradually reveal more and more detail.

Process: an operation that is performed on the data (a processing step).The top section is the label, and the middle section is the explanation.

Data store: a store if data i.e. database, file, or batch of documents.

Data Flow: the direction of movement between entities, processes, or data stores; the arrow is labelled to show what data is involved.

Possible Solutions & Chosen Solution:

A range of solutions are always possible, consider these for each task you identified in your analysis. You may consider:

• a manual solution,
• a spreadsheet sysem,
• a specialist system,
• or a database system,
• explain each of the systems good and bad points, and explain why a database system is the most suitable. Make a list of your reasons for your choice of software, the list will include some of the features you will use, i.e.
• linked tables,
• queries,
• archive and sort,
• macros,
• validation of data input,
• access control,
• customised menus and forms,
• automated processes.
  

Detailed Design:

This will give all the details of how your system will function, you need designs for:

• Data Flow Diagrams, for your own system,
• inputs, processing and outputs, best listed in a table,
• user interface, i.e. forms, menus, dialogue boxes etc,
• reports, i.e. title, table or query used, fields used, calculations, sequences used,
• macros, i.e. name, button, worksheet, action, procedure,
• queries, i.e. name, tables used, fields displayed, order, criteria, use screen shots,
• forms, i.e. table name, fields, lookup fields, calculated fields,
• security,
• testing of processes, end user testing.

Top Down Design:

When your design is finished draw a block diagram to show how the system works.

• Unit testing: individual components are tested independently without any other components.
• Module testing: a collection of dependant components such as an object class or an abstract data type is a module, are tested independently from other modules.
• Sub-system testing: a collection of modules that are integrated into sub-systems.
• Interface mismatching problems are tested, and module interface errors.
• System testing: a collection of sub-systems make up the complete system. Interaction problems between all of the sub-systems are tested. The system is validated for functional and non-functional requirements.
• Acceptance testing: testing of the system with the customer's data to ensure correct operation with the real data which may use the system differently to the test data. The systems requirements are tested for errors and omissions and for system performance. The customer / user will comment on the effectiveness of these.

The test plans done here will be used later during and after implementation, and must be used. If later you find other tests that need to be done during implementation, then add them into your design test strategy.
When the test plan is completed check for the following:

• How will you implement the testing later?
• Is the order you do the testing correct?
• Have you listed the actual tests?
• What data is to be used, normal, erroneous and boundary for testing?
• What acceptance testing is to be done to satisfy the users?
• If many macros are doing exactly the same thing, explain one and list the others.
• Check for the performance criteria, will a search give a result in under a second?