Pagine

sabato 29 novembre 2008

Usabilità, requisiti e progetti agili

Jakob Nielsen è un esperto di usabilità. Nella sua newsletter Alertbox parla del rapporto tra usabilità e approcci agili. L'argomentazione di Nielsen prende l'avvio dai requisiti:

"Requirement specifications are always wrong.

At best — when derived with care — the requirements might reflect what
users want. More commonly, however, they reflect the desires of user
'representatives' who are too far removed from the coalface to know the
details of the real work. In any case, what users want and what users need
are two different things, which is why it's long been a primary usability
guideline to watch what users do, rather than listen to what they say".

CMMI e Agile

Il Software Engineering Institute (SEI) è un'istituzione finanziata dal governo e da grandi aziende USA. Nei corsi che tengo sono solito raccomandare il sito del SEI come una delle fonti più autorevoli di documentazione sulle tematiche dello sviluppo software. Documenti di alta qualità, e gratuiti.

Tra le altre cose, il SEI è noto per aver creato il CMMI-SW (Capability Maturity Model Integration), un modello per la valutazione del grado di maturità delle organizzazioni che sviluppano software. Modello applicato dal governo americano e da molte organizzazioni internazionali per selezionare i propri fornitori nello sviluppo software.

Il CMMI-SW è spesso ritenuto, a torto, come un modello che porta a burocratizzare lo sviluppo, pesante e con effetti negativi sulla produttività e sulla flessibilità. Può essere applicato così, è vero. Ma pesantezza e burocrazia non sono affatto insite nel modello, bensì sono causate da chi lo interpreta in modo superficiale.

Una recente pubblicazione del SEI, "CMMI or Agile: Why Not Embrace Both!" evidenzia la compatibilità del CMMI con gli approcci agili.

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

lunedì 10 novembre 2008

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.

martedì 21 ottobre 2008

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.

martedì 14 ottobre 2008

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.

giovedì 9 ottobre 2008

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.

giovedì 2 ottobre 2008

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

martedì 16 settembre 2008

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

domenica 13 luglio 2008

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.

venerdì 4 luglio 2008

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.

mercoledì 18 giugno 2008

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.


mercoledì 21 maggio 2008

Cosa leggere - Grandi libri

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

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

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

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

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

Letteratura divertente

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

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

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

venerdì 16 maggio 2008

Lo saprò quando lo vedrò

Barry Boehm - Making a Difference in the Software Century

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


Riporto un paio di passi.

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

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


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

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

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

mercoledì 7 maggio 2008

About us

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

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

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

lunedì 28 aprile 2008

Being Your Own Boss

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

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

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

Legge di Conway

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

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

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

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

Patterns of Agile Adoption

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

Cohn descrive tre coppie di alternative:

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

Per ognuna delle alternative, vengono elencati vantaggi e svantaggi.

giovedì 10 aprile 2008

Usabilità ed esperienza utente

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

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

Scrum e pattern organizzativi

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

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

Scrum scalabile

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

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

Modernizzazione del software

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

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

mercoledì 2 aprile 2008

Il mercato dei Database relazionali

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

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

lunedì 31 marzo 2008

CMMI + altri metodi e standard

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

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

L'analista (definizione di Karl Wiegers)

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

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

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

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

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

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

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

UML - Apogeo 2007 (recensione)

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

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

UML pratico - Paravia 2007 (recensione)

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

Punti di forza:

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

Punti di debolezza:

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

Elenco strumenti gestione requisiti

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

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

Le iniziative metriche durano poco

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

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

Previsioni a partire dai function point

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

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

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

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

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

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.

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

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

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.

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.

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.

lunedì 7 gennaio 2008

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