EMI Software Quality Assurance Plan

1. Introduction

One of the main tasks of the SA2.2 activity is to write and implement a Software Quality Assurance Plan (SQAP). The SQAP contains the definition of the global software QA processes, procedures, roles and responsibilities for the EMI project. A first version of the SQAP was submitted to the EC in 03.09.2010. Since quality assurance is an iterative process, the SQAP will evolve accordingly. Check the Logbook to track the changes.

2. Complementary Documentation

The SQAP makes reference to the documents included in the following sections. Please, check the documents below to have a complete picture of the SQAP.

2.1. EMI QA Policies

The following policies are defined within SA2 and they describe the software lifecycle process. A group of experts representing each middleware has been involved in their definition. PT must follow these policies in order to release software within the EMI project:

• Releasing
• Change Management
• Configuration and Integration
• Packaging
• Testing
• Documentation
• Certification

2.1.1. Documentation guidelines for the Policies

2.1.1.1. Common layout

The policy documents follow this layout:

• Table of contents.
• Introduction explaining the purpose of the policy.
• Sections and subsections that would help to quickly find the needed information.
• Contacts: SA2 mailing list.
• Table of references.
• Logbook where changes to the policy are summarised.

All sections in the policy must be numbered.

2.1.1.2. Available Formats

The policy documents are available in the following formats:

• twiki pages
• PDF documents

The name of the PDF document should meet the following naming and versioning scheme:

• EMI_SA2_Releasing_v_X_Y.pdf
• EMI_SA2_Change_v_X_Y.pdf
• EMI_SA2_ConfigIntegration_v_X_Y.pdf
• EMI_SA2_Packaging_v_X_Y.pdf
• EMI_SA2_Testing_v_X_Y.pdf
• EMI_SA2_Documentation_v_X_Y.pdf
• EMI_SA2_Certification_v_X_Y.pdf

Where X represents a major change and Y represents a minor change (up to the different authors to judge this). X >= 0 as soon as the policy is approved for the first time.

In the twiki page, there should be a box where it should be mentioned which version of the policy is currently the one to be used and in which date it was approved.

PDF versions should include the Policy Cover Template.

2.1.1.3. How to manage changes

• Anybody can suggest changes to policies.
• Changes are communicated to SA2.
• The proposed change should contain all the necessary details to be included in a new version of the policy.
• Changes in the policies are done in the twiki page first.
• A summary of the introduced changes is included in the twiki Logbook.
• The twiki should then contain a message at the top of the page so that it's clear that a newer version is being prepared (see the list of messages in the table below).
• The policy table in the main SA2 twiki should also be updated stating that there's a new version in progress.
• SA2 decides when a new change or group of changes are ready to be announced by sending the twiki + PDF to all-members mailing list using the following template:

SUBJECT: Policy_Name policy vX.Y draft available for comments, deadline: dd.mm.yyyy
Hi all,

Policy_Name Policy vX.Y is now available for public comments in:

<copy here the Policy URL>

The Certification Policy is also available in PDF format:

<copy here the PDF Policy URL>

Please, send your feedback *BEFORE* dd.mm.yyyy.


Release Notes
---------------
Summarise the changes included in the new version.

For more details, please check: 
<Copy here the Policy Logbook URL>
---------------
Regards,
SA2 team

• SA2 waits for two weeks for public comments.
• After this period, SA2 processes the received feedback.
• Once the feedback has been discussed with the relevant parties and included in the policy, SA2 announces the new version as follows:
  • update the Latest version of this policy box with the new version.
  • announce the new version:
    • In the SA2 news RSS feed in the main SA2 twiki page.
    • In the policy table in the main SA2 twiki page.
    • In the all-members mailing list, using the following template

SUBJECT: Policy_Name Policy vX.Y is now ready
Hi all,

Policy_Name Policy vX.Y is now available in:

<copy here the Policy URL>

The Certification Policy is also available in PDF format:

<copy here the PDF Policy URL>

Release Notes
---------------
Summarise the changes included in the new version.

For more details, please check: 
<Copy here the Policy Logbook URL>
---------------

You can also register to the RSS feed for SA2 announcements here:
https://twiki.cern.ch/twiki/pub/EMI/SA2/sa2_news.rss
 
In case of questions do not hesitate to contact SA2: emi-sa2@eu-emi.eu

Regards,
XXX on behalf of SA2

The SA2.2 task leader is responsible for coordinating the implementation of new changes. The SA2.2 task leader is also responsible for updating the relevant twiki, PDF document and notify the changes to everybody by announcing the change.

If the SA2.2 task leader is not available, SA2 activity leader or even PEB can be a backup responsible for this process.

The following messages will be displayed at the beginning of the policy twiki pages for each possible scenario:

2.2. EMI Quality Model

The EMI Quality Model helps to evaluate EMI software products and processes quality. It identifies EMI quality requirements, a set of characteristics need to present in the EMI software to meet these requirements and a set of metrics and KPIs evaluating the presence of these characteristics.

The Quality Model should follow the same documentation guidelines as the QA policies. However, no feedback is needed from the rest of the project since this is a document describing an internal SA2 process.

The file name of the PDF version should follow the format: EMI_SA2_QualityModel_v_X_Y.pdf

2.3. EMI Production Release Criteria

The Producton Release criteria defines the minimum set of criteria considered to be mandatory for a component release to be released in production. The criteria will be checked by QC. Visit the Production Release Criteria twiki for more details.

The Production Release Criteria should follow the same documentation guidelines as the QA policies. However, no feedback is needed from the rest of the project since this document is already a summary of what it is defined as mandatory in the different policies.

The file name of the PDF version should follow the format: EMI_SA2_ProductionReleaseCriteria_v_X_Y.pdf

2.4. EMI Release Check List

The Release Check List is a document summarising all the steps needed to release a new EMI product version. Visit the Release Check List twiki for more details.

The Release Check List should follow the same documentation guidelines as the QA policies. However, no feedback is needed from the rest of the project since this document is already a summary of the release process.

The file name of the PDF version should follow the format: EMI_SA2_Checklist_v_X_Y.pdf

2.5. EMI Deliverables relevant to SQA

The following documents are deliverables of the EMI project that play a key role in the definition of the EMI SW lifecycle:

2.6 SQA within the EMI sustainability plan

One of the main goals of EMI at the end of the project is that EMI products are distributed in the EPEL and Debian repositories. SQA activities need to help in the transition from the current model where EMI products are released in the EMI repository, towards the model where EMI packages are released in EPEL and Debian repositories. In the following twikis, the criteria that needs to be satisfied for both EPEL and Debian is summarised. The twikis also describe the steps needed in EMI SQA activities to meet EPEL and Debian criteria:

• EPEL compliance in EMI

3. SQAP templates

The following templates aim at helping the members of the EMI project to produce high quality documentation. They are relevant to software lifecycle related documentation:

• Work Plan template

4. SQAP Logbook

Details Hide Details

-- MariaALANDESPRADILLO - 05-Aug-2010