PROJECT PLAN
Organization: CERN – LCG project
Project name
LCG Software Process & Infrastructure (“SPI”)
Document Revision #: 1.0
Date of Issue: 11.10.2002
Project Manager: Alberto Aimar
Project Plan
LCG Software Process & Infrastructure
Approval Signatures
Approved by:
Prepared by:
Business Project Leader
Business Project Manager
Approved by:
Prepared by:
Reviewed by:
< Insert Revision Number and Date of Issue >
Project Leader
Project Manager
Quality Assurance Manager
Page i
Project Plan
LCG Software Process & Infrastructure
Table of Contents
1.
Project Overview .......................................................................................... 1
1.1 .. Purpose, Scope, and Objectives ..................................................................................... 1
1.2 .. Assumptions, Constraints and Risks ............................................................................... 3
1.3 .. Project Deliverables ......................................................................................................... 3
1.4 .. Schedule and Budget Summary ...................................................................................... 4
1.4.1 Internal resources needed .................................................................................................... 4
1.4.2 External resources needed ................................................................................................... 4
1.5 .. Evolution of the Plan ........................................................................................................ 4
1.6 .. References ....................................................................................................................... 5
1.7 .. Definitions and Acronyms ................................................................................................ 5
2.
Project Organization .................................................................................... 6
2.1 .. External Interfaces ........................................................................................................... 6
2.2 .. Internal Structure ............................................................................................................. 6
2.3 .. Roles and Responsibilities ............................................................................................... 7
3.
Managerial Process Plans ........................................................................... 8
3.1 .. Start-up Plan .................................................................................................................... 8
3.1.1 Estimates .............................................................................................................................. 8
3.1.2 Staffing ................................................................................................................................. 9
3.1.3 External Help Needed ........................................................................................................ 10
3.1.4 Resource Acquisition .......................................................................................................... 10
3.1.5 Project Staff Training .......................................................................................................... 11
3.2 .. Work Plan.......................................................................................................................12
3.2.1 Work Breakdown Structure ................................................................................................. 12
4.
Technical Process Plans ........................................................................... 17
4.1 .. Process Model ...............................................................................................................17
4.2 .. Methods, Tools, and Techniques ...................................................................................18
4.3 .. Infrastructure ..................................................................................................................18
4.4 .. Product Acceptance .......................................................................................................19
5.
Supporting Process Plans ........................................................................ 19
5.1 .. Configuration Management............................................................................................19
5.2 .. Verification and Validation .............................................................................................20
5.3 .. Documentation ...............................................................................................................20
5.4 .. Quality Assurance ..........................................................................................................21
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page ii
Project Plan
LCG Software Process & Infrastructure
5.5 .. Reviews and Audits .......................................................................................................21
5.6 .. Problem Resolution ........................................................................................................22
5.7 .. Subcontractor Management...........................................................................................22
5.8 .. Process Improvement ....................................................................................................22
6.
Additional Plans ......................................................................................... 23
7.
Project Evolution........................................................................................ 23
7.1 .. Project support and maintenance ..................................................................................23
7.2 .. Follow-up projects ..........................................................................................................23
Annexe A “Component Document” template ................................................. 24
1. Description of the component ............................................................................................24
1.1 Purpose of the component ..................................................................................................... 24
1.2 Deliverables ........................................................................................................................... 24
1.3 Known problems and restrictions ........................................................................................... 24
1.4 Repository of the component ................................................................................................. 24
2 Technology surveys ............................................................................................................24
2.1 Contacts ................................................................................................................................ 24
22 External references ................................................................................................................ 25
3 Analysis of the component ..................................................................................................25
3.1 Glossary ................................................................................................................................ 25
3.2 Main Requirements - List of functionalities ............................................................................ 25
7.2.1. 25
4 Usage guide ........................................................................................................................25
4.1 How to use the component .................................................................................................... 25
4.2 Example of usage and links to documentation ...................................................................... 25
4.3 Solutions to common problems.............................................................................................. 25
5 To do list ..............................................................................................................................25
Annexe B: Removed sections from Templates .............................................. 28
7.3 .. Project Tracking Plan .....................................................................................................28
7.3.1 Requirements Management ............................................................................................... 28
7.3.2 Schedule Control ................................................................................................................ 28
7.3.3 Budget Control.................................................................................................................... 28
7.3.4 Quality Control .................................................................................................................... 29
7.3.5 Reporting ............................................................................................................................ 29
7.3.6 Project Metrics .................................................................................................................... 29
7.4 .. Risk Management Plan ..................................................................................................29
7.5 .. Project Closeout Plan ....................................................................................................30
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page iii
Project Plan
LCG Software Process & Infrastructure
Document Change Control
This section provides control for the development and distribution of revisions to the
Project Charter up to the point of approval. The Project Charter does not change
throughout the project life cycle, but rather is developed at the beginning of the project
(immediately following project initiation approval, and in the earliest stages of project
planning). The Project Charter provides an ongoing reference for all project stakeholders.
The table below includes the revision number (defined within your Documentation Plan
Outline), the date of update/issue, the author responsible for the changes, and a brief
description of the context and/or scope of the changes in that revision.
Revision Number
Date of Issue
Author(s)
Brief Description of Change
1.0
1.9.2002
AAim
Initial Draft
2.0
23.9.2002
AAim
Revised before T. Wenaus
review
3.0
30.9.2002
T Wenaus
Revisions
4.0
1.10.2002
AAim
Added T. Wenaus comments
5.0
10.10.2002
AAim
Add comment from PEB
meeting
Note
Template is derived from the “IM/IT Project Plan Template” of the Treasury
Board of Canada Secretariat
URL:
http://www.cio-dpi.gc.ca/emf-cag/ppto-gtpss/projplantemplate/ppt-mpp00_e.asp
Organisation
Owner
Title/Subject
Approved by
Date
Number
Version
Page iv
Project Plan
LCG Software Process & Infrastructure
1. Project Overview
This section of the Project Management Plan provides an overview of the purpose,
scope and objectives of the project for which the Plan has been written, the project
assumptions and constraints, a list of project deliverables, a summary of the project
schedule and budget, and the plan for evolving the Project Management Plan.
1.1 Purpose, Scope, and Objectives

