Computerized management of Microfinance institution

REPUBLIC DU CAMEROUN
Paix - Travail – Patrie
AFRICAN INSTITUTE OF COMPUTER SCIENCES
CAMEROON OFFICE
PAUL BIYA TECHNOLOGICAL CENTER OF
EXCELLENCY
P.O Box: 13718 Yaounde
Tel: 242 72 99 57; Fax: 242 72 99 58
E-mail: contact@iaicameroun.com
Web Site: www.iaicameroun.com
REPUBLIC OF CAMEROON
Peace-Work- Fatherland
UNIVERS BINAIRE
Tel: 697866127 / 674783450
Email: infos@universbinaire.com
Web Site: www.universbinaire.com
INTERNSHIP REPORT
In view of obtaining a Higher Technician Diploma in Computer
Sciences
Option: Software Engineering
Written By:
MBOVING TEGUETIO Levan Fredy
And
VOMO DONFACK Kelly Larissa
ACADEMIC SUPERVISOR:
MR FOTSA SEGNING LUCIEN
AND
MR TANGMO ANTOINE MARIUS
COMPUTER ENGINEER
LECTURER AT IAI-CAMEROON
PROFESSIONAL SUPERVISOR:
MR MARTIAL GAPIAPSI NGUETO
Computer Science Engineer
ACADEMIC YEAR 2015-2016
CONCEPTION AND REALISATION OF A
COMPUTERISED MANAGEMENT SYSTEM FOR
MICROFINANCE

CONCEPTION ANDREALISATION OF A COMPUTERISED MANAGEMENT SYSTEMFOR MICROFINANCE
Written by: MBOVING TEGUETIO Levan Fredy and VOMO DONFACK Kelly Larissa Student in level 2
Software Engineering
IAI Cameroon, Paul Biya Technological Center of Excellency
ii
We dedicate this work to the almighty GOD.
DEDICATION

iii
This document would not have been done without the contribution of a good number of
people who gave us great supports. We offer big thanks to the following:
 The Resident Representative of IAI-Cameroun, M. Armand Claude ABANDA,
for his follow up and precious counselling during our studies;
 The Director of UNIVERS BINAIRE, M. Martial GAPIAPSI NGUETO for
having welcome us and validated our application in his structure;
 To all our teachers in IAI Cameroun and particularly to our academic supervisor
M. FOTSA SEGNING Lucien and M. TAGMO Antoine Marius for their
evaluation in the academic context;
 To all the member of the family of VOMO and MBOVING for their daily
financial, moral and physical support ;
 To all our classmates, students of our promotion or batch, for their knowledge,
collaboration, love sharing, and also the great moment we are spending;
 All the people who were by our sides whether near or far during the realization of
this report and also those who left us because of one reason or the other.
ACKNOWLEDGEMENTS

iv
TABLE OF CONTENTS
DEDICATION.................................................................................................................................ii
ACKNOWLEDGEMENTS............................................................................................................iii
LIST OF FIGURES .......................................................................................................................vii
LIST OF TABLES..........................................................................................................................ix
ABBREVIATIONS .........................................................................................................................x
GENERAL INTRODUCTION......................................................................................................xii
PART I: INSERTION DOCUMENT ............................................................................................. 1
INTRODUCTION .......................................................................................................................... 3
I. RECEPTION AT UNIVERS BINAIRE.............................................................................. 4
II. PRESENTATION OF UNIVERS BINAIRE .................................................................. 4
1. HISTORY ..................................................................................................................... 4
2. Missions........................................................................................................................ 4
3. Administration chart of UNIVERS BINAIRE ............................................................. 4
4. Organization Chart of UNIVAIRE BINAIRE.............................................................. 6
5. Development Department............................................................................................. 7
III. RESOURCES................................................................................................................... 7
1. HARDWARE RESOURES.......................................................................................... 7
2. SOFTWARE RESOURES ........................................................................................... 7
IV. GEOGRAPHICAL LOCATION ..................................................................................... 8
1. LOCALISATION CHART .......................................................................................... 8
CONCLUSION............................................................................................................................... 9
PART II: SPECIFICATION BOOK............................................................................................. 10
INTRODUCTION ........................................................................................................................ 12
I. CONTEXT .................................................................................................................... 13
1. Core principles of microfinance .............................................................................. 13
2. Characteristics and features of a MFI.................................................................... 13
3. BRIEF HISTORY OF MICROFINANCES .......................................................... 14
1. Product and services ................................................................................................... 15
II. OBJECTIVES........................................................................................................... 18

v
a) Global Objective......................................................................................................... 18
b) Specific Objectives ..................................................................................................... 18
III. TECHNICAL CHOICES......................................................................................... 19
IV. CAPTURE OF FUNCTIONAL NEEDS ................................................................ 19
V. CAPTURE OF THE OPERATIONAL NEEDS.................................................... 21
VI. PROJECT PLAN............................................................................................................ 21
A. Time Scheduling......................................................................................................... 22
B. Estimation of resources needed .................................................................................. 22
C. Items produced............................................................................................................ 24
CONCLUSION............................................................................................................................. 25
PART III: ANALYSIS PHASE.................................................................................................... 26
INTRODUCTION ........................................................................................................................ 28
I. PRESENTATION OF THE ANALYSIS METHOD ........................................................ 29
1. Presentation of UML.......................................................................................................... 29
a) Structural View........................................................................................................... 29
b) Behavioural View ....................................................................................................... 30
2. The process of development of software ........................................................................... 30
a) A Unified Process ....................................................................................................... 30
b) Two Track Unified Process ........................................................................................ 31
II. CAPTURE OF THE FUNCTIONAL NEEDS .............................................................. 35
A. Identification of use case ............................................................................................ 35
B. Use case Diagram ....................................................................................................... 36
C. The description of use cases ....................................................................................... 41
D. Activity Diagram ........................................................................................................ 55
III. CAPTURE OF THE TECHNICAL NEEDS ................................................................. 60
A. Deployment Diagram.................................................................................................. 60
B. Component Diagram................................................................................................... 62
IV. ANALYSIS .................................................................................................................... 65
A. Categorization and packaging..................................................................................... 65
B. State Machine Diagram .............................................................................................. 71
C. Interaction overview Diagram .................................................................................... 78
V. CONCEPTION............................................................................................................... 80

vi
Detailed Conception.................................................................................................................. 80
A. Sequence Diagram...................................................................................................... 80
B. Class Diagram............................................................................................................. 90
CONCLUSION............................................................................................................................. 93
PART IV: REALISATION PHASE............................................................................................. 94
INTRODUCTION ........................................................................................................................ 96
III. THE ARCHITECTURE OF THE APPLICATION..................................................... 105
IV. PRESENTATION OF TOOLS USED......................................................................... 107
CONCLUSION........................................................................................................................... 108
PART V: USER’S GUIDE ......................................................................................................... 109
INTRODUCTION ...................................................................................................................... 111
I. INSTALLATION OF THE APPLICATION .................................................................. 112
II. USING THE APPLICATION...................................................................................... 114
CONCLUSION........................................................................................................................... 122
GENERAL CONCLUSION ....................................................................................................... 123
BIBLIOGRAPHY....................................................................................................................... 124
WEBOGRAPHY ........................................................................................................................ 125

