Italia: 80.000 imprese IT

La Camera di Commercio di Milano ha pubblicato i risultati di una propria elaborazione sui dati del registro imprese.

Riporto l'intestazione:
"LA CARICA DELLE 80 MILA IMPRESE INFORMATICHE ITALIANE
+7,4% in quattro anni, 4 miliardi di euro di commercio estero
25 mila nuove assunzioni di personale qualificato nel 2008
Lombardia e Milano prime in Italia per imprese. Seguono Roma e Torino."

Userei meno trionfali, visto lo stato dell'economia italiana in generale e del settore IT in particolare. 80 mila imprese (la grande maggioranza individuali!) è un dato sconsolante, indice di frammentazione e debolezza.

UML 2.2 e SysML 1.1

L'Object Management Group (OMG) ha approvato le nuove versioni di:

UML (Unified Modeling Language) 2.2, disponibile per il download la documentazione in formato beta con barre di cambiamento per evidenziare le pochissime novità.

SysML (Systems Modeling Language) 1.1, disponibile per il download al SysML Forum.

Software perfetto

"Perfect Software and other illusions about testing". È un libro di Gerald Weinberg, uscito da poco.

Tra tutte le attività collegate al software, il testing è l'attività più fraintesa. Anche dai professionisti dello sviluppo.

Il libriccino è sottile, scritto bene, si legge in fretta, non entra in dettagli tecnici. Un'ottima introduzione alla realtà del testing, per chiunque lavori in un progetto, per i manager, per i committenti. Anche per chi di software sa poco o nulla.

Story Maps

Rappresentare le funzionalità di un sistema in un modo comprensibile sia agli stakeholders che agli sviluppatori. E inoltre utile per indicare le priorità.

La tecnica delle "story maps" è semplice. Jeff Patton la descrive in questo intervento.

Moscow e priorità

Il primo corso a cui partecipai sull'analisi dei sistemi - tanti anni fa - insegnava ad usare per i requisiti una classificazione MoSCoW.

MoSCoW è un acronimo che sta per:
* Must have - si deve avere
* Should have - si dovrebbe avere
* Could have - si potrebbe avere
* Won't have - non si deve avere

Non ho mai usato la classificazione MoSCoW, anche se suggestiva. E non l'ho mai insegnata nei miei corsi. Ho sempre usato la tecnica di classificare i requisiti in termini di priorità, che ritenevo più efficace.

In realtà, comunque, non mi sono mai messo a ragionare a fondo sulla classificazione MoSCoW. L'ha fatto invece James Shore, in un intervento che condivido.

Precisare i requisiti

Un intervento di Tom Gilb su Requirements Network:
"Requirements Relationships: A Theory, some Principles, and a Practical
Approach"

Tom Gilb è uno dei padri dell'approccio iterativo e
incrementale, con il metodo Evo (1988).
Per quanto riguarda la gestione dei requisiti, il suo contributo
fondamentale è stato l'introduzione di Planguage, un linguaggio per
precisare i requisiti.

Requirements Network è un sito che pubblica settimanalmente articoli
sulla gestione requisiti.
Bisogna registrarsi con user e password per accedere, scaricare
articoli, commentare, intervenire.

I requisiti si scoprono meglio dopo

Esprimere requisiti per un sistema che esiste già è molto più facile che esprimerli per uno che non esiste ancora.
Vedi il sistema, lo usi, capisci quello che non funziona, quello che manca, quello che si potrebbe, vorrebbe, dovrebbe migliorare. Immediato.
Molto più facile che rispondere a domande su come si vorrà qualcosa che non esiste ancora, o sulla correttezza di un modello, o di una specifica.

Su questo assunto (di semplice buon senso) concordano tutti gli esperti di sviluppo software.

Naturalmente, bisogna vedere come trarne le conseguenze quando si cala l'assunto in un contesto di sviluppo professionale, con relazioni cliente-fornitore, contratti, ecc.
Su questo, un intervento interessante di Martin Fowler.

TED: idee che vale la pena diffondere

TED (Technology Entertainment Design). Ideas worth spreading.

Una collezione di video di durata contenuta (in genere non più di 20 minuti), con relatori e contenuti eccellenti. Non solo IT, purtroppo senza sottotitoli.

Tra quelli che ho visto:

Jill Bolte Taylor: My stroke of insight

Ken Robinson: Do schools kill creativity?

Benjamin Zander: Classical music with shining eyes

Il web per i cellulari

La prossima estinzione del WAP, secondo quanto pubblicato da Software Development Times. I cellulari sono ormai diventati dei normali client.

Italia ancora meno competitiva nell'IT

La conferma di un trend, secondo una ricerca pubblicata dalla Economist Intelligence Unit e ripresa dal sito di Computerworld Italia

Le scuole in Finlandia

Insegnare è un mestiere prestigioso, e selettivo. In Finlandia.

L'educazione è considerata "the centrepiece of national identity. So hard work and good behaviour are the norm; teaching tempts the best graduates (nearly nine out of ten would-be teachers are turned down)." Economist, 26 giugno 2008

Nove candidati all'insegnamento su dieci vengono scartati. I risultati si vedono: gli allievi delle scuole finlandesi compaiono ai vertici delle classifiche internazionali per capacità di comprensione ed espressione testuale, matematica, scienze.

Co-evoluzione di problemi e soluzioni

Mentre ragioniamo sulle possibili soluzioni ad un problema, la stessa definizione del problema può dover essere riformulata.

Uno studio interessante sul disegno creativo, di Kees Dorst e Nigel Cross: "Creativity in the design process: co-evolution of problem-solution"

