Live report da ICSE 2011 – Giorno 1

Short link: http://wp.me/pfeh0-dJ

Keynote

h 8.35: Inizia il primo keynote, K. Nakakoji – Interacting, continuity, sketching & experience

Pare scarso per una conferenza come icse, e non molto in tema: si parla delle differenze tra modellazione e realizzazione — Bridging the World of using with the World of making

Esempio: un pickup e una sportiva sono modellate differentemente, ma dal punto di vista realizzativo (funzionalità ) sono molto simili

La scelta di un nome è un importante esempio di modellazione .

h 8.39: pessime illegibili slides per una che si occupa d interaction design.  Mostra i tipi d dicument per la comunicazione tra interaction designer e programmatori. I designer producono sketch, i programmatori prototipi.  Questa difficoltà di comunicazione tra designer e programmer deriva dal fatto che realizzare e usare sono completamente diversi tra loro.

h 8.55: Nota folkloristica: Carlo Ghezzi molla dopo meno di mezzora…

Ora che i computer sono potenti devono diventare più confortevoli

Nota folkloristica. Come al solito gli americani mettono l’aria condizionata a palla negli ambienti chiusi. Mi copro per entrare, mi svesto per uscire…

h 9.00: Altra gente dalle retrovie molla…

h 9.05: Ora e’ un esodo

h 9.11: Mostra alcuni pattern di interazioni per applicazioni touch per ipad ipod

h. 9:29 Mollo anche io per ristudiarmi il programma… Vedo gente annoiata, mi chiedo chi farà domande…

h 9:37 Conclude finalmente

Prima domanda, giusta , ci può dire come valutiamo la bontà dei tool specifici per il software engineering…

Classica risposta da parole al vento di quando non si sa che rispondere.

Conclusione: Non sarà scarsa ma questo keynote credo c’entrasse poco con icse. Peccato

Short link: http://wp.me/pfeh0-dJ

 

New ideas and Engineering Results Track

h 10.45: Assisto alla sessione dove c’è Irwin Kwan, il dottorando di Dana. Hanno pochissimo tempo per ciascuno, 5 min.

h 10.58:  Irwin parla di emergent people. Per capirci, sono quelle persone che vengono aggiunte in cc perché interessate da un email che non avevano inizialmente ricevuto. Quindi si parla di delay in communication. Studio condotto su un corpus di email di un sw team della Dell in Brasile.

Scenari di emergent people:

1. crisis – email mandata a tutti i senior lead team developer che poi inoltrano (scenario spread & pray).

2. broker – un senior developer non sa come rispondere e gira una domanda a qualcun altro.

h 11.03 Irwin conclude

h 11.04 Parla C. Treude, dottorando di Peggy Storey. Analisi condotta su siti web di supporto che offrono domande e risposte (Q&A) riguardo al software. Le domande più risposte sono quelle di tipo “How to…”.

Hanno considerato siti, tra cui il noto StackOverflow, in cui le risposte possono essere votate come utili o no, e assegnare punti agli utente (stile yahoo answers). Questo perché è importante il “trust”.

h. 11.08: Iniziano le domande

Tra un po’ mi sposto per andare a seguire la sessione sull’Empirical Sw Eng.

h 11.15: Judith Bishop fa una domanda a tutti gli speaker, giusto per citare Pex4Fun, ma in maniera un po’ imbarazzante tutti le rispondono che non vedono cosa c’entri un tool per sfide di programmazione nel cloud con quanto detto finora…  😀

h 11.25: Un tipo inglese parla di Desk Space e, va bene il riuso, ma almeno rimuovere il nome della vecchia conferenza…

 

SEIP Empirical Sw Eng

h 11.45 Seguo A case study in SOA-based platform desing for socio-cultural analysis.

Paper abbastanza inutile.  Socio-cultural analysis usato come buzzword. Devo riguardarlo, ma mi pare un yet another paper on SOA.

 

Empirical Luau I

h. 1.48 Con Rafael a seguire la sessione sul Empirical Sw Eng, in particolar modo per assistere al talk di Cataldo / Herbsleb

Peccato che i proceedings siano solo elettronici, avrei voluto sfogliarli.