vii
LIST OF FIGURES
Figure 1:2TUP...........................................................................................................................32
Figure 2: Diagrammatical representation of use case diagram.................................................36
Figure 3: Representation of actors ............................................................................................36
Figure 4: Representation of inheritance ....................................................................................37
Figure 5: Representation of use case.........................................................................................37
Figure 6: Representation of association....................................................................................38
Figure 7: Representation of inclusion relation..........................................................................38
Figure 8: Representation of extension relation .........................................................................39
Figure 9: Representation of specialization................................................................................39
Figure 10: General Use case diagram of a << Microfinance>> ...............................................40
Figure 11: Use case of <<Manage User Account>>.................................................................43
Figure 12: Use case diagram of <<Manage Account Operations>>Error! Bookmark not
defined.
Figure 13: Use case Diagram of Manage Loans.......................Error! Bookmark not defined.
Figure 14: Use case diagram of <<Manage Products>>...........................................................52
Figure 15: Representation of sequence diagrams .....................................................................82
Figure 16: Sequence Diagram of <<Connect>> .......................................................................83
Figure 17: Sequence diagram of <<Record Deposits>>...........................................................83
Figure 18: Sequence diagram of <<Record Withdrawals>> ....Error! Bookmark not defined.
Figure 19: Sequence diagram of <<Create Employee Account>> ...........................................86
Figure 20: Sequence Diagram of <<Register Deposits>> ........Error! Bookmark not defined.
Figure 21: Sequence diagram of <<Update Employee Account>> ..........................................87
Figure 22: Sequence diagram of <<Create Product>> .............Error! Bookmark not defined.
Figure 23: Sequence Diagram of <<Read Requested Loans>> Error! Bookmark not defined.
Figure 24: Sequence diagram of<< investigation>>.................Error! Bookmark not defined.
Figure 25: Register Loan Request.............................................................................................88
Figure 26: Sequence Diagram of <<Setup Final Response>>..................................................89
Figure 27: Activity diagram of<< Program Meeting >> ..........................................................56
Figure 28: Activity diagram of<<investigate>> .......................................................................57
Figure 29: Activity diagram of<<Register Loan Request>> ....................................................58

viii
Figure 30: Activity diagram of<<Report>>..............................................................................59
Figure 31: Deployment diagram of the microfinance ...............................................................61
Figure 32: Explanation of Component Diagrams .....................................................................62
Figure 33: Component Diagram of<<Saving Transaction>> ...................................................63
Figure 34: Component diagram of <<Microfinance>> ............................................................64
Figure 35: Package diagram of <<Microfinance>>..................Error! Bookmark not defined.
Figure 36: Class diagram of<<Microfinance part1>> ..............................................................92
Figure 37 Class diagram of<<Microfinance part2>> ...............Error! Bookmark not defined.
Figure 38: State machine diagram of<<Collect data >>...........................................................72
Figure 39: State machine diagram of<<Register Loans >> ......................................................73
Figure 40: State machine diagram of <<Create User Account >> ...........................................74
Figure 41: State machine diagram of <<Collect Data>> ..........................................................75
Figure 42: State machine diagram of <<Update User account>> ............................................76
Figure 43: State machine diagram of<< Register Loans>> ......................................................77
Figure 44: Interaction overview of loan request .......................................................................79
Figure 45: Physical data model of <<Microfinance>> .............................................................98
Figure 46: The MVC Architecture..........................................................................................106

ix
LIST OF TABLES
Table 1: Presentation of Loans that may exist in MFIs ............................................................16
Table 2: Software Resources from Mercurial...........................................................................22
Table 3: Hardware Resources prices from Mercurial...............................................................23
Table 4: Human Resources Price..............................................................................................23
Table 5: Presentation of the left branch ....................................................................................33
Table 6: Presentation of the right branch..................................................................................33
Table 7 Textual Description of << Connect>> .........................................................................42
Table 8 Textual description of Manage << User Account>> ...Error! Bookmark not defined.
Table 9 Textual Description of<< Manage Account Operations>> .........................................49
Table 10 Textual Description of <<Manage Products>> .........................................................54
Table 11: Explanation of Activity Diagrams ............................................................................55
Table 12: Explanation of Class diagram...................................................................................91
Table 13: Explanation of State Machine Diagram....................................................................71

x
ABBREVIATIONS
2TUP Two Track Unified Process
CRUD Create Read Update Delete
HTML Hyper Text Mark-up Language
IAI African Institute of Computer Science
MVC Model View Controller
DB Database
ICT Information and Communication Technology
OOP Object Oriented Programming
OOSE Object Oriented Software Engineering
PC Personal Computer
PHP Hypertext Pre-processor
RDBMS Relational Data Base Management System
RUP Relational unified Process
SQL Structured Query Language
UML Unified Modelling Language
UP Unified Process
MFI Micro Financial Institution
NGO Non-Governmental Organization
CSS Cascading Style Sheets
XP Extreme Programming
UB Univers Binaire

xi
XUP Extreme Unified Process
EUP Enterprise Unified Process
RUP Relational Unified Process
PDM Physical Data Model
PHP Hypertext Pre-Processor
ICT Information and Communication Technologies

xii
SUMMARY
Nowadays, the technology has taken an important part of the life of humans in various domains
such as entertainment, agriculture, communication, health, economy, and many others. Thus, an
enterprise that wants to evaluate must use Information and Communication technologies (ICT).
IAI Cameroon integrates in its program, a practical training session for its students, for a
period of 4 months which we spent at Univers Binaire, an enterprise offering services in the ICT
sector. After two weeks of insertion at the latter enterprise, we were attributed the theme
“Conception and Realization of a Computerized Management System for Microfinances”.
In order to realize this project, we performed an investigation in some micro-financial
institutions and gathered the necessary information for the realization of our project. We then used
UML, an object-oriented graphical language for modelling, associated to 2TUP to obtain a
complete development method from analysis through conception, to realization. The application
was developed in a 3-level architecture, in the PHP programming language to obtain a flexible and
secured solution for microfinances.
The application produced at the end is called “Micro-Soft” and will be able to bring
customers closer to their MFIs.

xiii
ABSTRACT
De nos jours, les nouvelles technologies ont prises une importante dans la vie des hommes
dans plusieurs domaines tels que: la communication, le divertissement, l’agriculture, la santé et
bien d’autres domaines. Ainsi, une entreprise qui veut évoluer se doit d’utiliser les technologies
de l’Information et de la Communication (TIC).
L’IAI Cameroun intègre dans son programme pour ses étudiants, une période pratique de
4 mois, que nous avons passé à Univers Binaire, une entreprise qui offres des services dans le
secteur des TICs. Après 2 semaines d’intégration dans cette entreprise, nous avons été attribués le
thème « Conception et Réalisation d’un Système de Gestion des Microfinances ».
Dans le but de réaliser ce projet, nous avons effectués des descentes sur le terrain afin de
récolter les informations nécessaires. Nous avons ensuite utilisés le langage UML, qui est un
langage de modélisation graphique et orienté-objet, nous y avons associés le 2TUP, afin d’obtenir
une méthode de développement complète allant de l’analyse jusqu’à l’implémentation, en passant
par la conception. L’application a été développé dans une architecture 3-tiers, dans le langage de
programmation PHP afin d’obtenir une solution flexible et sécurisé pour les microfinances.
L’application produite à la fin de la période de stage a pour nom « Micro-Soft » et sera
capable de rapprocher les clients des microfinances.

