web development of a cricket progress file yousuf al ...€¦ · i summary this project is intended...

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.

Web Development

of a Cricket Progress File

Yousuf Al Hussaini MSc. Information Systems

(2001/2002)

i

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.

ii

Acknowledgement I would like to take this opportunity to thank all of the following:

- 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.

iii

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

iv

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

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

The Bradford/Leeds Cricketing Centre of Excellence is a member of the University Centres of

Cricketing Excellence (UCCE). The centre is located in Bradford City and dedicated to the students

from west Yorkshire universities, i.e. University of Bradford, Bradford College, University of

Leeds and Leeds Metropolitan University. The main task of the centre is to train and educate the

players (students of west Yorkshire universities) on cricketing skills, both physical and mental. The

mission of the centre is to help players mature faster and become excellent professional cricketers.

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

The objectives of this project are:

• 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 any time.


• To provide a working prototype that would help in creating a standard cricket progress file.

1.3 Minimum Requirements

The minimum requirements of this project are:

• Design of a database system using SQL Server database.

• Development of an interactive web interface with Active Server Pages and HTML.

1.4 Deliverables

The deliverables of this project are:

1. A project report.

2. A working prototype of �a database system accompanied by a web front-end�.

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.

1.6 Development Approach

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


use of Entity-Relationship modeling diagrams; as the underlying database is relational. An iterative

approach is demanded for construction of an evolutionary prototype. The prototype will give the

user/client the chance to be involved in the development stages and therefore help him express his

full requirements as the development progresses. It will also help the developer understand the

actual user requirements and enable him to accommodate them into the system.

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.


Figure 1.1 Iterative System Development Life Cycle. Adapted from [6]

1.7 Project Schedule

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.

Requirement Analysis

Requirement Specifications

Prototype Design

Prototype Implementation

Test & Evaluation

Next Iteration


Date Period Task Accomplished

March 2002 - Background research.

- Problem investigation.

April-May 2002 - Requirement gathering.

- Requirement analysis and specifications.

June 2002 - Write up of Chapter 1 (Introduction).

- Write up of Chapter 2 (Requirement Capture).

- Start first iteration of the prototype.

July 2002 - Continue first iteration of the prototype.

- Write up of Chapter 3 (Requirement Analysis).

- Write up of Chapter 4 (Prototype Design).

- Release of first iteration of the prototype.

Beginning-Mid

Aug 2002

- Write up of Chapter 5 (Prototype Implementation).

- Start second iteration of the prototype.

Mid August-5th of

September 2002

- Release second iteration of the prototype.

- Write up of Chapter 6 (Evaluation).

- Write up of Chapter 7 (Summary).

- Report review, sum-up and delivery.

- Review and delivery of the prototype.

Table 1.1 Project Schedule

1.8 Literature Review of Tools/Techniques

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.

1.8.1 System Architecture

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


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]

Figure 1.2 Three-tier Architecture. Adapted from [1].

1.8.2 Active Server Pages (ASP)

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.

Browser

Browser

Browser

Web Server

Database Server

Netscape Navigator/ Internet Explorer

Microsoft IIS, Windows 2000

SQL Server, Windows 2000

SQL Requests

HTTP Requests


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

Figure 1.3 ASP Architecture and Work Mechanism [3]

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.


- Application: to share application-level information and control settings for the lifetime of

the application.

1.8.3 SQL Server

The SQL Sever description in this section is provided by [4].

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.

Figure 1.4 Components of a Database [4]

The database in the SQL Server has two different database components (see Figure 1.5):


• 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 SQL Server Architecture [4].

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.


Chapter 2: Requirement Capture

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.

2.1 What is a Progress File?

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�.

2.2 The Cricket Progress File (CPF)

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


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.

2.3 Information Gathering

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.

2.4 System Requirements

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


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:


• Characteristics of the users who will use the system.

• The tasks that the users undertake, including the goals that they are trying to achieve.

• Situational factors that describe the situation that could arise during system use.

• Acceptance criteria by which the user will judge the delivered system.� [6]

2.4.1 The Current CPF System

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.

PlayerInterview Player

Record Performance Progress

Coach

Figure 2.1 The Current CPF System

2.4.2 The Proposed CPF System

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.


Maintain Cricket Progress File

Coach

Academic Tutor

Player

Monitor Cricket Progress File

Figure 2.2 Overall-View Use Case Diagram of the New CPF System Requirements


Chapter 3: Requirement Analysis

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).

3.1 The Detailed Use Case Diagram of the CPF

�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.


Create User AccountSystem Administrator

Delete Questionnaire Modify Questionnaire

As sign Access Role

<<inc lude>>

Alter User Account Information

<<extend>>

Fill-in Scores of Cricketing Skills

Answer Questionnaire

Player

Enter Text Comments about Player's Progres s

View Cricketing Progress Summary

Coach

Generat e Ques tionnaire

<<extend>> < <ex tend>>

Academic Tutor

View/Collect Answered Qustionnaire

<<extend>>

Figure 3.1 The Detailed Use Case Diagram of the CPF system

3.2 Use Case Description

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).


Use Case Name Actor(s)

Involved

Description Possible Candidate

Classes

1. Fill-in Scores of

Cricketing Skills

Player Player records his cricketing skills

regularly (once a week or so). He has to

fill-in/select the score against each

particular listed skill. The score value is

defined in the range 1-10.

Player, Skill, Score

Table 3.1 Description of the Use Case �Fill-in Scores of Cricketing Skills�

3.3 Modeling the Interaction

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.

dis play ("URL")

: P lay er : CP FHom eP age : Us erA c count : P lay erHom eP age : S k ill : S c ore : P la y erDB

s ignIn( )

getA c c ountDetails ( )

authoriz e( )

l is t S k ill( )

r ecord Sc ore( )

fill-inS c ore( )

get P lay erID ( )

Figure 3.2 Sequence Diagram for the Use Case �Fill-in Scores of Cricketing Skills�


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.

CPFHom ePage

authorize()s ignIn()

PlayerHom ePage

display()fill-inScroe()answerQuestionnaire()

PlayerDB

getP layerID()

UserAccount

getAccountDetails()addUser()

Questionnaire

c reateNewQuest ionnaire()a ddAnswer( )a ddQu estion()g etDet ail s()

Score

recordScore()getScore()

Skill

lis tSkill()addTextComment()

Figure 3.3 Part of Concept-Level Class Diagram Resulted from

the Sequence Diagram in Figure 3.2

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).


A dm inH om e P a ge

d is p lay ()c rea te Us erA c c o unt ()

C P F H om e P a ge

au th oriz e()s ign In()

P la y erH om eP a ge

d is p lay ()fi ll- in S c r oe( )ans we rQ u es t ionn a ire( )

C oa c hH om eP age

d is p la y ()view S um m ary ()g ene ra te Q ues tion na ire()c o l lec tQ u es t ionn a ire ()e nterTex tCo m m ent ()

