Lezione ID 2010 -3
24
-
Upload
marco-loregian -
Category
Education
-
view
545 -
download
7
Transcript of Lezione ID 2010 -3
Scenario-based design
Requisiti (in senso lato): affermazioni sulle situazioni di uso, bisogni dell’utente, opportunità offerte dal sistema, trasformazioni degli usi correnti, ...
Analisi dei requisiti:
Introduzione
Modelli tradizionali dell’ingegneria del software (cascata, …): cicli di richieste/offerte tra progettisti e clienti
approcci basati su decomposizione e controllo
nuove features, tecnologie, …
Participatory design: lavoro congiunto di utenti e progettisti, scambio di prospettive
risultato più accurato
i requisiti emergono nel corso delle attività, e ogni attività evoca viste differenti del problema, e si elicitano requisiti di diverso tipo
Specifiche di possibili casi d’uso astratti, possibili sequenze di eventi (istanze)
Espressi in UML in forma diagrammatica
Non esprimono gli aspetti di utilità e usabilità di un sistema
Non sono articolati a livello cognitivo (non esprimono gli obiettivi dell’utente, aspettative, reazioni, ...)
Non sono parte del contesto per il processo di design del prodotto (del “design rationale”, poiché esprimono le funzionalità, non le caratteristiche)
Use cases
http://www.iua.upf.edu/~dgarcia/Codders/DotUmlUseCases.html
{ per
gli info
rmatic
i }
Scenario: Textual description or narrative of a use episode
Described from the user point of view and may include social background, resource (e.g. disk space, time) constraints and background information
May describe a currently occuring use, or a potential use that is being designed and may include text, video, pictures, story boards, etc.
By using a narrative it is possible to capture more information about the user's goals, and the context the user is operating in
The context might include details about the work place or social situation, and information about resource constraints. This provides some more help in understanding why users do what they do. In much current design work the users goals and context are often assumed implicitly, or may not be taken into account
Scenarios are stories
The scenario becomes the design object or artifact and may be augmented and rearranged as the design evolves
It can become a hypothetical interaction scenario for a new design and allow better understanding of the new design
It is also desirable to maintain a history of past scenarios as a way of capturing past design rationale
In one sense scenarios are not really new in design activity
It's extremely common in design to imagine “what if” situations, or to walk through a design in ones mind or in a group
Scenario-based design is an effort to make some of what we do already more conscious and explicit
Scenario-Based Design
Gli scenari evidenziano gli obiettivi suggeriti dall’aspetto (interfaccia utente, affordances) e dal comportamento (interno e visibile) del sistema, e cosa gli utenti cercano di fare col sistema stesso (quali procedure sono adottate, quali scartate, quali errori si commettono, ...)
Aiutano a spiegare i flussi di azioni (workflow, vd. activity-centered design), e ad evidenziare le situazioni critiche (breakdown)
Scenari
Ambientazione
Agenti e attori, con i rispettivi (sub)goal e obiettivi
Trama: azioni ed eventi, con (eventuali) conseguenti cambi di obiettivi
Elementi caratteristici di uno scenario
Perso
na
IdeazioneScelta di una
tecnica narrativa
Sviluppo della
narrativa
Presentazione
...complicare a piacere
Prototipazione degli scenari
Testo
Storyboard, vignette
Video
Rappresentazione dal vivo (anche partecipata)
Tecniche narrative
http://www.celtx.com
Software free e multipiattaforma per scrivere (e condividere) sceneggiature
Da usare per i primi step
Per il progetto, potete scegliere a che livello fermarvi, o quale approfondire
Screencasts:http://www.celtx.com/walkthru/
Sviluppo della narrativa,per esempio: CeltX
La riflessione nel design
Le situazioni nel design sono fluide
Le scelte di design hanno molteplici conseguenze
Tecnologia al servizio del design, non viceversa
Vincoli esterni (di lavoro) al design
Le sfide della progettazione tramite scenari
I progettisti devono continuamente riflettere sia sul prodotto che sul loro ruolo nel processo
Gli scenari aiutano a confrontarsi con persone con ruoli, esperienze, e percezioni diverse
Ogni proposta è frutto di una visione parziale del problema
La creazione collaborativa di scenari aiuta a conciliare concretamente differenti visioni
La discussione degli scenari aiuta ad avere awareness del processo
Gli scenari aiutano a superare le barriere imposte dallo sviluppo di prototipi “tecnologici”
Design e riflessione
Rigore tecnologico vs. immaginazione di nuove soluzioni
Elaborare uno scenario non corrisponde alla definizione precisa/algoitimica di una soluzione tecnica/tecnologica ma solo dei requisiti e delle caratteristiche ad alto livello
Si descrive il comportamento di un sistema a macro-passi, poi per l’implementazione nel dettaglio “si vedrà” (fatto salvo che bisogna essere realistici, e quindi avere idee precise sulla tecnologia)
Gli scenari possono essere astratti e categorizzati
L’elaborazione degli scenari (documentazione su diverse istanze del problema) può portare nuova conoscenza tecnica
Conoscenza tecnica e design
L’analisi è sempre un po’ incerta, perché il mondo cambia di continuo (grazie al design stesso)
Specialmente quando la progettazione incorpora tecnologie in rapida evoluzione: più una proposta ha successo, maggiore sarà la sua variabilità
Scenari e Fluidità
Ci sono aspetti positivi e negativi, esempi:
Positivi: continua spinta all’innovazione, evoluzione del business e delle condizioni di vita, ...
Negativi: impatto sull’ambiente a discapito della sostenibilità, le skill possedute e richieste cambiano di continuo (forte instabilità del mercato del lavoro e della formazione); l’instabilità si ripercuote spesso anche sul finanziamento dei progetti (grandi flop), …
Scenari e Fluidità
Gli scenari hanno il grande pregio di essere concreti (soluzioni precise e specifiche per evitare il rischio di essere assorbiti dall’indeterminatezza) e flessibili (rivisitazioni e correzioni per adeguarsi al cambiamento) al tempo stesso
Prototipazione iterativa e raffinamento
Punti fissi nel processo (“milestones”)
Accessibili a persone con skill molto diverse
La progettazione è basata sui vincoli, altrimenti ci sarebbero troppe cose da fare
Ricordate: progettare vuol dire fare scelte precise e consapevoli
I requisiti, se identificati, sono la prima fonte di vincoli
La tecnologia rende alcune scelte impossibili (perché non esiste soluzione) ed altre irresistibili (perché di moda o fortemente affermate)
Esistono vincoli reali ed altri solo fittizi/superabili
es., non far digitare i manager (lavoro da segretarie)
Bisogna evitare o valutare bene gli stereotipi per mantenere il processo di progettazione nel caso reale
Gli scenari sono work-oriented: devono mostrare il sistema all’opera, con l’utente
Tutti gli stakeholders devono essere rappresentati in uno scenario
Fattori esterni e vincoli
Ogni scelta progettuale ha delle conseguenze: una caratteristica di un prodotto influenza le altre
es. estetica vs. acustica vs. proprietà meccaniche di uno strumento musicale
Gli scenari possono essere usati per presentare prospettive diverse
es. annotazioni testuali vs. vocali ←→ overhead vs. frustrazione
Le relazioni fra i diversi fattori sono lasciate implicite ma i possibili aspetti critici possono essere molto dettagliati
Valutazione delle conseguenze
Il problema fondamentale è incoraggiare, supportare e direzionare in maniera produttiva la riflessione presente nel processo di progettazione
I progettisti riflettono, pur sapendo che è impossibile ponderare tutto (effetti, dipendenze, ...)
Gli scenari fanno progredire verso una soluzione (almeno scartando alcune opzioni)
Sintesi
interaction time!
Scenari
http://www.onepuglaundry.com/dublin.htm
http://commons.wikimedia.org/wiki/File:Estacio_bicing_bcn.jpg
Riferimenti & Creditshttp://ldt.stanford.edu/~gimiller/Scenario-Based/scenarioIndex2.htm
Dan Saffer, Design dell’interazione, Pearson Education (capitoli 4, 5)
Carroll, J. M. 1999. Five Reasons for Scenario-Based Design. In Proceedings of the Thirty-Second Annual Hawaii international Conference on System Sciences-Volume 3 - Volume 3 (January 05 - 08, 1999). HICSS. IEEE Computer Society, Washington, DC, 3051. http://ieeexplore.ieee.org/iel5/6293/16783/00772890.pdf
Da leggere