h 1.49 Presentazione sul refactoring a livello API. Distingono modifiche che fixano bug con modifiche che modificano le interfacce pubbliche di classi. Quindi, dimostrano che dopo che sono occorse delle modifiche a livello API comporta un incremento di modifiche per bug fixing, in una finestra di 20 revisioni seguenti. Hanno scoperto che le modifiche a livello API occorrono perché c’e’ un errore da sistemare, ma il primo refactoring non è corretto e/o completo. Hanno anche speculato che quando occorrono delle revisioni a livello API il tempo medio per il bug fixing (di bug pre-esistenti) si accorcia mediamente, perché i programmatori conoscono bene quelle zone del codice che hanno modificato e quindi, fixano gli altri non relati giacché ci sono.

h 2.09 Bel paper – si può selezionare per il prossimo corso di Sistemi per la Collaborazione.

h 2.11 La presentatrice incassa i complimenti di J. Herbsleb

h 2.13 Marcelo Cataldo inizia il suo talk. Investigano technical and organizational aspects in failures during integrations,

Nota di folklore. Parte allarme iCal durante la presentazione: Cataldo è un tipo molto occupato e avrebbe dovuto avere un meeting proprio ora 😉

h 2.14 Dati raccolti dallo sviluppo di un software for automotive infotainment system

h 2.19 Misure caratterizzanti le features (changed LOCs, interdependencies, etc…) vs Misure caratterizzanti le organizzazioni coinvolte (# groups, feature owners, …)

h 2.20 Cosa porta alle failure: i risultati; dal punto di vista tecnico, sono le interdipendenze tra le features e tra le features e le componenti; dal punto di vista organizzativo, sono il numero di gruppi responsabili e il numero di siti su cui lo sviluppo delle features sono distribuiti. Risultati abbastanza in linea con le aspettative.

h 2.30 Una cosa interessante. Se ci sono molte interdipendenze tra le feature, anche i gruppi collocati hanno problemi di integration, non solo quelli GSD. Si potrebbe obiettare che se ci sono troppe feature interdipendenti ci potrebbe essere qualcosa che non va dal punto di vista architetturale.

h 2.34 E infatti un tedesco glielo fa notare. Dice che il progetto esiste da 15 anni … architect molto esperti nel dominio…. boh, direi io.

h 2.40 All in all, un paper discreto, anche se non al livello degli altri di Cataldo e Herbsleb, si può selezionare per il prossimo corso di Sistemi per la Collaborazione.

h 2.42 Nuovo paper.

h 2.43 Paper che cerca di capire che impatto hanno C e C++ sul maintenance. Che differenze reali, a dispetto della popolarità e reputazione.

h 2.46 Risultati C++ >> C. Il contributo credo sara’ il framework per valutare empiricamente la facilità di maintenance.

Nota folkloristica. Di solito gli americani sono molto easy e informali nell’abbigliamento quando participano alle conferenze. Ma i livelli che raggiungono alle Hawaii… se posso, cerco di scattare una foto a tradimento a qualcuno…

h 2.50 Progetti considerati VLC, MySQL, Firefox, Blender. Tutti grandi da 200K LOC in su. Contengono parti C e parti C++.

h 2.51 Considerano solo sviluppatori che committano sia per moduli C sia per moduli C++.

h 2.53 La % di codice C++ aumenta nel tempo a scapito di quella C. Tranne che per Blender.

h 2.54 C++ è di qualità migliore del C — minore complessità ciclomatica e minore complessità di interfaccia (# parametri + # di return)

h 2.56 C++ è meno error prone in termini di defect density

h 2.58 C++ più manutenibile (metrica maintenance effort)

h 3.01 Non capisco perché lo chiami framework di confronto tra linguaggi. Sono confronti basati su metriche pre-esistenti.

Nota di folklore: Al prossimo “Good point” o “Good question” in risposta a una domanda, me ne vado… (a nuotare)

h 3.05 Fanno notare che potrebbero aggiungere altro alla complessità ciclomatica, come il coupling, fan-in / fan-out.

 

Evento sociale: Luau (danza tipica hawaiiana) @ 6:00pm