Automation of Approval Certification

APPROVAL CERTIFICATION
This is to certify that Junaid Khan(6021) and Adrees Khan (6016) have worked on and
completed their Software Project at Department of Information Technology, Abbottabad
University of Science & Technology in partial fulfillment of the requirement for the degree of
MCS under the guidance and supervision of Mr. Muhammad Shakeel.
In our opinion, it is satisfactory and up to the mark and therefore fulfills the requirements of
Master’s in Computer Sciences.
Supervisor
Mr. Muhammad Shakeel
___________________
(Signature)
Project Committee Convener
___________________
(Signature)
Internal Examiner
___________________
(Signature)
External Examiner
___________________
(Signature)
HOD/CHAIRMAN
Dr. Muhammad Naeem
_____________
(Signature)
i
ACKNOWLEDGEMENT
It would be our pleasure and we are feeling ecstatically rapturous to pay heartiest thanks.
First of all, almighty ALLAH that he enabled and blessed us to take the leaf out of his
multitude bounties.
To our Dear parents, their prayers became the stepping-stones towards the completion of
our project.
We are greatly beholden to our esteemed honorable and kind-hearted supervisor Mr.
Muhammad Shakeel that he supervised and co-operated our project whole heartedly.
Thanks from the core of our heart to all the above-mentioned persons. Last but not the
least we would love to put forth the bouquet of reverence and thanks to Mr.
Muhammad Shakeel for moral support and sincere wishes for the completion of our
work.
ii
DEDICATION
This thesis is dedicated to our Parents who have never failed to give us financial and
moral support for giving all our needs during the time in which we developed our
system. Also this thesis is dedicated to our respected teachers who supported us all the
way. This thesis is dedicated to my juniors and all those who believe in the richness of
learning.
We dedicated this degree to our dearest Parents, Family, and Friends respected Teachers
who motivated, support and encouraged us in every aspect of our life.
Junaid Khan
Adrees Khan
iii
PREFACE
I hereby declare that this project neither as whole nor as a part has been copied out from any
source. It is further declared that I have developed this software and accompanied report
entirely on the basis of my personal effort, under the sincere guidance of my supervisor,
teachers and seniors. If any part of this system is proved to be copied out from any source or
found to be reproduction of someone else, I shall stand by the consequences.
Junaid Khan
Signature:
Adrees Khan
Signature:
iv
TABLE OF CONTENTS
CHAPTER 1 .......................................................................................................................................... 1
INTRODUCTION................................................................................................................................. 1
1.1 Project Introduction ................................................................................................................ 2
1.2 Project Scope .......................................................................................................................... 2
1.3 Tools and Technologies Used ................................................................................................. 3
1.4 Design and Implementation Requirements ............................................................................. 3
1.4.1 Hardware Requirements .................................................................................................. 3
1.4.2 Database Requirement .................................................................................................... 3
CHAPTER 2 .......................................................................................................................................... 4
THEORATICAL BACKGROUND .................................................................................................... 4
2.1 Introduction ................................................................................................................................... 5
2.2 Existing System ...................................................................................................................... 5
2.3 Problems and limitation of Existing System ........................................................................... 6
2.3.1 Lack of Information ........................................................................................................ 6
2.3.2 Time Consumption.......................................................................................................... 6
2.3.3 Man Power ...................................................................................................................... 6
2.3.4 Limited options ............................................................................................................... 6
CHAPTER 3 .......................................................................................................................................... 7
PROPOSED SYSTEM ......................................................................................................................... 7
3.1 Introduction ............................................................................................................................. 8
3.2 System Modules ...................................................................................................................... 8
3.2.1 Module 1: Admin module ............................................................................................... 8
3.2.2 Module 2: Add team ....................................................................................................... 9
3.2.3 Module 3: Add player ..................................................................................................... 9
3.2.4 Module 4: Add city ......................................................................................................... 9
3.2.5 Module 5: Add match schedule .................................................................................... 10
3.2.6 Module 6: Delete teams ................................................................................................ 10
3.2.7 Module 7: Delete players .............................................................................................. 10
3.2.8 Module 8: Delete city.................................................................................................... 11
3.2.9 Module 9: Show current ................................................................................................ 11
3.3 Functional Requirements ...................................................................................................... 11
3.4 Non-Functional Requirements .............................................................................................. 12
3.5 Business Requirements ......................................................................................................... 13
3.6 User Requirements ................................................................................................................ 13
v
3.6.1 System Administrators .................................................................................................. 13
3.6.2 User (Commentator) ..................................................................................................... 13
3.6.3 Users (Fan) .................................................................................................................... 13
3.7 Methodology ......................................................................................................................... 13
CHAPTER 4 ........................................................................................................................................ 14
SYSTEM DESIGN .............................................................................................................................. 14
4.1 Introduction ................................................................................................................................. 16
4.1.1 Process Model ............................................................................................................... 16
4.2 Package Diagram ........................................................................................................................ 16
4.3 Deployment Diagram .................................................................................................................. 17
4.4 System Sequence Diagram.......................................................................................................... 18
4.4.1 ADMIN ......................................................................................................................... 19
4.4.2 PLAYER ....................................................................................................................... 20
4.4.3 CITY ............................................................................................................................. 21
4.4.4 TEAM ........................................................................................................................... 22
4.4.5 MATCH ........................................................................................................................ 23
4.5 Use Case................................................................................................................................ 24
4.5.1 Admin Use Case............................................................................................................ 25
4.5.2 Viewers Use Case ......................................................................................................... 25
4.6 Data Flow Diagram ............................................................................................................... 26
4.7 Entity Relation Diagrams ...................................................................................................... 28
4.8 Entities and their attributes ................................................................................................... 29
4.8.1 ADMIN ......................................................................................................................... 29
4.8.2 CITY ............................................................................................................................. 29
4.8.3 PLAYER ....................................................................................................................... 30
4.8.4 TEAMS ......................................................................................................................... 30
4.8.5 TEAM MATCH ............................................................................................................ 31
4.9 Work Plan ............................................................................................................................. 31
4.10 DATA DICTIOARY TABLE ............................................................................................... 32
4.10 Design Goals ............................................................................................................................. 34
Dependability ........................................................................................................................ 34
Maintenance .......................................................................................................................... 34
End User Criteria .................................................................................................................. 34
CHAPTER 5 ........................................................................................................................................ 35
SYSTEM TESTING ........................................................................................................................... 35
5.1 Introduction ........................................................................................................................... 36
vi
5.2 Test Plan................................................................................................................................ 36
5.2.1 Integrating Testing ........................................................................................................ 36
5.2.2 Deployment Testing ...................................................................................................... 36
5.2.3 Unit Testing .................................................................................................................. 37
5.2.5 White Box Testing ........................................................................................................ 37
5.2.6 Black Box Testing......................................................................................................... 37
5.3 Test Cases ............................................................................................................................. 38
5.3.1 Test Case 1 .................................................................................................................... 38
Test Case 2 .................................................................................................................................... 39
5.3.3 Test Case 3 .................................................................................................................... 39
5.3.4 Test Case 4 .................................................................................................................... 40
5.3.5 Test Case 5 .................................................................................................................... 40
5.3.6 Test Case 6 .................................................................................................................... 41
5.3.7 Test Case 7 .................................................................................................................... 41
5.3.8 Test Case 8 .................................................................................................................... 42
5.3.9 Test Case 9 .................................................................................................................... 42
CHAPTER 6 ........................................................................................................................................ 43
USER MANUAL ................................................................................................................................. 43
6.1 Screen Shots of Web Application Screen ............................................................................. 44
6.1.1 Add teams by admin ..................................................................................................... 44
6.1.2 Add city by admin ......................................................................................................... 44
6.1.3 Add player by admin ..................................................................................................... 45
6.1.4 Add schedule of match.................................................................................................. 45
6.1.5 View added teams ......................................................................................................... 46
6.1.6 View city added by admin ............................................................................................ 46
6.1.7 View Commentator by admin ....................................................................................... 47
6.1.8 Schedule view by Commentator ................................................................................... 47
6.1.9 Update commentary and goals by Commentator .......................................................... 48
6.1.10 View matches by viewer ............................................................................................... 48
6.1.11 View both teams............................................................................................................ 49
6.1.12 View players of both team ............................................................................................ 49
6.1.13 View live commentary .................................................................................................. 50
CHAPTER 7 ........................................................................................................................................ 51
CONCLUSION ................................................................................................................................... 51
1. Conclusion ................................................................................................................................... 52
Appendixes: Source Code................................................................................................................... 53
vii
LIST OF FIGURES
Figure 4-1 : Package Diagram .............................................................................................................. 17
Figure 4-2: Deployment Diagram ......................................................................................................... 18
Figure 4-3: Admin Registration ............................................................................................................ 19
Figure 4-4: Player Registration ............................................................................................................. 20
Figure 4-5: City Registration ................................................................................................................ 21
Figure 4-6: Team Registration .............................................................................................................. 22
Figure 4-7: View Matches .................................................................................................................... 23
Figure 4-8: Use Case............................................................................................................................. 24
Figure 4-9: Admin Use Case................................................................................................................. 25
Figure 4-10: View Use Case ................................................................................................................. 25
Figure 4-11: Context Level DFD .......................................................................................................... 26
Figure 4-12: Level-1 DFD .................................................................................................................... 27
Figure 4-13: ER Diagram...................................................................................................................... 28
Figure 4-14: Attributes of Admin ......................................................................................................... 29
Figure 4-15: Attributes of City ............................................................................................................. 29
Figure 4-16: Attributes of Player .......................................................................................................... 30
Figure 4-17: Attributs of Teams............................................................................................................ 30
Figure 4-18: Attributes of Teams Match............................................................................................... 31
Figure 4-19: Work Plan ........................................................................................................................ 31
viii
LIST OF TABLES
Table 4.1 Data Dictionary .................................................................................................. 32-33
Table 5.1: Test case 1............................................................................................................... 38
Table 5-2: Test Case 2 ............................................................................................................. 39
Table 5.3: Test Case 3 .............................................................................................................. 39
Table 5.4: Test Case 4 .............................................................................................................. 40
Table 5.5: Test Case 5 .............................................................................................................. 40
Table 5.6: Test Case 6 .............................................................................................................. 41
Table 5.7: Test Case 7 .............................................................................................................. 41
Table 5.8: Test Case 8 .............................................................................................................. 42
Table 5.9: Test Case 9 .............................................................................................................. 42
ix
CHAPTER 1
INTRODUCTION
1
1.1Project Introduction
System includes a set of sports offered at various levels of competition, teams and
player cooperation. These are further classified into several seasons of play that define
the beginning and ending dates of various competitions; Fall, winter, spring, and
summer. Often, a given sport offered during a specific season is called a league in
which teams register to participate. Facility scheduling is another additional aspect to
be considered to schedule a sport.
There are two approaches that can be taken to manage football management program:
1. Do it manually using pen and paper and integrate technologies that support
management's needs. This approach requires manually recording all information with
regard to all data and manually creating the contest schedules, coordinating facility
usage, and hand-registering athletes and teams. The dissemination of information
would require that documents be typed, photocopied, and posted in mail to the
participating individuals.
2. The second approach is the integration of software technologies to help manage the
large amounts of data. While technologies that support sport management do exist in
today's market, the functionalities each technology supports can be limited and may
vary considerably. Some products provide useful facility management tools but lack
the ability to work with teams, while others tend to work well with teams but not with
facilities.
1.2Project Scope
 The scope of this system is to deliver an environment to District Football
