Re: [OpenSPCoop-Dev] Lista delle classi metodichedovrebberosubireRefactoring

["Walter Ambu" <walter.ambu@gmail.com>]

Ciao Luciano,

1. Per quanto riguarda il plug-in al momento è di proprietà dell'università 
di Cagliari che ha intenzione di distribuirlo come Open Source ( chiederò 
conferma)
2. Per quanto riguarda l'applicazione di XP a team distribuiti posso 
brevemente dire che abbiamo utilizzato le pratiche eccetto il pair 
programming (in realtà abbiamo attivato sessioni di pair programming (PP) 
per gruppi in base allo loro locazione; questo è stato possibile poichè il 
team era composto da persone della stessa regione).
Utilità delle sessioni  di PP:
1. sviluppo di componenti complessi
2. training per le nuove risorse

Per quanto riguarda la "metafora", posso dire che l'abbiamo utilizzata solo 
in casi spot. In ogni caso nella nuova versione dell'XP (XP 2) non se ne 
parla.
Il resto delle pratiche sono state utilizzate e integrate con i principi di 
Scrum.
Per quanto riguarda la gestione del team abbiamo raffinato nel team delle 
tecniche e linee guida che applichiamo e raffiniamo di progetto in progetto. 
Utilizziamo da anni un insieme di sistemi Open Source integrati che ci 
aiutano nella gestione del progetto ( Wiki, sistemi di chat, Ant, Cruise 
Control, XPSwiki (solo in certi progetti --> è un tool di gestione di 
progetti XP fatto dall'università di Cagliari e open source), Eclipse Xunit, 
Mock Objects, tool di refactoring)
Tutti questi tools ovviamente sono di supporto allo sviluppo e ai processi 
che seguiamo. Diciamo che i tools sono al servizio del team e si adattano al 
team e non viceversa (questo per mantenere lo spirito "agile").

Mi fermo qui per il momento altrimenti dovremmo stare ore ed ore a 
scrivere.... ovviamente sono a disposizione per ulteriori approfondimenti.

Ciao

Walter




----- Original Message ----- 
From: "Montebove Luciano" <L.Montebove@finsiel.it>
To: <sviluppatori@openspcoop.org>
Sent: Tuesday, May 23, 2006 1:18 PM
Subject: R: [OpenSPCoop-Dev] Lista delle classi metodi 
chedovrebberosubireRefactoring


> Walter,
>
> 1)Il plugin per Eclipse di cui parli è disponibile come Open Source od in 
> qualche altra forma?
> 2)Ci puoi dare qualche informazione in più su come avete adattato XP a 
> team distribuiti, usate qualche tool di collaborazione in particolare?
>
> Ciao
>
> Luciano
>
> -----Messaggio originale-----
> Da: sviluppatori-bounces@openspcoop.org 
> [mailto:sviluppatori-bounces@openspcoop.org] Per conto di Walter Ambu
> Inviato: martedì 23 maggio 2006 12.35
> A: sviluppatori@openspcoop.org
> Oggetto: Re: [OpenSPCoop-Dev] Lista delle classi metodi che 
> dovrebberosubireRefactoring
>
> Ciao a tutti,
> vorremmo portare il nostro contributo di esperienza riguardo queste 
> tematiche.
> Per il nostro progetto open source japs www.japsportal.org abbiamo 
> adottato delle linee guida che sono la base del nostro metodo di lavoro.
> In particolare l'intero ciclo di vita di produzione del SW è gestito 
> utilizzando le Metodologie Agili e din particolare SCRUM + Extreme 
> Programming applicato per team distribuiti che fanno sviluppo Open Source.
>
> Alcune linee guida relative al codice:
>
> 1. utilizziamo uno standard di codifica ben definito.
> 2. seguiamo precise tecniche di refactoring del codice sorgente che 
> avviene in maniera incrementale.
> 3. utilizziamo JUnit che consnete di fare test automatici  e ripetibili.
> 4. monitoriamo il progetto (codice sorgente) attraverso il calcolo delle 
> metriche CK di qualità del software.
>
> Per quanto riguarda la qualità del codice del nostro progetto open source, 
> presenteremo insieme all'università di Cagliari, alla conferenza 
> intenazionale sulle metodologie agili 
> http://virtual.vtt.fi/virtual/xp2006/,
> l'esperienza fatta in Italia di monitoring della qualità del codice 
> sorgente del progetto open source JAPS
>
> Dal gennaio 2005 ad oggi analizziamo il codice del nostro progetto ogni 15 
> giorni. Attraverso un plug in di Eclipse (IDE Java), sviluppato 
> dall'università di Cagliari, è possibile partendo da degli snapshot del 
> repository, verificare la qualità del codice sorgente utilizzando le 
> metriche CK adatte per sistemi Object Oriented:
> Queste sono le misure che facciamo sul codice:
>
> Weighted methods per Class (WMC)
> Coupling between object (CBO)
> Dept of Inheritance tree (DIT)
> Number of CHildren (NOC)
> Rsponse for a class (RFC)
> Lack of cohesion of methods (LCOM)
> Number of classes
> Class size
> Number of test cases
> Number of assertions
>
> In base ai risultati di queste analisi, sia il responsabile di progetto 
> che i programmatori ottengono continuo feedback sull'andamento del 
> progetto in riferimento alla stato di complessità del codice. In base ai 
> risultati ottenuti, siamo in grado di capire se gli sviluppatori stanno 
> scrivendo bene il codice, se il codice è object oriented, se è complesso, 
> se stanno facendo bene il refactoring, se e quanto stanno ntestando il 
> codice, etc
>
> Riferimenti per chi fosse interessato all'intervento che terremo alla 
> conferenza su questo tema:
>      Tuesday 20.6.2006
>      10:45 - 12:15 R3: Research papers: "Quality in agile software 
> development"
>
>        2. Studying the evolution of quality metrics in a Agile/Distributed 
> project, Walter Ambu, Giulio Concas, Sandro Pinna
>
>
>
>
>
>      Ciao
>
>
>      Walter Ambu
>
>
>
>
> ----- Original Message ----- 
> From: "Tito Flagella" <tito@link.it>
> To: <sviluppatori@openspcoop.org>
> Sent: Friday, May 19, 2006 9:00 AM
> Subject: Re: [OpenSPCoop-Dev] Lista delle classi metodi che dovrebbero
> subireRefactoring
>
>
> > Montebove Luciano wrote:
> >
> > > Ci sono metodi con valori di "complessità ciclomatica" veramente elevata
> > > 24,33,47,53.... su cui andrebbe fatto nel tempo un lavoro per spezzarli 
> > > in
> > > più metodi o meglio ancora in più classi facendo un minimo di analisi
> > > delle responsabilità annidate al suo interno.
> > Il nostro piano di lavoro prevede di procedere fino alla 0.8 (fine
> > settembre circa) per il completamento delle funzionalita` e
> > l'ottimizzazione. Poi la reingegnerizzazione (il "big rewrite") per
> > arrivare alla 1.0 entro fine anno. Nel frattempo gli esperti di "Software
> > Engineering" in lista, possono proporre standard guidelines o
> > raccomandazioni da discutere per arrivare ad approvare dei documenti di
> > riferimento per lo sviluppo software nel progetto?
> >
> > Ciao,
> >
> > tito.
> > _______________________________________________
> > Sviluppatori mailing list
> > Sviluppatori@openspcoop.org
> > http://www.openspcoop.org/mailman/listinfo/sviluppatori
>
> _______________________________________________
> Sviluppatori mailing list
> Sviluppatori@openspcoop.org
> http://www.openspcoop.org/mailman/listinfo/sviluppatori
>
> _______________________________________________
> Sviluppatori mailing list
> Sviluppatori@openspcoop.org
> http://www.openspcoop.org/mailman/listinfo/sviluppatori