SOFTWARE PROJECT MANAGEMENT PLAN

FOR
EZBUY! ONLINE PORTAL SYSTEM

SUBMITTED BY THE FIFITH CONCERTO

Anju Achuthan (MBA09011)

Deepak Rajasekharan Pillai ( MBA09031)

Deepti Mohan (MBA09033)

Madhavankutty (MBA09057)

Vivek Vincy (MBA09124)

1
Contents
1. Introduction...................................................................................................................................3
2. References.....................................................................................................................................3
3. Assumptions and dependencies.....................................................................................................3
4. Terminology, Definitions and Abbreviations..................................................................................3
5. Project Deliverables.......................................................................................................................4
7. Project Success measures..............................................................................................................9
8. Configuration Management Plans..................................................................................................9
9. Development methodologies.......................................................................................................10
10. Project Estimation........................................................................................................................11
11. Computer Resources Requirements............................................................................................13
12. Risk Management........................................................................................................................13
13. Tracking and Project Management..............................................................................................14
14. Management Reporting and review procedures.........................................................................16

2
1. Introduction
1.1. Project Identification

This document serves as the project plan for developing an online portal called EZbuy!
This portal facilitates buying and selling of goods between consumers and vendors
within a city. The portal provides them with an interface for transacting goods and cash.

1.2. Project Summary

EZbuy! is meant for shopping of daily necessities like household items, food etc. Since,
this portal is meant for daily use for a wide assortment of people, it should be simple,
user-friendly, and reliable. EZbuy! will effectively interact with systems like bank,
vendor, customer to facilitate the order placement and cash transaction.

1.3. Project objectives

EZbuy! has got 3 categories of users a- the consumers, the vendors and the logistics
team. Ezbuy! is expected to perform the following functions for them. ‘EZbuy!’ allows
consumers to login, search for desired products, check product details, Compare prices,
Place order and Pay online. ‘EZbuy!’ portal allows the vendors to update the vendor’s
inventory status and track the consumer/product demand, sales. EZbuy! portal allows its
logistics team to see all the details regarding transactions and orders placed.

2. References
2.1. Managing Global Software Project by Gopalaswamy Ramesh
2.2. Template for a Software Project Management Plan
2.3. SRS document Version 2.0 for EZbuy!
2.4. Meeting Minutes

3. Assumptions and dependencies

 Depends on the smooth running and operation of the internet, customer database,
vendor
 Database and banking system. Users will be accessing the portal through a PC having
a minimum speed of 500 MHz and 64 MB RAM.
 Users will have Web browsers Internet explorer 6.0 or above, Mozilla firefox 2.0 or
above,Google chrome

4. Terminology, Definitions and Abbreviations

SRS – Software Requirement Specifications

VD – Vendor Database

3
 CD – Customer Database

PB – Personal Bank

Aggregate Deliverables – A list that consolidates all the products different customers have
ordered from different vendors and the respective delivery addresses.

Transaction - A real event that involves flow of personal money. In context of Bank it is
deposit/withdrawal of money to/from one’s account.

Customer balance details – It is a list showing the details of amount of goods purchased by
the customers and the payments made. It will show the excess or shortage of payment
made so that it enables to take the correct amount during the next transaction.

1. Project Deliverables
5.1 External Deliverables

The EZBuy portal system deliverable to the clients is listed below. Here since we
follow a waterfall model, the process will be sequential and structured.

Project
Initiation

Project
Planning and
Analysis
Project
Design

Development
and
Implementatio

Closure

Figure 1: Waterfall Model for the EZBuy System

4
  Software Requirements Specifications (SRS) (As per IEEE 830 – 1998)
 Software Project Management Plan (SPMP) (as per IEEE 1058 – 1998)
 Software Test Plan (STP) (as per IEEE 829 – 1998)
 Software Configuration Management Plan (SCMP) (as per IEEE 828-1998)
 Software Quality Assurance Plan (as per IEEE 730 – 2002)
 User manuals
 Training Schedule
 Process documentation (including Process Improvement Plans)
 Project Signoff document

