Deadline

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

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.

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.

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.

Architettura e agile

Un numero di IEEE Software, March/April 2010, con articoli incentrati sul rapporto tra "agilità" e architettura.

Rilevante un testo di Roland Faber, "Architect as Service Providers", secondo cui gli architetti software devono assumere la responsabilità di soddisfare i requisiti non funzionali, mentre ai progettisti / sviluppatori compete quella di soddisfare i requisiti funzionali.

Vecchi programmatori

Interessante l'intervento di Brian Marick, e interessanti i commenti.

Semat

Semat è un'iniziativa di rifondazione dell'ingegneria del software, avviata nel novembre 2009.

Proposta da Ivar Jacobson, Bertrand Meyer e Richard Soley (OMG), ha un sito web dove è possibile consultare obiettivi, documenti prodotti e stato dei lavori.

Interessanti i "position papers" pubblicati da alcuni tra gli aderenti.

Interessante la critica di Alistair Cockburn, che si è ritirato dall'iniziativa dopo il primo meeting di lavoro.