505

SPIDER Research Project Report
MiCOpA:
Micro Credit Operation Automation
Jaana Vyrynen, PhD Candidate Gustav Bostrm, PhD Candidate Rafael Cordones Marcos, MSc., Research Assistant David Stoor, MSc. Candidate Salah Uddin Ahmed, MSc. Candidate Stockholm University/Royal Institute of Technology Sweden
MiCOpA: Micro-Credit Operation Automation
SPIDER Project Report
Page 2 of 141
Acknowledgements
MiCOpA has been carried out in collaboration with Grameen Communications, a software development company which belongs to the family of Grameen Bank enterprises in Bangladesh. Many thanks to Ms. Nazneen Sultana, the Managing Director, and to the development team of Grameen Communications for their collaboration and for providing valuable input into the project. Special thanks to SPIDER (Swedish Programme for ICT in Developing Regions) for providing the funding for the MiCOpA project.
Page 3 of 141
Page 4 of 141
Contents
1 INTRODUCTION............................................................................................................................... 9 1.1 MFIS AND IT.............................................................................................................................. 10 1.2 THE MICOPA PROJECT .............................................................................................................. 11 1.2.1 Scientific and Technological Background to MiCOpA......................................................... 11 1.3 OBJECTIVES AND EXPECTED SIGNIFICANCE OF THE RESEARCH ................................................. 17 2 PROCESS .......................................................................................................................................... 19 2.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.4 2.4.1 2.4.2 2.4.3 2.5 3 DEFINITION OF PROCESS ............................................................................................................ 19 DESCRIPTION OF WORK METHOD AND RESEARCH APPROACH .................................................. 21 ANALYSIS AND EVALUATION OF CURRENT PROCESS ................................................................. 23 Elements of the Current Process at Grameen Communications........................................... 23 Problems with Current Process of Grameen Communications ............................................ 25 Requirements on the Future Process of Grameen Communications .................................... 26 GUIDELINES FOR SOFTWARE PROCESS IMPROVEMENT ............................................................... 27 Two Software Process Approaches....................................................................................... 27 Evaluation of Five Critical Process Factors ........................................................................ 29 The Future Base Process for Grameen Communications..................................................... 36 CONCLUDING COMMENTS ON PROCESS ISSUES FROM A DEVELOPING COUNTRY PERSPECTIVE . 47
ARCHITECTURE............................................................................................................................ 49 3.1 3.1.1 3.2 3.3 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.4.8 3.4.9 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.6 3.6.1 3.6.2 3.6.3 DEFINITION OF ARCHITECTURE .................................................................................................. 49 Quality attributes and architectural analysis ....................................................................... 49 CONSTRAINTS ON A SOFTWARE ARCHITECTURE FOR DEVELOPING COUNTRIES........................... 50 DESCRIPTION OF WORK METHOD AND RESEARCH APPROACH .................................................. 50 GRAMEEN CURRENT SOFTWARE ARCHITECTURE ...................................................................... 51 The environment of the Grameen Banker V3.0 Software...................................................... 51 Grameen Communications Current Problems...................................................................... 51 Software Inspection .............................................................................................................. 52 Software Inspection Results .................................................................................................. 52 Security Architecture Analysis.............................................................................................. 53 Architecture of other Micro-credit software packages ......................................................... 53 Moap..................................................................................................................................... 54 Aquadev ................................................................................................................................ 54 Compiere .............................................................................................................................. 55 GUIDELINES ON ARCHITECTURAL DESIGN ................................................................................. 56 Addressing architectural quality problems with Styles and patterns.................................... 56 Addressing problems through Pragmatic Programming practices ...................................... 57 Addressing Security problems with Security Components.................................................... 59 Architectural guidelines summary........................................................................................ 60 CLIENT ARCHITECTURAL PROTOTYPE........................................................................................ 60 Implementation Technologies............................................................................................... 61 Architecture .......................................................................................................................... 63 UML Domain Model............................................................................................................. 66
THE PDA APPLICATION PROTOTYPE .................................................................................... 67 4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.4.3 4.5 THE LOAN COLLECTION BUSINESS PROCESS ............................................................................... 67 EXPERIENCES FROM OTHER PDA SOLUTIONS ............................................................................. 67 PDA TECHNOLOGY .................................................................................................................... 68 THE PDA DEVICE ....................................................................................................................... 68 Palm Tungsten C and other Palm OS devices ...................................................................... 69 Devices running Microsoft Pocket PC.................................................................................. 69 The Simputer......................................................................................................................... 70 JAVA 2 MICRO EDITION (J2ME)................................................................................................. 70
Page 5 of 141
4.5.1 Background........................................................................................................................... 70 4.5.2 The position of J2ME in the Java 2 family ........................................................................... 71 4.5.3 Configurations ...................................................................................................................... 71 4.5.4 Profiles ................................................................................................................................. 72 4.5.5 Java Virtual Machines for Palm devices .............................................................................. 72 4.5.6 Alternatives to J2ME ............................................................................................................ 72 4.5.7 Creating native applications in C/C++................................................................................ 72 4.5.8 AppForge Crossfire .............................................................................................................. 73 4.6 THE ECLIPSE AND J2ME WIRELESS TOOLKIT DEVELOPMENT TOOLS ......................................... 73 4.6.1 J2ME Wireless Toolkit.......................................................................................................... 73 4.6.2 The Eclipse development environment.................................................................................. 74 4.7 ARCHITECTURE .......................................................................................................................... 74 4.7.1 The classes of the MiCOpA MIDlet ...................................................................................... 75 4.7.2 The MiCOpA class................................................................................................................ 75 4.7.3 The LinkedList class ............................................................................................................. 76 4.7.4 The ListNode class................................................................................................................ 76 4.7.5 The LinkedListItr class ......................................................................................................... 76 4.7.6 The Sync class....................................................................................................................... 76 4.7.7 Classes representing the business data ................................................................................ 76 4.7.8 The Branch class .................................................................................................................. 77 4.7.9 The Center class ................................................................................................................... 77 4.7.10 The Group class ............................................................................................................... 77 4.7.11 The Loanee class.............................................................................................................. 77 4.8 OBJECT-ORIENTED STRUCTURE .................................................................................................. 78 4.8.1 The relationships between the business data ........................................................................ 78 4.8.2 The object model................................................................................................................... 80 4.8.3 UML class diagram of the PDA application prototype ........................................................ 81 4.9 SYNCHRONIZATION AND PERSISTENT STORAGE.......................................................................... 81 4.9.1 Serialization.......................................................................................................................... 82 4.9.2 Regenerating objects from serialized data ........................................................................... 83 4.9.3 Synchronization .................................................................................................................... 83 4.9.4 Persistent storage ................................................................................................................. 84 4.9.5 Other solutions to synchronization and persistent storage................................................... 84 4.9.6 The db4o object oriented database system ........................................................................... 85 4.9.7 Nextels RMS toolkit ............................................................................................................. 85 4.9.8 Sync4j ................................................................................................................................... 85 4.9.9 J2ME and the Palm HotSync technology.............................................................................. 85 4.10 PDA SECURITY .......................................................................................................................... 86 4.11 HUMAN COMPUTER INTERACTION (HCI) ASPECTS ..................................................................... 86 5 TECHNOLOGY ............................................................................................................................... 88 5.1 5.2 5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.4.5 5.4.6 5.4.7 5.4.8 5.4.9 DEFINITION OF TECHNOLOGY .................................................................................................... 88 ANALYSIS AND EVALUATION OF CURRENT TECHNOLOGY ......................................................... 88 ANALYSIS OF THE CURRENT GBANKER 3.0................................................................................ 88 Main Functionalities............................................................................................................. 89 Database Analysis ................................................................................................................ 90 Problems/Limitations in the GBanker3.0 ............................................................................. 91 Modifiability requirements ................................................................................................... 91 ALTERNATIVES TO MS ACCESS DATABASE ............................................................................... 93 Multiple User Access ............................................................................................................ 94 Management of Large database ........................................................................................... 94 Security ................................................................................................................................. 94 Cost....................................................................................................................................... 94 Hardware choices................................................................................................................. 94 Audit Trails........................................................................................................................... 94 Audit Logs............................................................................................................................. 95 Logs of SQL Transactions .................................................................................................... 95 Database Access Control...................................................................................................... 95
Page 6 of 141
5.4.10 5.4.11 5.4.12 5.4.13 6
Password Protection........................................................................................................ 96 Encryption between Client and Server............................................................................. 96 Encryption of data directory............................................................................................ 96 Protection of Audit Logs from Manipulation ................................................................... 96
KNOWLEDGE TRANSFER ACTIVITIES................................................................................... 97
7 A MICOPA SOFTWARE NETWORK -- BRIDGING THE DIGITAL DIVIDE WITH PURPOSEFUL OPEN-SOURCE SOFTWARE...................................................................................... 98 7.1 7.2 8 9 PARTNERING WITH UNIVERSITIES ............................................................................................... 98 CREATING AN ONLINE MFI MIS-SOFTWARE COMMUNITY ......................................................... 99
RELATED WORK ......................................................................................................................... 100 CONCLUSION ............................................................................................................................... 103
REFERENCES ......................................................................................................................................... 105 APPENDIX A APPENDIX B APPENDIX C APPENDIX D ANALYSIS OF GRAMEEN BANKER 3.0 .......................................................... 113 SOFTWARE PROCESS IMPROVEMENT ........................................................ 134 PLAN OF WORK ................................................................................................... 136 SCREENSHOTS AND THE PAPER PROTOTYPE .......................................... 140
Page 7 of 141
Page 8 of 141
1 Introduction
Poverty lending has grown to become a global movement during the past three decades. The movement was initiated by a few volunteering individuals, who sought for alternative ways of extending banking services to the rural poor, i.e. the majority of whom are deprived of the services of conventional banking. The effort has led to the development of micro credit, a sophisticated loan methodology targeting poor and underprivileged people. Micro credit is almost reverse to conventional banking methods. Instead of building financial services around the principle of assessing the material possession of individuals, micro credit builds on the principle of assessing the potential of individuals [Yunus, 2004]. Conventional banking is based on collateral, while micro credit is free of collateral. This is possible because micro credit is based on repayment incentive structures, e.g. peer group lending, wherein a group of borrowers guarantee each others' loans and the promise of continuing, increasing credit for borrowers paying on time [GDRC, 2004]. Although many successful micro credit organisations exist in the world today, they have reached a critical stage and are facing many challenges. To deal with an increasing amount of customers, competitors and regulatory constraints, the sector must become more professional. Reliability and efficiency are key factors. Information Technology (IT) provides an essential tool to deal with the increasing mass of information these structures receive but also to meet regulatory requirements to comply with local legislation [IICD, 2004]. However, from a developing country perspective, information technology is not always an obvious solution. Information technology is the same in developed and developing countries and regions, but the environment in which it is deployed in developing countries makes it unique in terms of the challenges in the process of acquisition, development, deployment and maintenance. Firstly, existing software and information technology is expensive. Investments in these regions of the world are still limited. Secondly, in the cases where there have been investments in IT, it has been introduced and developed only to help in solving the most immediate problems and focused only to serve the current operational needs. This has resulted in software that lacks flexibility in terms of customization and modification. The lack of flexibility has caused severe difficulties in meeting new needs and requirements as the micro credit organisations evolve and change and which require the software to adapt and behave accordingly. Thirdly, the relative lack of skills, knowledge, experience and support in developing countries pose problems in all phases of the IT life cycle. [IICD, 2004] The establishment of an accessible and sustainable information and communication infrastructure targeting the rural and poor areas around the globe strongly depends in the future on the ability to concretise massively the special needs in these areas. This implies a particular challenge of finding appropriate IT solutions and also appropriate ways to develop and deploy the IT solutions.
Page 9 of 141
1.1 MFIs and IT

A microfinance institution (MFI) is an organization that provides financial services, i.e. micro credit, targeted to the poor [CGAP, 2005]. As indicated in the introduction, the sustainability of MFIs depends largely on their ability to increase their productivity. Adequate training of staff and management is crucial, but there is also a need to improve the information system to support the management of micro credit operations. IT provides valuable support by making it possible to automate work that is done manually. Manual work generally consumes huge resources and in the case of MFIs, it is prone to many errors due to the enormous amounts of information and paper documents that must be managed. Good information is essential for the institution to perform in an efficient and effective manner and the better the information, the better the institution can manage its resources [CGAP, 2005]. In a competitive environment, the institution with better information is also at advantage by being able to carry out its services faster and with higher quality. IT investments are costly, but in a longer perspective it provides a much more viable basis for achieving efficiency and effectiveness that will lower operational costs, which in turn will have a positive impact on the whole structure. By improving the performance will bring value, not only to the own organisation, but also to the billions of people living in poverty around the world. With better performance the ability to effectively and efficiently reach out to these people is enhanced. For poor people, lower operational costs can also have an impact on the high interest rates of MFIs. In this respect, Management Information Systems (MIS) are critical to the long-term successful operation of any micro finance institution. However, a study on the performance of African MFIs proves that very few MFIs are using an efficient MIS [IICD, 2004]. The study shows that among three hundred studied MFIs, only forty are using adequate MIS. A main reason to this problem is that many MFIs are struggling with understanding the fundamental concepts of MIS, but also with recognising of the importance of MIS for their successful functioning [Indian NGOs, 2005]. Problems arise with the difficulties of identifying information needs, the poor communication between management and developers and unrealistic expectations from information technology [CGAP, 2005]. Therefore, very few MFIs have been able to develop effective systems. To be able to effectively and efficiently reach out to the billions of people that live in poverty, largely depends on the sustainability of MFIs and their ability to increase their productivity. In this respect, the presented facts point at two major needs of the MFIs. Firstly, technology that supports the operation of micro credit activities have to emerge to help solve the organizational performance difficulties - largely due to the lack of specially adapted technology - encountered. Secondly, to develop effective IT systems the problems of software development must be addressed with respect to the relative lack of resources, knowledge and skills in these regions of the world.
Page 10 of 141
1.2 The MiCOpA Project

The idea behind the creation of the MiCOpA project is to support the emerging structures of micro credit organisations. The aim is to strengthen the viability of these structures by investigating the automation of the micro credit operation at one of the worlds most successful micro credit organisations, Grameen Bank in Bangladesh. The MiCOpA project has provided a first attempt at such an investigation based on a case study of an existing micro credit system. The system has been analysed and evaluated on the basis of three thematic components that build a solid, comprehensive understanding of the system including the development of the system. The three thematic components are those of Process Architecture Technology The MiCOpA project has extracted value from the analysis of these thematic components and developed a knowledge base on the appropriate ways IT can be developed in future micro credit operations for the well being of billions of poor people in the world, but also in an effort to give any interested stakeholders the opportunity to learn from the experiences of this project.
1.2.1 Scientific and Technological Background to MiCOpA

Based on the organizational performance problems, the technological difficulties and the major technological needs of MFIs identified, the main objective of MiCOpA was to investigate the automation of the micro credit activity, based on the case of Grameen Bank, and to make recommendations on future software and system development. This involved an investigation of the advantages and disadvantages of various software processes, architectures and technologies for the development of micro credit systems, and an analysis of the feasibility of introducing new and innovative technologies in the particular development and application domain of micro credit operations and by taking into account the challenges of the third world. This has been carried out in an effort to provide a foundation for bridging the digital divide and to provide a foundation for the developing countries to take control of their own software development as a means to their empowerment. The foundation should support every different fashion of micro credit operation to increase the service level to the poor and strengthen every organisation that uses micro credit systems as tool to alleviate poverty in the world.
Page 11 of 141
The purpose of the work was to analyse and evaluate the three thematic components based on a case study of Grameen Communications, a software development company which belongs to the family of Grameen Bank enterprises in Bangladesh, to arrive at a better understanding of appropriate solutions for the development of a sustainable micro credit system. The objectives can be summarized in the following five points; 1. To establish an exhaustive understanding of the current software process, architecture and technology in terms of strengths and weaknesses 2. To investigate and understand the advantages and disadvantages of various software processes, architectures and technologies for the development of micro credit systems 3. To analyse the feasibility of introducing new innovative solutions for process, architecture and technology, respectively, in this particular development and application domain 4. To arrive at a specification of a recommended development process, architecture and technology based on the results of the preceding analysis and feasibility study 5. To develop a prototype for a new generation micro credit operation system, including a PDA solution, based on the guidelines put forward (as a proof of concept). Below, follows a description of the work plan and the research approach, including a description of the case study. The Case Study - Grameen Bank and Grameen Communications To make recommendations on future micro credit system development, including the development of a prototype of new generation micro credit software, require understanding of the domain and the system, i.e. what the system does, and where and when it is used. The MiCOpA project involved an investigation of the automation of the micro credit activity of various MFIs around the globe with a primary focus on the case of Grameen Bank. The work was organized according to a work plan consisting of four work packages (a detailed description of the work plan can be found in Appendix C). However, to understand what recommendations to specify and how the prototype could support the needs of MFIs, required that business and systems analysis was carried out [Dennis et al., 2002]. There exist many different ways for structuring business and systems analysis. In the MiCOpA project, a traditional systems development lifecycle approach was applied where the data gathered from the case study was transformed into graphical models [Dennis et al., 2002]. Therefore, defining the Grameen Bank Enterprise Architecture was taken as a starting point in the analysis. The Enterprise Architecture can be described as a "simple, logical structure of descriptive representations for identifying models that are the basis for designing the enterprise and for building the enterprise's systems" [Zachman, 1987].
Page 12 of 141
In Figure 1.1, the Enterprise Architecture of Grameen Bank is depicted. It captures the whole organisation in a graphical model that corresponds to an Enterprise Architecture, including its internal elements and their relations. The model visualises the elements of organisational vision, goals and strategies; IT vision, goals and requirements; organisational operation including products, business processes, organisational structure and roles, customers, and organisational information; applications and data storage; IT architecture; IT infrastructure, including development technology, hardware platforms and software; IT products and resources.
Figure 1.1. Enterprise Architecture of Grameen Bank.
The Enterprise Architecture model, in combination with other data gathered during the project provided the basis for understanding the system and how it would support the organisation, which included identifying who will use the system, what the system will do, and where and when it will be used. In addition to specifying the Enterprise Architecture, the existing MIS was investigated, improvement opportunities were identified and a prototype, including a PDA prototype, was also developed as a proposal of new generation micro credit software. The results will be presented in detail in the following chapters, which are structured according to the three perspectives focused on,
Page 13 of 141
i.e. the process, the architecture and the technology. Below, follows background information of the case study organisation which also refers to selected parts of the Enterprise Architecture that corresponds to the issues primarily focused on in the MiCOpA project. Grameen Bank Grameen Bank is an MFI that invented and applied the micro credit banking system in 1983 in Bangladesh as an effort to strengthen the poor and to help them overcome miserable poverty. The mechanism proved to be very effective in alleviating poverty and has also been adopted by both government and non-government organisations across the globe. [Grameen, 2004] In Figure 1.2 below, the organisational structure of Grameen Bank is depicted as an enlargement from the Enterprise Architecture model shown in Figure 1.1. This model describes the structure and the different levels of the organization and the roles associated with each level. There are eight hierarchical levels. The Head Office governs the whole organization and is managed by the Managing Director. There are eighteen Zonal Offices, hundred twenty-seven Area Offices and more than thirteen hundred Branches dispersed throughout Bangladesh. Each has a responsible office manager who is responsible for reporting to the level above in the organizational hierarchy. The Centers consist of groups of members, i.e. the micro credit clients. The Centers are central to the organisation because this is where the core micro credit operations are carried out in the villages. The Data Management Centers are responsible for entering the information, collected in paper form from Center and Branch operations, into the MIS. They are colocated with the Area Offices.
Figure 1.2. The Grameen Bank organistional structure, the levels and the associated roles.
In Figure 1.3, a static view of the Grameen Bank main business processes, their subprocesses and their relations are illustrated. This is an enlarged model of the business Page 14 of 141
process element from the Enterprise Architecture model shown in Figure 1.1. These correspond to processes primarily related to micro credit operations. Although not clear in this example, the business processes modeled also indicates processes in the various levels of the organization, running from Head Office to Centers. Furthermore, the principal reports of Loan/Saving reports and Updated Loan Collection sheets are also indicated in the model as input or output from the business processes of Local Micro Credit as related to Administration business processes. Note that the process Data Management of micro credits takes place under Area Office Operation. Apart from finance and accounting processes, this is where the existing IT, i.e. the MIS, supports the micro credit activities. For the reminder, this points out the IT solution focused on in the MiCOpA project.
Figure 1.3. Micro credit related business processes and the generated reports of Grameen Bank.
Grameen Communications Being a Grameen Bank family member with a Not-for-Profit organisational approach, Grameen Communications was assigned to automate the whole micro credit activity of Grameen Bank. The objectives of the automation initiative were to: Increase the service level to the poor Reduce service cost and time Implement IT to serve the poor Create IT awareness and IT related jobs Decrease the workload of the Grameen Bank employees Hold strong, easy and centralised monitoring on micro credit operation Today Grameen Communications is serving, with the MIS, the micro credit activity of 1184 Grameen Bank Branches throughout the country, hence, approximately 4 million members (96 % of whom are women). The MIS includes Software, Hardware Infrastructure, Trained Operator and Implementation Service. To develop and implement
Page 15 of 141
such an enormous MIS, Grameen Communications has closely been working with Grameen Bank since 1997. There exist four versions of the MIS Grameen Banker, which supports the management of micro credit information gathered from field and branch operations, e.g. loan collection information. The application is used at the Data Management Centers for entering data collected from the micro credit activities in the field. The Data Management Centers are located at each of the Area Offices (127 Area Offices in total). The current version running in the majority of the Data Management Centers is Grameen Banker 3.0 although a conversion to Grameen Banker 4.0 is undergoing. A more detailed description of Grameen Banker is given in Appendix A. Considering the operational needs, available techniques and technology, the following has been applied in the development of the MIS: Front-end tool : Visual Basic 5.0 Back-end tool : Microsoft Access 97 Reporting tool : Crystal Report 4.0 Operating System : Microsoft Windows 98 In Figure 1.4, the existing applications and the development technology used are visualized in an enlargement from the original Enterprise Architecture model. Although, the application GB Accounts, an accounting MIS, is included in the model this application is out of the scope in the MiCOpA project, because the project has primarily focused on technology solutions for the core micro credit activities and has not involved supporting applications.
Figure 1.4. The existing MIS applications and the development technology used.
Page 16 of 141
In Figure 1.5 below, an enlargement of the elements of applications, the application types, applications functions, the databases and the development technology used, the hardware platform and the relation between IT, i.e. the MIS, and business processes is depicted. This model indicates how the existing IT supports the business process of Data Management at the Area Office level and the Accounting process, respectively.
Figure 1.5. Business processes supported by IT.
In summary, this has provided a brief overview of the case study of Grameen Bank and Grameen Communications to give the reader background information about the project that will be useful in the following chapters, where details and project results will be presented from the three perspectives of process, architecture and technology. This overview is based on a selection of the most central aspects of the organization and supporting IT with regard to the focus of the MiCOpA project, i.e. the elements of the organizational structure, the main business processes, the applications and the technology supporting the core micro credit activity at Grameen Bank.
1.3 Objectives and Expected Significance of the Research

The MiCOpA project aimed at two things, to further uncover some of the challenges of software development in developing countries, i.e. the project aimed at providing better understanding of what factors in the developing countries affect the use of certain techniques and technology, and what factors can potentially change these circumstances
Page 17 of 141
support software sustainability for MFIs by the use of new software engineering and technology trends in a developing country context. The Open Source Model, in contrast to proprietary software, opens up new opportunities for bridging the digital divide, thus promoting the local development of software which also can solve the problem of financial constraints and dependency of western market trends. PDAs also provide MFIs a technological opportunity to improve their operational performance, which is critical for the long-term successful operation of any MFI. Furthermore, considering the resource constraints, developing countries should also strive for sustainable software development. A key to solve this is to provide these countries the tools that support development, where the development process is central. Agile software processes provide a unique opportunity to address these constraints and in helping software teams to achieve sustainable software development.
MiCOpA has also provided important research in an effort to further validate what has been discovered in previous projects on the automation of micro credit operations, for example in open source projects such as Aquadev [IICD, 2004] and MOAP [MOAP, 2005] and in projects involving PDA solutions for MFIs [CGAP, 2005]. Furthermore, MiCOpA has provided elaboration from a Bangladeshi perspective to couple with efforts made in these areas in other parts of the world. Apart from this, the MiCOpA project has pioneered the introduction of agile software development processes in the context of developing countries, which has not been done in any previous studies. Another important aspect is that this project has provided a strict software engineering perspective on the evaluation of MIS for micro credit operations, based on three thematic components of Process, Architecture and Technology. The knowledge gained has been used in the development and demonstration of a prototype for sustainable MIS and PDA solution for micro credit operations in the third world. Furthermore, research in the automation of micro credit operations is weakly structured. Some projects exist, but there are very few projects found that have made efforts towards academic research. Consequently, MiCOpA has enabled the formation and dissemination of this knowledge and competence in the academic field. It should also be noted that a UN resolution proclaims the year 2005 as the International Year of Micro credit, and has requested that the observance of the year 2005 to be a special occasion for giving impetus to micro credit programmes throughout the world [UN, 2004]. The MiCOpA project has contributed to the International Year of Micro Credit by highlighting to the role of sustainable software development for micro credit operations and its impact on the lives of people living in poverty.
Page 18 of 141
2 Process
The construction of software is a difficult undertaking. The failure or cancellation rate of software projects around the globe is still alarming, although in later years there is a trend towards improved software results. To be efficient, effective, productive and successful, software development teams need to be equipped with appropriate support. This can be achieved by introducing a software process, which facilitates the development of software. The MiCOpA project aims at uncovering some of the challenges of software development in developing countries, and as issues concerning software processes are tightly interconnected to software development this is also subject to investigation in this project. In this chapter, we report on the observations gathered from the case study of Grameen Communications. The observations show several software process improvement opportunities. For example, providing a definition of software process provides a good starting point to better understand the work actually undertaken; there exist no complete software process so initiating the building up a software process is already an improvement; process monitoring can be enhanced both for developers and management. However, introducing a software process in a company also requires ways to deal with organisational, cultural, technical and resource issues. For example, in this case study, the stakeholders showed large differences in technical and business awareness and organisational maturity, which have had a great impact on the choice of process.. The purpose of this chapter is to report on the observations, the problems identified, the results of the analysis carried out in the MiCOpA project and to present recommendations on software process improvement. The aim of the MiCOpA report is not only to provide Grameen Communications with recommendations on their future software development process, but also to provide any MFI or micro credit software developing organization an opportunity to learn from the experiences of the MiCOpA project to facilitate the development of future micro-credit software. The chapter is structured in four major parts: (a) a definition of software development process (b) the observations gathered from the case study of Grameen Communications, (c) general guidelines on how to evaluate and improve a software development process based on the case study, and (d) as a proof of concept, guidelines on a base process for Grameen Communications.
2.1 Definition of Process

In the MiCOpA project, the definition of process refers to Cockburns [2002] definition of methodology1. This definition has several advantages. For example, it has proved a good starting point for facilitating the communication between project stakeholders. It has helped in focusing the analysis on the particular elements a process generally consists of, such as activities, roles and products, and in recognising these elements in the analysis of the process of Grameen Communications. Moreover, the definition has facilitated the structuring of the data collected and also the structuring of results of the analysis. Figure
1 To avoid unnecessary misunderstandings, the term process has been used consistently throughout this project, which is also applied in this report.
Page 19 of 141
2.1 below, illustrates Cockburns [2002] definition of methodology, its elements and their relations.
Team Value
Process
Milestone
Quality
Activity
Team
Product
Technique
Role
Personality
Standard
Tool
Skill
Figure 2.1. Cockburns [2002] definition of methodology, its elements and their relations.
The definitions of each element and their relations to other elements are; Role: A person who is part of the team, who is involved with one or several activities and who beholds the skills and the personal traits needed to carry out the activities. The personal traits needed attributed a particular role to carry out the activities. The skills required for the role, e.g. education or talent in particular techniques or tools. The group of roles that work together to carry out activities. The specific procedure for how to accomplish an activity. The means, tools or equipment used to support particular techniques, requiring particular skills and which are described in some tool standard. The task or tasks to be carried out by the team or by individual roles to produce the product. A particular course of action intended to achieve a result or milestone, i.e. how activities fit together, often with a start and end condition, implying an orderly logical arrangement. An output or deliverable, i.e. what is produced with particular techniques in one or a set of activities and described in a particular product standard.
Personality: Skill: Team: Technique: Tool: Activity: Process:
Product:
Page 20 of 141
Milestone:
A time-related performance indicator marking work progress or completion, i.e. marking whether milestones are met or not met at a particular point of time. The conventions adopted for tools, products or techniques. The criteria used in assessments and evaluations of the products or the activities. Quality can be of both quantitative and qualitative nature. The underlying philosophy of the team.
Standards: Quality: Team value:
2.2 Description of Work Method and Research Approach

