Software Development Plan

Idev (Pvt) Ltd
Miracle Worker
Microfinance Software System
Version 1.0
Miracle Worker Version: 1.0
Microfinance Software System Date:
Software Project Plan
Revision History
Date Version Description Author
28/08/18 v 1.0 “Onboarding” process is recorded. Aurangzeb and Mughees
06/9/18 v 2.0 Reconciliation after group sessions at Noor

Kashf. “Recovery” “Dashboard”
“BM” modules added
Confidential idev, 2018 Page 2 of 26

Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms, and Abbreviations 4
1.4 References 4
1.5 Overview 4
2. Project Overview 5
2.1 Project Purpose, Scope, and Objectives 5
2.2 Assumptions and Constraints 5
2.2.1 Assumptions 5
2.2.2 Constraints 5
2.3 Project Deliverables 6
2.4 Evolution of the Software Development Plan 6
3. Project Organization/Stockholders 6
3.1 Organizational Structure 6
3.2 External Interfaces 7
3.3 Roles and Responsibilities 7
4. Management Process 9
4.1 Project Estimates 9
4.1.1 Cost Estimation 9
4.2 Project Plan 9
4.2.1 Phase Plan 10
4.2.2 Project Resourcing 10
4.3 Project Monitoring and Control 11
4.3.1 Dashboard 11
4.3.2 On Boarding Process 11
4.3.3 Disbursement 11
4.3.4 recovery 12
4.3.5 Reports 12
4.3.6 User Management 13
5. Annexes 16
5.1 Design of the Application 16
5.2 MS Project – Project Schedule 19
5.3 Reports 24

Software Development Plan (Small Project)
1. Introduction
This document provides the Software Project Management Plan of Miracle Worker project, which is about
providing the Microfinance Software System.
PS Software Requirement Specification report is prepared according to IEEE Std. 830-1998, IEEE
Recommended Practice for Software Project Management Plan. This document includes the information such
as purpose, scope, constraints and assumptions of the project. In addition to this information, managerial,
technical and supporting process plans will be also existing in this document.
1.1 Purpose
The purpose of the Software Development Plan is to gather all information necessary to control the project.
It describes the approach to the development of the software and is the top-level plan generated and used by
managers to direct the development effort.
The following people use the Software Development Plan:
 The project manager uses it to plan the project schedule and resource needs, and to track
progress against the schedule.
 Project team members use it to understand what they need to do, when they need to do it, and
what other activities they are dependent upon.
1.2 Scope
This Software Development Plan describes the overall plan to be used by the <project name> project,
including deployment of the product. The details of the individual iterations will be described in the
Iteration Plans.
The plans as outlined in this document are based upon the product requirements as defined in the Vision
Document.
1.3 Definitions, Acronyms, and Abbreviations
On Boarding Process: This is the first process of loan creation application for client
Disbursement: this process is involved in approval of loan application and generation of
installment.
1.4 References
Functional Specification Document (V 2.5)
1.5 Overview
This Software Development Plan contains the following information:
Project Overview — provides a description of the project's purpose, scope, and objectives. It also defines
the deliverables that the project is expected to deliver.
Project Organization — describes the organizational structure of the project team.
Management Process — explains the estimated cost and schedule, defines the major phases and milestones
for the project, and describes how the project will be monitored.

Applicable Plans and Guidelines — provides an overview of the software development process, including
methods, tools and techniques to be followed.
2. Project Overview
2.1 Project Purpose, Scope, and Objectives
This Software Development Plan describes the overall plan to be used by the Miracle Worker project,
including deployment of the product. The details of the individual iterations will be described in the Iteration
Plans.
The Microfinance Bank Software System is web base solution for the microfinance banking. To automate
the procedures by using technology to save time and cost and also increase the effectiveness of the
procedures. This system has two parts. First approach is to build a web base application that will be used in
the all branches with Windows operating system and access to a TCP/IP network via ethernet or wireless
network. Second aproch is to provide a andriod based application for the tablet to the teams that works in
remot areas.
Objectives of this project is to provied the sloution for the following process
 (Schyns and Schilling 2013)To provide On Boarding Process
 Disbursement Process
 Recovery Process
 Post disbursement Loan Utilization Check
 Client FeedBack
 Reports
 Expense Management
 Admin Process
