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