Quatic 2010: Towards automated quality models for software development communities

8/8/2019 Quatic 2010: Towards automated quality models for software development communities

http://slidepdf.com/reader/full/quatic-2010-towards-automated-quality-models-for-software-development-communities 1/24

IntroductionMethodology

ResultsConclusions

Towards Automated Quality Models for SoftwareDevelopment Communities

The QualOSS and FLOSSMetrics case

Daniel Izquierdo Cortazar, Jesus M. Gonzalez-Barahona,Santiago Duenas, Gregorio Robles

{dizquierdo, jgb, sduenas, grex}@libresoft.esGSyC/Libresoft, Universidad Rey Juan Carlos

Quatic 2010, Porto, Portugal29th, September, 2010

Daniel Izquierdo Cortazar, Jesus M. Gonzalez-Barahona, Santiago Duenas, Gregorio Robles

Towards Automated Quality Models for Software Development C

http://find/

http://goback/




ResultsConclusions

(cc) 2010 Daniel Izquierdo Cortazar.

Some rights reserved. This document is distributed under the CreativeCommons Attribution-ShareAlike 2.5 licence, available in

http://creativecommons.org/licenses/by-sa/2.5/

D. Izquierdo, J. G. Barahona, S. Duenas, G. Robles Towards Automated Quality Models

http://find/

http://goback/




ResultsConclusions

Table of contents

1 Introduction

2 Methodology

3 Results

4 Conclusions


http://find/

http://goback/




ResultsConclusions

Index

1 Introduction

2 Methodology

3 Results

4 Conclusions


I d i

http://find/

http://goback/




ResultsConclusions

Motivation

Quality models and FLOSS communities

There exist several quality models focused on FLOSSIn most of the cases, there are some new additions to thetraditional point of viewBeing the community of developers supporting the product of special interest


I t d ti

http://find/

http://goback/




ResultsConclusions

Motivation

General process of execution:

Most of them have followed a Goal-Question-Metric approachThus, there is a development of several high-level qualityattributesAnd go down to reach the final set of metricsThat final estimation of the metrics have been manually

calculated (in most of the cases)

Or based on experts estimations


Introduction

http://find/

http://goback/




ResultsConclusions

Motivation

Nowadays FLOSS offer a huge set of data mainly based onnext data sources:

Source Code Management System: CVS, Subversion, Git,Mercurial, etc.Mailing Lists or ForumsBug Tracking Systems: Bugzilla, GNATs, Trac, Redmine, etc.Source code: Releases

Others.


Introduction

http://find/

http://goback/




ResultsConclusions

Motivation

Even more: there exist meta-repositories of informationOSSMole, FLOSSMetrics, SRDA, Ohloh

Those meta-repositories store information from developmentactivities and from different perspectives


Introduction

http://find/

http://goback/




ResultsConclusions

Motivation

Thus, what if we start to use meta-repositories as a centralizedway of retrieving information for those quality models?


Introduction

http://find/

http://goback/




ResultsConclusions

Motivation

General problems found from people willing to use information

from software repositories:Different systems with different APIsDifferent representations of the same kind of informationPerformance when analyzing a huge set of dataLost data (e.g. when migrations take place)Damage to FLOSS projects infrastructure


Introduction

http://find/

http://goback/



MethodologyResults

Conclusions

Motivation

This paper discusses how this automation is done for the

QualOSS (quality model) project and using information fromthe FLOSSMetrics (meta repository of information) database

And how this could be extended to other quality models andmeta-repositories


Introduction

http://find/

http://goback/



MethodologyResults

Conclusions

Index

1 Introduction

2 Methodology

3 Results

4 Conclusions


Introduction

http://find/

http://goback/



MethodologyResults

Conclusions

QualOSS Quality Model


Introduction

http://find/

http://goback/



MethodologyResults

Conclusions

QualOSS Quality Model

Size and Regeneration Adequacy: The degree to which the

size evolution and regeneration of a FLOSS community

happens at an adequate rate to maintain a sustainable community size.

Interactivity and Workload Adequacy: The degree to which

the community interacts adequately and partition the

workload among FLOSS community members adequately to

maintain a community cohesion and motivated.


IntroductionM h d l

http://find/

http://goback/



MethodologyResults

Conclusions

Methodology

To measure risky situations, thresholds were defined: green,yellow, red and black

Those thresholds were derived from a statistical analysisThose thresholds show how a given project is located amongothers.

Having a black color does not mean that this project is “bad”,

but it means that the results were in the set of projects thatare most far from the average


IntroductionM th d l

http://find/

http://goback/



MethodologyResults

Conclusions

Metrics

sra2- New code contributors evolution.

sra3- New non-code contributors evolution.sra4- New core contributors evolution.

sra5- Evolution of core members who stopped contributing.

sra6- Balance between new core contributors and those who left the

project.



http://find/

http://goback/



MethodologyResults

Conclusions

Index

1 Introduction

2 Methodology

3 Results

4 Conclusions



http://find/

http://goback/



MethodologyResults

Conclusions

QualOSS method

22 out of 29 metrics were fully automated

Limitations

Environment highly dependable of the data sourcesIf the data sources are not supported by the FLOSSMetricsdatabase or the tools, then the metrics have to be manuallyretrieved.From them:

SCM: 15

Mailing lists: 4

BTS: 3



http://find/

http://goback/



MethodologyResults

Conclusions

QualOSS method

Extending this analysis to other communities, we can find, inthe FLOSSMetrics database, hundreds of projects analyzedusing the QualOSS approach (the community side, so far).

Thus, why not an extension to other quality models?



http://find/

http://goback/



MethodologyResults

Conclusions

OpenBRR, QSoS, SQO-OSS and QualOSS

Quality Method Num. metrics Num. automat. metrics

QualOSS 29 22

SQO-OSS 9 7

OpenBRR 2 2

QSoS 6 2

Table: Quality methods and their automatized community metrics



http://find/

http://goback/



gyResults

Conclusions

Index

1 Introduction

2 Methodology

3 Results

4 Conclusions



http://find/

http://goback/



ResultsConclusions

Conclusions

Other quality models different from QualOSS could bepartially automated

Other quality attributes from the QualOSS model could bepartially automated

Some strong limitations found in the automation of thequality models:

Not found data sources

Too complex metrics (e.g. there are not tools)It is necessary to have a more objective way of defining metricsand their ranges



http://find/

http://goback/



ResultsConclusions

Questions

How friendly are quality models for an automation of theirmetrics?

Is so important the human factor in the evolution of thesystems? if so, what can we do to improve their analysis?



R l

http://find/

http://goback/



ResultsConclusions

Questions?

Thanks for your attendance!

Questions?–

Daniel Izquierdo [email protected]

GSyC/LibreSoft - Universidad Rey Juan Carlos


http://find/

http://goback/

Quatic 2010: Towards automated quality models for software development communities

Documents

Transcript of Quatic 2010: Towards automated quality models for software development communities