xiv
GENERAL INTRODUCTION
IAI integrates in its Software Engineering training program for the end of the second year
of study, a four (4) months practicing program. This training seeks to ensure future employers of
IAI graduates, their rapid and effective integration in the workplace.
During the internship period, we participated in different activities and at the end we have
to ameliorate our skills by developing capacities for autonomy, reflection, research, accountability
and taxonomy.
Computer sciences being at the hard of many enterprise today, we had a variety of
enterprises for a choice but we had an internship at Univers Binaire which lasted for four months
in which we had the theme: Conception and Realization of a Computerized Management
System for Microfinances. Microfinances being our, we theme needed to make research
concerning it and to bring solutions so that microfinances and their customers can work together
in confidence, happiness and together as one. We divided this report into five parts which are as
follows:
1. Insertion document: here, we will present the company in which we spent our
internship period and the way we were welcomed in the company. At the end of
this part, we present the theme given to us.
2. Specification Book: In the specification book, we specify the needs of the
customer taking into consideration the time and cost of the project.
3. Analysis Document : Which presents the analysis method chosen together with
the presentation of all the diagrams used for the analysis of the project
4. The Realization Phase: which will permit to visualize the implementation process
of the solution.
5. The User Guide: Which presents the condition necessary to use the application
and how to use it.

xv

1
PART I: INSERTION DOCUMENT

2
Preamble
The insertion document is part of the internship report where we present
the internship environment, the organization structure of the company, how we were welcome in
the company and equally the projects to be realized during the internship.
Content
INTRODUCTION
I. Reception at UNIVERS BINAIRE
II. Presentation of UNIVERS BINAIRES
III. Resources
IV. Geographical Location
CONCLUSION

3
INTRODUCTION
In other to practice what have been thought to us in African Institute of Computer Science,
Paul BIYA Technological Centre of Excellence, the school integrates at the end of its second year
program in software engineering a practical training course with a duration of four months (4),
which is the main reason why we integrated UNIVERS BINAIRE.
The insertion report presents our two first weeks in this enterprise, how we were welcomed
and also its organization structure. This is in fact the first step out of a series of documents that
would be the result of our presence in this company. Here, we are going to present the history,
mission, organization, working domain and the theme that have been proposed to us.

4
I. RECEPTION AT UNIVERS BINAIRE
At our arrival at UNIVERS BINAIRE on Thursday 02nd June 2016 at 8 AM, we were
welcomed by the Chief Executive Officer, MR. GAPIAPSI NGUETO Martial, which presented to
us the different departments of the company. There-after, we had a meeting which lasted for 3
hours during which the Chief Executive Officer started by presenting himself to us and went further
to explain and present how important the internship is, how the company is organized and our
different functions and plan of work. He finished by encouraging us to work hard and asked us to
meet him on the following Monday in order to start with the internship.
II. PRESENTATION OF UNIVERS BINAIRE
1. HISTORY
UNIVERS BINAIRE was created on Sunday 7 of December 2014 by Mr GAPIAPSI
NGUETO Martial, in order to realize the dream that he had since he was in secondary school. This
enterprise provide many services such as software development, maintenance, configuration of
graphic design, website hosting, training in office tools, programming, systems and networking.
2. Missions
The principal objectives of UNIVERS BINAIRE are as follows:
Develop Applications;
Develop Websites;
Network installation and maintenance;
Offers training in ICT, office tool, System, programming and networking
3. Administration chart of UNIVERS BINAIRE
UNIVERS BINAIRE is placed under the supervision of the Chief Executive Officer (CEO)
who manages the day to day running of the enterprise and the implementation of its policies. The
following diagram shows the functioning of activities at UB:
 Human Resources Department which is charge of :
 Recruiting personnel,
 Transferring personnel,
 Paying personnel;

5
 Development Department which is charge of:
 Elaborating terms of reference for clients,
 Making estimates for software demands,
 Analysing and designing IT projects;
 Multimedia and Graphic Design Department which is in charge of:
 Elaborating terms of reference for clients,
 Making estimate,
 Creating graphics designs for clients;
 Maintenance Department which is in charge of:
 Diagnosing hardware problems,
 Repairing hardware equipment,
 Creating graphics designs for clients;
 Sales and Marketing Department which is charge of:
 Commercializing products,
 Publicizing goods and service,
 Selling goods and services;
 Accounting Department which is charge of:
 Managing stocks input and output,
 Producing balance sheet;
 System and Network Department which has as functions:
 Elaborating terms and reference to clients,
 Making estimates,
 Network installation and troubleshooting;

6
 Training department having the following function:
 Elaborating training schemes and programs,
 Training participants in office tools, programming Languages, operating
systems and networking.
4. Organization Chart of UNIVAIRE BINAIRE
Figure 1: Organization Chart of UNIVERS BINAIRE
CHIEF EXECUTIVE OFFICER
GENERAL DIRECTOR
DEVELOPMENT
DEPARTMENT
SYSTEM AND
NETWORKS
DEPARTMENT
MAINTENANCE
DEPARTMENT
MARKETING AND
SALES
DEPARTMENT
GENERAL
SECRETARY
HUMAN
RESOURCE
DEPARTMENT
ACCOUNTING
DEPARTMENT
MULTIMEDIA AND
GRAPHICS
DEPARTMENT
TRAINING
DEPARTMENT

7
5. Development Department
Our internship period will be spent in the Development Department and it carries out the
following activities:
 Elaborates terms of references for clients;
 Makes estimates for software demands;
 Analysing and designing IT projects;
 Development of software.
III. RESOURCES
1. HARDWARE RESOURES
The development department of UNIVERS BINAIRE has laptops, router,
telephones, optical fibre, routers, printers, scanners, maintenance case, switches and telephone
lines.
2. SOFTWARE RESOURES
Computers are equipped with operating systems such as windows seven and development
tools such as:
 Programming language: JAVA, PHP, C++ and C;
 Modelling tools: Power AMC;
 Operating Systems: Ubuntu and Debian;
 Data Base Management System: My SQL.

8
IV. GEOGRAPHICAL LOCATION
1. LOCALISATION CHART
The enterprise, UNIVERS BINAIRE, is located at Awae Escalier precisely at the OBERLI
residence not very far from the high way between IFTIC-SUP and IAI Cameroon.
Figure 2: Diagram belonging to UNIVERS BINAIRE (Localization Plan)

9
CONCLUSION
The end of the first two weeks of internship has helped us to take contact with our
environment in UNIVERS BINAIRE, which is the enterprise in which we will work during our
four months of internship. We confirm that the condition in which we find ourselves in this
company together with the understanding of the enterprise, its personnel, its mission, and the rules
and regulations have been well understood. Many themes were presented to us and the theme to
be presented throughout this document is: conception and realization of a computerized
management for MICRO FINANCE. The next step in this book will be to elaborate the
preliminary study which would in line with the academic and professional needs.

10
PART II: SPECIFICATION BOOK

11
Preamble
The specification book is the part of the document that describes with precision the need of
the user and the condition necessary for the success of the project. This part is considered as the
part of communication and the description of the project in order to avoid the production of
inadequate result.
Content

