loan security mgt system report
DESCRIPTION
A loan management system for managing micro-finance loansTRANSCRIPT
A WEB BASED LOAN SECURITY MANAGEMENT SYTEM
A CASE STUDY OF PRIDE MICROFINANCE LTD
BY
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 microfinance 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 specification for LSMS ............................................................................................. 31
4.1.5 System requirement specifications ................................................................................................. 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 definitions .......................................................................................................................... 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 Microfinance Institutions (MFIs) (Namakula, 2003). MFIs
were set up to help the rural low-level income earners. They are specialized providers of
financial services to micro enterprises. They are at times called Micro-Credit Institutions, and are
financial 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-profit, regulated, audited, evaluated and rated full-scale financial intermediaries. They are not
confined 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 Microfinance 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 Switzerland’s .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. It’s 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 today’s 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 borrower’s
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: it’s 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 financial 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, Specification, 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 specified along with the desired
objectives and the constraints were identified.
In the specification phase, the system specifications were produced from the detailed
definitions of the above, clearly defining the product function.
In the system design phase, the system specifications 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 identified and
that the system meets its required specification.
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 specifications 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 five 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 filled by every
member applying for a loan. The loans officer visits the applicants to assess and value the
intended security. After his findings, 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 first two problems and the other two are recommended for future
study.
4.1.4 Requirement specification 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 identification (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 confirmed by at least five members of LC 1. Animals will be by branding of the form
CW0010001 for cows, GT0010001 for goats and others. The first two characters represent the
animal type, next three integers represent the bank code and the last four integers represent the
animal number in that specific 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 identification 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 certificate to confirm the date of birth and names.
4.1.5 System requirement specifications
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 specific 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 notifies 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 specific designs,
overall goals are inherent in the system. The process involved decomposition of the system into
objects and tasks.
The researchers’ defined 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 definitions
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 defined by its
attributes, which take on specific values.
Table : Entities and their Attributes
Entity Entity Description Attribute Attribute Description
Bank Banking institution bankName
bankCode
Location
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
Client’s first name
Client’s last name
Client’s sex
Client’s date of birth
Bank
accNumber
loanType
loanAmount
security
status
county
subcounty
parish
village
telNumber
Client’s bank
Client’s number
Type of loan a client takes
Amount of money a client is lent
Type of security a client gives
Client’s marital status
Client’s home county
Client’s home sub county
Client’s home parish
Client’s home village
Client’s 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
Guarantor’s first name
Guarantor’s last name
sex
DOB
bank
accNumber
accBalance
telNumber
Guarantor’s sex
Guarantor’s date of birth
Guarantor’s bank
Guarantor’s number
Amount of money on
guarantor’s account
Guarantor’s 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
user’s first name
User’s last name
A name for entering the system
User’s unique identification
User password
bank
Sex
DOB
User’s bank
User’s sex
User’s date of birth
Partners member institutions
using the system
Name
Address
regno
telephone
abbreviation
Logo
Name of the partner
Partner’s physical address
Partner’s registration number
Partner’s telephone number
Partner’s e-mail address
Partner’s 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 figure 4.4.
Figure 4. : Web-Based, Three-Tier Client Server Architecture
The first 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 identifies a security item/object that is
already registered in DB and notifies 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 user’s 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 user’s specific 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 first 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 first 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 files at the five 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 findings 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 microfinance 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 benefits of the Web based LSMS were identified. The first 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 benefit 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 fields required including interest
rates, loan amount to security value ratios, loan period and expiry dates.
Above all, the major benefit is an effective and efficient system to coordinate micro finance
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 finance 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 five 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 specifications spelling out the
requirements of the LSMS were created.
5.2 Conclusion
This project provided a report on a LSMS for micro finance 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 finally the
LSMS components were integrated to form a running system that was tested and validated. The
overall finding 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 finance 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
finance 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 system’s
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.
APPENDIX C
Sample screenshots
Home page of LSMS
Member login page
Gurantor form page
Savings form page
Comments page
Loan Security
APPENDIX D
Sample codes
Administrator Login PHP script (login.php)
<?php require_once("includes/session.php"); ?>
<?php require_once("includes/connection.php"); ?>
<?php require_once("includes/functions.php"); ?>
<?php
if (logged_in()) {
redirect_to("staff.php");
}
include_once("includes/form_functions.php");
// 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));
$fields_with_lengths = array('username' => 30, 'password' => 30);
$errors = array_merge($errors, check_max_field_lengths($fields_with_lengths,
$_POST));
$username = trim(mysql_prep($_POST['username']));
$password = trim(mysql_prep($_POST['password']));
$hashed_password = sha1($password);
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">
<div align="left">
<table>
<tr>
<td>Username:</td>
<td><input type="text" name="username" maxlength="30" value="<?php
echo htmlentities($username); ?>" /></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="password" maxlength="30"
value="<?php echo htmlentities($password); ?>" /></td>
</tr>
<tr>
<td colspan="2"><p>
<input type="submit" name="submit" value="Login" />
</p>
</br>
<p>Not a <strong>Staff</strong>? Login <a href="login2.php">HERE</a> </p>
</td>
</tr>
</table>
</div>
</form>
</td>
</tr>
</table>
<?php include("includes/footer.php"); ?>
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. Enseñanza del inglés. 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 Industry’s 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.