Define the purpose and scope of the project.
The goal of the project is to provide a software infrastructure and a process to
the software projects that are being deployed in the LCG Application Area.
The goal of the project is to provide:
−
−
−
−
basic environment for physics SW development
general scientific libraries class libraries for PP applications
software development tools
documentation tools and document templates
and the support activity necessary to ensure that a common grid-enabled
environment is available.

Describe any considerations of scope or objectives to be excluded from the
project or the deliverables.
The project should use or adapt existing software tools where possible. Tools
from the LHC, HEP, open software and commercial software communities will
be used.
The goal of the project is to define and develop a process and an infrastructure.
The future maintenance of the infrastructure beyond LCG phase 1 will need
separate planning and resources.

Ensure that the statement of scope is consistent with similar statements in
the business case, the project charter and any other relevant system-level or
business-level documents.
The reason for such a Process & Infrastructure project is to have homogeneity
in the development of the different software packages of the LCG application
area.
The reference for the work of the project is the requirements specified in the
document RTAG2 Final Report (6 May 2002): “Managing LCG Software”.
The general recommendations of the above RTAG can be summarized as:
−
Organisation
CERN – LCG project
Owner: A.Aimar
All LCG projects must adopt the same set of tools, standards and
procedures
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 1
Project Plan
LCG Software Process & Infrastructure
−
−
−

Adopt commonly used open-source or commercial software where
available
Avoid “do it yourself solutions”
Avoid commercial software that may give licensing problems
Identify and describe the business or system needs to be satisfied by the
project.
The LCG project will involve several software projects that are being launched
and therefore to have a common infrastructure will provide an environment that
will allow:
−
−
−

Cost reduction by having projects that will share resources both in
terms of global effort to maintain a project infrastructure, sharing of
common services and of hardware equipment, of software licenses,
etc.
Easier exchange of information and communication among projects
A more advanced infrastructure than if each individual project was
building its own.
Provide a concise summary of:
−
−
−
the project objectives,
the deliverables required to satisfy the project objectives, and
the methods by which satisfaction of the objectives will be determined.
The project objectives are to provide to the LCG projects an infrastructure for
the:
−
−

Components of the software development phases, such as
development, testing, documentation, planning;
General services needed by any project, such as a repository, a
project web site, collaborative facilities, etc.
Describe the relationship of this project to other projects.
The SPI project is going to work mainly in providing services and facilities for
the other LCG software projects (e.g. Pool, the LCG persistency project). But its
artefacts will be of general use and therefore available to all LHC experiments
and to other projects.

If appropriate, describe how this project will be integrated with other
projects or ongoing work processes.
The SPI project will use as much as possible existing procedures and services
available in HEP, at CERN and in the experiments. The integration and usage
of such service is an important goal of the project.

Provide a reference to the official statement of project requirements (e.g.: in
the business case or the project charter).
RTAG2 Final Report (6 May 2002): “Managing LCG Software”.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 2
Project Plan
LCG Software Process & Infrastructure
1.2 Assumptions, Constraints and Risks

Describe the assumptions on which the project is based.
The SPI project assumes that it will be possible to define a decision mechanism
whenever more than one solution is available and there are discrepancies on
which is the solution to be adopted. Due to the minimal allocation of resources
any of such disagreements will slow down considerably the deployment of the
project itself.
The SPI project is also based on the goodwill of the user community to help in
the definition and in their contribution to the implementation of the
infrastructure.

Describe the imposed constraints and risks on the project such as:
−
−
−
schedule, budget, resources, quality,
software to be reused, existing software to be incorporated,
technology to be used, and external interfaces.
The project must deliver its components individually, as soon as they become
available, so that they can be used by the LCG projects, and by other projects
in the Laboratory that wish to do so.
A first release of the components should be available by the end of 2002,
beginning 2003. Which components will be available at that date is specified in
the planning and WBS sections.
The resources are those made available currently, or those known to be
assigned to the project in the future. Clearly when there will be assignments of
new staff, or staff with different seniority, then the project plan will be modified
accordingly.
1.3 Project Deliverables

Identify and list the following, as required to satisfy the terms of the project
charter or contract:
−
−
−
project deliverables (either directly in this Plan, or by reference to an
external document),
delivery dates, delivery location, ands
quantities required.
The deliverables and all details on the artefacts are in the Planning and WBS
sections that follow. In general terms, a first release should be available end of
2002 beginning 2003.

Specify the delivery media.
All deliverable of the SPI project will be available in these forms:
−
Organisation
CERN – LCG project
Owner: A.Aimar
AFS delivery area where can be accessed directly all the artefacts
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 3
Project Plan
LCG Software Process & Infrastructure
−

Web-based access for the deliverables such as templates,
collaborative facilities, etc.
Pre-installed software library and tools on a public AFS area.
−
Specify any special instructions for packaging and handling.
1.4 Schedule and Budget Summary

Provide a summary of the schedule and budget for the project.

