Arba Minch Institute of Technology Arba Minch University: Arba Minch Kenema Foot Ball Club Information Management System

ARBA MINCH INSTITUTE OF TECHNOLOGY
ARBA MINCH UNIVERSITY
ARBA MINCH KENEMA FOOT BALL CLUB INFORMATION

MANAGEMENT SYSTEM
Group Members
Name ID
1. Abebe Alambo RET/569/02

2. Dagim Bekele RET/592/02
3. Tamrat Tadesse RET/579/02
4. Hana Tibebu RET/324/01
5. Emebet Dereju RET/938/02
Signature
Advisor: - Professor Ronaldo Abad Austria __________________________
Co-Advisor:-Behailu Mitiku __________________________
A Senior Project
Submitted to Department of Computer Science and IT, Institute of Technology, Arba Minch
University, in Partial fulfillment for the requirement of the Degree of Bachelor Science in
Computer Science.
Arbaminch, Ethiopia
11 June 2013
Acknowledgment
We have taken efforts in this project. However, it would not have been possible without the kind
support and help of many individuals and organizations. We would like to extend our sincere
thanks to all of them. We are highly indebted to Arba Minch University for providing necessary
resources and guidance as well as information regarding the project. We would like to express
our special gratitude and thanks to our advisors Professor Ronaldo Abad Austria,
Mr. Mohammed Abebe, Mr. Nebiat Fikru, Mr. Teshome Megersa, and Mr. Addis Hailu for
giving us such advice, attention and time to accomplish our project.
We would like to express our gratitude towards our parents and friends for their kind co-
operation and encouragement which help us in completion of this project.
Lastly, our thank and appreciation also go to AMIT, Department of Computer Science and
Information Technology in developing the project and people who have willingly helped us out
with their abilities.
I
Abstract
The Foot Ball information management system (FIMS) is a web-based service designed to
facilitate the burden of creating and maintaining league tables, registration of players and
officials, entry of results, and outcomes of all this operations. Essentially the system consists of
three large components. The first component is creation of the league itself. This component is
data intensive and involves the fixtures and registration of players. Secondly, the system
processes the results, updates league tables, statistics and produce readable output. Thirdly, the
system performs personal information’s like identifying goal scorers, yellow cards, and red
cards.
The league information can be performed online or offline. The online method is to use the
online screens to enter all the details via the keyboard. The offline method involves the creation
of file(s) in the FIMS league language format. These files are uploaded and then processed via
the online screens at speed. Personnel management provides records for players, referees, and
administrator. These records contain personal details such as addresses, telephone details, goals,
transfers, and incidents of yellow and red cards.
In general, Arba Minch Kenema Foot ball club has no automated information management
system. So, the group initiated to solve the problem by their final year project. Therefore, we
wish the department will provide all the necessary things to accomplish the project.
II
Table of Contents
Acknowledgment ............................................................................................................................. I
Abstract ........................................................................................................................................... II
List of Figures ............................................................................................................................... VI
List of Tables ............................................................................................................................... VII
Chapter One: Introduction of the whole project process ................................................................ 1
1.1 Introduction ............................................................................................................................... 1
1.2 Background of the Project ........................................................................................................ 1
1.3 Statement of the Problem .......................................................................................................... 2
1.4 Team Composition .................................................................................................................... 2
1.5 Objective of the Project ...................................................................................................................... 3
1.5.1 General Objective ........................................................................................................................ 3
1.5.2 Specific Objective......................................................................................................................... 3
1.6 Feasibility Analysis ............................................................................................................................. 3
1.6.1 Operational Feasibility ................................................................................................................ 3
1.6.2 Technical Feasibility ........................................................................................................................ 3
1.6.3 Economic Feasibility ....................................................................................................................... 3
1.6.4 Behavioral Feasibility ...................................................................................................................... 5
1.6.5 Schedule Feasibility ......................................................................................................................... 6
1.7 Scope of the Project .................................................................................................................. 6
1.8 Significance of the Project ........................................................................................................ 7
1.9 Target Beneficiaries of the system ............................................................................................ 7
1.10 Methodology for the Project ................................................................................................... 7
1.10.1 Data Source ................................................................................................................................... 7
1.10.2 Fact Finding Techniques ............................................................................................................... 7
A) Interview .......................................................................................................................................... 7
B) Document Analysis .......................................................................................................................... 7
1.11 Systems Analysis and Design ................................................................................................. 8
1.12 Development Tools ................................................................................................................. 8
1.13 Testing procedures (types of testing used).............................................................................. 8
1.14 Implementation ....................................................................................................................... 9
III
1.15 Limitation of the project ......................................................................................................... 9
1.16 Risks& Contingencies ........................................................................................................... 10
Chapter Two: Description of the Existing System ....................................................................... 11
2.1 Introduction to Existing System ............................................................................................. 11
2.2 Players in the existing system ................................................................................................. 11
2.3 Major Functions/Activities in the Existing System like Inputs, Processes & Outputs ........... 11
2.4 Business Rules ........................................................................................................................ 12
2.5 Report generated in the existing system ................................................................................. 12
2.6 Forms and other Documents of the Existing Systems ............................................................ 13
2.7 Bottlenecks of the Existing System (Using for Example PIECES Frame Work)................. 17
2.7.1 Performance (Response Time) ....................................................................................................... 17
2.7.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate) .................................................... 17
2.7.3 Security and Controls .................................................................................................................... 17
2.7.4 Efficiency........................................................................................................................................ 18
2.8 Practices to be preserved ......................................................................................................... 18
2.9 Proposed solution for the new system that address problems of the existing system............. 18
2.10 Requirements of Proposed System ....................................................................................... 18
2.10.1 Functional Requirements ............................................................................................................. 19
2.10.2 Non Functional Requirements ..................................................................................................... 20
Chapter Three: System Analysis ................................................................................................... 21
3.1 Introduction ............................................................................................................................. 21
3.2 System Requirement Specifications (SRS) ............................................................................. 21
3.2.1 Use Case Diagrams ....................................................................................................................... 21
3.2.2 Use case Documentation (for each use case identified) ................................................................ 22
3.2.3 Sequence Diagram ......................................................................................................................... 31
3.2.4 Activity Diagram ............................................................................................................................ 36
3.2.5 Analysis Level Class Diagram (Conceptual modeling) ................................................................. 43
3.2.6 User Interface Prototyping ............................................................................................................ 44
3.2.7 Supplementary Specifications ................................................................................................. 45
Chapter Four: System Design ....................................................................................................... 46

