Software Project Management Plan

(1)

AIUB IT Solutions Inc.

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

(2)

AIUB IT Solutions Inc.

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.

(4)

AIUB IT Solutions Inc.

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

(5)

AIUB IT Solutions Inc.

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

(6)

AIUB IT Solutions Inc.

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

(7)

AIUB IT Solutions Inc.

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 Responsibility Project 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

(8)

AIUB IT Solutions Inc.

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

(9)

AIUB IT Solutions Inc.

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.

(10)

AIUB IT Solutions Inc.

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.

(11)

AIUB IT Solutions Inc.

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

(12)

AIUB IT Solutions Inc.

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

(13)

AIUB IT Solutions Inc.

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

(14)

AIUB IT Solutions Inc.

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

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

(15)

AIUB IT Solutions Inc.

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.

Software Project Management Plan

AIUB IT Solutions Inc.