PROJECT PLAN

FRONTIERS INTERNET SYSTEM V 2.0

VERSION 0.5

Approved By

Onsite Project Manager:

Offshore Project Manager:

Date:

Frontiers Internet System V2.0 Confidential Page 1 of 22

Copyright © 2009 PITS Solutions
This document is confidential and should not be shared with any third party without the
written authorization of PITS Solutions. Any product / service names used in this
document may be trademarks or service marks of their respective organizations.

Frontiers Internet System V2.0 Confidential Page 2 of 22

 Revision History

Date Version Description Author Reviewed By

Mmm- <Description of the revision <Author’s <Reviewer’s
N.n1
dd-yy 1> Name> Name>
Mmm- <Description of the revision <Author’s <Reviewer’s
N.n2
dd-yy 2> Name> Name>

Frontiers Internet System V2.0 Confidential Page 3 of 22

Table of Content
1 Project Introduction ..........................................................................................................................................6
1.1 Project Identification ..............................................................................................................................6
1.2 Details of the customer ..........................................................................................................................6
1.3 Acceptance criteria ..................................................................................................................................7
1.4 Deliverables .................................................................................................................................................7
1.5 Project Release Tracking .......................................................................................................................7
1.6 Revisions to this plan ..............................................................................................................................8
1.7 Reference Material ...................................................................................................................................8
1.8 Definitions and Acronyms Used ........................................................................................................8
2 Project Organization Plan ...............................................................................................................................9
2.1 Project Team Structure ..........................................................................................................................9
2.2 Project Interfaces and Communication....................................................................................... 10
3 Project Execution Plan .................................................................................................................................. 11
3.1 Technical Environment....................................................................................................................... 11
3.2 Tools ............................................................................................................................................................. 11
3.3 Size and Effort Estimation ................................................................................................................. 11
3.4 Effort Distribution Planned............................................................................................................... 12
3.5 Schedule ..................................................................................................................................................... 12
3.6 Causal Analysis and Resolution ...................................................................................................... 12
3.7 Risk Management Plan ........................................................................................................................ 13
3.8 Verification Plan ..................................................................................................................................... 14
3.9 Testing and Validation Plan .............................................................................................................. 15
3.9.1 Unit Testing ......................................................................................................................................... 15
3.9.2 Functional Testing ............................................................................................................................ 15
3.9.3 Load Testing ........................................................................................................................................ 16
3.10 Training Plan............................................................................................................................................ 16
3.11 Requirements Management Plan ................................................................................................... 16
3.12 Integration Plan ...................................................................................................................................... 16
3.13 Project Meetings ..................................................................................................................................... 17
3.13.1 Daily Scrum ..................................................................................................................................... 17
3.13.2 Sprint Planning Meeting ........................................................................................................... 17
3.13.3 Sprint Review Meeting .............................................................................................................. 17
3.13.4 Sprint Retrospective................................................................................................................... 18
3.14 Review by Project Manager .............................................................................................................. 18
3.15 Formal Project Review ........................................................................................................................ 18
3.16 Status Reporting ..................................................................................................................................... 19
3.17 Issue Management................................................................................................................................. 19
3.18 Configuration Management Plan .................................................................................................... 19
3.18.1 Change Control Procedure ...................................................................................................... 20
4 Quality Plan......................................................................................................................................................... 22

Frontiers Internet System V2.0 Confidential Page 4 of 22

 4.1 Quality & Process Performance objectives ................................................................................ 22
4.2 Quality Goal Tracking .......................................................................................................................... 22

Frontiers Internet System V2.0 Confidential Page 5 of 22

1 Project Introduction
The project Frontiers Internet SystemV2.0 (alias, FIS V2.0) is executed for Frontiers Media
SA (hereby referred as Frontiers or customer), a registered company in Lausanne,
Switzerland, which coordinates and manages the journal publishing activities of Frontiers
Foundation, a society of eminent scientists around the world. The project aims to create a
new website for Frontiers, which will enable Frontiers to create a knowledge environment
for researchers and general public. The project covers the creation of administration,
Journal publishing, e-commerce, social networking, and community building sites for
Frontiers. The Foundation has an existing website which manages the research publishing
activities, and porting the existing Journal data to the new system is also part of the project
task list.

1.1 Project Identification

Project Name Frontiers Internet SystemV2.0

Project ID FIS v2.0
Creation of a website (www.frontiersin.org) using ASP .NET 3.5 and
Project
SQL SERVER 2008. Data migration of existing Journal details.
Description

Provide a software solution which will enable the creation of the

