software engineering

Ci sono ancora architetti software che non sviluppano? Sì, nelle organizzazioni ancora influenzate dall'approccio a cascata. Ma il fenomeno è in calo, afferma Philippe Krutchen in IEEE Software, May/June 2011, Walking across the Seam.

"In our industry, I see fewer software architects throwing their designs over the wall to the hordes of programmers. In many organizations, these entities— architects and programmers—are roles, not individuals, and we've known for a long time that the best architects are also implementers; and vice versa, the best programmers understand the function of architecture and respect it.

The architect-programmer dichotomy might still exist, mostly in large organizations, as a sort of remnant of the waterfall approach, where the organization tended to match the phases. But today, the most successful software development organizations are staffed by people with a broad range of competencies, able to embrace multiple roles. We hear calls for more T-shaped individuals and less hyperspecialists."

Perché ci sono poche donne nel mondo del software? Poche, si intende, rispetto a quante potrebbero essercene, costituendo almeno il 50% della popolazione.

Per inclinazione? Per attitudine? Improbabile, sostiene Martin Fowler in questo articolo.

Fowler sottolinea come la compresenza di persone diverse tra loro (per genere, per razza, per cultura) nel settore del software sia estremamente vantaggiosa. E come in Cina, ad esempio, la presenza delle donne nel mondo del software sia, in percentuale, molto più alta che negli USA.

Solo quando il software viene effettivamente usato dagli utenti possiamo sapere se a loro va bene o no. Ovvio, no?

Tutte le attività di testing che facciamo prima del rilascio, comprese quelle di far usare il sistema a "utenti proxy" (cioè non agli utenti reali, ma a persone che vorrebbero rappresentare gli interessi degli utenti reali), non ci possono dare la certezza del fatto che il software sarà davvero apprezzato.

Possiamo fare ipotesi, speculazioni, ragionare in termini di probabilità. Ma la realtà verrà fuori solo dopo il rilascio.

Elisabeth Hendrickson ne parla in "What Software Has in Common with Schrödinger’s Cat".

Perché le verifiche sistematiche (ispezioni) su documenti di progetto e su codice vengono usate così poco, visto che sono il metodo più efficace ed efficiente per rimuovere difetti nei prodotti software?
Capers Jones e Olivier Bonsignour, su Dr.Dobb's, danno la loro risposta: perché non c'è nessun interesse commerciale a promuoverle.

Dal 1994, ogni due anni, Standish Group comunica i risultati delle sue statistiche sull'andamento di migliaia di progetti di sviluppo software nel mondo: il Chaos Report.
I dati riferiti al 2010, riportati da Computerworld, mostrano un incremento dei casi di successo (37%), una diminuzione dei casi di successo parziale (42% di progetti conclusi con meno funzioni, maggiori tempi e costi di quanto stimato inizialmente), una sostanziale stabilità di casi di fallimento (21%).

La natura dello sviluppo software consiste nella progressiva acquisizione di conoscenza, come diceva nel 2003 un eccellente libro di Phil Armour, "The Laws of Software Process". Quindi ogni analogia tra lo sviluppo del software ed i processi di produzione industriale è del tutto fuori luogo.

Il tema è ripreso nel suo blog da Alistair Cockburn, che traccia un abbozzo di storia per quello che definisce come un "movimento": il "Design as Knowledge Acquisition Movement". Secondo Cockburn, si tratta del fenomeno più rilevante successivo all'approccio agile ("Agile Movement").

Crosstalk, The Journal of Defense Software Engineering, ottimo mensile gratuito sponsorizzato dal Dipartimento della Difesa USA, è sul nuovo sito crosstalkonline.org

Semat, iniziativa lanciata nel 2009 da Ivar Jacobson, Bertrand Meyer e Richard Soley per rifondare l'ingegneria del software, comincia a dare i primi risultati.

Nel novembre 2010 i lavori di Semat sono stati ricondotti entro l'ambito dell'Object Management Group (OMG). A fine giugno 2011 è stata approvata una Request for Proposal dal titolo “A Foundation for the Agile Creation and Enactment of Software Engineering Methods”, (disponibile sul sito OMG) basata su quanto prodotto da Semat.

Cosa è un Product Manager, cosa deve fare, in quale posizione organizzativa può essere collocato (anche nell'IT, perché no). Una buona sintesi in Time to assign owners to your applications di Tom Grant su SD Times.

Quando conviene acquistare pacchetti applicativi, quando conviene adattare la propria organizzazione al pacchetto e quando invece sia opportuno personalizzare il pacchetto per adattarlo alla propria organizzazione. E se proprio si vuole personalizzare, in che modo farlo. Da Martin Fowler.