analisi-disegno.com

UML 2.4 è stato sottoposto all'iter di approvazione formale da parte dell'Object Management Group (notizia dal blog di Steve Cook).

Il gruppo di lavoro sta iniziando a lavorare sulla versione 2.5, con l'obiettivo primario (e lodevole) di semplificare la specifica.

Quanto ci ricordiamo una settimana dopo aver letto un testo scientifico?

Uno studio ha confrontato i ricordi di gruppi diversi di studenti. Un primo gruppo aveva semplicemente letto una volta il testo, un secondo gruppo lo aveva letto 4 volte, un terzo gruppo lo aveva letto 2 volte, ma dopo ognuna delle due letture aveva affrontato un test di apprendimento sugli argomenti trattati dal testo.

Gli studenti che avevano letto 4 volte ricordavano il 64% in più rispetto agli studenti che avevano letto una sola volta. Ma gli studenti che avevano sostenuto i test ricordavano il 145% in più rispetto agli studenti che avevano semplicemente letto una volta.

Lo studio, di Jeffrey D. Karpicke e Janell R. Blunt della Purdue University, è pubblicato su Science.
Sull'argomento, una nota interessante di Jakob Nielsen.

"Scegliere un analista comporta molto più che selezionare la persona con maggiore esperienza in una particolare tecnologia o dominio.

La verità è che dovete trovare qualcuno che sia indipendente delle applicazioni e delle tecnologie all'interno del vostro ambiente e che abbia soprattutto le capacità fondamentali che servono a un analista. La seconda cosa di cui dovete sincerarvi è che abbiano una personalità adeguata al vostro ambiente e al ruolo assegnato.

La cosa meno importante sono le tecnologie specifiche su cui hanno esperienza (a meno che non si tratti di un ambito molto particolare, che richiede una lunghissima curva di apprendimento). Un bravo analista ha la capacità di entrare nel merito dei problemi e di imparare nuove tecnologie molto rapidamente."

Barbara Davis, "Competency Based Assessment, Selection & Management of Business Analysts", in Requirements Network.

Uno studio pubblicato nel 2008 da Barry Boehm, Ricardo Valerdi e Eric Honour esamina il ritorno di investimenti (ROI) nelle pratiche di system engineering (requisiti, riduzione dei rischi architetturali, project management).

Lo studio prende in esame 151 progetti software, analizzati secondo la griglia interpretativa del metodo COCOMO (Constructive Cost Model).

Tra i risultati più rilevanti:

• le pratiche di system engineering hanno un effetto positivo generalizzato in termini di aumento della produttività e di riduzione dei costi, a prescindere da altri fattori
• il livello di system engineering opportuno varia in funzione delle dimensioni e della criticità dei progetti (al crescere delle dimensioni e della criticità, è necessaria una quota maggiore di attività di system engineering)

Lo studio riporta una serie di considerazioni specifiche relative al ROI delle attività di system engineering in progetti che comportano relazioni di outsourcing.

Barry Boehm, Ricardo Valerdi, Eric Honour, "The ROI of Systems Engineering: Some Quantitative Results for Software-Intensive Systems," Systems Engineering, Volume 11, Issue 3, April 2008, pp. 221-234, disponibile all'indirizzo http://csse.usc.edu/csse/TECHRPTS/2008/usc-csse-2008-808/usc-csse-2008-8...

La relazione tra IT e BPM (Business Process Management), in un articolo di Paul Harmon.

Le scadenze hanno effetti sia negativi che positivi.

Ci mettono sotto pressione:

"When your mind is pressured, it actively begins shutting things down. Your vision narrows—literally as well as figuratively. You no longer consider options. It would seem that deadlines, in general, are very bad for your cognitive processing."

Ma senza scadenze, le attività corrono il rischio di non essere completate:

"You need deadlines. If it weren’t for deadlines, nothing would get done. But be mindful of the consequences. If the consequences of missing the deadline are fearsome, then you can expect that your brains will start shutting down as the deadline approaches."

Ne parla Andy Hunt, uno dei Pragmatic Programmers. Da leggere.

David L. Parnas: "Risks of Undisciplined Development", in Communications of the ACM, 10/2010.

"Recent experiences reminded me that the activity we (euphemistically) call software engineering does not come close to deserving a place among the traditional engineering disciplines. [...]

Many of us preach about the importance of determining the requirements a software product must satisfy, but we do not show students how to organize their work so they can systematically produce a requirements specification that removes all user-visible choices from the province of the programmer. [...]

We are caught in a catch-22 situation:

* Until customers demand evidence that the designers were qualified and disciplined, they will continue to get sloppy software.
* As long as there is no better software, we will buy sloppy software.
* As long as we buy sloppy software, developers will continue to use undisciplined development methods.
* As long as we fail to demand that developers use disciplined methods, we run the risk—nay, certainty—that we will continue to encounter software full of bugs."

Un pattern sulla composizione dei gruppi di lavoro, formulato anni fa da Linda Rising, che ne parla in un articolo recente su IEEE Software, "The Benefit of Patterns".

Pochi giorni fa è morto Watts Humphrey, fondatore del Software Engineering Institute (SEI).

Dijkstra, grande informatico olandese, morì nel 2002. Solo ora, però, Communications of the ACM ha pubblicato uno stralcio di una sua intervista del 2001, davvero interessante.

L'intervista completa è disponibile gratuitamente sul sito del Charles Babbage Institute.