EGI Core activities:2013-bidding Acceptance criteria

From EGIWiki
Jump to: navigation, search
Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


EGI Core services menu: Services PHASE I Services PHASE II Services PHASE III Bids Payments Travel procedure Performance


Contents


Go back to the EGI Core Activities Bidding page.


Go back to the Core EGI activity list.


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 |QC Document, 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.

Personal tools
Variants
Actions
Navigation
Toolbox
Print/export