Restrict the level of detail to an itemization of the major work activities and
supporting processes (e.g.: give only the top level of the work breakdown
structure).
This estimation is for the period 2003-2005 assumes a stable development of
the project along the lines depicted in this plan; if there will changes in the
mandate or objectives the budget will need to be redefined.
In any case the budget of the project should be assessed and updated on an
early basis from the project start up.
1.4.1
Internal resources needed
The resources needed to run the project are as follows:
−
Desktop hardware needed. The staff will join the SPI project and the
move to new LCG projects; and they will keep their hardware when
change project.
The groups at CERN will provide about 10 equipped pcs/year.
−
Specific hardware for the LCG project infrastructure for servers and
hardware upgrades. 30 KCHF/year
Software acquisition and licenses for SPI pcs and servers. 20
KCHF/year
Expenses for participation workshops and conferences where to
present the infrastructure and meeting LCG groups of users (provided
by the group at CERN, ~20-25 KCHF/year) .
−
−
1.4.2
External resources needed
As much as possible the existing IT services will be used and therefore there be
the need of changing, adapting or increase some of the services (e.g. CVS
server, AFS file system, computer center, lxplus, lxbatch, Nice, etc).
So some resources will be needed by the existing IT services for these new
activities and may be estimated to 150 KCHF/year.
1.5 Evolution of the Plan

Identify the compliance of this Plan to any standards.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 4
Project Plan
LCG Software Process & Infrastructure
The structure of this Project Plan is in compliance with the recommendations of
IEEE Std 1058-1998, because of the dcoument template used.

Specify the plans for producing both scheduled and unscheduled updates to
this Plan.
The project plan should be revised every four or six months in order to reflect
the changes in staffing and policies of the LCG.
For the SPI a good time for a new plan will be early 2003 in order to plan the
second release and the maintenance of the artefact of the first release.

Specify how the updates to this Plan shall be disseminated.
The updates will be presented to the SC2 together with the tracking of the
existing plan.

Specify how the initial version of this Plan shall be placed under
configuration management.
As soon as the SC2 committee agrees to this planning, it will be used as a
baseline for project tracking of the current release in the project repository.

Specify how changes to this Plan shall be controlled after its issue.
The agreed plan will be controlled and tracked quarterly and at that point
changes proposed will be evaluated and inserted in the current planning.
1.6 References
The reference documents for this project are the LCG public documents
published to date.
The main reference is the RTAG document specifying the requirements for this
project: RTAG2 Final Report (6 May 2002): “Managing LCG Software”.

Provide a complete list of all documents and other sources of information
referenced in this Plan.

Identify each referenced document by title, report number, date, author and
publishing organization.

Identify other referenced sources of information, such as electronic files,
using unique identifiers such as path/name, date and version number.

Identify and justify any deviations from the referenced standards or policies.
1.7 Definitions and Acronyms

Define, or provide references to documents or annexes containing the
definition of all terms and acronyms required to properly understand this
Plan.
SPI: Software Process & Infrastructure. The project defined in this document.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 5
Project Plan
LCG Software Process & Infrastructure
RTAG: Requirements Technical Assessment Group.
2. Project Organization
2.1 External Interfaces

Describe the organizational boundaries between the project and external
entities.

Identify, as applicable:
−
the parent organization,
The project reports to the LCG Application area manager T.Wenaus, to the
PEB headed by L. Robertson and to the SC2 committee chaired by
M.Kasemann.
−
the customer,
In its current project definition, the users of the deliverables of the project are all
the LCG software projects and any other CERN experiment interested in using
part or the entire infrastructure. The first of such users is the Pool project,
defining a persistency framework for the LHC projects.
−
subcontracted organizations, and
No subcontracting. In case of specific collaboration it is specified in the WBS
with which body (experiment, external centres, universities, etc.) the component
is implemented.
−
other organizational entities that interact with the project.
The project will interact with all LHC experiments and with the main projects at
the Laboratory (Geant4, Root, etc.) in order to receive advice and feedback.

Use organizational charts or diagrams to depict the project's external
interfaces.
2.2 Internal Structure

Describe the internal structure of the project organization.
Project Leader: Alberto Aimar

Describe the interfaces among the units of the development team.
The team is small so there are not defined units in it at the moment.
The project members are:
People
Organisation
CERN – LCG project
Owner: A.Aimar
Commitment Comments
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 6
Project Plan
LCG Software Process & Infrastructure
People
Commitment Comments
Manuel Venancio GALLAS
TORREIRA
100%
From 08.2002
Luis MANCERA PASCUAL
100%
In SPI since 08.2002
Lorenzo MONETA
50%
Andreas PFEIFFER
50%
William (Max) SANG
50%
[Software tools responsible]
100%
From 01.2003
[Software developer]
100%
From 11.2002
[Swiss LCG positions]
2 x 100%
From10.2002
Many people are also involved in other projects and their real availability in the
future is crucial to the development of the project. Therefore their participation
must be defined and assured.

Describe the interfaces between the project and organizational entities that
provide supporting processes, such as configuration management, quality
assurance, and verification and validation.
The project is creating an infrastructure for the LCG software projects, and will
use itself the infrastructure that it will deliver to the projects.
In addition to this all services created will be validated by using them ourselves
and also in helping the user projects, by participating so some time to their
activities that use our infrastructure.

Use organizational charts or diagrams to depict the lines of authority,
responsibility and communication within the project.
2.3 Roles and Responsibilities

Identify and state the nature of each major work activity and supporting
process.
The major work activities of the project are those in charge of defining,
implementing and delivering the two main types of artefact:
−
Organisation
CERN – LCG project
Owner: A.Aimar
Components of the software development phases, such as
development, testing, documentation, planning;
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 7
Project Plan
LCG Software Process & Infrastructure
−