5.2. Internal Deliverables

 Project team meeting minutes
 Project team meeting agendas
 Requirements peer review summaries
 Design peer review summaries
 Implementation peer review summaries
 Project documentation reviews (Quality)
 Software maintenance
 Training plan
 Document and Review Lessons Learned

6. Components and constraints

6.1 Work breakdown Structures

As mentioned in the above section, the entire software lifecycle is envisaged into
various phases consisting of the Project initiation, project planning and analysis,
project design, project development and analysis and finally the project closure.
Dividing the project into several phases makes it easy to manage the schedules and
skill sets required for each phase. Also it helps to identify the errors occurring in each
phase and to rectify them before moving into the next phase.

5
1. Project Initiation
1.1. Chartering the project
1.1.1. Develop project charter
1.1.2. Project charter approval

2. Project Planning
2.1. Scope definition
2.1.1. Create scope document
2.1.2. Scope Approval

3. Project Analysis
3.1. Requirement gathering
3.1.1. Prepare research instruments
3.1.2. Interview users, SMEs
3.1.3. Draft SRS v1.0
3.1.4. Review and revise SRS
3.1.5. SRS Approval

4. Project design
4.1. Create data, software and hardware architecture
4.2. Design products
4.2.1. User Interface
4.2.2. Objects
4.2.3. Workflow
4.2.4. Rules
4.2.5. Database
4.2.6. Permissions
4.3. Design tests
4.3.1. User Interface
4.3.2. Objects
4.3.3. Workflow
4.3.4. Rules
4.2.5. Database
4.2.6. Permissions

5. Project Development and Implementation

5.1. Prototype development
5.1.1. Build prototype
5.1.2. Customer review
5.1.3. Customer approval
5.2. Product development, testing and implementation
5.2.1. User Interface

6
 5.2.2. Objects
5.2.3. Workflow
5.2.4. Rules
5.2.5. Database
5.2.6. Permissions

6. Closure
6.1. Project sign off

7
Figure 2: Work breakdown Structure
 6.2 Constraints
 The system should be delivered by first week of March 2011.
 The system should be able to handle 10,000 users simultaneously.
 The system should have less than 2hours of down time in a month.
 The response time should be less than 2 seconds.
 The system should be available almost all the time.
 No same login id should be accepted from the users.
 The user interface design should be user friendly with both keyboard and
mouse click operative.
 The system should be flexible and adaptive to future changes.
 There should be a backup of the data so as to avoid loss of data in case of
system crash.
 The system should be able to identify the correct amount entered by users
and also show error message when amount is less than Rs. 10,000 or exceeds
Rs.100000.

7. Project Success measures

Quantitative targets for measuring project success :

 The number of user login per month.

 The number of vendors registered
 The accuracy of the vendor product details
 Customer satisfaction scores
 System down time per month
 Number of change requests during development
 Consistency of response time

8. Configuration Management Plans

A Configuration Management Plan is used to establish and maintain consistency in a

software product by coordinating performance, functional and physical attributes
with its requirements, design, and operational information.

Configuration management involves identifying the configuration of the system at

given points in time, systematically controlling changes to the configuration, and
maintaining the integrity and traceability of the configuration throughout the
lifecycle. The items placed under configuration management include the software
and hardware products that comprise the system as well as items required to create
or maintain these products.
9. Development methodologies

9.1 Life cycle model

An iterative water fall model is used for developing the system. The project is divided
into sequence of well defined phases and modules. The requirements are majorly
well defined, organized and static as the scope of rapid change is limited. The
iterative development suites the system and it requires constant tracking to ensure
that the requirements of the entire stakeholder are properly captured. It strikes a
good balance mechanism for early problem identification and correction while not
missing out proactive problem prevention.

The entire software life cycle is visualized in terms of various phases constituting
Initiation, Planning and analysis, Design, Development and Implementation and
Closure. By dividing the project into such phases and scheduling the phases in
sequence, the lining up of the skill sets according to requirement becomes easy and
more manageable. The flow will be sequential and on completion of one phase next
will follow. There is feedback loop between adjacent phases.

