Work Plan template

The following main sections should be part of any Work Plan.

State of the Art (for first period deliverables only - up to M9)

• Description of the architecture of the relevant software components.
  • High level summary of what the software component does, which sub-components are part of it and how they interact. A graphic illustrating this is highly recommended.
  • Main technologies relevant to the technical area used by the software component (security and information system should always be mentioned. i.e. Kerberos and Glue 2.0).
  • Which clients are available.
• Main user communities of the software component.
• DCIs (EGI, PRACE, etc) where the software componet is used. Statistics of the number of instances installed are highly recommended.
• Strengths of the software component according to the users. It should answer the question Why is this software component being used nowadays?
• Main issues in the versions of the software component deployed in production infrastructures. It should answer the question What users would like to see implemented next?

Status Report (for periodically updated deliverables from M10)

• Achievements of the past period compared to the planned objectives.
• Deviation from the agreed plan of the past period and rationale/justification behind these changes.

Harmonization Activities

The structure of this section should be clear enough to easy understand the different activities aimed at harmonising the four middleware distributions. The activities should cover:

• Standardisation efforts: which standards are going to be chosen for which purpose and what changes are needed to implement the standard in the current version of the software components.
• Removal of duplications: which software components have duplicated functionality across dCache, UNICORE, ARC and gLite and how the duplication is going to be removed.
• Simplification of use and maintenance: how the current versions of the software components are going to be simplified for easier use and better maintenance.

For each sub-section, the following information should be present:

• Affected software component
• Which harmonization activity is addressed (standardisation, removal of duplications, simplification)
• Current status and target status (i.e. Current status is different authorization services, target status is single authorization service)
• Description of how to achieve the target status. (i.e. preliminiar studies within a task force or working group, description of the different stages to achieve the target status, coordination activities with other software components, etc)
• Risks associated with this change
• Constraints to implement this change (enough resources?)

Evolution

This section should contain an introductory description of what goals the technical area wants to achieve in the future. These goals should be based on:

• Addressing the requirements of the users and the DCIs where the software components are deployed. In this case, these requirements should be clearly identified.
• Adapting to changes in the underlying technologies. In this case, the change should be clearly described.

For each sub-section, the following information should be present:

• Affected software component
• Which evolution activity is addressed
• Description of Requirements or Technology changes
• Description of how they will be implemented (i.e. preliminiar studies within a task force or working group, description of the different stages to achieve the target status, coordination activities with other software components, etc)
• Risks associated with this change
• Constraints to implement this change (enough resources?)

Detailed workplan

For each of the activities described in the previous sections, a detailed work plan is needed. The following information should be provided:

• A GNATT chart for the overall technical area work plan should be included.
• For each activity, a description of sub-activities, deliverables, deadlines and responsible people should be provided.

Template to track the tasks automatically

Once the technical area work plan has been approved, the planned tasks should be tracked in EMI Technical Objectives Tracker. The task should contain at least the following fields:

• ID: number ID to identify the task.
• Title: a sentence summarising the task.
• Description: a detailed description of the task. This could be the text included in the technical area work plan.
• Responsible: the person responsible for the task.
• Category: which technical area is affected.
• Should be finished on: date when the task should be finished, including certification.
• Status: At least there should be Open and Closed to be able to differentiate between an objective that hasn't been completed yet and an objective that has been implemented in the middleware.

For more details, please check the Release Guidelines.

-- FloridaEstrella - 25-Feb-2011