Project Scope
website www.frontiersin.org as per the customer requirements
Project Start
01.06.2009
Date
Project End
30.04.2010
Date
Project
PIT Solutions, TechnoPark, Thiruvananthapuram
Location

1.2 Details of the customer

Customer Frontiers Media SA

Address Lausanne, Switzerland
Frontiers Media SA coordinates and manages the Journal publishing
Description activities of Frontiers Foundation via the website
www.frontiersin.org.
Contact
Kamila Markram, Henry Markram
Name
Contact Tel.
No.
Frontiers Internet System V2.0 Confidential Page 6 of 22
1.3 Acceptance criteria

Serial No. Acceptance Criteria

100% test coverage as per the test specifications approved by
1
customer
Successful execution of the performance and acceptance tests by
2
customer

1.4 Deliverables

Seri
Items to be Planned Mode of Acceptance
al
Delivered Date Delivery Responsibility
No.
DVD +
1 Prototype Source code Frontiers PM
Depository
Functional Document
2 Frontiers PM
document Depository
Detailed Design Document Frontiers PM/Frontiers
3
specification Depository System Architect
Test Cases /
Document Frontiers PM/Frontiers
4 Acceptance Test
Depository Business Analyst
Plan
Document Frontiers PM/Frontiers
5 Database design
Depository DBA
DVD +
Frontiers PM/ Frontiers
6 Software Source code
Business Analyst
Depository

1.5 Project Release Tracking

The Project Release process followed in the project is as follows:

 Every deliverable will undergo internal review.

 The concerned PL should ensure that all review errors for the corresponding
deliverable has been closed to baseline it.

Frontiers Internet System V2.0 Confidential Page 7 of 22

  During the process of project delivery, the baselined version of the deliverable will
be made available to the PM/PL to deliver to the client.

 A pre-delivery review process should be completed by the designers / or PL for the

respective deliverables and approved by them.

1.6 Revisions to this plan

The PM maintains the plan. If there is any change in the scope, delivery date, schedule,
requirements, strategy, resource, organization structure or quality goal deviation the plan
is updated and base-lined.
The PM reviews the plan every week for revision based on the actual project metrics data
and the organization level learning. During the weekly team meetings, the project plan is
reviewed and the discussions made are documented in the Minutes Of Meeting (MOM).
Whenever any of the supporting documents of the PMP is changed the entire set of
documents will be given a new version no., and the revision history updated.

1.7 Reference Material

Please include the Proposal, Technical Portion of Contract, Documents received from
Onsite.

Serial
Reference Area Reference
No.
1
2
3

1.8 Definitions and Acronyms Used

List the definitions and acronyms used in this document.

Serial
Acronym / Item Expansion / Definition
No.
1
2

Frontiers Internet System V2.0 Confidential Page 8 of 22

2 Project Organization Plan

2.1 Project Team Structure

Serial
Role Responsible for Reports to
No.
Total business responsibility for the
Project entire project. The Project Manager Account
1
Manager directs, controls, administers & Manager
regulates the entire project.
Total responsibility for the software
development and testing activities in
Project the project. This includes Project
2
Leader Requirements Management, Manager
Estimation, Planning, and Tracking &
Control activities
Responsible for the entire module. A
Module module consists of a module leader
3 Project Leader
Leader cum developer, developers and a test
engineer.
Developer Execution of Software development Module Leader
4
and testing activities that are assigned.
Responsible for the preparation and
review of integration, system and
acceptance test plans. He is also
responsible for executing the
Module
Test integration and system test cases and
5 Leader/Project
Engineer authorizing the code for delivery. He is
Leader
also responsible for conducting
acceptance testing or supporting the
client for acceptance testing as the
case may be.
Responsible for all quality control
activities in the project. This includes
Quality ensuring reviews/testing on all work
6 Project Leader
Controller products, use of proper checklists and
establishing the required standards for
the project.

Frontiers Internet System V2.0 Confidential Page 9 of 22

2.2 Project Interfaces and Communication

The Offshore PM is the point of contact for all issues regarding efforts and schedule that
may crop up. The offshore PM will approve all the change requests.
The team interacts with the onsite team for clarification. All issues are recorded and
tracked by using Issue Tracker (JIRA).
The standard MOM form is filled up for all conference calls with the onsite and distributed
to all the participants. The MOM form will also be filled for the inter group co-ordination
meeting and distributed to all the participants.

FRONTIERS PITS

Team

Project Leader

Project Manager Project Manager

Account Manager

Chairman
Project Sponsor
Managing Director

Escalation Procedure

Frontiers Internet System V2.0 Confidential Page 10 of 22

