Page 1 of 303 CG4 Resistant Materials Project CG4.1 ANALYSIS Background At Slough Grammar School, the Resistant Materials Technology department is involved in the ordering of materials for students studying the subject at GCSE and A Level. The current ordering system comprises of a paper based procedure. The students utilise a printed list of materials, the sizes available, and their respective prices to create an ordering list for the technician to collect. The students have to produce two copies of this ordering list for use in their subject coursework. There is no backup plan to replace these ordering lists should they be misplaced by the technician. The technician then uses the student ordering lists to create a batch order that covers all the student orders. The printed list of materials, and their respective details, is annually updated by the technician. These updates will consist of price changes, the addition, and removal of some of the materials available to the students to order. These changes in the list result in a new material order list for the next set of pupils to use. The creation of a computerised system will benefit the department of Resistant Materials Technology the most. The system will benefit the students and the technician as it will focus on how the department deals with ordering, with the aim of increasing its efficiency whilst benefiting the students also. The computerised system will seek to address secondary issues the department faces, such as department expenditure involving printing and non-existent backup measures. Nevertheless, the ordering aspect will remain priority.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1 of 303
CG4 Resistant Materials Project
CG4.1 ANALYSIS
Background
At Slough Grammar School, the Resistant Materials Technology department is involved in the
ordering of materials for students studying the subject at GCSE and A Level. The current ordering
system comprises of a paper based procedure.
The students utilise a printed list of materials, the sizes available, and their respective prices to
create an ordering list for the technician to collect. The students have to produce two copies of this
ordering list for use in their subject coursework. There is no backup plan to replace these ordering
lists should they be misplaced by the technician. The technician then uses the student ordering lists
to create a batch order that covers all the student orders.
The printed list of materials, and their respective details, is annually updated by the technician.
These updates will consist of price changes, the addition, and removal of some of the materials
available to the students to order. These changes in the list result in a new material order list for the
next set of pupils to use.
The creation of a computerised system will benefit the department of Resistant Materials
Technology the most. The system will benefit the students and the technician as it will focus on how
the department deals with ordering, with the aim of increasing its efficiency whilst benefiting the
students also. The computerised system will seek to address secondary issues the department faces,
such as department expenditure involving printing and non-existent backup measures. Nevertheless,
the ordering aspect will remain priority.
Page 2 of 303
Investigation and Analysis
An investigation into the current system was necessary to fully understand the depth of the issues
the solution will be required to deliver on. This meant investigating the efficiency of the current
paper based system.
The investigation proceedings began with an interview with Tony Smithers, lead technician at the
department. Mr Smithers dealt with producing the batch order, and supplying the materials ordered
to the students. His position meant he was the ideal candidate to question with regards to the
ordering process. The interview transcript is shown below:
What areas of improvement, if any, do you recognize in the current system?
“Well, you see the current method used for updating the material lists takes quite a long time. This
department is also facing new limitations in how much printing is done. So printing off the renewed lists
time and time again is not helping…Another thing is backing up the orders. You know sometimes the
students lose their copies and it takes a while to track their order down and hand over my copy. This
also means that my copy is also at potential risk of being misplaced too.”
Ok. Do you see any ways to improve these areas?
“To backup the orders, I mean, you could have them saved electronically on a document or something.
A method of bringing them up again efficiently would be brilliant. Giving the students access to them
will also help because they can change the orders without having to go through me. For the list, a
couple of years ago I transferred the list to the computer so that I can print them off when prices
changed etc. These new printing limits mean that somehow if the list could be interactive and stay on
the computer for access, which would be ideal.”
You describe feasible improvements to the areas of concern. What is the hardest aspect of the whole
ordering procedure in your view?
The hardest procedure would be…the calculating how many large material sheets to order so that it
would be enough to provide all the students with their orders.
Do you calculate that by the combined individual materials area or by the totalling of material lengths?
“I suppose it could be worked out both ways but I use the combining the individual areas to see how
many student orders will fit on a single sheet and make the batch order from that.”
The calculations are all supposedly calculated by hand yourself?
“Yeah all the calculations for the price and areas are done by me to make sure the student calculations
are correct. It takes quite a lot of valuable time. I suppose if they can be done electronically it will make
sure there are no errors for me to check really.”
Electronic calculations can potentially give inaccurate results. The accuracy of the calculations depends
on the quality of the code and the testing of the system. Thank you for your time and the next visit will
be about the design of the program.
Page 3 of 303
Analysis of Interview with Technician:
Updating the Materials list can be very time-consuming.
Backing-up the student orders is also time-consuming and difficult with the current system.
The printing limitations are not helping with the efficiency of the current system.
Identified the student order backups could possibly be available electronically.
Identified the calculations involved in the orders is the most crucial aspect, and one that
needs addressing the most with the new system.
Storing the orders would allow for the batch order to be created easier as the technician
would be able to access the student orders easier.
The interview with the technician highlighted the areas of concern. However, students using the
paper based system may well see other areas that they feel deserve more attention. It is important
that the investigation takes into account more than one viewpoint of the current system. Since there
are many students that may not share a collective view of the current system, it was decided a
questionnaire would be more useful to collect information rather than conducting several interviews
which would still not provide a clear picture. To collect the information from the students, an A5
data capture form was produced. The questionnaire, handed to thirty students, can be seen below:
Page 4 of 303
The questionnaire was completed by students studying the subject at GCSE and at A Level. The
questionnaire was completed and returned by twenty-eight students of the thirty, and the
breakdown of the results is as follows:-
The majority of the participants said the calculations aspect of the current ordering system
was the most difficult. Twenty-three students shared this view while the rest felt replacing
the order (having to recalculate) was the most difficult. Some students noted next to the
calculations choice about the confusion caused by the calculations.
All the students made clear that automatic calculations and saving the order in some form
were the most welcome features on a computerised system if there was to be one. The most
popular are of concern was calculations with nineteen votes.
The students did not see the additional username and password as being a big problem. The
majority also noted how the program may not be used as frequently if everything is stored.
Thus the additional username and password may not be a real problem.
Page 5 of 303
Most of the students chose the second option because they would are told never to under-
order any of the materials that would be needed. However eleven students chose the option
to be allowed to add and remove order items. The program is tailored for the technician and
students to use so it is important their needs are seen to.
In this question the students mentioned mostly about the program being able to help with
the ordering process. Through this it meant that a lot of the calculations are automatic and
using the program is simple.
A table of results has been created to summarise the results of the questionnaire.
Question Number
Answers Result 20% 40% 60% 80% 100%
1 Calculation of Order.
Replacing Order
2 Automatic Calculations
Amend & Reprint
3 U+P is a Problem
U+P is not a Problem
4 Remove Items Only
Remove & Add Items
5 Secure Orders
Automatic Calculations
The questionnaire provided a clearer picture of the students’ viewpoint on the current system. It
also provided information that will prove valuable come the designing of the system. But to ensure
the thorough investigation of the current system, personal observation of current practice and a
review of the existing system is needed.
The observation of the current practice highlighted the issues with the current system. The steps
involved in the current practice are:
Page 6 of 303
1. The technician updates the materials list with the prices, and an ordering form.
2. The students receive the printed list and ordering form.
3. The students use the list to complete the ordering form and calculate charges.
4. The student orders are handed back to the technician.
5. Technician validates the orders and the students’ calculations.
6. The students are charged and pay accordingly.
7. A batch order is produced that includes all the material needed for all the students.
A logical data model representing the procedures in the current system has been produced. This
helps to visualise the steps involved and also better understand the current system at hand.
SYSTEM FLOWCHARTS OF THE CURRENT ORDERING PROCESS
Material list and ordering forms
are updated by technician.
The ordering forms and
calculations are completed by the
students.
START
Student orders are validated by
the technician.
Students pay for materials order
and batch order that caters for all
the student orders is produced by
the technician.
Batch order is sent to schools
finance department for
processing and makes its way to
the suppliers.
FINISH
The ordering forms and calculations are
completed by a student. The completed
order is given to the technician.
Is the student
orders completed
correctly?
START
EACH STUDENT ORDER PROCESS
YES
NO
Student order is validated by the technician.
The student order is filtered and separate
materials are grouped to calculate how many
sheets are required.
FINISH
The separate materials are added to the
batch orders that will be sent off to the
material suppliers.
Has the student
finished the order? NO
YES
Page 7 of 303
Data flow modelling involves identifying and documenting how the data moves around in the
current system. This examines the processes, data stores, external entities and data flows in the
current system to help understand where data is input, and visualise the data calculation stages. A
data flow diagram representing the current system at the Resistant Materials Department can be
seen below.
DATA FLOW DIAGRAM OF THE CURRENT ORDERING PROCESS
To identify the relationship between the entities involved in the current system an entity
relationship diagram was produced and can be seen below.
ENTITY RELATIONSHIP OF THE CURRENT ORDERING PROCESS
STUDENT
SUPPLIER
TECHNICIAN
MATERIAL ORDER
BATCH ORDER
KEY
One to many
relationship.
One to no more
than one
relationship.
SUPPLIER ORDER
Page 8 of 303
The ordering system proved to be very lengthy and some orders required weeks before actually
making it through to the suppliers. Further delays such as misplacing orders, or last minute changes
and recalculations could further delay the process. This was crucial as there were department
deadlines to meet for the orders because there is only one financial window per department at the
school. Seeing this further supported the fact that this department would benefit the most at the
school.
The data collected by the system is derived from the materials ordering form. From following details
are collected:
Student Details (Name, Form)
Date
Material Details (Material, Size, Quantity)
Cost (per Material, Total Cost)
This ‘Materials Ordering Form’ can be seen below. The collected data has already been processed by
the students to calculate the costs. The data from which the calculations are derived from, the
‘Materials List’, can also bee seen further below. The processing of the data involves calculating the
cost of the materials. An example of the calculations involved follows.
The price of a piece of 9mm MDF measuring 480 x 680 (mm) is calculated by:
( Unit Cost / Unit Size ) X Order Area
( 4.00 / 744200) X (480 x 680) = 1.754367...
Which is rounded and the student would be charged £1.75 for the material
This calculation is performed for all the materials on the order form. The order has do be written out
twice by the students increasing the chances of potential mistakes. This can result in the student
being over-charged and provides the technician enough reason to have to validate the student
orders. An example of a finished student order can be seen below.
Page 9 of 303
The data processed in the current system uses the collecting data. This includes specifics such as:
Type of Material
Depth of Material
Area of Requested Size (of material)
Quantity
Unit cost (per material sheet)
The processing of the data is the calculations (as detailed above) being performed.
Output of the Current System:
The image above is the output from the student (materials ordering form). This order is then used
for the batch order created by the technician. The orders on the forms are validated by the student’s
teacher and the prices are validated by the department technician. The final forms may be changed
from the originals and this may require completing another form as the final copy to place in the
student’s coursework.
Other outputs of the current system include the materials list that is updated. This is also distributed
in the form of paper to the students and threatens the printing limitations the department faces
every term.
A full view of the student ordering form can be seen on the following page.
Page 10 of 303
Limitations in the Current System:
The limitations in the current system include being able to efficiently update the student
order. This was identified in the interview with the technician. A computerised system would
easily deal with this limitation as orders would be stored in a flat file where they can be
retrieved for amendments at any given time.
Page 11 of 303
Another limitation is the printing availabilities. The department is limited in its amount of
printing and at around 90 students potentially changing their orders on a regular basis, or
making any errors, it results in a high demand for printing. Annual updates and printing of
material lists only add to the problems caused by this limitation. The proposed computerised
system would also deal with this as the order can be stored and amended until the student
is content, ensuring every student need only to print their order once.
The lack of backup procedure that should store the latest student orders is an additional
limitation. The amount of loose paper in the form of material orders that are exchanged
between student and technician involves the risk of misplacing the orders. This causes a
nuisance to both the student and the technician as it means re-calculating and re-validating.
The current system is also limited in how it deals with performing with respect to
department deadlines. There is a window in which department finances are dealt with and
should a student order miss this window, it places the risk of jeopardising the continuation
of the course.
This highlights the extent of the problems the late changes in prices and the recalculations in student
orders can cause.
Below is the materials list that will need updating if the prices for the materials change.
Page 12 of 303
The investigation and analysis of the current system highlighted the bigger problems and the views
of the target users of the computerised solution. The analysis also emphasised the limitations that
the computerised solution will be trying to attend to. The current system has been analysed
sufficiently and the information from it is more than enough to create a problem definition and
produce suitable project objectives.
Page 13 of 303
Problem Definition
The Resistant Materials Technology department at Slough Grammar School has been utilising an old
paper based system for the ordering processes. The department procedures were in need of an
update. The department relies on the department technician, Tony Smithers, to deal with all the
aspects of the ordering. After a thorough investigation of the current system, a clearer picture of
what the computerised system will need to address can be drawn.
The intention is to create a computerised system that the students can utilise to order their
materials. The computerised system should be accessible to students from years 10 to 13 at the
school, studying the subject. The new system should also allow staff and the technician to make any
changes to the materials list. The program should include automated calculations meaning no
manual calculations or validation should be needed. The new system should aim to meet the project
objectives and be tailored to client needs.
The system should allow for separate student and staff logins. The login steps should aim to be
simple and not complicate the process. The staff login will be used for certain aspects of the ordering
process such as accessing all orders and the ability to amend the materials list.
The student login should allow the students access to an ordering form where the actual material
ordering can take place. The solution should be designed to make the process easier than doing the
equivalent on the current system. The form should allow material selection, size and quantity
options, and a relatable interface. Most of the solution will be automated. Ideally, the new system
will be straightforward to use and thus not need any instructions on the input forms etc.
The system will store all the student order details and the updates of the material lists in a flat file.
The system produced will cover all aspects of ordering process and will take into account
amendments may need to be made after the initial order has been created.
Despite these aims, there may be possible limitations in the computerised system produced. The
preliminary limitations may include:
Keeping track of the latest time and date of the order update.
Keeping track of when the order was last accessed or amended.
The delegation of unique usernames and passwords considering the number of students
that will potentially use the solution annually.
Automatic updates to student orders based on the changes on the material list.
An efficient password reminder facility that is secure, restricting access to other students
who may try to exploit the facility.
Taking into the account the limitations the initial project may face, the problem definition allows for
the initial project objectives to be written.
Page 14 of 303
Objectives
The main objective of the project will be to create a replacement system for the ordering process
within the Resistant Materials department. The system will benefit both the department and the
students. A computerised solution will be created using Visual Basic 6.
This will include a user interface capable of allowing the students to:
Register to use the system if it is the first time they are using it.
Be reminded of their password.
Enter their login details to access the materials ordering form.
Choose materials and the sizes of the materials to enable the program to calculate the
prices.
Amend a previous order.
Print the latest order by displaying the total order on a printable form.
View the latest materials list for information on material availability and prices.
The interface will be capable of allowing the staff to:
Register to use the system if it is the first time they are using it.
Enter their login details to access the materials list form.
Edit the materials list once accessed.
Access any student order.
Be reminded of their password.
The system will allow the input of and have the facility to store the following details:
Student Username, Password and other student details.
Student Order:
o Material name selected.
o Material Size selected.
o Quantity selected.
o Cost of order.
Any updates to the Material List.
Any updates to the Student Order.
The system will allow for the searching of student order by the student login details. The login details
will be stored alongside other data that will ensure the correct order is displayed at the time of
searching. This will also ensure no errors occur during search or more than one order is related to
one student.
The design of the computerised system should be professional and simple to use as students will be
using it as well as the staff members of the department. The appearance of the system should
remain consistent to ensure the program navigation is quick and simple. The computerised system
should be completed within the time provided.
Page 15 of 303
CG4.2 DESIGN
Output Content and Format
The output of the computerised system will include printed forms that summarise the student
material orders. This will be the main output of the system. The data that will be output from the
system will be the finished orders of the students. These will include all the material information
such as Type, Size, Depth, Quantity and Cost. As well as this, essentials such as student name and
form will be displayed on the form. These will ensure there is no confusion as they will serve as
order identifiers on the printed forms. The data included in the output is essential as it is the
information that is required by the technician and the students’ coursework files. This is why the
data chosen to be included in the output, is included. The form will appear with a white background
to remain printer friendly when it is printed. When the form is printed, the command buttons,
images and time which are all non-related to the order will be hidden. This will leave for an elegant
solution and provide an elegant output from the system.
Below is the design of the output form of the system. (Printable Student Order Summary Form)
<-
Time
Display Full Name
Display Form
Cost: £ Signed…………………………
.
##/##/####
PRINT
No. of Items
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form. Hidden when
form is printed.
Label: Displays the current
time. This is also hidden
when the form is printed.
Label: Displays the title
of the page. Will display
on the printed form.
Labels: Displays the
students name and the
students form in the
respective labels. Will
show when printed.
Labels: Displays the date.
It is vital this is displayed
in the printing form.
The number of items
ordered will be displayed.
Labels: Displays cost and
the actual cost of the order.
Formatted in currency.
Label: Displays the signed text.
This is for the teacher’s signature.
This will be displayed on print.
CommandBox: Prints the form with the
whole order being displayed. This cmdbox
will be hidden on the printed form.
DataGrid: Displays all the
material items that have
been ordered by the
student. This forms the
main art of the printed
form. Columns of
information will be
Material, Depth, Size,
Quantity, Cost will be
visible. The columns that
store data that links the
orders to the students will
not be visible in the data
grid. This will make for an
elegant output of the
computerised system.
Material Order
Page 16 of 303
Another output of the system will be an electronic version of the materials list. This will allow
students and staff to view the latest prices.
The form should display the latest prices which may be edited by the technician or staff member.
The form will use a datagrid to retrieve all the information from a database. The datagrid should not
allow any editing to the information when used in this form. This form will not be printable through
the system.
The material information is included in this form because it will be available to both students and
members of staff. Students will use this form to check the prices when considering their material
order and members of staff can check the prices are up to date and accurate.
Below is the design of the output form of the system. (Viewing Materials List and Latest Prices)
Another output form will be available from the main menu of the program. This will be a display
screen for the information about the system. This display screen is essentially to ensure the solution
to the problem is complete and the program is produced properly.
<-
Time
Label: Displays the
title of the page. DataGrid: Displays all the
material items and their
prices from the database.
The columns will display
Material, Depth, Unit
Sheet Size, Unit Cost and
any other additional info.
It will be locked as it is
available to the students
and thus values in the
datagrid will not be
editable.
This information will be
linked directly to the
database and should
display the latest
information.
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form.
Label: Displays the current
time.
DataGrid: The
background colour of
the datagrid should
relate to the colour
scheme of the form.
Materials List
Page 17 of 303
The form should display information on the version of the software solution, what the application is
designed to do, who it is developed for and who it is developed by. This information will provide the
software version, which if is updated through maintenance, can be updated and replaced.
Below is the design of the output form of the system. (About (the Application) Form)
The output forms designed above will all have similar backgrounds and colour schemes to ensure
the appearance of the program is consistent. This should aid user navigation and make using the
program easier. The background for all the forms will be a custom-made image, consisting of pastel-
light tones for a modern yet professional appearance.
The size of the forms will vary as their purposes vary. The ‘Material Order Print’ Form will be big
enough to fit the screen and space the data so that the printed orders stay elegant. This will also
help the technician as the data printed will be easy to read and key facts will stand out on the
printed page. The size of the ‘About’ form will be smaller as it provides useful, yet little, information
and thus does not need to occupy as much room on screen.
The position of the forms on when displayed on the screen will be set to Centre-Screen position so
that all output forms and display screens load in the centre of the user’s screen. Failure to ensure
this would damage the professional impression the software will be aiming to make.
Time
GIF IMAGE
Label: Displays the title
of the page.
PictureBox: With a
WebBrowser control
placed inside to load the
GIF animation as VB6 is
not capable of displaying
GIF images otherwise.
CommandBox: Exits the
form. A mouseover effect
will be applied to the
command button to make
using the program user
friendly.
Clicking this should also
make the main menu
form useable again.
Label: Displays the current
time. LOGO
Version………………………..
App Description + Info
Additional Info OK
ImageBox: This will
display the software
logo, which will
remain consistent
and be displayed in
all the forms in the
system tray.
Label: Displays the
information about
the version of the
software.
Displays the
description of the
app, explaining its
purpose and who the
application is tailored
to.
Any additional info
displayed below.
Resistant Materials
Ordering App.
Page 18 of 303
Input Content, Capture and Format
There will be many input forms in the new system as the main aim will be to make a program that
satisfies all of its broad objectives. All the designs have taken inspiration from the designs and notes
of Mr. Smithers the technician at the department. They can be seen after the designs of the input
forms.
MAIN MENU FORM
The design of the input form frmMainMenu.
The input in the form here will be in the form of command boxes. These will allow the user to make
a selection as to how the user logs in. The selections will be ‘STUDENT’ and ‘STAFF’.
The selection here will not be stored but will determine the next form that is displayed. The use of
command boxes here is most appropriate as there are only two choices and any other form of input,
such as textboxes, would not be suitable. The background of the form will remain consistent and be
similar to the output forms. The positioning of similar elements in the form will also remain the
same e.g. Return Image, position of title, display of time etc. The size of the form will be slightly
smaller than the others to differentiate it as a main menu rather than a data capture form. This will
be the first form on display when the program is loaded and its start-up position will be the centre of
the user screen.
Time
PictureBox: Displaying
ORDERING APP. When
clicked it will display the
ABOUT form which will
include all the information
about program.
CommandBox: Exits the
form. A mouseover effect
will be applied to the
command button to make
using the program user
friendly.
Clicking this should also
make the main menu
form useable again.
Label: Displays the current
time and displays the
date.
LOGIN
Labels: Will display
the department
name in front of oval
shapes. The font
colour will be black
and the shapes back
colour, yellow.
Labels: Displays the
information for the
login command
boxes. Will simply
display STUDENT and
STAFF. Mouse over
effects will be applied
here to make the
form interactive and
make obvious the
selection on the form.
The font colour will
be vbBlack and a bold
font will be used.
Resistant Date
LOGIN
Technology
Materials
Student Staff
Page 19 of 303
STUDENT LOGIN FORM
The design of the input form frmStudentLogin.
`
The input in the form will be in the form of textboxes and CommandButtons. These will allow the
user to input their username and passwords, and click to allow access to the users account. From
here the user will be able to access the other features of the program. There is also a command
button that will display the password reminder form. CommandButtons were the most appropriate
methods of input for the described.
Other input in the form will be by input in the textboxes. This is because data entry via keyboard is
required to input the user’s username and password. So textboxes were the most suitable form of
input here. Textboxes also have a ToolTipText feature that displays help on what to enter when the
cursor hovers over the box.
The background of the form will remain consistent and be similar to frmMainMenu. The positioning
of elements in the form will be logical e.g. the return button on the top left of the form. The size of
the form will be slightly smaller than the others to differentiate it as a login screen rather than a
form with a main feature of the system.
The forms start-up position will be centre screen also.
Time
Label: Displays the title
of the page.
PictureBox: Displaying an
image of a page. To
differentiate form the staff
login page, this will have a
book. Also groups the
inputs together.
CommandButtons: The
button marked “?” when
clicked will display the
password form that will
remind users of their
password in some way.
The LOGIN button will start
the search for matching
username and password
and give the user access
depending on match.
Label: Displays the current
time.
Don’t have an account? #####
Label: Displays
USERNAME and
PASSWORD in black
bold font.
Textboxes as inputs to
the right of the labels.
The most suitable for
this type of input.
If user does not have
an account a link will
display frmRegister.
LOGIN
Student Login
<-
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form. FrmMainMenu.
?
Username:
Password:
Page 20 of 303
STAFF LOGIN FORM
The design of the input form frmStaffLogin.
`
The input in the form will be in the form of textboxes and CommandButtons. These will allow the
user to input their username and passwords, and click to allow access to the users account. From
here the user will be able to access the other features of the program. There is also a command
button that will display the password reminder form. CommandButtons were the most appropriate
methods of input for the described.
Other input in the form will be by input in the textboxes. This is because data entry via keyboard is
required to input the user’s username and password. So textboxes were the most suitable form of
input here. Textboxes also have a ToolTipText feature that displays help on what to enter when the
cursor hovers over the box.
The background of the form will remain consistent and be similar to frmStudentLogin. The
positioning of elements in the form will be logical and also remain consistent with frmStudentLogin.
The size of the form will be similar to the size of the student login form.
The forms start-up position will be centre screen also.
Time
Label: Displays the title
of the page.
PictureBox: Displaying an
image of a black book. To
differentiate form the
student login page. Also
groups the inputs together.
CommandButtons: The
button marked “?” when
clicked will display the
password form that will
remind users of their
password in some way.
The LOGIN button will start
the search for matching
username and password
and give the user access
depending on match.
Label: Displays the current
time.
Don’t have an account? #####
Label: Displays
USERNAME and
PASSWORD in black
bold font.
Textboxes as inputs to
the right of the labels.
The most suitable for
this type of input.
If user does not have
an account a link will
display frmRegister.
LOGIN
Staff Login
<-
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form. FrmMainMenu.
?
Username:
Password:
Page 21 of 303
REGISTER FORM
The design of the input form frmRegister.
`
The input in this form will require both textboxes and command buttons. The textboxes will be used
to capture the data entry on the form. The data entry will include USERNAME, PASSWORD and
STUDENT DETAILS. The textboxes will also feature ToolTipText so when the cursor is hovered over
the textbox, providing help as to what to enter in the textboxes. Also used for the first time in the
system will be combo boxes. They feature options that the user may choose from. This form of data
capture ensures the user cannot input any invalid data such as characters in a field that requires
integers. The command button on this form will provide a method of checking all fields have data
entered into them before adding the data into the database.
The background of the form will remain consistent and be similar to all the other forms on the
program, using pastel-like shades and colours. The positioning of the return image, title and time on
the form will also remain consistent. The size of the form will be similar to the size of form
frmMainMenu, smaller than the forms that store the order data. The forms start-up position will be
centre screen (VB option).
Time
Label: Displays the title
of the page.
ComboBox: Displays the
options STUDENT and
STAFF. This ensures no
invalid data can be entered
in this box. This also
determines where the data
is stored when the CREATE
ACCOUNT button is clicked.
CommandButtons: The
button marked “?” when
clicked will display the
password form that will
remind users of their
password in some way.
The LOGIN button will start
the search for matching
username and password
and give the user access
depending on match.
Label: Displays the current
time.
Label: Displays
USERNAME and
PASSWORD and the
other labels in black
font.
TextBoxes:
Textboxes as inputs to
the right of the labels.
The most suitable for
this type of data input
capture.
CREATE
ACCOUNT
Sign Up
<-
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form. FrmStudentLogin
or FrmStaffLogin.
Username:
Password:
Confirm Password:
Alias:
SCHOOL USERNAME
SCHOOL PASSWORD
CONFIRM PASS.
Full Name: FORENAME SURNAME
Tech. Class: GROUP
Margin: Invisible margin on the form to
keep the appearance of the form organised
and easy on the eyes.
Page 22 of 303
STUDENT OPTIONS FORM
The design of the input form frmStudentOptions.
`
The form frmStudentOptions requires input in the form of selection. No input via textboxes is
needed here. The reason for this is because this form is a method of giving the student options to
access the different features of the program. The command buttons are enough to display the
respective forms. The selections will include NEW ORDER, EDIT ORDER, PRINT ORDER and VIEW LIST.
The background of the form will remain consistent and be similar to all the other forms on the
program, using pastel-like shades and colours. The positioning of the LOGOUT image will have to be
similarly placed on the staff options form. The size of the form will be similar to the size of form
frmMainMenu, smaller than the forms that store the order data. The forms start-up position will be
centre screen (VB option).
The form will have an appropriate caption. The GIF animations will be still to start with and the
mouse over effect on the forms will include running the animations when the cursor hovers over the
image. This screen will be used the most by all the students. To help the students understand the
options on the form a little description might be displayed at the bottom of the form upon
mouseover.
Time
Label: Displays the title
of the page.
Label: Displays the name of
the student that has logged
in. This will call data from
the database and display it
in on the form.
The data for display may be
displayed in a temporary
data form.
CommandButtons: The
button should display the
appropriate forms if the
images are not clicked to
the display the respective
forms.
Mouseover effects will be in
place here to give the
impression they can also be
clicked and which choice
the user will be making.
Label: Displays the current
time.
PictureBox: Contains
the web browser
control which allows
GIF images to be
displayed and
animate.
WebBrowserControl:
In the navigation
property will display
the GIF files.
Welcome
LOGOUT ImageBox: Displays
the logout image.
Once clicked will
display the main menu
form.
New Order Edit Order Print Order View List
You are logged in as: [ ]
NEW ORDER
GIF IMAGE
VIEW MAT.
LIST GIF
IMAGE
PRINT ORDER
GIF IMAGE
EDIT ORDER
GIF IMAGE
Page 23 of 303
STAFF OPTIONS FORM
The design of the input form frmStaffOptions.
`
The form frmStaffOptions requires input in the form of selection. No input via textboxes is needed
here. The reason for this is because this form is a method of giving the staff options to access the
different features of the program. The command buttons are enough to display the respective
forms. The selections will include VIEW LIST, EDIT LIST and FIND ORDER.
The background of the form will remain consistent and be similar to all the other forms on the
program, using pastel-like shades and colours. The positioning of the LOGOUT image will have to be
similarly placed on the student options form. The size of the form will be similar to the size of form
frmMainMenu, smaller than the forms that store the order data. The forms start-up position will be
centre screen (VB option).
The form will have an appropriate caption. The GIF animations will be still to start with and the
mouse over effect on the forms will include running the animations when the cursor hovers over the
image. This screen will be used the most by all the staff. To help the members of staff understand
the options on the form a little description might be displayed at the bottom of the form upon
mouseover.
Time
Label: Displays the title
of the page.
Label: Displays the name of
the student that has logged
in. This will call data from
the database and display it
in on the form.
The data for display may be
displayed in a temporary
data form.
CommandButtons: The
button should display the
appropriate forms if the
images are not clicked to
the display the respective
forms.
Mouseover effects will be in
place here to give the
impression they can also be
clicked and which choice
the user will be making.
Label: Displays the current
time.
PictureBox: Contains
the web browser
control which allows
GIF images to be
displayed and
animate.
WebBrowserControl:
In the navigation
property will display
the GIF files.
Welcome
LOGOUT ImageBox: Displays
the logout image.
Once clicked will
display the main menu
form.
View list Edit List Find Order
You are logged in as: [ ]
FIND ORDER
GIF IMAGE
EDIT LIST GIF
IMAGE
VIEW LIST
GIF IMAGE
Page 24 of 303
EDIT MATERIALS LIST FORM
The design of the input form frmEditList.
The data input on this form will take place directly in the datagrid. No input outside this datagrid will
take place. The datagrid will be re-queried on the change property so that any changes are
automatically updated. Simply exiting the form can be done without the need to click a SAVE button.
Then the changes can be viewed on the form frmViewMaterialsList from the staff options.
This is the most suitable method of inputting the data because it is updated on-the-fly. The form will
remain consistent in its appearance and have a similar background as well as keeping the
placements of the items on the form the same.
This will be an important form come every term and the technician will be using this form a lot. It is
important that enough help is provided as to how the form should be used.
<-
Time
Label: Displays the
title of the page. DataGrid: Displays all the
material items and their
prices from the database.
The columns will display
Material, Depth, Unit
Sheet Size, Unit Cost and
any other additional info.
It will not be locked and
will allow ADD, DELETE,
UPDATE any material
information on the form.
This information will be
linked directly to the
database and should
display updated
information on-the-go.
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form.
Label: Displays the current
time.
DataGrid: The
background colour of
the datagrid should
relate to the colour
scheme of the form.
HELP
CommandButton: When clicked will display
a MsgBox that will inform the member of
staff as to how to edit the list and what sort
of editing can be one on the datagrid.
Edit Materials List
Page 25 of 303
NEW ORDER FORM
The design of the input form frmNewOrder.
The data input on this form will take in the picturebox which will contain comboboxes and
textboxes. These are the most appropriate types of input here because in some areas it is vital the
data is valid to search the database for cost information. Other fields, such as length, will be
captured by using textboxes. These will also be validated to ensure there are no errors or no
erroneous data is entered. When the ADD button is clicked, validation checks will be carried out
before storing the data into the appropriate table in the flat file.
This is the most suitable method of inputting the data because it is updated on-the-fly. The form will
remain consistent in its appearance and have a similar background as well as keeping the
placements of the items on the form the same. This will be an important form and should be
validated correctly. The appearance of the form will remain consistent and information placed in
logical places on the form.
<-
Time
Label: Displays the
title of the page.
Labels: Displays all the
information; NAME,
FORM, NUMBER OF ITEMS
IN BASKET.
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form.
Label: Displays the current
time.
SUBTOTAL
Label: The label will display the total cost of
the order of all the items added into the
basket (datagrid to the left).
New Order
DataGrid: Displays all the
material items and their
prices from the database.
The columns will display
Material, Depth, Unit
Sheet Size, Unit Cost and
any other additional info.
It will not be locked and
will allow ADD, DELETE,
UPDATE any material
information on the form.
This information will be
linked directly to the
database and should
display updated
information on-the-go.
The background colour of
the datagrid should relate
to the colour scheme of
the form.
NO. OF ITEMS
PRINT
ADD
CLEAR
CommandButtons: Will
allow the student to add a
material to the basket.
Will display the print
order form. From here the
order can be printed to
hand to the technician to
make the batch order.
PictureBox: Contains the
comboboxes used to
ensure the order is valid.
Will group the inputs and
also be used for an effect.
Page 26 of 303
FIND ORDER & EDIT ORDER FORM
The design of the input form frmEditOrder.
This form will be used by both students and members of staff. It will require input into textboxes to
search the database and retrieve the correct order. From hereon the order can be amended by
either student or technician. The form will be very similar to the new order form because it needs to
allow ADDING, DELETING to the order. So the textboxes used for search will be the only change to
the form. It will also provide a link in the form of a command box to the printing order form.
The form will remain consistent in its appearance and have a similar background as well as keeping
the placements of the items on the form the same. This will be an important form and should be
validated correctly. The appearance of the form will remain consistent and information placed in
logical places on the form.
<-
Time
Label: Displays the
title of the page.
CommandBox: When
clicked will search the
database for the
USERNAME and DATE
provided in the textboxes
above.
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form.
Label: Displays the current
time.
SUBTOTAL
Label: The label will display the total cost of
the order of all the items added into the
basket (datagrid to the left).
Edit Order
DataGrid: Displays all the
material items and their
prices from the database.
The columns will display
Material, Depth, Unit
Sheet Size, Unit Cost and
any other additional info.
It will not be locked and
will allow ADD, DELETE,
UPDATE any material
information on the form.
This information will be
linked directly to the
database and should
display updated
information on-the-go.
The background colour of
the datagrid should relate
to the colour scheme of
the form.
NO. OF ITEMS
PRINT
ADD
CLEAR
CommandButtons: Will
allow the student to add a
material to the basket.
Will display the print
order form. From here the
order can be printed to
hand to the technician to
make the batch order.
PictureBox: Contains the
comboboxes used to
ensure the order is valid.
Will group the inputs and
also be used for an effect.
SEARCH
Page 27 of 303
PASSWORD REMINDER FORM
The design of the input form frmPasswordRem.
The only input on this form will be the textbox requiring the student username to remind of the
password. The user will not have to log on to use this form. The form may be accessed through the
login form by clicking on the “?” command button. To validate the data entry on the form, the
username will be searched for before displaying the password (possibly through an email).
ToolTipText feature will again be used here to tell the student to input the school username. The
description on the form should provide details on how the password can be retrieved.
The background of the form will remain consistent and be similar to all the other forms on the
program, using pastel-like shades and colours. The size of the form will be similar to the size of form
frmMainMenu, smaller than the forms that store the material order data. The forms start-up
position will be centre screen.
The input and data capture forms have been designed using the technician sketches and ideas,
which can be seen on the next page. The ideas of separate logins and datagrid-like displays on the
forms have influenced the actual designs a great deal.
Time
Label: Displays the title
of the page.
CommandButtons: The
button should display the
appropriate forms if the
images are not clicked to
the display the respective
forms.
Mouseover effects will be in
place here to give the
impression they can also be
clicked and which choice
the user will be making.
Label: Displays the current
time.
PictureBox: Contains
the web browser
control which allows
GIF images to be
displayed and
animate.
WebBrowserControl:
In the navigation
property will display
the GIF files.
Password
<-
ImageBox: Displays an
image, that when
clicked, takes the user
back to the previous
form.
Label: Description of the
process. Instructions.
USERNAME School Username:
Page 28 of 303
Page 29 of 303
File and/or Data Structures, Methods of Access
The new ordering system will consist of an easy to use interface which will utilise a database to store
all the input details from the data capture forms. The computers at the school will need to have at
the very least Microsoft Office 2003 edition installed. This is because the database file will be made
using Microsoft Access. Although there should be no need to open the database because the new
system should provide the interface to do so, any additional upgrades made in the future may
require opening the file directly. At least the technician’s computer will need to have Visual Basic
6.0 installed for debugging or maintenance purposes. Fortunately the all the computers at the school
have these software requirements installed.
The new computerised system will utilise a database with the file extension “.mdb”. This is because Visual Basic 6.0 collaborates well with the older version of Access. The location of the database will be in the local “M:/” drive (on the server) so that the program will have no problems accessing the database wherever will be used on the school network. The solution will not be using any arrays but will use RecordSets for linking and accessing the tables
in the database. The tables whether they require filtering on display or not, will be declared through
SQL statements. The system will consist of four tables.
Data Structure and Method of Access to STUDENT DETAILS:
The student details will be stored and can be accessed from the database file
‘resistantmaterialsdb.mdb’. This is a flat file with all the data that will need to be stored from the
computerised system. The file will hold all of the student details on the table ‘tblStudentDetails’.
The database will allow for many students details to be added as the program continues to be used
each term. The student details can be accessed by the random access method. This will allow the
adding and retrieving of records in the table. The information should also be accessible through the
computerised system.
The system will require the students to include the following details when registering to use the
system; school username, school password, full name and technology class amongst other details.
The data will be structured in the following way:
FIELD NAME DESCRIPTION DATA TYPE LENGTH EXAMPLE DATA
StudentID Each student needs a unique identifier. It will be a number.
AutoNumber Long Integer
34
Alias Type of registered account. Text 7 STUDENT
Username The school username of the student.
Text 20 04lawsonb
Password The school password of the student.
Text 20 Langley5%
Forename The forename of the student. Text 20 Ben
Surname The surname of the student, Text 20 Lawson
StudentYear The yeargroup of the student. Number 2 13
StudentGroup The class initials of the student. Text 3 BGP
Page 30 of 303
Primary Key: StudentID Data Structure and Method of Access to STAFF DETAILS:
The staff details will be stored and can be accessed from the database file
‘resistantmaterialsdb.mdb’. The data will be held in the table ‘tblStaffDetails’. The database will
allow for many numbers of staff records details to be added as the program continues to be used
each term. The staff details can be accessed by the random access method. This will allow the
adding and retrieving of records in the table. The information should also be accessible through the
computerised system.
The system will require the staff to include the following details when registering to use the system;
school username, password details.
The data will be structured in the following way:
FIELD NAME DESCRIPTION DATA TYPE LENGTH EXAMPLE DATA
StaffID Each student needs a unique identifier. It will be a number.
AutoNumber Long Integer
9
Alias Type of registered account. Text 15 STAFF
Username The username of the member of staff.
Text 20 phw
Password The password of the member of staff.
Text 20 Slough23%
Primary Key: StaffID
Data Structure and Method of Access to MATERIALS DETAILS:
The staff details will be stored and can be accessed from the database file
‘resistantmaterialsdb.mdb’. The data will be held in the table ‘tblMaterialsList’. The database will
allow for as many materials that need to be added. The details will be accessed by the frmViewList
form in the program and will be displayed via datagrid. The details will be accessed by the random
access method. This will allow the adding, updating, deleting and retrieving of records in the table.
The information should also be accessible through the computerised system.
The data will be structured in the following way:
FIELD NAME DESCRIPTION DATA TYPE LENGTH EXAMPLE DATA
MaterialID Each material needs a unique identifier. It will be a number.
AutoNumber Long Integer
16
Material The name of the material. Text Variable Plywood
Depth The depths of material available. Text 8 12.00mm
Unit Size (mm)
The size of the sheets of material available.
Text 10 1020x600
Page 31 of 303
Unit Cost The cost of the sheet of material. Currency 5 £4.80
Additional Info
Additional information on the material .
Text Variable Price per metre.
Primary Key: MaterialID Data Structure and Method of Access to STUDENT ORDER:
The staff details will be stored and can be accessed from the database file
‘resistantmaterialsdb.mdb’. The data will be held in the table ‘tblStudentOrder’. The database will
allow for as many orders that need to be added over the course of its use. The details will be
accessed by the frmNewOrder and frmPrintOrder form in the program and will be displayed via a
DataGrid. The details will be accessed by the random access method. This will allow the adding,
updating, deleting and retrieving of records in the table. The information should also be accessible
through the computerised system.
The data will be structured in the following way:
FIELD NAME DESCRIPTION DATA TYPE LENGTH EXAMPLE DATA
OrderID Each order needs a unique identifier. It will be a number.
AutoNumber Long Integer
16
Material The name of the material selected.
Text Variable MDF
Depth The depth of the material selected.
Text 8 3.00mm
Size The size of the material selected. Text 10 1010x540
Quantity The quantity of the material chosen,
Number 2 3
Cost The cost of the size of material chosen considering quantity as well.
Currency 5 £7.29
StudentID The unique student identifier. Number Long Integer
34
OrderDate The date the order was made. Date/Time 10 12/02/2011
Primary Key: MaterialID
Foreign Key: StudentID
The student order table will use the primary key from tblStudentDetails as a foreign key. The fields will also be related with a one-to-many relationship. This relationship will occur when a student orders more than one material per whole order.
Foreign Key.
Page 32 of 303
Validation
The details of the students, staff and student orders will be entered through the computerised
system. Thus validation for the data entered must be considered. Any invalid data entered may
cause the system to crash. Making the system robust is necessary to avoid any potential crashes.
This will be done by verifying the data meets certain criterion that avoids the saving of invalid data.
These checks will be prompted in command buttons or in real-time data entry.
The following measures will be in place for validating STUDENT DETAILS on frmRegister:
FIELD NAME VALIDATION DESCRIPTION
StudentID None
This field will not be accessible to the user through the form so there’s no need to validate. The number will be automatically assigned.
Alias To validate this, a ‘DropDownList’ style combo box will be used.
PRESENCE CHECK.
The student will not be allowed to enter in an option so save. The dropdown box will require input before other inputs are enabled. Validation will take place when prompted before storing via command box.
Username Input via textbox. Length restriction placed on textbox.
PRESENCE CHECK.
LENGTH CHECK.
A length restriction of 20 characters is more than enough for any name of any student that has a school account. It will also restrict deliberate attempts to test the system to its limits by the students, to some extent.
Password Input via textbox also. Length restriction also placed here.
PRESENCE CHECK.
LENGTH CHECK.
Like the username textbox, a presence check will be present to validate the input initially. Then a length check will take place that will avoid the storing of invalid data. This length check may also be placed in a way so that the input is being validated in real-time.
Forename Limitation in the form of input restriction.
PRESENCE CHECK.
FORMAT CHECK.
LENGTH CHECK.
Valid data in this field would not contain integers. Thus the textbox input is restricted to characters only. Any attempt to enter an integer into the textbox will result in nothing being input. There will also be a presence check before storing the data.
Surname Limitation in the form of input restriction.
PRESENCE CHECK.
FORMAT CHECK.
LENGTH CHECK.
Very similar in terms of validation to the forename textbox. A presence check will be present when the command button is clicked. Also there will a length check to avoid invalid password (length more than 20 characters.) This also enforces students to produce a password not to difficult to remember.
Student Year To validate this, a ‘DropDownList’ The validation will ensure that a valid input
Page 33 of 303
style combo box will be used.
PRESENCE CHECK.
is stored in the database. A presence check when the command button is clicked will take place.
Student Group
Limitation in the form of input restriction.
PRESENCE CHECK.
FORMAT CHECK.
LENGTH CHECK.
Validation here will use KeyAscii to ensure the correct data has been input. The textbox will require no more than two upper case letters. A textbox will be validated for data presence also.
The following measures will be in place for validating STUDENT/STAFF LOGIN DETAILS on
frmStudentLogin/frmStaffLogin:
FIELD NAME VALIDATION DESCRIPTION
Username Input via textbox. Length restriction placed on textbox.
PRESENCE CHECK.
Additional Check (existence)
The username when attempting to login must be present to allow access to the programs features. An additional check will be made to ensure the data is valid by searching the database to confirm the username is registered; this will allow the user to access the features of the system.
Password Input via textbox also. Length restriction also placed here.
PRESENCE CHECK.
Additional Check (existence)
Much like the username textbox validation, a presence check will be one of the checks here. The additional check will be to ensure (if the username is registered) the password matches the one for the registered username. If not, the user will not be able to gain access to the system.
The following measures will be in place for validating ORDER DETAILS on frmNewOrder:
FIELD NAME VALIDATION DESCRIPTION
OrderID None
This field will not be accessible to the user through the form so there’s no need to validate. The number will be automatically assigned.
Material To validate this, a ‘DropDownList’ style combo box will be used.
PRESENCE CHECK.
The drop down style combo box will ensure that only the options given to the student by the comb box will be valid input. The student will not be able to name the material. A presence check will be made before saving the order or enabling the rest of the material options.
Depth To validate this, a ‘DropDownList’ style combo box will be used.
The options from the combo box will change depending on the material selected. This will ensure the depth chosen by the user will
Page 34 of 303
PRESENCE CHECK.
always be valid as the cost calculations will use this data to retrieve the cost from the database.
Size Input via textbox.
PRESENCE CHECK.
RANGE CHECK.
A presence check will be carried out when the adding of the item to the basket takes place. The range check will be an important feature here as it will be important the student cannot order a material piece bigger than the sheets available.
Quantity Input via textbox.
PRESENCE CHECK.
RANGE CHECK.
The textbox will have a range limit of 1-50. This will mean an order of zero quantity cannot be made. A presence check will be made here too as this is required for the calculation of the cost.
Cost Indirect validation.
The cost will be validated by ensuring the cost is rounded to two decimal places. The validation of the other fields will ensure the cost is valid.
StudentID None
This field will not be accessible to the user through the form so there’s no need to validate. The number will be automatically assigned. The number will be the foreign key, adding the unique ID of the student here.
OrderDate None
This field will not be accessible to the user through the form so there’s no need to validate.
All the details that will be input into the system have been validated. This, to an extent, should ensure
that the probability of invalid data being stored by the system or provoking the system to crash should
stay close to zero. The importance of the data being valid is crucial for the system to function correctly
as different parts of the system rely on previously entered data. This will also make for a robust
solution, which works towards one of its objectives, as well as ensuring the user interface meets its
standard requirements.
Page 35 of 303
Processing Stages
To use the system, the user must have registered by entering all the details. This will be the first
step the user encounters when using the system. Both students and members of staff will need
to register to use the system.
NEW USER REGISTRATION PROCESS:
START
Are all registration
details completed?
FINISH
YES
NO
Is the user a
student? NO
Message box
Student details are added
to the database file, table
tblStudentDetails.
YES
User enters all the
details required for
registration process.
Student Details
Database File
(tblStudentDetails)
Staff Details
Staff details are added to
the database file, table
tblStaffDetails.
Database File
(tblStaffDetails)
An orange-outlined process
indicates the processes will
access the database file.
For this processing stage
the file will be accessed to
store details of the user.
Page 36 of 303
USER LOGIN PROCESS:
START
Have all the login
details been
completed?
FINISH
YES
NO
Is the user a
student? NO
Message box
Student login details are
compared with the all
student registered details.
YES
User enters the login
details.
Student Login
Details
Staff Login
Details
Database File
(tblStudentDetails)
Do the student
login details
match?
YES
NO
Display student welcome
form.
Message box
Staff login details are
compared with the all
student registered details.
Database File
(tblStaffDetails)
An orange-outlined process
indicates the processes will
access the database file.
For this processing stage
the file will be accessed to
compare details of the
user.
Do the student
login details
match?
YES
Display staff welcome form.
NO
Page 37 of 303
PASSWORD REMINDER PROCESS:
START
Has the username
been input?
FINISH
YES
NO
Is the user a
student? NO
Message box
YES
User enters their
username.
Database File
(tblStudentDetails)
Database File
(tblStaffDetails)
An orange-outlined process
indicates the processes will
access the database file.
For this processing stage
the file will be accessed to
extract password details to
display on the form.
Student
password is
extracted.
Student password is
displayed on the form.
Staff username is searched
from tblStaffDetails.
Student username is
searched from
frmStudentDetails.
Staff password
is extracted.
Staff password is emailed to
the member of staff account.
Page 38 of 303
NEW ORDER PROCESS:
START
Have all the
material details
been completed?
FINISH
YES
NO
Message box
Order details for the user are
extracted and displayed in
the data grid on the form.
Clears all inputs for a new
order.
User input all the
material details.
Material Order
Details
Display printing order form.
Material order details are
added to the database in the
table tblStudentOrder.
An orange-outlined process
indicates the processes will
access the database file.
For this processing stage
the file will be accessed to
store and display material
order details.
YES
NO
Database File
(tblStudentOrder)
Has the print
command button
been pressed?
Page 39 of 303
CALCULATING INDIVIDUAL MATERIAL ITEM COST PROCESS:
START
Are all the details
completed and
valid?
YES
NO
Message box
Retrieve data from searches
and perform calculation.
Round number to two
decimal places. Display in the
appropriate label.
Material details.
Material Order
Details
Search the corresponding
unit cost of the material.
Search for the corresponding
unit size of the material.
An orange-outlined process
indicates the processes will
access the database file.
For this processing stage
the file will be accessed to
retrieve material data that
will be used for the
calculations.
Database File
(tblMaterialDetails)
Material order details are
added to the database in the
table tblStudentOrder.
Database File
(tblStudentOrder)
Page 40 of 303
FIND ORDER PROCESS:
From this, the form can be edited. The processing stages for the editing of the orders will be very
similar to the adding material orders processing stage. The form can also be printed. The processing
stages for the printing of the form can be seen below.
Recordsets are created to act as the medium between the database and the program. A recordset is essentially a copy of the database data, which the program can manipulate. The changes to the recordset data overwrite the data in the database afterwards.
db
Not a data type.
New ADODB Connection
Connect the program (.exe) to the database. Allows the loading of database data onto the form and its along this connection the data is saved.
sConn
String String for the object location of the connection (database).
sPath
String String for the database address.
SQL
String
String for the SQL statements that determine where the data is saved to or retrieved from in the database.
SearchUsername
String String for the variable username.
SearchPassword
String String for the variable password.
SearchMaterial
String String for the variable material name.
SearchDepth
String String for the variable material depth.
SearchStudentForename
String String for the variable student forename.
SearchStudentSurname
String String for the variable student surname.
SearchOrder
String String for the variable student order.
SearchOrderDate
String String for the variable student order date.
SearchGroup
String String for the variable student class group.
SearchYear
Integer Integer variable for the student year at school.
rowNum Integer Integer variable for the number
Page 238 of 303
of rows in the datagrid used for calculating the costs on each of the forms.
sTotal
Long Integer
Long integer variable for the total cost of the order. Long integer as the cost will include calculation accuracy to the standard two decimal places.
strHeight
Integer
Integer variable for the height of the material selected during the order.
strWidth
Integer
Integer variable for the width of the material selected during the order.
strUnitSize
Integer Integer variable for the area of the material selected.
strUnitDepth
String String for the variable unit depth size.
strCost
Long Integer
Long integer variable for the cost of each item that is placed in the order. Long Integer again required here for standard currency accuracy.
Page 239 of 303
CG4.5 TESTING
Testing Strategy
The testing strategy will be to test the new system thoroughly. The system will be tested by me,
current students studying the subject, and the department technician.
The testing performed by myself will include the following:
The testing of any input forms in the system. This will include the thorough testing of any
inputs on these forms. The inputs on these forms will be subject to typical, extreme and
erroneous data to witness the systems response. Should the system not respond correctly,
maintenance will be performed to correct or adapt any of the features that may need
attention. This should test the system is robust enough to be suitable for implementation.
The navigational paths will be tested by common scenarios to see if the system is logical or
not. This is important considering the system is also going to be used by students and
ensuring the interface is clear is important.
The functions of the command buttons or any links on the forms will be tested to ensure
that no errors appear when transporting the user from one form to another and to ensure
there are no broken links. Errors here would have a big impact on the use of the system and
some errors here may also render the system fairly useless.
The validation on each of the forms that prompt an input from the user will be tested. This is
also important as not doing so could leave the system crashing when it tries to process
unexpected data. The validation will be tested to ensure all presence, format and range
checks function correctly.
The calculations the system performs will be tested thoroughly to ensure the system is
producing the correct results. These results will affect the students and the department
directly and undervaluing the order would undermine the reason for the system. The
calculations will be tested by manually working out what the system should produce as a
result via a calculator and comparing with the actual result. The technician will also provide
some hand-validated orders to verify the accuracy of the new system.
The testing performed by the students who study the subject will include the following:
(Feedback will be received from this testing that will contribute to the evaluation against the criterion
established before the system was made.)
The testing of the inputs the students will come across on the system. This will include
inputting general data and also making attempts to cause an error which will result in the
system crashing. This will thoroughly test the robustness of the system.
The testing performed by the students will also include testing the validation in the system.
The testing performed by the department technician will include the following:
(Feedback will be received from this testing that will contribute to the evaluation against the criterion
established before the system was made.)
Page 240 of 303
The testing of the inputs members of staff may come across on the system. The technician
may also want to test the calculations which will only reinforce the thoroughness of the
system testing.
The technician will also test the outputs of the system such as the materials list and typical
printed orders and compare with the requirements that were set whilst the system was
being designed.
Page 241 of 303
Test Plan / Data
The test plan is to devise appropriate data that will test all the inputs on each of the forms that
require manual input in the system. This test data will then be input into the system to see how it
responds. Unexpected responses form the system will highlight areas that need maintenance or
measures to prevent the crashing of the system. Testing then looks at all the command buttons and
links on the system to verify they work as expected. The testing will then be handed over to the
students and the technician. Although this will not be documented, the feedback will be recorded as
it will form an integral part of the evaluation of the system.
The test data will need to include typical, extreme, erroneous and null data to fully test the system.
The department technician, who has overseen the development of the system from its design stage,
will provide three examples of previous orders as a preliminary measure of how the system
performs. This test will be performed at the end of the testing on my behalf.
The expected result here includes the system responding
appropriately by retrieving the correct order details and
displaying them on the data grid. There should be no error
messages or validation errors.
EXPECTED RESULTS
Erroneous data here will cause the system to identify that
no student under that name has been registered and
should inform the user. This is the expected result.
EXPECTED RESULTS
The extreme date will test the system to ensure that it does
not display orders when there were not any placed on that
specific date. The expected result is the system displaying a
message box notifying the user of no order being placed.
EXPECTED RESULTS
Expected result is the correct user password to be on
display for three seconds. No error message or prompts.
EXPECTED RESULTS
Expected result includes nothing displayed on the form.
This will indicate that one of the inputs is invalid.
Page 247 of 303
Student: Shane Mann
Form: 13R
Date of Order: -
Validated: By the technician
Expected total: £9.71
Page 248 of 303
To test the navigational paths, four potential scenarios will be defined and the navigational paths
will be tested. The potential scenarios follow.
SCENARIO 1:
A student wants to make a new order but is using the system for the first time.
SCENARIO 2:
A student wishes to edit a previous order and print it off.
SCENARIO 3:
Member of staff wishes to check the material prices and edit some prices.
SCENARIO 4:
A student has forgotten their password and would like to be reminded by the system.
Page 249 of 303
Actual Test Results
The testing of the system will thoroughly test each form individually. Thus the test for each form has
been assigned a number:
1.) Main Menu form testing.
2.) Registration form testing.
3.) Student Login form testing.
4.) Staff Login form testing.
5.) New Order form testing.
6.) Edit Order form testing.
7.) Print Order form testing.
8.) View List form testing.
9.) Edit List form testing.
10.) Find Student Order form testing.
11.) Password Reminder form testing.
12.) Student Options form testing.
13.) Staff Options form testing.
14.) About form testing.
1.) MAIN MENU FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Student Login button (chkStudentLogin)
Direct the user from the main menu to the student login form.
The button does direct the user to the student login form.
Button functions as desired.
Staff Login button (chkStaffLogin)
Direct the user from the main menu to the staff login form.
The button does direct the user to the staff login form.
Button functions as desired.
Ordering App Logo (imgAbout)
Change the background of the main menu and display the About form.
The button does display the About form with the correct background.
Image link functions as desired.
Exit Button (Top right corner of form)
Unload the application and quit the program.
The button does direct the user to the update quote form.
Button functions as desired.
There are no inputs aside form the buttons so there is no further testing on this form. The
buttons function correctly and display the appropriate forms so there is no need to further
refine this form.
Page 250 of 303
2.) REGISTRATION FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the registration form to the student welcome form.
The image link does direct the user to the student welcome form.
Image link functions as desired.
Alias List Box (cmbAlias)
Display the appropriate input boxes when an alias option is chosen.
The list box does display the correct input boxes depending on the option chosen.
List box function as desired.
Create Account (cmdCreate)
Stores the details input into the system providing they are valid and prompt a message.
The button does validate the data and then store the details input by the ser into the database. The message follows.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
It was expected that there was to be no error messages and the system should accept the data that
was entered and store it in the database. The system responded as expected and stored the details
input into the database. An error message then appeared informing the user of the successful
creation of their account and the student login form was automatically displayed. The testing of this
form with the typical data set went as expected and thus no more extra work was needed.
Page 251 of 303
Evidence of successful storage in database:
EXTREME DATA entered into the system:
Again it was expected that there would be no error message and the test was created to ensure that
even extreme data could be handled well by the system. The test has been successful as the system
handled the data perfectly and has been validated and stored into the database. The testing of this
form with the extreme data set went as expected and thus no more extra work was needed.
Evidence of successful storage in database:
Page 252 of 303
ERRONEOUS DATA entered into the system:
Here it was expected that the username would cause the system to notify the user that the
username they had input was already chosen. This was exactly what happened when the system was
being tested. The system did not allow the storage of the details provided here as the data was
considered invalid. This test was also successful so no extra work on this form was needed.
All tests on the registration form also included new member of staff accounts. These also gave
accurate results and the reason they were not documented was because they included validation
that was not as comprehensive as for the student accounts. The tests that were not documented
were also successful and thus there was no extra work to refine this form was needed. The test data
for the tests that were not documented can be seen in the section above.
Page 253 of 303
Evidence of successful non-documented tests (new member of staff accounts):
3.) STUDENT LOGIN FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the student login form to the main menu form.
The image link does direct the user to the main menu form.
Image link functions as desired.
Forgot Password Button (cmdForgot)
Display the password reminder form.
The button does direct the user to the password reminder form.
Button functions as desired.
Login Button (cmdLogin)
Validates the login details and either grants or rejects the student access.
The button does validate the data and perform the appropriate action.
Button functions as desired.
Create New Account Link (lblCreateAcccount)
Directs the user to the registration form.
The link does direct the user to the registration form.
Link functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
Page 254 of 303
It was expected that there was to be no errors and that the system should allow the user access and
display the student welcome form with the student details on display. The system responded as
expected and displayed the welcome form with the student details displayed. The testing of this
form with the typical data set went as expected and thus no more extra work was needed.
EXTREME DATA entered into the system:
Again it was expected that there would be no errors and the system should have been able to cope
with the extreme data. This was the case as the test was successful and it did log in the user and
displayed the user’s details on the form. There was a slight problem with the display space of the
name and despite it being extreme data; the space was tweaked to allow extremely long names to
Page 255 of 303
be displayed properly. The test has been successful as the system handled the data perfectly. The
testing of this form with the extreme data set went reasonably well and after the minor tweak of the
display name space, there was no extra work required on the form.
ERRONEOUS DATA entered into the system:
It was expected here that the system would indentify that there was no student registered on the
system under the invalid name and the system would inform the user of the case. This would
prompt the user either to register or retry logging in. This was what happened when the system was
tested and this meant the test was successful. Because the test was successful there was no extra
work required on this form.
All the tests run on this form were documented and the results meant that the form was behaving as
expected and did not require maintenance.
4.) STAFF LOGIN FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the staff login form to the main menu form.
The image link does direct the user to the main menu form.
Image link functions as desired.
Forgot Password Button (cmdForgot)
Display the password reminder form.
The button does direct the user to the password reminder form.
Button functions as desired.
Login Button (cmdLogin)
Validates the login details and either grants or rejects the member of staff access.
The button does validate the data and perform the appropriate action.
Button functions as desired.
Create New Account Directs the user to the The link does direct the Link functions as
Page 256 of 303
Link (lblCreateAcccount)
registration form. user to the registration form.
desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
It was expected that there was to be no errors and that the system should allow the user access and
display the staff welcome form with the staff username on display. The system responded as
expected and displayed the welcome form with the details. The testing of this form with the typical
data set went as expected and thus no more extra work was needed.
EXTREME DATA entered into the system:
Page 257 of 303
Again it was expected that there would be no errors and the system should have been able to cope
with the extreme data. This was the case as the test was successful and it did log in the user and
displayed the user’s details on the form. The test has been successful as the system handled the data
perfectly. The testing of this form with the extreme data set went reasonably well and requires no
extra work.
ERRONEOUS DATA entered into the system:
It was expected here that the system would indentify that there wasn’t a member of staff registered
on the system under the invalid name and the system would inform the user of the case. This would
prompt the user either to register or retry logging in. This was what happened when the system was
tested and this meant the test was successful. Because the test was successful there was no extra
work required on this form.
All the tests run on this form were documented and the results meant that the form was behaving as
expected and did not require maintenance.
5.) NEW ORDER FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the new order form to the student welcome form.
The image link does direct the user to the student welcome form.
Image link functions as desired.
Clear Button (cmdClear)
Clear all the material details input boxes.
The button does clear all the input boxes.
Button functions as desired.
Add to Basket (cmdAdd)
Validates the item order and adds the item to the basket and database.
The button does validate the data and perform the appropriate action.
Button functions as desired.
Print Order Button (cmdPrint)
Directs the user to the print order form.
The button directs user to print order form.
Button functions as desired.
Page 258 of 303
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
Evidence of successful storage in database:
The test data to the left shows the expected cost at which
these typical item orders were expected to cost. As seen in
the screenshot above, the system was able to match the
expected cost down to the exact penny. The system
accepted the values that were input and also validated
these whilst they were being entered.
The system also responded well to the other typical set of
data. This was the result that was expected which deems
the test successful. So far, no extra work is required on this
form as it is functioning as desired.
Page 259 of 303
EXTREME DATA entered into the system:
Evidence of successful storage in database:
The test data to the left shows the expected cost of the
extreme data. Again, the system has produced very
accurate results and was able to correctly validate and
calculate the result. This test data was designed to properly
test the validation the form and how well the system
handles extreme data when it has to process the input.
The system handled it well which deems the test successful.
Thus no further refinement on this form is needed so far.
Page 260 of 303
ERRONEOUS DATA entered into the system:
All the tests run on this form were documented and the results meant that the form was behaving as
expected and did not require further maintenance.
6.) EDIT ORDER FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the edit order form to the student welcome form.
The image link does direct the user to the student welcome form.
Image link functions as desired.
Clear Button (cmdClear)
Clear all the material details input boxes.
The button does clear all the input boxes.
Button functions as desired.
The test data to the left shows the erroneous data that
was included to test the validation of the form. The test
should have resulted in the data not being stored into the
system and the validation should have prompted
messages to notify the user of a mistake in the details they
had entered. The error messages produced by the system
can be viewed above.
The test was a success as it did not allow the invalid data
to be stored and the error messages were displayed at
appropriate times. No extra maintenance is therefore
needed on this form.
Page 261 of 303
Add to Basket (cmdAdd)
Validates the item order and adds the item to the basket and database.
The button does validate the data and perform the appropriate action.
Button functions as desired.
Print Order Button (cmdPrint)
Directs the user to the print order form.
The button directs user to print order form.
Button functions as desired.
Search Order Date (cmdSearch)
Searches the database for orders placed by the student on that date and populates the data grid.
The button behaves as expected.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
The test data was created to check that the edit form will
still accept typical data. The expected cost was £6.00 and
the system calculated it to be correct. This test was
successful and with the expected result as it is, no further
work is needed on this form so far.
Page 262 of 303
Evidence of successful storage in database:
EXTREME DATA entered into the system:
The test data to the left shows the expected cost of the
extreme data. Again, the system has produced very accurate
results and was able to correctly validate and calculate the
result. This test data was designed to properly test the
validation the form and how well the system handles extreme
data when it has to process the input.
The system handled it well which deems the test successful.
Thus no further refinement on this form is needed so far.
Page 263 of 303
Evidence of successful storage in database:
ERRONEOUS DATA entered into the system:
The test data to the left shows the erroneous data that
was included to test the validation of the form. The test
should have resulted in the data not being stored into the
system and the validation should have prompted
messages to notify the user of a mistake in the details they
had entered. The error messages produced by the system
can be viewed above.
The test was a success as it did not allow the invalid data
to be stored and the error messages were displayed at
appropriate times. No extra maintenance is therefore
needed on this form.
Page 264 of 303
Another part of editing the order includes deleting an order item. This was tested by highlighting the
item and pressing the delete key as instructed to on the system. The result was the deletion of the
item and an update on the price, which was now appropriately lower. This was what was expected.
A screenshot and evidence of the deletion can be seen below.
All the tests performed on this form were documented and the results meant that the form was
behaving as expected and did not require further maintenance.
7.) PRINT ORDER FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the print order form to the student welcome form.
The image link does direct the user to the student welcome form.
Image link functions as desired.
Page 265 of 303
Print Order Button (cmdPrint)
Prints off the form on a4 paper.
The button prints the form onto the default printer.
Button functions as desired.
Search Order Date (cmdSearch)
Searches the database for orders placed by the student on that date and populates the data grid.
The button behaves as expected.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
The typical data was any previous date that an order has
been placed on. When the search button as clicked, it
displayed the order that was placed on that date. There
were no errors deeming the test successful and as
expected.
No further maintenance has been performed so far.
Page 266 of 303
EXTREME DATA entered into the system:
ERRONEOUS DATA entered into the system:
The extreme data was the latest date an order was made. This
will test that the connection between the database are correct
and the system is robust. If the system was to crash it would
mean the database connection was still exclusive to a loaded
form. The test was performed and the result was as expected.
The test was successful and the order was displayed.
Page 267 of 303
All the tests performed on this form were documented and the results meant that the form was
behaving as expected and did not require further maintenance.
Evidence of the system producing a quality printed invoice of the users order can be seen on the
next page.
The test data to the left shows the erroneous data that was
included to test the validation of the form. The test should have
resulted in the system notifying the user that no order had been
placed on this date. The system notification (message box) can be
viewed in the screenshot above. This should also disable the print
order button. This can also be seen in the screenshot above.
The test was a success as it did not allow the user to print the
order as it was not found. The user was also notified through a
message box as expected. No extra maintenance is therefore
needed on this form.
Page 268 of 303
Evidence of successful test:
Page 269 of 303
8.) VIEW MATERIALS LIST FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the view materials list form to the student welcome form.
The image link does direct the user to the student welcome form.
Image link functions as desired.
Datagrid (dgList) Allow the user to scroll/move up and down the list to view its contents.
Data grid buttons allow the user to move up and down the list when clicked.
Datagrid Buttons function as desired.
There are no inputs aside form the buttons so there is no further testing on this form. The
buttons function correctly and display the appropriate forms so there is no need to further
refine this form.
9.) EDIT MATERIALS LIST FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the edit materials list form to the staff welcome form.
The image link does direct the user to the staff welcome form.
Image link functions as desired.
Add Item Button (cmdAdd)
Validates the data entered and stores the new material.
The button validates and stores the data in the database. It then appears in the data grid.
Button functions as desired.
Clear input Button (cmdClear)
Clears all the material information inputs.
The button clears all form inputs.
Button functions as desired.
Help Button (cmdHelp)
Display a message explaining the adding and deleting material process on the form.
The button displays a message box when the button s clicked.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
Page 270 of 303
EXTREME DATA entered into the system:
The typical data was designed to witness the system
accepting normal data that it may encounter in future use.
The expectation was the system should accept the data and
store it in the database. The system performed as expected
and the typical data test was successful.
No further maintenance has been performed so far.
Page 271 of 303
Evidence of successful typical and extreme tests on this form:
The extreme data was normal material information but the
dimensions were extreme. This was to test that the validation
on the form allowed these kind of sizes should a material of
that size be stocked in the future. The expected result was that
the system should accept the data and store it in the database.
The actual result of the test was the storage of the new
material item in the database so the test was a success.
Page 272 of 303
ERRONEOUS DATA entered into the system:
The system was expected to deal with the erroneous data in real-time. This meant that anything
entered into the material name field that was an integer, was not allowed and the input was cancelled.
This system performed as expected as the integer 0 from the erroneous test data was not allowed to
be input. The real-time validation for the material name was successful and this meant no further
refining on this form so far.
Page 273 of 303
All the tests performed on this form were documented and the results meant that the form was
behaving as expected and did not require further maintenance.
The validation was also applied to all the forms ensuring rogue
vales could not be entered into the respective fields. The
validation on all of the fields was valid as an be seen in the
screenshot above. A presence check also ensured that invalid data
in not added to the database. This was the performance expected
from the system and it was delivered. This means the erroneous
test for this form was also successful.
No further work on this form was needed as it could
comprehensively tackle any data it may encounter and only store
valid data.
Page 274 of 303
10.) FIND STUDENT ORDER FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the find student order form to the staff welcome form.
The image link does direct the user to the staff welcome form.
Image link functions as desired.
Clear input Button (cmdClear)
Clears all the student information inputs.
The button clears all form inputs.
Button functions as desired.
Search Button (cmdSearch)
Display a students order in the data grid if there is student order data found.
The button displays the correct information in the data grid.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
Page 275 of 303
EXTREME DATA entered into the system:
The typical data was designed to witness the system
accepting normal data that it may encounter in future use.
The expectation was the system should accept the data and
display the appropriate order in the data grid. The system
performed as expected and the typical data test was
successful. Evidence of which in the screenshot above.
No further maintenance has been performed so far.
The extreme data was expected to produce a notification from
the system to inform the user that the student had not placed
an order on that day. The test was successful in that the
message was produced, along the student name. The evidence
of the data inputted and the notification to the user can be
seen in the screenshots above.
No corrective maintenance was performed on this form.
Page 276 of 303
ERRONEOUS DATA entered into the system:
All the tests performed on this form were documented and the results meant that the form was
behaving as expected and did not require further maintenance.
The erroneous data was designed to test the system so that it
could differentiate from an invalid date, or an invalid name that
was inputted. This test should have produced a message box
notifying the user that no such student had been registered on
this form. The test can be considered a success because the
system performed as expected. The message box was displayed
with the forename included in it to make clearer what the roor
was.
No further work on this form was needed as it could
comprehensively figure which of the details provided was invalid.
Page 277 of 303
11.) PASSWORD REMINDER FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Return Image (imgReturn)
Direct the user from the password reminder form to the staff welcome form.
The image link does direct the user to the staff welcome form.
Image link functions as desired.
Remind Me Button (cmdRemind)
Validates the details entered and displays the password for three seconds.
The button validates the details and displays the password for three seconds.
Button functions as desired.
The objects on the form function as desired and now the actual validation and the programs
behaviour when subject to different types of data will be tested and recorded.
TYPICAL DATA entered into the system:
The typical data in this set was designed to display the
password for the username “04rafiqw”. The password for
this account was “slough123%”. Evident from the
screenshot above. This meant the test was a success.
No further maintenance has been performed so far.
Page 278 of 303
ERRONEOUS DATA entered into the system:
All the tests performed on this form were documented and the results meant that the form was
behaving as expected and did not require further maintenance.
12.) STUDENT OPTIONS FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Logout Image (imgLogOut)
Direct the user from the student welcome form to the main menu.
The image link does direct the user to the main menu form.
Image link functions as desired.
New Order Text (lblNewOrder)
Direct the user from the student welcome form to the new order form.
The label link does direct the user to the new order form.
Label link functions as desired.
The expected result was nothing displayed when the user entered
the details. The test was a success in that nothing was displayed.
This hints at the fact that the details the user provided must be
invalid. A message box could be helpful here but the result was
nevertheless, as expected.
Page 279 of 303
Edit Order Text (lblEditOrder)
Direct the user from the student welcome form to the edit order form.
The label link does direct the user to the edit order form.
Label link functions as desired.
Print Order Text (lblPrintOrder)
Direct the user from the student welcome form to the print order form.
The label link does direct the user to the print order form.
Label link functions as desired.
View List Text (lblViewList)
Direct the user from the student welcome form to the view materials list form.
The label link does direct the user to the view materials list form.
Label link functions as desired.
There are no inputs aside form the buttons so there is no further testing on this form. The
buttons function correctly and display the appropriate forms so there is no need to further
refine this form.
13.) STAFF OPTIONS FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
Find Order Text (lblFindOrder)
Direct the user from the staff welcome form to the find order form.
The label link does direct the user to the find order form.
Label link functions as desired.
View List Text (lblViewList)
Direct the user from the staff welcome form to the view materials list form.
The label link does direct the user to the view materials list form.
Label link functions as desired.
Edit List Text (lblEditList)
Direct the user from the staff welcome form to the edit materials list form.
The label link does direct the user to the edit materials list form.
Label link functions as desired.
There are no inputs aside form the buttons so there is no further testing on this form. The
buttons function correctly and display the appropriate forms so there is no need to further
refine this form.
14.) ABOUT FORM:
OBJECT WHAT SHOULD IT DO? WHAT IT ACTUALLY DOES?
ADDITIONAL COMMENTS.
OK button (cmdOK)
Direct the user from the about form to the main menu again.
Button link does direct the user to the main menu form.
Button functions as desired.
Page 280 of 303
vbEXIT (Exit button on form)
Direct the user from the about form to the main menu again.
The form button does direct the user to the main menu form.
Form buton functions as desired.
There are no inputs aside form the buttons so there is no further testing on this form. The
buttons function correctly and display the appropriate forms so there is no need to further
refine this form.
All the forms that require manual user input in the system have been thoroughly tested using
typical, extreme and erroneous data. The data used was all created and the department technician
felt testing the system against an order that he had validated would leave no part of the system
thoroughly tested. The department technician provided the order of which a picture was taken.
DEPARTMENT TECHNICIAN VALIDATED ORDERS (test data can be seen above):
Student: Madiha Nawaz
Form: 13MH
Date of Order: 23/11/2010
Validated: By the technician
Expected total: £7.85
The results the system produced were very accurate. The items where the result suffered some
inaccuracies in the costs was due to the fact that materials were been used that had been
discontinued for this years ordering options. Apart from these inaccuracies the system performed
very well.
Student: Shane Mann
Form: 13R
Date of Order: -
Validated: By the technician
Expected total: £9.71
The results the system produced were also very accurate. The slight inaccuracies in this order were
again due to the discontinued material so the substitute material resulted in a different item cost.
Taking into account the student was not charged for the aluminium rod, the total cost produced by
the system was accurate.
Both the tests from the department technicians were successes in that the system performed well
and gave a good indication as to how well it would perform in general. The technician was satisfied
with the level of accuracy and its reliability.
Page 281 of 303
Evidence of technician created tests that were successful:
Evidence of testing for the order of Shane Mann:
Page 282 of 303
Having tested the system fully, a results summary of the testing can be produced based on the
findings.
TEST NO. FORM TESTED OBJECTIVE OF TEST TEST RESULT
1
Main Menu form
Test the inputs on the form; these were the two command buttons on the form.
Test Successful
2
Registration form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
3
Student Login form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
4
Staff Login form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
5
New Order form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
6
Edit Order form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
7
Print Order form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
8 View List form Test the links and button on the form.
Test Successful
9
Edit List form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
10
Find Student Order form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
11
Password Reminder form
Test all the buttons and links to ensure they function properly. Test all the inputs for correct validation and function.
Test Successful
12
Student Options form
Test the inputs on the form; these were the labels that were linked to the other forms.
Test Successful
13
Staff Options form
Test the inputs on the form; these were the labels that were linked to the other forms.
Test Successful
Page 283 of 303
14 About form Test the one command button on the form.
Test Successful
TESTING OF THE SYSTEM INTERFACE:
For all the forms in the system, the layout was consistent which made navigating around the system
very easy and easy-to-understand. The interface contained details on the function of each form that
was slightly difficult to understand. Other details were included such as how to delete an item from
the order basket. The user interface looked very similar to the forms that were designed earlier on in
the project. Very little had changed transforming the designs into a fully functioning application.
The colour scheme of the system was consistent and similar backgrounds were used. The only
exception with the background was the print order form. The background her was deliberately
changed to keep the invoice printer friendly.
The interface also made it clear the links and buttons on the page by utilising moue-over effects.
Consistent mouse-over effects not only made the system user friendly but also lifted the quality of
the application overall.
Overall the system interface was more than satisfactory as it stayed true to the designs that were
created before the system was made and the consistency also made it easy to navigate around,
whilst keeping the system user friendly.
NAVIGATIONAL TESTING OF SYSTEM:
The navigational paths of the system will now be tested. This will include the necessary paths that
the user will need to take in order to successfully counter the four scenarios devised earlier in the
test data.
SCENARIO 1:
A student wants to make a new order but it using the system for the first time.
The student will need to click on the student LOGIN
button on the main menu.
Page 284 of 303
The student will then need to click the link at the
bottom of the page to be directed to the
registration form.
The student will need to fill in the details required
and click the CREATE ACCOUNT button.
The student will enter their login details and click
the LOGIN button to log onto the system.
Once logged in the student will need to click NEW
ORDER in red to be directed to the ordering form.
Page 285 of 303
Once on the form the student can enter the item
details on the form and keep adding to the basket
until content.
Once finished with the ordering, the student can
click on the RETURN image in the corner to return
to the student welcome form.
The student then clicks the LOG OUT button that
logs the student out and displays the main menu
form.
Page 286 of 303
SCENARIO 2:
A student wishes to edit a previous order and print it off.
The student will need to click on the student LOGIN
button on the main menu.
The student will enter their login details and click
the LOGIN button to log onto the system.
Once logged in the student will need to click EDIT
ORDER in red to be directed to the ordering form.
Page 287 of 303
Enter the date of the order and click SEARCH. The
edit the order as desired. ADD items to the basket
or DELETE them.
Once the order has been finalised, click the PRINT
ORDER button on the form.
Enter the date of the order and SEARCH it. The
simply click the PRINT ORDER button to print the
order.
Page 288 of 303
SCENARIO 3:
Member of staff wishes to check the material prices and edit some prices.
Click the VIEW LIST link in red.
User needs to enter staff login details and click
LOGIN.
User will need to click the staff LOGIN button.
Page 289 of 303
View the contents of the forma dn then click the
RETURN image to return to the staff welcome form.
Click the EDIT LIST link in red to be directed to the
edit list form.
Enter the item details to add a material item or
delete through the tabbed list. Once finished. click
the RETURN image to return to the staff welcome
form.
Page 290 of 303
SCENARIO 4:
A student has forgotten their password and would like to be reminded by the system.
Click the LOG OUT image to log the user off the
system and return to the main menu.
Click the student LOGIN button to be directed to
the student login form.
Click the “?” button to be directed to the password
reminder form. (May also need to answer a system
prompt.)
Click the YES option to display the password
reminder form.
Page 291 of 303
The test runs above were for the navigational paths. Four random but possible scenarios were
created that tested that the user could correctly navigate and complete the possible tasks. The
testing was successful because the user can correctly navigate around the forms and the system
allowed the user to do so.
Enter you detail and click the REMIND ME button to
display your password for three seconds. Then click
the RETURN image to return to the student login
form and continue logging on.
Page 292 of 303
CG4.6 EVALUATION
Evaluation of Test Results
There were seventeen different tests performed on the application during the testing of the solution. These sub-tests tested all the aspects of the solution thoroughly. All the forms in the system that required input were tested. All the tests that were undertaken on the system were successful bar one. This was not to do with the direct testing as such but the way the information on the page was being displayed. The display space on the form was not big enough to display the extreme data that was used in the testing. To correct this, the display size was adapted and is now capable of displaying any extreme data. Validation was thoroughly tested during the testing phase. The validation for the registration form was thoroughly tested to ensure that only valid data would be stored which in turn would only allow valid accounts to be created. The login validation was thoroughly tested to ensure that gaining access to the feature of the system was only possible after submitting valid login details. The validation on all the forms where the cost of material items was concerned were tested in particular to ensure that no rogue values could be entered into the inputs on the form, which could have potentially crashed the system or stored inaccurate calculations. The validation tests carried out on all the above were successful. The system did not accept any invalid data, nor did it crash at any point in the testing phase. The test data used for the testing of the system was appropriate as the results of the testing of the solution were conclusive. The test data entered, thoroughly tested the validation on the forms and the response from the system when it encountered this data, gave a clear indication of whether that particular part of the system was to a satisfactory standard. The system was tested using typical, extreme, erroneous and null data sets. These formed the basis of the comprehensive test plan. Navigational paths were tested and the test summary revealed that the system has succeeded in passing all the tests with the corrected name display. No aspect of the solution testing was avoided. The testing phase was efficient as it covered all the test data and followed the test plan as best as it could. The test results were accurate. The solution was tested using the test data that was created and these yielded very accurate results. To further test this accuracy, technician validated orders were replicated. The results to this test were also very promising and inaccuracies only occurred through slight differences in actual materials. After overseeing the results of the tests carried out on the system, the technician was satisfied that the old system could be replaced and the new system would succeed in its aim to make the department, and the ordering process, more efficient.
Page 293 of 303
Solution Satisfies the Objectives
The objectives were outlined at the start of this project. They were documented so the system can
be compared with these objectives to determine its success. The comparison to see if the solution
satisfies the objectives follows.
The main objective of the project will be to create a replacement system for the ordering process within the
Resistant Materials department. The system will benefit both the department and the students. A computerised
solution will be created using Visual Basic 6.
It was concluded that the solution was a more than adequate replacement system for the ordering
process at the department. This conclusion was reached by the department technician himself. The
solution is computerised and was created using Visual Basic 6 as the only programming language.
This will include a user interface capable of allowing the students to:
Register to use the system if it is the first time they are using it.
The students can use the system if it the first time they are using it. The students must
register before being able to access the full features of the system. The system interface
allows them to do this relatively easily.
Be reminded of their password.
The system interface has a dedicated form that deals with password requests from the
students. Accessing this form is also relatively easy.
Enter their login details to access the materials ordering form.
The system is very robust and will not allow users full access to the features of the system
unless valid login credentials are provided.
Choose materials and the sizes of the materials to enable the program to calculate the prices.
The student has complete control over the dimensions of the materials the student has
selected. This enables the program to calculate the prices every time.
Amend a previous order.
The system includes a dedicate form for students who wish to amend/edit a previous order.
The link to this form is available as soon as the student logs in.
Print the latest order by displaying the total order on a printable form.
The system also has a dedicated print order form where all the details of the final order are
displayed.
View the latest materials list for information on material availability and prices.
The system has an option that directs the student to the materials list. This option is
displayed when the student has logged on.
The interface will be capable of allowing the staff to:
Register to use the system if it is the first time they are using it.
Page 294 of 303
The system ensures any member of staff is registered before allowing access to any of the
staff specific features of the system.
Enter their login details to access the materials list form.
The system is very robust and will not allow users full access to the features of the system
unless valid login credentials are provided.
Edit the materials list once accessed.
A form is dedicated to the editing of the materials list, where items can be edited, added or
deleted.
Access any student order.
Another form is dedicated to allowing members of staff to search for student orders. They
can be accessed/viewed at any time providing the input details are correct.
Be reminded of their password.
The solution does not allow for this to happen because it is a security issue. An explanation
detailing this decision will follow at the end.
The system will allow the input of and have the facility to store the following details:
Student Username, Password and other student details.
The student username, password and other details can be stored from the registration form
on the system.
Student Order:
o Material name selected.
o Material Size selected.
o Quantity selected.
o Cost of order.
All the order details above are stored on the new order and edit order forms on the system.
This has been verified in the tests that were conducted on the system earlier.
Any updates to the Material List.
Any updates to the material are saved automatically on a form dedicated to updating the
materials.
Any updates to the Student Order.
The edit order form saves all changes made to the student order. This can later be checked
when visiting the find order or the edit order form again. This has also been verified during
testing.
The system will allow for the searching of student order by the student login details. The login details will be
stored alongside other data that will ensure the correct order is displayed at the time of searching. This will also
ensure no errors occur during search or more than one order is related to one student.
This has been changed slightly. Although the search still exists, the details used to search for the
order are the student forename and surname. This decreases the chance of running into errors
during the search and returns more accurate results. However the objective is still fulfilled.
Page 295 of 303
The design of the computerised system should be professional and simple to use as students will be using it as
well as the staff members of the department. The appearance of the system should remain consistent to ensure
the program navigation is quick and simple. The computerised system should be completed within the time
provided.
The design of the system is eye-catching and sticks to the sketches made during its development
stage. The interface remains consistent and this ensures that navigation is quick and simple. The
solution was also completed within the time limit specified.
Overall the solution satisfied nearly all of the objectives. The only objectives it did not fully satisfy
were the members of staff being able to have a password reminder and the data used to find a
student order. The latter however, wasn’t so much of a problem as it increased the efficiency of the
search by searching for related records. The staff password reminder did pose a security issue in that
a student could have retrieved a member of staff’s password without too much difficulty. This would
mean the student could log into the system as a member of staff and have full access to the
materials prices and the materials list.
Page 296 of 303
Solution Satisfies the Evaluation Criteria
To successfully evaluate the computerised system, a set of evaluation criterion was created that
would allow comparisons against to measure the success of the solution. The solution is compared
with the evaluation criteria to see if it satisfies the criterion. The result is detailed below.
The old system was very time consuming. The new system should minimise the time to produce the
orders. The calculations of the old system were identified to be the most difficult phase of the ordering
process. The new system should make the ordering process simple by automatically calculating the
costs for the orders. This should minimise the errors within the process.
The system now minimises the time to produce the order. Previously, where it would have
taken several lessons to calculate and validate the orders, using the system on several
computers can produce all the orders for a whole class in roughly a lesson. The
computerised solution has made a big difference to the amount of time being spent on
ordering. It has fulfilled this aspect of the evaluation criteria. The calculations are also
automatic and all the student needs to do is input valid material information, which
shouldn’t be difficult as the system is fully validated.
The new system should not allow duplicate accounts. This will extend to not allowing invalid data and
details. The human errors should be minimised to none. The new system should allow the students to
edit the orders with ease.
The system has a comprehensive check for exiting usernames to ensure that duplicate
accounts cannot be registered. The validation extends to all the forms that require an input
on the system. The new system has an easily accessible form that students can access to edit
their order.
The suitability of the solution will need to be evaluated to ensure that the solution meets the objectives. The
suitability will be assessed after the system is created. Taken into account will be who the system was designed
for, whether it is suitable for audience and the purpose the system was created for. For purpose, the system will
be compared with the objectives I specified earlier in documentation.
The system meets all the objectives that were designed to measure the suitability of the system. The
system is fit for purpose.
The usability will be tested by me and others to see if the system is clear enough so that the user can navigate
and complete tasks successfully. Other factors that will be taken into account are how easy the system is to
use, whether it is possible to use the solution with no prior information on its purpose because this will indicate
the system is very usable.
The system was tested by students studying the subject and the technician oversaw the testing of
the system. Not a single student who tested the solution was given any prior information about how
to use the system. The feedback from the students was that is was a very efficient interface that was
easy to navigate around. This highlights how easy the system is to use and thus meets this aspect of
the criteria also.
The success rate will also be determined by the students that test the system. A good indication to me will be if
75% of the students that test the solution agree that the system is fit for audience and purpose. But if the
system fails to convince 75% of the students, it will be tweaked in accordance to the tester’s feedback. In other
words, corrective maintenance will be necessary to improve the system further.
Page 297 of 303
Fifteen students tested the system and the feedback was overwhelmingly positive. Fourteen
students had declared the system more than satisfactory and fit for purpose. This is higher than the
75% limit the criteria had planned to meet. Thus the system is fit for purpose due to almost universal
agreement from the testers.
The success rate will also be tested by performing acceptance testing. This will involve the testing of the system
against the technician’s system criteria. The technician criterion includes the following:
The printed orders the system produced must include:
o Full Student Name & Form
o Date of Order
o Full Details of Order (inc. Breakdown of Costs)
o Total Cost of Order
The printed invoices include the student’s full name, form, date of order, full details of order
and the total cost of the order. Evidence of this can be seen in the testing phase. This part of
the technician criterion is satisfied.
Materials List available on the system must include:
o Material Name
o Material Depths Available
o Material Sheet sizes
o Material Sheet Costs
The materials list that is available on the system includes all the information that is
requested in the criterion. Evidence of this can be seen in the testing phase. This part of the
technician criterion is also satisfied.
Staff or Technician Options must include:
o The ability to find a student order if needed
o The ability to update the materials list at any given time
Finding a student order and updating the materials list can be done at any time providing the
member of staff can login onto the system. Separate forms have been designed to deal with
the separate processes. Point satisfied.
Student Options must include:
o The ability to edit an order
o The ability to re-print a previous order
o The ability to view the latest materials available and their prices
When the student has logged on all the options detailed above are available. The materials
list is always displayed with the latest information and there is no limit on how many times
the order can be re-printed. Point satisfied.
If the system meets 90% of the technician criterion at a satisfactory level it will be considered a success. If it
fails to meet the criterion, perfective or adaptive maintenance will be required to ensure that it does as the
system will strive to meet every requirement.
The system has met 99% of the technician criteria to a satisfactory level and thus the system can be
considered a success. Therefore there is no need to perform any perfective or adaptive maintenance
on the system.
Page 298 of 303
Feedback from the technician will be the decisive information on whether the new system is a success. Being
the most experienced with the old system, the technician will rate several aspects of the system on a scale of 10
and leave detailed comments. Again, this may result in some corrective maintenance.
The following is how the technician has rated the system:
Interface 8.5/10
Navigation 10/10
Options 8.5/10
Meets Criteria 9/10
Accuracy 9/10
Ease of Use 8.5/10 Overall Score: 9/10
The system has scored relatively high. This was direct feedback from the technician, who agrees the
system could be implemented and the affects of which would show immediately. The system can
thus be considered a success.
The system has satisfied the majority of the evaluation criteria and almost the entire technician
criterion. It can now be concluded that the system is a success and is suitable for use by the
department whenever they wish to implement it.
Page 299 of 303
Future Improvements
The testing of the system was to ensure the system was usable, suitable and above all functioned
correctly. The testing proved crucial as it helped reassure that all areas were functioning correctly.
Although the system functions correctly and can be considered a success if measuring against the
objectives and the evaluation criteria, the system could be improved in areas to further enhance it.
Major improvements:
System creates a batch order for the technician.
o A major part of the department ordering process is the creating of a batch order to
send to suppliers. Adding this feature would involve adding a separate facility to the
system that would group similar materials and sizes and produce a list of them
which the technician could print out. It may also further extend to group orders of
the minimum amount of sheets are ordered. This could also help the department
financially.
System allows the members of staff to have a password reminder feature.
o This was not included initially for security reason but the facility could be added
onto the system if there was an extra measure of security for staff accounts. This
could be in the form of an extra question or an extra password.
Minor improvements:
Real-time updates on the materials that can be ordered.
o Materials have to be updated on a separate form before the affect of the change is
visible in the new order or edit order forms. This minor change would result in
students being able to order whilst the material prices can be changing
simultaneously. This is not very practical and this is why it is included a possible
minor change.
The ability to view the materials list without logging in.
o Currently the system requires users to log in to access the full range of features the
system has to offer. It would be more convenient, however, if the materials list
could be viewed without logging in. It would certainly cut down the amount of time
spent to retrieve the information wanted.
Further improve the security of the system.
o To further improve the security of the system, mainly where the password can be
displayed on the form, additional questions or an additional password could be
required. This would ensure that the security of the system is improved and lower
the chances of needing a password reminder or your account details being stolen.
Page 300 of 303
Log the user out automatically after 15 minutes.
o Logging the user out if there is no input from the keyboard or mouse for fifteen
minutes would be a helpful feature. This would tackle a problem if the user had
forgotten to sign off and increase the security measures by preventing another user
to use the account that was left logged in.
Improve the help the system provides.
o Although there were no complaints about the complexity of the system during the
testing of the system, to make it more user friendly a help file could be included on
the system. This would be a better solution than providing a readme file or a user
manual for the system as it would be available spontaneously and always up to date.
Both the major and minor future improvements would improve the system in the long run. They
were not included as the main aim of the solution was to meet the objectives and any requirements
After evaluating the system, it can concluded that if all these future improvements were to be
implemented properly then it would make for the best possible system for the department.
Page 301 of 303
CG4.7 USER DOCUMENTATION
Installation
To install the Resistant Materials Ordering Application simply follow the instructions below:
1.) Double-click on the SETUP application icon as seen in the picture below. This should
start an installation wizard that will help you through the installation process.
2.) Click the OK button to begin the installation process.
2.) Click the icon to begin the application setup.
Page 302 of 303
4.) Leave the default program group selected and click the CONTINUE button.
5.) Wait whilst the application is installed onto your system.
6.) Click the OK button when the following message is displayed.
7.) The Resistant Materials Ordering Application has now been successfully installed onto
your computer. You may now use the application at any time on your computer.
Page 303 of 303
Use
A user manual for the application has been created for the users of the system. The user manual is
best utilised on the computer although it can be useful if used in printed form.