9.2. Standards (external and internal)

External standards followed would be of API (American Petroleum Institute)
standards. Java Database Connectivity (JDBC) API which is the industry standard for
database-independent connectivity between the Java programming language and a
wide range of databases would be employed for the system database access.

Internal standards that would be followed during the project development are
Microsoft design template for the designing process and IEEE documentation
standard for the project documentation. To ensure consistency across the
development and testing process, version control and tracking of the changes would
be maintained using Microsoft VSS software

9.3. Specific processes to be used for the project

The project will be implemented in the following sequential phases: Initiation,

Planning and analysis, Design, Development and Implementation and finally closure.
Each of the phases will deal with the four parts of the system viz Web Front End,
Database, Interface and Report. The web front end will take care of the EZBuy portal
process and functionalities. The database will be the part where the complete data
for the system is stored hence the design is critical to ensure fast retrieval and higher
throughput. The Interface part will used to take care of the different interface
between the front end and database as well as other interface requirements. The
report is one of the feature of the system and used by key stock holders. The system
will have crystal report used for it.
10. Project Estimation

10.1 Size Estimation

Size estimation is required to have a good estimate of the time
required for the completion of the project. This would take into account the
various reports, screens and the transactions that would be part of the
project.

There are 15 reports and 12 screens

Internal Reports External Reports Screens

Change Management report Exit Report Home Page
Configuration Management Usage report Registration screen
report Vendor details report Customer Login Screen
Audit reports Stock details report Search screen – product wise
Availability reports Logistics report Search screen – vendor wise
Throughput report Customer satisfaction report Search screen – segment wise
Vendor satisfaction report Product availability/order screen
Sales report Payment screen
Security report Customer feedback screen
Daily order report Vendor stock update screen
Vendor feedback screen
Daily aggregate delivery screen
10.2 Effort estimation

Design 100 Man-hours

Web User Interface for SIS
SQL
Interfaces
Reports
Development 60 Man-hours
Web Front End
SQL Database
Interfaces
Reports
Testing 60 Man-hours
Web Front End
SQL Database
Interfaces
Reports
Training 40 Man-hours
Create system documentation
Create training materials
Train users
Implementation 40 Man-hours
Hardware
Packaged Software
Develop Implementation Plan
Installation
Post-Implementation 40 Man-hours
Verify System
Project Wrap-up
10.3 Schedule estimation
Design Sept 30 to Oct 17
Development Oct 17 to Nov 19
Testing Nov 20 to Dec 30
Training Jan 1 to Jan 20
Implementation Jan 21 to Jan30
Post-Implementation Feb 1 to Feb 15

11. Computer Resources Requirements

11.1 Project-specific computer software requirements

This project adapts the system for use on a Personal Computer using a Visual
Interface that would be built using Visual basic 6.0 and HTML, and Oracle 10 g
release 2 as its database management system.

11.2 Infrastructure requirements

The hardware resources are 100, 1 GHz Pentium computers running Windows XP
Operating System. Each of these computers should have at least 500 MB RAM
and a minimum of 50 GB of disk space.

12. Risk Management

12.1 Risk identification, Quantification and Mitigation

A risk is something which may occur in the course of a project, and which, under the
worst outcome, would affect it negatively and significantly. A risk categorization table
will be maintained for the duration of the project. This table will list the current
project risks, its likelihood and its impact.
A preliminary risk categorization table has been populated with risks and risk status
and is given below:

Risks Likeli-hood Impact Priority Mitigation Plans

(L)
(I) (L*I)

1 Deficient database skills High: 90% 8 – high 7.2 unskilled people work closely
with skilled people

2 Project Staff stability Low: 10% 6 - medium .60 Cross-train using inspections on
all documents & code

3 Requirements Changes Medium: 4 -medium 2.0 Write into contract that

50% changes

must result in renegotiation of

schedule

4 Under-estimate Medium: 2 - low 1.0 Implement high priority

Schedule 50% functions first. Monitor
schedules on a weekly basis
with meetings.