2.2 Assumptions and Constraints

2.2.1 Assumptions
This system will be used by K foundation in all branches and remotely.
All the required Servers and tablets will be provided by K Foundation.
This System Will be used by:
Branch Manger
Branch Staff
Fields Teams
2.2.2 Constraints
This project will be developed by idev solutions. all the information related to this project and requirements
of project is confidential and every stockholder of this project is to sign an affidavit in this regards.
The budged document is also confidential and will be not be disclosed except CEO.

2.3 Project Deliverables

 Initial Plan
 Software Requirements Specification
 Software Design Document
 Starting the Coding
 Finishing the Coding
 Demonstration of Product
 User Manual
Deliverables for each project phase are identified in the Development Case. Deliverables are delivered
towards the end of the iteration, as specified in section 4.2.4 Project Schedule.
2.4 Evolution of the Software Development Plan
The Software Development Plan will be revised prior to the start of each Iteration phase.
3. Project Organization/Stockholders
3.1 Organizational Structure
All the responsibilities will be shared by all of the members of this project. The main parts of the
organization are Software System Engineering, Software Configuration Management, Software Quality
Assurance, Coding and Training. The Internal Structure of the project is given
Project Management
Software Training Software Software

System Configuration Quality
Management Assurance
Software
Requirements Testin Design Content Version
Enginering g Engineering Management Control
Analysis Architectural
Concept Design
Requirement Interface
Elicitation Design
Requirement Content
s Design

3.2 External Interfaces

End User: user of the application (Branch Staff and Field Staff)
Project Group: The K Foundation Management
Subcontractor: Software Engineering, Coordinator
End User
Project Group
Subcontractor
3.3 Roles and Responsibilities
Person Rational Unified Process Role
Project Manager
Mughees
Noor Ali Software System Engineer
Aurangzeb DB Administrator, Configuration Manager
Abu baker Saeed
Amir
Software Engineer, Programmer
Ghulam Abbas
Ahmed Frooq
Abu baker Afzal

User Interface Designer.
Zunair

Maryam
Test Team Member
Yousaf
Software Engineer: will plan, analyze and design the software project during preparing the documentations
of project.
Programmer: will write the code of the system.
Test Team Member: will test the system to augment the quality.
Training Coordinator: will prepare the stuff-training plan to ensure that necessary skill levels in sufficient
numbers will be available to successfully conduct the software project.
DB Administrator: will be responsible from database configuration and management.
Software System Engineer: will help the project team to identify, control, and track requirements and changes
to requirements at any time as the project proceeds and make the architectural design of the project
accordingly.
Project Manager: will plan (schedule, cost and budget), motivate, organize and control the software team.
User interface designer: will design the web-based user interfaces.

Configuration Manager: will manage different versions of the work products, control the changes that are
imposed and audit and report on the changes that are made. And also will update the project’s web page
regularly.
4. Management Process
4.1 Project Estimates
4.1.1 Cost Estimation
The hourly salary of each group member is 489, therefore the estimated cost of the
Project is:
Cost = Effort x $ (the hourly salary)
C = 5400 man-hours x 489/man-hours
C = 2,640,600
4.2 Project Plan

Deliverables Due Date
Initial Plan Aug 3,2018
Software Requirements Specification

Aug 10,2018
Software Design Document

Aug 17,2018
Starting the Coding

Aug 21,2018
Finishing the Coding Sep 28,2018
Demonstration of Product
Sep 29,2018
User Manual
Sep 29,2018
Trainings Oct 5,2018
Delivery of Final Product Sep 29,2018

4.2.1 Phase Plan