U s e rA c c ou nt

ge tA c c oun tDe ta ils ()ad dU s er()

Q ues t ion na ir e

c reate Ne wQ u es t io nna ir e()a d dA ns w er( )a d dQ ues ti on( )g e tD et a il s( )

S k il l

lis tS k i ll ()

S u m m ary

d is p lay S um m a ry( )

S c ore

rec o rd S c ore()ge tS c o re()

C oac hD B

C om m en t

a ddTex tC om m e nt ()

P lay erDB

g etP lay erID ()

Figure 3.4 Concept-Level Class Diagram of the CPF System

3.4 Modeling System Functionalities

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).


S ig n In

[ In v a lid u se rn a m e /p a s s w o r d ]

Di s p la y P l a y er H o m e P a g e

[ V a lid u s e rn a m e /p a s s w o rd ]

A u th o riz e

L is t S k i ll

S c o re a g a in s t t h e S k il l

R e c o rd S c o re s

[ M o re s k il l s to l is t ]

[ N o m o re s k il ls to l is t ]

Figure 3.5 Activity Diagram for the Use Case �Fill-in Scores of Cricketing Skills�


Chapter 4: Prototype Design

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.

4.1 Moving from Analysis to 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.


AdminHom ePage

display()createUserAccount()

<<W eb P age>>

CPFHom ePage

authorize()s ignIn()

< <W eb Page>>

11

11

CoachHomePage

display()viewSumm ary()generateQues tionnaire()collectQuestionnaire()enterTextComment()

<<W eb Page>>

1

1

1

1

PlayerHom ePage

display()fill-inScroe()answerQuestionnaire()

<<W eb Page>>

0..n1 0..n1

Questionnaireqidqtitlec reationdateavailableanswered

c reateNewQues tionnaire()addAnswer()addQuestion()getDetails()

Skillskillidskillname

listSkill()

Summary

disp laySum mary()

Score

value

recordSc ore()ge tScore()

0.. n

1

0.. n

1

0..n0.. n 0..n0.. n

P lay erDBplayeridplayernamedobinstitutioncourse

getPlayerID()

1

1

1

1

0..n

0..n

0..n

0..n

0..n

1

0..n

1

Comment

addTextComment()

1

0.. n

1

0.. nCoachDB

coachidcoachname

1

1

1

1

0..n

1

0..n

1

0. .n

1

0. .n

1

1 0.. n1 0.. n

TutorDB

tutoridtutorname

0 .. n

1

0 .. n

1UserA ccount

useridusernamepasswdaccessrolestatus

getAccountDetails()addUser()

1

1

1

1

11

11

11

11

Figure 4.1 Detailed Class Model of the CPF Prototype

Class Name ASP/HTML DatabaseCPFHomePage !AdminHomePage !PlayerHomePage !CoachHomePage !UserAccount !PlayerDB !CoachDB !TutorDB !Skill !Score ! !Questionnaire ! !Comment ! !Summary !

Table 4.1 Possible Different Forms of the Mapped Classes


4.3 Software Architecture of the CPF Prototype

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.

Application Layer

Data Layer (SQL Server Database Tables)

Presentation Layer (HTML/ASP User Interfaces)

Data Connectivity ADO/OLE-DB

Score

Skill Questionnaire

HTTP Requests

CPFHomePage

AdminHomePage PlayerHomePage CoachHomePage

(ASP Dynamic Scripts) Score Questionnaire Summary

CoachDB PlayerDB

UserAccount TutorDB

Figure 4.2 Software Architecture of the CPF Prototype

Comment

Comment


4.4 Database Design

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).

4.4.1 The E-R Model-Overall View

�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.

Figure 4.3 First Cut E-R Model of the CPF Prototype

COACH PLAYER

SKILL

QUESTIONNAIRETUTOR

USERACCOUNT

1

11

1

1

1

0..M

0..M

0..M

0..M

0..M

0..M

0..M

1

has has

coaches

generates answers

tutors possesses

has

1

1

COMMENT

writes 10..M

0..M

1 views


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.

4.4.3 The E-R Model-Detailed View

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:


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.

Figure 4.4 Example of Skill Categorization

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:

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:

Questionnaire Formatting: Questionnaire is a complex entity. It contains set of questions. This

has to be broken down to avoid multi-valued dependency. Therefore, questions should be placed in

a separate entity say Questionnaire_Body. Questionnaire is to be answered by players later on, and,

likewise, the answers of the Questionnaire should be placed into another entity say

Player_Questionnaire. This would also resolve the Player-Questionnaire M2M relationship. Below

is the E-R segment resulting from this formatting process:

Batting

Technical & Tactical - Hitting over the Top - Versus Spin - Running between Wickets

Physical - Speed - Strength - Flexibility

Mental - Confidence - Toughness - Awareness

Skills

Skill Type

Role

PLAYER SCORE SKILL 1 0..M 0..M 1 records against

ROLE SKILL SKILL_TYPE 1 0..M 0..M 1 belongs to has


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).

Figure 4.5 The Full E-R Model of the CPF Prototype

PLAYER PLAYER_QUESTIONNAIRE

QUESTIONNAIRE1 0..M 1 answers

QUESTIONNAIRE_BODY

1

0..M

contains

contains 0..M

COACH PLAYER

SKILL

QUESTIONNAIRE

TUTOR

USERACCOUNT

1

11

1

1

10..M

0..M

1

0..M

1

0..M

0..M

1

has has

coaches

generates answers

tutors

records

PLAYER_QUESTIONNAIRE

QUESTIONNAIRE_BODY

contains1

0..M

0..M 1 contains

SCORE

0..M

1

against

SKILL_TYPE 0..M 1has

ROLE

0..M

1

belongs to

1has

1 COMMENT

writes 10..M

0..M

views 1


4.4.4 The Relational Model

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.

Figure 4.6 Relational Model of the CPF Prototype


4.5 User Interface Design

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.

4.5.1 Web Design

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


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.7 Main Components of the CPF Website

Figure 4.8 Screen Shots of Two Sections from Player�s Home Page

CPF Home Page

Player�s Home Page

Coach�s Home Page

Admin�s Home Page


Chapter 5: Prototype Implementation

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.

5.1 Database Creation

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.

5.2 Website Construction

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.

Figure 5.1 The Website Dynamic Structure of the CPF

5.2.1 Controlling Appearance and Access

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;



The connection.asp file consists of the following:

• A style sheet design to initialize font and link behaviors of web pages; <style> A:link, A:active { text-decoration : none; color : #008080 ; background : transparent; } A:visited { color : #008080 ; background : transparent; text-decoration : none; } A:hover { color : white; background : #008080 ; } </style>

• A connection object that connects the users to the CPF database; <% 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"

• A sub-routine that controls users� access to the web pages; 'This sub program verifys accessability of users to a specific page Sub VerifyAccess (p_accessrole) if session("accessrole") <> p_accessrole then Response.Write "<b> Access to this page is denied. Please contact the web site administrator! </b>" Response.End end if end sub

%>

5.2.2 Signing-in to the CPF

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.


Figure 5.2 The Start-up (Sign-in) Page of the CPF Prototype

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;

• COACH: if the user is a coach;

• TUTOR: if the user is an academic tutor; and

• ADMIN: if the user is the system administrator.

The code segment of the sign-in process can be found in Appendix F, Section F.1. 5.2.3 CPF System Administration

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.


Figure 5.3 System Administration Page Options

5.2.4 Scoring against Cricketing Skills

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).


Figure 5.4 Screen Shot of a Scoring Scenario

5.2.5 Commenting on Player�s Performance

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 ' add new comments to DB if (Request.Form("commenttext") <> "") then my_text = Server.HTMLencode(Request.Form("commenttext")) my_sql = "insert into comment (commenttext, coachid, playerid, entrydate) values('" my_sql = my_sql & my_text & "'," & my_coachid & "," & my_playerid & ",'" & date() & "')" conn.Execute my_sql end if%>


Figure 5.5 Screen Shot of Entering Text Comments

5.2.6 Monitoring Progress

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"))%>


<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 ).


• A statistical summary of the overall average score across the date period (see Appendix F, Section F.7 for the code segment).

Figure 5.6 Screen Shot of Monitoring Progress (Coach Options)

Figure 5.7 Screen Shot of Monitoring Progress (Players Options)


5.2.7 Managing Questionnaires

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.

Action Script Name User Responsible

Generate Questionnaire questionnaire.asp Coach, Tutor

Modify Questionnaire questionnaire.asp Coach, Tutor

Delete Questionnaire questionnaire.asp Coach, Tutor

Answer Questionnaire qanswer.asp Player

View Answered Questionnaire qview.asp Coach, Tutor

Table 5.1 Actions Performed on Questionnaires

Figure 5.8 Screen Shot of questionnaire.asp Page

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


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.

Figure 5.9 Screen Shots of Questionnaire Generation Steps

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.


Figure 5.10 Screen Shots of Questionnaire Modification Steps

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.

Figure 5.11 Screen Shot of Questionnaire Deletion Scenario


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.

Figure 5.12 Screen Shots of Questionnaire Answering Scenario

View Answered Questionnaire: A questionnaire, after answered by the players, is to be collected

by the coach (or perhaps by the academic tutor if he has created it). By using the qview.asp script,

the coach would be able to view any answered questionnaire. After selecting a questionnaire, the

questions and the answers of that questionnaire will be viewed on a new window. The answers will

be displayed as one screen per player. The coach can scroll to the different players by clicking on

�Next >>� that allows him to view the next set of a player�s answers. The scenario is shown in

Figure 5.13.

Figure 5.13 Screen Shot of Viewing Answered Questionnaire Scenario


5.3 User Input Validation

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; }

2. The ASP code segment of the second scenario;

'Check to see if this userid is already in use rs.Source = "Select userid from useraccount where userid = '" & my_id & "'" rs.Open if not rs.EOF then userfound = 1 end if rs.Close set rs = nothing if (Request.Form("userid") <> "" and userfound <> 1) then%> <font color="#008080" face="Arial"><br><b>User <%=Request.Form("userid")%> has been created! </b><br></font> <% elseif (userfound = 1) then%> <font color="red" face="Arial"><br><b>Error: User <%=Request.Form("userid")%> already exists! </b><br></font> <% end if %>

Figure 5.14 Screen shots of User�s Input Validation Scenarios


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.

6.1 Meeting the Objectives

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.


6.2 Meeting the Requirements

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.

Fill -in Scores of Cri cket ing S ki ll s

Answer Q uest ionnaire

Player View Cricketing Progress Summary

Figure 6.1 Meeting Player�s Requirements



Enter Text Comments about Player's Progress

View Cricketing Progress Summary

Generate Questionnaire

<<extend>> <<extend>>

Coach


<<extend>>

Figure 6.2 Meeting Coach�s Requirements

Figure 6.3 Meeting Academic Tutor�s Requirements


Generate Questionnaire

<<extend>> <<extend>>


<<extend>>

Academic Tutor


System Administrator

Create User Account

Alter User Account Information

<<extend>>

<<include>>

Assign Access Role

Figure 6.4 Meeting System Administrator�s Requirements

6.3 User Acceptance Test

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,


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.

6.4 Suggestions for Further Improvement

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:

• While it is desirable to adopt Microsoft development tools to implement an iterative

prototype, the resulting end-product will be hardware/software dependent. The CPF

application is limited to run under Microsoft platform only.

• User errors in the CPF prototype are minimized and handled on the application (business

code) level. Unfortunately, the ASP version running in the School of Computing IIS Server

is 2.0 which does not have the facility to handle system errors and/or server errors

appropriately. The solution of handling system and server errors has already been

incorporated in the connection.asp script file. The line codes for handling such errors has

been remarked (commented). The remark signs must not be removed unless ASP is

upgraded to version 3.0 or to the latest release which is ASP.NET. The full listing of

connection.asp script can be found in Appendix F, Section F.10.

• The client has to find a system administrator that has the capability of maintaining and

upgrading the system. Knowledge of SQL Server and ASP is demanded.

• The client has to find an ISP who can host the system. This issue has been raised before the

development has started and still has not been resolved yet. A commercial ISP host was

recommended (see Section 1.5). List of the top ASP/SQL Server hosts can be found at:

http://www.webhostsearch.info/Search/ASPHosting.asp.

• Iterative prototyping requires rapid development. The use of powerful web development