4.1 Introduction ....................................................................................................................................... 46
4.2 Class Type Architecture .................................................................................................................... 46
IV
4.3 Class Modeling ....................................................................................................................... 48
4.4 State Chart Modeling ........................................................................................................................ 49
4.5 Collaboration Modeling .......................................................................................................... 53
4.6 Component Modeling ............................................................................................................. 60
4.7 Deployment Modeling ............................................................................................................ 61
4.8 Persistence Modeling .............................................................................................................. 62
4.9 User Interface Design ............................................................................................................. 63
CHAPTER-5: CODING, IMPLIMENTATTION AND TESTING ............................................. 70
5.1 Introduction ....................................................................................................................................... 70
5.1.1 Coding ........................................................................................................................................ 70
5.2 Final Testing of The system .............................................................................................................. 74
5.2.1 Test cases ............................................................................................................................. 75
Actions .......................................................................................................................................... 75
Expected Results ........................................................................................................................... 75
Actions .......................................................................................................................................... 76
Actions .......................................................................................................................................... 77
5.3 Hardware and Software Acquisitions ............................................................................................... 78
5.4 User Manual Preparation .................................................................................................................. 78
5.5 Training ............................................................................................................................................. 78
5.6 Installation......................................................................................................................................... 78
5.7 Start up Strategy ................................................................................................................................ 79
Chapter 6: Conclusions and Recommendations ........................................................................... 80
6.1 Conclusions ....................................................................................................................................... 80
6.2 Recommendation.............................................................................................................................. 80
6.3 Reference: ......................................................................................................................................... 81
6.4 Glossary ............................................................................................................................................ 82
V
List of Figures
Figure 1: One-Time Cost Work Sheet .......................................................................................................... 5
Figure 2: Recurring Cost ............................................................................................................................... 5
Figure 6: Use Case Diagram ....................................................................................................................... 22
Figure 7: Sequence Diagram for Login....................................................................................................... 31
Figure 8: Sequence Diagram for Register Player....................................................................................... 32
Figure 9: Sequence Diagram for Buy Ticket .............................................................................................. 32
Figure 10: Sequence Diagram for Update Fixture ...................................................................................... 33
Figure 11: Sequence Diagram for View Profile.......................................................................................... 34
Figure 12: Sequence Diagram for Submit Comment .................................................................................. 34
Figure 13: Sequence Diagram for Generate Report .................................................................................... 35
Figure 14: Sequence Diagram for Create Account ..................................................................................... 35
Figure 15: Activity Diagram for Login ....................................................................................................... 36
Figure 16: Activity Diagram for Register Player ........................................................................................ 37
Figure 17: Activity Diagram for Buy Ticket .............................................................................................. 38
Figure 18: Activity Diagram for Update Fixture ........................................................................................ 39
Figure 19 Activity Diagram to View Profile .............................................................................................. 39
Figure 20: Activity Diagram for Submit Comment .................................................................................... 40
Figure 21: Activity Diagram for Generate Report ...................................................................................... 41
Figure 22: Activity Diagram for Create Account ....................................................................................... 42
Figure 23: Class Diagram ........................................................................................................................... 43
Figure 24: User Interface Prototyping ........................................................................................................ 44
Figure 25: Class Type Architecture ............................................................................................................ 46
Figure 26: Class Modeling .......................................................................................................................... 48
Figure 27: State chart modeling for login ................................................................................................... 49
Figure 28: State chart modeling for Create Account .................................................................................. 49
Figure 29: State chart modeling for Buy Ticket.......................................................................................... 50
Figure 30: State chart modeling for Submit Comment ............................................................................... 50
Figure 31: State chart modeling for Generate Report ................................................................................. 51
Figure 32: State chart modeling for Register Player ................................................................................... 51
Figure 33: State chart modeling for Update Fixture ................................................................................... 52
Figure 34: State chart modeling for View Profile ....................................................................................... 52
Figure 35: Collaboration Model for Login ................................................................................................. 53
Figure 36: Collaboration Model for Create Account .................................................................................. 53
Figure 37: Collaboration Model for Buy Ticket ......................................................................................... 54
Figure 38: Collaboration Model for View Profile ...................................................................................... 55
Figure 39: Collaboration Model for Submit Comment ............................................................................... 56
Figure 40: Collaboration Model for Generate Report ................................................................................. 57
Figure 41: Collaboration Model for Register Player................................................................................... 58
Figure 42: Collaboration Model for Update Fixture ................................................................................... 59
Figure 43: Component Modeling ................................................................................................................ 60
VI
Figure 44: Deployment Modeling ............................................................................................................... 61
Figure 45: Persistence Modeling................................................................................................................. 62
Figure 46: User Interface Design for Login ................................................................................................ 63
Figure 47: User Interface Design for Register Player ................................................................................. 64
Figure 48: User Interface Design for Buy Ticket........................................................................................ 65
Figure 49: User Interface Design for Submit Comment ............................................................................. 66
Figure 50: User Interface Design for Create Account ................................................................................ 67
Figure 51: update player registration .......................................................................................................... 68
Figure 52: Home Page ................................................................................................................................ 69
List of Tables
Table 1: Team composition .......................................................................................................................... 2
Table 2: Schedule Feasibility ........................................................................................................................ 6
Table 3: Development Tools ......................................................................................................................... 8
Table 4: Login Table ................................................................................................................................... 23
Table 5: Register Player table ..................................................................................................................... 24
Table 6: Buy Ticket table ............................................................................................................................ 25
Table 7: Update Fixture table...................................................................................................................... 26
Table 8: View Profile table ......................................................................................................................... 27
Table 9: Submit Comment table ................................................................................................................. 28
Table 10: Generate Report table ................................................................................................................. 29
Table 11: Create Account table................................................................................................................... 30
Table 12: Test case to register player.......................................................................................................... 75
Table 13: Test case to Login ....................................................................................................................... 76
Table 14: Test case to buy ticket ................................................................................................................. 77
VII
Chapter One: Introduction of the whole project process
1.1 Introduction
The Football Information Management System (FIMS) is a web service designed to facilitate the
burden of creating and maintaining league tables, registration of players and officials, creation of
fixtures, entry of results and output of all these operations.
Essentially the system consists of 3 large components. The first component is the creation of the
league itself. This component involves fixtures and registration of players. Secondly, the system
processes results to update league tables, statistics and produce readable result for the user.
Thirdly, the system performs personal information like, identifying goal scorers, yellow cards
and red cards and production of statistics.
Anyone who is involved in league administration understands the problems of teams and players
registration, scheduling of fixtures, result processing to produce tables and personal information
of players, and referees.
The league information can be performed online or offline. The online method is to use the
online screens to enter all the details via the keyboard. The offline method involves the creation
of file(s) in the FIMS league language format. These files are uploaded and then processed via
the online screens at speed.
1.2 Background of the Project

Arba Minch Kenema Foot ball Club is located in Arba Minch town, Southern Nation
Nationalities and Peoples Region (SNNPR) which is about 500 kilometers south of Addis Ababa,
at an elevation of 1285 meters above sea level. Formerly, Arba Minch Kenema Foot Ball Club
was known as Arba Minch Cherka-Cherk. Due to some problems Arba Minch Cherka-Cherk was
declined and finally dispersed. After that, the new club which is called Arba Minch Kenema Foot
Ball Club is formed. Before the formation, the club is under the control of Dashen Beer. And this
club joined Ethiopian premier league in the year of 2004 E.C.
Final Year Project Documentation Page 1

