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 PlanLCG Software Process & Infrastructure

Approval Signatures
Approved by: Business Project Leader / Approved by: Project Leader
Prepared by: Business Project Manager / Prepared by: Project Manager
Reviewed by: Quality Assurance Manager

< Insert Revision Number and Date of Issue >Page1

Project PlanLCG Software Process & Infrastructure

Table of Contents

1.Project Overview

1.1.Purpose, Scope, and Objectives

1.2.Assumptions, Constraints and Risks

1.3.Project Deliverables

1.4.Schedule and Budget Summary

1.4.1Internal resources needed

1.4.2External resources needed

1.5.Evolution of the Plan

1.6.References

1.7.Definitions and Acronyms

2.Project Organization

2.1.External Interfaces

2.2.Internal Structure

2.3.Roles and Responsibilities

3.Managerial Process Plans

3.1.Startup Plan

3.1.1Estimates

3.1.2Staffing

3.1.3External Help Needed

3.1.4Resource Acquisition

3.1.5Project Staff Training

3.2.Work Plan

3.2.1Work Breakdown Structure

4.Technical Process Plans

4.1.Process Model

4.2.Methods, Tools, and Techniques

4.3.Infrastructure

4.4.Product Acceptance

5.Supporting Process Plans

5.1.Configuration Management

5.2.Verification and Validation

5.3.Documentation

5.4.Quality Assurance

5.5.Reviews and Audits

5.6.Problem Resolution

5.7.Subcontractor Management

5.8.Process Improvement

6.Additional Plans

7.Project Evolution

7.1.Project support and maintenance

7.2.Follow-up projects

Annexe A “Component Document” template

1. Description of the component

1.1 Purpose of the component

1.2 Deliverables

1.3 Known problems and restrictions

1.4 Repository of the component

2 Technology surveys

2.1 Contacts

22 External references

3 Analysis of the component

3.1 Glossary

3.2 Main Requirements - List of functionalities

7.2.1

4 Usage guide

4.1 How to use the component

4.2 Example of usage and links to documentation

4.3 Solutions to common problems

5 To do list

Annexe B: Removed sections from Templates

7.3.Project Tracking Plan

7.3.1Requirements Management

7.3.2Schedule Control

7.3.3Budget Control

7.3.4Quality Control

7.3.5Reporting

7.3.6Project Metrics

7.4.Risk Management Plan

7.5.Project Closeout Plan

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:

Organisation / Title/Subject / Number
Owner / Approved by / Date / Version / Page 1

Project PlanLCG 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.1Purpose, 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 systemlevel or businesslevel 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:

−All LCG projects must adopt the same set of tools, standards and procedures

−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”.

1.2Assumptions, 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.3Project 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:

−AFS delivery area where can be accessed directly all the artefacts

−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.4Schedule 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.1Internal 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.2External 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.5Evolution of the Plan

  • Identify the compliance of this Plan to any standards.

The structure of this Project Plan is in compliance with the recommendations of IEEEStd10581998, 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.6References

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

RTAG: Requirements Technical Assessment Group.

2.Project Organization

2.1External 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.2Internal 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 / 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.3Roles 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:

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

  • 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 startup, risk management, project work, project tracking and project closeout.

3.1Startup Plan

3.1.1Estimates

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

  • Specify the methods, tools and techniques used to estimate project cost, schedule and resource requirements;
  • 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 reestimate 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.