SPIDER Research Project Report

Micro Credit Operation Automation

Jaana Väyrynen, PhD Candidate Gustav Boström, PhD Candidate Rafael Cordones Marcos, MSc., Research Assistant David Stoor, MSc. Candidate Salah Uddin Ahmed, MSc. Candidate Stockholm University/Royal Institute of Technology Sweden

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Page 2 of 141

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

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

MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Page 4 of 141 .

....................................... 36 CONCLUDING COMMENTS ON PROCESS ISSUES FROM A DEVELOPING COUNTRY PERSPECTIVE ........................................................................................ 50 GRAMEEN CURRENT SOFTWARE ARCHITECTURE .....2 3......... 19 2...............................................3 3............................................. 11 1............................................ 68 Palm Tungsten C and other Palm OS devices ........................... 49 Quality attributes and architectural analysis ............................ 69 The Simputer.............................................................1 2..................................................................................................... 9 1....................... 63 UML Domain Model.............2 2...........................................................................................................................5........................................... 27 Two Software Process Approaches................................. 53 Moap............................................. 11 1................. 50 DESCRIPTION OF WORK METHOD AND RESEARCH APPROACH ................................... 10 1. 67 4............................ 17 2 PROCESS ........................................................6......................... 47 ARCHITECTURE................ 70 Page 5 of 141 ........4...............2 2.. 27 Evaluation of Five Critical Process Factors ................................................................................5 THE LOAN COLLECTION BUSINESS PROCESS ..........4............................................................. 60 CLIENT ARCHITECTURAL PROTOTYPE....................................... 51 Software Inspection ...............3 OBJECTIVES AND EXPECTED SIGNIFICANCE OF THE RESEARCH ..... 67 EXPERIENCES FROM OTHER PDA SOLUTIONS .... 67 PDA TECHNOLOGY ..................................2 4...................5 3 DEFINITION OF PROCESS .................. 51 The environment of the Grameen Banker V3......................................................................4 3..................1 3..................... 52 Security Architecture Analysis...................3 DEFINITION OF ARCHITECTURE ....4 4......................6 3............ 57 Addressing Security problems with Security Components...........2 3............................ 53 Architecture of other Micro-credit software packages .................9 3...................3 4..................2.............................8 3....6 3........... 56 Addressing problems through Pragmatic Programming practices ..............................................1 MFIS AND IT......1........................... 69 Devices running Microsoft Pocket PC..... 49 CONSTRAINTS ON A SOFTWARE ARCHITECTURE FOR DEVELOPING COUNTRIES....................................................................4 3.......................................................... 52 Software Inspection Results ...................................4................................................................2 THE MICOPA PROJECT ..................................................3 2...........7 3...................................4.........................................................................5........................................4.3 4......................3 2..5 3......................................................1 2.................... 51 Grameen Communications Current Problems................................................................ 19 DESCRIPTION OF WORK METHOD AND RESEARCH APPROACH .................4 3.............................................................................4......................2 3...................................4.............................................4 2......................................................................................................MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Contents 1 INTRODUCTION............................................................................. 25 Requirements on the Future Process of Grameen Communications ......................................................................3......................................... 54 Compiere ..................................3..............................1 3.....................4......1 2.................................................................. 23 Elements of the Current Process at Grameen Communications............................................6...................................... 21 ANALYSIS AND EVALUATION OF CURRENT PROCESS ...........................2 3..............4......................................................4................................................................................. 29 The Future Base Process for Grameen Communications. 23 Problems with Current Process of Grameen Communications ..............5...... 49 3......1 4............................................... 68 THE PDA DEVICE ............................. 54 Aquadev ......................................... 60 Implementation Technologies..........................1 Scientific and Technological Background to MiCOpA.3 3. 61 Architecture ............................5 3.........................................4......................................................................1 4..4...................................................................................... 55 GUIDELINES ON ARCHITECTURAL DESIGN .......3...4....................................................................................................................................................................................4.........................................1 3.6......2 4...................5............3 2.................1 3...........0 Software....................... 56 Addressing architectural quality problems with Styles and patterns................. 70 JAVA 2 MICRO EDITION (J2ME)..........................................................................................................................................................................3 3.......1 3...............4.................................... 66 4 THE PDA APPLICATION PROTOTYPE ...............................2 2...... 26 GUIDELINES FOR SOFTWARE PROCESS IMPROVEMENT ....... 59 Architectural guidelines summary.............

......................................7...........................................3................................................... 84 4........7......................9.... 95 Logs of SQL Transactions ..............................................................................................4 5........5.............4.............4 5.........................................3 UML class diagram of the PDA application prototype ......................................................................3......7 Creating native applications in C/C++..........................................................................................7....................................................................................... 83 4.............................................. 77 4......................................................... 94 Security ..............................................8 AppForge Crossfire ................................................................8................................. 85 4.................................................................................... 94 Audit Trails..............3 Synchronization ...................11 The Loanee class........ 70 4........................................................................ 73 4......................................................................0.....1 5...........................5........8 OBJECT-ORIENTED STRUCTURE ....9...............................................................................................................................................................1 J2ME Wireless Toolkit..........2 The object model............................................. 71 4............. 95 Database Access Control............................. 76 4..................................................6.....................9.................................................5 Java Virtual Machines for Palm devices ................................................................... 94 Cost.............6........................5........ 78 4......................................6 The Sync class..............................................1 The classes of the MiCOpA MIDlet ............................................................... 91 ALTERNATIVES TO MS ACCESS DATABASE ..........5........................................ 85 4...................................................10 PDA SECURITY ..... 75 4.............................1 Serialization.7.........MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4............1 5.....................................................7................... 88 5..................................... 95 Page 6 of 141 ...........8 The Branch class .................................................... 72 4.................................................................. 76 4.....2 The MiCOpA class........................................................... 76 4....................................................2 The position of J2ME in the Java 2 family ...........................................................................3...............5........................................ 72 4............................................................................4........................ 94 Hardware choices..............................3 5....5........................................... 85 4........................4 The ListNode class.........................................................................................................................7.................................5.....4 Persistent storage ................ 80 4....... 81 4..8.......................5..........................................................9 J2ME and the Palm HotSync technology.........................................................................................................................................................7 ARCHITECTURE ........4.........................................9................................2 5...................................................................................................................................... 88 ANALYSIS AND EVALUATION OF CURRENT TECHNOLOGY ................ 89 Database Analysis ................................................... 76 4.........................................8 5............................. 91 Modifiability requirements ...................................................................6 Alternatives to J2ME ............................9............... 86 4...........5 Other solutions to synchronization and persistent storage..................................... 93 Multiple User Access ..............................................................................4......................................................................................................... 82 4........................ 72 4.. 84 4.............................................................7 5.......................9 SYNCHRONIZATION AND PERSISTENT STORAGE.............................4 5................................................................... 78 4................... 88 Main Functionalities.......... 90 Problems/Limitations in the GBanker3.... 86 5 TECHNOLOGY ..................1 The relationships between the business data ...............................................................................2 Regenerating objects from serialized data ............9......... 73 4...............2 The Eclipse development environment........................................................ 74 4.................................................................. 94 Audit Logs.....................7..................................6 THE ECLIPSE AND J2ME WIRELESS TOOLKIT DEVELOPMENT TOOLS .......................................... 94 Management of Large database ....5 The LinkedListItr class ..........................7................. 77 4............3 5................................................................................3 5........ 77 4........................................................2 5....4.2 5................................................................7............9.............4.............7 Nextel’s RMS toolkit ...........................7 Classes representing the business data ............................................................................................................................7... 85 4.................................9...............0 ......................................9 The Center class ........ 81 4................................................. 74 4................................... 76 4....1 5.... 88 ANALYSIS OF THE CURRENT GBANKER 3..........................9............................................................................ 77 4...................4.......................7.................................................................. 75 4....................................................................... 73 4.6 The db4o object oriented database system ........................................8..............................................................................4..........................9 DEFINITION OF TECHNOLOGY ......3 Configurations .........................10 The Group class ................................8 Sync4j ...1 Background............................................................4 Profiles ...11 HUMAN COMPUTER INTERACTION (HCI) ASPECTS .......................5 5........................................................ 71 4......................................................... 72 4.4....3...........................................................................6 5.............................. 83 4.......3 The LinkedList class ..........

.......................................4............................................................................................... 99 RELATED WORK ..................................................................................................0 ................ 103 REFERENCES .....11 5.......... 100 CONCLUSION ................4..............................................1 7......................BRIDGING THE DIGITAL DIVIDE WITH PURPOSEFUL OPEN-SOURCE SOFTWARE......................................................................................... 96 Protection of Audit Logs from Manipulation ..13 6 Password Protection..................................................................................................................10 5.......4...........12 5........................................................................ 113 SOFTWARE PROCESS IMPROVEMENT ........................................................................................................................ 96 KNOWLEDGE TRANSFER ACTIVITIES............................... 140 Page 7 of 141 ........ 96 Encryption between Client and Server............ 98 7.................... 98 CREATING AN ONLINE MFI MIS-SOFTWARE COMMUNITY ..................................................................................................................................................... 136 SCREENSHOTS AND THE PAPER PROTOTYPE .........4............ 105 APPENDIX A APPENDIX B APPENDIX C APPENDIX D ANALYSIS OF GRAMEEN BANKER 3................2 8 9 PARTNERING WITH UNIVERSITIES ................................................................................................................ 96 Encryption of data directory..... 134 PLAN OF WORK .......................................MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 5...................................................................................................................... 97 7 A MICOPA SOFTWARE NETWORK -.....................

MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Page 8 of 141 .

in the cases where there have been investments in IT. This has resulted in software that lacks flexibility in terms of customization and modification. wherein a group of borrowers guarantee each others' loans and the promise of continuing. [IICD. competitors and regulatory constraints. The effort has led to the development of micro credit. Thirdly. the relative lack of skills. This is possible because micro credit is based on repayment incentive structures. knowledge. 2004]. but the environment in which it is deployed in developing countries makes it unique in terms of the challenges in the process of acquisition. To deal with an increasing amount of customers. 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. development. Information technology is the same in developed and developing countries and regions. existing software and information technology is expensive. 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. Instead of building financial services around the principle of assessing the material possession of individuals. Page 9 of 141 . increasing credit for borrowers paying on time [GDRC. they have reached a critical stage and are facing many challenges. Although many successful micro credit organisations exist in the world today. information technology is not always an obvious solution. Micro credit is almost reverse to conventional banking methods. Investments in these regions of the world are still limited. experience and support in developing countries pose problems in all phases of the IT life cycle. Firstly.g. the sector must become more professional. The movement was initiated by a few volunteering individuals. 2004]. This implies a particular challenge of finding appropriate IT solutions and also appropriate ways to develop and deploy the IT solutions. the majority of whom are deprived of the services of conventional banking. i. 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. Reliability and efficiency are key factors. e. it has been introduced and developed only to help in solving the most immediate problems and focused only to serve the current operational needs. micro credit builds on the principle of assessing the potential of individuals [Yunus. while micro credit is free of collateral. Secondly.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 1 Introduction Poverty lending has grown to become a global movement during the past three decades.e. from a developing country perspective. peer group lending. a sophisticated loan methodology targeting poor and underprivileged people. 2004]. who sought for alternative ways of extending banking services to the rural poor. However. Conventional banking is based on collateral. deployment and maintenance.

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

The foundation should support every different fashion of micro credit operation to increase the service level to the poor and strengthen every organisation that uses micro credit systems as tool to alleviate poverty in the world. and to make recommendations on future software and system development. The MiCOpA project has provided a first attempt at such an investigation based on a case study of an existing micro credit system.1 Scientific and Technological Background to MiCOpA Based on the organizational performance problems. architectures and technologies for the development of micro credit systems. based on the case of Grameen Bank. comprehensive understanding of the system including the development of the system. Page 11 of 141 . Grameen Bank in Bangladesh. This involved an investigation of the advantages and disadvantages of various software processes.2. and an analysis of the feasibility of introducing new and innovative technologies in the particular development and application domain of micro credit operations and by taking into account the challenges of the third world. the technological difficulties and the major technological needs of MFIs identified. the main objective of MiCOpA was to investigate the automation of the micro credit activity. but also in an effort to give any interested stakeholders the opportunity to learn from the experiences of this project. 1. This has been carried out in an effort to provide a foundation for bridging the digital divide and to provide a foundation for the developing countries to take control of their own software development as a means to their empowerment. The aim is to strengthen the viability of these structures by investigating the automation of the micro credit operation at one of the world’s most successful micro credit organisations.2 The MiCOpA Project The idea behind the creation of the MiCOpA project is to support the emerging structures of micro credit organisations.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 1. The three thematic components are those of Process Architecture Technology The MiCOpA project has extracted value from the analysis of these thematic components and developed a knowledge base on the appropriate ways IT can be developed in future micro credit operations for the well being of billions of poor people in the world. The system has been analysed and evaluated on the basis of three thematic components that build a solid.

The Enterprise Architecture can be described as a "simple. To analyse the feasibility of introducing new innovative solutions for process. 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. architecture and technology based on the results of the preceding analysis and feasibility study 5. including a PDA solution. i. 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). 1. Page 12 of 141 . 2002]. to understand what recommendations to specify and how the prototype could support the needs of MFIs. To establish an exhaustive understanding of the current software process.. require understanding of the domain and the system.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report The purpose of the work was to analyse and evaluate the three thematic components based on a case study of Grameen Communications. architecture and technology in terms of strengths and weaknesses 2. Therefore. in this particular development and application domain 4. However. 1987]. and where and when it is used. To develop a prototype for a new generation micro credit operation system. To investigate and understand the advantages and disadvantages of various software processes. 2002]. a traditional systems development lifecycle approach was applied where the data gathered from the case study was transformed into graphical models [Dennis et al. architecture and technology. a software development company which belongs to the family of Grameen Bank enterprises in Bangladesh. In the MiCOpA project. The Case Study .Grameen Bank and Grameen Communications To make recommendations on future micro credit system development. respectively. what the system does. Below. required that business and systems analysis was carried out [Dennis et al. The objectives can be summarized in the following five points. There exist many different ways for structuring business and systems analysis.e. to arrive at a better understanding of appropriate solutions for the development of a sustainable micro credit system. defining the Grameen Bank Enterprise Architecture was taken as a starting point in the analysis. based on the guidelines put forward (as a proof of concept). including the development of a prototype of new generation micro credit software. To arrive at a specification of a recommended development process. follows a description of the work plan and the research approach.. logical structure of descriptive representations for identifying models that are the basis for designing the enterprise and for building the enterprise's systems" [Zachman. architectures and technologies for the development of micro credit systems 3. including a description of the case study.

In addition to specifying the Enterprise Architecture. Page 13 of 141 . the Enterprise Architecture of Grameen Bank is depicted. and organisational information. including development technology. business processes. including its internal elements and their relations. applications and data storage. customers. what the system will do. Figure 1.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report In Figure 1. which included identifying who will use the system. The results will be presented in detail in the following chapters. the existing MIS was investigated. IT products and resources. organisational operation including products.1. was also developed as a proposal of new generation micro credit software. Enterprise Architecture of Grameen Bank. including a PDA prototype. organisational structure and roles. improvement opportunities were identified and a prototype. and where and when it will be used. The Enterprise Architecture model. hardware platforms and software.1. The model visualises the elements of organisational vision. which are structured according to the three perspectives focused on. It captures the whole organisation in a graphical model that corresponds to an Enterprise Architecture. IT architecture. IT infrastructure. IT vision. goals and strategies. goals and requirements. in combination with other data gathered during the project provided the basis for understanding the system and how it would support the organisation.

Each has a responsible office manager who is responsible for reporting to the level above in the organizational hierarchy.3. This model describes the structure and the different levels of the organization and the roles associated with each level.2 below. This is an enlarged model of the business Page 14 of 141 . [Grameen. into the MIS. collected in paper form from Center and Branch operations. Below. the architecture and the technology. They are colocated with the Area Offices. Figure 1.1. The Head Office governs the whole organization and is managed by the Managing Director.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report i.2. The Grameen Bank organistional structure. the organisational structure of Grameen Bank is depicted as an enlargement from the Enterprise Architecture model shown in Figure 1.e. The Centers are central to the organisation because this is where the core micro credit operations are carried out in the villages. a static view of the Grameen Bank main business processes. The Centers consist of groups of members. the micro credit clients. In Figure 1. the process. There are eighteen Zonal Offices. the levels and the associated roles. There are eight hierarchical levels. their subprocesses and their relations are illustrated. 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. 2004] In Figure 1. i.e. 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. hundred twenty-seven Area Offices and more than thirteen hundred Branches dispersed throughout Bangladesh. 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. The Data Management Centers are responsible for entering the information.

Micro credit related business processes and the generated reports of Grameen Bank. Figure 1. running from Head Office to Centers. with the MIS.1. Trained Operator and Implementation Service. Hardware Infrastructure. easy and centralised monitoring on micro credit operation Today Grameen Communications is serving. Apart from finance and accounting processes. i. this points out the IT solution focused on in the MiCOpA project.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report process element from the Enterprise Architecture model shown in Figure 1. The MIS includes Software. this is where the existing IT. supports the micro credit activities. Grameen Communications was assigned to automate the whole micro credit activity of Grameen Bank. Although not clear in this example.e.3. To develop and implement Page 15 of 141 . the business processes modeled also indicates processes in the various levels of the organization. the micro credit activity of 1184 Grameen Bank Branches throughout the country. the MIS. 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. These correspond to processes primarily related to micro credit operations. approximately 4 million members (96 % of whom are women). For the reminder. hence. Grameen Communications Being a Grameen Bank family member with a Not-for-Profit organisational approach. Furthermore. 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. Note that the process Data Management of micro credits takes place under Area Office Operation.

Page 16 of 141 . Figure 1. A more detailed description of Grameen Banker is given in Appendix A.0 Operating System : Microsoft Windows 98 In Figure 1. the existing applications and the development technology used are visualized in an enlargement from the original Enterprise Architecture model. There exist four versions of the MIS Grameen Banker.4. because the project has primarily focused on technology solutions for the core micro credit activities and has not involved supporting applications. Grameen Communications has closely been working with Grameen Bank since 1997. Considering the operational needs.g. loan collection information. The existing MIS applications and the development technology used. is included in the model this application is out of the scope in the MiCOpA project.0 is undergoing.0 although a conversion to Grameen Banker 4. the application GB Accounts. e. an accounting MIS. Although. which supports the management of micro credit information gathered from field and branch operations. available techniques and technology. the following has been applied in the development of the MIS: Front-end tool : Visual Basic 5. The application is used at the Data Management Centers for entering data collected from the micro credit activities in the field.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report such an enormous MIS. The current version running in the majority of the Data Management Centers is Grameen Banker 3.4.0 Back-end tool : Microsoft Access 97 Reporting tool : Crystal Report 4. The Data Management Centers are located at each of the Area Offices (127 Area Offices in total).

the project aimed at providing better understanding of what factors in the developing countries affect the use of certain techniques and technology. the databases and the development technology used. the applications and the technology supporting the core micro credit activity at Grameen Bank.5. respectively.e. In summary. and what factors can potentially change these circumstances Page 17 of 141 . an enlargement of the elements of applications.3 Objectives and Expected Significance of the Research The MiCOpA project aimed at two things.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report In Figure 1. applications functions. 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. 1. 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. the application types. the hardware platform and the relation between IT. i. Business processes supported by IT. Figure 1.5 below. where details and project results will be presented from the three perspectives of process.e. 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.e. the main business processes. i. to • further uncover some of the challenges of software development in developing countries. the MIS. the elements of the organizational structure. architecture and technology.

Apart from this. 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. where the development process is central. developing countries should also strive for sustainable software development. Some projects exist. 2004] and MOAP [MOAP. MiCOpA has provided elaboration from a Bangladeshi perspective to couple with efforts made in these areas in other parts of the world. Furthermore. 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. which has not been done in any previous studies. 2005]. but there are very few projects found that have made efforts towards academic research. 2004]. based on three thematic components of Process. 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. The Open Source Model. Another important aspect is that this project has provided a strict software engineering perspective on the evaluation of MIS for micro credit operations. MiCOpA has enabled the formation and dissemination of this knowledge and competence in the academic field. A key to solve this is to provide these countries the tools that support development. Furthermore. PDAs also provide MFIs a technological opportunity to improve their operational performance. Page 18 of 141 . It should also be noted that a UN resolution proclaims the year 2005 as the International Year of Micro credit. which is critical for the long-term successful operation of any MFI. for example in open source projects such as Aquadev [IICD. Architecture and Technology. the MiCOpA project has pioneered the introduction of agile software development processes in the context of developing countries. research in the automation of micro credit operations is weakly structured. Agile software processes provide a unique opportunity to address these constraints and in helping software teams to achieve sustainable software development. 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.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • support software sustainability for MFIs by the use of new software engineering and technology trends in a developing country context. thus promoting the local development of software which also can solve the problem of financial constraints and dependency of western market trends. Furthermore. 2005] and in projects involving PDA solutions for MFIs [CGAP. considering the resource constraints. Consequently. opens up new opportunities for bridging the digital divide. in contrast to proprietary software.

technical and resource issues. Figure 1 To avoid unnecessary misunderstandings. The aim of the MiCOpA report is not only to provide Grameen Communications with recommendations on their future software development process. Page 19 of 141 . For example. roles and products. The observations show several software process improvement opportunities. In this chapter. although in later years there is a trend towards improved software results. This definition has several advantages. introducing a software process in a company also requires ways to deal with organisational. we report on the observations gathered from the case study of Grameen Communications. the definition of process refers to Cockburn’s [2002] definition of methodology1. in this case study. cultural. the term process has been used consistently throughout this project. Moreover. 2. The purpose of this chapter is to report on the observations. the stakeholders showed large differences in technical and business awareness and organisational maturity. process monitoring can be enhanced both for developers and management. such as activities. the problems identified. This can be achieved by introducing a software process.1 Definition of Process In the MiCOpA project. For example. productive and successful. The MiCOpA project aims at uncovering some of the challenges of software development in developing countries. effective. providing a definition of software process provides a good starting point to better understand the work actually undertaken. The failure or cancellation rate of software projects around the globe is still alarming. (c) general guidelines on how to evaluate and improve a software development process based on the case study. there exist no complete software process so initiating the building up a software process is already an improvement. guidelines on a base process for Grameen Communications. 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.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 2 Process The construction of software is a difficult undertaking. which is also applied in this report. However. and (d) as a proof of concept. the results of the analysis carried out in the MiCOpA project and to present recommendations on software process improvement. and as issues concerning software processes are tightly interconnected to software development this is also subject to investigation in this project.. and in recognising these elements in the analysis of the process of Grameen Communications. For example. it has proved a good starting point for facilitating the communication between project stakeholders. It has helped in focusing the analysis on the particular elements a process generally consists of. To be efficient. the definition has facilitated the structuring of the data collected and also the structuring of results of the analysis. software development teams need to be equipped with appropriate support. which facilitates the development of software. which have had a great impact on the choice of process.

The skills required for the role. The group of roles that work together to carry out activities.g. Cockburn’s [2002] definition of methodology. Role: A person who is part of the team. implying an orderly logical arrangement. The task or tasks to be carried out by the team or by individual roles to produce the product. The definitions of each element and their relations to other elements are. Personality: Skill: Team: Technique: Tool: Activity: Process: Product: Page 20 of 141 . its elements and their relations. its elements and their relations. e.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 2. tools or equipment used to support particular techniques. The personal traits needed attributed a particular role to carry out the activities. The means. illustrates Cockburn’s [2002] definition of methodology.1 below. how activities fit together.e. i. An output or deliverable.1. A particular course of action intended to achieve a result or milestone. education or talent in particular techniques or tools. often with a start and end condition.e. who is involved with one or several activities and who beholds the skills and the personal traits needed to carry out the activities. requiring particular skills and which are described in some tool standard. i. Team Value Process Milestone Quality Activity Team Product Technique Role Personality Standard Tool Skill Figure 2. The specific procedure for how to accomplish an activity. what is produced with particular techniques in one or a set of activities and described in a particular product standard.

products or techniques. The criteria used in assessments and evaluations of the products or the activities. in terms of strengths and weaknesses. 2005]. i. to gain understanding of the current software process at Grameen Communications. A qualitative approach based on group discussions was used to gain in-depth understanding about the current process and the requirements on a future process. To analyse the feasibility of introducing new innovative process solutions in this development and application domain 4. data was mainly collected during focus group discussions [McNamara. in terms of strengths and weaknesses 2. to identify the organisational structure of the team Page 21 of 141 .2 Description of Work Method and Research Approach The purpose of the work has been. based on the case study of Grameen Communications. based on the results of the preceding analysis and feasibility study In order to achieve these goals.e. marking whether milestones are met or not met at a particular point of time. The conventions adopted for tools. 2003]. to analyse and to evaluate the development process to arrive at a better understanding of the current process and way of working. Three workshops with the development team were organized. but primarily to identify problems particularly challenging software development from a developing country perspective and to provide recommendations on how to achieve sustainable development of micro credit systems. to identify the different phases and activities of the process. Standards: Quality: Team value: 2. The first workshop involved collecting data about the current software process and way of working.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Milestone: A time-related performance indicator marking work progress or completion. Quality can be of both quantitative and qualitative nature. 1. a comprehensive research method must be selected [Karlström. The underlying philosophy of the team. To establish an exhaustive understanding of the current software process at Grameen Communications. To investigate and understand the advantages and disadvantages of various alternative software processes for improving the development of micro credit systems based on the case study of Grameen Communications 3. The following was done: According to the first goal. The aim of the workshop was to gain understanding about the existing software development process at Grameen Communications. The objectives can be summarised in the following four points. To arrive at a specification of a recommended development process.

particularly. (Appendix B) The third workshop involved a specification of requirements on a future process. To focus the discussion on process weaknesses. which was based on the definition resulting from the preceding workshop. which the group had to respond to based on their perception of the current situation. tools support extent of documentation needed. people. even sample/prototype) Moreover. 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. to identify the problems of the current development process. Page 22 of 141 . i.e. 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]. a set of pre-defined questions was defined to guide the discussion during the workshop. its thirteen elements and their relations.e.e. 2005]. and to identify lackings and problems. (Appendix B) The second workshop focused on identifying the strengths and weaknesses of the current process. i. the aim of the third workshop also included a discussion on Rainer et al’s [2003] software process change motivators. data was collected through informal interviews with developers. The discussion was guided by a set of pre-defined criteria to cover the concept of process. That is. was used as a starting point. project success factors as defined by the Standish Group CHAOS report [CHAOS. roles and responsibilities standards. in order to identify the issues previously mentioned. level of correctness expected from the software length of increments (the time period until running code is delivered to client. The aim of this workshop was. The workshop was also concluded with a ranking of the problems according to a set of pre-defined criteria.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report including roles and responsibilities. software process improvement] happen? In addition to the workshops. and to identify any support tools and standards used. which included the specification of the following process elements: • • • • • • • workflow. 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. Cockburn’s [2002] definition of process.

3 Analysis and Evaluation of Current Process In this section a summary of the results of the three workshops. This will be described in detail below. Note that.2. then we know that we have done a good job and that is enough. technique and tool. Firstly. Existing software development process at Grameen Communications. illustrates the existing software development process at Grameen Communications. its elements and their relationships as described by the development team during workshops and in interviews. The third and forth goal mentioned above. this indicates a weakly defined process with clear gaps. Nor are any of the identified and currently present elements fully comprehensive.3. 2. information and collaboration” Team Value “Smooth.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 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. Secondly. is presented. 2. focused and competent staff” “As long as the client it satisfied. which is the second goal. the elements of milestone. there are elements missing. a summary of the identified current process is presented. which are described in Section 2.” “Correct and accurate communication.2 below.e. the results of the problems identified are summarised. respectively. when compared to the original definition of process. a summary of the requirements on a future process specified by the development team is presented. i. If following Cockburn’s [2002] definition. it is also indicated what each element involves as described by he development team. “Hardworking.1 Elements of the Current Process at Grameen Communications Figure 2. Thirdly. could also be realised based on an analysis of this data. but only partially defined.4. Page 23 of 141 . The analysis concerning these aspects were also carried out while applying well recognised software improvement techniques. In the figure. flexible system with few errors!” Quality Source code Functional Tests Training material User Manual Installer CD Process Analysis Coding Testing Meeting 5 step waterfall 1-5 Persons Activity Team Product Business Executive Project Leader Developer Role Personality Standard Skill Electrical Engineer Zoologist/Programmer SQL VB Code Comment: Change+Name + Date Figure 2.

The project leader is responsible for setting up the project. However. Training and Installation and Implementation. The business executive is responsible for clients. where one person is designated the role of project leader. Personality: Skill: Team: Process: Activity: Page 24 of 141 . involving a sequence of five phases. for leading the project and for assisting the business executive with technical issues. train end-user Installation and Implementation: make installer CD. “Seniority rules”. User Interface design and coding Testing: functional testing. collect report templates. Role: There are three project roles defined. The process is based on a traditional waterfall approach. prepare training material (“demidata”). sales and for business issues concerning the software to be developed. analyse existing system. System Development. The developer is responsible for programming and for developing the software. 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. report design. install the software properly at the client’s Product: The output produced in each phase of the process. debugging Training: write system user-manual. No supporting tools or techniques are used. the size of individual project teams varies between 1-5 developers.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Partially described elements Below. The skill required for a role is based on university education. i. follows a description of each of the identified elements in the Grameen Communications process as defined by the developers. Everyone on the current team beholds at a minimum a Bachelor degree in Electrical Engineering (from different Bangladeshi universities). the person with the most experience is designated the senior role. The five phases are Analysis. each phase including a set of activities or tasks to be carried out.e. Testing and Debugging. Most commonly a project team consist of 2 full-time persons. understand requirements System development: database development (physical). The entire software development unit currently consists of 5 persons.

(The team does not apply structured planning and does not have resources set aside for this. one general quality that is expressed qualitatively and subjectively by the developers as: “Smooth. “Change + Developer Name + Date”. which are cited from interviews with the developers. Planning is made on an ad hoc basis. i. Team value: Standards: Missing elements Technique: Tool: Milestone: There exist no techniques specifying how to accomplish an activity. from an organisational and a product perspective. The team values teamwork. However. equipment or other means of support can be identified.) 2.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Analysis phase: verbal requirement specification (frozen) System development: database. strong leadership and good quality products. flexible system with few errors!” The team values can be viewed from two main perspectives. The team also uses a common convention for commenting the code when changes are made. These are summarized below: • Complete lack of project planning and project management Page 25 of 141 . No tools. installed software at the client’s Quality: No criteria are defined for assessments and evaluations of neither the products nor the activities.3. the language standard used throughout current projects includes SQL and VB.e. The conventions and standards adopted for tools and products do only exist partially. source code Testing: error-free software Training: system user-manual. as indicated in the citations indicated in the figure. No milestones are defined. i.2 Problems with Current Process of Grameen Communications The output of the process problem workshop resulted in a few key areas that were listed as most problematic by the developers at Grameen Communications. trained operator Installation and Implementation: installer CD.e.

standards or other means to support software development Complete lack of organisational structure. techniques.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • • • • Complete lack of structure in process. 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.3. the main focus of the process improvement work will lie within these areas. in particular in the phases of analysis. i.3 Requirements on Communications the Future Process of Grameen In the third workshop. Complete lack of tools. the requirements on the: a) organisational level b) engineering level Page 26 of 141 .3 above illustrates which elements of a process. The prioritised process elements are highlighted with bold rectangles. the developers express requirements on two levels for an improved software development process.e.4 in this chapter. In general. design and testing. as defined by Cockburn [2002]. The developers also had to prioritise which requirements were most important. clear definition of roles and responsibilities Lack of balanced power between developers and management Consequently. that are most impacted by the requirements stated and prioritised by the software development team at Grameen Communications. A more detailed discussion on these problems will follow in Section 2. Team Value Process Milestone Quality Activity Team Product Technique Role Personality Standard Tool Skill Figure 2. 2. Figure 2.3. Developer’s requirements on future process.

