Software Project Management Plan

AIUB IT Solutions Inc.

2012 © Mazharul, Istiak, Abir & Rafi Page 1 of 15

Software Project Management Plan (SPMP)

for Automated Ticket Issuing System for

Bangladesh Road Transport Corporation

(BRTC)

:: Title Page ::

NAME ID

HAQUE, MAZHARUL 10-16377-1

AHMED, ISTIAK 10-16025-1

AHMED, ABIR 10-16234-1

RAFI, HASIB ADNAN ARR 08-11361-2

JUNE 18, 2012

Revision History

Revision Date Authors Description

Version

0.0.1

June 12, 2012

HAQUE, MAZHARUL AHMED, ABIR

RAFI, HASIB ADNAN ARR AHMED, ISTIAK

First Version



Table of Contents

SOFTWARE PROJECT MANAGEMENT PLAN (SPMP) FOR AUTOMATED TICKET

ISSUING SYSTEM FOR BANGLADESH ROAD TRANSPORT CORPORATION (BRTC) ...... 1

TITLE PAGE ..................................................................................................................................................... 1

REVISION HISTORY ....................................................................................................................................................... 1

INTRODUCTION ........................................................................................................................................................... 3

PROCESS MODEL ......................................................................................................................................................... 3

SOFTWARE MODEL ................................................................................................................................................... 3

BECAUSE OF THIS ..................................................................................................................................................... 3

SOFTWARE LIFE CYCLE FLOW CHART .................................................................................................................... 4

QUALITY GATES FOR EACH PHASE OF SW DEVELOPMENT ........................................................................................................ 4

LIST OF TASKS ............................................................................................................................................................ 5

ESTIMATION FOR EACH TASK .......................................................................................................................................... 5

SCHEDULE THE TASKS .................................................................................................................................................. 6

PREPARE LIST OF MILESTONE .......................................................................................................................................... 7

STAFFING PLAN ........................................................................................................................................................... 7

ROLE REQUIREMENTS .............................................................................................................................................. 7

STAFF ASSIGNED TO ROLES ................................................................................................................................... 8

STAFF RESOURCE LOADING CHART ........................................................................................................................ 8

MONITORING & CONTROLLING MECHANISM ......................................................................................................................... 9

COMMUNICATION AND REPORTING PLAN .................................................................................................................. 9

RISK MANAGEMENT ...................................................................................................................................................... 9

LIST OF DELIVERS ...................................................................................................................................................... 10

SCHEDULE TRACKING PROCESS ..................................................................................................................................... 12

TEAM LEADER MEETINGS ....................................................................................................................................... 12

DEFECT TRACKING PROCESS ......................................................................................................................................... 13

METRICS ................................................................................................................................................................. 14

POSTMORTEM ........................................................................................................................................................... 15



Introduction This document addresses the requirements for automated system of bus-ticket vending machine for

Bangladesh Road Transport Corporation (BRTC). The intended audience for this document is the

designers and the BRTCs of the project. It is the controlling document for this project. It specifies the

technical and managerial approaches to develop the software product. As such it is the companion

document to Requirements Analysis Document (RAD). Changes in either may imply changes in the other

document. All technical and managerial activities required to turn over the deliverables to the BRTC are

included. This includes scheduling, identification of tasks, and factors that may impact the project and

planning

Process Model

Software Model

Rapid Application Development (RAD) is a software development methodology that focuses on

building applications in a very short amount of time; traditionally with compromises in usability,

features and/or execution speed. The term has recently become a marketing buzzword that

generically describes applications that can be designed and developed within 60 - 90 days, but it

was originally intended to describe a process of development that involves application

prototyping and iterative development.

Because of this

To prevent cost overruns

(RAD needs a team already disciplined in cost management)

To prevent runaway schedules

(RAD needs a team already disciplined in time management)

To converge early toward a design acceptable to the customer

and feasible for the developers

To limit a project's exposure to the forces of change

To save development time, possibly at the expense of economy or

product quality

In certain situations, a usable 80% solution can be produced in

20% of the time that would have been required to produce a total

solution.

In certain situations, the business requirements for a system can

be fully satisfied even if some of its operational requirements

are not satisfied. The acceptability of a system can be

assessed against the agreed minimum useful set of requirements

rather than all requirements.



Software Life Cycle Flow Chart

Quality Gates for Each Phase of SW Development

Increased quality is a primary focus of the Rapid Application Development methodology, but the

