MUJUZI JONATHAN BIT/40790/91/DU And MUGERWA RONALD BIT/40602/91/DU
A PROJECT REPORT SUBMITTED TO THE COLLEGE OF APPLIED SCIENCES AND TECHNOLOGY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE AWARD OF A DEGREE OF BACHELOR OF INFORMATION TECHNOLOGY OF KAMPALA INTERNATIONAL UNIVERSITY
JUNE, 2012 DECLARATION We declare to the best of our knowledge that this project report is our original work and that work performed by others is appropriately cited. Signed: .. MR. MUJUZI JONATHAN BIT/40790/91/DU Student Date: .. Signed: .. MR. MUGERWA RONALD BIT/40602/91/DU Student Date: ..
APPROVAL This is our research dissertation and is submitted to the College of Applied Sciences and Technology with the approval of our supervisor. Name: Ms. Kareyo Margaret Date: .. Supervisor Signature: .
LIST OF FIGURES Figure 4. 1: Schematic Representing the Waterfall Model ........................................................... 28 Figure 4. 2: Illustration of Relationship between Entities ............................................................ 37 Figure 4. 3: LSMS Entity Relationship Diagram.......................................................................... 38 Figure 4. 4: Web-Based, Three-Tier Client Server Architecture .................................................. 39 Figure 4. 5: Login Screen.............................................................................................................. 42 Figure 4. 6: Main Administrator Menu ......................................................................................... 43
LIST OF TABLES Table 1: Entities and their Attributes ............................................................................................ 33
ABBREVIATIONS CERN - Counsel European pour le Recherch Nucleaire CORBA - Common Object Request Broker Architecture CPU Central Processing Unit CSM - Credit Score Model DB - Database DM - Development Methodology FGDs - Focused Group Discussions HSM - Hard System Methodology KB Kilo Byte LSMS - Loan Security Management System MB Mega Byte MDI - Microfinance Deposit-taking Institution MFI - Microfinance Institution MIS - Management Information System NABARD - National Bank for Agriculture and Rural Development NGO Non Governmental Organization PHP PHP Hypertext Preprocessor PML - Pride Microfinance Limited RAM Random Access Memory SHGs - Self-Help Groups SDLC - System Development Life Cycle SQL - Structural Query Language SSM - Soft Systems Methodology TPS - Transaction Processing Systems UML - Unified Model Language WIS - Web-based Information systems
ABSTRACT This study focused at designing and implementing a Web Based Loan Security Management System (LSMS), which would assist the micronance institution (Pride Microfinance Limited) to identify any object that is already in the loan security database. The LSMS developed during the study, compares the intended security and all securities already in the database. An investigation was carried out to establish how the existing system functions regarding the problems at hand in addition to the way forward. To help in investigation, the interview, observation and questionnaires were used in fact finding. The system design used the three-tier client server architecture to implement the inference mechanism while database component was implemented using PHP programming language and MySQL, a Relational Database Management System. The user interface was implemented using HTML and PHP. The LSMS helps users (loans officers) to identify any security item that is already being used for another loan and this avoids having one security item for more than one loan. The development used the Waterfall Model under the System Development Life Cycle (SDLC).
Table of Contents DECLARATION .......................................................................................................................... 2 APPROVAL .................................................................................................................................. 3 LIST OF FIGURES ...................................................................................................................... 4 LIST OF TABLES ........................................................................................................................ 5 ABBREVIATIONS ....................................................................................................................... 6 ABSTRACT ................................................................................................................................... 8 CHAPTER ONE ......................................................................................................................... 12 INTRODUCTION ...................................................................................................................... 12 1.0 Introduction ........................................................................................................................... 12 1.1 Background of the study ...................................................................................................... 12 1.1.1 Web-based loan security ............................................................................................................ 13 1.2 Statement of the Problem ..................................................................................................... 14 1.3 Objectives of the Study ......................................................................................................... 14 1.3.1 General Objective .......................................................................................................................... 14 1.3.2 Specific Objectives ........................................................................................................................ 14 1.4 Research Questions ............................................................................................................... 15 1.5 Scope of the Study ................................................................................................................. 15 1.6 Significance of Study ............................................................................................................ 15 CHAPTER TWO ........................................................................................................................ 17 LITERATURE REVIEW .......................................................................................................... 17 2.0 Introduction ........................................................................................................................... 17 2.1 Management Information Systems ..................................................................................... 17 2.2 Web Overview ....................................................................................................................... 18 2.2.1 Web Research ................................................................................................................................ 18 2.2.2 Web Application ............................................................................................................................ 18 2.3 Loan System .......................................................................................................................... 19 2.4 Management Information System of Pride MFI ............................................................... 19 2.4.1 Loan Management system in pride MF ......................................................................................... 20 2.5 Web Based Management System ......................................................................................... 20 2.6 Development Methodologies ................................................................................................ 21 2.6.1 Soft and Hard Systems Methodologies .......................................................................................... 21 2.7 System Validation ................................................................................................................. 21 2.8 Summary ................................................................................................................................ 22 CHAPTER THREE .................................................................................................................... 23 METHODOLOGY ..................................................................................................................... 23 3.0 Introduction ........................................................................................................................... 23 3.1 Primary sources .................................................................................................................... 23 3.1.1 Focused group discussions ............................................................................................................. 23 3.1.2 Federation ...................................................................................................................................... 23 3.1.3 Personal interview .......................................................................................................................... 24 3.1.4 Secondary sources .......................................................................................................................... 24 3.2 Design and implementation of LSMS ................................................................................. 24 3.3 Testing and Validation ......................................................................................................... 25 3.4 Environment and systems .................................................................................................... 25 3.5 Reports Interface Development ........................................................................................... 25 CHAPTER FOUR ....................................................................................................................... 27 SYSTEM STUDY, DESIGN AND IMPLEMENTATION ..................................................... 27 4.0 Introduction ........................................................................................................................... 27 4.1 System study and design....................................................................................................... 27 4.1.1 User analysis .................................................................................................................................. 29 4.1.2 The Current LSMS ......................................................................................................................... 30 4.1.3 Problems of the current LSMS....................................................................................................... 30 4.1.4 Requirement specication for LSMS ............................................................................................. 31 4.1.5 System requirement specications ................................................................................................. 31 4.1.6 Functional requirements ................................................................................................................. 31 4.1.7 Non Functional requirements ......................................................................................................... 32 4.1.8 User requirements .......................................................................................................................... 32 4.1.9 Task analysis .................................................................................................................................. 32 4.1.10 Entity denitions .......................................................................................................................... 33 4.1.11 LSMS software architecture......................................................................................................... 38 4.2 System Implementation ........................................................................................................ 40 4.2.1 Database ......................................................................................................................................... 40 4.2.2 LSMS inference mechanisms ......................................................................................................... 41 4.2.3 Communication component ........................................................................................................... 41 4.2.4 User interface ................................................................................................................................. 41 4.3 Testing and Validation of a prototype LSMS .................................................................... 43 CHAPTER FIVE ........................................................................................................................ 44 DISCUSSION, CONCLUSION AND RECOMMENDATIONS ........................................... 44 5.0 Introduction ........................................................................................................................... 44 5.1 Discussion .............................................................................................................................. 44 5.2 Conclusion ............................................................................................................................. 45 5.3 Recommendations ................................................................................................................. 45 5.3.1 Recommendations for future work ................................................................................................ 46 APPENDICES ............................................................................................................................. 47 APPENDIX A .............................................................................................................................. 47 A questionnaire for the initial usability requirements for the LSMS .................................... 47 APPENDIX B .............................................................................................................................. 49 Sample interview questions for loan officers and managers ................................................... 49 APPENDIX C .............................................................................................................................. 50 Sample screenshots ..................................................................................................................... 50 APPENDIX D .............................................................................................................................. 56 Sample codes ............................................................................................................................... 56 References .................................................................................................................................... 61
CHAPTER ONE INTRODUCTION 1.0 Introduction In the 1970s, the International Development Agency of the World Bank began searching for ways to have the poor members of the community get access to small loans. The result of such development was the emergence of Micronance Institutions (MFIs) (Namakula, 2003). MFIs were set up to help the rural low-level income earners. They are specialized providers of nancial services to micro enterprises. They are at times called Micro-Credit Institutions, and are nancial intermediaries specializing in extending resources to small sectors which are not covered by commercial banks. There is an increasing international trend towards MFIs becoming for-prot, regulated, audited, evaluated and rated full-scale nancial intermediaries. They are not conned to the sphere of social development but rather represent the latest expression of the on- going globalization of the World Financial System of which they form an integral part. They offer services to the excluded portion of the world population. One of the major services MFIs offer is giving loans. These loans are given on agreed terms and conditions between the member (borrower) and the institution (lender). Among the required conditions to acquire a loan from any of these MFIs is a collateral security which should be a property owned by the borrower. This study will focus on a computer-based loan security management tool that should improve security management in order to improve lending and borrowing actives in these institutions. In Uganda MFIs have formed associations constituting member institutions in the same region and one of them is the Pride Micronance Institutions Association. 1.1 Background of the study Pride Micro Finance limited is one of the leading Microfinance Deposit Taking Institutions in Uganda and is regulated by Bank of Uganda under the MDI Act, 2003. The major aim of the association is to solve common problems together. The member company would agree to develop a common shared database where every member institution would access information from other member company. All member companies are therefore obliged to connect to the Internet. The member company, among other services, lends money to members for their day to day operations of their small businesses. According to their constitution, a member qualifies to get a loan from an institution if he or she is a full member of the institution, with at least one guarantor who is also a full member of the institution and with a tangible property object to give to the institution as security for the loan, among other conditions. Many members easily fulfill the first two conditions but find it difficult to get security to give to the institution for the loan. Some end up borrowing items to use as security and others try to forge and give in invalid securities, which are already pledged elsewhere for another loan or are properties they will sold or given away and no longer own. The most common securities used include; land, with or without title; developed and undeveloped plots in commercial areas; motor vehicles, motor cycles and bicycles; household property like TVs, radios, video decks, chairs, tables, cardboards, and sideboards; animals like cows, goats, sheep, pigs and turkey; documents for money withdraws from their banks, especially salary earners. Security among other qualifications is the most important condition as it helps to ease the recovery of loaned money. In case of failure to repay the loan, the security is sold. Therefore the security determines the amount of money one can borrow. 1.1.1 Web-based loan security A web based loan security management system is an on line software designed to record, store, compare and identify similar security objects in the loan security database. Heng-Li and Jih-Hsin (2003), described Web-based information Systems (WIS) as information systems that are based on web technology and are likely to be integrated within conventional systems such as database and transaction processing systems. A web is said to be a powerful medium offering unique marketing, advertising, and product and service information. It eases communication opportunities between an organization and existing potential customers (KPMF vana et al, 1997). A web can give access to a greater store of information than other traditional communication media, and provide visitors with the means to select and retrieve only that which appeals to them (Gilbert, 1998). The Internet is looked at as a unique interactive medium. Its unique features such as the website will been described to offer a greater degree of interactivity. The web design, information and interactivity are indispensable components of interaction. Every interaction on the website is based on the interplay of these components (Miller, 1996). The Loan Security Management System uses the web because of its ease of communication, facilitation of access and greater degree of interactivity. 1.2 Statement of the Problem Pride Microfinance Limited is a Microfinance Deposit-taking Institution (MDI). The institution had members who were in more than one institution. These people were free to get loans from the institution in which they were members as long as they would be able to fulfill the required conditions. The conditions were analyzed manually and independently in different company. People took advantage of this and got more than one loan from different PML institutions using the same security object in all. When this members default, all the lender institution claim the same security object to sell and recover their money thus colliding on the same object. Therefore, there was need for a system that would help to identify an object that is already pledged as security and notify the loans officer in order to avoid this collision. 1.3 Objectives of the Study 1.3.1 General Objective The general objective of this study will be to design and implement an integrated web based loan security management system, which would assist micro finance company to identify any object which is already in the loan security database. 1.3.2 Specific Objectives To analyze the existing problems of the traditional Loan System of Pride Microfinance To design the Web-based Loan Security Management System To develop the Web-based Loan Security Management System To implement a Web-based Loan security Management System that compares the ID of the intended collateral security object with the IDs of those already in the loan security database. 1.4 Research Questions How is Loan Security handled at PML? Are there Loan security schemes at PML? How do users access Loan services at PML? Would a web-based system automate loan security management at PML? 1.5 Scope of the Study The scope of the project was restricted to the five blocks of Kampala as a district. These areas included Kansanga, Bunga, Kabalagala, Muyenga and Makindye. Two villages from each block were selected for conducting the detailed research. Pride was used as a case study to validate the system. Among the three conditions required to qualify for a loan, the study only looked at the collateral security management. 1.6 Significance of Study According to Namakula (2003), in GWEDICAL (Gwekitanagwako Development and Credit Association Limited), security has to be provided and members must agree that the security given is a personal property of the person giving it and is not committed elsewhere for another purpose. The system in this respect would be used to record and store detailed information about loan securities, ensure ownership and commitment to pay as witnessed by guarantors. It would also compare the intended security for a new loan with the securities already in the PML loan security database. If the intended security object for the new loan is already in the database, the system would notify the user. This helps PML members to avoid having a single security object pledged in more than one institution for different loans without the lender Company noticing it. This system therefore would help to avoid duplication of security, collision and thus conflict for one object to sell by more than one institution in case the borrower fails to pay. Finally, with this clearly recorded information and guarantors the witness, the institution would easily recover its money from borrowers which is the major purpose of a loan security.
CHAPTER TWO LITERATURE REVIEW 2.0 Introduction Literature review in this project will center around, management information systems in Microfinance institutions, existing information reporting systems, improving management reporting and the use of data warehousing efficiently to improve management reporting. The chapter starts with an overview of the web, and introduces a background of the online loan management process. 2.1 Management Information Systems Management Information Systems (MIS) is a system or process that provides information needed to manage organizations effectively. MISs are regarded to be a subset of the overall internal controls procedures in a business, which cover the application of people, documents, technologies, and procedures used by management accountants to solve business problems such as costing a product, service or a business-wide strategy. Management information systems are distinct from regular information systems in that they are used to analyze other information systems applied in operational activities in the organization. Academically, the term is commonly used to refer to the group of information management methods tied to the automation or support of human decision making, for example Decision Support Systems, Expert systems, and Executive information systems. An MIS is not simply a computer program, and it involves more than just calculating numbers. Information management is first and foremost people communicating with one another about events that affect the work of their organization. The chart of accounts, all the forms used by an institution; from receipts to loan applications, to staff vacation requests meetings, proposals, policies and procedures, the staffing structure, job descriptions, the planning process, and the computer software - all these and more influence the flow of information in an institution and so, together, make up the management information system. Another criticism cited under Directed Credit Programs relates to the transaction costs for both the lender and the borrowers caused by direct credit programs. The expenses incurred by the borrower in complying with the directed credit program monitoring and proposal requirements entailed in managing multiple lines of credit boost. Costs include opportunity costs of time spent in navigating cumbersome borrowing procedures, transportation costs on monitoring, costs of providing acceptable collateral and in some cases bribes to influence lending, (Desai and Mellor, 1993). There is therefore need to build a system that can help to minimize this costs through the web technology. 2.2 Web Overview The world wide web started in 1990 at the Counsel European pour le Recherch Nucleaire (CERN) in Switzerlands .in that time the laboratory was facing difficulties while they are sending important documents and graphics via the internet therefore they were needed something better than simple file transfer. Tim Berners-lee was working in CERN when he developed the World Wide Web portion of the internet (webopedia, 2008). Web is a subset of the internet that uses images, multimedia elements and hypertext navigation to communicate information globally. Its a connection of computers worldwide whose hosts serve and transit data among computer users. 2.2.1 Web Research This study included conducting web research on the different MFIs and articles on Pride Microfinance. The websites of different MFIs and the National Bank for Agriculture and Rural Development (NABARD) were explored and provided a rich material on their functioning. 2.2.2 Web Application Casal (2005), defined the web application as a software application that delivers its functionality to a user from a web server, through a network such as the World Wide Web or intranet. A web application is a collection of logically connected web pages managed as a single entity. A web site, on the other hand, contains one or more that result from different contracts with the customer (Auckland, 2004). The fundamental purpose of the web application is to facilitate the completion of one more task (Baxley 2003). According to Carvalho (2004), a web based application can serve the purpose for effective decentralized final management and it looks like a software package that can be accessed through the web browser .the software and database exit on a central server rather than being installed on the desktop system is accessed over a network .web-based application are the ultimate way to take advantage of todays technology to enhance efficiency, and give the opportunity to access information from anywhere at any time saving money and improving interactivity. 2.3 Loan System According to Securities Exchange Act of 1934, security is property, which is pledged as collateral for a loan. It is a binding pledge made by lender to the borrower to make a loan usually at a stated interest rate within a given period of time for a given purpose, subject to the compliance of the borrower to stated conditions. Collateral security is an additional security supplied by the borrower to obtain a loan. Most commonly used to mean some security in addition to the personal obligation of the borrower to repay a loan. There are two kinds of loans that the groups are getting. First is agricultural loan and second is term loan. Presently most of the loans disbursed to Self-Help Groups (SHGs) are agricultural loans that are of one-year duration. A SHG can get a loan from the bank if it has saving of minimum of Rs.5000. Generally SHG takes six to twelve months to reach the required savings. The rate of interest on the loan is 24 percent; if the installment becomes due for more than three months then the interest rate becomes 36 percent annually. 2.4 Management Information System of Pride MFI The microfinance sector is also quite diverse in its use of information systems. Generally there are the following three types: i. Manual System - Some MFIs still rely on manual systems, which involve maintenance of records in forms and ledgers. Organizations having manual systems are either small Micro-credit programs or NGOs. ii. Semi-automated System - More than 50% of MFIs are operating in a semi-automated mode. Within this category, the spreadsheet is the common tool being used either in conjunction with a manual system or with an MIS application that does not fulfill the information requirements of the MFI. The majority of non-regulated MFIs use semi- automated systems. iii. Fully Automated System - Few MFIs are fortunate enough to use a fully automated and integrated MIS fulfilling the whole information requirements of the organization. Such systems are existent with banks or regulated MFIs. 2.4.1 Loan Management system in pride MF The system would test the adjustments in conditions, which include security requirements. Automated CSM are a cost-effective and efficient means of determining high-risk borrowers security requirement. The system would be based on demographic and other financial information supplied, if an individual loan applicant belongs to the high-risk borrowers segment (Hempel and Simonsen, 1999). The system also helps to assess the character and integrity of the loan applicants that provide false information about income and security, or fail to disclose other commitments later revealed in a credit reference check. 2.5 Web Based Management System Gilbert (1998) asserts that the web provides the greater degree of interactivity than other Communication media. Quoting the previous studies, information on related services allows loyal customers to derive greater utility and be more satisfied. With more relevant information, and customers, it makes better decisions which leads to higher satisfaction, thus enhancing loyalty to the service provider. Peter (2004) cites Fisher et al (1992), supports Gilbert about interaction and Nielsen about Satisfaction arguing that the web design, interactivity and depth of information at the website may impact on service encounters satisfaction. A well designed interactive website would generate higher satisfaction by providing greater control to the customers to personalize the information search. The Web based loan security management system intends to derive high level of interactivity from the Web and satisfy the user by enabling efficient performance in management of loan securities. 2.6 Development Methodologies In Mukwanga (2006), review of Development Methodologies (DM) classified it as soft and hard systems methodology and system development life cycle. 2.6.1 Soft and Hard Systems Methodologies Mukwanga (2006), described Hard systems as precise objectives that would be expressed in mathematical terms while soft systems are used in relation to human activities where there is unlikely to be agreement about the precise objectives of the system. Soft Systems Methodology (SSM) deals with fuzzy problem situations. SSM is an approach for coping with issues of soft or ill-defined problem situations. Maguire (2000), states that Hard Systems Methodologies (HSM) adopted the seven stages approach as defined in the UK by the National Computing Centre. The stages are feasibility study, systems investigation, systems analysis, systems design, system development, implementation and maintenance. 2.7 System Validation The testing and validation of the system would be carried out throughout the development steps of the system depending on the activity that would be done. In the investigation and design stages, the requirements collected were tested to see whether they conformed to what the user really wanted. This was done through discussions with the client representatives to see that what had been captured is what they required. In the design process, the designs developed were subjected to user walkthroughs to see whether they corresponded to those agreed on in the requirements. During the programming stage, individual units were tested independently to verify if they were correct for example the data extraction process for loans information was tested to see whether it was picking the correct data from the source. In the integration testing process, different modules were tested on how they worked together as a whole. The modules included: data extraction and migration, data cleaning, the user access interface and the reports. In the implementation stage, user acceptance testing was carried out on the reports generated from the information reporting system developed and were compared with those generated manually by the users. Portal defines validation as a process of checking if something satisfies a certain criterion. That implies that one is able to testify that a solution or process is correct or compliant with set standards or rules. 2.8 Summary The web technology becomes one of the important solutions to many multifarious fields in the business area. And also there are many advantages to use the web: its one of the ways of that verifies the customer relationship management .The use of the web in finance field gives it a feature to deal with its customers through the web and will facilitate the applying for any kind of applications. This kind of web-based loan management system reduces time and save effort where some business change the way of applying for loan which will save a huge amount of money and encourages the use of web and internet fields.
CHAPTER THREE METHODOLOGY 3.0 Introduction This section outlined the standards and procedures that affected planning, analysis, design, development and final implementation of the loan security management system. It spelt out the techniques and methods that were used in; reviewing literature on related problems by other researchers, data collection, establishing the requirements for developing the loan security management system, the design approach, implementation and validation. To achieve the objective of establishing the requirements for the loan security management system, the researchers used interviews, questionnaires and discussions. The researchers continued to review literature on loan security management system from other materials that had the most recent views. 3.1 Primary sources The primary data of the pride microfinance was collected through Focused Group Discussions (FGDs), structured, semi structured interviews and informal interviews with the moneylenders. In order to gain insight into the practices of existing MFIs, BASIX was also visited. 3.1.1 Focused group discussions The study involved the conduction of 30 FGDs in 15 villages across the Kampala Town district. The focus in the FGDs was issues related to the understanding of their cash flows, credit needs of the people and the sources they use to obtain credit. The group on which the FGDs were conducted included both PML members and non-members. 3.1.2 Federation ASA forms a federation of Self-Help Groups (SHGs) if the number of SHGs accedes more than 125-150 SHGs in a block. The federation is a conglomeration of the SHGs, which provides active support to the SHGs in the loaning process by not only certifying their loan applications in the Bank but also standing as guarantee for them in the Bank. The federations are democratic bodies. The Federation provides the service of monitoring of SHGs, facilitating loans through bank to SHGs and also helps in training of SHGs. 3.1.3 Personal interview The primary Focused Group Discussions were followed up by 3 detailed questionnaires in the same village. This was done in order to validate the information collected in the FGDs. The bank managers of the Leading bank, Regional Rural Bank and other commercial banks were interviewed with the help of Semi-structured interviews. Informal discussions were also organized with the various development professionals working in the area. In order to gain a deeper understanding of the MFI program of Kampala, the Microfinance pride was also visited and discussions held with all the MFI staff and also the members of all the MFI. 3.1.4 Secondary sources The secondary data was collected from the following resources: Literature review - The methodology included a comprehensive literature review on micro- finance and its different models existing in Uganda. Web Research - The study included conducting web research on the different MFIs and articles on Microfinance. The websites of different MFIs and the National Bank for Agriculture and Rural Development (NABARD) were explored to provide rich material on their functioning. District statistical book - The official statistics of the whole district were used to stratify the villages into three different strata. Data gathered from Banks and also the district credit plan was utilized for the study. 3.2 Design and implementation of LSMS The second objective based on the requirements that were drawn from the interviews, questionnaires and discussion groups. A prototype of the system was designed and implemented. One of the major components was the database and one of the major functionalities was to identify any security object that was already registered in the database. The prototype was a working system that met the user basic requirements. It begun from the fundamental level of entities and their attributes to the relationship between entities and the entity relationship diagram. The logical Database Design for the relational model produced were the Physical Database design for the relational database that was derived by translating the logical data model into MySQL Database Management System. 3.3 Testing and Validation In this manner, the samples of users were identified and worked on the prototype using real data. These users were able to identify the problems and omissions in the initial prototype. The prototype was revised and enhanced basing on the feedback from the sample users. This was done rapidly until an acceptable working product was developed. The prototype was then presented to the potential users to test whether it measured to their expectations. 3.4 Environment and systems The development platform used was Microsoft Windows. The instruments of development included MySQL in the back end and HTML/PHP on the front end. Microsoft Visio was used to draw diagrams. 3.5 Reports Interface Development The last two objectives which involved the development of a Management reporting interface and testing of the whole system followed the Systems development life cycle (SDLC). This covered the following steps from the SDLC: Systems Analysis and Investigation - This involved reviewing data on the current system so as to determine the user requirements. System Design - The new system required a designed base on the requirements needed. The format and the appearance of the screens were set up basing on the functionality of particular modules. Programming - The designs developed was translated into code in developing the application. Testing - Different types of tests were carried out while the development was taking place. This ranged from the unit tests checking the functionality of small programs to integration and system tests that checked the way the various modules such as data and reports were working together. Implementation - This implementation step involved setting up the application in a live environment in which the users were given access to. Post implementation and maintenance - This is a continuous process that continued as long as the application was in use.
CHAPTER FOUR SYSTEM STUDY, DESIGN AND IMPLEMENTATION 4.0 Introduction The major development effort for this project was to design, build and test a dynamic and interactive loan security management system prototype to aid in the recording, storing and tracking of loan securities in nancial institutions. This chapter contains results of the study and describes the implementation of the design solution of the LSMS to meet the user requirements. It also shows the various screen shots of the forms and reports with the corresponding discussions of their uses. 4.1 System study and design The design approach follows the Waterfall Model of Systems Development Life Cycle (SDLC). The model consists of six distinct stages, namely: Requirements, Specication, Design, Implementation, Integration and Maintenance as shown in the figure 4.1
Figure 4. : Schematic Representing the Waterfall Model From the figure 4.1 above, the Waterfall Model highlights that: In the requirements analysis phase, the problem was specied along with the desired objectives and the constraints were identied. In the specication phase, the system specications were produced from the detailed denitions of the above, clearly dening the product function. In the system design phase, the system specications are translated into a software representation. The researchers at this stage were concerned with: Data structure, Software architecture, Algorithmic detail and Interface representations. The hardware requirements are also determined at this stage along with a picture of the overall system
architecture. In the implementation and testing phase the designs were translated into the system domain. Testing at this stage focused on making sure that any errors are identied and that the system meets its required specication. In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. The maintenance phase is continuous. In this phase the system is updated to meet the changing customer needs, accommodate changes in the external environment, and correct errors and oversights previously undetected in the testing phases and to enhance the efficiency of the system. The feedback loops allow for corrections to be incorporated into the model. For example a problem/update in the design phase would requires a revisit to the specications phase. 4.1.1 User analysis To develop an interface, inference mechanism and a database for an existing system, designers should begin by gathering users requirements. This was achieved with the use of interviews, questionnaires and discussion with the loans officer, the manager, two members and chairman of loans committee at each of the ve institutions. In understanding the users for a system Mutungi Fredrick (2005) citing Hackos and Redish (1998) describe four stages of use pertaining to software/hardware systems. Novice Advanced beginner Component performer Expert In the case of common software products such as Microsoft word, 80 percent of users never move beyond the advanced beginner stage of use (Mutungi Fredrick (2005)). For these products, interface functions and rules must be salient to a casual user; there is a high value in user- friendliness. In the case of advanced systems including weapons, aircraft or power plant controls, we assume that the operators will be highly trained (beyond the level of the novice or advanced beginner) on all the features, and rules in the interface. In designing this system, the researchers assumed that loans officers (users) might be at the novice level, while the system administrators (at PML H/Qs) may perform at an expert level. 4.1.2 The Current LSMS In all AMFIA member institutions, loan security management is merged in the loan assessment process. The system is manual by use of loan application forms. These forms are lled by every member applying for a loan. The loans officer visits the applicants to assess and value the intended security. After his ndings, the loans officer sits with the loans committee of the BOD to recommend the amount of money each applicant should take for a loan. All this is done independently in every institution without coordinating with other institutions. Portable items and documents are kept in the institutions strong rooms to ensure control over the security until the loan is fully serviced. For those items, which cannot be kept in a strong room, the only measure to ensure that they are not sold until the loan is full serviced is relying on the LCs and guarantors. 4.1.3 Problems of the current LSMS The current loan security management system had the following weakness: i. It is merely a part of loan assessment system and no clear details are given in record. ii. There is no coordination of institutions when assessing and accepting security items and this leads to one item being used for more than one loan from different institutions without noticing it. iii. There is no standard and uniform way of valuing security items. iv. There is no reliable means to safe guard security during loan servicing period other than depending on yet unreliable LCs and guarantors. This tool will only solve the rst two problems and the other two are recommended for future study. 4.1.4 Requirement specication for LSMS In all institutions using this LSMS, a standard format in loan security recording must be followed in order to allow consistence of the system. All securities must have a unique identication (id) that will enable the Tool to perform its major objective. Motor vehicles and motor cycles will use their registration numbers as ids. Bicycles, furniture and other house hold properties will use their original receipts numbers. Land and buildings will be by their location referred by plot number on the land title or Sub county receipt number or agreements conrmed by at least ve members of LC 1. Animals will be by branding of the form CW0010001 for cows, GT0010001 for goats and others. The rst two characters represent the animal type, next three integers represent the bank code and the last four integers represent the animal number in that specic bank. The branding of animals shall be on their right ears and no animal with an injury or abnormality on the right ear shall be accepted. Assessment and identication of any security item must critically be done and incase of any doubt, that item shall not be accepted until the doubt is cleared. The photographs of the households, buildings and animals for security with the client shall be included in the system to ensure the likeness of this security. These photos shall have a standard size, appear in the natural color of the object and be taken using a digital camera. On registration, a client must produce his/her birth certicate to conrm the date of birth and names. 4.1.5 System requirement specications This tool is designed basically for use with the Microsoft windows operating system. It can be used with Windows NT, Windows 2000 and Windows XP with PHP programming language and MySQL DBMS environments. It is recommended that the computer on which this software tool is installed contain at least 128MB of RAM and have a Pentium CPU. The LSMS itself is small, occupying about 500KB of disk space. However, its size grows when the DB is populated. Therefore its size is partly determined by the data to be stored in the database. 4.1.6 Functional requirements Functional requirements of this system capture the intended behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. This system registers and stores all information about loan securities in PML member Institutions and rejects any intended security that is already registered. 4.1.7 Non Functional requirements In contrast with functional requirements that specify specic behavior or functions, non- functional requirements specify criteria that can be used to judge the operation of a system. The system should: Have sufficient resources in terms of processor speed, memory, disk space, network bandwidth. Have good performance in terms of response time and run time. Be available all the time. Be maintainable. Be able to handle several users simultaneously. Be reliable such that the mean time between failures is close to zero. Have a security mechanism to authenticate authorized users and keep out unauthorized users. Be robust enough to recover from failure or crash. Have both vertical and horizontal scalability to accommodate future expansions without losing data and applications that are already in it. 4.1.8 User requirements User requirements give what the user desire or want from the system. Other than recording and storing loan security information, this system noties the user, of any security item that is being used when it is pledged for the second loan. 4.1.9 Task analysis For the task analysis, the researchers maintained a focus on the users overall goals. Although users may vary, the steps taken to achieve goals depending on features of specic designs, overall goals are inherent in the system. The process involved decomposition of the system into objects and tasks. The researchers dened relevant entities and inter-entity relationships in the LSMS to maintain common terminologies between the researchers and users, then the researchers followed the waterfall model to compose and develop the system prototype. 4.1.10 Entity denitions The following entities stand out as relevant in the system, Bank, Client (who is the borrower), Security, Loan, Guarantors, Users (who is the loans officer). Each entity is dened by its attributes, which take on specic values. Table : Entities and their Attributes Entity Entity Description Attribute Attribute Description Bank Banking institution bankName bankCode Location E-mail Address Telephone Logo Name of banking institution Bank reg. number Location of the bank E-mail address of the bank Physical address of the bank Telephone number of the bank Logo of the bank Client Member of the bank who take a loan Fname Lname Sex DOB Clients first name Clients last name Clients sex Clients date of birth Bank accNumber loanType loanAmount security status county subcounty parish village telNumber Clients bank Clients number Type of loan a client takes Amount of money a client is lent Type of security a client gives Clients marital status Clients home county Clients home sub county Clients home parish Clients home village Clients telephone number Loan Loan given to a client Type amount client interest rate security period Type of loan Amount of money lent out Bank member who borrows money Rate of interest per month Security given to acquire a loan Loan period Guarantor Surety for a loan who take a loan fname lname Guarantors first name Guarantors last name sex DOB bank accNumber accBalance
telNumber Guarantors sex Guarantors date of birth Guarantors bank Guarantors number Amount of money on guarantors account Guarantors telephone number Security Security a client gives security id type value location owner photo Security unique identification Security type Security value Location of the security Security owner Photo graph of the security
User User stationed at an institution fname lname username userid password users first name Users last name A name for entering the system Users unique identification User password bank Sex DOB Users bank Users sex Users date of birth Partners member institutions using the system Name Address regno telephone e-mail abbreviation Logo Name of the partner Partners physical address Partners registration number Partners telephone number Partners e-mail address Partners abbreviation Logo of the pattern Institution User comments User communication to others Subject comment topic commented on comment made in the system
From the above defined entities, the following inter-entity relationships were identified. Figure 4.2 shows each of these relationships between the given entities.
Figure 4. : Illustration of Relationship between Entities
Figure 4. : LSMS Entity Relationship Diagram Figure 4.3, shows how the major system entities interact with each other. In addition each entity has a named primary key. 4.1.11 LSMS software architecture The LSMS was developed using three-tier client-server architecture with: the presentation on the client side, the application on the web server and data management on the database (DB) main frame computer as shown in gure 4.4.
Figure 4. : Web-Based, Three-Tier Client Server Architecture The rst tier component is responsible for presentation and is the user interface. The user interface to LSMS allows the user to interact with the system. It is a simple text-oriented interface. These client components enable the user to interact with the second-tier processes in a secure and intuitive manner. Web Sphere Application Server supports several client types. Clients do not access the third-tier services directly. The second-tier process, commonly referred to as the application layer, manages the business logic of the application, and is permitted access to the third-tier services. Web Sphere Application Server provides the application logic layer in three-tier architecture, enabling client components to interact with data resources and legacy applications. The application logic layer is where most of the processing work occurs. Multiple client components can access the second-tier processes simultaneously, so this application logic layer must manage its own transactions. In this system, it is handled by the apache-friends server. The third-tier which is the DB-server tier is to manage persistency of certain data/information and to execute the database transaction services. These services are protected from direct access by the client components. Interaction must occur through the second-tier processes. The DB is a collection of all data on loan securities needed by users. The DB was generated by interviews with loans officers, managers, and loans committees chairmen and created using MySQL DBMS. 4.2 System Implementation This section describes the implementation of the design solution presented earlier to meet the requirements of users in loan security management. The technologies used here were selected based on availability, case of use and applicability. MySQL was used to design the back end of the LSMS while PHP and HTML were used to design the inference mechanism and the user interface respectively. 4.2.1 Database The basic structure implemented in the DB has 8 tables. The basic goal for the database was to achieve third normal form and to satisfy the requirements of PML. These DB tables contain data for bank, client, loan, guarantor, security, user, partner and user comment as shown below. Database tables The following database tables were created using MySQL Database Management System. Bank table - This table has attributes of a bank in the system. Client table - This table has all the attributes of a client. Loan table - This table shows all the required attributes of a loan in the system. Guarantor table - This table has the attributes of a guarantor Security table - This table has all the attributes of a security item. User table - There are two types of users namely; Ordinary user who are loans officers and all other staff stationed at the member institution and Systems Administrator stationed at PML Headquarters. The user table shows the attributes of a user. Partners table - This table has all the attributes of Partners (institutions registered in the system). User comments - This table has the attributes of comments. 4.2.2 LSMS inference mechanisms The prototype LSMS incorporates an algorithm function which provides simple yet effective logic to the users in loan security management. The LSMS identies a security item/object that is already registered in DB and noties the user. It also records and keeps records of all security items entered by the user. 4.2.3 Communication component The LSMS was developed using the PHP programming language and MySQL database management system. The system is a three-tier system with DB and applications located on the server side while the user interface is on client side. Users interact with the system through the user interface. Input data is transmitted from the client to the server through Structural Query Language (SQL) used to query the DB in MySQL relation table format. With the users input data and queried data from DB, the application processes are executed on the server side. Results are returned to the client side and displayed in table format. 4.2.4 User interface The user interface is the only LSMS component visible to the user. It transforms user queries and update requests into appropriate sequences of commands to the other LSMS components. The LSMS interface facilitates information transformation between user and servers, where the inference engine and DB reside, in the following ways; i. Serves as front end for entering loan security parameters ii. Provides features for extracting information stored in the DB. iii. Displays and illustrates the design structures upon users specic request The user interface for this prototype LSMS is best understood by scrutinizing the following screenshots which show how to gain access to the LSMS. The rst screenshot of the system is a welcome screen which takes the administrator and the user to their respective functionality screens. This is shown in Figure 4.5.
Figure 4. : Login Screen This screen allows in two types of users: the administrator and the loans officer at the Institution. The administrator As an administrator, after entering the user name and the password, the login button on the welcome screen opens the second screen that gives the Main Menu for the administrator functionalities as shown in Figure 4.6.
Figure 4. : Main Administrator Menu The rst functionality for the administrator is for managing website content and registering users in the staff Menu. Overall functionality would include registering an institution in the system, performing searches and viewing records in the database entered by users. More system interfaces can be accessed in Appendix C of this report. 4.3 Testing and Validation of a prototype LSMS The prototype was presented to potential users (loans officers and system administrators) in PML to test whether it measures to their expectations. This was done using real row data the loan security les at the ve chosen banks. The problem to be solved was to identify any intended security item/object that was already in the database and notify the user. This was by giving respective error messages regarding the task at hand. CHAPTER FIVE DISCUSSION, CONCLUSION AND RECOMMENDATIONS 5.0 Introduction This project centered on developing a Web Based Loan Security Management System for PML. Its major aim was to solve the problem of using one security item for more than one loan in different Institutions. In this chapter, focus is on the discussion of the ndings and making recommendations for further research. 5.1 Discussion Security is one of the major factors that qualify one to get a loan. It is the tool that ensures recovery of the lent money (Chan and Thaker (1987)). In micronance Institutions, the management of security has been poorly handled. The loans officers have therefore been confronted with the problem of recovering loaned money using the pledged securities especially when security is being claimed by more than one Institution for different loans. The development of a Web based LSMS appears to be a solution for this problem as stated in the problem statement. The benets of the Web based LSMS were identied. The rst one is proper recording and storing of Loan Security information. This is enhanced by an effective and efficient recording system availed by the LSMS. The second benet is the ease to track loan information. The LSMS, though centered on loan security, take a lot more details about loan records. This provides information to the user in other loan elds required including interest rates, loan amount to security value ratios, loan period and expiry dates. Above all, the major benet is an effective and efficient system to coordinate micro nance Institutions and avoid crashes on loan securities at a time of loan recovery. The LSMS is a standard way of loan security management. It allows a uniform format of handling securities in micro nance Institutions and thus enhances consistence in all the Institutions. If well administered, the LSMS will reduce on loan recovery costs, ease recovery process and reduce on delinquency rate. The aims and objectives of this study were achieved using a combination of techniques. First, the loans officers and managers of the ve chosen Institutions were interviewed while questionnaires were administered to the chairmen and at least one of the loans committee members. MySQL was used to design the back end of the LSMS while PHP and HTML were used to design the inference mechanism and the user interface respectively. The three-tier architecture was used to develop the system. In the system analysis and design, the techniques applied included the waterfall model and the thin client three-tier architecture. The entity relationship diagrams were used to show relationships among the entities of the system. The required specications spelling out the requirements of the LSMS were created. 5.2 Conclusion This project provided a report on a LSMS for micro nance Institutions. In addition, literature focusing on LSMS is reviewed and mechanism for avoiding having one security item for more than one loan in different Institutions was acquired. The database containing data on loan securities and loans in general was created. The mechanism was created basing on the three-tier architecture. The user interface was developed to enable user interaction with the system and nally the LSMS components were integrated to form a running system that was tested and validated. The overall nding of this study is that the LSMS can be used to aid loans officers to identify any security item that is already pledged in another institution for another loan. The study also showed that a combination of techniques namely three-tier architecture and entity relationship diagrams were appropriate for designing the LSMS. The study further shows that MySQL, PHP and HTML have role to play in implementing the LSMS. Finally the study showed that the LSMS provides accurate software for loan security management. 5.3 Recommendations This LSMS was developed with the intention of using it in the process of loan security management in micro nance Institutions. The researchers recommend that this LSMS be put to its intended use and provide an avenue for proper, efficient and effective loan security management. This LSMS is also recommended for use by loans officers to enable them to carry out proper loan security management. 5.3.1 Recommendations for future work This project designed and implemented a Loan Security Management System for Pride Micro nance Limited. However there are a number of functionalities that it does not perform, which if performed, would make this Tool more useful in loan security management. Here are some of these functionalities for future research; i. The system does not give a standard way of evaluating a loan security. If a component for standard evaluation of loan securities could be added, it would improve the systems performance. ii. The system cannot detect similar items by use of photographs. If comparison of securities could be done by photographs, this tool would serve much better especially where animal and households are used as security. iii. The Tool only works with Institutions that are connected to the internet. There is needed to look into how to link up with those Institutions that are not yet connected to the internet.
APPENDICES APPENDIX A A questionnaire for the initial usability requirements for the LSMS Dear respondent, The researchers kindly request you to fill this questionnaire below to facilitate the research study to a success. PLEASE feel free and give the important information as required to make the project feasible. Your information will be treated and kept with a lot of confidentiality, great care and will be highly appreciated. Much regards: Qn1. What conditions qualify a member to get a loan in your bank? ................................................................................................................................................. ................................................................................................................................................. ................................................................................................................................................. Qn2. Among the conditions given, where do you rank security (if applicable)? ................................................................................................................................................. ................................................................................................................................................. ................................................................................................................................................. Qn3. What types of security do you accept for a loan? ................................................................................................................................................. .................................................................................................................................................
Qn4. What is your geographical limit of security in relation to the bank location? ................................................................................................................................................. ................................................................................................................................................. ................................................................................................................................................. Qn5. What is the ratio of your loan amount to security value? ................................................................................................................................................. Qn6. How do you determine and confirm security ownership? ................................................................................................................................................. ................................................................................................................................................. ................................................................................................................................................. Qn7. How do you ensure that the security does not change ownership until the loan is fully serviced? ................................................................................................................................................. ................................................................................................................................................. Qn8. How can you tell whether or not the intended security is being used elsewhere as security for another loan? ................................................................................................................................................. ................................................................................................................................................. ................................................................................................................................................. Qn9. What do you do if you find out that the intended security is pledged elsewhere when you have already disbursed the loan money? ................................................................................................................................................. ................................................................................................................................................. Qn10. How do you describe/identify the different loan securities used in your bank? (You can use a another paper for these descriptions) ................................................................................................................................................. ................................................................................................................................................. Qn11. What is your loan period? ................................................................................................................................................. Thanks APPENDIX B Sample interview questions for loan officers and managers Interview Guide for knowledge acquisition (1) What is the full name of this Institution? (2) When did this Institution start? (3) Who started this Institution? (4) What services does this Institution give to its members? (5) What type of loans do you give to your members? (6) What are the conditions for one to qualify to get a loan from your Institution? (7) What type of security do you accept? (8) What is your minimum ratio acceptable for loan amount to security value? (9) How do you validate the securities? (10) What is the geographical distance limit of the security location in relation to bank location? (11) How do you determine and ensure ownership of a security item? (12) How do you guard against change of ownership (selling or giving away) of a security during loan servicing period? (13) How can you tell whether or not the intended security is being used elsewhere for another purpose? (14) What do you do if you find out that the intended security is pledged elsewhere when you have already disbursed the loan money? (15) How do you describe/identify the different loan securities used in your bank? (16) What is your loan period? (17) Do you have any means of coordination with your sister Institutions in your area? And about what? (18) Do you have any common problems with your sister Institutions about loan securities? (19) How do you handle these problems? Thanks.
// START FORM PROCESSING if (isset($_POST['submit'])) { // Form has been submitted. $errors = array();
// perform validations on the form data $required_fields = array('username', 'password'); $errors = array_merge($errors, check_required_fields($required_fields, $_POST));
if ( empty($errors) ) { // Check database to see if username and the hashed password exist there. $query = "SELECT id, username "; $query .= "FROM users "; $query .= "WHERE username = '{$username}' "; $query .= "AND hashed_password = '{$hashed_password}' "; $query .= "LIMIT 1"; $result_set = mysql_query($query); confirm_query($result_set); if (mysql_num_rows($result_set) == 1) { // username/password authenticated // and only 1 match $found_user = mysql_fetch_array($result_set); $_SESSION['user_id'] = $found_user['id']; $_SESSION['username'] = $found_user['username'];
redirect_to("staff.php"); } else { // username/password combo was not found in the database $message = "Username/password combination incorrect.<br /> Please make sure your caps lock key is off and try again."; } } else { if (count($errors) == 1) { $message = "There was 1 error in the form."; } else { $message = "There were " . count($errors) . " errors in the form."; } }
} else { // Form has not been submitted. if (isset($_GET['logout']) && $_GET['logout'] == 1) { $message = "You are now logged out."; } $username = ""; $password = ""; } ?> <?php include("includes/header.php"); ?> <hr color="#3366FF">
<table id="structure"> <tr> <td id="navigation"> <div align="left"><a href="index.php">Return to public site</a> </div></td> <td id="page"> <h2 align="left">Admin Login</h2> <?php if (!empty($message)) {echo "<p class=\"message\">" . $message . "</p>";} ?> <?php if (!empty($errors)) { display_errors($errors); } ?> <form action="login.php" method="post">
References Bob Baxley 2003, Making the Web Work. New Riders Publishing, ISBN: 0-7357-1196-8 Bhupat M. Desai, John W. Mellor (1993). Institutional Finance for Agricultural Development, An analytical survey of critical issues Canas, A., Carvalho, M., Aruedas, M., Eskridge, T., Maguitman, A., Reichherzer, T.: Mining the web to suggest concepts during concept map construction. In Canas, A.J., Novak, J.D., Gonzalez, F., eds,: Concepts Maps: Theory , Methodology, Technology. Proceedings of the First International Conference on Concept Mapping. (2004) Casal, S. 2005. Enseanza del ingls. Aplicaciones del Aprendizaje Cooperativo. Badajoz: Abecedario. Chan T and Thaker (1987). Collateral and Competitive Equilibria with Moral Hazard and Private information. Journal of Finance. Gilbert D C (1998). A study of the Hotel Industrys Application of the Internet as a Relationship Marketing Tool. Hempel, G.H, Simonsen, D.G (1999), Bank Management, John Wiley and Sons, New York, NY Heng-Li, Y. and Jih-Hsin, T. (2003). A three-stage model of requirements elicitations for Web- based information systems. Industrial Management and data Systems. 103: 398-409. Iserman R. (1984). Process Fault detection based on modeling and estimation methods a Survey Automatica 20 :( 4), 387-404 JoAnn T. Hackos, Janice Redish (1998) User and Task Analysis for Interface Design Wiley, Feb 23. Maguire s. (2000). Towards a business-led approach to information systems development. Information Management and Computer Security, 8; 230-238. Miller H (1996). A Re-examination of the Commitment- Trust Theory. European Journal of Marketing. http://www.webopedia.com/TERM/C/CERN.html Mukwanga Fred (2006). A Web-based Management Information System for Monitoring Budget variances on expenditure accounts. Case for Centenary Rural Development Bank Ltd. Mutungi Fredrick (2005). A Decision Support Tool for Effective Manpower Planning. Makerere, Kampala. Namakula Proscovia (2003) (BED Muk), Determination of effectiveness of micro finance institutions (MFI) Loans among selected small Businesses in Kampala and Mpigi Districts. Nielsen J (1999). Trust or Bust; Communication Trust Worthiness in Web Design. Peter K Turyakira (2004), Interactive Marketing (Web-Based) and Customer Loyalty.