Alert.png 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.

EGI Technology

From EGIWiki
Jump to navigation Jump to search


Quality Assurance

The Quality Assurance unit in EGI defines and executes the processes of

  • structuring, defining and assurance of technical accuracy of Quality Criteria
  • evolving Quality Criteria from a current set to a future set of criteria valid for assurance and control by Technology Providers

Structure and Definition of Quality Criteria

EGI's Quality Critera are organised in a set of documents. The organisation of Quality Criteria follows the layout of the UMD Roadmap version for which the Quality Criteria are valid (see below).

Evolution of Quality Criteria

It is a well-proven fact in Software Engineering that user requirements for any given piece of software change over time. So, as requirements change, so must the software designed to satisfy these requirements. Consequently, Quality Criteria by which the quality of the software is assessed that is verified for production infrastructure availability, must evolve over time, too.

With change of Quality Criteria come multiple sets of Quality Criteria. To deliver software that matches EGI's quality demand, Technology Providers must know well in advance which set of Quality Criteria are in effect at any given point in time.


The following rules define the process of Quality Criteria validity:

  • A set of Quality Criteria covers the complete UMD Capabilities.
  • A set of Quality Criteria are valid for 6 calendar months, following the publication and validity schedule of the UMD Roadmap
  • A set of Quality Criteria is stored in EGI's document database as a set of documents grouped in one storage location.
  • A set of Quality Criteria has a shared version, e.g. "QC-1"
  • At most one set of Quality Criteria is valid at any given point in time marked "FINAL" in EGI's document database.
  • There may be more than one set of Quality Criteria in "DRAFT" status, marked as such in the document database.
  • As time passes, FINAL sets of Quality Criteria may become "DEPRECATED" by the next version of Quality Criteria.
  • All DEPRECATED sets of Quality Criteria are kept publicly available for reference.


Quality Criteria may evolve to reflect changing user requirements. The process of evolution is captured as follows:

  1. Anyone interested in the Quality Criteria definition may review the documents, at any given point in time.
  2. Feedback and requests for change must be given through the appropriate channels associated with the reviewer's affiliation
    1. Reviews and comments from the resource operation communities must be given through the OMB
    2. Reviews and comments from the end user communities must be given, via the VRCs, to the UCB
  3. UCB and OMB are collating and prioritising the reviews and comments, and discuss them at regular TCB meetings.
  4. The TCB decides upon the changes, and in which DRAFT version of the Quality Criteria they shall be reflected.

Quality Control

Software Provisioning

2nd line support: Distributed Middleware Support Unit

Glossary

Term Description
(UMD) Capability A Capability is scoped around well known and well-defined activities that are sufficiently disparate, independent, and fulfil a discrete task in a higher-level orchestrated sequence of actions taken by the user (manually or automated) in order to reach the aspired goal. Capabilities may depend on the presence of another Capability. Appliances, however, SHOULD NOT depend on each other to avoid technical dependencies and vendor lock-in.
Appliance An Appliance is the technical implementation of a Capability. An Appliance may be delivered in a single, monolithic Package, or it may be delivered as a set of components that are grouped into a set of Packages. In the latter case all packages must be installed to provide the complete Appliance.
Package A Package is a structured software unit suitable for automated installation on a computer. A Package may specify dependencies on other packages, so that either a specific version of that package, or a minimum version of that package may satisfy that dependency.
Product A Product is a solution delivered by Technology Providers to EGI and provides the functionality for one, sometimes more Capabilities as one single, undividable unit. Consequently, a Product may comprise of one or more Appliances.
Primary Package A Product consists of a well-defined set of specific packages, each in a specific version. Different versions (whether major, minor, or revision) of the same Product may share a subset of packages of the same version, that do not change between the compared versions.
Secondary Package A Secondary Package is a Package that is resolved from dependency declarations within a Package, that sources either from the Technology Provider's own Repository, or from any additional repository except OS distribution repositories. (Note: EPEL is an example of such a repository that is not an OS repository.)