Software Project Management Plan

AIUB IT Solutions Inc. Software Project Management Plan (SPMP) for Automated Ticket Issuing System for Bangladesh Road Transport Corporation (BRTC)

::

Title Page

NAME HAQUE, MAZHARUL AHMED, ISTIAK AHMED, ABIR RAFI, HASIB ADNAN ARR

:: ID 10-16377-1 10-16025-1 10-16234-1 08-11361-2

JUNE 18, 2012

Revision History Revision Version 0.0.1

2012

©

Date June 12, 2012

Authors HAQUE, MAZHARUL AHMED, ABIR RAFI, HASIB ADNAN ARR AHMED, ISTIAK

Mazharul, Istiak, Abir & Rafi

Description First Version

Page 1 of 15

AIUB IT Solutions Inc.

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

2012

©

Mazharul, Istiak, Abir & Rafi

Page 2 of 15

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. 2012

©

Mazharul, Istiak, Abir & Rafi

Page 3 of 15

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 Open defects vs. closed defects over time

Line Of Code (LOC) Source code comment percentage Defects per KLOC

2012

©

Mazharul, Istiak, Abir & Rafi

Trigger Rate of increase of open defects >0.5*rate of increase of closed defects over the past 2weeks N/A 10% of defined norm for implementation phase, as follows:  Coding: 15  Complication: 6  Black-box test: 7  Integration: 3

Page 4 of 15

AIUB IT Solutions Inc.

List of Tasks Requirements Elicitation

Implementation & Unit Testing

Project Presentation by BRTC

Object Design Review

Project Planning

Project Agreement

Requirements Analysis

System Integration & System

Analysis Review

Testing

System Design

Internal Project Review (functional

Object Design

prototype)

Project Review with BRTC

Project Acceptance by BRTC

Estimation for Each Task Task Of Phase Requirements Elicitation Project Planning Requirements Analysis System Design Object Design

Days

Hours

28 25 32 16 10

210 187.5 240 120 75

12 90 Implementation & Unit Testing 15 112.5 System Integration & System Testing *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

2012

©

Mazharul, Istiak, Abir & Rafi

Page 5 of 15

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

October 21 - November 8

System Integration & System Testing

2012

©

Mazharul, Istiak, Abir & Rafi

Page 6 of 15

AIUB IT Solutions Inc.

Prepare List of Milestone Date July 26 September 22 - 26 October 4 October 24 October 17 October 25 November 12

Project Milestones Project Presentation by BRTCs Analysis Review Project Review with BRTC Object Design Review Project Agreement Internal Project Review (functional prototype) 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

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

2012

©

Skills Required

Mazharul, Istiak, Abir & Rafi

Page 7 of 15

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

1. ISTIAK AHMED Java Developer 2. ABIR AHMED 3. MAZARUL HAQUE Web Developer 1. ANNAS BISWAS Database Management

Acquired FTE FY yy-yy

Rate

FY 2012-2013

FY2012-2013

$20 $15 $25

Hour Hour Hour

FY 2012-2013

FY 2012-2013

$12

Hour

$20

Hour

FY 2012-2013

FY 2012-2013

FY 2012-2013

FY 2012-2013

1. TANVIR HASAN 2. RAGHIB HASAN 1. INDRO ROY 2. ZAHIDUL HAQUE

Software Engineer

Requested FTE FY yy-yy

Total:

$15 $20 $30

Rate Unit

Hour Hour

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 Java Developer Web Developer Database Management Software Engineer Total :

2012

©

Number of Staff Required

July

Aug

Sept

Oct

Total

10

20

20

20

20

85

3

15

20

15

10

60

2

25

20

20

25

90

3

20

15

15

20

70

18

90

75

70

75

305

Mazharul, Istiak, Abir & Rafi

Page 8 of 15

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

Weekly

Team 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. 2012

©

Mazharul, Istiak, Abir & Rafi

Page 9 of 15

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: 5 4.5 4 3.5 3 2.5 2 1.5