g. 2. well-defined roles and responsibilities. developer empowerment. including good planning and project management. On the other hand. Moreover. and guidelines on a future base process.4. 2004].MiCOpA: Micro-Credit Operation Automation SPIDER Project Report From an organisational point of view the developers require a more structured way of working. such as US Department of Defense military standards (e. On the engineering level. the plan-driven and the agile. ISO 12207/15504) and the Personal Software Process (PSP) [Humphrey. Plan-driven processes values well-defined work products and are based on a wellstructured. there is a risk with the predictability generally required by plan-driven processes. workflows. the results of a top-down evaluation of the current process and identified problems according to Deming’s [1982] software process improvement cycle where Boehm’s and Turner’s [2004] five critical evaluation criteria and process risk management approach has been applied. In the two following sections. systematic and repeatable engineering approach. 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 team’s and the individual’s skills. roles and responsibilities and product descriptions.g. activities and products any project stakeholder will also know where to look for information. the prioritised requirements concern an improved specification of activities and the introduction of techniques and supporting tools to overcome the current performance difficulties. The major advantage of plan-driven processes is in the repeatability that standardization brings [Boehm & Turner. 1995]. the results of an software process improvement effort is presented. In Page 27 of 141 .1 Two Software Process Approaches There are generally two main approaches to software development. DoD-STD-2167). the identified problems and the requirements gathered from a more objective perspective to understand the feasibility of introducing any kind of software process. where requirements do not change. it is necessary to evaluate the current process. general process standards (e. more resources in terms of time and personnel. Documentation is important through every step of the process as a means to allow traceability across requirements. By the specific descriptions of plans. Plan-driven processes. 2. and improved formal procedures and leadership. are generally considered the traditional way to develop software. Plan-driven processes are most successful in stable development environments. Plan-driven processes are sometimes referred to as heavyweight processes as they include specifications of detailed plans. design and code. activities. including a brief overview of exiting process approaches in general. clear organisation structure.4 Guidelines for Software Process Improvement To arrive at a specification of a recommended development process. In the following sections. an overview of software development processes in general and a presentation of the approach to software process improvement that has been used in this project will be presented.

putting the focus of production on the wrong things. 2002] [Beck. it requires management support. XP is most effective in the context of small teams. For a plan-driven process to succeed.4. which is realised through the value of constant communication with the customer and within the team.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report today’s rapidly changing business world this does not generally apply. Design is simple. The cornerstones of XP are a set of tightly interconnected practices. 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. software teams caught in heavy processes run the risk of becoming documentation generators instead of software developers. according to Boehm and Turner [2004]. such as short iterations and continuous testing of the system. YAGNI (You Aren’t Going to Need It) [Beck. Because XP is the agile process that is most widely used [Charette. culture and dynamism. but we refer to Beck [2002] [2004] and Jeffries et al. Page 28 of 141 . the key to finding an appropriate process is. However. heavyweight software development processes. In section. [2001] when any specific XP concepts are used in this report. size. 2004]. XP emphasises customer involvement and promotes teamwork. Previous observations suggest that XP would be a potential process alternative for the development team at Grameen Communications. This evaluation has also been considered necessary for the evaluation of the process aspects in MiCOpA. simplifying the development of software is not to be compared with a simple method. this will be discussed more in detail. Frequent deliveries are also important to enable the customer to directly evaluate and approve the results. before releasing the system [XP. Crystal [Cockburn. 2001]. The individual XP practices will not be presented in detail. Moreover. The reason is to avoid over-designing a system in a vain attempt to anticipate future requirement changes [Rasmussen. Agile processes have been proposed to overcome the problems experienced with traditional. criticality. 2004].2. 1997]. the evaluation of five critical factors – personnel. 2001] Effectiveness is accomplished by structuring the software development process into short iterations. we have chosen to present it more in detail as a representative of the agile processes. 2002] and Dynamic Systems Development Method (DSDM) [Stapleton. 2004]. Adaptive Software Development (ASD) [Highsmith. XP is based on a pragmatic approach. 2. 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]. small to middle-sized projects and chaotic development environments with changing requirements [Paulk. There are a number of existing agile software development processes. 2002]. Scrum [Schwaber & Beedle. These depend on each other to form a whole that is greater than its parts. a welldefined organizational structure and infrastructure. a philosophy of XP. where an iteration focuses on timely delivery of working code and other artifacts that provide value to the customer. principles and values. to get the full benefits of XP is a demanding challenge for the project team. 2003]. XP emphasises rapid feedback through mechanisms. where the most known processes are eXtreme Programming (XP) [Beck. On the contrary. in brief. 2002]. and the fundamental idea is to simplify the development of software. However. However.

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Best practice – Iterative development Although plan-driven and agile processes represent two very different approaches to software development, there are some practices that are considered best practices in both fields. In particular, it is generally argued that an iterative approach to software development is preferred over a waterfall approach. Traditionally, software development has been based on the waterfall approach, i.e. structured development that moves sequentially from one step or phase to the next [Dennis et al., 2002]. Once the work of one phase is approved by a project authority, the phase ends and the next one begins. However, the growing need to develop information systems more quickly in the competitive business environment of today and the need to more quickly adopt changes in requirements, have resulted in a demand for software development approaches that respond rapidly to changes during development. It is not possible to follow a traditional approach and sequentially first define the problem, design the entire solution, build the software and then save all testing to the end [RUP, 2005]. Modern development approaches therefore emphasise iterative and incremental development that undergoes continuous testing and refinement throughout the life of the project. Iterative development means that each iteration is a movement from one version of the software to the next version of it. The waterfall approach is, on the contrary, one monumental release with only one version of the product. In other words, an iterative lifecycle assumes increments, i.e. an improved or extended version of the software at the end of each iteration. It also assumes short iterations between increments, i.e. in weeks or even days rather than months or years as assumed in the waterfall lifecycle. Because each iteration is short and ends with an executable release, allows for quicker feed-back and help in ensuring that the project stays on track [RUP, 2005].

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

Page 29 of 141

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Personnel (% Level 1B) (% Level 2 and 3)
100 40 30 20 Many Lives Essential Funds Discretionary Funds 10 0 0 15 20 25 30 35 30 10

Criticality (% Loss Due to Impact of Defects)

Comfort 50 5 10 30 100 300 90 70 50


Dynamism (% Requirements Change/Month)

30 10

Size (Number of Personnel)

Culture (% Thriving on Chaos vs. Order)

Figure 2.4. Mapping the home ground of Grameen Communications’ process.

It is clear that the process of Grameen Communications does not imply a pure application of neither an agile nor a plan-driven approach. To get a better understanding of which process approach is most appropriate for Grameen Communications, the deviations must be considered as sources of risk that must be addressed in a risk analysis. To deal with this Boehm and Turner [2004] prescribes a five-step, risk-based method as a way to plan for the future process which in this case will incorporate elements of both agile and plandriven methods. In other words, it is fully possible to use a combination of agile and plandriven approaches, but it is a matter of altering the right parts of the process, and to take into account the risks that the deviation from either home ground can pose on the recommended process. The five-step risk method to develop a risk-based strategy uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy [Boehm and Turner, 2004]. The risk analysis is used to define and address risks particularly associated with agile and plan-driven processes. The five-step risk method to develop a risk-based strategy uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy [Boehm and Turner, 2004]. The risk analysis is used to define and address risks particularly associated with agile and plan-driven processes. The risks are evaluated according to a set of criteria that are specified within in three categories of risks defined by Boehm and Turner [2004]: Environmental risks: sources of risks found in the general environment of development, which are evaluated based on the criteria of technology uncertainties (E-Tech), coordination of project stakeholders (E-Coord) and system complexity (E-Cmplx).

Page 30 of 141

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

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 project’s 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 team’s 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

taken the high rate of personnel turn-over Page 32 of 141 . MFIs throughout the world are facing great challenges because performance issues are becoming more and more critical for several reasons. 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. In addition. Moreover. Risk Management Step 2 – Compare Agile and Plan-Driven Risks Primarily. agile risks concern the use of simple design. In particular. more order and structure was requested. the risk of increased costs that come with changing and revising elaborate plans and specifications also must be addressed. In the case study. As MFIs are undergoing organizational changes (P-Change). the culture of Grameen Communications is an important factor that has an impact on the process. i. 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.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report proposed below in Step 4a of this analysis. On the other hand. the high rate of personnel turnover and the developers’ lack of skills in agile processes. the requirements concerned improved communication between management and developers and within the development team. Introducing a selection of plan-driven planning and architectural design techniques is a way to deal with the agile risks. Moreover. For example. and which must be kept updated throughout the project. the need for rapid results is therefore a risk that must be addressed (PSpeed).4 indicates that other issues also must be considered in this comparison of agile and plan-driven processes. respectively. it must be said that. Good understanding of the field is an advantage that can help them in stabilizing the basic system requirements. During the process requirement workshop. From a plandriven perspective. Grameen Communications belong a family of enterprises that have world leading knowledge the in microfinance industry. an over-reliance on detailed and frozen specifications can have a negative impact on the development if changes occur that can not be anticipated. 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. this can be motivated by the fact that the search for new software buyers will result in buyers with new requirements. which also agrees with agile processes.e. the polar chart in Figure 2. As mentioned previously. which requires faster development of supporting IT solutions. The environment is characterised by chaos and the team has succeeded in this environment. Performance issues are also closely related to the growing competition. however. 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. Another plan-driven risk involves the delays incurred by work involving the development of elaborate plans and specifications required by plan-driven approaches. 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 this respect. From a plan-driven perspective. requirements that correspond to business processes and organizational policies in their respective MFIs. although the requirements of the core parts of the system are stable. In the case of Grameen Communications. If MFIs fail in administrating business critical information can be devastating for their future programme.

The majority of the ratings also indicate that the risks are “serious but manageable”.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report and loosing key personnel. 2004]. and according to Boehm and Turner [2004]. 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. because skill will be required in either case. it would be appropriate to apply a risk-based plan-driven approach. the constraints (such as developer competencies and skills and technology and license costs) and the priorities. The lack of skills definitively puts any software process improvement effort on its edge. E-Tech: Technical Uncertainties One major source of technical uncertainty is the existing use of old and soon-to-beoutdated development technologies.3. which is rated a “showstopper” for both agile and plan-driven approaches. The only exception concerns the team’s current skills in processes. more reliable and sustainable technologies. It is easier to get started with an agile process and then build the process up where after needs are identified. To summarise. including Visual Basic 5 and Access 97. although it will still require recruiting an expert who can coach the team initially. however. which is generally provided by plan-driven processes. Agile processes require fewer resources in terms of expensive tools. It is important to determine the objectives. an agile risk-based approach is to prefer for several reasons. This technology conversion is not an easy task and involves several risks. it is therefore strongly recommended that structured Page 33 of 141 . If the system is to survive. To improve the system architecture. a selection of plan-driven practices to be applied within an overall agile framework is proposed. architectural design is currently implemented on an ad hoc basis. Risk Management Step 4a – Individual Risk Resolution Strategies Given that Step 2 resulted in a risk-based agile decision. rather than “showstoppers” [Boehm and Turner. 4 and 5. The next step is to identify a resolution strategy for each risk. Few agile processes are commercialized or requiring any license fees. The recommendations are discussed more in detail in section 2. On the positive side. Our decision is. templates and standards.4. to counter the risks of both agile and plan-driven approaches. which has resulted in a very weak system architecture that lacks in several aspects. Step 3 in the analysis is bypassed [Boehm and Turner. As mentioned. Grameen Communications need to convert to newer. this should be regarded as an opportunity to empower the team and taken from that point. A-Yagni: Anticipated change versus Simple Design YAGNI and simple design will definitively challenge the team for several reasons. to apply a risk-based agile approach. Plan-driven methods generally require certifications and training which is not required by agile processes to the same extent. 2004]. security and performance are practically non-existent. 2004]. Given these arguments. One of the main goals of the MiCOpa project is to address technology issues. creates a risk of missing or loosing critical information that only can be mitigated by more formal procedures. This includes for example documentation. Important qualities such as modifiability. The resulting work and the recommendations are presented in detail in chapters 3.

In addition to this. P-Emerge – Delays and reduced competitiveness An agile process will address the risks of delays and reduced competitiveness. were the salary and lack of incentives for developers to stay. 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. P-Change. it should be mentioned that change.3. A-Churn: Loss of tacit knowledge via personnel turn-over Another agile risk concerns the high personnel turn-over rate at Grameen Communications. Development is carried out in tight interaction between all stakeholders throughout the process. Two reasons for leaving the company. There are several strategies for how to avoid this problem. and would thus benefit from structuring the design activities to avoid the current architectural problems.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report design activities are introduced in the development process. 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. this risk of loss can also be reduced by introducing documentation as part of the process. communication and constant feed-back.4. 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. Page 34 of 141 . Once the team has structured system architecture in place (with help of the recommendations provided in chapter 3). P-Speed. mentioned among the developers. will also facilitate making changes in the system during development. Knowledge transfer comes with the value of teamwork. From an agile perspective. This involves introducing architectural techniques. The core parts of the system are stable and can to the most part be anticipated. 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 third strategy to mitigate the risk of loosing important knowledge is to establish an attractive and stimulating work environment. which disrupts an agile project’s reliance on tacit knowledge. For example. 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. such as competence development and further education of personnel. 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. Faster results and reduced delays are also addressed by short iterations in combination with pairprogramming and early and disciplined testing of the code. Agile processes addresses work environment issues by its very nature. such as system documentation as a complement to the existing user documentation. knowledge losses are reduced due to the team work and shared responsibility that come from following the values and practices of agile processes. In addition. Documentation techniques will be discussed in section 2. rather than having single programmers owning particular modules of the system as is the case today. 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. From a plan-driven perspective and which is not counteracting agile processes and values.4).

