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 Core activities:2013-bidding Acceptance criteria

From EGIWiki
Revision as of 10:16, 3 July 2013 by Psolagna (talk | contribs)
Jump to navigation Jump to search
  • Service name: Acceptance criteria
  • Service category: Software
  • Service type: Coordination, operation and maintenance

Introduction

The quality criteria are the functional and non functional requirements that a product must fulfill to be released in UMD, these include generic requirement applicable to every product, and specific requirements applicable to the capabilities supported by a component.

Technical description

Incremental definition

The task must evolve the current set of quality criteria published in the UMD QC Document [1], removing the criteria no more relevant for the UMD distribution and adding the new criteria coming from operational requirements and new capabilities. The document drafts must be disseminated among the EGI technology providers and discussed to collect feedback from the developers. The task must maintain comprehensive wiki pages with the documentation to properly test the criteria, to be used during the verification, as well as the mapping products vs criteria. The task must also analyze the new products, and discuss with the software providers the capabilities relevant for the EGI communities.

Verification of acceptance criteria

All the products released in UMD must be verified against the relevant acceptance criteria. Products must be deployed in a controlled environment. Every product in UMD must have a verification report associated, with the results of the verification process. The verifiers must be familiar with the core products used in EGI, the most common site configurations and third parties components such as DBMS and LRMS.

Coordination

The task must coordinate the verifications when the process is outsourced to developers or user communities, this means: overview to advancements in the process and collect the reports produced during verification, making sure that the relevant information (GGUS tickets opened, known issues) are properly propagated to the UMD release.

Operation

The verification for the most critical UMD components must be performed within this core activity.

Service level targets

Incremental definition

The task must produce a new document version every year, following two public drafts.

Verification of acceptance criteria

The verification activities must support the UMD releases. The estimated number of products to verify in one year is 200 PPA, depending