1.3 Statement of the Problem
The major problems associated with in the current systems are the following: The supporters,
spectators, and other foot ball fans do not access immediate information about the league like
fixtures, goal scorers, referee, squad and results of the match.
There is no web based time table for the supporters and spectators. Due to this reason supporters
or fans of the club doesn’t know with whom the team is going to play. This means they are
announced or notified by the media before two or three days left for the match. Each players of
the Arba Minch Kenema Foot Ball Club does not have web based personal profiles. Finally, the
supporter’s registrations and ticket selling is also processed manually, and this takes too long
time.
1.4 Team Composition

The team for this project is composed of five members.
Project Title Arba Minch Kenema Foot Ball Club Information Management System
S.No Name ID_No Email/Mobil Responsibility
1 Abebe Alambo RET/569/02 abebealambo@gmail.com All activity
Team 2 Dagim Bekele RET/592/02 dagimbekele78@gmail.com All activity

Members
3 Tamrat Tadesse RET/579/02 tamrattadesse@gmail.com All activity
4 Hana Tibebu RET/324/01 hanatibebu@ymail.com All activity
5 Emebet Dereju RET/938/02 emebetdereju@yahoo.com All activity
Date 11 June 2013
Advisor Professor Ronaldo Abad Austria
Table 1: Team composition

1.5 Objective of the Project
1.5.1 General Objective
The general objective of this project is to develop web-based Foot Ball Information management
system for Arba Minch Kenema Foot Ball Club.
1.5.2 Specific Objective

To achieve the above general objective, we will use the following specific objectives.
 To create a dynamic website for the club.
 Design interactive user interface for the foot ball information management system.
 Create a database to register foot ball fans or supporters and to store personal profiles for
individual players and manager of the club.
 Make easier way of selling tickets for spectators and supporters.
1.6 Feasibility Analysis

1.6.1 Operational Feasibility
The services of new system that we are going to develop are flexible and expandable. By looking
this flexibility and expandability, the management supports this system. Additionally, the new
system is also supported by foot ball fans and supporters of the club, because it makes them well
informed. Therefore, the system will be designed to be operationally feasible. This means, the
system will operate in any kind of platforms without any mal functionalities.
1.6.2 Technical Feasibility

For the future, the organization is eager to buy hardware’s and software’s like computers,
servers, operating systems, and they are also voluntary to host the system. This system is easily
upgraded to provide the necessary information for the users and users use the system without any
difficulty. Therefore, the system is technically feasible.
1.6.3 Economic Feasibility

Our system is economically feasible, because it reduces the time needed to perform certain
actions such as supporter’s registration, and budget to cover announcement, man-power, paper
and pen which they are using for manual work. Based on this, we divide the economic feasibility
in to two parts. These are intangible and tangible benefits. Tangible and intangible benefit
specifies the benefits and costs associated with the project.

Intangible Benefits:-
The following lists are intangible benefits associated with the project.
 Increase Employee Morale
 Reduce Resource Consumption
 Increase Management flexibility
 Provides more timely information
Tangible Benefits: -
 The team calculated the corresponding tangible benefits based on the technique called the
Time Value of Money (TVM).
Cost Reduction and Avoidance: - To calculate these, the following points will be considered.
 Total Number of workers in existing system= 20
 Total salary required for employees per month= 15000.00 Birr
 Total salary required for employees per year= 180000.00 Birr
 Total expense required for announcement per game= 5000.00 Birr
 Total expense required for announcement per year= 13*5000=>65000.00 Birr
 Total money required for payment per year= 180,000+65000=>245,000.00 Birr
 Average Number of workers needed when the new system is deployed= 10
 Total salary required for employees per month= 10,000.00 Birr
 Total salary required for employees per year= 120,000.00 Birr
 Total money required for payment per year= 120,000.00 Birr
 Difference b/n before and after deployment money required for payment
Cost Reduction and Avoidance=245,000.00 Birr -120,000.00 Birr=125,000.00 Birr
One time cost: - The following worksheet specifies the One Time cost associated with the
project.

ONE-TIME COST WORKSHEET
Arba Minch Kenema Foot Ball Club information Managements system Cost
1.New Hardware cost 150,000.00 Birr
2.InternetAccess 5,000.00 Birr
3.New (purchased) software 30,000.00 Birr
4.User training -------------------
___________________________________________________________________________
Total One-time costs 185,000.00 Birr
Figure 1: One-Time Cost Work Sheet
Recurring cost: - the following worksheet specifies the recurring cost of the project
RECURRING COST WORKSHEET

Arba Minch Kenema Foot ball information Managements system Cost
1.Data Base Administrator 3,500.00 Birr
2.New hardware/software lease 50,000.00 Birr
__________________________________________________________________________
Total Recurring cost 53,500.00 Birr
Figure 2: Recurring Cost

When we compare the cost analysis of the new system with the existing one it reduces the cost
by half percent. Therefore, the proposed system is advantageous over the existing system.
1.6.4 Behavioral Feasibility

Our system is behaviorally feasible, because the staff of the foot ball club was open minded
towards the acceptance of this new system, and there is no specialized training needed for the
users.

1.6.5 Schedule Feasibility
Schedule
Activities
4 5-7 8-12 13-19 20-22
weeks Weeks weeks Weeks Weeks
Project Proposal
Requirement
Analysis
System and
Object Design
Implementation
Documentation
and Submission
Table 2: Schedule Feasibility
1.7 Scope of the Project

Arba Minch Kenema Foot ball club performs its basic tasks manually. The scope of this project
is to develop and implement a new web-based foot ball information management System for the
club which will overcome the problems associated with the manual system.
The scope of the project is to:-
 To create and maintain league tables
 To register new players and officials

 To review fixtures, entry of results, news and output of all these operations
 Update league tables, statistics and produce readable output
 Performs personnel management like identifying goal scorers, yellow cards and red cards
and production of statistics
 Register supporters (fan) of the club
 Ordering ticket online

1.8 Significance of the Project
 To save time and resource needed
 To easily manage and control the system
 To provide immediate and updated information for the users
 To store individual players and managers information permanently
 To provide tickets easily for the spectators
1.9 Target Beneficiaries of the system

The main beneficiary of this system is the management, the club, fans of the club, and the users.
And this improves the quality of internal operations as well as services given to the users.
1.10 Methodology for the Project
1.10.1 Data Source

 Management office of the club
 Supporter of the club
 Documented Files
1.10.2 Fact Finding Techniques
A) Interview
We will orally discuss and interview with some staff members and manager of the Arba Minch
Foot ball club for necessary information’s. This information will help us to identify the clubs
associated problems and also to understand the current system. So, we will analyze information’s
of the club and obtain some basic concepts on how the club is managed in the current system.
B) Document Analysis
To understand the existing system, we can collect more information by referring books,
documents and other reading materials about player’s registration, ticket selling, supporter’s
registration, and general information of the club. It helps us to design and organize our project.

1.11 Systems Analysis and Design
The team will use object oriented system development methodology. This methodology is used
for simplicity, increased quality, faster development, code reusability and maintainability of the
system.
1.12 Development Tools
In this project the following system development tools will be used:-
Activities Software Tools
Client Side Scripting HTML
Platform MS Windows
Database Server Mysql
Web server Apache
Server-Side scripting PHP
Browsers Mozilla Firefox, Internet Explorer, Chrome
Editors Adobe Dream weaver CS5.5, EdrawMax,

