Uploaded by LONGATUNYO SILVANUS OME

ONLINE TABLE BANKING MANAGEMENT SYSTEM

advertisement
KABARAK
UNIVERSITY
TABLE BANKING MANAGEMENT SYSTEM
BY
NAME: LONGATUNYO SILVANUS OME
REG NO: DIT/N/0354/01/20
A Research proposal submitted in partial fulfillment of the requirements for the
award of Diploma in Information Technology.
APRIL, 2022.
DECLARATION
This project is my original work and has not been submitted to any other institution of
higher learning for any award.
Signature_________________________
Date__________________________
Registration No: DIT/N/03544/01/20
Name: LONGATUNYO SILVANUS OME
This project has been given for examination with my approval as the project
supervisor.
Signature_________________________
Date__________________________
Supervisor
Mr. ELVIS SAIKWA
ii
DEDICATION
This research project is dedicated to my beloved family members, who have offered
me support from the time I started. Thank you and May God bless you abundantly.
iii
ABSTRACT
Online Table Banking Management System is a Web based application that works
within a centralized network. This project presents a review on the manual table
banking System” as should be used in a local groups and organizations system. OTBS
is built for managing and computerizing the traditional database, table banking and
tracking contributions made. It maintains all customer details, contributions details.
The software achieved is capable of improving the customer hand and relationship
management in the operations. It is recommended that despite the present
functionality of the designed software, an additional functionality such as the use of
E-mail to send messages and notifications to the customer and an online payment
using credit cards/debit cards should be implemented into the system. Furthermore,
other operations such as the m-pesa should also be integrated in order to enhance the
system.
Key words: OTBS, Online Table Banking System.
iv
TABLE OF CONTENTS
DECLARATION..........................................................................................................ii
DEDICATION............................................................................................................ iii
ABSTRACT ................................................................................................................. iv
TABLE OF CONTENTS ............................................................................................ v
LIST OF FIGURES ................................................................................................. viii
LIST OF ABBREVIATIONS ..................................................................................... x
CHAPTER ONE .......................................................................................................... 1
INTRODUCTION........................................................................................................ 1
1.1 Introduction to Online Table Banking Management System. .............................. 1
1.2 Background to the study. ...................................................................................... 1
1.3 Problem Statement. .............................................................................................. 2
1.4 purpose of the study. ............................................................................................ 3
1.5 Objectives ............................................................................................................. 3
1.6 Research Questions .............................................................................................. 3
1.7 Justifications for the study/significance of the study. .......................................... 3
1.8 The scope of the study(delimitation) .................................................................... 4
1.9 Limitations of the study........................................................................................ 4
1.10 Assumptions of the study. .................................................................................. 4
CHAPTER TWO ......................................................................................................... 6
LITERATURE REVIEW ........................................................................................... 6
2.1 Introduction .......................................................................................................... 6
2.2 Existing systems ................................................................................................... 6
2.3 Design an automated system ................................................................................ 6
2.4 Implementation of an automated management system. ....................................... 7
2.5 Research Gap........................................................................................................ 7
2.6 conceptual Framework ......................................................................................... 9
CHAPTER THREE ................................................................................................... 10
METHODOLOGY .................................................................................................... 10
3.1 Introduction ........................................................................................................ 10
3.1.1 System Development Methodology ................................................................ 10
3.1.2 Justification for the Methodology ................................................................... 11
3.1.3 Data Collection Approaches............................................................................ 11
v
3.4 Data Analysis Tools Techniques ........................................................................ 12
3.5 Feasibility Study................................................................................................. 12
3.5.1 Social operational feasibility ........................................................................... 12
3.5.2 Economic feasibility ........................................................................................ 13
3.5.3 Technical feasibility ........................................................................................ 13
3.5.4 Schedule feasibility ......................................................................................... 13
3.6 Development Tools ............................................................................................ 14
3.6.1 Programming tools .......................................................................................... 14
3.6.2 Database tools ................................................................................................. 14
3.6.3 System modeling tools .................................................................................... 14
3.7 Summary ............................................................................................................ 14
CHAPTER FOUR ...................................................................................................... 15
SYSTEM ANALYSIS AND REQUIREMENT MODELLING. ........................... 15
4.1 Introduction ........................................................................................................ 15
4.2 Description of the Current System ..................................................................... 15
4.2.1 Overview of the current system ...................................................................... 15
4.2.2 Problems associated with the current system .................................................. 15
4.3 System Requirements ......................................................................................... 16
4.3.1 Functional requirements .................................................................................. 16
4.3.2 Non-functional requirements........................................................................... 16
4.3.3 Domain requirements ...................................................................................... 17
4.3.4 Database requirements .................................................................................... 17
4.4 System Modelling .............................................................................................. 18
CHAPTER FIVE ....................................................................................................... 19
SYSTEM DESIGN ..................................................................................................... 19
5.1 Introduction ........................................................................................................ 19
5.2 Description of the System .................................................................................. 19
5.2.1 Home page....................................................................................................... 19
5.2.2 Create user ....................................................................................................... 19
5.2.3 Delete user ....................................................................................................... 20
5.2.4 Transfer money ............................................................................................... 20
5.2.5 Transactions history ........................................................................................ 20
5.3 Physical Process Design ..................................................................................... 20
5.4 Database Design ................................................................................................. 22
5.4.1. System Screenshots ........................................................................................ 22
vi
CHAPTER SIX .......................................................................................................... 25
SYSTEM IMPLEMENTATION .............................................................................. 25
6.1 Introduction ........................................................................................................ 25
6.2 Tools Used For Coding And Testing ................................................................. 25
6.2.1 Coding tools .................................................................................................... 25
6.3 System Test Plan ................................................................................................ 26
6.4 User Acceptance Testing.................................................................................... 26
6.5 Proposed Change-Over Techniques ................................................................... 27
CHAPTER SEVEN .................................................................................................... 29
CONCLUSIONS AND RECOMMENDATIONS ................................................... 29
7.1 Recommendations .............................................................................................. 29
7.1.1 Reduction in strictness of the Time deadlines ................................................. 29
7.1.2 Provision of project finances to the students ................................................... 29
7.1.3 Compelling some institutions to pave way for the students to develop .......... 29
7.1.4 Future improvements ...................................................................................... 29
7.2 Conclusion.......................................................................................................... 30
REFERENCES ........................................................................................................... 31
vii
LIST OF FIGURES
Figure 2. 1: conceptual design diagram ......................................................................... 9
Figure 4. 1: Data flow diagram for current system ...................................................... 18
Figure 5. 1: Data flow diagram for system administrator ............................................ 21
Figure 5. 2: system home page .................................................................................... 22
Figure 5. 3: Create user menu ...................................................................................... 23
Figure 5. 4: Remove user menu ................................................................................... 23
Figure 5. 5: Transfer money menu ............................................................................... 24
Figure 5. 6: Transaction history ................................................................................... 24
viii
LIST OF TABLES
Table 2. 1: Research gap ................................................................................................ 7
ix
LIST OF ABBREVIATIONS
GUI
Graphical User Interface
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
PHP
Hypertext pre-processor
IEEE
Institute of Electrical and Electronics Engineers
MIME
Multipurpose Internet Mail Extensions
SRS
Software Requirements Specification
DFD
Data Flow Diagram
UML
Unified Modeling Language
SDLC
System Development Life Cycle
XAMPP
Windows Apache MySQL PHP
OS
Operating System
NGOs
non-governmental organizations
NCCK
National Council of Churches of Kenya
x
CHAPTER ONE
INTRODUCTION.
1.1 Introduction to Online Table Banking Management System.
This Online Table Banking Management System shall help the user to keep track of
all the activities in the Chama. It is a web-based application that shall have users like
admin, beneficiaries and supervisor. The interface is developed using html and PHP.
It has user-friendly web interface. In today’s developing era, the numbers of table
banking are increasing inmost over the planet. So, developing this system shall
provide efficient service delivery to every table banking user today and in the future.
In addition, Chama users shall not be necessary to be present physically but only need
to login to access the services he/she may want. Using this system, the user shall be
able to make his/her contribution anywhere or at his/her place of residence or choice.
The aim of designing this system is to help the user because they are not required to
move to the beneficiary’s place which ultimately saves the time, efforts and money.
1.2 Background to the study.
Table Banking is a group-based funding strategy in which members save and borrow
immediately. It is a concept that has been in existence for some time and is being
practiced in many parts of the world. It caters for small business people who require
credit to finance their income generating activities and are not able to access credit
from formal banks nor from most micro-finance institutions due to long distances,
high charges and interest rates and conditional ties which they cannot meet (ROK,
2009).
On a given date in a month member place their savings and loan repayments on the
table to be accessed for immediately borrowing by the members. However, a small
percentage for administration can be retained. Savings include monthly contributions
for insurance and education, various penalty fines, membership fees and other micro
funds. Initial capital comes from the members. However, the managing institution
provides further funding, also known as Table Top-Ups, to boost the capital and pay
for social mobilization and administration services in the early stages (ROK, 2009).
Many actors and agents acknowledge relevance of Table Banking (Aguilar 2006).
Table banking takes on the model of the Grameen bank of Bangladesh and the village
savings and loans schemes of Zanzibar. Table banking was initially developed by the
Poverty Eradication Commission (PEC) under the former Ministry of Planning and
Vision 2030, targeting Millennium Development Goals number one that is on
eradicating abject poverty, especially in rural settings.
In Kenya Table-banking was first piloted in Gatanga and Bondo constituencies. The 9
results were very impressive but the government did not continue with the roll out
there after. JOYWO adopted and implemented it in Uasin Gishu, Nandi, Kakamega,
Trans-Nzoia, Bungoma and Nairobi. Reports from the said areas indicated ever-rising
demand for table-banking in other counties.
The success stories from these areas have been impressive and forms justification for
a possible country-wide roll-out program. Joywo is currently running Table banking
activities in 32 Counties in Kenya, turkana county included.
In Turkana especially, it has not been really formalized as it is done locally organized
groups funded by locally based NGO (non-governmental organizations) like NCCK
(National Council Of Churches Of Kenya) and Swiss Contact while others are fully
funded by members contributions which are maybe monthly or even weekly basis.
This small grouping normally faces problems like mismanagement, funds
embezzlement even dire disagreement which costs the group to the extent of
dissolution. All this problem is caused by lack of a stable systems that is free from
manipulation by management or organizers and therefore there is need to have a
stable system which is web -based and more secure to automated all the group/Chama
transactions since each member will be able to access it anytime and anywhere as
long as he/she is connected to the internet
1.3 Problem Statement.
Currently in table banking groupings, the transactions are collected manually. There is
no systematic approach of storing data that ends up in loss or misappropriations by
those in charge. There are many cases where money collected is lost or even
embezzled due to lack of clear data storage mechanisms in place. The quality at which
transactions are mostly done usually are not up to the mark since money handled
manually faces many threat agents like robbery of even loss thus beneficiaries usually
2
do not benefit since there is no privacy. Reaching the aims of the foundations of the
group has been really a problem. To solve the above problems, there is need for the
current manual system to be computerized. With this in mind, the system will be an
online web-based system that will enable automation of most of transactions
processes. The system will also provide a database for storing beneficiaries
information for future formalities.
1.4 purpose of the study.
The main goal of developing this system is to facilitate online based automation of
transactions done by members of table banking groupings and organizations in order
to make it more secure and thus increase the overall service delivery to its members.
1.5 Objectives
The main objective of the project is to develop an automated banking system.
Specific objectives
i.
To determine the existing table banking systems
ii.
To design an automated table banking system.
iii.
To implement an automated table banking system.
1.6 Research Questions
The study will be guided by the following research questions:
i.
To what extent has monthly or weekly contributions from table banking has
been handled?
ii.
To what extent does the management control the general group activities?
iii.
To what extent does monthly or weekly reports being produced and which
means are used?
1.7 Justifications for the study/significance of the study.
Over the past decades, rural households in Kenya have been involved in the activities
of informal savings schemes that raise capital from internal accruals that do not carry
any negative connotations and members who are shareholders control management of
these schemes. Through table banking activities, group funds from savings accruals
are retained within the group and are used as a credit source by members wishing to
3
boost their investment potential to reach ultimate performance in economic
empowerment. Despite household participation in such schemes in turkana county,
they are facing administrative issues due to lack of a proper system. This study will
therefore cast light into level of success and attributing factors that may help boost the
level of participation in table banking projects as a basis for achieving economic
empowerment.
1.8 The scope of the study(delimitation)
The study will assess the effectiveness of delivery channels of group savings and loan
scheme in Turkana West Sub County-Turkana County. The study will focus on
savings and loan groups promoted and supervised by the local NGO’s and local
entrepreneurs who form such groups for member financial empowerment. In carrying
out the study it will focus on assessing the members’ satisfaction with the services
offered by the scheme, groups operating efficiency and effects of the scheme on lives
of participating members in Turkana West Sub- County.
1.9 Limitations of the study.
The time allocated to this study may be short. In addition, the hardware may
sometimes experience failure due to design size; its size may cause the failure thus
slowing the study progress. The study will be limited by inadequate financial
resources therefore limiting the study coverage to only a small area. The researcher
however will overcome these limitations by using existing structure owned by NGOs
and self-help groups working within the vicinity who are in contact with self-help
groups or organizations that are custodians to information needed for the study. This
linkage will also help in minimizing impact of short time and also tackling hardware
failure since the actual size of the desired design will be crystal clear.
1.10 Assumptions of the study.
The study will assume that all respondents will be available and willing to participate
in the study. It is assumed that respondents will provide reliable data to be used in
making inference to the rest of the population. It is also assumed that the data
collection tools will have a high level of reliability and validity to aid in gathering
reliable data. The researcher appreciates the rich diversity in demographic profiles of
location from which the data is to be collected. Given the cultural affiliations and
varying beliefs the study assumes that the respondents truthful and correctly will
4
respond to the questions posed to them by the researcher. The assumption in location
selection is based on the fact that the target population is not uniform since the
localities may not necessarily have similar socioeconomic characteristics.
Homogeneity is assumed at individual strata level. However, considering the location
constraint, as such, the target and 6 accessible populations cannot be regarded as
homogeneous. This consideration ensures that each sub-group characteristic is
represented thus raising the external validity of the study.
5
CHAPTER TWO
LITERATURE REVIEW
2.1 Introduction
This chapter begins by examining the existing systems of table banking. It also
analyzes the efficiency, service delivery and the methods used by the administrators.
It also touches on the user satisfaction of the existing system and the proposed
solutions to curb the issue of poor service delivery and the efficiency the old systems.
2.2 Existing systems
This subsection examines the baseline models of existing systems and the knowledge
concerning the software, workload, hardware and other tools associated with the
monitoring of these systems and the overall ease of access to records and finally
system operations. Throughout my research I have conclude that all the existing
systems carry their daily operation manually. Manual systems are prone to many
problems including inaccurate record management, issues to do with loss of data, and
many more others. All the above issues associated with manual systems can be
addressed by introducing an improved system that is online based which have proper
structures and basically simpler way to access data, make contributions and finally
manage records, this will reduce management costs, and enhances greater service
delivery and customer satisfaction and finally data is save from loss.
2.3 Design an automated system
Nowadays, human believe the automation more and more. Because of the technical
development of hardware and software, automation has already replaced numerous
aspects of human-machine system.
The purpose of automatic is to make software replace the human works to make
people feel more convenient. Therefore, the most obvious thing is the automatic
software need to face all the requirements from human. We make software and make
the pc like a real man who can help us for our events and can communicate with us.
And here comes the challenge, replying the diversity of conditions and requirements.
6
2.4 Implementation of an automated management system.
Humans do make errors, but properly implemented automated systems do not. Human
errors are not only inefficient in that they must be corrected and lead to productivity
delays, but they can be costly. For instance, adding too many digits when paying an
employee or vendor. Serious mistakes can lead to security and compliance issues,
potentially fines and penalties. An automation system limits human intervention in
the transfer of data, which minimizes the occurrence of errors and it has the following
advantages;
Managing tasks and deadlines-For processes to run smoothly, employees must know
what to do and when to do it. Your automation system should allow you to create and
view pending tasks and deadlines, as well as redistribute tasks as needed.
Access control and security-To protect the security of your systems, you need to be
able to set access privileges throughout the organization and also offer advanced
security features to protect data from being compromised.
2.5 Research Gap.
Table 2. 1: Research gap
Author
Name of the Weaknesses
system
Gidraph J Nduati