General services needed by any project, such as a repository, a
project web site, collaborative facilities, etc.
Identify the organizational units that are responsible for those processes and
activities.
The support of the General Services requires the following roles and human
resources for a total of 7 FTE in the project for the App. Area:
−
−
−
−
−
−
−
Release manager
Librarian
Tool responsible
Tool development
QA
Web support
Documentation
In addition to the maintenance in the initial phase the main work is the definition
and the implementation of the components and of the services. Therefore the
proposed resources are going to be:
−
−

5 FTE for the next 6 months
Developing, maintaining and modifying components and services
Consider using a matrix of work activities and supporting processes vs.
organizational units to depict project roles and responsibilities.
3. Managerial Process Plans
This section of the Project Management Plan specifies the project management
processes for the project. This section defines the plans for project start-up, risk
management, project work, project tracking and project close-out.
3.1 Start-up Plan
3.1.1
Estimates

Specify the estimated cost, schedule and resource requirements for
conducting the project, and specify the associated confidence levels
for each estimate.
The plan has been produced by the project leader after two months in the
project and based on the perception of the objectives and of the existing skills
available in the project.

Organisation
CERN – LCG project
Owner: A.Aimar
Specify the methods, tools and techniques used to estimate project
cost, schedule and resource requirements;
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 8
Project Plan
LCG Software Process & Infrastructure

Specify the sources of estimate data and the basis of the estimation
such as: analogy, rule of thumb, standard unit of size, cost model,
historical database, etc.
The rule of thumb used for each component of the project has been to estimate:
1/3 of the time for the component definition, 1/3 for the definition of the solution
and 1/3 for the implementation of the solution.

Specify the methods, tools, techniques to be used to re-estimate the
project cost, schedule and required resources.
Weekly status and progress meetings will provide data for improvement of
these rules of thumb, for the planning of the second release.

Specify the schedule for re-estimation, which might be regular, a
periodic or event-driven (e.g.: on project milestones).
The schedule will be re-estimated after 3 months or in the event of major
changes in the policies regarding the project objectives, such as urgent needs
of the coming LCG software projects currently at the RTAG definition phase.
3.1.2
Staffing

Specify the number of required staff, providing the following
details:
− number of personnel by skill level,
− numbers and skill levels in each project phase, and
− duration of personnel requirement.
A more experienced staff would probably execute the project in a much faster
way. But the goal is to build the infrastructure by putting together the
experiences already available in the Laboratory (experiments and big projects)
and with not very experienced staff: the goal of the project is also to train future
members that will join future LCG projects.
The staffing process will have to reach the amount of resources specified in
section 2.3 by the beginning of 2003.

Specify the sources of staff personnel (e.g.: internal transfer, new
hire, contracted, etc.)
The resources for the project are coming from the IT/API group; see section 2.2
in this document. Other resources are from the LCG recruiting activities and to
a limited degree from the LHC experiments.
Resources from the experiments are very valuable in order to bridge the gap
between the project and its users.
To match needs and evolution of LCG staff, the plan and the resources should
be reviewed every 6 months. If some products will need to be maintained by the
SPI project, the project will need to be staffed adequately (e.g. configuration
management tool)
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 9
Project Plan
LCG Software Process & Infrastructure

Consider using resource Gantt charts, resource histograms,
spreadsheets and tables to depict the staffing plan by skill level, by
project phase, and by aggregations of skill levels and project phases.
The Gantt chart will be available (on the SPI project web) as soon as more
resources become clear because currently the timescale of acquisition of new
resources in under definition.
3.1.3
External Help Needed
The project is going to define the LCG infrastructure by trying to use as much
as possible:
−
the existing IT services for what concerns installations (hardware,
software, operating systems, database, etc.) and the support that they
are providing;
the existing artefacts and tools already available and developed in the
Experiments and in IT.
−
Some people could come to developed and maintain components in SPI
−
−
from LHC experiments which have developed them
from existing staff in the Laboratory
but this will need to be discussed only when, and if, the opportunity will be
available.
3.1.4
Resource Acquisition

Specify the plan for acquiring the resources and assets, in addition to
personnel, needed to successfully complete the project.
It is agreed that hardware and other resources come from IT division via
standard purchase procedures. No special acquisition is needed for this project.

Describe the resource acquisition process.

Specify the assignment of responsibility for all aspects of resource
acquisition.
Resource acquisition is the responsibility of the Project Leader for what
concerns the internal SPI resources, all resources needed at Application Area
level will be acquired after written agreement of the Applications Area Manager
(T.Wenaus).

Specify acquisition plans for equipment, computer hardware and
software, training, service contracts, transportation, facilities, and
administrative and janitorial services.
Offices are being freed in Building 32 but currently not at a pace that helps the
project to deploy and be effective.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 10
Project Plan
LCG Software Process & Infrastructure

Specify when in the project schedule the various acquisition
activities will be required.
When the first release will be available (beginning 2003) servers, or services,
will need to be put in place to have 24 hours availability of the infrastructure, in
terms of hardware but also of maintenance of the few crucial services (CVS,
Web access, etc). This does not mean necessarily acquisition of new material
but clear assignment of material for development and material for delivery, as
well as responsibility among staff of the different support services.
3.1.5

Specify any constraints on acquiring the necessary resources.

If necessary, expand this subsection to lower levels, to accommodate
acquisition plans for various types of resources.
Project Staff Training

Specify the training needed to ensure that necessary skill levels in
sufficient numbers are available to successfully conduct the project.
Most of the training of people will be done on the job, by learning from the
experience already available in the LHC experiments and in other big projects
(Geant4, Root, etc.).