The other alternative is to educate the team or at least some key persons on development processes. Page 35 of 141 . A balance must be found to reduce the risk of project planning failure. the person or persons who get an education will have to spread the knowledge in the team. i. 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. This is the suggested baseline for improvement to be used as a starting point for Grameen Communications. by sending them to courses arranged by the local university or any commercial education. No plans or milestones make it difficult to measure progress. the general lack of skill in development processes is the greatest. whether an agile or plan-driven approach is chosen. On the other side. No planning at all as well as too much planning are both risks that can make projects fail. The coach should follow-up on the team until it is able to work on its own. In the following sections. 1982] i.e. guidelines on supporting development techniques. Risk Management Step 4b – Risk-based Strategy for Software Development at Grameen Communications In Figure 2. If there are not resources available to send the whole team. A baseline must be established according to the Shewhart Improvement Cycle [Deming.e. The figure depicts an overall process strategy that integrates the risk resolution strategies discussed above. A-skill/P-Skill: No skills in any development processes Of all the risks analysed. It also addresses the requirements specified by the team in the requirements workshop. It is a critical factor for a successful outcome in any process improvement effort. Because an agile risk-based approach is decided. tools and standards to be applied must be provided to be able to carry out development in practice.4. The first alternative is to recruit a person with process expertise to coach the team and to get them started on the process.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report However. 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. 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. There exists no skill in any process at Grameen Communications. This could be realized by putting him/her in the coach position for sometime.3. There are two strategies to address this and depending on the resources available at least one of them should be carried out. recommendations on a more comprehensive software development process will be presented. as no planning is taking place at all in the current process has created problems that should be addressed.5 on the next page. the result of the risk analysis is summarized. planning will follow agile strategies which are described more in detail in section 2. both on the organisational and engineering level.

the base process will be described in detail. staff and organize team * Develop shared system vision * Establish release plan (planning game) including milestones * Explore project risks and options (spikesolutions) System & Architectural Design Design. by describing what techniques.5. i. Development & Implementation * Establish iteration plan Whole team (project manager. In this section. both a bottom-up analysis.3 The Future Base Process for Grameen Communications The overall software process strategy.e. this is where the strategies turn into an actual base development process. Grameen Communications overall process strategy. Exceptions in the comparison were not less important. based on Boehm’s and Turner’ [2004] polar chart and risk analysis have been carried out. but were treated as sources to future improvement because of the focus of first defining a base process. including the risk resolution strategies are in place. above all. and what basic activities must be described to fulfill the strategy. Results in sync were filtered out and prioritized as areas that need concrete improvement actions. In the MiCOpA project. to implement the strategy requires that the activities for carrying out the strategies are specified. It determined what process elements. 2. were needed to implement the overall strategy. and a topdown analysis. customer representative) * Define and evaluate architecture options * Explore design risks and options (spikesolutions) * Develop highrisk components * Develop tests first and then code * Analyse feedback on current version * Reprioritise features * Prepare for next increment Figure 2. based on the workshops. However. In other words. Page 36 of 141 . coach developers.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Startup * Establish joint team. tools and standards is needed to carry out the process effectively in practice.4. By synthesising their individual results gave an opportunity to validate but also to compare and match the results of each analysis.

Development and Deployment.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report By synthesising the output of the workshops. Startup Startup * Establish joint team. the key areas provide a very concrete foundation for knowing where to focus improvement efforts to conform to the overall process strategy. It is a simple and effective technique for setting up the overall release plan for the system. A shared vision can consist of a system metaphor that visualises the overall system goals. such as missing team members. i. System and Architectural Design. Page 37 of 141 . The customer specifies what the system needs to do.e. 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.e. problems identified and requirements specified. • • • The startup workflow is added to the original process and recommended to overcome the current lack of planning. other resources or options. the outcome from defining the current process according to Cockburn’s [2002] thirteen element model. Find good representatives and identify any missing team members who are critical for the project outcome. which helps the team to work in the same direction. Each recommended workflow and their activities are described more in detail below. Identify any project critical risks. 2004] Explore project risks: Explore goals and the plan again. Workflow According to [RUP. [Beck. 2005]. Establish release plan: A planning game involves requirements analysis and defining project milestones. Develop shared system vision: A shared vision involves defining goals together. which conform to the overall process strategy. It is based on an agile approach. A joint team consists of both developers and customers. Three engineering workflows are recommended. “a workflow is a sequence of activities that produces a result of observable value”. the workflows of Startup. It also provides a good basis for communicating during development. The developers specify how much each feature costs in time to implement and what budget is available per feature. including the planning game that allows flexibility to counter plan-driven risks as discussed in the risk resolution strategy. 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. i.

This provides a basis for planning and negotiating what can be achieved during an iteration that will provide value to the customer. automate and run them as soon as new code is checked in to attain better software quality. 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. • • In its current state the process lacks greatly from any design work. a complementary and more detailed discussion about architectural design is also presented. Re-prioritise features: Collaborate to identify any risks or opportunities. Evaluate and deal with change requests. Design problems or technical complexity has to be addressed before starting a development iteration to reduce risks. Aim at writing tests early. Develop tests first and then code: Testing should be automated and done as early as possible to achieve high quality software. is added to the original process to balance the agile risk-based approach. 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. System and Architectural Design. 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). 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. Explore design risks and options: Explore and determine risks of various architectural options.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report System and Architectural Design System & Architectur al Design • * Define and evaluate architecture options * Explore design risks and options (spikesolutions) * Develop highrisk components Define and evaluate architecture options: Define and evaluate potential architecture choices. Analyse feedback on current versions: Analyse feedback provided from continuous testing and representative customers. and in order to avoid running into architecture breaking problems later in the development process.g. it is recommended that a new engineering workflow. Development and Deployment Development & Deployment • * Establish iteration plan * Develop tests first and then code * Analyse feedback on current version * Reprioritise features * Prepare for next increment Establish iteration plan: Break the overall release plan down to 2-4 week iterations. e. Spike solutions [XP. modifiable and easily customisable. The customer prioritises the requirements to be implemented in the current iteration. Therefore. The ideal is to develop tests first and then code. which is required if the system should be flexible. • • • • Page 38 of 141 . either by including them or postponing them to the next iteration. In chapter 3. reuse of existing architecture. Developers specify development tasks for each requirement and estimate the time to implement them. 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.

2002] and should have a clear purpose and describe how to do things. Furthermore. Every activity is assigned to a role. Whole team (project manager.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Although these three workflows may evoke the sequential phases in a traditional waterfall process. 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. which indicates the dynamic aspect that is complementary to the static aspect discussed above.6. depicts the roles defined in the overall process strategy and which should actively be involved all the way through the whole development process. A role defines the behavior and responsibilities of an individual. 2005] Figure 2. analyst developers. 2005]. a mere enumeration of the workflows. One individual may have many different roles within one project. Note that it runs horizontally throughout the three workflows. By breaking the overall release plan into smaller. and no definition of what roles should be involved and interacting within the workflow. 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. and repeats them with various emphasis and intensity at each iteration [RUP. Therefore.6. i. their purposes and their products does not quite constitute a process. The actual complete workflow of a project interleaves these three core workflows. which has the responsibility to carry out the activity within the corresponding workflow. Page 39 of 141 . The roles are actually taken from an existing role specification at Grameen Communications which are described below. an iterative approach is strongly recommended to enhance the team’s ability to respond to changes during development.e. Therefore. no detailed specification of the activities that should be realised within a particular workflow. 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. It does not include the dynamic aspect. the dynamic aspects are described below. customer representative) Figure 2. Recommended roles of development team. [RUP. there is no time-related definition. Activities and Roles and Responsibilities An activity is an individual task within a workflow [Cockburn. Whole team refers to the recommendation of improving teamwork and to also actively involve the customer on the team to facilitate collaboration and communication. This is only a static description of the process.

design and implementation phase. we recommend Grameen Communications to keep the original activity and role specification although with the some modifications: Page 40 of 141 . Activities and the assigned roles and responsibilities. Customer representative: an active role in the team. The customer is also involved in defining acceptance tests and verifies if the system functions according to the requirements.1. Analyst: will have day-to-day responsibility of the majority of the work during requirement analysis. He/She will also keep the Analyst and the Programmers informed of any deviation from agreed schedule. He/She will review the deliverables and the Change Authority for the requirements of the project. In particular. This is a reasonable specification that already exists at Grameen Communications. However. The customer specifies the requirements. The programmers will report to him/her in the development phase. The programmer will also train the client and the distributor personnel on the developed software.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Project Manager: will act as the main point of contact with client. 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. To address the requirements of better organizational structure and better collaboration. Activity Planning Requirement Analysis Architectural Design Detailed Design Development (Coding) Software Integration Testing Documentation Training Responsibility of (role) Project Manager Analyst Analyst Analyst Programmer Programmer/Analyst Customer/Programmer Programmer/Analyst Programmer Table 2. 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. and prioritises what requirements are most critical and needed first and what requirements can be deferred. he/she will produce the requirement analysis and design documents. but also as means to mitigate the risk of loosing critical information if someone leaves the team. The Project Manager will be responsible for the total project and will review the actual progress against the planned and institute appropriate action. Our observations proved that the specified activities are only carried out partially and that a programmer carries all the roles. Activities and the responsible roles are indicated in Table 2.1 below.

specify and agree on the purpose of documentation activities to mitigate risks of loosing information if someone leaves the team. Standards According to Cockburn’ [2002] definition of standard as one of the thirteen elements of a methodology. Documentation standards – The source code provides important documentation. to further improve team work and to facilitate communication. the team should come to an agreement regarding what documents to use.g. but this can be further enhanced with additional comments. e. However. e. The following three types of standards are recommended as part of the base process. it is also important for the team to agree on what tools to use and to what extent in projects. work products and decision policies to become more effective in communication and for the purpose of improved team work. 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. techniques and documentation should be specified. commenting design decisions taken so that other developers can easier understand the code. e. 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. standards are the conventions the team adopts for particular tools. There already exists a convention for code commenting in the current process. • For the roles to be able to carry out these activities efficiently and effectively. end-user resistance to automation.g. it is recommended that a person with this expertise is recruited to the team. The team should agree on a common code standard as means of communication via the source code.g. Page 41 of 141 • • . In particular for the developers. Tool standards – There exist many different tools that support development. Due to the problems programmers faced during training. tools. To further improve team work. • Code standard – The source code provides the most important documentation.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • 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. These will be discussed in the following sections. to standardise the use of vbUnit testing tools throughout all projects. Documents are important for various purposes which will be discussed in detail below. 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. who has expertise in change management. Another recommendation is to change the programmers’ current responsibility for the Training activity. it is clear that the responsible role for this activity should be a person or several persons. how to write them and where to keep them for easy access. supporting standards. If possible.

it is clear that supporting tools are needed to overcome the current problems. as well as tools to automate tests to facilitate testing. manage resources or use Wiki as a repository of files. The tools chosen runs on almost any platform. An iterative development process also puts particular requirements on tools because they facilitate much of the work during development. documentation and testing are required. The Grameen Communication process can be used with a variety of tools. because it can be downloaded for free from the Internet. 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. From a developing country perspective. Tools support A software development process requires tools to support all activities in a system's lifecycle. fixing dates. maintenance and monitoring of various products or deliverables. Wiki supports hyperlinks and has a simple text syntax for creating new pages and cross links between internal pages on the fly. tools that facilitate communication. Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. such as resources and skills. which allows usage on the existing machines. The choice of tools depends on several factors. which is an easy way for the developers to learn on their own how to use the tools. communicate and change. such as tutorials. In particular. Below is a list of the tools that are recommended and which will support the activities in the base process of Grameen Communications. With respect to this. the recommendation of tools is based on freeware and involves only a few basic tools to support the baseline process. Projects use Wiki to work on their documentation. these are also challenging constraints because the lack of both. to support requirements traceability. either commercial or freeware. The tools proposed also provide training material. Cunningham [2005] defines Wiki as the “simplest online database that could possibly work. To improve the process of Grameen Communications. "open editing" has some profound and subtle effects on Wiki usage. Like many simple concepts. to automate documentation. This includes tools to keep track of changes. version control. • Wiki – Wiki [Wiki. 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. Freeware does not strain the company financially. on-line manuals and documentation.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 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. Allowing everyday users to create and edit any page in a Web site is exciting in that Page 42 of 141 . especially to support the development. The technical requirements have also been considered. In other words there is no need to buy complementary and costly technology.

Another important aspect is that if anything would go wrong. • CVS – Concurrent Versions System [CVS. The developers can work on their local machines. 2005] is a free source code management system that helps developers keep track of version history. the less it costs to have them fixed both in terms of time and money generally required for fixing bugs [Astel. i. rather than done in an isolated phase in the end of the project. Thirdly. continuous testing reduces development time. Firstly. It allows for example creating. Secondly. This is possible because testing makes coding and coding results more visible. and which enables the project team to track and manage all change activities that occur throughout the software development process. earlier testing cuts development costs. It also provides some guidance on how to create UML diagrams.1) [Poseidon. saving. testing is integrated with the development process. but by having a CVS installed on a central server (on a server on the local network in this case). testing provides a good feed-back mechanism making it easier to take quicker action upon. which allows thorough testing of the code and facilitates determining if the software meets the requirements and performs as expected. and exporting the diagrams to various formats. CVS is a central station for code. In iterative development. By testing the software throughout the development process has several advantages. it has proved to greatly improve the quality of the software. the system also provides a safety net because the latest versions can be tracked and retrieved from the CVS. releases and parallel versions. Continous testing also prevents many bugs to pass by unnoticed and which generally involves high costs when discovered late in development. More specifically. • • Page 43 of 141 . 2005]. The earlier errors are discovered. It is adapted to beginners by providing an intuitive interface that facilitates the creation of diagrams. 2005] is an open-source based testing tool free of charge that helps the developers to create. 1999] diagrams. and proved a very valuable tool for effective communication among the project participants. VBUnit – vbUnit Basic [VBUnit. maintain and execute automated functional tests. To draw a parallel. Poseidon for UML contains support for all the UML (Unified Modelling Language) [Fowler. but it is recommended that the team learns UML to fully benefit from using this tool.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report it encourages democratic use of the Web and promotes content composition by nontechnical users”. CVS is an open source version control and collaboration system [CVS. developers can check out and check in files in a controlled manner and even work on the same files in parallel. 2004].e.0. A Wiki was also used during the MiCOpA project. which allows the team to coordinate both individual and team work. Poseidon for UML – Poseidon for UML (Community Edition 3. The CVS keeps track of the different versions that are kept in a central repository on the server. 2005] is a cost-free and simple graphical modelling tool for documenting requirements analysis and system and architecture design.

Therefore it is required that the documentation is not too advanced. testing. A balance between these parameters must be found. and therefore it is also strongly recommended as to conform to the overall process strategy. what they should contain and for what purpose the documents should be created. vbUnit will help the team to keep track of progress and achieve higher software quality. leaves the conclusion that the types of documentation proposed should be as supportive but as simple as possible. vbUnit allows that tests are written. and that (3) the documents should comply with an agile risk-based approach. The proposed documents address the current problems. but (2) at the same time lack of documentation skills. 2002].MiCOpA: Micro-Credit Operation Automation SPIDER Project Report vbUnit is a tool that is especially designed to offer automated testing and integration of design. It is also specified for whom the documents are useful. However. but also to allow for project management and other project stakeholders to monitor development. and coding [vbUnit. 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.. which will immediately indicate if everything still works. Documentation There are two main types of documentation: system documentation and user documentation [Dennis et al. the focus here will be on recommendations regarding system documentation. Page 44 of 141 . 2005]. because documents must be created to help the team and the company to overcome current problems. Given three parameters: (1) that there is a great need for documentation. and therefore the team should create them as part of the development effort to be delivered as part of the overall system. A set of automated tests creates a test suite that will stay in the project for as long as needed. the most important system documents are specified. Ambler [2002] provides a solution to this called agile documentation. Automated testing means that instead of manually testing a piece of code just once. the level of documentation competence in the team is a factor that must be considered. 2005]. it is possible to run all tests for the whole project. documentation is a strategy to overcome the identified risk of loosing critical information if a person leaves the company. Moreover. In Table 2.2 below. The selection of documents comes from a list defined by Ambler [2002]. After changing or adding a piece of code. Because user documentation is already in place. automated and kept in a test repository. There exist no documentation skills.

where the permanent models pertaining to the system (if any) are. risks. or references to them. Think simple. staffing estimates. i. Keep it just simple enough. may also be included where appropriate. Start simply. Recommended documents from Ambler [2002] to be created by the development team. and where other documents (if any) are. Project Management Programmers. use cases. Management. Page 45 of 141 . Executive Overview Project overview Requirements document Programmers. but not too simple. 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. This document defines what the system will do. Customer System documentation Programmers A summary of critical information such as the vision for the system. and the critical operating processes (some applicable to development.2. primary user contacts. Table 2. and scheduled milestones. the business architecture. Do not overwork a document. Project Managers Senior Management. By understanding the documentation needs will help in specifying what documents should be created.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Document Design decisions Roles Programmers. 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). Detailed architecture and design models. User Management.e. a document that is minimal enough for the needs of its customers then improve it when needed. user stories. 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. or essential user interface prototypes. Also provides references to critical project artifacts such as the source code (the project name in the source code control system is often sufficient). and the highlevel requirements for the system. such as how to build the system and some applicable to production. summarizing or composed of requirements artifacts such as business rule definitions. predicted benefits. technologies and tools used to build the system. Identify who needs the documentation and for what purpose the document is needed. such as how to back up data storage).

Get someone with writing experience. Collaborate with the customer and improve the document until the customer is willing to accept it. organize. Put the documentation in the most appropriate place. to reduce double work but also to reduce the risk of misunderstandings between documents. because they know how to select. for example on a wall. Create documents just before they are needed. Be selective. Display models and diagrams publicly. which can be difficult to achieve with documentation. by putting notes on a notice board or whiteboard or in an external document. Page 46 of 141 . For example. Documentation supports knowledge transfer. By introducing a selection of plandriven planning and architectural design techniques is a way to deal with the identified agile risks. If there are documents left behind. Any documents selected. Prefer communication over documentation. Moreover. whether in textual or graphical format must be updated with changes. To summarise. This facilitates transfer of information and thus improves communication. Open communication on a project reduces the need for detailed documentation. Collaborate with the customer. A person with technical documentation experience should be included in the team. Communication often results in better understanding. on a notice board. 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. Write the fewest documents with least overlap. Make documents easily accessible. to counter the risks of both agile and plan-driven approaches. Let the customer validate the document. whether it is by commenting design decisions directly in the code. Documents should only be created if they fulfil a clear. and immediate goal and which facilitates the overall project efforts. Make any models or diagrams visible. to avoid unnecessary misunderstandings. Eliminate waste. Identify and define a clear purpose and the goal of the document. structure and present information effectively. Complement documents with communication. it may also be a sign of useless documentation that does not provide value to the project. Wait. a selection of plan-driven practices to be applied within an overall agile framework is proposed as the future base process for Grameen Communications. Identify where the needs of documentation is most critical. Avoid writing overlapping documents.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report The customer determines sufficiency. Communicate within the team and with project stakeholders and encourage active participation in development. Keep documentation updated. important. or internal web site such as Wiki. 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. Document with a purpose. but this does not necessarily meant it does so in every case. this proposal also addresses process problems.