Association Abbottabad to keep record of the registered players and team and
manage upcoming schedule.
 System will provide platform for footballs fans to view records of their favorite
players/teams, read live commentary and view the score update of ongoing
matches.
 System will provide platform for players to view their information which is added
by admin and view the upcoming schedule of tournaments and matches.
 System will provide platform where admin can manage teams and their records.
 System will provide platform where admin can manage players and their records.
2
 System will provide platform where admin can manage match schedule.
1.3Tools and Technologies Used

This system will be implemented using following tools & technologies
 HTML (Hypertext Markup Language) + JavaScript used to make web interface

of this system.
 PHP is used to make server side scripting.
1.4Design and Implementation Requirements
1.4.1 Hardware Requirements

 Memory Requirement:Minimum 1 GB ram is required.
1.4.2 Database Requirement

MySQL database will be used for storing relational data.
Communication Requirement:
 Internet connection required to use features of this system.
Implementation Requirement:
 XAMPP for working without internet connection
 Application will require a working internet connection.
 Sublime text for implementation of Web Application.
3
CHAPTER 2
THEORATICAL BACKGROUND
2.1 Introduction
System follows manual approach of pen and paper to registered the teams and players
into the association. This approach requires manually recording all information with
regard to all data and manually creating the contest schedules, coordinating facility
usage, and hand-registering athletes and teams. The dissemination of information
would require that documents be typed, photocopied, and posted in mail to the
participating individuals.
2.2 Existing System
 In existing system team manager bring all the required documents and hand