term has a different meaning than is traditionally associated with Custom Application

Development. Prior to RAD, and perhaps more intuitively, quality in development was both the

degree to which an application conforms to specifications and a lack of defects once the

application is delivered. According to RAD, quality is defined as both the degree to which a

delivered application meets the needs of users as well as the degree to which a delivered system

has low maintenance costs. Rapid Application Development attempts to deliver on quality

through the heavy involving of users in the analysis and particularly the design stages.

Quality Metric Trigger

Open defects vs. closed defects over time Rate of increase of open defects >0.5*rate of

increase of closed defects over the past

2weeks

Line Of Code (LOC) N/A

Source code comment percentage <10%

Defects per KLOC >10% of defined norm for implementation

phase, as follows:

Coding: 15

Complication: 6

Black-box test: 7

Integration: 3



List of Tasks Requirements Elicitation

Project Presentation by BRTC

Project Planning

Requirements Analysis

Analysis Review

System Design

Object Design

Project Review with BRTC

Implementation & Unit Testing

Object Design Review

Project Agreement

System Integration & System

Testing

Internal Project Review (functional

prototype)

Project Acceptance by BRTC

Estimation for Each Task Task Of Phase Days Hours

Requirements Elicitation 28 210

Project Planning 25 187.5

Requirements Analysis 32 240

System Design 16 120

Object Design 10 75

Implementation & Unit Testing 12 90

System Integration & System Testing 15 112.5

*Total days are 105 days and working days are 93 days without national holydays.

Time Duration (Days) Requirements Elicitation

Project Planning

Requirements Analysis

System Design

Object Design

Implementation & Unit Testing

System Integration & System Testing



Schedule the Tasks

Date Project Phases

June 17 - July 24 Requirements Elicitation

July 29 - September 2 Project Planning

August 8 - September 20 Requirements Analysis

September 6 - 27 System Design

September 30 - 11 Object Design

October 3 - 18 Implementation & Unit Testing

October 21 - November 8 System Integration & System Testing



Prepare List of Milestone

Date Project Milestones

July 26 Project Presentation by BRTCs

September 22 - 26 Analysis Review

October 4 Project Review with BRTC

October 24 Object Design Review

October 17 Project Agreement

October 25 Internal Project Review (functional prototype)

November 12 Project Acceptance by BRTC

Staffing Plan The purpose staffing plan is to make certain the project has sufficient staff with the right skills

and experience to ensure a successful project completion.

Role Requirements

The following is a detailed breakdown of the roles required to execute the project. It includes:

the project role, the project responsibility of the role, skills required, number of staff required

fulfilling the role, the estimated start date and the expected duration the staff resource will be

needed on the project.

Role

Project

Responsibility

Skills Required

No. of

Staff

Required

Estimated

Start

Date

Duration

Required

Java

Developer

Java

Development

Java programming

expert(J2ME,J2EE)

BSc in Software

Engineering

10 June 17,

2012

October 2,

2012

Web

Developer

Web

Development

HTML,CSS,XHTML,X

ML,AJAX, JavaScript,

PHP (Strong knowledge

in MVC Platform)

3 June 17,

2012

October 2,

2012

Database

Management

Full control in

Database

Expert in Oracle10g,

SQL, MYSql

2 June 17,

2012

October 2,

2012

Software

Engineer

Software Testing

And Quality

Assurance

Strong Knowledge in

Capability Maturity

Model Integration

(CMMI) & Spice, ISO

9001:2000 for Software

3 June 17,

2012

October 2,

2012



Staff Assigned to Roles

The following is a detailed breakdown of the actual staff assigned to the project role, the amount

of Full Time Equivalent (FTE) requested for the role, the actual FTE acquired, the labor rate and

unit of the labor rate for the resource and the source from which the resource is recruited.

Role

Name

Requested

FTE

FY yy-yy

Acquired

FTE

FY yy-yy

Rate

Rate Unit

Java Developer

1. ISTIAK AHMED

2. ABIR AHMED

3. MAZARUL

HAQUE

FY 2012-2013

FY2012-2013

$20

$15

$25

Hour

Hour

Hour

Web Developer 1. ANNAS BISWAS FY 2012-2013 FY 2012-2013 $12 Hour

Database

Management

1. TANVIR HASAN

2. RAGHIB HASAN

FY 2012-2013

FY 2012-2013 $20

$15

Hour

Hour

Software

Engineer

1. INDRO ROY

