The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.
Difference between revisions of "EGI Quality Criteria Definition"
(Created page with '{{Tech menubar}} {{Tech QA submenu}} {{TOC_right}} '''EGI Quality Assurance''' == Quality Criteria Definition == Described here...') |
|||
| Line 3: | Line 3: | ||
{{TOC_right}} | {{TOC_right}} | ||
The Quality Criteria (QC) Definition Task is responsible of generating the Quality Criteria Documents that drive the Quality Criteria Verification. | |||
== Quality Criteria | === Quality Criteria Roadmap === | ||
Quality Criteria definition is a continuous process driven by the requirements of users and operations communities, however the verification of new software releases is done against fixed release dates of the QC documents every 6 months. Between major these major releases, two minor releases are made available for lightweight review (one minor release every 2 months). The QC releases are done in coordination with the [[EGI Roadmap and Technoogy]] releases. | |||
There are 3 different possible states for the Quality Criteria documents: | |||
* '''FINAL''', meaning that the documents are actively used for verification of software products | |||
* '''DRAFT''', for documents that are in preparation and will be used in the future for verification. | |||
* '''DEPRECATED''', for documents that are no longer used in verification. | |||
For a given UMD Release, there is only one '''FINAL''' version of the QC documents. | |||
=== Quality Criteria Change Management === | |||
Changes in the criteria documents are triggered by one of the following sources of changes: | |||
* Requirements from User Community | |||
* Requirements from Operations Community (especially software incidents found in production) | |||
* Deficiencies in criteria found in Verification or Stage Rollout | |||
* Analysis of reference implementations of UMD Capabilities | |||
* Review and analysis of feedback from Technology Providers | |||
Any change to criteria is tracked in the ''Related Information'' field that includes any links to direct source of change for the criterion (e.g. RT ticket with user requirement) and the ''Revision Log'' field, that records the historic information about the changes in the criterion. | |||
Moreover, the Quality Criteria Release Notes include an overview of the most relevant changes produced in the whole set of criteria documents. | |||
Revision as of 19:06, 11 March 2011
| Technology | Software Component Delivery | Software Provisioning | UMD Middleware | Cloud Middleware Distribution | Containers Distribution | Technology Glossary |
| Quality Assurance | | Quality Criteria Definition | | Quality Criteria Dissemination | | Quality Criteria Verification | | Verifier Guideline | | Verification Testbed | | Glossary |
The Quality Criteria (QC) Definition Task is responsible of generating the Quality Criteria Documents that drive the Quality Criteria Verification.
Quality Criteria Roadmap
Quality Criteria definition is a continuous process driven by the requirements of users and operations communities, however the verification of new software releases is done against fixed release dates of the QC documents every 6 months. Between major these major releases, two minor releases are made available for lightweight review (one minor release every 2 months). The QC releases are done in coordination with the EGI Roadmap and Technoogy releases.
There are 3 different possible states for the Quality Criteria documents:
- FINAL, meaning that the documents are actively used for verification of software products
- DRAFT, for documents that are in preparation and will be used in the future for verification.
- DEPRECATED, for documents that are no longer used in verification.
For a given UMD Release, there is only one FINAL version of the QC documents.
Quality Criteria Change Management
Changes in the criteria documents are triggered by one of the following sources of changes:
- Requirements from User Community
- Requirements from Operations Community (especially software incidents found in production)
- Deficiencies in criteria found in Verification or Stage Rollout
- Analysis of reference implementations of UMD Capabilities
- Review and analysis of feedback from Technology Providers
Any change to criteria is tracked in the Related Information field that includes any links to direct source of change for the criterion (e.g. RT ticket with user requirement) and the Revision Log field, that records the historic information about the changes in the criterion.
Moreover, the Quality Criteria Release Notes include an overview of the most relevant changes produced in the whole set of criteria documents.