UML, Everywhere

In un articolo pubblicato su IEEE Software, September/October 2010, ma accessibile dal suo blog, Diomidis Spinellis elenca le ragioni per cui UML, al di là della sua imperfezione, va usato da tutti coloro che documentano sistemi software.

Value delivery

Fornire valore agli stakeholder (le parti interessate al rilascio di un prodotto) è ciò che si chiede allo sviluppo software.
Ma le specifiche dei requisiti spesso dettagliano solo i dettagli sulle funzionalità, anziché affrontare in modo diretto gli interessi degli stakeholder e chiarire ciò che per gli stakeholder è davvero importante.

"What's Fundamentally Wrong? Improving our Approach Towards Capturing Value in Requirements Specification", un articolo di Tom Gilb con Lindsey Brodie, su Requirements Network (per leggerlo, serve una registrazione gratuita).

Due tipi di progetto software

Due tipi di progetto software: quelli di base, a cui si chiede semplicemente di tirare fuori un prodotto che funzioni bene, e quelli strategici, che danno un vantaggio competitivo in termini di business.

Tra i due tipi di progetto sono diversi i rischi, le competenze necessarie, il modo di procedere.

Martin Fowler: Utility Vs Strategic Dichotomy.