1 0.5 0

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.

2012

©

Mazharul, Istiak, Abir & Rafi

Page 10 of 15

AIUB IT Solutions Inc. Deliverable work Products Name

Standard

Preparer

Reviewer

Date

IEEE 1016-1998

IEEE 1016-1998

Consultant 1, Project Manager

October 4, 2012

End-user Documentation

IEEE 1063-2001

Technical Writer 1

Consultant 2

November 8, 2012

Software

IEEE 830-1998 IEEE 1058-1998, IEEE 1074-1997

Requirements

Requirements

Project Manager

BTRC Executive Committee

November 12, 2012 September 27, 2012

Software Test Plan template (adapted from IEEE 829-1998) IEEE 730-2002

Verification Engineer 1, Verification Engineer 2

Project Manager

October 1, 2012

Quality Analyst 1

Project Manager

October 3, 2012

IEEE 1012-1998, IEEE 1012a-1998

Verification Engineer 1,

Project Manager

Software Design Specification (SDS)

Software Project Management Plan (SPMP)

Software Test Plan (STP)

Software Quality Assurance Plan (SQAP) Software Verification

2012

©

Mazharul, Istiak, Abir & Rafi

Distribution List Document repository, Preparer, Reviewer, PM, Consultant 1, Programmer 1, Technical Writer 1 Document expository, Preparer, Reviewer, PM Document Document repository, Preparer, Reviewer PM, NNB Executive Committee Document repository, Preparer, Reviewer PM, Programmer 1

Document repository, Preparer, Reviewer PM November Document 8 – 12, 2012 repository

Page 11 of 15

AIUB IT Solutions Inc. Non-deliverable work products Name

Standard

Preparer

Reviewer

Review copy due

Project team meeting minutes

Meeting Minutes template Meeting Agenda template Technical Review Summary template Quality

Project Manager

Meeting participants

Project Manager

Meeting participants

Software Designer 1

Review participants

24 hours after meeting 24 hours prior to meeting 48 hours prior to review

Distribution list Document repository, Reviewer Document repository, Reviewer Document repository, Reviewer

Quality

Meeting

N/A

Document

Project team meeting agendas Design peer review summaries Project

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 Status meetings Reports

2012

©

Weekly Project Team Meeting, Project Manager & Department Director Complete Tasks, Details on Schedules & Tasks for Next Week

Mazharul, Istiak, Abir & Rafi

Monthly Project Manger & Directors Summary of Standard Reports

Page 12 of 15

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

2012

©

Mazharul, Istiak, Abir & Rafi

Page 13 of 15

AIUB IT Solutions Inc. Priority Level

High

Medium

Description 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. 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 defect is occurred which places minor restrict on a function that is not critical. There is an acceptable work-around for the defect.

Low

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.

Others

Response Time or Turn around Time Defect should be responded to within 24 hours and the situation should be resolved test exit

A response or action plan should be provided within 3 working days and the situation should be resolved before test exit. A response or action plan should be provided within 5 working days and the situation should be resolved before test exit. An action plan should be provided for next release or future enhancement

Metrics Metrics Schedule Staff Usage Expenditures No. of Requirements No. of Requirements Defects No. of Objects Coding Progress Coding Size Test progress Defect Tracking Test Progress Defect Tracking

2012

©

Description Milestones Graph of person hrs used per month Both projected and actual Graph of total expenditures over time Both projected actual Graph of total requirements Identified per module over time Graph of number of defects identified per module over time Graph of number of objects identified Over time Number of objects coded Lines of code measured daily Unit test causes passed over time Number of code defects Number of integration test Passed over time Number of code defects test Passed over time

Mazharul, Istiak, Abir & Rafi

Tracking Tool MS Project MS Excel MS Excel MS Excel MS Excel

MS Excel MS Excel MS Excel MS Excel

Page 14 of 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.

THE END

2012

©

Mazharul, Istiak, Abir & Rafi

Page 15 of 15