tools such as �Dreamweaver MX� (http://www.macromedia.com/software/dreamweaver/) to

speed up the process is highly recommended.


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.


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.


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.


Appendix A: Reflection upon the Project Experience

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�?!


Appendix B: Objectives, Deliverables and Agreed Marking Scheme School of Computing, University of Leeds

MSC PROJECT OBJECTIVES AND DELIVERABLES

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.

Student: Al Hussaini, Yousuf Khamis

Programme of Study: MSc Information Systems

Supervisor: Peter Mott

Title of project: Web Development of a Cricket Progress File

External Organisation*: Bradford/Leeds Centre for Cricketing Excellence

*(if applicable)

AGREED MARKING SCHEME

Understand the Problem

Produce a Solution *

Evaluation Write -Up Appendix A TOTAL

%

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.

SOFTWARE AND HARDWARE RESOURCES REQUIRED:

DELIVERABLE(s):

1. A project report.

2. On-line database system with web front-end.

Signature of student: Date:

Signature of supervisor: Date:


Appendix C: A Copy of the Interim Report Header Sheet


Appendix D: Requirement Specifications Report

In this appendix, user and system requirements are brought together and maintained in one report to act as a reference. D.1 Problem Definition D.1.1 Problem Statement The Bradford/Leeds UCCE wants to improve the way of monitoring the players� cricket progress file by the implementation of a database solution with a web front-end.

D.1.2 Vision Statement Help players mature faster to become excellent cricketers. 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

D.2.2 Functional Requirements from User�s Perspective • Player�s Personal Profile

- Player should be able to alter his personal information like password, name, institution, coach, tutor, etc.

• Player�s Performance Record - Player should be able to fill-in scores about his cricketing skills. The skills are defined as

per the �Wagon Wheels� provided by the UCCE (see Appendix E, Section E.3). The scores are defined as 1-10 (poor-excellent) range.

- Coach should be able to enter text comments on a particular skill of his player(s). - Player should be able to read the text-comments feedback of his coach on a particular

skill or in general. • Player�s Progress

- Player should be able to view a statistical average summary, in a given period of time, of his skills development. The summary is to be supported by a line graph.

- Coach should also be able to view a statistical average summary, in a given period of time, of the skills of his players. The summary is to be supported by a line graph.


• 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.

D.2.3 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. • System Administrator has unlimited access.

D.2.4 Technical Requirements

• The system is to be a database system with web interface front-end. • The database is to be developed under SQL Server, and the scripting language to be used for

the web development is ASP. • No decision made yet by the client about where to host the system.

D.3 Use Case Requirement Model D.3.1 Use Case Diagram

Create U s er A cc ountS y s tem A dm in is t ra tor

Dele te Q ues tionnaire M odify Q ues t ionnaire

A s s ign Ac c es s Rol e

< < inc lude> >

A lter Us er A c c ount Inform at ion

< < extend> >

F ill-in S c ores o f Cric k et ing S k ills

A ns wer Q ues tionnaire

P lay er

E nter Tex t Com m ents about P lay er's P rogres s

V iew C ric ket ing P rogress S um m ar y

G enerate Q ues t ionnaire

< < ex tend> > < < ex t end> >

Coac h

V iew /C ollec t A nsw ered Q us t ionnaire

< < ex tend> >

A c adem ic Tutor


D.3.2 Use Case Description

Use Case Name

Actor(s) Involved

Description Possible Candidate Classes

1. Fill-in Scores of Cricketing Skills

Player Player records his cricketing skills regularly (once a week or so). He has to fill-in/select the score against each particular listed skill. The score value is defined in the range 1-10.

Player, Skill, Score

2. View Cricketing Progress Summary

Player, Coach Player can monitor his progress of skills development by selecting the option that should provide various types of statistical summaries. Coach can also do so and view summaries of his own players.

Player, Coach, Skill, Summary

3. Enter Text Comments about Player�s Progress

Coach Coach can provide feedback regarding the development progress of his player(s) by entering a text comment against his cricketing skills or in general.

Coach, Player, Skill, Comment

4. Generate Questionnaire

Coach Coach can create new questionnaire by navigating into the questionnaire feature that will be provided by the system and selecting �new questionnaire� option.

Coach, Questionnaire

5. Modify Questionnaire

Coach Coach can modify existing questionnaires, created by him, by navigating into the questionnaire feature that will be provided by the system and selecting �modify questionnaire� option.


6. Delete Questionnaire

Coach Coach can delete existing questionnaires, created by him, by navigating into the questionnaire feature that will be provided by the system and selecting �delete questionnaire� option.


7. Answer Questionnaire

Player Player is to answer questionnaires generated by his coach and/or tutor by entering text of answers against each question of the questionnaire.

Player, Coach, Questionnaire

8. View/Collect Answered Questionnaire

Coach Coach can view/collect answered questionnaire(s) that should be made available to him whenever a questionnaire, created by him, has been answered.


9. Create User Account


System Administrator is responsible for creating accounts for any user of the system. He should type a user Id, a user name and a password for the user to be created in the interface that will be provided by the system.

System Administrator, User Account

10. Assign Access Role


System Administrator is to assign access role for the user he creates according to the type of user.


11. Modify User Account Information


System Administrator can modify any user account information by viewing existing user account and make necessary modifications.

System Administrator, User Account


D.4 Analysis and Design Model

D.4.1 Interaction Diagrams

: Player : CPFHomePage : UserAccount : P layerHomePage : Skill : Score : P layerDB

s ignIn( )

getAccountDetails( )

authorize( )

display ("URL")

lis t Sk ill( )

recordSc ore( )

fill-inScore( )

get P lay erID( )

Figure D.1 Fill-in Scores of Cricketing Skills

: Coach : CPFHomePage : UserA ccount : Coac hHomePage : P layerDB : Skill : Sco re : Summary

signIn( )


authorize( )

dis p lay("URL")

viewSummary( )

displaySummary ( )

getPlayerID( )

getSc ore( )

listSkill( )

Figure D.2 View Cricketing Progress Summary


: Coach : CPFHomePage : UserA ccount : CoachHomePage : Comment : P la yerDB

signIn( )


authorize( )

display("URL")

enterTextComment( )

getPlayerID( )

addTextComment( )

Figure D.3 Enter Text Comments about Player�s Progress

: C o a c h : C P F H o m e P a g e : 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

s ig n In ( )

g e t A c c o u n t D e t a i l s ( )

a u t ho r iz e ( )

d i s p l a y ( " U R L " )

g en e r a t e Q u e s t i o nn a i re ( )

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 t i o n ( )

Figure D.4 Generate Questionnaire


: P layer : CP FHom eP age : UserA cc ount : P lay erHom eP age : Q ues t ionnaire

s ignIn( )

getA ccountDetails ( )

auth orize( )

disp lay ( "URL")

answerQ ues tionnaire( )

addA ns wer( )

getDetails ( )

Figure D.5 Answer Questionnaire

: C o ac h : C P F H o m eP a ge : U s e rA c c ou n t : C o ac h H o m eP a ge : Q u e s t ion n a ire : P la y e rD B

s ign In ( )

g e tA c c o u n tD e ta i ls ( )

a u th o r iz e ( )

d is p lay (" U R L" )

c o lle c tQ u e s t io nn a ire ( )

g e tD e ta i ls ( )

g e tP lay e rID ( )

Figure D.6 View/Collect Answered Questionnaire


: Sy s tem A dm inis trator

: CPFHom eP age : UserAc c ount : A dm inHom ePage

s ignIn( )

getA c countDetails ( )

authoriz e( )

display(" URL" )

c reateUs erA cc ount( )

addUs er( )

Figure D.7 Create User Account


D.4.2 Activity Diagrams

Sign In

[ Invalid username/password ]

Authorize

List Ski ll

[ More s k il ls t o l is t ]

Display Player Home Page

[ Valid username/password ]

Score against the Skill

Record Scores

[ No more sk ills to lis t ]

Figure D.8 Fill-in Scores of Cricketing Skills

Sign In


Display Coach Home Page


Authorize

L ist Sk i ll

Get the Score

View Summary

Select a P layer

[ More ski ll s to lis t ]

[ No more sk ills to lis t ]

Figure D.9 View Cricketing Progress Summary


Sign In


Authorize

Select Player

[ More players to select ]



Enter Text Comment

Save Com ment

[ No more players to select ]

Figure D.10 Enter Text Comments about

Player�s Progress

Sign In


Authorize

Enter Questionnaire Header Information


[ Valid usernam e/password ]

Enter a Question

Save and Exit

[ No more questions to enter ]

[ More questions to enter ]

Figure D.11 Generate Questionnaire


Sign In


Authorize

Select a Questionnaire

Display Player Home Page


List Question

[ More questions to list ]

Save and Exit

Enter Answer

[ No more questions to list ]

[ More questions t o answer ]

[ No more questions t o answer ]

Figure D.12 Answer Questionnaire

Sign In


Authorize

Se lect a Questionnaire



Li s t Player

Lis t Answer

[ More answers to lis t ]

[ No more answers to lis t ]

[ No more players to list ]

[ More players to lis t ]

Figure D.13 View/Collect Answered Questionnaire


Sign In

[ Invalid username /password ]

Authorize

Enter User Account Inform ation

Disp lay Admin Home Page


Create User Record

Figure D.14 Create User Account

D.5 Data Dictionary 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. USERACCOUNT: User account information table. Attribute Name Data Type Length Description USERID Varchar 8 User account identifier PASSWD Numeric 8 User password ACCESSROLE Varchar 15 User access role (e.g. PLAYER, COACH, TUTOR, ADMIN) STATUS Varchar 3 User account status (ACT for active accounts, BLK for blocked accounts) USERNAME Varchar 50 User full name


COACH: Coach�s information table. Attribute Name Data Type Length Description COACHID Integer 4 Coach�s unique identifier USERID Varchar 8 Foreign key references USERACCOUNT table COACHNAME Varchar 50 Coach�s full name TUTOR: Academic tutor�s information table. Attribute Name Data Type Length Description TUTORID Integer 4 Tutor�s unique identifier USERID Varchar 8 Foreign key references USERACCOUNT table TUTORNAME Varchar 50 Tutor�s full name PLAYER: Player�s information table. Attribute Name Data Type Length Description PLAYERID Integer 4 Player�s unique identifier USERID Varchar 8 Foreign key references USERACCOUNT table PLAYERNAME Varchar 50 Player�s full name DOB Date Player�s date of birth INSTITUTION Varchar 50 Name of the academic institution the player belongs to COURSE Varchar 80 Name of the course the player is studying COACHID Interger 4 Player�s coach. Foreign key references COACH table TUTORID Interget 4 Player�s academic tutor. Foreign key references TUTOR table EMAIL Varchar 30 Player�s electronic mail CONTACTNO Varchar 14 Player�s contact telephone number ROLE: Cricketing role look-up table Attribute Name Data Type Length Description ROLECODE Varchar 4 Role abbreviation code (e.g. BAT for Batting, BOW for Bowling) ROLENAME Varchar 15 Role name (e.g. Batting, Bowling, Bowling-Spin, etc) SKILL_TYPE: Cricketing skill type (category) look-up table Attribute Name Data Type Length Description SKILLTYPECODE Varchar 6 Skill type abbreviation code (e.g. TEC for Technical, TAC for Tactical) SKILLTYPENAME Varchar 25 Skill type name (e.g. Technical, Tactical, Physical, Mental, etc) SKILL: Cricketing skill look-up table Attribute Name Data Type Length Description SKILLID Integer 4 Skill unique identifier SKILLNAME Varchar 25 Skill name (e.g. Versus Spin, Running between Wickets, etc) ROLECODE Varchar 4 Role the skill belongs to. Foreign key references ROLE table SKILLTYPECODE Varchar 6 Type of the skill. Foreign key references SKILL_TYPE table SCORE: Player�s scoring storage table Attribute Name Data Type Length Description SCOREID Integer 4 Skill unique identifier PLAYERID Integer 4 Foreign key references PLAYER table SKILLID Integer 4 Foreign key references SKILL table SCOREVAL Integer 2 Value of the score. Defined between 1-10 UPDATEDATE Date Date of scoring


QUESTIONNAIRE: Questionnaire header information table Attribute Name Data Type Length Description QID Numeric 9 Questionnaire unique identifier QTITLE Varchar 80 Questionnaire title (or about) AUTHOR Varchar 8 Author of the questionnaire. Foreign key references USERACCOUNT

table CREATIONDATE Date Questionnaire creation date AVAILABLE Varchar 1 A flag to decide if the questionnaire is to be made available for

answering (Y/N) ANSWERED Varchar 1 A flag marking answered and non-answered questionnaires (Y/N) QUESTIONNAIRE_BODY: Questionnaire questions table Attribute Name Data Type Length Description QID Numeric 9 Foreign key references QUEATIONNAIRE table QNO Interger 4 Question serial number QTEXT Varchar 500 Question text PLAYER_QUESTIONNAIRE: Players� answers of the questionnaires table Attribute Name Data Type Length Description PLAYERID Integer 4 Foreign key references PLAYER table QID Numeric 9 Foreign key references QUEATIONNAIRE table ANO Interger 4 Answer serial number ATEXT Varchar 900 Answer text COMMENT: Coach�s comment entry table Attribute Name Data Type Length Description COMMENTID Numeric 9 Row unique identifier COMMENTTEXT Varchar 500 Comment text TERM Varchar 10 Calendar term of the session (Christmas, Easter, Summer) ROLECODE Varchar 4 Cricketing role abbreviation code SKILLTYPECODE Varchar 6 Skill type COACHID Integer 4 Foreign key references COACH table PLAYERID Integer 4 Foreign key references PLAYER table ENTRYDATE Varchar 300 Entry date of the comment D.6 Database Creation Script CREATE TABLE USERACCOUNT (USERID VARCHAR(8) NOT NULL PRIMARY KEY, PASSWD VARCHAR(8) NOT NULL, ACCESSROLE VARCHAR(15) NOT NULL, STATUS VARCHAR(3), USERNAME VARCHAR(50) ) CREATE TABLE COACH (COACHID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, USERID VARCHAR(8) NOT NULL, COACHNAME VARCHAR(50) NOT NULL FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID) ) CREATE TABLE TUTOR (TUTORID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, USERID VARCHAR(8) NOT NULL, TUTORNAME VARCHAR(50) NOT NULL FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID) ) CREATE TABLE PLAYER (PLAYERID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, USERID VARCHAR(8) NOT NULL, PLAYERNAME VARCHAR(50) NOT NULL, DOB DATETIME, INSTITUTION VARCHAR(50), COURSE VARCHAR(80),


COACHID INT, TUTORID INT, EMAIL VARCHAR(30), CONTACTNO VARCHAR(14) FOREIGN KEY (USERID) REFERENCES USERACCOUNT(USERID), FOREIGN KEY (COACHID) REFERENCES COACH(COACHID), FOREIGN KEY (TUTORID) REFERENCES TUTOR(TUTORID) ) CREATE TABLE ROLE (ROLECODE VARCHAR(4) NOT NULL PRIMARY KEY, ROLENAME VARCHAR(15) NOT NULL) CREATE TABLE SKILL_TYPE (SKILLTYPECODE VARCHAR(6) NOT NULL PRIMARY KEY, SKILLTYPENAME VARCHAR(25) NOT NULL) CREATE TABLE SKILL (SKILLID INT IDENTITY(1,1) NOT NULL PRIMARY KEY, SKILLNAME VARCHAR(50) NOT NULL, ROLECODE VARCHAR(4) NOT NULL, SKILLTYPECODE VARCHAR(6) NOT NULL FOREIGN KEY (ROLECODE) REFERENCES ROLE (ROLECODE) FOREIGN KEY (SKILLTYPECODE) REFERENCES SKILL_TYPE (SKILLTYPECODE) ) CREATE TABLE SCORE (SCOREID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY, PLAYERID INT NOT NULL, SKILLID INT NOT NULL, SCOREVAL SMALLINT, UPDATEDATE DATETIME NOT NULL FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID), FOREIGN KEY (SKILLID) REFERENCES SKILL (SKILLID) ) CREATE TABLE QUESTIONNAIRE (QID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY, QTITLE VARCHAR(80) NOT NULL , AUTHOR VARCHAR(8) NOT NULL, CREATIONDATE DATETIME, AVAILABLE VARCHAR(1), ANSWERED VARCHAR(1) FOREIGN KEY (AUTHOR) REFERENCES USERACCOUNT (USERID) ) CREATE TABLE QUESTIONNAIRE_BODY (QID NUMERIC NOT NULL, QNO INT NOT NULL , QTEXT VARCHAR(500) NOT NULL PRIMARY KEY (QID, QNO), FOREIGN KEY (QID) REFERENCES QUESTIONNAIRE (QID) ) CREATE TABLE PLAYER_QUESTIONNAIRE (PLAYERID INT NOT NULL, QID NUMERIC NOT NULL , ANO INT NOT NULL, ATEXT VARCHAR(900) PRIMARY KEY (PLAYERID, QID, ANO), FOREIGN KEY (QID) REFERENCES QUESTIONNAIRE (QID), FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID) ) CREATE TABLE COMMENT (COMMENTID NUMERIC IDENTITY(1,1) NOT NULL PRIMARY KEY, COMMENTTEXT VARCHAR(500) NOT NULL, TERM VARCHAR(10) NOT NULL, ROLECODE VARCHAR(4), SKILLTYPECODE VARCHAR(6), COACHID INT NOT NULL, PLAYERID INT NOT NULL, ENTRYDATE DATETIME NOT NULL FOREIGN KEY (COACHID) REFERENCES COACH (COACHID) FOREIGN KEY (PLAYERID) REFERENCES PLAYER (PLAYERID) )