Specify the following training information:
− the types of training to be provided,
− numbers of personnel to be trained,
− entry and exit criteria for training, and
− the training method, for example: lectures, consultations,
mentoring, computer-assisted training, etc.
No specific training is foreseen for now; except allocating enough time for
people to get acquainted with a specific topic they are assigned to.
The training will mostly be done by learning on the job, with help of existing
experts in the Laboratory, both from Experiments and from IT division. Their
availability will be very important to have newcomers getting knowledgeable
about specific topics.
The people in the project need to learn about the topic and also to see what is
being done in the same field in existing projects in the Laboratory as well in the
external world.

Organisation
CERN – LCG project
Owner: A.Aimar
Identify training as needed in technical, managerial and supporting
activity skills.
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 11
Project Plan
LCG Software Process & Infrastructure
3.2 Work Plan
3.2.1
Work Breakdown Structure

Define a Work Breakdown Structure (WBS) to specify the various
work activities to be performed in the project, and to depict the
relationships among these work activities.
The goal of the project is to provide (1) a set of common services available to
all the LCG projects and (2) a standard way to approach the different phases of
the development life cycle.
The WBS reflects this decomposition strategy: (1) each service becomes a
work package and as well as (2) each component of software development.
Each service and component will be a run as a sub-project with a responsible
staff in the LCG SPI project that will have to:
−
−
−
Understand and learn the subject
Know and find who knows about the subject
Provide practical solutions, usable independently from the other
components
General services for
all LCG projects
Summary
Deliverables
Software Library
Product used by the LCG
Tools installed, web site to use
projects, pre-installed for all them, internal organization to
supported platforms
maintain the installations
SPI Tools
Tools available to the LCG
projects in order to use the
SPI infrastructure
Tools installed, web site to use
them, internal organization to
maintain them
CVS server
CVS server available to all
LCG App projects
Server available, project assigned
to areas, support
Web server
Web server for Developer
and User Web
Server available, project assigned
to areas, support
AFS delivery area
App delivery area on AFS
Server available, project assigned
to areas, support
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 12
Project Plan
LCG Software Process & Infrastructure
General services for
all LCG projects
Build platform
Summary
Deliverables
Platforms to compile the
LCG packages and run the
global tests
Server available, project assigned
to areas, support
Components for each
Summary
LCG App projects
Deliverables
Code documentation
Doxygen, LXR, cvsweb,
viewcvs, etc.
Script to generate
documentation, examples, and
manuals
CVS repository
structure
Structure for development,
directory tree etc.
Tree structure, scripts to
instantiate it
Testing
Sub package testing, Unit
testing, test descriptions
Test cases documents,
examples and scripts to run
them
Coding Conventions
Standard naming and
programming conventions
Coding convention document,
tool support
Configuration
management
Release and tagging strategy, Configuration management
with tool support
items, tagging, releases, make
files, and tool support
Development Web
Internal web for a software
project
Users Web
Web for the users of the
package/project
Nightly builds
Automatic build system
Automatic system to build
packages
Bug reporting
Forms and process to
manage bug and user
feedback
Web based system to report,
follow up close and store bugs
and feedback
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 13
Project Plan
LCG Software Process & Infrastructure
Components for each
Summary
LCG App projects
Deliverables
Planning material
Project plan, project reports,
risk management, etc
Project Software
Documentation
Documentation of sub
packages etc.
User specifications
Use cases, user stories, etc.
Software Design
Design templates and
patterns, design
documentation, etc
LCG Process
Definition
Definition of a standard
process using the
components already defined
This is a component that will
be defined progressively,
using the other above.
In addition to the decomposition for the creation of the deliverable artefacts
there is also the definition of the internal processes and artefacts.

Decompose the work activities to a level that exposes all project risk
factors, and that allows accurate estimation of resource requirements
and schedule duration for each work activity.
The estimations that follow include the whole process for a component from
understanding it to delivering a packaged solution widely useable.
−
Definition of the component, find what is available, learn about the
subject and become ready to implement the solution
− Implementation of the solution and checking with the users (here the
beta of the component will be available, after ~ 50% of the estimated
time)
− Helping the projects to use it by going to help them implementing the
component in the project
− Maintenance and support need to be done well and actively
− 20% contingency is included because it is a fact that many unexpected
problems may arise during any project.
It is also important to consider that many people are new to the topics they are
working on; so on the job training is included in the estimation.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 14
Project Plan
LCG Software Process & Infrastructure
Priority is referred to the first release. Only components of high priority will be
delivered in next release (1 = higher).
Component
Estimate (days)
Who
Priority
(1=High 3=Low)
Software Library
90
(tbd)
1
SPI Tools
30
(tbd)
1
CVS server
10
APFE
1
Web server
10
APFE
1
AFS delivery area
10
APFE
1
Build platform
10
APFE
1
Code documentation
30
LMAN
1
CVS repository structure
20
IPAP
1
Testing
60
MGAL et al.
Coding Conventions
20
MSAN
1
Configuration management
60
IPAP
1
Development Web
40
(tbd)
1
Users Web
40
(tbd)
1
Nightly builds
30
LMON
1
Bug reporting
20
(tbd)
1
Planning material
15
AAIM
2
Project Software
Documentation
15
(tbd)
1
(60)
(tbd)
2 for future releases
General services for all LCG
projects
Components for each LCG
App projects
User specifications
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
1 Unit testing
2 Integration testing
1 memory leaks
Number
Version 1.0
Page 15
Project Plan
LCG Software Process & Infrastructure
Component
Estimate (days)
Who
Priority
(1=High 3=Low)
(60)
(tbd)
3 for future release
Glossary
3
AAIM
1
Internal templates
5
AAIM
1
CVS repository structure
3
APFE, AAIM
1
Users web
20
(tbd)
1
Delivery area
5
(tbd)
1
Tools web
30
(tbd)
2
Users support
60
“ALL”
2 after first release
Software Design
SPI internal
−
−
Organisation
CERN – LCG project
Owner: A.Aimar