The purpose of the work has been, based on the case study of Grameen Communications, to analyse and to evaluate the development process to arrive at a better understanding of the current process and way of working, but primarily to identify problems particularly challenging software development from a developing country perspective and to provide recommendations on how to achieve sustainable development of micro credit systems. The objectives can be summarised in the following four points; 1. To establish an exhaustive understanding of the current software process at Grameen Communications, in terms of strengths and weaknesses 2. To investigate and understand the advantages and disadvantages of various alternative software processes for improving the development of micro credit systems based on the case study of Grameen Communications 3. To analyse the feasibility of introducing new innovative process solutions in this development and application domain 4. To arrive at a specification of a recommended development process, based on the results of the preceding analysis and feasibility study In order to achieve these goals, a comprehensive research method must be selected [Karlstrm, 2003]. A qualitative approach based on group discussions was used to gain in-depth understanding about the current process and the requirements on a future process. The following was done: According to the first goal, to gain understanding of the current software process at Grameen Communications, in terms of strengths and weaknesses, data was mainly collected during focus group discussions [McNamara, 2005]. Three workshops with the development team were organized. The first workshop involved collecting data about the current software process and way of working. The aim of the workshop was to gain understanding about the existing software development process at Grameen Communications, to identify the different phases and activities of the process, to identify the organisational structure of the team Page 21 of 141
including roles and responsibilities, and to identify any support tools and standards used. The discussion was guided by a set of pre-defined criteria to cover the concept of process. That is, in order to identify the issues previously mentioned, Cockburns [2002] definition of process, its thirteen elements and their relations, was used as a starting point. This definition was also complemented with a set of pre-defined questions to collect data about the current process and to cover aspects on the way of working, which the group had to respond to based on their perception of the current situation. (Appendix B) The second workshop focused on identifying the strengths and weaknesses of the current process, which was based on the definition resulting from the preceding workshop. The aim of this workshop was, particularly, to identify the problems of the current development process. To focus the discussion on process weaknesses, and to identify lackings and problems, a set of pre-defined questions was defined to guide the discussion during the workshop. The workshop was also concluded with a ranking of the problems according to a set of pre-defined criteria, i.e. project success factors as defined by the Standish Group CHAOS report [CHAOS, 2005]. (Appendix B) The third workshop involved a specification of requirements on a future process. The aim was to get the group of developers to propose an initial base process for Grameen Communication and to look for ways to streamline the process and ways to communicate with less cost based on a workshop technique called On-the-fly methodology construction by Cockburn [2002], which included the specification of the following process elements: workflow, people, roles and responsibilities standards, tools support extent of documentation needed, level of correctness expected from the software length of increments (the time period until running code is delivered to client, even sample/prototype)
Moreover, the aim of the third workshop also included a discussion on Rainer et als [2003] software process change motivators, i.e. to investigate what would motivate the team to change the current way of working by asking the developers to answer the following questions: What are the potential motivators to software process improvement in your company? What will make it [i.e. software process improvement] happen?
In addition to the workshops, data was collected through informal interviews with developers.
Page 22 of 141
Based on the data gathered from the three workshops it was possible to investigate and understand the advantages and disadvantages of various alternative software processes for improving the development of micro credit systems at Grameen Communications, which is the second goal. The third and forth goal mentioned above, could also be realised based on an analysis of this data. The analysis concerning these aspects were also carried out while applying well recognised software improvement techniques, which are described in Section 2.4.
2.3 Analysis and Evaluation of Current Process

In this section a summary of the results of the three workshops, respectively, is presented. Firstly, a summary of the identified current process is presented. Secondly, the results of the problems identified are summarised. Thirdly, a summary of the requirements on a future process specified by the development team is presented.
2.3.1 Elements of the Current Process at Grameen Communications

Figure 2.2 below, illustrates the existing software development process at Grameen Communications, its elements and their relationships as described by the development team during workshops and in interviews. In the figure, it is also indicated what each element involves as described by he development team. Note that, when compared to the original definition of process, there are elements missing, i.e. the elements of milestone, technique and tool. Nor are any of the identified and currently present elements fully comprehensive, but only partially defined. This will be described in detail below. If following Cockburns [2002] definition, this indicates a weakly defined process with clear gaps.
Hardworking, focused and competent staff As long as the client it satisfied, then we know that we have done a good job and that is enough.
Correct and accurate communication, information and collaboration
Team Value
Smooth, flexible system with few errors! Quality Source code Functional Tests Training material User Manual Installer CD
Process Analysis Coding Testing Meeting
5 step waterfall
1-5 Persons Activity Team
Product
Business Executive Project Leader Developer
Role
Personality
Standard
Skill Electrical Engineer Zoologist/Programmer
SQL VB
Code Comment: Change+Name + Date
Figure 2.2. Existing software development process at Grameen Communications.
Page 23 of 141
Partially described elements Below, follows a description of each of the identified elements in the Grameen Communications process as defined by the developers. Role: There are three project roles defined. The business executive is responsible for clients, sales and for business issues concerning the software to be developed. The project leader is responsible for setting up the project, for leading the project and for assisting the business executive with technical issues. The developer is responsible for programming and for developing the software. Seniority rules, i.e. the person with the most experience is designated the senior role. The skill required for a role is based on university education. Everyone on the current team beholds at a minimum a Bachelor degree in Electrical Engineering (from different Bangladeshi universities). The entire software development unit currently consists of 5 persons. However, the size of individual project teams varies between 1-5 developers, where one person is designated the role of project leader. Most commonly a project team consist of 2 full-time persons. The process is based on a traditional waterfall approach, involving a sequence of five phases, each phase including a set of activities or tasks to be carried out. The five phases are Analysis, System Development, Testing and Debugging, Training and Installation and Implementation. The activities are defined as individual tasks within a phase of the process and follows in sequential order as described below: Analysis phase: consult client; collect report templates; analyse existing system; understand requirements System development: database development (physical); report design; User Interface design and coding Testing: functional testing; debugging Training: write system user-manual, prepare training material (demidata); train end-user Installation and Implementation: make installer CD; install the software properly at the clients Product: The output produced in each phase of the process. No supporting tools or techniques are used.
Personality: Skill:
Team:
Process:
Activity:
Page 24 of 141
Analysis phase: verbal requirement specification (frozen) System development: database, source code Testing: error-free software Training: system user-manual, trained operator Installation and Implementation: installer CD; installed software at the clients Quality: No criteria are defined for assessments and evaluations of neither the products nor the activities. However, one general quality that is expressed qualitatively and subjectively by the developers as: Smooth, flexible system with few errors! The team values can be viewed from two main perspectives, i.e. from an organisational and a product perspective. The team values teamwork, strong leadership and good quality products, as indicated in the citations indicated in the figure, which are cited from interviews with the developers. The conventions and standards adopted for tools and products do only exist partially, i.e. the language standard used throughout current projects includes SQL and VB. The team also uses a common convention for commenting the code when changes are made, Change + Developer Name + Date.
Team value:
Standards:
Missing elements Technique: Tool: Milestone: There exist no techniques specifying how to accomplish an activity. No tools, equipment or other means of support can be identified. Planning is made on an ad hoc basis. No milestones are defined. (The team does not apply structured planning and does not have resources set aside for this.)
2.3.2 Problems with Current Process of Grameen Communications

The output of the process problem workshop resulted in a few key areas that were listed as most problematic by the developers at Grameen Communications. These are summarized below: Complete lack of project planning and project management
Page 25 of 141
Complete lack of structure in process, in particular in the phases of analysis, design and testing. Complete lack of tools, techniques, standards or other means to support software development Complete lack of organisational structure, clear definition of roles and responsibilities Lack of balanced power between developers and management
Consequently, the main focus of the process improvement work will lie within these areas. A more detailed discussion on these problems will follow in Section 2.4 in this chapter.
2.3.3 Requirements on Communications
the
Future
Process
of
Grameen
In the third workshop, the aim was to follow-up the discussion on the problems identified in the second workshop and to specify the requirements on a future process together with the developers. The developers also had to prioritise which requirements were most important.
Team Value
Process
Milestone
Quality
Activity
Team
Product
Technique
Role
Personality
Standard
Tool
Skill
Figure 2.3. Developers requirements on future process.
Figure 2.3 above illustrates which elements of a process, as defined by Cockburn [2002], that are most impacted by the requirements stated and prioritised by the software development team at Grameen Communications. The prioritised process elements are highlighted with bold rectangles. In general, the developers express requirements on two levels for an improved software development process, i.e. the requirements on the: a) organisational level b) engineering level
Page 26 of 141
From an organisational point of view the developers require a more structured way of working, including good planning and project management, clear organisation structure, well-defined roles and responsibilities, more resources in terms of time and personnel, developer empowerment, and improved formal procedures and leadership. On the engineering level, the prioritised requirements concern an improved specification of activities and the introduction of techniques and supporting tools to overcome the current performance difficulties. Moreover, to be able to benefit from the introduction of any supporting techniques or tools it is clear that training is a base requirement to improve the teams and the individuals skills. In the following sections, the results of an software process improvement effort is presented, including a brief overview of exiting process approaches in general; the results of a top-down evaluation of the current process and identified problems according to Demings [1982] software process improvement cycle where Boehms and Turners [2004] five critical evaluation criteria and process risk management approach has been applied; and guidelines on a future base process.
2.4 Guidelines for Software Process Improvement

To arrive at a specification of a recommended development process, it is necessary to evaluate the current process, the identified problems and the requirements gathered from a more objective perspective to understand the feasibility of introducing any kind of software process. In the two following sections, an overview of software development processes in general and a presentation of the approach to software process improvement that has been used in this project will be presented.
2.4.1 Two Software Process Approaches

There are generally two main approaches to software development, the plan-driven and the agile. Plan-driven processes, such as US Department of Defense military standards (e.g. DoD-STD-2167), general process standards (e.g. ISO 12207/15504) and the Personal Software Process (PSP) [Humphrey, 1995], are generally considered the traditional way to develop software. Plan-driven processes values well-defined work products and are based on a wellstructured, systematic and repeatable engineering approach. Documentation is important through every step of the process as a means to allow traceability across requirements, design and code. Plan-driven processes are sometimes referred to as heavyweight processes as they include specifications of detailed plans, activities, workflows, roles and responsibilities and product descriptions. The major advantage of plan-driven processes is in the repeatability that standardization brings [Boehm & Turner, 2004]. By the specific descriptions of plans, activities and products any project stakeholder will also know where to look for information. On the other hand, there is a risk with the predictability generally required by plan-driven processes. Plan-driven processes are most successful in stable development environments, where requirements do not change. In Page 27 of 141
todays rapidly changing business world this does not generally apply. Moreover, software teams caught in heavy processes run the risk of becoming documentation generators instead of software developers, putting the focus of production on the wrong things. For a plan-driven process to succeed, it requires management support, a welldefined organizational structure and infrastructure, and an environment where people understand the importance of common process and who also have good knowledge and training in the plan-driven process [Boehm & Turner, 2004]. Agile processes have been proposed to overcome the problems experienced with traditional, heavyweight software development processes. There are a number of existing agile software development processes, where the most known processes are eXtreme Programming (XP) [Beck, 2002] [Beck, 2004], Adaptive Software Development (ASD) [Highsmith, 2002], Scrum [Schwaber & Beedle, 2001], Crystal [Cockburn, 2002] and Dynamic Systems Development Method (DSDM) [Stapleton, 1997]. Because XP is the agile process that is most widely used [Charette, 2004], we have chosen to present it more in detail as a representative of the agile processes. XP is based on a pragmatic approach, and the fundamental idea is to simplify the development of software. However, simplifying the development of software is not to be compared with a simple method. On the contrary, to get the full benefits of XP is a demanding challenge for the project team. The cornerstones of XP are a set of tightly interconnected practices, principles and values. These depend on each other to form a whole that is greater than its parts. The individual XP practices will not be presented in detail, but we refer to Beck [2002] [2004] and Jeffries et al. [2001] when any specific XP concepts are used in this report. However, in brief, XP emphasises customer involvement and promotes teamwork, which is realised through the value of constant communication with the customer and within the team. Design is simple. YAGNI (You Arent Going to Need It) [Beck, 2002], a philosophy of XP, symbolises the idea of simplicity as it emphasises working only on known requirements and to implement only what you actually need in the present situation. The reason is to avoid over-designing a system in a vain attempt to anticipate future requirement changes [Rasmussen, 2003]. XP emphasises rapid feedback through mechanisms, such as short iterations and continuous testing of the system. Frequent deliveries are also important to enable the customer to directly evaluate and approve the results, before releasing the system [XP, 2004]. XP is most effective in the context of small teams, small to middle-sized projects and chaotic development environments with changing requirements [Paulk, 2001] Effectiveness is accomplished by structuring the software development process into short iterations, where an iteration focuses on timely delivery of working code and other artifacts that provide value to the customer. Previous observations suggest that XP would be a potential process alternative for the development team at Grameen Communications. However, the key to finding an appropriate process is, according to Boehm and Turner [2004], the evaluation of five critical factors personnel, criticality, size, culture and dynamism. This evaluation has also been considered necessary for the evaluation of the process aspects in MiCOpA. In section, 2.4.2, this will be discussed more in detail.
Page 28 of 141
Best practice Iterative development Although plan-driven and agile processes represent two very different approaches to software development, there are some practices that are considered best practices in both fields. In particular, it is generally argued that an iterative approach to software development is preferred over a waterfall approach. Traditionally, software development has been based on the waterfall approach, i.e. structured development that moves sequentially from one step or phase to the next [Dennis et al., 2002]. Once the work of one phase is approved by a project authority, the phase ends and the next one begins. However, the growing need to develop information systems more quickly in the competitive business environment of today and the need to more quickly adopt changes in requirements, have resulted in a demand for software development approaches that respond rapidly to changes during development. It is not possible to follow a traditional approach and sequentially first define the problem, design the entire solution, build the software and then save all testing to the end [RUP, 2005]. Modern development approaches therefore emphasise iterative and incremental development that undergoes continuous testing and refinement throughout the life of the project. Iterative development means that each iteration is a movement from one version of the software to the next version of it. The waterfall approach is, on the contrary, one monumental release with only one version of the product. In other words, an iterative lifecycle assumes increments, i.e. an improved or extended version of the software at the end of each iteration. It also assumes short iterations between increments, i.e. in weeks or even days rather than months or years as assumed in the waterfall lifecycle. Because each iteration is short and ends with an executable release, allows for quicker feed-back and help in ensuring that the project stays on track [RUP, 2005].
2.4.2 Evaluation of Five Critical Process Factors

To understand the basis of the recommendations on the process, the position of the process of Grameen Communications must be clarified with regard to the two main approaches to development. According to Boehm and Turner [2004], there are five critical factors involved in determining the relative suitability of agile or plan-driven processes in a particular project environment or situation, i.e. the five factors of personnel, criticality, size, culture and dynamism. Figure 2.4 below, illustrates the five criteria mapped on the five axes of a polar chart. By rating a project along the five axes, it is possible to evaluate the projects home ground. If all the ratings are near the center, means the project is in the agile territory. If the ratings are at the edge, a plan-driven approach will be the best alternative. If there should be a mix of ratings, i.e. ratings are mostly in either one of the territories, these should be considered as sources of risk and therefore risk management should be addressed to deal with them. [Boehm & Turner, 2004] Given the outcome of the workshops, provided us with the following result when applying Boehms and Turners [2004] criteria and mapping the analysis results in the polar chart. The results which are indicated with filled rectangles, define the position of the process of Grameen Communications.
Page 29 of 141
Personnel (% Level 1B) (% Level 2 and 3)

100 40 30 20 Many Lives Essential Funds Discretionary Funds 10 0 0 15 20 25 30 35 30 10
Criticality (% Loss Due to Impact of Defects)
Comfort 50 5 10 30 100 300 90 70 50
Dynamism (% Requirements Change/Month)
30 10
Size (Number of Personnel)
Culture (% Thriving on Chaos vs. Order)
Figure 2.4. Mapping the home ground of Grameen Communications process.
It is clear that the process of Grameen Communications does not imply a pure application of neither an agile nor a plan-driven approach. To get a better understanding of which process approach is most appropriate for Grameen Communications, the deviations must be considered as sources of risk that must be addressed in a risk analysis. To deal with this Boehm and Turner [2004] prescribes a five-step, risk-based method as a way to plan for the future process which in this case will incorporate elements of both agile and plandriven methods. In other words, it is fully possible to use a combination of agile and plandriven approaches, but it is a matter of altering the right parts of the process, and to take into account the risks that the deviation from either home ground can pose on the recommended process. The five-step risk method to develop a risk-based strategy uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy [Boehm and Turner, 2004]. The risk analysis is used to define and address risks particularly associated with agile and plan-driven processes. The five-step risk method to develop a risk-based strategy uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy [Boehm and Turner, 2004]. The risk analysis is used to define and address risks particularly associated with agile and plan-driven processes. The risks are evaluated according to a set of criteria that are specified within in three categories of risks defined by Boehm and Turner [2004]: Environmental risks: sources of risks found in the general environment of development, which are evaluated based on the criteria of technology uncertainties (E-Tech), coordination of project stakeholders (E-Coord) and system complexity (E-Cmplx).
Page 30 of 141
Agile risks: risks specific to the use of agile processes, evaluated based on the criteria of project scalability and criticality (A-Scale), use of simple design (A-YAGNI), personnel turn-over (A-Churn) and level of agile process skills within the project team (A-skill). Plan-Driven risks: risks that are specific to the use of plan-driven processes and which are evaluated based on the criteria of frequency of change (P-Change), need for fast development results (P-Speed), emergent requirements (P-Emerge) and level of skill in plan-driven processes (P-Skill). The process framework is also based on the Risk-Based Spiral Model Anchor Points [Boehm and Turner, 2004], but this part has not been applied in this analysis. We will not present the five-step risk method more in detail, but only present a summary of the results of the analysis. Risk Management Step 1 Project Risk Ratings There exist major environmental risks of technology uncertainties (E-Tech). More specifically, these include the existing development environment including an outdated version of Visual Basic and the use of an Access 97 database, which should be converted to newer and more reliable development technologies if the company want the system survive in the future. In the context of a developing country, this risk involves the lack of sufficient skills and competence in new technologies, but also the cost of new technology (a detailed discussion on these issues is presented in chapter 4 and 5). The point is that a conversion to new technologies will require good planning and structuring of the activities to avoid the risk of failure. On the other hand, the amount of stakeholders does not pose an overwhelming risk from a coordination (E-Coord) perspective, because the software is more or less developed in-house at this point and does not involve reliance on other suppliers or distributors. Concerning agile risk factors there are some conflicting issues to consider as risks. Problems of system scalability and criticality (A-Scale) are small. However, it will be a challenge for the developers to follow YAGNI [Beck, 2000] and simple design (AYAGNI) for several reasons. The case study has proved that no design activities are carried out which has resulted in a very ill-structured system making it very difficult to achieve architectural qualities, such as system modifiability. To improve the system architecture, it is therefore strongly recommended that design activities are introduced in the development process. Moreover, there exists an agile risk when analyzing the dynamism of requirement change. The core parts of the system are stable and can to the most part be anticipated, and would thus benefit from structuring the design activities to avoid the current architectural problems, which are discussed in detail in chapter 3. Another agile risk is the high personnel turn-over rate (A-Churn) in the case study company, which disrupts an agile projects reliance on tacit knowledge. Also, none of the developers are skilled in agile processes (A-Skill), which must be considered as a risk for failure if an agile process is to be introduced. As with agile risks, plan-driven risks involve the teams skills (P-skill) in plan-driven processes. A general observation is that the team does not posess skills in any development process. This must be addressed and strategies to overcome this problem are
Page 31 of 141
proposed below in Step 4a of this analysis. Another plan-driven risk involves the delays incurred by work involving the development of elaborate plans and specifications required by plan-driven approaches, and which must be kept updated throughout the project. As mentioned previously, MFIs throughout the world are facing great challenges because performance issues are becoming more and more critical for several reasons. For example, the need to improve the information system to support the management of micro credit operation and to deal with an increasing amount of customers and information must be taken care of quickly if the MFIs are to uphold the trust of their customers. If MFIs fail in administrating business critical information can be devastating for their future programme. Performance issues are also closely related to the growing competition, which requires faster development of supporting IT solutions. From a plandriven perspective, the need for rapid results is therefore a risk that must be addressed (PSpeed). Moreover, although the requirements of the core parts of the system are stable, it must be considered a risk if over-reliance on pre-specified requirements in areas where requirements may emerge (P-Emerge) is preferred over specifications that allow for more flexibility. In the case of Grameen Communications, this can be motivated by the fact that the search for new software buyers will result in buyers with new requirements, i.e. requirements that correspond to business processes and organizational policies in their respective MFIs. In this respect, an over-reliance on detailed and frozen specifications can have a negative impact on the development if changes occur that can not be anticipated. As MFIs are undergoing organizational changes (P-Change), the risk of increased costs that come with changing and revising elaborate plans and specifications also must be addressed. On the other hand, it must be said that, Grameen Communications belong a family of enterprises that have world leading knowledge the in microfinance industry. Good understanding of the field is an advantage that can help them in stabilizing the basic system requirements, which should be considered as a possible source of risk if not addressed as a more stable element in the design of an agile process. Risk Management Step 2 Compare Agile and Plan-Driven Risks Primarily, agile risks concern the use of simple design, the high rate of personnel turnover and the developers lack of skills in agile processes. From a plan-driven perspective, the major risks encompass the lack of skills in plan-driven processes and a combination of the need for faster software development and to some extent changing and emerging requirements. Introducing a selection of plan-driven planning and architectural design techniques is a way to deal with the agile risks, which should be combined with a selection of agile planning and development techniques to balance the risk of not being able to respond to changes during development projects. Moreover, the polar chart in Figure 2.4 indicates that other issues also must be considered in this comparison of agile and plan-driven processes. In the case study, the culture of Grameen Communications is an important factor that has an impact on the process. The environment is characterised by chaos and the team has succeeded in this environment, which also agrees with agile processes. During the process requirement workshop, however, more order and structure was requested. In particular, the requirements concerned improved communication between management and developers and within the development team, respectively. In addition, taken the high rate of personnel turn-over
Page 32 of 141
and loosing key personnel, creates a risk of missing or loosing critical information that only can be mitigated by more formal procedures. This includes for example documentation, which is generally provided by plan-driven processes. Given these arguments, and according to Boehm and Turner [2004], it would be appropriate to apply a risk-based plan-driven approach. Our decision is, however, to apply a risk-based agile approach. The major reason is that we rely on the principle that it is better to build the process up than tailor it down [Boehm and Turner, 2004]. The majority of the ratings also indicate that the risks are serious but manageable, rather than showstoppers [Boehm and Turner, 2004]. The only exception concerns the teams current skills in processes, which is rated a showstopper for both agile and plan-driven approaches. The lack of skills definitively puts any software process improvement effort on its edge, because skill will be required in either case. On the positive side, this should be regarded as an opportunity to empower the team and taken from that point, an agile risk-based approach is to prefer for several reasons. Agile processes require fewer resources in terms of expensive tools, templates and standards. Few agile processes are commercialized or requiring any license fees. It is easier to get started with an agile process and then build the process up where after needs are identified, although it will still require recruiting an expert who can coach the team initially. Plan-driven methods generally require certifications and training which is not required by agile processes to the same extent. To summarise, to counter the risks of both agile and plan-driven approaches, a selection of plan-driven practices to be applied within an overall agile framework is proposed. The recommendations are discussed more in detail in section 2.4.3. Risk Management Step 4a Individual Risk Resolution Strategies Given that Step 2 resulted in a risk-based agile decision, Step 3 in the analysis is bypassed [Boehm and Turner, 2004]. The next step is to identify a resolution strategy for each risk. E-Tech: Technical Uncertainties One major source of technical uncertainty is the existing use of old and soon-to-beoutdated development technologies, including Visual Basic 5 and Access 97. If the system is to survive, Grameen Communications need to convert to newer, more reliable and sustainable technologies. This technology conversion is not an easy task and involves several risks. It is important to determine the objectives, the constraints (such as developer competencies and skills and technology and license costs) and the priorities. One of the main goals of the MiCOpa project is to address technology issues. The resulting work and the recommendations are presented in detail in chapters 3, 4 and 5. A-Yagni: Anticipated change versus Simple Design YAGNI and simple design will definitively challenge the team for several reasons. As mentioned, architectural design is currently implemented on an ad hoc basis, which has resulted in a very weak system architecture that lacks in several aspects. Important qualities such as modifiability, security and performance are practically non-existent. To improve the system architecture, it is therefore strongly recommended that structured
Page 33 of 141
design activities are introduced in the development process. In addition to this, there exists an agile risk when analyzing the dynamism of requirement change estimated to up to ten percent per month (which is also indicated on the dynamism axe of the polar chart presented in Figure 2.4). The core parts of the system are stable and can to the most part be anticipated, and would thus benefit from structuring the design activities to avoid the current architectural problems. This involves introducing architectural techniques, such as layered architecture and design patterns that can be used to create a framework for accommodating both the current lack of architecture and foreseeable change in a way that is much more appropriate than with a pure agile simple design. Issues concerning the architecture and recommendations on what techniques can be applied to achieve improvements are described in detail in chapter 3 and 4. A-Churn: Loss of tacit knowledge via personnel turn-over Another agile risk concerns the high personnel turn-over rate at Grameen Communications, which disrupts an agile projects reliance on tacit knowledge. There are several strategies for how to avoid this problem. From an agile perspective, knowledge losses are reduced due to the team work and shared responsibility that come from following the values and practices of agile processes. Development is carried out in tight interaction between all stakeholders throughout the process. For example the value of communication is realized by the practice of pair programming and rotating pairs where each team member learns about the whole system, rather than having single programmers owning particular modules of the system as is the case today. From a plan-driven perspective and which is not counteracting agile processes and values, this risk of loss can also be reduced by introducing documentation as part of the process, such as system documentation as a complement to the existing user documentation. Documentation techniques will be discussed in section 2.4.3. A third strategy to mitigate the risk of loosing important knowledge is to establish an attractive and stimulating work environment. Two reasons for leaving the company, mentioned among the developers, were the salary and lack of incentives for developers to stay, such as competence development and further education of personnel. Agile processes addresses work environment issues by its very nature. Knowledge transfer comes with the value of teamwork, communication and constant feed-back. P-Change, P-Speed, P-Emerge Delays and reduced competitiveness An agile process will address the risks of delays and reduced competitiveness. For example, change and emergent requirements are addressed by dividing the development process into short iterations that provides an effective mechanism for quick feed-back on results and which also helps ensuring the project is on track. Once the team has structured system architecture in place (with help of the recommendations provided in chapter 3), will also facilitate making changes in the system during development. Faster results and reduced delays are also addressed by short iterations in combination with pairprogramming and early and disciplined testing of the code. In addition, it should be mentioned that change, emergent requirements as well as speed is facilitated by the fact that the company in this case study has its major software customer located in the same building. Having easy access to the customer to communicate any issues regarding a project is very valuable to get quick feed-back as required when applying agile practices.
Page 34 of 141
However, as no planning is taking place at all in the current process has created problems that should be addressed. No planning at all as well as too much planning are both risks that can make projects fail. No plans or milestones make it difficult to measure progress. On the other side, over-specified plans and too detailed specifications can be costly if changes occur during a project and resources must be put aside to revise the plans taking the focus away from development. A balance must be found to reduce the risk of project planning failure. Because an agile risk-based approach is decided, planning will follow agile strategies which are described more in detail in section 2.4.3. A-skill/P-Skill: No skills in any development processes Of all the risks analysed, the general lack of skill in development processes is the greatest. It is a critical factor for a successful outcome in any process improvement effort, i.e. whether an agile or plan-driven approach is chosen. There exists no skill in any process at Grameen Communications. This is a very serious problem that must be regarded as a great source of risk which must be addressed if a process improvement is to be realized as has been the request by Grameen Communications. There are two strategies to address this and depending on the resources available at least one of them should be carried out. The first alternative is to recruit a person with process expertise to coach the team and to get them started on the process. The coach should follow-up on the team until it is able to work on its own. The other alternative is to educate the team or at least some key persons on development processes, by sending them to courses arranged by the local university or any commercial education. If there are not resources available to send the whole team, the person or persons who get an education will have to spread the knowledge in the team. This could be realized by putting him/her in the coach position for sometime. Risk Management Step 4b Risk-based Strategy for Software Development at Grameen Communications In Figure 2.5 on the next page, the result of the risk analysis is summarized. The figure depicts an overall process strategy that integrates the risk resolution strategies discussed above. It also addresses the requirements specified by the team in the requirements workshop, both on the organisational and engineering level. This is the suggested baseline for improvement to be used as a starting point for Grameen Communications. A baseline must be established according to the Shewhart Improvement Cycle [Deming, 1982] i.e. the underlying approach to software improvement that has been applied in the MiCOpA project and which is described more in detail in Appendix B. As this only provides the general strategy on how to balance an agile process approach with a plan-driven approach, guidelines on supporting development techniques, tools and standards to be applied must be provided to be able to carry out development in practice. In the following sections, recommendations on a more comprehensive software development process will be presented.
Page 35 of 141
Startup * Establish joint team, staff and organize team * Develop shared system vision * Establish release plan (planning game) including milestones * Explore project risks and options (spikesolutions)
System & Architectural Design
Design, Development & Implementation * Establish iteration plan
Whole team (project manager, coach developers, customer representative)
* Define and evaluate architecture options * Explore design risks and options (spikesolutions) * Develop highrisk components
* Develop tests first and then code * Analyse feedback on current version * Reprioritise features * Prepare for next increment
Figure 2.5. Grameen Communications overall process strategy.
2.4.3 The Future Base Process for Grameen Communications

