21 maggio 2008

Cosa leggere - Grandi libri

Stando così le cose in Italia, due problemi mi stanno particolarmente a cuore.

Prima di tutto, la sistematica sottovalutazione del merito e della competenza, che da trent'anni ci fa perdere competitività nel mondo.

Poi, la trasmissione del sapere. Che è un effetto della sottovalutazione del merito, come si vede dai meccanismi di selezione a livello di docenze universitarie, a livello di quadri politici, e di management in una parte consistente del settore pubblico. Ma che è anche una concausa del declino della competitività italiana. I paesi in cui si studia poco e male vanno sempre peggio, in una economia mondiale basata sulla conoscenza e sull'innovazione.

Cosa leggere. Nel sessantotto avevo dieci anni, ma il clima culturale degli anni seguenti vedeva con sospetto la tradizione, si amava piuttosto la rottura degli schemi. In quel contesto, la proposta di percorso culturale formulata da Mortimer Adler (negli Usa, prima metà del novecento) non mi era arrivata. E se fosse arrivata, l'avrei guardata con molto sospetto. Sbagliavo.

Adler proponeva un percorso di apprendimento basato sulla lettura dei Grandi Libri, in una certa sequenza. La scelta dei libri e della sequenza è certamente incompleta, e riflette uno specifico punto di vista (quello di Adler) e una specifica cultura (quella statunitense della prima metà del secolo scorso). Ma la lista di Adler ha tre vantaggi:
  1. fornisce una guida sintetica, che la scuola a miei tempi non dava in modo altrettanto efficace
  2. include testi sia "umanistici" che "scientifici", contribuendo a superare la distanza tra le due culture
  3. non contiene testi mediocri o scadenti.
Nella situazione attuale della scuola e della cultura in Italia, l'elenco dei Grandi Libri di Adler può essere un buon punto di partenza. Purtroppo, l'elenco aggiornato è in Wikipedia edizione inglese. Un elenco in italiano, anche se riferito ad una versione precedente, è curato da Valentino Sossella.

Letteratura divertente

Sembra quasi un ossimoro (in questo caso, due parole che dicono una il contrario dell'altra).

Eppure esiste, in Italia, una letteratura divertente. Non solo quella lontana del tempo e considerata minore, dall'Ariosto in poi, che può essere difficile da leggere oggi perché la lingua è cambiata (almeno un po'). Esiste anche una letteratura italiana recente (del novecento) divertente. Achille Campanile, per fare un nome (ad esempio Gli asparagi e l'immortalità dell'anima, Vite di uomini illustri, Il povero Piero). O Ermanno Cavazzoni (es. Vite brevi di idioti).

La letteratura divertente esiste, ma non viene insegnata a scuola (ai miei tempi, negli anni settanta, non veniva neppure citata), né data da bere in televisione. L'unica è il passaparola.

16 maggio 2008

Lo saprò quando lo vedrò

Barry Boehm - Making a Difference in the Software Century