3 Project Execution Plan

3.1 Technical Environment

Serial No. Technical Environment

1 ASP.NET 3.5, Microsoft Windows SharePoint Services 3.0
2 SQL Server 2008, ADO.NET
3 OS - Windows Server 2008
Web Server - Internet Information Services 7.0
Application Server - Internet Information Services 7.0

3.2 Tools

Serial
Tool Use in the project
No.
1 Microsoft Visual Software development
Studio
2008,Sharepoint
designer
2 Enterprise Architect Design Modeling
and Microsoft Visio
Microsoft Testing
3 Application centre
test, Microsoft test
framework
4 SVN Source Control
5 FxCop Code review
6 JIRA Bug reporting tool, Issue tracking tool

3.3 Size and Effort Estimation

The size and effort are subject to change in requirements. The figure quoted below is as
per the requirement analysis done on March 2008.

Size of the application

Effort Estimate 33500 manhours
Cost Estimate

Frontiers Internet System V2.0 Confidential Page 11 of 22

3.4 Effort Distribution Planned

Effort Distribution
Phase/Activity Percentage of Total Effort
Analysis 5
Design 5
Construction 50
Testing 30
PM activities 5
QA Activities 5

3.5 Schedule

Detailed schedules of the project will be maintained in Sprint plan files. Please refer to the
Sprint schedules for the project.

3.6 Causal Analysis and Resolution

The Offshore PM coordinates and organizes the defect prevention activities for the project.
The type of defects to be prevented for the project is identified from the organization’s
common defect database. The preventive actions for the root cause of the defects are
planned and scheduled.
Defect prevention kickoff meeting is conducted immediately after the project kick-off
meeting and the DP follow–up meetings are conducted at the start of each phase. PM
organizes these meetings. Agenda for the meeting includes:

 Type of defects to be prevented

 Root cause of the defects
 Preventive action scheduled for each type of defect
 Responsibilities for the planned actions

The Project team participates in this meeting. The observations/action points are recorded
using MOM form.
Causal Analysis Report is used for recording the findings from causal analysis. Preventive
actions for the root causes are planned.

Frontiers Internet System V2.0 Confidential Page 12 of 22

The effectiveness of the preventive actions taken is analyzed by monitoring the recurrence
of defects, and the corrective actions are taken.

3.7 Risk Management Plan

The Project Manager will maintain a risk catalogue with a risk mitigation plan, which will
assist in tracking, identified risks through to closure. The general categories of risks that
will be identified and managed include risks of strategic, operational, technological and
financial nature.
Risk Classification Operational
Risk Identified Loss of key people from Project
The loss of key people like Project Managers, senior leaders
from project might impact the successful execution of the
Description
project.

There will be back up resources for the key roles identified

Mitigation Plan in the project. Bigger team size than the one planned in the
schedule will be maintained.

Risk Classification Operational

Risk Identified Change in Requirements and Work flow
Changes in requirement scope and functionalities during
the development stage will impact the effort, schedule &
Description
cost of the project

Changes to approved requirements to be taken up through

Mitigation Plan
the change management process.

Risk Classification Operational

Risk Identified Delay in procuring third party tools
Third party tools which have to be integrated and
Description customized for the system must be available before the
start of the development phase.
Mitigation Plan Customer should provide all the required Third party tools.

Risk Classification Operational

Risk Identified Team skill level
Lack of adequate skills in the team can impact the quality
Description
of deliverables to Frontiers.
Mitigation Plan Extensive training programs, including domain, process

Frontiers Internet System V2.0 Confidential Page 13 of 22

 and technology, will be planned for the skill development.
Staff playing critical roles will undergo role based training.

Risk Classification Operational

Risk Identified Delay in hardware procurement
Any necessary hardware required for deploying the site
Description
has to be purchased by the customer.
Customer should provide all the hardware necessary for
Mitigation Plan
successful deployment of the site.

Risk Classification Strategic

Risk Identified Disaster Recovery and Business Continuity Planning
Natural Calamities and unprecedented incidents due to
Description
which there is a loss of data.
PITS can develop Disaster Recovery and Business
Continuity planning process for Frontiers. The process
Mitigation Plan
involves setting of a high-end Storage Area Network (SAN)
which is outside the scope of this proposal.
Table 1: Risk Management Plan

3.8 Verification Plan

The verification of the project outputs will be done via peer review and quality audits. The
code review and test review will done on the basis of corresponding checklists.

Seria Phase / Activity / Work % Of

