Valutazione Empirica di Sistemi ERP Open Source.

Gerardo Canfora, Aniello Cimitile, Davide Vetrale, Corrado Aaron Visaggio.

Abstract. La crescente diffusione del software open source, sia in termini di acquisizione, che quale

opportunità per lo sviluppo di nuovi modelli di business, richiede una comprensione più profonda

delle dinamiche che sottendono la sua realizzazione ed evoluzione. Questo lavoro riporta i risultati

preliminari di una ricerca empirica finalizzata a caratterizzare le strategie di progettazione ed

evoluzione del software open source.

1. Introduzione

Il software open source (oss) sta attraendo l’interesse sia della comunità industriale, che lo

considera una opportunità di business, che della pubblica amministrazione, che lo considera

un’opportunità per abbattere alcuni costi tipici dell’acquisizione e dell’esercizio di software

proprietario. Il lavoro [15] raccoglie alcune delle iniziative di molti governi nazionali, i quali stanno

organizzando programmi di adozione estensiva dell’oss per l’automazione dei propri uffici e

processi. Se la pubblica amministrazione è interessata nell’oss dalla prospettiva dell’utente,

l’industria sta impiegando l’oss per sviluppare nuove tipologie di servizi [14]. Per quanto concerne

quest’ultima prospettiva, Fuggetta [8] ha identificato cinque possibili modelli di business.

La crescente diffusione dell’oss, solleva, però un problema di interesse primario per la comunità

dell’Ingegneria del Software: gli attori coinvolti nel processo di acquisizione necessitano di

strumenti metodologici e tecnologici per valutare la qualità di tali software.

Purtroppo, non è stato ancora accertato come si caratterizzino il ciclo di vita del prodotto open

source ed i corrispondenti processi (progettazione, codifica, collaudo, verifica, gestione della

configurazione) che vengono realmente eseguiti; sebbene siano stati condotti diversi studi empirici,

il corpus di conoscenza è ancora immaturo. Alcune ricerche, quali quelle riportate in [13],

suggeriscono che le communità open source di successo rispettano processi rigorosi per la codifica,

l’identificazione e la correzione di difetti, la documentazione di progetto, la validazione ed il

rilascio di “patch”. Però, come atteso, una simile disciplina non è necessariamente assicurata da una

qualunque comunità open source. Come ha osservato Meo [3], dal momento che le comunità open

source hanno molti gradi di libertà, non vi è una “forma” comune a cui tutte le comunità open

source aderiscono, ma ognuna è caratterizzata da pratiche, tecniche e processi propri. Di

conseguenza, vi è ancora una notevole variabilità nella qualità degli oss. Sono dunque necessari

studi empirici che possano consentire di definire le leggi che governano l’architettura, la

realizzazione e l’evoluzione dei prodotti open source, onde poter avviare processi di acquisizione o

pianificare strategie di business in modo appropriato.

Un caso esemplare di prodotto OSS quale possibile prossimo candidato ad una massiccia diffusione

è l’ Enterprise Resource Planning (ERP): sul portale SourceForge sono presenti 351 progetti Open

Source (16.03.07), di cui 49% avviati negli ultimi 8 mesi.

L’adozione in un’organizzazione di un nuovo sistema gestionale ERP comporta alcune criticità,

soprattutto per le Piccole Medie Imprese (PMI) [7]. Questi sistemi sono complessi e supportano

processi significativi per l’organizzazione, per cui la loro introduzione richiede competenze

specialistiche e risorse economiche che spesso le PMI non possiedono. Con le soluzioni gestionali

ERP Open Source, molti di questi rischi sono mitigati, dal momento che vi è: disponibilità del

codice sorgente; abbattimento dei costi di licenza; controllo sulla qualità del prodotto; riduzione del

vendor lock-in.

In accordo a quanto premesso, questo lavoro riporta i risultati di una indagine estensiva riguardo le