The overall software process strategy, including the risk resolution strategies are in place. However, to implement the strategy requires that the activities for carrying out the strategies are specified. In other words, this is where the strategies turn into an actual base development process, i.e. by describing what techniques, tools and standards is needed to carry out the process effectively in practice. In this section, the base process will be described in detail. In the MiCOpA project, both a bottom-up analysis, based on the workshops, and a topdown analysis, based on Boehms and Turner [2004] polar chart and risk analysis have been carried out. By synthesising their individual results gave an opportunity to validate but also to compare and match the results of each analysis. Results in sync were filtered out and prioritized as areas that need concrete improvement actions. It determined what process elements, above all, were needed to implement the overall strategy, and what basic activities must be described to fulfill the strategy. Exceptions in the comparison were not less important, but were treated as sources to future improvement because of the focus of first defining a base process.
Page 36 of 141
By synthesising the output of the workshops, i.e. the outcome from defining the current process according to Cockburns [2002] thirteen element model, problems identified and requirements specified, with the risk analysis and resolution strategy resulted in a few key areas that could be filtered out to concretise the baseline for process improvement activities. The key areas are workflow activities and roles and responsibilities standards tools support documentation
More specifically, the key areas provide a very concrete foundation for knowing where to focus improvement efforts to conform to the overall process strategy. Workflow According to [RUP, 2005], a workflow is a sequence of activities that produces a result of observable value. Three engineering workflows are recommended, which conform to the overall process strategy, i.e. the workflows of Startup, System and Architectural Design, Development and Deployment. Each recommended workflow and their activities are described more in detail below. Startup
Startup * Establish joint team, staff and organize team * Develop shared system vision * Establish release plan (planning game) including milestones * Explore project risks and options (spikesolutions)
Establish joint team, staff and organise team: Building a good team is a critical project success factor. A joint team consists of both developers and customers. Find good representatives and identify any missing team members who are critical for the project outcome. Develop shared system vision: A shared vision involves defining goals together, which helps the team to work in the same direction. It also provides a good basis for communicating during development. A shared vision can consist of a system metaphor that visualises the overall system goals. Establish release plan: A planning game involves requirements analysis and defining project milestones. It is a simple and effective technique for setting up the overall release plan for the system. The customer specifies what the system needs to do. The developers specify how much each feature costs in time to implement and what budget is available per feature. [Beck, 2004] Explore project risks: Explore goals and the plan again. Identify any project critical risks, such as missing team members, other resources or options.
The startup workflow is added to the original process and recommended to overcome the current lack of planning. It is based on an agile approach, including the planning game that allows flexibility to counter plan-driven risks as discussed in the risk resolution strategy. Page 37 of 141
System and Architectural Design

System & Architectur al Design
* Define and evaluate architecture options * Explore design risks and options (spikesolutions) * Develop highrisk components
Define and evaluate architecture options: Define and evaluate potential architecture choices, e.g. reuse of existing architecture. Prioritise architectural qualities and what architectural techniques and tactics should be used to get a well structured system (which is described more in detail in chapter 3). Explore design risks and options: Explore and determine risks of various architectural options. Design problems or technical complexity has to be addressed before starting a development iteration to reduce risks. Spike solutions [XP, 2005] are developed by the developers to solve or explore critical problems and are helpful for evaluating any design risks to be considered before and during development. Develop high-risk components: Start development with developing the components with the highest risk to ensure a stable architectural design as early in development as possible, and in order to avoid running into architecture breaking problems later in the development process.
In its current state the process lacks greatly from any design work. Our observations onsite proved that one of the major reasons to why the current system is ill-structured is because there exists no design work at all, which is required if the system should be flexible, modifiable and easily customisable. Therefore, it is recommended that a new engineering workflow, System and Architectural Design, is added to the original process to balance the agile risk-based approach. In chapter 3, a complementary and more detailed discussion about architectural design is also presented. Development and Deployment
Development & Deployment
* Establish iteration plan
* Develop tests first and then code * Analyse feedback on current version * Reprioritise features * Prepare for next increment
Establish iteration plan: Break the overall release plan down to 2-4 week iterations. The customer prioritises the requirements to be implemented in the current iteration. Developers specify development tasks for each requirement and estimate the time to implement them. This provides a basis for planning and negotiating what can be achieved during an iteration that will provide value to the customer. Develop tests first and then code: Testing should be automated and done as early as possible to achieve high quality software. The ideal is to develop tests first and then code. Aim at writing tests early, automate and run them as soon as new code is checked in to attain better software quality. Analyse feedback on current versions: Analyse feedback provided from continuous testing and representative customers. Re-prioritise features: Collaborate to identify any risks or opportunities. Evaluate and deal with change requests, either by including them or postponing them to the next iteration. Prepare for next increment: Reflect and consolidate lessons learned from the current iteration and prepare a strategy for the next increment to further improve work.
Page 38 of 141
Although these three workflows may evoke the sequential phases in a traditional waterfall process, it should be kept in mind that the phases of an iterative process are different and that these workflows are revisited again and again throughout the development lifecycle. The actual complete workflow of a project interleaves these three core workflows, and repeats them with various emphasis and intensity at each iteration [RUP, 2005]. By breaking the overall release plan into smaller, more manageable pieces of work and because each iteration is short and ends with an executable release or increment, allows for quicker feed-back that help ensuring that the project stays on track. Therefore, an iterative approach is strongly recommended to enhance the teams ability to respond to changes during development. Furthermore, a mere enumeration of the workflows, their purposes and their products does not quite constitute a process. This is only a static description of the process. It does not include the dynamic aspect, i.e. there is no time-related definition, no detailed specification of the activities that should be realised within a particular workflow, and no definition of what roles should be involved and interacting within the workflow. Therefore, the dynamic aspects are described below. Activities and Roles and Responsibilities An activity is an individual task within a workflow [Cockburn, 2002] and should have a clear purpose and describe how to do things. Every activity is assigned to a role, which has the responsibility to carry out the activity within the corresponding workflow. A role defines the behavior and responsibilities of an individual. One individual may have many different roles within one project. The responsibilities assigned to a role include both to perform a certain set of activities as well as being owner of a set of products. [RUP, 2005] Figure 2.6, depicts the roles defined in the overall process strategy and which should actively be involved all the way through the whole development process. Note that it runs horizontally throughout the three workflows, which indicates the dynamic aspect that is complementary to the static aspect discussed above. The roles are actually taken from an existing role specification at Grameen Communications which are described below. Whole team refers to the recommendation of improving teamwork and to also actively involve the customer on the team to facilitate collaboration and communication.
Whole team (project manager, analyst developers, customer representative)
Figure 2.6. Recommended roles of development team.
Page 39 of 141
Project Manager: will act as the main point of contact with client. He/She will review the deliverables and the Change Authority for the requirements of the project. The Project Manager will be responsible for the total project and will review the actual progress against the planned and institute appropriate action. He/She will also keep the Analyst and the Programmers informed of any deviation from agreed schedule. Analyst: will have day-to-day responsibility of the majority of the work during requirement analysis, design and implementation phase. In particular, he/she will produce the requirement analysis and design documents. The programmers will report to him/her in the development phase. Programmer: will code the software and perform the unit and system testing of the coded software as per the approved requirement analysis and design document. The programmer will also train the client and the distributor personnel on the developed software. Customer representative: an active role in the team. The customer specifies the requirements, and prioritises what requirements are most critical and needed first and what requirements can be deferred. The customer is also involved in defining acceptance tests and verifies if the system functions according to the requirements. Activities and the responsible roles are indicated in Table 2.1 below.
Activity
Planning Requirement Analysis Architectural Design Detailed Design Development (Coding) Software Integration Testing Documentation Training
Responsibility of (role)
Project Manager Analyst Analyst Analyst Programmer Programmer/Analyst Customer/Programmer Programmer/Analyst Programmer
Table 2.1. Activities and the assigned roles and responsibilities.
This is a reasonable specification that already exists at Grameen Communications. However, currently it lacks of clear definitions of the meaning and the purpose of both activities and roles and exists only in this form on a paper. Our observations proved that the specified activities are only carried out partially and that a programmer carries all the roles. To address the requirements of better organizational structure and better collaboration, but also as means to mitigate the risk of loosing critical information if someone leaves the team, we recommend Grameen Communications to keep the original activity and role specification although with the some modifications:
Page 40 of 141
Activities: Specify a clear purpose for each activity and consider how it will support the overall process strategy to counter any of the risks identified. For example, specify and agree on the purpose of documentation activities to mitigate risks of loosing information if someone leaves the team. Roles and responsibilities: Include the customer representative on the team as to conform to the overall process strategy and to improve collaboration between the developers and the customer. Another recommendation is to change the programmers current responsibility for the Training activity. Due to the problems programmers faced during training, e.g. end-user resistance to automation, it is clear that the responsible role for this activity should be a person or several persons, who has expertise in change management. If possible, it is recommended that a person with this expertise is recruited to the team.
For the roles to be able to carry out these activities efficiently and effectively, supporting standards, tools, techniques and documentation should be specified. These will be discussed in the following sections. Standards According to Cockburn [2002] definition of standard as one of the thirteen elements of a methodology, standards are the conventions the team adopts for particular tools, work products and decision policies to become more effective in communication and for the purpose of improved team work. The following three types of standards are recommended as part of the base process. Code standard The source code provides the most important documentation. In particular for the developers. The team should agree on a common code standard as means of communication via the source code. There already exists a convention for code commenting in the current process, but this can be further enhanced with additional comments, e.g. commenting design decisions taken so that other developers can easier understand the code. The code standard should also be complemented with agreements on how to structure the code and rules for indentation and line spacing to increase readability. Documentation standards The source code provides important documentation, but it should be complemented with other types of documentation that can be offered to stakeholders not involved or skilled in coding for them to be able to monitor development. Documents are important for various purposes which will be discussed in detail below. However, to further improve team work and to facilitate communication, the team should come to an agreement regarding what documents to use, how to write them and where to keep them for easy access. Tool standards There exist many different tools that support development. To further improve team work, it is also important for the team to agree on what tools to use and to what extent in projects, e.g. to standardise the use of vbUnit testing tools throughout all projects. Page 41 of 141
It is very important that these standards are adopted voluntarily by the whole team and that the purpose of these standards is clear to everyone. It should be motivated that they will allow further improvement of team work and communication in projects and that standards also addresses the risk of loosing critical project or system information. Tools support A software development process requires tools to support all activities in a system's lifecycle, especially to support the development, maintenance and monitoring of various products or deliverables. An iterative development process also puts particular requirements on tools because they facilitate much of the work during development. This includes tools to keep track of changes, to support requirements traceability, to automate documentation, as well as tools to automate tests to facilitate testing. The Grameen Communication process can be used with a variety of tools, either commercial or freeware. To improve the process of Grameen Communications, it is clear that supporting tools are needed to overcome the current problems. In particular, tools that facilitate communication, version control, documentation and testing are required. The choice of tools depends on several factors, such as resources and skills. From a developing country perspective, these are also challenging constraints because the lack of both. With respect to this, the recommendation of tools is based on freeware and involves only a few basic tools to support the baseline process. Freeware does not strain the company financially, because it can be downloaded for free from the Internet. The technical requirements have also been considered. The tools chosen runs on almost any platform, which allows usage on the existing machines. In other words there is no need to buy complementary and costly technology. The tools proposed also provide training material, such as tutorials, on-line manuals and documentation, which is an easy way for the developers to learn on their own how to use the tools. Below is a list of the tools that are recommended and which will support the activities in the base process of Grameen Communications. Wiki Wiki [Wiki, 2005] provides a web based tool that helps keeping the entire development team updated and on track throughout the development process by making any project information easy to write, communicate and change. Projects use Wiki to work on their documentation, fixing dates, manage resources or use Wiki as a repository of files. Cunningham [2005] defines Wiki as the simplest online database that could possibly work. Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and cross links between internal pages on the fly. Like many simple concepts, "open editing" has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that
Page 42 of 141
it encourages democratic use of the Web and promotes content composition by nontechnical users. A Wiki was also used during the MiCOpA project, and proved a very valuable tool for effective communication among the project participants. CVS Concurrent Versions System [CVS, 2005] is a free source code management system that helps developers keep track of version history, releases and parallel versions, and which enables the project team to track and manage all change activities that occur throughout the software development process. More specifically, CVS is an open source version control and collaboration system [CVS, 2005]. To draw a parallel, CVS is a central station for code, which allows the team to coordinate both individual and team work. The developers can work on their local machines, but by having a CVS installed on a central server (on a server on the local network in this case), developers can check out and check in files in a controlled manner and even work on the same files in parallel. The CVS keeps track of the different versions that are kept in a central repository on the server. Another important aspect is that if anything would go wrong, the system also provides a safety net because the latest versions can be tracked and retrieved from the CVS. Poseidon for UML Poseidon for UML (Community Edition 3.0.1) [Poseidon, 2005] is a cost-free and simple graphical modelling tool for documenting requirements analysis and system and architecture design. It is adapted to beginners by providing an intuitive interface that facilitates the creation of diagrams. Poseidon for UML contains support for all the UML (Unified Modelling Language) [Fowler, 1999] diagrams. It allows for example creating, saving, and exporting the diagrams to various formats. It also provides some guidance on how to create UML diagrams, but it is recommended that the team learns UML to fully benefit from using this tool. VBUnit vbUnit Basic [VBUnit, 2005] is an open-source based testing tool free of charge that helps the developers to create, maintain and execute automated functional tests, which allows thorough testing of the code and facilitates determining if the software meets the requirements and performs as expected. In iterative development, testing is integrated with the development process, rather than done in an isolated phase in the end of the project. By testing the software throughout the development process has several advantages. Firstly, it has proved to greatly improve the quality of the software. Secondly, continuous testing reduces development time. Thirdly, earlier testing cuts development costs. This is possible because testing makes coding and coding results more visible, i.e. testing provides a good feed-back mechanism making it easier to take quicker action upon. Continous testing also prevents many bugs to pass by unnoticed and which generally involves high costs when discovered late in development. The earlier errors are discovered, the less it costs to have them fixed both in terms of time and money generally required for fixing bugs [Astel, 2004].
Page 43 of 141
vbUnit is a tool that is especially designed to offer automated testing and integration of design, testing, and coding [vbUnit, 2005]. Automated testing means that instead of manually testing a piece of code just once, vbUnit allows that tests are written, automated and kept in a test repository. A set of automated tests creates a test suite that will stay in the project for as long as needed. After changing or adding a piece of code, it is possible to run all tests for the whole project, which will immediately indicate if everything still works. vbUnit will help the team to keep track of progress and achieve higher software quality, and therefore it is also strongly recommended as to conform to the overall process strategy. Documentation There are two main types of documentation: system documentation and user documentation [Dennis et al., 2002]. Because user documentation is already in place, the focus here will be on recommendations regarding system documentation. System documentation is intended to help programmers and analysts understand the software and enable them to build it or maintain it after the system has been installed [RUP, 2005], but also to allow for project management and other project stakeholders to monitor development. Moreover, documentation is a strategy to overcome the identified risk of loosing critical information if a person leaves the company. However, the level of documentation competence in the team is a factor that must be considered. There exist no documentation skills. Therefore it is required that the documentation is not too advanced. Given three parameters: (1) that there is a great need for documentation, but (2) at the same time lack of documentation skills, and that (3) the documents should comply with an agile risk-based approach, leaves the conclusion that the types of documentation proposed should be as supportive but as simple as possible. A balance between these parameters must be found, because documents must be created to help the team and the company to overcome current problems. Ambler [2002] provides a solution to this called agile documentation. In Table 2.2 below, the most important system documents are specified. It is also specified for whom the documents are useful, what they should contain and for what purpose the documents should be created. The proposed documents address the current problems, and therefore the team should create them as part of the development effort to be delivered as part of the overall system. The selection of documents comes from a list defined by Ambler [2002].
Page 44 of 141
Document
Design decisions
Roles
Programmers, Project Managers Senior Management, User Management, Project Management Programmers, Management, Operations Staff
Content/Purpose
A summary of critical decisions pertaining to design and architecture that the team made throughout development A definition of the vision for the system and a summary of the current cost estimates, predicted benefits, risks, staffing estimates, and scheduled milestones.
Executive Overview
Project overview
Requirements document
Programmers, Customer
System documentation
Programmers
A summary of critical information such as the vision for the system, primary user contacts, technologies and tools used to build the system, and the critical operating processes (some applicable to development, such as how to build the system and some applicable to production, such as how to back up data storage). Also provides references to critical project artifacts such as the source code (the project name in the source code control system is often sufficient), where the permanent models pertaining to the system (if any) are, and where other documents (if any) are. This document defines what the system will do, summarizing or composed of requirements artifacts such as business rule definitions, use cases, user stories, or essential user interface prototypes. The purpose of this document is to provide an overview of the system and to help people understand the system. Common information in this document includes an overview of the technical architecture, the business architecture, and the highlevel requirements for the system. Detailed architecture and design models, or references to them, may also be included where appropriate.
Table 2.2. Recommended documents from Ambler [2002] to be created by the development team.
Strategies for Increasing the Agility of Documentation There exist a number of strategies that provide guidelines on how and when to write documents in an agile manner provided by Ambler [2002]: Focus on the documentation customer(s). Identify who needs the documentation and for what purpose the document is needed. By understanding the documentation needs will help in specifying what documents should be created. Keep it just simple enough, but not too simple. Think simple. Do not overwork a document. Start simply, i.e. a document that is minimal enough for the needs of its customers then improve it when needed.
Page 45 of 141
The customer determines sufficiency. Collaborate with the customer. Let the customer validate the document. Collaborate with the customer and improve the document until the customer is willing to accept it. Document with a purpose. Be selective. Identify and define a clear purpose and the goal of the document. Documents should only be created if they fulfil a clear, important, and immediate goal and which facilitates the overall project efforts. Prefer communication over documentation. Documentation supports knowledge transfer, but this does not necessarily meant it does so in every case. Complement documents with communication. Communicate within the team and with project stakeholders and encourage active participation in development. Communication often results in better understanding, which can be difficult to achieve with documentation. Put the documentation in the most appropriate place. Make documents easily accessible. Identify where the needs of documentation is most critical, whether it is by commenting design decisions directly in the code, by putting notes on a notice board or whiteboard or in an external document. Display models and diagrams publicly. Make any models or diagrams visible, for example on a wall, on a notice board, or internal web site such as Wiki. This facilitates transfer of information and thus improves communication. Open communication on a project reduces the need for detailed documentation. Wait. Eliminate waste. Create documents just before they are needed. For example, system overviews are best written towards the end of the development of a release because then the knowledge about what has actually been built will facilitate and speed up documentation. Keep documentation updated. Any documents selected, whether in textual or graphical format must be updated with changes, to avoid unnecessary misunderstandings. If there are documents left behind, it may also be a sign of useless documentation that does not provide value to the project. Write the fewest documents with least overlap. Avoid writing overlapping documents, to reduce double work but also to reduce the risk of misunderstandings between documents. Get someone with writing experience. A person with technical documentation experience should be included in the team, because they know how to select, organize, structure and present information effectively. To summarise, to counter the risks of both agile and plan-driven approaches, a selection of plan-driven practices to be applied within an overall agile framework is proposed as the future base process for Grameen Communications. By introducing a selection of plandriven planning and architectural design techniques is a way to deal with the identified agile risks, which should be combined with a selection of agile planning and development techniques to balance the risk of not being able to respond to changes during development projects. Moreover, this proposal also addresses process problems,
Page 46 of 141
requirements and local constraints particularly evident in a development country context, which are discussed in the following section.
2.5 Concluding Comments on Process Developing Country Perspective
Issues
from
IT is everywhere. It increasingly pervades our daily lives and can be found in our vehicles, electronics, and medical devices and practically in any programme, organisation or industry promising efficiency, effectiveness and higher quality. However, the transfer of IT to developing countries has failed somewhere along the way. Lack of financial and human resources are clearly factors that constrain the introduction of IT. Where IT is introduced these constraints are also reinforced by new constraints, making successful outcomes difficult to achieve. For example, a recent study points out several difficulties, among which dysfunctional customer-developer communication, the developers inability to reflect on their part in the development process, and the use of inadequate software development processes were emphasized as factors causing project failures in developing countries [Winschiers & Paterson, 2004]. In order for developing countries to yield the benefits of IT, the potential for local software development must be enhanced [Winschiers & Paterson, 2004]. Considering the resource constraints, developing countries should also strive for sustainable software development. A key to solve this is to provide these countries the tools that support development, where the development process is central. However, providing a process successfully can only be achieved by adapting it to the local context, which means that tools, techniques and goals need to be redefined within the local context and by taking into account the constraints in that context. These constraints are also particularly evident in the context of developing countries. In the MiCOpA project, a case study to demonstrate how the cultural differences and the particular conditions of developing countries can be considered when improving an existing process has been carried out. The results of the case study support observations made in other studies, proving the existing lack of financial and human resources and the lack of organizational maturity. In summary, the following major constraints were identified: Lack of financial resources Lack of competence and skills Lack of training Lack of user involvement Lack of organizational maturity
In the case of Grameen Communication, these constraints were addressed by the definition of an agile risk-based process [Boehm & Turner, 2004], which was presented in the form of a baseline process to be built up or tailored down depending on the current needs and available resources. Providing this in-built process flexibility, is an advantage because each project will require different kinds of process support depending on criteria
Page 47 of 141
such as the size of the team, the competence levels of team members, the complexity of the software, and how often requirements change [Boehm & Turner, 2004]. Once these factors are evaluated within the local context, the base process can be adjusted, re-used and maintained, thereby promoting sustainability. To this date, there exist no other studies that discuss the use of agile processes in developing countries. In this respect, the MiCOpA project has provided a unique opportunity to pioneer the use of agile processes in a developing country context, but also in the micro credit field. If considering the observations made in other studies on software development and software processes in developing countries, for example in [CGAP, 2005], [IICD, 2004] [Indian NGOs, 2005], [Winschiers & Paterson, 2004] the constraints for sustainable software development in the case of Grameen Communications in Bangladesh, are also likely to apply in other developing countries. By acknowledging this and the results of the MiCOpA project, it should be clear that agile processes can provide a highly potential solution to address the constraints particularly evident for software development in developing countries. However, it is very important to recognise that the baseline process recommended here cannot be applied universally. No software process can. There exist no one size fits allprocess [Boehm & Turner, 2004]. Processes have to be adapted to the local context and current project needs, and this applies to projects in developing countries as well as projects in development countries. Therefore, careful evaluation of constraints and sources of risk is still a pre-condition for successful, long-term and sustainable process improvement.
Page 48 of 141
3 Architecture
In this chapter we analyze the software architecture of Grameen Communications Microfinance software and propose guidelines for improvement.
3.1 Definition of Architecture

Before starting it is useful to have an understanding of what software architecture is: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them [Bass et al., 1994] Software architecture is often neglected in software development, probably because it is seen as a purely technical discipline that is not very relevant for the business objectives of a company. This view has some merit in the short term, but in the long term however insufficient attention to the software architecture of a MIS can lead to serious problems. Examples of problems that can occur are: The system cannot support the transaction volume and becomes unusable Insufficient lack of security features leads to financial loss due to malicious manipulation of the system for personal gain The system cannot support changes in the business process and becomes an obstacle to organizational change The system doesnt work properly because it is not constructed with its operational environment in mind The software application becomes more and more difficult to maintain and understand as it has no clear and logical structure
In fact, one of the starting points of the MiCOpA-project were that Grameen Communications were starting to realize it had some of the above mentioned problems and that they wanted guidance on how to address them. They felt that their microfinance MIS could not be easily modified to new requirements. It was also difficult for newcomers to understand the system. This leads to decreased organizational agility for Grameen Bank. It is simply put not possible to change the organization to new requirements as quickly as needed because the information system cannot keep up. This means that operational changes that are necessary to reduce the cost of operations, for example addition of PDAs for loan collection, are difficult to implement. A well-constructed software architecture should address the above problems
3.1.1 Quality attributes and architectural analysis

As was seen above software architecture can have a significant impact on the effectiveness of an organizations information system. Consequently it is important to analyze the suitability of the software architecture to the organizations needs. The organization must therefore determine the requirements on the software architecture. These requirements can be expressed as the Quality Attributes [Bass et al., 1998]
Page 49 of 141
[McGovern et al., 2004] the architecture should possess. Example of quality attributes are: Performance (response time) Security Usability (Is the system easy to use?) Modifiability (Can the system change easily to new requirements?) Testability (Is the system easy to test?) Integrability (Is it easy to integrate the system with other software, for example a PDA?)
Achieving good quality in all areas is either not possible or too expensive, so it is necessary to do tradeoffs. To determine these tradeoffs it is necessary to analyze the business environment of a system and to determine which qualities are the most important. This can be done using Quality Attribute Workshops [QAW, 2004] which has as outcome the necessary quality attributes of a future system and their priorities. Most of the time it is not possible or cost-effective to throw away all previous work and start from scratch, but the system must be incrementally improved. In that case one can do an Architectural analysis of the existing system and propose improvements. This is the path followed in this report were we mostly concentrate on the improvement of Grameen Communications MIS for micro-credit operations, Grameen Banker V3.0.
3.2 Constraints on a software architecture for developing countries

Running an information system in a developing country has its inherent challenges. In many aspects designing a system for use in a developing country is more challenging than doing it in a developed country [SIDAITStrategy]. For example the following factors have to be taken into account: Network Connectivity is often limited - Often a network connection is not available or maybe only available through a low-bandwidth modem. In many cases the cost of network traffic is also prohibitive. Cost constraints Since computers are scarce, it is beneficial if systems are able to run on older hardware as well. Lack of skills Architectures need to be more robust and simple to facilitate maintenance. Lack of electricity Electric supply should not be taken for granted. Power failures are very common, and computers need to be equipped with extra Auxiliary Power units.
3.3 Description of Work Method and Research Approach

To make an analysis of Grameen's software architecture, the following activities were performed: 1. Field trips to get a an understanding of the environment of the software system 2. Interviews with developers and management
Page 50 of 141
3. Perform Quality Attribute Workshops [Bass et al., 1998] to get an understanding for Grameens architectural requirements and to understand the current problems 4. Analyze the current architecture by software inspection 5. Analyze the security architecture of Grameen Banker with respect to the Common Criteria security standard [CC] 6. Analyze other current openly availaible Micro-finance software These activities then led to guidelines on how to improve the architecture.
3.4 Grameen Current Software Architecture

3.4.1 The environment of the Grameen Banker V3.0 Software
Grameen Banker V3.0 is installed in Area offices mostly located in smaller villages on the countryside in Bangladesh. None of Area Offices have an internet connection today. The only network that is available is a small LAN within the office itself. The computers are very heavily used for data-entry. Several hours every week are spent entering data. This means that the user-interface has to be very responsive and fast. Grameen Banker is not the only software used at the Area Offices. An custom accounting software built by Grameen Communication is also used. The two systems are not integrated. This lack of integration led to a lot of manual work.
3.4.2 Grameen Communications Current Problems

To analyze Grameen Communications existing software architecture and the requirements of a future one, a Quality Attribute Workshops were performed [QAW]. In this workshop Grameen Communications developers discussed the existing architecture with regard to Quality Attributes. This workshop was used both to spread knowledge on the importance of software architecture and to gather requirements for an improvement of their existing architecture. The Quality Attribute Workshop resulted in a good understanding of Grameen Communications architectural problems. The output of the workshop resulted in a few key areas that were voted to need most improvement. These were: Modifiability (5 1 votes) Security (2 2 vote and 1 1 vote from management) Performance (2 2 votes)
Page 51 of 141
Consequently the main focus of the architectural work ought to be in these areas. However, it would be insufficient to base all of the analysis on just Grameen Communications own opinions regarding their software architecture. This input needs to be complemented with a software inspection.
3.4.3 Software Inspection

As a complement to the workshops time was spent looking at the actual code of Grameen Banker V3.0. This has the effect of an informal software inspection. The code was analysed with regard to general software engineering principles such as: Structure Is the code well-structured? Does it use the modularity features offered by the language? Naming Are the program constructs logically named? Documentation Is the code documented through code documentation and comments? Database design Is the database designed according to good principles (E g, is it normalized?) Separation of Concerns Are different software concerns (E g, User interface and business logic) separated as well as possible?
3.4.4 Software Inspection Results

The results of this analysis were as follows: Structure The code is very poorly structured. There are very many procedures that are too long and complex. Logic is not split up into different procedures. The modularity constructs of the language (Modules, Classes, Subroutines and Functions) are very little used. For example there are only three VisualBasic classes in the entire system and only one module. This makes the application very hard to understand. Naming The names of Forms, Subroutines, Classes, Modules and Functions are frequently not indicative of their purpose. It is very hard to tell from the names in the code what it does. This adds to the complexity of the code. Documentation there is no code documentation, and quite few comments in the code. Database design The database is not normalized and it contains a lot of duplicated fields (This aspect is very important and will be more thoroughly investigated in a separate section in Appendix A: MS Access Database analysis.).
Page 52 of 141
Separation of concerns User interface code and business logic code are completely mixed. This makes it very hard to see what parts of the code deals with business logic and what parts is only concerned with user-interface issues such as layout. Very few security features The only security feature consists of login-screen which queries the database for an unencrypted password and username.
3.4.5 Security Architecture Analysis

