analisi-disegno.com

Dal sito di IEEE Europe, alcuni dati interessanti su chi sta cercando personale ICT in Europa, dove, e per quali skill.

Ottimo articolo di Tom DeMarco, uno tra i più lucidi esperti di sviluppo software (autore tra l'altro, con Tim Lister, dello straordinario Peopleware).

Tutte le cause legali, nei rapporti di outsourcing dello sviluppo software, vanno nello stesso modo:
"By the 1990s, a significant part of my practice was litigation support, which was a natural consequence of raising my rates to the level that only legal departments could afford. Of course, litigation is all about failure, so perhaps I was seeing more than my share of it. Surprisingly, the failures began to look pretty much alike. Company A contracts to build a software system for Company B and is late to finish, or it goes on beyond its contracted delivery date and the work is cancelled. B sues A or vice versa, one of them hires me, and we all obsess over failure for a while and then settle. In the end, A and B are poorer, the lawyers and I are slightly richer, and nothing has changed. "

E tutti i progetti in ritardo hanno qualcosa in comune... "All projects that finish late have this one thing in common: they started late."

Meno banale di quanto sembrerebbe a prima vista, come si scopre leggendo le motivazioni di DeMarco nell'articolo "All Late Projects Are the Same", comparso su IEEE Software Nov/Dec 2011, disponibile gratuitamente.

Pubblicato il video di un webinar sulla gestione requisiti del novembre 2011, dal titolo "I requisiti nello sviluppo software. Leggi generali e varianti contestuali".

Black Box Software Testing (BBST) è una serie di corsi online creati da Cem Kaner e gestiti dalla Association of Software Testing (AST).

I corsi della serie sono:

• Foundations - Introduzione alle tematiche principali del testing del software
• Bug Advocacy - Gestione del rapporto tra chi fa test, chi sviluppa, e gli altri ruoli coinvolti nei progetti software
• Test Design - Panoramica e confronto tra le tecniche di progettazione dei test

Sono corsi impegnativi (anche Foundations), progettati con un'attenzione particolare agli aspetti didattici e formativi, molto utili. Sia per chi si sta avvicinando al testing che per chi già lo pratica a livello professionale.

Una descrizione più approfondita in questo articolo di Cem Kaner.

Se nello sviluppo software intervenissero solo due persone, chi vuole il
sistema e chi lo realizza, avremmo un solo canale di comunicazione.

La comunicazione potrebbe funzionare più o meno bene. Il committente
potrebbe avere le idee più o meno chiare ed esprimersi in modo più o
meno efficace, e chi realizza potrebbe capire ciò che il committente
vuole, oppure no. Sarebbe, comunque, una comunicazione diretta, con i
vantaggi e gli svantaggi del caso.

Se invece il numero degli interlocutori aumenta, ad esempio perché
intervengono ruoli specializzati, come analisti, architetti software,
progettisti, aumenta anche il numero di comunicazioni da gestire.

I ruoli intermedi, in quanto specializzati (l'esperto di analisi,
l'esperto di software design), possono e devono fornire un valore aggiunto.

Il numero delle comunicazioni, in ogni caso, cresce, e possono crescere
i tempi necessari a comunicare. Se le comunicazioni avvengono in
sequenza può aumentare anche il livello di rischio.

Quando ero bambino, alcuni decenni fa, giocavamo un gioco dal nome che
oggi fa sorridere: il telefono senza fili. Ci si metteva in fila, e il
primo bambino diceva sottovoce e velocemente una frase nell'orecchio del
secondo bambino, che a sua volta la ripeteva velocemente all'orecchio
del terzo, che la ripeteva all'orecchio del quarto, e così via. Alla
fine, la frase che arrivava all'ultimo bambino era certamente diversa
dalla frase iniziale.

Nello sviluppo software può andare anche peggio. Perché ogni sviluppo
software si basa su un insieme di requisiti che non sono fissati
all'inizio, ma si precisano gradualmente, nella progressiva acquisizione
di conoscenza che coinvolge tutti i partecipanti al progetto.

Più ruoli intermedi esistono tra chi ha l'esigenza e chi implementa, più
sono le comunicazioni da gestire. Più le comunicazioni avvengono in
sequenza (a catena), più crescono i tempi di realizzazione. E i rischi
di incomprensione.

Semat, Software Engineering Method and Theory, ha reso pubblica la propria proposta all'Object Management Group.

Quando si rilascia un sistema, la reazione degli utenti può essere classificata in diverse categorie.

Chi usa il sistema, e chi no. Chi è favorevole al sistema, e chi no.

Può accadere che alcuni usino il sistema pur essendo contrari a farlo. E che altri non lo usino pur essendo favorevoli.

Inoltre, altri stakeholder, pur non usando il sistema direttamente, sostengono o contrastano la diffusione e l'uso del sistema.

Un caso reale, legato alla diffusione di un software per i medici di base da parte del governo in Olanda, è descritto in un articolo di Dong Back Seo, Albert Boonstra e Marjolein Offenbeek, su Communications of the ACM, novembre 2011.

Aziende con sede in grandi città, dove il costo del lavoro e della vita è elevato, che esternalizzano attività di sviluppo verso altre strutture, ubicate in aree dove il lavoro costa meno e ci sono meno rischi di turnover.

Succede negli Usa, in India, in Cina, in Israele. Può essere più efficace dell'outsourcing all'estero, come descrive un articolo su IEEE Computer (dicembre 2011) di Mary Lacity, Erran Carmel, Joseph Rottman:

"The two biggest drivers are low costs and high retention rates. Rural outsourcers can offer clients lower prices than ITO and BPO providers based in big cities. On the East or West Coast, for example, an IT analyst/programmer can cost $80 to $100 per hour, while rural outsourcing rates are $45 to $65 per hour. Retention rates among rural outsourcers are also high—more than 96 percent for the providers we studied—because there are few, if any, competitors to poach workers in rural communities"

Prendersi cura dell'architettura, nel tempo, come se fosse un giardino. "Gardening Your Architecture" è il titolo di due articoli di Frank Buschmann su IEEE Software, July/August e September/October 2011.

Analogie e differenze tra refactoring (ristrutturazioni locali, limitate, mirate), reengineering (ristrutturazioni complessive) e rewriting (rifacimento) delle applicazioni.

In particolare vengono elencate le motivazioni per il reengineering, "an activity that protects existing core investments":
"There are four main reasons to contemplate reengineering:

• Refactoring is insufficient for achieving the required qualities.
• Bug fixes in one place repeatedly cause bugs in other places.
• New operational or functional requirements can't be realized appropriately within the given architecture.
• The business case for the system changed."

Buschmann conclude con un confronto tra le tre forme di intervento:

• "Continuously practice refactoring. It's cheap and (mostly) under the radar, and helps minimize the need for reengineering.
• Consider reengineering when refactoring doesn't help or is inappropriate. But be aware that it's expensive and requires much ritual.
• Consider rewriting when reengineering doesn't help. But know that it's often very risky."

I benefici della certificazione CMMI non sono quelli di ricevere un "bollino", ma di migliorare in modo sostanziale la produttività e la qualità dello sviluppo software.
Con un ritorno di investimento molto elevato, particolarmente per i livelli più elevati (4 - Managed e 5 - Optimizing).

Sul tema, il numero monografico Jan/Feb 2012 di Crosstalk - The Journal of Defense Software Engineering