Micro Finance Management System (MFMS) Project Plan Filing Reference : INT/MFMS/MP.2 Document Title: Project Plan Version : 1.4 Prepared by : Maya Roosevelt Date Created : January 9, 2012 Reviewed by : Tan Achilles Date Quality Manager Verified by : Maya Roosevelt Project Manager © 2011 ISS. The information contained in this document is the property of ISS. The contents must not be reproduced , wholly or in part, for purposes other than for which it has been supplied, without the prior permission of ISS, or, if it has been furnished under contract to another party, as expressly authorised under that contract. ISS shall not be liable for any errors or omissions. ISS Date Document Reference : INT/MFMS/MP.2 Version Date Author Modifications 0.1 16/3/2011 Maya Roosevelt Initial Draft Reviewed by Achilles Tan 0.2 18/3/2011 Maya Roosevelt Updated Achilles Tan 0.3 28/3/2011 Maya Roosevelt Updated with Appendix Achilles Tan 0.4 31/3/2011 Maya Roosevelt 0.5 1/4/2011 Maya Roosevelt Updated Schedule. Updated intro, and Achilles Tan descriptions. Performed grammar and spell checks. Updated Sections 2.1.11, 4.2.3.2, 7.1 and 7.2 Achilles Tan 1.0 4/4/2011 Anupama Sarada Updated Gantt charts in Appendix D 1.1 9/4/2011 Maya Roosevelt 1.2 20/4/2011 Maya Roosevelt 1.3 1/8/2011 Maya Roosevelt 1.4 9/1/2012 Maya Roosevelt Updated Costar screen shorts Updated Gantt Chart Changed all Middleware instances to Branch Achilles Tan Office Support System (BOSS) Updated Gantt Chart in Appendix D Achilles Tan Consolidate DB Design deliverable Added Prototype Study Report Updated Gann Chart Achilles Tan Maya Roosevelt Achilles Tan Distribution: Name Department Vijeyakumar K Management Dave Hufton Suria R Asai Anupama Bright D L Jawahar Chelliah Karthi K Maya Roosevelt Satish Kumar Tan Achilles ISS Faculty ISS Faculty MTech SE18 2E MTech SE18 2E MTech SE18 2E MTech SE18 2E MTech SE18 2E MTech SE18 2E MTech SE18 2E Organisation Integratech Pte Ltd NUS NUS NUS NUS NUS NUS NUS NUS NUS Email vijey@integratech.com.sg issdrh@nus.edu.sg suria@nus.edu.sg G0802147u@nus.edu.sg A0065792@nus.edu.sg A0065999@nus.edu.sg A0065977@nus.edu.sg A0065877@nus.edu.sg A0065901@nus.edu.sg achillestan@nus.edu.sg TABLE OF CONTENTS 1. INTRODUCTION 1.1 2. Purpose 4. 6 1.2 Audience 1.2.1 Team Members 1.2.1 Project Sponsors and Business Users 1.2.2 Other Stakeholders 6 6 6 6 1.3 Organization 7 1.4 Project Background 7 1.5 References 7 PROJECT SUMMARY 2.1 Project Profile 2.1.1. Objectives 2.1.2. High-level Project Scope 2.1.3. Name of User/Department 2.1.4. Project Name 2.1.5. Project Start Date 2.1.6. Project End Date 2.1.7. Project Size 2.1.8. Project Effort 2.1.9. Project Budget 2.1.10. Estimation Technique 2.1.11. Project Work Environment 2.1.12. Frequency of PMP update 3. 6 8 8 8 8 8 8 8 8 8 8 8 9 9 9 2.2 Assumptions and Constraints 2.1.1 Assumptions 2.1.2 Constraints 9 9 10 2.3 10 Critical Success Factors PROJECT SCOPE 11 3.1 In Scope Items 3.1.1 Functional Scope 3.1.2 Non Functional Scope 11 11 11 3.2 Out of Scope Items 11 PROJECT APPROACH 12 4.1 Inception Phase 4.1.1 Produce Project Plan 4.1.2 Produce Quality Plan 4.1.3 User Requirement Specification 12 12 12 12 4.2 13 Elaboration Phase 4.2.1 4.2.2 4.2.3 5. Study the Current System Functional Specification High Level Design Specification 13 14 15 4.3 Construction Phase 4.3.1 Design Modelling: Low Level Design Specification 4.3.2 Test Driven Development 4.3.3 System Testing 4.3.4 Integration Testing 15 16 16 16 16 4.4 Transition Phase 4.4.1 Documentation 4.4.2 User Acceptance Test 4.4.3 Project Closure 16 17 17 17 WORK PLAN 18 5.1 Requirement Analysis 18 5.2 Study of the Current System 18 5.3 Analysis 5.3.1 Domain Object Modelling 5.3.2 Use Case Realisation Report (Analysis) 5.3.3 Prototype Study Report 18 18 19 19 5.4 High Level Design Specification 5.4.1 Software Architecture Specification 5.4.2 Transition Strategy from Analysis to Design 5.4.3 Database Design 19 19 19 19 5.5 Detailed Design Specification 5.5.1 Design Model Report 19 20 5.6 Application Development 5.6.1 Create Database Tables and Fields 5.6.2 Produce Source Code 20 20 20 5.7 Testing 5.7.1 System Test Plan 5.7.2 Integration Test Plan 5.7.3 Perform Testing 20 20 20 20 5.8 20 Documentation 5.9 User Acceptance 5.9.1 User Acceptance Test Plan 5.9.2 User Environment 5.9.3 Perform User Acceptance Test 21 21 21 21 5.10 Quality Assurance and Progress Management 5.10.1 Progress Report 5.10.2 Action List Sheet 5.10.3 Project Report 5.10.4 First Quality Audit 5.10.5 First Project Presentation 5.10.6 Second Quality Audit 5.10.7 Second Project Presentation 5.10.8 Third Quality Audit 5.10.9 Third Project Presentation 21 21 21 21 21 22 22 22 22 22 6. STAFF EFFORT ESTIMATES 6.1 7. Staff Effort Estimates and Progress PROJECT MILESTONES & DELIVERABLES 24 24 26 7.1 Project Deliverables 26 7.2 Project Milestones 27 7.3 Project Schedule with planned dates of activities 27 8. PROJECT ORGANISATION 28 8.1 Project Structure 28 8.2 Project Governance 28 8.3 Roles and Responsibilities & Resource Plan 29 9. PROJECT MONITORING AND CONTROL PLAN 30 9.1 Tolerance and Exceptional Management 30 9.2 Escalation Path 30 9.3 Communication Plan 9.3.1 Communication and Progress Reporting Plan 10. RISK AND ISSUE MANAGEMENT 30 30 31 10.1 Key Project Risks 31 10.2 Problem Resolution Process 31 GLOSSARY OF TERMS 32 11. APPENDIX A – FUNCTIONAL POINT COUNTING 33 APPENDIX B – COSTAR EFFORT ESTIMATION 43 APPENDIX C – RISK MANAGEMENT PLAN 46 APPENDIX D – GANTT CHART 48 INSTITUTE OF SYSTEMS SCIENCE 1. MICRO FINANCE MANAGEMENT SYSTEM INTRODUCTION Microfinance is the provision of financial services to low-income clients or solidarity lending groups including consumers and the self-employed, who traditionally lack access to banking and related services. Broadly, it is a movement whose object is "a world in which as many poor and near-poor households as possible have permanent access to an appropriate range of high quality financial services, including credit savings, insurance, fund transfers etc. Integratech is a company that would like to have a solution for Microfinance that is intended to be deployed overseas. On behalf of Integratech, MTech Team 2E will propose a software solution and develop this system – Microfinance Management System (MFMS). The system shall cover the following main components: 1) BackOffice Application 2) Mobile Channel 3) Branch Office Support System (BOSS) for Data Exchange This document is the Project Plan. The following sections describe the plan in terms of its purpose, audience, organization and related documents. 1.1 Purpose The purpose of this plan is to identify all the project activities, resources required, monitoring mechanism, and responsibilities. It serves as a planning as well as a tracking document for the Micro Finance Management System project. 1.2 Audience The intended readers of this Project Plan are 1.2.1 Team Members To provide the project team with a plan to perform required activities. To draft all the deliverables to be provided from this project and effort required to achieve them and timelines to be adhered to. To provide details of quality process to be followed. 1.2.1 Project Sponsors and Business Users To give clarity to the project sponsors on the processes for Project conceptualization; Project approvals; Project executions Interaction points Project deployment 1.2.2 Other Stakeholders To give clarity to ISS faculty of project organization, schedule and effort required. INT/MFMS/MP.2/V1.2 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 6 OF 50 INSTITUTE OF SYSTEMS SCIENCE 1.3 MICRO FINANCE MANAGEMENT SYSTEM Organization This document provides the project plan to the Micro Finance Management System and the following sections describes the project plan in detail Section 2 – Project Summary Section 3 – Project Scope Section 4 – Project Approach Section 5 – Work Plan Section 6 – Staff Effort Estimates Section 7 – Project Milestones and Deliverables Section 8 – Project Organisation Section 9 – Project Monitoring and Control Plan Section 10 – Risk Issue Management 1.4 Project Background Formal credit and savings institutions for the poor have also been around for decades, providing customers who were traditionally neglected by commercial banks a way to obtain financial services through cooperatives and development finance institutions. While the goal of such rural finance interventions was usually defined in terms of modernizing the agricultural sector, they usually had two specific objectives: increased commercialization of the rural sector, by mobilizing "idle" savings and increasing investment through credit, and reducing oppressive feudal relations that were enforced through indebtedness. In most cases, these new banks for the poor were not owned by the poor themselves, as they had been in Europe, but by government agencies or private banks. Over the years, these institutions became inefficient and at times, abusive. Experimental programs in Bangladesh, Brazil, and a few other countries extended tiny loans to groups of poor women to invest in micro-businesses. This type of microenterprise credit was based on solidarity group lending in which every member of a group guaranteed the repayment of all members. These "microenterprise lending" programs had an almost exclusive focus on credit for income generating activities (in some cases accompanied by forced savings schemes) targeting very poor (often women) borrowers. 1.5 References To fully understand the background to this project, the reader should also be familiar with the MFMS Quality Plan (Ref: INT/MFMS/MQ.1) To understand about the business of Integratech and detailed requirements of this Project, the reader should refer to MFMS User Requirements Specification document. (Ref: INT/MFMS/TS.1) INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 7 OF 50 INSTITUTE OF SYSTEMS SCIENCE 2. MICRO FINANCE MANAGEMENT SYSTEM PROJECT SUMMARY 2.1 Project Profile 2.1.1. Objectives The objective of Micro Financing is to improve the socioeconomic status of low income people and increase employment by improving their access to financial services through the provision of a revolving line of credit to finance viable farm and off-farm economic activities and thus to provide a solution to the Micro Finance system with the following functions To promote membership among microfinance institutions who provide financial services to the poor for alleviation of poverty. To develop and strengthen systems for information collection, analysis and dissemination through electronic and print media. To develop and deploy an independent performance monitoring system for MFIs that will set standards and increase professionalism in the Microfinance Industry. 2.1.2. High-level Project Scope The high level scope of the project is to integrate the MIFOS application with the IPT300 handheld device to provide a total solution to the MFMS project. 2.1.3. Name of User/Department Integratech Pte Ltd 2.1.4. Project Name The name of the project is “Micro Finance Management System”. 2.1.5. Project Start Date The project officially starts on 30/11/2010. 2.1.6. Project End Date The project officially ends on 10/01/2012 2.1.7. Project Size Medium 2.1.8. Project Effort The Project efforts spent will be approximately 400 - 500 man days 2.1.9. Project Budget This project will be done by ISS students as part of their Master of Technology course. This project is not billable. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 8 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 2.1.10. Estimation Technique Function point counting method and COSTAR effort estimation tool will be used to estimate the size of the project. Refer Appendix A for Functional Point Counting and Appendix B for Coaster Effort Estimation 2.1.11. Project Work Environment The project development will be done basically at ISS. Some of the activities like information gathering, Integration with Mobile Channel and User Acceptance testing will take place in Integratech, Robinson Tower. Computer Hardware and Software: The PC of individual Project member will be used by the project team to undertake all their coding, testing and the frame work needs to be maintained confidential. The ISS facilities will be used for documentation tasks. The following software support is required: Connection to existing Internet Explorer; JDK 1.4 development software package; COSTAR effort estimation tool software package; Microsoft Project; Rational Rose; Access to MySQL data base engine; Microsoft EXCEL spreadsheet package; and Microsoft WORD for WINDOWS word processing package. Java IDE C #.net Microsoft Visual studio 2005 IPT300 Handheld device 2.1.12. Frequency of PMP update The PMP will be updated quarterly and as required in case of any change requests. 2.2 Assumptions and Constraints 2.1.1 Assumptions Team size will be the same throughout the project as in the start of the project. 1. The team assumes that the functionality of the MFMS system is retained with no major functionality or feature change after the sign-off of the Requirements Specification. a. It is assumed that there will be no short supply of MFMS equipment and services from the client. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 9 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM b. Team size will be the same throughout the project as in the start of the project. 2.1.2 Constraints The project must finish by 10th January 2012. Reuse software can be used in project but there must be substantial amount of coding. All the deliverables and documents required by ISS (to fulfill CMMI level 3 requirements) must be provided in related phases and before continuing to next phase. 2.3 Critical Success Factors Following are the critical success factor for this project: Elicit the requirements thoroughly with help of Integratech Follow all the required documentation to fulfill the CMMI level 3 quality requirements. Get Integratech’s support for issues concerning with the IPT300 Handheld device User Acceptance Test to be performed by Integratech team before sign off. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 10 OF 50 INSTITUTE OF SYSTEMS SCIENCE 3. MICRO FINANCE MANAGEMENT SYSTEM PROJECT SCOPE 3.1 In Scope Items 3.1.1 Functional Scope All functional scope will be covered as stated in the User Requirements Specification (URS) document (Ref: INT/MFMS/TS.1) 3.1.2 Non Functional Scope All non functional scope will be covered as stated in URS document, (Ref: INT/MFMS/TS.1) . 3.2 Out of Scope Items All the items not covered in Section 3.1.1 and 3.1.2 and integration with the MFMS will be out of scope. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 11 OF 50 INSTITUTE OF SYSTEMS SCIENCE 4. MICRO FINANCE MANAGEMENT SYSTEM PROJECT APPROACH The development approach used for the MFMS project is Rational Unified Process (RUP). It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of highquality software that meets the needs of its end-users, within a predictable schedule and budget. The RUP approach breaks the software lifecycle into four phases with each phase is concluded with a well-defined milestone (a point in time at which certain critical decisions must be made and therefore key goals must have been achieved). The four phases of RUP approach will be applied to the development of the MFMS with some customization. The development phases are outlined below. 4.1 Inception Phase In this Phase, all the major planning activities take place which includes the following. 4.1.1 Produce Project Plan The project plan holds the vital information about the key stake holders, project backdrop, business needs, the organization structure, staff and effort estimates, project sizing, scheduling, and project approach. It also identifies key deliverables that needs to be produced at the completion of each phase. The Project plan also identifies major risks involved. 4.1.2 Produce Quality Plan The Quality plan defines all the quality related activities which is followed throughout the development cycle so as to ensure that the product is delivered with acceptable standards. The quality plan documents the process involved in conducting reviews, document control, product verification, validation and procedures involved in change control. The acceptance criteria for each deliverable are also defined. The configuration management tells about the document versioning to easily trace back for the changes. 4.1.3 User Requirement Specification User Requirement specification holds all the functional, non-functional, regulatory and statutory requirements of the system to be developed. The key activities that are performed as part of this task are as follows. 4.1.3.1 Interview User The user is interviewed or elicited to obtain the requirements. The technical requirements are gathered from the Project manager. The INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 12 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Project Manager and the Business Analyst are identified to be involved in eliciting customer requirements and producing User requirements specification. In regard to the technical aspects, the Technical Leader will be involved in assisting the Business Analyst. 4.1.3.2 Produce URS The User Requirement Specification (URS) is a sophisticated document which captures all the requirements as stated by the Customer Project manager. The URS covers the functional requirements in simple manner and also conversion of the business needs. Technical Leader in support with PM will produce the URS document. 4.1.3.3 Review URS and User Sign Off Once the document is produced, it is reviewed internally first and then sent to the customer for authorisation. It is the duty of the customer to ensure the correctness of the document. If any requirements are found missing, the document is sent back for further changes. When all parties accepts the document then customer sign-off takes place. All further changes to requirement document are handled in the form of change request. 4.2 Elaboration Phase The main two purposes of Elaboration are: a. Requirements analysis: Determine how functionality (described during requirements capture) will operate. The system is perceived as a black box i.e. we only consider how the system appears from outside (not inside) b. Architecture and Design: Determine how functionality will be implemented. The system is perceived as a white/clear box i.e. we consider the internal structure of the system The following are the major activities that are carried out in this phase. Activity 1: Study the Current System Activity 2: Functional Specification Activity 2: High Level Design Specification 4.2.1 Study the Current System A feasibility study on the Micro Finance Open Source System (MIFOS) is done for the following modules: Savings Module Loan Module Reports INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 13 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 4.2.2 Functional Specification 4.2.2.1 Produce Use Case Model Survey In the Functional specification, all the use-cases are determined. The internal and external actors interacting with the use-cases are also identified. Once the use-case and actors are identified, a global use-case model survey diagram is produced using the Rational Rose software. It is the duty of TL/BA to ensure that all the requirements are captured when producing the Use Case model survey. 4.2.2.2 Identify Domain Objects and Attributes All the business domain objects along with their key attributes are identified. The objects identified must be of high-level and should be captured from the URS. 4.2.2.3 Produce Class/Collaboration Diagram With the identified Domain objects and attributes, a comprehensive class and collaboration diagram is drawn to show the object interactions. Producing Class diagram for each of the identified use-case is optional though it is mandatory to produce one global class diagram representing all the use-cases. Collaboration diagram is produced for each use-case. 4.2.2.4 Write Use Case Realization Report Use-case realization is a sophisticated document, which includes the following the information Use-case Description Actors Involved Flow of events written in Standard English Pre-conditions Post-conditions Exception flows Collaboration Diagram Class Diagram For each case there should be at-least one Use case Realization Report. 4.2.2.5 Review and Finalise Documents Use-case Model Survey, Class, Collaboration diagrams and use-case Realization reports are carefully analyzed and reviewed for its correctness. This is to ensure from defects getting propagated to further phases. The identified defects are sent back to the originator for further corrections. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 14 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 4.2.3 High Level Design Specification 4.2.3.1 Produce Software Architecture Specification The High-level architecture of the current system is defined here. The issues regarding interfaces of various modules are analysed and clarified. 4.2.3.2 Produce Transition Strategy from Analysis to Design A Transition Strategy document will be produced to describe the decision made for moving the analysis deliverables (such as analysis objects and their collaborations) to the platform specific design. The document, where appropriate, will include the description of new objects introduced, changes of dynamic behaviours, changes of static structures and object construction issues. 4.2.3.3 Review and Finalise High Level Design Specification All the High-level documents produced in this stage are finally reviewed and finalized before it can be baseline. All the defects are sent back to the originator for corrective actions. 4.3 Construction Phase The construction phase is concerned with the development and integration of all system components incrementally. Testing is performed thoroughly under this phase for each stage of development. The following will be performed during the Construction Phase: Produce the Detailed Design Specification including sequence diagrams and object specification Produce executable Source Code Update and finalize System Test Plan Perform System Testing Perform Integration Testing Update and finalize User Acceptance Test Plan Development of code and testing happens in this phase. The programmers are involved in producing the code in compliance to the architecture and design. Different types of testing are performed to ensure a quality product is delivered. The following are the major activities that are carried out in this phase. Activity 1: Design Modelling: Low Level Design Specification Activity 2: Test driven Development Activity 3: System testing Activity 4: Integration Testing INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 15 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 4.3.1 Design Modelling: Low Level Design Specification The Low-level design model is the extension to the high-level design produced in the Analysis and Design Phase. The Design model is based on the architecture and transition strategy identified in the previous phase. All the objects identified in the previous stages are structured to the implementation architecture. The attributes and operations are specified in much more detail. All the object interactions are shown using the sequence diagrams. Use-case realization report (Design) for each use case is created containing the collaboration and class diagrams. 4.3.1.1 Review and Finalize Low-Level Design Specification All the Design documents produced are reviewed by the team and corrective actions are taken to ensure the correctness of the Reports. 4.3.2 Test Driven Development The tests are developed based on the design and coding is done in the based on the tests. Coding conventions, standards are all pre-defined and the programmers should ensure that these standards are followed when producing the code. The peer review of the code is done to ensure optimal coding is done and all the standards are followed and all the test scenarios are implemented. All the identified defects identified during the peer review are rectified and required cases are added. The tested code is integrated and sent for system testing. 4.3.3 System Testing The System test plan will be drafted and the testing of the whole system will be done. All the defects are logged and corrective action is taken to ensure all the functionalities are addressed. The MIFOS application will be integrated with Mobile Channel and tested during this phase. 4.3.4 Integration Testing The developed Mobile Channel module will be integrated with MIFOS application. The integrated modules are tested in the client site by Project Lead and QM, who are assisted by software engineers for corrective action. The final test report is produced and is reviewed by the PM. 4.4 Transition Phase The primary objective for this phase is to 'transition' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The product is also checked against the quality level set in the Inception phase. If all objectives are met, the Product Release Milestone is reached and the development cycle ends. An End of Project Report will be produced at this stage. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 16 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 4.4.1 Documentation The following are the documentation that will be undertaken. 4.4.1.1 Produce User Guide User-guide is a sophisticated manual which helps the user to gain understanding over the system. The user-guide contains all the screen shots and navigation flows to complete the transactions. The user-guide remains as a reference to the user at all time after the development of new system. This is prepared by software developer and it is reviewed by Business Analyst/Technical Leader. 4.4.2 User Acceptance Test Once the system is deployed at the customer site, it undergoes random checks mainly concentrating on the core functionalities by the User and Software engineer would assist them. In case of any corrective action it is performed by the software engineer at the client site. Once the test passed the acceptance criteria, acceptance sign-off takes place. The bugs detected are sent back for corrective actions. The final sign off is performed on conforming all the requirements stated in the URS are fulfilled. 4.4.3 Project Closure The purpose of this activity is to produce an end-of-project report that summarizes significant events in the course of the project and lessons learnt. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 17 OF 50 INSTITUTE OF SYSTEMS SCIENCE 5. MICRO FINANCE MANAGEMENT SYSTEM WORK PLAN The following work program has been identified to complete the development of the system according to the approach described in Section 4. Activity 1: Requirements Analysis Activity 2: Study of the Current System Activity 3: Analysis Modelling Activity 4: High Level Design Specification Activity 5: Detailed Design Specification Activity 6: Application Development Activity 7: Testing Activity 8: Documentation Activity 9: User Acceptance Activity 10: Quality Assurance and Progress Management Activities 1 through 9 contain the technical activities required to produce the system. Activity 10 provides the supporting management and administrative activities. The work to be performed in each activity is described in the following subsections. 5.1 Requirement Analysis After the business and technical meeting, a high level user requirement specification will be produced for the Client to verify the user requirements. 5.2 Study of the Current System As mentioned in Section 4.2.1, during the study the defects in the current system are identified and escalated to client to avoid defect multiplication in later stages. Any ambiguities with the current system or on the tool are clarified with the client during this stage. 5.3 Analysis This activity covers the analysis tasks to include the analysis objects definition and interaction between them in the forms of diagrams and detailed description. The breakdown of tasks is as follows: 5.3.1 Domain Object Modelling A conceptual model of a system which describes the various entities involved in that system and their relationships. Entities can become classes, while methods and attributes can be carried directly to the source code; the same names typically appear in the source code. In UML, a class diagram is used to represent the domain model. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 18 OF 50 INSTITUTE OF SYSTEMS SCIENCE 5.3.2 MICRO FINANCE MANAGEMENT SYSTEM Use Case Realisation Report (Analysis) A Use Case Realisation Report (Analysis) will be produced for each identified use case. The document will include the identification of the analysis objects, collaborations between them, descriptions for the collaborations, and static views between them. 5.3.3 Prototype Study Report The Prototype Study Report will be produced to assess the feasibility of the project based on the requirements and the technology to be used. 5.4 High Level Design Specification This activity covers the tasks needed to produce the High Level Design Specification documents. The breakdown of tasks is as follows: 5.4.1 Software Architecture Specification A Software Architecture document will be produced to describe the hardware and software platform for deployment. Consideration of architecture selection includes layering and distribution. 5.4.2 Transition Strategy from Analysis to Design A Transition Strategy document will be produced to describe the decision made for moving the analysis deliverables (such as analysis objects and their collaborations) to the platform specific design. The document, where appropriate, will include the description of new objects introduced, changes of dynamic behaviours, changes of static structures and object construction issues. 5.4.3 Database Design A Database Design document will be produced to incorporate all of the identified entities. The document should contain the definition of the database table names, column field names, their data types and sizes in a platform independent format. In the physical database, it should also contain the definition of the constraints such as primary keys, foreign keys, and indexes specified for the target database platform. 5.5 Detailed Design Specification This activity covers the tasks needed to produce the Detailed Design Specification documents. The breakdown of tasks is as follows: INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 19 OF 50 INSTITUTE OF SYSTEMS SCIENCE 5.5.1 MICRO FINANCE MANAGEMENT SYSTEM Design Model Report A standard RUP Design Model Report will be produced to include the sequence diagrams illustrating the interactions for each use case and the object specification for each participating design objects. The identified design objects should be structured in an implementation-friendly way. 5.6 Application Development This activity covers the tasks needed for translation of the requirements specified in the User Requirements Specification, Prototyping and Detailed Design Specification documents to application code. The breakdown of tasks is as follows: 5.6.1 Create Database Tables and Fields This task will create the physical database tables and columns. 5.6.2 Produce Source Code The source code will be produced using the selected programming language. It is important to ensure that coding standards specified in the project’s quality plan are applied to ensure consistency and quality of the software produced. 5.7 Testing This activity is performed to ensure the quality control is applied. Test Plan will be produced before actual testing. Corrective actions will be implemented for faults that are revealed during tests. Tests will be re-run after corrective fixes are applied to the software as a form of patch verification. The breakdown of tasks is as follows: 5.7.1 System Test Plan A System Test Plan will be produced to specify the approach and test cases necessary to ensure that all software features or/and functions are verified to comply with the requirements defined in the URS. 5.7.2 Integration Test Plan An Integration Test Plan will be produced to specify the approach and test cases necessary to ensure that all software features or/and functions are verified to comply with the requirements defined in the URS. 5.7.3 Perform Testing System testing and Integration testing will be performed according to the steps stated in the Test Plan and Test Reports will be produced for the performed tests. 5.8 Documentation This task will create the MFMS User Guide. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 20 OF 50 INSTITUTE OF SYSTEMS SCIENCE 5.9 MICRO FINANCE MANAGEMENT SYSTEM User Acceptance This activity includes tasks taken to ensure the final deliverables to the project sponsor are accepted and signed-off. The breakdown of tasks is as follows: 5.9.1 User Acceptance Test Plan A User Acceptance Test Plan will be produced that states the agreed strategy for performing the acceptance tests with the sponsor. The items included in the Acceptance Test Plan should be traceable to the requirements specified in the URS. 5.9.2 User Environment This task will install and setup the system in the sponsor environment before the actual Acceptance Test is conducted. A test run by the installer should be performed to ensure the installation is successful. 5.9.3 Perform User Acceptance Test The User Acceptance Test will be performed on the installed UAT environment and results are documented for review. 5.10 Quality Assurance and Progress Management This activity includes the tasks necessary to support the periodic review of quality aspects of the project against the processes contained within the Quality Plan throughout the project lifecycle. The breakdown of tasks is as follows: 5.10.1 Progress Report Progress reports will be produced every month. The format and location of such reports are documented in the Quality Plan. (Ref: INT/MFMS/MQ.1). 5.10.2 Action List Sheet An Action List sheet is maintained to specifically capture the action items of every meeting that is usually held at least on a weekly basis. Every action item has an owner and a target date. The list shall be used to monitor if tasked are done or are still outstanding. The format and location of such sheet is documented in the Quality Plan. (Ref: INT/MFMS/MQ.1). 5.10.3 Project Report This report is intended for the project assessors and will be done at the end of the project lifecycle. This report shall evaluate the project’s performance, and document any recommendations to finally close the project. 5.10.4 First Quality Audit The team will be expected to attend an audit meeting at which they will be expected to provide evidence that they are following the provisions of their INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 21 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Quality Plan. An audit checklist is provided by ISS and project team is expected to prepare minutes for this meeting. 5.10.5 First Project Presentation The aim of the presentation is to allow ISS advisors to give overall management and technical assessment of the project. The presentation should last approximately 30 minutes, followed by up to 15 minutes for question and answer. Presentation assessment guidelines are provided by ISS. The presentation should include: project background; overview of user requirements; project risks and technical challenges; plans (estimates etc) and strategies; progress report. 5.10.6 Second Quality Audit The team will be expected to attend an audit meeting at which they will be expected to provide evidence that they are following the provisions of their Quality Plan. An audit checklist is provided by ISS and project team is expected to prepare minutes for this meeting. It is important to note that the project team will be required to demonstrate that they have carried out all required actions from the First Quality Audit. 5.10.7 Second Project Presentation The aim of the presentation is to allow ISS advisors to give overall management and technical assessment of the project. The presentation should last approximately 30 minutes, followed by up to 15 minutes for question and answer. Presentation assessment guidelines are provided by ISS. The presentation should include: software architecture; transition from analysis to design; implementation issues; progress report against the plans (planned versus actual). 5.10.8 Third Quality Audit The team will be expected to attend an audit meeting at which they will be expected to provide evidence that they are following the provisions of their Quality Plan. An audit checklist is provided by ISS. It is important to note that the project team will be required to demonstrate that they have carried out all required actions from the Second Quality Audit. 5.10.9 Third Project Presentation The aim of the presentation is to allow ISS advisors to give overall management and technical assessment of the project. The presentation should last approximately 30 minutes, followed by up to 15 minutes for question and answer. Presentation assessment guidelines are provided by ISS. This is the final presentation and should report on the whole project. It should include: overview of background and requirements; summary development strategy INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 22 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM and technical issues; brief demonstration (if possible); report on the overall project progress (planned versus actual); recommendations for further work; lessons learnt by the project team. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 23 OF 50 INSTITUTE OF SYSTEMS SCIENCE 6. MICRO FINANCE MANAGEMENT SYSTEM STAFF EFFORT ESTIMATES Estimates of the staff effort required to undertake the activities described in Section 3 are given in Section 4.1. 6.1 Staff Effort Estimates and Progress INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 24 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM The total combined effort from Staff Effort Estimates table is calculated as 515 man-days. Thus, estimated man-days for each team member will be about 74 man-days (515 / 7). INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 25 OF 50 INSTITUTE OF SYSTEMS SCIENCE 7. MICRO FINANCE MANAGEMENT SYSTEM PROJECT MILESTONES & DELIVERABLES 7.1 Project Deliverables INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 26 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 7.2 Project Milestones 7.3 Project Schedule with planned dates of activities The Gann Chart schedule of the project is specified in the Appendix D. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 27 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 8. PROJECT ORGANISATION 8.1 Project Structure Client Project Manager Project Manager (ISS) Technical Lead 8.2 Business Analyst Database Administrator Quality Manager System Architect Software Engineer Project Governance Integratech is the user who wanted this system to be developed. Project Management team comprising of the Client Project Manager and the Project Manager of SE18E2 are involved in planning, monitoring and managing the project team and project activities in order to ensure the implementation / changes are running according to the plan and be able to achieve the project objective. Project team members are to perform the tasks according to the project schedule and as assigned by the Project Manager in order to deliver the desired deliverables by following the applicable IT best practices adopted by the project. INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 28 OF 50 INSTITUTE OF SYSTEMS SCIENCE 8.3 MICRO FINANCE MANAGEMENT SYSTEM Roles and Responsibilities & Resource Plan INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 29 OF 50 INSTITUTE OF SYSTEMS SCIENCE 9. MICRO FINANCE MANAGEMENT SYSTEM PROJECT MONITORING AND CONTROL PLAN 9.1 Tolerance and Exceptional Management Monthly progress reporting will be done stating all the issues or risks in project if there is any and stating project status in terms of schedule and effort. Team will plan to handle major risk in each phase. Any changes in the project scope will be managed by change control board. 9.2 Escalation Path Refer to Section 8.1 Project Structure to follow the escalation path. 9.3 Communication Plan 9.3.1 Communication and Progress Reporting Plan Stream/ Level Team Level Overall project Activities Frequency Responsibility Status Check Weekly Status check, Issue & risk Monitoring Monthly Technical Leader Project Manager INT/MFMS/MP.2/V1.4 Stakeholders Involvement Team Members ISS/ Integratech PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED Method of Communication Weekly meetings Progress Report PAGE 30 OF 50 INSTITUTE OF SYSTEMS SCIENCE 10. MICRO FINANCE MANAGEMENT SYSTEM RISK AND ISSUE MANAGEMENT 10.1 Key Project Risks The following risks are identified as potential risks and are addressed in Appendix C Possibility of Change request Installation/Customisation of MIFOS Application Integration with Mobile Channel Team skill set Development on the Hardware IPT300 Sponsor support UI Design 10.2 Problem Resolution Process Problems, if any, will first be highlighted in monthly progress reports. Any known issue will be highlighted in the weekly team meetings and the team will try to resolve it internally. Risk will be prioritized based on severity. For any risks and issues that require escalation, refer to Section 8.1 Project Structure for the escalation path. The risk scoring table and the risk assessment questionnaire can be referred in Appendix C INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 31 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM 11. GLOSSARY OF TERMS INT/MFMS/MP.2/V1.4 S/N 1 2 3 Acronyms PM QM UCMS 4 UAT 5 MIFOS Full Name Project Manager Quality Manager Use Case Model Survey User Acceptance Testing Micro Finance Open Source PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 32 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM APPENDIX A – FUNCTIONAL POINT COUNTING Data Functions : Mobile Application Layer INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 33 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Data Functions: Branch Office Support system Synchronization between Mobile Channel to Branch Office System INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 34 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 35 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Transactional Functions: Mobile Application Layer INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 36 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 37 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 38 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 39 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Transactional Functions: Branch Office Support system Synchronization between Mobile Channel to Branch Office System INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 40 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 41 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM Unadjusted Function Point Count Summary Determine Total Degree of Influence Total Unadjusted FPC = 157 Adjustment Factor = 0.65 + (0.01 * Total Degree of Influence) Adjustment factor = 0.65 + (0.01*43) = 1.08 Adjusted FPC = Unadjusted FPC * Adjustment factor Adjusted FPC = 157 * 1.08 = 170 INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 42 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM APPENDIX B – COSTAR EFFORT ESTIMATION INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 43 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 44 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 45 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM APPENDIX C – RISK MANAGEMENT PLAN The following section describes the identification and analysis of risks with preventive and corrective actions planned for the MFMS project. Risk Scoring Table Risk Impact Risk Assessment questionnaire for MFMS Project (0-5, 0-no risk, 5-max risk) INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 46 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 47 OF 50 INSTITUTE OF SYSTEMS SCIENCE MICRO FINANCE MANAGEMENT SYSTEM APPENDIX D – GANTT CHART INT/MFMS/MP.2/V1.4 PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 48 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 49 OF 50 INSTITUTE OF SYSTEMS SCIENCE INT/MFMS/MP.2/V1.4 MICRO FINANCE MANAGEMENT SYSTEM PROJECT PLAN © 2011 ISS. ALL RIGHTS RESERVED PAGE 50 OF 50