Security is of special concern to Grameen. Although incidents are not frequent it is important to prevent them ahead of time. An important standard that can be used to analyse security architecture is the Common Critera [CC, 2004]. Doing this is normally an entire report in it's own right. Due to the time constraints in this project however this has to be done on a high-level way with the hope of capturing at least the most obvious security flaws. The simplified methodology used here was therefore to take a high-level look at Common Criteria functional security requirements and to estimate how well the existing architecture fulfils these requirements. Through the analysis of the software and technology and the workshops the following problems need to be addresses: Lack of database security The database can be, and is, arbitrarily modified by datacenter staff. Lack of Audit trails there is no record of datacenter staff transactions that can be used for auditing other than the database itself Users can modify any file they want The staff can modify any file they want on their systems, potentially with a malicious intent. Lack of fine-grained access control (The future version of Grameen Banker, V4.0 has more advanced access control) After logging in all users have the same access rights Poor strength of authentication mechanism The authentication is based on a simple password that is stored in clear text in the database. This mechanism is easily circumvented by a moderately skilled user.
3.4.6 Architecture of other Micro-credit software packages

As the aim of this project involves investigating the feasibility of introducing Opensource technology, it is interesting to see what other free Open-Source alternatives that exist. From a search on the Internet (Using the search terms: Microfinance and Opensource.) and browsing the MFI Gateway website [MicrofinanceGateway, 2005] we found the following software: MOAP (no working software) MIFOS (Preliminary stage. This project was started very recently, so it has not been thoroughly analysed yet.) Aquadev Compiere (Not a Micro-finance package, but it could be customized to become one)
Page 53 of 141
3.4.7 Moap
The MOAP Open-source Micro-finance MIS Software is in a pre-alpha stage [MOAP, 2005]. That is very early stage of development. In fact virtually no code has been written, just some documentation. Nevertheless the documentation and the little code there is one can see that MOAP is based on the J2EE platform and is designed to be a browser-based web-application. The architecture can be described as follows: A layered architecture with Domain (Model) objects implemented using Hibernate, Model-View-Controller architecture using Struts JSP as the View layer
However the software is in no way usable since the only functionality implemented is to create and list customers. Comments Since the MOAP clearly suggests a web-architecture it is ill suited for the needs of Grameen and other larger MFI's. This is because web-application is often quite slow and offers a lot less in usability for frequent users. It is for example difficult to use the keyboard navigation and control of the application. Another question is that a webapplication requires a web server. This makes the application more complex and possibly more costly since a separate server will often have to be installed. This cost can be offset if the server has many clients however. In the Grameen case and in many other developing countries it will be difficult to have many clients on the same server because the lack of network infrastructure. In Grameens case for example one server is needed in each Area office.
3.4.8 Aquadev
Aquadev [Aquadev, 2004] is a software package developed by the Aquadev foundation for the West-African region. It is not Open-source, but it can be used without licence cost in poor countries. However, it is not Open-Source. The organisation that wants to use the software has to contact Aquadev and pay for the installation costs. The architecture of Aquadev is however based on Open-source software. Here is a description of the architecture: WEB application type architecture Operating system : LINUX on the server and Windows/Linux on the workstations WEB server : APACHE SGBDR : POSTGRES Language : PHP Browsers : Internet explorer Netscape Mozilla.
The Aquadev documentation also mentioned that this software is possibly to adapt to different needs through the parameterization. For example the following things can be changed without programming: Holidays programming Page 54 of 141
Users/profiles and access configuration Agency configuration Savings product(s) configuration (unlimited number) Credit product(s) configuration (unlimited number) Accounting plan configuration
Comments Without having access to the software however it is difficult to say much about this architecture. The same problems with web-applications as for MOAP applies here as well. Another possible issue is that in general PHP-applications tend to be rather illstructured. Layered architectures, such as the one exhibited by MOAP, tend to be rare in the PHP environment. PHP-applications are also very often tied to a particular database, in this case PostgreSQL. This is a disadvantage. Especially since PostgreSQL is not the easiest database to use. To analyse these issues more thoroughly however requires access to the source code.
3.4.9 Compiere
Compiere [Compiere, 2005] is not a MIS-system specifically targeted at the MFI's. It is a full-featured general purpose MIS-system. It is however very interesting since it is Opensource and it has a very extensible architecture. Some important architectural features are: Structural changes can be done in runtime without programming Multi-lingual support Multi-currency support Multi-organization support Import/Export functionality Declarative validation Table-driven forms design Audit-trails Authorization
Comments These architectural features are very valuable and can normally only be found in expensive ERP-systems. They are very useful for producing extensible systems that are capable of being adapted to diverse situations and environments. Compiere however has some serious disadvantages as well: It is based on the proprietary Oracle database It requires a server and a network infrastructure It is a very complex product It takes a lot of time to learn how to extend it
In fact the possibility of using Compiere for the Micopa-project was considered. Some experiments were conducted to see whether it would be easy to configure it to support micro-credit operations. The conclusions from these experiments were that this is
Page 55 of 141
probably possible, but in order to succeed in this quite a lot of time needs to be invested in learning. Probably it would be necessary to participate in a course given by the Compiere company. In this project this was not possible to achieve because of the short time frame, for other projects however and for Grameen, this would be a very good alternative.
3.5 Guidelines on Architectural Design

In this section we describe our recommendations to Grameen on how to overcome the problems with their present architecture. This is done by referring to Architectural Styles, Design patterns, Pragmatic Programming practices and Security Architecture components. As a further more concrete and detailed illustration see also the description of the Client Architectural Prototype in chapter 2.
3.5.1 Addressing architectural quality problems with Styles and patterns

