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