5 Under-estimate Budget Medium: 6- medium 3.0 Planning and cost estimating

tools: FAST Planner for IT, and
50% MS Project
Evaluating tradeoffs:
time/resources
Spending plans and forecasts

6 Security Low : 20% 6-medium 1.2 Data Encryption

13. Tracking and Project Management

The objective of the Project tracking is to ensure that the project is proceeding as per
the plan and if there are any differences, to plan the appropriate corrections

13.1 Factors to be tracked

The factors to be tracked would mainly include the actual effort involved vis a vis the
estimated effort.

The critical activities such as the interfaces with the product order and payment
module should be achieved effectively. After the effort estimation once the work
begins there needs to be a constant tracking on whether or not there is slippage
occurring due to planned work not able to be finished in the estimated time.
Depending on the type of work various ways to solve slippage and put the project
back on track should be initiated.

If there is unplanned work that gets done in the time allotted for the planned work,
the estimated time is more than required and necessary correction needs to be,
made. Also, the estimation of work also needs to be reworked to include the
unplanned activities.

It has to be ensured that the time earmarked for various activities in the work
breakdown structure should me met so that the product is delivered on time.

Another main area where there should be focus is the quality assurance front. This
area needs to be constantly on the tab and a weekly report should be in place.

13.2 Tracking and reporting frequency and responsibility

The reporting of the status should be done on a weekly basis other than that
there would be a daily and monthly report to the various section leaders.

Daily reports would be filled in by the developers to their immediate

managers and this would be on tracking sheet. This would be in the form of
the daily status report.

The line managers would be responsible for keeping the project on track
pertaining to development goals. The line managers would report to the
Project manager on a weekly basis. The project manager would be in charge
of the whole project and the required inputs would be given to keep the
project on schedule. This would be in the form of a weekly status report and
face to face meeting at the end of every month.

11.3 Project Plan change management, review and approval procedures

Any change would be significant if it affects the schedule or the cost or

features of the project.

Updating the SPMP document is the responsibility of the Project Manager

and PM would also be the configuration controller. There would be a weekly
review of the SPMP and there would be fortnightly meeting of the Line
managers and the project managers to make the necessary changes in the
SPMP document.
 The date of approval of the change request, name of the person who
requested the change and the name of the person who approved the change
should be mentioned in the plan.

The various scenarios where the SPMP would be updated are as follows

1. There is a slippage by more than 5% of the total project duration from

the promised date of delivery.
2. There is attrition of any line manager or the project manager involved in
the project.

14. Management Reporting and review procedures

14.1 Management Review procedures

Management review would be twofold: Project management level and the
development level.

At the project management level, there would be project review meetings every
week. This would be attended by the developers and the line managers also. This is
to ensure there are no problems in achieving the milestones as set in the SPMP. The
meeting also has to ensure that there are no interruptions or slippages and the
project would be heading towards completion as promised.

At the development level there are weekly meetings with the line managers and the
developers. This is to ensure that that the tasks assigned are completed and there is
no problem with the estimation. The line managers should keep tab on the changes
that are required to be made on the estimation and the procedures instituted to
make estimations.

Status reports would be provided on a daily basis by the developers to the line
managers. This would be collated into a weekly report to the project manager.

The project managers would meet with the senior management and the Line of
Business Manager to update on the project every month during the course of the
project.

14.2. Service Level Agreements and Escalation mechanisms

Since there are internal and external customers there would be two point of
escalation for both the stakeholders.

For the internal stakeholders like the developers and the testers, the point of
escalation would be the line managers.

For the external stakeholders the point of escalation would be the Project Manager.

There would be 3 level of issues as seen by the system.

Level 1 Issue: This issue would be top priority and the seriously hampers the usage of
the system. This needs to be solved in maximum of 6 hours.

Level 2 Issue: This issue would be medium priority and affects the functioning of the
system. This needs to be solved in maximum of 1 week.

Level 3 Issue: This issue would be low priority and would be mostly related to the
look and feel of the system. This needs to be solved in maximum of 15 days.