WBS No: Task Name: Milestone
1. PS Project
1.1 Problem Analysis
1.2 Meeting with the Customer
1.3 Determining the Problems
2 Software Requirement Specification
2.1 Determining actors and use cases
2.2 Detailing use cases
2.3 Documenting SRS
2.4 Discussion about issues of SRS
2.5 Delivery of the first version of SRS *Milestone
2.6 Feedback of SRS
2.7 Delivery of updated SRS *Milestone
3 Software Design Description
3.1 Studying about IEEE std 1016
3.2 Determining Design Entities
3.3 Determining Design Entity Attributes
3.4 Drawing Design Views
3.5 Documenting SDD
3.6 Discussion about issues of SDD
3.7 Delivery of the first version of SDD *Milestone
3.8 Feedback of SDD
3.9 Delivery of updated SDD *Milestone
4 Coding
4.1 Determining the Coding Standard
4.2 Coding of General Interfaces
4.3 Coding of Infrastructure of Project
4.4 Code Review of General Interfaces
4.5 Testing of Code side of Product
4.6 Meeting with Customer about the Product
4.7 Update and Delivery of Product *Milestone
5 User Manual
5.2 Determining Cases for UM
5.3 Documenting UM
5.4 Discussion about issues of UM
5.4 Delivery of the first version of UM *Milestone
4.2.2 Project Resourcing

Group members have the general information about design techniques of Java Frameworks(Spring Boot),

Micro-service Architecture, New JS Frameworks ( Angular) etc. PCs will be used for documentations of the
reports that are IP, SRS, SPMP and SDD and coding. Table shows software tools to be used by project phase.
Personnel allocation for each WBS item is given in Resource Allocation Appendix.
WBS WBS Item SOFTWARE RESOURCES

No
1.2 Initial Plan MS Word, MS Project, MS Visio, Photoshop
1.3 Software Requirement Specification MS Word, MS Visio
1.4 Software Project Management Plan MS Word, MS Project, MS Visio
1.5 Software Design Description MS Word, MS Visio, Photoshop
1.6 Coding Eclipse IDE, Oracle DB, Java , Spring Boot,
Spring JPA, Angular 6, VS Code. Tomcate Server.
1.7 User Manual MS Word
Resource Allocation
4.3 Project Monitoring and Control

Requirements Management
The requirements for this system are captured in the Vision document. Requested changes to requirements
are captured in Change Requests, and are approved as part of the Configuration Management process.
4.3.1 Dashboard
After Logging in, the BDO lands on the Home page(Dashboard from here on). The purpose of a dashboard
is to provide real-time results by aggregating and extracting value from all the data collected, otherwise
known as your key performance indicators (KPIs). It simplifies data into more manageable chunks of visual
information that allows the user to see what they are doing right and where they need to improve. When
utilized properly, dashboards can help you make informed decisions that can dramatically impact business
performance.
The dashboard for the new generation Miracle Worker will consist of three important compartments:
Targets and feedback
Tasks
Filters
4.3.2 On Boarding Process
This is the first process of loan creation application for client in Kashf foundation which is named
as “On Boarding”. It’s a screening practice of a client. In this process concerned personnel monitor
the client keenly by following and implementing Kashf’s well-defined criteria. This method often
takes place at the client’s house.
Registration completion is the core function for this whole process. A client ID is generated
against every CNIC registration and consists of 12 digits.
4.3.3 Disbursement
Disbursement is the second core process performed by Kashf. This process happens after the first process
(onboarding) has been duly completed and the client’s Loan Application has been accepted by the Branch
Manager. The disbursement procedure involves generating and exporting the following significant
documents:

Print LABAF
Print Undertaking
Print Payment Schedule
Print Health Card (if applicable)
In this progress the concern person takes indulges acknowledgements from the clients on some important
and confidential sheets. The client needs to be physically present in their designated KASHF branch. BM
provides passbook and LRS documents to the client. After being presented the passbook, the client can take
loan from the nearest authorized bank. (Thereby considering handing out the passbook as the point of
disbursement)
It is important to note that if no action is taken on the Loan Application and is not disbursed within 30 days
of creation, the Application will be marked as “expired.”
4.3.4 recovery
The recovery screen auto populates as recoveries are coming in real time from various ADCs.
A late payment penalty % will be decided by Kashf for each product and needs to be entered in the
Setup.
This percentage will be applied to the Outstanding Principal Amount linked to the Installment ID.
4.3.5 Reports
Following reports were marked as required based on the team feedback
Due Recovery Sheet
Pending [Exit] Clients by BDO
Murabaha Agency Info Sheet
Validation Report posted data
Projected Clients Loan Completion Report
Women Participation
Bank Book Detail
Funds Statement
Insurance Claim Report
Loan Repayment Schedule
Overdue Loans by Clients New/Old Portfolio
Portfolio Monitoring Report
Tagged Overdue Clients Detail
Recovery Trend Analysis Report
Portfolio Concentration
Rate of Retention/Rate of renewal
Branch Turnover Analysis(TAT) Needs to be revised
Insurance Claim Form
Cash Deposit Slip
Client Health Beneficiaries Report(JLI)
TAT/Woman participation/Disb Analysis - Merged with KPI report
HR Area office Report
KCRs- for all Cash Vouchers