2. ZAHIDUL

HAQUE

FY 2012-2013 FY 2012-2013 $20

$30

Hour

Total: 8

Staff Resource Loading Chart

The following includes the estimated effort in Full Time Equivalent (FTE) days required by

month for each staff resource assigned to the project.

Role

Number of Staff

Required

July

Aug

Sept

Oct

Total

Java Developer 10 20 20 20 20 85

Web Developer 3 15 20 15 10 60

Database

Management

2 25 20 20 25 90

Software Engineer 3 20 15 15 20 70

Total : 18 90 75 70 75 305



Monitoring & Controlling Mechanism Define the reporting mechanisms, report formats, review and audit mechanisms, and other tools

and techniques to be used in monitoring and controlling adherence to the SPMP. Project

monitoring should occur at the level of work packages. Include monitoring and controlling

mechanisms for the project support functions (quality assurance, configuration management,

documentation and training).

A table may be used to show the reporting and communication plan for the project. The

communication table can show the regular reports and communication expected of the project,

such as weekly status reports, regular reviews, or as-needed communication. The exact types of

communication vary between groups, but it is useful to identify the planned means at the start of

the project.

Communication and Reporting Plan

Information Communicated

From To Time Period

Status report Project Team Project Manager Weekly

Status report Project Manger Software Manager, Project

Team

Weekly

Project Review Project Team Software Manager Monthly

Risk Management This section mentions a number of possible risks for the project. Also, actions or measures are

described to prevent or to reduce the risks.

Four categories of risks are identified:

Risks with respect to the work to be done.

Risks with respect to the management.

Risks with respect to the resources.

Risks with respect to the customer.

The risks for each category are listed below. For each risk, a description, a probability to occur,

the action associated and the impact of the risk are given.

It is obvious that problems will occur during the project. To avoid problems the following rules

should be followed by all team members:

Try to signal problems as early as possible and report them to the PM, so that action can

be taken.

Pay attention to communication and make sure everybody understands the things the

same way.



Focus on the agreed user requirements, which express the wishes of the customer

Minimize friction between people by helping and supporting each other.

Follow guidelines that are posed in [SQAP] and [SCMP] to aid coordination and to

ensure product quality.

The risk Management Analysis diagram:

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

List of Delivers The System documentation will describe the principles of operation. The delivery consists of a

presentation of the system, a demonstration of the working system and the successful passing of

the acceptance test. The BRTC expects the acceptance test to be successfully demonstrated

remotely via the Internet November 8, 2012.from 8:30 pm to 10:20 pm. All work deliverables

will be on November 12, 2012.The work products will also be delivered on a CD-ROM after any

working days on November 12, 2012.



Deliverable work Products

Name Standard Preparer Reviewer Date Distribution

List

Software

Design

Specification

(SDS)

IEEE

1016-1998

IEEE

1016-1998

Consultant 1,

Project

Manager

October 4,

2012

Document

repository,

Preparer, Reviewer,

PM,

Consultant 1,

Programmer 1,

Technical Writer 1

End-user

Documentation

IEEE

1063-2001

Technical

Writer 1

Consultant 2 November

8, 2012

Document

expository,

Preparer, Reviewer,

PM

Software IEEE

830-1998

Requirements Requirements November

12, 2012

Document

Software

Project

Management

Plan (SPMP)

IEEE

1058-1998,

IEEE

1074-1997

Project

Manager

BTRC

Executive

Committee

September

27, 2012

Document

repository,

Preparer, Reviewer

PM,

NNB Executive

Committee

Software Test

Plan (STP)

Software Test

Plan

template

(adapted

from IEEE

829-1998)

Verification

Engineer 1,

Verification

Engineer 2

Project

Manager

October 1,

2012

Document

repository,

Preparer, Reviewer

PM,

Programmer 1

Software

Quality

Assurance Plan

(SQAP)

IEEE

730-2002

Quality

Analyst 1

Project

Manager

October 3,

2012

Document

repository,

Preparer, Reviewer

PM

Software

Verification

IEEE

1012-1998,

IEEE

1012a-1998

Verification

Engineer 1,

Project

Manager

November

8 – 12, 2012

Document

repository



Non-deliverable work products

Name Standard Preparer Reviewer Review

copy due

Distribution

list

Project team

meeting minutes

Meeting

Minutes

template

Project

Manager

Meeting

participants

24 hours

after

meeting

Document

repository,

Reviewer

