Beruflich Dokumente
Kultur Dokumente
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
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
Password Protection........................................................................................................ 96 Encryption between Client and Server............................................................................. 96 Encryption of data directory............................................................................................ 96 Protection of Audit Logs from Manipulation ................................................................... 96
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
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
Page 10 of 141
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.
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.
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.
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.
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.
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.
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.
Team Value
Smooth, flexible system with few errors! Quality Source code Functional Tests Training material User Manual Installer CD
5 step waterfall
1-5 Persons Activity Team
Product
Role
Personality
Standard
SQL VB
Code Comment: Change+Name + Date
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.)
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.
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 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.
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].
Page 29 of 141
30 10
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)
* 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
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
* 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
* 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.
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
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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
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
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.
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.
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
Page 65 of 141
Page 66 of 141
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.
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.
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.
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.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.
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].
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.
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.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.
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.
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.10
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 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
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
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
Page 80 of 141
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;
To make the string in figure 4.5 more readable, line breaks and indentation have been added.
Page 82 of 141
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.
Page 84 of 141
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].
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.
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.
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.
Figure A.1. The Grameen Bank organistional structure, the levels and the associated roles.
Page 89 of 141
MiCOpA
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.
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
Page 93 of 141
MiCOpA
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]
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.
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
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
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
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
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.
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
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].
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.
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.
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.
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
[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.
[CHAOS, 2005]
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]
[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.
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:
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.
[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.
MiCOpA
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]
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.
[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
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]
[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
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
[Steve, 2005]
[TAA, 2005]
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]
MiCOpA
Appendix A
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].
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.
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.
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
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.
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.
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.
MiCOpA
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.
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.
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
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.
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.
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
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.
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
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
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
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.
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.
MiCOpA
Appendix B
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.
MiCOpA
Appendix C
Starting date
Plan of Work
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)
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
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
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.
MiCOpA
Appendix D
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:
(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