Manual
They are often "single entry"
Preformatted
systems, meaning you enter each
record
transaction only once. As such,
books.
there is no automatic check and
balance system like that used in
computer
(like Quicken
programs
-- or
in
more
formal double entry bookkeeping
systems.

You must manually tally up
expenses or income by category
or by month -- which can be time
consuming.
7
Andra Picincu

Enterprise
Security issues: security risks for
record
businesses
management
printed documents can be easily
system
lost, mishandled or damaged
is
paper
because
while digital data could be
encrypted and safely keep in
hard disk or electronic devices.

Lack of storage space: paper
documents
can
take
up
a
significant amount of space, and
the
quantity
of
paper
will
increase day by day. However,
documents will typically need to
be stored close to hand so that
they can be accessed as quickly
as possible.
Andra Picincu

Cloud-based
Security in the cloud: since data
records
is store on the internet, hackers
management
will also be able to access it,
software
resulting in security breaches
including data loss and account
hijacking.

Technical issues: it limits one
from being able to access to files
due to slow internet connection.
8
2.6 conceptual Framework
This subsection explains how the whole system framework is implemented beginning
from the administrator down to the logout page when a user’s exits the system, this is
how the system should look at the end of the development process.
Administrator
Home page
Create user
database
Make a transaction
Transaction history
Figure 2. 1: conceptual design diagram
9
Remove users
CHAPTER THREE
METHODOLOGY
3.1 Introduction
It is important to fulfill the planning of the implementation phase. This can only be
done if proper methodology is selected. Methodology is important to make sure all
project life cycle activities are being carried out without any shortcuts. Methodology
helps the system developers to take one step at a time towards accomplishing the full
system. The following section discusses on the choice of methodology towards the
implementation of Online Table Banking System for local Chamas.
3.1.1 System Development Methodology
This system underwent all the stages of system development lifecycle (SDLC).
According to the nature of this system and the data collected, a waterfall methodology
was used to develop this system. This methodology included the following stages:
feasibility study, requirement analysis and specification design, coding, testing,
integration then maintenance. Each phase required a different amount of effort and
every phase had a well-defined starting and ending point. Every phase had to be
completed before beginning the next stage
Feasibility
study
Requirement
analysis and
specification
Design
Coding
Testing
Integration
Maintenance
10
3.1.2 Justification for the Methodology
The waterfall methodology was worthwhile because this approach produced a
complete quality system and error-free system due to the fact that every phase had to
be completed before the next one began thus leaving no phase unattended.
However, according to the data collected on the user requirements, there was a clear
understanding of the user requirement hence no doubt on what was to be developed.
Similarly, the approach was also less costly since there was no repeating of a process
once completed and thus minimized wastage of resources as compared to other
approaches such as the rapid prototyping methods.
3.1.3 Data Collection Approaches
So as to collect data from Easy coach bus ticket booking system as well as its clients,
appropriate methods of collecting data were needed. These techniques included the
following:
3.1.3.1 Observation
This involved the researcher going to the field of study, making direct watch on the
way the organization under study operates, identifying the possible drawbacks of the
operating system analyzing the problems and developing a solution based on the
observations made. This technique was employed since it provides a first-hand
information which is quite reliable and accurate since the method provided a quick
overview of the system. It is the most effective technique.
3.1.3.2 Interviews
This is a direct face to face conversation between the system analyst(interviewer) and
the users of the system. This was used where the respondents were few in order
clarifying and verifying gathered facts. This technique was important to use since
some data could not be collected by direct observation unless interviewed, hence it
helped in enriching the data for quality processing.
11
3.1.3.3 Questionnaires
A questionnaire refers to a set of questions prepared by the person collecting data in a
paper which is issued to specific people who in turn respond to the questions privately
without the presence of the interviewer. Once the respondent is through, he/she will
issue the answers back to the person collecting the data. This technique was also
important because some interviewees
we’re not confident enough to respond to the question at the interview panel during
the interview, and therefore a questionnaire best suited for such people.
3.4 Data Analysis Tools Techniques
Data analysis is the process of evaluating data using analytical and logical reasoning
to examine each component of data provided. Data from various sources was
analyzed after being gathered and reviewed so as to come up with conclusion. The
current system was evaluated using the gathered facts or information. These tools
included be the following: Use of tables and charts
3.5 Feasibility Study
The feasibility study was intended to examine the current system and determine
whether there was need for a new system to replace it or not. It tended to check
whether the current system was viable. Basically, this was meant to analyze the
feasibility of a new system through cost-benefit analysis. It included: operational
feasibility, economic feasibility, technical feasibility and schedule feasibility.
3.5.1 Social operational feasibility
This is a measure of how well a proposed system solves the problems, and takes
advantage of the opportunities identified during scope definition and how it satisfies
the requirements identified in the requirements analysis phase of system development.
It dealt with the effect of the system on the current society within the community.
The operational feasibility assessment focused on the degree to which the proposed
development projects fitted in with the existing business environment and objectives
with regard to development schedule, delivery date, corporate culture, and existing
business processes.
12
To ensure success, desired operational outcomes were imparted during design and
development. These included such design-dependent parameters such as reliability,
maintainability, supportability, usability, predictability, disposability, sustainability,
affordability and others. These parameters were considered at the early stages of
design where desired operational behaviors were to be realized. A system design and
development required appropriate and timely application of engineering and
management efforts to meet the previously mentioned parameters. A system may
serve its intended purpose most effectively when its technical and operating
characteristics are engineered into the design. Therefore, operational feasibility is a
critical aspect of systems engineering that needed to be an integral part of the early
design phase. The Online Table Banking system solutions was found reliable and
adaptable therefore making it operationally feasible.
3.5.2 Economic feasibility
The purpose of the economic feasibility assessment was to determine the positive
economic benefits to the organization that the proposed system had to provide. It
included quantification and identification of all the benefits expected. This assessment
typically involved the Cost-Benefits Analysis (CBA). Undoubtedly the Online Table
Banking system was found economically feasible and no possibility of it outliving its
usefulness in the near future.
3.5.3 Technical feasibility
The assessment focused on gaining an understanding of the present technical
resources of Table Banking sector and their applicability in the proposed system.
This was aimed at evaluating both hardware and software required for the new
system. It also determined whether the current facilities were adequate for the new
system implementation.
3.5.4 Schedule feasibility
Schedule feasibility is a measure of how reasonable the project timetable is. The
project would fail if it took too long to be completed before it is useful. However, this
means estimating how long the system would take to develop, and if it can be
completed in a given time period using some methods like payback period. According
to the time schedule of this system, it was clear that the project would be scheduled
13
feasible since it would take approximately 3 months which was a relatively short
period for such a system.
3.6 Development Tools
3.6.1 Programming tools
HTML and PHP were used for coding purposes as they served best during web-based
applications. JAVA SCRIPT was also employed for scripting purposes while CSS
was used to format the web pages and creating appealing and user-friendly interfaces
of the system. Visual Studio Code editor was used to edit the code.
3.6.2 Database tools
For database creation and connection purposes XAMPP was used which also has PHP
MYADMIN for database management and hosting.
3.6.3 System modeling tools
Data flow diagrams, sequence diagrams and use case diagrams were some of the
system modeling tools that would be used to draw in the development process.
3.7 Summary
From the discussed methodology, it is evident that every system must undergo
through a series of steps in a system development lifecycle. The methodology stated
above was used throughout the system development and this helped in coming up
with an Online Table Banking system that would address the needs of Easy coach
organization and also its clients.
14
CHAPTER FOUR
SYSTEM ANALYSIS AND REQUIREMENT MODELLING.
4.1 Introduction
In this chapter, the current system used in Table Baking system is to be examined and
the relevant analysis done on it. The core aim of this is to determine whether there is
need for a new system or not. The chapter also explains how the current system works
by providing system requirements through various models that enables one to
comprehend the system better. Modelling tools such as Data Flow Diagram (DFD),
flowcharts, use case diagrams and others are used in the chapter.
4.2 Description of the Current System
4.2.1 Overview of the current system
Currently, Table Banking system does not have a particular developed system for
enhancing the online table banking transactions. This implies that there is lack of any
kind of interaction between the administrator and the members. In most of time,
anyone wishing to do make contributions has to choose from any of the following two
options in order to make his/her contributions:
i.
Visiting the management office to make the necessary inquiries upon
which contributions are done.
ii.
Contacting the chairman of the group through a communication
channel in order to inquire about the contribution process.
4.2.2 Problems associated with the current system
The main challenge associated with the current system is that potential members have
travel all the way to where the Table Banking office is located. As a result, there is
consumption of time which would be avoided by having an automated system.
Making contributions through a call can limit the provision of enough information
which might cause inconveniences of service delivery. All these are both tedious and
time-consuming activities.
There is also problem of members being unable to assess the progress of their
contributions amounts not unless they directly contact the manager which in turn
consumes time in both parties.
15
In some cases, the interested members may not know exactly where the office is
located, other than visiting it. This problem is clearly solved by the new system which
provides all relevant information about the Online Table Banking System are all
available online and are accessible anytime and anywhere.
4.3 System Requirements
So as to be in a position to automate the manual system at table banking chamas, an
automated system was required. This system allows users to perform their
contributions while in remote environments. Due to this, several requirements were
thus required in order to come up with a system that will allow this. Such
requirements will be classified into three; functional, non- functional and domain
requirements.
4.3.1 Functional requirements
These requirements are those that enable the system to operate. These requirements
focus mainly on what the system should do. They include:

Users have to register themselves by creating accounts to gain access
to the system’s services.

User authentication by use of password.

The system has two database views; the super administrator has more
privileges than the other users. The system shall validate users
accessing data in the system through use of password and username
validation and verification. A login dialog box will be used for these
purposes.

The categories of users allowed to access data in the system are:
I) Administrator,
The super Admin will be responsible for making changes to the database while the
members will only be allowed to view the contents of the database.
4.3.2 Non-functional requirements
These requirements focus on how the system works or how the system should behave
by providing its quality attributes. These requirements include:
16
i.
The system should be able to handle an unlimited number of users at a
time.
ii.
Documentation: the system will be documented.
iii.
Recover-ability: the system will be regularly backed up so that it can
be recovered in case data is lost for some reason.
iv.
Design constraints: The software will be developed with MySQL
database back end.
v.
The system will not work in the absence of internet
vi.
The system will only require the registered users to log in to the
system.
vii.
The system will only allow the super admin to change data on the
database and not any other user.
4.3.3 Domain requirements
i.
This system will not be in a position to operate in environments which are not
accessible to internet
ii.
The system will also require the user to have access to a computer/a laptop, a
smart phone or any other device that has internet access.
iii.
The system will be by those people basic computer skills.
iv.
People with visual impairments will not use the system unless there is
assistance from people without visual challenges.
4.3.4 Database requirements
i.
A common repository of data will be needed. This implies that the new system
will require a database for data storage and retrieval for the purposes of
processing and feedback information.
ii.
The database will require a number of tables to record various entries that the
uses will enter into the system.
17
4.4 System Modelling
In this section, diagramming tools are used to help users understand the flow of data
for the existing system of operation a local table banking system. Since the system is a
manual one, below (see Fig 3) is a Data Flow Diagram on how data flows.
Issue form
Customer
consultation
Customer
fills the form
Customer arrival
Attendant’s
At attendant’s desk
information
Manager
verifies
the form
Customer details
Form file
Verified details
Figure 4. 1: Data flow diagram for current system
18
CHAPTER FIVE
SYSTEM DESIGN
5.1 Introduction
The aim of this chapter is to examine the system which was proposed for Online
Table Banking system by describing it in details. It also focuses on the process design
of the system which in turn explains how the system operates with the aid of various
modeling tools.
Moreover, the chapter further covers the system’s database design by focusing on
both physical, conceptual and logical models. Finally, the chapter will focus on the
interface design of the newly proposed system to examine its usability by the users.
5.2 Description of the System
The proposed system will have a structure like the one discussed below.
5.2.1 Home page
The system home page is a page where any user lands after typing the address of the
site on a web browser. The home page contains general information such as the
heading, welcome messages, core values of table banking group, the mission of the
group and a few images of the table banking group. Moreover, there are links to other
pages such as log in, create user, delete user, make a transaction, transaction history.
5.2.2 Create user
User is created by the system admin by filling the user registration form details and
updates it to the database
In this page, the administrator is required to create user account with Akiporo Table
Banking system by filling in a form that is provided. This form contains the following
input fields:
i.
Name:
The user is required to enter the first name of his/her choice
ii.
Email Address
19
The user is required to provide a valid email address which can be used
to communicate
iii.
Initial balance
The start up amount is entered when the user account is created
iv.
Save user or Reset.
Command to save the user or deregister users
5.2.3 Delete user
Users are deleted and updated by the system admin in the remove user menu
5.2.4 Transfer money
The administrator makes money transfer from one user account to another and then
updates it to the server database.
5.2.5 Transactions history
This page is only displaying to users’ transactions with Akiporo Table Banking
system
This transactions details includes
i.
Serial no of the user
ii.
Sender
The user transferring the money to another user.
iii.
Receiver
Details of the user receiving the money
iv.
Amount
Since Akiporo online table banking system can be fixed or mobile, the
user is required to check the nature from the two options.
v.
Date and time
This is the time period the transactions took place in the contributions date. It
provides the time slot.eg 10.00Am-11.00Am and date slot e.g. 2022-4-1
5.3 Physical Process Design
In this section, all the processes that take place within the system when a user is using
the system are described.
20
The various processes that take place include: User registration, user log in, user
contribution, user post payments, user check progress and payments, user log out,
admin log in, admin update progress and payments, admin update the contributions
status, admin post and updates group’s new amount to be remitted by its members,
admin database manipulation and admin log out.
There are also various storage requirements such as:
 User details of registration,
 User contributions details and
 Admins authentication details.
