Professional Documents
Culture Documents
of
a Cricket Progress File
Yousuf Al Hussaini
MSc. Information Systems
(2001/2002)
The candidate confirms that the work submitted is his own and the appropriate credit has been given where
reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be considered as
plagiarism.
Summary
This project is intended to help the Bradford/Leeds Centre for Cricketing Excellence introduce
student progress files in which student cricketers will record their development in various skill
areas, including technical, tactical, physical and mental skills as well as lifestyle development.
An iterative evolutionary prototype has been developed consisting of a database and a web front-
end to enable the students to use it to log their skills development. The coach, in turn, will also be
able to use the prototype to monitor the performance progress of his students (players) textually;
statistically and graphically, record his comments, and obtain players feedback through the use of
the electronic questionnaires provided by the prototype. The prototype should also enable the
players to reflect, to their academic tutor, on how their cricketing progress has contributed to their
academic achievement.
The reader should note that this report documents the iterative developments of the prototype where
there is no clear cut between development stages (or phases). In other words, part of the
requirements could be captured in middle or late stages and may not be necessary in initial stages
such as requirement analysis stage. He should also note that, throughout the report, the words
“system”, “application” and “prototype” are used interchangeably to reference the same
product/artifact.
i
Acknowledgement
- My supervisors, Mr. Peter Mott and Dr. Julika Matravers for their full support, advice,
guidance and finding the time to see me.
- Dr. Lydia Lau for her interim report feedback and her valuable advices in the early
stages of this project, which helped me start it off.
- My client members, Peter Rees Jones, Kevin Sharp, Clive Souter, Andy Siddall and
Andy Walker for their time and support, and their interest, that without them it wouldn’t
be possible to accomplish this project.
- My family members and my friends, here and back home, for their continues
encouragement, prayers and wishes during the entire MSc. Course.
For all of these, I would say: many thanks and bless you.
ii
Contents
Chapter 1: Introduction 1
1.1 Background 1
1.2 Objectives 1
1.3 Minimum Requirements 2
1.4 Deliverables 2
1.5 Deployment 2
1.6 Development Approach 2
1.7 Project Schedule 4
1.8 Literature Review of Tools/Techniques 5
1.8.1 System Architecture 5
1.8.2 Active Server Pages (ASP) 6
1.8.3 SQL Server 8
Chapter 2: Requirement Capture 10
2.1 What is a Progress File 10
2.2 The Cricket Progress File (CPF) 10
2.3 Information Gathering 11
2.4 System Requirements 11
2.4.1 The Current CPF System 13
2.4.2 The Proposed CPF System 13
Chapter 3: Requirement Analysis 15
3.1 The Detailed Use Case Diagram of the CPF 15
3.2 Use Case Description 16
3.3 Modeling the Interaction 17
3.4 Modeling System Functionalities 19
Chapter 4: Prototype Design 21
4.1 Moving from Analysis to Design 21
4.2 Mapping Classes into ASP/HTML Files and SQL Server Database Tables 21
4.3 Software Architecture of the CPF Prototype 23
4.4 Database Design 24
4.4.1 The E-R Model-Overall View 24
4.4.2 Normalization 25
4.4.3 The E-R Model-Detailed View 25
4.4.4 The Relational Model 28
4.5 User Interface Design 29
4.5.1 Web Design 29
Chapter 5: Prototype Implementation 31
5.1 Database Creation 31
5.2 Website Construction 31
5.2.1 Controlling Appearance and Access 32
5.2.2 Signing-in to the CPF 32
5.2.3 System Administration 33
5.2.4 Scoring against Cricketing Skills 34
5.2.5 Commenting on Player’s Performance 35
5.2.6 Monitoring Progress 36
5.2.7 Managing Questionnaires 39
5.3 User Input Validation 43
iii
Chapter 6: Evaluation 44
6.1 Meeting the Objectives 44
6.2 Meeting the Requirements 45
6.3 User Acceptance Test 47
6.4 Suggestions for Further Improvement 48
Chapter 7: Conclusion 49
References 51
Appendix A: Reflection upon the Project Experience 52
Appendix B: Objectives, Deliverables and Agreed Marking Scheme 53
Appendix C: A Copy of the Interim Report Header Sheet 54
Appendix D: Requirement Specifications Report 56
Appendix E: Information Gathering Samples 70
Appendix F: Code Segment Samples 78
Appendix G: User’s Feedback and the Outcome of the Acceptance Test 85
Appendix H: CPF Installation Guide 89
iv
Web Development of a Cricket Progress File 1/89
Chapter 1: Introduction
This chapter gives a brief introduction to the problem, the objectives, the suggested solution and a
literature review of the associated technology. It also describes the overall structure of this report
and the approach used to carry out the project.
1.1 Background
At present, the centre does not have a standard way of monitoring cricket progress files of the
players. The coach keeps his own set of paper files to log the development of players’ skills and
monitor their achievements. Recently, the centre has decided to adopt a better way of keeping the
cricket progress files. The plan is to create a standard file and join up all separate records into this
file. The planned cricket progress file is to be maintained by the players themselves (not the coach)
and to be made available to the coach electronically through the Internet. The key objective of this
project is to develop a software prototype as a first step (iteration) to form the basis of an iterative
development of a cricket progress file.
1.2 Objectives
• To provide a working prototype that would help in creating a standard cricket progress file.
1.4 Deliverables
1.5 Deployment
The system will be deployed under Microsoft Windows NT/2000 platform that supports Microsoft
SQL Server and Microsoft Active Server Pages. There is no specific reason to develop it and deploy
it under Microsoft environment. However, prototyping under Microsoft environment can be done
faster and easier, saving the time and the effort of coding, because of the powerful development
tools provided by Microsoft. More general reasons like the ones listed in [11] do also apply to the
development of the prototype. The client is to decide whether to find a sponsor who would host the
system, or to go for a commercial Internet Support Provider. The later is recommended; as most of
the commercial hosts provide range of services such as email accounts, email forwarding, files
uploading, etc. The monthly charge of a commercial hosting ranges from £30 to £50. However, the
prototype has been developed using the School of Computing web/database server on CSMS2
machine. The prototype can be accessed through http://csiis.leeds.ac.uk/msczyka/cpf provided that
login information is issued.
The object oriented method will be adopted for analysis and conceptual design of the Cricket
Progress File system. Unified Modeling Language (UML) will be used to model the development
system components. After system components are identified, they will be mapped into a form that
can be implemented under the development environment. Design of the database will involve the
Web Development of a Cricket Progress File 3/89
Object oriented analysis and design has been preferred over the structured methods for the
following reasons:
• It provides an abstract view of the system and hence shows the big picture of the
requirement specifications;
• It is, unlike the structured methods, provides an organic structure of the system. That is both
data and processes are coupled together in the same unit (or class). Therefore, it enables the
designer to discover system operations without the need for a separate process modeling;
• It is a good candidate for the development of a Three-tier architecture system. System
components in object oriented can be distributed into the different layers of the system
architecture quite easily;
• It minimizes the cost of maintenance and of future development; as the conceptual system
components can be re-used.
Furthermore, UML has been chosen to model system components because it is the standard
modeling language, for object oriented systems, adopted by the Object Management Group (OMG).
This has been stated by [6] and [7].
The basic concept of the System Development Life Cycle will be used as a framework for every
iteration of the prototype. Two to three iterations of the life cycle will be performed and their
outcome will be checked against user requirements. Figure 1.1 illustrates the iterative life cycle
approach.
Web Development of a Cricket Progress File 4/89
Requirement
Analysis
Requirement
Specifications
Prototype
Design
Next Iteration
Prototype
Implementation
Test &
Evaluation
Project schedule has been revised and adjusted from the original schedule given in the interim
report. It was quite difficult to follow the original schedule as I had to base the new schedule on the
client availability. The tasks have been accomplished as per Table 1.1 below. Every iteration of the
prototype includes the life cycle processes shown in Figure 1.1. The report has been re-visited and
modified to accommodate the modifications in the prototype as suggested by the client.
Web Development of a Cricket Progress File 5/89
In this section, an overview of software and hardware requirements is represented. The tools and/or
techniques discussed below are based on the requirement specifications of the prototype. Please see
appendix D (Requirement Specifications Report) for details.
The software system to be delivered is of Three-tier Architecture type. This architecture is used for
many Internet technology database applications. Three types of processors or tiers are shown in
Figure 1.2. From right to left, they are the database server, the web server, and the browser or client
computers. Each of the three tiers can run under a different operating system/platform. In the
Cricket Progress File application, the database server and the web server both run under Windows
Web Development of a Cricket Progress File 6/89
2000 server, and the browsers can run heterogeneous PC operating systems. The application is
independent of the browser operating system.
The software products shown underneath each tier of Figure 1.2 are Microsoft SQL Server on the
database server, Microsoft Internet Information Server (IIS) on the web server, and any kind of
browser on the clients, e.g. Netscape Navigator 4.0+ or Microsoft Internet Explorer 5.0+.
The interface between the web server and the database server transmits SQL statements and
relational data. The interface between the web server and the browser transmits web pages and
client code (HTTP requests). The purpose of the database server is to run the Database Management
System (DBMS) to process SQL statements and perform database management tasks. It is a pure
data engine; receiving SQL requests and processing table rows. [1]
Browser HTTP
Requests
Web SQL
Server Requests
Database
Browser Server
Browser
As shown in Figure 1.2, the web server will always be IIS since it is part of Windows 2000
operating system. IIS, as described by [1], provides an interface called Internet Server Application
Program Interface (ISAPI) by which other programs can trap and process HTTP messages. The
Active Server Pages (ASP) is one such program. It processes all web pages with the suffix .asp.
Web Development of a Cricket Progress File 7/89
When IIS receives such a page, it sends it to ASP over the ISAPI interface. ASP then processes the
page and sends a response back to the client via the ISAPI interface to IIS.
ASP is defined by [2] as follows: “ASP (Active Server Pages) is a technology developed by
Microsoft. Pages using ASP are primarily developed in JavaScript, VBScript , or PerlScript and are
integrated into the HTML of your Web pages. The ASP code is compiled on-the-fly by the server
and the resulting output is standard HTML. By using ASP, Web pages can be dynamic, full of ever-
changing content, and browser independent”.
Besides generating dynamic HTML pages, ASP can be integrated with Microsoft Component
Object Model (COM) objects to access databases or to call another COM object that is written in
C++, Visual Basic or Java. The COM object used to access databases is called ActiveX Data Object
(ADO). Figure 1.3 shows the way that ASP accesses databases and generates dynamic HTML
pages.
DB Storage
ASP, as described by [2], includes five standard objects for global use, which are:
- Request: to get information from the user, normally through HTML forms.
- Response: to send information to the user.
- Server: to control the Internet Information Server.
- Session: to store the information and the settings of the user's current Web-server session.
Web Development of a Cricket Progress File 8/89
- Application: to share application-level information and control settings for the lifetime of
the application.
SQL Server is a relational database management system (RDBMS). A database typically has two
main parts: first, the files holding the physical database and second, the database management
system (DBMS) software that applications use to access data. The DBMS is responsible for
enforcing the database structure, including:
• Maintaining relationships between data in the database.
• Ensuring that data is stored correctly, and that the rules defining data relationships are not
violated.
• Recovering all data to a point of known consistency in case of system failures.
The data in a database is organized into the logical components visible to users. A database is also
physically implemented as two or more files on disk. When using a database, the user works
primarily with the logical components such as tables, views, procedures, and users. The physical
implementation of files is largely transparent. Typically, only the database administrator needs to
work with the physical implementation. Figure 1.4 shows the two components of a database.
The database in the SQL Server has two different database components (see Figure 1.5):
Web Development of a Cricket Progress File 9/89
• System databases: these are administrative databases used to control and secure the whole
database system. They also maintain information about user databases.
• User databases: these are user created databases for specific applications.
Figure 1.5 shows that SQL Server is settled above the databases. In fact, it is the memory instance
or the engine that enable the user to communicate with the database (the physical storage) by using
the Structured Query Language (SQL). Through SQL the user can enquire or manipulate the
information stored in the database, or even alter the database structure.
Web Development of a Cricket Progress File 10/89
This chapter gives an understanding of the business, i.e. the Cricket Progress File (CPF), and
describes the user requirements in brief. It shows an overall view of what the CPF system is about.
A progress file is defined by [5] as the following: “While the term Progress File suggests that it is a
document charting the progress of an individual, the overall concept contains:
• The transcript: a record of an individual's learning and achievement, provided by the
institution;
• an individual's personal records of learning and achievements, progress reviews and plans
that are used to clarify personal goals and can provide a resource from which material is
selected to produce personal statements (e.g. CVs etc) for employers, admissions tutors and
others;
• structured and supported processes to develop the capacity of individuals to reflect upon
their own learning and achievement, and to plan for their own personal educational and
career development. The term Personal Development Planning (PDP)is used to denote this
process.
Progress files help to make the outcomes, or results, of learning in higher education more explicit,
identify the achievements of learning, and support the concept that learning is a lifetime activity”.
The Cricket Progress File (CPF) from the client point of view is described as follows:
The Cricket Progress File (CPF) will be used by the UCCE cricketers to log their performance and
review with their coach the higher-level skills, such as concentration, in order to improve their
performance. This is the primary function of the CPF. The qualities this develops in players are
relevant to their personal and academic development, and a secondary function of the CPF is to
communicate the value of this to the academic tutor in the terms used by the generic university
progress file.
The CPF is a valuable document for the player, his coach and others who are contributing to his
development as a cricketer. It uses a detailed log of the player’s developing cricketing skills to help
Web Development of a Cricket Progress File 11/89
him identify the more general skills, attitudes and aptitudes he is acquiring, and in this way helps
him mature as a player more quickly. This will also help the player express the value of sporting
excellence to his university academic tutor and cope with the competing demands of sport, study
and social life.
The CPF will also help the player to express to his academic tutor the value of cricket from
developing his general skills, such as teamwork and motivation; and attitudes, such as the ability to
set goals and achieve them.
There are different information gathering techniques that are used by analysts to investigate
requirements. [6] describes the five main information gathering techniques in broad details. These
techniques are Sample Documents, Questionnaires, Interviews, Background Reading and
Observations. They are also referred to as SQIRO techniques.
Through the CPF project, three of the information gathering techniques have been used, which are
Sample Documents, Interviews and Questionnaires. In addition to these, Email Enquiries have also
been used for answering some short questions that do not require meeting with the client. Email,
overall, was an effective communication tool throughout the project. Examples of information
gathering techniques used throughout the CPF project can be found in Appendix E (Information
Gathering Samples). The user requirements, listed in Appendix D (Requirement Specifications
Report), is the outcome resulted from using such techniques.
The aim of developing a new system must be to produce something that meets the need of the
people who will be using it. In order to do this, we must have a clear understanding both of the
overall objectives of the business and of what is that the individual users of the system are trying to
achieve in their jobs. Unless we are in a rare position of developing a system for a new
organization, we will need to understand how the business is operating at present and how people
are working now. Many aspects of the current system will need to be carried forward into the new
system, so it is important that the information about what people are doing is gathered and
documented. These are the requirements that are derived from the ‘current system’. The motivation
for the development of a new system is usually problems with and inadequacies of the current
Web Development of a Cricket Progress File 12/89
system, so it is also essential to capture what is that users require of the new system that they cannot
do with their existing system. These are the ‘new requirements’. [6]
System requirements, as described by [6] fall into one of the three categories: functional
requirements, non-functional requirements and usability requirements.
Functional requirements describe what a system does or is expected to do, often referred to as its
functionality [6]. In the object-oriented approach, which is adopted for the analysis and design of
the CPF, I shall initially employ use cases to document the functionality of the system. As I
progress into the analysis stage, the detail of the functionality will be recorded in the data that are
held about the objects, their attributes and operations. “Functional requirements include the
following:
• Description of the processing that the system will be required to carry out.
• Details of the inputs into the system form paper forms and documents, from interactions
between people, such as telephone calls, and from other system.
• Details of the outputs that are expected from the system in the form of printed documents
and reports, screen displays and transfers to other systems.
• Details of data that must be held in the system.” [6]
Non-functional requirements, as described by [6], are those that describe aspects of the system that
are concerned with the quality of providing the functional requirements. These include the
following:
• Performance criteria such as desired response times for updating data into the system or
retrieving data from the system.
• Anticipated volume of data, either in terms of throughput or of what must be stored.
• Security considerations.
• Hardware and software constraints.
Usability requirements are those that will enable us to ensure that there is a good match between the
system that is developed and both the users of that system and the tasks that they will undertake
when using it. The International Standards Organization (ISO) has defined the usability of a product
as “the degree to which specific users can achieve specific goals within a particular environment;
effectively, efficiently, comfortably and in acceptable manner”. “In order to build usability into the
system from the outset, we need to gather the following type of information:
Web Development of a Cricket Progress File 13/89
I shall describe the current system briefly as it does not offer a great contribution to the
development of the proposed CPF system. Instead, the requirements of the proposed system are
discussed in detail bearing in mind the concept of the current system.
The existing CPF system is very simple. It is paper based, and involves two types of users
(stakeholders) who are the coach and the player. The coach interviews each player at a time and
record his skills and performance progress on a paper. This interview is done informally, after a
cricket match or during a training session. By time, the coach should have a clear view about the
player’s progress. The player also is informed of his progress regularly. The use case diagram
below demonstrates this interaction between the coach and the player.
Interview P lay er
Coac h P lay er
The new (or proposed) CPF system is to be fully computerized. The player plays the most crucial
part on maintaining his progress file(s) on behalf of his coach. The coach does only need to
monitor/view those files, and should be able to add his comments on them. A third actor is involved
in the new system, which is the academic tutor. He should also be able to monitor the skills related
to the player’s academic life, and also add his own comments where applicable. Figure 2.2 is an
overall view of how the requirements of the new system should look like.
Web Development of a Cricket Progress File 14/89
P layer
Coac h
A c ad emic Tutor
Figure 2.2 Overall-View Use Case Diagram of the New CPF System Requirements
Web Development of a Cricket Progress File 15/89
This chapter analyzes the detailed functionality of the CPF system. All components of the system
will be identified, and the interactions between these components will be examined. It will start to
go into more details of the user requirements by representing these requirements with a detailed use
case diagram. It will then take every use case, describe it textually using use case description
technique, and systematically using the standard UML interaction diagrams such as
collaboration/sequence diagrams, and activity diagrams. Since the end product (i.e. the program
code) will not be object oriented, the interaction diagrams will be used to extract the candidate class
diagram, whereas, the activity diagrams will be used mainly to model the functionalities of the
system/subsystems so that the functionalities can be translated into program codes. This chapter will
finally arrive at a conceptual class diagram model that should have been constructed from the
description of the detailed use case diagram. The conceptual, or concept-level, class diagram will be
the first cut of the solution model which is the detailed class diagram.
Requirement analysis will be illustrated using only some examples of the CPF UML notational
diagrams. The detailed specifications, including the essential UML models of the CPF, can be
found in Appendix D (Requirement Specifications Report).
“The most influential factor for the success of an information system project is whether the software
product fulfils its users’ requirements. Models constructed from an analysis perspectives aim at
determining these requirements. This means much more than just gathering and documenting facts
and requests.” [6]
The use case diagram shown in Figure 3.1 models the textual user requirements of the CPF (as
given by Appendix D) in a visual abstract view. It gives a perspective on many user requirements
and models them in terms of what the CPF system can do to help the users perform their work (i.e.
what functionalities can the CPF system provide). The model in the figure introduces a new actor
which is the System Administrator. This actor plays an administrative role such as creating and
managing user accounts for the users who will be involved in using the CPF system.
Web Development of a Cricket Progress File 16/89
Coac h
Ac ad emic Tutor
Ans wer Ques tionnaire << ex tend> > Ge nerat e Ques tionnaire
Alter Us er Ac c ount Inform ation Delete Ques tionnaire M odify Ques tionnaire
<<ex tend>>
Figure 3.1 The Detailed Use Case Diagram of the CPF system
Use case description is described by [7] as an informal specification of the system functionalities. It
does not have any formal syntax, and the description can be written in a format that is most useful
to the development team and, of course, to the system actors. The simplest and most common
approach used is to describe each use case using simple English text. Table 3.1 describes one of the
use cases of Figure 3.1. An extra column has been added to construct possible candidate classes
from the text. Full description of the use cases can be found in Appendix D (Requirement
Specifications Report).
Web Development of a Cricket Progress File 17/89
Table 3.1 Description of the Use Case “Fill-in Scores of Cricketing Skills”
Having constructed the candidate classes for each use case, the interaction between these classes
can now be modeled. In object orientation, objects interact with each other by sending messages
(see [6] and [7]). In Figure 3.2 below, sequence diagram is used to model all possible interactions
between objects of the classes found in use case 1 (Fill-in Scores of Cricketing Skills). Please note
that some of the classes are not in the use case description text as they are going to be the interface
classes the user of the system will be using to interact with the system. Fore example, in Figure 3.2,
CPFHomePage and PlayerHomePage are the interface classes which are going to be web pages
eventually.
: CP F Hom eP age : Us erA c c ount : P lay erHom eP age : S k ill : S c ore : P la y erDB
: P lay er
s ignIn( )
aut horiz e( )
lis t S k ill( )
fill-inS c ore( )
r ecord Sc ore( )
Figure 3.2 Sequence Diagram for the Use Case “Fill-in Scores of Cricketing Skills”
Web Development of a Cricket Progress File 18/89
Part of the concept-level class diagram can now be drawn using the classes and associations
resulted from the above sequence diagram. See Figure 3.3 below.
Pl ay erHom ePage
CPFHom eP age
dis play ()
authoriz e()
fill-inSc roe()
s ignIn()
ans werQues tionnaire()
Us erA c c ount
Play erDB
getA c c ountDetails ()
addUs er()
getP lay erID()
Ques tionnaire
Sc or e
S k ill
Likewise, the interaction of other use cases can be modeled and their partial concept-level class
diagrams can be drawn. All resulted partial concept-level class diagrams can eventually be joined
into one concept-level class diagram (Figure 3.4). This concept-level class diagrams forms the basis
of the detailed class diagram which will be described in chapter 4 (Prototype Design).
Web Development of a Cricket Progress File 19/89
P la y e rH o m e P a g e
A d m in H o m e P a g e C P FH om e P a ge
d is p la y ()
d is p la y () a u th o riz e ()
fi ll- in S c r o e( )
c re a te U s e rA c c o u n t () s ig n In ()
a n s w e rQ u es t io n n a ire( )
U s e rA c c o u n t
P la y e rD B
C oa c hH om eP age g e tA c c o u n t D e ta ils ()
a d d U s e r()
g e t P la y e rID ()
d is p la y () C oac hD B
vie w S u m m a ry ()
g e n e ra te Q u e s tio n n a ire () C om m en t
c o lle c t Q u e s t io n n a ire ()
e n t e rTe x t C o m m e n t () a d d T e x t C o m m e n t ()
Q u es t io n n a ir e
c re a t e N e w Q u es t io n n a ir e()
a d d A n s w e r( )
a d d Q u e s ti o n( )
g e tD et a il s( )
S c o re
S u m m a ry
S k ill
re c o rd S c o re ()
d is p la y S um m a ry( )
g e tS c o re () lis t S k ill()
UML activity diagrams can be used to model functionalities and information flow in a use case.
Activity diagrams, as described by [7], has many purposes. They can be used throughout a project
from business analysis through to program design. In the CPF system, activity diagrams are used as
a bridge to bring the high-level functionalities of use cases towards producing the program code.
Figure 3.5 describes the high-level logic encapsulated in use case 1 (Fill-in Scores of Cricketing
Skills).
Web Development of a Cricket Progress File 20/89
S ig n In
A u t h o riz e
[ In v a lid u s e r n a m e / p a s s w o r d ]
[ V a lid u s e r n a m e / p a s s w o rd ]
Di s p la y P l a y er
Hom e P age
L is t S k i ll
S c o re a g a in s t
t h e S k ill
[ M o re s k ill s t o lis t ]
[ N o m o re s k ills t o l is t ]
R e c o rd S c o r e s
Figure 3.5 Activity Diagram for the Use Case “Fill-in Scores of Cricketing Skills”
Web Development of a Cricket Progress File 21/89
This chapter describes the design of the CPF prototype. Since the prototype to be developed is an
evolutionary prototype, all software components should be constructed and linked together to form
a working prototype system. This prototype is an iterative one (as introduced in chapter 1).
Additional functionalities will be incorporated as new iterations are performed. The client
involvement plays an essential part of the development of this prototype.
This chapter begins with a description of the detailed class diagram that its operations will be
mapped into functions (i.e. ASP/HTML and JavaScript codes), and its classes will be mapped into
user interfaces and relational database tables. It will then describe the steps involved in designing
the relational database. Finally, this chapter will discuss the issues related to Human Computer
Interface (HCI) and web design.
The concept-level class diagram, described in section 3.3, is recalled here. Further refinements
should be performed to the diagram, attributes should be constructed and extra operations may be
added. Figure 4.1 shows the detailed class model of the CPF Prototype. Refinements have been
made to the model after further study of user requirements. Please note that there is no home page
dedicated to the academic tutor. Nevertheless, the coach’s home page, is to be used by him, only, to
generate and collect questionnaires related to the academic aspects.
4.2 Mapping Classes into ASP/HTML files and SQL Server Database Tables
Since the implementation of the CPF prototype is to be done using ASP as the coding language,
and/or SQL Server as the database engine, classes need to be mapped into a form that is suitable to
the development environment. Classes need to be expressed either into ASP/HTML files and/or
SQL Server database tables. For example the interface class “PlayerHomePage” will be in a form of
HTML file, while the class “PlayerDB” will be in a form of database table since it is meant to hold
player’s biographical details. However, some of the classes, that are to be used as data storage and
processing at the same time, need to be expressed in both forms, ASP/HTML and SQL Server
database tables. An example of this type of classes is the “Questionnaire” class. Operations of the
classes will be encapsulated into the ASP scripts. Table 4.1 shows the forms of how the different
classes are going to be in.
Web Development of a Cricket Progress File 22/89
0..n 0.. n
0..n Questionnaire
qid 1
qtitle S kill
c reationdate
skillid
available
skillnam e
answered
listS kill()
c reateNewQues tionnaire()
addA nswer()
addQuestion()
getDetails()
The system architecture of the CPF prototype has already been described in Chapter 1 from the
hardware point of view. Since the system architecture of the CPF is a three-tier architecture,
software components should conform to this architecture and hence they should be distributed
across the three tiers according to their roles and functionalities. Software architecture defined by
[6] as: “A description of the sub-systems and components of software system and the relationship
between them. Subsystems and components are typically specified in different views to show the
relevant functional and non-functional properties of a software system. The software architecture is
an artifact. It is the result of the software design activity”.
There are different types of software architecture approaches described in [6]. One popular
approach is what is called the “layered architecture”. Layered architecture means that system
components are placed on separated layers. Tightly related components are placed in the same
layer. In three-tier architecture, layers are divided into data storage layer, application layer and
presentation layer. The CPF software architecture is kind of three-tier layered architecture. Figure
4.2 represents the CPF software architecture and shows the main components of the prototype.
HTTP Requests
Application Layer Score Questionnaire Summary Comment
(ASP Dynamic Scripts)
Data Layer
(SQL Server Database Tables) Skill Questionnaire Comment
TutorDB UserAccount
As the database layer and its components have already been identified, further work need to be
curried out to make sure that this layer conforms to the Relational Database Management System
(RDBMS) roles. Referring to Figure 4.2, the database tables within the data layer are the candidate
relations (or entities) to start with. In this section the Entity-Relationship, or E-R, diagram will be
constructed. Relations of the E-R diagram need to be normalized to the Third Normal Form (3NF).
Then the Relational Model of the CPF prototype can be drawn as the final step prior to database
creation. The relational model is supported by description of relations and attributes. This
description is attached to Appendix D (Requirement Specifications Report).
“To insure that we get a precise understanding of the nature of the data and how it is used by the
enterprise, we need to have a model for communication that is non-technical and free of
ambiguities. The Entity-Relationship (ER) model is one such example. ER modeling is a top-down
approach to database design that begins by identifying the important data called entities and
relationships between the data that must be represented in the model” [8].
The candidate entities that form the E-R model of the CPF prototype, as presented in Figure 4.2, are
Questionnaire, Skill, Score, Comment, UserAccount, PlayerDB, CoachDB and TutorDB. For
simplicity, PlayerDB, CoachDB and TutorDB entities will be renamed to Player, Coach and Tutor
respectively. The diagram represented by Figure 4.3 is the first cut E-R model of the CPF prototype.
has 1
USERACCOUNT 1 has
has 1
1 1
0..M coaches 1
PLAYER COACH
1 views writes 1
0..M
0..M 0..M 0..M 1
tutors COMMENT
possesses 0..M generates
1 1 answers
TUTOR 0..M
QUESTIONNAIRE
0..M 0..M
SKILL
The entity “Score” is not shown in the diagram because it is a derived entity. It will be needed later
in the relational model to resolve the many-to-many relationship between Player and Skill.
4.4.2 Normalization
Normalization is meant to bring database entities into a form that is free of redundancy and
update/insert anomalies. Normalization, as defined by [8] is “A technique for producing a set of
relations with desirable properties, given the data requirements of an enterprise”. It is often
performed as a series of tests on a relation to determine whether it satisfies or violates the
requirements of a given normal form. There are different levels or degrees of normal forms which
are first normal form (1NF), second normal form (2NF), third normal form (3NF) and Boyce-Codd
normal form (BCNF) . BCNF was introduced by R. Boyce and E.F. Codd as a stronger definition of
3NF [8]. Higher normal forms that go beyond BCNF were introduced later such as fourth normal
form (4NF) and fifth normal form (5NF). However these later normal forms deal with situations
that are very rare [8].
There are 2 common approaches, described by [8] and [9], of arriving at normal forms:
• Bottom-up: Starting with the original entities and use normalization rules to move the
design from 1NF to a higher normal form such as 3NF.
• Top-down: Start with data modeling and, if done properly, it should lead to a normalized
database. Normalization can be used later on, as a crosscheck, to resolve any anomaly
problem.
In the database design of the CPF prototype, the top-down approach will be followed. Resulted
entities (or relations) will end up to be normalized up to the 3NF at least, although, 3NF is
satisfactory for such small-scale database.
A fully normalized E-R model is demanded. A deeper analysis of user requirements would be very
useful to construct the final model. As a result of this, new entities have been constructed and added
to the E-R model. Also some relations in the original model need to be decomposed to eliminate
many-to-many (M2M) relationships as this relationship violates 1NF. The following are set of steps
that have been performed to arrive at a fully normalized E-R model:
Web Development of a Cricket Progress File 26/89
Skills Categorization: In cricket, players (cricketers) can play different roles on the pitch. For
examples “Batting”, “Bowling” and “Fielding” are said to be roles. Players are expected to possess
set of commonly defined skills belonging to different roles. The word “skill” is used as a shortcut
referring to different levels, types, or categories, of skills. “Technical & Tactical”, “Physical” and
“Mental” are such examples of skill types. The diagram below illustrates an example of this
categorization.
Batting Role
Another two entities can be extracted from the above figure, which are Role and Skill_Type, in
addition to the entity Skill. The following E-R model segment has resulted from this categorization
process:
belongs to has
ROLE 1 0..M SKILL 0..M 1 SKILL_TYPE
Player-Skill Relationship: The relationship between Player and Skill is many-to-many (M2M).
This must be decomposed by introducing a third entity. In the CPF it is meant that player records
his performance progress by scoring against each cricketing skill, and hence the entity Score
introduced previously in the class diagram in Figure 4.1, as a class, is a good candidate to form the
relationship between Player and Skill entities. The new E-R structure of this relationship should
look like the following:
records against
PLAYER 1 0..M SCORE 0..M 1 SKILL
0..M
QUESTIONNAIRE_
BODY
Consequently, the detailed, and fully normalized, E-R model resulting from the top-down
normalization approach can be constructed now (see Figure 4.5 below).
has 1 USERACCOUNT
1 has
has 1
1 1
0..M coaches 1
0..M PLAYER COACH
1 views writes 1
tutors 1
1 0..M 1
1 1 generates
records answers 0..M COMMENT
TUTOR
0..M PLAYER_ 0..M
0..M QUESTIONNAIRE QUESTIONNAIRE
SCORE 0..M
contains 1 1
0..M
contains
against
0..M
1 QUESTIONNAIRE_
has BODY
SKILL 0..M 1 SKILL_TYPE
0..M
belongs to
1
ROLE
In this section, the entities of the final E-R model, shown in Figure 4.5, are expressed into relational
database tables with their key attributes. Relationships between the tables are represented by
primary key-foreign key referential integrity. The relational model is considered to be the final step
prior to database creation activity. Figure 4.6 shows the relational model of the CPF prototype. Only
key attributes are shown in the model. For full listing of attributes and description, please refer to
Appendix D (Requirement Specifications Report). Primary key attributes are underlined while
foreign keys are printed in Italic face. Attributes that are both underlined and printed in Italic face
are foreign keys and part of the primary key at the same time.
Designing the user interface can be critical in the development of an information system. The core
issues related to the user interface design process are described by [12] as:
• Understanding the essential properties of users which effect their interaction with the
computer system;
• Analyzing what users do with computer systems;
• Specifying how the interface should respond to the user and its appearance;
• Evaluating the properties of human-computer interfaces and their effect on people to ensure
good quality.
The issue of the user interface has been incorporated into the CPF prototype form the early stages of
the system development process. This can be seen obvious in Chapter 3 (Requirement Analysis)
where interface, or boundary, classes are within the class diagram of the prototype. Software
architecture of the CPF prototype, in this chapter, has also emphasized the user interface issue
considering the user interface as a separate layer of the architecture that has to be separated from the
other layers of the architecture.
The CPF prototype user interface is web-based, therefore, it should follow web design standards.
Web design is defined by [10] as “The process by which a web designer, working with the web’s
specifications, makes decisions about how web components will accomplish the web’s objectives”.
The following are the key issues, that have to be achieved, in web design as described by [10]:
• Create a consistent look and feel for the web;
• Separate information into page-sized chunks;
• Use links to connect pages along the routes of use and user thinking.
The website of the CPF is organized into four main pages, as shown in Figure 4.7, which are the
CPF Home Page (login page), the Player’s Home Page and the Administrator’s (Admin) Home
Page. This structure allows user security access to be built into the design. The user is required to
login using the CPF Home Page, his account is validated and then he will be redirected to the
appropriate home page according to the access role he has been given. For example, a player will be
redirected to the Player’s Home Page. Every main page consists of sections (sub pages), and inside
each section there are different tasks the user may choose to perform. Consistent look and feel has
Web Development of a Cricket Progress File 30/89
been maintained into all pages and sections, although, contents of the pages vary according to the
type of the user. Figure 4.8 shows screen shots of Player’s Home Page sections. More explanation
of the website will be given in Chapter 5 (Prototype Implementation).
Figure 4.8 Screen Shots of Two Sections from Player’s Home Page
Web Development of a Cricket Progress File 31/89
This chapter describes the creation of the software system. The software is distributed between
three separate layers, as explained in section 4.3, which are the database, the application program
(the business code) and the user interface. The chapter starts by describing database creation. Then
it will describe the construction of the website including the program code (the ASP scripting). At
the end, the chapter gives a brief description about user input validation mechanism built into the
CPF prototype. Please note that only code segments are demonstrated in this report. The full code is
quite long and contains large amounts of embedded HTML text.
The database is created under Microsoft SQL Server. The database creation implements the
relational model described in section 4.4.4. The SQL script for creating the database can be found in
Appendix D, Section D.6.
The website contains both the user interface and the program code. It is organized into ASP files
with “asp” extension. The ASP files contain embedded HTML text in a way that both ASP codes
and HTML text exist inside one container which is the ASP file; this is to maintain the dynamics of
the pages and the security of access. Figure 5.1 shows the website structure of the CPF prototype.
The function of the ASP file connection.asp is to unify the appearance of text and links on all web
pages. It also controls the access to the different web pages, and connects the users to the database
as well. All web pages reference this file as a header information file;
<!-- #include file = "connection.asp" -->
In order to use the CPF prototype, the user is required to sign (log) into the system. His user name
should have been created first by the system administrator. The sign-in page, default.asp, is shown
in Figure 5.2.
Web Development of a Cricket Progress File 33/89
The page is to be used as the start-up page of the CPF prototype. After the user has supplied his
username and password, the system verifies that his user record exists into the database, and that
username and password match. After that, the system redirects the user to the appropriate web page
according to his access role. There are four different types of access roles, which are:
• PLAYER: if the user is a player;
The code segment of the sign-in process can be found in Appendix F, Section F.1.
Access to the CPF is controlled by the system administrator’s home page which is admin.asp.
System administrator can create a new user using useraccount.asp or alter access information of an
existing user using updateuser.asp. Both options are shown in Figure 5.3 below.
Web Development of a Cricket Progress File 34/89
Players are required to record their progress of cricketing skills by scoring. They do the scoring
periodically say every week, or after every cricket match or a training programme. The script that
enables them to score is score.asp. The script reads the standard cricketing skills, as defined by the
UCCE (see the document sample in Appendix E, Section E.3), from the database and displays them
on a web page prompting the players to enter a score value against each listed skill. Skills are
displayed according to the role they belong to and to their type (skills categorization has already
been described in Section 4.4.3). Scores are defined within the range 1-10 (poor-excellent). A score
of 10 means player reached a maximum level of excellence on the particular skill. Figure 5.4 shows
a screen shot of a scoring scenario. The scoring process workflow of score.asp script is described
briefly by the following lines:
1. Retrieve the set of skills according to the given role and skill type in an HTML form (see
Appendix F, Section F.2 for the code segment).
2. Read and save score values, and move to the next set of skills (see Appendix F, Section F.3
for the code segment).
Web Development of a Cricket Progress File 35/89
The coach should also be able to contribute to the development of his players’ skills. After watching
the player physically or even after looking into his performance record, the coach can enter text
comments as a feedback about the player’s performance progress. These comments will be stored as
a log history, with date stamp, into the database so that both the coach and the player can monitor
the improvement of the player’s performance (as described in the next section). The script
comment.asp is used to record the comments (see Figure 5.5) and can be accessed through the
interface script progress.asp. First, the progress.asp script displays the players’ list to enable the
coach to select one player at a time. Pressing “Text Comments” button allocated underneath the
player’s list invokes the comment.asp script that pops up a text-area box for comments entry. The
following is the code segment of recording the text comments;
<%if (Request.Form("add") <> "") then%>
<form method="POST" action="comment.asp">
<p><textarea rows="13" name="commenttext" cols="58"></textarea></p>
<p><input type="submit" value="Save Comments" name="save">
<input type="reset" value="Clear Text" name="B2"></p>
</form>
<%end if
The coach and the player can both monitor the player’s performance progress. Monitoring the
progress means observing the development/improvement of the player’s skills. In other words, it
means viewing the text comments log and the history of the accumulated scores using comment.asp
and summary.asp scripts respectively. Both scripts are accessed through the interface script
progress.asp shown in Figure 5.6. The players do not see the players’ list, and will not be prompted
to enter text comments when they access their progress records. Instead, they will be shown
different options so a player may only access his own progress records (see Figure 5.7). Windows
of comment and summary are viewed side by side so that the contents of the two progress files can
be compared and contrasted.
Text comments log can be viewed simply by pressing “Text Comments” button. A complete log of
comments will be displayed by date of entry. The following is the code segment of viewing text
comments log:
my_sql = "select entrydate, commenttext from comment "
my_sql = my_sql & "where coachid = " & my_coachid
my_sql = my_sql & " and playerid = " & my_playerid
my_sql = my_sql & " order by commentid desc"
rs.Source = my_sql
rs.Open%>
<font face="Arial" color="#008080"><b><u>Progress Record of <%=my_playername%> </u></b><br><br>
<table border="0" width="700">
<%while not rs.EOF
my_entrydate = day(rs("entrydate")) & "/" & month(rs("entrydate")) & "/" & year(rs("entrydate"))%>
Web Development of a Cricket Progress File 37/89
<tr>
<td width="100" valign="top"> <font face="Arial" color="#008080"><b> <%=my_entrydate%> </b></font> </td>
<td width="600" valign="top"> <font face="Arial" color="#008080"> <%=rs("commenttext")%></font></td>
<tr><td></td><td></td></tr>
</tr>
<%rs.MoveNext
wend
rs.Close%>
</table>
Similarly, progress summary can be viewed by pressing “Progress Summary” button underneath
players’ list. It is based on a, from-to, date period that is provided at the top of the page. The
summary page contains the following sections:
• An HTML form that inputs the, “From” and “To”, date period (see Appendix F, Section F.4
for the code segment);
• A statistical summary of average score displayed by scoring date (see Appendix F, Section
F.5 for the code segment);
• A line-chart graph plotting the average score by date∗ (see Appendix F, Section F.6 for the
code segment);
∗
The JavaScript library, glib.js, used to draw the graph is a freeware provided by http://siva.cc.hirosaki-u.ac.jp/usr/koyama/glib.
It is a modified version of Netscape JavaScript graph builder graph.js (http://developer.netscape.com/docs/technote/javascript/graph ).
Web Development of a Cricket Progress File 38/89
• A statistical summary of the overall average score across the date period (see Appendix F,
Section F.7 for the code segment).
The player, the coach and the academic tutor can use the questionnaire facility provided in the CPF
prototype. The player may only answer the questionnaires that are made available for him by his
coach or his tutor, whereas, the coach and the tutor are responsible for generating and maintaining
their own questionnaires. The coach and the tutor should also be able to view (collect) the
questionnaires that have been answered by their players (or tutees). Table 5.1 lists the different
possible actions that can be performed on questionnaires, and who is responsible for performing
each particular action. Figure 5.8 shows the questionnaire.asp main page with the different
actions/options accessible to the coach.
The following lines describe the actions listed in Table 5.1. The tutor can also do all tasks that can
be done by the coach:
Generate Questionnaire: Questionnaire consists of header and body (see Figure 5.9). The header
contains information like questionnaire title, author, creation date, etc. The coach is to enter the title
Web Development of a Cricket Progress File 40/89
and has to decide whether to make the questionnaire available online to his players or not. Other
information like author and creation date is to be stored internally by the system. After header
information has been filled, coach will be prompted to enter questionnaire body information. Body
information is actually the set of questions the questionnaire may contain. Questions are to be
entered one by one, each per screen. Pressing “Proceed” button will save the current question and
leads to the next one, whereas, pressing “Finish and Exit” button will save the current question, if
text area is not empty, and ends questionnaire generation process. The code segments for generating
a new questionnaire can be found in Appendix F, Section F.8.
Modify Questionnaire: Questionnaire modification takes two steps, modification of the current
structure (e.g. modifying header and body information) and adding more questions to the existing
structure. This is shown in figure 5.10. Modification of the current structure includes editing header
information, and editing or deleting existing questions. Removing text from question text area will
delete the question from the structure, after “Save Changes” button has been pressed, and the
questions order will be re-arranged. Adding more questions is actually the same process, described
above, of entering questions one by one. The code segment of questionnaire modification can be
found in Appendix F, Section F.9.
Web Development of a Cricket Progress File 41/89
Delete Questionnaire: Deleting a questionnaire is a simple process. The coach needs to select the
questionnaire he wants to delete from the list provided and press “Delete” button. An alert message
will pop-up to confirm the deletion. The scenario is shown in Figure 5.11. The code segment of
questionnaire deletion follows;
' 1. Deleting Questionnaire
if (Request("edit") = 1 and Request.Form("del") = "Delete") then
conn.BeginTrans
my_sql = "delete from player_questionnaire where qid = " & Request.Form("qid")
conn.Execute my_sql
my_sql = "delete from questionnaire_body where qid = " & Request.Form("qid")
conn.Execute my_sql
my_sql = "delete from questionnaire where qid = " & Request.Form("qid")
conn.Execute my_sql
conn.CommitTrans
end if
As the code segment above shows, all questionnaire components are deleted including the answers,
if any, to maintain data consistency. Answers are stored in PLAYER_QUESTIONNAIRE table.
Answer Questionnaire: Answering of questionnaire is to be done by the player through the script
qanwer.asp. A list of questionnaires is displayed to the player so that he can select the questionnaire
he wishes to answer. Player is then get a listing of all questions of the questionnaire, and he will be
required to fill-in the text area, below each question, with his answers. If an answer text area is left
empty, then the answer for the corresponding question will not be stored and will be treated as not
answered. The scenario is shown in Figure 5.12.
Validating user input is an essential step to be done before submitting user’s input data to the
database. In the CPF prototype, input data are even verified before forms are posted to the ASP
scripts. In other words, input data are verified in the client side. Client side scripting, therefore, has
been implemented in the CPF using JavaScript. JavaScript can perform the preliminary check of the
data inputted to HTML forms. It can also give immediate feedback to the user like displaying pop-
up alert messages.
Input data in the CPF are checked against null values and against incorrect formats. Further check is
to be done at the server side using ASP if a contact to the database is required to perform the check.
Figure 5.14 shows an example of user’s input validation within two stages (e.g. client side and
server side). In the first (left) scenario it ensures that the “password” to be entered must be at least 6
characters of length, while in the second one (right) it verifies that the user to be created is a new
user (i.e. “user name” must not be already in the database). The code segments of the two scenarios
are as following;
1. The JavaScript code segment of the first scenario;
if (theForm.password.value.length < 6)
{
alert("Please enter at least 6 characters in the \"password\" field”.);
theForm.password.focus();
return false;
}
Chapter 6: Evaluation
This chapter describes the evaluation of the project. It begins with a discussion on how the
objectives and the user requirements have been met. It then describes the outcome of the user
acceptance test that has been performed by the users themselves. The chapter, finally, raises some
issues and arrived at a couple of suggestions for future development.
Objective 1: To use the Internet to allow the players maintain their own cricket progress files.
The players could now login to the system and perform various tasks of maintaining their progress
file.
Objective 2: To maintain the players’ various skills and achievement records into a database
system so that their progress can be monitored by themselves and by their coach.
The database system has been created to enable the players to store all various skills and
achievement records (e.g. Scores). The database has also been tested with sample data, and that all
different kinds of progress records could be monitored by the players and their coach.
Objective 3: To improve the way the cricket progress file is being handled, and eliminate the need
for the coach to keep manual records.
This is now obvious, as the CPF system could be used indeed, and that it should alter the manual
procedures.
Objective 4: To facilitate the coach’s job by letting the players keep their own performance records
electronically and make them available to him at anytime.
This has already been addressed by objectives 1 and 2 above.
Objective 5: To provide a working prototype that would help in creating a standard cricket
progress file.
The CPF prototype is functioning and it has been created according to the user needs. Therefore, it
should lead to the creation of a standard cricket progress file system.
Furthermore, the client feedback letter in Appendix G, Section G.1, reflects the user satisfaction on
what has been achieved. I therefore conclude that all the objectives have been met.
Web Development of a Cricket Progress File 45/89
All user requirements have been incorporated into the CPF prototype. A common way to verify this
is to use test cases. Test cases can be derived from the use cases and they are used to verify user
requirements (see [6], [13] and [14]). Accordingly, I shall match the use cases of the CPF use case
diagram, described in Chapter 3, with the various functionalities provided by the prototype. The
following figures demonstrate this match and insures that all user requirements have been met. The
figures are self-explanatory and do not require further explanation.
Coach
View/Collect Answered
Qustionnaire
<<extend>> <<extend>>
View/Collect Answered
Qustionnaire
Academic Tutor
<<extend>> <<extend>>
<<extend>>
<<include>>
User acceptance test has been done to verify that the prototype meets the user’s requirements, goals
and expectations, and to capture any bugs that might persist. All types of the CPF users were
involved in the test including the system administrator, the coach, a player and an academic tutor.
The outcome of the test is shown in Appendix G, Section G.2. The following lines summarize the
outcome of the test and the actions that have been taken as a result of the outcome:
• All user accounts of the testers were successfully created by the system administrator before
the beginning of the test.
• The testers were able to do all different tasks happily and efficiently.
• All user’s requirements have been implemented, however, the coach asked for an additional
feature that should enable him to view the individual score values of his players. The
prototype, at the moment, provides an average summary of the scores and plots skills
development as a line-graph but there is no option to view the individual score values. This
option has been considered and it could be added in the future.
• Some skill names were spelt incorrectly. These are database entries and they have been
corrected.
• There were a few bugs encountered during the test, which are:
o In progress summary (comments), general comments on player’s skills do not view
to the coach. The bug has been identified and fixed.
o In questionnaires (answering), the player gets an error message when submitting
long answers. The reason was the length of the database field, that holds the answers,
Web Development of a Cricket Progress File 48/89
was not satisfactory. Field length has been resized and the problem has been sorted
during the test. The player could then resubmit his answers successfully.
o In questionnaires (modification), the tutor was not supposed to see the questionnaires
generated by other users. This bug has also been identified and fixed.
The evaluation has also raised some issues that should be considered in the future development. The
following lines address these issues while suggesting further improvement:
Chapter 7: Conclusion
This report has started with Chapter 1, which has explored the problem domain and the overall
technical evaluation of the hardware/software tools that might be used to implement the proposed
solution. Chapters 2 and 3 explained how user requirements have been gathered and analyzed to
give more understanding to the problem. Chapter 3 has also suggested a conceptual solution to the
problem. Based on the outcome of Chapter 3, Chapter 4 has explained how the different system
components could be derived from the conceptual solution and fitted within a system architecture
that is applicable to the web environment. It has also described the issues related to HCI and web
design. Chapter 5 explained how the different system design components have been converted into
software components that formed the prototype. The chapter has also featured the various facilities
provided by the prototype. Finally, in Chapter 6, the project has been evaluated to see if it has
achieved users’ objectives and met their needs. It has also addressed the issues that should be
considered in the future development.
The project has been started with a little hope of getting feasible user requirements. It was under-
specified as quoted by my former supervisor, Peter Mott (see interim report feedback in Appendix
C). The situation was even worse, as there has been no similar application can be found on the Net.
What might a cricket progress file contain? Was the hard question to be answered.
The obvious answer to the above question was prototyping. After the users saw the first iteration of
the prototype, they could recognize what they wanted to keep in this progress file. The actual
requirements then could be extracted and gathered as the iterative development went on. The
experience showed that prototyping is a very effective technique to get user attention and
involvement in the project. One thing I would like to emphasize is that prototyping that lacks user
commitment is like a waste of time. I was fortunate to find my client, in a few times, during the
summer period to discuss the project.
The prototype developed is an evolutionary prototype. There are advantages as well as drawbacks
of the evolutionary prototypes. [12] suggests that evolutionary prototypes save efforts as no code is
discarded; however, they may not produce maintainable systems, as the code structure may be poor.
I also argue with this and just want to make it certain to my client that the code has been revisited
many times and some of the modules (ASP scripts) have been totally re-written to tackle such a
drawback.
Web Development of a Cricket Progress File 50/89
Finally, my experience of this project reflected that documenting the prototype was the hardest of
the whole bit. The prototype keeps changing and so is the report. As a mater of fact, the report
shows an incremental evolution of the requirements where many facts have been discovered in later
stages (perhaps in the implementation stage). This could give the evidence that the prototyping
approach has been adopted successfully.
Web Development of a Cricket Progress File 51/89
References
[1] David M. Kroenke (c2002), Database processing : “fundamentals, design & implementation”,
Prentice Hall.
[2] http://www.powerasp.com/ [11/04/2002 7:30 PM]
[3] http://www.csis1.leeds.ac.uk/dbmodules/module_menu.asp?module=DB32 [11/04/2002 9:32
PM]
[4] http://msdn.microsoft.com/library/ [11/04/2002 11:12 PM]
[5] http://www.nicats.ac.uk/using/related.htm [19/06/2002 9:15 PM]
[6] Simon Bennett, Steve McRobb and Ray Farmer (2002), Object-Oriented Systems Analysis and
Design Using UML, McGraw Hill.
[7] Simon Bennett, John Skelton and Ken Lunn (2001), Schaum’s Outlines of UML, McGraw Hill.
[8] Thomas Connolly and Carolyn Begg (2002), Database Systems: “A Practical Approach to
Design, Implementation, and Management”, Addison Wesley.
[9] Lydia Lau (2001), COMP5050 Information Modeling (Lecture Handouts), University of Leeds-
School of Computing.
[10] http://www.december.com/web/develop/design.html [28/07/2002 7:30 PM]
[11] http://www.15seconds.com/faq/IIS%203.0/471.htm [23/08/2002 9:10 PM]
[12] A. G. Sutcliffe (1995), Human-Computer Interface Design, Macmillan press LTD.
[13] Edward Kit (1995), Software Testing in the Real World: “Improving the Process”, Addison
Wesley.
[14] Philippe Kruchten (1998), The Rational Unified Process: “An Introduction”, Addison Wesley.
Web Development of a Cricket Progress File 52/89
This project has made a significant contribution to my knowledge in Information Systems and/or
Information Technology in general. In fact, it is my first time developing an Information System
from scratch going through all system development life cycle phases, as well as dealing with
external people (i.e. people outside my organization). I could really achieve my strategy that I have
put into my mind before selecting my MSc. project, which was to select a project that can put the
chunks of knowledge I gained from the MSc. Information System modules into one container and
hence apply it, comprehensively, in practice.
In brief, the following are the set of benefits, skills and achievements I gained from this experience:
• Comprehensive knowledge of systems analysis, design and implementation skills.
• Knowledge of process and data modeling in both object oriented method and E-R technique.
• Knowledge of prototyping through the iterative development and user involvement.
• Skills of web development, particularly through learning and applying ASP in a professional
way.
• Solid knowledge of research and academic writing gained from the books I have consulted
as well as from the comments and the recommendations of my supervisors.
• Skills of professionalism gained from dealing with an external organization.
• Skills of communication, which is the key skill for the analyst, through the various meetings
and interviews I have conducted with my client.
• Skill of project, time and resources management gained from project planning task.
• Knowledge of politics. I believe that projects that have unclear set of requirements and
conflict of interests among stakeholders require politics. Although, I have never been
involved in such case before, I am quite proud of bringing this project to success.
• And last, but not least, learning cricket laws and knowing the necessary cricketing skills.
Who can believe that, before this project, I had never knew what on the earth is “Batting” or
“Wicket Keeping”?!
Web Development of a Cricket Progress File 53/89
This form must be completed by the student, with the agreement of the supervisor of each project, and submitted to the
MSc project co-ordinator (Mrs A. Roberts) via CSO by 21st March 2002. A copy should be given to the supervisor and
a copy retained by the student. Amendments to the agreed objectives and deliverables may be made by agreement
between the student and the supervisor during the project. Any such revision should be noted on this form. At the end of
the project, a copy of this form must be included in the Project Report as an Appendix.
*(if applicable)
20 40 20 15 5 100
* This category includes Professionalism
OVERALL OBJECTIVES:
• To use WWW to allow players to maintain their own sports progress reports.
• To produce online progress forms.
• To develop existing forms as necessary.
MINIMUM REQUIRMENTS:
3. To produce a working system available over the Internet.
DELIVERABLE(s):
1. A project report.
In this appendix, user and system requirements are brought together and maintained in one report to
act as a reference.
D.1.3 Objectives
• To use the Internet to allow the players maintain their own cricket progress files.
• To maintain the players’ various skills and achievement records into a database system so
that their progress can be monitored by themselves and by their coach.
• To improve the way the cricket progress file is being handled, and eliminate the need for the
coach to keep manual records.
• To facilitate the coach’s job by letting the players keep their own performance records
electronically and make them available to him at anytime.
• To provide a working prototype that would help in creating a standard cricket progress file.
D.2 Requirements
D.2.1 Stakeholders
• Player
• Coach
• Academic Tutor
• System Administrator
• Questionnaires
- Coach should be able to generate questionnaires and make them available to his players
on-line to be answered by them. He should also be able to view/collect the answered
questionnaire per each player.
- Academic tutor should be able to generate questionnaires and make them available to his
tutees (students) on-line to be answered by them. He should also be able to view/collect
the answered questionnaire per each player
- Players should be able to answer questionnaires provided by their coach and/or their
academic tutor. Questionnaires have varying purpose such like evaluating a training
programme or even self evaluation after a cricket match, on one hand. On the other
hand, questionnaires have academic purpose in a way that players are required to answer
a set of questions of how their cricket progress has contributed to their academic
achievement for a given period of time (a semester or an academic year for instance).
• System Administration
- System Administrator should be able to create user accounts on the system.
- System Administrator should be able to assign access roles to the users of the system.
- System Administrator should be able to alter user access information.
E nt e r Te x t C o m m e n ts a b o u t
F ill-in S c o res o f C ric k e t in g S k ills
P la y e r's P rog r e s s
Coac h
V ie w C ri c k e t in g P ro g re s s
P la y e r
S um m ar y V ie w /C o lle c t A n s w e re d
Q u s t io n n a ire
A c a d e m ic Tu t o r
C re a t e U s e r A c c o u n t A s s ig n Ac c e s s R o l e
S y s t em
A d m in is t ra t o r
Web Development of a Cricket Progress File 58/89
s ignIn( )
getAcc ountDetails( )
authorize( )
display ("URL" )
lis t Sk ill( )
fill-inSc ore( )
record Sc ore( )
: CP FHom e Pa ge : UserA ccount : Coac hHom eP age : P la yerDB : S kill : S co re : S umm ary
: Coach
signIn( )
getA ccountDetails( )
authorize( )
dis p lay("URL")
viewS um m ary( )
displayS um m ary ( )
getP layerID( )
getS c ore( )
listS kill( )
: CP FHom eP age : Us erA cc ount : Coac hHom eP age : Com m ent : P la y erDB
: Coach
s ignIn( )
getA c c ountDetails ( )
authoriz e( )
display("URL")
addTextCom m ent( )
: C P F H om eP age : U s e rA c c o u n t : C o a c hH om e P a g e : Q u e s t io n n a i re
: C oac h
s ig n In ( )
g e t A c c o u n t D e t a il s ( )
a u t h o r iz e ( )
d is p la y (" UR L " )
g en e r a t e Q u e s t io nn a ire ( )
c r e a t e N e w Q u e s t io n n a ire ( )
a d d Q u e s tio n ( )
s ign In ( )
auth oriz e( )
get D et ails ( )
ad dA ns w er( )
s i g n In ( )
g e t A c c o u n t D e t a i ls ( )
a u t h o r iz e ( )
d i s p l a y (" U R L " )
c o ll e c t Q u e s t i o n n a i re ( )
g etD e tails ( )
g e t P l a y e rID ( )
authoriz e( )
addUs er( )
S ign In S ign In
A uthoriz e A uthorize
S elec t a P lay er
List S k i ll
L ist S k i ll
S core against
the S k ill
V iew S um m ary
Figure D.8 Fill-in Scores of Cricketing Skills Figure D.9 View Cricketing Progress Summary
Web Development of a Cricket Progress File 64/89
S ign In
S ign In
A uthoriz e
A uthorize
S ave C om me nt
[ M ore ques tions to enter ]
S ave and E x it
[ No m ore play ers to s elec t ]
Figure D.10 Enter Text Comments about Figure D.11 Generate Questionnaire
Player’s Progress
Web Development of a Cricket Progress File 65/89
Sign In S ign In
Authorize A uthoriz e
Displ ay Coa c h
Display Player Hom e P age
Home Page
Se lect a Qu es tionnaire
Select a Questionnaire
Li s t P layer
List Questi on
S ign In
A uthorize
Dis p lay A dm in
Hom e P age
E nter U s er A c count
Inform ati on
Create Us er Record
The following is the description of tables and attributes of the database. Underlined attributes are
the primary key(s) of the table, while attributes printed in Italic face are the foreign key(s).
Attributes that are underlined and printed in Italic face are primary and foreign keys at the same
time.
E.1 Meetings/Interviews
Meeting Number: 1
Date: 20/03/2002
Time: 11:00 AM
Place: Leeds University
Attendees: Peter Rees Jones, UCCE Project Coordinator
Yousuf Al Hussaini, Leeds University
The meeting started with Peter Rees Jones welcoming me (Yousuf) and introducing himself. He then asked me about
my interest on this project. I replied him that I always find and interest in computer projects especially those requiring
dynamic web development. Peter then gave me a brief summary about the cricket game, its laws and the role of each
player on the pitch. He then introduced the UCCE (University Centre of Cricketing Excellence) and described its
functions. The main function of the UCCE is to develop students (players) skills and make them good excellent
cricketers.
Peter then continued his discussion by representing some manual documents (records) they are keeping to monitor
players performance. He said that during training and after every cricket matches, the coach and players and try to
record all performance or skills related aspects of their game to help players reflect, set themselves targets and apply
improvements to their game. The skills are divided into low-level skills (the behaviour of the player on the pitch) and
high-level skills (physical and mental related). The low-level and the high-level skills then linked together and a
summary page about each will be produced. Peter has expressed some of these paper records as a Currently they are
using Microsoft Excel Worksheet to store the related data. He also showed me some interesting graphical representation
diagrams. Those diagrams are set of circles and each circle is divided into sectors (representing the type of skills) and
tracks (each track represents performance in training or a cricket match).
We then talked about the project they want to develop. He represented to me a power point slides file describing his
idea of developing the progress file. This file suggests bringing all possible records together so that all relevant skills of
the player could by highlighted and his achievement could be monitored. The file also suggests linking low-level skills
to high-level skills to and then matched with the academic achievement of the player (student).
After Peter finished his description, I raised a couple of questions to him. The dialogue went as follows:
Yousuf: What is the relationship between the UCCE and the universities around such as
Leeds University?
Peter: The UCCE is dedicated for the students in Yorkshire universities: Leeds University,
LMU, Bradford University and Bradford College.
Yousuf: Who is in charge of the UCCE?
Peter: Kevin Sharp, the coach of the centre;
Jim Parry, Chairman of the School of Humanities, University of Leeds and the UCCE academic liaison officer;
Clive Souter, Director of Joint Honours Science, University of Leeds, responsible for electronic (information
technology) aspects,
Peter Rees Jones, Quality Management and Enhancement Unit, University of Leeds, centre project coordinator.
Yousuf: Could you describe briefly your objectives and requirements of the proposed web-
based progress file system?
Peter: Shared access between the players and the coach;
Shift performance recording process to the players;
Easy and global access to players’ information;
Link low-level skills with high-level skills;
Provide summary page covering player’s achievement (assessment);
Improves development of players’ skills;
Help players mature faster;
The facility to add/modify players’ records on-line;
The system development process should be iterative and the players will be involved
in this process.
Yousuf: Could you describe the organizational hierarchy of the UCCE?
Peter: There is no real hierarchy; the coach is leading the squad and the rest act as supportive/consultants.
Yousuf: Who is going to use the proposed system?
Peter: The coach (will be able to see all records) and the players (each will only be allowed to access his own record).
Web Development of a Cricket Progress File 71/89
At the end of the meeting, I gave a quick introduction about myself; as it was not possible to do this in the beginning,
since we rushed into discussion immediately. And then we greet each other and we agreed to see later on April.
Meeting Number: 2
Date: 03/04/2002
Time: 10:30 AM
Place: University of Leeds.
Attendees: Clive Souter, Director of Science Joint Honours, University of Leeds.
Peter Rees Jones, Quality management and Enhancement Unit,
University of Leeds, UCCE Project Coordinator.
Kevin Sharp, University of Bradford, UCCE Coach.
Andrew Siddall, UCCE Marketing and PR officer.
Yousuf Al Hussaini, University of Leeds.
This meeting was held to capture user requirements based on the agenda which I have introduced to the attendees at the
beginning of the meeting. Unfortunately, the requirements still have not been clearly stated by the client and another
meeting has been scheduled to take place on 26th of April, 10:30 AM in Clive’s office.
The meeting started with each individual introducing himself and then a long discussion about the requirements
followed.
Structure and details of the above file components is to be prepared by the client.
Roles of stakeholders
Player should be able to:
• Create and maintain his own cricket progress file.
• Receive coach’s comments on cricket progress file.
• Feedback on coach’s comments on cricket progress file.
• Create and maintain his own academic progress file.
• Receive academic tutor’s comments on academic progress file.
• Feedback on academic tutor’s comments on academic progress file.
• Create and maintain his own performance progress file.
• Receive coach’s comment on performance progress file.
Web Development of a Cricket Progress File 72/89
Functional requirements
• A database is to be designed to store file components and player’s relevant data.
• A web-based ‘working prototype’ is to be developed to interact with the database and to handle stakeholders’
roles/activities.
• A calendar of events is to be included in the prototype.
Security Requirements
• Player is allowed to access his own files/data only.
• Coach is allowed to access his players’ files/data only.
• Academic Tutor is allowed to access his tutees’ files/data only.
Technical Requirements
• The system is to be a database system with web interface front-end.
• No decision made yet about where to host the system.
• Database and scripting language to be used depend on the facilities provided by the host. Yousuf suggests
ASP/SQL Server.
Attendees:
• Kevin Sharp, Bradford/Leeds UCCE Coach;
• Peter Rees Jones, Academic Tutor;
• Andy Walker, Bradford/Leeds UCCE Cricket Player;
• Yousuf Al Hussaini.
Points discussed:
# Project progress;
I have demonstrated the new features I added to the system since our last meeting on the 2nd of August, which
are “Text Comments” and “Progress Summary”. The attendees will start using the system, (the coach already
did), to get used to it and to be able to spot and errors or suggest modifications.
Kevin (the coach) has suggested another way of keeping text comments to the player records. A report
Web Development of a Cricket Progress File 73/89
showing the different Roles of the cricket against subjective assessments to the skills (Tactical, Technical,
etc.). This has to be entered by the coach once every session or term (e.g. Christmas, Easter and Summer). This
is to be put as the main “Text Comment” screen and the existing one to be attached to it.
Kevin also suggested that he should be able to answer some questions of the questionnaires that are created by
himself, and so is Tutor.
# Prototype testing.
We agreed to run a workshop of user acceptance test on the 2nd of September. This workshop will involve the
coach, an academic tutor and a player. Scenario of the test workshop is to be created by me. The same people
who attended this meeting will turn in for the workshop.
Summary:
E.2 Questionnaires
Hi Yousuf,
I've made some comments against the questions you set out below: -
-----Original Message-----
From: Al Hussaini Yousuf [mailto:msczyka@comp.leeds.ac.uk]
Sent: 30 June 2002 17:21
To: Peter Reece Jones
Subject: Enquiries
Hi Peter.
I have started the implementation of the CPF prototype. I will try to get it ready for you to try it, in 10
days.
1- I should consider using graphics representation as an option. I need to know what specific data is
to be represented by the graphs, and in what format (shape) of graphs shall I produce?
I think that simple graphs would be a very good way of presenting information about how
performance is developing and whether it is consistent between different areas for a one to one
between coach and player. A stacked line graph with markers would show the relative trend in
several areas and make it easy to relate performance to particular times. It would be good to view
any skill within a single wagon wheel against any other single skill or against the average of skills for
that wheel (2 lines). Also it would be good to view any skill or average against any skill or average
on the other wheels (3 lines). I'm not clear how (or whether) a more detailed breakdown of an
individual skill (like toughness) could be plotted. You would also need to take account of skills within
wheels to which no score had been assigned so that they did not warp the average; I would suggest
discounting them.
This could give the player a view of their performance relative to indicators set by the coach, but it
might also be useful for the coach and player to be able to view the player against the average
performance of all players. (These 2 perspectives are used within the med school to look at the
Web Development of a Cricket Progress File 74/89
assessed performance of students in 5 key skills.)
It is important that Kevin gives his view on this and I would suggest simply being able to illustrate
the approach in the first para to Kevin for his feedback before going further.
2- Is there any other type of skills apart from what I got from you (those represented by wagon
wheels). If there is, to what they belong (e.g. physical, mental, technical, tactical)?
The wagon wheels cover a particular domain of skills relevant to cricket. It would be useful to look
at how a skill like 'toughness', which is represented on the wagon wheel could be further analysed by
the player and the coach.
There will be further skills in the domain of skills relevant to cricket which have not been specified.
By resolving the problem of the 'wagon wheel' skills you will make it easier to take account of further
skills. I am not sure that you should go beyond the 'wagon wheel skills' and Clive would be well
placed to advise on what is practicable given the other parts of the project.
I promised to provide a standard set of prompts which might be used by the player to articulate the
value of the generic skills he is acquiring in cricket to the tutor and added to the University Progress
File. (In other words express the value of the skills acquired by the student in the cricket domain in
general terms which can be understood in the academic domain). This will be a single side of A4 for
each level of study.
I think its important that we now meet, so I am copying this email to Clive and Kevin. I am free all
the week beginning the 8th except the Wednesday the 10th and Monday the 15th.
Best Wishes
Peter
Please provide me with a deep clarification for the 1st point particularly.
Thanking you.
Yousuf.
Web Development of a Cricket Progress File 75/89
Web Development of a Cricket Progress File 76/89
This document is a template setting out the broad structure of the Progress File for the Bradford
Leeds UCCE. Page 3 simulates a home page from which hot links lead on to definitions of the structure
of the progress file given in red italic with some illustrative material.
Stakeholders: -
The following types of people will draw upon the Progress File: -
• The player, who will complete the performance logs provided within the progress file, use them to
review and reflect on how performance may be improved in terms of higher level skills;
• The coach, who is responsible for the design of the progress file as a means by which players can
take increasing responsibility for their own development and as a basis for reviewing players
performance in one to ones and setting targets;
• The academic tutor, who needs to be aware of the importance of cricket to the students personal
and academic development to deal with practical issues, such as the need to reconcile sporting and
academic timetables, and in providing references to employers.
The progress file will be used by cricketers to log their performance and review with their coach the
higher level skills, such as concentration, they need to bring to bear in order to improve their
performance. This is the primary function of the progress file. The qualities this develops in players
are relevant to their personal and academic development and a secondary function of the progress file
is to communicate the value of this to the Academic Tutor in the terms used by the generic University
Progress File.
Data about performance and skills will be input by the player and reviewed by the player and the
coach either of whom may add comments into text fields. The player will add further text into a form
derived which can readily be used to complete the University's generic progress file and this subset of
data may be used as a basis for discussions between the player and their University tutor.
Web Development of a Cricket Progress File 77/89
Web Development of a Cricket Progress File 78/89
<%else
' record scores
my_counter = Request.Form("skillcounter")
conn.BeginTrans
for i = 1 to my_counter
my_skillid = Request.Form ("skill" & i)
my_score = Request.Form ("score" & i)
my_sql = "insert into score (playerid, skillid, scoreval, updatedate) "
my_sql = my_sql & "values(" & my_playerid & "," & my_skillid & "," & my_score & ",'" & date() & "')"
if (my_score <> "") then
conn.Execute my_sql
end if
next
conn.CommitTrans
conn.close
set conn = nothing
' move to next set of skills
my_nextset = Request.QueryString("rolecode")& Request.QueryString("skilltypecode")
select case my_nextset
case "BATTECTAC" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=PHYS")
case "BATPHYS" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=MENT")
case "BATMENT" Response.Redirect ("score.asp?rolecode=BAT&skilltypecode=TOUG")
case "BATTOUG" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=TECTAC")
case "BPTECTAC" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=PHYS")
case "BPPHYS" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=MENT")
case "BPMENT" Response.Redirect ("score.asp?rolecode=BP&skilltypecode=TOUG")
case "BPTOUG" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=TECTAC")
case "BSTECTAC" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=PHYS")
case "BSPHYS" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=MENT")
case "BSMENT" Response.Redirect ("score.asp?rolecode=BS&skilltypecode=TOUG")
case "BSTOUG" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=TECTAC")
case "FLDTECTAC" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=PHYS")
Web Development of a Cricket Progress File 80/89
case "FLDPHYS" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=MENT")
case "FLDMENT" Response.Redirect ("score.asp?rolecode=FLD&skilltypecode=TOUG")
case "FLDTOUG" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=TECTAC")
case "WKTECTAC" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=PHYS")
case "WKPHYS" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=MENT")
case "WKMENT" Response.Redirect ("score.asp?rolecode=WK&skilltypecode=TOUG")
case "WKTOUG" Response.Redirect ("player.asp")
end select
end if%>
To
<select size="1" name="to">
<%rs.Open
while not rs.EOF
my_option = ""
my_request = "'" & Request.Form("to") & "'"
my_date = "'" & rs("updatedate") & "'"
if (my_date = my_request) then
my_option = "selected"
end if
my_updatedate = day(rs("updatedate")) & "/" & month(rs("updatedate")) & "/" & year(rs("updatedate"))%>
<option value="<%=rs("updatedate")%>" <%=my_option%>> <%=my_updatedate%> </option>
<%rs.moveNext
wend
rs.Close%>
</select></p>
<p><input type="submit" value="View Summary" name="view"></p>
</form>
<%
' Error handling
' on error go to error_handler
' Connection to DB
Set conn = Server.CreateObject("adodb.connection")
conn.ConnectionTimeout = 0
Conn.ConnectionString = "Provider=SQLOLEDB.1;" & _
"Persist Security Info=False;" & _
"User ID=********;" & _
"Password =*******;" & _
"Initial Catalog=CPF;" & _
"Data Source=CSMS2"
'error_handler:
' set err = Server.GetLastError()
'if (err.number <> 0 ) then
'Response.Write err.description
'end if
%>
Web Development of a Cricket Progress File 85/89
The following are the steps required to install the CPF prototype or to move it into a new host
server. An electronic copy of the directories/files described below will be packed and handed to the
client.
Step 1: Copy the cpf entire directory under the active directory of the IIS server (e.g.
C:\InetPub\wwwroot).
Step 2: Create a new database in the SQL Server and call it CPF.
Step 3: Open the SQL Query Analyzer utility and run the script cpf.sql that is located under the
directory export (the script may also be copied and pasted). This should create the database table
structure. 13 tables should have been created as a result of this step, which are USERACCOUNT,
COACH, PLAYER, TUTOR, ROLE, SKILL_TYPE, SKILL, SCORE, COMMENT, QUESTIONNAIRE,
QUESTIONNAIRE_BODY, and PLAYER_QUESTIONNAIRE.
Step 4: Import the data of the lookup tables into the CPF database. Use append table option to
avoid recreating the tables. The import files are located under the export directory and named
role.txt, skill_type.txt and skill.txt. They should also be imported in the same order respectively.
Step 5: Create a new user with a password in the CPF database and grant him full access (i.e.
select, insert, update, delete) on all tables of the CPF database.
Step 6: Modify the following lines of the script connection.asp that is located under the cpf
directory:
"User ID=********;" & _ Replace the stars with the user id you have created in Step 5.
"Password =*******;" & _ Replace the stars with the password you have assigned to the
user you have created in Step 5.
"Initial Catalog=CPF;" & _ If you named the database as CPF then ignore this line,
otherwise, replace CPF with the database name you have
created in Step 2.
"Data Source=CSMS2" Replace CSMS2 with your IIS Server/Machine name.
Step 7: Open the database table USERACCOUNT and add a new user account entry. This user is
supposed to be the System Administrator of the CPF. Type ADMIN in the ACCESSROLE field.
This user account should be used to create other user accounts, through the website.
Step 8: Test the prototype from your browser (IE or NN). Type <<machine name, domain name or
the IP address>> of your IIS Server proceeded by /cpf in the address bar. The log-in page should
be displayed. Use the useraccount/password created in Step 7 to login to the system and to create
the rest of the user accounts, including coach, players and tutors with the appropriate access role.