High Quality
Open the downloaded document, and select print from the file menu (PDF reader required).
Usabilità e ripetibilità dei processi produttivi software
ing. R.Turco
Introduzione
Uno dei problemi fondamentali dei processi produttivi software è quello di renderlieffettivamente dei processi ingegneristici e non artigianali.Negli anni sono stati fatti notevoli progressi. Sono stati, difatti, introdotti modelli di processo e
metodologie di notevole interesse: i processi iterativi e quelli di prototyping, l’Object Orientede l’UML, il Rational Unified Process o l’Extreme Programming o l’Agile, l’I
SO 9000 (Plan, Do,Check, Act). Per i conteggi e le stime di quanto produrre sono stati introdotti i Function Point(IFPUG) e gli Early Function Point.Infine, negli anni, sono stati introdotti anche strumenti e suite adeguate a supportare talimodelli, metodologie e processi.Tutto questo, oggi, permette ad un responsabile di progetto di scegliere le giuste metodologiee gli strumenti necessari alle proprie esigenze di processo produttivo.Tuttavia occorre ancora prestare una forte attenzione a tutte le scelte che si fanno: è ancoranecessaria una componente di competenza trasversale e di visione generale del settore perassortire il tutto in modo adeguato e ottenere qualcosa di efficiente ed efficace per il proprioprocesso produttivo; ma soprattutto per ridurne i rischi (Vedi articolo Extreme Programming).
Uno dei quesiti che è fonte di ricerca, tra molte persone del settore, è il seguente: “Perché pur
partendo da una stessa metodologia UML, stessi requisiti, etc si ottengono alla fine risultatidiversi per la descrizione dei requisiti (Use Case), per i Funtion Point o Early Function Point,
per la modellazione del dominio, e anche per l’implementazione?”.Poiché ciò è vero e condiziona in modo significativo la pianificazione e lo “staffing progettuale”,
questo significa che se non si prendono opportuni accorgimenti di processo produttivoaumentiamo i rischidel progetto in maniera non lineare.Significa, inoltre, che esiste ancora una forte componente di artigianalità nel nostro processoproduttivo
; difatti in questo caso sia la qualità, sia l’esito del progetto dipenderanno dalla
bravura e dallo skill delle risorse umane coinvolte ed i costi del progetto necessariamentesaranno superiori al necessario.
Process Usability
L’usabilità è un’
astrazione,
nata inizialmente con le GUI (Jacob Nelsen), trasportata poi versoil Web (Web usability), ma che è
estensibile
anche ai processi produttivi software.
L’usabilità di un processo produttivo software è legata a due concetti:
o
Il grado di complessità dei vari task del processo;
o
Il grado di abilità delle persone in gioco (lo skill).
La “
Process Usability
” ha come obiettivo di rendere basso il grado di complessità del processo
produttivo (M
ODELLO DEL PROCESSO E
M
ETODOLOGIA
),
in modo che occorra un grado di abilità, daparte delle risorse umane, non elevato.Ma questo da solo non basta per trovarsi dinanzi ad un processo produttivo ingegneristico esistematico; occorre aggiungere, infatti, il sale giusto, un altro attributo: il processo deveessere
ripetibile,
da chiunque.Laripetibilità di un processo
è legata solo all’esistenza degli strumenti che supportano ilprocesso? Ad esempio per l’Object Oriented esistono valide suite come Rational Rose, oppure
Together ed altri IDE come Jbuilder, NetBeans, Sun One Community Editino, etc.Ma questo basta? Il nostro processo produttivo è in grado di dare lo stesso risultato chiunque
utilizzi tali strumenti? La risposta è NO. Questo vuol dire che la ripetibilità dell’analisi, dellaprogettazione e dell’implementazi
one NON è sistematica.
La ripetibilità, difatti, non dipende solo dall’esistenza degli strumenti, ma da quanto questi
strumenti siano in grado di supportare, in modo vincolante, una metodologia, con template,suggerimenti, help e mentoring; permettendo così diversi vantaggi:
o
Una modalità progettuale unica indipendentemente dalle persone coinvolte;
o
Un facile ingresso nel team di persone nuove;
o
Una modalità progettuale che aiuta gli skill più bassi a fornire un risultato di valoremaggiore;
o
Una produzione di un output progettuale che favorisce buone relazioni con un fornitore;
o
Una riduzione dei rischi progettuali e, per conseguenza dei costi, per tutti gliStackholder in gioco nel processo produttivo;I rischi maggiori di un processo produttivo sono, difatti, concentrati in almeno due punti:
o
I requisiti utente con gli use case;
o
La progettazione del modello.Sbagliare qualcosa o omettere qualche dettaglio importante in questi due punti significa che cicosterà molto rimettere a posto le cose e riciclare più volte.
Use Case e template
In UML i requisiti utente vengono espressi attraverso gli USE CASE.
E’ noto che gli Use Case rispondono solo alle domande: Chi fa? (Gli attori), Che cosa? (Le
funzionalità).Per questo, non bastando da soli, spesso occorre affiancarli, a seconda delle necessità, aDiagrammi di sequenza (che danno un senso temporale delle azioni tra gli oggetti), Diagrammidelle attività (che danno un aspetto di parallelismo del flusso delle azioni), Diagrammi di stato(che danno un senso di stato degli oggetti).
I requisiti sono, tuttavia, il punto di partenza (la “Pole position” progettuale) e sono
estremamente critici. A maggior ragione diventano maggiormente critici quando i requisitisotto forma di use case vengono dati in input ad un fornitore.
Ci si domanda perché con Rational Rose o altro strumento due persone partendo diùa unostesso insieme di requisiti (Storie), e a parità di livello di dettaglio fornito, ottengono Use casediversi?La risposta è che la parte testuale degli Use case di Rational Rose è lasciata alle capacità e algiudizio di chi usa lo strumento.
Se, invece, s’introduce un semplice template con dei campi da riempire si ottiene il seguente
effetto:
o
Nessun utilizzatore rischia di dimenticare le parti strettamente necessarie da dichiarare
nell’use case;
o
Due persone di skill diverso riescono a fornire le stesse indicazioni.Per gli Use Case è proponibile difatti un template come quello della tabella successiva.Il template, per la verità, può essere introdotto sotto Rational Rose come un add-in chepermette di riproporre nella parte testuale degli use case ogni volta il template.Nome requisito (Use case)DescrizioneInputPre-condizioneElaborazioneOutputPost-condizioneNote
Template proposto
Anche se gli use case fanno riferimento a requisiti funzionali è il caso di indicare anche irequisiti non funzionali importanti,
sia come template o come altro diagramma utile
:
o
Parallelismo;
o
Timeout web;
o
Etc.Attenzione: il parallelismo non è un aspetto concettuale legato alla tecnologia, ma allamodalità di esecuzione di un task e, quindi, un requisito non funzionale.
Ad esempio per poter superare il timeout di Apache che potrebbe nascere per un’attesa
superiore al default (300 secondi) su un database, si deve pensare ad una soluzioneapplicativa.Per cui occorrerà affiancare agli use case un diagramma delle attività dove ci saranno inparallelo due attività: una che è quella che permette di riciclare su una pagina web di attesa(chiusura della Request http con una Response che fornisce una pagina html chiudendo la
connessione ed evitando il timeout) e l’altra che prepara la pagina html finale con i risultati.
Se non si ritiene necessario un diagramma delle attività, occorre almeno indicare il requisitonon funzionale nelle note.
Questo fatto lo può difatti giudicare solo l’analista che conosce la quantità di dati in gioco che
potrebbero o meno portare al timeout del web server. Un analista non deve mai dare perscontato che tale fatto venga intuito dagli sviluppatori: va dichiarato.Se il requisito, attraverso gli use case, non è sufficientemente dettagliato, allora è in fase dianalisi di requisiti (quando cioè si parla anche di architettura e di conseguenza di tecnologia) sideve aumentare il dettaglio degli use case, specie di quelli critici.
Add a Comment