12
INTRODUCTION
The specification book gives us the directives on the product to be delivered, the conditions of their
delivery and the technical specifications of the deliverable. We will establish this book as the
executors of the project on one hand, with the close agreement with the project’s owner or client.
In this project, we, students of IAI constitute the executors and the Director of UNIVERS
BINAIRE makes up the project owner. This specification book will enable us to realize and also
specify the needs of the user (clients) geared toward the new information system, details to respect
as well as the constraints on the tools to be used.

13
I. CONTEXT
Microfinance, according to Otero (1999, p.8) is “the provision (or supplying) of financial
services to low-income poor and very poor self-employed people”. These financial services
according to Ledgerwood (1999) generally include savings and credit but can also include other
financial services such as insurance and payment services. Therefore, microfinance involves
the provision of financial services such as savings, loans and insurance to poor people living
in both urban and rural settings who are unable to obtain such services from the formal financial
sector.
1. Core principles of microfinance
 The poor also need access to appropriate financial services. That is why MFI must aim is
to provide financial services to an increasing number of disadvantaged people
 The poor has the capability to repay loans, the real cost of loans and generate savings
 Microfinances is an effective tool to attenuate poverty
 MF NGOs and programs must develop performance standards that will help define and
govern the MF industry toward greater reach and sustainability
2. Characteristics and features of a MFI
Categorization
 MFIs are divided into category 1, 2 and 3
Type of client
 MFI have low income clients
 They are employed in the informal sector
 They lack Physical collateral security
 Household and business activities are closely interlinked
Lending Mechanism
 Prompt approval and provision of micro loans since they are usually needed in
immediate purpose
 Consideration of collateral substitutes and also possibilities of group based
guarantees

14
 For security, conditional access to further microcredits
 Lending is based on information about usual financial flow analysis and group
based borrower selection
Loan Portfolio
 Highly volatile
 Risk heavily depend on the portfolio management skills
Organizational Ideology
 MFI have cost recovery objectives and are aimed at maximizing profit
 Non-dependent from government
3. BRIEF HISTORY OF MICROFINANCES
The history of microfinances can be traced back as long to the middle of the 1800 when the
theorist Lysander Spooner was writing over the benefits from small credits to entrepreneurs and
farmers as a way of getting the people out of poverty. But it was at the end of World War 2 with
the Marshall plan that the concept had a big impact.
The today use of micro financing has his root from Muhammad Yunus and the founding of
Bangladesh’s Grameen’s Bank. In the middle of the 1970’s, Bangladesh was trying to build a new
nation. Muhammad Yunus, an economist trained at Vanderbilt University was teaching at
Chittagong University in southeast Bangladesh started in 1976, started a series of experiments
lending to poor households in the nearby village of Jobra. He found that borrowers where not only
profiting greatly by access to the loan but they were also paying reliably even though, they could
offer no collaterals. That same year, Yunus convinced the central Bank of Bangladesh to help him
settle a special branch to help the poor people living in Jobra, the Grameen’s Bank. This brought
another trial project, this time in Tangail in North-Central Bangladesh. This project was not region
specific, but nationwide. One innovation that made Grameen’s to grow explosively was group
lending, a mechanism that allowed the poor borrowers to act as guarantors for each other. With
group lending in place, the bank could easily grow village by village as funding permitted.
In Cameroon, since it independence, the government has embarked on several attempts aimed
at promoting agriculture development in the country. In the first years after independence in 1961;

15
the government embarked on the policy of <<GREEN REVOLUTION>>, which aimed at
encouraging the development of agriculture in the country. Other efforts included the setting up of
agencies like National Fund for Rural Development (FONADER) and other rural extension
program. In spite all of this attempt, much is still needed to boost this sector, which is considered
very vital for the economy wire of the state. A recent development in this sector has been the
increase involvement of Non-Governmental Institutions (NGOs) and the microfinance institut ion
in the process of enhancing the development of informal sector.
STUDY OF THE EXISTENCE
Microfinances in Cameroon are quickly expanding, and institutions have increased their
activities. This is because offering financial services to the poor people is an expensive business to
banks. The cost is one of the reason why traditional banks don’t make small loans, the loans
required for a 100 000 FRS loan is the same as for the 1 000 000 FRS loan. This is why
microfinances have been successful in reaching the population excluded from the classical
financial system. In the last decade, the government’s efforts have been concentrated toward
financial and institutional sustainability of the microfinances institution.
1. Product and services
a) Loans
The microcredit loan cycle are usually shorter than the traditional commercial loans with terms
from typically six months to a year with payments plus interest, paid weekly. Shorter loan cycles
and weekly payments help borrowers stay current and not become surprised by large payments.
Clearly the transaction intense nature of weekly payment collection, often in rural areas, is more
expensive than running a bank branch that provides large loans to economically secure borrowers
in city. As a result, MFIs must charge interest rate that might sound high.
In order to lend money, the MFIs must in addition borrow from traditional finance sector
with commercial perspective. There’s is always 1-2% loss on loans due to people not paying back.
Typical microcredit product look like this (the number is only hypothetical):
Product Purpose Terms Interest rate
Income Generating
Loan (IGL)
Income generating,
asset development
50 weeks loans
Loans paid weekly
12.5%(flat)-24%
(effective)

16
Mid Term loan
(MTL)
Same as IGL,
available at middle
(week 25) of IGL
50 weeks loans
Loans paid weekly
12.5%(flat)-24%
(effective)
Emergency Loans
(EL)
All emergencies such
as health, funerals,
hospitalization
20 weeks loans 0% interest
Free
Individual Loans (IL) Income generating,
asset development
1-2 years loans paid
weekly
11% (flat)-
23% (effective)
Table 1: Presentation of Loans that may exist in MFIs
The Income Generating Loan is used for a variety of activities that generate income for their
families. Clients submit a loan application and based on approval, receive the loan after one week.
Loans are paid equal weekly instalments. After completion of the loan cycle, the client can submit
an application for future loans. The approach with short-loan is to avoid long term economic
problem with bigger loans.
The Mid Term Loan is available to client after 25 weeks of repaying their IGL loans. A client
is eligible for MTL if the client has not taken the maximum amount of IGL. The residual amount
can be taken as MTL. The term and condition of MTL is the same as IGL.
The Emergency loan is available to all clients over the course of a fiscal year. The loan is
interest frees and the amount and repayment terms are agreed upon by MFIs and the client on a
case by case basis. The amount is small compared to the income generating products and is only
given in the case of dire need to meet expensive such as funerals, hospital admission, prenatal care
and other crisis solution.
The Individuals Loans is designed for clients and non-clients that have specific needs beyond
the group lending model. Loans are given to individuals outside the group lending process.
Amounts are typically higher than that of income generating loans and repayment are less frequent.
Applicant must complete a street business appraisal process and have both collaterals and
guarantors.
Microfinances is not a solution to all troubles, this means that not any poor person can obtain
the loan. In particular very poor people living by a means of chance earning, lacking stable income

17
and particularly having debts cannot be client of microfinances because in case of non-repayment,
they will become poorer in case of non-repayment. There is some restriction with what money is
used for. Usually, microcredit is not used for the following purpose:
 Payment for other loans or depth;
 Production of tobacco an liquor;
 Forming turnover capital for trade and intermediary business;
 Organizing or purchasing products for gambling or entertainment services for the