over the required department (Team management department).
 Manger can register their teams in the files system.
 Files were managed by clerk.
 The existing system is simple and includes a lot of paper work with huge man
power.
 The existing system has a confined set of rules and options to have an entry to
the files
 Paper work management and time sheet requiring double data entry generates
errors, mistakes and increases the time in entering with lot data.
There are four board members of District Football Associations
 President:This member holds all kind of information about the system.
 Secretly:This member work for president and take order from president.
 Provisional Member: This member works on the provisional level and holds all
kind ofinformation about the system at the district level.
 Vice Chancellor:This member work on behalf of Provisional Member and take
orders from Provisional Member and president.
5
2.3 Problems and limitation of Existing System
Following are the problems and limitation of existing system

2.3.1 Lack of Information
At district level getting information is difficult there exist no platform where people can
get information about upcoming football events. Football followers not able to get any
kind of information about team, players and their records.If someone wants to register
their team he/she have no knowledge what will be the process to register the team. The
viewers face problems while taking any kind of information about players or teams and
their records.
2.3.2 Time Consumption
The existing system is time consuming and not very user friendly. Paper work
management and time sheet requiring double data entry generates errors, mistakes and
increases the time in entering with lot data. Even an efficient officer may not be able to
handle more than one match at a time. So it requires lot of time to handle two or more
matches at a time.
2.3.3 Man Power
A lot of man power involved in the existing system, all the record was managed by only
a single person.Players can easily be switch by other player which is not registered in
the team without being permissioned by the authorities.Sometimes the complaints may
be ignored by the operating officers.In most of the matches, the records are not saved in
the existing system.
2.3.4 Limited options
The existing system has a very little and confined options wide open to the user, which
depicted the admin/player to find a base to design and develop the new system which
enhances the present system to satisfy the current existing system's necessities.
As we all know, a covered live commentary plays an important role in the existing
system there was no such facility present in the existing system.It has been mainly
scheduled to design and developed to deliver its information about the players, teams
and its other aspects to the viewers. No proper coordination between teams, players and
users.
These limitations in the existing system confine both the operational as well as the
functional aspects of the system which leads all the different actors of the system with
limited features and operational benefits.
6
CHAPTER 3
PROPOSED SYSTEM
7
3.1 Introduction
The propose system follows the second approach which is the integration of software
technologies to help manage the large amounts of data. While technologies that support
sport management do exist in today's market, the functionalities each technology
supports can be limited and may vary considerably. Some products provide useful
facility management tools but lack the ability to work with teams, while others tend to
work well with teams but not with facilities.
The implementation environment used to support the District Football Associations