Un eccellente articolo su IEEE Computer, marzo 2008 (in realtà, si tratta di un estratto della introduzione scritta da Boehm per l'antologia dei propri scritti, pubblicata nel 2007 da IEEE CS Press-John Wiley & Sons ).


Riporto un paio di passi.

Il primo, sulla difficoltà per gli utenti di chiarire i requisiti in anticipo :

"Spesso, quando si chiede agli utenti di specificare come vorrebbero interagire con una nuova applicazione, essi rispondono “Lo saprò quando la vedrò” (IKIWISI - I’ll Know It When I See It). In questi casi, usare un modello a cascata sequenziale, specificare-prima-i-requisiti, diventa di solito la ricetta per un sistema inefficace e per un mucchio di costosi rifacimenti".


Il secondo, sul conflitto tra punti di vista ed interessi tra gli stakeholder di progetto:

"Il fatto che ci siano molti conflitti potenziali tra i principali stakeholder significa che il progetto può entrare in situazioni in cui uno vince e un altro perde. E una situazione del genere di solito diventa una situazione in cui perdono tutti.

In situazioni simili è importante gestire le aspettative degli stakeholder, lavorare di più per assicurare che la soluzione proposta sia fattibile e adeguata agli interessi di tutti, e negoziare un insieme globalmente soddisfacente e vantaggioso di specifiche, piani e risorse, prima di procedere con lo sviluppo. Quando si negoziano i requisiti, nei momenti iniziali è meglio sostituire termini che possono essere interpretati come non negoziabili, ad esempio il termine 'requisiti' (cose richieste con autorità e diritto) con parole come 'obiettivi' e 'scopi'."

07 maggio 2008

About us

aboutus.org è un'organizzazione che ha tra i suoi obiettivi il miglioramento dei servizi offerti dalle aziende su web, attraverso critiche costruttive e pubbliche da parte degli utenti.

L'ho scoperta perché attualmente vi lavora Ward Cunningham (tra le altre cose, ideatore dei Wiki e ispiratore di Extreme Programming), le cui iniziative sono normalmente da seguire con attenzione.

Potrebbe servire a diffondere anche in Italia la pratica della critica pubblica e costruttiva dei servizi web?

28 aprile 2008

Being Your Own Boss

Watts Humprey è il padre del Software Engineering Institute e del Capability Maturity Model.

In una serie di cinque articoli, tratteggia l'atteggiamento mentale di sviluppatori e manager nei confronti dello sviluppo software.

1: The Ideal Job
2: The Autocratic manager
3: Knowledge Work
4: Being a Victim
5: Building Trust

Legge di Conway

"Ogni organizzazione che progetti un sistema (sistemi informativi, e non solo) produrrà inevitabilmente un design la cui struttura è una copia della struttura comunicativa dell'organizzazione."

Melvin E. Conway “How Do Committees Invent?” Datamation 14(4), April 1968

In altri termini, esiste uno stretto rapporto tra l'organizzazione dello sviluppo e l'architettura dei sistemi che un'organizzazione produce.

Conoscevo la legge di Conway grazie agli Organizational Patterns of Agile Software Development di James Coplien e Neil Harrison, ma non avevo letto il testo originale di Melvin Conway, apparso nel 1968. Vale la pena farlo.

Patterns of Agile Adoption

Un articolo di Mike Cohn su Agile Journal delinea alcuni possibili percorsi per modificare il processo di sviluppo di un'organizzazione verso una maggiore agilità.

Cohn descrive tre coppie di alternative:

  • partire con progetti pilota o intervenire contemporaneamente su tutti i progetti ("Start Small or go All In?")
  • iniziare dalle pratiche agili più "tecniche" o partire dall'approccio iterativo ("Technical Practices First or Iterative First?")
  • partire di nascosto o pubblicizzare in anticipo il cambiamento ("Stealth Mode or a Public Display of Agility?")

Per ognuna delle alternative, vengono elencati vantaggi e svantaggi.

10 aprile 2008

Usabilità ed esperienza utente

"Usability" e "user experience" sono espressioni diverse. La prima per qualcuno rimanda a problemi di forma, la seconda a problemi di sostanza. Ma non è così. Un intervento interessante al riguardo è stato pubblicato da Tom Stewart, il chair del gruppo di lavoro per l'aggiornamento dello standard ISO 13407 - the International Standard for Human Centred Design.

"The ISO concept of usability is much closer to this definition of user experience than it is to the concept of ‘easy to use’ so we have decided to use the term user experience in the new version of ISO 13407 (which will be called ISO 9241-210 to bring it into line with other
usability standards"

Scrum e pattern organizzativi

Un altro materiale interessante relativo a Scrum è stato prodotto da Jim Coplien. Coplien è, tra le altre cose, autore del testo fondamentale sui pattern organizzativi, cioè sui principi guida organizzativi per lo sviluppo software.
James Coplien, Neil Harrison: Organizational Patterns of Agile Software Development, Prentice-Hall 2005 (il titolo è purtroppo fuorviante, in quanto il testo non parla in specifico dei processi agili, ma dei pro e dei contro delle diverse modalità di organizzare lo sviluppo software).

A proposito di Scrum, è disponibile (sul sito di Jeff Sutherland, uno degli originatori di Scrum) una recente presentazione di Coplien che mappa Scrum ai pattern organizzativi, e ne evidenzia la necessità di un'adozione consapevole.

Scrum scalabile

Scrum è un processo agile nato per fare fronte in modo controllato a situazioni progettuali con requisiti poco determinati, e instabili. Dato che si tratta di situazioni progettuali comuni, Scrum si sta diffondendo.

Un articolo di Scott Ambler sottolinea la necessità di riflettere sulle modalità di adozione di Scrum nelle organizzazioni, sfruttandone i vantaggi ma senza dimenticare gli insegnamenti di decenni di storia dell'Information Technology e dello sviluppo software.

Modernizzazione del software

Computerworld segnala l'offerta di servizi da parte di HP per la modernizzazione di applicazioni legacy. I servizi offerti si avvalgono di strumenti (non in vendita) che analizzano il codice e ne evidenziano su grafici le parti più bisognose di rifacimento o modifica. Tra i concorrenti di HP sul fronte della modernizzazione vengono citati IBM e Microfocus.

L'idea di modernizzazione del software è intrigante dal punto di vista di marketing e ancora di più dal punto di vista teorico.

02 aprile 2008

Il mercato dei Database relazionali

Un articolo su Information Week fa il punto sulla diffusione dei principali database management system.

Vengono presi in esame prodotti commerciali e open source. La crescente diffusione dei DBMS open source non sembrerebbe intaccare le quote di mercato dei prodotti commerciali, e del resto il contesto dei DBMS open source è in movimento, particolarmente dopo l'acquisizione di MySql AB da parte di Sun.

31 marzo 2008

CMMI + altri metodi e standard

Se si cerca la soluzione unica e definitiva ai problemi dello sviluppo e della gestione dei sistemi informatici, può capitare di pensare che CMMI (Capability Maturity Model Integration), ISO, ITIL, CoBIT, Six Sigma, lean, processi agili, ecc. siano tra loro alternativi. Non è così, afferma Mike Phillips del Software Engineering Institute, che chiarisce le relazioni tra i diversi approcci al miglioramento dell'IT.

Per analisi più dettagliate delle relazioni tra CMMI e altri approcci, un buon punto di partenza è questo.

L'analista (definizione di Karl Wiegers)

"Lo sviluppo dei requisiti è un’attività di esplorazione. L’analista non è un semplice scrivano che registra ciò che dicono i clienti. L’analista è un investigatore che pone domande per stimolare il ragionamento dei clienti, cercando di scoprire informazioni nascoste e di generare nuove idee."

Karl E. Wiegers: More About Software Requirements, Microsoft Press 2006.

Scegliere lo strumento giusto per la gestione dei requisiti - o forse nessuno

Selecting The Right Requirements Management Tool — Or Maybe None Whatsoever.
Un report di Forrester Research (Carey Schwaber e Peter Sterpe), del settembre 2007.

Riporto l'executive summary:
"Many of today’s requirements management tool purchases are misguided: Application development and program management professionals often buy requirements management tools for the wrong reasons and select tools that are out of line with their needs. To avoid purchasing tools that are more complex and more expensive than necessary, app dev organizations need to be realistic about the problems that a requirements management tool can address, the level of tooling that they require, and their ability to build and maintain tool integrations."

Nelle indicazioni finali, viene suggerito di prendere in considerazione strumenti integrati in una soluzione complessiva di ALM (Application Lifecycle Management), piuttosto che strumenti stand-alone, isolati.

Il report è scaricabile, previa registrazione, dal sito di Computerworld.

UML - Apogeo 2007 (recensione)

Autore: Enrico Amedeo
Titolo: UML. Imparare a descrivere sistemi orientati agli oggetti graficamente e in modo standard.
Editore: Apogeo. Anno edizione: 2007

Punti di forza:
  • Discreta copertura di UML, corredata da esempi Java. Utile per l'aggancio tra UML e gli aspetti di programmazione.
  • Prezzo contenuto (7,50 euro)
Punti di debolezza:
  • Alcune imprecisioni concettuali, (ad esempio il fatto che i diagrammi di sequenza consentano di descrivere il dettaglio dell'implementazione degli algoritmi).
  • Parecchia attenzione ai dettagli, manca però qualche accenno all'uso di UML per la rappresentazione di alto livello dell'architettura del sistema.

UML pratico - Paravia 2007 (recensione)

Autori: Ernesto Damiani, Mauro Madravio, Andrea Bőhm
Titolo: UML pratico. Con elementi di ingegneria del software. 2a edizione.
Editore: Paravia Bruno Mondadori Editori. Anno edizione: 2007

Punti di forza:

  • Introduzione generalissima a varie tematiche relative allo sviluppo software, tra cui UML. Forse valida come primo approccio all'ingegneria del software, ma solo in ambito universitario.

Punti di debolezza:

  • Sulle 150 pagine, solo 50 circa parlano di UML. Diagrammi di attività, stato, package, componenti e deployment sono condensati in 10 pagine. Il livello è davvero elementare.
  • UML 2 non è trattato, nonostante la data di pubblicazione sia il 2007, se non in un appendice di 2 pagine copiata quasi integralmente da un mio articolo (non citato).

Elenco strumenti gestione requisiti

Pubblicato da Incose (International Council on Systems Engineering). Utile.

Consente un confronto delle caratteristiche dei diversi strumenti di gestione requisiti. Con riferimenti ai siti dei produttori, che hanno la responsabilità delle dichiarazioni pubblicate (la cui attendibilità, pertanto, è tutta da verificare) e del loro aggiornamento.

Le iniziative metriche durano poco

Secondo Ed Yourdon, solo il 10% circa delle iniziative intraprese dalle organizzazioni per impiantare un sistema metrico in ambito software ha una durata superiore ai 18 mesi.

Perché? I motivi, secondo Yourdon, sono principalmente legati ai conflitti politici interni alle organizzazioni.

Previsioni a partire dai function point

In un intervento sulla mailing list requirements-engineering, Capers Jones, un'autorità nelle statistiche relative allo sviluppo software, ha fornito queste indicazioni:

"Function point size raised to the 0.4 power gives a useful prediction of
development schedules in calendar months. (Agile projects should use the 0.34
power).

Function point size raised to the 1.25 power gives a useful and alarming
prediction of the probable number of bugs that will be encountered.

Function point size raised to the 1.2 power predicts numbers of test cases
needed.

Function point size divided by 150 predicts development team size."