Risorse educative aperte

Global Warming Toward Open Educational Resources, un articolo di Richard G. Baraniuk e C. Sidney Burrus su Communications of the ACM, settembre 2008.

Sulla diffusione di ambienti e strumenti gratuiti per la formazione. Tra cui:

MIT: Open-CourseWare e OCW consortium

Rice University: Connexions

Open University: OpenLearn

Carnegie Mellon University: Open Learning Initiative

Destino degli strumenti Telelogic

Dopo parecchi mesi, si è delineato il quadro di integrazione degli strumenti Telelogic (per la gestione dei requisiti e per la modellazione UML - SysML) in ambito IBM.

Il problema essenziale era come far convivere l'offerta Telelogic con l'offerta concorrente della linea Rational. Un paio di articoli (SDTimes , eWeek) fanno finalmente emergere cosa IBM propone ai propri clienti.

Modelli di stima dei costi nel software

Cocomo (Constructive Cost Model) è ritenuto comunemente il modello per la stima dei costi più completo ed affidabile in ambito software.

Achievements and Challenges in Cocomo-Based Software Resource Estimation (su IEEE Software, September-October 2008) è un articolo scritto dal padre di Cocomo, Barry Boehm, insieme a Ricardo Valerdi del MIT.

L'articolo fa il punto sullo stato dell'arte, le criticità e le tendenze nell'evoluzione dei modelli previsionali.

Tecnologie digitali e disintegrazione sociale

The Dea[r]th of Human Understanding. La penuria (la morte) della comprensione umana. Un articolo di Neville Holmes su IEEE Computer, ottobre 2008.

Holmes cita Nicholas Carr (Is Google Making Us Stupid?), ma espande la sua analisi sul ruolo e sugli effetti dei videogiochi. Pessimista, e convincente.

Princìpi di software testing (Meyer)

Da un articolo di Bertrand Meyer, uno dei nomi più importanti nel campo del software design:

• Principle 1: Definition. To test a program is to try to make it fail.

• Principle 2: Tests versus specs. Tests are no substitute for specifications.

• Principle 3: Regression testing. Any failed execution must yield a test case, to remain a permanent part of the project’s test suite.

• Principle 4: Applying oracles. Determining success or failure of tests must be an automatic process.

• Principle 5: Manual and automatic test cases. An effective testing process must include both manually and automatically produced test cases.

• Principle 6: Empirical assessment of testing strategies. Evaluate any testing strategy, however attractive in principle, through objective assessment using explicit criteria in a reproducible testing process.

• Principle 7: Assessment criteria. A testing strategy’s most important property is the number of faults it uncovers as a function of time.