Il modello di co-evoluzione tra spazio dei problemi e spazio delle soluzioni è stato formalizzato in:

Maher, M L, Poon, J and Boulanger, S Formalising design exploration as co-evolution: a
combined gene approach, in Gero, J S and Sudweeks, F (eds.) Advances in Formal Design Methods for CAD, Chapman and Hall, London, UK (1996)

You Tube e simili

Mi colpiscono soprattutto due cose:

1. che nessuno, mai, prima d'ora, neppure i centri informativi più ricchi che siano mai esistiti, ha mai avuto a disposizione questa varietà di registrazioni in tempi così rapidi. Possiamo vedere ciò che è stato trasmesso ieri dalle televisioni di tutto il mondo, ma possiamo anche vedere filmati realizzati da una miriade di produttori non professionali, con punti di vista eventualmente contradditori rispetto alle versioni degli eventi rese pubbliche dai governi e dalle fonti informative consolidate.

2. che nessuno, mai, prima d'ora, ha mai potuto vedere e ascoltare tante persone viventi o vissute. Posso vedere filmati di Nietzsche, del Mahatma Gandhi, di Jimi Hendrix, di qualunque personaggio pubblico di cui abbia mai sentito parlare che sia vissuto negli ultimi cento anni o più. Ascoltare le voci. Diventerà (è già diventato) normale, ma io, oggi, lo trovo impressionante.

Incremental Commitment Model

Barry Boehm e Jo Ann Lane: "Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering", in CrossTalk, October 2007

Many projects have difficulties in integrating their hardware, software, and human factor aspects.

In comparison to the software-intensive RUP, the ICM also addresses hardware and human factor integration. It extends the RUP phases to cover the full system life cycle: An Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on architecting (a term based on describing concurrent development of requirements, architecture, and plans),
which adds feasibility evidence; the RUP Construction and Transition phases are combined into the Development phase; and an additional Operation phase combines
operations, production, maintenance, and phase-out. Also, the names of the milestones
are changed to emphasize that their objectives are to ensure stakeholder commitment
to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system objectives and a set of architecture diagrams. Thus, the RUP Life-Cycle Objectives (LCO) milestone is called the Architecture Commitment Review (ACR) in the ICM, and the RUP Life-Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).

In comparison to the sequential waterfall and V-model, the ICM explicitly does the following:
• Emphasizes concurrent engineering of requirements and solutions.
• Establishes feasibility rationales as pass/ fail milestone criteria.
• Enables risk-driven avoidance of unnecessary documents, phases, and reviews.
• Provides support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment.

Agile è troppo rigido...

Kunal Mittal Executive Director, IT, Sony Pictures Entertainment: The software development life cycle for Web 2.0. Realize the benefits of agile development.

"You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid [...] User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing."

Secondo me, esagera. Ma è indicativo del fatto che l'approccio agile è ritenuto ormai consolidato.

Google ci sta facendo diventare stupidi?

'Is Google Making Us Stupid?' è un articolo di Nicholas Carr, pubblicato su The Atlantic Online, July/August 2008.

Il titolo è ad effetto, ma il nostro istupidimento non è causato in modo specifico da Google. Il problema è "What the Internet is doing to our brain", le modifiche che Internet porta al nostro modo di apprendere e pensare.

Carr segnala, partendo dalla propria personale esperienza e da quella di altri utenti, che chi frequenta in modo sistematico la rete si abitua ad una modalità di apprendimento e di elaborazione del pensiero diverse rispetto a quelle a cui era abituato. Più frammentarie, meno riflessive. Per alcuni versi, il discorso rimanda a quello trattato trent'anni fa da Neil Postman (in Amusing Ourselves to Death - anche in italiano) sugli effetti del modello culturale visuale - pubblicitario - televisivo.

Il wiki e la civiltà

The Software Practitioner è una newsletter (a pagamento) curata da Robert Glass. Sul numero gratuito di maggio 2006, scaricabile come esempio, in fondo, c'è una storiella intrigante sul wiki e la civiltà, di Peter e Dorothy Denning.

Tecnologie di collaborazione

Peter Denning, Peter Yaholkovsky: 'Getting to "We". Solidarity, not software, generates collaboration.' in Communications of the ACM, April 2008.

'Collaboration occurs when a community creates a solution to a messy problem that takes care of all their concerns at the same time. Collaboration is an ideal achieved far less often than it is invoked. It is often confused with information sharing, cooperation, or coordination. Most of our “collaboration technologies” are actually tools for information sharing.

[...] Collaboration does not mean that you give up or compromise your dearest concerns. It means designing a solution that recognizes your concerns. The process often leads to a reconfiguration of everyone’s concerns. The hallmark of successful collaboration is the

experience of solidarity and new energy: a “we”.'

L'offshoring cresce

Charalambos L. Iacovou and Robbie Nakatsu: 'A Risk Profile of Offshore-Outsourced Development Projects' in Communications of the ACM, June 2008.

'According to Forrester Research, 65% of American and European enterprises (with 1,000 or more employees) currently use offshore providers for application development; another 13% plan to begin doing so in the next year. Two years ago, only 45% of such organizations utilized offshore vendors to develop applications.'

Lo sviluppo in team distribuiti a livello internazionale

Michael Cusumano: 'Managing Software Development in Globally Distributed Teams' in Communications of the ACM, February 2008.

Cusumano raccomanda uno sviluppo agile, basato su un contratto "iterativo" tra cliente e fornitore, con definizione progressiva dei requisiti e distribuzione guidata dalle scelte architetturali.

Nulla di nuovo e di rilevante, se non un segnale di quanto gli approcci agili siano ormai considerati come la base necessaria anche per lo sviluppo software distribuito.