was Microsoft windows 7 and the main scripting languages used were PHP/JavaScript.
XAMPP server and Mozilla Firefox were used to execute the system
This section introduces the developed application with emphasis on how it was
developed and it further shows the samples of the implemented District football
association’s interfaces in use as well as the methodologies used in testing the
application.
3.2 System Modules

List of system modules are given as follows:
3.2.1 Module 1: Admin module
Scope:District Football Associations

Level:Admin Goal
Primary Actor:Admin
Stake holders and interests:
Administrator: Want to login to the system to manage behavior of the system.
Precondition(s):User knows his/her password and email address.
Success Guarantee:User login successfully.
8
3.2.2 Module 2: Add team

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants add the team.
Precondition(s):Admin is logged in to the system.
Success Guarantee:Adds the data successfully.
3.2.3 Module 3: Add player

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants add the player.
3.2.4 Module 4: Add city

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants add the city.
9
3.2.5 Module 5: Add match schedule

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants add the match schedule.
3.2.6 Module 6: Delete teams

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants delete the teams.
Success Guarantee:Delete the data successfully.
3.2.7 Module 7: Delete players

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants delete the players.
10
3.2.8 Module 8: Delete city

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants delete the city.
3.2.9 Module 9: Show current

Level:Admin Goal
Primary Actor:Admin
Administrator: Wants to view the live status of current match.
Precondition(s):User know the well address of the required page.
Success Guarantee:Data shown to the users successfully.
3.3 Functional Requirements
The purpose of this project is to digitize the records of District Football Association,
make it easy for DFA officials to keep the schedule of league and to provide fans to
view their favorite teams and their statistics. Project will also provide live score and
commentary for fans.Functional requirements are as follows: -
 This system will provide functionality the admin to login and manage team
players and their statistics.
 This system will provide functionality to admin to have access to every record
of the player and will send notification to player on android application.
 This system will provide functionality to admin to manage the fixture of
football tournaments.
 This system will provide functionality to the player to login and add/view their
record.
11
 This system will provide functionality to the player to view the upcoming
football tournaments and see their own stats.
 This system will provide functionality to the player to receive notifications
sent by the admin.
 This system will provide functionality to the viewers to view the stats of their
favorite teams and players.
 This system will provide functionality to viewers to read live commentary and
check live scores and view upcoming schedule of their favorite teams.
 This system will provide functionality to the Commentator to update match
scores and write live commentary.
 This system will provide functionality to officials DFA to view their consoles.
 This system will provide functionality to officials of DFA to view upcoming
matches and funds details.
3.4 Non-Functional Requirements
Non-functional requirements are as follows:

 System is not compatible with IOS.
 All its operations should be correct, that is, should produce expected results
when supplied with the right inputs.
 System should verify/validate all user input and users must be notified in case
of errors.
 System should be complete and consistent that is, able to deal with all the
possible outcomes during its operation.
 Allow users to use it simultaneously on computers with minimum system
requirements and connected to internet.
 System should be able to sustain the heavy load offered to it due to network
requests (provide high performance in all situations).
 System should be reliable, up and running every time its operations are
needed.
 System should operate efficiently under the TCP/IP protocol suite.
 User should easily register with the system.
 The system should be extensible.
12
 It should give fast, accurate and inexpensive process of results to users.
3.5 Business Requirements
Business requirements are as follows:

 The website shall have a home page that lists current matches on that date.
 New fan/viewers signup.
 The system shall allow the users to search teams.
 Internet connection must be available.
3.6 User Requirements
3.6.1 System Administrators
 Create/Edit/Delete teams.
 Create/Edit/Delete players.
 Create/Edit/Delete city.
 Create matches schedule.
3.6.2 User (Commentator)
 View the current matches.

 Update Goals and Live commentary.
3.6.3 Users (Fan)
 View current and upcoming events.

 View teams and player’s statistics.
 View live match via commentary.