caratteristiche strutturali di un campione di ERP Open Source. Tale lavoro è parte di un più ampio

programma di ricerca orientato a caratterizzare la qualità e l’evoluzione della stessa nei prodotti

open source. Il lavoro è così organizzato: nel secondo paragrafo si discute la letteratura del settore,

nel paragrafo 3 viene mostrato il metodo di analisi, nel paragrafo 4 viene discussa l’analisi dei dati;

infine, nel paragrafo 5, sono riportate le conclusioni.

2. Lavori Correlati

In letteratura sono stati analizzati differenti aspetti dei prodotti e dei processi open source.

Capiluppi [4] ha analizzato l’evoluzione di 12 progetti, studiando attributi quali la modularità, la

dimensione, ed il numero di sviluppatori partecipanti. L’obiettivo della ricerca è stato quello di

comprendere se possono essere identificati andamenti o differenze chiave con lo sviluppo di closed

software. I risultati principali mostrano che alcuni progetti raccolgono una comunità significativa di

sviluppatori, ma la maggior parte dei progetti include un numero limitato di membri e prosegue con

un passo di evoluzione molto lento.

Al crescere della dimensione, il numero di autori e di partecipanti aumenta. Le leggi dell’evoluzione

del software di Lehman’s and Belady [2] sono confermate, dal momento che è stata osservata una

crescita di dimensioni costante. La dimensione dei moduli tende a crescere fino ad un valore stabile;

infine, i progetti open source evolvono con un numero maggiore di rilasci del software tradizionale.

Godfrey and Tu [9] hanno esaminato 96 versioni del kernel Linux. Gli autori hanno, infatti, trovato

che, anche se Linux era molto grande, la crescita ha rispettato un andamento superlineare per molti

anni. Questi risultati indicano che la crescita dell’oss è maggiore di quella del software closed.

Dinh and Bieman [5] hanno analizzato alcuni aspetti dei processi open source; gli obiettivi del loro

lavoro erano di identificare: i) le caratteristiche comuni nel processo di sviluppo di progetti open

source di successo; ii) la qualità del software che è stato prodotto usando tali processi. Gli autori

hanno replicato lo studio di Mockus et al. [10] su un differente progetto open source, il FreeBSD

project, una versione open source del sistema operativo Unix. I risultati chiave sono che: i) la

densità dei difetti è minore che nel codice commerciale; ii) gli sviluppatori sono anche utilizzatori

del software e iii) il gruppo di sviluppatori “core” contribuiscono all’ 80 per cento del codice. Il

lavoro [12] ha raffrontato la qualità del software realizzati nel closed source e nell’ open source. Gli

autori hanno trovato che la qualità dell’ open source non è inferiore alla qualità del closed software:

non vi è una supremazia di uno dei due approcci, in termini di qualità. La qualità dell’oss decresce<

con i costi e gli sforzi dei programmatori; la qualità di entrambi descresce nei mercati competitivi.

Paulson et al. [11] hanno confrontato closed ed open source software, ricavando evidenza che l’oss

ha generalmente meno difetti. Ferenc et al. [6] riportano che la “fault-proneness” del software

Mozzilla diminusce nelle differenti versioni.

3. Metodo di Ricerca

L’obiettivo del lavoro di ricerca è formulato in accordo al paradigma Goal Question Metrics

(GQM) [1]:

Analizzare: il prodotto open source

Con l’obiettivo di : caratterizzare

Rispetto a: architettura.

Dal punto di vista: dello sviluppatore

Nel contesto di: open source enterprise resource planning software (ERP).

Il campione di analisi è costituito da dieci progetti open source, pubblicati in uno dei più noti

portali web di oss, ‘Sourceforge.org’ (ww.sourceforge.com). La scelta del campione è stata

motivate da due ragioni: (i) il portale è tra quelli che riporta il maggior numero di accessi, (ii)

