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.