3.7 Methodology
Water fall model is used to make the system because it is easy for making system and
easy to understand its components and its requirement. In water fall model document is
written in the form of softcopy and after that implementation of the system will start.
13
CHAPTER 4
SYSTEM DESIGN
14
4.1Introduction
This chapter includes the detailed design of the proposed system, the working of the
system, its features and functions. All the classes their collaboration sequence and
transition is briefly described.
This chapter also includes process model which tells us about how we are going to
build our system.
This chapter include package diagram, deployment diagram, Entity Relation Diagrams,
sequence diagram, Data Dictionary.
4.1.1 Process Model

A Process Model describes the sequence of phases for the entire lifetime of a product.
Therefore, it is sometimes also called Product Life Cycle. This covers everything from
the initial commercial idea until the final de-installation or disassembling of the product
after its use.There is a need to elaborate quality of modeling techniques as an important
essence in quality of process models. This process is a series of steps and decisions
involved in the way work is completed. We describe the flow of our project in diagrams
which are given below. Using these diagrams, we describe how user will interact with
system and how will system give response to users. By following the rules of process
model the following diagram are given as follows.
4.2 Package Diagram

Package diagram is Unified model language structure diagram which shows packages
and dependencies between the packages.
The figure 4-1 shown below is the Package diagram of @DSDFA the structure includes
standard pattern MVC (Model, View and Controller).
 View is used to display information to user on the required interface. View
includes Fans module, Players and Admin module.
 Controller is used to take data from model and pass it to view. Controller
behaves like bridge between view and controller. Controller includes
Commentary Module, Players, Teams, City, and Events.
 Model is taking data from database and pass to controller.
16
Figure 4.1: Package Diagram
4.3 Deployment Diagram

Deployment diagram is a structure diagram which shows architecture of the system as
deployment (distribution) of software artifacts to deployment targets. Artifacts
represent concrete elements in the physical world that are the result of a development
process.
The figure 4-2 shown below is the deployment diagram of @DSDFA as shown in the
diagram client will send request to view. After client submit the request, view will send
request to controller and controller will process on the view request and take response
from model. Controller will return response to view and client can view the response.
17
Figure 4.2:Deployment Diagram
4.4 System Sequence Diagram

A system sequence diagram (SSD) is a sequence diagram that shows, for a particular
scenario of a use case, the events that external actors generate their order, and possible
inter-system events.
18
4.4.1 ADMIN
The figure 4-3 shown below is the system sequence diagram of @DSDFA. Admin will
request for login and system will ask about login details. Admin will provide login
requirement (email, password) and system will return message (invalid email or
password) or return the profile page.
Figure 4.3: Admin Registration
19
4.4.2 PLAYER
The figure 4-4 shown below shows player registration. The process consists of the
admin that will request for register player and system will ask login details, Admin will
provide login requirement (email, password) and system will return message (invalid
email or password) or return the player registration page and admin will provide data
about player and system will response accordingly his/her request.
Figure 4.4: Player Registration
20
4.4.3 CITY
The figure below 4-5 shows that admin will request for register city and system will ask
login details. Admin will provide login requirement (email, password) and system will
return message (invalid email or password) or return the city registration page and
admin will provide data about city and system will response accordingly his/her
request.
Figure 4.1 City Registration
21
4.4.4 TEAM
The below figure 4-6 shows admin will request for register team and system will ask
return message (invalid email or password) or return the team registration page and
admin will provide data about team and system will response accordingly his/her
request.
Figure 4.6 Team Registration
22
4.4.5 MATCH
The below figure 4-7 shows admin will request for view matches and system will ask
return message (invalid email or password) or return the view matches page.
Figure 4.7: View Matches
23
4.5 Use Case
Use case diagrams are used to gather the requirements of a system including internal
and external influences. These requirements are mostly design requirements. Hence,
when a system is analyzed to gather its functionalities, use cases are prepared and actors
are identified.
Figure 4.8: Use Case
24
4.5.1 Admin Use Case
The figure 4-9 below shows the admin use case of @DSDFA, it illustrates the task that
can be perform by an admin he can add players, teams, city and match. On the other
hand, he can also Edit or view players, teams and city.
Figure 4.9: Admin Use Case

.
4.5.2 Viewers Use Case

The figure 4-10 below shows the viewers use case of @DSDFA, it illustrates the task
that can be perform by a viewer he can view the schedule of matches, live match, player
record, team record and live commentary.
Figure 4.10: Viewers Use Case
25
4.6 Data Flow Diagram
A data-flow diagram (DFD) is a way of representing a flowof a data of a process or a
system (usually an information system). The DFD also provides information about the
outputs and inputs of each entity and the process itself. Adata-flow diagram has no
control flow, there are no decision rules and no loops.
The figure 4-11 below shows the context level Data Flow Diagram of @DSDFA
Figure 4.11: Context level DFD
26
The figure 4-12 below shows the Level-1 Data Flow Diagram of @DSDFA
Figure 4.12: Level-1 DFD
27
4.7 Entity Relation Diagrams
An Entity-Relationship diagram (ERD) is a detailed representation of an information