Specify the following factors for each work activity:
− necessary resources,
− estimated duration,
− products or deliverables of the activity,
− acceptance criteria for the work activity products, and
− predecessor and successor work activities.

The level of decomposition internally within the WBS may vary
depending on the quality of the requirements, familiarity of the
work, applicable level of technology, etc.

Schedule Allocation
December 2002 – Beta Version.
All components will be released and used as soon as they are
available independently. Therefore many components will be available
before as beta versions for project such as Pool or other that want to
use or contribute to them. Actually some are in use by Pool already.
February 2003 – Version 1.0
All components and services mentioned above will be available but for
the Software Library and the Project portal there will be basic
implementations and services.
This date seems tight if the deliverables needs to be widely used and
available. Therefore the project will need close monitoring whether
resources will need to be injected in November/December 2002.
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 16
Project Plan
LCG Software Process & Infrastructure
−
−
May 2003 - LCG Testbed – Version 1.1
Software Library, Project portal and all features
Standard templates and tools will be widely available.
Simple LCG software process
September 2003 – Version 2.0
LCG software process
Standards for user specifications
Design guidelines and specifications
4. Technical Process Plans
4.1 Process Model

Define the relationships among major project work activities and supporting
processes.
The different components will be all developed with a standard process that has
the goal of involving as much as possible the users and the existing experience
already available in the Laboratory.
The standard procedure for the implementation of each component will consist
in executing the following steps:
−
−
−
−
−
−
−

Survey of possible/existing solutions in HEP and free software
Meet the people expert and responsible of the component in existing
projects (LCG or experiments or big projects)
Discuss and agree/decide/verify a solution
Present the solution
Implement the solution and make it available to the users
Test the solution in the LCG SPI project itself
Refine implementation in light of experience in a real project (LCG or
experiment or big project)
Describe the flow of information and work products among activities and
functions.
When a component is launched the SPI Project Leader will ask experiments
and big projects to provide the list of people that can give advice and expertise
about the subject.
Once this list of experts is available it will be passed to the responsible of the
component that will proceed with the implementation procedure described
above.
Each component will deliver its solutions using standard templates and
procedure defined in the SPI project.

Specify the timing of work products to be generated.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 17
Project Plan

LCG Software Process & Infrastructure
Identify the reviews to be conducted.
Reviews of the project will be executed after the first release, beginning 2003.

Specify the major milestones to be achieved.
Already specified in the work plan and WBS sections.

Define the baselines to be established.
Already specified in the work plan and WBS sections.

Identify the project deliverable to be completed.

Specify the required approvals within the duration of the project.

In the process model for the project, include project initiation and project
termination activities.

Use a combination of graphical and textual notations to describe the project
process model.

Indicate any tailoring of your organization's standard process model for a
project.
4.2 Methods, Tools, and Techniques

Specify the development methodologies, programming languages and other
notations, and the processes, tools and techniques to be used to specify,
design, build, test, integrate, document, deliver, modify and maintain the
project deliverable and non-deliverable work products.

Specify the technical standards, policies, and procedures governing
development and/or modification of the work products.
The SPI internal infrastructure is based on standard procedures and templates
for the development of each component and services.
The SPI project will also use all components it defines for the LCG software
projects when they apply also to an infrastructure project as SPI.
All procedures and templates are extremely simple and practical in order to
make the useable in an heterogeneous software environment.
4.3 Infrastructure

Specify the plan for establishing and maintaining the development
environment (hardware, operating system, network and software), and the
policies, procedures, standards, and facilities required to conduct the
project. These resources may include workstations, local area networks,
software tools for analysis, design implementations, testing, and project
management, desks, office space, and provisions for physical security,
administrative personnel, and janitorial services.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 18
Project Plan
LCG Software Process & Infrastructure
The internal SPI infrastructure is already part of the work plan and WBS
sections above.
4.4 Product Acceptance

Specify the plan for customer acceptance of the deliverables generated by
the project.
All users of tools, templates and standards will be helped in using the
infrastructure as the top most important feature to get user acceptance.

Specify objective criteria for determining acceptability of the deliverables.
All tools, templates and standards defined are acceptable when approved by
the LCG Applications Area Manager

Reference a formal agreement of the acceptance criteria signed by
representatives of the organization and the customer.
Not available. But could be defined in the framework of the SC2 committee.

Specify any technical processes, methods, or tools required for deliverable
acceptance, such as testing, demonstration, analysis and inspection.
All solutions will be discussed and presented to experts in the experiments and
big projects before being proposed and presented publicly. Only when the LCG
Applications Manager approves the solutions they will be implemented.
5. Supporting Process Plans
5.1 Configuration Management

Specify or reference the configuration management plan for the project,
providing the information identified in the following lines.
All artefacts, both internal and for the users, will be (1) uniquely identified, (2) in
a repository in (3) version and configuration tags.

Specify the methods that will be used to perform the following activities:
−
−
−
−
−
configuration identification,
configuration control,
status accounting,
evaluation, and
release management.
Each component has a unique identifier and a standard repository substructure.

Specify the processes of configuration management including procedures
for the following activities:
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 19
Project Plan
LCG Software Process & Infrastructure
−
−
−
−
−

initial baselining of work products,
logging and analysis of change requests,
change control board procedures,
tracking of changes in progress, and
procedures for notification of concerned parties when baselines are
established or changed.
Identify the automated configuration management tools used to support the
configuration management process.
5.2 Verification and Validation

Specify or reference the verification and validation plan for the project,
providing the information identified in the following lines.

Specify the scope, tools, techniques and responsibilities for the verification
and validation work activities.
Being an infrastructure development the way to test it will be to use it, make it
available and get feedback from:

