analisi-disegno.com
Identificare gli stakeholder è una condizione essenziale per il successo di un progetto software. Ma, una volta identificati, come possiamo coinvolgerli e cosa possiamo aspettarci da loro?
Possono innanzitutto esprimere i propri requisiti. Naturalmente nessuno stakeholder ha già pronta una lista di requisiti completa, è invece compito dell'analista aiutarlo a fornire il proprio contributo al progetto, scoprendo quali sono i fattori critici di successo rilevanti dal suo punto di vista, e quali sono i rischi che possono avere un impatto negativo sui suoi interessi.
L'approccio dell'analista deve essere maieutico, come quello del filosofo greco Socrate che aiutava i propri interlocutori a chiarirsi le idee attraverso una serie di stimoli e di domande, e paragonava se stesso ad un'ostetrica che aiuta le donne a partorire. In altri termini, i requisiti non arrivano all'analista già belli pronti, ma vanno tirati fuori con strumenti adeguati.
L'analista, grazie alla propria esperienza, può sottoporre agli stakeholder gli stimoli necessari per chiarirsi le idee ed esprimere i propri requisiti. I mezzi principali sono due: fare domande (per farle in modo efficace è utile la conoscenza di tecniche di analisi) e proporre soluzioni, ad esempio prototipi o semilavorati.
Dato che ogni stakeholder è un soggetto interessato al prodotto da sviluppare, è possibile che il chiarimento dei requisiti dal suo punto di vista faccia emergere aspetti che sono in conflitto con i requisiti di altri stakeholder. Ad esempio, nello sviluppo di prodotti per il mercato, è possibile che la volontà di fornire un numero elevato di funzioni entri in contrasto con l'esigenza di contenere il prezzo che i futuri acquirenti dovrebbero pagare per il prodotto. O che determinate iniziative commerciali siano rischiose sotto il profilo legale, o per la sicurezza.
Il conflitto tra requisiti espressi dagli stakeholder è una caratteristica normale nei progetti che comportano innovazione. È però importante che il conflitto, quando c'è, venga portato alla luce il più velocemente possibile, in modo che gli stessi stakeholder possano, in collaborazione con il committente, affrontarlo e risolverlo per tempo. Più tardi il conflitto emerge, maggiori sono i rischi e i costi per il progetto.
Il secondo determinante contributo che gli stakeholder possono fornire in un progetto software consiste nel controllare, per il proprio ambito di competenza, i prodotti / servizi che costituiscono il risultato dei lavori progettuali. Le verifiche effettuate in corso d'opera dagli stakeholder sono utili per evidenziare con il massimo anticipo, durante l'intero progetto, i rischi che possono comprometterne l'esito positivo.
*** Fasi dell'approccio agile ***
Jim Highsmith è uno tra i più maturi proponenti dell'approccio agile, essendosi occupato di software engineering dai tempi dell'approccio strutturato ed essendo tra i firmatari del Manifesto agile del 2001.
Highsmith ha pubblicato su Software Development Times un articolo breve ma utile in cui ripercorre le fasi di diffusione degli approcci agili: una fase di sperimentazione iniziale in cui in molti casi ci si focalizzava essenzialmente sulle pratiche di gestione iterativa dei progetti, senza curare in modo adeguato le pratiche tecniche (automazione dei test, integrazione, test driven development); una seconda fase più matura, in cui ci troviamo ancora, in cui le pratiche manageriali e tecniche si integrano; una terza fase, agli inizi, in cui il tema principale diventa come sfruttare la maggiore flessibilità e produttività dello sviluppo software a vantaggio delle finalità di business delle imprese - l'enterprise agility.
*** Saturn 2011 ***
Saturn (SEI Architecture Technology User Network) è una conferenza annuale sulle architetture software organizzata dal Software Engineering Institute.
Saturn 2011 si è tenuta a Burlingame (California) dal 17 al 21 maggio. Sul sito della conferenza sono disponibili gli abstract e le slide di diverse presentazioni.
*** Insegnamento basato sulla pratica ***
Insegnare tramite la pratica, usando la teoria come supporto e non come unico punto di partenza, dà risultati più efficaci. Decisamente più efficaci.
Un articolo di Science il 13 maggio 2011 cita i risultati di uno studio relativo all'insegnamento di fisica all'University of British Columbia. Risultati che corrispondono alla mia esperienza didattica.
L'articolo di Science è a pagamento, ma una sintesi dei risultati è stata pubblicata su The Economist.
*** Italia digitale 2011 ***
Pubblicati i dati della commissione europea sulla società dell'informazione: Digital Agenda Scoreboard 2011
Particolarmente interessanti gli indicatori sull'evoluzione negli ultimi anni raffrontata agli altri paesi europei.
*** Manifesto for Software Craftsmanship ***
"Manifesto for Software Craftsmanship. Raising the bar.
As aspiring Software Craftsmen, we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work, we have come to value:
That is, in pursuit of the items on the left, we have found the items on the right to be indispensable."
"Craftsmanship" si può tradurre con arte, maestria, perizia tecnica. Il manifesto, pubblicato nel 2009, si fonda sul manifesto agile del 2001, e lo reinterpreta spingendo sul fronte della qualità dei prodotti software e del processo di sviluppo.
"Raising the bar", cioè alzando il tiro: non si tratta solo di sviluppare in modo più efficiente e flessibile, ma soprattutto di elevare la qualità di ciò che si fa e di come lo si fa.
*** Liste di strumenti UML ***
Continua a crescere il numero di strumenti UML disponibili, sia a pagamento che gratuiti. Anche per smartphone. Un punto di partenza abbastanza aggiornato è il sito Modeling Languages.
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita e regolare.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.