that displays the relation between people, objects, places and events within that system.
The figure 4-13 below shows the entity relation diagram of @DSDFD. In this diagram
1 is used for one-time relationship and * is user many time relations.
Figure 4.13: ER Diagram
28
4.8 Entities and their attributes
Entities and their attributes are given in the following with diagrams
4.8.1 ADMIN
The Figure 4-14 below represents the attributes of city entity.
Figure 14: Attributes of Admin
4.8.2 CITY
The Figure 4-15 below represents the attributes of city entity.
Figure 4.15 Attributes of City
29
4.8.3 PLAYER
The figure 4-16 above represents the attributes of player entity.
Figure 4.16: Attributes of Player
4.8.4 TEAMS
The figure 4-17 above represents the attribute of team entity.
Figure 4.17: Attributes of Teams
30
4.8.5 TEAM MATCH
The figure 4-18 above represents the attribute of team matches entity.
Figure 4.18: Attributes of Teams Match
4.9 Work Plan

The figure 4-19 below represents the work plan of the project.
Figure 4.19:Work Plan
31
4.10 DATA DICTIOARY TABLE
The table 4-1 below illustrate the attributes, type and size, key and description to the
relation.
Relation Attribute Type and Key Description

Size
Admin Id int(10) Primary Identifies a administrator
Key
Username Varchar(50) Administrator User name
Password Varchar(50) Administrator Password.
City Id int(20) Primary Unique identifier of a City
Key
Name Varchar(50) Identifies a City Name
Commentary Id Int(5) Primary Unique key for the

Key Commentary
Text Varchar(50) Text value
date time Varchar(50) Date/time when commentary
is save
Match_id Int(5) Identifies a Match.
Goals Id int(10) Primary Uniquely identifies Goals
Key
Player id int(10) Save id of player against its
goals.
Match id int(10) Save id of Match
Team Id int(10) Save id of teams
Date Int(10) Save date time
Date Date Date of the uploaded news
Players Id int(10) Primary Uniquely identifies the Player
Key
32
Name Varchar(50) Full name of the Player
City int(10) City Name of the Player
cell number Varchar(20) Player phone number
Team Int(10) team of the Player
Image Varchar(50) Player image
Teams Id int(10) Primary Uniquely identifies teams
Key
Name Varchar(25) Full name of teams
City Int(10) City Name of team
Image Varchar(50) Image of team
Team Match Id int(10) Primary Uniquely identifies the Match

Key
Ist_Team Int(10) First Team
Second_Team Int(10) Second Team
Date Time Varchar(50) Date Time Of Match
City Int(10) City Name
Table 4.1: Data Dictionary
33
4.10 Design Goals
This describes the qualities of the system that developers should optimize. such goals
are normally derived from the non-functional requirements of the system.
They are grouped into five categories these are:
 Performance
 Dependability
 Maintenance
 End user criteria
 Performance
The system to be used should have a fast response time with maximum throughput. The
system should not take up much space in memory. There should be a fast response time
over throughput and hence the system should try to be more interactive and therefore
the system should be more reliable to satisfy constraints than fast response time.
 Dependability
District Football Associations needs a system that is highly dependable as it’s accepted
to be used by non IT professionals. The system needs to be fault tolerant and strong. As
the system is handling data of the players/teams.
 Maintenance
The system should be easily extensible to add new functionalities at a later stage. It
should be easy to modify any changes to features and functionalities.
 End User Criteria

From the end user point of view, the system is designed in such a way that it is easy to
learn and use.
34
CHAPTER 5
SYSTEM TESTING
35
5.1 Introduction
Software testing is a process of executing a program or application with the intent of
finding the software bugs. It can also be stated as the process of validating and
verifying that a software program or application or product: Meets the business and
technical requirements that guided its design and development., testing is an important
phase in development, it is also use to check the errors and bugs in the application if any
exits due to texting programmers are able to remove them from the application.
5.2 Test Plan
Testing plan of District Football Associations comprises of the following tests.

 Integration testing
 Deployment testing
 Unit Testing
We made this application of all the modules of our project and then tested every
application individually. The test modules are given below.
 Add players.
 Add teams.
 Add city.
 Add schedule.
 Add Goals.
 Add Commentary.
5.2.1 Integrating Testing
Then we combine all the modules together and then tested them. We combined all the
main modules and tested them as a whole like one application.
5.2.2 Deployment Testing
We deployed this website on local host and tested it.
36
5.2.3 Unit Testing
Unit testing is a level of software testing where individual units/ components of a