− Usage in the SPI project itself
− Helping some project to use each component of the SPI deliverables
− Making available at an early stage the deliverables
Specify the organizational relationships and degrees of independence
between development activities and verification and validation activities.
Each component and service will be verified as soon as it will become
available.

Specify the use of verification techniques such as traceability, milestone
reviews, progress reviews, peer reviews, prototyping, simulation and
modeling.

Specify the use of validation techniques such as testing, demonstration,
analysis and inspection.
It is part of the standard process to develop an SPI component and service to
have it verified by the users, both in presenting the component while developing
it and also by having all the artefacts always available.

Identify the automated tools to be used in verification and validation.
5.3 Documentation

Specify the plans for generating non-deliverable and deliverable project
documentation.
Each component will have a “component document” that will describe it
completely, in all its phases, from definition of the problem to description of the
solution.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 20
Project Plan
LCG Software Process & Infrastructure
The “component document” template is available as annex A to this project
plan.

Specify the organizational entities responsible for providing input
information, and for generating and reviewing the project documentation.

Specify the following information or object identification:
−
−
−
−
−
−
−
list of documents to be prepared,
controlling template or standard for each document,
who will prepare each document,
who will review each document,
due dates for review copies,
due dates for initial baseline versions, and
a distribution list for review copies and baseline versions and quantities
required
5.4 Quality Assurance

Specify or reference the quality assurance plan for the project, containing
the information identified in the following lines.

Specify the plans for assuring that the project fulfills its commitments to the
process and the product as specified in the requirements specification, the
Project Management Plan, supporting plans and any standards, procedures,
or guidelines to which the process or the product must adhere.

As applicable, specify the quality assurance procedures to be used, such as
analysis, inspection, review, audit, and assessment.

Indicate the relationship among the quality assurance, verification and
validation, review, audit, configuration management, system engineering,
and assessment processes.
5.5 Reviews and Audits
Currently it is not specified.

Specify the schedule, resources, and processes, and procedures to be used in
conducting project reviews and audits.

Specify the plans for joint customer-project reviews, management progress
reviews, developer peer reviews, quality assurance audits, and
customer-conducted reviews and audits.

List the external agencies that approve or regulate any project deliverable.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 21
Project Plan
LCG Software Process & Infrastructure
5.6 Problem Resolution

Specify the resources, methods, tools, techniques and procedures to be used
in reporting, analyzing, prioritizing and processing problem reports
generated during the project.

Indicate the roles of development, configuration management, the change
control board, and verification and validation in problem resolution work
activities.

Provide for separate tracking of effort expended on problem reporting,
analysis and resolution, so that rework can be tracked and process
improvement accomplished.
5.7 Subcontractor Management
Currently does not apply to this project.

Specify or reference the plans for selecting and managing any
subcontractors that may participate in or contribute to the project.

Specify the criteria for selecting subcontractors.

Generate a separate management plan for each subcontract, using a tailored
version of this Project Plan, and include all items necessary to ensure
successful completion of each subcontract as follows:
−
−
−
−
−
−
−
requirements management,
monitoring of technical progress,
schedule and budget control
product acceptance criteria,
risk management procedures,
additional topics as needed to ensure successful completion of the
subcontract, and
a reference to the official subcontract and subcontractor/prime
contractor points of contact.
5.8 Process Improvement

Specify the plans for periodically assessing the project, for determining
areas for improvement, and for implementing the improvement plans.

Ensure that the process improvement plan is closely related to the problem
resolution plan.

Include in the improvement plan, a process to identify the project processes
that can be improved without serious disruption to an ongoing project, and
to identify the project processes that can best be improved by process
improvement initiatives at the organizational level.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 22
Project Plan
LCG Software Process & Infrastructure
6. Additional Plans

Specify or reference any additional plans required to satisfy product
requirements and contractual terms, which may include:
−
−
−
−
−
−
−
−
−
plans for assuring that safety, privacy, and security requirements are
met,
special facilities or equipment specification,
product installation plans,
user training plans,
integration plans,
data conversion plans,
system transition plans,
product maintenance plans, or
product support plans.
Plans for installation and training will be provided when needed, after the first
release (beginning 2003).
The maintenance and the support of the infrastructure built by the SPI project
following LCG Phase 1 will need to be planned separately and will need
separate specifications and resources.
7. Project Evolution
7.1 Project support and maintenance

Specify or reference to the support, maintenance and operational model for
the project when the project will be used by the potential customers
7.2 Follow-up projects

Identify potential follow-up projects which will use this project
The LCG software projects will use the infrastructure delivered by the SPI
project as soon as components will become available.

Identify potential follow-up projects which will supersede this project
An anticipated follow-up project is foreseen in LCG Phase 2 to maintain and
continue the development of the software process and infrastructure, with a
focus on the commissioning phase of the LHC.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 23
Project Plan
LCG Software Process & Infrastructure
Annexe A “Component Document” template
LCG Application Area - LCG Infrastructure
Component: COMPONENT NAME
Responsible persons
NAME, NAME
Last Update
dd-mm-yyy
Version
COMP-xx.yy
Note: This is the internal documentation of the component. Not the way
the user will see and use what the component provides. Therefore feel
free to write in it whatever you consider useful
1. Description of the component
1.1 Purpose of the component
Overview of the component
What the component will do and what it will not do (in general)
1.2 Deliverables
What the component will deliver (in detail)
1.3 Known problems and restrictions
Limitations of the component, maybe in its different versions and deliverables
1.4 Repository of the component
CVS repository path where all artifacts of the component
2 Technology surveys
2.1 Contacts
List of people contacted and feedback received from each of them.
See what are doing in:
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 24
Project Plan
LCG Software Process & Infrastructure

