EGI-Engage:Quality Plan

From EGIWiki
Jump to: navigation, search
EGI-Engage project: Main page WP1(NA1) WP3(JRA1) WP5(SA1) PMB Deliverables and Milestones Quality Plan Risk Plan Data Plan
Roles and
responsibilities
WP2(NA2) WP4(JRA2) WP6(SA2) AMB Software and services Metrics Project Office Procedures


Contents


Help and support: quality@egi.eu


This page is providng rules regarding organization, communication and recording of work within EGI-Engage project.


Project communication and outputs

All output produced by staff active within EGI-Engage (funded and unfunded effort) must be recorded so that it can be reported by the project.

The following rules must be used:

Templates

All EGI-Engage templates can be found under http://www.egi.eu/about/logo_templates/index.html

Acknowledgement

Proper acknowledgement statements should be used for EGI-Engage outputs unless the output already uses one of the recognised project templates, where appropriate acknowledgements are already included.


Software and Services quality

Services

Quality of services produced within EGI-Engage project will be ensured by the adoption of the EGI Services management standard FitSM, a international standard developed by the FedSM project.

Instruction for Tools teams can be found under Instructions Tools teams


Software

The software produced within the project will follow the well established Software provisioning process that has been adopted since 2010, based on the definition of quality criteria, quality verification and software validation in a controlled production environment of the federated EGI infrastructure.

The development activities within the project will augment capabilities of existing open source software. The resulting software code, tools and interfaces developed as part of EGI-Engage will be released as open source code and the full access will be provided via publicly available source code repositories such as GitHub, SourceForge, Subversion (SVN), Concurrent Version System (CVS) etc. Software developers will be able to choose their preferred source code repository to better integrate with existing practices, nevertheless they will need to

Other

All tools availabe for EGI-Engage to be used are listed under EGI Collaboration tools

Document management

All documents, presentations and other material that form an official output of the project (not just milestones and deliverables) are placed in the document repository to provide a managed central location for all material.


Content

All documents will be written in English and use document formats described in the following section. In addition to the fields and sections already described in the document template, deliverables must include an Executive Summary and, if required, one or more Annexes. References to external document and a Glossary to terms not listed on the website must be recorded. The correct capitalisation of the project name is EGI-Engage. English date format must be used (DD/MM/YYYY) when required.


All output from the project (paper or presentation) must include the phrase: EGI-Engage is co-funded by the Horizon 2020 Framework Programme  of the European Union under grant number 654142

unless the output is using one of the recognised project templates where appropriate acknowledgements are already included.

Formats and tools

The following tools and formats will be recognised within the project:

Final version of all formal documents (milestones and deliverables) must be available in PDF format.


Document naming convention

Filenames must use the following format in order to link any item back to other versions placed in the document repository. The filename format is:

EGI-Engage-<DOCUMENT IDENTIFIER>-V<VERSION>

DOCUMENT IDENTIFIER The document identifier is dependent on the document type. If the document is:
  • Deliverable: Use the deliverable name: e.g. D1.1, D5.5, etc.
  • Milestone: Use the milestone name: e.g. M1.2, M5.4, etc.
  • Activity: Use the activity code: e.g. SA1, NA3, etc.
  • Committee/Board: Use an acronym based on the committee or board name: e.g. TCB, OMB, UCB, SPG, etc.
  • Other: If the source of the material cannot be identified then ignore this section.
VERSION This is the version number generated by the document repository for the particular repository identifier.

Versioning rule:

  • +0.1 – new version of draft
  • +1.0 – new version of approved document


Example: EGI-Engage-M3.1-V1.0.pdf


The title of documents uploaded to document repository must be in the following format:

<DOCUMENT IDENTIFIER> Title (from the first page of the document)

Example: M3.1 User Support Contacts


Metadata management

Document metadata 

The first page of the document (along with the header and footer) contains metadata that needs to be reviewed and completed:

The document title must be repeated into the header and before submitting a new version to the document repository the date and filename fields in the header must be updated.

Repository metadata

When creating the entry in the document repository there are a number of compulsory metadata fields that need to be completed. These should be copied from the document metadata where duplicated:

Access to documents

Access to internal or confidential documents is controlled at SSO group level, with SSO IDs being assigned to particular groups depending on their permissions to view or modify documents. Public documents are available to all, without restriction or the requirement to log in. Restricted documents can only be viewed and/or modified by logging in using an account with the correct permissions.



Glossary

Review process for deliverables and milestones

All deliverables and milestones should be a subject of review defined under https://wiki.egi.eu/wiki/PROC01_Deliverables_and_milestones_review

Guidelines for editors

While creating Deliverable and Milestones Editor should remember to:

QA internal resources


Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox
Print/export