software are tested. The purpose is to validate that each unit of the software performs as
designed.
Unit testing is performed by using the White Box Testing method.
5.2.5 White Box Testing
White Box Testing is a software testing method in which the internal structure/ design/
implementation of the item being tested is known to the tester. The tester chooses inputs
to exercise paths through the code and determines the appropriate outputs.
Programming know-how and the implementation knowledge is essential. White box
testing is testing beyond the user interface.
Unit testing is only applied on those systems which is built on concept of Object
Oriented Programming. Our system is based on structured approach so that's why we
cannot apply Unit testing on our system.
5.2.6 Black Box Testing

Black Box Testing is also known as Behavioral Testing, is a software testing method in
which the internal structure/design/implementation of the item being tested is not
known to the tester. These tests can be functional or non-functional, though usually
functional.
This method is named so because the software program, in the eyes of the tester, is like
a black box; inside which one cannot see. This method attempts to find errors in the
following categories:
 Incorrect or missing functions

 Interface errors
 Errors in data structures or external database access
 Behavior or performance errors
 Initialization and termination errors
37
5.3 Test Cases
The following test cases were written and executed to compare the actual results with
the desired results. The following test cases are success scenarios. The test cases were
tested by Junaid Khan. The test cases consist of functionalities, actor, pre-condition,
input data and comparison of expected result with actual result.
5.3.1 Test Case 1
Test Case ID: TC001
Test Case Version Version 1.0
Functionality Add Teams
Actor: Admin
Pre-Condition: Valid data must be known.
Input data Add Teams Name , Add Teams city
Normal Flow Expected Result Actual Result
Teams must be added Teams gets registered
Table 5.1: Test case 1
38
Test Case 2
Test Case ID: TC002
Functionality Add Players
Actor: Admin
Input data Add Player Name , Add Player City , Add Player Team
Player must be added Player gets registered
Table 5.2: Test Case 2
5.3.3 Test Case 3
Test Case ID: TC003
Functionality Add City
Actor: Admin
Input data Add City Name
City must be added City gets registered
39
5.3.4 Test Case 4
Test Case ID: TC004
Functionality Add Schedule
Actor: Admin
Input data Add Schedule Name
Schedule must be added Schedule gets registered
5.3.5 Test Case 5
Test Case ID: TC005
Functionality Add Commentary
Actor: Admin
Input data Add Commentary Value
Commentary must be added Commentary gets registered
40
5.3.6 Test Case 6
Test Case ID: TC006
Functionality Edit Player
Actor: Admin
Input data Add Court Data
Player Data must be edit Player Data gets edit
5.3.7 Test Case 7
Test Case ID: TC007
Functionality Edit Teams
Actor: Admin
Input data Add Answer
Team must be edit Team gets edit
41
5.3.8 Test Case 8
Test Case ID: TC007
Functionality Edit city
Actor: Admin
Input data Add Question
City must be edit City gets edit
5.3.9 Test Case 9
Test Case ID: TC007
Functionality Add Players Goals
Actor: User
Input data Add Goals
Players Goals must be added Players Goals gets registered
42
CHAPTER 6
USER MANUAL
43
6.1 Screen Shots of Web Application Screen
6.1.1 Add teams by admin
Screen Shot of teams being added by admin
6.1.2 Add city by admin
Screen shot of city being added by admin
44
6.1.3 Add player by admin
Screen shot of players added by the admin
6.1.4 Add schedule of match
Screen shot of match schedule being added
45
6.1.5 View added teams
Screen shot of added teams
6.1.6 View city added by admin
Screen shot of cities added by admin
46
6.1.7 View Commentator by admin
Admin Console of Commentator
6.1.8 Schedule view by Commentator
Commentator console schedule view screen shot
47
6.1.9 Update commentary and goals by Commentator
Commentator updating goals and commentary of ongoing match
6.1.10 View matches by viewer
Fans/viewers view ofupcoming matches.
48
6.1.11 View both teams
Viewers view of both teams.
6.1.12 View players of both team
Screenshot of viewers viewing both team’s players
49
6.1.13 View live commentary
Viewers reading live commentary
50
CHAPTER 7
CONCLUSION
51
1. Conclusion
The objective of the project is fully accomplished. The proposed system is totally
digital and manages all the activity of football matches. It also manages to save data of
players and teams. The users will consume less amount of time when compared to
manual paper work through the automated system. The system takes care of all the
servicing activity in a quick manner. Data storing is easier. It is compatible to check any
report at any time. The system is user friendly and easy to use. There are 2 users’ i.e.,
the admin and the viewers. Admin has username and password saved in the system.
Using this username and password, admin can login to the system. Admin can add / edit
/ delete data of players / teams / operators. All this information will be stored in the
database. Next is the entry of the tournaments. The tournament date and the venue is
saved in the database for further confirmation. A list of players is also displayed and the
upcoming tournaments will be shown according to the particular time. The system also
provides a special authority of adding photos to the system for a particular player /
teams.
52
Appendixes: Source Code
<?php
include 'includes/head.php';
include 'includes/menu.php';
include 'functions/functions.php';
$already = 0;
$result = 0;
$validateTeam=0;
if (isset($_POST['save']) ) {
$tname = $_POST['tname'];
$city = $_POST['city'];
$s_image_name = image_name();
/*print_r($_FILES['tpic']);
exit();*/
if (!teamName($tname)) {
$validateTeam = 1;
else{
$query = "SELECT * FROM `teams` WHERE `name`='$tname'";
$already = return_rows($query);
if ($already==0) {
$query = "INSERT INTO `teams`(`name`, `cityId`,`image`) VALUES

('$tname','$city','$s_image_name')";
$result = insert_data($query);
if ($result==1) {
$s_path = "./teamImages/".$s_image_name;
$images = move_uploaded_file($_FILES['tpic']['tmp_name'],"../".$s_path);
53
$query = "SELECT * FROM `city`";
$city = retrieve_data($query);
?>
<div id="page-wrapper" style="height: 100%;">
<div class="container-fluid">

<div class="row">
<div class="col-lg-12">
<?php
if ($result == 1) {
?>
<div class="alert alert-success" role="alert">
<span class="glyphiconglyphicon-exclamation-sign" aria-hidden="true"></span>
<span class="sr-only">Success:</span>
Team With This Name Is Added
</div>
<?php }
?>
<?php
if ($already == 1) {
?>
<div class="alert alert-warning" role="alert">
<span class="sr-only">Warning:</span>
Team With This Name Is Already In The Database
</div>
<?php }
?>
<?php
if ($validateTeam ==1) {
?>
54
<div class="alert alert-warning" role="alert">
<span class="sr-only">Warning:</span>
Not able to add team Enter Name Correctly
</div>
<?php }
?>
<h1 class="page-header">
Add Teams
</h1>
</div>
</div>

<div class="row">
<div class="col-lg-6">
<form role="form" action="" method="post" enctype="multipart/form-data">
<div class="form-group">
<label>Team Name</label>
<input class="form-control" placeholder="Team Name" name="tname" required="">
</div>
<label>Select City</label>
<select class="form-control" name="city" required="">
<?phpforeach ($city as $key => $value) {
?>
<option value="<?php echo $value['id']; ?>">
<?php echo $value['name']; ?>
55
</option>
<?php } ?>
</select>
</div>
<label>Select Image</label>
<input class="form-control" placeholder="Team Name" name="tpic" required="" type="file">
</div>
<button type="submit" class="btnbtn-primary" name="save">Save Team</button>
<button type="reset" class="btnbtn-success">Reset</button>
</form>
</div>
</div>

</div>

</div>
<?php /*include 'includes/footer.php';*/
?>
56

Automation of Approval Certification

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Automation of Approval Certification

Uploaded by

Copyright:

Available Formats

APPROVAL CERTIFICATION

Project Committee Convener

1.3Tools and Technologies Used

 HTML (Hypertext Markup Language) + JavaScript used to make web interface

 PHP is used to make server side scripting.

1.4Design and Implementation Requirements

1.4.1 Hardware Requirements

1.4.2 Database Requirement

2.2 Existing System

Following are the problems and limitation of existing system

The implementation environment used to support the District Football Associations

3.2 System Modules

3.2.1 Module 1: Admin module

Scope:District Football Associations

Scope:District Football Associations

3.2.3 Module 3: Add player

Scope:District Football Associations

3.2.4 Module 4: Add city

Scope:District Football Associations

Scope:District Football Associations

3.2.6 Module 6: Delete teams

Scope:District Football Associations

3.2.7 Module 7: Delete players

Scope:District Football Associations

Scope:District Football Associations

3.2.9 Module 9: Show current

Scope:District Football Associations

3.3 Functional Requirements

3.4 Non-Functional Requirements

Non-functional requirements are as follows:

3.5 Business Requirements

Business requirements are as follows:

3.6 User Requirements

3.6.1 System Administrators

3.6.2 User (Commentator)

 View the current matches.

3.6.3 Users (Fan)

 View current and upcoming events.

4.1.1 Process Model

4.2 Package Diagram

4.3 Deployment Diagram

4.4 System Sequence Diagram

Figure 4.3: Admin Registration

Figure 4.4: Player Registration

Figure 4.1 City Registration

Figure 4.6 Team Registration

Figure 4.7: View Matches

Figure 4.8: Use Case

Figure 4.9: Admin Use Case

4.5.2 Viewers Use Case

Figure 4.10: Viewers Use Case

Figure 4.11: Context level DFD

Figure 4.12: Level-1 DFD

An Entity-Relationship diagram (ERD) is a detailed representation of an information

Figure 4.13: ER Diagram

Figure 14: Attributes of Admin

Figure 4.15 Attributes of City

Figure 4.16: Attributes of Player

Figure 4.17: Attributes of Teams

Figure 4.18: Attributes of Teams Match

4.9 Work Plan

Figure 4.19:Work Plan