ArticlePDF Available

METODI AGILI E SISTEMI DI GESTIONE DELLE CONFIGURAZIONI

Authors:
  • Centre for Applied Software Engineering
METODI AGILI E SISTEMI DI GESTIONE DELLE
CONFIGURAZIONI
Bruno Rossi, Alberto Sillitti, Giancarlo Succi
Libera Università di Bolzano
[Bruno.Rossi, Alberto.Sillitti, Giancarlo.Succi]@unibz.it
I sistemi di gestione delle configurazioni sono una possibile fonte di
informazioni riguardo lo stato di un progetto software. Questo articolo
presenta un tool per l’estrazione e l’analisi di informazioni da
repository CVS con lo scopo di fornire dati ai progetti agili. Il tool si
propone di analizzare il processo di produzione del software senza
interferire con lo sviluppo e raccogliere dati empirici riguardo
l’efficacia dei Metodi Agili.
1. Introduzione
I sistemi di controllo delle versioni (es. CVS, Visual Source Safe, Clear Case,
ecc.) sono strumenti indispensabili per lavorare in team e sviluppare prodotti
software complessi [1]. Questi sistemi permettono ad un team di lavorare
contemporaneamente sugli stessi file sorgente gestendo automaticamente
operazioni come: tracciamento delle versioni di un file, unione di modifiche fatte
da diversi sviluppatori, ripristino di una versione precedente, ecc.
Questi sistemi sono stati progettati per memorizzare e gestire codice sorgente
ma, oltre a queste informazioni, raccolgono anche una moltitudine di altri dati
riguardanti il processo di sviluppo [3]. Questi dati comprendono: dimensione del
codice, numero di modifiche, nome dello sviluppatore che ha inserito le
modifiche, ecc. I dati memorizzati possono essere usati per ricavare
informazioni sul processo di sviluppo in modo non invasivo, cioè senza
influenzare in alcun modo il processo di sviluppo [4]. Inoltre, è possibile
analizzare non solo i progetti attuali ma anche tutti i progetti passati dei quali si
dispone ancora dei repository e, quindi, confrontarli tra loro.
Ad esempio, l’analisi dei dati raccolti in questo modo e i dati sui difetti
potrebbero essere un metodo efficace per identificare buone abitudini di
programmazione e migliorare l’intero processo di sviluppo.
Tracciare le attività compiute dai programmatori non è un compito facile per
diversi motivi tra cui:
1. richiede tempo per essere fatta con precisione [6]
2. sia gli sviluppatori sia i manager non considerano importante questa
attività perché non produce benefici immediati [5].
Per questi motivi, i dati raccolti manualmente sono spesso errati e/o incompleti,
in particolare quando sarebbe più importante disporre di informazioni corrette:
durante periodi critici come l’avvicinamento di una scadenza importante.
Molte aziende portano avanti progetti software per molti anni e le informazioni
raccolte involontariamente dai loro sistemi di gestione delle configurazioni
potrebbero essere analizzate e produrre dati utili per l’azienda. In particolare, i
project manager potrebbero usare queste informazioni storiche per verificare
quali cambiamenti al processo di sviluppo sono avvenuti nel tempo e quali
hanno prodotto un effetto positivo sul software prodotto (es: meno difetti, minore
effort, ecc.). Tutto questo lo si potrebbe ottenere senza aver pianificato di
monitorare il processo di sviluppo e senza dover aspettare di aver raccolto una
quantità sufficiente di dati, una grande quantità di dati è già disponibile in
azienda.
Questo articolo presenta una prima applicazione di CodeMart, uno strumento
per la raccolta ed analisi di informazioni di processo contenute nei sistemi di
gestione delle configurazioni [11]. L’articolo è organizzato come segue: la
sezione 2 propone un metodo di analisi dei dati; la sezione 3 presenta un primo
esperimento; la sezione 4 trae le conclusioni.
2. Analisi di repository di codice
I sistemi di gestione delle configurazioni sono una fonte di dati per lo studio
della produzione del software e sono allo studio innumerevoli metodi per
estrarne informazioni utili [3].
I sistemi di gestione delle configurazioni memorizzano il codice sorgente e le
modifiche introdotte ma non raccolgono nessuna informazione relativa al tipo di
modifica introdotta (es. aggiunta di una nuova funzionalità, bug fix, ecc.). Ai fini
dell’analisi dei dati, sarebbe molto utile disporre di queste informazioni ma
richiedere che gli sviluppatori inseriscano commenti significativi all’interno del
codice e/o quando inseriscono il codice all’interno del sistema di gestione delle
configurazioni è estremamente difficile. Nonostante questa difficoltà oggettiva, è
possibile implementare un semplice sistema di classificazione automatica delle
modifiche introdotte nel codice analizzando le differenze tra le diverse versioni
dello stesso file memorizzate all’interno del sistema di gestione delle
configurazioni [7].
Una classificazione semplice delle modifiche introdotte nel codice è la seguente
[11]: (1) commenti, (2) modifiche strutturali, (3) modifiche non strutturali
Le modifiche di commento riguardano tutti i cambiamenti relativi ai commenti
nel codice sorgente, quindi nessuna istruzione del linguaggio.
Le modifiche strutturali sono modifiche ad istruzioni del codice sorgente che
influenzano i possibili percorsi di esecuzione del programma (es. i costrutti if-
then-else, for, do-while, switch, ecc.)
Le modifiche non strutturali sono modifiche ad istruzioni del codice sorgente
che non modificano i possibili percorsi di esecuzione del programma.
Un sistema di analisi statica del codice può facilmente individuare questi tipi di
modifiche tra le diverse versioni di uno stesso file sorgente.
Normalmente, i sistemi di gestione delle configurazioni non forniscono alcuno
strumento di supporto all’analisi dei dati, quindi è stato sviluppato CodeMart,
uno strumento in grado di estrarre il codice, pre-processalo, memorizzare i dati
interessanti in un data warehouse e, infine, fare delle analisi [2] [9].
Una delle possibili analisi che si possono effettuare sui dati raccolti in questo
modo si basa sull’analisi del comportamento degli sviluppatori. In particolare,
l’analisi di come si evolve il comportamento nel tempo in progetti simili ed in
progetti molto diversi. Per fare una analisi di questo tipo è possibile usare la
Gamma analisi [10] che è utilizzata nelle scienze sociali.
In questo tipo di analisi si identifica un insieme di stati possibili del modello (fasi)
e si analizza la loro evoluzione temporale. Nel caso delle modifiche al codice
sorgente (strutturali, non-strutturali e di commento), uno sviluppatore può
introdurre una qualunque combinazione di queste modifiche ad ogni invio del
codice al sistema di gestione delle configurazioni (Tabella 1).
Tabella 1: Fasi
Phase
Structural
modifications
Non-structural
modifications
Comment
modifications
A 0 0 0
B 0 0 0
C 0 0 0
D 0 0 0
E 0 0 0
F 0 0 0
G 0 0 0
H 0 0 0
La Gamma analisi descrive come le fasi si susseguono nel tempo e fornisce
una misura delle sovrapposizioni.
3. Analisi dei dati
Il web server Apache è stato considerato spesso in studi riguardanti l’Open
Source e lo sviluppo software [8], per questo motivo è stato utilizzato per fare
un primo test di questo strumento analizzando i repository delle versioni 1.2, 1.3
e 2.0.
Questo primo esperimento vuole investigare l’applicabilità della Gamma analisi
all’analisi del processo di sviluppo del software. Nel caso considerato, l’ipotesi
sperimentale consiste nel ritenere che i precedence score e i separation score
relativi ai progetti considerati siano scorrelati. Dato il numero esiguo di progetti
considerati, non è possibile fare una analisi statistica vera e propria ma i valori
ottenuti saranno valutati qualitativamente.
Tabella 2: Precedence score
Apache
Version
A B C D E F G H
1.2 -0.10 -0.01 -0.07 0.10 0.02 0.06 0.00 0.01
1.3 -0.15 -0.04 -0.07 0.24 -0.01 0.02 -0.02 0.03
2.0 -0.13 0.06 0.00 0.15 0.11 0.02 -0.01 -0.19
Tabella 3: Separation score
Apache
Version
A B C D E F G H
1.2 0.33 0.24 0.35 0.38 0.35 0.08 0.29 0.30
1.3 0.28 0.27 0.30 0.38 0.30 0.08 0.33 0.29
2.0 0.32 0.29 0.32 0.35 0.31 0.16 0.33 0.33
La Tabella 2 riassume i precedence score dei progetti evidenziando il fatto che
tutti questi valori non sono rilevanti, visto che quasi tutti sono compresi
nell’intervallo [-0.2; 0.2]. Questo significa che non è possibile identificare un
ordinamento all’interno delle fasi. Inoltre, in ogni categoria, i valori dei tre
progetti considerati sono piuttosto “simili”.
I separation score elencati nella Tabella 3 sono anch’essi molto “simili”
all’interno delle diverse categorie ma presentano una situazione diversa.
Eccetto i valori associati alla fase F, tutti i valori sono maggiori di 0.2, quindi
esiste una separazione tra le fasi (più o meno marcata a seconda dei casi).
Secondo questi dati, gli sviluppatori tenderebbero a separare le fasi identificate
nella Tabella 1. Non è possibile affermare quali tipi di modifiche vengano fatte
prima ma è possibile affermare che le modifiche sono organizzate a blocchi che
tendono a non mischiarsi tra loro.
4. Conclusioni
Il sistema presentato in questo articolo è la prima versione di un sistema
progettato per l’identificazione di sequeze di dati rilevanti all’interno dei sistemi
di gestione delle configurazioni ed avente lo scopo di estrarre informazioni
riguardo al processo di sviluppo. Questo lavoro è solo una prima analisi
esplorativa dell’applicabilità dell’analisi Gamma ai dati provenienti da sistemi di
gestione delle configurazioni.
5. Bibliografia
[1] P. Cederqvust, “Version Management with CVS” – website:
http://www.cvshome.org/manual
[2] R. Cooley, B. Mobasher, J. Srivastava, “Web Mining: Information and Pattern Discovery on
the World Wide Web”, Proceedings of the 9th IEEE International Conference on Tools with
Artificial Intelligence (ICTAI'97), Novembre 1997.
[3] M. Fisher, J. Oberleitner, J. Ratzinger, H. Gall, “Mining Evolution Data of a Product Family”,
2nd International Workshop on Mining Software Repositories (MSR 2005), St. Louis, MO,
USA, 17 Maggio 2005.
[4] P.M. Johnson, “You can't even ask them to push a button: Toward ubiquitous, developer-
centric, empirical software engineering”, The NSF Workshop for New Visions for Software
Design and Productivity: Research and Applications, Nashville, TN, USA, Dicembre 2001.
[5] P.M. Johnson, H. Kou, J. Agustin, C. Chan, C. Moore, J. Miglani, S. Zhen, W.E.J. Doane,
“Beyond the Personal Software Process: Metrics collection and analysis for the differently
disciplined”, 25th International Conference on Software Engineering, Portland, OR, USA, 3 -
10 Maggio 2003.
[6] P.M. Johnson, A.M. Disney A.M., “A critical analysis of PSP data quality: Results from a
case study”, Journal of Empirical Software Engineering, Dicembre 1999.
[7] S.J. Metsker, “Building Parsers with Java”, Adison-Wesley, 2001.
[8] A. Mokus, R.T. Fielding, J. Herbsleb, “A Case Study of Open Source Development: The
Apache Server”, International Conference on Software Engineering, Limerick, Ireland,
Maggio 2000.
[9] J. Myllymaki, J. Jackson, “Web-based data mining, Automatically extract information with
HTML, XML, and Java”, IBM developerWorks, http://www-
106.ibm.com/developerworks/web/library/wa-wbdm/?dwzone=web
[10] D.C. Pelz, “Innovation Complexity and Sequence of Innovating Strategies”, Knowledge:
Creation Diffusion, Utilization, Vol. 6, 1985, pp. 261-291.
[11] Sillitti A., Succi G., “Source Code Repositories and Agile Methods”, 6th International
Conference on eXtreme Programming and Agile Processes in Software Engineering
(XP2005), Sheffield, UK, 18 - 23 Giugno 2005.
ResearchGate has not been able to resolve any citations for this publication.
Conference Paper
Full-text available
Source repositories are a promising database of information about software projects. This paper proposes a tool to extract and summarize informa- tion from CVS logs in order to identify whether there are differences in the de- velopment approach of Agile and non-Agile teams. The tool aims to improve empirical investigation of the Agile Methods (AMs) without affecting the way developers write code. There are many claims about the benefits of AMs; how- ever, these claims are seldom supported by empirical analysis. Configuration management systems contain a huge amount of quantitative data about a pro- ject. The retrieval and part of the analysis can be automated in order to get use- ful insights about the status and the evolution of the project. However, this task poses formidable challenges because the data source is not designed as a meas- urement tool. This paper proposes a tool for extracting and summarizing infor- mation from CVS (Concurrent Versions System) repositories and a set of analysis that can be useful to identify common or different behaviors.
Conference Paper
Full-text available
Pedagogues such as the Personal Software Process (PSP) shift metrics definition, collection, and analysis from the organizational level to the individual level. While case study research indicates that the PSP can provide software engineering students with empirical support for improving estimation and quality assurance, there is little evidence that many students continue to use the PSP when no longer required to do so. Our research suggests that this "PSP adoption problem" may be due to two problems: the high overhead of PSP-style metrics collection and analysis, and the requirement that PSP users "context switch" between product development and process recording. This paper overviews our initial PSP experiences, our first attempt to solve the PSP adoption problem with the LEAP system, and our current approach called Hackystat. This approach fully automates both data collection and analysis, which eliminates overhead and context switching. However, Hackystat changes the kind of metrics data that is collected, and introduces new privacy-related adoption issues of its own.
Conference Paper
Full-text available
According to its proponents, open source style software development has the capacity to compete successfully, and perhaps in many cases displace, traditional commercial development methods. In order to begin investigating such claims, we examine the development process of a major open source application, the Apache web server. By using email archives of source code change history and problem reports we quantify aspects of developer participation, core team size, code ownership, productivity, defect density, and problem resolution interval for this OSS project. This analysis reveals a unique process, which performs well on important measures. We conclude that hybrid forms of development that borrow the most effective techniques from both the OSS and commercial worlds may lead to high performance software processes
Conference Paper
Full-text available
Application of data mining techniques to the World Wide Web, referred to as Web mining, has been the focus of several recent research projects and papers. However, there is no established vocabulary, leading to confusion when comparing research efforts. The term Web mining has been used in two distinct ways. The first, called Web content mining in this paper, is the process of information discovery from sources across the World Wide Web. The second, called Web usage mining, is the process of mining for user browsing and access patterns. We define Web mining and present an overview of the various research issues, techniques, and development efforts. We briefly describe WEBMINER, a system for Web usage mining, and conclude the paper by listing research issues
Article
The Personal Software Process (PSP) is used by software engineers to gather and analyze data about their work. Published studies typically use data collected using the PSP to draw quantitative conclusions about its impact upon programmer behavior and product quality. However, our experience using PSP led us to question the quality of data both during collection and its later analysis. We hypothesized that data quality problems can make a significant impact upon the value of PSP measures—significant enough to lead to incorrect conclusions regarding process improvement. To test this hypothesis, we built a tool to automate the PSP and then examined 89 projects completed by ten subjects using the PSP manually in an educational setting. We discovered 1539 primary errors and categorized them by type, subtype, severity, and age. To examine the collection problem we looked at the 90 errors that represented impossible combinations of data and at other less concrete anomalies in Time Recording Logs and Defect Recording Logs. To examine the analysis problem we developed a rule set, corrected the errors as far as possible, and compared the original and corrected data. We found significant differences for measures such as yield and the cost-performance ratio, confirming our hypothesis. Our results raise questions about the accuracy of manually collected and analyzed PSP data, indicate that integrated tool support may be required for high quality PSP data analysis, and suggest that external measures should be used when attempting to evaluate the impact of the PSP upon programmer behavior and product quality.
Article
In case histories of innovation adoption by local governments, seven innovating stages orfunctionsfrom need identification to diffusion were coded on time ofoccurrence. A method using gamma was applied to measure the time sequence offunctions at each site, and their separation from other functions. These data were used to test the hypothesis that the stages will appear more overlapping and the innovating process more "disorderly "for innovations that are more complex. The hypothesis was supported for a measure of technical complexity but not for one of organizational complexity. The innovating process was found to be most orderly when a technically simple innovation was neither "custom-made" nor copied "ready-made, " but was modified or adapted. When the time sequences at each site were grouped into patterns such as problem-oriented versus solution-oriented, few differences on effectiveness were found, although one contingent effect was observed. Perhaps any single-factor explanation of effectiveness is bound to fall short.
Article
Parser building is a powerful programming technique that opens a world of opportunity for designing how users interact with applications. By creating mini-languages, you can precisely address the requirements of your application development domain. Writing your own parsers empowers you to access a database more effectively than SQL to efficiently control the movement of an order through its workflow, to command the actions of a robot, and to control access privileges to transactions in a system. The repertoire of today's professional programmer should include the know-how to create custom languages.Building Parsers with Java™ shows how to create parsers that recognize custom programming languages. This book and its accompanying CD provide an in-depth explanation and clearly written tutorial on writing parsers, following the Interpreter Design Pattern. An easy-to-follow demonstration on how to apply parsers to vital development tasks is included, using more than a hundred short examples, numerous UML diagrams, and a pure Java parser toolkit to illustrate key points.You will learn How to design, code, and test a working parser How to create a parser to read a data language, and how to create new computer languages with XML How to translate the design of a language into code How to accept an arithmetic formula and compute its result How to accept and apply matching expressions like th* one How to use tokenizers to define a parser in terms of logical nuggets instead of individual characters How to build parsers for a custom logic language like Prolog How to build parsers for a custom query language that goes beyond SQL How to construct an imperative language that translates text into commands that direct a sequence of actionsThe CD contains all of the examples and the parser toolkit, including more than three hundred Java classes and their corresponding javadoc. The CD also provides example programs for the new logic, query, and imperative languages that this book introduces.With the information, methods, and tools in this book/CD package, you can create new computer languages that exactly fit your domain. You can nestle a new language into any niche, defining how your users interact with computers. 0201719622B04062001
Article
Collection and analysis of empirical software project data is central to modern techniques for im-proving software quality, programmer productivity, and the economics of software project development. Unfortunately, barriers surrounding the cost, quality, and utility of empirical project data hamper effective collection and application in many software development organizations. This paper describes Hackystat, an approach to enabling ubiquitous collection and analysis of empir-ical software project data. The approach rests on three design criteria: data collection and analysis must be developer-centric rather than management-centric; it must be in-process rather than between-process, and it must be non-disruptive—it must not require developers to interrupt their activities to collect and/or analyze data. Hackystat is being implemented via an open source, sensor and web service based archi-tecture. After a developer instruments their commercial development environment tools (such as their compiler, editor, version control system, and so forth) with Hackystat sensors, data is silently and unob-trusively collected and sent to a centralized web service. The web service runs analysis mechanisms over the data and sends email notifications back to a developer when "interesting" changes in their process or product occur. Our research so far has yielded an initial operational release in daily use with a small set of sensors and analysis mechanisms, and a research agenda for expansion in the tools, the sensor data types, and the analyses. Our research has also identified several critical technical and social barriers, including: the fidelity of the sensors; the coverage of the sensors; the APIs exposed by commercial tools for instrumen-tation; and the security and privacy considerations required to avoid adoption problems due to the spectre of "Big Brother".
Conference Paper
Diversification of software assets through changing requirements impose a constant challenge on the developers and maintainers of large software systems. Recent research has addressed the mining for data in software repositories of single products ranging from fineto coarse grained analyses. But so far, little attention has been payed to mining data about the evolution of product families. In this work, we study the evolution and commonalities of three variants of the BSD (Berkeley Software Distribution), a large open source operating system. The research questions we tackle are concerned with how to generate high level views of the system discovering and indicating evolutionary highlights. To process the large amount of data, we extended our previously developed approach for storing release history information to support the analysis of product families. In a case study we apply our approach on data from three different code repositories representing about 8.5GB of data and 10 years of active development.