- With the labels of the graph they will not change with the data so you end up having to go over the whole process of making a graph again.
Access
Access also has its advantages and disadvantages, which need to weigh up against Excel's advantages and disadvantages to come up with the right choice of software. Access' advantages include: -
- Access can perform advanced queries.
- Access can make forms to insert data.
- Access is very user friendly.
- In Access you can have macros to go between forms and queries.
- Access has lots of facilities which help to improve the appearance these include- Word Art, Paint, text and line fill, Spell check, Clip art, Importing pictures
- Access is not a flat file database so you can also create relationships between tables of data.
- It has a query language, which means it can perform advanced searches.
- You can hide certain forms out of view.
- You can put a password on the system to prevent people tampering with it.
- There are writing tools including spelling and punctuation tools available.
- Access can have relational tables, which are linked together. This avoids repetition in entering in data as more than one department of the system can share one bit of data.
Access has disadvantages as well as advantages these include: -
- Access is more sophisticated than Excel and is therefore harder to use for a novice.
- Access is used by professional system designers who design systems for end users. This means the system must be very powerful and very detailed. However it is more complicated for a non-expert to use.
High Level Language Such as Pascal
I have decided not to use a high level language, as I do not have the necessary knowledge to produce a system written in a high level language such as Pascal.
Advantages
- It can be customized to suit the company’s needs.
Disadvantages
- Developer does not have sufficient enough knowledge.
- I would take a long time to code some areas where as in Access they are easily done in tables.
Evaluation of possible software solutions
I have decided to recommend the use of Access to the clients as being most suitable because it seems to offer more facilities and features, which will help me in designing a program for the Postquick Parcels, clients.
Access is more usable than both Excel and Pascal and the end users will find the system easier to use as the system will save time by cutting out repetitive tasks and will give them quick access to the information they need. A system designed is Access should give a very user-friendly interface and will function in the way the client’s want in to. Access is a quick database and is quick to open files and change to new pages. Access will really provide a solution to the clients needs, as it is a diverse program, which can be used in many different ways. Another very good thing about Access is that it will be very easy to upgrade, introduce new functions and make modifications as and when they are necessary.
The system should take approximately 4 months to complete and has the proposed delivery date of the 30th of April. It will come complete with a progress report, a system guide and details on the testing completed.
DATA REQUIREMENTS
There are many data requirements for the new database system these include the following:
- Data on the different prices, which depend on the various, weight categories.
- Data on the parcel which the customer is sending, this will include, parcel ID, width of parcel, length of parcel, height of parcel, total dimensions, weight and price which will be calculated by the computer.
- Data on the customer, this will include, customer ID, customer’s title, customer’s surname, customer’s forename, businesses name which the customer comes from as well as the business town, postcode, contact number, email address, street and street number.
- Data on the parcels destination, which will include, Destination ID, the recipient’s company, address, town, county and postcode.
- To actually order the parcel the information needed is, the order, customer, destination, parcel ID’s and the date ordered and the required delivery date.
THE DATA FLOW
Data Flow Diagram
To help me design an effective and structured database system I have drawn a data flow diagram to show the logical movement of the data through a system, however it does not show how the data is stored.
There are different levels of data flow diagrams, I have drawn a level 1 diagram that can also be known as a context diagram. A data flow diagram has many symbols, which mean specific things the symbols I have used are: -
- External Entities - can also be known as a data source or destination. In the following diagram the Customer is the External Entity.
- Processes – are operations performed on the data. In the following diagram there are five processes each named P1, P2 …etc.
- Data Stores – are logical stores for data, which are not physical in the following data, flow table they are labelled D1 and D2.
There are many different levels of DFD’s the DFD below is a level 0 and the DFD on the following page is an example of a level 1 DFD.
Entity-Relationship diagrams
Entity-relationship diagrams are diagrams, which show the relationship between entities in a database. Entities are things of interest to an organization about which data is held. In order to be able to draw an entity-relationship diagram you need to know the degree and the name of the relationship. The degree of the relationship will come under one of three categories:
- One-to-one, e.g. relationship between Person and National Insurance number which is unique to every person.
- One –to-many, e.g. relationship between Customer and Parcel Order.
- Many-to-many, relationship between Customer and parcel.
Below are examples of data entities, which are relevant to my system.
SYSTEM DESIGN
Top Down Design
A top down design is the technique of cutting down and simplifying a complicated problem into the major tasks which need to be completed and then cutting down the major tasks into modules. It is mainly used in programming but the principle can be used to help design my system.
Modular Design
The system can be divided into different modules, and these modules can then be drawn in a structure diagram to show how the modules relate to one another and to form the whole solution to the problem. On the following page there is a structure diagram of the proposed system.
System Structure Diagram
Algorithm Design
Finding ID
I have devised an algorithm to show how the system will search and answer for an ID by the user entering in the business name. The diagram shows the flow of actions and could be called a flow chart. I could create algorithms for all of the queries.
USER INTERFACE
When thinking about the user interface you should think about who the system is for, what tasks the system is performing, and what environment the system will be in and whether the technology is feasible.
Outputs
There will be two main outputs of my system and all need to be user friendly. These outputs are as follows:
Consignment Note:
The consignment note will be given to the recipient via the delivery and will need to include some details on the customer sending the parcel, these will be the customer’s ID number, title and surname so that the recipient knows whom the parcel is from. Then so that the delivery person knows where the parcel has got to go I will include information on the destination ID, name of recipient and their address.
The note is mainly for the recipient and delivery person, this means that it won’t need to carry very much information. For instance it will not need to carry the price of the parcel delivery. The recipient will need the information on the customer sending the parcel and the delivery person needs the information on the destination.
The consignment note only needs to have a plain and simple design showing the necessary information and it is not necessary to include any colour and images. The font will be ‘Times New Roman’ as this is a very easy to read font and will be in size 10 font to make it even easier to read, if it was smaller it would be a lot harder to read. The destination information will be in larger font and bold so that it will stand out easily for the deliveryman. The most important thing about the consignment note is that it is clear.
Query outputs:
The results of my queries could either be displayed in a table or in a form created by a wizard. The presentation of the results would better in a form this is because of a number of reasons, which include:
- It is easier to read from forms than tables.
- Forms display one record at a time, rather than all of them at once, like on a list, which make it harder to isolate one particular record.
- Forms are better for presentation as they can have images on them and you can change the font and size.
- With tables you cannot have buttons, where as, you can with forms.
Over all forms are better for this type of system as they are more user friendly because they look less intimidating than tables and require less work on behalf of the user as they can have buttons on them to take the user to and from different forms and menus.
Each form will have a title to identify it to the user. The forms will not be cluttered and if anything will have a maximum of two images. This will insure that the results are easily readable and not interfered by unnecessary clutter. The field headings will be written in a clear easily read font like ‘Tahoma’ and in 10 points, this will make the information clear and easy to read. This is better than fonts such as Algerian in font 9 which although is fancy, is difficult to read.
Forms
The reason I have chosen forms instead of tables for the system is explained above under the title ‘Query Outputs.’
There are four main forms, which are used for entering data about the customers, parcels, destination and orders information. All of these forms have their own clear large title saying what the data is about. Each field as above (query output forms) is in point 10 and in a clear and legible font, which is, well defined and easy to read. Also the forms will be clear of images as they are not really needed, and there are large rewind and fast forward buttons to manually take the user through the records. Each of these forms follows the same structure to make the forms consistent in presentation and familiar to the user. All the forms will be in a light blue colour. I have chosen blue because it shows up the black writing very well and the writing is easily visible where as if I had filled the background in red or green the writing would not have shown up very well at all.
On some of my forms where appropriate, e.g. customer’s title or possible weight categories, I will include drop down lists which should save the users time when entering information as they will just have to drop the box down and choose the category they want.
Menu
There will be three menus: the first one will be a general welcome menu giving the user the option the go into either the existing or new customer menu. The welcome menu will have a large welcome title and will have two large buttons to take the user to one of the two other menu choices. It will also have two images as without them the menu will look very plain and boring as there would only be a title and two buttons. The existing and new customer menus both will contain a lot of buttons, which take the user to different forms or run queries. The buttons will have an easily distinct font like Tahoma and will have a font of at least size 10 points. The menu will also have a light blue background so that there is a consistency in colour.
Reports
The reports I need to include for the system are : -
- Consignment notes which are discussed above.
- Price lists which specification says must be included. This will be used for hard evidence on the prices and may be used when re-pricing the cost of sending parcels.
- Manager’s statistics which were also specified in the specification.
METHODS OF DATA ENTRY
The user only needs to enter data into the database about the customer, parcel, destination and order. To make data entry easy I have written instructions for the user on how and what information to enter in but on the whole it is self explanatory and very easy to get used to. Also as explained earlier I have even included list boxes so information doesn’t always need to be written in manually by the user thus cutting down on human or syntax error. The screen print below shows one such list box which brings up possible suggestions for peoples name titles.
However if there was a duke the user simply has to type in the title and the system will accept it. This is shown below.
The user will have very easy access to the data entry forms, which requires the user to simply click on the appropriate button using a computer mouse, which will take them to the required form. This will not require users to have knowledge about opening and closing forms in a raw database. Then once in the appropriate form the user will be able to use a keyboard and mouse to type in the appropriate information.
Over all the user will use the keyboard for data entry and will use the mouse for the operation of the system (e.g. buttons).
RECORD STRUCTURE
Customer Records
The customer records will be in a table called ‘Customer’. The following table shows the field names, their type and field size.
Destination Records
The destination records will be in a table called ‘Destination’. The following table shows the field names, their type and field size.
Parcel Records
The parcel records will be in a table called ‘Parcel’. The following table shows the field names, their type and field size.
Order Records
The order records will be in a table called ‘Order’. The following table shows the field names, their type and field size.
FILE ORGANISATION
I will be creating a relational database where tables work collectively rather than individually. For this to happen there is a need for links between the tables, the links need to be between one key field in a table and a foreign key in another. The foreign key and primary key must ideally both be called the same thing and spelt exactly the same and essentially be of the same field type so that there is not a syntax error. Below is a list of the links I will have between different tables: -
-
Customer ID in the Customer Table and Customer ID in the Order Table so that if the customer ID is typed in the order table all the other information will come up.
-
Parcel ID in the Parcel Table and Parcel ID in the Order Table. So that if a user types in a parcel ID in the order table all other parcel data will automatically come up.
-
Destination ID in the destination Table and Destination ID in the Order Table so that if a user types in a destination ID in the order table all their other data will automatically come up.
-
Weight in the weight cost table and Weight in the Parcel Table. This is so that the system can use the weight in the parcel table to calculate the cost by using the weight cost table.
SECURITY AND INTEGRITY OF DATA
Integrity
Input Masks
Input masks can be used in fields in tables to format data and have some sort of control over what values can be entered into them. Input masks consist of literal characters along with other special characters, which determine the kind of value that can be entered. Input masks are mainly used in text and date/time fields, but can be used in number or currency fields. I will be using input masks to make sure the users don’t make obvious errors when inputting data. By obvious I mean, for example, not putting capitals at the beginning of a name or putting too many digits in a phone number.
Validation Rules
A validation rule specifies a test, which has to be performed on any data entered into the field. If that data doesn’t pass the test a message comes up on the screen, which shows the text specified in the validation. I will use validation rules to make sure that on every parcel record there will be checks to makes sure the size and weight of each parcel has a:
- maximum weight of 30 Kg
- minimum weight of 1 Kg
- maximum length of 150 cm
- maximum total dimension of 300cm
- maximum weight of any one consignment
List Boxes
List boxes are drop down boxes, which display a range of possible categories for a user to choose from. Once clicked, the chosen value will be transferred to what ever field the box is connected to. This will help to prevent data entry errors or syntax errors and acts as a form of validation (previously shown on page 18).
Safety
Back up recommendations
To insure the safety of the database I would suggest daily back ups are made so that if the system for some reason looses its integrity, the company will have a recent back up to fall back on. This type of a daily back up is called a differential backup. This will insure that the majority of customer’s orders will not be affected and therefore the company will not lose customers. The regular backup should be made to a floppy disk, there should be a floppy disk for daily back ups done on Saturdays, Tuesday s and Thursday. Another floppy disk should be used to data back ups on Mondays, Wednesday s and Fridays. This means that if for some reason the system goes down and the daily back up that day had gone wrong, there is always the other floppy disk which even though is dated may still be of some use.
Security
Security is provided by making sure there are safeguards to ensure that data is not accidentally or maliciously corrupted.
Passwords
The system will have a password, which prevents the user from changing the design or appearance of forms. All the user will be able to do is enter the appropriate information in the right sections. The only person who will have total access to all areas both the users and behind the scenes of the database will be the administrator.
Encryption
Encryption is where data appears garbled unless you know how to decrypt the data.
Other Security Recommendations
I would suggest the user have various security measures for the system, these include: -
- A security manager who can oversea and monitor all terminal activities.
- Keyboards and monitors to be locked via a password when they are not being used or are left unattended.
IMPLEMENTATION
STARTING WITH A SIMPLE DATABASE
The Tables
The system will include five tables, these are: -
-
Customer, this table should include the fields concerned only with the personal information to the customer and does not include information about the parcel or anything else.
-
Destination, this table is where the user will enter in all information about the parcels destination.
-
Order, this table should include all information needed for and order to make the deliverers life easy. I am going to include all information about the customer order and destination and will also include the price of the parcel.
-
Parcel, this table will include all information about the parcel.
-
Weight Cost, the user will not use this table because the weight and costs should only be changed if the company changes their prices. The table will be used like a reference table or a look up-table (as in excel) in queries.
Customer table:
The customer table includes the fields:
- Customer ID
- Title
- Customer Surname
- Customer Forename
- Business Name
- Business Street and Street Number
- Business Town
- Business postcode
- Contact number
- E-mail
To the right you can see a copy of design view of the customer table, as you can see all but the key field are text data types, this means that the information entered here can be both numeric and or letters. The reason that the contact number is a text data type and not a numeric type is because a numeric field would not allow a leading zero where as a text type will. Every table must have a key field, a key field is a field, which is a unique number field, which is used as an index. The Customer ID is an auto number, an auto number is a number, which is unique to that particular record, and the computer program enters it automatically.
Destination table:
The destination table includes the following fields:
- Destination ID
- Name of Recipient
- Address of recipient
- Town
- Country
- Postcode
This table, like the customer table, has mainly text data types and only the key field is different, as it has to be a key field.
Order Table:
This table includes the following fields:
- Order ID
- Customer ID
- Parcel ID
- Date Ordered
- Delivery Date
This form will not actually be used to directly enter in information on orders as the order information will be entered in by the user on to an order form which due to the relational links between the tables will transfer the necessary information on to order table.
The form has Order ID as the key field, this means each order is given its own identification number which if necessary can be used like a reference.
Weight and Cost table:
This table includes only two fields:
LINKING THE TABLES
The tables are linked together to make a relational database. The tables are linked by means of a common field. One of the common fields must be a key field and the other is known as a foreign key.
The purpose of having a relational database is that by linking tables you can use data from all of the tables not just one. For example instead of writing the customer’s information twice, once in the customer table and once in the order form, you can just enter in the customer ID in the order table and the information will come up, this is all down to the relational links.
Below is a copy of the relationships between the tables.
ENTERING DATA
Now that the structure of the database is in place how the user is to enter in the data is the next task. The entering of the data should be user friendly, quick and as far as possible not prone to human error, because time is very important.
To make entering data easier I have decided to use the auto form function, which is quick and effective at designing simplistic and easy to use forms. All you have to do is follow the various self-explanatory steps, which the wizard takes you through. Below are the forms I have used in my database
Customer Data Form
Parcel Data Form
On the previous page is my first parcel data form, however it relied on the user remembering the different weight categories, this is not very reliable and is subject to human error, so I decided to include a list box with the categories already in there, this makes the form easier to operate. I have also included a title and instructions telling the user what needs to be inputted and that the measurements not including the weight need to be measured in centimeters. The improved form is shown below.
Destination Data Form
Order Data Form
Original design
I have modified the order table throughout the project to make it easier for the users to use, however below is my first design, which simply includes places for the user to enter in the ID’s and also the date ordered and delivery date, independently, without any help from the computer by way of an input mask.
Revised Form
As you can see from the following form I decided to change the order form to include a lot more information. The modified order form is better because the user has to enter in less information. All the user has to enter in is the Customer ID, Parcel ID Destination ID and delivery date. All the other information is automatically brought up as you type in the auto numbers (relational database) and the date ordered is automatically entered in due to the date input masks (as explained later).
Final Order Form
This form includes a title, instructions and record navigation buttons to take the user manually through the records. Also the fields where information needs to be entered is written in red for the users convenience.
AVOIDING HUMAN ERRORS USING INPUT MASKS
To improve the database and make it less likely for users to input errors into the database I have included a number of ‘Input Mask’s’ and default values, these are all shown below:
Customer Data Table:
There is an input mask in Customer Surname field, which makes it impossible for the user to enter in anything but a capital letter for the first character.
There is an input mask to make sure the Business postcode has a letter, letter, number, number, number, letter, and letter.
Destination Table:
There is an input mask for the business postcode, which is the same as the input mask above.
Order Table:
I have included a default value on the Date Ordered field, which enters in the correct date automatically once you add a new record.
VALIDATION RULES
I have included several validation rules which make sure the specification (as stated previously) is carried out. These Validation Rules include making sure that the: -
- maximum weight of 30 Kg and a minimum weight of 1 Kg, which is the validation rule on the Weight Field in the Parcel Table.
The validation rule stated that the value entered in the weight field must be between 0 and 30 Kg. So the smallest value you could enter is 1.1 Kg and the largest you could enter is 30 Kg.
- maximum length of 150 cm, which is the validation rule for the Length field in the parcel table.
The validation rule stated that the value entered in the length field must be between 0 and 150 centimeters. So the smallest value you could enter is 1centimeter and the largest you can enter is 150 centimeters. It also means this it won’t be possible for the user to enter in a negative number.
- maximum total dimension of 300 cm, which is the validation rule for the Total Dimensions field in the parcel table.
The validation rule stated that the value entered in the total dimension field must be between 0 and 300 centimeters. So the smallest value you can enter is 1 centimeter and the largest you can enter is 150 centimeters. It also means this it won’t be possible for the user to enter in a negative number.
- The maximum weight of any one consignment is 200kg. I have included the validation rule that if the total weight of any one consignment goes above 200 kg an error message will be displayed.
QUERIES
Simple Queries
To improve my database further I have set up a query. A query is a function, which can do things like looking up certain fields in a certain table and searching for something within that field.
Parameter Queries
A parameter query is more complicated than a simple query. It is a query which when runs, displays a dialog box, which asks you for information e.g. a surname. The query then looks through the customer records and would find all the records with that surname. When you create a query you need to decide what fields of the matched record to show. This is done by first of all picking the tables you want and then the fields, which are pasted into the field row at the bottom. Then you need to type in what the dialog box is going to say, this is put in the criteria row under the field, which is going to be searched for a match. In my database I have included the following queries:
Finding Existing destination
This query is one, which the user can use, to find the information on a destination, which the customer has already previously sent a parcel to. This should help the user to save both time and disk space as it makes sure only one copy of the same address is kept on record.
I have included all the fields because when the query brings up the record asked for, the user will want to see all the information held on that record. To make the parameter query work I need to specify the criteria by which the computer will search the records. In this case the criteria is as follows:
This formula means that the computer has to look in the destination table and under the Name of Recipient company, as shown in the query screen print showing all the fields, to get a match to the name of recipient which is written in as shown in the above caption.
In the dialog box I could have had one of two possible formulas I could have had:
- Like “*” [Enter Business Destination Name:]”*”
With this search the user would have to enter in the full business name, however with the following formula which has a wild card, which is the two & signs either side of the parameter, the user will not have to enter in the whole name to get the record as it can match up the beginning three letters with the record needed. This is good as it will save time and doesn’t mean the user has to enter in long company names.
- Like “*”&[Enter Business Destination Name:] &”*”
When the query is run the following dialog box is shown.
Finding ID
This query is also intended to save the user time when finding an existing customer’s ID number if they had forgotten it. The dialog box will ask the user for the Business name of the company that is sending the parcel.
Updating customer data
This is another query which saves the user time when entering and changing data. The dialog box asks the user the business name of the customer and then the computer matches the name given with the business name fields in the customer table records. The following diagram shows the criteria formula.
Total Dimensions
This query speeds up the entering of the parcel data by calculating the total dimensions of the parcel by adding up the width, length and height. This both saves time for the user and helps to prevent human error when calculating the total.
I used the Expression Builder function to put this calculation into a formula.
Finding Weight From Price
To do this I had to use the weight and cost fields, however in order for the user to be able to enter in the weight of a parcel and for the computer to work out the price you have to use the relationships and get the weight from the parcel table and match it up with the weight in the weight cost table where it will then get the price. This has been made possible because of the relationships as discussed previously. The screen print below shows you how the weight and cost have been taken from different tables.
This query is not used as a parameter query as it is not directly going to be used as parameter query, it will be used to create the form to enter data about parcels.
Below is the overall design view of the two queries as explained above.
CONSIGNMENT NOTE
As a Report
The consignment was produced using the report wizard and pervious discussion explains the layout and design of the note.
This is the first design of my consignment form, which will be given to both the deliveryman and the customer.
Below is the final design for my consignment note. The annotated notes describe the improvement I have made.
As a Query
The above screen print shows the design view of a query for the consignment note, which after the user inputting the customer’s ID will display the total cost, and weight of all the parcels being sent by that person.
The screen print below shows the form created when the user asks the computer to run the consignment query for the customer with ID number 1. This consignment note will be given to the customer along with the itemized list given to the deliveryman.
Integrated Consignment notes for the deliveryman and Customer
Instead of having two separate consignment notes for the deliveryman and the customer I have designed a query which incorporates all the field from both consignment notes. This query is shown below.
The combined consignment note includes the following fields:
- Sum of Weight
- Sum of Cost
- Title
- Customer Surname
- Name of recipient
- Address of recipient
- Town
- Total Dimensions
- Weight
On the following page is the consignment report created for the customer with ID 5.
REPORTS
Price Lists
It is specified that a report showing the price listings for the various weights is included in the system. I have made a simple report, which will show the managers the prices. This report is shown below. As you can see it is clear and simple.
Buttons
As you can see from the above screen prints I have used button in all of the switchboards which when clicked will take the user to the forms and queries as specified on the buttons themselves.
The code for the buttons is shown in appendix 2.
MAKING THE DATABASE USER FRIENDLY
Making Menus
I made a switchboard menu by using design view and then adding images using clip art, words using the text box function and buttons, which are explained further on.
My first draft of a menu included all the facilities for both existing and new customers and is shown below. As you can see it is very cluttered and a user would possibly find the many choices very confusing and would be likely to make mistakes. Also the overall appearance of the form is very boring and not interesting at all.
In order to make the system more user friendly and less cluttered I have broke the menu up into three individual menus. I have first created a welcome menu, which gives the user a choice of going into Existing or New Customer switchboards depending on the customer being dealt with. The existing and new customer menus then provide buttons, which allow the user to do a number of things concerning the database. On the following page are copies of the final welcome menu and new and existing customer switchboards.
MANAGERS STATISTICS
The above screen print shows a query in which I used the sigma function in order to count the number of parcels, add up the prices of all the parcels and to add up the weight of all the prices. Below is the output from this query for all the parcels ordered.
The managers simply get a table displaying data about the number of parcels ordered, the total income from the ordering of the parcels and the sum of the weight of all the parcels.
SECURITY
To keep the database secure from hackers or from people who are not officially allowed access to the database I have put a password on to the database, which only the users will know. By putting passwords on the system it will comply with the data protection act. There are several rules for passwords, these include:
- Passwords should be at least 6 characters
- Passwords must not be displayed on the screen but must be masked by asterisks.
- Files containing passwords must be encrypted
- Passwords must be kept confidential
- Passwords must be changed regularly
Also for security reasons the company should make sure that the system is regularly backed up using a zip file on to disk. That disk should then be placed in a secure place preferably off site and in a fire proof secure box.
Further security precautions include:
- Keeping the room with the computer systems in securely locked n an alarmed room when they are not being used.
- Installing a virus checker.
MAKING THE MENU COME UP WHEN THE DATABASE IS OPENED
At the moment you can still see the tables, queries and the access program and you have to go to form and open up the menu. So to improve my database for the end user I have made a macro so that as the database is opened it comes up straight away with the menu thus preventing the user seeing the behind the scenes program. As well as making it less complicated it ensures no one will copy your design.
To create the macro I clicked on macro in the main menu, and then I clicked on ‘new’. Then a form for writing macros comes up, there are lots of boxes under the title ‘Action’ you have to drag down on the arrow to hourglass, and then in the box underneath you put ‘Open Form’ this then brings up a box titled ‘Action Arguments’ there is a list of fields in the field ‘Form Name’ put ‘Welcome’. This means that the ‘Welcome’ menu will come up when the database in opened. Then you have to put another action in the action column, this time you have to put ‘maximise’, this is put here so that the form will be maximised when opened.
Once you have done a macro like this you must save it as ‘Autoexec’ this is what commands the computer to open the form automatically.
TESTING
There are various strategies of testing, these include:
- Dry run – manually working through out the program step by step
- Unit testing – you test each section of the program individually
- Integration test – test as a complete system
TESTING THE BUTTONS
I first tested to see if the buttons, which move from form to form or to queries were working. To do this I set up a table. The table includes where the buttons move from and where it goes to and whether it works or not. The table is shown below.
The results in the table show that all the buttons work and do not need modifying.
TESTING THE QUERIES
I needed to test all the queries to make sure they were working properly.
Finding existing destination
I tested this query by asking the system to look for a destination ‘Gemma’s Café’, I typed in the business’s full name, you can see from appendix 1 (which shows the data sheets) the correct data which should be displayed.
Once the query has run it comes out will the following result which when checked with the data sheets shows that the results are correct and the query works.
To see if the query still worked when I typed in only ‘Gemm’ the results were the same as before. Thus showing that the query is definitely working correctly.
Finding ID
I used the business ‘Hats are you’, you can see from appendix one what the correct data should be. Below is a screen print of the findings via the query.
Finding price from weight and total dimensions
To run this query in my database the user has to fill out the weight field in the ‘Parcel form’ and then the Order form using that customer’s parcel ID, customer ID and destination ID.
If the weight of the parcel is 8 Kg then the price of sending that parcel should be £9.10 as you can see from the appendix.
I tested this data by firstly telling the system that the parcel was 8 Kg in weight, the parcel ID, as you can see from below, is 19.
Now using the customer ID 5, Parcel ID 19, Destination ID 3 you get the following answer. The price of the parcel is £9.10, which as you can see from the appendix given to us is correct.
Update Customer Information
I have tested this query by asking for information about the business ‘The Folkestone School For Girls’, the appendix shows the information which should come up on the screen, which when checked with the screen print below, shows that, the query works.
TESTING VALIDATION RULES
Weight Restrictions
The weight restrictions say that the maximum weight is 30 Kg and the minimum weight is1 Kg. To test this firstly I tried to enter the weight as 35Kg (in test data given)
35 is greater than 30 by 5 Kg, therefore the database should not allow this value to be entered in.
When I tested this validation rule by entering in 35 Kg the computer gave the message:
Which is telling the user that the number is not between 1 and 30 and therefore it can not accept the value previously entered.
When I tried to enter the value -0.5 the same message came up, -0.5 is below 1Kg by 1.5 Kg. Therefore this validation rule works.
Length Restrictions
The maximum length of the parcel is 1.5 m. I tested this validation rule by entering in 120 m (as in test data given), which is 120 – 1.5 = 18.5 and there fore well over the allowed maximum value. When I tried to input this value a message came up saying:
Which means that the user has entered a value over 1.5, which is not allowed.
Total Dimensions Restrictions
The maximum total dimension of the parcel is 300 cm. I tested this validation rule by trying to input values for the width as 200 cm, length as 150 cm and height as 40 cm which would cause the total dimensions to be greater than the specified amount because 200 + 150 + 40 = 390 cm. When this was tried the following message came up saying the value was impossible for the system to accept.
Consignment Restrictions
The maximum weight of any one consignment is 200 kg. I tested this validation rule by entering consignments in where the total weight came to more than the specified 200 kg. When the total weight of three parcels came to 150 + 100 + 48 = 298 kg the database displayed an error message saying:
Also when I tried to enter in the value –2 the same error message was displayed. There for the testing shows the validation rules work.
Testing Input MasksCustomer Table
The input mask in Customer Surname field is not supposed to allow the user to enter in a lower case letter for the first character of the name. When testing this input mask I tried to enter in a lower case ‘e’. As a result the system automatically entered the ‘e’ as ‘E’, this is shown below in the screen print.
There is also an input mask to make sure the Business postcode has a letter, letter, number, number, number, letter, and letter. I tried to enter in 4 to begin with and it would not type it, only when I entered in a letter would it accept it.
Destination Table
There is an input mask for the business postcode, which is the same as the input mask above. The results from the testing showed the same thing, the system would only accept the right type of character when it is programmed to.
Order Table
I have included a default value on the Date Ordered field, which automatically once you add a new record enters in the correct date. To test this I created a new table to see if the correct data came up, the date when tested was 29/04/01 and as you can see from below the input mask works.
TESTING USING TEST DATA GIVEN
Testing Customer 1’s data
Weight 1.5Kg is not the exact weight for the price categories. This computer design is such that the user uses a list box to enter in the weight therefore the use would not enter in 1.5.
Length 25 is allowed as it is within the boundaries and the total dimensions are also within the boundaries.
Testing Customer 2’s data
Weight 15Kg is not the exact weight to fit in with the price categories. This computer design is such that the user uses a list box to enter in the weight therefore the use would not enter in 15.
Length 100 is allowed as it is within the boundary of 150. Also the total dimensions is also within the boundaries 100 +60 + 40 = 200.
Testing Customer 3’s data
Weight 35Kg is not the exact weight to fit in with the price categories. This computer design is such that the user uses a list box to enter in the weight therefore the use would not enter in 35.
Length 120 is allowed as it is within the boundary of 150. Also the total dimensions is also within the boundaries 120 +70 + 50 = 240.
Testing Customer 4’s data
Weight 20 is one of the specific weight price categories. However length 190 is not and as the user enters this value in a warning sign as previously shown comes up. This is the same as for the total dimensions.
Testing Customer 5’s data
All of customer fives data is acceptable so the user is able to input it without any warnings.
Testing Customer 6’s data
Weight 0.4Kg is not the exact weight to fit in with the price categories. This computer design is such that the user uses a list box to enter in the weight therefore the use would not enter in 0.4.
All of customer six’s dimensional data is acceptable so the user is able to input it without any warnings.
MAINTENANCE
Maintenance is important as it ensures the long life of the system, e.g. If the business changes so may the requirements of the system, by resolving bugs or program errors, which arise after the system has been implemented, and to enhance the functionality of the system when users require it.
We are not required to produce user documentation and system documentation. However if we had been required to produce documentation I would include the following:
User Documentation
- Installation Instructions
- Instructions on how to start and run the system. As well as a guide for using the different functions.
- Over view of the system and what it does
- Trouble shooting guide on possible errors and how users should deal with them
System Documentation
- Data Flow diagrams
- Data base diagram to display relationship between each of the tables
- Data entity diagrams
Appendix 1 – Data Lists
APPENDIX 2 – CODE FOR BUTTONS ON FORMS