Notepad++
Documentation Microsoft Word
User Interface Design HTML

Table 3: Development Tools
1.13 Testing procedures (types of testing used)

The team will perform two types of testing procedures for its functionality and meeting
customers need. These techniques are Black box testing and White box testing.
Black box testing: -

To test our system, the tester may use black box testing, if he/she has not enough time to check
internal modules or codes. By looking only input /output or user interface, the tester can test our

systems functionalities without looking the internal code. We used this testing technique for the
following reasons:-
 This testing type is more effective on larger units of code

 Tester needs no knowledge of implementation, including specific programming
languages
 Tester and programmer are independent of each other
 Tests are done from a user's point of view
White box testing: -
In this type of testing, skilled man in different programming languages tries to test the logic of
our system. If the person who tests the system is not skilled, it is difficult to understand our
systems functionality. If any failures occur while testing the system in all of the above testing
methods, the team will take immediate correction where this fault occurred before jumping to
next work. So, that it will meet the goal.
1.14 Implementation
To implement our system we will use different tools such as hyper text markup language
(HTML) for client side scripting, Java Script for validation, Mysql for database server, Apache
for web server, hyper text pre-processor (PHP) for server side scripting, and Macromedia Dream
weaver and Notepad++ for writing source codes.
1.15 Limitation of the project

This project is limited only to those activities and operations related to the foot ball information
management system which the team is intended to deal and it will not perform those activities
and operations out of the scope.

1.16 Risks& Contingencies
Technical Risks: These risks may result from excessive constraints, lack of experience, poorly
defined parameters, or dependencies on organizations outside the direct control of the project
team. In order to mitigate or control this risk the team will perform periodic checks on the work
that have been done.
Requirement changes: since this risk leads to system poor communication resulting in
misunderstandings, quality problems and rework, the team altered participatory type of data
modeling to overcome such risks. Since, the team discusses with the customer when needed in
each phase, the team will handle this risk before it leads to system rework.

Chapter Two: Description of the Existing System
2.1 Introduction to Existing System
With the existing system, all the activities are performed manually such as ticket selling,
supporter registration, fixtures which are tedious job and care has to be taken of each and every
transaction with the clients. Presently, all the access is maintained on paper, which increases the
additional job of maintaining the paper work. A report is later prepared manually on pre-defined
format printed on paper.
2.2 Players in the existing system

In the existing system there are various actors to carry out foot ball information management
system.
Administrator:-this body controls the overall actions of the team such as financing, controlling
and maintain of the whole team.
Referee:-skilled person who tries to match the two opposite team.
Supporters: - are the foot ball fans that are supporting the club.
The main actors of the existing system are:-
 Administrator
 Coach
 Supporter
2.3 Major Functions/Activities in the Existing System like Inputs, Processes &
Outputs
The main functions of the existing system are new player registration, supporter’s registration,
ticket selling, report generation, and administrator role. All these information are recorded on the
paper.
 Administrator Role
Input:-detailed information of the whole team situation.
Process:-maintain and control over all activity of the system.
Output:-having organized team.

 Supporter Registration
Input: - Detail information of supporter
Process: - Register information of supporter
Output: - providing identity card of supporter
 Ticket Selling
Input:-preparing ticket on the number of supporter
Process:-selling the ticket to supporter and spectator
Output:-collecting the total cost of the ticket.
 Coach
Input:-detailed information about the team
Process: - perform trainee to the players of the team.
Output:-having well organized players
2.4 Business Rules

The major business rules in the existing system are the following:-
 Ticket selling:-tickets are sold during game playing time by ticket sellers. Many supporters
and spectators buy ticket during that time.
 Each and every player of the team should obey the club rule.
 Each and every player of the team should train before the match.
 Each player should play in his/her own position.
 There is no direct contact between each player and referee during the match.
 The players should not insult the referee.
 The players should wear their club uniform.
 Each match should contain four referee and eleven players in the field.
2.5 Report generated in the existing system

In an existing system there are different kinds of reports which are generated for different
purposes. Those reports include ticket selling report, supporters report, player’s status report,
budget plan report, Players sign-In and sign-Out report.

 Ticket Selling Report
After the ticket has been sold by ticket sellers, the financial body of the club will generate how
many tickets have been sold and how many tickets are left. Financial man calculates money
based on ticket numbers and types.
 Supporters Report
Based on numbers of supporters registered, supporters association will generate number of
supporters and how much income collected from the supporters to the management of the club.
 Players Status Report

This report will be generated by the coach (manager) of the club. Manager reports status of
individual players like player’s performance, health status, injury report, and position of players.
 Budget Plan Report

Management of the club will generate annually reports how much budget the club needs for
player salary, signing new players, buying club uniforms and shoes.
 Player Sign-In and Sign-Out Report

When new players are signed-In and existing players transfer to another club, manager of the
club point out which player should be signed-In to club and which player should be transferred.
2.6 Forms and other Documents of the Existing Systems

Currently Arba Minch Kenema Foot ball club uses different forms and reports to manipulate
different records associated with different activities. From those forms some are Players
registration form, Supporters registration form. Some sample forms associated with the current
system are shown below.

Player Registration Form

Supporters Registration Form

2.7 Bottlenecks of the Existing System (Using for Example PIECES Frame
Work)
Manually Kenema foot ball club information management system is prone to various problems.
These problems can be seen from the following perspectives like performance, information,
economic, control, efficiency and services given by the existing system to the users, by using the
PIECES framework as follows.
2.7.1 Performance (Response Time)

The current system’s performance is weak. This is due to the following reasons: -
 First, the acceptable throughput rate is relatively high i.e. the time required from initiation
to completion of a particular task is relatively high. For example supporter registration.
To be supporter of the club, he/she has to go to supporter’s association office to be
registered. This may take a long time, if the person is far apart from supporter’s
association office.
 Second is the acceptable response time for a particular task is large.
2.7.2 Input (Inaccurate/redundant/flexible) and Output (Inaccurate)

Input
 Receive incorrect/redundant personal information about the player.
 List of the players and supporters does not contain their full information on the papers.
Output
 If one player’s information is repeated, this will make unwanted redundancy in the
system.
2.7.3 Security and Controls

Since all the records associated with in the system are recorded and stored manually, the
security that the system provides is not good. The system shouldn’t provide sufficient protection
for accessing and manipulation of the records associated with the system. Therefore, it is not
easily protected.

2.7.4 Efficiency
In manual operation, most of the activities are prone to wastage of resources like papers, man
power, time etc. to generate the corresponding outputs. This makes the current system inefficient
while utilizing resources. There should be a mechanism that reduce wastage of resources and that
make the system to be efficient.
2.8 Practices to be preserved
The existing system use file and forms that is used to perform the business rules, describe the
operations, definitions and constraints that apply in the maintenance and deployment of system.
Team member preserve the following practices from the existing system.
 There is manual ticket selling system, supporter’s registration system, and player’s
registration system.
2.9 Proposed solution for the new system that address problems of the existing
system
To address the problem of the existing system the team has studied and analyzed the problems
of the existing system. To come up with the possible solutions associated with those problems a
group will just follow the natural system development methodologies as the only option for
addressing and solving those problems associated with the current system.
 This new system is a web based application that enables the users to access the services