mantiene traccia del ciclo di vita dei progetti tramite un ricco insieme di indicatori di progetto. E’

stato, inoltre, selezionato uno specifico tipo di software (ERP), al fine di avere omogeneità nelle

osservazioni.

Il 31 Luglio 2006, 202 Progetti ERP sono stati pubblicati su Sourceforge. Affinché il campione

potesse consentire un’analisi significativa, un sottoinsieme di 25 progetti che mostrano un alto

livello di partecipazione sia della comunità degli sviluppatori che di quella degli utenti. I progetti

selezionati, presentano, infatti le seguenti caratteristiche:

• la metrica di attività è maggiore del 97.00%.

• dal momento che il numero di download potrebbe dipendere dall’età del progetto, è stato

preso in considerazione un valore normalizzato (downloads/età);questo valore è maggiore di 800;

• per la stessa ragione, anche la metrica “project web hits” è stata considerata,

normalizzandola rispetto all’età (project web hits/age),e questo valore è maggiore di 800.

Per ogni progetto le metriche sono state raccolte da Gennaio 2000 a Giugno 2006, al fine di

osservare l’evoluzione dei progetti nel tempo. Le metriche rilevate sono state definite in un GQM

[14] che, per motivi di spazio, non si riporta in questa sede.

4. Analisi dei Dati

Di seguito viene fornita una specifica quantitativa (il livello di completezza) rispetto alla qualità

di interesse, la Software Architecture, ottenuta valutando gli ERP in relazione al primo goal del

modello GQM già citato [14](Analizzare: un ERP; Con il proposito di: caratterizzarlo; Rispetto alla:

Software Architecture; Dal punto di vista: dell’ingegnere del software). La figura 3.4 riporta un

punteggio cumulativo che include tutte le metriche valutate nell’analisi.

44

35

4539

3227

33

25

3428

0

5

10

15

20

25

30

35

40

45

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Somma degli Scores

Fig. 3.4. Valutazione complessiva del livello di completezza degli ERP.

Come si può osservare, non vi è molta differenza tra gli ERP del campione, i quali riportano

valori che non si discostano molto dal valore medio, eccezion fatta per i due massimi. L’ERP che ha

totalizzato il punteggio più alto numero di scores è stato OpenCRX (45) seguito immediatamente da

Compiere (44). L’ERP che ha ottenuto il punteggio più basso è stato Evaristo, con un totale di 25

scores.

Tuttavia per un’analisi puntuale, si analizzano le singole metriche che esprimono i livelli di

completezza.

0

1

2

3

4

5

6

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di Completezza attesoLivello di completezza

Fig. 3.5. Valutazione dei sistemi operativi supportati per host e server. Sistemi operativi per host e server: si osserva che il massimo è raggiunto solo da OpenCRX, ma

che il livello medio oscilla intorno a uno score pari a 4 (supporto di Microsoft NT/2000/XP e Unix).

Il livello minimo viene riportato da Yuza ed Evaristo. Tutti raggiungono il livello di completezza

atteso (Microsoft Windows NT/2000/XP). Il livello di completezza atteso per tutte le metriche viene

ricavato sulla base dei valori forniti in letteratura.

012345678

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.6. Valutazione dei sistemi operativi supportati per il client.

Sistemi operativi per client: si osserva che il valore massimo è raggiunto da quasi tutti gli ERP,

anche in corrispondenza di Evaristo che nella metrica precedente riporta il minimo (3). Yuza

continua a presentare il valore minimo, questa volta affiancato da Project-Open che nella metrica

precedente aveva ottenuto uno score medio. Il motivo per cui molti client supportano tutti i sistemi

operativi è che alcuni di essi sono realizzati in java (Compiere, OpenCRX, Evaristo), perciò sono

portabili su tutte le piattaforme java enabled. Tutti raggiungono il livello di completezza atteso

(Microsoft Windows NT/2000/XP).

