I rischi dello sviluppo indisciplinato

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."

Non più di dieci

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".

Watts Humphrey

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

Edsger W. Dijkstra

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.

L'Italia, la corruzione, il mondo

Un articolo su The Economist del 28 ottobre 2010 riporta i dati del Corruption Perception Index di Transparency International, organizzazione internazionale con sede a Berlino.

Da vergogna la mappa, che riporto qui:

CMMI 1.3

Il Software Engineering Institute (SEI) ha pubblicato la versione 1.3 dei Capability Maturity Model: CMMI for Development (CMMI-DEV), CMMI for Acquisition (CMMI-ACQ), and CMMI for Services (CMMI-SVC.

Annuncio e pagina per il download.

Time: Arrivederci, Italia

Uno strumento di validazione per BPMN

BPMN ha le sue regole sintattiche. Di conseguenza, ogni strumento di modellazione BPMN dovrebbe verificare che i diagrammi BPMN prodotti siano validi, in termini di coerenza con le regole sintattiche dello standard.

Molti strumenti lo fanno. Difficilmente in modo completo, non sempre in modo efficace.

Bruce Silver, autore del libro più valido su BPMN, BPMN Method and Style, ha creato e reso disponibile un validatore che controlla, oltre alle regole sintattiche ufficiali, anche le regole di stile descritte nel libro.

Il validatore ha il limite (notevole) di accettare come input solo diagrammi prodotti con gli strumenti itp commerce Process Modeler for Visio e Microsoft Visio Premium 2010.

IT, Italia

Perché l'informatica italiana è nello stato disastrato in cui è?
Non c'è un motivo solo, ma tra gli altri c'è sicuramente la corruzione: http://roma.corriere.it/roma/notizie/cronaca/10_settembre_15/tangenti-arrestato-dirigente-asl-romah-1703768575684.shtml

UML, Everywhere

In un articolo pubblicato su IEEE Software, September/October 2010, ma accessibile dal suo blog, Diomidis Spinellis elenca le ragioni per cui UML, al di là della sua imperfezione, va usato da tutti coloro che documentano sistemi software.

Value delivery

Fornire valore agli stakeholder (le parti interessate al rilascio di un prodotto) è ciò che si chiede allo sviluppo software.
Ma le specifiche dei requisiti spesso dettagliano solo i dettagli sulle funzionalità, anziché affrontare in modo diretto gli interessi degli stakeholder e chiarire ciò che per gli stakeholder è davvero importante.

"What's Fundamentally Wrong? Improving our Approach Towards Capturing Value in Requirements Specification", un articolo di Tom Gilb con Lindsey Brodie, su Requirements Network (per leggerlo, serve una registrazione gratuita).

Due tipi di progetto software

Due tipi di progetto software: quelli di base, a cui si chiede semplicemente di tirare fuori un prodotto che funzioni bene, e quelli strategici, che danno un vantaggio competitivo in termini di business.

Tra i due tipi di progetto sono diversi i rischi, le competenze necessarie, il modo di procedere.

Martin Fowler: Utility Vs Strategic Dichotomy.

Ristrutturazione di UML

Un articolo (su Dr Dobb's) di Ivar Jacobson e Steve Cook sulla ristrutturazione in corso della specifica di UML e sugli sviluppi futuri della notazione.

10 regole per prodotti di successo

Video di un intervento di Donald Norman alla conferenza Better Software 2009.

Norman è uno tra i massimi esperti di usabilità, famoso soprattutto per il libro "The Design of Everyday Things", tradotto e pubblicato da Giunti con il triste titolo all'italiana "La caffettiera del masochista. Psicopatologia degli oggetti quotidiani".

Tecno austerità

"Meno è meglio".

"I tecnologi si stanno risvegliando ai vantaggi del minimalismo, per due motivi: il fastidio per l'eccessivo numero di funzionalità dei prodotti da parte dei clienti che vogliono solo che le cose funzionino, e una forte richiesta da parte di clienti meno ricchi provenienti dai paesi in via di sviluppo."

The Economist, 12 giugno 2010.

Nuove versioni di UML e SysML

Revisioni minori, nulla di sostanziale.

UML 2.3 (maggio 2010)
Superstructure Specification - pdf, con barre di cambiamento: formal/2010-05-06

SysML 1.2 (giugno 2010) - pdf, con barre di cambiamento: formal/10-06-02

Ostacoli all'agilità

Articolo breve e succoso di Johanna Rothman: "Barriers to Agility". Argomenti:

• Scegliere il giusto progetto pilota
• Scegliere il gruppo giusto per il progetto pilota

"Se non avete la possibilità di creare un piccolo gruppo di lavoro multifunzionale, che lavori su un unico progetto, non avete l'ambiente organizzativo giusto per iniziare a operare in modo agile."

L'articolo è apparso su PragPub, una rivista online mensile pubblicata dai Pragmatic Programmers.

Tecnica: atto tradizionale efficace

"J'appelle technique un acte traditionnel efficace (et vous voyez qu'en ceci il n'est pas différent de l'acte magique, religieux, symbolique). Il faut qu'il soit traditionnel et efficace. Il n'y a pas de technique et pas de transmission, s'il n'y a pas de tradition. C'est en quoi l'homme se distingue avant tout des animaux: par la transmission de ses techniques et très probablement par leur transmission orale."

Marcel Mauss: "Les techniques du corps", 1934

Arrivo a Mauss , sociologo noto soprattutto per i suoi studi sul significato del dono, tramite un articolo di Edoardo Sanguineti, uscito sul Corriere della Sera lo stesso giorno in cui il poeta e critico è morto durante un'operazione in un ospedale di Genova.

Una poesia di Yeats

W.B. Yeats - "He Wishes For the Cloths of Heaven"

HAD I the heavens’ embroidered cloths,
Enwrought with golden and silver light,
The blue and the dim and the dark cloths
Of night and light and the half light,
I would spread the cloths under your feet:
But I, being poor, have only my dreams;
I have spread my dreams under your feet;
Tread softly because you tread on my dreams.

W.B. Yeats (1865–1939)

Ho incontrato questa poesia seguendo un nuovo intervento di Ken Robinson, esperto inglese di formazione, su TED.
Per chi non conoscesse Robinson, può essere utile seguire l'intervento precedente, con sottotitoli in italiano.

Giochi per la formazione IT

Il mio interesse per il software è scaturito, trent'anni fa, quando mi è stato presentato un problema da risolvere con un flow chart, e mi ha appassionato come i giochi della Settimana Enigmistica.

L'uso dei giochi per la formazione sta forse crescendo: "Puzzle-Based learning for Engineering and Computer Science", su IEEE Computer, April 2010. (In inglese, i puzzle non sono solo i giochi in cui si incastrano le tesserine, ma anche tutti i giochi logici, linguistici, enigmistici, matematici.)