In general what Grameen needs to address their architectural problems is sound software engineering. Today the process is totally chaotic and there is no wonder that this leads to poor structured code that is hard to maintain. What is needed is a way to address the poor architectural qualities of Grameen Banker. Architectural Styles [Bass et al.,1998] is a way of doing just that. A Style can be seen as a tactic to achieve architectural qualities. Design patterns (see for example [Gamma et al., 1994]) are also useful tools for an architect to use when addressing modifiability problems. Some common patterns that are useful in this regard are: Model-View-Controller Strategy In the following list we present useful styles and patterns that can address the Grameen Bankers shortcomings:
Quality Modifiability Security
Styles/Patterns Modular design, Layered architecture, Model-View-Controller, Strategy Audit Trails, Access Control, Integrity checks
Modular design Modular design has been one of the cornerstones of software engineering for a long time. Yet, surprisingly, it is very often not achieved. In Grameens case this is probably due to lack of time, experience and lack of process design activities. So what is a module? Here is a definition:
Page 56 of 141
A module is a self-contained component of a system, which has a well-defined interface to the other components; something is modular if it is constructed so as to facilitate easy assembly, flexible arrangement, and/or repair of the components.(wikipedia search on module [WIKIPEDIA, 2005] In a Micro-finance perspective one module might for example be Loanee register. This component would then have a defined interface that would be used by other modules. This would make the application simpler to understand since all logic would have its place. If one need to change the Loanee register, for example to add some data that needs to be tracked for loanees, one only needs to change the Loanee register component. There is no need to go through the entire application. This would make the application easier to change. Exactly how the application needs to be split up into components is a complex question. This requires detailed a more detailed analysis of the entire Micro-finance domain. However, a basic rule of thumb can often be to have one module per database table (Provided that the database design is well done, something that has to be addressed first). This would then follow the Table Module design pattern [Fowler, 2002]. Layered architecture Using layers a common tactic to promote architectural qualities [Bass et al.,1998]. An application is then split up in different layers that each has its specific purpose. One of the most common examples of this is when you split an application into a User-interface layer, a Business logic layer and Database layer. In this way it is easier to make a change to one layer without affect the other. For example, a simple layout change in the userinterface will not affect the database layer. This also provides for better modifiability. This well-known example would be beneficial to follow also for Grameen. Model-View-Controller Model-View-Controller (MVC) [Bass et al., 1998] is a software pattern specifically targeting the design of user-interfaces. Since Grameen Banker mostly consists of userinterface component this pattern would also be good to follow in order to achieve a better structured application. The MVC-pattern is basically a description of how the Userinterface layer should interact with the business logic layer. Strategy pattern The goal of the Strategy-pattern [Gamma et al., 1994] is to make it possible to switch algorithms in runtime. E g, by using different Strategies one can change business rules in an application. This could for example be the way interest payments are calculated. By introducing the Strategy-pattern it thus becomes easier to modify the business logic of an application. It is common way to make software more modifiable. Frequently, the Strategy to use is also determined by configuration data, which means that business rules can be changed in runtime and not only by programming.
3.5.2 Addressing problems through Pragmatic Programming practices

Other tools for addressing the problems can not be classified as patterns, but just good practice. A useful reference when addressing these general issues is the book: The
Page 57 of 141
Pragmatic Programmer, [Hunt et al., 2000] The following practices stick out as being especially relevant to Grameen: Problem Bad structure Naming Poor separation of concern Practice DRY Don't Repeat Yourself, Make it easy to reuse It's all writing Separate Views from Models, Eliminate Effects between unrelated things, Refactor early, refactor often Build documentation in. Don't bolt it on
Poor code documentation
DRY Don't Repeat Yourself This practice is one of the most important in programming. Every piece of encoded knowledge should have only one representation in the software. If this is not the case, every time this knowledge changes, changes will have to be made at many different places. This leads to bad modifiability and poor structure. Make it easy to reuse A modular structure makes it easier to reuse components. Documentation is also important to support this practice. Its all writing With this practice is meant that good code should clearly communicate its purpose. Programmers should carefully choose their naming to communicate intent. Otherwise the code becomes very difficult to understand. Separate Views from Models This practice is mainly a call for using the Model-View-Controller pattern. Eliminate Effects between unrelated things This practice is basically a call for modularity and layering. Refactor early, refactor often The idea behind this pattern is that the first design that you come up with is not necessarily the best one. If it is felt that the design could be better it is necessary to change it as soon as possible. The longer you wait the harder it gets. Failure to do so will result in a system that is poorly structured and hard to modify. Build documentation in. Don't bolt it on Producing documentation for code is important. This however takes time, and it is often the case that when hurried changes are made, there is no time to also update the documentation. Therefore it is better to generate as much documentation as possible directly from the code. An example of this is Javadoc, a documentation system that is
Page 58 of 141
used in the Java-environment. Similar systems also exist for other languages. If it is deemed to time-consuming to produce documentation manually, an automatic system such as this can provide huge benefits.
3.5.3 Addressing Security problems with Security Components

It is quit clear from the above analysis that Grameen Banker has several serious flaws in it's security architecture. There exists several ways of addressing these with standard security measures. The following table lists these:
Security problem Lack of database security Lack of Audit trails
Security measure Implement secure access control to the database. This can be done with most modern databases Implement Audit trails. At least by logging all database transactions and who performed them and when. More advanced audit trails needs to be coded into the application. An Audit Trail component needs to be built. If a decision to use Compiere is taken the built-in audit-trail functionality can be used. Implement Operating System file systems access control. This is easily doable with any modern operating system staring from Windows NT. An upgrade needs to be done from Windows 95/98 to XP or Linux. Implement a Role-based Access Control scheme. A start has already been done with Grameen Banker 4.0. New programming frameworks, such as .Net or Python or Java can help here. The Compiere system also comes with out-of-the-box access control features.
Users can modify any file they want
Lack of fine-grained access control
Poor strength mechanism
of
authentication A more advanced Authentication components needs to be implemented. The easiest choice here would be to use the database authentication mechanisms of for example MySQL. If database portability is needed a new component would need to be constructed. Again, although not database independent yet, Compiere provides an example of this using hashed passwords and encrypted network communication.
Page 59 of 141
3.5.4 Architectural guidelines summary

The guidelines for a future Grameen Banker application can mainly be summarized as the application of sound design principles. The application needs to be considerably redesigned to improve its architectural qualities. This is a large effort, and to make it happen it is important to also implement changes in Grameens development process. Here is a summary of the general recommendations: Split the application into logical modules according to business functionality Layer the application into User-interface, Business logic and Database Organize the user-interface code according the Model-View-Controller pattern Organize business logic that needs to be configurable according to the Strategypattern so that they can be changed by configuration Study Pragmatic programming principles to improve the design of further versions
Security recommendations: Implement database security to prevent unauthorized access to data Put in place Audit Trails to track changes to data and allow for accountability. Possible easiest done at the database level Enforce access control on files through operating system features Increase the strength of the authentication. Possibly through use of database authentication features
3.6 Client Architectural Prototype

In order to test some of the proposed guidelines and in order to test the some of the opensource technologies, we implemented a small architectural prototype of a client application to support a small but relevant set of use cases. In order to find the requirements of a client application for a micro-finance institution we used the following sources of information: Grameen Banker 3.0 demo application from Grameen Communications[Grameen Banker Demo] Grameen Banker 3.0. User Manual[Grameen Banker Manual] Grameen Banker 3.0. MS Access database structure Meetings with a developer from Grameen Communications. Other micro-finance applications developed by Grameen Communications[Grameen Software] and other projects like MOAP[MOAP, 2005]
Grameen Banker 3.0 is architected as a one-layer Visual Basic 5.0 application. Forms are drawn in Visual Basic Studio and the Visual Basic code implementing the domain logic is inserted in the controls/widgets. The domain logic is implemented mostly via a thin layer of Visual Basic code that wraps SQL statements which are sent to the MS Access database and RecordSets[Microsoft Data Ctrl] are used to manipulate the results. Data-
Page 60 of 141
aware controls[Microsoft Data Ctrl] are used in the forms and it is therefore Visual Basic runtime that takes care of updating the contents of the fields in the form. Usually there is a one-to-one relationship between forms and database tables, i.e. for every table a form is created to update the data in it. Furthermore, database tables are created to store temporary and intermediate results (Appendix A Grameen Banker 3.0 Analysis). By analyzing the demo application (see Appendix A Grameen Banker 3.0 Analysis) we learned that it is very important for branch operators to be able to enter data in an efficient and quick manner. This is because they have to enter enormous amounts of data every day. That is to day, an application in which the operator has to enter data in a form for each of the members will not fulfil the requirements of the operators. After the analysis of the demo application and the aforementioned sources we came to the following to main requirements for the prototype: Branch operators should be able to enter data for loan collection in a grid that resembles as much as possible the loan collection sheet printed on paper that field operators take to the centres. Developers should be able to design data-entry forms graphically as they do now with Visual Basic.
3.6.1 Implementation Technologies

We surveyed available open-source technologies to develop an architectural prototype for a micro-finance client application in order to test the implementation of some of our recommendations on architectural design. Grameen Banker and most of the other MFI applications are developed in Visual Basic for the Microsoft Windows platform. This means that developers have a good experience with Visual Basic, MS Access and MS Windows. Besides, there is a great shortage of personal computer in developing countries and thus, it is very rare that computers can be exclusively dedicated to run MFI applications and are also used for other office tasks. Since the very beginning we saw that proposing the replacement of the operating system (Windows) for an open source one (GNU/Linux) was not a viable in the short or medium term because MFIs use other Windows applications on the same computers they run their accounting systems and requiring a switch to Linux would prevent them from running them. Therefore, our proposed technologies should be cross-platform in order to initially be able to run on Windows and, when a full migration to Linux can take place, be able to run also with minor modifications. Choosing an implementation language was a relatively easy task given the constraints we had: developers are experienced with a procedural Visual Basic programming paradigm the syntax of the language should be relatively similar to Visual Basic Page 61 of 141
developers are not used to C++ and its pointer and reference-based programming the programming language should support object-oriented programming the computers available are mostly of low computing power developers should be able to design visual forms in a similar way in which they do it in Visual Basic
3.6.1.1 Python We chose the programming language Python[Python, 2005] for the implementation of the architectural prototype. The main reasons behind our decision are: it has a clear syntax which is similar to Visual Basic it supports both the object-oriented as well as procedural programming paradigms it is a scripting language which makes it very apt for prototyping it has a wide variety of packages and add-on technologies that allow for the development of layered applications
C++ was discarded for being too different to Visual Basic and having a very steep learning curve. Java was not chosen mainly because graphical Java applications require a lot of computing resources which are not available at MFIs. The choice of programming language heavily determined the rest of the products and technologies we chose to implement the prototype (with the exception of the database server). 3.6.1.2 Qt Qt[Trolltech, 2005] is a complete C++ application development framework which provides source-code compatibility across the Windows, Mac and Linux platforms. This means that applications developed with Qt can be recompiled and run on all three platforms without having to change the source code. Trolltech is a Norwegian company founded by the creators of Qt to support their product. Up to now, development of open-source software was only possible on the Linux platform but in the upcoming Qt version 4 (to be released on the second quarter of 2005) development of open-source software will be also possible on the Windows platform. As mentioned before, Qt is not only a GUI toolkit but a full application framework, offering other development facilities like data-aware controls, XML processing and introspection. Nevertheless, we only used the GUI functionality that it provides because of our aim to build a prototype with a layered architecture we wanted to avoid the use of a single product that would cut across all layers. Furthermore, given that we did not use C++ as a programming language, we used PyQt[PyQt, 2005], which is a library that enables the use of the Qt framework from Python. Qt also provides a WYSIWYG form editor (QtDesigner) that stores the form definition in XML which can be later translated to Python code. It is worth mentioning that Qt also provides data-aware controls as Visual Basic so a full remake of Grameen Banker using Python + Qt with the data-aware controls would be pretty straightforward.
Page 62 of 141
Nevertheless, the new application would still suffer from the architectural deficiencies as the current one. We found documentation regarding the development of applications with Qt in the form of two books: C++ GUI Programming with Qt 3[Blanchette, 2004] and GUI Programming with Python and Qt[Boudewijn, 2001]. Only the latter focused on programming applications with Python and Qt. 3.6.1.3 SQLObject SQLObject[SQLObject, 2005]: an object-relational mapper that automatically bridges the data source layer with the domain logic layer. We create Python classes that represent the objects in our domain and they are persisted in the database. The big advantage with this technology is that we do not write SQL statements in the domain layer code and therefore, we make it independent of the database technology. 3.6.1.4 ReportLab Toolkit The ReportLab Toolkit [Report Lab]: an open source PDF library used for report generation. This is the only reporting library we found that can be used from Python and that is open-source. This toolkit plays the role that Crystal Reports play in Grameen Banker 3.0. Nevertheless, the ReportLab Toolkit lacks a visual report editor like the one offered by Crystal Reports.
3.6.2 Architecture
Given the guidelines on architectural design we implemented a small prototype to test some of the proposed technologies for the client application. The prototype has a layered architecture as show in Figure 4.1. The prototype also implements the Model-ViewController pattern for accessing, visualizing and modifying the entities of the domain (loan, members, products, ). Our main source of information for the development of this prototype was the book GUI Programming with Python and Qt[Boudewijn 2001] and a multi-user, open-source linguistic application called Kura[Kura, 2005]. One of the advantages of open source software is the possibility to read/modify and use existing software as long as one complies with the license of the software. Given that the license of the Kura application was GPL we decided to use its code and ideas in our prototype and thus the prototype is covered by the GPL license.
Figure 3.1. Architecture of the client prototype.
Page 63 of 141
For the implementation of this architecture in Python in the prototype, we followed the guidelines proposed in [Boudewijn, 2001] and in the Kura application. 3.6.2.1 Presentation Layer The primary purpose of this layer is to show data to the user of the application and to receive commands from the user. This layer is implemented as a Python module named micopagui. The visual forms in which users enter data are created and maintained with QtDesigner (see Figure 3.2). These forms (Views) are later compiled into Python code and more code is written to communicate the events gathered from the user to the application (Controllers). On Figure 3.3 we show the prototype showing purposes for a loan and a dialog to edit one of them. 3.6.2.2 Domain Layer In this layer is where the actual work is done. This layer contains the functionality to manage the entities and processes a micro-finance institution deals with (members, loans, payments, ...). See Section 3.5.4 Domain model for more detailed description of the domain model. The domain layer is implemented in a Python module called micopalib. One of the big advantages of having a separate module containing all the domain classes and business logic is that we can actually access them without having to go through a GUI and therefore, we can automate or add ad-hoc functionality to the application with independence from the GUI. 3.6.2.3 Object-Relational Mapping Layer This layer contains the functionality to communicate with the database in which the data is stored/persisted. Furthermore, SQLObject provides an implementation of a RecordSet that we use to pass data back and forth through the different layers. 3.6.2.4 Data Layer The data layer is stored in a MySQL database. Given that SQLObject has support for other database we also added support in or prototype to use a file-based database called SQLite[SQLite, 2005]. See Section 5.4 for further details on the technologies used in this layer.
Page 64 of 141
Figure 3.2. Designing forms in QtDesigner.
Figure 3.3. Management of purposes for loans.
Page 65 of 141
3.6.3 UML Domain Model
Page 66 of 141
4 The PDA application prototype

The purpose of the PDA application is to automate the loan collection process. Currently, Grameen Bank uses paper sheets to gather loan collection data. The data are then transferred manually to the Grameen Banker software running on a PC. With a PDA solution, data will instead be transferred by connecting the PDA to the PC. This PDA prototype application does not perform any other operations, like handling loan applications or extensive financial calculations. Since cost is an important issue to MFIs, the aim for the prototype application has been to make it capable of running on simple and inexpensive PDAs. When developing a PDA solution to be used in third world countries, there are some special aspects to consider. Costs are often crucial and a PDA solution could probably help in further reducing the administrative costs for MFIs. To keep the costs for a PDA solution down, choosing free or inexpensive technologies is often preferable. The solution should also be easy to use since the end users are often inexperienced with computer technology and training a large number of employees would be expensive. The needs for maintenance should also be considerably low as that also would add to the costs. Today, MFIs that have tried PDA solutions have developed their own applications. An open source solution available to all MFIs would not only reduce the costs for implementation, it would also probably result in a more widespread knowledge about how to develop and use the technology. Even if a well-functioning free software solution for PDAs would exist, the cost for the PDA itself is harder to overcome. However, nowadays PDAs with fair computing power that cost less than $100 exist, although that still is a considerable amount of money in this context. A PDA that is to be used in a third world country field environment should also be able to withstand heat, dust, shock and humidity. There are PDA models with a more ruggedized design, but they are also more expensive.
4.1 The loan collection business process

Using the PDA prototype application the loan collection process would start with the field worker downloading the collection sheet data from a PC to the PDA. When visting a center, installments for each group of the center are collected. If the expected installments are made, the field worker only needs to take a note of that. If the collected amount differs from the expected amount, the field worker needs specify how much each loanee has paid. Also, if a loanee does not show up at the meeting, the field worker should take a note of that. After collecting installments from all centers, the field worker uploads the updated collection sheet data to a PC.
4.2 Experiences from other PDA solutions

The idea of using PDAs for automating micro credit operations is not new and som MFIs have tried it, most of them in Latin American countries, [CGAP, 2005]. There is no such software available, either commercial or as open source, so the MFIs have developed their own solutions. The costs for developing the PDA solutions have ranged from $20 000 to $80 000 and the durations of the development processes have ranged from nine months to two years. The availability of an open source or even a commercial
Page 67 of 141
PDA software product would therefore give MFIs better opportunities to adopt a PDA solution for their operations. The MFIs who have tried PDA solutions agree on some guidelines when considering adopting a PDA solution [CGAP, 2005]: Leverage the use of PDA as much as possible the more of the operations that can be handled with the PDA, the better Start with a stable management information system (MIS) the best way is to use a PDA solution in addition to a MIS that is unlikely to need changes; changes in the MIS will probably affect the PDA solution as well Have relatively stable, proven loan products product changes will probably affect the PDA solution as well Ensure strong support from top management deploying a PDA solution is likely to generate needs for substantial changes throughout the organisation Have high speed access to MIS data fast and reliable network connections should be used for synchronization. Have capable MIS support the use of PDA solutions makes the access to technical support even more important Think through implementation issues carefully PDA solutions tend to raise issues such as accountability and the integrity of the employees and clients Define success upfront make clear what the expected results are from the beginning
Considering these guidelines, the PDA application prototype developed in this project takes a somewhat different approach. Only one business process the loan collection process has been implemented. Although it only aims to improve one business process, the adjustments needed to make it fit in with the current infrastructure and way of working will probably not be too extensive.
4.3 PDA Technology

The PDA application prototype was developed using Java 2 Micro Edition (J2ME) and the Eclipse integrated development environment (IDE). Although the application is platform independent, it is intended to be run on the Palm OS platform.
4.4 The PDA device

There are lots of different PDAs on the market today, ranging from quite simple devices with only a few megabytes of memory and processors running at 33 MHz to those with almost the same amount memory and processor speed as a PC. Most devices run on either the Palm OS operating system from PalmSource, Inc. or Pocket PC from Microsoft. There are also other, less common operating systems on the market. For example, there are some built on Linux. The aspects of selecting a PDA operating system are somewhat different compared to selecting a PC operating system. For PDAs, there are in most cases only one operating system that works for each device model. For example, Pocket PC can not be installed on a Palm device. Neither of Palm OS or Pocket PC is open source, but they are almost Page 68 of 141
always preinstalled or bundled with the devices. The cost of the operating system can be considered to be part of the price of the device, but except from that the only additional costs are for any possible upgrades.
4.4.1 Palm Tungsten C and other Palm OS devices

The PDA model used for testing the PDA application was the palmOne Tungsten C, which is one of the most recent and powerful devices running Palm OS. Some of is most significant properties include [palmOne, 2005]: 64 MB built in memory Palm OS 5.2.1 operating system 400 MHz Intel processor with XScale technology TFT color display with touchscreen and a resolution of 320320 pixels 1500 mAh rechargeable lithium ion/polymer battery Built in QWERTY keyboard and gamepad navigator button Expansion slot for Secure Digital (SD) or Multimedia Card (MMC) 802.11b Wi-Fi wireless networking Infrared and USB connectivity
Despite the built in keyboard, the device is about the same size as most other PDAs. This is one of the most powerful models and its specifications are well on par with devices running Pocket PC. Usually, Palm devices are less powerful than Pocket PC devices, but its operating system and applications require less power as well. For running the prototype application, or even a full-scale implementation, a simpler Palm device running the CLDC 1.0 and MIDP 1.0 compliant MIDP for Palm OS virtual machine would probably be sufficient. Since the costs are a very important factor in this case, being able to use cheap devices would be a great benefit. For example, the palmOne Zire 21 with a 136 MHz processor, 8MB of memory and a 160160 pixels noncolor display sells for $99 to be compared to the $399 Tungsten C. There are also other sorts of devices powered by Palm OS [PalmOS, 2005]. Sony offers the Cli line of PDAs, much like the devices from palmOne, but more exclusive. Symbol offers a line ruggedized Palm OS powered devices, although quite expensive and with rather poor specifications. palmOne also provides the Treo series of smartphones, who also have QWERTY keyboards. Garmin, a manufacturer of GPS equipment, makes Palm OS powered devices with built-in GPS receivers. The watchmaker Fossil makes a wristwatch that has a 66 MHz processor, 8 MB of memory and runs Palm OS 4.1.
4.4.2 Devices running Microsoft Pocket PC

Devices running Microsoft Pocket PC are typically more powerful and expensive than their palm counterparts, starting at prices about $250. Although, Palm and Pocket PC devices do not target the exact same markets; the Palm devices are by tradition considered to be more of digital calendars or phonebooks, while the Pocket PC devices are considered to be compact computers. Today, with devices like the Tungsten C, the difference in performance between the two platforms has become smaller, but there is still some sort of a cultural difference.
Page 69 of 141
There are lots of different models of Pocket PC devices, ranging from the $159 HP iPAQ rz1710 with 32 MB memory and a 203 MHz processor to more advanced devices like the $549 Asus MyPal A730W with 128 MB memory, 520 MHz processor and full VGA display resolution. There are also smartphones running Pocket PC [CNET, 2005]. For Pocket PC, applications are mostly developed with commercial tools like Microsoft eMbedded Visual C++ or eMbedded Visual Basic. Developing J2ME applications for Pocket PC does not seem to be as common as for the Palm OS platform.
4.4.3 The Simputer

The Simputer is a PDA-sized device running a version of GNU/Linux [Simputer, 2005]. The name Simputer stands for simple, multilingual and inexpensive peoples computer which is a good description of its purpose to overcome the digital divide by providing an inexpensive and easy-to-use computer for poor people in third world countries. The organization behind the Simputer, The Simputer Trust, is based in India and is registered as a charitable trust. Since it is based on GNU/Linux the operating system software is licensed under the General Public License (GPL). The Simputer Trust has also released the hardware specifications under a general public license, the Simputer General Public Licence (SGPL). The Simputer Trust does not manufacture any devices themselves, they only develop it and provide the specifications. A Simputer model that currently is on the market is the Amid Simputer designed and developed by PicoPeta and manufactured by Bharat Electronics (BEL), both Indian companies [Amida, 2005]. The Amida Simputers come in different models with both greyscale and color displays at prices from $240 to $480. Although these prices are still considered a bit too high for third world countries, the Simputers are intended to substitute full-scale personal computers rather than to just be used for personal information management. With 206 MHz processors and 64 MB of memory they have specifications similar to the more recent Pocket PC models. Applications for the Simputer can be developed in C/C++, Java, Perl or lisp for example. The Simputer could be an interesting alternative to Palm or Pocket PC devices, especially if heavier applications are to be run. However, considering all three technologies Palm OS, Pocket PC or the GNU/Linux based Simputer , one of the less expensive Palm OS devices seems to be the best choice for running a loan collection application. The main reason is the price since many devices will be needed, but also, there seems to be no need for the more computing power provided by the other devices.
4.5 Java 2 Micro Edition (J2ME)

This section is intended to give a brief description of what J2ME is, its most important architectural properties, its constraints and how it relates to other Java technologies.
4.5.1 Background
Java was at first intended to become a programming language mainly for networked home appliances. Even though home appliances have become increasingly computerized in recent years, there are still almost no such devices with network support. Realising the breakthrough for networked home appliances was not in the near future, Sun instead Page 70 of 141
targeted Java for the Web which turned out to be a huge success. Today, besides standalone applications and Web-based applets, Java is also widely used for enterprise applications. With J2ME, Sun somewhat brings back Java to its roots by making a programming language for small, networked devices with limited capabilities.
4.5.2 The position of J2ME in the Java 2 family

Based on different needs for different sorts of application, Sun provides three editions of its Java 2 programming language: Java 2 Enterprise Edition, J2EE: the most advanced and feature-rich version suitable for enterprise application with high requirements on networking, I/O and database features Java 2 Standard Edition,J2SE: a subset of J2EE targeted at simpler applications as the lack of some advanced features instead provides better performance Java 2 Micro Edition: a subset of J2SE with functionality applicable to mobile devices.
J2ME, like J2EE and J2SE, is platform independent and is supposed to run on different systems. J2ME-capable devices range from very simple cellphones complying to the minimum requirements to PDAs with almost the power of a PC. Therefore, some of the J2ME specification is fixed and applies to all devices, while other parts are defined with respect to a certain device.
4.5.3 Configurations
The set of available APIs are defined by configurations and profiles. A configuration defines a minimum set of APIs needed for developing programs for a range of devices. The configuration that applies to most wireless devices is the Connected Limited Device Configuration, CLDC, which specifies information about the needed capabilities [SAMS, 2001]: The subset of Java programming language features The subset of functionality of the Java Virtual Machine The core APIs required for mobile application development The hardware requirements of the wireless mobile devices targeted by the CLDC.
CLDC states some basic requirements on the devices hardware properties [SAMS, 2001]: At least 160 KB of memory available for Java - 128 KB of non-volatile memory for the Java Virtual Machine and the CLDC API libraries - 32 KB of volatile memory for the Java runtime system 16-bit processor Low power consumption Network connectivity of some kind
CLDC brings some limitations to the Java programming language itself as well, although
Page 71 of 141
the probably most important one the lack of support for floating point math is no longer a problem with version 1.1 of the CLDC [Sun, 2005].
4.5.4 Profiles
As the configuration describes the basic properties and requirements, the profile is a further specification on top of the configuration, providing a more device-specific set of APIs. It is worth noting that device specific in this case refers to a type of device rather than a specific brand or model. Suns Mobile Information Device Profile, MIDP, specifies requirements for device properties such as memory, input, display, networking. The following requirements apply to MIPD compliant devices [SAMS, 2001]: 8 KB of non-volatile memory for persistent storage in addition to the 160 KB of memory specified by the CLDC a keyboard or touchscreen for input, or both a screen with at least 96 by 54 pixels with an ascect ration of 1:1; color or greayscales are not requierd some sort of network connection; may even be slow and intermittent, for example a dial-up connection.
SUN has released two versions of their Mobile Information Device Profile: MIDP 1.0 and MIDP 2.0 where the later is backward compatible with the earlier. MIDP 2.0 provides some improvements over MIDP 1.0 such as enhanced user interface capabilities, improved security and connectivity to name a few [ONJava, 2005].
4.5.5 Java Virtual Machines for Palm devices

The Java Virtual Machine used for testing the PDA application on the Palm platform was the IBM WebSphere Micro Environment which supports the CLDC 1.1 configuration and the MIDP 2.0 profile. It is included for free with many of the recent Palm devices and is also sold separately for $5.99 [IBMWS, 2005]. For older Palm devices, Sun Microsystems provides for free MIDP for Palm OS that relies on the older CLDC 1.0 configuration and MIDP 1.0 profile [Sun, 2005]. Since the PDA application does not contain any code specific to CLDC 1.1 or MIDP 2.0, it would run just fine on a device with MIDP for Palm OS as well.
4.5.6 Alternatives to J2ME

There are several alternatives to J2ME for developing applications for Palm devices. The most common language for writing Palm applications is C/C++, but there are other languages as well. Both commercial and open source alternatives exist.
4.5.7 Creating native applications in C/C++

Palm provide SDKs both with the 68K APIs for developing applications for the older and current Palm devices with Palm OS versions up to 5.X as well as the Protein APIs for the new and upcoming devices running the next generation of Palm OS. The new versions of the operating system will be backward compatible with applications created with the
Page 72 of 141
68K, so if the features mentioned above are not necessary, the 68K APIs will probably do. Palm also provides the Palm OS Developer Suite which integrates Palm OS SDKs into the open source Eclipse IDE [PalmDS, 2005]. Two other common C/C++ compiler suites targeting the Palm platform are PRC-Tools [PRC, 2005], which is free and based on the GNU Compiler Collection (GCC), and Metrowerks Code Warrior, a commercial IDE [Metrowerks, 2005]. They are both compliant with the language part of the ISO C standard and almost compliant with the ISO Standard for the C++ language, but lacks the complete libraries of C and C++. Besides the loss of platform independence, there are some advantages of writing native applications in C/C++ rather than J2ME. Because the C/C++ implementations are made especially for the Palm platform, they provide better performance since they do not need to run on top of a virtual machine. They also provide better integration with Palmspecific technologies such as the HotSync synchronization technique, Palm databases and the Palm GUI.
4.5.8 AppForge Crossfire

There are also tools for other languages, like the AppForge Crossfire technology that allows developers to write applications using Microsoft Visual Studio in for example C#, Visual Basic 6 or Visual Basic .net [Appforge, 2005]. Like with J2ME case, applications developed using AppForge Crossfire run on several different device platforms including Symbian-based smartphones, Palm OS, Pocket PC and Smartphone versions of Microsoft Windows Mobile. Also somewhat like J2ME, AppForge Crossfire applications require a Crossfire Client file to be installed on the target device to run applications. The client files have quite large footprints from 500 KB up to 1.3 MB depending on the target device. The Crossfire Client is available even to the simpler Palm devices such as the Zire models and the older Palm III. The client is available at $25 or as a free 15-day trial. The AppForge Crossfire is a commercial product and a license costs around $1000. For developers familiar with Microsoft Visual Studio, C# and Visual Basic, AppForge Crossfire might be a nice choice; although the license costs can be high if many licences are needed.
4.6 The Eclipse and J2ME Wireless Toolkit development tools

For developing the PDA application prototype, the J2ME Wireless Toolkit (J2ME WTK) was used in combination with the Eclipse integrated development environment (IDE) and the EclipseME plugin for J2ME development.
4.6.1 J2ME Wireless Toolkit

The J2ME Wireless Toolkit is a set of tools specifically for J2ME. One of the most important parts of the J2ME WTK is the emulator for test-running J2ME applications. The emulator can be configured by changing parameters and using different graphical skins to simulate different types of devices. The J2ME WTK comes with a set of different emulator profiles for a variety of cell phones or PDAs, most of them fictitious but quite typical.
Page 73 of 141
There is also the KToolbar application which provides a convenient graphical user interface for building and launching J2ME applications in the emulator, instead of using the command line interface. Besides from the emulator and the KToolbar, there are also a number of utilities for managing and monitoring different aspects of the J2ME environment like network, memory and mobile databases used by the emulator.
4.6.2 The Eclipse development environment

Eclipse is an open source software development project dedicated to providing a robust, full-featured, commercial-quality, industry platform for the development of highly integrated tools [Eclipse, 2005]. The Eclipse IDE is open source and is licensed under the common public licence. It provides building blocks and a foundation for constructing and running integrated software-development tools [Eclipse, 2005]. Examples of tools that can be integrated with the Eclipse IDE are CVS for version control, JUnit for unit testing and the Ant build tool. The Eclipse IDE reminds a lot of other IDEs, like for example Microsoft Visual Studio or Sun Java Studio, with a project view and views for editing and output. Eclipse also has features like code completion and debugging with variable tracking. The Eclipse IDE is mainly targeted at Java development, but there are also tools for C/C++ and COBOL for example. When developing the PDA prototype application, the EclipseME plugin was used, which provides J2ME support for the Eclipse IDE [EclipseME, 2005]. Developing applications with the Eclipse IDE and the EclipseME plugin proved to be much more convenient than using the tools that come with the J2ME Wireless Toolkit. Applications under development can also be launched directly from the Eclipse IDE buy pressing a button an application is built and run in the emulator. As Eclipse is quite extensible and written in Java, it should require a rather powerful computer to run properly. A bit surprising, when developing the PDA application prototype, it proved to run fairly smooth on a 500 MHz Pentium III PC with 256 MB of memory running Microsoft Windows XP.
4.7 Architecture
Considering the aspects described in section 2.4, the PDA application architecture can be described as: Structure Some methods are rather extensive and complex, although they have been split up and placed in the classes they affect. For example, initially there was only one serialization method handling the serialization for all classes representing business data; recently, this method was split up into smaller methods and put into the classes they concern. Inheritance was considered for the classes representing the business data, but was abandoned because the classes turned out to be too different. Naming The ambition has been to use names that are logical and consistent rather than as short as possible. Page 74 of 141
Documentation Besides what is found in this document, the code has been commented in most cases. Database design There is no real database system involved with the PDA application. The data is stored in the record management system (RMS) that comes with J2ME. Since this RMS is quite simple and there are not too much data to be dealt with, all the data are always stored or retrieved at the same time. Selection of particular data is then performed through the objects that are regenerated from it. Separation of concerns The GUI is separated from the business logic as far as was considered possible. The methods handling the GUI are put in the main class of the application; almost no other functionality resides there. Methods concerning business logic and serialization are put in the classes that represent the business data they affect. Functionality for synchronization and persistent storage is put in one of the classes representing business data. Modifying the application will probably require quite good insight about the design since the modularity is limited and many of the methods probably must me modified if changes are made.
4.7.1 The classes of the MiCOpA MIDlet

The PDA application MIDlet consists of nine classes with different purposes. In short, there are classes for handling the business data model, a set of classes implementing a linked list, a class for running synchronization in a separate thread and a main class that handles the application lifecycle and the user interface.
4.7.2 The MiCOpA class

The class MiCOpA is the main class of the MIDlet and contains methods for controlling the lifecycle of the application startApp(), pauseApp() and destroyApp(). It also contains methods for generating the graphical user interface (GUI). The constructor of the MiCOpA class creates the commands that appear in the GUI, a Display object that represents the devices screen and an instance of the Branch class that is the top of the business data hierarchy, but also provides the synchronization and storage functionality. Seven methods implement the GUI: createBranchScreen() the screen shown at startup, shows sub totals for all the data stroed in the device and allows synchronization and load operations createCentersScreen() shows a list of centers createCenterDetailsScreen() shows the details of a selected center createGroupsScreen() shows a list of groups within a selected center createGroupDetailsScreen() shows the details of a selected group createLoaneesScreen() shows a list of loanees within a selected center createLoaneeDetails() shows the details for a selected loanee and allows entering loanee data
All these methods return a Screen object that can be passed as an argument to the Display.setCurrent() method in order to change screen. Screen changes are in most cases Page 75 of 141
initiated by a commandAction() method that belongs to one of the screens. Other than creating different screens, functionality like manipulating the business data or synchronization has been placed outside the MiCOpA class. The only exception is the getServerAddress() method that retrieves a URL stated in the application properties.
4.7.3 The LinkedList class

The LinkedList class is an implementation of a linked list that in this case is used for containing the lower levels of the hierarchy of business data objects, for example the groups within a center. The LinkedList class and its related classes, ListNode and LinkedListItr, were found on the Internet but have been slightly modified [Hunter, 2005].
4.7.4 The ListNode class

TheListNode class has two data members a reference to the next list node and an object of the class Object, where the data of the node is to be stored. Since Object is the general super class of all classes, objects of any class can be stored. The only thing to remember is that when the object of a list node is retrieved, it is considered to be an instance of the Object class, why type casting might be necessary. The ListNode class has no methods.
4.7.5 The LinkedListItr class

The LinkedListItr class implements a list iterator with a header node. The class contains a ListNode and some methods, of who the two most important are the retrieve() method that returns the data stored in the node and the advance() method that iterates to the next node of the list.
4.7.6 The Sync class

The purpose of the Sync class is to run synchronization in a thread separate from the rest of the application, since http communication might cause the application to halt for some time if something goes wrong. The class implements the Runnable interface and is called from the MiCOpA class. The only method of the class is the run() method that calls the synchronization methods of the branch class. This is further described in section 4.8.
4.7.7 Classes representing the business data

Four classes represent the business data model the Branch, Center, Group and Loanee class. The business data model is further described in section 4.8. Although inheritance is not implemented since there are differences in how their methods are implemented, these classes have some data members and methods in common. Common member variables: disburse integer representing the total amount borrowed or lended repaid integer representing the amount that has been paid back balance integer representing the current debt performedLoanInstallment integer representing the loan installment actually collected expectedLoanInstallmen integer representing the loan installment expected to be collected performedInterestInstallment integer representing the interest amount actually collected Page 76 of 141
expectedInterestInstallment integer representing the interest amount expected to be collected
Common methods: regenerate() regenerates the levels below in the hierarchy, i.e. a call to the regenerate() method of the Branch class builds the whole hierarchy (the Loanee class does not have this method) serialize() returns a string containing the data of the object and the lower levels of the hierarchy, i.e. a call to the serialize() method of the Branch class returns a string containing the data from all the objects These methods are further described in section 4.9.
4.7.8 The Branch class

The branch class represents the top of the business data hierarchy. Except from data representation, it also handles the synchronization and storage functions. These processes and methods are described in section 4.9. In addition to the common member variables, the Branch class has a linked list containing all the centers, a RecordStore object for referencing the record store and a string for storing the server address.
4.7.9 The Center class

The Center class represents the center level as described in section 4.8. Besides the common methods and member variables, it contains two string variables containing the center code and the collection date. It also contains a reference to an instance of the Branch class and a linked list containing the Group objects below in the hierarchy.
4.7.10
The Group class
The Group class represents the group level as described in section 4.9. Besides the common methods it has a method fullInstallment() that is initiated from the GUI to specify that the expected loan and interest installments for the loanees of the group have been made. In addition to the common member variables, it has a string variable for the group name, a reference to the center it belongs to and a linked list containing the Loanee objects below in the hierarchy.
4.7.11
The Loanee class
The Loanee class represents the loanee level of the hierarchy. It has all the common member variables and methods, except the regenerate() method since it represents the bottom level of the hierarchy. It has three string variables for the loanee name, the loanee number and the purpose of the loan. It also has an integer variable that states whether a loanee was absent at the loan collection meeting. There are also some additional methods. The updateDataFields method is called from when data is entered in the GUI and adds the entered values to all objects that are affected throughout the whole hierarchy. The setLoaneeAbsent() method is used to specify if a loanee was absent or not by passing a Boolean argument to it. The reason behind this method is that the GUI provides a Boolean value while an integer value is preferred in order to make serialization easier.
Page 77 of 141
4.8 Object-oriented structure

The business data and the relationships between them are mapped to a hierarchial structure of objects of different classes representing the levels of the hierarchy.
4.8.1 The relationships between the business data

The business data the PDA prototype application needs to be able to represent are derived from the original paper loan collection sheet used by Grameen Bank. The loan collection sheet implies that the business data can be organized in four levels, from bottom to top: A loanee is a person who has borrowed money from Grameen bank A group consist of about five loanees who to some extent share the responsibility for their loans A center is where a set of groups meet for loan collection sessions; the term center in this case represents this set of groups A branch is an office that organizes a set of centers; the term branch in this case represents this set of centers, or a subset of it. In short, loanees are members of a group, which in turn belongs to a center that is organized by a particular branch. These one-to-many relationships are shown in figure 4.1.
Branch 1 * Center 1 * Group 1 * Loanee
Figure 4.1: The one-to-many relationship between the hierarchial levels.
The table of figure 4.2 shows an example of a fictitious loan collection sheet based on the sheets that are used by Grameen Bank. The sheet contains a branch with two centers, each containing two groups with two loanees.
Loanee No. Loanee Name Purpose Disburse Repaid Balance Expected Loan Installment Performed Loan Installment Expected Interest installment Performed Interest Installment Loanee Absent
The Branch Center 1 Collection Date: 01/01/2005 Group 11 Full Installment: 111 Adam Aluminum 40000 112 Bertil Boron 20000 Group 11 sub total 60000 Group 12 Full Installment: 121 Cesar Carbon 30000 122 David Dubnium 10000 Group 12 sub total 40000 Center 1 sub total 100000 Center 2 Collection date: 01/02/2005 Group 21 Full Installment: 211 Erik Europium 24000 212 Fredrik Fluorine 96000 Group 21 sub total 120000 Group 22 Full Installment: 221 Gustav Gallium 60000 222 Harald Hydrogen 20000 Group 22 sub total 80000 Center 2 sub total 200000 The Branch sub total 300000
24000 12000 36000 18000 6000 24000 60000 14400 33600 72000 36000 12000 48000 120000 180000
16000 8000 24000 12000 4000 16000 40000 9600 62400 48000 24000 8000 32000 80000 120000
8000 4000 12000 6000 2000 8000 20000 1200 4800 6000 3000 1000 4000 10000 30000
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
800 400 1200 600 200 800 2000 120 480 600 300 100 400 1000 3000
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Figure 4.2: Example of a fictitious loan collection sheet.
Page 78 of 141
The data represented in the PDA application are almost the same as in the original loan collection sheet, although some modifications are made. For example, the PDA application only keeps track of one week of collections since the data are assumed to be synchronized rather often. Also, two boolean fields are added; Loanee Absent is checked if a loanee does not show up for a collection gathering; Full Installment is checked if a group has fulfilled their instalments and no further specification is necessary. As implied by the sheet, there are seven fields that are common to all levels of the hierarchy: Disburse the total amount borrowed or lended Repaid the amount that has been paid back Balance the current debt Performed Loan Installment the loan installment actually collected Expected Loan Installmen the loan installment expected to be collected Performed Interest Installment the interest amount actually collected Expected Interest Installment the interest amount expected to be collected
For the branch, center and group levels, these values represent the sub totals of the lower levels. There are also some fields unique to the different levels, for example the centers need a field for the collection date, the date when the loan collection will take place; the groups need a field Considering the relationships shown in figure 4.1, the relationships between the data of the example loan collection sheet in figure 4.2 can be shown as the tree structure in figure 4.3.
Branch level
1 The Branch
Center level
2 Center 1
9 Center 2
Group level
3 Group 11
6 Group 12
10 Group 21
13 Group 22
Loanee level
4 111 Adam 5 112 Bertil 7 121 Cesar 8 122 David 11 211 Erik 12 212 Fredrik 14 221 Gustav 15 222 Harald
Figure 4.3: The relationships between the data shown as a tree structure.
Page 79 of 141
4.8.2 The object model

The hierarchy can be represented as an object model of four different classes: the Branch, Center, Group and Loanee class. Each class consists of member variables containing the business data, a reference to the object in the level above in the hierarchy and a linked list containing the objects below in the hierarchy. For example, considering the structure of figure 4.3, the Center object representing Center 1 would have a reference to the Branch object representing The Branch and a linked list containing two Group objects representing Group 11 and Group 12. In this way, the structure can be traversed in Java by using the dot operator to access objects above in the hierarchy or by retrieving objects from the linked list containing the objects below in the hierarchy. Data is mostly entered into the Loanee objects and then added to the sub total values of its related group, center and branch. Even though the classes are quite similar both with respect to the member variables and methods, inheritance has not been applied. The methods of the classes provide almost the same functionality, but had to be implemented rather different. Also, the Center and Group classes have much in common while the Loanee class requires less functionality since has no levels below it in the hierarchy. The Branch class also has methods to handle synchronization and persistent storage, which the other classes do not need.
Page 80 of 141
4.8.3 UML class diagram of the PDA application prototype
Figure 4.4: UML diagram of the PDA application prototype..
4.9 Synchronization and persistent storage

Before the data that are stored in the objects can be synchronized to a PC or stored in persistent storage it has to be serialized, i.e. the data has to be represented in some sequential form. Therefore, functionality both to serialize objects and to regenerate objects from serialized data is needed. Fortunately, the techniques for synchronization and persistent storage can use the almost the same form of serialized data, only minor adjustments are needed.
Page 81 of 141
4.9.1 Serialization
Data needs to be serialized to be synchronized with a PC or saved to persistent storage. Unfortunately, J2ME does not provide any serialization techniques such as the serializable interface that comes with J2SE and J2EE. It turned out that a fairly easy solution in this case was to put all the data stored in the objects in a single string. The string can then easily be sent over a network connection or stored in persistent storage. Of course, the application also needs to be able to regenerate an object structure from a string containing data received from a connection or retreived from persistent storage. In serialized form, each object is represented by a starting tag followed by the object data. The starting tag indicates the type of object that follows next in the string; Center, Group and Loanee starting tags are <C>, <G> and <L> respectively. The Branch class has only one instance and its data is placed first in the the string without a preceding starting tag. All tags and data are separated by a ;-character. To serialize the object structure, a call is made to the Branch objects serialize method. The method creates a StringBuffer to which it first appends the Branch objects own data separated by ;. Then, the serialize() method iterates through the Branch objects linked list of Center objects and makes calls to their serialize() methods and appends the strings they return to the string buffer. The serialize() methods works in about the same way for all the classes representing business data. In this way, the structure gets traversed in a depth-first manner in the order indicated by the numbers next to the objects in figure 4.3. A call to the serialize() method of the Branch object in the example would generate a string with the structure described in figure 4.4.
The Branch data 1;;The Branch data n; <C>;Center 1 data 1;;Center 1 data n; <G>;Group 11 data 1;;Group 11 data n; <L>;Loanee 111 data 1;;Loanee 111 data <L>;Loanee 112 data 1;;Loanee 112 data <G>;Group 12 data 1;;Group 11 data n; <L>;Loanee 121 data 1;;Loanee 121 data <L>;Loanee 122 data 1;;Loanee 122 data <C>;Center 2 data 1;;Center 2 data n; <G>;Group 21 data 1;;Group 21 data n; <L>;Loanee 211 data 1;;Loanee 211 data <L>;Loanee 212 data 1;;Loanee 212 data <G>;Group 12 data 1;;Group 11 data n; <L>;Loanee 221 data 1;;Loanee 221 data <L>;Loanee 222 data 1;;Loanee 222 data
n; n; n; n;
n; n; n; n;
Figure 4.5: Example of a string of serialized data.
To make the string in figure 4.5 more readable, line breaks and indentation have been added.
Page 82 of 141
4.9.2 Regenerating objects from serialized data

Regenerating an object structure from a string of serialized data is performed in two steps by calling two methods of an empty Branch object, i.e. where no data has been set. First, the string has to be parsed into substrings, or tokens, by calling the tokenize() method. The string of serialized data is passed as an argument and the method returns a linked list containing all the tokens that were separated by ;. After the list of tokens is created, a call is made to the regenerate() method of a Branch object. The method first fills the data fields of the object with the data from the first few tokens of the list. Then, continuing iterating the list of tokens, the linked list of the Branch object containing Center objects is created. When creating Center objects, the method continues to iterate the list of tokens looking for a <C> starting tag followed by the Center object data. When the first Center object is created and its data fields are filled, a call to the newly created Center objects regenerate() method is made. Two arguments are passed: the list of tokens and an iterator pointing out the current position in the list of tokens. The regenerate method of the Center class continues to iterate the list of tokens from the current position and keeps looking for a <G> starting tags. When a <G> starting tag is discovered, a Group object is created similar to when a Center object is created. Loanee objects are also created in a similar way. When the regenerate() method of the first Center object is finished, it returns an iterator updated to the current position in the list of tokens. As the execution of the regenerate() method of the Branch object then proceeds, new Center objects are created as long as new <C> starting tags are discovered.
4.9.3 Synchronization
Synchronization to and from a PC is performed over an http connection to a web server running a Java Servlet that stores the string of data in a single text file. When downloading data, for example before collecting installments, the servlet simply reads the file and sends the contents to the PDA application. When uploading data to the server, for example after collecting instalments, a string of serialized data is sent to the servlet which replaces any old text file with a new one containing the received string. The servlet acts to send data if no parameter comes with the http request. If it receives a parameter data containing a string of data, it acts to save the string as described above. The text file can then be manipulated in order to exchange data with an application on a PC. Two methods in the PDA application handle the synchronization the downloadData() and the uploadData() method of the Branch class. The downloadData() method simply makes an http request without any parameters, regenerates the object structure as described in the section above and saves it to persistent storage. The uploadData() method works similar to the downloadData() method but sends a parameter data containing a string of serialized object data. The string of object data is first URL encoded as it probably will contain whitespace for example.
Page 83 of 141
Due to the nature of network connections, these methods are run in a separate thread to avoid the device from locking when a connection fails. Synchronization is initiated from the GUI when the user chooses to perform a download or an upload operation. The CommandListener creates a new thread running new instance of the class Sync that implements the Runnable interface. When the Sync object is created, two arguments are sent to its constructor: a Branch object for which the synchronization is to be performed, and an integer to indicate if a download or upload operation is to be performed. Two integer values are defined in the Sync class, DOWNLOAD and UPLOAD, and can be accessed as Sync.DOWNLOAD or Sync.UPLOAD when creating the Sync object. When the thread starts, the Sync objects run method calls the downloadData() or uploadData() method of the Branch object, depending on the value of the integer argument.
4.9.4 Persistent storage

The only way to store data persistently with J2ME is by utilizing the MIDP Record Management System (RMS) that comes with the package javax.microedition.rms. An RMS record store can be considered as a simple database with only one table of two columns; one for the record IDs that serves as primary keys and one for the data. The record ID for a record is an integer value and the data is stored as an array of bytes. The RMS package defines the RecordStore class, which represents a record store, and some useful interfaces used for example to enumerate, compare or filter records. Hence, to save a string of serialized object data, it first has to be converted to an array of bytes. Fortunately, the Java String class provides functionality for this. The data is in this case stored as a singe record. Two methods of the Branch class handle the storing and retrieving of data from persistent storage the loadData() and saveData() methods. The loadData() method simply retrieves the one and only record from the record store, converts it to a string which it passes to the regenerate method to create the object structure. The saveData() method makes sure that the record store is empty, calls the serialize method to get a string of serialized data. The string is then converted to an array of bytes which is stored in the record store by calling the RecordStore.addRecord() method. Retrieving data from persistent storage is transparent to the user and is performed automatically when the application is started, given that there are any stored data. Data are saved when leaving an input screen by using the Save command.
4.9.5 Other solutions to synchronization and persistent storage

When developing the PDA prototype application, no packages or libraries other than what comes with Suns J2ME Wireless Toolkit have been used, but there are some that were considered. Most of them are open source, which is preferable in this project. However, if a full scale application is to be developed, it might be a good idea to reconsider using these techniques since many of them provide very useful features that are also proven to work well.
Page 84 of 141
4.9.6 The db4o object oriented database system

An interesting alternative to the solution described above could have been to use the open source object oriented database db4o from db4objects [5]. The db4o is a lightweight object oriented database system native to java and comes as a single .jar file of 300 KB. The big advantage of using an object oriented database is that the object model would not need to be converted for persistent storage because the class model is the same as the database schema. Unfortunately, it turned out that db4o stores its data in a file, which is not supported by J2ME why db4o can not be used in this case.
4.9.7 Nextels RMS toolkit

Nextels RMS Toolkit is open source and provides classes for record management [Nextel, 2005]. The toolkit relies on the J2ME MIDP RMS, but operations are instead performed via record objects built on top of the more primitive byte array operations. It also provides the possibility to cache records in memory in order to increase performance, but at the cost of heavier memory use. The toolkit also has functionality to insert or retrieve arrays of records, instead of for example use the RecordEnumeration for browsing a record store. Although the J2ME MIDP RMS was sufficient as-is for the prototype, Nextels RMS Toolkit seems very interesting for developing a full scale application, especially since it also provides mechanisms for synchronization via http.
4.9.8 Sync4j
Sync4j from Funambol is a platform for mobile applications that relies on the SyncML standard for exchanging data, especially suitable for devices that are only sometimes connected to a network [Sync4j, 2005]. SyncML utilizes XML and is supported by big actors such as Ericsson, Nokia Motorola and Symbian. Both Sync4j and SyncML are open source, but commercial applications based on Sync4j require a commercial license. Sync4J or other tools based on XML such as kXML could be good choices when developing a full-scale application as they provide a more standardized data format [kXML, 2005].
4.9.9 J2ME and the Palm HotSync technology

Native Palm applications usually synchronize their databases through the HotSync technology which lets the user synchronize by just putting the device in a cradle connected to a PC and press a button. Unfortunately, this is not supported by J2ME as a backside of its platform independence, and neither does Palm provide any proprietary solutions for this. However, since the J2ME MIDP RMS maps almost exactly to Palms implementation of persistent storage, it is possible to trick HotSync into synchronizing a J2ME database as well [Biech, 2005]. This is done by writing a conduit, an application on the PC side used by the HotSync technology, which carefully manipulates the database. The differences lies in how the header values are set. When creating a J2ME MIPD RMS database, the only header value that can directly manipulated is the name of the database. In order to fit both the J2ME MIPD RMS and Palms system for record databases, the database is created by a conduit that is able to manipulate all the header fields to suitable values.
Page 85 of 141
However, it seems unclear how stable a solution like this would be since J2ME MIPD RMS databases are not supposed to be synchronized using the HotSync technology in the first place.
4.10 PDA Security

No security functionality has been implemented in the PDA application prototype, but there are some aspects that should be considered if a full scale application is developed. The palm devices provide access control to some extent since the user can set the device to require a password each time it is stated or returned from standby. Another option is to let the application require a password each time it is launched. The password could maybe serve as a key for encrypting/decrypting the application data. Encryption might also be a good idea if data is to be sent over a network instead of synchronized directly with a PC. Integrity could also be an issue for example if the device looses power while data are being stored to persistent storage. Therefore, maybe it could be a good idea to insert some kind of rollback functionality to ensure that such operations are atomic. There is also not yet any functionality to tell the user whether synchronization has succeeded or not. This could be hard to find out, especially if synchronizing from a distant location over a network. One way to solve that would be by calculating some sort of checksum that is sent back and compared with the original data.
4.11 Human computer interaction (HCI) aspects

When developing the PDA prototype application, some special aspects had to be considered. As compared to a PC application, the lack of screen space is probably the most obvious limitation, but also the limitations of the input devices, network availability and the power consumption of the device need to be taken into account. Besides from the characteristics of the PDA devices, the users skills needs to be considered; in the area of work, technology and, in this case, English as a foreign language. The first idea of the GUI layout of the PDA prototype application was to adopt some sort of table where lots of information could be shown at the same time. This design would probably, at least initially, have been appreciated by the end users at Grameen Bank as it resembles the paper loan collection sheets that currently are being used. However, due to both the limitations of the PDA screens and the J2ME GUI APIs, this type of design was abandoned in favour of a more list-like design. As the loan collection sheets currently being used at Grameen Bank are in English, the end users are expected to have quite good skills in both English and their area of work. However, this might not be the case for other MFIs; not all developing countries may have such a widespread knowledge of English, and the personnel of new MFIs may not be very skilled in the area of work. The technical knowledge may differ a lot among the end users since knowing about how to use computer has not been necessary to fulfil their work so far. In order to not Page 86 of 141
complicate the use for those who are not accustomed to the technology, technical terms and operations have been avoided as far as possible. The most common input device of PDAs is a touch sensitive screen accompanied with hand writing recognition software and a pen to write on it. Learning how to use this technique often takes some time and effort for anyone who tries it. In the case of the PDA prototype application, mostly only numbers need to be entered, which is often rather straight forward on most PDA devices. However, there are devices with other input technologies such as speech recognition or miniature keyboards that could be used, but they are often more expensive. When designing the GUI of the PDA prototype application, the starting point was to develop a paper prototype showing the layout and navigation structure. Since the GUI was not to be very extensive, almost all of it was designed in detail from the beginning. After revising the paper prototype, an experimental implementation of the application was developed, containing the GUI but no underlying logic at all. That code was later discarded when creating the full PDA prototype application, but the GUI design was similar, and important lessons were learned from writing it. When developing the full PDA application prototype, the logic was first created and the GUI could then easily be built on top of it. The paper prototype and some sample screenshots can be found in appendix D of this document. The need for network availability is also often discussed in the context of HCI. The PDA prototype application is designed to use a network connection on a sometimes-basis; the user synchronizes the device with a PC, collects data in the field, and then synchronizes the device again. Synchronization is expected to be performed on a daily basis, and the devices batteries could probably be recharged at the same time as well.
Page 87 of 141
MiCOpA
5 Technology
5.1 Definition of Technology
By technology is meant which specific off the shelf, commercial or Open-source, products and platforms that can be recommended for Grameen or other Micro-credit institutions. In this chapter we provide a brief overview of the current technology used in Grameen Banker 3.0 and an in-depth review of our proposed technology for the database layer: MySQL. For a more detailed explanation of the technologies used on the PDA prototype and the architectural client prototype please refer to Chapter 4 and Section 3.6 respectively.
5.2 Analysis and Evaluation of Current Technology

The current Grameen Banker is built on the MS Access database. There are many limitations of the Access database. Actually Access is only suitable for some pretty small desktop database work, but on a practical basis, it is entirely unsuitable for any task where there will be more than a half a dozen concurrent connections on a regular basis [TAA, 2005]. Users of MS Access database has faced a lot of difficulties when increasing the number of users, database and when using the database in any web application. The limitation of the Access database is described below: 1. Performance degradation with number of increased concurrent users. Apart from the theoretical value that MS says about the possible concurrent connections, users have been reported to face serious performance problem when the number crosses more than half a dozen of concurrent users [Macromedia, 2005]. 2. The number of users depends on the load and the size of the database. 3. The common problem of Access in a Web environment is that the database files get corrupted besides the poor performance of the application. 4. Even though the security in Access database has been made improved a lot from the Access 95 to Access 2000, but it is based on the user groups and assigning permissions directly to users make database administration complex. Besides the security hole still exists from Access 95 to Access 2000 and some one who knows about it can very easily get into the forms, modules, reports and macros [FAQ, 2005]. Even Microsoft itself does not suggest for use Access when security concerns are stronger and they recommends server database in that case [FAQ, 2005].
5.3 Analysis of the Current GBanker 3.0

The purpose of the analysis of the Grameen banker 3.0 is to understand the business logic, domain knowledge of microcredit operations and the requirements for further improvements in managing the information system. In order to propose a prototype that supports the Grameen Banks Operation more efficiently we investigate the current solution to find out its limitations, drawbacks, advantages and disadvantages. We study
Page 88 of 141
MiCOpA
the Grameen Banks business logic, requirements and future development issues so as to incorporate them in the proposed prototype. We have investigated three sources simultaneously in order to analyze the GBanker, they are: Grameen Banker 3.0. Visual application: menu options, forms and fields. MS Access database Grameen Banker stores it's data in. Grameen Banker 3.0 User Manual [2]. As the application has several modules and the MS Access database consists of many tables, the full analysis description is long and is not included here therefore. The complete description is attached as Appendix A; here we will discuss only the summary of the analysis to find out the main functionalities, drawbacks and redundancies in the system.
5.3.1 Main Functionalities

Grameen Bankers main function is as described in the Grameen Banker Manual by the Term Branch Loan monitoring System (BLMS). The small amounts of loans that are disbursed to the poor are monitored in the following ways: 1. Daily Loan disbursement: the amount of loan disbursed daily from a branch 2. Daily loan Collection: the entry of all loan payments collected daily in a branch. 3. Daily Savings Collection: entry of all savings collection from the GB members. The operations are performed at different level of the organization which is divided into different sections and braches dispersed in the remote rural areas. The organizational graph [2] of the Bank is shown below.
Figure A.1. The Grameen Bank organistional structure, the levels and the associated roles.
Page 89 of 141
MiCOpA
5.3.2 Database Analysis

The database of the application consists of twenty two tables. Many of the tables are used as intermediate tables to facilitate querying and lot of information is duplicated around different tables which make the database hard to understand and analyze. Discussing with Grameens software developer and consulting the manual helped to understand the operations and business processes that are supported by the database. The information about the organizations subdivisions as shown in the organization graph is kept in the following tables: ZoneCode AreaCode BranchCode Center
The hierarchy of the divisions are as shown in the graph that is one zone has many area offices, one area has many branches and each branch has about 50 to 60 centers. Branch is the heart of main activities regarding loan collection and distribution. BranchStaff table keeps the information of all the staffs in a branch. One Branch Staff is responsible many centers. He/ she collects loan by field visiting the centers. Each Center has a loan collection day. It is based on weekly (one particular day of the week) for Grameen, but may vary to monthly or to some specific days. Center table contains information about the loan collection day. Loanee is a person who registers him/herself with the bank to take loan. Although the loanee is registered in the branch office as a member of the bank, but each loanee is registered against a Center where the loanee will repay the loans. Each loanee has to be a member of a group too in order to get loan. The concept of group formation is to create dutifulness and responsibility to repay the loan timely. Group members help each other and inspire to make proper utilization of the loan. Several data regarding Group is kept in the database, but they are kept in the Loanee table which makes a lot of redundancy. A table with Group data could have saved this redundancy reducing the size of tables. Loanee registers for a loan, and these information are kept in the LoanRegister database. Loanee registers a loan by taking a specific loan product from the list of products available in the bank. Each product has some attributes and ItemCode table keeps information on the product specification. Every loan item is taken for a purpose, a business purpose and the table PurposeCode keeps that information. This data provide valuable information such which loans (taken for which purpose) were most successful and which were not etc. InvestorCode keeps the information of the investors for items. DailyLoanCollection table keeps the data of collected loans and interests from the members of a branch. These values are feed into the UpdateLoan table that keeps the status information of all loans. Each loanee gets a savings account against a Loan. This is registered in the SavingsRegister table and as a savings account is opened against a loan, it registers one account for every loan a member has taken. From the DailyCollection, if someone pays greater than the loan instalment, the extra amount goes to Savings of that loan and is entered in the table UpdateSavingsRegister. The amount of money
Page 90 of 141
MiCOpA
disbursed from the branch is kept recorded in the DailyDisburse table. Daily Disburse keeps the record of a particular day and DisburseHistroy keeps all the records. Apart from these operational values some values are kept in database as a summary or report for showing some results of business interest. CenterSummary table keeps the summary of day to day transaction for a Center. CurMonth (Current Month) and PrevMonth (Previous Month) are two intermediate tables that keep the transactions along with the staff that was responsible for the transaction of the ongoing month. This data goes to PrevMonth table after the end of month. Summary of a branch is kept on the Summary table. This summary is kept against loan items. MonthlyProcessFile keeps information about a branchs processing date. The Khatwary is a special table that keeps the data on gender basis for each loan item in a branch.
5.3.3 Problems/Limitations in the GBanker3.0

From the analysis of the tables and database we come to discover the problems of the database. The following problems exist with the database: 1. Not-Normalized: Many tables are not normalized. Related information is not kept together in one table and in some cases attributes from two different tables are kept in a table as attribute of that. 2. Lot of repetitions: Repetitions results from the fact that tables are not normalized. They are repeated to facilitate querying. 3. Unused fields: There are lots of fields in the tables that are not currently used by the Grameen Bank. 4. Redundant information: Information redundancy has occurred due to the lack of proper design of query or reports. 5. Intermediate tables: Lots of intermediate tables are used, for example the CurMonth table contains the information that is otherwise available from the Daily loan Collection table. 6. Missing of some valuable attributes: Some very important attributes which they use are not included in the database, for example the sex of loanee is not stored in the database. But this data is required to generate values for Khatwary table. Presumably this data values are calculated manually or in some other way. 7. Missing of entity: Some important entities that Grameen uses is missing in the database. For example they use group information, group formation date, and others in the application. It is kept with loanee information causing a lot of repetitions of information and loss of space. A separate table was worthy to build with relevant group data.
5.3.4 Modifiability requirements

The modifiability of the parameters for Microfinance software varies on a very wide range due to the varying nature of the MFIs. Different MFIs have different kinds of requirements and different ways to deal their customer. Even for a single MFI, the parameters vary due to the variations of customers financial capabilities, residing locations, purposes of the loan and the different types of loans. The change and modifications of this kind of software is inherent with its nature and hence a good Microfinance Management application should be able to easily incorporate the dynamic Page 91 of 141
MiCOpA
changes that pop up during the lifetime of the software. That is apart from the known parameters that usually vary among the different centers, branches or MFIs, there are also unknown parameters that happen to pop up to satisfy some non frequent functionalities. The application therefore must be easily modifiable to incorporate those changes. The common changes and variations in different MFIs and in the different sections of the same institute give the scope of the parameterization. As a basis for the flexibility to change, the application has to consider the possible areas of modifications. Considering the Grameen Banks and their clients requirements the modifiability should include the following parameters: 1. The concept of group is not used by all the MFIs. Some MFIs provide loans to the loanees directly, that is to the loanee without being a member of a group. The concept of Group is just a way to increase the responsibility and the activity of an individual loanee being a part of a group and to help each other to achieve their targets. 2. Number of Members in a group varies for different MFIs. 3. Loanee status tracking 4. Interest Calculation process: different kinds of principal and interest loan 5. Repayment Schedule: some have weekly, some monthly, twice a week and so on with many other types. 6. No personal ID 7. Validation : loan limit, amount or term 8. Adding fields, happen sometimes not so often. 9. Different reports: different MFIs want reports in different formats. From some other MFIs operating in different countries [LOS, 2005], we get some more modifiability requirements such as: 1. Some MFIs have group loans and individual loans together. 2. Some do not have the concept of centers. So the loan collection is not based on the centers loan collection day. Installment date is fixed by the loan products repayment schedule. Even in some cases the loan repayment can be defined. [LP, 2005] 3. Specific for an individual loanee and a loan product based on some business rules. 4. Grace period and some other considerations due to some natural disaster or some other unavoidable phenomenon.
Page 92 of 141
MiCOpA
5.4 Alternatives to MS Access Database

Moving from the Access database to an open source database we have in fact several options. First we must mention the reason to keep away the proprietary databases like Oracle, SQL Server, DB2 and others from our choice, and the reason behind is the cost to afford them. As Microcredit Operations have high administrative costs, it is always tempting to use tools and technologies for Solutions that costs less and lesser. Many of the Micro Finance Institutes are not-for-profit organizations, and for those a proprietary database based solution may not be the optimum choice as it will add up high cost for the technology. Besides most of the MFIs are small or medium organizations with large amount of staffs involved with many small but time consuming tasks. So for these organizations an open source based solution is more attractive and better option in consideration with the expenditures of the organization. Some of the most available and used open source databases are MySQL, PostgreSQL, MaxDB, Firebird and Ingres. A detailed and informative comparison between the different features of these databases is published in the site http://www.geocities.com/mailsoftware42/db/. From the comparison table it is obvious that MySQL is definitely a strong choice for the purpose. Here in this section we describe some of the features of the database along with the specific conditions and criteria of the Grameen Bank which prompts us to select MySQL as the option to work with. First of all MySQL has more platform support than the others and it is the mostly used one among the four. As it is widely used it is easy to find MySQL developers. MySQL is faster than PostgreSQL and others and as it has a much larger user base than others, therefore the code is more tested and has historically been more stable than PostgreSQL MySQL is the much more used in production environments - MySQL has a lot of tweaking options [DC, 2005]. It has a wide range of programming interfaces like c/c++, .NET/Mono, ADO.Net, OLEDB, Delphi, Perl, Python, PHP, Embedded (C precompiler), Embeded in Java (Connector/MXJ), ODBC, JDBC etc. So developers skilled in these languages are available. Other databases also has more or less the same number of programming interfaces though, but the wide spread use of MySQL in the production level has made the difference that developers experienced working with MySQL with these languages are more available to hire. Being placed in a higher position with regard to its speed, wide use, availability of programmers and its suitability for web applications for Grameen Communications perspective and in the context of Bangladesh MySQL would obviously a better choice to go for. The limitations that Access has can be overcome successfully by the deployment of MySQL. MySQL can even be used as a storage Manager for Access with partial migration to MySQL and using Access as the user interface for the information. In [Paul, 2003], Paul DuBois has mentioned different advantages of migrating from Access to MySQL. Some of them are described here in a short in the context of Grameen Communications.
Page 93 of 141
MiCOpA
5.4.1 Multiple User Access

MySQL supports multiple user access simultaneously. It is perfect to run on a network environment and capable of servicing multiple clients at the same time. The limitation of Access is removed when MySQL is used instead. Whereas in Access, performance degradation occurs when number of users increase more than half a dozen, MySQL handles hundreds of users without major performance degradation.
5.4.2 Management of Large database

MySQL can manage hundreds of Megabytes of data. For a large company like Grameen which has many clients, database at a branch can grow very large. MySQL can support that better than Access.
5.4.3 Security
MS Access is not at all a secured database. Anyone can enter into the windows machine where the database is stored and launch Access to gain access to the tables. MySQL server manages security; no one can get access to the tables without a valid username and password. MySQL can limit logins based on different criteria; username, table name and client hostname. MySQL offers access control for user/host connectivity, and from server-side down to column level. With views in 5.0, row-level security is also possible [DC, 2005].
5.4.4 Cost
MySQL can be obtained for free where as for Access it needs money to purchase it. Providing other means of using your database (such as through a Web interface) can reduce your dependence on proprietary software and lower your software acquisition and licensing costs. [Paul, 2003]
5.4.5 Hardware choices

MySQL runs on several platforms; Access is a single-platform application. If you want to use Access, your choice of hardware is determined for you [Paul, 2003].
5.4.6 Audit Trails

Audit trail is an accounting term which means the sequence of paper work that validates accounting entries. In computer security, it is used to track computer activities. A good definition of audit trail for computing is given in [ISG, 2005] which is stated as: A record, or series of records, which allows the processing carried out by a computer or clerical system to be accurately identified, as well as verifying the authenticity of such amendments, including details of the users who created and authorised the amendment(s) In the context of Grameen Bank, Audit trail is very important. Many branch staffs are collecting money from the loanees in the filed tours and sometimes the collectors may be changed. So it is important to keep track of the records. At the current solution, the software is based on access database and there is no audit trailing facilities as anyone can access to the database and change directly the access table values. So it will be particularly useful to see how MySQL can improve the audit trailing and its security features. In the following section, the security features of MySQL found in the MySQL Page 94 of 141
MiCOpA
Reference Manual is described. We will be interested to find the following features in MySQL from the Grameens Security perspective. 1. 2. 3. 4. 5. 6. 7. Audit Logs Logs of SQL Transactions Database Access Control Password Protection Encryption between client and Server encrypting table data Protection of Audit logs from manipulation.
5.4.7 Audit Logs

Audit logs can be maintained by the General Query Log and the Update Log of MySQL. The general query log file logs established client connections with server and the executed statements. Query Log is enabled when the MySQL daemon is started with log[=filename] option. With this log it is possible to detect which client has error and for what the error occurred. Mysqld (the daemon program) writes queries in the order that it receives which can be different from the order in which they were executed. Update Log It logs statements that change data. It is deprecated and is not available from MySQL 5.0.0. This log has been replaced by the Binary Log.
5.4.8 Logs of SQL Transactions

Binary log contains all statements that change data or could have the potentially change the data. It can do anything that Update log did in the older versions in a more efficient way and in transaction safe manner. Binary log contains the statements which updated the data or could have updated it. For example and an update query that does not match any row. Binary log also contains the information about how long each statement took. Running Server with binary log makes it 1% slower, but the benefits of it outweigh this minor performance drawback. It can restore operations and set up replication. It provides the facility to update the database as fully as possible during a restore operation.
5.4.9 Database Access Control

MySQL has an advanced database access control system. The Access control of MySQL involves two stages: At first stage it checks whether it should allow a user to connect to the server. At the second stage, assuming that the user is already connected, the server checks all the statements that the user generates against his/her user privilege in the system. If a user wants to modify some data in a database his/ her user privilege is checked to see whether s/he has an UPDATE privilege for that database. MySQL uses grant tables for the server access and these tables are stored in the database named mysql. It actually uses three tables to manage the whole access privilege system for users: The user, db and host table. MySQL server checks each statement to see whether the user has sufficient privilege to perform the statement. It has fine grained privilege system up to table and columns level.
Page 95 of 141
MiCOpA
5.4.10
Password Protection
MySQL provides password for the users. When every user is given a password then it is secured that no one can access with others user name (unless s/he steals the password of some other user in some other way). MySQL provides a special function to keep passwords safe from prying eyes, the password () function. The password can be protected in following ways to keep it safe from any kind of intruders. 1. Passwords should not be stored in plain text anywhere in the database. Password function of MySQL creates a hash value of the actual password. Besides application level passwords or important data can be encrypted by MD5 (), SHA (), or some other hashing function. 2. The encrypted password is stored in the MySQL database user table. The encrypted password in the user table is the real password. So access to the user table must be limited only to the root accounts. 3. Pre- 4.1.1 style passwords has less strong encryption algorithm than 4.1.1 or later ones. 4. If the connection between the client and the server goes through an un-trusted network, an SSH tunnel should be used to encrypt the communication.
5.4.11
Encryption between Client and Server
By default, MySQL does not use encrypted connection between the client and the server. So any one can read the data who can watch the connection, she can even change the data on the in the transit. To secure the communication, MySQLs compressed protocol can be used. It makes the traffic much more difficult to decipher. To make the Connection more secure SSH should be used to get an encrypted TCP/IP connection. Beginning from the 4.0.0 MySQL has support for SSL encrypted connections. This internal OPenSSL support can be also used for client server communication in a secured manner.
5.4.12
Encryption of data directory
It is even possible to encrypt the data directory of MySQL. But it is important to know that if the private key that is used to encrypt the data directory is lost, all the data is lost. Also performance decreases as all the data must be decrypted first before they can be accessed.
5.4.13
Protection of Audit Logs from Manipulation
As log files are the source of all history of statements and events, it is important to check that some clients do not change the log files. Otherwise log files would not be able to show the exact sequences or actions that were performed in the MySQL server by different clients. To ensure this the following tasks should be taken in to consideration. 1. A client with the SUPER privilege can disable binary logging of its own statements by using a SET SQL_LOG_BIN=0 statement. 2. RELOAD privilege should not be given to any of the clients. Because then with Reset mater operation, a user can delete all the binary logs file. 3. In a word, No Server Administration Privileges or FILE privilege should not be given to any users except root users.
Page 96 of 141
MiCOpA
6 Knowledge transfer activities

In order for the MiCOpA project to be of best use to developing countries, it is important that the result is not just a report, but also activities that help spread the results so they can be put into action. In the project we therefore arranged for the following activities which helped share the knowledge with Grameen Communications: Workshops on Software architecture Workshops on Software process Workshops on Technology A website with a Wiki-system to enable easy online communication One of Grameen Communications developers came to the IT-university to learn first hand about the proposed architecture improvements and technologies. This was done through pair-programming on a system integration project related to the PDA-application.
Page 97 of 141
MiCOpA
7 A MiCOpA Software Network -- Bridging the Digital Divide with Purposeful Open-Source Software
In this report we have argued for the use of Open-source software for Micro-credit automation. While we may generally have put forward the technical merits of different solutions, we believe that this is not the most important aspect. In fact, from a functional point of view, proprietary software is probably better. Today it is more complete, provides better documentation and training, and is more mature. Many proprietary software packages also exist to support micro-credit operations. Wouldnt it be easier for a micro-credit institution to just buy this software? In a developed First World country this would probably be the case. However, from a development and Digital Divide perspective the question becomes more faceted. While proprietary software provides faster and easier access to functionality, it also has several disadvantages. Namely: Control of the software lies with the vendor, not the user. This makes customization and localization difficult. This makes MFIs dependent on the vendor [Worldbank OSS Report]. Profit from selling and supporting the software frequently goes to developed countries The software knowledge is kept at the vendor. The developing country does not significantly increase its knowledge of ICT production if it only buys a finished solution License costs
These disadvantages might not seem important in the short-run, but in the long run it makes the MFI very dependent on their software vendor and does little to bridge the digital divide. Open-source software on the other hand has the following advantages: The software is entirely under control of the MFIs who use it. They are free to adapt it as they wish. Localization is possible to achieve. MFIs are no longer dependent on a foreign western software company. They can develop their expertise in their own country [Worldbank OSS Report]. The cost previously spent on software licenses can be put to better use Open-source development can act as an educational tool computing skills
It should be stressed however that the overall goal of a MFI must never be to develop MIS-systems; they are merely important tools. Instead we propose a model where MFIs enter into partnerships with local educational institutions and companies.
7.1 Partnering with universities

MFIs most often do not have their own resources to develop and configure MIS software. Local universities offering computer science education however often has skilled software engineers. Often university teachers are lacking good examples for students to work on. Letting students and staff work on Open-source MFI MIS-software solutions provides for an excellent learning opportunity. Especially if an active
Page 98 of 141
MiCOpA
international community exists with which they can share knowledge. Universities in developed countries such as Sweden could also participate and provide assistance if needed. Working on Micro-finance software would allow the students to gain important skills in for example: Information system development Database technology Accounting Programming Micro-credit finance operations
7.2 Creating an online MFI MIS-software community

To create an international community around an Open-source it is necessary to create some kind of internet-portal. Sourceforge [Sourceforge] could be a good place to start the community. This portal allows developers too: Create a portal for the software Track bugs and feature requests Track changes to source code through version control systems
This can be done without programming and with very little setup. However, a more difficult part would be to recruit a significantly large number of universities and MFIs to participate. A possible solution here could be to rally support on Micro-finance conferences. Other Open-source MIS-solutions such as Compiere and MIFOS should also be contacted [MIFOS][Compiere].
Page 99 of 141
MiCOpA
8 Related work
Microfinance Institution is an important financial banking to the poor and it has been playing a very important role in the recent years in many developing countries. Although everyone agrees that Microfinance Institutions would benefit from open source, but till today the research devoted to the development of open source platform and applications have not reached critical mass yet [Steven, 2005]. Most of the applications for Micro credit operations are commercial applications and even though there are many software developing firms that have developed MIS system for microfinance, many of them are small firms with limited products [LOS, 2005]. The most notable open source project in this area is MOAP (Microfinance Open Architecture Project) [Steven, 2005]. But the project is in a perilous condition. Despite more than 2 years of activity, there are just 5 registered developers, who are essentially dormant (0th percentile in activity on sourceforge). Notably, no code has been written and only some documentation is available on the project page. As of the latest news from the Twiki project site, the MOAP site is no longer active now. The Grameen Technology Center, which was promoting the MOAP, is hosting a new effort in the name of Mifos (Microfinanace Open Source). Another effort to provide free software to MFIs in developing countries was from Aquadev, a non profit organization born in 1987, in a university context has developed a MIS package for the West African Region. Even though it is not an open source product, but it can be used without license in the poor countries. The software was built from the on field pressure and it is one of the many complementary services offered by the AQUADEV. The package was developed on Open source platform and specially adapted for Western Africa Region [Aquadev, 2005]. The New Economy Project is a USAID project to improve Jamaicas business environment. One of the main purposes of this project is to evaluate MIS to determine suitability for business expansion. JN Small Business limited installed a new IT system to improve the loan administration and has expanded its operation from two to fourteen [JNUSAID, 2005]. The project just to help the organization to buy MIS software, not to provide any platform for the MFIs to get general support in developing software of their own. The new effort by Grammen Tech, Mifos is an open source project for the developing MIS for the micro credit operations. The purpose of the project is to provide a platform for the microfinance organizations to manage portfolios and client accounts in multiple languages, currencies, and methodologies. The project is still in the inception phase, the status report of 5th April 21, 2005 states that they are dealing with the functional issues and Business requirements. The project aims to achieve the following goals:

Build a system that is easy to run, easy to maintain, and doesn't rely on heavyduty servers or costly development tools; Create a flexible and wholly extensible architecture that can accommodate new features and interfaces; Work on implementations of the software for both highly distributed operations and highly centralized requirements; Page 100 of 141
MiCOpA
Develop a banking application for the unique procedures of a microfinance institution including using groups as co-guarantors or pooling repayments. Make the software available in dozens of languages, supporting multiple languages, currencies, and display formats. Provide a high level of built in parameterization so that customized code bases do not create forks in the source code. Handle currency calculations correctly, with proper levels of control over precision and rounding. Support work flow flexibility
Another open source Project is Microbusiness Development Network which aims to provide a portal for microfinance, microbusiness, consulting and charitable organizations, to publish financial report, business proposal, community project proposal, expertise database, market intelligence, whitepapers, and investment analysis [MDN, 2005]. The project does not actually deal with the MIS for micro credit operations and it shows no sign of movement or progress. The project was registered on the month of June, 2002 and it has produced no documents until now. Y-community is an open source project that aims to develop a web & mail interface for management of social enterprises in developing countries. It concerns all type of socially responsible organizations such as Human Rights activists, microcredit promoters, alternative energies inventors and others. This project seems to have stopped as it is not moving since the year 2001 when it was registered [Y-Community, 2005]. SKS Microfinance in southern India completed a one year long pilot project in May 2002, which coupled Smart Cards with personal digital assistants (PDAs). Using Smart Cards, SKS aimed to save loan-officer time at client center meetings, reduce error rates associated with manual record-keeping, and more rapidly obtain data for management reporting and monitoring [Steve, 2005]. Even though the project was not a open source one but it was a step onward to the implementation of PDA based automation and its applicability in the real life. It envisioned creating a technology infrastructure through which flexible services such as emergency loans, credit scoring, real-time application processing, and automated cash access could be delivered. The Smart Card Project is supposed to revolutionize microfinance by overcoming the high cost of delivering financial services to the doorstep of the poor [SKS, 2005]. SKS used the smart card and PDA combination in two client centers for one year and they did not face any technical problems. They achieved greater accuracy in recording transactions, but the key benefit of higher loan officer productivity was not as significant as expected as the loan officers were already very much adopted and prompt with the manual system and also they decided not to implement further in light of the high cost of the project and the limited benefit for loan officers [Steve, 2005]. But the project showed that the ability of the villagers to quickly master the technology was impressive and their willingness to replace the manual system was notable. Apart from lowering the operational cost and increasing accuracy, this technology will be particularly valuable in lowering the high transportation cost of the MFIs working in the remote areas and SKS strongly believes that by thinking creatively and leveraging technology both MFI and their clients will benefit [digitaldividend, 2005].
Page 101 of 141
MiCOpA
Another educational initiative designed to encourage the open source platform development for microfinance is from the Red Hat India. Red Hat Scholarships is the Open Source Challenge to encourage budding open source software developers. Eight challenges have been decided by the organizers of the scholarship and one of those eight challenges is to build Meaningful applications for Small and Medium Enterprises (SMEs) e.g. MiniERP, Accounting and microcredit applications [Red Hat, 2005]. The projects submitted to Red Hat scholarships are expected to have effort contribution similar to that of a typical final year BE/B. Tech project. The final date for submitting proposal was 31st July, 2004 and the successful proposals were to be notified by 5th August 2004 according to the Redhat India web site (http://www.in.redhat.com/community/rhscholarship.php). All software submitted to the Red Hat Scholarships program will be in the public domain under one of the popular Open Source Licenses such as GPL, LGPL, BSD, etc., so that it can benefit the entire community [Red Hat, 2005]. So after the completion of the contestants projects and the evaluation of their projects, hopefully some micro credit operation application will be available under open source license for the interested community.
Page 102 of 141
MiCOpA
9 Conclusion
Micro-finance is a powerful tool for fighting poverty. Micro-finance institutions (MFIs), especially the pioneering Grameen Bank in Bangladesh, have had much success. Creating a long-term viable MFI is however not unproblematic. Frequently the administrative costs of running the MFI can become very high and this in turn leads to high interest rates or the MFI needs external funding in order to continue. This problem has led to the failure of many MFIs. It is therefore of vital interest that the administrative problems that MFIs are facing can be addressed. ICT plays an important role here. Management Information Systems can help to automate MFI operations, just like they are heavily used in banks. Grameen Bank in Bangladesh has long since realized this and has therefore given its sister company, Grameen Communications, the task to develop their own MIS to support the banks operations. This development has however not been entirely unproblematic. Producing advanced banking software that needs to evolve as the MFIs business changes is a complex endeavor. While the produced software is operational and has a lot of functionality it is felt that it has become difficult to change the software to support new requirements. The process of developing the software was also seen as very stressful. It was therefore necessary conduct an analysis of Grameen Communications software architecture (including technology choices) and software development process to help address their problems. To further increase the efficiency of Micro-finance operations the use and development of a Personal Digital Assistant (PDA) should also be carried out. The result of this work has led to several deliverables: Guidelines on the software development process for Grameen Bank Guidelines on the software architecture for a Micro-finance MIS Guidelines on what software technology to use A prototype application illustrating how a high-volume Micro-finance MIS can be constructed using Open-source technology and sound design principles A well functioning prototype of a PDA application that can be used to automate loan collection and significantly reduce the cost of Micro-finance operations A proposal for how the digital divide can be reduced through the international collaboration in a network focusing on the development of an Open-source MIS for Micro-finance A summary of related work in the area of MIS for Micro-finance
To summarize these deliverables we conclude that: The software development process at Grameen Communications needs to be significantly improved and elaborated. Roles need to be defined and more emphasis needs to be given to requirements and design activities The software architecture of Grameen Banker software needs to be improved to better support modifiability and security concerns. This can be achieved through architectural techniques such as modules, layers and design patterns as well as good programming practices. Open-source technology can be used to construct a similar application as Grameen Banker, but based on sound design principles.
Page 103 of 141
MiCOpA
A PDA application to support the loan collection operations can quickly be developed using Open-source development software. This application has the potential of significantly reducing the cost of Micro-finance operations. Through the collaboration on an Open-source Micro-finance MIS the digital divide can be reduced and developing countries unhealthy dependence on developed countries resources can be reduced. MIS for Micro-finance is an active field. Although most systems are commercial, some interesting Open-source projects have emerged recently.
Page 104 of 141
MiCOpA
References
[Ambler, 2002] [Amida, 2005] [Appforge, 2005] Ambler S., Agile Modeling. John Wiley & Sons, 2002. PicoPeta. Introducing the Amida Simputer. URL: http://www.amidasimputer.com. Accessed in April 2005. Appforge, Inc. Crossfire create multi-platform mobile applications using C#, VB.net or VB 6.0. URL: http://www.appforge.com/products/enterprise/crossfire/index.html. Accessed in Apri, 2005. Astel D., Test-Driven Development. Addison-Wesley, 2004. Aquadev, http://www.aquadev.org/en/fr/pdf/AdBanking_Anglais_High.pdf Accessed in Oct 2004. Bass, L., Clements, P, Kazman, R., Software architecture in Practice. SEI Series in Software Engineering, Addison-Wesley, 2003. Beck K., Extreme Programming Explained: Embrace Change. Addison-Wesley, 2000. Beck K., eXtreme Programming: Embrace Change. 2nd Edition, Addison-Wesley, 2004. Biech, J. Sync up Palm OS with J2ME. URL: http://www.javaworld.com/javaworld/jw-05-2002/jw-0531palm.html. Accessed in April, 2005. Blanchette J., Summerfield M., C++ GUI Programming with Qt 3, Prentice Hall, 2004. http://phptr.com/bookstore/product.asp?isbn=0131240722&rl=1
[Astel, 2004] [Aquadev, 2004]
[Bass et. al]
[Beck, 2000] [Beck, 2004] [Biech, 2005]
[Blanchette, 2004]
[Boehm and Turner] Boehm B. and Turner R., Balancing Agility with Discipline. Addison-Wesley, 2004. [Boudewijn, 2001] Boudewijn R., GUI Programming with Python: QT Edition. Open Docs Publishing, 2001. http://www.opendocspublishing.com/pyqt/ Common Criteria, http://csrc.nist.gov/cc/. Accessed in December 2004 CGAP Consultative Group to Assist the Poor. How successful are PDAs for microfinance?. URL: http://www.cgap.org/docs/IT_pda.pdf. Accessed in April 2005. Standish Group, The CHAOS Report (1994). URL: http://www.standishgroup.com/sample_research/PDFpages/chaos 1994.pdf. Accessed in January 2005.
[CC, 2004] [CGAP, 2005]
[CHAOS, 2005]
Page 105 of 141
MiCOpA
[Charette, 2004]
Charette R., The Decision is in: Agile versus Heavy Methodologies. Agile development and Project Management, Cutter Consortium, Vol. 2 (19), URL:www.cutter.com/freestuff/epmu0119.html. Accessed in February 2004. CNET. Shop for Handhelds/PDAs. URL: http://shopper.cnet.com/PDAs/2001-3127_9-0.html?tag=shfd.di. Accessed in April 2005. Cockburn A., Agile Software Development. Pearson Education, 2002. Compiere, http://www.compiere.org. Accessed on April 2005 Cooper A., The Inmates are Running the Asylum, Macmillan Computer Publishing, 1999.
[CNET, 2005]
[Cockburn, 2002] [Compiere, 2005] [Cooper]
[Cunningham, 2005] Wiki. URL: http://wiki.org/wiki.cgi?WhatIsWiki. Accessed in April 2005. [CVS, 2005] [db4o, 2005] Concurrent Versions System. URL: https://www.cvshome.org/. Accessed in April 2005. db4objects, Inc. Product Information. URL: http://www.db4o.com/about/productinformation/ .Accessed in April, 2005. Open Source database Comparison, A Web article found at the site http://www.geocities.com/mailsoftware42/db/, last updated March, 2005 and retrieved on 3rd April 2005. Deming, W. E., Out of the Crisis. MIT Center for Advanced Engineering Study, Cambridge, MA, 1982.
[DC, 2005]
[Deming, 1982]
[Dennis et al., 2002] Dennis A., Haley-Wixon B., Tegarden D., Systems Analysis and Design: An Object-Oriented Approach with UML. John Wiley & Sons, 2002. [Digitaldividend, 2005] Swayam Krishi Sangam (SKS) Handheld/Smart Card Project. Online article, retrieved on the 7th April, 2005 from the site http://www.digitaldividend.org/pubs/pubs_05_sks.htm [Dunlop, Brewster] Dunlop M. and Brewster S., The Challenge of Mobile Devices for Human Computer Interaction. Personal and Ubiquitous Computing, Jan 2002.
Page 106 of 141
MiCOpA
[Eclipse, 2005]
Eclipse Foundation. Eclipse projectFAQ. URL: http://www.eclipse.org/eclipse/faq/eclipse-faq.html. Accessed in April, 2005. EclipseME. J2ME Development using Eclipse. http://www.eclipseme.org. Accessed in April, 2005. URL:
[EclipseME, 2005] [FAQ, 2005]
Frequently Asked Questions About Microsoft Access Security for Microsoft Access. Retrieved from Microsoft support homepage on 14th April, 2005. the link is: http://support.microsoft.com/default.aspx?scid=%2Fsupport%2Fac cess%2Fcontent%2Fsecfaq.asp Fowler M., UML Distilled 2nd Edition . Addison-Wesley, 1999. Fowler M., Patterns of Enterpries Application Architecture . Addison-Wesley, 1999.
[Fowler, 1999] [Fowler, 2002]
[Gamma et al.,1994] Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley, 1994 [GDRC] Global Development Research Center, URL: http://www.gdrc.org/icm/microlending.html. Accessed in Oct 2004. Grameen Bank, URL: http://www.grameen-info.com. Accessed in Oct 2004. Grameen Bank Monthly Update in US$:November, 2004. http://www.grameen-info.org/bank/November04US$.htm Grameen Banker 3.0 Demo http://asp.grameen.com/demosoft/gbanker.htm Grameen Banker 3.0 Manual Grameen Bank's Micro credit operation Automation System. A Project with DSV. PowerPoint presentation. Demo Software for MFIs http://asp.grameen.com/demosoft/index.htm
[Grameen] [Grameen Monthly Update] [Grameen Banker Demo] [Grameen Banker Manual] [Grameen MiCOpA] [Grameen Demo Software]
[Grameen Grameen Bank's Operating System. PowerPoint presentation. Operating System] [GTK, 2005] [Highsmith, 2002] [Hubbard, 2004] [Humphrey, 1995] http://www.gtk.net Highsmith J., Agile Software Development Ecosystems. Addison-Wesley, 2002. Hubbard J., Open Source to the Core. ACM Queue, Vol. 2 (3), May 2004. Humphrey, W. S., A discipline for Software Engineering: The CompletePSP Book. Addison-Wesley, 1995.
Page 107 of 141
MiCOpA
[Hunt et al, 1999] [Hunter, 2005]
The Pragmatic Programmer: From Journeyman to Master, Andy Hunt and David Thomas, Addison-Wesley Oct 1999 Hunter, J M. Data Structures and Algorithms in Java. URL: http://www.idevelopment.info/data/Programming/data_structures/j ava/LinkedList/LinkedList.shtml. Accessed in April, 2005. IBM WebSphere Everyplace Micro Environment. Software Connection. URL: http://software.palmone.com/PlatformSearch.jsp?optionId=1_1_2 &platformId=1&siteId=291&count=20&txtSearch=websphere&se ctionId=0+All+Categories. Acccessed in April 2005. Bright Helms and Xavier Reille. Interest Rate Ceiling and Microfinance. CGAP Occasional Paper. September 2004. International Institute for Communication and Development, URL: http://www.iicd.org/stories/articles/Story.import5103. Accessed in Oct 2004.
[IBMWS, 2005]
[ICM] [IICD]
[Indian NGOs, 2005] Indian NGOs. URL: http://www.indianngos.com/issue/microcredit/misandmicrofinance .htm. Accessed in April 2005. [INTERCOMM] Interaction Design Prototyping of Communicator Devices: Towards Meeting the Hardware-Software Challenge, Interactions, Vol. 9 (6), Nov/Dec 2002. Information Security Glossary. Retrieved from the site http://www.yourwindow.to/ at 13thApril, 2005.
[ISG, 2005]
[Jeffries et al., 2001] Jeffries R., Anderson A., Hendrickson C., Extreme Programming Installed. Addison-Wesley, 2001. [JN-USAID, 2005] Project with JN Small Business Loan Ltd. Information retrieved on 15th April, 2005. Link: http://www.neweconomyproject.com/release0028.html Karlstrm D., Effects of Introducing Agile Methodologies in Software System Engineering. Third National Conference on Software Engineering Research and Practice in Sweden, SERPS'03 Sweden, 2003. Kruchten P., The Rational Unified Process An Introduction. Addison-Wesley, 2000. Kura, a multi-user open-source linguistic database. http://www.ats.lmu.de/kura/index.php. Accessed April, 2005. Haustein, S. About kXML. URL: http://kxml.sourceforge.net/about.shtml. Accessed in April, 2005. Crystal Clear Software Limited. A software company in Uganda, has developed a micro finance management application marketed as Loan performer. URL: http://www.loanperformer.com/
[Karlstrm, 2003]
[Kruchten] [Kura, 2005] [kXML, 2005] [LP, 2005]
Page 108 of 141
MiCOpA
[LOS, 2005]
List of MIS products for MFIs. Retrieved from the CGAP home site. http://64.78.5.216/dev/cgap/iss/product_list.cfm
[Macromedia, 2005] Using Microsoft Access Databases in a Production Environment, ColdFusion TechNote, retrieved on april , 2005. from http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id =tn_17034 [MASE] MASE, URL: http://ebe.cpsc.ucalgary.ca/ebe/Wiki.jsp?page=Root.MASE. Accessed in Oct 2004.
[McGovern et al., 2004] A Practical Guide to Enterprise Architecture, James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Elias K. Jo, Vikas Sharan, Prentice Hall PTR, 2004 [McNamara, 2005] McNamara W., Basics on Conducting Focus Groups. URL: http://www.mapnp.org/library/evaluatn/focusgrp.htm. Accessed in January 2005. Microbusiness Development Network. Project Home page on sourceforge http://sourceforge.net/projects/alcaiceria/ Metrowerks, a Freescale company. CodeWarrior Technology. URL: http://www.metrowerks.com/mw/default.htm. Accessed in April, 2005.
[MDN, 2005] [Metrowerks, 2005]
[Microsoft Data Ctrl] Microsoft Data Control Documentation http://msdn.microsoft.com/library/default.asp?url=/library/enus/vb98/html/daobjData.asp [MicrofinanceGateway, 2005] http://www.microfinancegateway.org/. Accessed on April 2005 [MIDP-OVM] MIDP-OVM, URL: http://opensource.erve.vtt.fi/pdaovm/midp-ovm/index.html. Accessed in Oct 2004. Mifos Project Home page on sourceforge. Retrieved on April 20, 2005 from http://mifos.sourceforge.net. Charles Waterfield , Nick Ramsing.Management Information Systems for Microfinance Institutions. February 1998 MOAP Twiki Home Page. Information retrieved on April, 2005 from http://moap.sourceforge.net/cgibin/twiki/bin/view/Moap/WebHome Morrison, M. Teach Yourself Wireless Java with J2ME in 21 Days. SAMS, 2001. Naked Objects, URL: http://www.nakedobjects.org. Accessed in Oct 2004. Digital Focus, Inc. Nextel's Open Source J2ME Toolkits. URL: http://nextel.sourceforge.net. Accessed in April, 2005. Page 109 of 141
[Mifos, 2005] [MIS] [MOAP, 2005]
[Morrison, 2001] [NakedObjects] [Nextel, 2005]
MiCOpA
[ONJava, 2005]
OReilley Media, Inc. Introducing MIDP 2.0. URL: http://www.onjava.com/pub/a/onjava/2002/12/18/midp.html. Accessed in April, 2005. PalmSource, Inc. PalmOS Developer Suite. URL: http://www.palmos.com/dev/tools/dev_suite.html. Accessed in April 2005. palmOne, Inc. Tungsten handhelds. URL: http://www.palmone.com/us/products/handhelds/tungsten-c/. Accessed in April 2005. PalmSource, Inc. Palm powered products. URL: http://www.palmsource.com/products/. Accessed in April 2005. Patton J., Hitting the Target: Adding Interaction Design to Agile Software Development, Practitioners Reports, OOPSLA, 2002. Paul DuBois. Migrating from Microsoft Access to MySQL. An internet article written on January, 2003 and retrieved from the site: http://www.kitebird.com/articles/access-migrate.html on 5th April, 2005. Paulk M., Extreme Programming from a CMM Perspective. IEEE Software Vol. 18 (6), 2001. OSTG Open Source Technology Group. Palm OS programming with GCC. URL: http://prc-tools.sourceforge.net. Accessed in April, 2005. http://www.python.org Quality Attribute Workshops, URL: http://www.sei.cmu.edu/ata/products_services/qaw.htm. Accessed in Oct 2004.
[PalmDS, 2005]
[palmOne, 2005]
[PalmOS, 2005] [Patton] [Paul, 2003]
[Paulk, 2001] [PRC, 2005]
[Python, 2005] [QAW]
[Rainer et al., 2003] Rainer A., Hall T., Baddoo N., Persuading Developers to Buy into Software Process Improvement: Local Opinion and Empirical Evidence. Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE03), IEEE Computer Society, 2003. [Rasmussen, 2003] [Rational, 2005] Rasmussen J., Introducing XP into Greenfield Projects. IEEE Software Vol. 20 (3), 2003. Rational Software. URL: http://www-306.ibm.com/software/rational/. Accessed in April 2005. Red Hat Scholarships, the open source challenge, information collected from the Red Hat India web page on April 12, 2005. http://www.in.redhat.com/community/rhscholarship.php
[Red Hat, 2005]
[Report Lab Toolkit] http://www.reportlab.org/rl_toolkit.html. Accessed April, 2005.
Page 110 of 141
MiCOpA
[RUP, 2005]
A Rational Software Corporation White Paper, Rational Unified Process: Best Practices for Software Development Teams. URL: http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/pa pers/rup_best_practices/rup_bestpractices.html. Accessed in April 2005.
[Schwaber & Beedle, 2001] Schwaber K. and Beedle M., Agile Software Development with Scrum. Prentice Hall, 2001. [SIDAITStrategy, 2005] Strategy for IT i Development Cooperation (sic), http://www.sida.se/Sida/articles/5400-5499/5490/strategy.pdf, Access in April 2005 [Simputer, 2005] [SKS, 2005] The Simputer Trust. Welcome to Simputer. URL http://www.simputer.org Putting Technology to Work for Poverty Alleviation, online document retrieved from the home page of SKS India, on April 2005. link: http://www.sksindia.com/TechnologyAtSKS.htm Service-Oriented-Architectures, URL: http://www.serviceoriented.org. Accessed in Oct 2004. http://www.sqlobject.org. Accessed in April, 2005. Stapleton J., DSDM Dynamic Systems Development Method: the Method in Practice. Addison-Wesley, 1997. Steven Ketchpel, Webliography of Open Source Software for Microfinance. Retrieved from http://www.rdvp.org/~sketchpel/weblio/open-source.html on the 24th March, 2005. Steve Whelan, Smart Cards- CGAP IT Innovation series, online article retrieved on the 28th march, 2005 from http://www.cgap.org/docs/IT_smart_card.html Sun Microsystems, Inc. Java 2 Platform, Micro Edition (J2ME). URL: http://java.sun.com/j2me. Accessed in April, 2005. Funambol. Sync4j. URL: http://sync4j.funambol.com/main.jsp?main=theproject. Accessed in April, 2005. Internet Article. The Truth About Access, by 15 seconds Discussion List. URL: http://www.15seconds.com/Issue/010514.htm. Accessed in March 2005. Tk Toolkit, URL: http://tcl.sourceforge.net. Accessed April, 2005. Trolltech Inc., http://www.trolltech.com. Accessed April, 2005. UN General Assembly, URL: http://www.uncdf.org/english/microfinance/year/GAresolutions/U
[SOA] [SQL Object, 2005] [Stapleton, 1997] [Steven, 2005]
[Steve, 2005]
[Sun, 2005] [Sync4j, 2005]
[TAA, 2005]
[Tk, 2005] [Trolltech, 2005] [UN]
Page 111 of 141
MiCOpA
NGA-YoM_eng.pdf. Accessed in Oct 2004. [Yunus] [VBUnit, 2005] [Wiki, 2005] Yunus M., Grameen at a glance. Packages Corporations Limited, 2004. VBUnit Unit Testing. URL: http://www.vbunit.org. Accessed in January 2005. Wiki. URL: http://wiki.org. Accessed in April 2005.
[WIKIPEDIA, 2005] Wikipedia, http://www.wikipedia.org/. Accessed in April 2005 [Winschiers & Paterson, 2004] Winschiers H. and Paterson B., Sustainable Software Development. Proceedings of SAICSIT 2004, 2004. [wxWidgets] [XP, 2004] wxWidgets, URL: http://www.wxwidgets.org Extreme Programming, Extreme Programming: A Gentle Introduction. URL: www.extremeprogramming.org. Accessed in January 2004.
[Y-Community, 2005]Open Source Project: Y-community. Retrieved on 13th April, 2005 from http://sourceforge.net/projects/y-community/ [Yunus 2002] Grameen Bank II: Designed to Open New Possibilities. Muhammad Yunus. October 2002. http://www.grameen-info.org/bank/bank2.html Zachman J., A framework for information systems architecture. IBM Systems Journal, Vol 26 (3), 1987.
[Zachman, 1987]
Page 112 of 141
MiCOpA
Appendix A
Analysis of Grameen Banker 3.0
The purpose of this report is to analyze the current information system used for operations at Grameen Bank. We have investigated three sources simultaneously in order to analyze the GBanker: Grameen Banker 3.0. Visual application: menu options, forms and fields. MS Access database Grameen Banker stores it's data in. Grameen Banker 3.0 User Manual [GBankerManual].
Objectives of Analysis
In order to propose a prototype that supports the Grameen Banks Operation more efficiently we investigate the current solution to find out its limitations, drawbacks, advantages and disadvantages. We study the Grameen Banks business logic, requirements and future development issues so as to incorporate them in the proposed prototype. The objective of this document is to solve the following issues in order to satisfy the requirements for the prototype described above: 1. Find out how much of the bank's business processes is supported by Grameen Banker 3.0. 2. Find out how much of the business process is hard-coded into the Grameen Banker 3.0. 3. Find out common functionalities in other software developed by Grameen Communications for MFIs. 4. Find out if Grameen Banker 3.0 supports Grameen Bank II [Yunus, 2002].
Page 113 of 141
MiCOpA
Grameen Bank
Organization
This is the organizational graph of Grameen Bank as found in [GBankerManual, Page 13] and the figures are taken from [Grameen 2004, Grameen OS]:
Figure A.1. The Grameen Bank organistional structure, the levels and the associated roles.
Grameen Banker 3.0

Architecture
GBanker 3.0 is an application developed in Visual Basic that uses an Access database to store its data.
Technology Used
Visual Basic 5.0 on Windows 9x.
Main Functionalities
Grameen Bankers main function is described by the Term Branch Loan monitoring System (BLMS). The small amounts of loans that are disbursed to the poor are monitored in the following ways: 1. Daily Loan disbursement: the amount of loan disbursed daily from a branch 2. Daily loan Collection: the entry of all loan payments collected daily in a branch. 3. Daily Savings Collection: entry of all savings collection from the GB members.
Page 114 of 141
MiCOpA
Besides these main functionalities, the information of the following entities is stored in the database: i. ii. iii. iv. v. Field Operator information Centre information Loanee Information Holiday Information Purpose Information
MS Access Database Analysis

Tables
For every table in the database we provide a description of its purpose, the columns and a set of questions that arose during the study of the database. These questions were solved during the course of the project and therefore we include the answers. ZoneCode Contains data for zonal offices. There are 18 zonal offices [Grameen OS]. Columns: ZoneCode: zone identifier. String (only numbers) ZoneName: name of the zone. String.
Questions and observations: 1. No information is kept of which people work at which zone office and what is their role or position there. 2. Who (Actor) enters or adds zones to the database? 3. How often are zones added to the database? 4. In which office (Head/Zone/Area/Branch) are they created? Answers to the questions: 1. The application does not consider the part of which people working at which zone offices and their positions. This information is actually kept by the zonal authority, i.e. the zone manager and it is maintained manually. The Headquarter keeps the information of the zonal authorities of different zones and this is done manually as well. They might need a separate database module to keep that information. 2. An employee (an operator) at the Headquarter is responsible to do this. As this is not yet stored in the database, it is done manually. 3. It is added very rarely, as a creation of new zone means the expansion of Grameen Bank to a new district or local with a many area offices and large number of branch offices. 4. The codes are given from the Headquarters.
Page 115 of 141
MiCOpA
AreaCode Contains data for Area offices. There are 127 area offices [Grameen OS]. Columns: AreaCode: area identifier. String (only numbers). AreaName: name of the area. String. ZoneCode: identifier of the Zone the area belongs to. Keys: AreaCode: primary key. ZoneCode: foreign key to the ZoneCode table. Questions and observations: 1. No information is kept of which people work at which area office and what is their role or position there. 2. Who (Actor) enters or adds areas to the database? 3. How often are areas added to the database? 4. In which office (Head/Zone/Area/Branch) are they created? Answers to the questions: 1. Area manager keeps this information manually. The information of different area managers are kept in the zone office. 2. They are entered by an operator in the Zone level. But only the code is given and they values are entered to the manual system there in the zone office. Once the code for a area is defined from the zone, it is entered into the database by the branch operators. 3. Areas are added into the database every four months. 4. The area codes are given at the Head Office. BranchCode Contains data for Branch offices. There are 1277 branch offices [Grameen 2004]. Columns: BranchCode: branch identifier. String (only numbers) BranchName: name of the branch. String. AreaCode: identifier of the Area the area belongs to. ZoneCode: identifier of the Zone the area belongs to. Keys: BranchCode: primary key. AreaCode: foreign key to the ZoneCode table.
Page 116 of 141
MiCOpA
Questions and observations: 1. The column ZoneCode is a duplication of the data contained in the table ZoneCode but they have not defined it as a foreign key. From the discussion with Imrul, we know that ZoneCode is a foreign key to the Area. 2. Information is kept about who has worked for which Branch in the table BranchStaff. 3. Can an employee work for different branches at the same time? No, No they can not move from one to another. 4. Can an employee stop working in a branch and move to another? A: Then the employee is treated as s/he has finished her job in the current branch and joins the new branch as a new staff. 5. What happens when an employee from a branch is promoted to an area office? A: Then the employee is treated as s/he has finished her job in 6. Who (Actor) enters or adds branches to the database? A: The operators at the area office enter the information. 7. How often are branches added to the database? A: Branches are added very often in the database. Some branches every month. 8. In which office (Head/Zone/Area/Branch) are they created? A: the Head Office creates the information. Center Contains data for centers. There are between 50-60 centers per branch office [Grameen OS]. A center is the meeting place for borrowers and the operator from the branch [GBankerManual, Page 13]. Columns: BranchCode: identifier of the Branch the center belongs to. CenterCode: area identifier. String (only numbers). CenterName: name of the center. String. CollectionDay: day of the week that the operator from the branch meets the people in the village Center. Values are integers from 1 to 7, where 1 corresponds to Saturday. Organizer: is a representative from the groups StaffID: operator from the branch that goes to the center. Status: performance indicator for a center. Possible values are {Golden, Silver, Copper}. Keys: CenterCode: primary key. BranchCode: foreign key to the BranchCode table. StaffID: foreign key to the BranchStaff table.
Page 117 of 141
MiCOpA
Sample data: Centers ordered by CenterName:
We find a center "ALI NOGOR" with three different center codes. This can be a way to represent several centers at the same village. So for the center name they used that of the village but in village in which they have many members they create different centers by assigning them different codes. Centers ordered by CenterCode and BranchCode:
In different branches we find centers with the same CenterCode but different CenterName and thus CenterCode is not unique. Questions and observations: 1. How is the Status of a Center computed? Apparently, the Status of a center is no longer indicated with this three values but with stars[Yunus 2004]. In Grameen Bank II the status is calculated as stars.
Page 118 of 141
MiCOpA
2. Collection day is for a center and it represents the day when operator meets the loanee in the village. 3. The operators do not distribute money. Money is not distiributed from the centers, Loanees have to go to the branch office to collect the money. 4. Organizer is a representative from the group. The database keeps this information as they want the Organizer to be a female. BranchStaff Contains the data of the employees of a branch. Columns: BranchCode: identifier of the Branch the center belongs to. StaffID: identifier of the employee. String (only numbers). StaffName: name of the employee. Designation: the role or position the employee holds in the organization. JoiningDate: date the employee starts working at the branch. RealisingDate: date the employee stops working at the branch. Keys: StaffID: primary key BranchCode: foreign key to the BranchStaff table. Sample data:
Questions and observations: 1. An employee can not work for different branches at the same time. 2. Can an employee stop working in a branch and move to another? Yes, an employee can do that. But the info is not kept in the database. The employee gets a new registration in the BranchStaff table in the new branch where s/he moved.
Page 119 of 141
MiCOpA
3. When promoted, the employee is treated as s/he has released, and gets a new employee in the area office. 4. The Designation column contains many repetitions and mistakes like "SENIOR ASSISTANT" and "SENIOR ASSESTANT". DESIGNATION posts are not taken from a set of fixed values. 5. No contact information is kept of the employees. This probably means that they use some other system to manage this information. 6. The only keep the name of the employee. The name is not even divided into name and surname. Do they also keep the title or profession of the employee together with the name? MD means Muhammad. Loanee Contains the data of members of the bank that borrow and save money. Columns: BranchCode: identifier of the Branch the loanee belongs to. CenterCode: identifier of the Center the loanee belongs to. GroupNo: identifier of the group the loanee belongs to. GroupFormationDate: when the group was formed. LoaneeNo: identifier for the loanee. String with only digits and a dot. LoaneeName: name of the loanee LoaneeCareOf: name of a person LoaneeAge: age of the member. LoaneeJoiningDate: the date LoanLimit: the amount of money that a loanee can take TotalAbsent: number of days loanee is absent from meeting TotalDropIns: number of drop in installment PreLoaneeNo: previous Loanee Number LoaneeDropDate: if dropped, then the drop date is kept ActiveOrDrop: the status of Loanee whether active or dropped Questions and observations: 1. Instead of saving the age of the loanee in the LoaneeAge column, we should keep at least the year of birth if not the full date. 2. Loanee No is assigned from the branch office. The loaneeNo in a branch is unique, outside the branch they are not unique. Two branch can have same LoaneeNo and they usually have. The dot in the LoaneeNo is used when a Loanee has taken more than one loan of the same product type. The dot then distinguishes the different loans. 3. LoaneeCareof is a special field that is included on the context of rural social structure of Bangladesh. This is same as Care of address used in the mail address. Many of the poor village women will use the name of a well known person in the village as their care of address. 4. Group Formation date included here makes the schema not normalized. Page 120 of 141
MiCOpA
5. If database is not maintained globally and is maintained in the branch office then BranchCode and CenterCode is not needed in this table. 6. LoaneeSEX is not kept in the database, but it is really important from Grameen Baks respect. LoanRegister This is the table that contains the information of the loans that a member has
Columns: BranchCode: identifier of the Branch the loanee belongs to. CenterCode: identifier of the Center the loanee belongs to. LoaneeNo: identifier for the loanee. String with only digits and a dot. ItemCode: string. Identifier of the Loan Product LoanTerm: number representing the number of terms the loan is taken. PrincipalLoan: the total amount of principal Loan LoanInstallment: the amount that is to re-pay each term DueLoanInstallment: previous due, the installment that is not repaid (one of them is reduandant..only how much he has to pay each term is needed) InterestCharge: interest rate InterestPaid: Interest that is paid DueInterestInstalment: amount of InterestInstallment not paid InstallmentDate: date for first installment
Page 121 of 141
MiCOpA
Observations: 1. Due Loan Installment seems to be a repetition. Is it something that represents the amount of money the loanee has missed to repay in the previous installment? It should be like this, whereas the Grameen Bank does not keep track of this at their current application. 2. InterestPaid is not needed if DueInterestInstallment is there. Its a repetition. As Grameen bank collects the interest before collecting the loan installment, only DueInterestInstallment can serve the purpose. 3. InstallmentDate unnecessary comes from the centers collection day. 4. Interest Paid field is also unnecessary in this table.
Page 122 of 141
MiCOpA
Center Summary This table keeps the summary of a Center. It is updated everyday. Columns BranchCode: identifier for Brach Code CenterCode : identifier for Center Code ItemCode: identifier for product InvestorCode: Identifier of Investor Code OpeningBalance: Opening balance for a center. Previous days loan collected from loanees DueInstallment: due installment for a particular product LoanRepaid: total loan repaid in the center SavingsDeposit: total savings deposited TaxDeposit: tax LoanDisburse: total loan disbursed SavingsWithdrawal: withdrawal from savings ClosingBalance: Closing balance InterestBalance : total interest for this loan item DueInterestInstallm : due interest installment total for this loan Product. CurrentInterestPaid: total amount of paid interest PreviousInerestPaid: Up to Previous days interest paid InterestClosingBala: Closing balance for today RegularLoanee: Number of Regular Loanees in the center DropLoanee: Number of Drop Loanees in the center TokenLoanee: Not Used or Unknown Member: total members Absent: Number of absent members Observation: 1. Center Summary is an intermediate table that is used to generate the center summary report. 2. This table is made only to facilitate query. 3. Absent field is not needed. CurMonth This table is also an intermediate table. The columns of the tables are: BranchCode: identifier for Brach Code CenterCode : identifier for Center Code ItemCode: identifier for product LoaneeNo: identifier of the loanee LoanTerm: number of terms the loan allocated Regular: number of regular loanee Drop: number of dropped loanee Token: number of token loanee PrincipalLoan: total amount taken by the loanee Page 123 of 141
MiCOpA
LoanInstallment: Loan Installed this month DueLoanInstallment: due of this month InterestPaid: total interest paid this month DueInterestInstallm: due in this month InstallmentDate: date loan collected StaffID: ID of the responsible staff StaffName: name of the staff
Observation: Current Month is the intermediate table that keeps the information of the current months collection of loan. It keeps the loans information against the loaneeNo and Loan product. Information of all the loanees of a branch is kept here, and the information of the branchStaff responsible for collecting the loan is also kept. This is for security purpose we guess.
DailyLoanCollection This table keeps the information of the daily Loan Collection. The columns of the table are: BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode string type, identifier of the Loan Item LoanTerm : Number of terms for the loan PrincipalLoan: toatal amount of loan LoanRepaid: Loan repaid so far CurInterestCharge : Interest Charge active now CurInterestPaid : total interest paid PreInterestCharge : Not used PreInterestPaid : Not used LoanInstallment : the amount to repay DueLoanInstallment : if any due of loan installment CurIntInstallment : interest amount to pay PreIntInstallment : not used DueInterestInstallm : any due in interest, not used DropWeek : if loanee is absent InstallmentDate: collection DATE Observation: 1. Loan Term, Principal Loan, Loan Repaid are not needed. They are repetition. They already exist in the loan Register table. 2. Only LoanInstallment and CurIntInstallment are needed for loan collection.
Page 124 of 141
MiCOpA
3. DueInterestInstallment, PreIntInstallment, DueLoanInstallment, PreInterestCharge, DropWeek are also repetition as they already exist in the UpdateLoan table. 4. BranchCode is not needed in this table, because if the database is managed in the branch level, then LoaneeNo in a branch is unique. 5. Daily Loan Collection sheet is created from the branch, So there is no problem of mix up with other branch. So BranchCode is not necessary here. 6. Installment date is confusing here, collection date may be more appropriate. 7. This table is created for the Loan Collection sheet, so the other information needed for the Collection sheet can be gathered from other tables, it is not needed to include those (in bullet 3) in this table. DailyDisburse The daily disburse table contains the disburse details of everyday. The table contains following columns: BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode: string type, identifier of the Loan Item LoanTerm: Number of terms PurposeCode: purpose identifier DisburseDate: DATE of disburse PrincipalLoan: Total loan amount LoanInstallment: amount to repay in each term InterestInstallment: interest to pay in each term TaxRate1: Tax rates for the item TaxRate2: Tax rates for the item TaxRate3: Tax rates for the item TaxDepositItem1: tax deposited for item by rate 1 TaxDepositItem2: tax deposited for item by rate 2 TaxDepositItem3: tax deposited for item by rate 3 JanuaryLoanInst: Loan installment for this month JanuaryInterestInst: Interest installment for this month FebruaryLoanInst: Loan installment for this month FebruaryInterestIns: Interest installment for this month MarchLoanInst: Loan installment for this month MarchInterestInst: Interest installment for this month AprilLoanInst: Loan installment for this month AprilInterestInst: Interest installment for this month MayLoanInst: Loan installment for this month MayInterestInst: Interest installment for this month JuneLoanInst: Loan installment for this month JuneInterestInst: Interest installment for this month JulyLoanInst: Loan installment for this month JulyInterestInst: Interest installment for this month
Page 125 of 141
MiCOpA
AugustLoanInst : Loan installment for this month AugusInterestInst: Interest installment for this month SeptemberLoanInst: Loan installment for this month SeptembeInterestIns: Interest installment for this month OctoberLoanInst: Loan installment for this month OctobeInterestInst : Interest installment for this month NovemberLoanInst: Loan installment for this month NovemberInterestIns : Interest installment for this month DecemberLoanInst: Loan installment for this month DecemberInterestIns: Interest installment for this month Function: Not Used or Unknown
Observation: 1. This table is for defining the loan parameters for every single loan disbursed to a loanee. 2. The loanInstallment and InterestInstallment is defined for each month of the year which sounds a bit strange. As loanInstallment and Interest Installment is already defined in the table LoanRegister, so it is a repetition and the separate definition for each month is also confusing. May be that is because of any special criteria existed in the context of Grameen Banks Loanees. 3. If daily disburse kepps the information of disburse against a Loanees particular loan, database is kept in a branch then use of branchCode and CenterCode is redundant here. If it is used as a global database then only these two fields are needed. 4. If DailyDisburse keeps the amount that is to be disbursed each month and it varies in each month, then it is important to keep the information of each month separately. Otherwise it is a loss of space in the database. 5. TaxRates and PrincipalLoan. L Installment, I installment, TaxDeposit seems to be taken from the ItemCode table. And are redundant. 6. If the loanee takes loan in different times, not at one time..and DailyDisburse keep track of that then it is good to have the values against a date, the disburse date. Total amount disbursed must be kept as a column. 7. If DailyDisburse is used to kept the money disbursed daily from the branch, then the amount money disbursed against which loan to which customer is needed only, the rest of the columns are not necessary. 8. The monthly installments can be the different repayment rates for the loan as they can vary depending on the season. In that case, this table keeps information on loan registration and its details. DisburseHistory This table keeps the information of the Loan and Interest Installments of the loanees month by month. BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode string type, identifier of the Loan Item Page 126 of 141
MiCOpA
LoanTerm: Number of terms PurposeCode: purpose identifier DisburseDate: DATE of disburse PrincipalLoan: Total loan amount LoanInstallment: amount to repay in each term InterestInstallment: interest to pay in each term JanuaryLoanInst: Loan installment for this month JanuaryInterestInst: Interest installment for this month FebruaryLoanInst: Loan installment for this month FebruaryInterestIns: Interest installment for this month MarchLoanInst: Loan installment for this month MarchInterestInst: Interest installment for this month AprilLoanInst: Loan installment for this month AprilInterestInst: Interest installment for this month MayLoanInst: Loan installment for this month MayInterestInst: Interest installment for this month JuneLoanInst: Loan installment for this month JuneInterestInst: Interest installment for this month JulyLoanInst: Loan installment for this month JulyInterestInst: Interest installment for this month AugustLoanInst : Loan installment for this month AugusInterestInst: Interest installment for this month SeptemberLoanInst: Loan installment for this month SeptembeInterestIns: Interest installment for this month OctoberLoanInst: Loan installment for this month OctobeInterestInst : Interest installment for this month NovemberLoanInst: Loan installment for this month NovemberInterestIns : Interest installment for this month DecemberLoanInst: Loan installment for this month DecemberInterestIns: Interest installment for this month
Observation: 1. LoanIstallment and the InterestInstallment are same for all months for all the loan items taken by loanees. So it is redundant to keep that information separately for each month. 2. Interest is calculated as 0.2% of the principal loan per term. For example, for a loan of 4000 taka, the interestInstallmemt is 4000*0.2/100 = 8 taka per term. In DisburseHistory this 8 is inserted in the column of each months InterestInstallment. 3. The calculation of LoanInstallment is not clear; they fix it with some specific condition and criteria of Grameen Bank and the Loanee. But from the values, it shows that when the Loan term is 1 it has no InterestInstallment and for other values it has the same result of LoanInstallment and InterestInstallment.
Page 127 of 141
MiCOpA
InvestorCode This table is used to keep the investor information. The columns are: InvestorCode: string type, identifier of the investor Investor: Name of the Investor, string type ItemCode This table contains the information about the Item that is the loan product. ItemCode: identifier of the Item ItemName: name of the item InvestorCode: identifier of the investor Function: not Known LoanInstallment: Loan amount to pay each time for this item InterestInstallment: interest amount to pay each time for this item SavingsInstallment: amount to save each term InterestRate: interest rate for the item TaxRate1: Tax rates for the item TaxRate2: Tax rates for the item TaxRate3: Tax rates for the item TaxDepositItem1: tax deposited for item by rate 1 TaxDepositItem2: tax deposited for item by rate 2 TaxDepositItem3: tax deposited for item by rate 3 MainItemCode: parent category of the item
Observation: 1. taxRate is not used in Grameen right at the moment. But they might be used at some time or in some other MFIs. 2. LoanInstallment. IntInstallment, savingsInstallment,why they are kept in this table? If these values are set in the LoanRegister table 4.1.7 then they are redundant here. Otherwise if they are fixed for an item, then in the LoanRegister table it is not necessary to add these fields. 3. MainItemCode keep the category information. All items are categorized under some Khatwary This table keeps the information about which loan was borrowed by how many women and how many male loanees, and how much amount for total male and total female loanees? This is a summary for the sex wise loan distribution in a branch. BranchCode: identifier of the branch BranchName: name of the branch ItemCode: ID of item ItemName: Name of the Item PurposeCode: ID of purpose Purpose : Name of ourpose
Page 128 of 141
MiCOpA
DisburseFemale: total amount of money taken by female with this loan item DisburseMale: total amount of money taken by male loanees with this loan item LoaneFemale: Number of female loanees LoaneMale: number of male loanees TotalDisburse: total amount disbursed for this item TotalLoane: total number of loanees,
Observation: 1. They are keeping track of male and female loanees and it seems Grameen has a great interest on it. But in Loanee table Loanee Sex is not included. 2. If it is like keeping the male and female loans and their number then the values should kept against per branch per loan item, ItemName and Purpose is not as they can be accessed from PurposeCode and ItemCode tables. MonthlyProcessFile The columns for this table are: BranchCode: ID for branch MonthlyProcessDate: DATE of processing, MonthlyProcessYN: Boolean, whether process has done or not BranchName: Name of the branch This table keeps the information of the date when a monthly process is done for a branch. PreMonth Is this table just an intermediate table? Is it a kind of report or we store this for previous months for a lonee and item. BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode string type, identifier of the Loan Item LoanTerm: number of terms of the loan Regular: whether the loanee is regular Drop: whether the loanee is Drop Token : whether the loanee is Token PrincipalLoan: total amount of loan LoanInstallment: amount paid in each term DueLoanInstallment: due InterestPaid: interest paid in each term DueInterestInstallm: interest due InstallmentDate: date of collection StaffID: ID of staff StaffName: Name of Staff
Page 129 of 141
MiCOpA
Observation: 1. How LoanTerm is defined here? Is not it redundant? Drop and Regular, Toekn these values represent the condition of the Loanee for each installment. But can be done by only one parameter. Actually this table contains all necessary values for the report and thats why it has repetitions. 2. StaffID is sufficient, Staff name can be found from BranchStaff table. 3. It seems to be an intermediate table that keeps the information about a loanees previous months transaction summary. This table is fed with data from the CurMonth table. PurposeCode This table keeps the purpose information. PurposeCode: ID for purpose Purpose: description of the purpose SavingsRegister This table keeps the savings BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode string type, identifier of the Loan Item PersonalSavings: amount of savings LoanTax: tax for the loan BankInterest: interest rate of the bank Withdrawal: money withdrawn FundLoan: Unknown/ unused FundLoanRepaid: Unknown/ unused Balance: total amount Absent: absent of savings in a date InstallmentDate: date of savings collection Observation: 1. Is savings kept as per loanee per item basis? Or is not it better to have as per loanee basis. In case of Grameen savings account is opened against each loan item taken by a loanee. 2. Absent mean the absence of savings in a installment date. But it generates rows where no savings is added. It was better if only when some value is added in savings account then to generate a row for this table. 3. Insatallment date keeps the record when savings added or withdrawn. Summary This table keeps the summary information of a particular item in a branch. The columns of tables are: BranchCode: ID for branch ItemCode: ID for item InvestorCode: ID for investor
Page 130 of 141
MiCOpA
OpeningBalance: Opening balance for the item DueInstallment: due installment on this item LoanRepaid: total repaid of this item SavingsDeposit: savings deposited against this loan item TaxDeposit: tax deposited against this loan item LoanDisburse: loan disbursed against this loan item SavingsWithdrawal: total savings withdrawn ClosingBalance: closing balance InterestBalance: total interest DueInterestInstallm: unused / unknown CurrentInterestPaid: unused / unknown PreviousInerestPaid: unused / unknown InterestClosingBala: unused / unknown RegularLoanee: number of regular loanee against this item DropLoanee: number of drop loanee against this item TokenLoanee: number of token loanee against this item Member: total loanee Absent: not clear Observation: 1. Many fields are not used as it seems from the sample data. 2. Summary is kept for each item in a branch. 3. It is not clear whether its a monthly based summary or yearly. As there is no date time attached with it, it seems that this summary is for the item from the starting of the branch till today. UpdateLoan This table keeps the intermediate states of al the loans disbursed to the loanees. It keeps the status, how much of the loan has been repaid and the status of the loanee, the time passed etc. BranchCode: string type, identifier for the branch CenterCode: string type, identifier for the Center LoaneeNo: string type, identifier for the Loanee ItemCode string type, identifier of the Loan Item LoanTerm: number of term PurposeCode: purpose code for the loan PrincipalLoan: total loan LoanRepaid: Total amount repaid CurInterestPaid: interest paid this installment date CurrentCharge: current interest rate PreInterestPaid: previously paid interest PreviousCharge: previous Interest charge LoanInstallment: loan to repay each term InterestInstallment: interest to pay each term InterestRate: Rate of interest Page 131 of 141
MiCOpA
DisburseDate: date of loan disburse Duration: duration of the loan taken for WeekPassed: week passed DropWeek: total drop Holidays: holidays InstallmentDate: date of installment JanuaryLoanInst: Loan installment for this month JanuaryInterestInst: Interest installment for this month FebruaryLoanInst: Loan installment for this month FebruaryInterestIns: Interest installment for this month MarchLoanInst: Loan installment for this month MarchInterestInst: Interest installment for this month AprilLoanInst: Loan installment for this month AprilInterestInst: Interest installment for this month MayLoanInst: Loan installment for this month MayInterestInst: Interest installment for this month JuneLoanInst: Loan installment for this month JuneInterestInst: Interest installment for this month JulyLoanInst: Loan installment for this month JulyInterestInst: Interest installment for this month AugustLoanInst : Loan installment for this month AugusInterestInst: Interest installment for this month SeptemberLoanInst: Loan installment for this month SeptembeInterestIns: Interest installment for this month OctoberLoanInst: Loan installment for this month OctobeInterestInst : Interest installment for this month NovemberLoanInst: Loan installment for this month NovemberInterestIns : Interest installment for this month DecemberLoanInst: Loan installment for this month DecemberInterestIns: Interest installment for this month
Observation: 1. Many repetitions. 2. Why this monthly Loan and Interest Installments are there as it is already mentioned in some other table. 3. Disburse date, Duration (not understood), Interest Rate is not needed here. 4. The monthly Loan and interest installments were used as because the loanee repayment amount varies in different season in the year (in harvest season they have more money). 5. Update Loan keeps the status information, but monthly installments are not clear whether they represent monthly repaid amount or the amount each term they should pay in each month. UpdateSavings Updates the savings status and SavingRegister keeps the transactions.
Page 132 of 141
MiCOpA
Column: BranchCode: Identifier for branch CenterCode: ID for center LoaneeNo: ID of Loanee ItemCode: ID of Item PersonalSavings: savings of this product LoanTax: tax BankInterest: interest of the bank Withdrawal: withdrawn from the savings FundLoan: Unused / unknown FundLoanRepaid: Unused / unknown CurInterest: active interest SavingsInstallment: amount of savings per term Balance: total amount InterestTransferCod: Unknown OpeningDate: start date MaturedDate: the date after which savings can be withdrawn Observation: In case of Grameen, four savings accounts are opened against a loan. This table keeps the status information of the savings accounts. But from this table it is not clear how the four tables are maintained.
Page 133 of 141
MiCOpA
Appendix B
Software Process Improvement
Software process improvement work is itself is based on models or strategies. Therefore, a few words on software process improvement work will be presented to describe what it involves and how it has been carried out in the MiCOpA project. The Shewhart Improvement Cycle provides a well-known foundation for process improvement work, and is used as a basis in for example the Capability Maturity Model evaluation frameworks [CMM, 2005]. As shown in the list below, it defines four steps for a general improvement process [Deming, 1982]. The Shewhart Improvement Cycle [Deming, 1982] [Humphrey, 1992] 1. Plan Define the problem Establish improvement objectives 2. Do Identify possible problem causes Establish baselines Test change 3. Check Collect data Evaluate data 4. Act Implement change Determine effectiveness In the MiCOpA project the Shewhart Improvement Cycle has been applied, although in a modified way. Step four and step three are excluded due to the goals, scope and delimitations of the MiCOpA project. The plan is instead that these steps, i.e. evaluating and determining the actual effects of introducing the improved process, will be followed up in future projects. The output of the three workshops and interviews resulted in much data about the current process and about problems that need to be solved in order to be able to develop software more effectively and efficiently in the future. In this process analysis and evaluation, Cockburns definition [2002] has been used as a starting point for structuring both the discussions and the data collected during the workshops, but also as a means to structure the results of the analysis. This work mainly corresponds to a bottom-up analysis and to step one and the first part of step two in the Shewhart Process Improvement Cycle [Deming, 1982]. Step two was then followed up by a top-down analysis by applying Boehms and Turners [2004] five critical evaluation criteria and process risk management approach to gain deeper understanding of the causes of the problems and to establish a baseline for the process. The polar chart and risk analysis were used as tools to Page 134 of 141
MiCOpA
identify the sources of risks and to understand whether an agile or plan-driven process approach would be the better choice of process. Once the risks where identified it was possible to define resolution strategies which were integrated into the definition of a baseline process. As a final step in the improvement effort more specific guidelines on how to carry out the proposed process strategy in practice was provided i.e. turning the strategy into an actual process. The results of the analysis also pointed out how it related to the requirements specified by the developers and how these were addressed in the proposed process.
Page 135 of 141
MiCOpA
Appendix C
Starting date
Plan of Work
Work package 1 - Process January 1, 2005.
Participants SU/KTH (Leader) Grameen Bank Objective The purpose of this work package is to analyse and evaluate the current software development process at Grameen Bank to arrive at a better understanding of an appropriate process for the development of a sustainable micro credit system. The objectives of the 5 months project period are the following: To establish an exhaustive understanding of the current development process in terms of strengths and weaknesses To investigate and understand the advantages and disadvantages of various software processes for the development of micro credit systems To analyse the feasibility of introducing an agile process, such as eXtreme Programming (XP) in this development and application domain To arrive at a specification of a recommended development process, based on the results of the analysis and feasibility study To contribute generally to the definition of a globally appropriate development process for the automatisation of micro credit operations Method Tasks Interviews, observations, case study. The tasks planned for the 5 months of project time are: T1.1: Analysis and evaluation of the current Software Process T1.2: Definition of an appropriate Software Process Deliverable The deliverable of the work package is: D1: Guidelines on an appropriate Software Process (Due April 30, 2005)
Page 136 of 141
MiCOpA
Work package 2 - Architecture Starting January 1, 2005. date Participants SU/KTH (Leader) Grameen Bank Objective The purpose of this work package is to analyse and evaluate the Architectural Design as implemented in the current MIS of Grameen Bank to arrive at a better understanding of an appropriate Architecture for the development of a sustainable micro credit system. The objectives of the 5 months project period are the following: To establish an exhaustive understanding of the current Architectural Design in terms of strengths and weaknesses To investigate and understand the advantages and disadvantages of various architectural approaches and standards (including the use of ontologies and QAW) for micro credit systems To analyse the feasibility of introducing a service-oriented architecture in this development and application domain To arrive at a specification of a recommended architectural design, based on the results of the analysis and feasibility study To contribute generally to the definition of a globally appropriate architectural design for micro credit operations Method Tasks Interviews, observations, case study. The tasks planned for the 5 months of project time are: T2.1: Analysis and evaluation of the current Architecture T2.2: Definition of an appropriate Architectural Design The deliverable of the work package is: D2: Guidelines on an appropriate Architectural Design (Due May 30, 2005)
Deliverable
Page 137 of 141
MiCOpA
Work package 3 - Technology Starting January 1, 2005. date Participants SU/KTH (Leader) Grameen Bank Objective The purpose of this work package is to analyse and evaluate the current Technology applied in the MIS of Grameen Bank, to arrive at a better understanding of enabling technologies for the development of a sustainable micro credit system. The objectives of the 5 months project period are the following: To establish an exhaustive understanding of the current technology environment in terms of strengths and weaknesses To investigate and understand the advantages and disadvantages of various technological approaches and standards for micro credit systems To analyse the feasibility of introducing the technologies of Open Source in this development and application domain To arrive at a specification of a recommended technology environment, based on the results of the analysis and feasibility study To contribute generally to the definition of a globally enabling technology environment for the automatisation of micro credit operations Method Tasks Interviews, observations and case study. The tasks planned for the 5 months of project time are: T3.1: Analysis and evaluation of the current technology environment T3.2: Definition of an enabling technology environment The deliverable of the work package is: D3: Recommendations on an enabling technology environment (Due May 30, 2005)
Deliverable
Page 138 of 141
MiCOpA
Work package 4 - Prototype Starting date Participants Objective February 15, 2005. SU/KTH (Leader) The purpose of this work package is to tackle the new generation software for micro credit operations jointly from the three perspectives that constitute the claim of MiCOpA (namely, Process, Architecture, Technology) in order to identify the mutual contributions and the expected benefits from joining the three perspectives develop a prototype for a new generation micro credit operation system, including a PDA solution, based on the guidelines put forward (as a proof of concept). The tasks planned for the 3 months of project time are: T4.1: Development of a prototype The deliverable of the work package is: D4: Prototype (Due June 30, 2005)
Tasks
Deliverable
The study is exploratory in its nature due to the fact that the system resides in a third world country. The environment in which the recommended techniques and technologies eventually are expected to be deployed present challenges of a different nature compared to the conditions under which industrialised countries normally operate. The processes of acquisition, building up, exploitation and maintenance of ICT, as well as the associated problems, require creative solutions that would not be thought of under more stable conditions of development. In this respect, this project will also provide better understanding of what factors in the developing countries affect the use of certain techniques and technology, and what factors can potentially change these circumstances. and its positive impact on the lives of people living in poverty. (UN, 2004) Detailed account of available resources including all personnel and equipment Stockholm University will be the leader of the project. Stockholm University will provide resources in addition to the funding provided by SPIDER, corresponding to 3 man-months worth of work. Grameen Bank and Grameen Communications will provide the pre-agreed assistance to conduct the research and the research activities. Grameen Bank and Grameen Communications will provide resources in addition to the funding provided by SPIDER, corresponding to 1.5 person-months worth of work.
Page 139 of 141
MiCOpA
Appendix D
Screenshots and the Paper Prototype
Figure D.1: Screenshot examples from the PDA prototype application.
Page 140 of 141
MiCOpA
The Branch Disburse: 200000 Repaid: 120000 Balance: 80000 Loan installment: 10000st installment: Intere 1000 Server address: (0) (0)
http://192.168.0.5:8080/micopa/dbServlet
Exit
Open Open
Download
The Branch: Centers Center code 1 2 Collection date 01/01/2005 01/02/2005 Details
The Branch > Center 2: Details Collection date: 01/02/2005 Disburse: 200000 Repaid: 120000 Balance:
80000 Loan installment: 10000 installment: Interest 1000
(0) (0)
Open Open The Branch > Center 2: Groups Collection date: 01/02/2005 Group no. 21 22
Details
The Branch > Center 2 > Group 21 > Details Collection date: 01/02/2005 Disburse: 120000 Repaid: Balance:
Details
72000 48000 Loan installment: 6000 installment: Interest 600 Full payment
(0) (0)
Open Open The Branch > Center 2 > Group 21: Loanees Collection date: 01/02/2005 Loanee name Erik Fredrik 212 Loanee number 211
Details
Save
The Branch > Center 2 > Group 21: Fredrik Collection date: 01/02/2005 Loanee number: 212 Purpose of loan: Fluorine Details Disburse: Repaid: Balance: 96000 33600 62400 Loan installment: Loanee absent
Interest installment:
(4800) (480)
0 0
Groups
Details
Save
Figure D.2: The paper prototype. Page 141 of 141

505

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

505

Uploaded by

Copyright:

Available Formats

SPIDER Research Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

5.4.10 5.4.11 5.4.12 5.4.13 6

KNOWLEDGE TRANSFER ACTIVITIES................................................................................... 97

RELATED WORK ......................................................................................................................... 100 CONCLUSION ............................................................................................................................... 103

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

1.1 MFIs and IT

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

1.2 The MiCOpA Project

1.2.1 Scientific and Technological Background to MiCOpA

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Figure 1.1. Enterprise Architecture of Grameen Bank.

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Figure 1.5. Business processes supported by IT.

1.3 Objectives and Expected Significance of the Research

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

2.1 Definition of Process

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Personality: Skill: Team: Technique: Tool: Activity: Process:

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Standards: Quality: Team value:

2.2 Description of Work Method and Research Approach

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

2.3 Analysis and Evaluation of Current Process

2.3.1 Elements of the Current Process at Grameen Communications

Correct and accurate communication, information and collaboration

Process Analysis Coding Testing Meeting

Business Executive Project Leader Developer