given by the system through the Internet.
 The proposed system will enables the club to store information on the database.
2.10 Requirements of Proposed System
In generally, our proposed system contains two different kinds of requirements. These are
Functional and Non-Functional requirements.

2.10.1 Functional Requirements
Our proposed system functionally requires process, Input related, Output related, Storage related
requirements, and other specific functionality that define what a system is supposed to
accomplish.
Process Requirements
The proposed system will do the following processes.
 The system receives background information about each player of the club from the
administrator and stores that information permanently in the database.
 The system receives ticket number and user information from users and orders ticket online.
 When the customer didn’t register the system gives the option to register.
Input Related Requirements
 Background information about each player should be entered in the database by system
administrator.
 Supporters of the club must be registered by supporters association.
 For online ticket ordering, ticket number and user information should be entered by the users.
 When new players join the club, their personal information should be entered to the database
by the system administrator.
 Accept users comment
Output Related Requirement
 The system shall provide immediate information for the users.
 The system shall store personal information about the players and coach with in the database.
 The system shall report annual schedule of the match for the spectators.
 The system performs personnel management like identifying goal scorers, yellow cards and
red cards for each players while they are playing.
Storage Related Requirements
 The system shall store all the data related with all the tasks performed into a database

2.10.2 Non Functional Requirements
Proposed system non-functionally requires performance, User Interface, Security and access
permissions, backup and recovery, and other specific functionality that define what a system is
supposed to accomplish.
Performance Requirements
 Our proposed system shall provide 7x24 hrs access for the users.
 The proposed system runs on any kind of operating system.
 After the user information is submitted the response time must be fast enough.
 The system shall accommodate number of users at a time.

User Interface
 Users easily navigate and access our web page by using user interface designed
 The system must be compatible with any environment and user friendly
Security and Access Permission
 Our system is secured; means unauthorized body cannot damage system and system
resources.
 All the ticket number and personal identification information shall be encrypted.
 The system shall permit the administrator to edit player’s information.
 Without entering ticket number and user information ticket will not be sold for supporters.
 Players will not register them self as a club member
Backup and Recovery
 It is easy to recover data stored on the server in case of unexpected server failure.
 The first option to back up or recover data is using distributed data base.
 We can use an offline data base server if current data base server crushes. Fetching data from
an offline server makes proposed system more efficient than existing system.

Chapter Three: System Analysis
3.1 Introduction
In this project, the team will use an object oriented system development methodology which
incorporates two principal phases. These principal phases are Object-Oriented Analysis and
Object-oriented Design. For this project, the team will use the object oriented analysis
(OOA).During Object Oriented Analysis the following major activities are performed.
System Requirement Specifications (SRS), Use case diagrams, Use case documentation (for each
use case identified), and Sequence diagram, Activity Diagram, User Interface Prototyping, and
Supplementary specifications.
3.2 System Requirement Specifications (SRS)
We can divide requirements in to two parts. Hardware and Software requirements.
Hardware and software requirements for this project are listed below.
Hardware Requirements
 Computer
 Printer
 Pen Drive
Software Requirements
 Notepad++
 E-draw
 Xampp server
 Microsoft Windows
 Microsoft-Office
3.2.1 Use Case Diagrams
The major actors that plays major role out of the system are: - Admin, Coach, and
Supporter. The use cases incorporated in the system are:-Login, Register Player, Buy
Ticket, Update Fixture, View Profile, Submit Comment, Generate Report, and Create
account .

Register
Player Buy Ticket
<<include>>
Update Fixture <<include>>
<<include>>
Admin
Login
Generate <<include>>
Report
<<include>>
<<include>>
Submit
Comment
Create
Account
Supporter
Coach View Profile
Figure 3: Use Case Diagram

3.2.2 Use case Documentation (for each use case identified)
The following successive tables show the use case documentation for each of the use cases that
has been identified in the above use case diagram. Each table contains the use case name, the
actor which initiates and interacts with the use case, description of each use case and typical
course of events that show the interaction between the actor and the use case which enable the
team to easily depict the functions of the proposed system.

1) The use case documentation for “Login” use case.
Use case name Login
Actors Admin
Description This use case describes the process of submitting user name and password to the
database.
Precondition Administrator should submit personal information’s like user name and password.
Postconditon Administrator will update database and Register new players.
Basic Course Actor action System Response
of Action Step1: Administrator should click
Login Button Step 2: Redirect to the Login Page.
Step 3:Administrator should
Fill Login detail and Submit it to Step 4: Checks the User ID and Password of
The Data base. administrator from the data base if it exists or
not.
Step 5: If the User ID and Password is valid,
Administrator page is displayed.
Alternate If Admin submits invalid information to database, send a notification to the
Course of Administrator to re-submit valid information.
Action
Table 4: Login Table

2) The Use case documentation for “Register Player” use case.
Use case name Register Player
Actors Admin
Description This use case describes the process of registering new players to the database.
Precondition Administrator should login to the system.
Postconditon Administrator should register new players to the database.
of Action Step 1: Administrator should click
Login Button
Step 2: Redirect to the Login Page.
Step 3: Administrator submits Step 4: Checks if User ID and Password is valid or not
user ID and password to the from the database.
system. Step3: If User ID and Password is valid, Admin page
is displayed.
Step 4:Administrator can register newStep 5:checks all personal information about the
new players to the database. Players are filled or not.
Step 6: If all fields are filled, players are successfully
registered.
Alternate If some of the fields are not filled, send a notification to the Administrator to fill all the
Course of fields again.
Action
Table 5: Register Player table

3) The Use case documentation for “Buy Ticket” use case.
Use case name Buy Ticket
Actors Supporter
Description This use case describes the process of buying and selling tickets to supporters and
spectators.
Precondition Spectators or supporters should have to buy ticket from the shop.
Postconditon Supporters should get confirmation number from the system.
of Action Step 1: Supporters should buy
ticket. Step 3: Check whether the ticket number is valid or
Step 2: Supporters should enter not from the data base.
his/her basic info and ticket Step 4: If ticket number is valid, registration for ticket
number. is successful.
Alternate If supporters or spectators submit invalid ticket number, send notification to re-submit
Course of valid ticket number.
Action
Table 6: Buy Ticket table

4) The Use case documentation for “Update Fixture” use case.
Use case name Update Fixture
Actors Admin
Description This use case describes the process of updating immediate information like results.
Precondition There should be new information.
Postconditon Administrator should update database after the game has been finished.
of Action Step 1: Administrator should
click Login Button Step 2: Redirect to the Login Page.
Step 3: Administrator should
login to the system. Step 4: Checks if the User ID and Password is valid
or invalid from the database.
Step 5: If User ID and Password is valid, Administrator
Page is displayed.
Step 6: Administrator can
update fixtures and other
immediate information’s.
Alternate If Admin submit invalid information, send notification to re-submit valid information.
Course of
Action
Table 7: Update Fixture table