The various processes for proposed system in Akiporo online table banking system
have been summarized in a Data Flow Diagram (see figure 5&6). The figure below is
therefore a data flow diagram describing the design of these processes:
Administrator
Delete/remo
ve user
Home page
Creates user
Transfer
money to user
accounts
Generates
transaction
report
Post & update group
new contributions \\
Figure 5. 1: Data flow diagram for system administrator
21
5.4 Database Design
The database called banksysphp is designed using the structured query language
(SQL) and has following tables:

transactions

users
5.4.1. System Screenshots
System screenshot shows how data appear in the tables including the data types
Home page
Figure 5. 2: system home page
22
Create user interface
Figure 5. 3: Create user menu
Remove user’s menu
Figure 5. 4: Remove user menu
23
Transfer money menu
Figure 5. 5: Transfer money menu
Transaction history menu
Figure 5. 6: Transaction history
24
CHAPTER SIX
SYSTEM IMPLEMENTATION
6.1 Introduction
In this chapter, the newly developed system is addressed before it is deployed into the
operations of the business. As a result, I am therefore going to examine the tools used
for coding the system as well as testing, the system test plan, actual testing and finally
propose a suitable change over method that the business should employ in order to
bring the system into operation.
6.2 Tools Used For Coding And Testing
During the coding process of the entire system, the following tools were of great
importance for the project.
6.2.1 Coding tools
Editing: During the coding process, I used the Visual Studio Code as the tool for
editing the code using the various languages as discussed below.
Programming languages: During the coding process, I used the following web
scripting languages:

Html5: Html stands for Hypertext Mark-up Language. I used Html mainly to
display text codes as well as formatting these texts.

CSS: CSS stands for Cascading Style sheets. This is a very powerful language
for formatting the web pages and has been of great help in my project. I used it
to format the user interface in order to make it more appealing to the users.

Java scripts:
Java scripts played a very crucial role in adding some
functionalities to my system. These included sliding images, a feature which is
much clear in the system’s homepage.

SQL: This is an abbreviation which stands for Structured Query language. I
used SQL as the language to connect the PHP code to the database as well as
executing the various queries.

Php: This is an abbreviation which stands for hypertext pre-processor

6.2.2 Testing tools performance test
25
This test evaluates the working of the system that has been developed to establish
whether it is solving the intended problem. Below are the tests that will be used for
this system.
Unit testing: This requires that testing be done on individual units constituting the
entire system. This testing approach was to help identify errors since each unit was
examined independently.
Stress testing: This is a testing method that always tests the behavior of a system
when subjected to unusual conditions. I tested the system with invalid input data such
as unfilled input fields and no execution could continue.
Actual system testing:
This is done to the entire system to test the general working of the system after it has
been fully developed. This test will be done on this system to test whether the
objectives stated earlier have been achieved or not.
Functional testing:
This involves testing the functions of the program by providing an input data and
observing the output. This will be done to test the working of the various functions of
the programmed and any unexpected behavior will be identified and corrected
accordingly.
6.3 System Test Plan
The system was tested in all aspects of functionality whereby various types of data
inputs such as integers (INT), variable characters (VARCHAR), DATETIME and
others were used and the results were observed.
6.4 User Acceptance Testing
During the testing process, any invalid data input altered the expected results and the
system validation functions could alert the user of these invalid inputs.
The system was also subjected to potential users for feedback and acceptance tests
and I got a positive response from these users whereby they accepted the system as a
solution to inefficient manual operations in table banking system productions.
26
Acceptance testing was done after the completion of development process where the
system was delivered to the users for their views and once they accepted the system,
then the system is said to have met the user requirement. User acceptance for this
system was be done at later stages of development to give potential users/clients an
opportunity to give views about it.
6.5 Proposed Change-Over Techniques
Generally, there are four approaches for the implementation of the system in an
organization. These are: Direct changeover, phased approach, pilot approach and the
parallel approach. I greatly analyzed the four approaches to the system
implementation and chose the phased operation.
Phased changeover
Phased operation works in different stages. It normally entails the implementation of
the new system in modules. It is also a combination of the direct changeover and the
parallel approach. I intend to implement it this way because the fact that the system is
new and stress as to the number of the users is not clear at this moment, it would be
therefore essential to take it and implement it module by module till the last module
of the system proves to be effective and well operational as required. Risk of errors or
failures in this system may also have prompted me to use the same as the risks will
not be subjected to the entire system but to the single module or the several modules
implemented so far. Similarly, for its use, the cost involved in its implementation may
be relatively lower compared to other approaches such as the direct approach which
entails the overall implementation of the system at once.
Phased operation works in different phases or stages. Implementation of new system
in modules or stages is phased operation. This is also a combination of direct
changeover and parallel similar to pilot operation. But in this approach the entire
system is provided to some users instead a part of system to all users. (E-Commerce
Encyclopedia, 2002)
In phase operation, the risk of errors or failures is limited to the implemented module
only and also phased operation is less expensive than the full parallel operation. But
in some cases, phased operation can cost more than a pilot approach where the system
involves a large number of separate phases This is done on completion of
27
development process where the system is delivered to the users for their views and
once they accept the system, then the system is said to have met the user requirement.
User acceptance for this system will be done at later stages of development to give
potential users/clients an opportunity to give views about it.
28
CHAPTER SEVEN
CONCLUSIONS AND RECOMMENDATIONS
7.1 Recommendations
In order to reverse the risks/problems involved in the project and realize
improvements in succeeding developments, I would like to make the following
recommendations.
7.1.1 Reduction in strictness of the Time deadlines
Since some of the issues in this system cover new concepts, I would recommend that
the students be allowed to begin the project development at a quite early time to build
up on their Ideas and to complete early and meet the set deadlines by the
requirements.
7.1.2 Provision of project finances to the students
Due to the fact that some of the students are unable to meet the threshold required for
data and requirements capture, I would recommend that some special finances be
provided to act as the support for the students who face difficulties in the development
and research process.
7.1.3 Compelling some institutions to pave way for the students to develop
Some institutions have been a major bottleneck in the development of the projects and
the higher-level institutions should compel them to release and loosen the restrictions
they have over their intellectual property such API (Application Programming
Interface).
7.1.4 Future improvements
I would like to say that my system did not capture everything that would be required
and would therefore recommend for future improvements on the following:

A feature to allow the admin message the clients within the system

Features to enable clients give their feedback and suggestions.

Integrating the system with M-pesa for customers to make payments using the
system.
29
7.2 Conclusion
It is clear that the existing systems of table banking are limited to fixed manual
services and do not provide mobile table banking service feature. This is therefore a
bit expensive to the clients as compared to when the system is available to them
online. Therefore, proposed system provides a module to select the nature of the ways
to choose from either physical or online, i.e. either mobile or fixed and this helps the
clients make contributions online or physically. This will reduce unnecessary costs
and time consumption.
The problems associated with the current system will be addressed with the new
proposed system. The whole design of the proposed system is a clear automation of
the current system at Akiporo table banking system and therefore the problems
associated with the manual system are well addressed by this design.
Also, the new system has been developed with a graphical user interface that is simple
for use and is therefore going to simplify the entire transaction process. Despite a few
challenges in the implementation process, the process was a successful one as I was
able to come up with a system that did not only work but also got acceptance form
users.
Taking this project all through has been a wonderful experience for me and for the
practical knowledge that I acquired, this would not have materialized. This is a very
important part of my course and has helped me understand the concepts behind a
number of web scripting languages as well as familiarize with the market expectations
of the course at large.
30
REFERENCES
BEIGHLEY L., & MORRISON, M. (2009) Head First PHP & MySQL. (Kindle
Edition).
DUCKETT, J. (2010). Beginning HTML, XHTML, CSS, and JavaScript, Wiley
Publishing Inc., (4th Edition).
EPROGRAMY, (2002). HTML & CSS Crash Course. (Kindle Edition).
GEORGE PETERSEN, “In Memoriam: Keith Barr 1949-2010”, Mix Magazine
Online, August 2010, http://mixonline.com/news/keith_barr_obit_ 2508/
index1.html
MANNING, A. (1991). Centre for Economic Performance. (1st Edition).
MURACH, J., HARRIS, K. (2014). Murach’s PHP and MySQL. (2nd Edition)
NIXON, R. (2014). Learning PHP, MySQL, Java Script, CSS and HTML. O'Reilly
Media. (2nd Edition). RICHARD C. (2002) Music Education. (3rd Edition).
SPOLSKY, J.A. (2006). User Interface Design for Programmers (Kindle Edition).
Routledge publishers, (1st edition)
31
Download