PROJECT PLAN Organization: Project name ( SPI ) Document Revision #: 1.0 Date of Issue: 11.10.2002 Project Manager: Alberto Aimar
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 and Date of Issue > Page i
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 Title/Subject Owner Approved by Date Version Page ii
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 Title/Subject Owner Approved by Date Version Page iii
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 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 Template of the Treasury Board of Canada Secretariat URL: http://www.cio-dpi.gc.ca/emf-cag/ppto-gtpss/projplantemplate/ppt-mpp00_e.asp Title/Subject Owner Approved by Date Version Page iv
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: All LCG projects must adopt the same set of tools, standards and procedures Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 1
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 2
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: AFS delivery area where can be accessed directly all the artefacts Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 3
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 4
The structure of this 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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 5
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 Commitment Comments Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 6
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: Components of the software development phases, such as development, testing, documentation, planning; Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 7
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. Specify the methods, tools and techniques used to estimate project cost, schedule and resource requirements; Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 8
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) Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 9
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 10
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. 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. 3.1.5 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. Identify training as needed in technical, managerial and supporting activity skills. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 11
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 Software Library Summary Product used by the LCG projects, pre-installed for all supported platforms Deliverables Tools installed, web site to use them, internal organization to 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 Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 12
General services for all LCG projects Summary Deliverables Build platform Platforms to compile the LCG packages and run the global tests Server available, project assigned to areas, support Components for each LCG App projects Code documentation CVS repository structure Summary Doxygen, LXR, cvsweb, viewcvs, etc. Structure for development, directory tree etc. Deliverables Script to generate documentation, examples, and manuals 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, with tool support Configuration management 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 Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 13
Components for each LCG App projects Summary 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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 14
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) General services for all LCG projects 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 Components for each LCG App projects Code documentation 30 LMAN 1 CVS repository structure 20 IPAP 1 Testing 60 MGAL et al. 1 Unit testing 2 Integration testing 1 memory leaks 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 User specifications (60) (tbd) 2 for future releases Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 15
Component Estimate (days) Who Priority (1=High 3=Low) Software Design (60) (tbd) 3 for future release SPI internal 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 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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 16
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 17
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 18
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: Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 19
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 20
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 21
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, 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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 22
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 23
Annexe A Component Document template LCG Application Area - LCG Infrastructure Component: COMPONENT NAME Responsible persons Last Update Version NAME, NAME dd-mm-yyy COMP-xx.yy 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: Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 24
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. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 25
Milestone Priority Due Date Status/Delivery Fill in Description of the Component in this document 1 Milestone Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 26
Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 27
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 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. 7.3.2 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. 7.3.3 Budget Control 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 Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 28
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. 7.3.4 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. 7.3.5 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. 7.3.6 Project Metrics Specify the methods, tools, and techniques to be used in collecting and retaining project metrics. Specify the following metrics process information: 7.4 Risk Management Plan identification of the metrics to be collected, frequency of collection, and processes for validating, analyzing, and reporting the metrics. Specify the risk management plan for identifying, analyzing, and prioritizing project risk factors. Owner: A.Aimar Approved by Date 12.10.2002 Version 1.0 Page 29