Appendix E: Information Gathering Samples E.1 Meetings/Interviews

Development of the UCCE Progress File Meeting Minutes

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).


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.

Development of the UCCE Progress File Meeting Minutes

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. The following summarizes the resulted requirements/specifications: Components of the UCCE Progress File

1. Cricket Progress File: o Contains player�s physical and mental skills. o To be created/maintained by player once a week (one record per week or so). o To be viewed and commented by coach.

2. Academic Progress File: o Contains player�s academic achievement progress. o To be created/maintained by player (how often?). o To be viewed and commented by academic tutor.

3. Performance Progress File: o Contains facts and statistics about player�s skills on the pitch. o To be created/maintained by player after a cricket match (one record per match). o To be viewed and commented by coach.

Structure and details of the above file components is to be prepared by the client. Users (stakeholders) of the system

1. Player. 2. Coach. 3. Academic tutor. 4. Web site administrator. 5. Liaison officer: is not a direct user. Players contact him by phone or email to sort out any clash problem in a

training session or a cricket match. 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.


• Feedback on coach�s comments on performance progress file Coach should be able to:

• View cricket progress file of his players. • Give feedback on each skill in the cricket progress file. • View performance progress file of his players. • Give feedback on each skill in the performance progress file.

Academic tutor should be able to:

• View academic progress file of his tutees. • Give feedback on each skill in the academic progress file.

Web site administrator should be able to:

• Add/delete users and assign access roles. • Maintain the structure of the web site.

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.

Project Meeting Agenda15/08/2002 10:30 AM

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;

Project progress was discussed in the meeting briefly.

# Demonstration of the prototype (iteration 2);

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.

# Players Report (from Kevin);

Kevin (the coach) has suggested another way of keeping text comments to the player records. A report


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: # Text Comments Screen to be modified; # Access to be given to coach and tutor to be able to answer questionnaires. # All other areas of the system are okay; # User acceptance test will be run on 2nd of September

E.2 Questionnaires Hi Yousuf, I've made some comments against the questions you set out below: -

-----Original Message----- From: Al Hussaini Yousuf [mailto:[email protected]] 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.

I need to clarify the following points:

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


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.


E.3 Sample Documents

Developing a Progress File for Cricket

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. The file will draw material from: - • The Performance Diary provided by the ECB for developing under 17s, in particular the sections

logging the development of physical and tactical skills related to performance as they articulate with higher level skills.

• The generic academic Progress File developed By Geography and in current use within other faculties.

• Further material to be supplied by ECB from the National Cricketing Academy. 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 contain the following types of data: - • Objective numeric data about the player's performance; • Subjective numeric data about the player's self assessment of the skills required for

performance; • Text entered by the player and the coach reviewing the player's performance and skills; • Some of the above material may best be represented within active images, for example the bulls'

eyes representing performance and the physical and mental qualities good performance requires. • Dates attached to all the above material in order that trends can be identified and within a diary

allowing the academic and cricketing schedule to be reconciled. 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.


Appendix F: Code Segment Samples F.1 The Sign-in Process 'Check if user/password exist rs.Source = "Select userid, accessrole, status from useraccount where userid = '" & my_id & "'" & " and passwd = '" & my_pass & "'" rs.Open if (not rs.EOF) then if (rs("status") <> "BLK") then session("userid") = rs("userid") session("accessrole") = rs("accessrole") rs.Close set rs = nothing conn.Close set conn = nothing if (session("accessrole") = "PLAYER") then Response.Redirect "player.asp" elseif (session("accessrole") = "COACH") then Response.Redirect "coach.asp" elseif (session("accessrole") = "TUTOR") then Response.Redirect "tutor.asp" else Response.Redirect "admin.asp" end if else blocked = 1 end if else notfound = 1 end if F.2 Skills Retrieval for Scoring