population;
 Establishing trading points;
 Purchase for properties that are not used for business.
b) Micro Savings
The poor need like any one a secure place to store their money. That is, a place that allows
people to retain money for future uses or for unexpected costs. The following are examples
of savings that may exist but it varies from MFIs:
 Deposited Account: These are current account and withdrawals are possible through
cheques. Private and public sectors salary are treated in this account. Withdrawals
are instant on demand and there are no monthly handling charges.
 Saving Accounts: This is open for individuals, groups and enterprise. Earn above
market interest rates on your saving annually. A prior notice restrict withdrawals
from this account because this account is linked to the insurance account.
 Minor Account: This permit to save money for the future of our children. This
saving is separate and can start as early as the child is born.
 Group Account: This account is reserved for legalized groups like meetings,
associations, NGOs and churches. It allows for safe keep of groups funds and avoids
misappropriation by individuals. Interest is paid on the amount saved and
withdrawals are free of charge.

18
c) Micro insurance
Gives the entrepreneur the chance to focus more on their core business activities
which drastically reduces the risk of affecting their property, health or working
possibilities. There are different types of insurance which include life insurance, property
insurance, health insurance and disability insurance. The spectrum of insurance in this
sphere is continually increasing and their services are determined by each company
individually.
d) Micro Leasing
For entrepreneurs or small businesses who can’t afford to buy at full cost, they can
easily lease equipment’s, agricultural machineries or vehicles. Often there is no limitation
of minimum cost of the leased object.
e) Money Transfer
A service for transferring money mainly to family or friends
II. OBJECTIVES
a) Global Objective
The main objective of this project is to realize software that will manage efficiently MFIs. This
will permit to bring out speed and security to microfinances.
b) Specific Objectives
This permits to bring out the description of information in the system and permits the users
to effectively understand the system. The system will be able to:
 Provide a convenient user friendly interface to customers/members and to the
personnel of the MFI;
 Provide a centralized database for the MFI;
 Facilitate communication between the MFI and its stakeholders;
 Permits to generate statistics about MFI;
 Provide clean and reliable information to facilitate decision making.
 Provide traceability of operations within the MFI.

19
III. TECHNICAL CHOICES
Microfinances need to adapt themselves to the continuously changing needs
of customers. After an introductory analysis of the project, software dealing with microfinances
needs to be iterative and incremental and thus needs certain technologies to adapt to the different
needs.
The principal technologies are:
The object oriented modelling with UML;
The 3 tiers architecture with DBMS;
The use of object oriented programming with PHP.
IV. CAPTURE OF FUNCTIONAL NEEDS
After contacting different employees of the microfinance, we could know how the different
workers do their jobs. They are as follows:
 Loan Granting Process
The applicant deposits a loan request to the MFI. We say applicant because the person
which wants to be granted the loan may not be a member of the microfinance (that is may not have
an account in the MFI). The application files are under the responsibility of the credit officers. The
designated credit officer meets with the applicant and guarantor, if any, and collects the relevant
data, and make a recommendation to the credit committee (usually the branch manager).The credit
officer needs to examine in details the applicant’s business balance sheet and the household
budget’s. Lastly, the full application file together with the credit officer recommendation is
examined by the credit committee who has the final word on the loan approval/denial and loan
size.
 Management of products
The branch manager creates products and specifies the necessary condition and/or
requirements for each product. The products are saved in the database. The client, the marketing

20
agent, the teller and the field assistant can consult the list of products and subscribe to the different
products or print them for their clients.
 Clients
A client is a person that has created his account in the microfinance and has subscribe to a product.
 Manage account operations
After all the arrangement between the credit officer and the applicant, if the loan request is
accepted, the request will have a way of paying back the loans so that it should not be heavy on
the applicant. Depending on the arrangement, this payment can be done weekly, after two weeks
or monthly, and certain amount is deposited by the applicant to the cashier or to the field assistant.
After a client/member has created an account, he chooses directly a product he wishes to
subscribe. Then, he can deposit money in his account either directly in the branch through the
cashier or through teller who are representing a branch in the field.
A teller is the person who collects money from the different clients in the field and then
deposits their money in the bank.
When the marketing agent creates an account, there is a first money that is given by the
client in order to confirm his registration.
The main function of the marketing agent is to present the MFI to potential clients.
 The director
The director is the one that creates a Microfinance and a Branch and specify certain
information concerning the branch like the name and opening time.
 Field staff
Field assistant manager must perform survey before entering the village or town, conduct
interview with potential borrowers, educate the borrower in credit discipline, visit the borrower
every week to collect interest and distribute loans and control that the loans are being used for the
given purpose.

21
Mobilization of new members to form new centers, conduct group meeting and verify loan
utilization and ensure 100% timely collection. Book keeping and record maintenance of allocated
centers.
 The branch manager
The branch manager is responsible for the administration and efficient daily operation of
the branch officer, including operations, product sales, customer and services. Develop new deposit
and loans business.
V. CAPTURE OF THE OPERATIONAL NEEDS
 Security
During the connection, each user should be recognized by the system so as to be presented
his actions only. A cashier for example should not have access to functionalities that are particular
to the branch manager.
A client can access the different products or perform any transaction by creating his or her
account. These clients can be connected via internet and have information accessible by
themselves. All these operations should be traced.
An applicant can borrow money without having an account and that’s the only operation
that can be done by the applicant/borrower.
 Profile Manager
This allows a categorization of users and eases management of rights and permissions on the
functionalities of the system.
VI. PROJECT PLAN
This section describes scheduling of the project realization, its costs and products. This
project will have to pass through a series of feasibility studies, field studies and analysis, to ensure
a perfect definition of the context, expectations and boundaries. The project will then pass through
the implementation, testing and maintenance phases to ensure its realization. This section will also
define the time schedule.

22
A. Time Scheduling
The time management being an important factor in project management, it is important to
define exactly when and for how long each phase of the project will be realized. Our internship
period is 4 months which leads us to the below scheduling of time:
The time being completely allocated, we need to allocate resources to the project according to
its requirements.
B. Estimation of resources needed
1. Software resources
Resource Software Usage Quantity
Cost
(FCFA)
Database
Management
System
MySQL Communicating with the
database 1
Free
Operating
System
Microsoft®
Windows® 10
Operating system of the
computer
1
100,000
Development
Software
NetBeans IDE Integrated development
environment for editing of
HTML, CSS and PHP codes.
1
Free
Project
Planner
Microsoft Project Project planning tool
1
194 623
Installation
Media
Microsoft Office Used for the realization of
the internship report
1
460 000
Modelling
tool
Visual Paradigm Modelling the system in UML
1
100 000
Server
Package
Wamp Server Server suite used as
application and database
server
1
Free
Total 1 - - 854623
Table 2: Software Resources from Mercurial