4.3.6 User Management

This module allows the user to assign and manage rights of different roles and users.
The user will select one of the roles and assign it ‘Read(R), Write(W), and Delete(Del) rights’ for each
function(module). The function eg Onboarding or Disbursement can be added by clicking the ‘Add’ button.
Schedule and Budget Control
Expenses are monitored by the project manager, and reported and assessed monthly
The project manager maintains a schedule showing the expected date of each milestone. The line items in
the schedule include work packages assigned to individuals. Each individual who is assigned a work
package provides %completion information to the project manager on a weekly basis. Changes in the
schedule will be escalated to the project sponsors, who will then decide whether to alter scope in order to
preserve target completion dates.
Quality Control
Defects will be recorded and tracked as Change Requests, and defect metrics will be gathered (see
Reporting and Measurement below).
All deliverables are required to go through the appropriate review process, as described in the
Development Case. The review is required to ensure that each deliverable is of acceptable quality, using
guidelines described in the RUP for Small Projects review guidelines and checklists.
Any defects found during review which are not corrected prior to releasing for integration must be captured
as Change Requests so that they are not forgotten.
Reporting and Measurement
Updated cost and schedule estimates, and metrics summary reports, will be generated at the end of each
iteration.
The Minimal Set of Metrics, as described in the RUP Guidelines: Metrics, will be gathered on a weekly
basis. These include:
Earned value for completed tasks. This is used to re-estimate the schedule and budget for the remainder of
the project, and/or to identify need for scope changes.
Total defects open and closed – shown as a trend graph. This is used to help estimate the effort remaining
to correct defects.
Acceptance test cases passing – shown as a trend graph. This is used to demonstrate progress to
stakeholders.
In addition, overall costs will be monitored against the project budget.
Risk Management
Risks will be identified in Inception Phase using the steps identified in the RUP for Small Projects activity
“Identify and Assess Risks”. Project risk is evaluated at least once per iteration and documented in this
table. The risks of the greatest magnitude are listed first in the table.
Risks Category Probability Impact

(%)
Uncertainty in the format of PS Process definition 90 Moderate
file
Development tool unfamiliar Staff experience 70 High
Not enough time for SW Business impact 87 Moderate
integration

Staff inexperienced Staff 72 High

Absentees of personnel could Staff 75 High
result in loss of effort
Design and coding deficiencies. Process definitions 70 High
Expected technical changes Development environment 40 Moderate
Documentation Process definition 30 Moderate
May have to train the trainer Staff 55 Low
Incorrect and missing Work Process definition 45 High
package definition
Optimistic schedule for HW/SW Business impact 25 Low
integration
Less reuse than planned Product size 25 Moderate
Customer may change Product size 20 Critical
requirement
Misunderstood and/or Product size 20 Critical
undetermined requirements
Process demands not adequately Product size 15 High
planned in estimates
Inappropriate metrics Product size 18 Moderate
List of Identical Risks
Probability Uncertainty Statement Evaluation

>80% Almost, certainly, highly, likely 5
61 – 80% Probable, likely, probably, we 4

believe
41 – 60% We doubt, improbable, better 3
than even
21 – 40% Unlikely, probably not 2
1 – 20% Highly, unlikely, changes are 1
slight
Probability Evaluation Criteria
Criterion Cost Schedule Technical

Low Less than 2% Slip 1 day Slight effect on
performance

Moderate Less than 4% Slip 2 days Moderate effect on