<% 'retrieve skill information if (Request.QueryString ("add") <> 1) then my_sql = "Select s.skillid, s.skillname, r.rolecode, r.rolename, st.skilltypecode, st.skilltypename " my_sql = my_sql & "from skill s, role r, skill_type st " my_sql = my_sql & "where st.skilltypecode = '" & Request.QueryString ("skilltypecode") & "' " my_sql = my_sql & "and s.skilltypecode = st.skilltypecode " my_sql = my_sql & "and r.rolecode = '" & Request.QueryString ("rolecode") & "' " my_sql = my_sql & "and s.rolecode = r.rolecode" rs.Source = my_sql rs.Open%> <font face="Arial" color="#008080"><br> <center><b><%=rs("rolename") & " (" & rs("skilltypename")& " Skills)"%></b><br> <img src="<%=rs("rolecode") & ".gif"%>"> </center> </font> </font> <font > <font face="Arial" color="#008080"> <form name ="frmScore" method="POST" action="score.asp?rolecode=<%=rs("rolecode")%>&skilltypecode=<%=rs("skilltypecode")%>&add=1"> <div align="center"> <center> <table border="0" width="927" cellpadding="3" bgcolor="#ECFFF5"> <tr> <font face="Arial" color="#008080"> Select the desired score against each skill. <p> </font> </tr> <%index = 1 while not rs.EOF%> <tr> <%for i = 1 to 4 ' generate 4 columns my_skill = "skill" & index my_score = "score" & index%> </font> <td width="673"> <font face="Arial" color="#008080"> <%if (not rs.EOF) then%> <%=rs("skillname")%>


</font> </td> <td width="232"> <font face="Arial" color="#008080"> <input type="hidden" name="<%=my_skill%>" value="<%=rs("skillid")%>" > <select size="1" name="<%=my_score%>" > <option value=""></option> <option value="1">1</option> <option value="2">2</option> <option value="3">3</option> <option value="4">4</option> <option value="5">5</option> <option value="6">6</option> <option value="7">7</option> <option value="8">8</option> <option value="9">9</option> <option value="10">10</option> </select> </font> </td> <font face="Arial" color="#008080"> <%index = index + 1 rs.MoveNext end if next%> </tr> <%wend rs.Close set rs = nothing conn.close set conn = nothing%> </table> </center> </div> <p> </p> <input type="hidden" name="skillcounter" value="<%=index-1%>" > <p align="center"><input type="submit" value="Save Scores" name="B1" onClick = "return frmScore_Validate()"> <input type="reset" value="Reset Entries" name="B2"></p> </form>

F.3 Reading and Saving Score Values

<%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")


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%>

F.4 Summary HTML Input Form

<%rs.Source = "select distinct updatedate from score where playerid = " & my_playerid & " order by updatedate desc" rs.Open%> <form method="POST" action="summary.asp"> <p>Period of the summary: From <select size="1" name="from"> <%while not rs.EOF my_option = "" my_request = "'" & Request.Form("from") & "'" 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> 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>

F.5 Statistical Summary of Average Score by Scoring Date

<%' 1- view summary statistics by scoring date if (Request.Form("view") <> "") then my_sql = "select r.rolename, avg(sc.scoreval*1.0) as average, sc.updatedate from score sc, role r, skill sk " my_sql = my_sql & "where sc.playerid = " & my_playerid my_sql = my_sql & " and sc.updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'" my_sql = my_sql & "and sc.skillid = sk.skillid and r.rolecode = sk.rolecode " my_sql = my_sql & "group by sc.updatedate, r.rolename order by sc.updatedate, r.rolename" rs.Source = my_sql rs.Open%> <u>Average Summary by Date of Scoring</u> <table border="0" width="466"> <tr> <td bgcolor="#008080" width="195"><font face="Arial" color="#FFFFFF"><b>Date Period</b></font></td> <td bgcolor="#008080" width="195"><font face="Arial" color="#FFFFFF"><b>Date of Scoring</b></font></td> <td bgcolor="#008080" width="287"><font face="Arial" color="#FFFFFF"><b>Role/Skill Name</b></font></td> <td bgcolor="#008080" width="135"><font face="Arial" color="#FFFFFF"><b>Average Performance</b></font></td> </tr> <%my_datebreak = "" 'break summary on date my_period = 0 while not rs.EOF


if (my_datebreak = rs("updatedate")) then my_updatedate = "" my_seq = "" else my_datebreak = rs("updatedate") my_updatedate = day(rs("updatedate")) & "/" & month(rs("updatedate")) & "/" & year(rs("updatedate")) my_period = my_period + 1 my_seq = my_period & " " end if%> <tr> <td width="120"> <font face="Arial" color="#008080"><b><%=my_seq%></b></font></td> <td width="195"> <font face="Arial" color="#008080"><b><%=my_updatedate%></b></font></td> <td width="287"> <font face="Arial" color="#008080"> <%=rs("rolename")%></font></td> <td width="135"> <font face="Arial" color="#008080"> <%=cint(rs("average"))%></font></td> </tr> <font face="Arial" color="#008080"> <%rs.MoveNext wend rs.Close%> </table>

F.6 Skills development Line-Graph Plotter

