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.

Difference between revisions of "EGI-InSPIRE:WP5 Project Metrics"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
=== EGI SA2 Metrics ===
=== EGI-InSPIRE Work Package 5 (SA2) quarterly metrics<br> ===
 
The following table provides an overview of all collected metrics throughout the EGI-InSPIRE project.<br>


{| cellspacing="0" cellpadding="5" style="border: 1px solid black;"
{| cellspacing="0" cellpadding="5" style="border: 1px solid black;"
Line 112: Line 114:
|}
|}


<sup>1</sup> Beginning with PQ4 the semantics of this metric has changed. For more details, see [https://documents.egi.eu/document/375 D5.3]<sup></sup><br>
<br>
 
=== EGI-InSPIRE Work Package 5 (SA2) metrics definition<br>  ===
 
The following table defines the metrics for the the SA2 activity. It is the direct input to the relevant management deliverables (i.e. D1.1, D1.5, etc.).
 
{| width="70%" cellspacing="0" cellpadding="5" style="border: 1px solid black;"
|- style="background: none repeat scroll 0% 0% darkgray;"
! style="border-bottom: 1px solid black;" | Metric ID
! style="border-bottom: 1px solid black;" | Metric
! style="border-bottom: 1px solid black;" | Public/<br>Internal
! style="border-bottom: 1px solid black;" | Task
! style="border-bottom: 1px solid black;" | Explanation
|-
| M.SA2-1
| Number of software components recorded in the UMD Roadmap
| P
| TSA2.1
|
|- style="background: none repeat scroll 0% 0% lightgray;"
| M.SA2-2
| UMD Roadmap Capabilities coverage with Quality Criteria
| P
| TSA2.2
| Expresses the coverage of UMD Quality Criteria with Quality Criteria. Value is given in percent.
|-
| M.SA2-3
| Number of software incidents found in production that result in changes to quality criteria
| P
| TSA2.2
| Indicates how good the quality criteria are – what is slipping through into staged rollout and production that could be caught? Only incidents that are investigated with post mortems are counted, not ordinary bugs.
|- style="background: none repeat scroll 0% 0% lightgray;"
| M.SA2-4
| Number of quality related issues that result in changes to quality criteria.
| I
| TSA2.2
| Measures the activity and communication flow between TSA2.2 and its input sources as defined in the Wiki.
|-
| M.SA2-5
| Number of new Product releases validated against defined criteria
| P
| TSA2.3
| Measures the workload on the validation team
|- style="background: none repeat scroll 0% 0% lightgray;"
| M.SA2-6
| Mean time taken to validate a Product release
| P
| TSA2.3
| Indicates how responsive the team is to validating releases
|-
| M.SA2-7
| Number of Product releases failing validation
| P
| TSA2.3
| Indicates the quality assurance process of the software providers
|- style="background: none repeat scroll 0% 0% lightgray;"
| M.SA2-8
| Number of new releases contributed into the Software Repository from all types of software providers
| P
| TSA2.4
| Records how actively is the repository used by software providers in the community
|-
| M.SA2-9
| Number of unique visitors to the Software Repository
| P
| TSA2.4
| Records the visibility of the repository front-end to the community through Google Analytics
|- style="background: none repeat scroll 0% 0% lightgray;"
| M.SA2-10
| Number of unique visits to the Repository backend
| P
| TSA2.4
| Records how actively the software repository is being used by the community in terms of visits.
|-
| M.SA2-11
| Number of tickets assigned to DMSU
| P
| TSA2.5
| Demonstrates use of DMSU
|-
| M.SA2-12
| Demonstrates use of DMSU
| P
| TSA2.5
| Demonstrates effectiveness of DMSU for resolving tickets
|}
 
<br> <sup>1</sup> Beginning with PQ4 the semantics of this metric has changed. For more details, see [https://documents.egi.eu/document/375 D5.3]<sup></sup><br>  


<sup>2</sup> beginning with PQ4 this metric is not collected until appropriate reporting means in GGUS are implemented. (See [https://documents.egi.eu/document/375 D5.3] for more details.)
<sup>2</sup> beginning with PQ4 this metric is not collected until appropriate reporting means in GGUS are implemented. (See [https://documents.egi.eu/document/375 D5.3] for more details.)

Revision as of 17:39, 9 May 2011

EGI-InSPIRE Work Package 5 (SA2) quarterly metrics

The following table provides an overview of all collected metrics throughout the EGI-InSPIRE project.

Metric ID Metric Task Q1 Q2 Q3 Q4 Q5
M.SA2-1 Number of software components recorded in the UMD Roadmap TSA2.1 0 0 30 30

M.SA2-2 Number of UMD Roadmap Capabilities defined through validation criteria TSA2.2 0 6 17 70% (18)

M.SA2-3 Number of software incidents investigated in a post-mortem found in production that result in changes to quality criteria1 TSA2.2 0 1 0 0
M.SA2-4 Number of new product releases validated against defined criteria1 TSA2.3 0 1 1 3

M.SA2-5 Mean time taken to validate a product release TSA2.3 n/a 4h 8h 4h

M.SA2-6 Number of releases failing validation TSA2.3 n/a 0 0 0

M.SA2-7 Number of new product updates contributed into the Software Repository from all types of software providers TSA2.4 0 1 3 4

M.SA2-8 Number of unique visitors to the Software Repository1 TSA2.4 0 507 412 525

M.SA2-9 Number of unique visits to the Repository backend TSA2.4 0 0 0 1663

M.SA2-10 Number of tickets assigned to DMSU TSA2.5 0 8 144 198

M.SA2-11 Mean time to resolve DMSU tickets2 TSA2.5 3d 2d n/a n/a


EGI-InSPIRE Work Package 5 (SA2) metrics definition

The following table defines the metrics for the the SA2 activity. It is the direct input to the relevant management deliverables (i.e. D1.1, D1.5, etc.).

Metric ID Metric Public/
Internal
Task Explanation
M.SA2-1 Number of software components recorded in the UMD Roadmap P TSA2.1
M.SA2-2 UMD Roadmap Capabilities coverage with Quality Criteria P TSA2.2 Expresses the coverage of UMD Quality Criteria with Quality Criteria. Value is given in percent.
M.SA2-3 Number of software incidents found in production that result in changes to quality criteria P TSA2.2 Indicates how good the quality criteria are – what is slipping through into staged rollout and production that could be caught? Only incidents that are investigated with post mortems are counted, not ordinary bugs.
M.SA2-4 Number of quality related issues that result in changes to quality criteria. I TSA2.2 Measures the activity and communication flow between TSA2.2 and its input sources as defined in the Wiki.
M.SA2-5 Number of new Product releases validated against defined criteria P TSA2.3 Measures the workload on the validation team
M.SA2-6 Mean time taken to validate a Product release P TSA2.3 Indicates how responsive the team is to validating releases
M.SA2-7 Number of Product releases failing validation P TSA2.3 Indicates the quality assurance process of the software providers
M.SA2-8 Number of new releases contributed into the Software Repository from all types of software providers P TSA2.4 Records how actively is the repository used by software providers in the community
M.SA2-9 Number of unique visitors to the Software Repository P TSA2.4 Records the visibility of the repository front-end to the community through Google Analytics
M.SA2-10 Number of unique visits to the Repository backend P TSA2.4 Records how actively the software repository is being used by the community in terms of visits.
M.SA2-11 Number of tickets assigned to DMSU P TSA2.5 Demonstrates use of DMSU
M.SA2-12 Demonstrates use of DMSU P TSA2.5 Demonstrates effectiveness of DMSU for resolving tickets


1 Beginning with PQ4 the semantics of this metric has changed. For more details, see D5.3

2 beginning with PQ4 this metric is not collected until appropriate reporting means in GGUS are implemented. (See D5.3 for more details.)