AUTOMATED SPORTS CLUB BOOKING AND ENQUIRY SYSTEM

AUTOMATED SPORTS CLUB BOOKING
AND ENQUIRY SYSTEM
James Salmon
BSc Information Systems
2001/2002
i
Summary
OBJECTIVES
The key objective of this project is to produce an effective automated booking
solution for a small to medium sized sports club. Many problems exist with the
current manual systems that inconvenience staff and members of the club al ike. The
project seeks to overcome these problems and produce a system that can be deployed
at a low cost.
WHAT THE PROJECT ACHIEVED
A web based booking system was constructed to allow members to book facilities
from any computer that has Internet acces s. Provision was made for those members
who do not wish to use the online system, as staff can book facilities on their behalf.
In addition, a number of enhancements that will make the task of managing
membership at the club were also implemented.
ii
Table of Contents
CHAPTER 1 – INTRODUCTION .........................................................................................1
1.1 PRELIMINARY ANALYSIS..................................................................................................1
1.2 CURRENT SYSTEMS ..........................................................................................................1
1.3 PROJECT PLAN ..................................................................................................................3
CHAPTER 2 - BACKGROUND READING AND RESEARCH........................................4
2.1 INTRODUCTION ................................................................................................................4
2.2 EXISTING SOLUTIONS .......................................................................................................4
2.3 DEVELOPMENT METHODS ................................................................................................5
2.4 HOSTING ........................................................................................................................10
2.5 SUMMARY OF DEVELOPMENT METHODS AND TOOLS ....................................................10
CHAPTER 3 – ANALYSIS...................................................................................................12
3.1 USER REQUIREMENTS ....................................................................................................12
3.2 SUMMARY OF REQUIREMENTS .......................................................................................14
CHAPTER 4 – DESIGN........................................................................................................17
4.1 DATABASE .....................................................................................................................17
4.2 WEB INTERFACE.............................................................................................................20
4.3 ASP PAGES.....................................................................................................................20
4.4 CGI SCRIPTS ..................................................................................................................21
CHAPTER 5 - IMPLEMENTATION..................................................................................23
5.1 DATABASE .....................................................................................................................23
5.2 WEB INTERFACE AND ASP.............................................................................................26
5.3 CGI SCRIPTS ..................................................................................................................31
CHAPTER 6 - TESTING......................................................................................................34
6.1 SOFTWARE TESTING .......................................................................................................34
6.2 USER ACCEPTANCE TESTING ..........................................................................................36
CHAPTER 7 - DEPLOYMENT ...........................................................................................37
7.1 INTRODUCTION ..............................................................................................................37
7.2 DEPLOYMENT OF DATABASE .........................................................................................37
7.2 DEPLOYMENT OF CGI SCRIPTS ......................................................................................38
7.3 DEPLOYMENT OF WEB INTERFACE .................................................................................39
CHAPTER 8 - EVALUATION.............................................................................................40
APPENDICES ........................................................................................................................44
APPENDIX A – REFLECTION ON PROJECT PROCESS .............................................................44
APPENDIX B – GANTT CHARTS ............................................................................................45
APPENDIX C – REQUIREMENTS INTERVIEWS .......................................................................47
APPENDIX D – DATABASE STRUCTURE ...............................................................................49
APPENDIX E – SAMPLE ANNUAL SUBSCRIPTION BILL .........................................................50
APPENDIX F – SAMPLE MEMBERSHIP FORM ........................................................................51
APPENDIX G – USER ACCEPTANCE TESTING .......................................................................52
APPENDIX H – SCREEN SHOTS .............................................................................................54
APPENDIX I – USER GUIDE FOR ADMINISTRATION STAFF ....................................................55
APPENDIX J – REFERENCES AND BIBLIOGRAPHY ................................................................56
iii
Chapter 1 – Introduction
1.1 PRELIMINARY ANALYSIS
The Ellesmere Spo rts and Leisure Club (“the club”) provides cricket, tennis, squash, bowls,
and croquet facilities to its members. In addition, there is a function room which is available
to hire by anyone, and a bar / restaurant. Two main forms of analysis were performe
d in
order to determine problems with current systems – the first being interviews with members
of staff, and the second from my own observations being a member at the club for several
years. A transcript of the interviews is included in appendix C. The
“Object Oriented
Analysis and Design” module provided useful guidance when performing the analysis.
1.2 CURRENT SYSTEMS
To determine what would be required from the new system, it was first necessary to analyse
the current manual procedures and determine what problems are presented.
Sports bookings
Members of the club can book the sports facilities for tennis and squash. To book either
sport, the member must sign a list. The list is divided into 30 minute slots, spanning the
duration of the opening h ours - 9am to 11pm. Members may choose to book more than one
slot to obtain longer use of the facilities. The current manual system is inconvenient for
members – they have to visit the club in order to make a booking or check availability. It also
causes administration problems – if a member finds that he or she is unable to attend at the
time they have booked, they rarely come back to the club in order to cancel the booking.
Members also occasionally forget when they have made a booking for, and so fai l to turn up.
Club staff occasionally receive telephone booking enquiries, and must put new lists out every
week.
1
A remotely accessible system that would allow members to check availability and make
bookings would be of great benefit to club members and staff alike.
Function room bookings
Function room hire is available to both members and non -members. Enquiries for function
room hire can currently only take place in the main club house. Most of these enquiries
currently take place over the phone, whi ch is inconvenient for staff if the club house is busy.
After pricing and details of supplementary services (such as catering) have been agreed, a
booking form is filled out in duplicate, and staff record the booking in a paper diary. Rooms
can be booked for the morning, afternoon and/or the evening. As prices vary depending on
the type of event and what supplementary services are required, and the club do not allow
certain events to take place, the process of booking function rooms cannot be fully automated,
but steps can be taken to improve the current manual system.
It would be useful to have information about the function rooms online, and the ability to
check availability and request to book a room, as this would be more convenient for staff and
customers.
Administrative system
Membership fees are charged on an annual basis, the fee being dependant on the membership
type – Sports –full, Sports –over 60, Sports –student (14-21), Sports – junior (under 14) or
Social membership. The club currently
has a spreadsheet, created by one of the
administrative staff, which stores a list of all members, the amount payable (after any
discount has been taken into account), and whether or not they have paid. This information is
linked to the word processor us
ing mail merge in order to produce the annual bills
automatically. As payments are received, the administrative staff must open the spreadsheet
and mark the bills as paid.
As the online booking system will have to store a list of all members and their me
mbership
type, it would be useful if billing functionality could be incorporated into the system, and the
process of managing bills be made easier and more dynamic.
2
1.3 PROJECT PLAN
Given the duration of the project, it was necessary to devise a projec t plan at the outset. The
project was divided into key phases and the plan identifies the order in which the phases are
to be completed, and specifies target completion dates for each task. This is beneficial, as it
ensures efforts are focused into doing the correct task at the correct time and also increases
motivation. The initial plan of tasks and deadline dates are outlined below. Some of the
phases overlap – details can be seen in the Gantt chart in appendix B.
The relevant sections of the project report are to be written at during each phase.
Phase 1 – Feasibility study and project planning
• Perform preliminary analysis
• Research possible and existing solutions
Deadline
30/10/2001
Phase 2 – Analysis
• Determine full system requirements and user needs
30/11/2001
Phase 3 – Design
• Design database
• Design web interface
• Design extra enhancements
14/01/2002
Phase 4 – Implementation
14/03/2002
• Implementation of designed features
• Test system
• Time has been allowed in this phase to take into account exam revision
Phase 5 – User testing and evaluation
• Feedback from users
• Carry out any alterations to system if required
• Time has been allowed to rectify any problems found in earlier phases
and to allow for any unforeseen delays
30/04/2002
Modifications were required to this initial plan due to an unexpectedly long implementation
process – the revised Gantt chart is also shown in appendix B.
3
Chapter 2 - Background reading and research
2.1 INTRODUCTION
In this chapter, t he options for implementing the system are evaluated, and the choice of
development methods and tools are identified and justified.
2.2 EXISTING SOLUTIONS
Several searches on the web revealed
the fact that no commercial booking and enquiry
systems that are suitable for small to medium sized sports clubs are readily available.
Last year, a sports centre booking system final year project was completed at Leeds
University[1]. This system was developed primarily for the University Sports Centre, which
due to different user requirements would not be suitable for the average small to medium
sized sports club. Reasons include:
•
The database element was developed using PostgreSQL, which most end users do not
know how to operate. If the club required an additio
nal query, it would require a
computer professional to perform the task. In addition, basic functions such as
printing a list of members from the database would not be possible without
knowledge of the database.
•
Whilst the PostgreSQL software is available free of charge, support costs are very
high due to the fact that not many people are familiar with the product.
•
The system does not have provision for the function room enquiry aspect, which
would be required by many small to medium sized sports clubs.
•
There must be a level of flexibility with regard to the hosting of the system. Last
years project was developed for deployment on the University network. These
resources are not available to most sports clubs, which require the system to be
operational for minimal costs. This requires the system to be able to be locally hosted
or hosted by an Internet Service Provider (ISP) on a low cost hosting plan depending
on which is the most cost effective option.
4
2.3 DEVELOPMENT METHODS
Static Web pages are ba sed on two tiered architectures, consisting of the client (user’s Web
browser) and the server (Web server). As Internet technologies have developed, and
interactivity has become a key requirement for users, Web applications have emerged. Web
applications tend to use 3-tiered architectures. The tiers are:
•
Presentation tier. The front-end interface for the system.
•
Business logic tier. Captures and implements business procedures and rules.
•
Data tier. Data is stored at this level.
The options for each layer are discussed in detail below.
Presentation tier
Two options exist for the construction of a remotely accessible application:
i)
A bespoke application, distributed to members on CD-ROM or similar.
ii)
A web browser based system.
The table in figure 1 compares the two options.
Bespoke application
Cost
Ease of use
Security
Maintenance
Expensive due to distribution, etc.
User must learn new interface. May
be more graphically impressive,
though.
Likely to be slightly more secure, as
CD is only distributed to members
initially.
Upgrades would have to be
distributed and installed.
Web browser based
Cheap – server is main cost.
Familiar web interface.
Varying level, dependent on
sensitivity of data.
Can be updated centrally with
immediate effect.
Figure 1 – comparison of options for a remotely accessible application.
It would appear that a web based system is more appropriate for this application. The
“Human Computer Interaction” module offers useful information about the constru
ction of
user-friendly web sites, as did the “Co-operative Information Systems” module.
5
Data tier
A RDBMS (Relational Database Management System) will be used for this tier. The
“Databases Principles and Practice” module, which was studied in the seco nd year, provided
useful background knowledge for research into this section of the system.
A RDBMS is a set of software that allows the user to create, review, update and delete
information held in a relational database[ 2]. Use of an RDBMS is more appro priate for this
system, for a number of reasons. These include[3]:
•
Redundancy can be easily controlled
•
Unauthorised access can be restricted
•
Enforcing of integrity constraints
•
Providing backup and recovery in the event of hardware of software failures
•
Transactional controls make accessing and sharing data more efficient
•
Faster development time
After performing the Analysis, it was clear that Microsoft Access would provide an
appropriate solution for this application. Although Access is a file
-based datab ase as
opposed to a full server (like Microsoft SQL Server), it has a number of advantages over
the alternatives.
•
Due to its ease of use, it will be possible for administration staff at the club to add
new queries if they are required, and any maintenance that is required will be simple
to carry out. This is discussed in more detail in the evaluation section (chapter 8) of
this report.
•
Integration with Microsoft Office makes the process of generating the annual
subscription bills and reminders straightforward.
•
Access is capable of having 50 simultaneous users, which given that users will only
be connected to the database for a few seconds in order to check availability of
facilities or to make a booking, is more than adequate for small to medium sized
sports clubs. If more than 50 users did attempt to connect at the same time, some
users would be unable to retrieve bookings data or make a booking, but they would
simply have to wait a few seconds and try again – no erroneous data would be entered
into the database.
•
A “free” DMBS such as PostgreSQL would not be suitable due to lack of readily
available support. This would result in a system that is costly and difficult to
maintain.
6
•
Whilst there is readily available support for Microsoft SQL server, ISP hostin g costs
would be substantially more (Verio UK costs an additional £40 per month, which
would raise the annual hosting cost from under £300 to almost £800).
•
If a sports club wanted to host the system onsite, they would have to buy SQL Server,
which would cost approximately £700.
•
If the application were to be used by a larger organisation with more members, the
database could easily be changed by substituting the database driver. This is
discussed in more detail in the implementation chapter (section 5.1).
Business-logic tier
As the application is to be remotely accessible, the core functionality has to be on the server
side, with data transfer to the client being kept to a minimum. Server side scripting is a
popular technique for the implementation of su ch Web applications. The “Internet Systems
Technologies” module relates directly to this section of the system. Unfortunately, as the
module was taken in the final semester of my third year, and the information on scripting
languages was towards the end
of the module, it was too late to incorporate any of the
material and advice offered in the lectures into the development of the system.
The four main scripting techniques were each considered for use in this tier. They are:
•
Cold Fusion
•
Active Server Pages (ASP)
•
Java Server Pages (JSP)
•
CGI scripting
Cold Fusion
Cold Fusion is tag based rather than script based. This has made it very popular amongst web
designers who are used to HTML. It uses a its set of tags to perform any function that is
available using ASP or JSP, and is considered easier to use[
4
] as it is a compact language
which requires few lines of code. Portability is not a concern either, as it is available for
Windows, Sun Solaris and Linux.
Cold Fusion Server is available in three v ersions: Express, Professional and Enterprise. The
Express version is free, but would lack essential functionality required by the system. The
professional version has all the necessary features, but ISPs tend to charge a considerable
7
amount of money per month to host such a system. Also, if the system were to be hosted
onsite at the sports club, a copy of Cold Fusion server would have to be bought, at a cost of
around £1000. Given that the only major advantage of using Cold Fusion appears to be easier
development of the system, it does not justify the extra expense.
Java Server Pages (JSP)
JSP is Sun Microsystems’ scripting language, based on the Java programming language. JSP
is a sub section of the Java 2 Enterprise Edition, the application develop
ment environment,
which includes the most popular Java technologies such as Servlets, Enterprise Java Beans
(EJB), Java Database Connectivity (JDBC), and Java Naming and Directory Interface (JNDI).
JSP has excellent portability, being both platform and se rver independent. In addition, JSP
uses the Java language for scripting, which is widely regarded as a mature, scalable
programming language. Hosting a JSP solution is cost effective, as there are a wide range of
servers that support JSP scripts. It was originally planned to develop the business logic layer
using JSP, but it was found that there were no JDBC drivers readily available that support
Microsoft Access reliably.
Active Server Pages (ASP)
ASP is often thought of as an entity in itself, but
is in fact a combination of technologies,
which work together in order to provide dynamic web content. A series of ASP objects that
can be manipulated by languages such as VB Script or Jscript are present, in addition to a
number of active server componen ts ranging from Active X Data Objects (for data access) to
custom COM components.
Hosting an ASP solution would be cost effective. It would simply require the server to be
running Microsoft’s Internet Information Services (IIS) version 4 or 5. All ISPs that provide
Windows NT based hosting plans allow execution of ASP scripts. IIS is also included in
Windows 2000 and XP Professional, so hosting from a PC would be an option.
A disadvantage of using ASP is that it can currently only be displayed in Micr osoft’s Internet
Explorer browser. Statistics indicate that since 1997, Internet Explorer is being used by a
rapidly growing percentage of users at the expense of Netscape. The average global figure
5
for use of Netscape in 2001 was only 13% and is rapidl y decreasing - Internet Explorer being
used by the majority of other users. Also, the latest version of Internet Explorer is available
for free download for Windows, Unix and Macintosh operating systems, so it is possible for
8
anybody to access the site if they are prepared to use this browser. ASP was therefore used to
implement the system.
Common Gateway Interface (CGI) scripting
CGI is a standard for managing the interface between Web servers and the server software. It
converts data from the Interne t format into something that can be used by the operating
system. Most web servers can handle dynamic files using CGI. The web server executes
CGI files and sends the output to the user rather than just sending the static content straight to
the browser. The server recognises files that should be executed because they are placed in
directories that instruct the server that files contained within are to be dealt with like this.
Most web servers have been standardised to include a cgi -bin directory, which is the default
location that such files should be placed. PERL (Practical Extracting and Reporting
Language) is the most popular language for CGI scripting, as it does not have to be compiled
on the web server prior to its use.
CGI scripting is very p ortable – it can be run on any CGI enabled web server, and can be
programmed in a variety of languages. However, CGI can be slow for multiple user access,
as a new process is started each time the script is run (ie the script must run separately for
each user), which is demanding on the server. The three other scripting methods described in
this chapter overcome this problem by embedding the code in the HTML page, and
interpreting the page on the server without starting a separate process for each user on
the
server. In addition, when using CGI scripting, database access is only available by using
additional libraries, and maintaining state throughout multiple web pages can be difficult.
It was therefore decided that CGI scripting would be inappropriat
e for implementing the
booking system or the associated booking system management facilities (such as updating
member details via the web browser). However, it was suggested that CGI scripting could be
used to implement two extra enhancements – an automated password reminder system and the
Secure Sockets Layer (SSL) credit card payment system, details of which are discussed in
section 4.4. Doing this will allow the traditional CGI methods of reading input, accessing
databases and producing output to be compared with more modern ASP techniques.
9
2.4 HOSTING
A key requirement for the implementation of this system is to minimise the running costs.
This is very important if the application is to be targeted at other small to medium sized sports
clubs with fewer than 50 employees, of which there are currently 4,478 in the UK [6].
The major cost of the system is hosting, to enable remote access. There are two options for
hosting – through an ISP or using the PC that is onsite at the club.
Hosting on the club’s computer would require a fast ‘always on’ Internet connection and a
static IP address. At present, it would not be economical to host the system onsite due to the
high cost of having a connection that is adequately fast to serve users of the syste
m.
However, it is likely that prices for fast, ‘always on’ Internet connections will fall in the near
future, and speeds will improve. It is therefore desirable to design the system so that it can be
easily transferred between the two different hosting models.
Currently, there are a number of advantages to using an ISP. The technologies selected at
each layer mean that a basic NT hosting plan is all that is required. Verio’s basic NT hosting
package priced at £24.95 per month can be used. Whilst cheap er hosting plans are available
with other ISPs, it was felt that the use of an ISP that provided good customer support was
required as there are no specific computer support staff at the club. This will be far more
reliable and require less maintenance th
an hosting on the club’s computer. Bandwidth
provision and storage space requirements are discussed in more detail in the deployment
chapter (section 7.1).
2.5 SUMMARY OF DEVELOPMENT METHODS AND TOOLS
For the reasons discussed earlier in this chapter, Microsoft Access will be used to develop the
data tier and provide automated generation of annual subscription bills using mail merge.
To develop the forms that are required for the maintenance of members, membership types
and facilities, Macromedia Dreamweaver UltraDev 4 will be used. This was chosen as many
forms are required for adding, updating and deleting these attributes, all with similar
requirements. It was felt that by using this piece of software in order to make the simple and
repetitive aspects of creating the site less time consuming, more time and attention could be
given to the more challenging aspects such as displaying the bookings timetable, and ensuring
10
that a system was produced that met and exceeded the user requirements. In additio
n,
Dreamweaver UltraDev 4 has a graphical interface for organising and managing all of the
files in the site, making tasks such as checking for broken links a simpler process.
The booking system itself is to be written manually in ASP, and two of the ex
tra
enhancements are to be created using PERL CGI scripts.
11
Chapter 3 – Analysis
3.1 USER REQUIREMENTS
This chapter outlines the user requirements and objectives of the system and relates them to
the minimum requirements for the project.
After perf orming the preliminary analysis, it was ascertained that there are four different
categories of people that will use the system. Within these categories, people will have
varying amounts of computer experience.
Categories of user
1) Non-member
2) Member
3) Club staff
4) Administrative staff
Requirements for each user category are detailed in this section in order to:
•
Present to the ‘problem owner’ (the Club) to clarify understanding of the problem.
•
Ensure that I, the ‘problem solver’ am solving the correct problems in a way which
is acceptable to the ‘problem owner’.
•
Increase likelihood of developing a system which will be successful.
1) Non-member
•
A visitor can access the system by typing the URL of the site home page into their
Web browser software.
•
The home pa ge should be displayed, which should provide links to promotional
information, membership pricing details, and contact details for the sports club.
•
If the visitor is interested in joining, they can fill out an application form online,
which will be sent to the membership secretary. Alternatively, the visitor may wish
12
to look at the ‘contact details’ page and e
-mail or telephone the club for more
information.
•
The visitor should not be granted access to restricted areas of the site such as
members’ details or sports bookings.
2) Member
Members of the club range in age from 9 to over 80 years old, and obviously have different
amounts of computer experience.
•
Members should be able to access the home page in the same manner as non
-
members, but will be required to enter their user name and password in order to log in
to the system to access the more advanced functionality of the site.
•
After logging in, members will be able to view bookings for sports activities, and
make a booking if they wish to do so. The b ooking will then be stored in the system.
Members should also be able to cancel or amend their own bookings.
•
Each member should be able to view bookings that they have made.
•
An e -mail link will be provided so that members can inform administration staff
if
any of their details need updating (eg change of address)
3) Club staff
There are 15 part time bar staff – mostly students, who are all reasonably computer literate,
and use the Internet regularly. Learning to use the new system should not be a probl
em for
the staff, as the familiar web browser interface will be used.
•
Staff who work in the club should be able to perform all of the tasks which a member
can perform.
•
It is inevitable that the more techno -phobic members will not want to use the system.
Similarly, people will not be able to use the system themselves if they do not have
Internet access. Staff must therefore be able to take bookings on behalf of members.
4) Administrative staff
There are 2 administrative employees, who both regularly use the computer at the Club to do
bookkeeping and maintain the spreadsheet of members. One of the employees is not familiar
13
with the Internet and the WWW, but with some minimal guidance should be able to use the
system.
•
Administrative staff should be able to add new sports activities and membership types
and also modify annual subscription charges for each membership type.
•
In addition, administrative staff must also be able to add new members when
application forms are received (whether electronic or paper based), modify members’
details when requested to do so, and also remove members, when resignations are
received. It is necessary to record whether each member has paid their annual
subscription charge.
•
Once a year, annual subscription bills are generated and sent out to all members. The
system should provide facilities to generate the bills automatically from the database
and print them on the local printer.
Non–functional requirements
•
The overall running costs of the system need to be kept to a minimu
m - this
requirement was discussed in more detail in the Research chapter.
•
The system needs to be very reliable and largely maintenance free, as there are no
computer support staff employed by the club.
•
The system should be easy to use.
3.2 SUMMARY OF REQUIREMENTS
The basic user requirements, which were determined in the first section of this chapter are
summarised in the table in figure 2 in order to:
•
Clarify what functions should be available to each user category.
•
Gain a better understanding of the
entities and relationships that will form the
database element.
•
Outline precise required functionality.
14
Administrative
staff
Club staff
Member
Non-member
Facilities
Display available facilities to book
Create a new facility
Amend facility details
Delete a facility
Membership types
Display membership types available
Display annual subscription charge for each type
Create new membership type
Modify existing membership type
Delete a membership type
Members
Display details of any member
Create a new member
Modify member details
Delete a member
Bookings
Display own bookings
Display bookings for each activity
Display bookings by user
Create a booking
Create a booking on a member’s behalf
Apply to book a function room
Book a function room
Delete a booking
Delete a booking on a member’s behalf
Financial
Display members who have not paid their subscription fees
Mark a bill as paid
Create a bill
Figure 2 – summary of user requirements
To summarise, the key requirements are that a member should be able to make bookings fo r
sports activities without visiting the club, and without contacting staff. Automating the
process of function room hire as much as possible is also essential. Given that the system is
for a small to medium sized sports club, it is also necessary to ens ure that the system can be
operational at a low cost. As there are no computer support staff at this club nor most other
small to medium sized clubs, the system must be as reliable and maintainable as possible by
people who have minimal computer experience.
15
Minimum requirements
The minimum requirements for the project are therefore as follows:
1.
Bookings for sports facilities can be made without visiting the club.
2.
Bookings can be made without the need for staff contact.
3.
For those members without Internet access or who are not computer literate,
bookings can still be made at the club.
4.
Enquiries about function room availability and pricing can be made without
visiting the club (bookings cannot be made online as certain events require staff
approval).
5.
Ensure that the system could be put into use at a low cost.
Possible further enhancements
A number of extra requirements that are desirable but not essential are as follows:
1. To make the system as maintainable as possible, the process of adding, deleting and
updating sports activities, member details and membership types should be made as
straightforward as possible.
2. There are 4,478 other small to medium sized sports clubs [6] in the UK with under 50
employees, which may benefit from a low cost booking system solution, so the
system should be able to adapted for use at other small to medium sized sports clubs
with minimal modification.
3. The system should allow visitors to apply for membership, and automate this process
as much as possible.
4. As mentioned previously, the facility to print annual subscription bills could be
included.
5. An automated password reminder system could be implemented so that the process of
retrieving forgotten passwords does not require staff contact, and therefore reduces
the burden on staff to support the system.
6. A method of paying subscription bills online using a credit card could be
implemented – this would not only be more convenient for members, but would also
save on administration costs.
16
Chapter 4 – Design
There are three separate s ections that have to be designed in order to meet the minimum
requirements and ‘extra enhancements’ system functionality that was outlined in the analysis
process.
1) Database
-
Tables and attributes
-
Billing system
2) Web interface
-
To provide a system that is remotely accessible
-
To provide a system that is easy to use
3) ASP pages
-
Booking system
-
Maintenance for booking system (changing facilities, membership types,
deleting old bookings etc.)
-
Maintenance of member details
-
Membership application feature
4) CGI scripts
-
Automated e-mail system for password reminder
-
Secure Sockets Layer (SSL) credit card payment system
Material covered in the “People Centred Information Systems” module taken in the third year
proved to be useful when designing the system, ensuring that t
he focus of design is user
oriented.
4.1 DATABASE
The database is to be designed first, as most of the functionality is accessed by linking to the
database. A good database structure is critical for the system to function correctly. The first
step in d atabase design is ascertaining exactly what data needs to be stored. The club
currently holds the following information about each member in a Microsoft Excel
spreadsheet:
17
Membership number
Title
Name
Address
Postcode
Telephone number
Date of birth
Membership type
Annual subscription fee for membership type
Discount
Total annual subscription fee payable
Whether or not bill has been paid
Comments
It will be necessary to store all of this information about each member in the new system. It
is evident that mapping a ‘member’ entity type, which corresponds to a table in the database,
is appropriate. However, for members to be able to access the online system it will be
necessary to give each member two further attributes - a unique username and a password. In
order to make communication with users of the system easier, it is also vital that members e mail addresses are stored. For example, if a member forgets his or her password, it can be
sent to them via e-mail if addresses are stored in the database. Modifications were required to
most of the tables described in this chapter - the complete final list of tables and attributes for
the database is shown in Appendix D.
Relational databases are designed for normalised tables [7] to ensure that data redundancy and
hence anomalies are avoided. As the membership type determines the annual subscription
fee, it is necessary to model the ‘membership type’ attribute as an entity in its own right. The
attributes for this entity are as follows:
Attribute
Type
Description
Category
Text
Membership category – foreign key to Member table
Fee
Number
Annual fee for the membership category
From the analysis chapter, it can be seen that it is also necessary to store information about
facilities that are av ailable to book - sports activities and function rooms. This entity,
‘facilities’ can be mapped as a table with the following attributes:
18
Attribute
Type
Description
facility_id
Autonumber
Primary key for facility table
name
Text
Name of facility (eg Tennis Court 1)
A ‘bookings’ table is required to store information about facilities that have been booked by
members.
Attribute
Type
Description
booking_id
AutoNumber
Booking reference number – Primary key
date
Date/Time
Date of booking – Primary key
start
Date/Time
Time booking starts
end
Date/Time
Time booking ends
name
Text
Name of who booking is for
facility_id
Number
Facility number – Primary key
It is possible to create an Entity -Relationship (E -R) model from this analysis. The Rock
-
Evans conventions were used to create the E-R diagram.
Designing the automated billing system simply involved creating a letter in Microsoft Word,
and leaving space for the mail merge fields from the database to be inserted during the
implementation phase. The letter is included in appendix E. It gives the member the option
of changing his or her membership type by ticking a box in the form, which they must then
19
return to the club. In this scenario, administration staff can update the
information in the
system and issue a new bill.
The membership application form also needs to be generated using mail merge. The design
for this form is included in appendix F.
4.2 WEB INTERFACE
A well designed web interface is essential to ensure co mmon functions are easily accessible
and the site is user friendly. It was decided that the “log in” functionality was to be placed on
the home page, and the rest of the site be divided into three main areas
– information for
visitors, the booking system, and an administration section for staff. Care should be taken to
ensure that appropriate colours are used so that text can be read easily.
4.3 ASP PAGES
The output of current bookings should be presented in a way that is clear to recognise when
facilities are booked. A form was designed to allow users to check bookings for a particular
activity. It was designed to be as simple to use as possible, with drop down menus being used
for the activity and the date. The user should be able to view current b
ookings by simply
selecting the activity and date from the menus and clicking on the submit button. It was
decided that bookings should be output into a timetable grid, with a different timetable being
displayed for each facility. A timetable grid should then be automatically generated for the
facility. This automatic generation of timetables is essential, as when new facilities are added
by administration staff, modification of the site should not be necessary in order for bookings
to be made or displayed.
An application form has been included in the ‘join’ section to allow visitors to the site to
apply for membership. This process cannot be fully automated, as a signature is required, but
is designed to be as straightforward as possible. The user su bmits their details using the form
on the website – this information is sent by e -mail to the club, where the administration staff
will be able to input the details into the database and generate a membership form using mail
merge – as depicted in Appendix F. The member will simply have to sign the form when they
visit the club.
20
The process of booking a function room cannot be fully automated either, as arrangements
must be confirmed in person, and a form must be signed. A similar system to the membership
application process will be used. The user first checks room availability using the online
system, and if they wish to apply to book the room, they follow the e
-mail link submitting
details of their requirements (such as catering). When the e-mail is received by the club, staff
can reply with a price quotation. If the user accepts, staff will then mark the room as booked.
The user may then confirm the details in person, sign the form and pay the deposit.
Unfortunately, due to the wide range of supple mentary services such as different levels of
catering, DJ hire, door staff, etc and the large price variations depending on what is required
and at what time of year, it is unfeasible to automate this process any further.
4.4 CGI SCRIPTS
It was decided t hat CGI scripts would be used to create an automated password reminder
system and a Secure Socket Layer (SSL) credit card payment system for the payment of
annual subscription fees.
Automated password reminder system
The password reminder system must be easy to use and inform the user of their password as
quickly as possible. Steps must be taken to ensure that the password is only given to the
intended recipient. Sending the user their password reminder via e -mail seems to meet all of
these criteria. W hen a user has forgotten their password, they simply type in their username
and e-mail address into the appropriate form on the website. The information will be sent to a
CGI script, which will query the database to determine the user’s password. The CGI
script
will then create and send an e -mail, addressed to the user, containing their password in the
body of the message. The message should take no longer than a few minutes to arrive in the
users inbox. Sending information by e-mail is not totally secure, but only the user’s password
is being sent – not their username, so it would be impossible for somebody else to gain access
to the system with a password alone. In addition, the data stored is not highly sensitive, and
potential for serious damage to occur to the system is low.
SSL credit card payment system
To allow members to pay their annual subscription fee renewal more easily, it is desirable to
offer an online payment system. The member should be able to enter the name of the
21
cardholder, the c ard type, and the expiry date of the card. The club has a merchant account
with a bank, and is able to accept payment by credit cards MasterCard and Visa. This
information that the user submits should be securely transmitted from web browser to the web
server. SSL provides a method of doing this – details are discussed in the research chapter.
Once received, there are essentially two options as to where the credit card information can be
stored – in the database or in a text file on the server. Storage
using the database was
considered at first because it would offer a more integrated solution, however I came to the
conclusion that this was not a sensible idea. The database has to be stored in a directory
called ‘/data’, to allow read/write access, as discussed is the deployment chapter (section 7.2),
so it is not possible to give the directory a unique password. In addition, it is not desirable to
store the credit card details for any longer than is necessary to process them, because if an
unauthorised person managed to get a copy of the database, which may contain hundreds of
different credit card details, this would present a serious problem. Therefore, it was decided
that the best option would be for the details, when submitted, be sent using SSL t o a text file
located in a password protected directory. An e
-mail should be automatically sent to the
administration staff to inform them that a payment instruction has been received, but should
contain no details about the payment, as e -mail is not suff iciently secure. The staff can then
view the details by typing the URL of the text file, where they will be prompted for the
password for the directory. They can then process the transaction using the method described
in the deployment chapter, and delete the contents of the text file immediately.
22
Chapter 5 - Implementation
This chapter outlines the processes that were involved in implementing the system. Firstly,
the database implementation is described, followed by the web interface and ASP coding
.
Next, the implementation of the CGI scripts is presented. A number of changes to the
original design were necessary in order to allow the system to function as intended. These
changes are outlined and justified in the relevant sections that follow.
5.1 DATABASE
The database was constructed in Microsoft Access 2000 because it offers low deployment
costs and the easy to use interface will allow the administration staff to maintain and amend
the database if required. For example, it would be possible
for staff to print off a list of all
members, or to add formulate a query without the assistance of a computer professional. The
mail merge facility, which allows annual subscription bills to be generated automatically, is
also an invaluable feature for the club.
Apart from the mail merge feature, Access 2000 was only used to create tables, their
attributes and relationships. The database is queried and updated solely by using Active
Server Pages (ASP) via the web interface.
Constructing tables and their fields in Access 2000 is a simple process; the graphical user
interface makes this task slightly quicker to do than using SQL commands with other
DBMSs. However, although it is easy to create the tables and their fields, it is essential that
the design of the database is correct and suitable for its purpose. During implementation, it
was found that the original design required some modifications to be made to certain tables.
Member
Using ASP it is possible to grant each user a different access lev
el based on the pages that
they are allowed to access. The user simply has to log in to access the restricted areas of the
site to which they are permitted. In the analysis chapter, four different categories of user were
identified – visitor (non -member), member of the club, member of club staff and member of
administration staff. It was necessary to store in the database the level of access each user
23
has. Obviously, details of visitors to the website are not stored in the database, so they are
unable to login to the system, and by default have the lowest level of access. An additional
field ‘accesslevel’ was added to the ‘Member’ table of type integer. A member is given
‘accesslevel’ 2, a member of club staff is given 3, and a member of administration
staff is
given the highest level of access, 4. The default level for people who have not logged in is 1.
It was possible to streamline the membership application process that was initially designed.
Originally, the application form was to be submitted by e-mail to the administration staff. On
receiving the e -mail, staff would then have to enter the details of the person who wished to
join into a form in the administration section of the online system, which would be submitted
into the database using AS P. The staff were then to print off an application form using mail
merge, for the new member to sign. It was assumed that the person who wished to join could
not submit their details into the database directly because they had not signed the terms and
conditions or paid the annual subscription fee.
On reflection, this process seemed quite labour intensive
– it required details to be entered
twice. It was discovered that it would be more straightforward to simply allow the user to
submit their name and contact details directly into the ‘Member’ table in the database using
the online form provided. When the person comes into the club to sign the terms and
conditions, and pays the fee, the member of staff can activate their account by allocating a
username and password for use with the system. Before the username, password and access
level are set, it is not possible for the user to access the system, so it does not matter that their
name and contact details are stored. This simply requires an ASP page
to allow
administration staff to check for new applicants.
Booking
It was decided that instead of storing a start time and an end time in the ‘Booking’ table,
booking slots would be used. As with the current paper based booking system at the club, the
length of the each booking slot is to be 30 minutes. Therefore, it is not necessary to store the
end time of the booking in the database. This will allow facilities to be booked directly from
the timetable, which is more straightforward for users, as a pa rticular time slot can be booked
by just clicking on the time in the timetable. This is discussed in more detail in the
implementation of the web interface, section 5.2
24
Connection to the database
Before the database could be queried, it was necessary t o set up and ActiveX Data Objects
(ADO) connection to the database using Open Database Connectivity (ODBC). ADO offers a
standard interface to the database that allows all operations on the database to be performed.
ODBC is a popular connection method wi
th ADO as most Windows based databases are
ODBC compatible, and ODBC drivers are included with the Windows operating system.
ODBC was developed to overcome compatibility problems between different computers and
software. When an ADO connection is set up using ODBC, the ODBC driver is connected to,
not the actual database. The driver acts as an interpreter
– it translates the commands
received into commands that can be properly understood by the database. Using such an
interpreter has the effect of slowi ng the query process down very slightly, but the delay is
small compared with time taken to transmit data over the Web.
There are two types of connection object that can be used with the ADO object model
– by
using a connection string or using a data source name (DSN).
Using a connection string involves inserting a database specific set of strings in each ASP
page that requires access to the database, whereas setting up an intermediary DSN using the
control panel in Windows NT allows a database to be acce ssed by using a one -line command
as in figure 3. Connection strings are easier to maintain where a number of computers each
access a database on a Local Area Network (LAN), as it would be necessary to modify
settings in the control panel on each computer i f any changes were made. However, for a
Web application, the connection to the database only has to be defined on the Web server, not
on individual computers. In addition, the DSN can be used to access the database using either
ASP or CGI scripts and the location of the database is of no concern, providing the correct
information is stored about the ODBC connection settings. A DSN connection was therefore
used.
To set up the DSN connection on the PC that was used for development of the system, the
ODBC Data Source Administrator was used. This is located in the Control Panel of Windows
NT. The database driver has to be selected (in this case Microsoft Access), and then the name
and location of the database must be input along with a name for the DSN, wh
ich can be
chosen by the developer. If the database requires a username or password to gain access,
these can also be specified. It should be noted that the method of setting up a DSN on the
Web server is different from this process and varies depending on the ISP. The method used
25
for this project is discussed in the deployment chapter, section 7.2. The Data Source Name
‘escweb’ was used in this project – it can be accessed simply using the command shown in
figure 2. This command must be included for e
very ASP page that requires access to the
database.
<% "dsn=escweb;" %>
Figure 3 – defines connection to database using DSN
5.2 WEB INTERFACE AND ASP
Screenshots of the system can be viewed in appendix H. Macromedia Dreamweaver
UltraDev 4 (“UltraDev”) was used to create most of the HTML for the site, and was also used
to automatically generate ASP code for some of the simpler functionality that was required –
such as adding, amending and deleting records in the database. I chose to use this pi
ece of
software in order to make the simple and repetitive aspects of creating the site less time
consuming so that more time and attention could be given to the more challenging aspects
such as displaying the bookings timetable, and ensuring that a system was produced that and
exceeded the user requirements. UltraDev also displays a map of the site, which allows the
pages to be structured more easily and makes checking for broken links straightforward.
However, using UltraDev to perform these tasks turne d out not to be as straightforward as
expected. Firstly, it took a considerable amount of time to gain familiarity with the software
package, and secondly, the code that was generated had to be altered, as it was not of a
satisfactory standard, mainly bec ause no basic error checking was performed
– this is
discussed in the rest of this section. From observing the code that was generated, though, a
good understanding of ASP was gained, which proved useful in the implementation of the
actual booking system, for which UltraDev could not be used due to the specificity of the
application that was required.
Maintenance pages for creating, updating and deleting items
An example of a page created in Dreamweaver is the ‘update member records’ page, for
which access is only granted to administration staff. Screenshots can be viewed in appendix
H.
26
The page ‘member search’ asks the operator to input the surname of the member that they
wish to modify into the HTML form field
– the database contains details of appro ximately
1000 members, so it is undesirable to navigate through the records. When the surname is
submitted, the form is sent to the ASP page (shown in figure 4) using the “post” command.
The surname that the user submitted could just be put straight into
an SQL statement, as
Ultradev can do automatically, but if no data were submitted, an incomprehensible error
message would be generated. For this reason, the surname is retrieved and is declared as a
variable manually using the code in figure 4. The def
ault value for this variable is the
wildcard character ‘%’, so all records of members are retrieved in the order of membership
number if nothing is submitted by the user.
Dim rsMembers_surname
rsMembers_surname = "%"
if (Request("surname") <> "") then rsMembers_surname = Request("surname")
Figure 4 – code to declare submitted surname as a variable to perform error checking
A simple SQL query generates the set of results which is stored in a recordset in ASP - in this
case given the name rsMembers. The code for retrieving this recordset is shown in figure 5.
rsMembers.Source = "SELECT * FROM Member WHERE surname
LIKE '%" + Replace(rsMembers_surname, "'", "''") + "%'"
Figure 5 – SQL statement to retrieve details of members with a surname that matches search
criteria
Another scenario for which Ultradev offers no provision for is if no records match the search
criteria – if this happens, an incomprehensible error message is a
gain generated. An ‘if’
statement was inserted in the page manually to overcome the problem. This only allows the
full web page to be displayed if records are found
– otherwise a user understandable error
message is produced – in this case “Sorry, no records match your criteria” is output.
If records do match the search criteria, the details are output onto the web page. As this data
is an ‘update member records’ page, details are to be modified by the member of staff, so
must be displayed in a way tha
t will allow changes to be made to the data, and the
modifications submitted back into the database. It was found that using dynamic form fields
provided an ideal way of doing this. This involved selecting an appropriate form field type
for each field th at was retrieved from the database. Available form field types are text box,
drop down list, check box and radio button. The majority of form fields used were text boxes,
27
but check boxes were used for Boolean data, and drop down lists were used where there was a
limited choice of values.
To make the form fields dynamic, the usual HTML for a form field was constructed, and the
value of the field retrieved in the recordset was inserted into the form field in the ‘value’
parameter. Figure 6 shows an example.
<input type="text" name="Address1" value="<%=(rsMembers.Fields.Item("Address1").Value)%>" >
Figure 6– HTML to output the first line of a member’s address into a text box, to allow
modification of the data.
It should be noted that to prevent modification of the primary key ‘Membership Number’
which is an Autonumbe r field, I used plain HTML to just output the number, rather than
inserting it into a text box form field.
As the search for a member by surname may produce more than one result, it is necessary to
add the ability to scroll through records. As the tabl e ‘Member’ contains a large number of
fields, it is preferable to display each result on a separate page. This task can be performed by
using the ‘move to next record’ Server Behaviours in UltraDev. This inserts a hyperlink
‘next’, which when followed, a dvances the record set to the next record (by using the ASP
‘movenext’ command), and displays that record. A ‘while’ loop ensures that the link only
works whilst there are more records to display by checking that the end of the results file has
not been reached. A similar procedure is followed for the ‘move to previous record’ function,
except the loop checks that the beginning of the results file has not been reached.
Once the user has modified that data as required, it needs to be sent back to the data base. To
do this in UltraDev requires each of the form fields to be mapped to the correct field in the
correct attribute in the database. Next, an ‘Update Record’ button was inserted at the bottom
of the form, which is of type ‘Submit’. When this is sel ected by the user a loop that writes an
appropriate SQL ‘update’ statement for each field runs, until all fields are updated and the
loop ends. This could be done in a more straightforward manner if UltraDev was not used –
using just a single SQL ‘update’ statement to update all fields.
A separate page to delete a member was created
– this works on the same principle as
updating members, but when displaying the details of the member to be deleted, the
member’s details are output as plain HTML rather than
as form fields, as the data does not
28
need to be modified. The ‘Submit’ button was labelled ‘Delete Record’ and the loop writes
an SQL ‘delete from’ statement to delete the record.
A further page to insert new members into the database was created. This consists of a form
with appropriate form fields, which has the same layout as the update member details page.
The submit button was labelled ‘Insert Record’ and an SQL ‘insert into’ statement ensures
that the values are entered into the database. Again, the user is not permitted to enter a value
for the primary key
– this field is assigned automatically in Microsoft Access as an
Autonumber.
Many more pages that allowed modification of data in all of the different tables stored in the
database were created in a similar manner to the Member’s details modification functionality
described above. This was necessary to ensure that the system would be easily adaptable to
accommodate future changes in facilities offered or to install the system at a different
sports
club. It is not necessary to describe how each of these pages was created in this report.
Sports booking system
The booking system itself was also constructed using ASP. The first step was to create a page
that allows the user to check availabil ity. The user should be able to select which activity
they want to view bookings for on which date. Screenshots can be viewed in Appendix H.
Drop down lists were created for both of these fields to simplify the process of checking
bookings for the user and eliminate the chance of invalid data being submitted. For the
activities drop down list, the activity names were retrieved from the database and output into
the drop down lists. The value that was assigned to each item was its own activity_id from
the database – this is what is submitted. The VB script ‘date’ commands were used to create
the date drop down list – these commands retrieve the current date from the server, so that the
site does not need modification. In accordance with the user require ments, the dates of the
next seven days were output into the list so that users can only view and make bookings for
the next seven days. To make this element more user friendly, the days were output into the
list as well using the VB script “WeekdayName” commands.
The next step was to create the ‘display bookings’ screen, where this data is to be submitted
to generate the booking timetable. The date and activity_id were declared as variables in the
‘display bookings’ page. An SQL statement was then cr
eated that utilises the submitted
variables. The SQL retrieves all bookings for that specific activity on that specific date, and
29
orders them by time. Next, a table was constructed using a ‘while’ loop to output the times of
the booking slots (eg. 9:00, 9:30 etc) for the opening hours of the club (9am to 11pm).
It was found that outputting the bookings horizontally across the screen provided a clearer
interface for the user than using a vertical table, and simplified the process of outputting
whether or not the slot was booked. ASP code to check if any of the booking times retrieved
from the database matched the slots was created. If there is a match, the text ‘booked’ is
output into the table. The code for dealing with these bookings was not as strai ghtforward as
first thought, as it was difficult to deal with the time slots so numerous modifications had to
be made before it worked satisfactorily.
It was also necessary to allow a user to make a booking. Initially, a form was created, similar
to the ‘check availability’ form, but an additional input field ‘time’ allowed the user to select
the time they wished to book the facility. Their username was retrieved from the current
session and submitted as a hidden form field. Whilst this allowed the use r to make bookings
quite easily, it was decided that it would be better if users could actually make bookings from
the ‘display bookings’ timetable. This would present a graphical interface that could allow
the user to click on one button to make a bookin
g. This functionality was subsequently
incorporated into the ‘display bookings’ screen, and the ‘make bookings’ form was
withdrawn. To add this functionality to the display bookings screen, if there is not a current
booking for a particular time slot, a hidden form is created, with the input fields ‘bookingdate’
and ‘bookingactivity’, into which the date and activity of the timetable being viewed are
inserted. The username is retrieved from the current session, and the time of the booking is
determined by the location in the table. The submit button for this hidden form was labelled
‘Book’ is output into all spaces in the table where there is no current booking. On pressing
any of these ‘Book’ buttons, the hidden form fields are submitted, and the user i s taken to the
‘confirm bookings’ page. This page simply outputs the details of the booking that the user
has selected, and invites them to confirm the booking by clicking on the ‘Confirm’ button.
Doing so executes a SQL insert command, which sends the data to the database.
Function room booking system
The function room booking system was created using the same principles as the sports
booking system. In accordance with the user requirements though, users are only permitted to
view bookings. In addi tion the timetable has been adapted to display whether the room is
booked for the morning, afternoon or evening rather than displaying individual time slots. If
a room is booked ‘booked’ is output into the timetable, otherwise an e
-mail link allows the
30
user to submit a booking request to the administration staff. A form was created to allow
administration staff to book the function room by inputting the date and who the booking is
for, and selecting whether a morning, afternoon or evening slot was require
d. The date is
input manually, as club rules allow the rooms to be booked as far in advance as desired.
5.3 CGI SCRIPTS
Automated password reminder system
The Perl programming language was used to create the CGI scripts, as it does not need to be
compiled on the Web server prior to use. In order to use Perl on the NT platform, it was
necessary to download a Perl interpreter. ActivePerl is a port of core Perl to the windows
platform, the current version – 5.6.1 can be downloaded free of charge from the Web.
Additional Perl modules are available to extend the functionality of the PERL language.
Included with ActivePerl is the Perl Package Manager (PPM), which provides a command
line interface for managing Perl modules and extensions. PPM can be used
remove modules with ease
to install and
– they can be automatically downloaded and installed from
ActiveState’s web site by typing a simple command. The Database Independent Interface
(DBI) module provides a consistent method of accessing databases using the PERL language
no matter what the database type. The DBI module is capable of communicating with such a
wide variety of databases because it does not communicate with the database directly
instead it communicates with the various DBD modules. Diffe
–
rent DBD modules are
available for different databases – for example DBD:Oracle is used to connect to Oracle
databases. The module DBD:ODBC allows connection to any database that can communicate
via the ODBC protocol. Therefore, the DBI and DBD:ODBC modu les were downloaded and
installed using the Perl Package Manager.
Connecting to the database using Perl was a straightforward task. The DSN had already been
registered for the database so that it could be queried using ASP. In the CGI scripts, the
connection to the DSN was opened using the command shown in figure 7.
$dbh = DBI->connect('dbi:ODBC:escweb');
Figure 7 – Perl command used to connect to the database
31
Next, the two user inputs from the HTML file had to be processed
– username and e -mail
address. These we re submitted as two text form fields, named username and email, and
stored as scalar variables (denoted by $) named input_username and input_email respectively.
The database could then be queried to retrieve the member’s password, providing that they
had submitted the correct username and e -mail address for their account. The password is
retrieved and then stored as a variable. The SQL statement in figure 8 was used to retrieve
the password. If the wrong details were submitted, an error message is produced, and the user
is invited to resubmit their details.
$sth = $dbh->prepare(qq{
SELECT password FROM member
WHERE email LIKE '$input_email' AND username LIKE
'$input_username'});
Figure 8 – Query used to retrieve the forgotten password
The Net::SMTP module allows a Perl application to communicate with SMTP (Simple Mail
Transfer Protocol) servers, and can therefore be used to send e -mail. The e -mail address that
the user submitted, which is stored as a variable was inserted into the ‘To:’ field of the
message, and an SMTP server was specified to send the message. The password was
included in the body of the message. The message is sent instantly, as soon as the Perl script
has executed. The code for sending the e -mail is quite straightforward and so is included in
figure 9.
use Net::SMTP;
$smtp = Net::SMTP->new('smtp.ellesmeresports.net');
$smtp->mail( 'admin@ellesmeresports.co.uk' );
$smtp->to($input_email);
$smtp->data();
# connect to the SMTP server
# sender's address
# recipient's address
# start of the email
$smtp->datasend("To: Ellesmere Sports Club Member\n");
# header information
$smtp->datasend("From: Ellesmere Sports Administration\n \n"); # header information
$smtp->datasend("Dear member, \n your password is $password");
$smtp->dataend();
# denotes the end of the message
$smtp->quit;
# closes the SMTP connection
Figure 9 – Perl code to send password reminder e-mail - # denotes comments
32
Secure Sockets Layer (SSL) credit card payment feature
The first step in implementing this feature is to create a secure form into which the user enters
their payment details. This entails creating a standard HTM
L form with appropriate input
fields and placing it in a secure area on the server. When submitted, the form should post the
users information to the CGIript (which must also be located in the secure area) that will then
perform the desired action of storing the details in a text file, and e-mailing the administration
staff to alert them of a new payment instruction.
Sending the credit card details to the CGI script is performed in the same manner as
submitting user details in the password reminder syste m, except the details are posted to the
secure area, which has the prefix ‘https://’ rather than ‘http://’. Basic input validation was
constructed using simple ‘if’ statements to determine if the credit card number that was
submitted contained any invalid characters or was the wrong length (Visa cards are 13 or 16
digits and MasterCard cards are 16 digits). If any invalid characters were present, or the
number was the wrong length, an error message is output the user’s browser, and they are
invited to res ubmit their details. It is not necessary to check if the credit card number is
genuine, as this will be done by the acquiring bank when the club administration staff pass on
the details, as discussed in the deployment chapter. CGI scripts that can determ ine whether
credit card numbers are genuine are available free of charge though, so if the club received a
lot of false credit card details it would be possible to include one of these scripts.
Finally, when the details have been sent to the text file, th e automatic notification e -mail is
sent to the administrative staff in a similar manner to the password reminder script, the only
differences being the address admin@ellesmeresports.co.uk is inserted in t he ‘To:’ field, and
the body of the message contains the text ‘New payment instruction received. Please check
secure text file to retrieve details’.
33
Chapter 6 - Testing
Two types of testing were performed on the system
- software testing and u ser acceptance
testing. Successful completion of both tests is required to determine if the system performs
satisfactorily, and if not, what changes need to be made.
The software testing should be performed first, before demonstration to the user and
subsequent user acceptance testing. This ensures that the system functions as the developer
intended, so that the user can assess whether or not the system meets their needs without
being concerned with bugs in the software.
6.1 SOFTWARE TESTING
Software testing involves checking every aspect of the system to ensure that no problems
occur during its use, even if the system is not being used in the correct manner. Invalid data
should be input to ensure that input validation works correctly, and an error
message is
displayed rather than the data being sent to the database. It is important to ensure that the
system outputs correct data and does not crash. The system was tested as it was developed,
but it was thought that it would be beneficial to test the whole system again.
The requirements table in section 3.2 of the analysis chapter was used as the basis for
performing the software testing on each element. In addition, further more general tests were
added. The outcome of each test is shown in the ta
ble in figure 10. As there are so many
items to test, the results table simply indicates whether the item tested was successful or not,
rather than showing the result of performing the test. For each item that was tested, various
invalid and incomplete d ata was input to ensure that incorrect data could not be entered into
the database. Items that were initially not passed successfully are discussed below figure 10.
34
Successful?
General
Displays correctly in browser
User can login
Each function available only to correct categories of user
Rectified?
(See 1)
Facilities
Display available facilities to book
Create a new facility
Amend facility details
Delete a facility
Membership types
Display membership types available
Display annual subscription charge for each type
Create new membership type
Modify existing membership type
Delete a membership type
Members
Display details of any member
Create a new member
Modify member details
Delete a member
Bookings
Display own bookings
Display bookings for each activity
Display bookings by user
Create a booking
Create a booking on a member’s behalf
Apply to book a function room
Book a function room
Delete a booking
Delete a booking on a member’s behalf
Financial
Display members who have not paid their subscription fees
Mark a bill as paid
Create a bill
(See 2)
Figure 10 – Software testing plan and results
1 – Access levels set incorrectly for numerous pages. Was corrected to ensure only authorised
users could view relevant pages.
2 – ASP form did not update database field because dynamic form field (check box) to select
whether or not the user ha s paid was not assigned to update the field in the database.
Rectified by assigning the check box to the ‘paid’ field.
35
6.2 USER ACCEPTANCE TESTING
User acceptance testing is equally as important as software testing – software that is error free
but does not meet with user acceptance is of no use. The main users of the system will be
members and staff at the club, so feedback should be obtained from each group. Full user
acceptance testing was not yet possible because of the limited timescale of the p roject, but a
member of staff and selected members were invited to use the system briefly and offer
comments. Comments received during testing are included in appendix G.
36
Chapter 7 - Deployment
7.1 INTRODUCTION
The club requested that an appropriat e domain name be bought to allow easy access to the
new web site and booking system. The name www.ellesmeresports.co.uk was subsequently
registered.
An NT based hosting plan running IIS is required to p
rocess the ASP pages and store the
Microsoft Access database. IIS is also capable of processing the Perl CGI scripts. The site
will be hosted by Verio UK, because although they are not the cheapest of Internet Service
providers (ISPs), they offer compreh ensive customer support, which is essential, as the club
have no specific computer support staff. Their cheapest plan, at £24.95 per month was
chosen. This provides 100Mb of storage space, far in excess of the 5Mb that the system
requires. A data transfer limit of 6.4Gb per month should prove more than adequate – as each
visitor to the site is likely to access about 200Kb of HTML and ASP files, if they are only
logging on to make a booking. The database, which takes up most of the storage space, is not
transferred when data is accessed. Based on 200Kb access per user, this would allow all 1000
members of the club to access the site 32 times per month. If the 6.4Gb data transfer limit is
exceeded, additional transfer is allowed at a small charge to the club on a per gigabyte basis.
7.2 DEPLOYMENT OF DATABASE
To deploy the database and make it accessible through the web interface, it was first
necessary to set up a new Data Source Name (DSN) and register an ODBC driver on the
server. These tasks were c
ompleted on my own computer when the system was being
constructed, by using the administrative tools in the control panel of Windows NT. To do this
on the ISP’s server required a request to be sent to the ISP, asking them to create a new DSN
of type Microsoft Access, to be given the same name as used when constructing the system –
‘escweb’.
Once the DSN was set up, I was able to upload the database file using FTP to the ‘/data’
directory on the web server. The database had to be placed in this directory in order to allow
the web pages to write data into the database as well as reading data from it.
37
If the club were to recruit a large number of new members, or if the system were deployed at
a larger sports club, the database could be substituted for a mor
e powerful DBMS, such as
Microsoft SQL Server 7.0 by changing the ODBC driver. The ISP hosting costs would
increase, though.
7.2 DEPLOYMENT OF CGI SCRIPTS
The hosting plan allows execution of CGI scripts. The CGI files must be placed in the ‘/cgi local’ directory to be executed. The files were sent using FTP, but had to be sent in ASCII
transfer mode to ensure that they worked correctly. In addition, the ISP states that the code
#!/usr/local/bin/perl must be placed at the top of each script.
Deployment of CGI password reminder script
The password reminder script, which functioned perfectly on my system, would not work
when transferred to the ISP server. It was found that the ISP did not have the Perl DBI
module installed, so the script was unable to query the database. I requested that the module
be installed, but as yet the module has not been made available. If the module were installed,
a simple modification the database connection string to include the username for the ISP
account (as was also required for the ASP pages) would be all that is required for the script to
work remotely.
Deployment of CGI credit card payment scripts
The text file, which is to store the submitted credit card numbers, must be placed in a
password protected direc tory on the server to prevent unauthorised access. In addition, the
ISP states that every site that wishes to use SSL has to obtain an authentication certificate,
which are given out by independent organisations like Verisign and Thawte, with prices
starting at around £75 per year.
The processing of the credit card details which are sent to the text file requires a merchant
account from an accredited financial institution (normally a bank). The club has such an
account, and so would simply have to tele phone the bank with the credit card numbers and
amount of money to be debited from each card. Credit card companies are soon to release
38
software (such as ‘Verified by Visa’), which will allow small to medium sized organisations
to carry out transactions i nstantly and automatically when the user submits their credit card
details. The software will be released as a plug -in and could easily be added to the site when
it becomes available. The credit card payment feature has not yet been deployed, as the SSL
certificate has not been purchased.
7.3 DEPLOYMENT OF WEB INTERFACE
To allow the active server pages to access the database whilst on the server, it was assumed
that no modification would be required to the ASP files, as the DSN was given the same
name. This assumption proved to be incorrect – the connection string has to be modified by
prefixing the username for the ISP account (ellesm) to the DSN. The connection string used
is shown in figure 11.
<% "dsn=ellesm.escweb;" %>
Figure 11 – string used to connect to the database when located on the server
The HTML and ASP files were sent using FTP into the ‘/wwwroot’ directory of the web
server, to make them viewable to users. If a user types the address
‘http://www.ellesmeresports.co.uk’ into their browser, the home page, ‘default.asp’ would be
displayed.
After the site had been comprehensively tested, it was moved to a password
-protected
subdirectory to prevent anybody from accessing it before its official launch. The club intends
to write to all
of its members to inform them about the new system, when the annual
subscription renewal notices are sent out in October. Each member will be given their
username and password at this stage. All members of staff will have had sufficient practice at
using the system by this before its launch, and certain aesthetic improvements, which are
detailed in the Evaluation chapter, will be carried out to the interface.
39
Chapter 8 - Evaluation
Whether or not a system is a success depends on the criteria used to
evaluate it. Block[ 8]
provides a comprehensive definition of a successful system - “a successful system is one that
is developed on time and within budget; is reliable and maintainable; meets its goals and
specified requirements and satisfies the users”. These criteria allow a system to be evaluated
in broader terms than just performance of the software, and so will be used to evaluate the
project.
Time and budget
The system was completed on time, and whilst there was no specific budget for its
development (as it was developed free of charge), the club did specify that the running costs
of the system must be kept to a minimum. This was taken into consideration from the outset
– the current running costs of the system are £300 per annum, which is the ISP
hosting
charge. Whilst cheaper hosting plans are available, I felt that it was necessary to opt for an
ISP that provides a good level of customer support because there are no specific computer
support staff at the club. Choosing an ISP that did not prov
ide adequate customer support
could adversely affect the reliability of the system, as staff would not be able to rectify any
problems as quickly and easily.
Reliability
The second set of criteria defined by Block is that the system should be reliable. The system
underwent thorough testing during the testing phase, and any bugs that were discovered were
rectified. The system passes all of the specified tests and operates entirely as expected.
However, it was unfeasible for me to test the system with a large number of connected users.
Microsoft Access can support up to 50 simultaneous users. In the analysis phase, it was
calculated that this should be more than sufficient for a club of 1000 members, as each user
will only access the database for a few s
econds in order to check availability or make
bookings. It is possible that more than 50 users could try to access the database at one time
though, in which case some users would be unable to retrieve bookings data or add a booking,
but they would simply have to wait a few seconds and try again – no erroneous data would be
40
entered into the database. It was accepted that the extra maintainability that Access gives the
staff outweighs the small probability of too many users being connected, and the
consequence, which is only a minor inconvenience to users. Whether or not this assumption
is correct should become clearer after the official launch of the system. Substituting it for a
different database would simply involve changing the database driver - if all of the tables and
attributes in the database were given the same names, no further modification of any other
part of the system should be necessary.
Maintainability
Being able to maintain the system, to add, modify and delete facilities, member details
, and
prices is a key requirement for the club. This can be done using the online HTML and ASP
forms. The system has been designed to be dynamic so that any changes made using these
forms updates the web site interface automatically, without any modifications being needed to
the HTML or ASP code, or changes being made to the database. In addition, the provision of
an automated password reminder system for members means that they can retrieve their own
password if they forget it, reducing the staff burden of maintaining member details. However,
the booking system itself is not quite as flexible as it could be
- it was designed to meet the
requirements of the club, by providing half hour time slots for bookings. Other sports clubs
may have different requirements for time slots – unfortunately, there was not time to simplify
the process of maintaining booking slots, and so if any changes were required, it would be
necessary to modify the ASP code slightly. The same applies for the modification of opening
hours.
Specified requirements
The first step is to evaluate the system against the objectives and minimum requirements that
were defined at the end of section 3.2.
1) Members can check availability of sports facilities and make bookings without the
need to visit the club, if they are prepared to use the online system.
2) Members can check availability of sports facilities and make bookings without the
need to contact staff, if they are prepared to use the online system.
3) Members who do not wish to use the system may still book facilities by visiting or
telephoning the club.
41
4) Enquiries about function room hire can be made without visiting the club, and
availability can be checked by visitors and members alike.
5) The system could be deployed at a low cost
– it simply requires a small monthly
payment to an ISP that runs IIS.
The minimum requirements have therefore been met. In addition, a great deal of extra
functionality has been added. All of the extra features detailed below have been
implemented:
1) Online membership application form – allows visitors to the site who wish to join the
club to do so quickly and easily. The process has been automated as much as club
rules will allow.
2) Provision of online forms allows instant modification of facilities, membership price s
and member details without manually entering data into the database.
3) System has been designed to be dynamic so that any changes made using the forms
updates the web site interface automatically without need for modification of HTML
code.
4) Annual subscrip tion bills and reminders can be automatically generated from the
database, saving staff time and effort.
5) An automated password reminder system was implemented to reduce the burden on
staff, and make the system as convenient as possible for members.
6) A credi t card payment system was implemented to make the system even more
useful, and save time and money for the club.
User satisfaction
Feedback from staff and users in the testing phase reinforced the fact that for users who are
familiar with the Web, using the online system presents an easy and convenient method of
booking facilities at the sports club.
During the testing phase, users commented that although the system provided a clear and
straightforward interface, the lack of graphics and bright colours m
ade the interface look
uninteresting. Ideally, club staff and members would like promotional material about the club
and an attractive site to try to entice more people into joining the club. It was agreed that at a
later date, images and promotional material would be added.
42
Potential improvements
Apart from adding more graphics to the web site, it would be desirable to incorporate the
ability to book more than one time slot, or make repeat bookings, and preferably provide a
simple method of altering th e booking slot length without having to modify the HTML and
ASP code.
Conclusion
It is clear that by Block’s criteria, the implementation of the system has been a success, as the
user requirements have been met and exceeded, and feedback was positive
from staff and
members alike. However, whether or not the system can be defined as a success in terms of
being used by a large proportion of members on a regular basis will not be evident until after
its official launch.
43
Appendices
APPENDIX A – REFLECTION ON PROJECT PROCESS
Initially, I was apprehensive about the size and scale of the project as it was larger and more
important than any other single piece of work completed during my academic career to date.
After performing the analysis and research,
however, the apprehension turned into
enthusiasm, as I felt that the system would deliver real benefits to the target organisation, and
I felt that it I could deliver a system that would be truly successful. Outlining the schedule
and appropriate milestones helped to boost my enthusiasm and confidence, and made the task
seem less daunting.
The enthusiasm turned to despair at many points during the project, when problems were
encountered with software that took a great amount of time to fix so that it func
tioned as
intended. Also, as I learnt more about the scripting languages throughout the entire project, I
was inclined to go back to parts of the software that I had previously completed in order to
add new functionality, or make certain sections work mor e efficiently, which slowed down
the process of writing this report.
The project changed direction somewhat from the original plan, which was just to create a
booking system. The inclusion of automatic annual bill generation and credit card payment
facilities has meant that the system would perhaps be better described as a sports club
management system instead. While the extra features help deliver a better product without
compromising the generic nature of the system, I would advise students doing similar projects
in the future to be careful not to get carried away with adding extra features unless they are
absolutely necessary, as it can take more time to do than expected.
The original schedule proved to be quite realistic, however a lot of time was de
voted to
adding the extra enhancements to the system over the Easter vacation, as I did not anticipate
that it would take so long.
I would perhaps not recommend the use of end user development tools such as Dreamweaver
UltraDev 4 to future students undert aking similar projects. Whilst it sped up the development
of more repetitive aspects of the project, it was difficult and time consuming to learn, and as
the resulting code had to be modified, it is questionable whether time was saved by using it.
I would advise future students to undertake a project that they feel that they can be
enthusiastic about, and to seek to create the best possible solution for, taking care not to
neglect the project write up. I feel that I have learnt many new skills throughout the project
process, including management of the process, and I feel that it has been an invaluable
experience.
44
APPENDIX B – GANTT CHARTS
45
46
APPENDIX C – REQUIREMENTS INTERVIEWS
Interview I – Alan Pearson, Administration staff
1) How are bookings taken for sports facilities at present, and what are the problems
associated with the current systems?
Bookings for tennis and squash are taken by the member signing a list. There are no formal
booking procedures for the bowling green – details of when the g reen is booked for fixtures
are placed on the notice board. The main problem is that the member has to come to the club
in order to make a booking or check availability. If a member finds that he or she is unable to
attend at the time they have booked, th ey rarely come back to the club in order to cancel the
booking. Members also occasionally forget when they have made a booking for, and so fail
to turn up. Club staff must put out new lists every week (sports can only be booked 7 days in
advance), and occasionally receive instructions over the phone to book facilities.
Booking lists are set out in time slots of 30 minutes – a member can book an activity for 30
minutes, but may book more than one consecutive slot if they wish to use the facility for
longer.
The club is looking to expand its facilities – we may add new sports activities and we are
considering making a smaller function room available for hire. The booking system must be
adaptable so that new sports or rooms can be added easily.
2) How are bookings taken for function room hire at present, and what are the problems
associated with the current system?
Function room hire is available to both members and non -members. Enquiries for function
room hire can currently only take place when the mai n club house is open. Most of these
enquiries currently take place over the phone, which is inconvenient for staff if the club house
is busy. Typically, the function room is booked for evening functions, but it is occasionally
booked for conferences in t he morning or afternoon. After pricing and details have been
agreed, a booking form is filled out in duplicate. Staff record the bookings in a paper diary.
It would be useful to have information about the function rooms online, and the ability to
check availability and request to book a room, as this would be more convenient for staff and
customers.
3) Would it be acceptable for members of staff to take bookings on behalf of people who are
not computer literate or do not have Internet access?
Yes, as the staff will no longer have to put out and check lists for sports activities, and will
receive fewer telephone enquiries, it will be acceptable for staff to carry out this task.
4) Are there any additional features that you think would be useful to include along with the
automated booking system?
Members are charged an annual subscription fee, the amount depending on their membership
type. I have created a spreadsheet in Microsoft Excel which stores a list of all members and
their details, so that the “mail-merge” feature of Microsoft Office can be used to generate
47
annual subscription renewal notices (bills) to be sent to members. It would be useful if the
generation of the renewal notices could be integrated into the new system.
Interview II – Leaders of sports sections: Tony Fare, Pat Hague, John Luke, Ian Nutter
Leaders were briefed on the proposed new system.
1) Are there any additional features that you think would be useful to include in the new
system?
Tony Fare suggested that it would be useful to have promotional information about the club
on the web site to attempt to increase the number of members.
48
APPENDIX D – DATABASE STRUCTURE
Member table
Attribute
Membership_Number
Title
Surname
Firstname
Address1
Address2
Address3
Postcode
Telephone
Email
Dateofbirth
Category
Discount
Total_fee
Paid
Username
Password
Accesslevel
Data type
Autonumber
Text
Text
Text
Text
Text
Text
Text
Text
Text
Date
Text
Number
Number
Boolean
Text
Text
Text
Member_type table
Attribute
Category
Fee
Data type
Text
Number
Description
Primary key
Facility table
Attribute
Activity_id
Name
Data type
Autonumber
Text
Description
Primary key
Booking table
Attribute
Booking_date
Start
Activity_id
Booking_id
Name
Data type
Date/Time
Date/Time
Number
Autonumber
Text
Description
Primary key
Primary key
Primary key. Foreign key for facility table
Primary key
Description
Primary key
Foreign key to member_type table
49
APPENDIX E – SAMPLE ANNUAL SUBSCRIPTION BILL
Ellesmere Sports Club
Off Walkden Road Worsley Manchester M28 2RZ
Telephone 0161 790 2376 e-mail mail@ellesmeresports.co.uk
Membership renewal
[title] [firstname] [surname]
[address1]
[address2]
[address3]
[postcode]
Date:
Dear [title] [firstname]
Your subscription for the year commencing 1 October 2002 is now due. Details
of your existing membership and the new subscription are as follows:
Membership number: [membership_number]
[category]
[fee]
If you want to change your type of membership, tick one of the following
boxes:
Senior playing
[fee] (over 18 & ceasing to be in full time education)
Over 60
[fee] (over 60 & ceasing to be in full time employment)
Social only
[fee] (over 18 & ceasing to be in full time
education & no longer playing)
(If either box is ticked a new membership demand will be automatically issued)
Yours sincerely
NB Continued use of club facilities requires payment of the proper
subscription by 30 October 2002. Failure to pay will result in your
membership card being invalidated.
50
APPENDIX F – SAMPLE MEMBERSHIP FORM
Ellesmere Sports Club
Off Walkden Road Worsley Manchester M28 2RZ
Telephone 0161 790 2376 e-mail mail@ellesmeresports.co.uk
Membership application
WELCOME !
Your membership application to the Ellesmere Sports Club has been successful.
We have recorded your details as follows:
[Title] [First name] [Surname]
[Address1]
[Address2]
[Address3]
[Postcode]
[Phonenumber]
[Email]
Your membership number is: [Membership_number]
Your username is:
[username]
Your password is:
[password]
The fee payable is:
[total_fee]
I have read and accept the terms of membership
Signed:
Date:
51
APPENDIX G – USER ACCEPTANCE TESTING
Staff – Alan Pearson, administrative staff
Interface
Alan commented that the site presented a clear and simple interface, but it did look rather
basic, with a minimal amount of graphics. The
intention of the project was to create a
working system, which was easy to use, and as generic as possible. For these reasons and due
to lack of time available to deal with the less important issues, images of the club were not
included. It would be easy to add images to the HTML documents at a later date, though.
Adding, modifying, and deleting members, facilities, membership types, and notices
Alan found that all of these tasks could be performed with ease, as they all had a similar
interface. He did comment that it was perhaps too easy to delete items, and perhaps a
confirmation dialogue could ensure that the user really wishes to delete an item. This is
perhaps something that could be implemented at a later date.
Making and cancelling bookings
Alan found that the booking element of the system was easy to use and a considerable
improvement over the current manual system.
Producing annual subscription bills
Being familiar with Microsoft Word, Alan found that having the ability to quickly and eas ily
generate annual bills was an invaluable feature of the system.
Automated e-mail password reminder system
Alan again observed that this was very easy to use, and a very important feature, as people
have many different passwords for different online se rvices, which they often forget. If this
feature were not present, they would have to ask staff to retrieve their password, which would
place an unnecessary burden on them.
52
Display members who have not paid their bill
Alan stated that it is essential to have the ability to automatically generate reminder notices to
those members who have not paid. This feature was subsequently implemented.
Members
A number of members were invited to try the new system. The number of functions that can
be performed b y members in the system is considerably less than can be accessed as a
member of staff. All of the people who tried the system were familiar with using the Web,
and so had no problems logging in and making bookings. The only criticisms were about the
lack of graphics in the interface.
53
APPENDIX H – SCREEN SHOTS
54
APPENDIX I – USER GUIDE FOR ADMINISTRATION STAFF
User guide for online system
1) Open Internet Explorer browser and type the address http://www.ellesmeresports.co.uk into
the address line and press return.
2) Type in your username and password and click on submit.
3) You are now able to access the administration section of the system by clicking on the link
at the top of the page.
Modifying member details, facilities and membership types
Member details, facilities, membership types and prices can be added, modified or deleted
using the forms provided. Simply follow the links in the administration section.
Deleting old bookings
Old bookings should be deleted on a weekly basis if no longer required. To do this, simply
click on the ‘delete old bookings’ link.
Booking sports facilities on behalf of members
Be sure to use the booking form provided in the administration section so that details of who
the booking is for can be recorded.
Booking function rooms
Use the form provided in the administration section. If more than one slot is required (eg
afternoon and evening), the form must be filled out for each slot that is required.
55
APPENDIX J – REFERENCES AND BIBLIOGRAPHY
References
1
Pearse, Adam, (2001), An Automated Sports Centre Booking System, University of Leeds.
2
Unknown, (1999), RDBMS FAQ, URL: http://www.baek.com.hk/baek/dataroom/rdbms.htm, [22nd
Nov 2001].
3
Elmasri R and Navathe S, (2000), Fundamentals of Database Systems, Third Edition, Addison-
Wesley, p17.
4
West R and Muck T, (2001), Dreamweaver Ultradev4 – A beginner’s guide, McGraw-Hill.
5
Unknown, (2002), NUA Internet statistics, URL: http://www.nua.ie, [20th March 2002]
6
Source: Yell.com Business listings, 2001, URL: http://www.yell.com/business, [7th Nov 2001].
7
Roberts, Stuart, (2000), DB21 Databse Principles and PrcaticeCourse Notes, University of Leeds
8
Block, R, (1983), The Politics of Projects, Yourdon Press.
Bibliography
•
Atzeni, Paraboschi and Torlone, (1999), Database Systems, McGraw Hill
•
Barron, David W, (2000), The world of scripting languages, Chichester Wiley
•
Curtis, G, (1995), Business Information Systems – Analysis, Design and Practice,
Addison-Wesley
•
Gough, Tom, (2001), Notes on People-Centred Information Systems Development,
University of Leeds
•
Ince, Darrel, (2002), Developing Distributed and E-commerce Applications, Addison
Wesley
•
Mason, D and Willcocks, L, (1994), Systems analysis, systems design, Waller
•
Matravers, J (1999), SI13 Introduction to Human Computer Interaction, University of
Leeds
•
Mills, Richard and Santoro, Denise, (2001), ASP, ADO and XML complete, Sybex
•
Mills, Richard, (2000), Perl, CGI and Javascript complete, first edition, Sybex
•
Mott, P and Roberts, S, (1999), DB11 Introduction to Databases Modules Notes,
University of Leeds
•
Reynolds, Matthew, (2000), Beginning E-commerce applications with Visual Basic,
ASP, SQL server 7.0 and MTS, Wrox Press
56