5) The Use case documentation for “View Profile” use case.
Use case name View Profile
Actors Supporter
Description This use case describes the process of viewing personal information about the players
from the database.
Precondition There should be personal profile in the database.
Postconditon Supporter should view personal profile of the individual player.
of Action Step1: Supporter should click
Teams Menu.
Step 2: All players Name displayed.
Step 3: Supporter should click
the name of the player he/she
want to view. Step 4: Personal info about the player displayed.
Alternate ---
Course of
Action
Table 8: View Profile table

6) The Use case documentation for “Submit Comment” use case.
Use case name Submit Comment
Actors Supporter
Description This use case describes the process of submitting user comments to the clubs website.
Precondition Supporters or spectators should have user Id and Password to submit comment.
Postconditon Supporters or spectators should submit their comments to the clubs website.
of Action Step 1:Click Write Comment Button
Step 2: Redirects to the Login button
Step 3:Click Login Button
Step 4: Redirects to the Login Page
Step 5: Supporters should login to the
system by using User ID and Password. Step 6: Displays comment box for the users.
Step 7: Now supporters or spectators

can post message on the website.
Alternate If supporter submits invalid User Id and Password, send notification to re-submit valid
Course of User ID and Password.
Action
Table 9: Submit Comment table

7) The Use case documentation for “Generate Report” use case.
Use case name Generate Report
Actors Coach
Description This use case describes the process of generating reports about transfer, injury, and
general information about club.
Precondition There should be new information to be generated.
Postconditon After getting new information, coach should generate report and post on the club
website.
Basic Course of Actor action System Response
Action Step 1: Coach should click Login
Button
Step 2: Redirect to the Login Page.
Step 3: Coach submits user ID and Step 4: Checks if User ID and Password is valid
password to the system. or not from the database.
Step 5: If User ID and Password is valid, Coach
page is displayed.
Step 6: Coach can generate report

and submit to the database.
Alternate Course If coach submits invalid User Id and Password, send notification to re-submit valid
of Action User ID and Password.
Table 10: Generate Report table

8) The Use case documentation for “Create Account” use case.
Use case name Create Account
Actors Supporter
Description This use case describes the process of creating accounts to be supporter of the club.
Precondition There should be website for the club.
Postconditon After filling necessary information, user should be supporter’s member of the club.

of Action Step 1:Supporter should click
Sign Up button Step 2:Display Sign up Page
Step 3: Fill the necessary Step2: Checks if an information filled is valid or not.
information to create an account Step 3: If information filled is valid, notifies the
and Submit to the data base. account is created successfully and redirects to the
supporter page.
Alternate If supporter fills invalid information, send notification to fill it again.
Course of
Action
Table 11: Create Account table

3.2.3 Sequence Diagram
Figure 4: Sequence Diagram for Login

Figure 5: Sequence Diagram for Register Player
Figure 6: Sequence Diagram for Buy Ticket

Figure 7: Sequence Diagram for Update Fixture

Figure 8: Sequence Diagram for View Profile
Figure 9: Sequence Diagram for Submit Comment

Figure 10: Sequence Diagram for Generate Report
Figure 11: Sequence Diagram for Create Account

3.2.4 Activity Diagram
Administrator
Click Login
Button
Enter Login Info
Invalid
Check Enter Login Info
Valid
Display Admin
Page
Figure 12: Activity Diagram for Login

Administrator
Click Login
Button
Enter Login Info
Invalid
Check Enter Again
Valid
Display Admin
Page
Click Register
Player Button
Enter Player Info
Player is
Invalid Valid
Enter Again Check Successfully
Registered
Figure 13: Activity Diagram for Register Player

Supporter
Get Ticket
Number
Enter basic info

and ticket number
Invalid
Check Re Enter
Valid
Successfully register
Figure 14: Activity Diagram for Buy Ticket

Administrator
Click Login
Button
Enter Login Info
Invalid
Check Enter Again
Valid
Display Admin
Page
Click Update Successfully

Update Fixture
Fixture Button Updated
Figure 15: Activity Diagram for Update Fixture
Supporter
Click Teams
Menu
Select Player Name
Display Player
Profile
Figure 16 Activity Diagram to View Profile

Supporter
Click Write
Comment Button
Click Login
Button
Enter Login Info

Valid
Invalid
Check Enter Again
Valid
Display Comment
Box
Successfully
Write Comment
Submitted
Figure 17: Activity Diagram for Submit Comment

Coach
Click Login
Button
Enter Login Info
Invalid
Check Enter Again

Valid
Display Coach
Page
Click Report Successfully

Button Generate Report
Generated
Figure 18: Activity Diagram for Generate Report

Supporter
Click Sign Up
Button
Enter Sign Up Info
Invalid
Check Enter Again
Valid
Display Supporter
Page
Successfully
Created
Click L
Figure 19: Activity Diagram for Create Account

3.2.5 Analysis Level Class Diagram (Conceptual modeling)
Figure 20: Class Diagram

3.2.6 User Interface Prototyping
Home Page
NEWS FIXTURE TABLE TEAMS HISTORY GALLERY CONTACT US
Administrator Supporter Coach
Sign In Log In Log In
Search View Profile

Create Account
Register Player Submit comment

Submit comment
Create Account
Buy Ticket
Generate Report
Update Fixture
Create Account
Generate Report Log Out
Log Out
Sign Out
Figure 21: User Interface Prototyping

3.2.7 Supplementary Specifications
The Supplementary Specifications capture the system requirements that are not readily captured
in the use cases of the use-case model. Such requirements include:-
 Legal and regulatory requirements and application standards.

 Quality attributes of the system to be built, including usability, reliability, performance,
and supportability requirements.
 Other requirements such as operating systems and environments, compatibility
requirements, and design constraints.
The other Supplementary specifications are the business rules .The business rules is a principle
or a policy in which the proposed system operates accordingly. It deals with access control issue.
Some of the business rules that we have included in this project are the following
 Ticket selling:-ticket should be sold during game playing time by ticket sellers. Many
supporters and spectators buy ticket during that time.
 Each and every player of the team should obey the club rule.
 Each and every player of the team should train before the match.
 Each player should play in his/her own position.

Chapter Four: System Design
4.1 Introduction
System Design is the process of defining the architecture, components, Modules, Interfaces,
Deployment, and data for a system to satisfy the specified requirements. In the case of our
project the team members used object-oriented analysis and design methods. This object-oriented
method is the most widely used methods for systems design and analysis. The UML has become
the standard language in object-oriented analysis and design.
4.2 Class Type Architecture
User Interface Layer
Process Layer
System Layer
Domain Layer
Persistence Layer
Data Source
Figure 22: Class Type Architecture

 User interface layer
This Layer is the form which provides the application to either programmer or end user.
 Process layer
This Layer implements business logic that involves collaborating with several domain
classes or even other process classes
 Domain layer
This layer is used to transfer data from application layer or presentation layer to data
layer. This layer is also used when a class variables are declared corresponding to the
fields of the database which can be required for the application and make the properties.
So that, the team can gets or sets the data using these properties into the variables.
 Persistence layer
This layer encapsulates the capability to store, retrieve, and delete objects/data
permanently without revealing details of the underlying storage technology. This layer is
also a class to get or set data to the database queries back and forth.
 System layer