l No. Product Peer % Of onsite Review
Review
1 Onsite Documents 100 0
2 SRS 100 100
3 Estimate 100 100
4 Project Plan & SCM Plan 100 100
5 High Level Design 100 100
6 System Test Plan 100 100
7 Integration Test Plan 100 100
8 Unit Test Plan 15 15
9 Program 15 50

Frontiers Internet System V2.0 Confidential Page 14 of 22

 Specifications/Component
Specifications
10 Source Code 100 15
11 Test results 15 100

The responsibility for verification of implementation of all planned reviews and closing of
the review comments are given below.

Serial No. Deliverables Responsibility

1 Code PL
2 Test plans Test Manager
3 Test Results Test Manager
4 Detailed Design specification PM
5 Database design PM

3.9 Testing and Validation Plan

The testing of the software will be done at various levels starting from unit testing by the
programmer, functional testing using test specifications by the test engineers, and System
and load testing by the test team.

3.9.1 Unit Testing

The development approach will be a test driven approach. Test cases will be defined for
each programming unit before the coding starts and once the coding is finished, the defined
tests should run successfully. This is to ensure that any future modification of the source
code will not result in the failure of old features.

3.9.2 Functional Testing

Functional testing of each delivery module according to pre approved test specifications
will be conducted by the test team attached to the module. All errors and bugs will be
reported in the JIRA (Issue tracking) tool. A test report will be generated at the end of each
round of testing and this will be send to customer along with the software delivery.

Frontiers Internet System V2.0 Confidential Page 15 of 22

 3.9.3 Load Testing

Functional testing of each delivery module according to pre approved test specifications
will be conducted by the test team attached to the module. All errors and bugs will be
reported in the JIRA (Issue tracking) tool. A test report will be generated at the end of each
round of testing and this will be send to customer along with the software delivery.

3.10 Training Plan

The project execution is planned in Microsoft Windows Sharepoint Server. Since around
90% of the team identified at PITS does not have this skill set, a training from Microsoft
WSS trainers is planned.

Partic
Serial Training Facult Duratio Coursewa Remar
ipant Planned Date
No. Program y n re ks
s
1 Seed Team 14.05.2009 3 days WSS
Sharepoint InfoTe
Training ch,
Pune

3.11 Requirements Management Plan

A requirement traceability matrix will be maintained in the Docs/QAdocs folder of

Frontiers project folder. All requirement documents prepared in discussion with customer
are available inside Specifications/frontiers2.

The base line requirements documents will be fixed after the business analysis phase and
any change to these documents will be monitored under the change control procedures
outlined for the project.

3.12 Integration Plan

The various elements/ components of the project need to be integrated. An Integration

plan needs to be created for this. The document will be updated later with the reference to
the Integration Plan for the project.

Frontiers Internet System V2.0 Confidential Page 16 of 22

3.13 Project Meetings

The project management methodology adapted is the Agile method using Scrum. So the
offshore project meeting will be planned according to this methodology. The following
meetings will be conducted as part of the project management process.

3.13.1 Daily Scrum

Each day during the sprint, a project status meeting occurs. During the meeting, each team
member answers three questions:
 What have they achieved since the last meeting? (Yesterday)
 What will they achieve before the next meeting? (Tomorrow)
 Is anything holding up their progress? (‘Impediments’)

And PITS Team strictly adheres to the sprint plan.

3.13.2 Sprint Planning Meeting

At the beginning of the sprint cycle (every 30 days), a "Sprint Planning Meeting" is held.
The purpose of the meeting is to identify the three objectives listed below.

 Select what work is to be done

 Prepare the Sprint Backlog that details the time it will take to do that work

This meeting has an 8 hour time limit.

3.13.3 Sprint Review Meeting

At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the
"Sprint Retrospective". The purpose of the meeting is to identify the three objectives listed
below.

 Review the work that was completed and not completed

 Present the completed work to the stakeholders (a.k.a. "the demo")
 Incomplete work cannot be demonstrated

This meeting has a 4 hour time limit.

Frontiers Internet System V2.0 Confidential Page 17 of 22

 3.13.4 Sprint Retrospective

All team members reflect on the past sprint. The objective of this meeting is to make
continuous process improvement. Two main questions are asked in the sprint
retrospective:

 What went well during the sprint?

 What could be improved in the next sprint?

This meeting has a 4 hour time limit.

Every week, the offshore and onsite Project Managers will conduct a conference call, and
Offshore PM will prepare the MOM which will be sent to the project stakeholders. This will
be kept as a record.

3.14 Review by Project Manager

The PM will verify project activities every week and on specific milestones, using the
Project Manager’s Review checklist. The Project Manager will also review the status report.
The observations / action items identified during these reviews will be documented in the
PM review report and tracked to closure.

