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 Core activities:2013-bidding Acceptance criteria"
| Line 6: | Line 6: | ||
= Technical description = | = Technical description = | ||
== Incremental definition == | == 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 == | == Verification of acceptance criteria == | ||
Revision as of 11:04, 3 July 2013
- 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. The verification for the most critical UMD components must be performed within the core activity, about 150 product releases to verify per year. The task must also 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.
Service level targets
Incremental definition
The task must produce a new document version every year, following two public drafts.