23
2. Hardware resources
Resource Hardware Usage Quantity Cost (FCFA)
Computer
Dell Latitude
E6400
Analysis, coding,
document building
2
400 000
Installation Media CD-ROM Installation media 1,000
Removable disk
2GB USB key For file transfers
between computers
2
8000
Total 2 - - 409,000
Table 3: Hardware Resources prices from Mercurial
3. Human resources
Resource Number Cost per day Number of days Cost (FCFA)
Analyst 2 12000 21 504 000
Designer 2 10 000 10 200 000
Programmer 2 5750 14 161 000
Tester 900 000
Total 3 - - 1,765,000
Table 4: Human Resources Price
Total1 + Total2 + Total3 =3,028,623 FCFA
Unexpected: 20% of Total = 605,724 FCFA
Overall total = 3,028,623 + 605,724 = 3,634,347 FCFA
Hence the total cost is evaluated at 3,634,347 FCFA
The resources and their cost allocated to the project, we have to define what will be the
output of these resources.

24
C. Global planning of the project
For the realization of this project, our application will pass through several stages which
depend on each other. The duration of this project is 4 months. Each stage must be carried out in
the strict respect of the time which is assigned to it as indicated in the following diagram:
D. Items produced
At the end of the internship period, we are supposed the produce:
 An insertion report;
 A specifications book;
 An analysis document;
 A conception document;
 An implementation document;

25
 A user manual;
 The software in a CD-ROM.
CONCLUSION
This section defined the expectations that the software should meet, the way it will be
realized and its requirements. To conclude, the complexity of the system requires a secured, fast
and reliable system that needs to be developed within the allocated time, in order to meet with the
specifications.

26
PART III: ANALYSIS PHASE

27
Preamble
The analysis put in place in this book present the modelling of the solution proposed,
presents in details the functionalities to take into consideration, the different diagrams and their
arrangement in order of risk and priority.
Content
INTRODUCTION
I. Presentation of the analysis method
II. Capture of the functional needs
III. Capture of the technical needs
IV. Analysis
V. Conception
CONCLUSION

28
INTRODUCTION
All computer projects needs to be well analyze in order to provide an answer to the
different problems faced. Before programming, we have to be sure that we will consider all the
specifications of the project. This part will permit us to define all the boundaries of the system, its
component and how they interact together to accomplish a task.
This section will consist of choosing an appropriate analysis method and using it to
analyze the information system of Micro financial institution.

29
I. PRESENTATION OF THE ANALYSIS METHOD
1. Presentation of UML
UML stands for Unified modelling Language. It is a graphical language used for visualizing,
specifying and documenting blueprints of an object-oriented software system.
As its name suggests, UML defines software system and is just a language. There is no
development method or procedure in UML and is thus incomplete for software development.
UML proposes two main ways in which a system can be looked at:
- Structural View
- Behavioural View
a) Structural View
The structural view shows elements that make-up the system and their relationships. In
fact, the class diagram is a perfect example. Other diagrams just follow the principle of class
diagrams. The other diagrams that constitute this view are: object diagram, composite structure
diagram, component diagram, deployment diagram and finally package diagrams.
The following describes diagrams of the structural view.
Package diagrams are used to divide the model into logical containers or “packages” and
describe the interactions between them at a high level
Class or Structural diagrams define the basic building blocks of a model: the types, classes
and general materials that are used to construct a full model
Object diagrams show how instances of structural elements are related and used at run-
time.
Composite Structure diagrams provide a means of layering an element's structure and
focusing on inner detail, construction and relationships
Component diagrams are used to model higher level or more complex structures, usually
built up from one or more classes, and providing a well-defined interface
Deployment diagrams show the physical disposition of significant artefacts within a real-
world setting.

30
b) Behavioural View
Behavioural diagrams captures the variety of interaction and instantaneous state within a
model as it ‘execute’ over time.
Use Case diagrams are used to model user/system interactions. They define behaviour,
requirements and constraints in the form of scripts or scenarios
Activity diagrams have a wide number of uses, from defining basic program flow, to
capturing the decision points and actions within any generalized process
State Machine diagrams are essential to understanding the instant to instant condition
or "run state" of a model when it executes
Communication diagrams show the network and sequence of messages or
communications between objects at run-time during a collaboration instance
Sequence diagrams are closely related to Communication diagrams and show the
sequence of messages passed between objects using a vertical timeline
Timing diagrams fuse Sequence and State diagrams to provide a view of an object's
state over time and messages which modify that state
Interaction Overview diagrams fuse Activity and Sequence diagrams to provide allow
interaction fragments to be easily combined with decision points and flows
2. The process of development of software
A process is defined as a sequence of steps, partly ordered which permits to obtain software
system or the evolution of an existing software. The objectives of software development is the
production of quality software which answer the needs of users during a particular time and at a
particular cost.
a) A Unified Process
A unified process is a process of development of software constructed on UML; it is
iterative, incremental, centred on the architecture, driven by the use cases and driven by
requirements.
- Iterative and incremental

31
Iterations are distinct sequences of activities with a basic plan and an evaluation criteria which
produce an output (internal or external). Either the content of an iteration is ameliorated or the
evolution of the system is evaluated by the users.
An increment is the difference between two release produce at the end of two iterations. Each
iteration ensures that the group is capable of integrating the technical environment in order to
develop a final product and give the possibility to users to have tangible results of their
specifications.
- Risk-driven: Here, the major causes of the failure of software project must be avoided in
priority. We identify the first cause coming from the incapacity of the technical architecture
to answer to operational constrains and the second cause is due to inadequacy of the
development of the needs of users.
- It is constructed around the creation and the maintenance of a model instead of the
production of mountain of documents. The volume of information of this model needs a
strict organization which represents the different viewpoints of the software at different
level of abstraction.
- It is component oriented: Whether at the level of modelling and/or production, it is the
guarantee of flexibility for the model itself and the software it is representing. This type of
practice constitutes the necessary support for the re-usability of software and offers a
perspective of gain that is not negligible.
- It is user oriented: since the specification and the conceptions are constructed from the mode
of utilization of the user of the systems.
- Examples of unified process are 2TUP, RUP, XUP, EUP, …
b) Two Track Unified Process
2TUP is a UP process. The 2TUP brings an answer to the constraint of continual changes
imposed by the information system of the enterprise. In this sense, it enforces the control on the
capacity of evolution and correction of the system. “2 Tracks” signifies literally that the system
follows two branches. These branches are “functional” and “technical” branches which answer to

32
the two level of changes imposed by the information system. After the evolution of the functional
branch and the technical branch, the realization merges the results of the two branches. The
merging permits to obtain a process of development in the form of Y as illustrated in the figure
below.
Figure 1:2TUP
i. The left branch (functional)
It captures the functional needs which help preventing the production of software
that does not fit the need of the user. The analysis here consist of studying precisely
the functional specification in order to obtain an idea of what the system is going to
realise and its result does not depend on any technology. The table below shows the
different diagrams which constitute this branch.
Capture of the functional need
 Use case diagram
 Collaboration diagram
 Activity diagram

33
Analysis
 Interaction overview diagram
 State machine diagram
 Package Diagram
 Interaction overview
Table 5: Presentation of the left branch
ii. The right branch (Technical branch)
It captures all the constraints and choices related to the conception of the system,
the tools and equipment’s as well as the integration constraint with the existing system
condition. The different diagrams are shown in the table below:
Capture of the technical needs  Component diagram
 Use case diagram
Generic conception  Deployment diagram
Table 6: Presentation of the right branch
iii. The middle Branch
The preliminary conception, the detailed conception and the documentation of the
system are studied here. The diagrams are shown in the table below:
Preliminary conception  Component diagram

34
 Deployment diagram