In order for developing countries to yield the benefits of IT. electronics. Lack of financial and human resources are clearly factors that constrain the introduction of IT. 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. and medical devices and practically in any programme. 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. developing countries should also strive for sustainable software development. among which dysfunctional customer-developer communication. Where IT is introduced these constraints are also reinforced by new constraints. 2.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report requirements and local constraints particularly evident in a development country context. These constraints are also particularly evident in the context of developing countries. 2004]. However. the transfer of IT to developing countries has failed somewhere along the way. However. In the MiCOpA project. the developers’ inability to reflect on their part in the development process. which means that tools. where the development process is central. the potential for local software development must be enhanced [Winschiers & Paterson. 2004]. effectiveness and higher quality. For example. making successful outcomes difficult to achieve. is an advantage because each project will require different kinds of process support depending on criteria Page 47 of 141 . Providing this in-built process flexibility. A key to solve this is to provide these countries the tools that support development. Considering the resource constraints. which are discussed in the following section. and the use of inadequate software development processes were emphasized as factors causing project failures in developing countries [Winschiers & Paterson. 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. techniques and goals need to be redefined within the local context and by taking into account the constraints in that context. In summary. providing a process successfully can only be achieved by adapting it to the local context.5 Concluding Comments on Process Developing Country Perspective Issues from a IT is everywhere. 2004]. a recent study points out several difficulties. The results of the case study support observations made in other studies. these constraints were addressed by the definition of an agile risk-based process [Boehm & Turner. organisation or industry promising efficiency. It increasingly pervades our daily lives and can be found in our vehicles. proving the existing lack of financial and human resources and the lack of organizational maturity.

Page 48 of 141 . In this respect. 2005]. 2005]. the MiCOpA project has provided a unique opportunity to pioneer the use of agile processes in a developing country context. and this applies to projects in developing countries as well as projects in development countries. the complexity of the software. If considering the observations made in other studies on software development and software processes in developing countries. and how often requirements change [Boehm & Turner. 2004]. There exist no “one size fits all”process [Boehm & Turner. [Winschiers & Paterson. but also in the micro credit field. thereby promoting sustainability.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report such as the size of the team. are also likely to apply in other developing countries. Once these factors are evaluated within the local context. re-used and maintained. 2004] [Indian NGOs. it is very important to recognise that the baseline process recommended here cannot be applied universally. By acknowledging this and the results of the MiCOpA project. However. [IICD. No software process can. Therefore. the competence levels of team members. there exist no other studies that discuss the use of agile processes in developing countries. 2004]. 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. Processes have to be adapted to the local context and current project needs. the base process can be adjusted. careful evaluation of constraints and sources of risk is still a pre-condition for successful. for example in [CGAP. 2004] the constraints for sustainable software development in the case of Grameen Communications in Bangladesh. To this date. long-term and sustainable process improvement.

A well-constructed software architecture should address the above problems 3. are difficult to implement. which comprise software components.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 3 Architecture In this chapter we analyze the software architecture of Grameen Communications Microfinance software and propose guidelines for improvement.1 Definition of Architecture Before starting it is useful to have an understanding of what software architecture is: “The software architecture of a program or computing system is the structure or structures of the system. Examples of problems that can occur are: • • • • • The system cannot support the transaction volume and becomes unusable Insufficient lack of security features leads to financial loss due to malicious manipulation of the system for personal gain The system cannot support changes in the business process and becomes an obstacle to organizational change The system doesn’t work properly because it is not constructed with its operational environment in mind The software application becomes more and more difficult to maintain and understand as it has no clear and logical structure In fact. Consequently it is important to analyze the suitability of the software architecture to the organizations needs.1. The organization must therefore determine the requirements on the software architecture. 3.1 Quality attributes and architectural analysis As was seen above software architecture can have a significant impact on the effectiveness of an organizations information system. for example addition of PDA’s for loan collection. but in the long term however insufficient attention to the software architecture of a MIS can lead to serious problems.. These requirements can be expressed as the Quality Attributes [Bass et al. They felt that their microfinance MIS could not be easily modified to new requirements. 1994] Software architecture is often neglected in software development. 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. It was also difficult for newcomers to understand the system. 1998] Page 49 of 141 . It is simply put not possible to change the organization to new requirements as quickly as needed because the information system cannot keep up. and the relationships among them” [Bass et al. This means that operational changes that are necessary to reduce the cost of operations.. This view has some merit in the short term. This leads to decreased organizational agility for Grameen Bank. the externally visible properties of those components. probably because it is seen as a purely technical discipline that is not very relevant for the business objectives of a company.

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.2 Constraints on a software architecture for developing countries Running an information system in a developing country has its inherent challenges. In many cases the cost of network traffic is also prohibitive. Field trips to get a an understanding of the environment of the software system 2. Interviews with developers and management Page 50 of 141 . but the system must be incrementally improved. so it is necessary to do tradeoffs. it is beneficial if systems are able to run on older hardware as well. for example a PDA?) Achieving good quality in all areas is either not possible or too expensive. the following activities were performed: 1. To determine these tradeoffs it is necessary to analyze the business environment of a system and to determine which qualities are the most important. Power failures are very common. This is the path followed in this report were we mostly concentrate on the improvement of Grameen Communications MIS for micro-credit operations.. 2004] which has as outcome the necessary quality attributes of a future system and their priorities.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report [McGovern et al. Cost constraints – Since computers are scarce. Most of the time it is not possible or cost-effective to throw away all previous work and start from scratch.0. This can be done using Quality Attribute Workshops [QAW. For example the following factors have to be taken into account: • • • • Network Connectivity is often limited . 3.Often a network connection is not available or maybe only available through a low-bandwidth modem. and computers need to be equipped with extra Auxiliary Power units.3 Description of Work Method and Research Approach To make an analysis of Grameen's software architecture. 2004] the architecture should possess. 3. Lack of electricity – Electric supply should not be taken for granted. In that case one can do an Architectural analysis of the existing system and propose improvements. Lack of skills – Architectures need to be more robust and simple to facilitate maintenance. In many aspects designing a system for use in a developing country is more challenging than doing it in a developed country [SIDAITStrategy]. Grameen Banker V3.

The computers are very heavily used for data-entry. a Quality Attribute Workshops were performed [QAW].MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 3. The only network that is available is a small LAN within the office itself. In this workshop Grameen Communications developers discussed the existing architecture with regard to Quality Attributes.2 Grameen Communications Current Problems To analyze Grameen Communications existing software architecture and the requirements of a future one.4 Grameen Current Software Architecture 3. Several hours every week are spent entering data.4. Perform Quality Attribute Workshops [Bass et al.1 The environment of the Grameen Banker V3. The Quality Attribute Workshop resulted in a good understanding of Grameen Communications architectural problems. None of Area Offices have an internet connection today.4. This means that the user-interface has to be very responsive and fast. The two systems are not integrated.0 is installed in Area offices mostly located in smaller villages on the countryside in Bangladesh. This workshop was used both to spread knowledge on the importance of software architecture and to gather requirements for an improvement of their existing architecture. The output of the workshop resulted in a few key areas that were voted to need most improvement. 3. 1998] to get an understanding for Grameens architectural requirements and to understand the current problems 4..0 Software Grameen Banker V3. 3. An custom accounting software built by Grameen Communication is also used. These were: • • • Modifiability (5 “1” votes) Security (2 “2” vote and 1 “1” vote from management) Performance (2 “2” votes) Page 51 of 141 . Analyze the current architecture by software inspection 5. Grameen Banker is not the only software used at the Area Offices. This lack of integration led to a lot of manual work. Analyze other current openly availaible Micro-finance software These activities then led to guidelines on how to improve the architecture. Analyze the security architecture of Grameen Banker with respect to the Common Criteria security standard [CC] 6.

Subroutines. This adds to the complexity of the code. However.4. This has the effect of an informal software inspection. The modularity constructs of the language (Modules.4 Software Inspection Results The results of this analysis were as follows: • Structure – The code is very poorly structured. Logic is not split up into different procedures.4. It is very hard to tell from the names in the code what it does. it would be insufficient to base all of the analysis on just Grameen Communications own opinions regarding their software architecture. User interface and business logic) separated as well as possible? 3.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Consequently the main focus of the architectural work ought to be in these areas. Classes.). and quite few comments in the code. Documentation – there is no code documentation. This makes the application very hard to understand. Subroutines and Functions) are very little used.3 Software Inspection As a complement to the workshops time was spent looking at the actual code of Grameen Banker V3. Classes. 3. is it normalized?) Separation of Concerns – Are different software concerns (E g. Naming – The names of Forms. The code was analysed with regard to general software engineering principles such as: • • • • • Structure – Is the code well-structured? Does it use the modularity features offered by the language? Naming – Are the program constructs logically named? Documentation – Is the code documented through code documentation and comments? Database design – Is the database designed according to good principles (E g. Modules and Functions are frequently not indicative of their purpose.0. There are very many procedures that are too long and complex. • • • Page 52 of 141 . Database design – The database is not normalized and it contains a lot of duplicated fields (This aspect is very important and will be more thoroughly investigated in a separate section in Appendix A: “MS Access Database analysis”. This input needs to be complemented with a software inspection. For example there are only three VisualBasic classes in the entire system and only one module.

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

Separation of concerns – User interface code and business logic code are completely mixed. This makes it very hard to see what parts of the code deals with business logic and what parts is only concerned with user-interface issues such as layout. Very few security features – The only security feature consists of login-screen which queries the database for an unencrypted password and username.

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

3.4.6 Architecture of other Micro-credit software packages
As the aim of this project involves investigating the feasibility of introducing Opensource technology, it is interesting to see what other free Open-Source alternatives that exist. From a search on the Internet (Using the search terms: “Microfinance” and “Opensource”.) and browsing the MFI Gateway website [MicrofinanceGateway, 2005] we found the following software: • • • • MOAP (no working software) MIFOS (Preliminary stage. This project was started very recently, so it has not been thoroughly analysed yet.) Aquadev Compiere (Not a Micro-finance package, but it could be customized to become one)

Page 53 of 141

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

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

MiCOpA: Micro-Credit Operation Automation

SPIDER Project Report

• • • • •

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

this would be a very good alternative. for other projects however and for Grameen. In this project this was not possible to achieve because of the short time frame. Architectural Styles [Bass et al. but in order to succeed in this quite a lot of time needs to be invested in learning.5 Guidelines on Architectural Design In this section we describe our recommendations to Grameen on how to overcome the problems with their present architecture. Integrity checks Modular design Modular design has been one of the cornerstones of software engineering for a long time. A Style can be seen as a tactic to achieve architectural qualities. it is very often not achieved. Probably it would be necessary to participate in a course given by the Compiere company. 3.1998] is a way of doing just that. experience and lack of process design activities. Access Control. What is needed is a way to address the poor architectural qualities of Grameen Banker. Layered architecture. In Grameen’s case this is probably due to lack of time. Some common patterns that are useful in this regard are: • Model-View-Controller • Strategy In the following list we present useful styles and patterns that can address the Grameen Bankers shortcomings: Quality Modifiability Security Styles/Patterns Modular design. Design patterns (see for example [Gamma et al..1 Addressing architectural quality problems with Styles and patterns In general what Grameen needs to address their architectural problems is sound software engineering. As a further more concrete and detailed illustration see also the description of the Client Architectural Prototype in chapter 2. Today the process is totally chaotic and there is no wonder that this leads to poor structured code that is hard to maintain.. Strategy Audit Trails.5. 3. Model-View-Controller. surprisingly. Yet.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report probably possible. So what is a module? Here is a definition: Page 56 of 141 . 1994]) are also useful tools for an architect to use when addressing modifiability problems. Pragmatic Programming practices and Security Architecture components. This is done by referring to Architectural Styles. Design patterns.

Layered architecture Using layers a common tactic to promote architectural qualities [Bass et al. There is no need to go through the entire application. This well-known example would be beneficial to follow also for Grameen. In this way it is easier to make a change to one layer without affect the other. This would then follow the Table Module design pattern [Fowler. The MVC-pattern is basically a description of how the Userinterface layer should interact with the business logic layer.. something is modular if it is constructed so as to facilitate easy assembly. which means that business rules can be changed in runtime and not only by programming. the Strategy to use is also determined by configuration data.2 Addressing problems through Pragmatic Programming practices Other tools for addressing the problems can not be classified as patterns. a basic rule of thumb can often be to have one module per database table (Provided that the database design is well done. Strategy pattern The goal of the Strategy-pattern [Gamma et al. by using different Strategies one can change business rules in an application. This would make the application simpler to understand since all logic would have it’s place. which has a well-defined interface to the other components. for example to add some data that needs to be tracked for loanees. This would make the application easier to change. A useful reference when addressing these general issues is the book: “The Page 57 of 141 . This component would then have a defined interface that would be used by other modules. E g. flexible arrangement. By introducing the Strategy-pattern it thus becomes easier to modify the business logic of an application. However. one only needs to change the Loanee register component..5. 3. This could for example be the way interest payments are calculated. 1994] is to make it possible to switch algorithms in runtime. a simple layout change in the userinterface will not affect the database layer. 2005] In a Micro-finance perspective one module might for example be “Loanee register”.. This requires detailed a more detailed analysis of the entire Micro-finance domain. It is common way to make software more modifiable. Exactly how the application needs to be split up into components is a complex question. If one need to change the Loanee register.1998].”(wikipedia search on “module” [WIKIPEDIA. An application is then split up in different layers that each has its specific purpose. 1998] is a software pattern specifically targeting the design of user-interfaces. This also provides for better modifiability. but just good practice. a Business logic layer and Database layer. Model-View-Controller Model-View-Controller (MVC) [Bass et al. Since Grameen Banker mostly consists of userinterface component this pattern would also be good to follow in order to achieve a better structured application. 2002]. Frequently.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report “A module is a self-contained component of a system. something that has to be addressed first). and/or repair of the components. One of the most common examples of this is when you split an application into a User-interface layer. For example.

If this is not the case. An example of this is Javadoc. The longer you wait the harder it gets. every time this knowledge changes. Documentation is also important to support this practice. Make it easy to reuse It's all writing Separate Views from Models. Eliminate Effects between unrelated things. 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 A modular structure makes it easier to reuse components.. Refactor early.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Pragmatic Programmer”. If it is felt that the design could be better it is necessary to change it as soon as possible. and it is often the case that when hurried changes are made. This leads to bad modifiability and poor structure. Otherwise the code becomes very difficult to understand. [Hunt et al. Eliminate Effects between unrelated things This practice is basically a call for modularity and layering. Refactor early. a documentation system that is Page 58 of 141 . Build documentation in. Don't bolt it on Producing documentation for code is important. This however takes time. Failure to do so will result in a system that is poorly structured and hard to modify. refactor often The idea behind this pattern is that the first design that you come up with is not necessarily the best one. Separate Views from Models This practice is mainly a call for using the Model-View-Controller pattern. changes will have to be made at many different places. refactor often Build documentation in. there is no time to also update the documentation. Every piece of encoded knowledge should have only one representation in the software. Programmers should carefully choose their naming to communicate intent. It’s all writing With this practice is meant that good code should clearly communicate its purpose. Don't bolt it on Poor code documentation DRY – Don't Repeat Yourself This practice is one of the most important in programming. Therefore it is better to generate as much documentation as possible directly from the code.

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

Other micro-finance applications developed by Grameen Communications[Grameen Software] and other projects like MOAP[MOAP. Possible easiest done at the database level Enforce access control on files through operating system features Increase the strength of the authentication.0 demo application from Grameen Communications[Grameen Banker Demo] Grameen Banker 3. User Manual[Grameen Banker Manual] Grameen Banker 3. In order to find the requirements of a client application for a micro-finance institution we used the following sources of information: • • • • • Grameen Banker 3. 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.0. Business logic and Database Organize the user-interface code according the Model-View-Controller pattern Organize business logic that needs to be configurable according to the Strategypattern so that they can be changed by configuration Study Pragmatic programming principles to improve the design of further versions Security recommendations: • • • • Implement database security to prevent unauthorized access to data Put in place Audit Trails to track changes to data and allow for accountability.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 3. and to make it happen it is important to also implement changes in Grameens development process.4 Architectural guidelines summary The guidelines for a future Grameen Banker application can mainly be summarized as the application of sound design principles. MS Access database structure Meetings with a developer from Grameen Communications.6 Client Architectural Prototype In order to test some of the proposed guidelines and in order to test the some of the opensource technologies.0 application. Possibly through use of database authentication features 3.5. Data- Page 60 of 141 . Here is a summary of the general recommendations: • • • • • Split the application into logical modules according to business functionality Layer the application into User-interface. The application needs to be considerably redesigned to improve its architectural qualities.0 is architected as a one-layer Visual Basic 5.0. Forms are drawn in Visual Basic Studio and the Visual Basic code implementing the domain logic is inserted in the controls/widgets. This is a large effort. we implemented a small architectural prototype of a client application to support a small but relevant set of use cases. 2005] Grameen Banker 3.

database tables are created to store temporary and intermediate results (Appendix A “Grameen Banker 3. By analyzing the demo application (see Appendix A “Grameen Banker 3.6. Usually there is a one-to-one relationship between forms and database tables. 3.e. Choosing an implementation language was a relatively easy task given the constraints we had: • • developers are experienced with a procedural Visual Basic programming paradigm the syntax of the language should be relatively similar to Visual Basic Page 61 of 141 . 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. Furthermore. Therefore. when a full migration to Linux can take place. for every table a form is created to update the data in it. be able to run also with minor modifications. This means that developers have a good experience with Visual Basic. there is a great shortage of personal computer in developing countries and thus. Developers should be able to design data-entry forms graphically as they do now with Visual Basic. i. This is because they have to enter enormous amounts of data every day.0 Analysis”). it is very rare that computers can be exclusively dedicated to run MFI applications and are also used for other office tasks. Besides. That is to day. MS Access and MS Windows. 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.1 Implementation Technologies We surveyed available open-source technologies to develop an architectural prototype for a micro-finance client application in order to test the implementation of some of our recommendations on architectural design. Since the very beginning we saw that proposing the replacement of the operating system (Windows) for an open source one (GNU/Linux) was not a viable in the short or medium term because MFIs use other Windows applications on the same computers they run their accounting systems and requiring a switch to Linux would prevent them from running them.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 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. our proposed technologies should be cross-platform in order to initially be able to run on Windows and. Grameen Banker and most of the other MFI applications are developed in Visual Basic for the Microsoft Windows platform.0 Analysis”) we learned that it is very important for branch operators to be able to enter data in an efficient and quick manner.

Up to now. 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).1. 3.2 Qt Qt[Trolltech. 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. Page 62 of 141 . 2005]. This means that applications developed with Qt can be recompiled and run on all three platforms without having to change the source code. 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. 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. given that we did not use C++ as a programming language. which is a library that enables the use of the Qt framework from Python. 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. Trolltech is a Norwegian company founded by the creators of Qt to support their product.1 Python We chose the programming language Python[Python. XML processing and introspection. we used PyQt[PyQt.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • • • • 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. Java was not chosen mainly because graphical Java applications require a lot of computing resources which are not available at MFIs. 2005] for the implementation of the architectural prototype. offering other development facilities like data-aware controls. 2005] is a complete C++ application development framework which provides source-code compatibility across the Windows. Qt is not only a GUI toolkit but a full application framework.1.6.6. Mac and Linux platforms. Furthermore. Qt also provides a WYSIWYG form editor (QtDesigner) that stores the form definition in XML which can be later translated to Python code. As mentioned before. Nevertheless.

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. members.3 SQLObject SQLObject[SQLObject. …). The big advantage with this technology is that we do not write SQL statements in the domain layer code and therefore. 2005]: an object-relational mapper that automatically bridges the data source layer with the domain logic layer.4 ReportLab Toolkit The ReportLab Toolkit [Report Lab]: an open source PDF library used for report generation. We create Python classes that represent the objects in our domain and they are persisted in the database. 2001]. 3. products.6. We found documentation regarding the development of applications with Qt in the form of two books: “C++ GUI Programming with Qt 3”[Blanchette. visualizing and modifying the entities of the domain (loan. The prototype has a layered architecture as show in Figure 4. the ReportLab Toolkit lacks a visual report editor like the one offered by Crystal Reports. Figure 3. the new application would still suffer from the architectural deficiencies as the current one. 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.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Nevertheless.2 Architecture Given the guidelines on architectural design we implemented a small prototype to test some of the proposed technologies for the client application.1.1. This is the only reporting library we found that can be used from Python and that is open-source. 2004] and “GUI Programming with Python and Qt”[Boudewijn. 2005]. open-source linguistic application called Kura[Kura. Only the latter focused on programming applications with Python and Qt. Architecture of the client prototype.6. we make it independent of the database technology. This toolkit plays the role that Crystal Reports play in Grameen Banker 3. Nevertheless. Page 63 of 141 .0. 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. 3.6.1. 3.1. The prototype also implements the Model-ViewController pattern for accessing.

3.4 Data Layer The data layer is stored in a MySQL database. we followed the guidelines proposed in [Boudewijn.3 Object-Relational Mapping Layer This layer contains the functionality to communicate with the database in which the data is stored/persisted. 2005].6.2. The visual forms in which users enter data are created and maintained with QtDesigner (see Figure 3.4 for further details on the technologies used in this layer. See Section 3. On Figure 3.2. loans. .2. This layer contains the functionality to manage the entities and processes a micro-finance institution deals with (members.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. 3. 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).. 3. The domain layer is implemented in a Python module called micopalib.4 “Domain model” for more detailed description of the domain model.6..).6.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report For the implementation of this architecture in Python in the prototype. SQLObject provides an implementation of a RecordSet that we use to pass data back and forth through the different layers. This layer is implemented as a Python module named micopagui. 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. 2001] and in the Kura application.3 we show the prototype showing purposes for a loan and a dialog to edit one of them. Page 64 of 141 . Given that SQLObject has support for other database we also added support in or prototype to use a file-based database called SQLite[SQLite. we can automate or add ad-hoc functionality to the application with independence from the GUI.5. Furthermore. payments.2 Domain Layer In this layer is where the actual work is done.6. See Section 5.

Designing forms in QtDesigner. Management of purposes for loans.2. Figure 3.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Figure 3.3. Page 65 of 141 .

3 UML Domain Model Page 66 of 141 .6.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 3.

although that still is a considerable amount of money in this context. either commercial or as open source. data will instead be transferred by connecting the PDA to the PC. When visting a center. 4. The data are then transferred manually to the Grameen Banker software running on a PC. dust. To keep the costs for a PDA solution down. When developing a PDA solution to be used in third world countries. nowadays PDAs with fair computing power that cost less than $100 exist. the field worker needs specify how much each loanee has paid. the field worker uploads the updated collection sheet data to a PC. MFIs that have tried PDA solutions have developed their own applications. The costs for developing the PDA solutions have ranged from $20 000 to $80 000 and the durations of the development processes have ranged from nine months to two years.1 The loan collection business process Using the PDA prototype application the loan collection process would start with the field worker downloading the collection sheet data from a PC to the PDA. choosing free or inexpensive technologies is often preferable. Costs are often crucial and a PDA solution could probably help in further reducing the administrative costs for MFIs. it would also probably result in a more widespread knowledge about how to develop and use the technology. This PDA prototype application does not perform any other operations.2 Experiences from other PDA solutions The idea of using PDAs for automating micro credit operations is not new and som MFIs have tried it. Today. Currently. the field worker should take a note of that. However. The solution should also be easy to use since the end users are often inexperienced with computer technology and training a large number of employees would be expensive. installments for each group of the center are collected. Since cost is an important issue to MFIs. After collecting installments from all centers. An open source solution available to all MFIs would not only reduce the costs for implementation. [CGAP. 2005]. but they are also more expensive. There is no such software available. The availability of an open source – or even a commercial – Page 67 of 141 . Even if a well-functioning free software solution for PDAs would exist. so the MFIs have developed their own solutions.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4 The PDA application prototype The purpose of the PDA application is to automate the loan collection process. There are PDA models with a more ruggedized design. With a PDA solution. 4. The needs for maintenance should also be considerably low as that also would add to the costs. Also. A PDA that is to be used in a third world country field environment should also be able to withstand heat. If the collected amount differs from the expected amount. most of them in Latin American countries. if a loanee does not show up at the meeting. like handling loan applications or extensive financial calculations. the cost for the PDA itself is harder to overcome. the aim for the prototype application has been to make it capable of running on simple and inexpensive PDAs. the field worker only needs to take a note of that. Grameen Bank uses paper sheets to gather loan collection data. there are some special aspects to consider. If the expected installments are made. shock and humidity.

For example. Although the application is platform independent.3 PDA Technology The PDA application prototype was developed using Java 2 Micro Edition (J2ME) and the Eclipse integrated development environment (IDE). The MFIs who have tried PDA solutions agree on some guidelines when considering adopting a PDA solution [CGAP. 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. Although it only aims to improve one business process. but they are almost Page 68 of 141 . ranging from quite simple devices with only a few megabytes of memory and processors running at 33 MHz to those with almost the same amount memory and processor speed as a PC. Pocket PC can not be installed on a Palm device. the adjustments needed to make it fit in with the current infrastructure and way of working will probably not be too extensive. 4.4 The PDA device There are lots of different PDAs on the market today. there are some built on Linux. Inc. There are also other. changes in the MIS will probably affect the PDA solution as well Have relatively stable. Only one business process – the loan collection process – has been implemented. or Pocket PC from Microsoft. For example. Neither of Palm OS® or Pocket PC is open source. less common operating systems on the market. it is intended to be run on the Palm OS® platform. 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. there are in most cases only one operating system that works for each device model. Most devices run on either the Palm OS® operating system from PalmSource. The aspects of selecting a PDA operating system are somewhat different compared to selecting a PC operating system. the PDA application prototype developed in this project takes a somewhat different approach. 2005]: • • • • • • • • Leverage the use of PDA as much as possible – the more of the operations that can be handled with the PDA.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report PDA software product would therefore give MFIs better opportunities to adopt a PDA solution for their operations. For PDAs. 4. 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.

a manufacturer of GPS equipment.2. Garmin. The cost of the operating system can be considered to be part of the price of the device. Page 69 of 141 . the difference in performance between the two platforms has become smaller. makes Palm OS® powered devices with built-in GPS receivers. 2005]. the Palm devices are by tradition considered to be more of digital calendars or phonebooks.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report always preinstalled or bundled with the devices.0 compliant “MIDP for Palm OS®” virtual machine would probably be sufficient. There are also other sorts of devices powered by Palm OS® [PalmOS. but except from that the only additional costs are for any possible upgrades. 2005]: • • • • • • • • • 64 MB built in memory Palm OS® 5.4. Since the costs are a very important factor in this case.1 Palm Tungsten C and other Palm OS devices The PDA model used for testing the PDA application was the palmOne Tungsten C. while the Pocket PC devices are considered to be compact computers. Sony offers the Clié line of PDAs. the device is about the same size as most other PDAs. 4. but there is still some sort of a cultural difference. 8MB of memory and a 160×160 pixels noncolor display sells for $99 to be compared to the $399 Tungsten C. who also have QWERTY keyboards. For example. which is one of the most recent and powerful devices running Palm OS. Symbol offers a line ruggedized Palm OS® powered devices. but more exclusive. Usually. the palmOne Zire 21 with a 136 MHz processor.11b Wi-Fi wireless networking Infrared and USB connectivity Despite the built in keyboard. or even a full-scale implementation. being able to use cheap devices would be a great benefit. Palm devices are less powerful than Pocket PC devices. although quite expensive and with rather poor specifications. but its operating system and applications require less power as well.1 operating system 400 MHz Intel processor with XScale® technology TFT color display with touchscreen and a resolution of 320×320 pixels 1500 mAh rechargeable lithium ion/polymer battery Built in QWERTY keyboard and gamepad navigator button Expansion slot for Secure Digital (SD) or Multimedia Card (MMC) 802. with devices like the Tungsten C. 8 MB of memory and runs Palm OS® 4. Palm and Pocket PC devices do not target the exact same markets. a simpler Palm device running the CLDC 1.0 and MIDP 1. Some of is most significant properties include [palmOne. The watchmaker Fossil makes a wristwatch that has a 66 MHz processor. For running the prototype application. palmOne also provides the Treo series of smartphones. 4. Although. This is one of the most powerful models and its specifications are well on par with devices running Pocket PC. starting at prices about $250. much like the devices from palmOne. Today.2 Devices running Microsoft Pocket PC Devices running Microsoft Pocket PC are typically more powerful and expensive than their palm counterparts.4.1.

Developing J2ME applications for Pocket PC does not seem to be as common as for the Palm OS platform. There are also smartphones running Pocket PC [CNET. its constraints and how it relates to other Java technologies. but also. 4.5. especially if heavier applications are to be run. The Amida Simputers come in different models with both greyscale and color displays at prices from $240 to $480. both Indian companies [Amida.1 Background Java was at first intended to become a programming language mainly for networked home appliances. considering all three technologies – Palm OS®.4. Applications for the Simputer can be developed in C/C++. the Simputers are intended to substitute full-scale personal computers rather than to just be used for personal information management. is based in India and is registered as a charitable trust. there are still almost no such devices with network support. The Simputer could be an interesting alternative to Palm or Pocket PC devices. Since it is based on GNU/Linux the operating system software is licensed under the General Public License (GPL). its most important architectural properties. applications are mostly developed with commercial tools like Microsoft eMbedded Visual C++® or eMbedded Visual Basic®. The Simputer Trust has also released the hardware specifications under a general public license. 2005]. Pocket PC or the GNU/Linux based Simputer –. With 206 MHz processors and 64 MB of memory they have specifications similar to the more recent Pocket PC models. However. The Simputer Trust. The organization behind the Simputer.3 The Simputer The Simputer is a PDA-sized device running a version of GNU/Linux [Simputer. Even though home appliances have become increasingly computerized in recent years. The Simputer Trust does not manufacture any devices themselves. 4. there seems to be no need for the more computing power provided by the other 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. The main reason is the price since many devices will be needed. Realising the breakthrough for networked home appliances was not in the near future. multilingual and inexpensive people’s computer” which is a good description of its purpose – to overcome the digital divide by providing an inexpensive and easy-to-use computer for poor people in third world countries. For Pocket PC. 2005]. one of the less expensive Palm OS® devices seems to be the best choice for running a loan collection application. Java. they only develop it and provide the specifications.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report There are lots of different models of Pocket PC devices. Perl or lisp for example.5 Java 2 Micro Edition (J2ME) This section is intended to give a brief description of what J2ME is. the Simputer General Public Licence (SGPL). Although these prices are still considered a bit too high for third world countries. Sun instead Page 70 of 141 . The name Simputer stands for “simple. 4. 2005]. 520 MHz processor and full VGA display resolution. A Simputer model that currently is on the market is the Amid Simputer designed and developed by PicoPeta and manufactured by Bharat Electronics (BEL).

The configuration that applies to most wireless devices is the Connected Limited Device Configuration.128 KB of non-volatile memory for the Java Virtual Machine and the CLDC API libraries . CLDC states some basic requirements on the devices hardware properties [SAMS.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report targeted Java for the Web which turned out to be a huge success.5. I/O and database features Java 2 Standard Edition. A configuration defines a minimum set of APIs needed for developing programs for a range of devices. although Page 71 of 141 .2 The position of J2ME in the Java 2 family Based on different needs for different sorts of application. while other parts are defined with respect to a certain device. Sun somewhat brings back Java to its roots by making a programming language for small. some of the J2ME specification is fixed and applies to all devices. which specifies information about the needed capabilities [SAMS. Sun provides three editions of its Java 2 programming language: • • • Java 2 Enterprise Edition. J2EE: the most advanced and feature-rich version suitable for enterprise application with high requirements on networking. Today. With J2ME. like J2EE and J2SE. 4.J2SE: a subset of J2EE targeted at simpler applications as the lack of some advanced features instead provides better performance Java 2 Micro Edition: a subset of J2SE with functionality applicable to mobile devices.3 Configurations The set of available APIs are defined by configurations and profiles. J2ME.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.5. Java is also widely used for enterprise applications. Therefore. is platform independent and is supposed to run on different systems. 2001]: • At least 160 KB of memory available for Java . besides standalone applications and Web-based applets. CLDC. networked devices with limited capabilities. J2ME-capable devices range from very simple cellphones complying to the minimum requirements to PDAs with almost the power of a PC. 4. 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.

0 provides some improvements over MIDP 1.4 Profiles As the configuration describes the basic properties and requirements. may even be slow and intermittent. networking. 4.5. 2005].1 or MIDP 2.0 such as enhanced user interface capabilities.1 of the CLDC [Sun.6 Alternatives to J2ME There are several alternatives to J2ME for developing applications for Palm devices. It is included for free with many of the recent Palm devices and is also sold separately for $5. MIDP 2. Since the PDA application does not contain any code specific to CLDC 1. It is worth noting that “device specific” in this case refers to a type of device rather than a specific brand or model.7 Creating native applications in C/C++ Palm provide SDKs both with the 68K APIs for developing applications for the older and current Palm devices with Palm OS versions up to 5.0 profile. SUN has released two versions of their Mobile Information Device Profile: MIDP 1. input.0 configuration and MIDP 1. 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. Both commercial and open source alternatives exist.5 Java Virtual Machines for Palm devices The Java Virtual Machine used for testing the PDA application on the Palm platform was the IBM WebSphere® Micro Environment which supports the CLDC 1. 4. display. 2005].0 profile [Sun. providing a more device-specific set of APIs. but there are other languages as well. For older Palm devices.0.5. MIDP. 4. color or greayscales are not requierd some sort of network connection.99 [IBMWS. The new versions of the operating system will be backward compatible with applications created with the Page 72 of 141 . The following requirements apply to MIPD compliant devices [SAMS. 2005].0 where the later is backward compatible with the earlier. 4. for example a dial-up connection.1 configuration and the MIDP 2. The most common language for writing Palm applications is C/C++. it would run just fine on a device with “MIDP for Palm OS®” as well. improved security and connectivity to name a few [ONJava.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report the probably most important one – the lack of support for floating point math – is no longer a problem with version 1.5. 2005].0 and MIDP 2. Sun Microsystems provides for free “MIDP for Palm OS®” that relies on the older CLDC 1. the profile is a further specification “on top” of the configuration. or both a screen with at least 96 by 54 pixels with an ascect ration of 1:1. specifies requirements for device properties such as memory. Suns Mobile Information Device Profile.X as well as the Protein APIs for the new and upcoming devices running the next generation of Palm OS.5.

AppForge Crossfire might be a nice choice.1 J2ME Wireless Toolkit The J2ME Wireless Toolkit is a set of tools specifically for J2ME.3 MB depending on the target device. 2005]. so if the features mentioned above are not necessary. Pocket PC and Smartphone versions of Microsoft Windows Mobile. although the license costs can be high if many licences are needed.net [Appforge. For developers familiar with Microsoft Visual Studio. a commercial IDE [Metrowerks. The emulator can be configured by changing parameters and using different graphical skins to simulate different types of devices.8 AppForge Crossfire There are also tools for other languages. most of them fictitious but quite typical. Page 73 of 141 . 4. Because the C/C++ implementations are made especially for the Palm platform. Palm databases and the Palm GUI. 4. Besides the loss of platform independence. Palm also provides the Palm OS Developer Suite which integrates Palm OS SDKs into the open source Eclipse IDE [PalmDS. 2005]. The Crossfire Client is available even to the simpler Palm devices such as the Zire models and the older Palm III. but lacks the complete libraries of C and C++. Two other common C/C++ compiler suites targeting the Palm platform are PRC-Tools [PRC. The client files have quite large footprints – from 500 KB up to 1.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 68K. The J2ME WTK comes with a set of different emulator profiles for a variety of cell phones or PDAs. One of the most important parts of the J2ME WTK is the emulator for test-running J2ME applications.6 The Eclipse and J2ME Wireless Toolkit development tools For developing the PDA application prototype. Palm OS. the J2ME Wireless Toolkit (J2ME WTK) was used in combination with the Eclipse integrated development environment (IDE) and the EclipseME plugin for J2ME development. 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. which is free and based on the GNU Compiler Collection (GCC). AppForge Crossfire applications require a Crossfire Client file to be installed on the target device to run applications. 4. Also somewhat like J2ME.5. The AppForge Crossfire is a commercial product and a license costs around $1000. 2005]. They also provide better integration with Palmspecific technologies such as the HotSync synchronization technique. applications developed using AppForge Crossfire run on several different device platforms including Symbian-based smartphones. C# and Visual Basic.6. they provide better performance since they do not need to run on top of a virtual machine. Visual Basic 6 or Visual Basic . The client is available at $25 or as a free 15-day trial. and Metrowerks Code Warrior. Like with J2ME case. there are some advantages of writing native applications in C/C++ rather than J2ME. the 68K APIs will probably do. like the AppForge Crossfire technology that allows developers to write applications using Microsoft Visual Studio in for example C#.

MiCOpA: Micro-Credit Operation Automation SPIDER Project Report There is also the KToolbar application which provides a convenient graphical user interface for building and launching J2ME applications in the emulator. which provides J2ME support for the Eclipse IDE [EclipseME. instead of using the command line interface. this method was split up into smaller methods and put into the classes they concern. like for example Microsoft Visual Studio or Sun Java Studio. although they have been split up and placed in the classes they affect. A bit surprising. The Eclipse IDE reminds a lot of other IDEs. Eclipse also has features like code completion and debugging with variable tracking. the EclipseME plugin was used. commercial-quality. For example. it should require a rather powerful computer to run properly. Besides from the emulator and the KToolbar. When developing the PDA prototype application. but there are also tools for C/C++ and COBOL for example.7 Architecture Considering the aspects described in section 2. The Eclipse IDE is mainly targeted at Java development. Naming – The ambition has been to use names that are logical and consistent rather than as short as possible. when developing the PDA application prototype. memory and mobile databases used by the emulator.4. industry platform for the development of highly integrated tools…” [Eclipse. it proved to run fairly smooth on a 500 MHz Pentium III PC with 256 MB of memory running Microsoft Windows XP. Page 74 of 141 • . The Eclipse IDE is open source and is licensed under the common public licence. Developing applications with the Eclipse IDE and the EclipseME plugin proved to be much more convenient than using the tools that come with the J2ME Wireless Toolkit. with a project view and views for editing and output. JUnit for unit testing and the Ant build tool. the PDA application architecture can be described as: • Structure – Some methods are rather extensive and complex. but was abandoned because the classes turned out to be too different. Examples of tools that can be integrated with the Eclipse IDE are CVS for version control. Inheritance was considered for the classes representing the business data. full-featured. recently. 2005].6. 2005]. Applications under development can also be launched directly from the Eclipse IDE – buy pressing a button an application is built and run in the emulator.2 The Eclipse development environment “Eclipse is an open source software development project dedicated to providing a robust. 2005]. It “…provides building blocks and a foundation for constructing and running integrated software-development tools” [Eclipse. there are also a number of utilities for managing and monitoring different aspects of the J2ME environment like network. initially there was only one serialization method handling the serialization for all classes representing business data. 4. As Eclipse is quite extensible and written in Java. 4.

shows sub totals for all the data stroed in the device and allows synchronization and load operations createCentersScreen() – shows a list of centers createCenterDetailsScreen() – shows the details of a selected center createGroupsScreen() – shows a list of groups within a selected center createGroupDetailsScreen() – shows the details of a selected group createLoaneesScreen() – shows a list of loanees within a selected center createLoaneeDetails() – shows the details for a selected loanee and allows entering loanee data All these methods return a Screen object that can be passed as an argument to the Display. a Display object that represents the device’s screen and an instance of the Branch class that is the top of the business data hierarchy.2 The MiCOpA class The class MiCOpA is the main class of the MIDlet and contains methods for controlling the lifecycle of the application – startApp(). almost no other functionality resides there. The constructor of the MiCOpA class creates the commands that appear in the GUI.7. Selection of particular data is then performed through the objects that are regenerated from it. there are classes for handling the business data model. Seven methods implement the GUI: • • • • • • • createBranchScreen() – the screen shown at startup. In short.7. a set of classes implementing a linked list. 4. pauseApp() and destroyApp(). 4. The data is stored in the record management system (RMS) that comes with J2ME. the code has been commented in most cases. Methods concerning business logic and serialization are put in the classes that represent the business data they affect.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • • • Documentation – Besides what is found in this document. 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. Separation of concerns – The GUI is separated from the business logic as far as was considered possible. a class for running synchronization in a separate thread and a main class that handles the application lifecycle and the user interface. Functionality for synchronization and persistent storage is put in one of the classes representing business data.setCurrent() method in order to change screen. Since this RMS is quite simple and there are not too much data to be dealt with. It also contains methods for generating the graphical user interface (GUI). all the data are always stored or retrieved at the same time. Database design – There is no real database system involved with the PDA application.1 The classes of the MiCOpA MIDlet The PDA application MIDlet consists of nine classes with different purposes. The methods handling the GUI are put in the main class of the application. Screen changes are in most cases Page 75 of 141 . but also provides the synchronization and storage functionality.

4 The ListNode class TheListNode class has two data members – a reference to the next list node and an object of the class Object. Since Object is the general super class of all classes. Although inheritance is not implemented since there are differences in how their methods are implemented.7. for example the groups within a center.7 Classes representing the business data Four classes represent the business data model – the Branch. The class implements the Runnable interface and is called from the MiCOpA class. since http communication might cause the application to halt for some time if something goes wrong. these classes have some data members and methods in common.8. 4. 4. where the data of the node is to be stored. The ListNode class has no methods. 4. This is further described in section 4. The class contains a ListNode and some methods. Group and Loanee class.7.8. Other than creating different screens. objects of any class can be stored.6 The Sync class The purpose of the Sync class is to run synchronization in a thread separate from the rest of the application. functionality like manipulating the business data or synchronization has been placed outside the MiCOpA class. 2005]. The business data model is further described in section 4. The only method of the class is the run() method that calls the synchronization methods of the branch class. The LinkedList class and its related classes. were found on the Internet but have been slightly modified [Hunter.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report initiated by a commandAction() method that belongs to one of the screens. Center. why type casting might be necessary.5 The LinkedListItr class The LinkedListItr class implements a list iterator with a header node. ListNode and LinkedListItr.7. 4. The only exception is the getServerAddress() method that retrieves a URL stated in the application properties.3 The LinkedList class The LinkedList class is an implementation of a linked list that in this case is used for containing the lower levels of the hierarchy of business data objects. it is considered to be an instance of the Object class.7. of who the two most important are the retrieve() method that returns the data stored in the node and the advance() method that iterates to the next node of the list. 4. Common member variables: • disburse – integer representing the total amount borrowed or lended • repaid – integer representing the amount that has been paid back • balance – integer representing the current debt • performedLoanInstallment – integer representing the loan installment actually collected • expectedLoanInstallmen – integer representing the loan installment expected to be collected • performedInterestInstallment – integer representing the interest amount actually collected Page 76 of 141 . The only thing to remember is that when the object of a list node is retrieved.7.

9. It has all the common member variables and methods. except the regenerate() method since it represents the bottom level of the hierarchy. Besides the common methods and member variables.8 The Branch class The branch class represents the top of the business data hierarchy.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report • expectedInterestInstallment – integer representing the interest amount expected to be collected Common methods: • regenerate() – regenerates the levels below in the hierarchy. In addition to the common member variables.8.7. In addition to the common member variables. 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. 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. 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.11 The Loanee class The Loanee class represents the loanee level of the hierarchy.7. the Branch class has a linked list containing all the centers.9.7. 4. The setLoaneeAbsent() method is used to specify if a loanee was absent or not by passing a Boolean argument to it. i. i. the loanee number and the purpose of the loan. Page 77 of 141 . Except from data representation. These processes and methods are described in section 4.10 The Group class The Group class represents the group level as described in section 4.9. It also contains a reference to an instance of the Branch class and a linked list containing the Group objects below in the hierarchy. it also handles the synchronization and storage functions.7. It has three string variables for the loanee name.e. a RecordStore object for referencing the record store and a string for storing the server address. 4. 4. it has a string variable for the group name.e. 4. it contains two string variables containing the center code and the collection date.9 The Center class The Center class represents the center level as described in section 4. 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. There are also some additional methods. It also has an integer variable that states whether a loanee was absent at the loan collection meeting. 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. a reference to the center it belongs to and a linked list containing the Loanee objects below in the hierarchy.

the term branch in this case represents this set of centers. Loanee No. Branch 1 * Center 1 * Group 1 * Loanee Figure 4.1: The one-to-many relationship between the hierarchial levels. The table of figure 4. each containing two groups with two loanees. The sheet contains a branch with two centers. or a subset of it. 4.1. the term center in this case represents this set of groups • A branch is an office that organizes a set of centers.8 Object-oriented structure The business data and the relationships between them are mapped to a hierarchial structure of objects of different classes representing the levels of the hierarchy. Page 78 of 141 . which in turn belongs to a center that is organized by a particular branch.8. In short. These one-to-many relationships are shown in figure 4. Loanee Name Purpose Disburse Repaid Balance Expected Loan Installment Performed Loan Installment Expected Interest installment Performed Interest Installment Loanee Absent The Branch Center 1 Collection Date: 01/01/2005 Group 11 Full Installment: 111 Adam Aluminum 40000 112 Bertil Boron 20000 Group 11 sub total 60000 Group 12 Full Installment: 121 Cesar Carbon 30000 122 David Dubnium 10000 Group 12 sub total 40000 Center 1 sub total 100000 Center 2 Collection date: 01/02/2005 Group 21 Full Installment: 211 Erik Europium 24000 212 Fredrik Fluorine 96000 Group 21 sub total 120000 Group 22 Full Installment: 221 Gustav Gallium 60000 222 Harald Hydrogen 20000 Group 22 sub total 80000 Center 2 sub total 200000 The Branch sub total 300000 24000 12000 36000 18000 6000 24000 60000 14400 33600 72000 36000 12000 48000 120000 180000 16000 8000 24000 12000 4000 16000 40000 9600 62400 48000 24000 8000 32000 80000 120000 8000 4000 12000 6000 2000 8000 20000 1200 4800 6000 3000 1000 4000 10000 30000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 800 400 1200 600 200 800 2000 120 480 600 300 100 400 1000 3000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Figure 4.2 shows an example of a fictitious loan collection sheet based on the sheets that are used by Grameen Bank.2: Example of a fictitious loan collection sheet.1 The relationships between the business data The business data the PDA prototype application needs to be able to represent are derived from the original paper loan collection sheet used by Grameen Bank. The loan collection sheet implies that the business data can be organized in four levels. loanees are members of a group.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4. from bottom to top: • A loanee is a person who has borrowed money from Grameen bank • A group consist of about five loanees who to some extent share the responsibility for their loans • A center is where a set of groups meet for loan collection sessions.

“Loanee Absent” is checked if a loanee does not show up for a collection gathering. the relationships between the data of the example loan collection sheet in figure 4. 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.3: The relationships between the data shown as a tree structure. Also. As implied by the sheet. “Full Installment” is checked if a group has fulfilled their instalments and no further specification is necessary. the PDA application only keeps track of one week of collections since the data are assumed to be synchronized rather often.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report The data represented in the PDA application are almost the same as in the original loan collection sheet. the date when the loan collection will take place. although some modifications are made. the groups need a field Considering the relationships shown in figure 4. There are also some fields unique to the different levels.1.2 can be shown as the tree structure in figure 4. 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. these values represent the sub totals of the lower levels. Page 79 of 141 . For example. for example the centers need a field for the collection date. two boolean fields are added. center and group levels.

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

4: UML diagram of the PDA application prototype. functionality both to serialize objects and to regenerate objects from serialized data is needed. Page 81 of 141 . the techniques for synchronization and persistent storage can use the almost the same form of serialized data. only minor adjustments are needed. the data has to be represented in some sequential form. i.9 Synchronization and persistent storage Before the data that are stored in the objects can be synchronized to a PC or stored in persistent storage it has to be serialized. 4.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4.e.3 UML class diagram of the PDA application prototype Figure 4.8. Fortunately. Therefore..

each object is represented by a starting tag followed by the object data. Group and Loanee starting tags are “<C>”.…. To serialize the object structure.Group 11 data n.….…. n. 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. n.Loanee 122 data 1.3. <G>. <L>.Group 21 data 1.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4.Loanee 211 data 1.….….Loanee 221 data <L>. All tags and data are separated by a ‘. <C>.…. line breaks and indentation have been added.5: Example of a string of serialized data. <L>.Loanee 112 data 1.5 more readable. J2ME does not provide any serialization techniques such as the serializable interface that comes with J2SE and J2EE. In serialized form.The Branch data n. Center.Group 12 data 1.Loanee 212 data 1. a call is made to the Branch objects serialize method.Loanee 111 data <L>.Center 1 data 1.Group 11 data n. the structure gets traversed in a depth-first manner in the order indicated by the numbers next to the objects in figure 4.Loanee 212 data <G>.Center 2 data n. The method creates a StringBuffer to which it first appends the Branch objects own data separated by “. In this way.Group 21 data n.1 Serialization Data needs to be serialized to be synchronized with a PC or saved to persistent storage. <L>. To make the string in figure 4. <L>.Loanee 221 data 1.Loanee 121 data <L>. Then. Unfortunately.”.Loanee 222 data 1.Center 2 data 1. n.…. The string can then easily be sent over a network connection or stored in persistent storage. “<G>” and “<L>” respectively. Page 82 of 141 .…. 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.…. Of course.9.…. <G>. The starting tag indicates the type of object that follows next in the string.….Group 11 data n.….’-character. n.…. n. n.Loanee 211 data <L>.Loanee 112 data <G>. n.….Loanee 222 data n. 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.….Group 12 data 1.Loanee 121 data 1.Loanee 122 data <C>.Center 1 data n.4.Loanee 111 data 1. The Branch data 1. A call to the serialize() method of the Branch object in the example would generate a string with the structure described in figure 4. The serialize() methods works in about the same way for all the classes representing business data. The Branch class has only one instance and its data is placed first in the the string without a preceding starting tag.Group 11 data 1. Figure 4.

First. the string has to be parsed into substrings. The string of object data is first URL encoded as it probably will contain whitespace for example. a Group object is created similar to when a Center object is created. When the regenerate() method of the first Center object is finished. When the first Center object is created and its data fields are filled. a call is made to the regenerate() method of a Branch object. a call to the newly created Center objects regenerate() method is made. for example before collecting installments. it returns an iterator updated to the current position in the list of tokens. If it receives a parameter “data” containing a string of data. for example after collecting instalments. the method continues to iterate the list of tokens looking for a “<C>” starting tag followed by the Center object data. When creating Center objects.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4. The servlet acts to send data if no parameter comes with the http request. by calling the tokenize() method. Then. regenerates the object structure as described in the section above and saves it to persistent storage. Page 83 of 141 . The method first fills the data fields of the object with the data from the first few tokens of the list. The string of serialized data is passed as an argument and the method returns a linked list containing all the tokens that were separated by ‘. The uploadData() method works similar to the downloadData() method but sends a parameter “data” containing a string of serialized object data.9. the linked list of the Branch object containing Center objects is created. The text file can then be manipulated in order to exchange data with an application on a PC.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. where no data has been set.e.9. Two methods in the PDA application handle the synchronization – the downloadData() and the uploadData() method of the Branch class. The regenerate method of the Center class continues to iterate the list of tokens from the current position and keeps looking for a “<G>” starting tags. it acts to save the string as described above. 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 simply reads the file and sends the contents to the PDA application. As the execution of the regenerate() method of the Branch object then proceeds.’. continuing iterating the list of tokens. When uploading data to the server. new Center objects are created as long as new “<C>” starting tags are discovered. The downloadData() method simply makes an http request without any parameters. When a “<G>” starting tag is discovered. i. Two arguments are passed: the list of tokens and an iterator pointing out the current position in the list of tokens. After the list of tokens is created. 4. Loanee objects are also created in a similar way. or tokens.2 Regenerating objects from serialized data Regenerating an object structure from a string of serialized data is performed in two steps by calling two methods of an empty Branch object.

if a full scale application is to be developed. given that there are any stored data. The saveData() method makes sure that the record store is empty. and can be accessed as Sync. However. depending on the value of the integer argument. Fortunately. one for the record IDs that serves as primary keys and one for the data. The data is in this case stored as a singe record. two arguments are sent to its constructor: a Branch object for which the synchronization is to be performed. The record ID for a record is an integer value and the data is stored as an array of bytes. and an integer to indicate if a download or upload operation is to be performed.DOWNLOAD or Sync. Retrieving data from persistent storage is transparent to the user and is performed automatically when the application is started. 4. to save a string of serialized object data. The RMS package defines the RecordStore class. Two integer values are defined in the Sync class. An RMS record store can be considered as a simple database with only one table of two columns. converts it to a string which it passes to the regenerate method to create the object structure. no packages or libraries other than what comes with Suns J2ME Wireless Toolkit have been used.4 Persistent storage The only way to store data persistently with J2ME is by utilizing the MIDP Record Management System (RMS) that comes with the package javax. compare or filter records. it might be a good idea to reconsider using these techniques since many of them provide very useful features that are also proven to work well. Two methods of the Branch class handle the storing and retrieving of data from persistent storage – the loadData() and saveData() methods. The string is then converted to an array of bytes which is stored in the record store by calling the RecordStore.9. The loadData() method simply retrieves the one and only record from the record store. Synchronization is initiated from the GUI when the user chooses to perform a download or an upload operation. Page 84 of 141 . and some useful interfaces used for example to enumerate. Hence. which represents a record store.5 Other solutions to synchronization and persistent storage When developing the PDA prototype application. 4. Data are saved when leaving an input screen by using the “Save” command. the Java String class provides functionality for this. The CommandListener creates a new thread running new instance of the class Sync that implements the Runnable interface. but there are some that were considered. DOWNLOAD and UPLOAD. Most of them are open source.UPLOAD when creating the Sync object. the Sync objects run method calls the downloadData() or uploadData() method of the Branch object.9. it first has to be converted to an array of bytes. calls the serialize method to get a string of serialized data.rms. When the Sync object is created.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report Due to the nature of network connections.addRecord() method.microedition. which is preferable in this project. When the thread starts. these methods are run in a separate thread to avoid the device from locking when a connection fails.

especially suitable for devices that are only sometimes connected to a network [Sync4j.9 J2ME and the Palm HotSync technology Native Palm applications usually synchronize their databases through the HotSync technology which lets the user synchronize by just putting the device in a cradle connected to a PC and press a button.7 Nextel’s RMS toolkit Nextel’s RMS Toolkit is open source and provides classes for record management [Nextel. 4. but at the cost of heavier memory use. SyncML utilizes XML and is supported by big actors such as Ericsson. It also provides the possibility to cache records in memory in order to increase performance. Both Sync4j and SyncML are open source. the only header value that can directly manipulated is the name of the database. but operations are instead performed via record objects built on top of the more primitive byte array operations. an application on the PC side used by the HotSync technology. which is not supported by J2ME why db4o can not be used in this case. The differences lies in how the header values are set.9. it turned out that db4o stores its data in a file. but commercial applications based on Sync4j require a commercial license. 2005]. Unfortunately.6 The db4o object oriented database system An interesting alternative to the solution described above could have been to use the open source object oriented database db4o from db4objects [5]. However. and neither does Palm provide any proprietary solutions for this.9.9. Page 85 of 141 . The toolkit relies on the J2ME MIDP RMS. since the J2ME MIDP RMS maps almost exactly to Palms implementation of persistent storage. instead of for example use the RecordEnumeration for browsing a record store. which carefully manipulates the database. The big advantage of using an object oriented database is that the object model would not need to be converted for persistent storage because the class model is the same as the database schema.jar file of 300 KB. When creating a J2ME MIPD RMS database. 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. the database is created by a conduit that is able to manipulate all the header fields to suitable values. 4.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report 4. it is possible to trick HotSync into synchronizing a J2ME database as well [Biech.8 Sync4j Sync4j from Funambol is a platform for mobile applications that relies on the SyncML standard for exchanging data. In order to fit both the J2ME MIPD RMS and Palms system for record databases. Nextel’s RMS Toolkit seems very interesting for developing a full scale application. 2005]. 4. 2005]. The toolkit also has functionality to insert or retrieve arrays of records. The db4o is a lightweight object oriented database system native to java and comes as a single . this is not supported by J2ME as a backside of its platform independence. Nokia Motorola and Symbian. Although the J2ME MIDP RMS was sufficient as-is for the prototype. especially since it also provides mechanisms for synchronization via http. This is done by writing a conduit. Unfortunately. 2005].9.

However. network availability and the power consumption of the device need to be taken into account. This could be hard to find out. Therefore. have been appreciated by the end users at Grameen Bank as it resembles the paper loan collection sheets that currently are being used. English as a foreign language. technology and. Encryption might also be a good idea if data is to be sent over a network instead of synchronized directly with a PC. in the area of work. The technical knowledge may differ a lot among the end users since knowing about how to use computer has not been necessary to fulfil their work so far. In order to not Page 86 of 141 . maybe it could be a good idea to insert some kind of rollback functionality to ensure that such operations are atomic. The first idea of the GUI layout of the PDA prototype application was to adopt some sort of table where lots of information could be shown at the same time. the lack of screen space is probably the most obvious limitation. due to both the limitations of the PDA screens and the J2ME GUI APIs. the end users are expected to have quite good skills in both English and their area of work. As compared to a PC application. not all developing countries may have such a widespread knowledge of English. in this case.11 Human computer interaction (HCI) aspects When developing the PDA prototype application. This design would probably. the users skills needs to be considered. and the personnel of new MFIs may not be very skilled in the area of work. 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. this might not be the case for other MFIs. One way to solve that would be by calculating some sort of checksum that is sent back and compared with the original data. As the loan collection sheets currently being used at Grameen Bank are in English. this type of design was abandoned in favour of a more list-like design. The password could maybe serve as a key for encrypting/decrypting the application data.10 PDA Security No security functionality has been implemented in the PDA application prototype. However. especially if synchronizing from a distant location over a network. some special aspects had to be considered. but there are some aspects that should be considered if a full scale application is developed. but also the limitations of the input devices. Integrity could also be an issue for example if the device looses power while data are being stored to persistent storage. There is also not yet any functionality to tell the user whether synchronization has succeeded or not. 4. Besides from the characteristics of the PDA devices. at least initially. The palm devices provide access control to some extent since the user can set the device to require a password each time it is stated or returned from standby.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report However. 4. Another option is to let the application require a password each time it is launched.

After revising the paper prototype. 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. However. technical terms and operations have been avoided as far as possible. Synchronization is expected to be performed on a daily basis. and then synchronizes the device again. mostly only numbers need to be entered.MiCOpA: Micro-Credit Operation Automation SPIDER Project Report complicate the use for those who are not accustomed to the technology. When developing the full PDA application prototype. the logic was first created and the GUI could then easily be built on top of it. In the case of the PDA prototype application. When designing the GUI of the PDA prototype application. and the devices batteries could probably be recharged at the same time as well. the user synchronizes the device with a PC. containing the GUI but no underlying logic at all. collects data in the field. there are devices with other input technologies such as speech recognition or miniature keyboards that could be used. That code was later discarded when creating the full PDA prototype application. The PDA prototype application is designed to use a network connection on a sometimes-basis. an experimental implementation of the application was developed. Page 87 of 141 . but they are often more expensive. and important lessons were learned from writing it. Learning how to use this technique often takes some time and effort for anyone who tries it. The need for network availability is also often discussed in the context of HCI. the starting point was to develop a paper prototype showing the layout and navigation structure. almost all of it was designed in detail from the beginning. which is often rather straight forward on most PDA devices. Since the GUI was not to be very extensive. but the GUI design was similar. The paper prototype and some sample screenshots can be found in appendix D of this document.

advantages and disadvantages. 2005].0 and an in-depth review of our proposed technology for the database layer: MySQL. The number of users depends on the load and the size of the database. but on a practical basis. 5. 3. Apart from the theoretical value that MS says about the possible concurrent connections. 2005]. Actually Access is only suitable for some pretty small desktop database work. 2005]. We study Page 88 of 141 . products and platforms that can be recommended for Grameen or other Micro-credit institutions. 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. 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. modules.2 Analysis and Evaluation of Current Technology The current Grameen Banker is built on the MS Access database. domain knowledge of microcredit operations and the requirements for further improvements in managing the information system. In this chapter we provide a brief overview of the current technology used in Grameen Banker 3. Performance degradation with number of increased concurrent users.0 The purpose of the analysis of the Grameen banker 3.1 Definition of Technology By technology is meant which specific off the shelf.6 respectively. it is entirely unsuitable for any task where there will be more than a half a dozen concurrent connections on a regular basis [TAA. There are many limitations of the Access database. Even Microsoft itself does not suggest for use Access when security concerns are stronger and they recommends server database in that case [FAQ. reports and macros [FAQ.0 is to understand the business logic. 2005]. Besides the security hole still exists from Access 95 to Access 2000 and some one who knows about it can very easily get into the forms. commercial or Open-source. users have been reported to face serious performance problem when the number crosses more than half a dozen of concurrent users [Macromedia. database and when using the database in any web application. Even though the security in Access database has been made improved a lot from the Access 95 to Access 2000. but it is based on the user groups and assigning permissions directly to users make database administration complex. 5. The common problem of Access in a Web environment is that the database files get corrupted besides the poor performance of the application. The limitation of the Access database is described below: 1.3 Analysis of the Current GBanker 3. 4.MiCOpA SPIDER Project Report 5 Technology 5. Users of MS Access database has faced a lot of difficulties when increasing the number of users. 2.

3. they are: • Grameen Banker 3. Daily loan Collection: the entry of all loan payments collected daily in a branch. 3. The operations are performed at different level of the organization which is divided into different sections and braches dispersed in the remote rural areas. As the application has several modules and the MS Access database consists of many tables. The organizational graph [2] of the Bank is shown below.1. Page 89 of 141 . • Grameen Banker 3.MiCOpA SPIDER Project Report the Grameen Banks business logic.1 Main Functionalities Grameen Banker’s main function is as described in the Grameen Banker Manual by the Term “Branch Loan monitoring System” (BLMS). Daily Savings Collection: entry of all savings collection from the GB members. drawbacks and redundancies in the system. • MS Access database Grameen Banker stores it's data in. The Grameen Bank organistional structure. forms and fields.0 User Manual [2]. The small amounts of loans that are disbursed to the poor are monitored in the following ways: 1. here we will discuss only the summary of the analysis to find out the main functionalities. Daily Loan disbursement: the amount of loan disbursed daily from a branch 2. We have investigated three sources simultaneously in order to analyze the GBanker. requirements and future development issues so as to incorporate them in the proposed prototype.0. 5. the full analysis description is long and is not included here therefore. Figure A. The complete description is attached as Appendix A. Visual application: menu options. the levels and the associated roles.

MiCOpA SPIDER Project Report 5. It is based on weekly (one particular day of the week) for Grameen. This is registered in the SavingsRegister table and as a savings account is opened against a loan. the extra amount goes to Savings of that loan and is entered in the table UpdateSavingsRegister. Group members help each other and inspire to make proper utilization of the loan. One Branch Staff is responsible many centers. 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. but they are kept in the Loanee table which makes a lot of redundancy. These values are feed into the UpdateLoan table that keeps the status information of all loans.2 Database Analysis The database of the application consists of twenty two tables. it registers one account for every loan a member has taken. Each product has some attributes and ItemCode table keeps information on the product specification. A table with Group data could have saved this redundancy reducing the size of tables. if someone pays greater than the loan instalment. The information about the organization’s subdivisions as shown in the organization graph is kept in the following tables: • • • • ZoneCode AreaCode BranchCode Center The hierarchy of the divisions are as shown in the graph that is one zone has many area offices. From the DailyCollection. The amount of money Page 90 of 141 . Several data regarding Group is kept in the database. InvestorCode keeps the information of the investors for items. Many of the tables are used as intermediate tables to facilitate querying and lot of information is duplicated around different tables which make the database hard to understand and analyze. Center table contains information about the loan collection day. Each loanee has to be a member of a group too in order to get loan.3. Loanee registers for a loan. DailyLoanCollection table keeps the data of collected loans and interests from the members of a branch. Discussing with Grameen’s software developer and consulting the manual helped to understand the operations and business processes that are supported by the database. Loanee registers a loan by taking a specific loan product from the list of products available in the bank. He/ she collects loan by field visiting the centers. one area has many branches and each branch has about 50 to 60 centers. Each loanee gets a savings account against a Loan. and these information are kept in the LoanRegister database. Loanee is a person who registers him/herself with the bank to take loan. Each Center has a loan collection day. Every loan item is taken for a purpose. a business purpose and the table PurposeCode keeps that information. but may vary to monthly or to some specific days. Branch is the heart of main activities regarding loan collection and distribution. This data provide valuable information such which loans (taken for which purpose) were most successful and which were not etc. The concept of group formation is to create dutifulness and responsibility to repay the loan timely. BranchStaff table keeps the information of all the staffs in a branch.

The Khatwary is a special table that keeps the data on gender basis for each loan item in a branch. For example they use group information. It is kept with loanee information causing a lot of repetitions of information and loss of space.MiCOpA SPIDER Project Report disbursed from the branch is kept recorded in the DailyDisburse table. group formation date.4 Modifiability requirements The modifiability of the parameters for Microfinance software varies on a very wide range due to the varying nature of the MFI’s. 5. Even for a single MFI. Intermediate tables: Lots of intermediate tables are used. 3. 7. the parameters vary due to the variations of customer’s financial capabilities. 5.3 Problems/Limitations in the GBanker3. for example the CurMonth table contains the information that is otherwise available from the Daily loan Collection table. and others in the application. The following problems exist with the database: 1.3. Daily Disburse keeps the record of a particular day and DisburseHistroy keeps all the records. MonthlyProcessFile keeps information about a branch’s processing date. Unused fields: There are lots of fields in the tables that are not currently used by the Grameen Bank. 5.3. They are repeated to facilitate querying. Apart from these operational values some values are kept in database as a summary or report for showing some results of business interest. Missing of entity: Some important entities that Grameen uses is missing in the database. This data goes to PrevMonth table after the end of month. residing locations. 6. Missing of some valuable attributes: Some very important attributes which they use are not included in the database. But this data is required to generate values for Khatwary table. A separate table was worthy to build with relevant group data. 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. Presumably this data values are calculated manually or in some other way. Not-Normalized: Many tables are not normalized. purposes of the loan and the different types of loans. Lot of repetitions: Repetitions results from the fact that tables are not normalized.0 From the analysis of the tables and database we come to discover the problems of the database. CenterSummary table keeps the summary of day to day transaction for a Center. Summary of a branch is kept on the Summary table. This summary is kept against loan items. Different MFI’s have different kinds of requirements and different ways to deal their customer. for example the sex of loanee is not stored in the database. 2. Related information is not kept together in one table and in some cases attributes from two different tables are kept in a table as attribute of that. Redundant information: Information redundancy has occurred due to the lack of proper design of query or reports. The change and modifications of this kind of software is inherent with its nature and hence a good Microfinance Management application should be able to easily incorporate the dynamic Page 91 of 141 . 4.

6. That is apart from the known parameters that usually vary among the different centers. 4. So the loan collection is not based on the centers loan collection day. amount or term 8. From some other MFI’s operating in different countries [LOS. The concept of group is not used by all the MFIs. twice a week and so on with many other types. The application therefore must be easily modifiable to incorporate those changes. Some MFI’s provide loans to the loanees directly. 2. Specific for an individual loanee and a loan product based on some business rules. Loanee status tracking 4. happen sometimes not so often. 2005] 3. As a basis for the flexibility to change. No personal ID 7. Some do not have the concept of centers. Repayment Schedule: some have weekly. there are also unknown parameters that happen to pop up to satisfy some non frequent functionalities. Validation : loan limit. 9. Installment date is fixed by the loan product’s repayment schedule. Number of Members in a group varies for different MFI’s. The common changes and variations in different MFI’s and in the different sections of the same institute give the scope of the parameterization. Adding fields. 2. we get some more modifiability requirements such as: 1. 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. Grace period and some other considerations due to some natural disaster or some other unavoidable phenomenon. Considering the Grameen Bank’s and their clients’ requirements the modifiability should include the following parameters: 1. [LP. Some MFI’s have group loans and individual loans together. Different reports: different MFI’s want reports in different formats. branches or MFI’s. the application has to consider the possible areas of modifications. Interest Calculation process: different kinds of principal and interest loan 5. that is to the loanee without being a member of a group. Page 92 of 141 .MiCOpA SPIDER Project Report changes that pop up during the lifetime of the software. 2005]. 3. Even in some cases the loan repayment can be defined. some monthly.

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

which allows the processing carried out by a computer or clerical system to be accurately identified. 2003] 5. including details of the users who created and authorised the amendment(s)” In the context of Grameen Bank. and from server-side down to column level. 2005].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.3 Security MS Access is not at all a secured database. your choice of hardware is determined for you [Paul. table name and client hostname. At the current solution. no one can get access to the tables without a valid username and password. If you want to use Access. MySQL offers access control for user/host connectivity.MiCOpA SPIDER Project Report 5. MySQL can limit logins based on different criteria.5 Hardware choices MySQL runs on several platforms.4. as well as verifying the authenticity of such amendments. it is used to track computer activities. 5. 5.4. It is perfect to run on a network environment and capable of servicing multiple clients at the same time. 5.4. With views in 5. In computer security. For a large company like Grameen which has many clients. the software is based on access database and there is no audit trailing facilities as anyone can access to the database and change directly the access table values. or series of records. So it is important to keep track of the records. MySQL can support that better than Access. A good definition of audit trail for computing is given in [ISG. MySQL handles hundreds of users without major performance degradation. row-level security is also possible [DC. 5. In the following section.6 Audit Trails Audit trail is an accounting term which means the sequence of paper work that validates accounting entries. [Paul. username. The limitation of Access is removed when MySQL is used instead. Anyone can enter into the windows machine where the database is stored and launch Access to gain access to the tables.0. 2003].4. Many branch staffs are collecting money from the loanees’ in the filed tours and sometimes the collectors may be changed.4. Whereas in Access. MySQL server manages security. 2005] which is stated as: “A record. performance degradation occurs when number of users increase more than half a dozen. So it will be particularly useful to see how MySQL can improve the audit trailing and its security features. Access is a single-platform application. Audit trail is very important.1 Multiple User Access MySQL supports multiple user access simultaneously. the security features of MySQL found in the MySQL Page 94 of 141 . database at a branch can grow very large.2 Management of Large database MySQL can manage hundreds of Megabytes of data.4.

MiCOpA SPIDER Project Report Reference Manual is described.8 Logs of SQL Transactions Binary log contains all statements that change data or could have the potentially change the data.0. but the benefits of it outweigh this minor performance drawback. Mysqld (the daemon program) writes queries in the order that it receives which can be different from the order in which they were executed. It is deprecated and is not available from MySQL 5. 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 . The general query log file logs established client connections with server and the executed statements. MySQL uses grant tables for the server access and these tables are stored in the database named mysql. For example and an update query that does not match any row. Query Log is enabled when the MySQL daemon is started with – log[=filename] option. It provides the facility to update the database as fully as possible during a restore operation.4. This log has been replaced by the Binary Log. At the second stage. 1.0.7 Audit Logs Audit logs can be maintained by the General Query Log and the Update Log of MySQL. Binary log also contains the information about how long each statement took. 2. MySQL server checks each statement to see whether the user has sufficient privilege to perform the statement. the server checks all the statements that the user generates against his/her user privilege in the system. It has fine grained privilege system up to table and columns level. Update Log It logs statements that change data. 7. It can restore operations and set up replication. 6. If a user wants to modify some data in a database his/ her user privilege is checked to see whether s/he has an UPDATE privilege for that database.4. Running Server with binary log makes it 1% slower. It can do anything that Update log did in the older versions in a more efficient way and in transaction safe manner. It actually uses three tables to manage the whole access privilege system for users: The user.9 Database Access Control MySQL has an advanced database access control system. The Access control of MySQL involves two stages: At first stage it checks whether it should allow a user to connect to the server. We will be interested to find the following features in MySQL from the Grameen’s Security perspective. 4. Binary log contains the statements which updated the data or could have updated it. assuming that the user is already connected.4. 3. 5. 5. 5. db and host table. With this log it is possible to detect which client has error and for what the error occurred. 5.

The encrypted password in the user table is the real password. 5. MySQL’s compressed protocol can be used.4. In a word. an SSH tunnel should be used to encrypt the communication. Page 96 of 141 . the password () function. SHA (). she can even change the data on the in the transit.1. A client with the SUPER privilege can disable binary logging of its own statements by using a SET SQL_LOG_BIN=0 statement. 1. a user can delete all the binary logs file.0. 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). 3. Password function of MySQL creates a hash value of the actual password. The password can be protected in following ways to keep it safe from any kind of intruders. It makes the traffic much more difficult to decipher. So any one can read the data who can watch the connection. 2. 5. MySQL provides a special function to keep passwords safe from prying eyes. The encrypted password is stored in the MySQL database user table.4. Beginning from the 4. Otherwise log files would not be able to show the exact sequences or actions that were performed in the MySQL server by different clients.1 style passwords has less strong encryption algorithm than 4. To make the Connection more secure SSH should be used to get an encrypted TCP/IP connection. all the data is lost. 1.1. Pre. Passwords should not be stored in plain text anywhere in the database.1 or later ones. 4.13 Protection of Audit Logs from Manipulation As log files are the source of all history of statements and events. it is important to check that some clients do not change the log files.10 Password Protection MySQL provides password for the users. 2.0 MySQL has support for SSL encrypted connections.12 Encryption of data directory It is even possible to encrypt the data directory of MySQL. To secure the communication. No Server Administration Privileges or FILE privilege should not be given to any users except root users.4. MySQL does not use encrypted connection between the client and the server. To ensure this the following tasks should be taken in to consideration.4. 3. So access to the user table must be limited only to the root accounts. or some other hashing function. If the connection between the client and the server goes through an un-trusted network. 5. Because then with Reset mater operation. But it is important to know that if the private key that is used to encrypt the data directory is lost.4.11 Encryption between Client and Server By default.MiCOpA SPIDER Project Report 5. RELOAD privilege should not be given to any of the clients. This internal OPenSSL support can be also used for client server communication in a secured manner. Besides application level passwords or important data can be encrypted by MD5 (). Also performance decreases as all the data must be decrypted first before they can be accessed.

it is important that the result is not just a report. Page 97 of 141 . In the project we therefore arranged for the following activities which helped share the knowledge with Grameen Communications: • • • • • Workshops on Software architecture Workshops on Software process Workshops on Technology A website with a Wiki-system to enable easy online communication One of Grameen Communications developers came to the IT-university to learn first hand about the proposed architecture improvements and technologies. This was done through pair-programming on a system integration project related to the PDA-application. but also activities that help spread the results so they can be put into action.MiCOpA SPIDER Project Report 6 Knowledge transfer activities In order for the MiCOpA project to be of best use to developing countries.

The developing country does not significantly increase it’s knowledge of ICT production if it only buys a finished solution License costs These disadvantages might not seem important in the short-run. we believe that this is not the most important aspect. provides better documentation and training. While proprietary software provides faster and easier access to functionality. This makes customization and localization difficult. Letting students and staff work on Open-source MFI MIS-software solutions provides for an excellent learning opportunity. 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. from a development and Digital Divide perspective the question becomes more faceted. Wouldn’t 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. While we may generally have put forward the technical merits of different solutions. from a functional point of view. but in the long run it makes the MFI very dependent on their software vendor and does little to bridge the digital divide. MFI’s are no longer dependent on a foreign western software company. Many proprietary software packages also exist to support micro-credit operations. This makes MFI’s 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. Local universities offering computer science education however often has skilled software engineers. Localization is possible to achieve.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. Instead we propose a model where MFI’s enter into partnerships with local educational institutions and companies. They are free to adapt it as they wish.MiCOpA SPIDER Project Report 7 A MiCOpA Software Network -. Today it is more complete. proprietary software is probably better. Often university teachers are lacking good examples for students to work on. However.1 Partnering with universities MFI’s most often do not have their own resources to develop and configure MIS software. Namely: • • • • Control of the software lies with the vendor. Especially if an active Page 98 of 141 . and is more mature. In fact. 7. They can develop their expertise in their own country [Worldbank OSS Report]. Open-source software on the other hand has the following advantages: • • • • The software is entirely under control of the MFI’s who use it. it also has several disadvantages. not the user.

Sourceforge [Sourceforge] could be a good place to start the community. However. This portal allows developers too: • • • Create a portal for the software Track bugs and feature requests Track changes to source code through version control systems This can be done without programming and with very little setup. Page 99 of 141 . Other Open-source MIS-solutions such as Compiere and MIFOS should also be contacted [MIFOS][Compiere]. A possible solution here could be to rally support on Micro-finance conferences.2 Creating an online MFI MIS-software community To create an international community around an Open-source it is necessary to create some kind of internet-portal. Universities in developed countries such as Sweden could also participate and provide assistance if needed.MiCOpA SPIDER Project Report international community exists with which they can share knowledge. Working on Micro-finance software would allow the students to gain important skills in for example: • • • • • Information system development Database technology Accounting Programming Micro-credit finance operations 7. a more difficult part would be to recruit a significantly large number of universities and MFI’s to participate.

2005]. The package was developed on Open source platform and specially adapted for Western Africa Region [Aquadev. One of the main purposes of this project is to evaluate MIS to determine suitability for business expansion. there are just 5 registered developers. 2005]. 2005 states that they are dealing with the functional issues and Business requirements. the MOAP site is no longer active now. Notably. Another effort to provide free software to MFI’s in developing countries was from Aquadev. 2005]. and methodologies. Work on implementations of the software for both highly distributed operations and highly centralized requirements. The software was built from the on field pressure and it is one of the many complementary services offered by the AQUADEV. Even though it is not an open source product. Create a flexible and wholly extensible architecture that can accommodate new features and interfaces. The project is still in the inception phase.MiCOpA SPIDER Project Report 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. but it can be used without license in the poor countries. easy to maintain. Despite more than 2 years of activity. The new effort by Grammen Tech. no code has been written and only some documentation is available on the project page. The Grameen Technology Center. The project aims to achieve the following goals: • • • Build a system that is easy to run. many of them are small firms with limited products [LOS. Although everyone agrees that Microfinance Institutions would benefit from open source. is hosting a new effort in the name of Mifos (Microfinanace Open Source). which was promoting the MOAP. Page 100 of 141 . JN Small Business limited installed a new IT system to improve the loan administration and has expanded its operation from two to fourteen [JNUSAID. As of the latest news from the Twiki project site. not to provide any platform for the MFIs to get general support in developing software of their own. a non profit organization born in 1987. in a university context has developed a MIS package for the West African Region. and doesn't rely on heavyduty servers or costly development tools. The most notable open source project in this area is MOAP (Microfinance Open Architecture Project) [Steven. but till today the research devoted to the development of open source platform and applications have not reached critical mass yet [Steven. The purpose of the project is to provide a platform for the microfinance organizations to manage portfolios and client accounts in multiple languages. Mifos is an open source project for the developing MIS for the micro credit operations. currencies. 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. But the project is in a perilous condition. The project just to help the organization to buy MIS software. 2005]. who are essentially dormant (0th percentile in activity on sourceforge). 2005]. The New Economy Project is a USAID project to improve Jamaica’s business environment. the status report of 5th April 21.

expertise database. microcredit promoters. The project does not actually deal with the MIS for micro credit operations and it shows no sign of movement or progress. with proper levels of control over precision and rounding. Handle currency calculations correctly. This project seems to have stopped as it is not moving since the year 2001 when it was registered [Y-Community. to publish financial report. 2005]. consulting and charitable organizations. Provide a high level of built in parameterization so that customized code bases do not create forks in the source code. real-time application processing. They achieved greater accuracy in recording transactions. 2002 and it has produced no documents until now. SKS aimed to save loan-officer time at client center meetings. 2005]. 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. microbusiness. and automated cash access could be delivered. 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. Make the software available in dozens of languages. and more rapidly obtain data for management reporting and monitoring [Steve. supporting multiple languages. 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. business proposal. 2005]. Page 101 of 141 . 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 concerns all type of socially responsible organizations such as Human Rights activists. The project was registered on the month of June. 2005]. Support work flow flexibility Another open source Project is Microbusiness Development Network which aims to provide a portal for microfinance. and display formats. 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. market intelligence. Y-community is an open source project that aims to develop a web & mail interface for management of social enterprises in developing countries. and investment analysis [MDN.MiCOpA SPIDER Project Report • • • • • Develop a banking application for the unique procedures of a microfinance institution including using groups as co-guarantors or pooling repayments. community project proposal. reduce error rates associated with manual record-keeping. 2005]. credit scoring. alternative energies inventors and others. Apart from lowering the operational cost and increasing accuracy. 2005]. It envisioned creating a technology infrastructure through which flexible services such as emergency loans. this technology will be particularly valuable in lowering the high transportation cost of the MFI’s working in the remote areas and SKS strongly believes that by thinking creatively and leveraging technology both MFI and their clients will benefit [digitaldividend. SKS used the smart card and PDA combination in two client centers for one year and they did not face any technical problems. currencies. whitepapers.

so that it can benefit the entire community [Red Hat. hopefully some micro credit operation application will be available under open source license for the interested community. BSD.com/community/rhscholarship. The final date for submitting proposal was 31st July. MiniERP. LGPL. 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. Page 102 of 141 .MiCOpA SPIDER Project Report Another educational initiative designed to encourage the open source platform development for microfinance is from the Red Hat India. 2004 and the successful proposals were to be notified by 5th August 2004 according to the Redhat India web site (http://www. 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. So after the completion of the contestants’ projects and the evaluation of their projects.g. Red Hat Scholarships – is the Open Source Challenge to encourage budding open source software developers. Tech project. The projects submitted to Red Hat scholarships are expected to have effort contribution similar to that of a typical final year BE/B. Accounting and microcredit applications [Red Hat.in..redhat. 2005].php). etc. 2005].

MiCOpA SPIDER Project Report 9 Conclusion Micro-finance is a powerful tool for fighting poverty. Management Information Systems can help to automate MFI operations. ICT plays an important role here. 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. 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. Open-source technology can be used to construct a similar application as Grameen Banker. but based on sound design principles. just like they are heavily used in banks. 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. It was therefore necessary conduct an analysis of Grameen Communications software architecture (including technology choices) and software development process to help address their problems. This can be achieved through architectural techniques such as modules. It is therefore of vital interest that the administrative problems that MFI’s are facing can be addressed. the task to develop their own MIS to support the banks operations. The process of developing the software was also seen as very stressful. Producing advanced banking software that needs to evolve as the MFI’s business changes is a complex endeavor. • Page 103 of 141 . layers and design patterns as well as good programming practices. To further increase the efficiency of Micro-finance operations the use and development of a Personal Digital Assistant (PDA) should also be carried out. This development has however not been entirely unproblematic. Micro-finance institutions (MFI’s). 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. Grameen Communications. This problem has led to the failure of many MFI’s. Grameen Bank in Bangladesh has long since realized this and has therefore given its sister company. especially the pioneering Grameen Bank in Bangladesh. have had much success. Creating a long-term viable MFI is however not unproblematic.

This application has the potential of significantly reducing the cost of Micro-finance operations. Page 104 of 141 . MIS for Micro-finance is an active field. 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.MiCOpA SPIDER Project Report • • • A PDA application to support the loan collection operations can quickly be developed using Open-source development software. Although most systems are commercial. some interesting Open-source projects have emerged recently.

Accessed in April 2005.. Sync up Palm OS with J2ME.pdf Accessed in Oct 2004. Summerfield M. L.0. 2005] [Blanchette. Prentice Hall. 2004] [CGAP.gov/cc/. The CHAOS Report (1994). C++ GUI Programming with Qt 3.com. 2005] [Appforge. http://www. Accessed in January 2005.. 2002] [Amida. 2000. Kazman.MiCOpA SPIDER Project Report References [Ambler.. Accessed in Apri.com/products/enterprise/crossfire/index. Introducing the Amida Simputer. 2001.com/javaworld/jw-05-2002/jw-0531palm.html.. 2004.aquadev. Astel D...com/sample_research/PDFpages/chaos 1994. Software architecture in Practice. P. http://www. 2nd Edition.asp?isbn=0131240722&rl=1 [Astel. 2004. 2004. URL: http://www. [Boudewijn. Beck K. J. Biech. 2004] [Boehm and Turner] Boehm B. Accessed in April. Addison-Wesley.javaworld.standishgroup. URL: http://www. Bass. Inc. Appforge.. Agile Modeling. Crossfire – create multi-platform mobile applications using C#. URL: http://www. 2004] [Bass et. VB.com/pyqt/ Common Criteria. GUI Programming with Python: QT Edition. http://csrc. URL: http://www. SEI Series in Software Engineering. Accessed in December 2004 CGAP – Consultative Group to Assist the Poor..org/docs/IT_pda. Blanchette J. Open Docs Publishing.org/en/fr/pdf/AdBanking_Anglais_High. 2002.amidasimputer. Standish Group. R. Addison-Wesley. 2000] [Beck.net or VB 6. eXtreme Programming: Embrace Change. URL: http://www. Clements. [CC. 2005] Ambler S.appforge.html. and Turner R. John Wiley & Sons. al] [Beck. 2005] Page 105 of 141 . 2004] [Biech. 2004] [Aquadev. Addison-Wesley.. 2005. Balancing Agility with Discipline. 2005. Test-Driven Development.opendocspublishing.pdf. 2004. Addison-Wesley.nist. http://phptr. Accessed in April 2005. PicoPeta.pdf.. 2005] [CHAOS. 2003.cgap. Aquadev.com/bookstore/product. How successful are PDAs for microfinance?. Addison-Wesley. Beck K. Extreme Programming Explained: Embrace Change. 2001] Boudewijn R.

cutter.. 2004] Charette R. 2005] [Deming..org/wiki. Cockburn A. Tegarden D. Open Source database Comparison.Accessed in April. 2005] Swayam Krishi Sangam (SKS) Handheld/Smart Card Project. Accessed in April 2005. [Digitaldividend. Personal and Ubiquitous Computing. URL: http://shopper. last updated March.org/. 2002] Dennis A.digitaldividend. 1982. John Wiley & Sons. 2005] [Cockburn. 2002. 2005] Concurrent Versions System.html. 2005 and retrieved on 3rd April 2005.di. Pearson Education. The Inmates are Running the Asylum. [CVS. 1999. 2005 from the site http://www. http://www. Accessed in April 2005. Haley-Wixon B.html?tag=shfd.org/pubs/pubs_05_sks. Product Information.. db4objects. [DC. CNET. Cambridge. Agile development and Project Management..db4o..compiere. 2 (19).cgi?WhatIsWiki. URL: http://wiki. Accessed on April 2005 Cooper A. Vol.com/PDAs/2001-3127_9-0. Accessed in April 2005.com/about/productinformation/ .MiCOpA SPIDER Project Report [Charette.. Macmillan Computer Publishing. E. 2002] [Compiere. 1982] [Dennis et al. retrieved on the 7th April. Agile Software Development. Cutter Consortium.com/mailsoftware42/db/. [CNET. A Web article found at the site http://www. MA. Out of the Crisis. Compiere.geocities. Page 106 of 141 . and Brewster S. Online article. 2005. W. URL:www. The Challenge of Mobile Devices for Human Computer Interaction. Inc. Jan 2002. URL: http://www. The Decision is in: Agile versus Heavy Methodologies. Deming. Accessed in February 2004.cnet.. 2005] Wiki. 2002. Brewster] Dunlop M. Shop for Handhelds/PDAs. MIT Center for Advanced Engineering Study. URL: https://www..cvshome.htm [Dunlop.com/freestuff/epmu0119. 2005] [db4o.. Systems Analysis and Design: An Object-Oriented Approach with UML.org. 2005] [Cooper] [Cunningham.

1999.html.net Highsmith J.. A Project with DSV. URL: http://www.com/demosoft/index. S.1994] Design Patterns: Elements of Reusable Object-Oriented Software. 1995] http://www. PowerPoint presentation. ACM Queue.htm Grameen Banker 3. 2002. Eclipse projectFAQ. Vol. 2005] [Highsmith. A discipline for Software Engineering: The CompletePSP Book.gdrc.gtk. 2005. http://www. 1999] [Fowler. Hubbard J. Humphrey.microsoft.eclipseme. 2002] [Gamma et al. 2 (3). Demo Software for MFIs http://asp. 2005.0 Manual Grameen Bank's Micro credit operation Automation System. 2005] Frequently Asked Questions About Microsoft Access Security for Microsoft Access.eclipse. Grameen Bank. J2ME Development using Eclipse. Accessed in Oct 2004.org. 2005] Eclipse Foundation. Accessed in April. Addison-Wesley. the link is: http://support.com. Richard Helm.grameen. Addison-Wesley. John Vlissides. Erich Gamma..org/bank/November04US$. Accessed in April. Fowler M. URL: http://www.org/eclipse/faq/eclipse-faq.0 Demo http://asp.html. Accessed in Oct 2004.com/default.com/demosoft/gbanker.asp Fowler M.htm [Grameen] [Grameen Monthly Update] [Grameen Banker Demo] [Grameen Banker Manual] [Grameen MiCOpA] [Grameen Demo Software] [Grameen Grameen Bank's Operating System. 1999. UML Distilled 2nd Edition . Open Source to the Core.aspx?scid=%2Fsupport%2Fac cess%2Fcontent%2Fsecfaq. May 2004. 1994 [GDRC] Global Development Research Center. Addison-Wesley. EclipseME.. Patterns of Enterpries Application Architecture . URL: http://www. Agile Software Development Ecosystems.htm Grameen Banker 3. 2005.MiCOpA SPIDER Project Report [Eclipse. Operating System] [GTK. Retrieved from Microsoft support homepage on 14th April.grameen-info. 2004. PowerPoint presentation. 2004] [Humphrey. URL: [EclipseME. 2002] [Hubbard.. Addison-Wesley.grameen... 1995.org/icm/microlending. Grameen Bank Monthly Update in US$:November. W. Ralph Johnson. Page 107 of 141 . http://www.grameen-info. [Fowler. 2005] [FAQ. Addison-Wesley.

2005.sourceforge.import5103. Anderson A.com/release0028..com/ [Karlström. About kXML. S.idevelopment.jsp?optionId=1_1_2 &platformId=1&siteId=291&count=20&txtSearch=websphere&se ctionId=0+All+Categories. 9 (6).ats. Interactions.com/PlatformSearch. Bright Helms and Xavier Reille.com/issue/microcredit/misandmicrofinance . 2001] Jeffries R.net/about. 2001.. Kruchten P. Hendrickson C. 2005.info/data/Programming/data_structures/j ava/LinkedList/LinkedList. Accessed in April 2005.shtml.to/ at 13thApril.php.lmu. 2005] [kXML. 2005] Indian NGOs. 2005. Extreme Programming Installed. Crystal Clear Software Limited. [IBMWS. URL: http://www. J M.neweconomyproject. [INTERCOMM] Interaction Design Prototyping of Communicator Devices: Towards Meeting the Hardware-Software Challenge. 2005. Accessed in April. Third National Conference on Software Engineering Research and Practice in Sweden. Acccessed in April 2005. 2005] [Jeffries et al. CGAP Occasional Paper. Kura. URL: http://www. 2005] The Pragmatic Programmer: From Journeyman to Master. Software Connection. 2005] [ICM] [IICD] [Indian NGOs. 2003] [Kruchten] [Kura. Information Security Glossary. International Institute for Communication and Development. 2005] Page 108 of 141 .. URL: http://kxml. URL: http://www. 2003. The Rational Unified Process – An Introduction.yourwindow. [JN-USAID.. Andy Hunt and David Thomas. 2005] [LP.. Accessed in April.de/kura/index. http://www. Addison-Wesley.indianngos.iicd. Addison-Wesley. 2000. Retrieved from the site http://www. Data Structures and Algorithms in Java. URL: http://www.. A software company in Uganda. 2005] Project with JN Small Business Loan Ltd. a multi-user open-source linguistic database.org/stories/articles/Story. SERPS'03 Sweden. has developed a micro finance management application marketed as Loan performer. 2005.palmone. URL: http://software. Link: http://www. Vol.loanperformer. September 2004.shtml. IBM WebSphere Everyplace Micro Environment. Haustein. 1999] [Hunter. Addison-Wesley Oct 1999 Hunter. [ISG.MiCOpA SPIDER Project Report [Hunt et al.html Karlström D.htm. Interest Rate Ceiling and Microfinance. Accessed in Oct 2004. Nov/Dec 2002. Effects of Introducing Agile Methodologies in Software System Engineering. Information retrieved on 15th April. Accessed April.

Accessed in Oct 2004.com/library/default. Accessed in January 2005.MiCOpA SPIDER Project Report [LOS. Prentice Hall PTR. Elias K. Information retrieved on April. Accessed on April 2005 [MIDP-OVM] MIDP-OVM. 2005] [Morrison.sourceforge. 2005] McNamara W. Jo. 2005] List of MIS products for MFI’s. James McGovern.net. URL: http://nextel. Accessed in April.net/projects/alcaiceria/ Metrowerks. Teach Yourself Wireless Java with J2ME in 21 Days.fi/pdaovm/midp-ovm/index. James Linn. Charles Waterfield . Stevens.cfm?id =tn_17034 [MASE] MASE. 2005 from http://mifos.asp [MicrofinanceGateway. 2005] [Metrowerks. URL: http://www. 2004 [McNamara. Project Home page on sourceforge http://sourceforge.78.html. Retrieved from the CGAP home site. URL: http://www. URL: http://opensource. February 1998 MOAP Twiki Home Page. [MDN. 2005] Using Microsoft Access Databases in a Production Environment. 2005] http://www. CodeWarrior Technology. Michael E. from http://www.net. Accessed in April.sourceforge.metrowerks.MASE..org/library/evaluatn/focusgrp.cpsc.nakedobjects. Nick Ramsing. Ambler. 2005] [MIS] [MOAP. Nextel's Open Source J2ME Toolkits.jsp?page=Root. http://64.org.ca/ebe/Wiki. Vikas Sharan. Mifos Project Home page on sourceforge. 2001. 2005.asp?url=/library/enus/vb98/html/daobjData. Naked Objects.org/.macromedia. 2005] [Microsoft Data Ctrl] Microsoft Data Control Documentation http://msdn. URL: http://www. Scott W. 2004] A Practical Guide to Enterprise Architecture.sourceforge.. a Freescale company. 2005] . Accessed in Oct 2004.vtt. Microbusiness Development Network.cfm [Macromedia. Digital Focus. Accessed in Oct 2004.htm.mapnp.com/cfusion/knowledgebase/index. Retrieved on April 20. [McGovern et al. Inc.com/mw/default. URL: http://ebe. 2005 from http://moap.microsoft.ucalgary.htm.net/cgibin/twiki/bin/view/Moap/WebHome Morrison. M.erve. Page 109 of 141 [Mifos.Management Information Systems for Microfinance Institutions.216/dev/cgap/iss/product_list. Basics on Conducting Focus Groups.microfinancegateway. ColdFusion TechNote. retrieved on april .5. 2005. SAMS. 2001] [NakedObjects] [Nextel. 2005.

com/articles/access-migrate.. 2005. 2001. Accessed in Oct 2004. IEEE Software Vol. [Rasmussen. 2005] [Python.redhat. URL: http://www. Palm OS programming with GCC. 2005] [Report Lab Toolkit] http://www. 20 (3). http://www.com/software/rational/.onjava. 2001] [PRC. 2003. Page 110 of 141 .htm. URL: http://www. URL: http://www.sei. palmOne. 2003] [Paulk.html. Inc. PalmSource. Hall T.edu/ata/products_services/qaw... Accessed in April 2005.palmone. Baddoo N. PalmOS Developer Suite. 2005. Introducing XP into Greenfield Projects. 2005. OSTG Open Source Technology Group. URL: http://www.0. Practitioners Reports. IEEE Software Vol. Hitting the Target: Adding Interaction Design to Agile Software Development.php [Red Hat.python. 2005] [PalmOS.reportlab.html. 2005] [QAW] [Rainer et al. URL: http://www.palmos.com/pub/a/onjava/2002/12/18/midp.org Quality Attribute Workshops.MiCOpA SPIDER Project Report [ONJava. PalmSource. URL: http://www-306.sourceforge. Migrating from Microsoft Access to MySQL. Red Hat Scholarships. [PalmDS. IEEE Computer Society.com/community/rhscholarship. 2005.com/products/. 2003] [Rational.palmsource.. Inc.com/dev/tools/dev_suite. Tungsten handhelds. Accessed in April 2005.html on 5th April. information collected from the Red Hat India web page on April 12. Rational Software.cmu. 2005. 2002. Accessed April. Extreme Programming from a CMM Perspective.com/us/products/handhelds/tungsten-c/.html. Inc.in.. 2005] [palmOne. Paul DuBois.kitebird. Accessed in April. Accessed in April 2005. Accessed in April. 2005] Rasmussen J. Patton J. 18 (6). Introducing MIDP 2.. OOPSLA.org/rl_toolkit. Paulk M. An internet article written on January.net. Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE’03). Accessed in April 2005. the open source challenge. Persuading Developers to “Buy into” Software Process Improvement: Local Opinion and Empirical Evidence. 2003 and retrieved from the site: http://www. 2003] Rainer A. 2005] [Patton] [Paul.. 2005] O’Reilley Media. http://www. URL: http://prc-tools. 2003. Palm powered products. Inc.ibm.

funambol.trolltech.org/docs/IT_smart_card.jsp?main=theproject. 2005] [Stapleton.org/~sketchpel/weblio/open-source. Internet Article.com.net. Access in April 2005 [Simputer. 2005] [TAA.sida. URL: http://www. 2001. URL: http://www. Retrieved from http://www.pdf. Steve Whelan.html.rdvp. 2005] A Rational Software Corporation White Paper. http://www. URL http://www. online article retrieved on the 28th march. and Beedle M.cgap.org Putting Technology to Work for Poverty Alleviation. [Schwaber & Beedle. on April 2005. http://www. 2005.com/main.simputer. 2005. 2005 from http://www. 2005] [SKS.html on the 24th March.sqlobject. 2005] Strategy for IT i Development Cooperation (sic). by 15 seconds Discussion List.sourceforge.serviceoriented. 2005] The Simputer Trust.sun. Stapleton J. Accessed in April. [SIDAITStrategy. 1997. URL: http://java. URL: http://www.org/english/microfinance/year/GAresolutions/U [SOA] [SQL Object.ca/~mohrj/courses/2000. DSDM Dynamic Systems Development Method: the Method in Practice. link: http://www. UN General Assembly. Accessed April.CGAP IT Innovation series. 1997] [Steven. 2005] [Trolltech.org. Steven Ketchpel.15seconds. Addison-Wesley. 2005] [UN] Page 111 of 141 . URL: http://tcl. 2005. Funambol. 2001] Schwaber K. Smart Cards. URL: http://sync4j. Webliography of Open Source Software for Microfinance.augustana.htm.. 2005.com/TechnologyAtSKS. 2005] [Sync4j.winter/csc220/pa pers/rup_best_practices/rup_bestpractices.sksindia.. Welcome to Simputer.html Sun Microsystems. Accessed in March 2005. Prentice Hall. 2005. Micro Edition (J2ME). Accessed in Oct 2004. online document retrieved from the home page of SKS India. Accessed in April. http://www.com/Issue/010514.uncdf. Accessed in April 2005. The Truth About Access. Agile Software Development with Scrum.com/j2me. 2005] [Sun. Trolltech Inc. Accessed in April. 2005. Rational Unified Process: Best Practices for Software Development Teams. Sync4j.org. Tk Toolkit.se/Sida/articles/5400-5499/5490/strategy. URL: http://www..ab. Java 2 Platform.MiCOpA SPIDER Project Report [RUP. 2005] [Steve.htm Service-Oriented-Architectures. Inc. Accessed April. 2005] [Tk.

IBM Systems Journal.wikipedia.org Extreme Programming.vbunit. http://www.. A framework for information systems architecture.grameen-info. Accessed in Oct 2004. 2005] [Wiki. 2005 from http://sourceforge. October 2002. Accessed in January 2005. 2005] Yunus M. [Y-Community. [WIKIPEDIA. [Zachman. URL: www.pdf.. URL: http://wiki. Grameen at a glance.org/bank/bank2. Packages Corporations Limited.extremeprogramming. 1987] Page 112 of 141 . Proceedings of SAICSIT 2004. [wxWidgets] [XP. 2004] Winschiers H. and Paterson B. 2004. URL: http://www. 2005]Open Source Project: Y-community.org. VBUnit Unit Testing.net/projects/y-community/ [Yunus 2002] Grameen Bank II: Designed to Open New Possibilities. 2005] Wikipedia. 2004] wxWidgets. Extreme Programming: A Gentle Introduction. Wiki.wxwidgets.org.org. Accessed in April 2005 [Winschiers & Paterson. 2004. URL: http://www. Retrieved on 13th April. Muhammad Yunus. Vol 26 (3).html Zachman J. [Yunus] [VBUnit. http://www.MiCOpA SPIDER Project Report NGA-YoM_eng. Accessed in April 2005.org/. 1987.. Sustainable Software Development. Accessed in January 2004.

MS Access database Grameen Banker stores it's data in. Page 113 of 141 . requirements and future development issues so as to incorporate them in the proposed prototype.0.0 The purpose of this report is to analyze the current information system used for operations at Grameen Bank. Find out if Grameen Banker 3.0.0 User Manual [GBankerManual]. 4. drawbacks. Find out common functionalities in other software developed by Grameen Communications for MFIs.MiCOpA SPIDER Project Report Appendix A Analysis of Grameen Banker 3. advantages and disadvantages. Grameen Banker 3. 2002]. The objective of this document is to solve the following issues in order to satisfy the requirements for the prototype described above: 1.0. 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. 2. We study the Grameen Banks business logic. Visual application: menu options. Find out how much of the business process is hard-coded into the Grameen Banker 3.0 supports Grameen Bank II [Yunus. 3. forms and fields. Find out how much of the bank's business processes is supported by Grameen Banker 3. We have investigated three sources simultaneously in order to analyze the GBanker: • • • Grameen Banker 3.

0 on Windows 9x. Daily Savings Collection: entry of all savings collection from the GB members. Page 114 of 141 . Daily Loan disbursement: the amount of loan disbursed daily from a branch 2. Grameen OS]: Figure A.0 Architecture GBanker 3. the levels and the associated roles. The Grameen Bank organistional structure.1.0 is an application developed in Visual Basic that uses an Access database to store its data. Technology Used Visual Basic 5. Main Functionalities Grameen Banker’s main function is described by the Term Branch Loan monitoring System (BLMS). Page 13] and the figures are taken from [Grameen 2004.MiCOpA SPIDER Project Report Grameen Bank Organization This is the organizational graph of Grameen Bank as found in [GBankerManual. The small amounts of loans that are disbursed to the poor are monitored in the following ways: 1. Daily loan Collection: the entry of all loan payments collected daily in a branch. 3. Grameen Banker 3.

iii. This information is actually kept by the zonal authority. Columns: • • ZoneCode: zone identifier. The codes are given from the Headquarters. v. Page 115 of 141 . Field Operator information Centre information Loanee Information Holiday Information Purpose Information MS Access Database Analysis Tables For every table in the database we provide a description of its purpose. As this is not yet stored in the database. It is added very rarely. 3. it is done manually. the information of the following entities is stored in the database: i. 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. Questions and observations: 1. How often are zones added to the database? 4. the zone manager and it is maintained manually. 2. The Headquarter keeps the information of the zonal authorities of different zones and this is done manually as well. the columns and a set of questions that arose during the study of the database. The application does not consider the part of which people working at which zone offices and their positions. Who (Actor) enters or adds zones to the database? 3.e. An employee (an operator) at the Headquarter is responsible to do this. There are 18 zonal offices [Grameen OS]. In which office (Head/Zone/Area/Branch) are they created? Answers to the questions: 1.MiCOpA SPIDER Project Report Besides these main functionalities. String (only numbers) ZoneName: name of the zone. No information is kept of which people work at which zone office and what is their role or position there. 2. They might need a separate database module to keep that information. String. iv. 4. These questions were solved during the course of the project and therefore we include the answers. ii. i. ZoneCode Contains data for zonal offices.

Columns: • AreaCode: area identifier. Columns: • BranchCode: branch identifier. Questions and observations: 1. • AreaCode: identifier of the Area the area belongs to. String. String. 3. String (only numbers). • ZoneCode: identifier of the Zone the area belongs to. Area manager keeps this information manually.MiCOpA SPIDER Project Report AreaCode Contains data for Area offices. • AreaName: name of the area. The area codes are given at the Head Office. String (only numbers) • BranchName: name of the branch. • AreaCode: foreign key to the ZoneCode table. Who (Actor) enters or adds areas to the database? 3. Areas are added into the database every four months. There are 127 area offices [Grameen OS]. 2. There are 1277 branch offices [Grameen 2004]. Page 116 of 141 . Once the code for a area is defined from the zone. • ZoneCode: foreign key to the ZoneCode table. Keys: • BranchCode: primary key. BranchCode Contains data for Branch offices. The information of different area managers are kept in the zone office. 2. 4. • ZoneCode: identifier of the Zone the area belongs to. But only the code is given and they values are entered to the manual system there in the zone office. No information is kept of which people work at which area office and what is their role or position there. Keys: • AreaCode: primary key. In which office (Head/Zone/Area/Branch) are they created? Answers to the questions: 1. it is entered into the database by the branch operators. How often are areas added to the database? 4. They are entered by an operator in the Zone level.

7. Information is kept about who has worked for which Branch in the table BranchStaff. Keys: • CenterCode: primary key. In which office (Head/Zone/Area/Branch) are they created? A: the Head Office creates the information. 8. There are between 50-60 centers per branch office [Grameen OS]. Values are integers from 1 to 7. • StaffID: foreign key to the BranchStaff table. The column ZoneCode is a duplication of the data contained in the table ZoneCode but they have not defined it as a foreign key.MiCOpA SPIDER Project Report Questions and observations: 1. Who (Actor) enters or adds branches to the database? A: The operators at the area office enter the information. • BranchCode: foreign key to the BranchCode table. where 1 corresponds to Saturday. String (only numbers). • CenterCode: area identifier. • CollectionDay: day of the week that the operator from the branch meets the people in the village Center. • Status: performance indicator for a center. Some branches every month. • CenterName: name of the center. A center is the meeting place for borrowers and the operator from the branch [GBankerManual. we know that ZoneCode is a foreign key to the Area. Copper}. Columns: • BranchCode: identifier of the Branch the center belongs to. 5. 3. 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. From the discussion with Imrul. How often are branches added to the database? A: Branches are added very often in the database. • Organizer: is a representative from the groups • StaffID: operator from the branch that goes to the center. 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. 2. Page 13]. String. No they can not move from one to another. 4. Page 117 of 141 . Possible values are {Golden. Silver. Center Contains data for centers. Can an employee work for different branches at the same time? No.

Questions and observations: 1. 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. This can be a way to represent several centers at the same village. • 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. the Status of a center is no longer indicated with this three values but with stars[Yunus 2004]. How is the Status of a Center computed? Apparently.MiCOpA SPIDER Project Report Sample data: • Centers ordered by CenterName: We find a center "ALI NOGOR" with three different center codes. In Grameen Bank II the status is calculated as stars. Page 118 of 141 .

An employee can not work for different branches at the same time. BranchStaff Contains the data of the employees of a branch. • RealisingDate: date the employee stops working at the branch. Sample data: Questions and observations: 1. The operators do not distribute money. • Designation: the role or position the employee holds in the organization. Page 119 of 141 . Organizer is a representative from the group. The employee gets a new registration in the BranchStaff table in the new branch where s/he moved. String (only numbers). The database keeps this information as they want the Organizer to be a female. Money is not distiributed from the centers. 4. 2.MiCOpA SPIDER Project Report 2. Loanees have to go to the branch office to collect the money. • JoiningDate: date the employee starts working at the branch. Collection day is for a center and it represents the day when operator meets the loanee in the village. • StaffID: identifier of the employee. an employee can do that. Keys: • StaffID: primary key • BranchCode: foreign key to the BranchStaff table. • StaffName: name of the employee. Columns: • BranchCode: identifier of the Branch the center belongs to. But the info is not kept in the database. 3. Can an employee stop working in a branch and move to another? Yes.

The Designation column contains many repetitions and mistakes like "SENIOR ASSISTANT" and "SENIOR ASSESTANT". the employee is treated as s/he has released. • GroupFormationDate: when the group was formed. 5. DESIGNATION posts are not taken from a set of fixed values. 4. outside the branch they are not unique. Group Formation date included here makes the schema not normalized. Do they also keep the title or profession of the employee together with the name? “MD” means Muhammad. Instead of saving the age of the loanee in the LoaneeAge column. Two branch can have same LoaneeNo and they usually have. • GroupNo: identifier of the group the loanee belongs to. LoaneeCareof is a special field that is included on the context of rural social structure of Bangladesh. • LoaneeName: name of the loanee • LoaneeCareOf: name of a person • LoaneeAge: age of the member. String with only digits and a dot. Loanee Contains the data of members of the bank that borrow and save money. Page 120 of 141 . When promoted.MiCOpA SPIDER Project Report 3. This is same as Care of address used in the mail address. • 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. 6. This probably means that they use some other system to manage this information. The only keep the name of the employee. 4. The loaneeNo in a branch is unique. • LoaneeNo: identifier for the loanee. then the drop date is kept • ActiveOrDrop: the status of Loanee whether active or dropped Questions and observations: 1. The dot then distinguishes the different loans. The dot in the LoaneeNo is used when a Loanee has taken more than one loan of the same product type. Columns: • BranchCode: identifier of the Branch the loanee belongs to. and gets a new employee in the area office. we should keep at least the year of birth if not the full date. • CenterCode: identifier of the Center the loanee belongs to. No contact information is kept of the employees. The name is not even divided into name and surname. 3. 2. Loanee No is assigned from the branch office. Many of the poor village women will use the name of a well known person in the village as their care of address.

• ItemCode: string. • CenterCode: identifier of the Center the loanee belongs to.only how much he has to pay each term is needed) • InterestCharge: interest rate • InterestPaid: Interest that is paid • DueInterestInstalment: amount of InterestInstallment not paid • InstallmentDate: date for first installment Page 121 of 141 . the installment that is not repaid (one of them is reduandant. LoaneeSEX is not kept in the database. 6. Identifier of the Loan Product • LoanTerm: number representing the number of terms the loan is taken. 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. • LoaneeNo: identifier for the loanee.MiCOpA SPIDER Project Report 5. If database is not maintained globally and is maintained in the branch office then BranchCode and CenterCode is not needed in this table.. String with only digits and a dot. but it is really important from Grameen Baks respect. • PrincipalLoan: the total amount of principal Loan • LoanInstallment: the amount that is to re-pay each term • DueLoanInstallment: previous due.


SPIDER Project Report

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. It’s 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 center’s collection day. 4. Interest Paid field is also unnecessary in this table.

Page 122 of 141


SPIDER Project Report

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 day’s 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 day’s 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


SPIDER Project Report

• • • • • • •

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 month’s collection of loan. It keeps the loans information against the loaneeNo and Loan product. Information of all the loanees’ of a branch is kept here, and the information of the branchStaff responsible for collecting the loan is also kept. This is for security purpose we guess.

DailyLoanCollection This table keeps the information of the daily Loan Collection. The columns of the table are: • BranchCode: string type, identifier for the branch • CenterCode: string type, identifier for the Center • LoaneeNo: string type, identifier for the Loanee • ItemCode string type, identifier of the Loan Item • LoanTerm : Number of terms for the loan • PrincipalLoan: toatal amount of loan • LoanRepaid: Loan repaid so far • CurInterestCharge : Interest Charge active now • CurInterestPaid : total interest paid • PreInterestCharge : Not used • PreInterestPaid : Not used • LoanInstallment : the amount to repay • DueLoanInstallment : if any due of loan installment • CurIntInstallment : interest amount to pay • PreIntInstallment : not used • DueInterestInstallm : any due in interest, not used • DropWeek : if loanee is absent • InstallmentDate: collection DATE Observation: 1. Loan Term, Principal Loan, Loan Repaid are not needed. They are repetition. They already exist in the loan Register table. 2. Only LoanInstallment and CurIntInstallment are needed for loan collection.

Page 124 of 141

The table contains following columns: • BranchCode: string type. DueLoanInstallment. identifier for the Center • LoaneeNo: string type. Installment date is confusing here. identifier for the Loanee • ItemCode: string type.MiCOpA SPIDER Project Report 3. then LoaneeNo in a branch is unique. identifier for the branch • CenterCode: string type. DueInterestInstallment. so the other information needed for the Collection sheet can be gathered from other tables. DropWeek are also repetition as they already exist in the UpdateLoan table. This table is created for the Loan Collection sheet. collection date may be more appropriate. Daily Loan Collection sheet is created from the branch. identifier of the Loan Item • LoanTerm: Number of terms • PurposeCode: purpose identifier • DisburseDate: DATE of disburse • PrincipalLoan: Total loan amount • LoanInstallment: amount to repay in each term • InterestInstallment: interest to pay in each term • TaxRate1: Tax rates for the item • TaxRate2: Tax rates for the item • TaxRate3: Tax rates for the item • TaxDepositItem1: tax deposited for item by rate 1 • TaxDepositItem2: tax deposited for item by rate 2 • TaxDepositItem3: tax deposited for item by rate 3 • JanuaryLoanInst: Loan installment for this month • JanuaryInterestInst: Interest installment for this month • FebruaryLoanInst: Loan installment for this month • FebruaryInterestIns: Interest installment for this month • MarchLoanInst: Loan installment for this month • MarchInterestInst: Interest installment for this month • AprilLoanInst: Loan installment for this month • AprilInterestInst: Interest installment for this month • MayLoanInst: Loan installment for this month • MayInterestInst: Interest installment for this month • JuneLoanInst: Loan installment for this month • JuneInterestInst: Interest installment for this month • JulyLoanInst: Loan installment for this month • JulyInterestInst: Interest installment for this month Page 125 of 141 . DailyDisburse The daily disburse table contains the disburse details of everyday. because if the database is managed in the branch level. 5. BranchCode is not needed in this table. PreInterestCharge. PreIntInstallment. 7. 6. So there is no problem of mix up with other branch. 4. it is not needed to include those (in bullet 3) in this table. So BranchCode is not necessary here.

7. The loanInstallment and InterestInstallment is defined for each month of the year which sounds a bit strange. If daily disburse kepps the information of disburse against a Loanee’s particular loan. database is kept in a branch then use of branchCode and CenterCode is redundant here. then the amount money disbursed against which loan to which customer is needed only. L Installment. In that case. This table is for defining the loan parameters for every single loan disbursed to a loanee. If DailyDisburse is used to kept the money disbursed daily from the branch. so it is a repetition and the separate definition for each month is also confusing. DisburseHistory This table keeps the information of the Loan and Interest Installments of the loanees month by month. If it is used as a global database then only these two fields are needed. If DailyDisburse keeps the amount that is to be disbursed each month and it varies in each month. 8. Otherwise it is a loss of space in the database. 2.and DailyDisburse keep track of that then it is good to have the values against a date. TaxRates and PrincipalLoan. As loanInstallment and Interest Installment is already defined in the table LoanRegister. 4. TaxDeposit seems to be taken from the ItemCode table. this table keeps information on loan registration and its details. identifier for the Center LoaneeNo: string type. the rest of the columns are not necessary. 3.. May be that is because of any special criteria existed in the context of Grameen Bank’s Loanees.MiCOpA SPIDER Project Report • • • • • • • • • • • 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. Total amount disbursed must be kept as a column. If the loanee takes loan in different times. then it is important to keep the information of each month separately. identifier of the Loan Item Page 126 of 141 . And are redundant. 6. not at one time. I installment. the disburse date. identifier for the Loanee ItemCode string type. identifier for the branch CenterCode: string type. 5. The monthly installments can be the different repayment rates for the loan as they can vary depending on the season. • • • • BranchCode: string type.

So it is redundant to keep that information separately for each month. Interest is calculated as 0. for a loan of 4000 taka. For example. In DisburseHistory this 8 is inserted in the column of each month’s InterestInstallment. LoanIstallment and the InterestInstallment are same for all months for all the loan items taken by loanees. Page 127 of 141 . The calculation of LoanInstallment is not clear.2/100 = 8 taka per term. But from the values. the interestInstallmemt is 4000*0.2% of the principal loan per term. 2. they fix it with some specific condition and criteria of Grameen Bank and the Loanee.MiCOpA SPIDER Project Report • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 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. 3. 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.

2. Otherwise if they are fixed for an item. string type ItemCode This table contains the information about the Item that is the loan product. identifier of the investor • Investor: Name of the Investor. LoanInstallment.MiCOpA SPIDER Project Report InvestorCode This table is used to keep the investor information. But they might be used at some time or in some other MFI’s. The columns are: • InvestorCode: string type.7 then they are redundant here. IntInstallment. • BranchCode: identifier of the branch • BranchName: name of the branch • ItemCode: ID of item • ItemName: Name of the Item • PurposeCode: ID of purpose • Purpose : Name of ourpose Page 128 of 141 . MainItemCode keep the category information. • • • • • • • • • • • • • • • 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. savingsInstallment. then in the LoanRegister table it is not necessary to add these fields. 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. 3.why they are kept in this table? If these values are set in the LoanRegister table 4.1. taxRate is not used in Grameen right at the moment.

If it is like keeping the male and female loans and their number then the values should kept against per branch per loan item. identifier for the Loanee ItemCode string type. 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. ItemName and Purpose is not as they can be accessed from PurposeCode and ItemCode tables. They are keeping track of male and female loanees and it seems Grameen has a great interest on it. 2. identifier for the Center LoaneeNo: string type. identifier of the Loan Item LoanTerm: number of terms of the loan Regular: whether the loanee is regular Drop: whether the loanee is Drop Token : whether the loanee is Token PrincipalLoan: total amount of loan LoanInstallment: amount paid in each term DueLoanInstallment: due InterestPaid: interest paid in each term DueInterestInstallm: interest due InstallmentDate: date of collection StaffID: ID of staff StaffName: Name of Staff Page 129 of 141 . But in Loanee table Loanee Sex is not included. MonthlyProcessFile The columns for this table are: • BranchCode: ID for branch • MonthlyProcessDate: DATE of processing. • • • • • • • • • • • • • • • • BranchCode: string type. 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. identifier for the branch CenterCode: string type. • MonthlyProcessYN: Boolean. Observation: 1.MiCOpA SPIDER Project Report • • • • • • 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.

identifier for the branch • CenterCode: string type. The columns of tables are: • BranchCode: ID for branch • ItemCode: ID for item • InvestorCode: ID for investor Page 130 of 141 . Is savings kept as per loanee per item basis? Or is not it better to have as per loanee basis. Staff name can be found from BranchStaff table. But can be done by only one parameter. 3. It was better if only when some value is added in savings account then to generate a row for this table. But it generates rows where no savings is added. StaffID is sufficient. Toekn these values represent the condition of the Loanee for each installment. In case of Grameen savings account is opened against each loan item taken by a loanee. 2. PurposeCode This table keeps the purpose information. 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. Summary This table keeps the summary information of a particular item in a branch. 2. Absent mean the absence of savings in a installment date. identifier for the Center • LoaneeNo: string type. • PurposeCode: ID for purpose • Purpose: description of the purpose SavingsRegister This table keeps the savings • BranchCode: string type. How LoanTerm is defined here? Is not it redundant? Drop and Regular. This table is fed with data from the CurMonth table. It seems to be an intermediate table that keeps the information about a loanee’s previous months’ transaction summary. 3. Actually this table contains all necessary values for the report and that’s why it has repetitions. Insatallment date keeps the record when savings added or withdrawn.MiCOpA SPIDER Project Report Observation: 1. 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 . how much of the loan has been repaid and the status of the loanee. UpdateLoan This table keeps the intermediate states of al the loans disbursed to the loanees.MiCOpA SPIDER Project Report • 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. • • • • • • • • • • • • • • • BranchCode: string type. It is not clear whether it’s a monthly based summary or yearly. 2. Summary is kept for each item in a branch. the time passed etc. it seems that this summary is for the item from the starting of the branch till today. identifier for the Center LoaneeNo: string type. identifier for the branch CenterCode: string type. Many fields are not used as it seems from the sample data. As there is no date time attached with it. identifier for the Loanee ItemCode string type. 3. It keeps the status.

2. Why this monthly Loan and Interest Installments are there as it is already mentioned in some other table. 4. 3. Interest Rate is not needed here.MiCOpA SPIDER Project Report • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 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. Disburse date. Page 132 of 141 . 5. UpdateSavings Updates the savings status and SavingRegister keeps the transactions. 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). Duration (not understood). but monthly installments are not clear whether they represent monthly repaid amount or the amount each term they should pay in each month. Many repetitions. Update Loan keeps the status information.

But from this table it is not clear how the four tables are maintained. Page 133 of 141 . four savings accounts are opened against a loan.MiCOpA SPIDER Project Report 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. This table keeps the status information of the savings accounts.

MiCOpA SPIDER Project Report Appendix B Software Process Improvement Software process improvement work is itself is based on models or strategies. The plan is instead that these steps. The Shewhart Improvement Cycle [Deming. 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. Act Implement change Determine effectiveness In the MiCOpA project the Shewhart Improvement Cycle has been applied. Cockburn’s definition [2002] has been used as a starting point for structuring both the discussions and the data collected during the workshops. 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. although in a modified way. scope and delimitations of the MiCOpA project. 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. Do Identify possible problem causes Establish baselines Test change 3. 2005]. but also as a means to structure the results of the analysis. 1982]. The polar chart and risk analysis were used as tools to Page 134 of 141 . As shown in the list below. will be followed up in future projects. it defines four steps for a general improvement process [Deming. 1982]. Step two was then followed up by a top-down analysis by applying Boehm’s and Turner’s [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. Step four and step three are excluded due to the goals. evaluating and determining the actual effects of introducing the improved process. Therefore. and is used as a basis in for example the Capability Maturity Model evaluation frameworks [CMM. Plan Define the problem Establish improvement objectives 2. The Shewhart Improvement Cycle provides a well-known foundation for process improvement work. i. In this process analysis and evaluation. 1982] [Humphrey. Check Collect data Evaluate data 4.e. 1992] 1.

MiCOpA SPIDER Project Report identify the sources of risks and to understand whether an agile or plan-driven process approach would be the better choice of 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. 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. Once the risks where identified it was possible to define resolution strategies which were integrated into the definition of a baseline process. Page 135 of 141 . turning the strategy into an actual process.

Process January 1. observations. 2005. The tasks planned for the 5 months of project time are: T1. 2005) Page 136 of 141 . case study.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. 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.MiCOpA SPIDER Project Report Appendix C Starting date Plan of Work Work package 1 . 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. 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.1: Analysis and evaluation of the current Software Process T1.

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. 2005) Deliverable Page 137 of 141 . 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. The tasks planned for the 5 months of project time are: • T2. 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.2: Definition of an appropriate Architectural Design The deliverable of the work package is: • D2: Guidelines on an appropriate Architectural Design (Due May 30.MiCOpA SPIDER Project Report Work package 2 .1: Analysis and evaluation of the current Architecture • T2.Architecture Starting January 1. case study. 2005. observations.

observations and case study.1: Analysis and evaluation of the current technology environment • T3. 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. 2005) Deliverable Page 138 of 141 .2: Definition of an enabling technology environment The deliverable of the work package is: • D3: Recommendations on an enabling technology environment (Due May 30.Technology Starting January 1. 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. 2005. 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.MiCOpA SPIDER Project Report Work package 3 . The tasks planned for the 5 months of project time are: • T3.

including a PDA solution. Page 139 of 141 . this project will also provide better understanding of what factors in the developing countries affect the use of certain techniques and technology. Grameen Bank and Grameen Communications will provide the pre-agreed assistance to conduct the research and the research activities.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. based on the guidelines put forward (as a proof of concept). The tasks planned for the 3 months of project time are: • T4. 2004) Detailed account of available resources including all personnel and equipment Stockholm University will be the leader of the project. 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. In this respect. Stockholm University will provide resources in addition to the funding provided by SPIDER. as well as the associated problems. require creative solutions that would not be thought of under more stable conditions of development. 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.5 person-months worth of work. (UN. and its positive impact on the lives of people living in poverty. The processes of acquisition. Grameen Bank and Grameen Communications will provide resources in addition to the funding provided by SPIDER. Process.Prototype Starting date Participants Objective February 15. 2005. and what factors can potentially change these circumstances.MiCOpA SPIDER Project Report Work package 4 . building up. Architecture. corresponding to 3 man-months worth of work. 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. exploitation and maintenance of ICT. corresponding to 1.

1: Screenshot examples from the PDA prototype application. Page 140 of 141 .MiCOpA SPIDER Project Report Appendix D Screenshots and the Paper Prototype Figure D.

MiCOpA SPIDER Project Report The Branch Disburse: 200000 Repaid: 120000 Balance: 80000 Loan installment: 10000st installment: Intere 1000 Server address: (0) (0) http://192.0. 21 22 Details The Branch > Center 2 > Group 21 > Details Collection date: 01/02/2005 Disburse: 120000 Repaid: Balance: Details 72000 48000 Loan installment: 6000 installment: Interest 600 Full payment (0) (0) Open Open The Branch > Center 2 > Group 21: Loanees Collection date: 01/02/2005 Loanee name Erik Fredrik 212 Loanee number 211 Details Save The Branch > Center 2 > Group 21: Fredrik Collection date: 01/02/2005 Loanee number: 212 Purpose of loan: Fluorine Details Disburse: Repaid: Balance: 96000 33600 62400 Loan installment: Loanee absent Interest installment: (4800) (480) 0 0 Groups Details Save Figure D.2: The paper prototype.168. Page 141 of 141 .5:8080/micopa/dbServlet Exit Open Open Download The Branch: Centers Center code 1 2 Collection date 01/01/2005 01/02/2005 Details The Branch > Center 2: Details Collection date: 01/02/2005 Disburse: 200000 Repaid: 120000 Balance: 80000 Loan installment: 10000 installment: Interest 1000 (0) (0) Open Open The Branch > Center 2: Groups Collection date: 01/02/2005 Group no.

Sign up to vote on this title
UsefulNot useful