Project team

meeting agendas

Meeting

Agenda

template

Project

Manager

Meeting

participants

24 hours

prior to

meeting

Document

repository,

Reviewer

Design peer

review

summaries

Technical

Review

Summary

template

Software

Designer 1

Review

participants

48 hours

prior to

review

Document

repository,

Reviewer

Project Quality Quality Meeting N/A Document

Schedule Tracking Process Every week, the work done by the members needs to be administrated. Each team member has to

fill in their hours on a web based log. This log needs to be filled in every Monday before 12:00.

A week stats at Sunday and ends at Tuesday. The PM sends an e-mail to the SM every week,

containing the hours spends on the different work package and the hours spend on followings

categories:

Non project relate, General project related, Documentation, specification, design, Source code,

testing, verification, consolidation and rework. Further, for every work-package, an estimation of

remaining hours is added.

Team leader meetings

Whenever the Project Manger (PM) or QAM finds it necessary he can arrange a team meeting.

Team leader meetings are rather informal and infrequent and the task required for one the

purpose of the meeting.

Reporting and Information Flow Matrix:

Action Weekly Monthly

Status meetings Project Team Meeting, Project Manager

& Department Director

Project Manger & Directors

Reports Complete Tasks, Details on Schedules &

Tasks for Next Week

Summary of Standard Reports



Defect Tracking Process

This document is details the process the bug or defect follows. It also details the way in which a

bug/defect is entered in to the bug tracking database.

Lifecycle of Defect:

Open Defect/Bug using bug template and bug tracking software

Assigned to developer or person responsible for fix

Developer reviews Bug

Developer acknowledges bug or declines bug for various reasons

If developer acknowledges bug, then a fix in progress is in

Developer fixes bug and assigns it back to person who opened it

QA confirms fix is completed in proper build

QA closes bug

If developer declines bug, then developer assigns bug back to person who opened it with reason

of decline

QA either acknowledges reason for close or can re-open bug with more details or proof

Developer can give reasons of: not a bug, by design, not reproducible, duplicate bug



Priority

Level

Description

Response Time or Turn -

around Time

High

A defect occurred due to the inability of a key

function to perform. This problem causes the system

hang it halts (crash), or the user is dropped out of the

system. An immediate fix or work around is needed

from development so that testing can continue.

Defect should be responded to within

24 hours and the situation should be

resolved test exit

Medium

A defect occurred which severely restricts the system

such as the inability to use a major function of the

system. There is no acceptable work-around but the

problem does not inhibit the testing of other functions

A response or action plan should be

provided within 3 working days and

the situation should be resolved

before test exit.

Low

A defect is occurred which places minor restrict on a

function that is not critical. There is an acceptable

work-around for the defect.

A response or action plan should be

provided within 5 working days and

the situation should be resolved

before test exit.

Others

An incident occurred which places no restrictions on

any function of the system. No immediate impact to

testing. A Design issue or Requirements not

definitively detailed in project. The fix dates are subject

to negotiation.

An action plan should be provided

for next release or future

enhancement

Metrics Metrics Description Tracking Tool

Schedule Milestones MS Project

Staff Usage Graph of person hrs used per month

Both projected and actual

MS Excel

Expenditures Graph of total expenditures over time

Both projected actual

MS Excel

No. of Requirements Graph of total requirements

Identified per module over time

MS Excel

No. of Requirements Defects Graph of number of defects identified per

module over time

MS Excel

No. of Objects Graph of number of objects identified

Over time

Coding Progress Number of objects coded MS Excel

Coding Size Lines of code measured daily

Test progress Unit test causes passed over time MS Excel

Defect Tracking Number of code defects

Test Progress Number of integration test

Passed over time

MS Excel

Defect Tracking Number of code defects test

Passed over time

MS Excel



Postmortem The overall project plan follows the model, a modified RAD model. 3 prototypes have to be

delivered: A graphical user interface, a functional prototype and a system integration prototype.

Analysis is started before Project Planning is finished. System Design is followed by Object

Design. Important Milestones are the Analysis Review September 22 to September 26, the

Project Status on September 26, the Project Review on October 4 and the Object Design Review

on October 24. Implementation and Unit Testing are scheduled to overlap significantly. System

Integration is scheduled to immediately follow Unit Testing. System Testing starts immediately

after system integration and leads to the BRTC Acceptance Test on December 8, 2012.

T H E E N D

Documents

Software Project Management Plan