Detailed conception
 Class diagram
 Sequence diagram
 Collaboration diagram
 Activity diagram
 Component diagram

35
II. CAPTURE OF THE FUNCTIONAL NEEDS
The capture of the functional needs is the first step in the left branch of the Y cycle. It
formalizes and explains in details what have been presented in the preliminary study.
A. Identification of use case
The different use cases of our system are as follows:
 Manage Microfinances;
 Manage Branch;
 Manage Products;
 Manage Interest Cost;
 Manage Interest Rate;
 Manage Account Type;
 Manage Interest Time;
 Manage Accounts
 Manage User Accounts;
 Manage Employee Account;
 Manage Account operation;
 Manage Meeting;
 Manage Meetings;
 Manage Loans;
 Manage User Type;
 Manage Menus;
 Print;
 Reports;
 Connect;
 Disconnect.

36
B. Use case Diagram
The use case diagram simply shows the functionalities of the system, their
interdependency and how they are linked with actors of the system. It also clearly defines the
boundaries of the system. The following is a use case diagram:
Figure 2: Diagrammatical representation of use case diagram
 An Actor
An actor represents an entity that directly interacts with the system. The actor is what performs
the different possible actions of the system. The following is a representation of an actor as
specified by UML:
Figure 3: Representation of actors

37
Note that an actor does not necessarily represents specific physical entity but merely a
particular facet of some entity that is relevant to the specification of its association use case.
Actors can have relations between them. The only possible relation between actors is
inheritance and is represented by an empty arrow-headed line from the child to the parent actor.
For example:
Figure 4: Representation of inheritance
 Use case
A use case represents a functionality of the system. It is an action that can be performed by an
actor. It is represented as follows:
Figure 5: Representation of use case
The notation for using a use case is a connecting line with an optional arrowhead showing the
direction of control. The following diagram shows the relation between an actor and a use case:

38
Figure 6: Representation of association
Use cases can have relationships between them. The relationships can be
specialization/generalization, inclusion or extension.
Inclusion:
An inclusion relation denotes that an included action must be performed before another
action can be performed. It is represented by a broken arrow with the stereotype “<< include >>”
as follows:
Extension:
An extension relation denotes that an action may be performed while another one is being
performed. It is represented by a broken arrow with the stereotype “<< extend >>” as follows:
Figure 7: Representation of inclusion relation

39
Figure 8: Representation of extension relation
Specialization:
A generalization relation between use cases denotes different ways of performing a
particular action or use case. For example,
Figure 9: Representation of specialization

40
The use case diagram of the micro finance system is as follows:
Figure 10: General Use case diagram of a << Microfinance>>

41
C. The description of use cases
As we mentioned earlier, a use case represent a transaction. Here, is a question of breaking
down the use cases, making a textual description and then emphasizing on the different detailed
scenario. This will be done using diagrams known as the sequence diagram, the collaboration
diagram and activity diagram.
The various textual description will be represented as follows:
 Identification of content: here we are going to give the title, the goal and actors
concerned in the user cases.
 The description of scenario of uses cases.
The description will be presented in the form of a table, where we will find the elements mentioned
above.
The use case “Connect”
Identification of content
Title: Connect
Goal: To permit all the users of the application to connect to the system.
Actors: Branch manager, cashier, teller, loan officer, customers/members.
Description of scenario
Pre-condition: Launch the system
Nominal Scenario:
1. The user clicks on the connection button;
2. The system sends a connection form;
3. The user enters the login and password and submits;
4. The system verifies the information in the database;
5. A welcome page is presented to the user in case the information are found in the
database;

42
Alternative Scenario
5a. An error message is displayed to the user;
5b. The system returns to step 2.
Table 7 Textual Description of << Connect>>

43
1. The use case <<Manage User Account>>
Figure 11: Use case of <<Manage User Account>>
Textual description of “Manage User Account”
Title: Create individual account
Objective: Permits users to individually create their account easily and rapidly.
Principal actor: Customer/member

44
Secondary actor: Cashier, marketing agent
Description of scenarios
Pre-condition: launch the system
Steps:
1. The actor chooses the menu “create account”;
2. The system presents a form to the user;
3. The user fills the form and submits;
4. The system verifies if all the information have been entered and if the information does
not exist in the database;
5. The system sends a confirmation message to the user in addition to the presentation of
the different products and the different branches available in the microfinance.
6. The user chooses a product and a branch where he wishes to deposit his money;
7. The system sends a message to confirm his registration.
Alternatives
3a. The user fills the form with invalid or incomplete data;
5a. The system displays an error message;
5b. The system returns to level 2.
Title: update user account
Objectives: Permits to modify certain information about a user
Principal actor: customer/member
Pre-condition: Read user account
Steps:
1. The customer/member chooses the menu update account;
2. The system presents a form containing information about the customer;
3. The user modifies the information and clicks on submit;
4. The system verifies the new information and saves in the database;
5. The system sends a confirmation message to the user.

45
Alternative Scenario
5a. System attempts and fails the saving;
5b. An error message is displayed;
5c. The system returns to step 2.
Title : Read transaction history
Goal: To permit the user to read the transactions done in their account
Actors: Customer/member
Secondary actor: Marketing agent, Teller, cashier
Pre-condition: Connect
Scenarios:
1. The actor clicks on read transaction history;
2. The system presents all the history of transaction.
Table 8 Textual description of Manage << User Account>>

46
Figure 12: Use case diagram of <<manage account operations>>

47
2. The use case <<manage account operations>>
Textual description of use cases in “Manage account operations”
Title: Register deposit
Objective: The use case permits to input money in the Microfinance
Principal actor: Cashier
Pre-condition: connect
Nominal Scenario
1. The actor clicks on register deposit;
2. The system presents a form ;
4. The system verifies if all the fields were filled;
5. The information is saved in the database and the amount in the account is increased or
the loan is reduced.
6. The system sends a confirmation message to confirm the registration.
Alternative scenario
5a. The information cannot be saved;
Post-condition: The amount has been successfully deposited
Title: Register withdrawal
Objective: The use case permits the removal of money from an account

48
Nominal Scenario
1. The actor clicks on register withdrawals;
2. The system presents a form;
5. The information about the amount present in the account is searched from the database,
the amount asked by the customer/member and debited from it and both the transaction
and the remaining amount present in the account are saved;
5a. An error message is sent if the amount to be removed is more than the amount in the
account ;
5b. The system returns to step 2.
Title: Record deposit
Objective: The use case permits the customer to input money without coming directly in the
microfinance
Principal actor: Marketing agent, teller
Nominal Scenario
1. The actor clicks on register deposit;
2. The system presents a form ;
5. The information is saved in the database;

49
5a. System attempts and fails the saving;
Table 9 Textual Description of<< Manage Account Operations>>

50
3. The use case << Manage loans >>
Figure 13: Use case diagram of <<manage Loans>>
Textual description of use cases in “Manage Loans”
Title: Register loan requests
Objective: The use case permits to input money in the bank
Nominal Scenario
Credit officer logs in