012345678

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.7. Valutazione dei database e dei linguaggi di programmazione supportati. Database e linguaggi di programmazione supportati: si può notare molta variabilità nei livelli di

completezza, con un livello medio prossimo a 6, ma nessun ERP raggiunge il massimo score (10).

In accordo con la valutazione complessiva, OpenCRX presenta il massimo relativo affiancato da

Pentaho (presenta il massimo anche nella metrica precedente) ed Evaristo nuovamente il minimo,

appena sufficiente a rispettare il livello di completezza atteso.

0

1

2

3

4

5

6

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.7. Valutazione della capacità del sistema di gestire l'Import/Export dei dati. Formato dei dati importati ed esportati: Nessun ERP raggiunge il livello massimo (7), questo

perchè il formato lotus non viene supportato da nessuno. Si osserva una forte variabilità, ma

OpenCRX non riporta il valore massimo per questa metrica. In questo caso il massimo relativo

viene raggiunto da Compiere e Project-Open, mentre il minimo da webERP che col suo score (1)

scende addirittura al di sotto del livello atteso (2). In questa metrica Evaristo presenta ben 2 score in

più del livello minimo.

0

2

4

6

8

10

12

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.8. Valutazione della capacità del sistema di gestire la scrittura di report. Report supportati dal sistema: si può notare che il livello medio oscilla attorno a uno score 7, con

il massimo (11) raggiunto da Compire e il minimo ancora una volta da Evaristo affiancato in questa

metrica da FreeERP. OpenCRX come nel caso precedente non presenta il valore massimo, ma

comunque un livello più alto delle restanti metriche.

0

1

2

3

4

5

6

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.9. Valutazione degli elementi di supporto al cliente nelle varie attività. Strumenti di supporto al cliente per lo svolgimento delle attività: si osserva una forte variabilità

dei valori che vanno da uno score di 1 raggiunto da Yuza e, come nella metrica precedente, da

Evaristo e FreeERP, ad uno score di 6 per Pentaho che, se pur non raggiunge il massimo (8),

rappresenta il massimo relativo. OpenCRX continua a fornire uno score inferiore al valore

massimo.

0

1

2

3

4

5

Compiere

Openta

ps

OpenC

RX

Pentah

o

]Projec

t-Ope