This Layer provides operating-system-specific functionality for our applications,
isolating our software from the operating system (OS) by wrapping OS-specific features,
increasing the portability of our application.

4.3 Class Modeling
Coach
Account
Position:String LName:String
Salary:Float FName:String
Email:String
Password:String
Phone:Int
Login() Street:String
Generate Report() Nationality:String
Create Account() Sex:String Supporter
Birth Date:Date
Administrator Salutation:String
Create Account()
Update() First Name:String
Middle Name:String
Education Status:String Last Name:String
Salary:Float Sex:String
Email:String
Password:String
Register Player() Login Nationality:String
Update Fixture()
Login()
1
* User ID:String
Create Account()
Password:String Create Account()
Buy Ticket()
1 Submit() Login()
* Reset() Submit Comment()
Player
BuyTicket
Mother's Name:String View Profile
License Number:Int Name:String
Photo:String Phone Number:Int
City:String Email:String
Position:String SitNo:Int Name:String
Height:Float Position:String
Weight:Float Submit()
Previous Club:String Cancel()
Contract Start Date:Date
Contract End Date:Date
View()
Register()
Reset()
Figure 23: Class Modeling

4.4 State Chart Modeling
Valid Display Admin

Click Login Button Enter Login Info
Page
Invalid Success
Figure 24: State chart modeling for login
Click Sign Up Valid Display Supporter

Enter Sign Up Info
Button Page
Invalid
Successfully Created
Figure 25: State chart modeling for Create Account

Valid Display Successfully
message
Invalid
Success
Figure 26: State chart modeling for Buy Ticket
Click Write Valid Display Comment

Comment Button Box
Invalid
Success
Write Comment
Figure 27: State chart modeling for Submit Comment

Valid Display Coach Click Report
Page Button
Invalid
Successfully
Generated
Generate Report
Figure 28: State chart modeling for Generate Report
Click Login Button Valid Display Admin Click Register

Enter Login Info
Page Player Button
Invalid
Invalid
Enter Player Info
Valid
Success
Successfully
Registered
Figure 29: State chart modeling for Register Player

Click Login Button Valid Display Admin Click Update
Enter Login Info
Page Fixture Button
Invalid
Successfully
Updated
Update Fixture
Figure 30: State chart modeling for Update Fixture
Click Teams Menu Select Player Name Display Player

Profile
Figure 31: State chart modeling for View Profile

4.5 Collaboration Modeling
Enter Login
Detail Security Login
Click to Login Web Page
Administrator <<UI>>
<<UI>>
Validate
Enter Again
:AMKFIMS
<<DB>>
Success
Valid
Admin Page
Figure 32: Collaboration Model for Login
Click To Login Security Login

Supporter Main Screen Fill Info
<<UI>>
<<UI>>
Validate
Enter Again
:AMKFIMS
<<DB>>
Successefully
created Valid
Supporter Page
Figure 33: Collaboration Model for Create Account

Get Ticket
Number Security Login
Supporter Main Screen Enter Basic
<<UI>>
<<UI>> Info and Ticket
Number
Validate
Enter Again
:AMKFIMS
<<DB>>
Success
Valid
Sends Successfully
message
Figure 34: Collaboration Model for Buy Ticket

AMKFIMS
Click Teams Team Page Enter Login
Supporter <<DB>>
Menu <<UI>> Detail
Display Player
Enter Again Profile
:Web Page
<<UI>>
Figure 35: Collaboration Model for View Profile

Figure 36: Collaboration Model for Submit Comment

Click To Login Security Login
Main Screen Submit
Coach <<UI>>
<<UI>> Login Info
Validate
Enter Again
:AMKFIMS
<<DB>>
Valid Successfully
Generated
Submit Coach Page
Click Report
Write Report
Generate Report Web Page
Figure 37: Collaboration Model for Generate Report

Click To Login
Security Login
Main Screen Submit
Administrator <<UI>>
<<UI>> Login Info
Validate
Enter Again
:AMKFIMS
<<DB>>
Valid Successfully
Registered
Submit Admin Page
Click Register
player
Enter player
Register Player Web Page
Info
Figure 38: Collaboration Model for Register Player

Get Ticket
Number Security Login
Supporter Main Screen Enter Basic
<<UI>>
<<UI>> Info and Ticket
Number
Validate
Enter Again
:AMKFIMS
<<DB>>
Success
Valid
Sends Successfully
message
Figure 39: Collaboration Model for Update Fixture

4.6 Component Modeling
Access
Administrator
Admin
Access
Coach
Coach
Foot Ball Information
Management System
Access
Supporter
Supporter
Figure 40: Component Modeling

4.7 Deployment Modeling
Figure 41: Deployment Modeling

4.8 Persistence Modeling
Figure 42: Persistence Modeling

4.9 User Interface Design
Figure 43: User Interface Design for Login

Figure 44: User Interface Design for Register Player

Figure 45: User Interface Design for Buy Ticket

Figure 46: User Interface Design for Submit Comment

Figure 47: User Interface Design for Create Account

Figure 48: update player registration

Figure 49: Home Page

CHAPTER-5: CODING, IMPLIMENTATTION AND TESTING
5.1 Introduction
In this phase what the group members have done is turning the physical design specification into
working computer code, and then the code is tested until most of the errors have been detected
and corrected. User sites are prepared for new system and user must come totally on the new
system rather than the existing one to get there work done. There are some managerial activities
in this, coding, testing, and installation.
5.1.1 Coding
The physical design specification created by the designers is turned in to working computer
code.
Administrator Login Script

Administrator Account Creation Code

5.2 Final Testing of The system
Black box testing: -To test our system, the tester may use black box testing, if he/she has not
enough time to check internal modules or codes. By looking only input /output or user interface,
the tester can test our systems functionalities without looking the internal code. We used this
testing technique for the following reasons:-
 This testing type is more effective on larger units of code

 Tester needs no knowledge of implementation, including specific programming
languages
 Tester and programmer are independent of each other
 Tests are done from a user's point of view
White box testing: -
In this type of testing, skilled man in different programming languages tries to test the logic of
our system. If the person who tests the system is not skilled, it is difficult to understand our
systems functionality. If any failures occur while testing the system in all of the above testing
methods, the team will take immediate correction where this fault occurred before jumping to
next work. So, that it will meet the goal.

5.2.1 Test cases
Test Case 1: Register player
Test case objective : To register player
Test case description: Admin enters basic info of the player, then presses register button.
Client program contacts with server, server contacts with the database, and database checks for
registration and sends message to the administrator.
Requirements Verified: Yes
Test Environment: Apache mysql server must be in running state, Database Should contain
appropriate table and link must be established between server and client program.
Test Setup/Pre-Conditions: Apache server should be in running state and all fields should be
filled.
Actions Expected Results

The administrator should login and press the register menu. Displays registration page.
Administrator should enter player information Displays success message
If some fields are not filled the system display to fill the fields again.
Table 12: Test case to register player