Experiments in HEP (LHC experiments, Babar, etc)

HEP projects (Geant4, ROOT, etc.)

Free projects
22 External references
External links to existing material (if the material is not on the web add it to the
web of the component itself and link to it)
3 Analysis of the component
3.1 Glossary
Domain-specific terms of the component. Specify many term if you see that
people use different names for the same meaning.
Define in alphabetical order the most important terms in as much detail is
necessary to completely and unambiguously characterize it, but without any
definition which is strictly related to the implementation.
3.2 Main Requirements - List of functionalities
7.2.1
4 Usage guide
This is the material temporarily internally while the component is developed it
could also stay even when there is public documentation as there maybe more
detailed information that woudl confuse a user.
4.1 How to use the component
How to get access to the component; for now we don't have a standard template
for these sections.
4.2 Example of usage and links to documentation
4.3 Solutions to common problems
5 To do list
Action list of the component. Write here anything needs to be done realted to the
component. Keep it up to date.
Priority 1-5, 1= highest
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 25
Project Plan
LCG Software Process & Infrastructure
Milestone
Priority Due Date
Status/Delivery
Fill in Description of the Component
1
in this document
Milestone
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 26
Project Plan
Organisation
CERN – LCG project
Owner: A.Aimar
LCG Software Process & Infrastructure
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 27
Project Plan
LCG Software Process & Infrastructure
Annexe B: Removed sections from Templates
These sections will need to be filled later in the project.
7.3 Project Tracking Plan
7.3.1
7.3.2
7.3.3
Requirements Management

Specify the process for measuring, reporting and controlling changes
to the project requirements.

Specify the processes to be used in assessing the impact of
requirements changes on product scope and quality, and the impacts
of requirements changes on project schedule, budget, resources and
risk factors.

In the configuration management processes, specify change control
procedures and the formation and use of a change control board.

In the processes for requirements management, include traceability,
prototyping and modeling, impact analysis and reviews.
Schedule Control

Specify the schedule control activities by identifying the processes
to be used for the following purposes:
− to measure the progress of work completed at the major and
minor project milestones,
− to compare actual progress to planned progress, and
− to implement corrective action when actual progress does not
conform to planned progress.

Specify the methods and tools that will be used to measure and
control schedule progress.

Identify the objective criteria that will be used to measure the scope
and quality of work completed at each milestone, and hence to
assess the achievement of each schedule milestone.
Budget Control

Organisation
CERN – LCG project
Owner: A.Aimar
Specify the budget control activities by identifying the processes to
be used for the following purposes:
− to measure the cost of work completed,
− to compare the actual cost to the planned and budgeted costs,
and
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 28
Project Plan
LCG Software Process & Infrastructure
−
7.3.4
7.3.5
7.3.6
to implement corrective action when the actual cost does not
conform to the budgeted cost.

Specify when cost reporting will be done in the project schedule.

Specify the methods and tools that will be used to track the project
cost.

Identify the schedule milestones and objective indicators that will be
used to assess the scope and quality of the work completed at those
milestones.

Specify the use of a mechanism such as earned value tracking to
report the budget and schedule plan, schedule progress, and the cost
of work completed.
Quality Control

Specify the processes to be used to measure and control the quality
of the work and the resulting work products.

Specify the use of quality control processes such as quality
assurance of conformance to work processes, verification and
validation, joint reviews, audits and process assessment.
Reporting

Specify the reporting mechanisms, report formats and information
flows to be used in communicating the status of requirements,
schedule, budget, quality, and other desired or required status
metrics within the project and to entities external to the project.

Specify the methods, tools and techniques of communication.

Specify a frequency and detail of communications related to project
management and metrics measurement that is consistent with the
project scope, criticality, risk and visibility.
Project Metrics

Specify the methods, tools, and techniques to be used in collecting
and retaining project metrics.

Specify the following metrics process information:
− identification of the metrics to be collected,
− frequency of collection, and
− processes for validating, analyzing, and reporting the metrics.
7.4 Risk Management Plan

Specify the risk management plan for identifying, analyzing, and
prioritizing project risk factors.
Organisation
CERN – LCG project
Owner: A.Aimar
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 29
Project Plan
LCG Software Process & Infrastructure

Specify plans for assessing initial risk factors and for the ongoing
identification, assessment, and mitigation of risk factors throughout the life
cycle of the project.

Describe the following:
−
−
−
−
−
−
−
−

procedures for contingency planning,
procedures for tracking the various risk factors,
procedures for evaluating changes in the levels of the risk factors and
responding to changes in the levels of the risk factors,
risk management work activities,
procedures and schedules for performing risk management work
activities,
risk documentation and reporting requirements,
organizations and personnel responsible for performing specific risk
management activities, and
procedures for communicating risks and risk status among the various
customer, project and subcontractor organizations.
Identify and describe the applicable impact of any of the following risk
factors:
−
−
−
−
−
−
−
−
risks in the customer-project relationship,
contractual risks,
technological risks,
risks caused by the size and complexity of the product,
risks in the development and target environments,
risks in personnel acquisition, skill levels and retention
risks to schedule and budget, and
risks in achieving customer acceptance of the deliverables.
7.5 Project Closeout Plan

Identify the plans necessary to ensure orderly closeout of the project.

Specify the following:
−
−
−
−
−
Organisation
CERN – LCG project
Owner: A.Aimar
a staff reassignment plan
a process for archiving project materials,
a process for capturing project metrics in the business projects
database,
a process for post-mortem debriefings of project personnel, and
a plan for preparation of a final report to include lessons learned and an
analysis of project objectives achieved.
Project Plan
LCG Software Process & Infrastructure
Approved by
Date 12.10.2002
Number
Version 1.0
Page 30