performance
High Less than 7% Slip 5 days Severe effect on
performance
Critical 7% or more Slip over 5 days Mission cannot be
accomplished
Consequence Evaluation Criteria
PRIORITY Risk Scenarios Risk Alternatives / Resolutions Monitoring

Environment: not suitable for Alternatives: Choose a work During the group meetings.
team communication. environment that allows team
1 communication.
Resolution: Optimizing the
environment situation.
Group deficiency: One of the Resolution: Other group members are Dead line is very close.
1 members is sick. over work.
Communication skill is not Alternatives: Group will make a Middle of the coding
4 enough: In the code phase, meeting with customers. phase.
the new requirements will be
come.
The development tool is hard Alternatives: If project member is not During the implementation
to use. enough knowledge about development phase.
tool, they will take a related info from
project training coordinator.
2 Resolution: Before implementation
team will make mini projects with
development tool.
Risk Management
Configuration Management
Appropriate tools will be selected which provide a database of Change Requests and a controlled versioned
repository of project artifacts.
All source code, test scripts, and data files are included in baselines. Documentation related to the source
code is also included in the baseline, such as design documentation. All customer deliverable artifacts are
included in the final baseline of the iteration, including executables.
The Change Requests are reviewed and approved by one member of the project, the Change Control
Manager role.
Full backups are performed monthly and incremental are performed nightly.

5. Annexes
5.1 Design of the Application



5.2 MS Project – Project Schedule





5.3 Reports



Software Development Plan

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Development Plan

Uploaded by

Copyright:

Available Formats

Idev (Pvt) Ltd

06/9/18 v 2.0 Reconciliation after group sessions at Noor

Confidential idev, 2018 Page 2 of 26

Confidential idev, 2018 Page 3 of 26

Software Development Plan (Small Project)

Confidential idev, 2018 Page 4 of 26

2.2 Assumptions and Constraints

Confidential idev, 2018 Page 5 of 26

2.3 Project Deliverables

Software Training Software Software

Confidential idev, 2018 Page 6 of 26

3.2 External Interfaces

Project Group: The K Foundation Management

Subcontractor: Software Engineering, Coordinator

3.3 Roles and Responsibilities

Person Rational Unified Process Role

Abu baker Afzal

Confidential idev, 2018 Page 7 of 26

Programmer: will write the code of the system.

DB Administrator: will be responsible from database configuration and management.

User interface designer: will design the web-based user interfaces.

Confidential idev, 2018 Page 8 of 26

4.2 Project Plan

Initial Plan Aug 3,2018

Software Requirements Specification

Software Design Document

Starting the Coding

Finishing the Coding Sep 28,2018

Trainings Oct 5,2018

Delivery of Final Product Sep 29,2018

Confidential idev, 2018 Page 9 of 26

4.2.1 Phase Plan

4.2.2 Project Resourcing

Confidential idev, 2018 Page 10 of 26

WBS WBS Item SOFTWARE RESOURCES

4.3 Project Monitoring and Control

Confidential idev, 2018 Page 11 of 26

Confidential idev, 2018 Page 12 of 26

4.3.6 User Management

Risks Category Probability Impact

Confidential idev, 2018 Page 13 of 26

Staff inexperienced Staff 72 High

Probability Uncertainty Statement Evaluation

61 – 80% Probable, likely, probably, we 4

Probability Evaluation Criteria

Criterion Cost Schedule Technical

Confidential idev, 2018 Page 14 of 26

Moderate Less than 4% Slip 2 days Moderate effect on

Consequence Evaluation Criteria

PRIORITY Risk Scenarios Risk Alternatives / Resolutions Monitoring

Confidential idev, 2018 Page 15 of 26

5.1 Design of the Application

Confidential idev, 2018 Page 16 of 26

Confidential idev, 2018 Page 17 of 26

Confidential idev, 2018 Page 18 of 26

5.2 MS Project – Project Schedule

Confidential idev, 2018 Page 19 of 26

Confidential idev, 2018 Page 20 of 26

Confidential idev, 2018 Page 21 of 26

Confidential idev, 2018 Page 22 of 26

Confidential idev, 2018 Page 23 of 26

Confidential idev, 2018 Page 24 of 26

Confidential idev, 2018 Page 25 of 26

Confidential idev, 2018 Page 26 of 26