Test Case 2: Login
Test case objective : To login to the system
Test case description: Admin enters Username and Password, then presses login button.
Client program contacts with server, server contacts with the database, and database checks for
authentication and displays administrator page.
Test Environment: Apache mysql server must be in running state, Database Should contain
appropriate table and link must be established between server and client program.
Test Setup/Pre-Conditions: Apache server should be in running state and User name and
Password fields should be filled correctly.

The administrator should enter the correct user name and Displays administrator page.
password to login.
If user name and password are not filled correctly the system display to fill the user name and
password again.
Table 13: Test case to Login

Test Case 3: Buy ticket
Test case objective : To buy ticket
Test case description: supporter should login to the system. Supporters fill the fields to buy
the ticket and press register button.
Test Environment: There should be internet connection to register in order to buy ticket.
Test Setup/Pre-Conditions: The supporter’s basic info and ticket number should match.

Displays ticket buying
page.
The supporter should buy ticket.
If supporter basic info and ticket number do not filled correctly, the system will display to fill
the supporter basic info and ticket number again.
Table 14: Test case to buy ticket

5.3 Hardware and Software Acquisitions
For the project implementation; the following Software and hardware tools are used.
Hardware Tools:-
 Server: for connection to the client computer(to host the system)
 Computers
 Network connection
 Printer: For printing Documentation
Software Tools
For the System implementation the following software’s are used.
 Dream weaver CS5.5
 Notepad++
 Mysql database server
 Xampp
5.4 User Manual Preparation

No more manual preparation is needed for users, because the system developed is not software
and it is not installed on a client computer. After the implementation has been completed, it is
directly hosted on Network (server).
5.5 Training
During the deployment of the system, the project group members will give short time training for
the system administrators and clerks explaining how the system works and in what way they can
manage the system developed.
5.6 Installation
Since the project is a web based System, there is no need to install it on a particular machine
rather it will be hosted on a server.

5.7 Start up Strategy
Once the system has been published, the user can start and access his/her authorized page by
entering the correct Username and Password with proper authentication and authorization
processes.

Chapter 6: Conclusions and Recommendations
6.1 Conclusions
It is known that developing a web based system for an Arbaminch Kenema foot club ball
information management system is not easy. It is also very difficult for the project members to
gather the documented data because the project area does not have documented materials. But
the team has developed interesting web based information management system for Arbaminch
Kenema foot ball club.
It is flexible, accurate and attractive with easy GUI approach. Generally, the team confidently
can ensure that the software is completed successfully with negligible errors. Finally the team
expects that the developed system will change the general information management atmosphere
of the Arbaminch Kenema foot ball club information management system, and makes it more
reliable and efficient than the previous manual system.
6.2 Recommendation
According to scope of our project the team develops web application .Because of the time constraint
we cannot do beyond to our scopes, but in the future the team believes that this system can be fully
operational by having enough time and full information.
Nextly, the team would recommend that further work should be done on the system in order to make
the system perform better like official website of Arsenal, Barcelona, and others. For example
currently, for Arba Minch Kenema foot club has no seat number in the stadium and credit card system
is not available currently. Due to this reason ticket selling is not fully online. When credit card system
and seat number is available, the interested group will have to accomplish the following things:-
 Ticket Selling should be online by using Credit card system.

 Arrange seat numbers and places for supporters or spectators based on their amount of
payment.

6.3 Reference:
1. Gary B.Shelly and Harry J.Rosenblatt (2011).System Analysis Ninth Edition
2. Roger S.Pressman (2005).Software engineering a practitioner’s approach Sixth Edition
3. Official website of Arsenal, London (http://www.arsenal.com)
4. Official website of Barcelona, Spain (http://www.barcelona.com)
5. Learn to create Website: http://www.w3schools.com/html/

6.4 Appendix
Abbreviations Description
AMIT Arba Minch Institute of Technology
Admin Administrator
AMKFIMS Arbaminch Kenema Football information Management system
CS5.5 Cascading style sheet 5.5
DB Database
E-Draw Erasable Digital Read After Write
FIMS Football Information management system
GUI Graphical User Interface
HTML Hyper text markup Language
ID Identity card
INFO Information
MS Microsoft
MYSQL Structured Query Language
OOA Object oriented Approach
PHP Hypertext Preprocessor
SNNPR Southern Nation Nationalities and People Region
SRS System Requirement Specification
TVM Time Value of Money
UI User Interface
UML Unified Modeling Language

Arba Minch Institute of Technology Arba Minch University: Arba Minch Kenema Foot Ball Club Information Management System

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Arba Minch Institute of Technology Arba Minch University: Arba Minch Kenema Foot Ball Club Information Management System

Загружено:

Авторское право:

Доступные форматы

ARBA MINCH INSTITUTE OF TECHNOLOGY

ARBA MINCH UNIVERSITY

ARBA MINCH KENEMA FOOT BALL CLUB INFORMATION

1. Abebe Alambo RET/569/02

Advisor: - Professor Ronaldo Abad Austria __________________________

Co-Advisor:-Behailu Mitiku __________________________

Chapter Four: System Design ....................................................................................................... 46

1.2 Background of the Project

Final Year Project Documentation Page 1

1.4 Team Composition

S.No Name ID_No Email/Mobil Responsibility

1 Abebe Alambo RET/569/02 abebealambo@gmail.com All activity

Team 2 Dagim Bekele RET/592/02 dagimbekele78@gmail.com All activity

4 Hana Tibebu RET/324/01 hanatibebu@ymail.com All activity

5 Emebet Dereju RET/938/02 emebetdereju@yahoo.com All activity

Date 11 June 2013

Advisor Professor Ronaldo Abad Austria

Table 1: Team composition

Final Year Project Documentation Page 2

1.5.2 Specific Objective

1.6 Feasibility Analysis

1.6.2 Technical Feasibility

1.6.3 Economic Feasibility

Final Year Project Documentation Page 3

 Increase Employee Morale

 Reduce Resource Consumption

 Increase Management flexibility

 Provides more timely information

Cost Reduction and Avoidance=245,000.00 Birr -120,000.00 Birr=125,000.00 Birr

Final Year Project Documentation Page 4

Figure 1: One-Time Cost Work Sheet

RECURRING COST WORKSHEET

Figure 2: Recurring Cost

1.6.4 Behavioral Feasibility

Final Year Project Documentation Page 5

Table 2: Schedule Feasibility

1.7 Scope of the Project

The scope of the project is to:-

 To create and maintain league tables

 To register new players and officials

Final Year Project Documentation Page 6

1.9 Target Beneficiaries of the system

1.10 Methodology for the Project

1.10.1 Data Source

1.10.2 Fact Finding Techniques

Final Year Project Documentation Page 7

1.12 Development Tools

In this project the following system development tools will be used:-

Activities Software Tools

Client Side Scripting HTML

Database Server Mysql

Web server Apache

Server-Side scripting PHP

Browsers Mozilla Firefox, Internet Explorer, Chrome

Editors Adobe Dream weaver CS5.5, EdrawMax,

User Interface Design HTML

1.13 Testing procedures (types of testing used)

Black box testing: -

Final Year Project Documentation Page 8

 This testing type is more effective on larger units of code

1.15 Limitation of the project

Final Year Project Documentation Page 9

Final Year Project Documentation Page 10