Su alcuni di questi princìpi (in particolare sull'ultimo) ho dei dubbi. Ma vale la pena di leggere l'articolo (su IEEE Computer, agosto 2008), per chi ha la possibilità di accedere alla rivista (che consiglio).

La nuvola

The cloud - la nuvola. L'infrastruttura di elaborazione evaporata.

O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.

Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.

Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist.

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.

L'insegnamento e le stringhe

Alistair Cockburn: Teaching is pushing a string; learning is pulling the string

People keep asking, "What is the difference between teaching and learning? What is the instructor's role? After years of noodling, here's what I end up with:

Teaching is putting various strings in front of the students to pull on. The role of the instructor is to select and lay out the strings, indicate something about the meaning of pulling on them, etc.

Learning is their pulling on any of those strings. The role of the student is to select some strings, pull on them, abstract/note something about what happens. The instructor can't really know which strings the student is pulling on, or what the student will learn/abstract/note.

Note that this applies to parenting as much as to teachers.

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.

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

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?

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.

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.

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.

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

Software Quality Requirements

Il numero di IEEE Software di Marzo-Aprile 2008 ha come tema centrale la gestione dei requisiti di qualità.

Tra gli spunti, un confronto tra Tom Gilb e Alistair Cockburn sulla precisazione i requisiti. Gilb sostiene l'esigenza di quantificare, Cockburn ritiene che in un contesto agile non sia il caso di farlo, e che in alcuni casi possa risultare dannoso.
A differenza di quanto normalmente accade, l'esito del confronto non è per nulla conciliatorio, segno di un contrasto profondo tra i rispettivi punti di vista.

Planguage

Tom Gilb – Competitive Engineering. A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering using Planguage. - Elsevier 2005

È un testo pesante, faticoso. Però vale la pena faticare, perché Planguage è un linguaggio con costrutti utili per precisare i requisiti.

IBM e Telelogic

L'acquisizione di Telelogic da parte di una società controllata di IBM non si è ancora completata, ma è in via di conclusione. Da verificare le ricadute sui prodotti nell'area della gestione requisiti (Doors e Requisite(Pro) e del visual modeling UML (Tau, Rational Architect e Rational Modeler).

CrossTalk, marzo 2008

Nel numero di marzo 2008 di CrossTalk ("The Journal of Defense Software Engineering", la rivista software dei militari USA), tra le altre cose:

- Un articolo di Ellen Gottesdiener su "Good Practices for Developing User Requirements". L'aspetto più interessante è un elenco di modelli utilizzabili per rappresentare i requisiti utente.

- Un articolo di David Coe che riporta dati sperimentali, per quanto in ambito universitario, sull'uso degli Use Case Points.

Il cliente - Mahatma Gandhi

Nell'inserto speciale dell'Economist sull'e-government, una citazione del Mahatma Gandhi:

"Who is the customer? The customer is the most important visitor on our premises. He is not dependent on us. We are dependent on him. He is not an interruption of our work. He is the purpose of it. He is not an outsider in our business, he is part of it. We are not doing him a favour by serving him. He is doing us a favour by giving us an opportunity to do so."

La citazione è tratta da un discorso tenuto da Gandhi in Sudafrica, dove svolse attività come avvocato negli anni tra il 1893 ed il 1895.

E-government: successi ed insuccessi

Inserto speciale in The Economist del 16 febbraio 2008 su tecnologie e governo. Particolarmente interessante un articolo sugli investimenti nel settore della sanità nel Regno Unito.

L'importanza delle parole

Un eccellente (non è una novità) intervento di Gerry McGovern , esperto di gestione dei contenuti (content management), che sottolinea quanto sia decisiva l'importanza della comunicazione testuale per il successo di una iniziativa sul web.

La storia degli inizi di Rational

Descritta nel suo blog da Grady Booch. Rational è stata una delle società leader nel mondo dell'object oriented e del visual modeling, ed è nota soprattutto per essere all'origine dell'Unified Modeling Language (UML). Rational è stata acquisita 5 anni fa da IBM.

Informatici in Italia

Dalla newsletter AICA (Associazione Italiana per il Calcolo Automatico) n.23 di Novembre-Dicembre 2007, leggo che :

"Sul portale della Borsa Nazionale del Lavoro è stata attivata la sezione dedicata al Settore ICT che consentirà agli oltre 1,3 milioni di specialisti informatici del nostro Paese di orientarsi e aggiornarsi nello scenario particolarmente mutevole del settore fornendo informazioni specifiche, strumenti e servizi utili ai professionisti ICT. "

La notizia è interessante, ma se il numero degli specialisti informatici in Italia è questo, come è possibile che a livello di pubblica opinione, di politica e di relazioni di lavoro si parli così poco di questo milione ed oltre di persone?

La partecipazione degli utenti ai progetti

Erica L. Wagner and Gabriele Piccoli:"Moving Beyond User Participation to Achieve Successful IS Design" in Communications of the ACM, december 2007

L'articolo mette in luce con estrema chiarezza uno dei nodi principali dello sviluppo software.

"We suggest that rather than fighting human nature by trying to force the participation of user groups throughout a project, we should broaden our thinking about development and implementation methodologies to reflect what happens in practice. We find that in practice user participation can be most powerful after ‘go live’ when users are truly engaged.

[...] we acknowledge it will be difficult to fully engage users before the software begins to affect their daily lives, which are generally at ‘go live.’ Yet, we are not suggesting there is no value in user involvement via prototyping or phased roll-out techniques. When properly implemented, these techniques can help increase communication, provide some valuable feedback in the design process, and generally improve goodwill on the user side. But it is critical to recognize that trying to force engagement of user groups throughout a project goes against human nature. We should therefore expand our thinking about the stages of the systems development life cycle, and incorporate this broadened perspective into whichever methodology is used.
We need to recognize that implementation extends beyond “flipping the switch.” Legitimizing the post-implementation activities that are often kept as a shameful secret — a sign of project failure — will help to manage expectations and avoid much of the conflict that erodes trust between the user community, project champions, and the development team by more naturally mimicking human behavior.

[...] It is time to speak honestly about the gap between our intentions to build working systems and our ability to do so in practice. This gap is typically not caused by a lack of effort on behalf of developers or users, but rather is the result of misdirected efforts. The systems development and implementation process will continue to be overly challenging if we work against the tide by trying to make users fit our theories of how and when they should participate in development initiatives."

Sondaggio sul Business Process Management

Business Process Trends ha pubblicato il sondaggio "The State of BPM - 2008", con risposte ottenute a fine 2007. Per quanto sondaggi di questo tipo siano poco scientifici, alcuni dati sui trend sono interessanti.
Per scaricare il sondaggio è necessaria una registrazione al sito.

CMMI e processi agili

Un sondaggio curato da Scott Ambler per la Dr. Dobb's Agile Newsletter.

Inoltre, una serie di articoli sui processi adeguati per i progetti brevi sul numero di febbraio 2008 di CrossTalk, the Journal of Defense Software Engineering. Tra cui un articolo di Capers Jones che mette in rapporto CMMI e processi agili.

Casi d'uso e requisiti non funzionali

Casi d'uso per requisiti non (strettamente) funzionali. Alistair Cockburn riporta un esempio di caso d'uso per il richiamo di un servizio in ambito SOA.

Intervista al CEO di Infosys

Intervista al CEO di Infosys, la maggiore software house indiana, su Information Week. Aspettative crescenti dei clienti sull'outsourcing, esperienza e formazione degli sviluppatori indiani, differenze culturali.

Mega e BPMN

MEGA integrerà, nella proprie soluzioni per la modellazione dei processi e per l’enterprise architecture, l’ultima versione degli standard di Business Process Modeling Notation (BPMN™).
La MEGA Modeling Suite con l’ultima versione degli standard BPMN sarà disponibile nel corso del primo trimestre 2008.

Costo e produttività delle risorse umane

Martin Fowler discute il legame fra talento, produttività e costo nello sviluppo software. Di come, cioè, avvalersi della collaborazione di risorse relativamente più costose possa comportare vantaggi sotto il profilo economico.

La realtà

"Reality is the murder of a beautiful theory by a gang of ugly facts" (Robert L. Glass)

Un consiglio sentimentale

Da Ward Cunningham, sulla mailing list software testing. Cunningham è, tra le altre cose, ideatore del Wiki, di FIT - Framework for Integrated Testing, e di Extreme Programming. Ecco il consiglio:

'I have found that the world is the way it is for reasons very different from those often given as explanation. If you want to change the world, you need to understand all the forces that apply, and especially forces that are in flux. Then you stand a chance.

I don't, however, recommend that you debug your spouse. An old and wise friend of mine, who is still married to his high school sweetheart, says, "you have to decide, do you want to be right? or do you want to be loved?" '

Italia e competenza

La salvaguardia degli interessi consolidati, dei clan e dei privilegi è in conflitto con la valorizzazione del merito e della competenza individuali.

Accade in tutto il mondo. Nei paesi vitali, la valorizzazione del merito e delle competenze (nella scuola e nel mondo del lavoro) trainano l'economia e la società. In Italia, come nel terzo mondo, di solito la difesa dei privilegi e l'appartenenza a un clan hanno la meglio.

La percezione diffusa in Italia è che studiare sia inutile, e che lavorare con coscienza, professionalità e impegno non produca alcun beneficio per chi lo fa. Ecco perché l'Italia scivola nel terzo mondo.

Il pianeta dove scomparivano le cose

Roberto Casati e Achille Varzi: Il pianeta dove scomparivano le cose. Esercizi di immaginazione filosofica. Einaudi 2006 .
Per bambini, e non solo. Stimolante nei temi, semplice e colloquiale nei toni, accompagnato da disegnini elementari e simpatici. Da non perdere.

Anche: Roberto Casati e Achille Varzi: Semplicità insormontabili. 39 storie filosofiche. Laterza 2004

Testi di storia dell'informatica

Su Mondo Digitale settembre 2007 (rivista dell'AICA) c'è un articolo di Corrado Bonfanti "Corsi di Storia dell'Informatica nelle università italiane".

Cita i testi di storia dell'informatica più utilizzati dai docenti:


Letture consigliate: le più gettonate
Opere che i docenti hanno suggerito a chi volesse approfondire.
Il numero di ❑ indica il rispettivo score.
❑ ❑ ❑ ❑ M.R. Williams: A History of Computing Technology. Prentice-Hall, 1985.
Trad.it. [possibilmente da evitare!] Storia dei computer. Dall’abaco ai calcolatori elettronici. Franco Muzzio, 1989.
❑ ❑ W. Aspray (editor): Computing Before Computers. Iowa State University Press, 1990.
❑ ❑ P.E. Ceruzzi: A History of Modern Computing. The MIT Press, 2003 (2nd ed.).
Trad.it. Storia dell’informatica: dai primi computer digitali all’era di internet. Apogeo, 2006.
❑ ❑ M. Davis: The Universal Computer – The road from Leibniz to Turing; 2000.
Trad.it. Il calcolatore universale: da Leibniz a Turing. Adelphi, 2004.
❑ M. Calvo, F. Ciotti, G. Roncaglia, M.A. Zela: Internet 2004. Laterza, 2003.
❑ M. Campbell-Kelly, W. Aspray: Computer: A History of the Information Machine. Basic Books - HarperCollins Publishers, 1996.
❑ A.D. Chandler: Inventing the Electronic Century. The Free Press, 2001.
Trad.it. La rivoluzione elettronica. Egea - Università Bocconi editore, 2003.
❑ G. Ifrah: Histoire universelle des Chiffres. Éditions Seghers, 1981.
Trad.it. Storia universale dei numeri. Arnoldo Mondadori, 1983.
❑ M. Morelli: Dalle calcolatrici ai computer degli anni cinquanta. Franco Angeli, 2001.
❑ R.W. Sebesta: Concepts of Programming Languages. Addison-Wesley, 2006 (7th ed.).

Refactoring

da IEEE Software, Sep/Oct 2007, J.B.Rainsberger a pag. 27:

"You already need to refactor your system, but there's never a good time to start refactoring, so start now."

Avvocati

da Hernando De Soto - The Mistery of Capital. Why Capitalism Triumphs in the West and Fails Everywhere Else - Basic Books 2000, p. 199

"Using economic data from fifty-two countries from 1960 to 1980, Samar K. Datta and Jefferey B. Nugent have shown that for every percentage point increase in the number of lawyers in the labor force (from, say, 0.5 to 1.5 percent), economic growth is reduced by 4.76 to 3.68 percent - thus showing that economic growth is inversely related to the prudence of lawyers."

Due punti come separatore

Ancora Alessandro Manzoni citato nel libro di Gensini, questa volta da un testo del 1868, "Dell'unità della lingua e dei mezzi di diffonderla".

"Ci pare di dover distinguere i mezzi che sarebbe fattibile di mettere in pratica, anche senza attendere la formazione del nuovo vocabolario, da quegli altri che, di necessità, devono seguirne la pubblicazione.
I primi sarebbero: insegnanti di Toscana, nel maggior numero possibile, o anche educati in Toscana, da mandarsi nelle scuole primarie delle diverse province; esclusivamente toscani, ove ce ne sia, per le cattedre di lingua nelle scuole magistrali e normali:
Alcuni sussidi, sui fondi appositi iscritti per le scuole primarie nel bilancio del Ministero dell'istruzione pubblica, da assegnarsi a que' Comuni che si provvedessero di maestri nati od educati in Toscana:
Conferenze tra l'anno, od anche solo ne' mesi autunnali, nelle quali de' maestri e delle maestre di Toscana si rechino nelle varie province, per intrattenere i maestri e le maestre delle scuole primarie in letture di libri classici e di libri moderni (pezzi opportunamente scelti) notando gli arcaismi dei primi, e sostituendo le locuzioni dell'uso, avvertendo i provincialismi, i neologismi inutili de' secondi, colla stessa sostituzione:
Persone competenti, delegate nelle città capoluoghi dalla primaria magistratura, ed ufizialmente, che rivedano non solo qualunque iscrizione, avviso, od insegna devasi esporre in pubblico, ma anche le notizie che gli uffici regi o municipali forniscono ai giornalisti, per le loro cronache quotidiane:
Abbecedari, catechismi e primi libri di lettura nelle scuole, scritti o almeno riveduti da Toscani, sempre colla mira di cercare la diffusione della lingua viva:
Dare, come premio, a qualche allievo ed allieva delle scuole normali e magistrali, che ne abbiano fornito il corso con profitto e segni d'eminente capacità, il mezzo di passare un'annata scolastica in Firenze, per farci la pratica in una delle migliori scuole primarie:
Raccomandare ai membri de' corpi scientifici, quando la trattazione delle materie essenziali ne concedesse loro il tempo, di determinare fra loro le norme per una concorde e costante nomenclatura in que' rami scientifici che sono più accessibili al pubblico, come la storia naturale, la meccanica, la matallurgia, ecc.

I mezzi di diffusione poi, i quali dovrebbero seguire la pubblicazione del nuovo vocabolario sarebbero:
Provvedere che tutte le scuole governative, cos' dette secondarie, abbiano per ciascuna classe, degli esemplari del nuovo vocabolario, in quantità proporzionata al numero degli alunni:
Curare che del vocabolario si faccia anche un'edizione la più economica possibile, per renderne facile l'acquisto a ciascuno scolare:
Avere, per le scuole elementari ed anche per le scuole tecniche, de' piccoli vocabolari domestici d'arti e mestieri, compilati sul nuovo vocabolario della lingua, e alcuni, anche, figurati:
Dare in premio, nelle diverse scuole, insieme ad un'opera di bona letteratura, una copia del vocabolario, od anche, secondo la scuola, de' piccoli vocabolari che ne sono estratti:
Cercare che, anche in tutte le scuole femminili, i libri i più elementari sieno raccomandati o prescritti in modo che si diffonda sempre più, nelle città e nelle campagne, la cognizione della bona lingua viva, affinché si giunga così, a poco a poco, a renderla nota e familiare anche ai bambini."

Alessandro Manzoni e l'ingegno

"I doni dell'ingegno non si acquistano, come lo indica il nome stesso; ma tutto ciò che lo studio, che la diligenza possono dare, non istarebbe certamente per me ch'io non lo acquistassi."

è dalla seconda Introduzione (1823) a "Fermo e Lucia".

Riportato da Stefano Gensini, "Breve storia dell'educazione linguistica dall'Unità ad oggi", Carocci 2005. Tra l'altro, il libro tratta il difficile e tormentato processo che ha portato all'adozione generalizzata di una lingua italiana unitaria a partire dai dialetti. Molte affinità con il processo che stiamo vivendo in direzione di un'adozione generalizzata della lingua inglese.

Education: how to be top

Economist, October 20th 2007, p.74-75

"What works in education: the lessons according to McKinsey

There are big variations in educational standards between countries. These have been measured and re-measured by the OECD's Programme for International Student Assessment (PISA) which has established, first, that the best performing countries do much better than the worst and, second, that the same countries head such league tables again and again: Canada, Finland, Japan, Singapore, South Korea.
Those findings raise what ought to be a fruitful question: what do the successful lot have in common? Yet the answer to that has proved surprisingly elusive. Not more money. Singapore spends less per student than most. Nor more study time. Finnish students begin school later, and study fewer hours, than in other rich countries.
Now, an organisation from outside the teaching fold—McKinsey, a consultancy that advises companies and governments—has boldly gone where educationalists have mostly never gone: into policy recommendations based on the PISA findings. Schools, it says*, need to do three things: get the best teachers; get the best out of teachers; and step in when pupils start to lag behind. That may not sound exactly “first-of-its-kind” (which is how Andreas Schleicher, the OECD's head of education research, describes McKinsey's approach): schools surely do all this already? Actually, they don't. If these ideas were really taken seriously, they would change education radically.

Begin with hiring the best. There is no question that, as one South Korean official put it, “the quality of an education system cannot exceed the quality of its teachers.” Studies in Tennessee and Dallas have shown that, if you take pupils of average ability and give them to teachers deemed in the top fifth of the profession, they end up in the top 10% of student performers; if you give them to teachers from the bottom fifth, they end up at the bottom. The quality of teachers affects student performance more than anything else.

[...] Teaching the teachers
Having got good people, there is a temptation to shove them into classrooms and let them get on with it. For understandable reasons, teachers rarely get much training in their own classrooms (in contrast, doctors do a lot of training in hospital wards). But successful countries can still do much to overcome the difficulty.
Singapore provides teachers with 100 hours of training a year and appoints senior teachers to oversee professional development in each school. In Japan and Finland, groups of teachers visit each others' classrooms and plan lessons together. In Finland, they get an afternoon off a week for this. In Boston, which has one of America's most improved public-school systems, schedules are arranged so that those who teach the same subject have free classes together for common planning. This helps spread good ideas around. As one educator remarked, “when a brilliant American teacher retires, almost all of the lesson plans and practices that she has developed also retire. When a Japanese teacher retires, she leaves a legacy.”

[...] But there is a pattern in what countries do once pupils and schools start to fail. The top performers intervene early and often. Finland has more special-education teachers devoted to laggards than anyone else—as many as one teacher in seven in some schools. In any given year, a third of pupils get one-on-one remedial lessons. Singapore provides extra classes for the bottom 20% of students and teachers are expected to stay behind—often for hours—after school to help students.
None of this is rocket science. Yet it goes against some of the unspoken assumptions of education policy. Scratch a teacher or an administrator (or a parent), and you often hear that it is impossible to get the best teachers without paying big salaries; that teachers in, say, Singapore have high status because of Confucian values; or that Asian pupils are well behaved and attentive for cultural reasons. McKinsey's conclusions seem more optimistic: getting good teachers depends on how you select and train them; teaching can become a career choice for top graduates without paying a fortune; and that, with the right policies, schools and pupils are not doomed to lag behind.

Structured Procrastination

Grazie a Brian Marick, ho scoperto questa chicca:

Structured Procrastination, di John Perry

Tyler Cowen - How to work and play a little better

The Economist, September 8th 2007

Mr Cowen is a professor of economics at George Mason University in Fairfax, Virgina, and a co-owner of marginalrevolution.com, one of the best economics blogs on the internet.

“Discover Your Inner Economist” joins a recent school of books demystifying and popularising economics that began with Steven Landsburg's “Armchair Economist” in 1993, and conquered the bestseller lists in 2005 with “Freakonomics” by Steven Levitt and Stephen Dubner. It stands apart from its predecessors by making its revelations not so much about the way the world works as about the way we ourselves work (and play) and how we can take practical steps to do both better.

Tyler Cowen: Discover Your Inner Economist: Use Incentives to Fall in Love, Survive Your Next Meeting, and Motivate Your Dentist - Dutton 2007

Lustiger, cardinale cattolico, ed ebreo

From The Economist, Aug 16th 2007

Aaron Jean-Marie Lustiger, cardinale di Parigi, ebreo di origini polacche; sua madre morì ad Auschwitz.

AT THE funeral of Jean-Marie Lustiger, at Notre Dame de Paris on August 10th, his second cousin Jonas Moses-Lustiger read a psalm in Hebrew and placed on the coffin a jar of earth that had been gathered on the Mount of Olives. Then another cousin, Arno Lustiger, bent over the coffin to recite Kaddish. Only when those things were done was the body of Cardinal Lustiger carried inside the cathedral, where Catholic panoply took over.
There was no question of mixing the rites; the cardinal, said his staff, would not have liked that. Yet they were mixed in himself. He was a Jew by birth, instinct, emotion and devotion; he was a Catholic by conversion and conviction. He cracked Jewish jokes, and put on a suit and kippa to go to synagogue, although the evening would find him in his soutane again. For him, Christianity was simply the fruit of Judaism; his first religion came to completion in his second. Christ, in his eyes, was the Messiah of Israel, his cross worthy of a yellow star. And since the mission of Israel was “to bring light to the goyim”, preaching the gospel became his own mitzvah.

Every detail of his funeral, with its two rites, he carefully arranged himself. Then he wrote his epitaph:
I was born Jewish. I received the name of my paternal grandfather, Aaron. Having become Christian by faith and baptism, I have remained Jewish. As did the Apostles.

The Chimera of Software Quality

by Les Hatton, in IEEE Computer, August 2007.

"Nobody knows how to produce a fault-free program. Nobody even knows how to prove it even supposing one we were magically provided. I teach my students that in their whole careers, they are unlikely ever to produce a fault-free program and if they did, they would never know it, they could never prove it and they could not systematically repeat it. It provides a usefully humble starting point.

[...] I've analysed enough failed systems in my time to know that there are two classic symptoms of a system on its way to the fairies. First, no independent audit is allowed and second, talking heads tell you everything is fine when the ultimate users tell you the opposite.

[...] The Linux kernel is now arguably the most reliable complex software application
humanity race has yet produced, with a mean time between failures reported in tens and in some cases, hundreds of years. Poetically, the development environment of Linux, which leverages the contributions of thousands of Web volunteers who give their spare time for the public good, breaks just about every rule which software process experts hold dear."

Parnas on abstractions

Communications of the ACM, June 2007, p.7

"Use the Simplest Model, But Not Too Simple

Jeff Kramer's view, expressed in his article "Is Abstraction the Key to Computing?" (Apr. 2007), that abstraction is indeed a key concept in computing, especially in software design, is correct but far from new. It's a lesson I learned from the late E.W. Dijkstra 40 years ago and underlies every software development method proposed since then. Dijkstra said many useful things. Among them is the most useful definition of "abstraction" I know: "An abstraction is one thing that represents several real things equally well." This positive definition is more useful than the more typical ones Kramer quoted that emphasize the elimination of information. Dijkstra's clarifies what must remain.

Dijkstra's definition allows us to distinguish between an abstraction and a lie. When a model makes assumptions that are not true of a real object (such as infinite memory), these assumptions are often defended by saying "It is an abstraction." Using Dijkstra's definition, such models are not abstractions. Rather than represent several things equally well, they represent nothing at all. Because they embody unrealistic assumptions, one cannot trust the conclusions that might be drawn from them.

Models that are not abstractions in Dijkstra's sense may provide insight or understanding but can also mislead. Programs based on them may not work, and theories based on them may yield results not relevant in the real world.

Dijkstra's work showed that two distinct skills are related to abstractions:

• Being able to work with a given abstraction; and
• Being able to develop a useful abstraction.
  

Mathematics courses teach us how to work with abstractions but not usually how to develop appropriate ones. Many researchers I know can analyze formal models, deriving properties and proving theorems, but do not seem to notice (or care) when a model is based on an impractical design or makes assumptions that are not true in reality. Both skills are important, but teaching the second is much more difficult and is the essence of design.

Many computer science courses fail to teach students how to develop abstractions because they use models that are not abstractions but lies. Students must be taught the implications of an idea often attributed to Albert Einstein: "Everything should be as simple as possible but not simpler." Finding the simplest model that is not a lie is the key to better software design."

David Lorge Parnas
Limerick, Ireland

The Sarbanes-Oxley Act: implications for large-scale IT outsourcing

James A. Hall, Stephen L. Liedtka, "The Sarbanes-Oxley Act: implications for large-scale IT outsourcing", Comm ACM 03-2007

"Until they are certain that outsourcing IT management is the best possible option, firms would do well to maintain and invest in their own in-house IT assets.
[...]

Two sections of SOX are especially important to corporate IT departments:
Section 404. Called “Management Assessment of Internal Controls,” it mandates that corporate CEOs implement internal controls over their financial reporting systems, physically test these controls, and certify in writing that they function correctly. As a practical matter, the vast majority of controls are embedded in computer technologies that involve virtually
all of an organization’s financial transaction processing systems; and
Section 302. Called “Corporate Responsibility for Incident Reports,” it requires senior financial executives to disclose deficiencies in internal controls and fraud (whether material or not). Also, public accounting firms must attest in their audit opinions to the adequacy
and function of their client firms’ internal controls. Prior to SOX, auditing standards required
auditors only to be “familiar” with internal controls.
[...]

While large-scale IT outsourcing may appear to be a way to address the costs of SOX compliance, outsourcing contracts can actually increase the likelihood that a firm will fail to
comply with both the detail and the spirit of SOX.
Specifically, large-scale IT outsourcing increases the risk that top management and boards of directors will be unable to fulfill their oversight duties; that firms will employ ineffective internal controls over financial statements; that financial reports will be inaccurate
and/or misleading; and that firms will fail to protect shareholder wealth.
[...]

Finally, we note that an outsourcing client’s competitive success depends on the vendor’s ability to perform. Electronic Data Systems Corp. (EDS) has demonstrated the potential for vendor failures to have drastic, perhaps unforeseeable, financial repercussions.
EDS has struggled due to a variety of factors, including its own financial reporting failures and the bankruptcies of two of its largest customers—WorldCom and US Airways. In order to cut costs, EDS terminated 7,000 employees, which affected its ability to serve its clients. Following an 11-year low in share prices in 2002, EDS stockholders filed a class-action
lawsuit against the company. Vendors experiencing such serious financial and legal problems clearly threaten the viability of their strategic partners, as well as their ability to maintain internal controls and completely and accurately present financial information."

The effects of online advertising

Scott McCoy, Andrea Everard, Peter Polak, Dennis F. Galletta: The effects of online advertising, Comm ACM 03-2007

"Our findings suggest that advertisements do have significant effects on retention of the site. Also, advertising content that is non-congruent with the site’s content seems to lead to greater effort in reconciling the differing content, and ultimately greater memory of both the Web site and the advertisement. Intrusiveness is also important for both Web site designers and advertisers. Pop-ups and pop-unders seem to be more intrusive than in-line ads, implying
that users should not be interrupted from their online tasks to close the extraneous windows.
[...]

Designers should realize the magnitude of ill effects caused by advertising.
Although some of the differences were not large in magnitude, reducing the likelihood of a person’s return by 11% might be a cost that is too great for a site host to bear. Discovering that pop-up and in-line ads differ greatly in measures of intrusiveness, a host might play it safe and make use of in-line ads. As theory and practice begin to converge in this area, perhaps
what has been described so often as a wild new frontier might finally take a few steps toward being tamed."

Theoretical Reflections on Agile Development Methodologies

Sridhar Nerur e VenuGopal Balijepally, "Theoretical Reflections on Agile Development Methodologies", Comm ACM 03-2007 . Con una lista di riferimenti eccellente.

"The progression of thought in software development parallels the maturation of design ideas in architecture and strategic management. The traditional mechanistic worldview is today being challenged by a newer agile perspective that accords primacy to uniqueness, ambiguity,
complexity, and change, as opposed to prediction, verifiability, and control. The goal of optimization is being replaced by flexibility and responsiveness.
[...]

The tenets of agile methods depart from the traditional orthodoxy of software development. This shift in philosophy is not unusual, as similar patterns of intellectual evolution have emerged in other disciplines. A look at architecture and strategic management reveals that
the progression of ideas in them is remarkably similar to conceptual pattern shifts in software design."

Management Theory - Rhythm and blues

Economist, March 31st 2007

"Employees may be reluctant to admit this, but managers should take heed: teams that like each other also seem to work better together".

(a partire da una riflessione sulla composizione dei ggruppi di voga nelle regate annuali che contrappongono Oxford a Cambridge).

Web Services

José Luiz Fiadeiro – Designing for Software’s Social Complexity – IEEE Computer January 2007

Gerarchie, reti, decisioni

Peter Denning e Rick Hayes-Roth - Decision Making in very Large Networks - Comm ACM November 2006.

La creazione di reti operative in situazioni di crisi (es. tsunami in est asiatico, uragano Katrina a New Orleans) richiede un coordinamento decisionale rapido ed efficiente. Questa esigenza si scontra con il fatto che i partecipanti appartengono ad organizzazioni gerarchiche

Articoli su outsourcing

Hazel Taylor – Critical Risks in Outsourced IT Projects: the Intractable and the Unforeseen – Comm ACM November 2006

Phillip G. Armour – Agile... and Offshore - Comm ACM January 2007

Innovazione ICT in Italia

Da Computerworld Online, 19-02-2007:

"Sono stati annunciati i 20 finalisti (sui 70 nominati da 450 candidati) dello European Information and Communications Technology Prize 2007, il cui montepremi, di 700.000 euro, verrà condiviso da imprese realizzatrici di servizi e prodotti innoivativi in ambito ICT e delle tecnologie digitali. Si parla quindi di settori convergenti quali computer, media e comunicazione. I vincitori saranno ammunciato in occasione del CeBIT di Hannover il 16 marzo. I Paesi rappresentati sono Germania (con 7 finalisti), Francia(4), Austria (3), Svezia (2) e Finlandia, Israele, Norvegia e Rgno Unito (1 ciascuno).
I finalisti sono stati scelti in base al potenziale tecnologico e industriale. Organizzato da Euro CASE e supportato dalla Commissione Europea. Nel gruppo dei primi 70 c'era anche la milanese Gempliss."

Emilio C. Porcelli

Pochi giorni fa, il 15 febbraio 2007, è morto Emilio C. Porcelli, un amico.

La sua intelligenza, la sua curiosità intellettuale, la sua attenzione nei confronti degli altri mi mancheranno, e mancheranno a tutti quelli che hanno avuto modo di conoscerlo.

Emozioni base e non

The Economist, December 23rd 2006, "Captain Kirk's Revenge"

Most neuroscientists now recognise six basic emotions: anger, disgust, fear, joy, sadness and surprise. [...] From the 70s onwards, Dr Paul Ekman, a psychologist at the University of California, San Francisco, was responsible for the general agreement on the six basic emotions. He showed that the facial expressions associated with these emotions are universal, and therefore almost certainly plumbed in genetically. [...]

The list of higher emotions is not as well defined as that of the baser ones, but they include things such as guilt, embarrassment, shame and sympathy. What they have in common is that they depend not merely on what the person feeling them thinks about others, but on what the person feeling them thinks other are thinking about them. It is not the guilt or shame of the act itself, but the risk of being found out that provokes the emotion.

Project Management - Ivo Andric

Da "Il ponte sulla Drina" di Ivo Andric, Meridiani Mondadori 2001, pag. 592:

La primavera dell'anno in cui il visir prese la decisione di costruire il ponte, arrivarono a Visegrad i suoi uomini con il seguito per i preparativi necessari. Erano in molti, con cavalli, carri, macchinari di tutti i generi e tende. [...].
Il loro capo era Abid-aga, uomo di fiducia del visir e responsabile della costruzione del ponte insieme a Tosun-efendija, l'architetto. (Di Abid-aga già prima del suo arrivo si diceva che fosse un uomo crudele, senza scrupoli.) Non appena si furono sistemati nelle tende sotto Mejdan, Abid-aga convocò le autorità locali e i notabili musulmani per discutere con loro sul da farsi. In realtà non vi fu discussione, perché parlò uno solo, Abid-aga.

'Sono certo che prima del mio arrivo vi sono giunte voci sul mio conto, e so che non sono belle né piacevoli. Vi avranno sicuramente detto che esigo lavoro e obbedienza assoluta e sono pronto a frustare o a uccidere chiunque non lavori come si deve e non obbedisca senza sollevare obiezioni, che non conosco il significato di frasi come "non è possibile" e "non c'è", che con me una testa può cadere anche per una parola insignificante, insomma che sono un uomo sanguinario e malvagio.
Voglio confermarvi che queste voci non sono né inventate né esagerate. E' vero che sotto il mio tiglio non si trova ombra. Mi sono conquistato questa reputazione nel corso di lunghi anni di servizio, eseguendo fedelmente gli ordini del gran visir. A Dio piacendo eseguirò altrettanto bene il lavoro per cui sono stato inviato qui e spero che, quando avrò portato a termine la mia missione e sarò ripartito, le voci che mi seguiranno saranno anche peggiori e più terribili di quelle che sono giunte alle vostre orecchie.'

cosa trasmettere ai figli

Michel Houellebecq – Le particelle elementari (Bompiani, 1998) p. 170

"[per i maschi] i figli erano la trasmissione di uno stato, di regole e di un patrimonio. E questo principalmente nell'ambito dell'aristocrazia, ma non solo: anche tra i commercianti, i contadini, gli artigiani, in pratica in tutte le classi sociali. Oggi tutto ciò non esiste più: io sono un impiegato, cosa dovrei trasmettere a mio figlio? Non ho nessun mestiere da insegnargli, neppure so cosa potrà fare da grande; e comunque, per lui le regole che ho conosciuto io non saranno più valide, vivrà in un altro universo. Accettare l'ideologia del cambiamento continuo significa accettare che la vita di un uomo sia strettamente ridotta alla sua esistenza individuale, e che le generazioni passate e future non abbiano più alcuna importanza ai suoi occhi. E' così che viviamo; e oggi per un uomo avere un figlio non ha più alcun senso. La situazione delle donne è diversa, giacché non hanno mai smesso di provare il bisogno di avere un essere da amare – il che non è, né è mai stato, il caso degli uomini.”

Economist - But did they buy their own furniture?

The Economist, Aug 10th 2006 But did they buy their own furniture?

As a new YouGov poll for The Economist shows, Britons are surprisingly alert to class—both their own and that of others. And they still think class is sticky. According to the poll, 48% of people aged 30 or over say they expect to end up better off than their parents. But only 28% expect to end up in a different class. More than two-thirds think neither they nor their children will leave the class they were born into.

What does this thing that people cannot escape consist of these days? And what do people look at when decoding which class someone belongs to? The most useful identifying markers, according to the poll, are occupation, address, accent and income, in that order. The fact that income comes fourth is revealing: though some of the habits and attitudes that class used to define are more widely spread than they were, class still indicates something less blunt than mere wealth. Being the sort of person who “buys his own furniture”, a remark that Alan Clark, a former minister and diarist once reported as directed at Michael Heseltine, a self-made Tory colleague, is still worthy of note in circles where most inherit it.

[...]
A survey conducted earlier this year by Experian for Liverpool Victoria, a financial-services firm, shows how this convergence on similar types of work has blurred class boundaries. Experian asked people in a number of different jobs to place themselves in the working class or the middle class. Secretaries, waiters and journalists were significantly more likely to think themselves middle-class than accountants, computer programmers or civil servants. Many new white-collar jobs—in vast call centres, for example—offer no more autonomy or better prospects than old blue-collar ones.

CIO Magazine - Postmodern Manifesto

CIO magazine 1 may 2006

The Postmodern Manifesto, by Christopher Koch http://www.cio.com/archive/050106/pomo.html

In a 2005 SIM survey of skills that CIOs expect to most value in their IT staffs over the next three years, project management led the list, followed closely by company, functional and industry knowledge. Other skills in demand included business process reengineering, user relations management, negotiation, change management, communication and managing expectations. Only two technical skills (systems analysis and systems design) made the top 15—and both of those skills focus more on architecture and process than on hard-core programming.

[...]
To some extent, the deconstruction of IT has already occurred, especially in big companies where the large scale of IT and the separation of IT functions such as help desk, application maintenance and some programming have made them candidates for outsourcing. More and more jobs in IT will become components in a distributed services supply chain modeled on today's distributed manufacturing supply chains.

IT departments already have undergone a structural shift. The number of programmers employed in the United States has dropped by 25 percent since its peak in 2000, even though the total number of IT workers has increased slightly since then, according to the Bureau of Labor Statistics. In our "State of the CIO 2006" survey, 76 percent of respondents said they outsource application development, maintenance or support—more than double the next highest category.

In one respect, the distributed services supply chain model is actually creating more work. As pieces of the IT supply chain break off and become more specialized, the need for coordination of the pieces increases. That means the number of internal jobs dependent upon external people is increasing. This shift is reflected by the new emphasis in IT departments on relationship management and project management.
Economists call these kinds of skills tacit work, which requires the ability to analyze information, grapple with ambiguity and solve problems, often based on experience. Tacit interactions are complex and require interaction (such as managing a software development project) rather than being simple and solitary (fielding help desk calls with a script, for instance).

Tacit jobs have been growing three times faster than employment in the entire national economy, according to consultancy McKinsey, and they make up 70 percent of all U.S. jobs created since 1998 and 41 percent of the total labor market in the United States. These roles track pretty closely with the categories where the Department of Labor says IT employment has made the biggest gains since 2000: application engineers, systems engineers and network analysts.

Glass - Standish Chaos Report

Communications of the ACM, October 2006

Robert L. Glass The Standish Report: Does It Really Describe a Software Crisis?

Most academic papers and guru reports cite the same source for their crisis concern—a study published by the Standish Group more than a decade ago, a study that reported huge failure rates, 70% or more, and minuscule success rates, a study that condemned software practice by the title they employed for the published version of their study, The Chaos Report.
So the Standish Chaos Report could be considered fundamental to most claims of crisis.

[...]
Several researchers, interested in pursuing the origins of this key data, have contacted Standish and asked for a description of their research process, a summary of their latest findings, and in general a scholarly discussion of the validity of the findings. They raise those issues because most research studies conducted by academic and industry researchers arrive at data largely inconsistent with the Standish findings.

Let me say that again. Objective research study findings do not, in general, support those
Standish conclusions.

[...]
Standish, please tell us whether the data we have all been quoting for more than a decade really means what some have been saying it means. It is too important a topic to have such a high degree of uncertainty associated with it.

Boehm - Requirements Volatility

Communications of the ACM, October 2006

Barry Boehm One-size-fits-all Methods: the Wrong Solution to new Problems

Requirements Volatility ratings for stable embedded devices are still in the 0.1% to 0.3% per-month range, but the counterpart ratings for rapidly changing competition-driven applications are often in the 10% to 30% per-month range.

Level 5 CMM - India

Communications of the ACM, October 2006

Michael Cusumano, Envisioning the Future of India’s Software Services Business:

In terms of process maturity, the Indian companies are difficult to beat as well: It is well known that, as of last year’s count, 80 of the World’s 117 SEI CMM Level-5 companies are based in India.

David Grossman

8/11/2006
David Grossman, ospite nella trasmissione di La7 L'Infedele, condotta da Gad Lerner.

Parlano di Bruno Schulz, considerato affine a Kafks, un genio, ucciso per scherzo dalle SS nel 1942 e autore di un libro pubblicato da Einaudi, Le botteghe color cannella.
Probabile che Schulz sia citato nel libro di Grossman Vedi alla voce amore.

Sembrano interessanti, di Grossman, anche i libri per bambini e per adolescenti.

Dilbert - project management

Dilbert su PMI Journal (3-11-06 Scott Adams.)

Boss: Yesterday I had a great meeting about project Wombat.
Dilbert: What?! I've been managing that project for six months! How can you have a meeting without inviting me? !!
Greta: Have you noticed that meetings go smoother without any knowledge or expertise?
Boss (very small font): Kinda.

Culture

Khaled Fouam Allam: Solitudine dell'Occidente. Rizzoli 2006

Rafik Schami (siriano, cristiano): saga Il lato oscuro dell'amore (Garzanti)

Ivo Andric: Il ponte sulla Drina

Predrag Matvejevic: Mediterraneo

Agile and Toyota - Alistair Cockburn

due post il 31-12-2006 e 1-1-2007

Re: [APM] Management lineage of software processes

Interestingly, the Toyota Production System (TPS) was already doing most of what we now call agile, already back in the 1970s.

The west didn't notice what they were doing and misinterpreted it. (most of) Those of us who wrote the agile manifesto in 2001 were not aware of TPS, and simply wrote what was on our minds. Since then, many of us have looked at TPS --- and I for one, can't see that we've added very much to what was already in TPS (test-first comes to mind as an exception).

Alistair

Re: [APM] Management lineage of software processes

Thanks, Boris. Well, I have three times visited a place in SLC(O.C.Tanner) where they are implementing TPS pretty strictly in their awards production, and I am unable to to suggest anything that they haven't already been doing for over a year. I.e., TPS already leads them to everything I know.

Personally, I think it's pretty nifty that we in software managed to reinvent our own localization of the ideas of TPS without knowing first about TPS. It doesn't bother me if Toyota got there first (over a 60-year period). I think the ideas are there to be found by multiple groups of people ... the math adds up, reflection and inspection lead there.

But the only reason I brought this all up was that someone asked about the sequencing of ideas and influences. AFAIK, we software people were not particularly influenced by Deming or TPS in coming up with the agile manifesto (I can speak for myself --- my information came strictly from staring at my interview results and management attempts in the early/mid 1990s ... I suspect the same was true for at least most of the people at the Snowbird meeting). And still, looking at time sequencing, it is clear that lean manufacturing got there first. I still don't know about Deming'sstuff.

Lean and contracting situations - Mary Poppendieck

post il 3-1-2007 RE: [leandevelopment] Budgeting a Lean Project

Tal,

It seems that you are in a contracting situation, as opposed to developing software for use within your own organization. If I can make that assumption, then I would suggest that lean principles are not particularly viable unless lean contracting is also part of the equation. When you reach organizational barriers and lean organizations run up against non-lean organizations, it is often impossible for the supplier to act in a lean manner.

As an example, many automotive suppliers have adopted lean practices in order to supply Toyota. The lean areas of their plants are much more efficient and cost-effective, but they are usually not able to supply other automobile companies with the lean area of the plant – they have to maintain a non-lean (and less efficient) area of the plant to serve those other customers. Why? Because the Detroit automotive companies still want parts delivered in large batches – they thin the economies of scale are the dominating factor in their business, despite decades of evidence to the contrary.

Similarly, if you have customers that believe that accumulating huge batches of detailed requirements is the most efficient way to contract with suppliers, then you may have to operate in a non-lean way with those customers. When you find customers that want a lean supplier, you can partner with them in a lean way, and as the automotive suppliers found out, deliver better, more cost effective software. However, in general, the choice lies with the customer, not the supplier.

Mary Poppendieck