n[Yuz

aTuto

s

Evaris

to

webERP

FreeErp

Livello di completezza attesoLivello di completezza

Fig. 3.10. Valutazione del livello di libertà che l’utente ha riguardo la creazione di forms. Form disponibili per l’utente: si osserva una leggere variazione (un solo score) dal valore 4, anche

se nessun ERP raggiunge il valore massimo. Compiere, OpenCRX e webERP (per la prima volta)

presentano il massimo relativo, Yuza il valore minimo, mentre Evaristo si assesta sul valore medio.

5. Conclusioni

Questo lavoro riporta i risultati preliminari di una indagine estensiva sulle strategie di progettazione

ed evoluzione dei software open source. Nella fattispecie, è stata caratterizzata l’architettura, in

termini di strategie progettuali, di un campione di ERP open source. Il miglior ERP della

valutazione è risultato OpenCRX con uno score di 45 seguito da Compiere con un punteggio di 44.

Entrambi sono risultati i migliori in 4 metriche su 7 (57%). L’ERP che ha totalizzato il livello più

basso è stato Evaristo con uno score pari a 25 seguito da Yuza che ha ottenuto solo 2 score in più

(27). Evaristo è risultato il peggior ERP in 4 metriche (57%), il migliore solo in una (14%).

Nonostante abbia ottenuto un punteggio appena superiore ad Evaristo, Yuza è risultato il peggior

ERP in ben 5 metriche su 7 (71%) e mai il migliore. La ricerca ha consentito di suffragare l’assunto

che attualmente non si possono identificare linee comuni nelle strategie progettuali dei progetti

open source. Inoltre la maggiore diffusione di uno specifico oss non esalta connotati di

polarizzazione in nessuna delle caratteristiche analizzate, ma, piuttosto rafforza le differenze e ne

enfatizza le singolarità.

Bibliografia [1] V.R. Basili, G. Caldiera, and H.D. Rombach, "Goal/Question/Metric Paradigm." In Marciniak J.J., editor, Encyclopedia of Software Engineering, vol. 1, pp. 528-532. John Wiley & Sons, 1994. [2] L.A. Belady, and M.M. Lehman, ”An introduction to Program Growth Dynamics”, in Statistical computer Performance Evaluation, W. Freiburger (ed.), Academic Press, Ny, 1972, pp. 503-511. [3] M. Berra, and A.R. Meo, Informatica solidale. BollatiBoringhieri, Torino, Italy, 2001. [4] A. Capiluppi, “Models for the evolution of open source projects”, proc. of the Int’l Conference on Software Maintenance (ICSM’03), Amsterdam, The Netherlands, 2003, IEEE CS, pp.65-74. [5] T.T. Dinh-Trong, and J.M. Bieman, “The FreeBSD Project: A Replication Case Study of Open Source Development”, IEEE Trans. on Software Engineering, vol. 31, no. 6, June 2005, pp. 481-494. [6] R. Ferenc, I. Siket, and T. Gyimothy, ”Extracting Facts from Open Source Software”, proc. of the 20th IEEE Int’l Conference on Software Maintenace (ICSM ’04), Chicago, Illinois, USA, 2004, IEEE CS, pp. 60-69 [7] A. Fuggetta, “Open source software: an evaluation”. Journal of Systems and Software, vol. 66, no. 1, Elsevier, 2003, pp. 71-90. [8] A. Fuggetta, “Open Source and Free Software: A New Model for The Software Development Process?” Upgrade (The European Journal for the Informatics Professional), vol.V, no.5, October 2004, pp. 22-26 (last access on the 5th Sept 2006, at http://www.upgrade-cepis.org/index.html). [9] M. Godfrey, and Q. Tu, “Evolution in Open Source Software: A Case Study”, proc. of Int’l Conference on Software Maintenance (ICSM ‘00), San Jose, CA, USA, 2000, IEEE CS, pp.131-142. [10] A. Mockus, T. Fielding, D. and Herbsleb, “Two Case Studies of Open Source Development: Apache and Mozzilla”, ACM Trans. Software Eng. And Methodology, vol. 11, no. 3, July 2002, ACM, pp.309-346. [11] J.W. Paulson, G. Succi, and A. Eberlein, “An Empirical Study of Open-Source and Closed Source Software Products”, IEEE Trans. On Software Engineering, vol.30, No.4, April 2004, pp.246-256. [12] S. Raghunathan, A. Prasad, K.M. Birendra, and H. Chang, “Open Source versus Closed Source: Software Quality in Monopoly and Competitive Market”, IEEE Trans. On Systems,Man, and Cybernetics- Part A: Systems and Humans, vol.35, no.6, 2005, IEEE CS, pp.903-918. [13] M.A. Rossi, “Decoding the Free/Open soruce Software Puzzle, a survey of theoretical and empirical contributions”, Quaderni - Università degli Studi di Siena, April 2004, (http://opensource.mit.edu/papers/rossi.pdf#search=%22open%20source%20survey%20filetype%3Apdf%22) [14] D. Vetrale, and C.A. Visaggio, “Open Source Economics”, RCOST- Technical Report TR-VV01-2006, University of Sannio. [15] K. Wong, “Free/Open Source Software and Governments: A Survey of FOSS Initiatives in Governments”, International Open Source Network, August 2003 (accessed on the 5th of September 2006 at http://opensource.mimos.my/fosscon2003cd/paper/full_paper/kenneth_wong.pdf#search=%22open%20source%20survey%20filetype%3Apdf%22 ).