51
1. System presents a list of all recent loan requests
2. Credit officer clicks on "New " button;
3. System displays a loan request form to be filled;
4. Credit officer fills the form with the loan request information and saves
5. System notifies the Credit officer that the operation was successful
Post-condition: The amount has been successfully deposited
Title: Investigate
Objective: Permits the saving of investigation information be the credit officer
Principal actor: Credit officer
Nominal Scenario
1. Credit officer logs in;
2. System displays a list of recent loan requests;
3. Credit officer chooses a loan request and clicks on "investigate" button;
4. System displays an investigation form;
5. Credit officer fills the form and saves;
6. System processes;
7. System notifies the credit officer that the action was successful
Title: Setup final response
Objective: The use case permits the credit committee (branch manager) to evaluate a loan
request file and respond to it
Principal actor: Branch manager
Nominal Scenario
1. On the list of loan request (investigated or not), branch manager clicks on a request;

52
2. The system load the information concerning the loan request and investigation
information;
3. Branch manager clicks on "setup final response";
4. System displays a response form;
5. Branch manager fills the form and validates the response;
6. System processes the operation;
7. System notifies the successful operation.
Table 10: Textual Description of <<Manage Loans>>
4. Use case diagram of Manage Products
Figure 14: Use case diagram of <<Manage Products>>

53
Textual description of “manage products”
Title: Create Products
Objective: Permits to add new products in the MFI
Principal actor: Branch Manager
Nominal Scenario
1. Branch manager clicks on "new" button;
2. System displays a new product form;
3. Branch manager fills the new product form with information concerning the new product;
4. Branch manager clicks on "save";
5. System processes the data;
6. System saves the new product in the database;
7. System sends a successful message to the Branch manager.
6.a. Invalid data entered
1. System displays an error message.
Post-condition: The product has been successfully created
Title: Update Product
Objective: Permits the Branch manager to easily update a product.
Principal actor: Branch Manager
Pre-condition: Connect

54
Table 11 Textual Description of <<Manage Products>>
Steps:
1)Branch manager clicks on the "details" button of a product;
2)System displays details concerning the chosen product;
3)Branch manager clicks on the "edit" button;
4)System displays an editable form with details concerning the product;
5)Branch manager edits the product details;
6)Branch manager edits the product details;
7)System processes the data;
8)System updates the product details in the database;
9)System displays a successful message;
Alternatives
7.a. Invalid data
1. System displays an error message;
2. Go to 7.
Post-condition: Product successfully updated.
Title: Read Product
Objective: Permits Users to read the different products created.
Principal actor: User
Pre-condition :Connect
Steps:
1) Branch manager enters the product management section;
2) System displays a list of created products;
Post-condition: Product presented to users.

55
D. Activity Diagram
The activity diagram is used to represent the sequence of activities and actions of the
system. It shows details from a start point to end point through all decisions and actions that can
possibly be performed. It permits to consolidate the specification of a use case. It may be used to
detail situations where parallel processing may occur in the execution of some activities.
Name Diagrammatical Representation Description
Activities An activity is a round
cornered rectangle enclosing
all actions, control flows and
other elements that make up
an activity.
actions
It represents single step
within an activity.
Control flow
It shows the flow of control
from one action to the next.
Initial node
An initial node is a control
node that splits a flow into
multiple concurrent flows.
Final node
Denotes the end of a single
control flow.
Flow final node It denotes the end of a single
control flow.
Decision and merge
nodes
It is used either for decision
or merge.
Table 12: Explanation of Activity Diagrams

56
The following diagram are activity diagrams of our system:
1. Activity diagram of Program Meeting
Figure 15: Activity diagram of<< Program Meeting >>

57
2. Activity diagram of Investigate
Figure 16: Activity diagram of<<investigate>>

58
3. Activity diagram of Register Loan Request
Figure 17: Activity diagram of<<Register Loan Request>>

59
4. Activity diagram of Report
Figure 18: Activity diagram of<<Report>>

60
III. CAPTURE OF THE TECHNICAL NEEDS
The technical needs is a specification of the right branch of Y and it is important for the
architecture. This step is necessary when we have sufficient information in the technical needs. We
need to at least know the materials that are going to be used; that is the machines needed, the
network and tools need for the development of the software.
A. Deployment Diagram
A deployment diagram shows the run-time structure/architecture of the system. It shows
the structure of the computer network that will host the software, and how they are mapped to the
software elements. It has the highest level of abstraction. The table below presents and explain the
different notations of a deployment diagram.
Name Diagrammatical
representation
Description
Node A node is either a hardware or
software component
Artifact An artifact is a product of
software development process.
Example: source file, text report
etc.
Association
In this context, an association
represents a communication path
between nodes.
Component It represent a modular part of a
system that encapsulate it content
and whose manifestation is
replaceable within it
environment.

61
1. Deployment Diagram of the Microfinance
Figure 19: Deployment diagram of the microfinance

62
B. Component Diagram
A component diagram shows pieces of software or embedded controllers that will
make up the system. A component diagram has a higher abstraction level compared to a class
or composite structure diagram. This is because it is usually implemented by one or more
classes at runtime and can thus encompass a large portion of the whole system.
Name
Diagrammatic
representation
Description
Component It represent a modular part of a system
that encapsulate it content and whose
manifestation is replaceable within it
environment.
Interfaces An interface is a kind of classifier that
represents a declaration of a set of
coherent public features and
obligations. An interface specifies a
contract; any instance of a classifier
that realizes the interface must fulfil
that contract.
Port A port is a property of a classifier that
specifies a distinct interaction point
between that classifier and its
environment or between the (behavior
of the) classifier and its internal parts.
Figure 20: Explanation of Component Diagrams
1. Component Diagram of <<saving Transaction>>

63
Figure 21: Component Diagram of<<Saving Transaction>>
2. Component Diagram of Microfinance

64
Figure 22: Component diagram of <<Microfinance>>

65
IV. ANALYSIS
A. Categorization and packaging
Cutting down into category constitute the first step in the process of analysis. In
order to do an analysis, we are going to change the organization of the model and consider the
principle of object oriented approach that is encapsulation. So, we are going to move from the
structural function via use cases and packages of use cases via classes and categories.
Notion of Category
A class represents an entity structure very small when we talk of a real project.
When we have more than twelve classes, it is necessary to group into bigger units.
A category consist of logical grouping of classes with very strong internal coherence and very
weak external coupling. The term category does not belong to the standard of UML but in contrary
the term package. We are going to graphically represent categories with stereotype packages.
Note that UML2.0 officially use the term << package diagram>> to represent the diagram
containing only packages.
Packages can be built to represent either logical or physical relationship. When choosing
to include classes to specific packages, it is useful to assign the classes with the same inheritance
hierarchy to packages, classes that are related via composition and classes that collaborate with
also have a strong argument for being included into the same package.

66
1. Categorization into packages
Figure 23: Package "Product"
Figure 24: Package "Complaint Management"

67
Figure 25: Package "Loan Management”
Figure 26: Package "Transaction Management"

68
Figure 27: Package "Microfinance Management"
Figure 28: Package "Profile Management”

69
Figure 29: Package "Meeting Management"
Figure 30: Package "Report"

70
2. Package diagram
Figure 31: Package Diagram

Computerized management of Microfinance institution

Computerized management of Microfinance institution

Recommended

Recommended

More Related Content

What's hot

What's hot (10)

Similar to Computerized management of Microfinance institution

Similar to Computerized management of Microfinance institution (20)

Recently uploaded

Recently uploaded (20)

Computerized management of Microfinance institution