<%' 2- plot the results in 1 my_sql = "select distinct updatedate from score " my_sql = my_sql & "where playerid = " & my_playerid my_sql = my_sql & " and updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'" my_sql = my_sql & " order by updatedate" rsDate.Source = my_sql rsDate.CursorType = 3 rsDate.Open my_xrange = rsDate.RecordCount + 5 my_period = 1 ' intialize the graph Response.Write "<script src=glib.js></script> " Response.Write "<script> " Response.Write "Gopen(""white"",650,300,"""",0); " Response.Write "xyinit(50,270,1,0,0,0); " Response.Write "goffset(1,0,1); " Response.Write "gscale(3,4,1); " Response.Write "xscale(""BLACK""," & my_xrange & ",""Date Period"",1); " Response.Write "yscale(""BLACK"",10,""Avergae Score"",1); " Response.Write "xygrid(""lightcyan""); " Response.Write "Glabel(""Batting"",""Bowling-Pace"",""Bowling-Spin"",""Fielding"",""Wicket Keeping""); " Response.Write "Gsymbol(""B"",""BP"",""BS"",""F"",""WK""); " while not rsDate.EOF my_updatedate = rsDate("updatedate") ' get avg score of Batting rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk " rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'" rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BAT'" rs.Open if (isNull(rs("average"))) then my_BAT = 0 else my_BAT = cint(rs("average")) end if rs.Close ' get avg score of Bowling-Pace rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk " rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'" rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BP'" rs.Open if (isNull(rs("average"))) then my_BP = 0 else my_BP = cint(rs("average")) end if rs.Close ' get avg score of Bowling-Spin rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk " rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'" rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'BS'" rs.Open


if (isNull(rs("average"))) then my_BS = 0 else my_BS = cint(rs("average")) end if rs.Close ' get avg score of Fielding rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk " rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'" rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'FLD'" rs.Open if (isNull(rs("average"))) then my_FLD = 0 else my_FLD = cint(rs("average")) end if rs.Close ' get avg score of Wicket Keeping rs.Source = "select avg(sc.scoreval*1.0) as average from score sc, skill sk " rs.Source = rs.Source & "where sc.playerid = " & my_playerid & " and sc.updatedate = '" & my_updatedate & "'" rs.Source = rs.Source & " and sc.skillid = sk.skillid and sk.rolecode = 'WK'" rs.Open if (isNull(rs("average"))) then my_WK = 0 else my_WK = cint(rs("average")) end if rs.Close my_row = "Gdata(" & my_period & "," & my_BAT & "," & my_BP & "," & my_BS my_row = my_row & "," & my_FLD & "," & my_WK & "); " Response.Write my_row my_period = my_period + 1 rsDate.MoveNext wend rsDate.Close Response.Write "Gclose(); </script> <br>"%> </font> </font><font face="Arial" size="2"color="black">* 0 indicates no score <br> * Javascript library used to draw the above graph<br> is provieded as a freeware by http://siva.cc.hirosaki-u.ac.jp/usr/koyama/glib</font>

F.7 Statistical Summary of the Overall Average Score

<%' 3- view overall summary my_sql = "select r.rolename, avg(sc.scoreval*1.0) as average from score sc, role r, skill sk " my_sql = my_sql & "where sc.playerid = " & my_playerid my_sql = my_sql & " and sc.updatedate between '" & Request.Form("from") & "' and '" & Request.Form("to") & "'" my_sql = my_sql & "and sc.skillid = sk.skillid and r.rolecode = sk.rolecode " my_sql = my_sql & "group by r.rolename" rs.Source = my_sql rs.Open%> <u>Overall Average Summary</u> <table border="0" width="466"> <tr> <td bgcolor="#008080" width="287"><font face="Arial" color="#FFFFFF"><b>Role/Skill Name</b></font></td> <td bgcolor="#008080" width="135"><font face="Arial" color="#FFFFFF"><b>Average Performance</b></font></td> </tr> <%while not rs.EOF%> <tr> <td width="287"> <font face="Arial" color="#008080"> <%=rs("rolename")%></font></td> <td width="135"> <font face="Arial" color="#008080"> <%=cint(rs("average"))%></font></td> </tr> <font face="Arial" color="#008080"> <%rs.MoveNext wend rs.Close%> </table>


F.8 New Questionnaire Generation <%' adding new questionnaire if (Request("add") = 1) then Response.Write "<hr>" Application.Lock if (Request("qno") = 1001) then ' create header my_sql = "insert into questionnaire (qtitle, author, creationdate, available, answered) values ('" my_sql = my_sql & Request.Form("qtitle") & "','" & my_author & "','" & date() &"','" & Request.Form("available") & "', 'N')" conn.Execute my_sql session("qno") = 1 else ' get qid and qno of this question from a different form (e.g. qupdateform) if (Request.QueryString("addmore") = 1) then session("qno") = Request.QueryString("qno") + 1 my_qid = Request.Form("qid") else ' get qid of this questionnaire from DB if (Request.Form("qid") = "") then rs.Source = "select max(qid) as qid from questionnaire" rs.Open my_qid = rs("qid") rs.Close end if end if if (my_qid = "") then my_qid = Request.Form("qid") end if ' create body (save questions) if (Request.Form ("qtext") <> "") then my_sql = "insert into questionnaire_body (qid, qno, qtext) values (" my_sql = my_sql & my_qid & "," & session("qno") & ",'" & Request("qtext") & "')" conn.Execute my_sql session("qno") = session("qno") + 1 end if end if my_qno = session("qno") ' Check if Exit button has been pressed if (Request("qno") = 99) then Response.Redirect ("questionnaire.asp") end if%> <form method="POST" name="qbody" action="questionnaire.asp?add=1&qno=<%=my_qno%> "> <input type="hidden" name="qid" value="<%=my_qid%>"> <p><font face="Arial" color="#008080">Enter Question Number <%=my_qno%> </font></p> <p><textarea rows="8" name="qtext" cols="79"></textarea></p> <p><input type="submit" value="Proceed" name="B1"> <input type="submit" value="Finish and Exit" name="B2" onClick="qbody_Exit()"></p> </form> <%Application.UnLock end if F.9 Questionnaire Modification ' 2. Modifying Questionnaire ' Update modification changes if (Request.QueryString ("savemod") = 1) then conn.BeginTrans ' update header my_sql = "update questionnaire set qtitle = '" & Request.Form("qtitle") & "'," my_sql = my_sql & "available = '" & Request.Form("available") & "' where qid = " & Request.Form("qid") conn.Execute my_sql ' update body my_qid = Request.Form ("qid") if (Request.Form("qcounter") <> "") then for i = 1 to Request.Form("qcounter") my_qtext = Request.Form( "q" & i & "text") ' If no text is entered, delete question if (my_qtext = "") then my_sql = "delete from questionnaire_body where qid = " & my_qid & " and qno = " & i else ' else update question text my_sql = "update questionnaire_body set qtext = '" & my_qtext & "' " my_sql = my_sql & "where qid = " & my_qid & " and qno = " & i end if conn.Execute my_sql


next end if conn.CommitTrans ' Re-arange questions if any has been deleted rs.Source = "select qno from questionnaire_body where qid = " & my_qid rs.Open i = 0 while not rs.EOF my_qno = rs("qno") i = i + 1 if (my_qno> i) then my_sql = "update questionnaire_body set qno = " & i & " where qno = " & rs("qno") & " and qid = " & my_qid conn.Execute my_sql end if rs.MoveNext wend rs.Close if (my_qno = "") then my_qno = 0 end if ' Prompt for adding more questions%> <br><font color="#008080" face="Arial"> Changes have been saved. Click the button below to add more questions.</font> <form name="addmore" method="post" action="questionnaire.asp?add=1&addmore=1&qno=<%=my_qno%>" > <input type="hidden" name="qid" value="<%=my_qid%>"> <input type="submit" name="B9" value="Add More Questions"> </form> <%end if%> F.10 Listing of connection.asp Script <style> A:link, A:active { text-decoration : none; color : #008080; background : transparent; } A:visited { color : #008080; background : transparent; text-decoration : none; } A:hover { color : white; background : #008080; } </style> <% ' 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" 'This sub program verifys accessability of users to a specific page Sub VerifyAccess (p_accessrole) if session("accessrole") <> p_accessrole then Response.Write "<b> Access to this page is deniend. Please contact the web site administrator! </b>" Response.End end if end sub 'error_handler: ' set err = Server.GetLastError() 'if (err.number <> 0 ) then 'Response.Write err.description 'end if %>


Appendix G: User�s Feedback and the Outcome of the Acceptance Test G.1 Client�s Feedback Letter


G.2 The Outcome of the User�s Acceptance Test


Appendix H: CPF Installation Guide 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.