3.15 Formal Project Review

Formal project reviews are conducted after each milestone. The Project Leader, Project
Manager and a representative of the senior management participate in this review. If there
are any outstanding issues between the project group and support groups or there are
changes in the project that affect the support groups a representative of the group is
invited to join the review meeting. The PL organizes the formal reviews. The agenda for the
meeting will be circulated in advance.
The following items will be used to decide the agenda:
 Review the project progress in terms of milestones, deliverables and outstanding
issues
 Quality Goals
 Metrics Data for Defect Density, Productivity, Defect Detection Effectiveness,
Schedule Variation, Estimate Variation, Defect Prevention Effectiveness and Other
process metrics
 Product Characteristics
 Causal Analysis
Frontiers Internet System V2.0 Confidential Page 18 of 22
  Customer Feedback
 NCR Closures
 Verification of PM’s review
 Lessons learnt / good practices – use of this for re-planning
 Discussion on issues or changes in commitment expected from the support groups

The observations and action points will be recorded using MOM Form.

3.16 Status Reporting

The PM/PL keeps track of the activities in the project. The status is reported on a weekly
basis using the Weekly Project Status Report.
The Offshore PM will send a weekly status report to the Onsite PM. A consolidated monthly
status report will be sent to project stakeholders.

3.17 Issue Management

During the course of the project, the project team will identify different issues that are to be
tracked to closure. The issue tracker tool (JIRA) would have the issue, the resolution, the
raised and closed dates, the status of the issue which tracks effectiveness of the prescribed
resolution provided and the impacted artifacts on which the solution will be implemented.

3.18 Configuration Management Plan

The configuration management plan for the project maintains the versions of the identified
configurable items in a document. The latest version list for the configurable is kept in the
project folder file Abstracts/Configurationlist.xls.

Configurable Item Remarks

Functional document Document revisions will be maintained with detailed

revision history.
UML designs Change control procedure

Frontiers Internet System V2.0 Confidential Page 19 of 22

 Database Designs Change control procedure

Software Microsoft Visual Source Safe

Test specifications Change control procedure

3.18.1 Change Control Procedure

Changes can originate either from PITS or Frontiers Team and it can arise due to different
reasons as follows:
 Upgrade to FIS to make it compatible with changes in database, browser, application
server
 New features voluntarily provided by PITS
 New features specifically requested by Frontiers

A Change Control Board (CCB) will be set up for FIS Project, which will consist of Frontiers
Project Manager, PITS Project Manager, Configuration Manager and other technical
members of the project. The CCB will evaluate the impact of any change in terms of
functionality, effort, schedule and cost.

At any time prior to the acceptance date agreed between PITS and Frontiers, Frontiers may
request or recommend, changes to any part of the project or the deliverables to the Change
Control Board. The change will be raised as a formal Change Request (CR). The CR will be
evaluated at PITS and the impact in terms of functionality, effort and schedule will be
communicated to Frontiers who will approve the CR before it is taken up for development
at PITS. The required changes will be made in the impacted components and they will be
base-lined after undergoing the quality verification and validations.

The changes proposed to the application after go-live, will be managed by the PITS
Maintenance Team. An illustration of the change management process at PITS is depicted
below:

Frontiers Internet System V2.0 Confidential Page 20 of 22

 Frontiers/PIT S PITS

Change Request Impact Analysis

Frontiers

Approve Change Design &

Request Development

RMP Testing

Accepted Close Change

Request

RMP – Release Management Plan

Change Management Plan

The records of each stage of the change control process will be documented inside the
project folder Prjmgmt/Changes/(Change request, Change Analysis, Change Approval)

Frontiers Internet System V2.0 Confidential Page 21 of 22

4 Quality Plan

4.1 Quality & Process Performance objectives

The quality assurance method for each stage of the project is planned in the table below.

Stage Input Output Verificat Documents

ion and prepared
Validati
on
Method
Requirements Contract/Proposal SRS Peer Functional
Review, document
Prototyp
ing

Design (high level) SRS HLD Peer High level

Review architecture
document
Design (low level) HLD LLD Peer Detailed
Review design
specifications
Development HLD, LLD Software Peer NA
Review
Testing SRS Test spec Peer Test
review specifications

The quality metrics will be taken according to the measurement plan defined for the
project.

4.2 Quality Goal Tracking

The quality goal need to tracked and updated continuously. The measures taken to achieve
these goals also need to be monitored. Offshore and Onsite Project Managers maintains this
tracker.

Frontiers Internet System V2.0 Confidential Page 22 of 22