Unificazione blog

Ultimo post su questo blog. I post precedenti sono stati spostati su http://acomai.blogspot.com/ , su cui verranno pubblicati i nuovi messaggi.

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.

Richieste di offerta, contratti, requisiti

Alistair Cockburn prevede che nei prossimi 10 anni cambierà parecchio il modo di definire le richieste di offerta ed i contratti, per tenere conto del fatto che il cambiamento dei requisiti in corso d'opera è inevitabile.

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